EmbeddedPlus Engineering [email protected] (480) 517-9200 Embedded Plus Engineering Innovative Comprehensive Solutions V1.0 Current

EmbeddedPlus Engineeringwww.embeddedplus.com

[email protected](480) 517-9200

EmbeddedPlus EngineeringInnovative Comprehensive Solutions

V1.0

Current Status of

SysML and UPDM- A DoDAF Profile

by

Paula ObeidPresident

Embeddedplus EngineeringFor

INCOSE Orlando ChapterMay 15, 2008

V1.0

Why Model Systems? Manage Complexity

Ability to abstract detail, drill down for details Improve communications

Between internal stakeholders/teams With customers

Reduced ambiguity and errors Formal languages like SysML and UML offer precise

notation Models can seed detailed design and implementation –

particularly for software components. Models can be simulated, documents can not.

V1.0

What is OMG SysMLTM? SysML is an extension of the Unified Modeling Language (UML) that has been

developed to support the systems engineering process. SysML was developed by the Object Management Group (OMG) through an open

process of standards development. A graphical modelling language for Systems Engineering

a UML Profile that represents a subset of UML 2 with the extensions Supports the specification, analysis, design, verification and validation of a broad

range of complex systems systems may include hardware, software, data, personnel, procedures, and

facilities SysML Standard Approved 2007 and currently being adopted by Systems Engineers OMG Finalization task force completed efforts in 2007 OMG Revision task force is wrapping up outstanding issues now

V1.0

UML2

Relationship between SysML and UML

UML not required by

SysML

SysML

UML4SysML - UML reused by

SysML

SysML Profile – extensions

to UML

SysML Toolkit

<<implemented by>>

Eclipse Platform

<<implemented by>>

Rational Software ModelerRational Systems Developer Rational Software Architect

V1.0

SysML Diagram Taxonomy

SysML Diagram

StructureDiagram

BehaviorDiagram

Use CaseDiagram

ActivityDiagram

Internal BlockDiagram

Block DefinitionDiagram

SequenceDiagram

State MachineDiagram

ParametricDiagram

RequirementDiagram

Modified from UML 2

New diagram type

Package Diagram

Same as UML 2

V1.0

req [package] VehicleSpecifications [Requirements Diagram - Braking Requirements]

Braking Subsystem Specification

Vehicle System Specification

id=“102”text=”The vehicle shall stop from 60 mph within 150 ft on a clean dry surface.”

«requirement»StoppingDistance

id=”337"text=”Braking subsystem shall prevent wheel lockup under all braking conditions.”

«requirement»Anti-LockPerformance

«deriveReqt»






SatisfiedBy«block»Anti-LockController



«deriveReqt»

act PreventLockup [Activity Diagram]

DetectLossOf Traction

Modulate BrakingForce

TractionLoss:

par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]

:AccellerationEquation[F = ma]

:VelocityEquation[a = dv/dt]

:DistanceEquation[v = dx/dt]

:BrakingForceEquation

[f = (tf*bf)*(1-tl)]

tf: bf:tl:

f:

F:

c

a:a:

v:

v:

x:

ibd [block] Anti-LockController [Internal Block Diagram]

d1:Traction Detector

m1:Brake Modulator

c1:modulator interface

Cross Connecting Model Elements1. Structure 2. Behavior

3. Requirements 4. Parametrics

act PreventLockup [Swimlane Diagram]

«allocate»:TractionDetector

«allocate»:BrakeModulator

allocatedTo«connector»c1:modulatorInterface

DetectLossOf Traction

Modulate BrakingForce

TractionLoss:


allocatedFrom«activity»DetectLosOfTraction

d1:TractionDetector

allocatedFrom «activity»Modulate BrakingForce

m1:BrakeModulator

allocatedFrom«ObjectNode»TractionLoss:

c1:modulatorInterface


allocatedFrom«activity»DetectLosOfTraction

d1:TractionDetector


m1:BrakeModulator



satisfies«requirement»Anti-LockPerformance


allocatedFrom«activity»DetectLosOf Traction

d1:TractionDetector

valuesDutyCycle: Percentage


m1:BrakeModulator



satisfies«requirement»Anti-LockPerformance

allocate






[f = (tf*bf)*(1-tl)]

tf: bf:tl:

f:

F:

m:

a:a:

v:

v:

x:

v.Position:

v.Weight:v.chassis.tire.

Friction:v.brake.abs.m1.

DutyCycle:v.brake.rotor.BrakingForce:






[f = (tf*bf)*(1-tl)]

tf: bf:tl:

f:

F:

m:

a:a:

v:

v:

x:

v.Position:

v.Weight:v.chassis.tire.

Friction:v.brake.abs.m1.

DutyCycle:v.brake.rotor.BrakingForce:

value binding




VerifiedBy«interaction»MinimumStoppingDistance



SatisfiedBy«block»Anti-LockController



«deriveReqt»

satisfy

verify

V1.0

SysML Toolkit Provides SysML 1.0 Support Highly customizable and easily integrated with

other tools Supports simulation via Simulation Toolkit Supports upgrade of Rose or RSX UML models to

SysML Integrates with Requisite Pro and DOORS for

SysML Requirements Sophisticated query and validation mechanisms

for ensuring completeness of SysML models Compatible with other profiles such as SOA and

DoDAF.

Simulation Toolkit

SysML Toolkit

IBM Rational

Eclipse Platform

- Systems Developer- Software Modeler- Software Architect

V1.0

What is OMG UPDM? An UML Profile for DoDAF/MODAF that provides industry

standard UML/SysML representation and exchange of DoDAF/MODAF architecture artifacts and descriptions

Currently UPDM specifies two compliance levels corresponding to supporting a UML-based profile and a UML+ OMG SysML™ profile.

V1.0

OMG UPDM Status Charter of the Original UPDM FTF remains as is but the

FTF ceased to exist on its existing, published deadline (Friday, March 21, 2008)".

A new team has spun up with the intention of submitting an RFC

Current UPDM Group Mission Statement“The UPDM RFC group is committed to creating a unified

profile for MODAF and DoDAF, leveraging the capabilities of UML, SysML and other OMG standards.”

V1.0

UPDM Group GoalsShort Term Goals

Create a unified profile for DODAF (Department of Defense Architectural Framework) and MODAF (Ministry of Defense Architectural Framework) and submit it to the OMG (Object Management Group) RFC (Request for Comment) process at the September meeting of the OMG. We will use the approved standard of DODAF 1.5 and soon to be released standard of MODAF 1.2.[FD1]

Create an RFP (Request for Proposal) for the next generation UPDM profile to include changes proposed by DOD, NATO, the Canadian Department for Defense, the IDEAS group, and others for the September meeting of the OMG.

Mid Term Goals Create a profile addressing the requirements of the next generation RFP UPDM for submission to the OMG.

Address the future needs of Military Architectural Frameworks by making use of Business Process Modeling, Motivational Modeling, and other concepts.

Long Term Goals Continue to publicize our work in order to build a consensus, standardize the use and definition of Military

Architectural Frameworks, and foster communication and understanding between defense related organizations.

Work to create a standards body with the purpose of specifying a standard MAF definition. [FD1]I suggest removing references to specific version of DODAF. also, the statement :"We will use the approved standard of DODAF 1.5“

is not very accurate, DoDAF is neither "official" approved, it is promulgated to DOD via a memo, a construct diff than that of having docs approved by DOD, and it is not a standard. suggest you just remove the sentence alltogether: "We will use the approved standard of DODAF 1.5 and soon to be released standard of MODAF 1.2."

V1.0

Why UPDM? Significantly enhance the quality, productivity, and

effectiveness associated with architecture and system of systems modeling

Promote architecture model reuse and maintainability Improve tool interoperability and communications between

stakeholders Reduce training impacts due to different tool

implementations and semantics

V1.0

Capabilities– model architectures for a broad range of complex

systems, which may include hardware, software, data, personnel, and facility elements

– model consistent architectures for system-of-systems down to lower levels of design and implementation

– model service oriented architectures– support the analysis, specification, design, and

verification of complex systems – improve the ability to exchange architecture information

amongst related tools that are UML based and tools that are based on other standards

V1.0

Why UPDM Level 1 ? SysML was created as a simple language and extended from

UML to provide functionality required for Systems Engineering Systems Engineers are more likely to use SysML than UML

given the momentum of SysML Primarily systems engineers are responsible for DoDAF/MoDAF

artifact creation System Engineers would like to represent their DoDAF and

MoDAF models using SysML constructs. UPDM Level 0 compliance has redundant elements such as

Requirements and Views which are already exists in SysML. Redefining existing SysML elements for UPDM Level 0 would

confuse System Engineers using SysML. System Engineers views their model as Blocks and Systems

rather than Class and Objects.

V1.0

UPDM Level 1 Toolkit for RSDP Provides UPDM Level 1 modeling Support Highly customizable and easily integrated

with other tools Supports simulation via Simulation Toolkit Integrates with Requisite Pro and DOORS

for Requirements Sophisticated query and validation

mechanisms for ensuring completeness of UPDM models

UPDM Level 1 Toolkit

SysML Toolkit

IBM Rational

Eclipse Platform

- Systems Developer- Software Modeler- Software Architect

UPDM (Level 0)

V1.0

Network-Enablement Increases Complexity and Difficulty of Major Systems Development

Cha

lleng

eLi

fecy

cle

IdentifyGap

DevelopConcept

ProcureSolution

ValidateSolution

DeploySolution

ExtendSolution

IT bridges the gap for NCW transformationIT bridges the gap for NCW transformation

As Is To Be

Com

plex

ity

Tim

e-to

-Sol

utio

n

Complexity & Time-to-solution Diametrically Opposed

Rapidly changing requirements establish the need for agile development of systems where IT bridges the gap

Rapidly changing requirements establish the need for agile development of systems where IT bridges the gap

V1.0

Enterprise Agility is Achieved Through Integration

Systems exist to support the end customer Changes in client requirements or supplier

delivery cascade through the SoS Enterprise How does this impact engineering?

– Migration to architecture and its influence upon enterprise and system lifecycles

– Requirements and design: Analysis of alternatives, cost, impact and risk across the entire asset base including all tiers of supplier

– Development: Make vs Buy vs Use trade offs involving assets across the enterprise

– Validation: Virtual simulation of SoS early in the development lifecycle

– Deployment: Harmonizing component dependencies over time

Reduced time-to-solution adaptive enterprises gain agility dependent increasingly upon frictionless flow of information

V1.0

Enterprise Agility is Achieved Through Integration

Systems exist to support the end customer Changes in client requirements or supplier

delivery cascade through the SoS Enterprise How does this impact engineering?

– Migration to architecture and its influence upon enterprise and system lifecycles

– Requirements and design: Analysis of alternatives, cost, impact and risk across the entire asset base including all tiers of supplier

– Development: Make vs Buy vs Use trade offs involving assets across the enterprise

– Validation: Virtual simulation of SoS early in the development lifecycle

– Deployment: Harmonizing component dependencies over time

Reduced time-to-solution adaptive enterprises gain agility dependent increasingly upon frictionless flow of information

Integration of this scale requires tooling that is as agile as the

systems it seeks to help build.

V1.0

Model Driven Systems Development (MDSD) is as collaborative & agile as the systems built !

Model Driven Systems Development (MDSD) is as collaborative & agile as the systems built !

Need for Frictionless, Predictive Enterprise Tooling Various changes in the A&D community require integration of multiple

systems across disciplines– To decrease latency of program operation– For reduced time from when a gap is identified to when a solution is

deployed.– To increase program adaptability when new functionality is

introduced Doing this requires

– Association between program management and supply chain between all the data of the systems

– Automation of engineering processes to reduce time to solution– Begin architecture simulations earlier in lifecycle– Concept definition is validated earlier with MDSD and tooling

supports standards– Systems and software development are done hand-in-hand

V1.0

Frictionless Development Organization Concept

Gaps

Realization

$Cost

Models

IT bridges the gap for NCW transformationIT bridges the gap for NCW transformation

As Is To Be

Simulations

SystemArchitecture

Model

CapabilitySchedule

CostRisk

Need

Technology

PerformanceMod & Sim

Program Mission Statement

Removing Friction Linkage between Program Management, Procurement,architecture and systems Frictionless flow of information Automation of the engineering and analysis

processes Information collaboration within Program

including Supply Chain Integrating all disciplines through enterprise

artifacts Tooling supports standards

Agile Tooling helps enterprise remove friction from the programAgile Tooling helps enterprise remove friction from the program

Global Enterprise

V1.0

From Execute Break Fix

To Manage Adapt Co-Align

Tool Innovation - removes latency from program processesTool Innovation - removes latency from program processesby providing real-time information accessby providing real-time information access

PastPast FutureFuture

Use Modern Technology to Achieve a Paradigm Shift

V1.0

Frictionless Information Flow: Allows Enterprise to Deliver Faster and Cheaper

Virtual Enterprise Info Repository

ProgramManager

Client

EngineeringIPTs

Business &Contracts Org.

ProgramStaff

IT&V IPT

SubcontractorTeams

Processes and Tools for ALL Disciplines utilize the same Information RepositoryProcesses and Tools for ALL Disciplines utilize the same Information Repository

V1.0

Information Integration and Process Automation across the Enterprise

DB2 CM FamilyDomino.doc DocumentumFileNetOpen TextStellentInterwovenHummingbird

iSight-FWBIEtc.

Lotus NotesMicrosoft Index Server

IBM Lotus Extended Search

SametimeQuickPlaceMicrosoft Exchange

ArchitectureViews: DoDAF, MODAF, sysML, UML

Model-Driven CDRLs

Performance Requirements

Content& Imaging

EngineeringWorkflow Svcs

SoSModel

WebServices

CollaborationSystems

AnalysisApplications

Eclipse / RSA Enterprise Engineering Data Bus

Adapters

Technical MatLabNASTRANForesightEtc.

CostRisk

EngineeringData Repository

MSC SimMgrOthers

V1.0

A Standards Based Solution for Deploying Frictionless Model Driven Systems Development (MDSD)

IBM RationalRose/RoseRT

TelelogicDOORS

IBMRationalClearQuest DK4CQ

DoorKeeper Change Management Umbrella

DK4Eclipse

DK4RSDP

includes

Simulation Toolkitfor IBM RSDP

Eclipse Platform

IBM Rational- Systems Developer- Software Modeler- Software Architect

SysML Toolkitfor IBM RSDP

UPDM (DoDAF)

Level 1

Bridge DOORS to scalable CM infrastructure

Bridge DOORS to opencollaborative infrastructure

Tools for modelingand Integration

Tool Source- IBM- Embedded+- Telelogic

PDM System

Project Management System

V1.0

Frictionless Information Flow: Allows Enterprise to Deliver Faster and Cheaper

Innovative MDSD reduces complexity and time-to-solutionInnovative MDSD reduces complexity and time-to-solution

ProgramManager

Client

EngineeringIPTs

Business &Contracts Org.

ProgramStaff

IT&V IPT

SubcontractorTeams

V1.0

Contact InformationFor more information, please contact:

Paula ObeidEmbeddedplus Engineering480-517-9200 office480-239-0660 [email protected]

V1.0

Leverage SysML Constructs for DoDAF/MoDAF

Use of SysML blocks as the modular unit of structure to represent operational nodes, system nodes, systems, and other structural elements. This in turn enables the use of other SysML features such as flow ports, item flows, and value properties with units and distributions.

Use of SysML activities which includes extensions that support continuous flow modeling, activity hierarchies, and additional semantics to support enhanced functional flow block diagrams.

Use of SysML requirements that enable text based requirements to be captured and traced to other model elements using the satisfy, derive, verify and refine relationships.

Use of SysML parametrics that enable the integration of engineering analysis with the architecture models. In particular, the performance parameters in an SV-7 can be captured in parametric equations.

Use of SysML allocations to support various types of mappings. These are useful for modeling a variety of DoDAF and MODAF products such as an SV-5 that maps systems to capabilities or system functions to operational activities.

In addition, other features of SysML, such as the more formalized use of diagram frames and headers, labeling of compartments, and other features can be leveraged

V1.0

UPDM Level 1 Model Wizard

V1.0

UPDM Level 1 Toolkit Screenshot

Documents

EmbeddedPlus Engineering [email protected] (480) 517-9200 Embedded Plus Engineering Innovative Comprehensive Solutions V1.0 Current