Model-Based Systems Engineering

Practical Perspectives

Clive Boughton

Clive Boughton

The hope of MDD

COMP3530

AssemblyCode

Machine Code

Appropriate for1950 - 1960s

Assembler

High Level Language

Source Code

Assembly Code

Source CodeCompiler

Appropriate for1960 - 1990s

UMLModels

Source Code

ModelCompiler

Appropriate for2000s

2

What about now in 2015?

Clive Boughton

Agility not Agile Development

• Earlier delivery of simulations/code to the customer • Increments/releases in models - continuous capture of

requirements• Refactoring - Who wants to do it with code? • “Pair modeling”• IP is in the models

MDA and xtUML• We were doing MDA 10 years ago (Model Design Code)• xtUML ‘automated’ MDA• MDA remains but xtUML as an MDD tool has disappeared

Agility with MDD - 1

3COMP3530

Clive Boughton

Agility with MDD - 2

Working tenets• Low overhead software development (smart developers + automation)• Workable requirements (once they are modelled)• Thinkers over processes and tools• Customer collaboration• Welcoming change

Demonstrated agility • Analysis models that business people can understand and comment on• Minimal documentation (its mostly in the models)• Requirements changes

easily demonstrated and accommodated with modelsvery visible to customer

• Rapid turn-around time to re-generate and re-deploy application/system

4COMP3530

Clive Boughton

Class Models: Easier for who?

COMP3530 5

Clive Boughton

State Models: Easier for who?

6COMP3530

Clive Boughton

Domain ’TRANSPORT' Statechart 'Logistics::Mission_Set' Description and Action Specification

State: 7. Attempt_Vehicle_Allocation

…if not empty vehicle // unrelate from all existing possible uses (now redundant as vehicle has moved) select many possible_uses from instances of PU where selected.Vehicle_ID ==

rcvd_evt.Vehicle_ID; if not empty possible_uses for each possible_use in possible_uses select any mission related by vehicle -> M[R243]; unrelate vehicle from mission across R243 using possible_use; delete object instance possible_use; end for; end if; // if none that's OK

//find trips that start where vehicle is located select many trips from instances of Trip where selected.Departure_NodeID ==

vehicle.Currently_Available_At_ID; if empty trips…

Action Language: Easier for who?

7COMP3530

Clive Boughton

MDD: Used in many domains

Business (commerce & government)DefenceElectionsEmergency services and securityMedicalTraffic controlTransport logisticsAerospace

8COMP3530

Mostly M

DD in th

e form

of MBSE

Clive Boughton

Transport Airlift Integrated Logistics

The TAIL model is a simulation of the air transport of resources to remote locations in an emergency.

• High Level of Detail• Air Transport only• Remote Location• Context : Emergency

(possible infrastructure damage, time critical)

9COMP3530

Clive Boughton

TAIL Model

In a natural disaster, a variety of emergency resources are needed, and quickly.

• Natural DisasterCycloneVolcanoTsunamiEarthquake

• Mode(s) of TransportShipTruckRailAir

10COMP3530

Clive Boughton

TAIL Model

The modeling of the transportation of these resources is complicated by several issues:

• Heterogeneous Cargoes• Weather• Infrastructure Capabilities• Not limited to Civil Transport

(all available)

11COMP3530

Clive Boughton

TAIL Model

Given :• Set of available aircraft

(with certain characteristics)• Sets of cargo to be transported

(and routes)

Then :• How long will it take to transport cargo and evacuate people?• Can all cargo be transported?• Where are the bottlenecks?• How much will it cost?

12COMP3530

Clive Boughton

Table Driven Simulation

All simulation of initial conditions in tables• Aircraft Specifications & Numbers• Transport Nodes (Infrastructure)• Routes• Cargo Items

Atomic and Bulk Cargo• Weather

Easy to change initial conditions, re-run and compare results

13COMP3530

Clive Boughton

Results

Full simulation audit trail• Snapshot of initial conditions• Tracking of individual cargo items • Aircraft use and locations• Cost breakdowns• Snap shot of final conditions• Aggregated costs and usage

Flexible • Customer requirements for results not known• XML allowed easy extraction of items of interest

14COMP3530

Clive Boughton

TAIL Metrics - 1

6 elapsed weeks

10 effort weeks (domain expert & modeler)• A standard simulation was still incomplete after 2 years

34 classes • 6 active (have state model)• 28 passive (some place-holders for extensions)

39 states

15COMP3530

Clive Boughton

TAIL Metrics - 2

1,676 lines action language

18,061 lines generated C++ (excl. mechanisms)

1,566 lines C++ hand coded (input table driven)

116 builds (half in last week)

16COMP3530

Clive Boughton

TAIL Outcomes

Early feedback to customer • Weekly milestones & deliveries

IP capture at high level of abstraction

Project successful

Unexpectedly useful results • Sensitivity to infrastructure capability• Sensitivity to minor aircraft capability differences

17COMP3530

Clive Boughton

Issues that had to be overcome

• Ensuring accurate abstraction of the (business) requirements

• Getting people to understand ‘less’ is better than ‘more’ for objects• While separating concerns

• Deficiencies of the available tools• Weren’t perfect but worked and added significant value!

18COMP3530

Clive Boughton

Advantages of MDD (xtUML)

Project

Actual Effort (PM)

Hand Coding

(FP/PM)

Modeling plus Hand

Coding (FP/PM)

Modeling plus Model Compiling (FP/PM)

PI US* Hand

Coding (FP/PM)

BattleMapTM 8.0 242 23 0.9

MAC2 8.0 185 22 1.5

TAIL 2.5 157 23 2.5

SoDISTM 31.5 38 12 3.8

Ada Model Compiler

12.5 38 13 4.5

* Capers Jones - Applied Software Measurement - 1997

19COMP3530

Clive Boughton

What’s the state of play? - 1

• You don’t need to invest heavily or take unnecessary risks to start using MDD concepts• Even on small projects• Good tools provide significant value by reducing costs & schedule

further

• Models sometimes developed & translated into code manually &/or with the use of simple tools• Typically “toe-in-the-water” approach!

• Lack of people with a high level of abstraction capability• Sometimes seen as too HARD to fix!This situation might be improving

20COMP3530

Clive Boughton

What’s the state of play? - 2

• OMG UML 2.4.1 is mature and stable• Contains most of the required modeling elements• Has good tool support (both commercial and free)• Is basis for several other profiles – SysML, SoaML, UPDM, MARTE• Version 2.5 (Beta) available

• MDD concepts are seen as increasingly to ‘systems’ development• INCOSE strongly supports MBSE – WG with OMG

• Now a wider range of MDD concepts, methods and tools available for S/W and Sys Engineers

21COMP3530

Clive Boughton

What’s the state of play? - 3

SysML now quite stable.• Encourages architecture & design based thinking.• Even includes a requirements diagram! • Has built-in constructs for traceability and verification• Several good tools available (commercial & free)• Together with UML ans SoaML forms basis of UPDM profile

Systems Engineers use architecture frameworks• To develop (arch/design) models for solution spec. and

simulations.

Enterprise Architects use architecture frameworks • To develop business/IT operations - ERP

COMP3530 22

Clive Boughton

What’s the state of play? - 4

AFs have evolved largely by increasing ‘views’ or

‘viewpoints’For example DoDAF 2 contains the following viewpoints - views• All Viewpoint (AV) – 2 views• Capability Viewpoint (CV) – 7 views• Data and Information Viewpoint (DIV) – 3 views• Operational Viewpoint (OV) – 9 views• Project Viewpoint (PV) – 3 views• Services Viewpoint (SvcV) – 13 views• Standard Viewpoint (StdV) – 2 views• Systems Viewpoint (SV) – 13 views

8 viewpoints / 51 views – only very large systems use all!

COMP3530

Some u

sefu

l too

ls now

suppor

t

DoDAF an

d MoD

AF – UPDM

.

23

Clive Boughton

DoDAF Viewpoints

COMP3530

All V

iewpoint

Overarching aspects of architecture context that relate to all m

odels

Data and Inform

ation View

pointA

rticulate the data relationships and alignment structures in the architecture content

Standards V

iewpoint

Articulate applicable O

perational, Business, Technical, and Industry policy,

standards, guidance, constraints, and forecasts

Systems ViewpointArticulate the legacy systems or independent systems, their composition, interconnectivity, and context providing for, or

supporting, DoD functions

Services Viewpoint Articulate the performers, activities, services, and their exchanges providing for, or supporting, DoD functions

Operational ViewpointArticulate operational scenarios, processes, activities &

requirements

Capability Viewpoint Articulate the capability requirement, delivery timing, and

deployed capability

Project V

iewpoint

Describes the relationships betw

een operational and capability requirements and the

various projects being implem

ented; Details dependencies betw

een capability m

anagement and the D

efense Acquisition S

ystem process.

24

Clive Boughton

UPDM

OMG has weighed into AF domain with the Unified Profile

for DoDAF & MoDAF (UPDM).

COMP3530

Lots of tools support UMLGrowing number of tools support SysMLSeveral tools now support UPDM at L1

25

Clive Boughton

DM2: DoDAF Meta-Model

COMP3530

Underlying the DM2 is a foundation of common ontological constructs that facilitate the reuse of common data patterns, as shown below.

26

Clive Boughton

Underpinning Ontologies

An Ontology (the nature of being - philosophy)• Captures knowledge about a domain of interest.• Describes concepts within a domain• Describes relationships between concepts• Typically based on a logical model

o Making it possible for concepts to be defined as well as described.

o Allows use of ‘reasoners’ to check consistency.

• OWL (Web Ontology Language) consists of:o Individualso Classeso Properties

COMP3530 27

Clive Boughton

And then there’s AADL

A unifying framework for MBSE used to capture (in

a single model):• Static modular s/w architecture,• Runtime architecture in terms of communicating tasks,• The computer platform (h/w) architecture on which s/w is

deployed, and• Any physical system/environment interfaces with which a

system interacts.• Architecture is represented as a hierarchy of interacting

components.• I/F specs & implementation blueprints of s/w, h/w &

physical components are organised into packages to support large scale & team based development.

COMP3530 28

Clive Boughton

And then there’s AADL

AADL is an SAE standard that has annexes for:• A meta-model,• Graphical notation,• Model interchange formats, • Language compliance,• API, and• Error model language.

COMP3530

AADL can be considered an alternative to MARTE & SysML

A few good tools for AADL are now available• OSATE-2 & OCARINA

29

Clive Boughton

MDD with xtUML

COMP3530 30

Clive Boughton

MDD with SysML

COMP3530 31

Clive Boughton

MDD with AADL

COMP3530 32

Clive Boughton

MDD with SysML & AADL

ExSAM (for example)

COMP3530 33

1Requirements, Traceability, Parametric Models, Interactions

2Modes / State Machines,Components / System Blocks,Component Interactions / Block Flows

3Quantitative Analysis,Hardware-Software Component Categories,Software to Hardware Binding

SysML

AADL

Clive Boughton

Complex or Complicated

• The mechanical/electronic things that humans build are often ‘complicated’• Intricate but determinable!

• When humans are part of a system then they are often ‘complex’• Intricate and often indeterminable!

• MBSE is expected to deal with both of these.• MBSE languages are complicated – much more

so than (say) Ada or HTML etc.

COMP3530 34

Clive Boughton

Systems of Systems

MBSE is expected to deal with SoS and:

• Multi-domain systems in a multi-disciplinary environment• The inherent lack of individuals who can grasp the concepts.• The inherent lack of individuals who can ‘conceptualise’.• The lack of professionalism in the ICT/SysEng domain.• Perpetuation of ‘belief systems thinking’.

BUT:

It seems we might be getting somewhere – at last!!

COMP3530 35