International Workshop

25 Jan – 26 Jan 2014

Torrance, CA, USA

Model-based Systems Engineering

(MBSE) 101
Moderated by
Elyse Fosse,
Jet Propulsion Laboratory,
California Institute of Technology
Presented at Board Meeting
25 January / 26 January 2014
MBSE
©2014 California Institute of Technology. Government sponsorship acknowledged Workshop
 International Workshop

Agenda
25 Jan – 26 Jan 2014
Torrance, CA, USA

• Objective
• Acknowledgements
• FAQ list
• FAQ answers
• JPL MBSE Lessons Learned
• Additional questions from Day 1

Audience participation encouraged throughout

MBSE
Workshop
 International Workshop

Objective
25 Jan – 26 Jan 2014
Torrance, CA, USA

• Provide answers to frequently asked MBSE

questions
– Answers are from a Jet Propulsion Laboratory
(JPL)-centric view
• Will use a list of FAQs as a starting point
• Audience provided questions/interactions are
encouraged

MBSE
Workshop
 International Workshop

Acknowledgements
25 Jan – 26 Jan 2014
Torrance, CA, USA

• The FAQs and answers included have been

collected from the presentations and
experiences of:

• Todd Bayer • Sanda Mandutianu

• Daniel Dvorak • Louise Anderson
• Sanford Friedenthal* • Elyse Fosse
• Steve Jenkins • Bjorn Cole
• Chi Lin • Chris Delp

*JPL, Lockheed

MBSE
Workshop
 International Workshop

FAQ (1 of 2)
25 Jan – 26 Jan 2014
Torrance, CA, USA

1. What is MBSE?
2. What SE problems does MBSE address?
3. What is SysML?
4. What is a system model?
5. What are typical purposes of modeling?
6. What are the different types of models
7. How are the different types of models
integrated?

MBSE
Workshop
 International Workshop

FAQ (2 of 2)
25 Jan – 26 Jan 2014
Torrance, CA, USA

8. How can models help a SE effort?

9. What does MBSE mean for projects?
10. How does MBSE Compare to Traditional SE?
11. How good is a model?
12. What is an ontology?
13. Why are ontologies relevant?

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Torrance, CA, USA

FAQ 1: What is MBSE?

MBSE
Workshop
 International Workshop

MBSE Definition
25 Jan – 26 Jan 2014
Torrance, CA, USA

“Model-Based Engineering (MBE): An approach to engineering

that uses models as an integral part of the technical baseline that
includes the requirements, analysis, design, implementation, and
verification of a capability, system, and/or product throughout the
acquisition life cycle.”

Final Report, Model-Based Engineering Subcommittee, NDIA, Feb. 2011

“Model-based systems engineering (MBSE) is the formalized

application of modeling to support system requirements, design,
analysis, verification and validation activities beginning in the
conceptual design phase and continuing throughout development
and later life cycle phases.”

INCOSE SE Vision 2020 (INCOSE-TP-2004-004-02, Sep 2007)

MBSE
Workshop
 International Workshop

MBSE Motivation
25 Jan – 26 Jan 2014
Torrance, CA, USA

 Systems Engineering requires structural, behavioral, physics and

simulation-based models representing the technical designs which
evolve throughout the life-cycle, supporting trade studies, design
verification and system V&V.
 Current practice tends to rely on standalone (discipline-specific)
models whose characteristics are shared primarily through static
documents.
 MBSE moves toward a shared system model with remaining
discipline-specific models providing their characteristic information in
a mathematically rigorous format. All disciplines “view” a consistent
system model.

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Current Practice to Future Practice Torrance, CA, USA

Future: Shared system

Today: Standalone
model with multiple
models related
views, and connected to
through documents
discipline models

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Torrance, CA, USA

FAQ 2: What SE Problems does

MBSE address?

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
JPL-Identified Problems in SE Torrance, CA, USA

1. Mission complexity is growing faster than our ability to manage it

…increasing mission risk from inadequate specification & incomplete
verification
2. System design emerges from the pieces, not from an architecture
…resulting in systems which are brittle, difficult to test, and complex and
expensive to operate.
3. Knowledge and investment are lost at project lifecycle phase boundaries
…increasing development cost and risk of late discovery of design problems.
4. Knowledge and investment are lost between projects
…increasing cost and risk; damping the potential for true product lines
5. Technical and programmatic sides of projects are poorly coupled
…hampering effective project decision-making; increasing development risk.

JPL IOM-3100-09-040, "The Need for an Integrated Model-Centric

Engineering Environment at JPL", 24 Oct 2009, Todd Bayer

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Industry-Identified Problems in SE Torrance, CA, USA

1. Poor integration of models across the life cycle*

…hard to get coherent, checkable model of the whole system
(at some level of abstraction)
2. Limited reuse of models between programs*
…paying for similar engineering work over and over
3. Variation in modeling maturity and integration across Engineering
Disciplines (e.g., systems, software, mechanical , electrical, test,
maintainability, safety, security)*
…Mechanical/Electrical CAD/CAE fairly mature
…Systems/Software/Test fairly immature

* NDIA Final Report, Model Based Engineering Subcommittee

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
How MBSE Addresses Problems Torrance, CA, USA

Structural Operations
Model Plan

Power Mass
Model Roll-up

Thermal Software
Model Model

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Torrance, CA, USA

FAQ 3: What is SysML?

MBSE
Workshop
 International Workshop

SysML Defined
25 Jan – 26 Jan 2014
Torrance, CA, USA

• The OMG Systems Modeling Language (OMG SysML™) is a general-

purpose graphical modeling language for specifying, analyzing,
designing, and verifying complex systems that may include hardware,
software, information, personnel, procedures, and facilities.
• It provides graphical representations with a semantic foundation for
modeling system
– Requirements
– Behavior
– Structure
– Parametrics
• It extends a subset of OMG Unified Modeling Language (OMG UML™)
version 2
• First version (1.0) released September 2007
• Current version (1.3) released June 2012

MBSE
Workshop
 International Workshop

SysML Development
25 Jan – 26 Jan 2014
Torrance, CA, USA

• The SysML specification is a product of the Object Management Group

(OMG)
– an international, open membership, not-for-profit computer industry
consortium
• SysML development is performed under the auspices of a Revision Task
Force
– SysML v1.3 RTF has just concluded
– SysML v1.4 RTF now under way
• NASA is a member of OMG
• JPL has strong influence on both RTFs
– Nicolas Rouquette represents NASA at OMG and serves on UML
and SysML RTFs
– Sanford Friedenthal chairs the Systems Engineering Domain
Special Interest Group and consults for JPL

MBSE
Workshop
 International Workshop

What SysML Is Not

25 Jan – 26 Jan 2014
Torrance, CA, USA

• SysML enables MBSE, but MBSE doesn’t equal SysML; MBSE typically
uses SysML as a standard visual modeling language and lingua franca,
but is not limited to it

• SysML is not intended to replace current investment in modeling in the

other engineering disciplines. (Nor could it.)

• It is intended that SysML-based models be the framework for

interoperating with these discipline models, thus enabling integrated
model-centric engineering

• SysML is not a methodology or a tool

– SysML is a language
– SysML is methodology- and tool-independent

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Torrance, CA, USA

FAQ 4: What is a System Model?

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
System Model Defined Torrance, CA, USA

1. Structure 2. Behavior A system model

is an
interconnected
c ate set of model
allo
elements that
value represent key
binding system aspects
satisfy including
structure,
behavior,
requirements,
and parametrics

Verify
3. Requirements 4. Parametrics
MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
System Model and Other Models Torrance, CA, USA

The system model exchanges information with discipline

specific models to form the authoritative, up-to-date
source of information at the system level

Requirements
Repository
Analysis Verification
Models Models
System
Model

Hardware
Software
Models
Models

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Torrance, CA, USA

FAQ 5: What are typical purposes

of modeling

MBSE
Workshop
 International Workshop

Model Purposes (1 of 2)
25 Jan – 26 Jan 2014
Torrance, CA, USA

• To align interests and share understanding

- The mission systems are usually created by people with different
interests and skills who must work together.
- A common model enables effective collaboration and helps to develop
common understanding.
• To balance competing priorities to maximize stakeholder value
- Offers a foundation for the systems to evolve, reuse, or integrate
without substantial rework
- Standard way of representing data across missions and it can be easily
understood by the stakeholders
• The modeling offers process discipline by supporting small,
iterative steps that can demonstrate incremental value and get
early and continuous feedback
- The model of a mission is built by composing common functions that
can be re-used across missions
- Increased efficiency of the system engineering process
- Increased reliability (common modules already proven)
- The model supports the addition of very specific functions without
impact on the common modules
MBSE
Workshop
 International Workshop

Model Purposes (2 of 2)
25 Jan – 26 Jan 2014
Torrance, CA, USA

• To describe a design in durable form

- Almost anything can be used for that
• To communicate a design to a set of stakeholders
- A common notation and familiar presentation idioms
- Standards (e.g., SysML) cover most of that
• To Relate analyses to design
- In general, a much harder problem
- Largely outside the scope of SysML, except to provide language extension
mechanisms that allow you to do this
- If done automatically, software tools to reason about models
- This is also outside the scope of SysML, but some SysML modeling tools provide some
help

Modeling is supported by software tools that minimize the

modeling efforts

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Torrance, CA, USA

FAQ 6: What are different types of

models?

MBSE
Workshop
 International Workshop

Model Types (High Level)

25 Jan – 26 Jan 2014
Torrance, CA, USA

• Different models render the system from different

perspectives
• Physical vs. abstract
• Domain-specific vs. domain-independent

• And in different manners

• Formal vs. informal
• Descriptive vs. procedural

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Model Types (More Detailed) Torrance, CA, USA

• Models apply to a wide range of domains (e.g., systems, software,

electrical, mechanical, human behavioral, logistics, manufacturing,
business, socio-economic, regulatory)
• Computer-interpretable computational model
• Time varying (e.g., performance simulations, structural dynamic analysis)
• Static (e.g., reliability prediction model)
• Deterministic or stochastic (e.g., Monte Carlo)
• May interact with hardware, software, human, and physical environment
• Includes input/output data sets
• Human-interpretable descriptive models (e.g., architecture/design such as
UML, SysML, UPDM, IDEF, electrical schematic, 3D CAD geometry,
DODAF 2.0)
• Symbolic representation with defined syntax and semantics
• Repository based (i.e., the model is stored in structured computer format)

• Supporting metadata about the models including assumptions, versions,

regions of validity, etc.
• MBE can also include the use of physical models (e.g., scale models for
wind tunnels or wave tanks)
MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Torrance, CA, USA

FAQ 7: How are different types of

models integrated?

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Integration By a System Model Torrance, CA, USA

Requirements
Repository
Analysis Verification
Models Models
System
Model

Hardware
Software
Models
Models

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Torrance, CA, USA

FAQ 8: How Can Models Help an

SE Effort?

MBSE
Workshop
 International Workshop

Reasoning About Models

25 Jan – 26 Jan 2014
Torrance, CA, USA

• We can use models to answer questions

• The questions may be about the system itself
– What is it?
– How does it work?
– Is the performance adequate?
– What happens if something breaks?
• The questions may be about the model
– Is it complete?
– Is it consistent?
– Does it support required analyses?
• The questions may be about the design artifacts
– Are all required documents present?
– Does each document contain all required content?
• We call answering these kinds of questions reasoning
– It doesn’t necessarily mean exotic, artificial intelligence MBSE
Workshop
31
 International Workshop
25 Jan – 26 Jan 2014
Reasoning About Completeness Torrance, CA, USA

What components «component»

«component» perform no function? ground
spacecraft
system

«performs»
«function» «function»
transmit receive
telemetry telemetry

«sends» «receives»
«message»
telemetry
packet

MBSE
Workshop
32
 International Workshop
25 Jan – 26 Jan 2014
Reasoning About Consistency Torrance, CA, USA

Are there illegal or meaningless «component»

«component» relationships in the model? ground
spacecraft «sends» «sends»
system

«performs» «performs»
«function» «sends» «function»
transmit receive
telemetry telemetry

«sends» «receives»
«message»
telemetry
packet

MBSE
Workshop
33
 International Workshop
25 Jan – 26 Jan 2014
Reasoning About Design Torrance, CA, USA

«component»
«component» Rule: Reserve mass mr
spacecraft
spacecraft of any component with
me: m 95e: kg
mr: 15 kg
parts is the difference
m
maa::130
130kg kg
between its ma and the
sum of ma of its parts
«contains» Rule: CBE mass me of
«component» «component»
telecom propulsion any component with
me:m 27
e:
kg
mr: 5 kg
me: 68 kg parts is the sum of me
maa: 35 kg ma: 80 kg mr: 7 kg
of its parts
Policy: me < ma for
«component» «component» «component» «component» every component
amplifier
me: 8 kg
ma: 10 kg
antenna
me: 19 kg
ma: 20 kg
tank
me: 38 kg
ma: 44 kg
✖
thruster
me: 30 kg
ma: 29 kg

me: estimated mass

ma: allocated mass
MBSE
Workshop
34
 International Workshop
25 Jan – 26 Jan 2014
Torrance, CA, USA

FAQ 9: What Does MBSE Mean

For Projects?

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
MBSE implications for projects Torrance, CA, USA

How does MBSE affect…

• deliverables?
• project schedule/milestones?
• project organization?
• processes (e.g. design, reviews, CM, model
mgmt, methodology…)?
• infrastructure?
• metrics?
MBSE
Workshop
 International Workshop

MBSE and Deliverables

25 Jan – 26 Jan 2014
Torrance, CA, USA

• Project still has to produce deliverables for each

review
• Some documents may be generated
automatically from system model
– This ensures that design and documents
are kept in sync Reports

HTML
Model Web
Transformers Pages

Simulation &
System Model Analysis
Ex:
Mathematica
Audits MBSE
Workshop
 International Workshop

MBSE and Schedule

25 Jan – 26 Jan 2014
Torrance, CA, USA

• Projects will need to schedule time and resources

to deploy infrastructure and train workforce
• Model development becomes infused within the
product development schedule

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
MBSE and Project Organization Torrance, CA, USA

• Everyone needs training, but not to the same depth

• Different levels of training for different levels of modeling

EVERYONE Under
st
using and and ex
Sy s M
L s t a n p re s s c o n c
dar d n ep
ot a t i o t s
n
SysML Models
MOST SEs
including Collaborate and develop models
leadership with help from core team

nt ributes
s t p r a c tices, co
be
Applies els
p r o d u c tion mod
to
CORE
TEAM

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
MBSE and Project Reviews Torrance, CA, USA

• It can affect reviews, but doesn’t Reviewers

have to
• Leverage the model by
reviewing the model itself
• Stakeholders focus on the
views of the system model
Models
that address their concerns

MBSE
Workshop
 International Workshop

MBSE and Infrastructure

25 Jan – 26 Jan 2014
Torrance, CA, USA

• Need:

– System modeling tool(s)

– Training (in modeling and in tool usage)

– Standards (modeling style guide, model management)

– Methodology*

SysML Modeling
Guide
* See “Survey of Model-Based Systems Engineering (MBSE) IMCE Team
Methodologies”, J. A. Estefan, 2008, INCOSE. Version: 9/24/11

http://www.omgsysml.org/MBSE_Methodology_Survey_RevA.pdf

MBSE
Workshop
 International Workshop

MBSE and Project Metrics

25 Jan – 26 Jan 2014
Torrance, CA, USA

• Easier to get data from models and update metrics

• Example metrics
– Quality of design
• Mass margin, power margin, data margin, cost, …
– Progress of design and development effort
• Completeness of component specs, # use case scenarios, …
– Estimated effort to complete design and development
• Constructive Systems Engineering Cost Model (COSYSMO) gets
inputs from system model (# requirements, # use cases, etc.)
– Others:
• Number of critical TBDs
• Stability of requirements and design changes over time
• Potential defect rates

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Torrance, CA, USA

FAQ 10: How does MBSE

Compare to Traditional SE?

MBSE
Workshop
 International Workshop
A Historical Perspective on SE and 25 Jan – 26 Jan 2014
Torrance, CA, USA
MBSE
• Way back when, systems and subsystems were on equal footing
• Over time, computers allowed pretty much all the domains - except systems - to
build rigorous modeling capabilities.
– Systems is the last to get this rigor because it’s the broadest, most conceptual,
and has by definition the full complexity of the system to deal with. So it’s the
hardest one to get rigorous about.
• SE has been at a disadvantage because of this
– Lacking this quantitative rigor, SE has had to rely too heavily on intuition,
overemphasizing the Art and neglecting the Science
• Systems needs to claim the rigor of its domain to restore balance
– Otherwise our systems will continue to be assemblages of components whose
performance and behavior must be discovered after assembly.
• MBSE provides this rigor

Source: Todd Bayer (JPL)

MBSE
Workshop

44
 International Workshop
25 Jan – 26 Jan 2014
MBSE: Consistency and Continuity Torrance, CA, USA

Transition to a rigorous
system model ensures
consistent modeling across
disciplines and continuous
access to this system model
between system levels and
across the life cycle
Past
• Specifications
• Interface requirements Future
• System design
• Analysis & Trade-off
• Test plans

Revision by GIT; Original Source: OMG SysML Tutorial (June 2008). Reprinted with permission. Copyright © 2006-2008 by Object Management Group.

MBSE
Workshop
 International Workshop
Modeling in Traditional Systems 25 Jan – 26 Jan 2014
Torrance, CA, USA
Engineering
• “Models have been used as part of document-based
systems engineering approach for many years, and
include functional flow diagrams, behavior diagrams,
schematic block diagrams, N2 charts, performance
simulations, and reliability models, to name a few.” *
• “However, the use of models has generally been limited
in scope to support specific types of analysis or
selected aspects of system design. The individual
models have not been integrated into a coherent model
of the overall system.” *
* A Practical Guide to SysML. Friedenthal, Moore and Steiner.

MBSE
Workshop
 International Workshop

What’s New About MBSE 25 Jan – 26 Jan 2014

Torrance, CA, USA

• Modeling is not new

– Flight projects have a strong legacy of modeling
(structural, thermal, circuit design, mission design…)
– Systems Engineering uses models also, though typically limited in
scope and duration. A set of requirements, an excel spreadsheet, and
a PowerPoint drawing are all models.

• What is new is …
– the availability of a formal modeling languages which can describe
systems, and
– the information engineering standards and tools which enable
integration of a system model with existing discipline models.

MBSE
Workshop

Page 47
 International Workshop

MBSE Benefits (1 of 2)
25 Jan – 26 Jan 2014
Torrance, CA, USA

MBSE enables overall better quality, lower cost, and

lower risk for the following reasons …

1. Modern modeling languages have clearer semantics than

common boxes-and-lines diagrams, reducing miscommunication
2. Consistent, single source of information keeps team on same
page and reduces time spent getting answers
3. Earlier detection of inconsistencies because models can be
analyzed with respect to calculations, policies, rules, patterns,
etc.
4. Documents are kept up-to-date because they can be auto-
generated from the system model

MBSE
Workshop
 International Workshop

MBSE Benefits (2 of 2)
25 Jan – 26 Jan 2014
Torrance, CA, USA

5. System model supports multiple views to address different stakeholder

concerns, but all views refer to same model elements, so changes in an
element appear on all views
6. Model-based simulation of state machines enables debugging and refinement
of behavioral requirements
7. System model evolves across life-cycle and may guide similar future projects
8. System model helps to better manage complexity

Summary
Formal systems models offer these benefits
because they introduce additional consistency and
continuity, and because they are both human- and
computer-understandable, and logically verifiable

MBSE
Workshop
 International Workshop

Comparison Summary
25 Jan – 26 Jan 2014
Torrance, CA, USA

• MBSE doesn’t replace traditional SE

Rather, MBSE formalizes part of SE

• MBSE combines traditional methods and best

practices with rigorous modeling techniques

• MBSE uses modeling languages that support

rigorous modeling techniques and integration
of various systems engineering disciplines
(structural, electrical, mechanical, software,
etc.) and stakeholders MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Torrance, CA, USA

FAQ 11: How good is a model?

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Some Objectives of Modeling Torrance, CA, USA

• To describe a design in durable form

– You can use almost anything for that
• To communicate a design to a set of stakeholders
– Now you need (at least) a common notation and familiar presentation
idioms
– Standards (e.g., SysML) cover most of that
• To organize and relate analyses of a design
– This is, in general, a much harder problem
– You have to make sure that every element that could affect an
analysis is present, properly identified, and consistently related to
appropriate other elements
• This is largely outside the scope of SysML, except to provide extension
mechanisms that allow you to define the rules
– You also need software to reason about your models
• This is also outside the scope of SysML, but some tools do
– Analysis operates on facts MBSE
Workshop
52
 International Workshop
Questions to Ask When Evaluating a 25 Jan – 26 Jan 2014
Torrance, CA, USA

System Model
• Meaning of the model
• Is the modeling notation expressive enough for the domain?
• Does it convey the conventional domain wisdom?
• Is the semantics of the model elements unambiguous?
• Can pertinent questions about the domain be answered?
• Model generic logical correctness
• Does it support “reasoning” about the model?
• Is the model complete?
• Does it support the required analyses?
• Does it support reasoning about the design?
• Does it support reasoning about the programmatic aspects?

MBSE
Workshop
 International Workshop

Is This A Model?
25 Jan – 26 Jan 2014
Torrance, CA, USA

ground
spacecraft
system

transmit receive
telemetry telemetry

telemetry Sure, why not?

packet

MBSE
Workshop
54
 International Workshop

Is It A Good Model?
25 Jan – 26 Jan 2014
Torrance, CA, USA

ground
spacecraft
system

transmit receive
telemetry telemetry

telemetry Not so much.

packet

MBSE
Workshop
55
 International Workshop

What’s Wrong With It?

25 Jan – 26 Jan 2014
Torrance, CA, USA

ground
spacecraft
system

transmit receive
telemetry telemetry

Same symbol for telemetry Same symbol for

different kinds of packet different kinds of
things relationships

MBSE
Workshop
56
 International Workshop

Better?
25 Jan – 26 Jan 2014
Torrance, CA, USA

ground
spacecraft
system

transmit receive
telemetry telemetry

Not much. Essential

distinctions are merely
suggested--they
telemetry should be explicit.
packet
MBSE
Workshop
57
 International Workshop
25 Jan – 26 Jan 2014
Making Distinctions Explicit Torrance, CA, USA

• Rather than merely hinting at distinctions with shapes or colors,

we could devise a set of types or classes to be applied to model
elements
• The set of types is application-dependent
– Systems engineers talk about different things from chefs
– The distinctions are whatever matters for your application
– Is red wine a different type from white, or is is merely a property of
wine?
• It depends on what you want to say about wine
• What kinds of things do systems engineers talk about?
– Component, Interface, Function, Requirement, Work Package, Product,
Process, Objective, Message, etc.
• Let’s apply some classes to our model
• For now, every element has
– one type, denoted like this: «type»
– one name, which identifies an individual of that type MBSE
Workshop
58
 International Workshop
25 Jan – 26 Jan 2014
Model With Typed Elements Torrance, CA, USA

«component»
«component»
ground
spacecraft
system

«function» «function»
transmit receive
telemetry telemetry

«message»
telemetry Much better.
packet

MBSE
Workshop
59
 International Workshop
25 Jan – 26 Jan 2014
Answering Questions (1 of 2) Torrance, CA, USA

«component»
«component» What components are present? ground
spacecraft system

«function» «function»
transmit receive
telemetry telemetry

«message»
telemetry
packet

MBSE
Workshop
60
 International Workshop
25 Jan – 26 Jan 2014
Answering Questions (2 of 2) Torrance, CA, USA

«component»
«component» What functions are present? ground
spacecraft
system

«function» «function»
transmit receive
telemetry telemetry

«message»
telemetry
packet

MBSE
Workshop
61
 International Workshop

Add Typed Relationships

25 Jan – 26 Jan 2014
Torrance, CA, USA

«component»
«component»
ground
spacecraft
system

«performs» «performs»
«function» «function»
transmit receive
telemetry telemetry

«sends» «receives»
«message»
Note that
telemetry
relationships are
packet
now directed.

MBSE
Workshop
62
 International Workshop
25 Jan – 26 Jan 2014
More Questions and Answers (1 of 4) Torrance, CA, USA

«component»
«component» What component performs the
function transmit telemetry? ground
spacecraft
system

«performs» «performs»
«function» «function»
transmit receive
telemetry telemetry

«sends» «receives»
«message»
telemetry
packet

MBSE
Workshop
63
 International Workshop
25 Jan – 26 Jan 2014
More Questions and Answers (2 of 4) Torrance, CA, USA

«component»
«component» What functions does the
component ground system ground
spacecraft
perform? system

«performs» «performs»
«function» «function»
transmit receive
telemetry telemetry

«sends» «receives»
«message»
telemetry
packet

MBSE
Workshop
64
 International Workshop
25 Jan – 26 Jan 2014
More Questions and Answers (3 of 4) Torrance, CA, USA

«component»
«component» What messages does the function
transmit telemetry send? ground
spacecraft
system

«performs» «performs»
«function» «function»
transmit receive
telemetry telemetry

«sends» «receives»
«message»
telemetry
packet

MBSE
Workshop
65
 International Workshop
25 Jan – 26 Jan 2014
More Questions and Answers (4 of 4) Torrance, CA, USA

What components perform a «component»

«component» function that sends or receives the ground
spacecraft message telemetry packet? system

«performs» «performs»
«function» «function»
transmit receive
telemetry telemetry

Alternatively, what
«sends» «receives»
component designs
«message» may be affected if the
telemetry definition of telemetry
packet packet changes?

MBSE
Workshop
66
 International Workshop

A Good Model
25 Jan – 26 Jan 2014
Torrance, CA, USA

• Describes a system design clearly and transparently

– In particular, it shows a flawed design to be flawed
• Communicates a system design effectively to an
incompletely bounded audience
– In particular, it uses standard, well-defined vocabulary and notation
• Lends itself to automated reasoning for
– validation in modeling domain (well-formedness, etc.)
– validation in engineering domain (performance, etc.)
– validation in programmatic domain (cost, schedule, etc.)
• Lends itself to automated transformation into
– analysis specifications for discipline-specific tools
– documents or other information products
• Narrows the risky and expensive gap between describing a
design and analyzing it
MBSE
Workshop
67
 International Workshop
25 Jan – 26 Jan 2014
Torrance, CA, USA

FAQ 12: What is an ontology

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Presentations Versus Facts Torrance, CA, USA

Presentation Facts

«component»
• spacecraft is a
spacecraft «component»
• transmit telemetry is a
«function»
«performs»
«function» • spacecraft «performs»
transmit
telemetry
transmit telemetry

SysML is (among other things) a We need other standards for

presentation standard our facts

MBSE
Workshop
69
 International Workshop

Facts and Ontologies

25 Jan – 26 Jan 2014
Torrance, CA, USA

• The field that deals with facts and reasoning is logic

• The subset of logic that deals with facts and their meaning is
ontology
• Ontologies contain axioms:
– Definitions of concepts and their specializations
• e.g., a Spacecraft is a Flight Component, which is a Component
• These are sometimes called classes
– Definitions of attributes of individuals of a class
• e.g., mass is a property of Flight Component
• These are sometimes called data properties
– Definitions of relationships among individuals
• e.g., a Component performs a Function
• These are sometimes called object properties
– Restrictions
• e.g., a Function isPerformedBy at most one Component
– Facts about individuals using these concepts and properties
MBSE
Workshop
70
 International Workshop
25 Jan – 26 Jan 2014

Ontology Definition Torrance, CA, USA

Ontologies provide descriptions

of concepts and their
relationships for a domain of
interest

Ontologies are agreements on

usage, more than a dictionary or
a taxonomy

Formal ontology standards provide

powerful mechanisms for automatic
domain specific reasoning

MBSE
Workshop
 International Workshop
Some Simple Ontology Reasoning 25 Jan – 26 Jan 2014
Torrance, CA, USA
Examples

Type Given this input A reasoner concludes

Consistency “has mass” is a functional property. Inconsistent: at least two
Determine whether Curiosity is a HardwareComponent. facts are mutually
individuals do not Curiosity has mass 850 kg. Curiosity has contradictory.
violate descriptions and mass 900 kg.
axioms

Rules Entailment Every Spacecraft is a Component. Every Every Orbiter is a

(satisfiability, Orbiter is a Spacecraft. Component. (therefore, all
subsumption) Component rules apply to
Orbiter.)
Facts Entailment Every Spacecraft is a Component. MSL MSL Rover is a
(satisfiability, Rover (an individual, not a class) is a Component.
subsumption) Spacecraft.

These examples are given in “equivalent” natural language, not OWL. The purpose is to show the
kinds of problems for which reasoning is useful, not to demonstrate the mechanics.

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Ontologies as Integrating Standards Torrance, CA, USA

• We use a lot of discipline-specific tools and

terminology in space flight systems engineering
– e.g., trajectory synthesis, radiation effects modeling
– SysML supports the broad discipline of systems engineering,
but we need a unifying vocabulary that can relate these
disciplines to each other
• This problem is not unique to space flight (nor to
systems engineering)
– Lots of people have been working on it for years.
• There is a set of international (W3C) standards for
defining and using ontologies
– All related to the Web Ontology Language (OWL)
• Can build OWL ontologies for disciplines of interest
MBSE
Workshop
73
 International Workshop
25 Jan – 26 Jan 2014
Example of SysML Profile Application Torrance, CA, USA

MBSE
Workshop
74
 International Workshop
25 Jan – 26 Jan 2014
Torrance, CA, USA

FAQ 13: Why are ontologies

relevant?

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Why Do We Care about Ontology? Torrance, CA, USA

• There is a well-developed body of theory that can

– help us avoid undecidable questions
• i.e., not solvable in principle
– help us avoid intractable questions
• i.e., solvable in principle but not in practice
• There is a body of tools that can
– help us edit our ontologies
– validate our ontologies
• i.e., tell us if they’re well-formed, consistent, and satisfiable
– compute inferences
• i.e., Blah is a Spacecraft and Spacecraft is a Component implies Blah is
a Component
• these are sometimes called entailments
– answer a large class of questions about facts
• i.e., What Components perform a Function that sends or receives the
particular Message? MBSE
Workshop
76
 International Workshop
25 Jan – 26 Jan 2014
Ontologies and SysML – which one? Torrance, CA, USA

• Ontology languages can be used to validate extensions to

SysML to address ambiguities
• SysML and its ontology extensions can be translated to ontology
languages.
– Disambiguate semantics of the modeling language
– Support automated checking and reasoning

Ontology languages enable modelers to design better and more

reliable models

This doesn’t mean that the systems engineers need to learn

ontology languages

MBSE
Workshop
77
 International Workshop
25 Jan – 26 Jan 2014
Torrance, CA, USA

Lessons Learned-Flight Project A

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Lessons Learned* (1 of 2) Torrance, CA, USA

1. Investment is crucial
– Project investment in tools, modeling environment, and training
2. Unity of leadership is essential
– Management must be willing to pay the startup costs and give
time for the effort to pay dividends
3. Best way to start modeling is to hire people who already know
how to do it
– Later infusions will benefit from an experienced pool of
engineers
4. Team organization matters
– 3-tiers: small set of core modelers, larger set of modeling-savvy
SEs, within larger set of project personnel
5. Everyone needs training, but not to the same depth

MBSE
* Source: Todd Bayer (JPL)
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Lessons Learned* (2 of 2) Torrance, CA, USA

6. Best way to figure out how to apply MBSE: do it for real

– “Shadow pilots” would not have been helpful
– Pressure to deliver real engineering products forces discovery and
resolution of problems not likely encountered in a shadow
7. Keep the focus on project deliverables, and model only as far as you
need to answer the questions
– This may need to be constantly reinforced
8. Description first, then analysis
– Just describing something in a formal model language immediately
improves communication and understanding
9. Separate models from analyses
– Mass analysis script is independent of system details
10. Real examples are powerful
– Much more effective at conveying understanding and building support

MBSE
* Source: Todd Bayer (JPL)
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Torrance, CA, USA

Lessons Learned-Flight Project B

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Lessons Learned* (1 of 2) Torrance, CA, USA

1. SE First- System Engineering needs/products dictate modeling

efforts
2. Incremental development – Build and evolve the model
incrementally, adding value to the project needs and products at
each increment
3. Focus on changes – Focus first on project/system aspects that
will most likely change or will be affected by change (e.g., greater
focus on components that interface with outside entities)
4. Leverage any and all tool development/modeling environment,
and training available

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Lessons Learned* (2 of 2) Torrance, CA, USA

5. Get the experts involved-cross training new-to-modeling SEs with new to

SE mbSEs allows for an ease in the adoption of new practices (both are
learning new things)
6. Separate concepts, from the model, from analyses- the patterns used to
populate the system model should be coupled to the system model in an
adaptable manner. Similarly with analysis models
7. Have to receive management buy in by showing them the SE job is not
negatively affected by the new methodology (takes no more time than usual
to generate SE products—hopefully less time)
8. Model validation rules help ease the fear to newcomers that they are going
to “mess up” the model.

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Appendix Torrance, CA, USA

Breakout Day 1 Additional Questions:

• What tools are available?
• How would you implement Agile development
with MBSE?

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Available Tools Torrance, CA, USA

OMG provides a list of vendors:

• http://www.omgsysml.org/#Vendors
SysML forum also provides a list of vendors:
• http://www.sysmlforum.com/tools/
Recommendations for tool comparison:
• http://www.sysmltools.com/article/selecting-a-
sysml-tool
/

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Agile Environment Torrance, CA, USA

Agile:
• Deliverable based
• Incremental approach
• Iterative
• Stakeholder driven

MBSE
Workshop
 International Workshop
Integrated Model-based Engineering 25 Jan – 26 Jan 2014
Torrance, CA, USA
Environment (MBEE)

System Model
Stakeholders: System/Sub-System Domain Experts, Project Managers…
Deliverables: Model-generated document artifacts, view artifacts, System
model

Metamodel
Stakeholders: System Model Team, System/Sub-System Domain Experts
Deliverables: SysML extended language, Domain specific patterns,
Viewpoints

Software Infrastructure
Stakeholders: Metamodel Team, System Model Team
Deliverable: Model transformations, Repository infrastructure

MBSE
Workshop
 International Workshop
25 Jan – 26 Jan 2014
Agile MBEE Torrance, CA, USA

1x System Model
Stakeholders: System/Sub-System Domain Experts, Project Managers…
Deliverables: Model-generated document artifacts, view artifacts, System
model

2x Metamodel
Stakeholders: System Model Team, System/Sub-System Domain Experts
Deliverables: SysML extended language, Domain specific patterns,
Viewpoints

3x Software Infrastructure
Stakeholders: Metamodel Team, System Model Team
Deliverable: Model transformations, Repository infrastructure

MBSE
Workshop