Design Refinement and Requirements Satisfaction in
Download
Report
Transcript Design Refinement and Requirements Satisfaction in
Ontological Foundations
For SysML
Henson Graves
September 2010
1
INCOSE MBSE Roadmap
MBSE Capability
Reduced cycle times
System of systems
interoperability
Design optimization across broad trade space
Cross domain effects based analysis
June 15, 2008
Well
Defined
MBSE
Maturity
Institutionalized
MBSE across
Academia/Industry
This talk
fits here
Distributed & secure model repositories
crossing multiple domains
Defined MBSE theory, ontology, and formalisms
Architecture model integrated
with Simulation, Analysis, and Visualization
Matured MBSE methods and metrics,
Integrated System/HW/SW models
Ad Hoc MBSE
Document Centric
Emerging MBSE standards
2010
Refer to activities in
the following areas:
•Planning & Support
•Research
•Standards Development
•Processes, Practices, & Methods
•Tools & Technology Enhancements
•Outreach, Training & Education
2020
2025
INCOSE IW09 MBSE Workshop
2
Outline
Why is an MBSE reasoning formalism so important
Lessons from applying OWL to engineering
applications
Steps toward integrating OWL reasoning with SysML
3
Reasoning Is Required Multiple Places In
The Systems Engineering Process
Are requirements
consistent
Are implementations
feasible
Is design sufficiently
detailed for
implementation
Can an implementation
satisfy design
requirements
Do proposed
modifications stay
within design
constraints
Deployment
Requirements
Test &
Verification
Design
Develop
requirements
specifications
Implementation
Develop
design
specifications
Check
specification
consistency
Check
integration
design
consistency
Perform
integration
tests
Verify that
implementatio
n realizes
specifications
Perform
verification
tests
Verify
product
satisfies
requirements
Produced by Engineering Tools
Produced by Reasoning Tools
… Long history of attempting to use formal methods for engineering, with
mixed success, often too hard to use, doesn’t scale
4
Size And Complexity Put Bounds On Manual
Analysis
Design
WBS Partition
150
Build
Architecture
Decomposition
Design for
Implementation
Support
As Built
Design
As Maintained
Design
15000
1500
2
Rush Time
3
Last Skier
4
Ru
sh Ti me
Check
Line
1
5
Impatient Skier
2
Stan d ar d Ti me
3
L ast Ski er
4
5
C h eck L i n e
I mp ati en t Ski er
6
Line
7
Lift 1
8
Lift 2
6
Line
7
8
9
Ski
L i ft 1
9
10
Go Home
Ski
10
Go H o me
L i ft 2
Many enterprises use
modeling extensively but the
result is an enormous
collection of non-integrated
models - Situation is worse
than in document centric
development
5
Where Does One Look For Formal Logical
Foundation For Modeling Systems: OWL
Designed for conceptual modeling
represents more than 20 years of research
Extensive experience model complex physically
structured systems in the life sciences and medicine
Logic based modeling language
Optimized reasoning algorithms
designed so as to be decidable (arbitrary queries can
be answered)
W3C language standard with tool support
Designed so as to allow for extensibility
… its clear that OWL and UML/SysML have significant overlap
6
Ian Horrocks Helped Me Develop An OWL Air
System Ontology in Protégé To Answer:
Can OWL provide semantic
foundation and integration
for MBSE
Could OWL work where other
approaches have failed?
Can ontologies capture meaning of
concepts independent of
interpretation by subject matter
experts?
Can automated reasoning be used
to check design properties such as
consistency and conformance with
specification?
Paper in OWL Experiences and Directions 2008
7
The OWL Experience
One can build OWL ontologies to represent static
structure of systems
Used reasoning to verify design consistency with
requirements and other questions
We made extensive use of an Upper Ontology
Some requirements not (easily) expressible OWL
Weight of product is sum of weights of components
Behavioral requirements
Representing a “detailed design” in OWL is difficult
(where all valid implementations have the same parts
structure and connection relationships)
The experience led me to focus on how to represent detailed
designs, first in OWL and its extensions, and then in SysML
8
Which Models (Ontologies) Have The Property That All
Valid Implementations Have The Same Structure?
Model
Rule out implementations with
two fingers sharing distal
phalange
Hands with 500 fingers
Non-connected fingers as part
of hand
Then can argue from a specific implementation to any implementation
9
How Can a Model Be Characterized So All
Implementations Have The Same Structure?
A Water Model
Used To
Generate 3D Visualization
of implementation
Answer questions about
mass, size, geometrical
shape, …
Develop examples and generalize
10
Yvonne Bijan and I Have a SysML Model And a
Proof That All Implementations Of Are The Same
This is a prototypical design
analysis/verification problem
If all implementations are the
same you can calculate or
measure weight of individual
molecule
Another version of problem is
when is a design sufficiently
complete that it can be
implemented
The two diagrams which are part of the
water model show both the parts
structure and the bond connection
… we are building the models directly in SysML but have to go
outside SysML for reasoning
11
We Had To Add Some Additional Axioms For
Water That May Be Implicit In SysML
Issues arising in the proof
Does any valid implementation of
Water have exactly three atoms
Language concepts and constructs
match modeling domain
Maybe it is implied by the SysML
spec, but we had to add it
The covalent bond is a SysML
connection between parts
We added the equation
hasHydrogenAtom.covalentBond
= hasOxygenAtom
We also had to make assumptions
about restrictions of properties
… we have (we think) a general concept of structural template that
can be validated by SysML tools
12
SysML Has Language Constructions Not In
OWL
Variables & operations
Constraints
Behavior
Role properties, e.g.,
part properties and
other component
properties
OWL reasoning can be made
to work where languages
overlay, but the reasoning
requires extension for full
SysML
Constraints used to generate 3D visualization
13
Conclusions: Providing SysML With A
Logical Foundation
is feasible and it …
Enables engineers to work in a good user friendly
language integrated with valid reasoning tools
Engineers are able to employ benefits of logic without
having to learn special logical language syntax
Provides better integration with simulation
Provides a check on expressiveness and coherence
Provides potential language candidate extensions for
SysML and OWL2
There is a strong case that OWL and SysML can be unified with benefits
to both
14
Next Steps
Develop SysML use cases for inference
Develop rules to translate SysML to an extended
OWL2
Export SysML to reasoner and reimport results
Develop template validation code for SysML tools
Verify SysML logic retrofit is computationally
tractable
15