MODEL DRIVEN ARCHITECTURE FOR SUPPORTING SYSTEMS ENGINEERING

1. } SODIUS / EADS CASSIDIANMD DAY 2010MODEL DRIVEN ARCHITECTURE FOR SUPPORTING SYSTEMS ENGINEERING AT CASSIDIAN
25 November2010
Yann LEBEAUPIN –SODIUS –CTO
Jean-Baptiste CARTIER –EADS CASSIDIAN -PLM TechnicalExpert

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. WhoisSodius?
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.
SODIUSprovides 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 Integrationand Tools InteroperabilityProjectsWhoisSodius?
Based on a common Moded-Based approach and MDWorkbenchtechnology 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 (IntegratedProject Support Environnement) whichgoal isto providea suite of toolsfor System Engineering. First phase of project Communication between tools for data and diagram exchangeSecond 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 CassidianAgenda

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 ADBMS
TOOL 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

8. CASSIDIAN Project context BorderShieldProject Legacy 3 Tools currently used on the BorderShieldproject in DoDAFcontext2
DoDAF
Models initially created and used on German CASSIDIAN project, then on BorderShield
1
Change authoring ?
How migrate models anddiagrams ? MEGA 2009Recommended by our business Unit
3

9. Drivers for Change
Facts on the Bordershieldproject
Initial choice : SA as common language –legacy models
Collateral architecture team shift from SA to EA
BordershieldTechnical 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
DoDAFSV3 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
DoDAFOne thingthatissure: Actors, Tools, Process,Standards(DoDAF, NAF, UPDM, etc…) WILL CHANGE The challenge isto integratearchitectures in 2010 (t) AND maintainthiscapabilityin 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 diagramsas the diagram types for NAF
NMM is defined as a abstract UML profile using underlying UML concepts
Ensure application connectivity maintenabilityDirect 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 ProfileUML2MMDI ProfileNAF MM Assets(Tool Agnostic Pivot) Conforms To
DBMS1TOOL 1TOOL1Metamodel
TOOL2
MetamodelDBMS2TOOL 2
Model 1
Model 2
Interoperability RulesRulesRulesDIUML2 ModelsRulesNMM UML2 Models
MDWorkbenchConnector
Connector

13. Interoperability approach
SODIUS’ interoperability approach is based on MDWorkbenchplatform:
Separated approach between the data (I/O) and the required transformation : Connectors + MMs + Rules
Metamodelsto 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
MetamodelModel 1Benefit of the approach: Rules manage specific exchange process, connectors are reusable assets encapsulating complexity of connection with tools. Connector = MM + Reader + WriterConnectors 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 apisor 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
MMNAF MM Assets“XMI” DI File
DI Model
Semantic Data
DI Metamodel

15. Diagram Support“Tool-Agnostic” Viewers of NAF ModelsDI ModelConnectors 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
«extends» CompositeStructureModel
«extends»
owningArchitecture
1
products
*
«metaclass»
PackageableElement
«metaclass»
Dependency
«extends»
«extends»
«extends»
NodeConnector
«metaclass»
Connector
«metaclass»
ConnectorEnd
«extends»
1
2
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
MDWorkbenchautomatic 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 DoDAFViews, 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. CassidianFindings
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, MDWorkbenchconnectors 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. UnmodifiableRectangle 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 CassidianAgenda

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 engineeringBusiness Process & System EvaluationTraceability & consistencyStakeholderReq. SystemReq. TechnicalReq. DBOrganic ViewSystem View
Operational View
requirement
traceabilityrequirementtraceabilityStakeholderReq.
SystemReq.
TechnicalReq.

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 reqsto delivery) + SoSmaintenanceData re-use(business objects & logic) to avoid re-inventing the wheelInfo 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 frameworkRequirements EngineeringDOORSSoS Architecture DesignSA
Process Simulation
Product development
PLM
Project ManagementConfiguration ManagementSoSArchitecture DesignMEGASoS Architecture DesignEAConnector BackboneMDWorkbench

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 ViewerConfiguration Management Web ServerMEGA CLIENTMDWorkbench DOORS CLIENT
Web services
Configuration Management Web Server
MDWorkbench
Web ClientHTTP

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) ConfigurationManagementAuthoring ToolsMDWorkbench“Interface Layer” MEGADOORS

27. SODIUS IPSE ComponentsDB
MDWorkbenchInterface Layer
Authoring Tools
Configuration
Management
Specify, Design, Produce
Requirement/ArchitectureMDWorkbenchWeb ViewerInspect/ReviewArchitecture & ProduceChange RequestExported Model “Unit” AuthoringModelCheckin

28. Questions

29. Contacthttp://www.mdworkbench.comParis 1 Rue André Gide75015 ParisFranceTel. : +33 (0)1 43 21 16 12 Fax : +33 (0)2.28.23.60.57
Nantes
2 impasse Joseph Marie Fourage44300 NANTESFranceTel. : +33 (0)2.28.23.60.60Fax : +33 (0)2.28.23.60.57
Yann LEBEAUPIN –SODIUS –CTO –ylebeaupin@sodius.com