Lecture #3c

7/29/2019 Lecture #3c

1/50

SYS 5390 Lecture #3, Slide 1

Model BasedCollaborative Systems Engineering

Stphane Bucaille, PhDElectrical and Computer Engineering Department

7/29/2019 Lecture #3c

2/50


MBSEProcess

remainder

SysMLlanguagearchitecture

Modelingstructurewithpackage

7/29/2019 Lecture #3c

3/50


7/29/2019 Lecture #3c

4/50


MBSE Overview

Context

MBSE: A myth or reality?

MBSE Benefits MBSE Implementation Challenges

MBSE process example

Conclusions

7/29/2019 Lecture #3c

5/50


Context Systems increasing complexity Program over-costs and delays continuously

increase as well Aeronautics:

Dreamliner: $9B, 3 years A380: $10B, 15 months

Energy: EPR: $4B, 5 years

Communications: Next Gen Data Comm: $4.2B, from 2 months to 14

years!

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

Software Functions and capabilities Implementation techniques Cyber-security challenges

Organizations Stakeholders Skills Processes and Tools Knowledge management and reusability

Slide courtesy of MBSE4All, LLC

7/29/2019 Lecture #3c

6/50


Context

Growing need for systems affordability and resilience

This requires faster delivery of adaptable, trusted,

assured, reliable and interoperable systems


7/29/2019 Lecture #3c

7/50SYS 5390 Lecture #3, Slide 7

MBSE: A myth or reality

Model-based systems engineering (MBSE) is the formalized

application of modelingto support system requirements, design,analysis, verification and validation activities beginning in theconceptual design phase and continuing throughout developmentand later life cycle phases.

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


7/29/2019 Lecture #3c



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?


7/29/2019 Lecture #3c



So whyMBSE? 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, L3Communications

Energy (GE, AREVA, Alstom), Automotive (Ford)

Why is it becoming a standard for the complexsystems industry?

According to OMG, 28% of DoD contracts granted in2011were using MBSE approach

Strong synergies with DoDAF methodology


7/29/2019 Lecture #3c


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% andreduce 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, butproper 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)


7/29/2019 Lecture #3c


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 model-

based techniques enable and facilitate complexity

management


7/29/2019 Lecture #3c


Benefits

Enhanced Collaboration By the use of a

common languageand collaborativeplatform

Consistent,single sourceof information for the whole team

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

Increased productivity Improved impact analysis of requirements changes

Reuse of existing models to support design/technologyevolution

Auto-generation of up-to-date documentation

Reduced risk Improved cost estimates Early/on-going requirements validation & design

verification

Life Cycle Support

VerticalIntegration

Today: Standalone modelsrelated through documents

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


7/29/2019 Lecture #3c


MBSE Implementationchallenges

INCOSE MBSE Development Roadmap

Z

2010 2020 2025

Maturity

MBSE Capability

Ad Hoc MBSEDocument Centric

2010

WellDefinedMBSE

InstitutionalizedMBSE across

Academia/Industry

Reduced cycle times Design optimization across broad trade space

Cross domain effects based analysis

System of systems

interoperability

Extending Maturity and Capability

Distributed & secure model repositoriescrossing multiple domains

Defined MBSE theory, ontology, and formalisms

Emerging MBSE standards

Matured MBSE methods and metrics,Integrated System/HW/SW models

Architecture model integratedwith Simulation, Analysis, and Visualization

Planning & SupportResearchStandards DevelopmentProcesses, Practices, & Methods

Tools & TechnologyEnhancementsOutreach, Training & Education

Refer to activities inthe following areas:


7/29/2019 Lecture #3c



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


7/29/2019 Lecture #3c



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)


7/29/2019 Lecture #3c


MBSE ExampleGlobal Process


7/29/2019 Lecture #3c


PoleSat DiagramExamples

Scenario

Altitude( km) Orbi t

Inclination(deg)

Orbit

Period(s)

deltaL

(deg)

Time

in View(s)

Image

Width(km)

Field

of View(deg)

Number of

Pixelsin one

dimension

Number

of Pixelsin Image

Number of

PolePassages

Per Cycle

Number of

ImagesPer Cycle

Downlink

Data Volume(Bytes)

Downlink Data

Rate(bits/s)

1 600 97.87 5799 24 642 1133 87 801 642262 7 42 27096627 337651

2 700 98.28 5923 25 715 1157 79 818 669747 7 40 27088855 303038

3 800 98.70 6049 25 786 1181 73 835 697980 7 39 27083057 275777

4 900 99.13 6175 26 854 1206 68 853 726969 7 37 27079116 253610

5 1000 99.58 6303 26 921 1230 63 870 756720 7 36 27076925 235143

6 1100 100.04 6431 27 987 1255 59 887 787243 7 34 27076387 219464

7 1200 100.53 6560 27 1052 1279 56 905 818544 7 33 27077406 205945

Parametric

Diagram

Results inMS Excel

z


7/29/2019 Lecture #3c


7/29/2019 Lecture #3c


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)

7/29/2019 Lecture #3c

20/50


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

7/29/2019 Lecture #3c

21/50


The SysML Language

Architecture

For the domain being modeled System Function

Domainconcepts

To language concepts Blocks Activities

Mapping ofDomainconcepts

Of the language concepts as they apply to aparticular system Block called airplane

Called user model

Instantiationand

representation

7/29/2019 Lecture #3c

22/50


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

7/29/2019 Lecture #3c

23/50


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

7/29/2019 Lecture #3c

24/50


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 modifiedconcepts. (used for the extension of UML in SysML)

Figure shows two SysML concepts in the Blockslanguage unit of the SysML profile

And how they relate to UML metaclasses

Blockextends Class. It is the fundamentalstructural concept in SysML

Value Type extends Data Type. It addsquantitative features (unit, dimension)

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

Described via mapping between the Domain concepts and the language concepts

The domain concepts defined either in natural language or mathematical form.

7/29/2019 Lecture #3c

25/50


The System Model

(User Model) (1/2)

Consists ofmodel 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 metaclassproperties, 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

7/29/2019 Lecture #3c

26/50


SysML Diagrams

In addition to a metamodel, SysML defines a notation (concrete

syntax)

SysMLDiagram

BehaviorDiagrams

ActivityDiagram

SequenceDiagram

StateMachineDiagram

Use CaseDiagram

RequirementDiagram

StructureDiagrams

BlockDefinitionDiagram

Internal BlockDiagram

ParametricDiagram

PackageDiagram

Same as UML Modified from UML Not in UML

7/29/2019 Lecture #3c

27/50


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, containingstandard 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.

7/29/2019 Lecture #3c

28/50


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 Activity diagram - act

Block Definition Diagrambdd

Internal Block Diagramibd

Package Diagrampkg Parametric Diagrampar

Requirement Diagramreq

Sequence Diagramsd

State Machine Diagramstm

Use Case Diagramuc

7/29/2019 Lecture #3c

29/50



Model Element type: represented by the diagram kind. Validpermutations 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 severalallowable model elements

7/29/2019 Lecture #3c

30/50



Diagram name: user defined, to provide a concise description of thediagrams 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 purposeand hide other model elements from the diagram that may detract fromthis 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

Di H d

7/29/2019 Lecture #3c

31/50


Diagram Header

(4/4) (summary)

Diagram kind

Activity diagram - actBlock DefinitionDiagrambdd

Internal BlockDiagramibd

Package Diagrampkg

Parametric Diagrampar

Requirement DiagramreqSequence Diagramsd

State MachineDiagramstm

Use Case Diagramuc

Model element type

Activity diagram -activity

Block DefinitionDiagram block,constraint block,package, model,model library

Internal BlockDiagram block

Package Diagrampackage, model,model library, profile,view

Parametric Diagramblock, constraint block

Requirement Diagram package, model,model library,requirement

Sequence Diagraminteraction

State MachineDiagram statemachine

Use Case Diagrampackage, model,model library

Model element name

name of therepresented modelelement

Diagram name

user defined, toprovide a concisedescription of thediagrams purpose

Diagram usage

describes specializeduse for the diagramtype

7/29/2019 Lecture #3c

32/50


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 detailof the represented elements

Paths: these edges are lines with multiple additional adornments such as arrows andtext 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 theirname string (name, type)

Properties: shown as a comma-separated list, enclosed in braces, following the nameof the model element

7/29/2019 Lecture #3c

33/50



Node symbols Generally rectangular, or round-angles, ellipses

All nodes have

one name compartment (display the name string), with anyapplicable keyword(s) and properties

Eventually additional compartments used to display details ofnested 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

7/29/2019 Lecture #3c

34/50



Icon symbols Typically used to represent low-level concepts that do not

have further internal details

Properties displayed in a text string floating near theobject

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 torequirements and allocations

Displayed as a rectangular box with a cutoff upright corner

7/29/2019 Lecture #3c

35/50


Additional Notations

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

Matrices: to describe relationships

Tree: hierarchical relationships presented using browser panels

7/29/2019 Lecture #3c

36/50


C t d

7/29/2019 Lecture #3c

37/50


Case study:

The Surveillance System

ACME Surveillance Inc., produces and

sells surveillance systems. Their range of surveillance systems

products is intended to provide securityeither for homes or small commercial sites

Their systems use sophisticated pan andtilt cameras to produce video images of the

surrounding area, and for a fee can beconnected to a central monitoring service.

ACME also produces the cameras andsells them as separate products for do-it-yourself 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 itsdesignated command center

7/29/2019 Lecture #3c

38/50


Package Notions

Each model element has parents or contains Childs = hierarchy Packages = one example of container

The model elements contained in a package = packageable elements Blocks, use cases, activities

Member of a namespace: enables unique identification

A package is a namespace for the packageable element it contains

A model is a special type of package that contains a set of model elements thatdescribes 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 organizingprinciples

View: package used to show a particular perspective on the model (ex: performance orsecurity)

Viewpoint: represents a particular stakeholder perspective that specifies the contents of aview

Many relationships b/n packages : Import relationship

7/29/2019 Lecture #3c

39/50


7/29/2019 Lecture #3c

40/50


The Package Diagram

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

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

Defining packages using a

7/29/2019 Lecture #3c

41/50



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, andpackages

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 alternativeorganizing principles (cf next slides)


7/29/2019 Lecture #3c

42/50



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)

Organizing a Package

7/29/2019 Lecture #3c

43/50


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 organizingprinciples

By system hierarchy (system, sub-system, componentlevels)

By process life cycle (requirement analysis, systemdesign)

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

7/29/2019 Lecture #3c

44/50


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 architecturalprinciples:

Logical architecture

Physical architecture

Use Case package

Packageable elements

7/29/2019 Lecture #3c

45/50


Packageable elements

on a package diagram

Packageable elements: represented by node symbols or icons

Word block to indicates element type

7/29/2019 Lecture #3c

46/50


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 packagemust 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 ofqualified names

Importing elements into

7/29/2019 Lecture #3c

47/50



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 toanother 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


7/29/2019 Lecture #3c

48/50



Packages (2/2)

Import shown by a dashed arrow, labeled import or access, pointing to the source (packageor element)

Diagram description

Resulting packages and consequent naming

Dependencies between

7/29/2019 Lecture #3c

49/50


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 thesupplier (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

7/29/2019 Lecture #3c

50/50

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 thatconforms to a viewpoint

Imports set of model elementsaccording to the viewpointmethod

Conform relationship

Lecture #3c

Documents

Transcript of Lecture #3c