1. }
SODIUS / EADS CASSIDIAN
MD DAY 2010
MODEL DRIVEN ARCHITECTURE FOR SUPPORTING SYSTEMS ENGINEERING AT CASSIDIAN
25 November 2010
Yann LEBEAUPIN – SODIUS – CTO
Jean-Baptiste CARTIER – EADS CASSIDIAN - PLM Technical Expert

2. 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

3. 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)

4. Model Integration and Tools Interoperability Projects
Who is Sodius ?
Based on a common Moded-Based approach and
MDWorkbench technology platform and assets

5. 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

6.  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

7. 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
DBMS
TOOL A
DBMS
TOOL B
DBMS
TOOL 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

8. 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

9. 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

10. 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”

11. 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

12. 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
MM
DI Profile
NAF MM Assets
(Tool Agnostic Pivot)
Conforms To
DBMS1
TOOL 1
TOOL1
Metamodel
TOOL2
Metamodel
DBMS2
TOOL 2
Model 1
Model 2
Interoperability Rules
RulesRules
DI
UML2
Models
Rules
NMM
UML2
Models
MDWorkbench
Connector Connector

13. 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
Rules
TOOL1
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

14. 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

15. Diagram Support
“Tool-Agnostic” Viewers of
NAF Models
DI Model
Connectors use diagramming apis or proprietary
formats serializers to re-create diagrams into
authoring tools from neutral DI definitions

16. 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
whole
1
*
part
1
*
target
1
*
source
1
*
Node
«extends»
NodeAssemblyUsage
InformationExchange
target
1
*
source
1
*
class
1
*
type
1
*
NOV-2 Stereotypes
«metaclass»
Package
1
ownedMember
*
ArchitecturalDescription
NodeRelationshipDescription
ArchitecturalProduct
CompositeStructureModel«extends»
«extends»
owningArchitecture
1
products
*
«metaclass»
PackageableElement
«metaclass»
Dependency
«extends»
«extends»
«extends»
NodeConnector
«metaclass»
Connector
«metaclass»
ConnectorEnd
«extends»
12
NodeConnectorEnd
«extends»
supportingNeedlines
Needline
NestedConnectorEnd
role
connectionContext
«metaclass»
StructuredClassifier
1
ownedConnector
*
1
end
*
realizingConnector
«metaclass»
Activity
«extends»
OperationalActivity
NodeHasBehavior
conductedAt
1
*
activityConducted
1
*
«metaclass»
NamedElement
supplier
1..*
*
client
1..*
*
NAF Metamodel

17. 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

18. 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.

19.  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

20. 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

21. 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

22. 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
requirement
traceability
requirement
traceability
Stakeholder
Req.
System
Req.
Technical
Req.

23. 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 reqs
to 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

24. The IPSE framework
Requirements
Engineering
DOORS
SoS Architecture
Design
SA
Process
Simulation
Product development
PLM
Project
Management
Configuration
Management
SoS
Architecture
Design
MEGA
SoS
Architecture
Design
EA
Connector
Backbone
MDWorkbench

25. 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

26. 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
Management
Authoring Tools
MDWorkbench
“Interface Layer”
M
E
G
A D
O
O
R
S

27. 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

28. Questions

29. 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