}

SODIUS / EADS CASSIDIAN

MD DAY 2010MODEL DRIVEN ARCHITECTURE FOR SUPPORTING SYSTEMS ENGINEERING AT CASSIDIAN

25 November 2010

Yann LEBEAUPIN – SODIUS – CTO

Jean-Baptiste CARTIER – EADS CASSIDIAN - PLM Technical Expert

Agenda

Introduction

Who is SODIUS?

Collaboration with CASSIDIAN (EADS D&S) since 2009

Enterprise Architecture Framework Interchange Solution Definition

Application and Feedback on a tool migration project

IPSE project and System Engineering collaborative software

perspectives

Model driven architecture for supporting systems engineering at Cassidian

Who is Sodius ?

SODIUS, started in 1999

SODIUS is specialized in Systems Engineering and Interoperability

SODIUS is recognized as a leading company to bridge different tools used by engineers involved in systems or software projects.

SODIUS, is a technology provider for IBM, NoMagic, and a certified IBM Business Partner.

SODIUS provides solutions to interoperate with a number of engineering tools : to transform models, to customize code generators, and create Word documentation from multiple models.

We have highly specialized tools and skills for:

• Model-Driven Engineering

• Multidisciplinary Systems Engineering

• Legacy Models handling

• Long Life Cycle handling (>10 years)

Model Integration and Tools Interoperability Projects

Who is Sodius ?

Based on a common Moded-Based approach and

MDWorkbench technology platform and assets

SODIUS &

Since 2009, SODIUS develops for CASSIDIAN (former EADS Defence & Security)

solutions enabling interchange of data between modeling (architecture framework)

tools in the context of System Engineering projects.

These solutions are achieved as part of a common CASSIDIAN corporate effort

named IPSE (Integrated Project Support Environnement) which goal is to provide a

suite of tools for System Engineering.

First phase of project

Communication between tools for data and diagram exchange

Second and subsequent phases :

Implementation of a "bus" to communicate with more advanced features

as configuration management and automation of authoring activities

Introduction

Who is SODIUS?

Collaboration with CASSIDIAN (EADS D&S) since 2009

Enterprise Architecture Framework Interchange Solution Definition

Scope and solution architecture

Application and Feedback on a CASSIDIAN migration project

IPSE project and System Engineering collaborative software perspectives

Model driven architecture for supporting systems engineering at Cassidian

Agenda

Exchange the models

In the real world, a single toolset is not possible…however we need:

Be able to “exchange” models with partners/external customers/subcontractors on a single target even if

teams have different/heterogeneous choices (historical, national, businness)

To re-use “architecture models”, integrate or migrate “legacy” components

Reuse legacy models (as components) and insert them into new designs

…enhance/customize them to support specific features and manage specific value

DBMSTOOL A

DBMSTOOL B

DBMSTOOL C

?Accept the diversity !

Development of complex systems requires dedicate solutions to enable

exchange, reuse or integrate models helping systems engineers to

handle complete scope and challenges of systems architecting and

management throughout the lifecycle of the system

CASSIDIAN Project context

BorderShield Project Legacy

3 Tools currently used on the BorderShield project in DoDAF context

2

DoDAF

Models initially

created and

used on German

CASSIDIAN

project, then on

BorderShield

1

Change authoring ?

How migrate models and diagrams ?

MEGA 2009

Recommended by our

business Unit

3

Drivers for Change

Facts on the Bordershield project

Initial choice : SA as common language – legacy models

Collateral architecture team shift from SA to EA

Bordershield Technical Opportunity to move to another modelling solution ?

MEGA has been selected on technical criteria

Identified in an internal justification table

Mainly○ Cosmetic features

○ Power of the tool itself

DoDAF SV3 views useless on System Architect

Higher consistency check with MEGA, close to the MetaModel

○ Few support on System Architect in the French « community »

Translation from SA to MEGA 2009 decided

and performed in June 2010 by SODIUS and CASSIDIAN teams

Problem statement

The scope of the solution is to provide an

architecture for

Exchanging models and diagrams

Between MEGA and System Architect

Considering future extensibility needs

DoDAF

One thing that is sure: Actors, Tools, Process,Standards (DoDAF, NAF, UPDM, etc…) WILL CHANGE

The challenge is to integrate architectures in 2010 (t)

AND maintain this capability in 2011, 2015,etc… (t+n) !

NAF

The SAM project had to consider

too the underlying movement to

NAF (NATO Architecture

Framework) in the domain of

complex systems of systems

(NATO, Defence actors, LSI

European projects)

General Capability Requirements

Model Exchange should cover the content of DoDAF ,

and later of NAF

Model Exchange should be “vendor neutral”

Proposed Solution

Adopt NAF V3 Metamodel (NMM) as the pivot format for EA models NAF V3 has the largest user support

NAF V3 has almost a complete coverage for System Engineering projects

Adopt UML2 diagrams as the diagram types for NAF NMM is defined as a abstract UML profile using underlying UML concepts

Ensure application connectivity maintenability

Direct tool integration (P2P) should be avoided because:• There are too many tools involved

• Such integration depends on tools internal architectures which are not under control of the

integration platform

Architecture of the NAF solution

SODIUS has built a NMM 1.0 pivot-based solution, including support of diagrams using connectors to

import/export native “RAW” data from applications and NMM UML models to store intermediate data.

Benefit of the approach: The solution supports both of CORE Data AND Diagrams

exchange. As NMM has been defined as a UML “conceptual” profile (abstract syntax),

implementation is 100% conforming with the specification (NMM 1.0).

NMM

Profile

UML2

MMDI Profile

NAF MM Assets

(Tool Agnostic Pivot)

Conforms To

DBMS1

TOOL 1

TOOL1

Metamodel

TOOL2

Metamodel

DBMS2

TOOL 2

Model 1Model 2

Interoperability Rules

RulesRules

DI

UML2

Models

Rules

NMM

UML2

Models

MDWorkbench

Connector Connector

Interoperability approach

SODIUS’ interoperability approach is based on MDWorkbench platform:

Separated approach between the data (I/O) and the required

transformation : Connectors + MMs + Rules

Metamodels to abstract data model (instead of syntax views)

Connectors to enable tools access (read/write) in multiple, reusable ways and

feed models (conforming to previous MMs)

Rules for specific mapping

Capacity of SODIUS to create new connectors quickly (using any text or xml

formats, apis, web-services or database access)

DBMS1

TOOL 1

RulesTOOL1

Metamodel

Model 1

Benefit of the approach: Rules manage specific exchange process, connectors are

reusable assets encapsulating complexity of connection with tools.

Connector =

MM + Reader

+ Writer

Connectors are

able to manage

many kind of

formats

Diagram Support

SODIUS is involved in the XMI Interchange Workgroup

Even if normalization consensus has not been reached, UML DI Extension referencing UML

semantic elements is a good way to represent “common” denominator between applications in a

pragmatic way

Based on DI format, connectors use diagramming apis or proprietary formats of tools to re-create

diagrams from neutral DI defintions

To manage diagrams in the closest way that target authoring environment allow it, some layout

rules have to be add for each tool (anchors management, edges/nodes support differences

between tools, default shapes) – there is a “human” interpretation to find consensus

(“common denominator”).

DI Profile

NMM

Profile

UML2

MM

NAF MM Assets

“XMI” DI File

DI Model

Semantic

Data

DI Metamodel

Diagram Support“Tool-Agnostic” Viewers of

NAF ModelsDI Model

Connectors use diagramming apis or proprietary

formats serializers to re-create diagrams into

authoring tools from neutral DI definitions

Samples of managed views

MEGA

System

Architect

Diagrams and Data can be exchanged between tools (each time view

concepts are supported by the authoring tool)

UML Base Classes

«metaclass»

InformationFlow

«metaclass»

Property

«metaclass»

Class

wh

ole

1

*

pa

rt

1

*

targ

et

1

*

so

urc

e

1

*

Node

«extends»

NodeAssemblyUsage

InformationExchange

targ

et

1

*

so

urc

e

1

*

cla

ss

1

*

typ

e

1

*

NOV-2 Stereotypes

«metaclass»

Package

1

ownedMember*

ArchitecturalDescription

NodeRelationshipDescription

ArchitecturalProduct

CompositeStructureModel«extends»

«extends»

owningArchitecture1

products*

«metaclass»

PackageableElement

«metaclass»

Dependency

«extends»

«extends»

«extends»

NodeConnector«metaclass»

Connector

«metaclass»

ConnectorEnd

«extends»

1

2

NodeConnectorEnd

«extends»

su

pp

ortin

gN

ee

dlin

es

Needline

NestedConnectorEnd

role

co

nn

ectio

nC

on

text

«metaclass»

StructuredClassifier1

ow

ne

dC

on

ne

cto

r

*

1e

nd

*

rea

lizin

gC

on

ne

cto

r

«metaclass»

Activity

«extends»

OperationalActivity

NodeHasBehavior

co

nd

ucte

dA

t

1

*

activityConducted

1

*

«metaclass»

NamedElement

supplier

1..*

*

client

1..*

*

NAF Metamodel

CASSIDIAN Lesson’s learnt on SAM

Semi-automatic procedure including two stages

MDWorkbench automatic on the full modelling DataBase (100% Data/90% Diagrams)

Some manual modification on geometry and layout of elements

Inputs

Mapping of objects sometimes tricky between SA and MEGA Common work on

Specification Document

Outputs

Quick translation : one week workload on 150 views / 1500 modelling items

○ Some manual fixes

Mainly due to IDEF0 notation origin use in OV05 DoDAF Views, artefacts items to be

corrected

Geometry cf. manual work

Hidden objects Board side effect still to be fixed

Much quicker than modelling from scratch

No lost or wrong migration of modelling objects and diagrams

Cassidian Findings

Was this development successful?

○ Yes, it provides a real benefit for CASSIDIAN, compared to re-modelling

Is the connector bidirectional

○ Yes, the reverse translation (from MEGA to SA) has been tested. It also requires manual re-drawing

What are the possible extensions on the connector:

○ The success of this first attempt has opened the way to NAF model transformation between various tools. As a new feature expected,

integration of Enterprise Architect © would be of interest.

FAQs How do I validate import/export ?

We are able to generate “exchange” reports comparing for each view number of elements between source and target

tools (including type and name sorting)

How diagrams are managed ?

Using common diagram interchange properties, MDWorkbench connectors create diagrams using authoring tool client

apis (MEGA/SA) or native formats of modeler : Position, Size, Color, Font, Visibility are handled.

Is there any limitation ?

According authoring tools, some concepts are missing . In such case, bridge documentation lists unsupported elements

between tools. These differences come from proprietary extensions and not really from AF itself (e.g: capability to mix

NAF + BPMN + UML + Custom xxx in the same tool) – This could be handled by introducing model checking rules earlier

in the design tasks.

Some diagrams are totally different (e.g. Custom Shape vs. Unmodifiable Rectangle Figure, 3D layout vs. 2D layout, IDEF

vs. Activity Diagram, Table vs. Tree views) – In this case 100% of data and diagrams figures is converted but diagrams’

layout has to be manually modified. We work to improve this special cases by improving custom optional “properties” on

writers or layout algorithms.

Introduction

Who is SODIUS?

Collaboration with CASSIDIAN (EADS D&S) since 2009

Enterprise Architecture Framework Interchange Solution Definition

Application and Feedback on a EA tool migration project

IPSE project and System Engineering collaborative software perspectives

Model driven architecture for supporting systems engineering at Cassidian

Agenda

Introduction

The problem:

LSI Projects are more and more complex

High cost / High risk projects

Long life cycle projects

Lot of actors (engineers, suppliers…)

Rapidly changing requirements

The need:

an integrated environment of system engineering

tools throughout the LSI product life cycle:

○ Requirement management

○ Architecture design

○ Change management

○ Integration & Validation

The system engineering spiral

Requirements

Management

Operational and

System Rules Model

engineering

Business Process &

System Evaluation

Requirement refinement

requirement update from

the prototyping experience

Architecture design.

Operational and System Rules

elements will be linked to

requirements

V & V in simulation.

Business Process & System

elements prototyping

Requirements

Management

Operational and System

Rules Model engineering

Business

Process &

System

Evaluation

Traceability & consistency

Stakeholder

Req.

System

Req.

Technical

Req.

DB

Organic View

System View

Operational View

requirementtraceability

requirementtraceability

Stakeholder

Req.

System

Req.

Technical

Req.

The IPSE Added Value – SE Collaboration

IPSE (Integrated Project Support Environment) is a collaborative software environment for system

engineering from Requirement Engineering, Behaviour & Architecture Modelling, Validation through

Process Simulation, Verification with Systems Simulation to Data Management.

Info traceability (from reqsto delivery) + SoS

maintenance

Data re-use (business objects & logic) to avoid re-inventing the wheel

Info flow control (powerful workflow centric approach)

Data coherency maintenance (link project & BMS F1)

System Engineering life-cycle collaboration (shared

repository)SAM

Bordershield IPSE

Connectors

The IPSE framework

Requirements Engineering

DOORS

SoS Architecture Design

SA

Process Simulation

Product development

PLM

Project Management

Configuration Management

SoSArchitecture

DesignMEGA

SoS Architecture

DesignEA

Connector Backbone

MDWorkbench

SODIUS IPSE Components

SODIUS is developing CASSIDIAN integration and automation tooling

for the IPSE framework

MDWorkbench Authoring tool to configuration management client application

MDWorkbench Model Artifacts Web Viewer

Configuration Management Web Server

MEGA CLIENT MDWorkbench DOORS CLIENT

Web services

Configuration Management Web Server

MDWorkbench

Web Client

HTTP

SODIUS IPSE Components

MDWorkbench “Interface Layer” RCP Eclipse Application

Ensuring communication between configuration management and

authoring tools (user workspace or baseline restore,

checkin/checkout operations)

Configuration

ManagementAuthoring Tools

MDWorkbench

“Interface Layer”

M

E

G

A D

O

O

R

S

SODIUS IPSE Components

DB

MDWorkbench

Interface Layer

Authoring Tools

Configuration

Management

Specify, Design, Produce

Requirement/Architecture

MDWorkbench Web Viewer

Inspect/Review

Architecture &

Produce Change

Request

Exported Model “Unit”

Authoring

ModelCheckin

Questions

Contact

http://www.mdworkbench.com

Paris

1 Rue André Gide

75015 Paris

France

Tel. : +33 (0)1 43 21 16 12

Fax : +33 (0)2.28.23.60.57

Nantes

2 impasse Joseph Marie Fourage

44300 NANTES

France

Tel. : +33 (0)2.28.23.60.60

Fax : +33 (0)2.28.23.60.57

Yann LEBEAUPIN – SODIUS – CTO – ylebeaupin@sodius.com