Integrating UPDM with SysML and UML on a

DoD Acquisition Program

March 23, 2015

Paul Vaughan

NGIS Tech Fellow

Chief Engineer/Architect

OMG UAF & MBSE Information Day

DoD and ISR Acquisition Programs

•  DoD and ISR programs typically require extensive and detailed traceability –  Requirements flowdown and derivation down to software item/hardware item (SI/HI) –  Functional flow block diagrams (activity diagrams/sequence diagrams/internal block diagrams) down to unit level –  Requirements allocated to architectural elements (physical baseline) and system functions (functional baseline), including

performance requirements –  Contractor’s functional baseline, verification environments, and operations concepts are traceable to and consistent with

the Government’s CONOPS –  Test & evaluation planning is traceable to critical design, correlating test objectives, test environments, and test resources

to allocated requirements

•  Most programs require diagrams compliant with the DoD Architecture Framework (DoDAF) –  Generally the Government doesn’t specify to what level this applies: usually interpreted as at the top level of the contract

scope (system or segment level)

•  The Systems Engineering team is responsible for the development of requirements, definition of the functions, and creation of the architectural design that provide the content for these diagrams

•  The Software/Hardware teams are responsible for detailed designs consistent with higher level designs and that are fully traceable to Government requirements and CONOPS

•  An objective of Model-Based methods is to do all that (and more) in a single integrated model

2

Stakeholder Requirements Definition

• Identify users and stakeholders • Define needs • Capture source requirements • Initialize requirements database • Establish the CONOPS • Generate System Requirements Document

Requirements Analysis • Define systems capabilities and performance objectives • Define, derive, and refine functional/performance requirements • Define other non-functional requirements • Develop specification trees and specifications • Allocate requirements and establish traceability • Generate a system specification

Architectural Design • Define selection criteria • Define/refine system element alternatives • Synthesize multiple system architectures • Analyze and select preferred system architecture/element solution • Model, simulate, and prototype system architectures • Define, refine and integrate system physical configuration • Implement requirements and design feedback loops

Sys

Req 1

Req 2

Req 11

Req 12

Req 21

Req 22

I/F I/F

I/F I/F

I/F

Sys

Act a 1

Act a 2

Act a 11

Act a 12

Act a 31

Act a 32

I/F I/F

I/F I/F

I/F Act a 3

I/F

Operational Context is provided by System Spec and CONOPS from Government

Operational Context in Model (User requirements and OV-5b)

3

Stakeholder Requirements Definition

• Identify users and stakeholders • Define needs • Capture source requirements • Initialize requirements database • Establish the CONOPS • Generate System Requirements Document

Requirements Analysis • Define systems capabilities and performance objectives • Define, derive, and refine functional/performance requirements • Define other non-functional requirements • Develop specification trees and specifications • Allocate requirements and establish traceability • Generate a system specification

Architectural Design • Define selection criteria • Define/refine system element alternatives • Synthesize multiple system architectures • Analyze and select preferred system architecture/element solution • Model, simulate, and prototype system architectures • Define, refine and integrate system physical configuration • Implement requirements and design feedback loops

Sys

Req 1

Req 2

Req 11

Req 12

Req 21

Req 22

I/F I/F

I/F I/F

I/F

Sys

Func 1

Func 2

Func 11

Func 12

Func 31

Func 32

I/F I/F

I/F I/F

I/F Func 3

I/F

Sys

Sub 1

Sub 2

Comp 21

Comp 22

Comp 23

I/F I/F

I/F I/F

I/F Sub 3

I/F

Systems Engineering Provides the System Design Model, Including Traceability to OpsCon

4

Software Traces the System Engineering Design into the Software

Sys

Req 1

Req 2

Req 11

Req 12

Req 21

Req 22

I/F I/F

I/F I/F

I/F

Sys

Func 1

Func 2

Func 11

Func 12

Func 21

Func 22

I/F I/F

I/F I/F

I/F Func 3

I/F

Sys

Sub 1

Sub 2

Comp 21

Comp 22

Comp 23

I/F I/F

I/F I/F

I/F Sub 3

I/F

Sys

Func 31

Func 32

Func 41

Func 42

Func 51

Func 52

I/F I/F

I/F I/F

I/F Func 33

I/F

Sys

Sub 11

Sub 12

Comp 41

Comp 42

Comp 43

I/F I/F

I/F I/F

I/F Sub 13

I/F

Sys

Req 11

Req 12

Req 21

Req 22

Req 31

Req 32

I/F

I/F I/F

I/F

System Engineering Design

Software/Hardware Design

5

System and Software Design With Full Traceability in an Integrated Model

•  System requirements are decomposed into lower level specs and are traceable to the software and hardware designs

•  CONOPS (operational activities) are traceable to software and hardware behavior in use case, activity, state, and sequence diagrams

•  Requirements at each architecture level are allocated to SW/HW components and functions (activities)

•  So have we achieved the objective?

•  Along the way there was some creative modeling to make this happen

–  System level items modeled in DoDAF (UPDM or SysML) per customer requirement

–  Software items modeled in UML due to SW team familiarity with UML and (in some programs) desire to generate code from model

–  DoDAF model items aren’t typically allowed on SysML diagrams –  Had to transition from DoDAF to UML by switching tools or building a

transition layer

6

One Model, Multiple Viewpoints

Typical Architecture Synthesis Overview

SEIT and Software/Hardware IPTs Share Ownership of Architecture and Design

Allocated to

Performed by

SW/HW Unit SI/HI Component Element Segment System

SEIT IPT Leads Software/Hardware IPT Leads

Performed by

Performed by

Performed by

Implemented by (SV-5a)

Satisfies Allocated to Packaged

as

Composed into

Refined by

Implemented by

Satisfies Allocated to Satisfies Allocated

to

Requirements [Imported from DOORS]

System View

Segment View

Element View

SI Component View

SW Unit View

Traced in the Design Assurance Matrix (DAM)

Linked in the Architecture Model

Decomposed to

Refined by

Refined by

Refined by

Decomposed to

Refined by

Decomposed to

Deployment Diagrams

SW State Machine Diagrams

[as needed]

SW Intra-Component Sequence Diagrams

[Reuse SW: as needed]

Component to

Component Sequence Diagrams

[as needed]

Element to Element Structure Diagrams

(SV-2, BDD, IBD)

SI to SI Sequence Diagrams

[as needed]

Segment to Externals Structure

(SV-1, SV-2)

OV-1a, OV-2, OV-4, OV-6c,

AV-1, AV-2

SV-6, StdV-1

Segment Requirements

SW Class Diagrams and Class

Descriptions

Component to

Component IBD/BDD

CSU Blocks (IBD/

Package Diagrams)

Component to

Component Activity

Diagrams

Use Case Diagrams

[critical only]

Element Requirements

Element Activity

Diagram (SV-4)

Segment Activity

Diagrams (SV-4)

Mission Threads (OV-5b)

Software Requirements

SEIT & Software/Hardware Shared Responsibility

Decomposition of requirements and structural items not shown but are similar to activity decomposition

7

Architecture Synthesis Overview

Transition Layer Bridges Between SEIT and Software/Hardware Parts of Model

Allocated to

Performed by

SW Unit SI Component Element Segment System

SEIT IPT Leads Software/Hardware IPT Leads

Performed by

Performed by

Performed by

Implemented by (SV-5a)

Satisfies Allocated to Packaged

as

Composed into

Refined by

Implemented by

Satisfies Allocated to Satisfies Allocated

to

Requirements [Imported into Artisan from DOORS]

System View

Segment View

Element View

SI Component View

SW Unit View

Traced in the Design Assurance Matrix (DAM)

Linked in the Artisan Model

Decomposed to

Refined by

Refined by

Refined by

Decomposed to

Refined by

Decomposed to

Deployment Diagrams

SW State Machine Diagrams

[as needed]

SW Intra-Component Sequence Diagrams

[Reuse SW: as needed]

Component to

Component Sequence Diagrams

[as needed]

Element to Element Structure Diagrams

(SV-2, BDD, IBD)

SI to SI Sequence Diagrams

[as needed]

Segment to Externals Structure

(SV-1, SV-2)

OV-1a, OV-2, OV-4, OV-6c,

AV-1, AV-2

SV-6, StdV-1

Segment Requirements

SW Class Diagrams and Class

Descriptions

Component to

Component IBD/BDD

CSU Blocks (IBD/

Package Diagrams)

Component to

Component Activity

Diagrams

Use Case Diagrams

[critical only]

Element Requirements

Element Activity

Diagram (SV-4)

Segment Activity

Diagrams (SV-4)

Mission Threads (OV-5b)

Software Requirements

SEIT & Software/Hardware Shared Responsibility

Decomposition of requirements and structural items not shown but are similar to activity decomposition

Transition Layer in one of these levels

8

Conclusions

•  Objective of full traceability from system to software is achievable but faces hurdles

•  A single model can support both SEIT and SW/HW objectives

•  Current architecture modeling tools don’t consistently provide a good solution

•  UPDM and/or SysML may need revision to facilitate better traceability, or is it a tool implementation issue?

9

One Model, Multiple Viewpoints