Model Based Collaborative Systems Engineering

Stphane Bucaille, PhD

Electrical and Computer Engineering Department

SYS 5390

Lecture #3, Slide 1

SysML language architecture

Modeling structure with package

MBSE Process remainder

SYS 5390

Lecture #3, Slide 2

SYS 5390

Lecture #3, Slide 3

MBSE Overview
Context MBSE: A myth or reality? MBSE Benefits MBSE Implementation Challenges MBSE process example Conclusions

SYS 5390

Lecture #3, Slide 4

Context
Systems increasing complexity Program over-costs and delays continuously increase as well

Aeronautics:
Dreamliner: $9B, 3 years A380: $10B, 15 months EPR: $4B, 5 years Next Gen Data Comm: $4.2B, from 2 months to 14 years!

Energy: Communications:

Reasons
Technology development and development dynamics Competition pressure Inability of traditional systems engineering approach to tackle increasing complexities
Hardware
Technologies Functions and Performance System Architectures and Interfaces Functions and capabilities Implementation techniques Cyber-security challenges Stakeholders Skills Processes and Tools Knowledge management and reusability

Software

Organizations

Slide courtesy of MBSE4All, LLC SYS 5390 Lecture #3, Slide 5

Context
Growing need for systems affordability and resilience This requires faster delivery of adaptable, trusted, assured, reliable and interoperable systems

Slide courtesy of MBSE4All, LLC SYS 5390 Lecture #3, Slide 6

MBSE: A myth or reality

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)

Slide courtesy of MBSE4All, LLC SYS 5390 Lecture #3, Slide 7

MBSE: A myth or reality

One definition
Generic
In support of systems engineering approaches

Only technical
Definition does not mention any business objectives

Many valuable questions

On changing core and development activities
Scope and reality of change (processes, skills, tools, organization) Buy-in by customers, partners, suppliers, and mostly internal teams!

On impact change
On efficiency and competitiveness On flexibility and agility to develop and offer rapidly cost effective and adaptable solutions

On transformation process
Where to start? How to deploy? How to measure implementation? At what cost and risk?

Slide courtesy of MBSE4All, LLC SYS 5390 Lecture #3, Slide 8

MBSE: A myth or reality

So why MBSE?
Is it just a buzz word? Why is it so deeply studied? worked out? utilized?
National and international Bodies: OMG, INCOSE, NDIA, NIST Governmental agencies: DoD, NASA Aerospace and Defense industries: Lockheed Martin, Northrop Grumman, General Dynamics, L3 Communications Energy (GE, AREVA, Alstom), Automotive (Ford)

Why is it becoming a standard for the complex systems industry?

According to OMG, 28% of DoD contracts granted in 2011were using MBSE approach Strong synergies with DoDAF methodology
Slide courtesy of MBSE4All, LLC SYS 5390 Lecture #3, Slide 9

MBSE: A myth or reality

In fact, this reflects a reality
MBSE is the future of SE
It combines traditional methods and best practices with rigorous modeling techniques It uses modeling languages that support integration of various systems engineering disciplines and stakeholders

Benefits demonstrated when methodology properly implemented

Kyocera Mita: 80 percent of design errors detected prior to production, leading to subsequent reduction in overall cost, while new product development time reduced by 30 percent (source: IBM) Proper implementation of MBSE lead to cut development costs by 50% and reduce time to market by 45% (source: IMTI 2009)

MBSE implementation is challenging many aspects of a corporation

The methodology is not unique nor universal
It does not replace SE, it formalizes part of it It is a framework and encompasses at least 5 different approaches Thus, it can or should be adapted/customized to any company

MBSE purely offers design processes, tools and SysML language, but proper implementation requires as well
Organization culture change, from document-based to model-based data trust Organization human resources diversification, appropriate training and support Organization/Projects management adaptation Organization transformation roadmap (Processes/IT/Structure)

Slide courtesy of MBSE4All, LLC SYS 5390 Lecture #3, Slide 10

MBSE: a continuity in history

Rigor now required in the system design process
As it is broadly in place for all other engineering disciplines

Mechanical or Electrical Design

An additional historical proof that shows how modelbased techniques enable and facilitate complexity management

Slide courtesy of MBSE4All, LLC SYS 5390 Lecture #3, Slide 11

Benefits
Enhanced Collaboration
By the use of a common language and collaborative platform Today: Standalone models Consistent, related through documents single source of information for the whole team

Future: Shared system model with multiple views, and connected to discipline models

Improved quality
Early identification of requirements/inconsistencies issues Enhanced system design integrity Improved specification of allocated requirements to HW/SW (SysML Simulation) Fewer errors during I&T More rigorous requirements traceability
Life Cycle Support

Increased productivity

Improved impact analysis of requirements changes Reuse of existing models to support design/technology evolution Auto-generation of up-to-date documentation
Improved cost estimates Early/on-going requirements validation & design verification

Reduced risk

Slide courtesy of MBSE4All, LLC SYS 5390 Lecture #3, Slide 12

Vertical Integration

MBSE Implementation challenges

MBSE Capability
Reduced cycle times System of systems interoperability Design optimization across broad trade space Cross domain effects based analysis

Institutionalized MBSE across Academia/Industry

Extending Maturity and Capability

Distributed & secure model repositories crossing multiple domains Defined MBSE theory, ontology, and formalisms

Maturity

Well Defined MBSE

Architecture model integrated with Simulation, Analysis, and Visualization Matured MBSE methods and metrics, Integrated System/HW/SW models

Refer to activities in the following areas:

Planning & Support Research Standards Development Processes, Practices, & Methods Tools & Technology Enhancements Outreach, Training & Education

Ad Hoc MBSE Document Centric

Emerging MBSE standards

2010

2020
INCOSE MBSE Development Roadmap

2025

Slide courtesy of MBSE4All, LLC SYS 5390 Lecture #3, Slide 13

MBSE Implementation challenges

Expertise creation
Core Team of experts, per domains, possibly transversal to organization
Develop modeling standards, ontologies Build reusable repository, libraries Provide support to system model developers Pair experts with new hire to extend buy in of the methodology Early support to ongoing projects

Training
3 level training (Core Team, SE and Management, Everybody else)

Repartition of roles and responsibilities (BUs/Corporate)

Who builds models for projects? Who interacts with specialized engineering teams? Who provides modeling environment and infrastructure? Who develops repositories, standards, processes, ontologies?...

Roadmap defined and approved by executive management

Slide courtesy of MBSE4All, LLC SYS 5390 Lecture #3, Slide 14

MBSE Implementation challenges

Prepare project management and teams:
Impact on deliverables
Use of automated reports Use of online reports Use of simulation tools

Impact on schedule, initially and thereafter

Initially schedule time
to deploy infrastructure to train workforce

Once approach is implemented

take advantage of the methodology reusability benefits!

Impact on reviews
Do not neglect hardware displays and communication technologies

Impact on metrics
implements rigorous metrics
Quality of Design Progress of Design and Schedule aspects Estimated effort to complete design and development Financial aspects (COSYSMO model) Others (# of critical TBDs)

Slide courtesy of MBSE4All, LLC SYS 5390 Lecture #3, Slide 15

MBSE Example Global Process

Slide courtesy of MBSE4All, LLC SYS 5390 Lecture #3, Slide 16

PoleSat Diagram Examples

Parametric Diagram

Altitude(km)

Orbit Orbit deltaL Time Inclination Period (deg) in View (deg) (s) (s)

Image Width (km)

Results in MS Excel

Field Number of Number Number of Number of Downlink Downlink Data of View Pixels of Pixels Pole Images Data Volume Rate (deg) in one in Image Passages Per Cycle (Bytes) (bits/s) dimension Per Cycle 87 79 73 68 63 59 56 801 818 835 853 870 887 905 642262 669747 697980 726969 756720 787243 818544 7 7 7 7 7 7 7 42 40 39 37 36 34 33 27096627 27088855 27083057 27079116 27076925 27076387 27077406 337651 303038 275777 253610 235143 219464 205945

Scenario 1 2 3 4 5 6 7

600 700 800 900 1000 1100 1200

97.87 98.28 98.70 99.13 99.58 100.04 100.53

5799 5923 6049 6175 6303 6431 6560

24 25 25 26 26 27 27

642 715 786 854 921 987 1052

1133 1157 1181 1206 1230 1255 1279

Slide courtesy of MBSE4All, LLC SYS 5390 Lecture #3, Slide 17

SYS 5390

Lecture #3, Slide 18

The SysML Language Specification (1/2)

Specifications published in September 2007
By the OMG Group In response to the requirement specified in the UML for SE RFP

Defines the SysML concepts

An abstract syntax (schema, described by a metamodel) A concrete syntax (notation, described using notation tables) The semantics (meaning of the language concept in the SE domain)

SYS 5390

Lecture #3, Slide 19

The SysML Language Specification (2/2)

SysML organized in language units
Model elements model-wide modeling concepts Requirements textual requirements, and their relationships to
Each other Models

Blocks system structure and properties Activities extension to UML activities to support continuous behavior Constraint blocks parametric models Ports and flows extensions to UML to support
flow of information, matter, energy between system elements

Allocations establish design relationships between model elements

SYS 5390

Lecture #3, Slide 20

The SysML Language Architecture

Domain concepts
Mapping of Domain concepts Instantiation and representation
SYS 5390

For the domain being modeled System Function

To language concepts Blocks Activities

Of the language concepts as they apply to a particular system Block called airplane Called user model

Lecture #3, Slide 21

The Modeling Domain

Objective: enable the description of some domain of interest
For SysML, domain of interest is the modeling of systems

Domain concepts defined in the UML for SE RFP specifications Requirements organized into concepts needed to model
Structure, Behavior, Properties, Requirements, other systems modeling constructs Ex: 6.5.1.1 System hierarchy. UML for SE shall provide to model the hierarchical decomposition of a system into lower-level logical or physical components

Bills plane: a typical system

SYS 5390

Lecture #3, Slide 22

The Modeling Language (Metamodel) (1/2)

Describes the concepts in the language, their characteristics and interrelationships
It is the abstract syntax

Individual concepts are described by metaclasses

Related to each other using relationships such as generalizations or associations With set of properties that characterize the language concept it represents And with a set of constraints that impose rules on the values for those properties

SYS 5390

Lecture #3, Slide 23

The Modeling Language (Metamodel) (2/2)

Profile: in UML, it is a mechanism used to customize UML language
Contains stereotypes, similar to metaclasses and used to create new or modified concepts. (used for the extension of UML in SysML) Figure shows two SysML concepts in the Blocks language unit of the SysML profile And how they relate to UML metaclasses Block extends Class. It is the fundamental structural concept in SysML Value Type extends Data Type. It adds quantitative features (unit, dimension)

Semantics: describe the meaning of its concepts in the domain of interest.

Described via mapping between the Domain concepts and the language concepts The domain concepts defined either in natural language or mathematical form.

SYS 5390

Lecture #3, Slide 24

The System Model (User Model) (1/2)

Consists of model elements that are instances of the metaclasses in the SysML metamodel.
A SysML Block may be instancied as an airplane, a fuselage, a wing and a landing gear The model elements are represented in this model conformed to the metaclass properties, constraints, and relationships defined by the metamodel These model elements are visualized using a concrete syntax mapped to the abstract syntax so that each symbol represents a specific concept

SYS 5390

Lecture #3, Slide 25

SysML Diagrams
In addition to a metamodel, SysML defines a notation (concrete syntax)
SysML Diagram

Behavior Diagrams

Requirement Diagram

Structure Diagrams

Activity Diagram

Sequence Diagram

State Machine Diagram

Use Case Diagram

Block Definition Diagram

Internal Block Diagram

Parametric Diagram

Package Diagram

Same as UML

Modified from UML

Not in UML

SYS 5390

Lecture #3, Slide 26

Diagram Frames

Diagram frames provide a visible context tor the diagram

Certain diagrams explicitly draw symbols on or to the frame boundary to indicate external interfaces of the model element represented by the diagram frame

Diagram Frame: rectangle with a header, or label, containing standard information on the top left corner.
The rest of the rectangle is the content area An optional diagram description can be attached to the frame boundary.

SYS 5390

Lecture #3, Slide 27

Diagram Header (1/4)

Diagram header (Label): rectangle with its lower right corner cut off. It includes:
Diagram kind: abbreviation indicating the type of diagram Model element type: type of model element that the diagram represents Model element name: name of the represented model element Diagram name: name of the diagram, usually to mention its purpose Diagram usage: keyword indicating a specialized use of the diagram

Diagram kind: takes on of the following values

SYS 5390

Activity diagram - act Block Definition Diagram bdd Internal Block Diagram ibd Package Diagram pkg Parametric Diagram par Requirement Diagram req Sequence Diagram sd State Machine Diagram stm Use Case Diagram uc
Lecture #3, Slide 28

Diagram Header (2/4)

Model Element type: represented by the diagram kind. Valid permutations
Activity diagram - activity Block Definition Diagram block, constraint block, package, model, model library Internal Block Diagram block Package Diagram package, model, model library, profile, view Parametric Diagram block, constraint block Requirement Diagram package, model, model library, requirement Sequence Diagram interaction State Machine Diagram state machine Use Case Diagram package, model, model library

Model element type needs to be included only when several allowable model elements

SYS 5390

Lecture #3, Slide 29

Diagram Header (3/4)

Diagram name: user defined, to provide a concise description of the diagrams purpose
A model can contain considerable amounts of information The modeler can choose to only represent
selected model elements in a particular diagram for a given purpose

and hide other model elements from the diagram that may detract from this purpose

Diagram Usage: describes specialized use for the diagram type

Included in the header in guillemets Ex: the modeler can specify a context diagram as a usage of a use case diagram

SYS 5390

Lecture #3, Slide 30

Diagram Header (4/4) (summary)

Diagram kind Activity diagram - act Block Definition Diagram bdd Internal Block Diagram ibd Package Diagram pkg Parametric Diagram par Requirement Diagram req Sequence Diagram sd State Machine Diagram stm Use Case Diagram uc Model element type Activity diagram activity Block Definition Diagram block, constraint block, package, model, model library Internal Block Diagram block Package Diagram package, model, model library, profile, view Parametric Diagram block, constraint block Requirement Diagram package, model, model library, requirement Sequence Diagram interaction State Machine Diagram state machine Use Case Diagram package, model, model library Model element name name of the represented model element Diagram name user defined, to provide a concise description of the diagrams purpose Diagram usage describes specialized use for the diagram type

SYS 5390

Lecture #3, Slide 31

Diagram content (1/3)

Diagram content (canvas): contains elements that graphically represent model elements 2 types of graphical elements
Node: symbol that contains text and/or other symbols to represent the internal detail of the represented elements Paths: these edges are lines with multiple additional adornments such as arrows and text strings

Possibility to hide information when not relevant Properties and keywords

A keyword identifies the type of model element (metaclass) to avoid any ambiguity.
included in guilletmets before the name of the model element

Symbols display commonly used information about their model elements in their name string (name, type) Properties: shown as a comma-separated list, enclosed in braces, following the name of the model element

SYS 5390

Lecture #3, Slide 32

Diagram content (2/3)

Node symbols
Generally rectangular, or round-angles, ellipses All nodes have
one name compartment (display the name string), with any applicable keyword(s) and properties Eventually additional compartments used to display details of nested elements

Path symbols
Line with different styles and ends depending on the modeling concept they represent
Optional text adornment that contains name string, keywords or additional properties Eventually textual information on the ends where the represented model element requires it

SYS 5390

Lecture #3, Slide 33

Diagram content (3/3)

Icon symbols
Typically used to represent low-level concepts that do not have further internal details Properties displayed in a text string floating near the object

Note symbols
Can be attached to any model element or any set of model elements. Annotates the model with additional textual information (ex: hyperlink to a reference document), called comment Also used to display cross-cutting information, such as traceability to requirements and allocations Displayed as a rectangular box with a cutoff upright corner

SYS 5390

Lecture #3, Slide 34

Additional Notations
Table: Efficient and expressive way to represent information
Requirements, interfaces information

Matrices: to describe relationships Tree: hierarchical relationships presented using browser panels

SYS 5390

Lecture #3, Slide 35

SYS 5390

Lecture #3, Slide 36

Case study: The Surveillance System

ACME Surveillance Inc., produces and sells surveillance systems. Their range of surveillance systems products is intended to provide security either for homes or small commercial sites Their systems use sophisticated pan and tilt cameras to produce video images of the surrounding area, and for a fee can be connected to a central monitoring service. ACME also produces the cameras and sells them as separate products for do-ityourself enthusiasts.
Setup for a small commercial site: The system has 4 wall-mounted cameras (3 wired, 1 wireless) 1 of the offices is used to house the monitoring station This station consists of one workstation and an additional screen The office has a PBX that the monitoring station uses to communicate to its designated command center
Lecture #3, Slide 37

SYS 5390

Package Notions
Each model element has parents or contains Childs = hierarchy
Packages = one example of container Blocks, use cases, activities Member of a namespace: enables unique identification A package is a namespace for the packageable element it contains

The model elements contained in a package = packageable elements

A model is a special type of package that contains a set of model elements that describes a domain of interest Effective model organization required to
Facilitate reuse of model elements (model library) Enable easy access and navigability among model elements Support configuration management of the model Exchange information with other tools

Specific partitioning is methodology dependant Views and viewpoints used to visualize models according to multiple organizing principles
View: package used to show a particular perspective on the model (ex: performance or security) Viewpoint: represents a particular stakeholder perspective that specifies the contents of a view Many relationships b/n packages : Import relationship
Lecture #3, Slide 38

SYS 5390

SYS 5390

Lecture #3, Slide 39

The Package Diagram

The model elements contained within a package can be shown on a package diagram

Package type: type of package represented in the diagram (model, package, model library, view) Package name: identifies the particular package that the frames represents Diagram name: used to summarize the diagram purpose

SYS 5390

Lecture #3, Slide 40

Defining packages using a Package Diagram

Models organization = hierarchical tree (similar to Win Explorer) Packages used to partition elements into coherent units with properties: Access control Model navigation Configuration management Most used packages: Package: container for other elements (copy/delete properties) Packageable elements: include blocks, activities, value types, and packages Model: top-level package in a nested package hierarchy Primary hierarchy based on the project needs Model Library: package that is designated to contain reusable elements View: provides additional perspectives on the model using alternative organizing principles (cf next slides)

SYS 5390

Lecture #3, Slide 41

Defining packages using a Package Diagram

Packages possibly linked with different relationship types Packages represented by Folder symbols The figure depicts the top-level packages within the corporate model of ACME It contains: Standard off-the-shelf components Standard engineering definitions (ex: SI units) The company's products Specific extensions to support more domain-specific notations and concepts The elements can then be represented on SysML diagrams (structure, behavior, requirements)
Lecture #3, Slide 42

SYS 5390

Organizing a Package Hierarchy

Model organization crucial. It impacts Reuse Access control Navigation Configuration management Data exchange of the development process Model hierarchy should be based on a set of organizing principles By system hierarchy (system, sub-system, component levels) By process life cycle (requirement analysis, system design) By teams working on the project By the type of model elements (requirements, behavior, structure) By model elements that are likely to change together By model libraries By any other logical defined grouping
Lecture #3, Slide 43

SYS 5390

Containment relationship

Containment relationship: relates parents to children within a package hierarchy. Several levels of the hierarchy can be shown 2 symbol options Product level here organized to show 2 product lines and requirements Cameras package hierarchy organized by artifact type Behavior, Structure, and Parametrics Surveillance System package hierarchy is organized based on architectural principles: Logical architecture Physical architecture Use Case package
Lecture #3, Slide 44

SYS 5390

Packageable elements on a package diagram

Packageable elements: represented by node symbols or icons Word block to indicates element type

SYS 5390

Lecture #3, Slide 45

Packages as Namespaces

Package Contains packageable elements Is a namespace for all named elements within it Uniqueness rule: Each element of a particular element type within one package must have a unique name BUT difficult to implement Possibility to add the type keyword in the symbol (block) Multi-hierarchy display induced confusion cleared by the use of qualified names
Lecture #3, Slide 46

SYS 5390

Importing elements into Packages (1/2)

Package import / element import Used to clear potential ambiguity of previous diagram Used to bring an element or collection of elements from one namespace to another namespace Elements modifiable only in the source namespace Name clash rules apply Named elements recognized within a namespace are called members Public or Private visibility Public allows import Private only allows access

SYS 5390

Lecture #3, Slide 47

Importing elements into Packages (2/2)

Import shown by a dashed arrow, labeled import or access, pointing to the source (package or element) Diagram description Resulting packages and consequent naming

SYS 5390

Lecture #3, Slide 48

Dependencies between packageable elements

Dependancy relationships: used when the content of one package is dependant on the content of another package 5 more common types of dependencies Use: the client uses the supplier as part of its definition Refine: the client represents an increase in detail compared to the specification of the supplier (usually in requirement analysis) Realization: the client realizes the specification expressed in the description of the supplier Trace: there is a linkage b/n the client and supplier without imposing more significant semantic constraints Allocate: one model element is allocated to another

SYS 5390

Lecture #3, Slide 49

Views and Viewpoints

Viewpoint: describes perspective of interest of a set of stakeholders that is used to specify a view of a model. It includes the set of properties that identify The purpose or reason for taking this perspective The stakeholders who have an interest in this perspective The concerns that the stakeholders wish to address The languages used to present the view The methods used to establish the view

View: Type of package that conforms to a viewpoint Imports set of model elements according to the viewpoint method Conform relationship

SYS 5390

Lecture #3, Slide 50