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