application of mbse theory in a world of practical deadlines and deliverables: lessons learned

Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.

Application of MBSE Theory in a World of Practical Deadlines

and Deliverables: Lessons Learned

March 29th , 2014

Tamara Valinoto

Systems Architect/Model Driven Engineering (MDE) Community of Practice(CoP) Chair

[email protected]

MBSE Symposium: INCOSE Chesapeake Chapter and JHU/APL

mailto:[email protected]

Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.

What is Model Based Engineering? MBE = MBSE + MDD + MBI&T

2

MBSE MBI&T

MBSW/MBHW(MDD)

Common MDE Framework

Views

MBE includes Model-Based Systems Engineering, Model Driven Development, and Model Based Integration and Test

Descriptive

Model Based SE

PerfVerification

Model Based I&T

Analytical

Model Driven Development

Framework Collaboration Support

MDECOP

Artifacts / Products

Tools & Processes

MDE COP

2


Delivered System Does Not Reflect the System Design

Breakdown in the Development ProcessLeveraging Models / Design Between Engineering Disciplines

• Process Chain Breaks Down Between Disciplines– No Standard Translations Between Model Languages– Models and Requirements are not Consistent or Traceable– No Process or Translation for Feedback into the System Architecture

• Systems / Software Architectures Might Not Have Valid Implementations

3

SystemArchitecture

Model(s)

SoftwareArchitecture

Model(s)

SoftwareImplementation

Model(s)

Similar Corollary For Hardware Design


How MBE/MBE Should Work Across DisciplinesUsing Models to Effectively Communicate and Implement System

• Consistent Models Shared Between Disciplines– Standard Transformations Between Models, Both To and From– Feedback so System Designs Have Valid Implementations

• Constructs in Systems Models Map to Valid Implementations• Implementations Set Standard Rules to Guide Systems Architecture

– Enable Communications Between Disciplines and Customer

• ‘As Designed’ and ‘As Built’ are one in the same

4

SystemArchitecture

Model(s)

SoftwareArchitecture

Model(s)

SoftwareImplementation

Model(s)


An Integrated System Model is a Multi-Faceted Approach to Provide Solutions

• Model is a central repository for all knowledge about the system

– Aiding communication and collaboration

• Automatically self-consistent system architecture and design

– Improving maintainability and reducing ambiguity of design

• Automate traceability of requirements to architecture elements

– Aiding analysis of change Impact(s)

• Automate ability to generate formal documentation from model

– Ensuring documents reflect what was designed

• Automatic Code Synchronizer (ACS) to generate code from UML designs

– Design, Develop, and Implement high quality code in less time

5


Lesson(s) Learned: Obtain Chief Systems Engineer Backing in Effort

6

Lesson(s): • Relationship:

• Build a bond and present together on current state of architecture(i.e. pretty picture and modeling data)

• Determine the responsibilities of the person who owns the content and its accuracy

• Get Early Buy in from Program Management, Engineering Manager

Question(s): • Architecture Team: How do we get the Chief Systems Engineer to

be an advocate for the team’s MBE effort?


Lesson(s) Learned: Everyone Makes Pretty Pictures BUT Enforce Data Comes from Model

7

Question(s): • Architecture Team: How do I ensure the whole program

team uses the model as “ground truth” when making their presentation material?

• Customer: What is “ground truth” of architecture?

Lesson(s): • Presentation Packages:

• Determine Process for “how” people request data from model or have them as read only users to grab periodic data from model to build presentations

• Ensure your team is on the presentation review board • Present process to customer


Lesson(s) Learned: Showcase “how” to Navigate Model Database

8

Question(s): • Architecture Team: How do I navigate the model element

relationships behind the views/viewpoints? • Customer: How do I find the latest set of views/viewpoints that

were reviewed in the last meeting?

Lesson(s): • Model:

• Create HTML exports of views and/or Create Text Diagrams containing hyperlinks to views within model

• Training: • Bring in Tool Vendor to showcase the various browser panes if

they exist


Lesson(s) Learned: Map Views/Viewpoints to System Decomposition

9

Question(s): • Architecture Team: What is the scope for each architecture level (i.e. boundaries

of my system, segment, element)? How to divide the work among the distributed team? What are the modeling languages applied at each level and are they required (i.e. UPDM for SoS, System; SysML for Segment/Element; UML for Subsystem)? How far will we model the system?

• Customer: What views/viewpoints will be delivered at each milestone?

Lesson(s): • Training:

• Modeling languages

• Schedule:

• Products Aligned to Milestones ( i.e. CDRLs)

• Milestone Reviews:

• Present Product Traceability from Requirements


What are the Architecture Products to Develop at Each Architecture level for each Milestone?

10

System of Systems

Segments

Elements

Unified Profile for MODAF and DoDAF (UPDM)Systems Modeling Language (SysML)

System

Air Ground

External Nodes

Payload 1

Payload 2

OV-2

OV-5

OV-1d

SV-1 (L1) SV-

4a (L1)

SV-6

SV-5SV-4a (L0)

SV-11

SV-1 (L0)

Comms

SRR

PDR

CDR

SV-2 (L1)

IBD

BDD

Behavior Diagrams

Data Model

Emphasis to Produce and Control Products that Specify the Design

SV-10c


How Do I Develop Relationships between Capabilities and Segment Functional Architecture?

11

Mission Use Case

Customer Spec

Operational Operational Activity ArtisanStudio ®

System Spec DOORS

Segment Spec

Segment Functions

Segment Behavior Diagrams

Segment Use CaseExcel

ArtisanStudio

®ArtisanStu

dio ® Artis

anSt

udio

®System Behavior Diagrams

ArtisanStudio ®

ArtisanStudi

o ®

Manual

Manual

System

Segment

System Functions

Capability

Artis

anS

tud

io ®

ArtisanStudio ®

Enables Validation of Top Level Capabilities and Ability to Analyze Future Capabilities


System Level Architecture – UPDM Profile

SV-1

How Do I Develop Relationships at System Level Architecture?

12

External Nodes

System

External NodesExternal NodesExternal Nodes

«SystemConnector»

«DataExchange»

SV-2External Nodes

Segment Node

External NodesExternal NodesExternal Nodes«CommunicationsLink»

Segment Node

«DataElement»

SV-11

Exchanges (1)Uses (1..n)

«DataElement»

«DataElement»

«DataElement»

SV-10c

External Node

External Node

Segment

«DataExchange»

«Operation»

SV-4a External

Node

Segment

«ObjectFlow»

Function

Instance of (1)

Function

Purpose to Validate Implementation Path and Functional Need for Data Element

System


System Level UPDM Profile SV-1

How Do I Develop Relationships Across Levels of Architecture?

13

External Nodes

System

External NodesExternal NodesExternal Nodes

«SystemConnector»

«DataExchange»• Periodicity• Transfer Protocol

SV-2External Nodes

Segment Node

External NodesExternal NodesExternal Nodes«CommunicationsLink»• Throughput

Segment Node

SV-11 Exchanges (1)

Uses (1..n)

«DataElement»

• Data Standard• Size• Classification

Segment Level SysML Profile Segment

Element Element

Element

«ItemFlow»

IBD«ItemFlow»

Refines (1..n)

«DataType»

Exchanges (1)

Sour

ce

Desti

natio

n

Data

Exc

hang

e

Data

Ele

men

t

Item

Flow

(s)

Data

Sta

ndar

d

Size

Tran

sfer

Pro

toco

l

Clas

sifica

tion

From

Nod

e

To N

ode

Com

ms P

ath

Port

Typ

e

Thro

ughp

ut

Clas

sifica

tion

SysA SysB DE1 Dx IF1 NITF 1kb FTP U N1 N2 CP1 PT2 1kbps USysA SysB DE1 Dx IF1 NITF 1kb FTP U N1 N2 CP1 PT2 1kbps U

COMMSDATASYSTEMS

SV-6

Exchanges (1)

Purpose to Validate all External Data Elements are Implemented in Segment Design


Lesson(s) Learned: Keep Open Mind about Tools/Techniques/Processes

14

Question(s): • Architecture Team: What can the tool support and not support in

terms of report generation, traceability, model relationships, etc? Can we accomplish our goal without support from tool vendor? Does our techniques align with NGES processes?

• Customer: What can the tool provide me in sense of traceability to requirements and the system behavior?

Lesson(s): • Tool Vendor Support:

• Determine up front whether to use them or to have an experienced programmer to retrieve model data

• Management Perception:• Tailoring is required of the Processes and not all tools are

created equal


Why Export MBE Data?

• View different perspectives without creating diagrams for use in each type of ‘view’ into the model

– Decrease number of diagrams to maintain and configuration manage

• Viewing the information in the model is limited to the application GUI that many find cumbersome or confusing

– Model reviewers don’t need tool training

• Relationships stored in the database can be ‘hidden’ from certain views or diagrams

15

Exporting modeled information into a familiar format aids in communication, model validation, and

facilitates deliverables


View Data Across All Levels of the Architecture

• Traditional approaches maintain numerous hierarchy diagrams

16

Func 1

Func 1.1

Func 1.2

Func 1.1

Func 1.1.1

Func 1.1.2

Operational Activity System Function Segment Function Element FunctionFunc 1.1.1Func 1.1.2

Func 1.2 Func 1.2.1Func 2 Func 2.1 Func 2.1.1

Func 3.1.1Func 3.1.2

Operational Activity 1Func 1

Func 1.1

Operational Activity 2 Func 3 Func 3.1

• Hierarchy diagrams can be replaced by a single hierarchy report


Additional Relationship Reports

• Custom Internal Block Diagram(IBD) report

• Bi-directional Requirement to Function trace report

• Bi-directional «InformationElement» to «DataElement» trace report

• Communications protocol sub-address utilization report

• Diagram notes report

• Sequence & Activity Diagram reports

• «OperationalNode» & «Block» activity reports

17

«Con

nect

or»

Sour

ce «

Bloc

k»

Desti

natio

n «B

lock

»

Dire

ction

«Ite

mFl

ow»

«Dat

aTyp

e»

Item

Flo

w O

SD(s

)

From

Por

t

To P

ort

Port

Typ

e

Port

Typ

e us

ed o

n Fl

ow S

pec B

DD(s

)

C1 Block 1 Block 3 Inbound IF1 DT1 OSD1 PN1 PN3 PT1 BDD1C2 Block 2 Block 4 Internal IF2 DT2 OSD2 PN2 PN4 PT2 BDD2

BLOCKS DATA PORT INFO


«OperationalActivity»

«OperationalPartition»«OperationalNodeRole» ::

«OperationalNode»

Automated Model Review

• Diagrams show custom views into the underlying model– What is in the model that isn’t represented on the diagram?– Did the activities really get deleted from the model?

• Automated analysis can check the entire model– Are all my ports typed by the correct model object type?– Are there unused item flows defined that the system does not need?– What relationship(s) is the modeling tool creating or deleting automatically?

18

«OperationalActivityAction»

«OperationalActivity»

«OperationalNode»

«performs»


ArtisanStudio ® Generated Reports Support Validation of Integrated Architecture

19

Validation Model Elements Purpose

System Requirement to System Function Mapping

System Function Depict Function Traceability throughout modelIdentify functions mapping to requirementCreate Verfification binning metricsDetermine meeting operational needs of usersView mapping from Operational into System Functional Architecture

Mission Use CaseOPSCON Activity

Segment FunctionRequirement

System Data Exchange Matrix

System Interfaces Identify Interfaces with/without Data ExchangesIdentify Data Exchanges with/without Comms PathsIdentify Data Exchanges with/without behavior diagrams

Data ExchangesData Elements

Comms Paths

System Sequence Diagram ReportSequence Diagrams

Identify Functions with/without behavior diagramsCalculate % of functions with behavior diagrams

Sequence Diagram Messages

Segment Internal Block Diagram Data Exchange Matrix

Internal Interfaces Identify interfaces with/without Item FlowsIdentifyItem Flows with/without Behavior DiagramsIdentify inconsistencies in flow spec modelsItem Flows

Segment Activity Diagram Report

Activity Diagram List all Connection Types for any elementList Activities grouped by owning elementSwimlane

ActivityConnection Type

System to Operational Data Mapping

Data ElementView mapping from System to Operational Data Architecture

Information ElementProviding these Products Established Evidence to

Customer that the System will Accomplish It’s Intended Requirements


Lesson(s) Learned: Compile Functional/Data Architecture Completion Measures

20

Question(s): • Architecture Team: How do we know when the architecture is done

tweaking and we can start building? How do we know when we have satisfied the requirements with the architecture?

• Customer: What state is the architecture? What are those measures? What measures provide insight into architecture status and progress?

Lesson(s): • Model:

• Assign Attributes to monitor relationships (i.e. traceability of requirements to functions)

• Determine visual representation of measures to depict gaps that need to be worked

• Customer/Program Meetings:

• Present burn down charts of both aspects of the functional and data architecture paths


Status Reporting and Metrics

• Automatically generate custom-designed metrics

21

0%30%60%90%

194 116 79 10123 10 8 1516 10

Percentage of Objects Mapped

Mapped UnmappedIntentionally Omitted

System Segment Element0%

10%20%30%40%50%60%70%80%90%

100%

38

13

6

21

12

10

40

15

Current Diagram Status

Final ECR Rework DraftPreliminary In Work


Lesson(s) Learned: Collaborate with Stakeholders on Model Data Needs/Wants

22

Question(s): • Architecture Team: When do I transition the model to

System Test? How do I support SW Integration? What are the benefits of MBE? What does my customer need/want to be able to sell off on architecture? What are our requirements for modeling the system (i.e. real time system with executable sequence diagrams/rate monotonic analysis)?

Lesson(s): • Face to Face Meetings:

• Determine Stakeholders’ needs vs. wants and lay our against schedule and cost

• Agree on set of products for stakeholders

• Create team chart for each product lifecycle phase to maintain and build higher fidelity model


Keystone Data Case (KDC)

• End-to-end scenario of normal system operations

• Owned by System Integration & Test

• Provides consistent scenario with associated data products across entire system to be used in system integration

• Documented in ArtisanStudio ® as a series of Sequence Diagrams– Custom ArtisanStudio ® export contains:

• All included sequence diagram steps• All included diagrams• All utilized data flows (and those not utilized)• All implemented functions (and those not implemented)• All utilized interfaces (and those not utilized)

– Helps define KDC to maximize system utilization

23


Keystone Data Case (KDC)

• MS Excel Report containing:

24

Ext Seg A Seg B

Sequence Diagram 1

ref

Sequence Diagram 2

ref

Sequence Diagram n

ref

Inte

rfac

e

Sour

ce

Desti

natio

n

Data

Exc

hang

e

Data

Ele

men

t

Data

Sta

ndar

d

Tran

sfer

Pro

toco

l

Clas

sifica

tion

Cate

gory

Usa

ge

SC1 SysA SysB DE1 D1 KMZ FTP U KDC YesSC2 SysA SysB DE1 D1 KMZ FTP U Other NoSC2 SysB SysC DE2 D2 XLS HTTPS U KDC Yes

DATASYSTEMS KDC

KDC Sequence Diagram

All «DataExchange»

Nam

e

Impo

rtan

ce

Type

Test

Eve

nt A

Test

Eve

nt B

Cate

gory

Usa

ge

Func 1 E Leaf Yes Yes KDC YesFunc 2 I Leaf No Partial Other NoFunc 3 S Leaf Partial Yes KDC Yes

FUNCTION KDCAll «SystemFunction»

Inte

rfac

e

Sour

ce

Desti

natio

n

Cate

gory

Usa

ge

SC1 SysA SysB KDC YesSC2 SysA SysB Other NoSC2 SysB SysC KDC Yes

SYSTEMS KDCAll «SystemConnector»

Step 2

«OSD» Keystone Data Case«OSD» Sequence Diagram 1

«OSD» Sequence Diagram 2Step 1…

par

also par

end par

Step 1

Step 1.1

Step 1.2

All Object Sequence Diagram (OSD) steps


End-to-End Test Scenarios

• Mimic KDC approach within ArtisanStudio ® to allow definition of and export of system behavior scenarios

• System I&T can leverage system design in test case design– System I&T stays in sync with system design– Currently only used as a reference for test case design

• Proposed Option (not adopted to date):– Apply attributes to individual sequence diagram steps

• Free text attribute describing step (required user action or description of automated activity)

• Link to Test Resources (managed as model objects)– Custom script exports all information to a Test Case template document (MS Word)– Custom script to aid in population of Test Case steps and Test Resource linking

25


Benefits to Stakeholders

• Assists decision makers in identifying gaps

• Ensures complete and consistent architecture from user need to the system design

• Builds refinement detail for test cases

• Assists with requirements definition for new systems that are needed to achieve similar capabilities

• Ability for re-use on future similar architecture programs

26

Validating that you are “building the right system”…… [Boehm]


Acknowledgements

27

• Additional Authors– Jeff Herbert, Systems Engineer, Northrop Grumman Electronic

Systems


Questions and Answers

28

application of mbse theory in a world of practical deadlines and deliverables: lessons learned

Documents

affiliated societies

integrated system model

model based integration

model languagesmodels

based engineering

jhuapl copyright

hardware design copyright

incose chesapeake chapter