Experiences in Applying SysML to Develop …...Experiences in Applying SysML to Develop...

Experiences in Applying SysML to Develop Interoperable Torpedo Modeling

and Simulation Components

Presented to:NDIA10th Annual Systems Engineering ConferenceSan Diego, CA

Presented by:Thomas HaleyNaval Undersea Warfare CenterDivision NewportNewport, RI

24 October 2007

http://www.acq.osd.mil/osjtf/

2

Outline

• SysML Case Study Motivation • TEAMS Project Background• SysML Proof of Concept• Lessons Learned• TEAMS Perspective: SysML Pros and Cons• Acknowledgements

3

Funded by Office of Secretary of Defense, Systems and Software EngineeringDetermine if open standards can be used to describe:– System of systems (SoS) architectures based on

computer models– System components as elements of composable

distributed simulationsDetermine whether SysML models can be used in conjunction with performance simulation models

Motivation:Feasibility of Open Standards

4

Background: TEAMS Simulation Scope

Campaign

Mission

Engagement

Engineering

Military M&S Resolution Levels

TEAMS Emphasis:“Launch-to-Hit”

Analysis

TEAMS: Torpedo Enterprise Advanced Modeling & Simulation

5

Background:High-Level M&S Requirements

R’s Pdet Pcl Phit Wheff=Pk X X X X

Torpedo Kill Chain

Other “Stimulus” M&S Components

EnvironmentalAcoustics Targets Countermeasures

Torpedo M&S Components

Sensor Post-DetectionProcessing Tracking Control Hydro-

dynamicsFuze

6

TEAMS Background

LASWFNCLASWFNC

WeaponsNNR

WeaponsNNR

D&ID&I

FFPFNCFFPFNC

Today

CMs NewSensors

MultipleWeaponsTargets

Where We Are Going

CMsCMs NewSensorsNew

Sensors

MultipleWeaponsMultipleWeaponsTargetsTargets

Where We Are Going

Problem: Modeling & Simulation Business “Model” Obsolete

– Monolithic– Stove pipes– Single developers– No communication

Solution: Foster Collaborative M&S Development Environment

– Standardize M&S architecture framework and component models

– Reduce the technology development timeline

– Increase model content, implementation efficiency and reuse

– Reduce cost

7

Overall TEAMS Goals

Modeling and Simulation Community Collaboration Standardized architecture framework

– Conceptual reference model– Model-based requirements specifications

Standardized reference model interfaces– Interchangeable & composible components– Extendable to other applications (e.g., XML schema)– Semantically described (e.g., OWL ontology)

Document standards and requirements Cost effective process to achieve interoperability and composabilityBusiness model for future cross-organization M&S funded efforts

8

TEAMS Core Requirements

1. Standard Interfaces2. Platform Independence3. Open Standards4. Model Realizable Systems5. Extensible Interfaces6. Evolving Standards7. Loosely Coupled Interfaces8. Tiers of Interfaces9. Support Different Levels of Detail10. Standard Implementation Strategies

9

International organization, developers of TOGAF architectural framework

- Wants TEAMS as test case for TOGAF 8.1.1 and 9.0

- Interest in using TEAMS to test synergy between DoDAF and TOGAFframeworks

- Wants TEAMS for its process to incorporate Ontologies (relationships of components)

Organizations Looking to TEAMS

TEAMS is quickly yielding highly visible and transitionable results.

International organization, developers of several business communications standards

- Used TEAMS as test case for their TOGAF/ Model Driven Architecture (MDA) under the TOGAF/MDA Synergy Project

The Open Systems Joint Task Force of the Office of Secretary of Defense (OSD)

- Wants to convert TEAMS UML artifacts to the newly approved SysML standard to demonstrate utility of the new standard

http://www.omg.org/

http://www.acq.osd.mil/osjtf/

10

High-Level Process:TOGAF ADM

The Open Group: IT ConsortiumOffers Consortia Services

TOGAF: The Open Group Architecture Framework

ADM: Architecture Development Method

11

“OMG™ is [a] … not-for-profit computer industry consortium … developing enterprise integration standards for a wide range of technologies [… / …] industries … enabl[ing] powerful visual design, execution and maintenance of software and other processes…”CORBA – Common Object Request BrokerUML – Unified Modeling LanguageSysML – Systems Engineering Modeling LanguageNumerous others in diverse industries (e.g., business)Developer of Model Driven Architecture (MDA) method

OMG has a model-based emphasis in developing standards

http://www.omg.org/

12

UML

UML Consists of 13 Diagrams

Structure: E.g., Class Diagram

Behavior: E.g., Activity Diagram

Interaction: E.g., Sequence Diagram OMG models are MOF-Based - Meta-Object Facility Standard

Think “TurboTax”

http://en.wikipedia.org/wiki/Image:Uml_diagram.svg

http://upload.wikimedia.org/wikipedia/en/3/32/CheckEmail.png

13

Computation Independent Model (CIM) is a domain view of a system that does not show detailed structure.

Using MDA in SE Context

Transition

Validation

Verification

IntegrationImplementation

RequirementsDevelopment

DesignSolution

LogicalAnalysis

Core Technical SE ProcessesCIM

PIM

PSM

Code

Platform-Independent Model (PIM) represents business functionality and behavior, undistorted by technology detailsPlatform-Specific Model (PSM) defines mappings for generation of implementation from the PIM.

The implementation (code) for technology selected by the developer

14

Baseline Technology Architecture

PingServer

Signal InjectionInterface

ScenarioFile

ReverberationGenerator

SignalGenerator

NTS

BasebandAcousticData

Origin-Based Simulators

RunData

I/FBoard

Signal Parameter Generator (SPG)

Target Models

Acoustic Data

Origin 2000

I/OFire Control

I/F

Dynamics

AfterbodyInterface

Fiber OpticRing

RecordI/F

RecordingData

Data Record

Display

HLA

Post Run Tools:Glance

Quick Look

EnvironmentGeneration

Tools

Scenario Setup Tools:Interface

Preset

Pg 6Pg 10

Pg 11Pg 14

Pg 14

Pg 21

Pg 23

Pg 8

Pg 22

Pg 31

Pg 26

Pg 26

Pg 27

Pg 32

Pg 26

OBJECT ACOUSTICSActive Target StrengthTarget Radiated NoiseCountermeasuresMagnetics“Artificial” TargetsPlatform SensorsRemote Sensors

DYNAMICSWeapon 6 DOFWeapon 3 DOFSubmarineSurface ShipAircraftCountermeasure

OTHERCommand and ControlPropulsionPropulsors

Multiple ObjectAcoustics and DynamicsInterface

SensorsTactical

Processor

ControlServosAutopilot

Propulsion

Post-DetectionProcessor

Tracker

SonarController

SignalProcessor

Pro

p

ENVIRONMENTAL ACOUSTICSSound Propagation MultipathsAmbient NoiseReverberationSurface and Bottom TypesWakeIce

WEAPON/PLATFORM ACOUSTICSSelf-NoiseRadiated NoiseBeam FormingPulse Types

Submarines, surface ships, and platform sensors







SensorsTactical

Processor


Propulsion


Tracker

SonarController

SignalProcessor

Pro

p

SensorsTactical

Processor


Propulsion


Tracker

SonarController

SignalProcessor

Pro

p





Oce an

SoundSpee d

Absorption

Bounda ryRe fle ction

Scatte ring

Sona r Transmitte r

Tra jectory

Bea m(fre q)

Signa l

T

Sona r Rece iver

Bea m(fre q)

R

RTra jectory Signa l

Eige nra y

de lay, los s (freq), dire ctions

Ta rge t

Tra je ctoryhighlights

Source

Traje ctoryS igna lBe a m

Filte rs , De lays

Re verbe ration

Ta rge t Echo

One-wa y S igna l

Gene rateBroa dba nd

Noise Spe ctra

Any Exte rnal Signa l

Acoustic Environmental

Model

Magnetic Environmental

Model

Visual Environmental

Model

Radar Environmental

Model

Wake Environmental

Model

Other Acoustic Emissions

OR

Other Visual Emissions

Other Radar Emissions

Other WaKeEmissions

Acoustic Propagation Model

Magnetic Propagation Model

Visual Propagation Model

Radar Propagation Model

Wake Propagation Model

Acoustic Sensors

Magnetic Sensors

Visual Sensors

Radar Sensors

Wake Sensors

Data Displays

Data Fusion

Acoustic Emissions

Magnetic Emissions

Visual Emissions

Radar Emissions

Wake Emissions

Naval Platform

Man-in-the-Loop Control

Rule-Base Behavior

Scripted Behavior

Other Magnetic Emissions

KinematicModel


Model


Model


Model

Radar Environmental

Model

Wake Environmental

Model


OR



Other WaKeEmissions






Acoustic Sensors

Magnetic Sensors

Visual Sensors

Radar Sensors

Wake Sensors

Data Displays

Data Fusion

Acoustic Emissions

Magnetic Emissions

Visual Emissions

Radar Emissions

Wake Emissions

Naval Platform


Rule-Base Behavior

Scripted Behavior


KinematicModel

Sensor

Tactics

Motion

EnduranceEmitters

& Reflectors

Launcher

Sensor

Shape

Sensor

Tactics

Motion

Shape

Endurance

Reflectors

Launcher

Shape Tactics

MotionMotion

CASSANDRA:Common Elements

WAF Architecture TRM’s CARLEE

SST Component Models

CASSANDRA Common Elements

ORBIS Object Examples

Common Architecture Framework

PingServer

Signal InjectionInterface

ScenarioFile

ReverberationGenerator

SignalGenerator

NTS

BasebandAcousticData

Origin-Based Simulators

RunData

I/FBoard

Signal Parameter Generator (SPG)

Target Models

Acoustic Data

Origin 2000

I/OFire Control

I/F

Dynamics

AfterbodyInterface

Fiber OpticRing

RecordI/F

RecordingData

Data Record

Display

HLA

Post Run Tools:Glance

Quick Look

EnvironmentGeneration

Tools

Scenario Setup Tools:Interface

Preset

Pg 6Pg 10

Pg 11Pg 14

Pg 14

Pg 21

Pg 23

Pg 8

Pg 22

Pg 31

Pg 26

Pg 26

Pg 27

Pg 32

Pg 26





SensorsTactical

Processor


Propulsion


Tracker

SonarController

SignalProcessor

Pro

p










SensorsTactical

Processor


Propulsion


Tracker

SonarController

SignalProcessor

Pro

p

SensorsTactical

Processor


Propulsion


Tracker

SonarController

SignalProcessor

Pro

p





Oce an

SoundSpee d

Absorption

Bounda ryRe fle ction

Scatte ring

Sona r Transmitte r

Tra jectory

Bea m(fre q)

Signa l

T

Sona r Rece iver

Bea m(fre q)

R

RTra jectory Signa l

Eige nra y

de lay, los s (freq), dire ctions

Ta rge t

Tra je ctoryhighlights

Source

Traje ctoryS igna lBe a m

Filte rs , De lays

Re verbe ration

Ta rge t Echo

One-wa y S igna l

Gene rateBroa dba nd

Noise Spe ctra

Any Exte rnal Signa l


Model


Model


Model

Radar Environmental

Model

Wake Environmental

Model


OR



Other WaKeEmissions






Acoustic Sensors

Magnetic Sensors

Visual Sensors

Radar Sensors

Wake Sensors

Data Displays

Data Fusion

Acoustic Emissions

Magnetic Emissions

Visual Emissions

Radar Emissions

Wake Emissions

Naval Platform


Rule-Base Behavior

Scripted Behavior


KinematicModel


Model


Model


Model

Radar Environmental

Model

Wake Environmental

Model


OR



Other WaKeEmissions






Acoustic Sensors

Magnetic Sensors

Visual Sensors

Radar Sensors

Wake Sensors

Data Displays

Data Fusion

Acoustic Emissions

Magnetic Emissions

Visual Emissions

Radar Emissions

Wake Emissions

Naval Platform


Rule-Base Behavior

Scripted Behavior


KinematicModel

Sensor

Tactics

Motion

EnduranceEmitters

& Reflectors

Launcher

Sensor

Shape

Sensor

Tactics

Motion

Shape

Endurance

Reflectors

Launcher

Shape Tactics

MotionMotion

CASSANDRA:Common Elements

WAF Architecture TRM’s CARLEE

SST Component Models

CASSANDRA Common Elements

ORBIS Object Examples

Common Architecture Framework

Sonar System Toolset (SST)

Weapons Analysis Facility (WAF) Technology Requirements Model (TRM)

ConceptualReference

Model

ConceptualReference

Model

The Method: Model Driven Architecture (MDA)MDA

Computational Independent Model (CIM)

MDA Computational Independent Model (CIM)

1.Propagation• Ray Tracing• Bottom Scattering

2.Platform/Vehicle and Tracking

• Location• Orientation• Time/Space/Position

Information (TSPI)• Kinematics

3.System Components (Platform/Torpedo)

• Propulsion• Sonar

4.G&C – Signal Processing Chain

• Command and Control• Tactics

5.Targets• Highlights• Active Sources• Non-Acoustic

7.Simulation Run Info & Management

• Time• Events

8.Environment• Sound Velocity Profile (SVP)• Surface Wave• Bottom Characteristics• Boundary Characteristics• Bathymetry• Bottom Scatter Strengths• Environmental False Targets

9.Model Description• Fidelity• Level of Detail• Validity• Launchers• Submarine and Surface Ship

Classes• Inter-platform Communication

(relationships)

6.Data Interchange• Precision• Units• Errors• Tolerances• Uncertainty

TEAMS Conceptual Reference Model

MDAComputationalIndependentModel (CIM)

3322

2233 4455

33

11

88

6,76,788

88

11

11

1. Propagation• Ray Tracing• Bottom Scattering

2. Platform/Vehicle and Tracking

• Location• Orientation• Time/Space/Position Information (TSPI)• Kinematics

3.System Components(Platform/Torpedo)

• Propulsion• Sonar

4. Signal Proc. Chain

(Guidance & ControlCommand and ControlTactics

5. Targets• Highlights• Active Sources• Non-Acoustic

7. Simulation Run Info & Management

• Time• Events

8. Environment• Sound Velocity Profile (SVP)• Surface Wave• Bottom Characteristics• Boundary Characteristics• Bathymetry• Bottom Scatter Strengths• Environmental False Targets

9. Model Description• Fidelity• Level of Detail• Validity• Launchers• Submarine and Surface Ship Classes• Inter-platform Communication

(relationships)

6. Data Interchange• Precision• Units• Errors• Tolerances• Uncertainty

TEAMS Conceptual Reference Model

17

Platform Conceptual Level Diagram

18

Environment Conceptual Level Diagram

19

The Method: Model Driven Architecture (MDA)

TEAMS UML Component Diagrams(Now Represented in SysML)



MDA PlatformIndependentModel (PIM)

20

TEAMS PSM: Implementation

Closed-Loop SimuLink™ Torpedo, Environment & Target

Jackson Bottom Model via CORBA

In-situ Environmental Datavia Web Services

Applied Physics LabUniversity of Washington

NAVOCEANOSIPRNET Web Site

Reference Implementations

21

TEAMS SysML Proof of Concept

Port existing UML to SysML– Torpedo system components– Simulation environment

Extend TEAMS SysML to include:– Requirements traceability– Parametrics and constraints

Share experiences and lessons learned using SysML for architecture and component modeling

22

UML to SysML Approach

Convert UML Class Diagrams to SysMLBlock Definition Diagrams (BDDs)Convert UML Component Diagrams to SysML Internal Block Diagrams (IBDs)Represent Behavior Relationships Between Blocks as Activity Diagrams (new!)Capture Requirements Traceability (new!)Capture Parametric Relationships and Constraints (new!)

23

TEAMS Perspective:SysML Pros and Cons

ProsRequirements

– Explicitly lay out requirements and consequences

Views and Viewpoints– Can separate requirements and model

views based on stakeholders concernsStructure

– Ability for model structure to verify requirements

Can search for requirements that aren’t verifiedCan search for model components that aren’t justified

– Separation of structure from behaviorSysML BDDs vs. IBDs and Activities allow for clear separationUML allows this, but easier to implement in SysML

Behavior– Dashed line for activity flow is more

aesthetically pleasingvs. UML solid line

ConsAllocating CIM to PIM

– Difficulty with abstract activitiesExit path dependent on logic within an activity is not accessible and can’t be modeledNot represented well in either UML or SysML – tactical controller example

Implementing PIM– Not “direct” for some SysML features

Flow ports, continuous activities, parametric constraints involve more components than just themselvesFlows in “real systems” easier to representFlows in software modeling are open to interpretation

– Requires additional documentation of model to bridge between SysMLfeature and executable code

24

TEAMS Perspective:SysML Pros

ProsRequirements– Explicitly lay out requirements and consequences

Views and Viewpoints– Can separate requirements and model views based on stakeholders concerns

Structure– Ability for model structure to verify requirements



Behavior– Dashed line for activity flow is more aesthetically pleasing

vs. UML solid line

25

Sponsor Requirements

26

Rationale for Deriving TEAMS Core Values

from Sponsor Requirement(s)

27

Requirements Traceability: TEAMS Core Values

28

Sponsor Requirements Mapped to TEAMS Core Values

29


ProsRequirements– Explicitly lay out requirements and consequences

Views and Viewpoints– Can separate requirements and model views based

on stakeholders concernsStructure– Ability for model structure to verify requirements




vs. UML solid line

30

TEAMS Stakeholder Requirements

31


ProsRequirements

– Explicitly lay out requirements and consequencesViews and Viewpoints

– Can separate requirements and model views based on stakeholders concerns

Structure– Ability for model structure to verify requirements




vs. UML solid line

32

Torpedo Block Definition Diagram

33

Torpedo Internal Block Definition Diagram

34

Torpedo Sensor Activity Diagram

35

Undersea World Block Definition Diagram

36

Simulation “World”Internal Block Definition Diagram

37

Acoustic Properties Internal Block Definition Diagram

38


ProsRequirements

– Explicitly lay out requirements and consequencesViews and Viewpoints

– Can separate requirements and model views based on stakeholders concernsStructure

– Ability for model structure to verify requirementsCan search for requirements that aren’t verifiedCan search for model components that aren’t justified


Behavior– Dashed line for activity flow is more aesthetically

pleasingvs. UML solid line

39

Simulation “World” Activity Diagram

40

Solid Line Representation

41

TEAMS Perspective:SysML Cons




Flow ports, continuous activities, parametric constraints involve more components than just themselvesFlows in “real systems” easier to representFlows in software modeling are open to interpretation

– Requires additional documentation of model to bridge between SysML feature and executable code

42

TEAMSTactical Controller Example

43

TEAMS Perspective:SysML Cons




Flow ports, continuous activities, parametric constraints involve more components than just themselvesFlows in “real systems” easier to represent than simulationsFlows in software modeling are open to interpretation

– Requires additional documentation of model to bridge between SysML feature and executable code

44

Lessons Learnedand Value Added

Requirements traceability is vital to the success of several TEAMS projects

– ONR TEAMS standard framework and interfaces– OSD-ATL feasibility study– TOGAF/MDA Synergy Project

SysML was designed with “real” systems in mind– where UML is software oriented

Perceived concreteness – simulated vs. actual system– not just one way to design interfaces, need recommendations

for implementationStill need some UML features not present in SysML

– <<Instantiate>> or <<create>> for dynamic allocationStill need guidance on how to best implement parametrics and constraints for modeling and simulation

45

OMG SE DSIG Recommendation

“Clarify the distinction between the domain model and the simulation design model.”

*Reference SE DSIG minutes from OMG San Diego Meeting on March 27, 2007

Integrating SysML Modelswith Simulation Models

Goal– Integrate system design models with simulation and analysis

modelsUse SysML models to specify an executable architectureUse simulation and analysis models to analyze performance

How can they work together ?– Plug the SysML executable architecture model into a simulation

infrastructure to establish a dynamic interface – Use the executable architecture model to control the sequence

of activities (e.g. detect target, launch weapon)– Use the simulation model to compute the parameter values (e.g.

missile range to target vs. time)What is needed?

– Approach to use SysML architectural model to specify simulation requirements (use of parametrics?)

– Harmonization between SysML and simulation standards (i.e. HLA) ?

Source: Sanford Friedenthal, Lockheed Martin, OMG SE DSIG Chair - Recommendation to TEAMS Project

47

Future Direction

Working to Establish an Activity for SysML / Simulation Integration Approach– Formulation/establishment during INCOSE MBSE

Workshop in Albuquerque on January 24-25– Liaison to the INCOSE Model Base Systems

Engineering (MBSE) Initiative– Keep abreast of industry related activities– Help to foster interaction in this area across

industry, government and academia to help move towards the INCOSE MBSE Vision.

– Explore this integration through SISO.

48

Acknowledgements

LtCol Telford / Dwayne Hardy and OSD-ATL; supported and funded this effort for FY07David Drumheller and ONR; supports and funds TEAMSSanford Friedenthal of Lockheed Martin; contributed his expertise and willingness to educate the TEAMS consortium on the nuances of SysMLMembers of The Open Group, Object Management Group, and TEAMS Consortium; contributed to the success of SysML ProjectSparx Systems; provided complimentary licenses for Enterprise Architect 6.5 for this SysML effort

49

References

Armstrong, C., Cerenzia, J., Harrington, E., Rivett, P., Waskeiwicz, F., , TOGAF/MDA/IC Synergy Project: Integration Proof-of-Concept Results, Proceedings of the Global Information Summit 2007.Avalable: http://www.omg.org/docs/omg/07-05-01.pdfCerenzia, J. L., Scrudder, R.; Goddard, R. P., Haley, T. B., Lounsbury, D. M., Practical Experiences in Creating Components from Legacy Simulations, Proceedings of the Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC), 2005.Avalable: http://ntsa.metapress.com/app/home/contribution.asp?referrer=parent&backto=issue,111,153;journal,2,7;linkingpublicationresults,1:113340,1

http://www.omg.org/docs/omg/07-05-01.pdf

http://ntsa.metapress.com/app/home/contribution.asp?referrer=parent&backto=issue,111,153;journal,2,7;linkingpublicationresults,1:113340,1



Experiences in Applying SysML to Develop …...Experiences in Applying SysML to Develop...

Documents

Transcript of Experiences in Applying SysML to Develop …...Experiences in Applying SysML to Develop...