How Systems Engineering With SysML

Helps in Complex Systems Design?

Dr. Saulius Pavalkis

3DS (No Magic, Inc.)
Topics

1. What Drives Complexity Of New Systems Design?

2. Systems Engineering To Manage Complexity
3. Systems Engineering Framework And Method
4. Case Study

2
WHAT DRIVES COMPLEXITY OF NEW
SYSTEMS DESIGN?

3
New Systems Challenges: What Drives Complexity?

• Cyber Components (Electrical, Software, Mechanical)

• Software Centric

4
New Systems Challenges: What Drives Complexity?

• Short Time to Market

5
New Systems Challenges: What Drives Complexity?

• Limited Resources

NASA’s Curiosity rover

landed on Mars in 2012,
in part to analyze rocks to
see whether the Red
Planet was ever A selection of the 23 cameras on NASA's 2020
habitable (or inhabited) Mars rover (Credit: NASA/JPL-Caltech)
6
SYSTEMS ENGINEERING TO MANAGE
COMPLEXITY

7
What is Model Based Systems Engineering (MBSE)?

From the INCOSE SE Handbook Version 4

“The formalized application of

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

8
What Makes MBSE Different

• It helps avoid catastrophic mistakes by enhancing and significantly lowering

the costs of feasibility studies, tradeoff analysis, and impact analysis
• The entire specification set about the system that the model captures is an
interconnected network of information
• As opposed to being spread out in non-searchable and non-navigable set of
documents that require dedicated staff to manage

Future: Shared system model with multiple

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

9
How do you do MBSE?

MBSE is a combination of a
modeling language(s), a
methodology, a modeling tool,
A
and people that using
modeling
language infrastructure apply Model
Driven Development in the
A context of a particular
modeling
method organization.

A modeling tool

10
SysML Language

• Systems Modeling Language (SysML) is a graphical modeling language

for specification, analysis, design, verification and validation of
systems.
• Developed by OMG and INCOSE / Adopted by OMG in May 2006
• ISO Standard
• Cover the latest SysML version 1.5, active work is done on 2.0
UML reused
Tutorial, specifications, papers, and by SysML
vendor info can be found on the (UML4SysML)

OMG SysML Website at

UML 2 SysML
http://www.omgsysml.org/
Not SysML’s
required by extensions
SysML to UML

11
System Model as an Integration Framework

© 2012-2014 by Sanford Friedenthal

12 12
An Interconnected Network of Information

13
SYSTEMS ENGINEERING FRAMEWORK AND
METHOD

14
System engineering process (V process)

Credits: Pawel Chadzynski & Michael Pfenning - MBSE and the Business of Engineering
15
Systems Engineering Activity

Analyze •Causal analysis

Major SE Development Activities
Stakeholder •Mission use cases/Scenario
Needs •Domain model
System
Optimize & Analyze •System context Specificatio
System •System use case/scenarios n
Evaluate
Alternatives Requirements
•Critical parameters Define •Logical decomposition
•Trade studies & analysis Logical •Logical scenarios
Architecture •Logical subsystem interconnection
Manage Support
Requirements Validation &
Traceability Verification •HW/SW/Data
Synthesize
architecture
•Requirements Trace •Test cases Physical
•Physical
•Impact Analysis •Test procedures Architecture
interconnection
•System deployment
Common Sub-activities (Automatic with MBSE)

16
MBSE Focus SE Activities

Tower. James. 2013. “ Model Based Systems Engineering ‘The State of the Nation’” INCOSE UK
ASEC 2013

17
MagicGrid

Pillar

Requirements Behavior Structure Parametrics

Concept

Use System
Stakeholder Needs
Layer of Abstraction

Cases Context
Specification

Measurements of
Effectiveness
Problem

System Logical Subsystems

Functional Analysis
Requirements Communication
Solution
Design

Component Component Component Component

Requirements Behavior Structure Parameters

18
18
CASE STUDY

20
Case Study of CAR Climate Control

• The CAR Climate Control case study follows the MagicGrid

approach to describe the concept, problem, and Solution
• The model of the case study is based on SysML 1.4 and
created with MagicDraw CASE tool

21
21
Stakeholder Needs

Pillar

Requirements Behavior Structure Parametrics

C1 C2 C3
Concept

Stakeholder Use Cases System Context

Needs
Layer of Abstraction

C4-P4 Measurements
of Effectiveness
P1 P2 P3
Problem

System Functional Analysis Logical Subsystems

Requirements Communication

S1 Component S2 S3 S4
Solution

Requirements Component Behavior Component Component

Structure Parameters

22
Stakeholder Needs
• The cell represents information gathered from all the
stakeholders of the system
• It includes primary user requirements, government
regulations, policies, procedures, etc.
• The later refinements in the model make these
stakeholder needs structured and formalized

23
23
Use Cases

Pillar

Requirements Behavior Structure Parametrics

C1 C2 C3
Concept

Stakeholder Use Cases System Context

Needs
Layer of Abstraction

C4-P4 Measurements
of Effectiveness
P1 P2 P3
Problem

System Functional Analysis Logical Subsystems

Requirements Communication

S1 Component S2 S3 S4
Solution

Requirements Component Behavior Component Component

Structure Parameters

24
24
Use Cases

26
26
System Context

Pillar

Requirements Behavior Structure Parametrics

C1 C2 C3
Concept

Stakeholder Use Cases System Context

Needs
Layer of Abstraction

C4-P4 Measurements
of Effectiveness
P1 P2 P3
Problem

System Functional Analysis Logical Subsystems

Requirements Communication

S1 Component S2 S3 S4
Solution

Requirements Component Behavior Component Component

Structure Parameters

27
27
© 2016 No Magic, Inc. Exclusively for No Magic Use
System Context

29
29
Measurements of Effectiveness (MoEs)

Pillar

Requirements Behavior Structure Parametrics

C1 C2 C3
Concept

Stakeholder Use Cases System Context

Needs
Layer of Abstraction

C4-P4 Measurements
of Effectiveness
P1 P2 P3
Problem

System Functional Analysis Logical Subsystems

Requirements Communication

S1 Component S2 S3 S4
Solution

Requirements Component Behavior Component Component

Structure Parameters

30
30
Measurements of Effectiveness (MoEs)

32
32
System Requirements

Pillar

Requirements Behavior Structure Parametrics

C1 C2 C3
Concept

Stakeholder Use Cases System Context

Needs
Layer of Abstraction

C4-P4 Measurements
of Effectiveness
P1 P2 P3
Problem

System Functional Analysis Logical Subsystems

Requirements Communication

S1 Component S2 S3 S4
Solution

Requirements Component Behavior Component Component

Structure Parameters

33
33
System Requirements

35
35
Functional Analysis

Pillar

Requirements Behavior Structure Parametrics

C1 C2 C3
Concept

Stakeholder Use Cases System Context

Needs
Layer of Abstraction

C4-P4 Measurements
of Effectiveness
P1 P2 P3
Problem

System Functional Analysis Logical Subsystems

Requirements Communication

S1 Component S2 S3 S4
Solution

Requirements Component Behavior Component Component

Structure Parameters

36
36
Functional Analysis

38
38
Functional Analysis

39
Logical Subsystems Communication

Pillar

Requirements Behavior Structure Parametrics

C1 C2 C3
Concept

Stakeholder Use Cases System Context

Needs
Layer of Abstraction

C4-P4 Measurements
of Effectiveness
P1 P2 P3
Problem

System Functional Analysis Logical Subsystems

Requirements Communication

S1 Component S2 S3 S4
Solution

Requirements Component Behavior Component Component

Structure Parameters

40
40
Structure – Product Tree

42
Interfaces

43
Logical Subsystems Communication

44
44
Component Assembly

Pillar

Requirements Behavior Structure Parametrics

C1 C2 C3
Concept

Stakeholder Use Cases System Context

Needs
Layer of Abstraction

C4-P4 Measurements
of Effectiveness
P1 P2 P3
Problem

Goals & Objectives Functional Analysis Logical Subsystems

Communication

S1 Component S2 S3 S4
Solution

Requirements Component Behavior Component Component

Assembly Parameters

45
45
Component Assembly

47
47
MagicGrid

Pillar

Requirements Behavior Structure Parametrics

Concept

Use System
Stakeholder Needs
Layer of Abstraction

Cases Context
Specification

Problem

Goals & Objectives Functional Analysis Logical Subsystems

Solution
Design

Component Component Component Component

Requirements Behavior Assembly Parameters

48
48
Enable Traceability – Digital Thread

49
Conclusions

• Systems engineering support complex multidisciplinary systems design.

• Because of formalization and transparency MBSE with SysML and
method / framework support complex systems design automation and
integration.
• Requirements are no longer abstract text paragraphs. Now they are
formalized with models which allows efficient traceability and
optimization between stakeholder needs to electrical, software and
mechanical components even at the most complex systems.

50
50
[email protected]

THANK YOU!

51