• Like

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Sodius cassidian mdday2010

  • 809 views
Uploaded on

 

More in: Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
809
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
45
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. } 25 November 2010SODIUS / EADS CASSIDIANMD DAY 2010MODEL DRIVEN ARCHITECTURE FOR SUPPORTING SYSTEMS ENGINEERING AT CASSIDIANYann LEBEAUPIN – SODIUS – CTOJean-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. Who is Sodius ?Model Integration and Tools Interoperability Projects 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. Agenda 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
  • 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 TOOL B DBMS DBMS TOOL A ? Accept the diversity ! DBMS TOOL C 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 contextBorderShield Project Legacy3 Tools currently used on the BorderShield project in DoDAF context 1 Models initially created and used on German DoDAF CASSIDIAN MEGA 2009 3 project, then on BorderShield Recommended by our business Unit Change authoring ? How migrate models and diagrams ? 2
  • 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 The SAM project had to consider architecture for too the underlying movement to  Exchanging models and diagrams NAF (NATO Architecture Framework) in the domain of  Between MEGA and System Architect complex systems of systems  Considering future extensibility needs (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” NAF DoDAFOne 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) !
  • 11. Proposed SolutionDirect 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 theintegration platform 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
  • 12. Architecture of the NAF solutionSODIUS has built a NMM 1.0 pivot-based solution, including support of diagrams using connectors toimport/export native “RAW” data from applications and NMM UML models to store intermediate data. UML2 NMM NAF MM Assets DI Profile MM Profile (Tool Agnostic Pivot) MDWorkbench Conforms To Interoperability Rules NMM UML2 Models DI Model 1 UML2 Model 2 Models TOOL 1 TOOL 2 TOOL2 TOOL1 Rules Rules Rules Metamodel MetamodelDBMS1 DBMS2 Connector Connector 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).
  • 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 Connectors are  Capacity of SODIUS to create new connectors quickly (using any text or xml able to manage formats, apis, web-services or database access) many kind of formats Connector = Model 1 MM + Reader + Writer TOOL 1 TOOL1 DBMS1 Metamodel Rules Benefit of the approach: Rules manage specific exchange process, connectors are reusable assets encapsulating complexity of connection with tools.
  • 14. Diagram Support SODIUS is involved in the XMI Interchange Workgroup NAF MM Assets 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 NMM pragmatic way Profile Based on DI format, connectors use diagramming apis or proprietary formats of tools to re-create diagrams from neutral DI defintions UML2 To manage diagrams in the closest way that target authoring environment allow it, some layout DI Profile MM 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 Model “XMI” DI File Semantic Data DI Metamodel
  • 15. Diagram Support DI Model “Tool-Agnostic” Viewers of NAF ModelsConnectors use diagramming apis or proprietaryformats serializers to re-create diagrams intoauthoring tools from neutral DI definitions
  • 16. Samples of managed viewsSystemArchitect UML Base Classes NOV-2 Stereotypes «extends» «metaclass» ArchitecturalDescription Package owningArchitecture 1 1 ownedMember products * * «metaclass» ArchitecturalProduct PackageableElement 1 «extends» CompositeStructureModel «metaclass» StructuredClassifier NodeRelationshipDescription «extends» «metaclass» 1 Node conductedAt Class whole 1 part 1 class type 1 1 * * * * «extends» role «metaclass» NodeAssemblyUsage connectionContext Property 1 source 1 target 1 source 1 target * * * * «extends» «metaclass» InformationExchange InformationFlow «extends» «metaclass» NestedConnectorEnd ConnectorEnd supportingNeedlines * end NodeConnectorEnd realizingConnector 2 ownedConnector Needline 1 «extends» «metaclass» 1 * NodeConnector Connector «extends» activityConducted «metaclass» 1 OperationalActivity Activity «extends» «metaclass» NodeHasBehavior * Dependency * «metaclass» NamedElement * * 1..* client 1..* supplier NAF MetamodelMEGA Diagrams and Data can be exchanged between tools (each time view concepts are supported by the authoring tool)
  • 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. 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.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.
  • 19. Agenda 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
  • 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 ManagementRequirement refinement Architecture design. requirement update from Operational and System Rulesthe prototyping experience elements will be linked to requirements Operational and Business Process & System Rules Model System Evaluation engineering V & V in simulation. Business Process & System elements prototyping
  • 22. Traceability & consistency requirement traceability Requirements Management Stakeholder Req. System Req. Technical Req. DB Business Operational and System Process & Rules Model engineering System Evaluation Operational ViewStakeholder Req. System View System Req.Technical Organic View Req. requirement traceability
  • 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. Data re-use (business System Engineering life-cycleSAM objects & logic) to avoid collaboration (shared re-inventing the wheel repository)Bordershield IPSE Connectors Info flow control Data coherency (powerful workflow maintenance (link centric approach) project & BMS F1) Info traceability (from reqs to delivery) + SoS maintenance
  • 24. The IPSE framework Product development Configuration Project Management Management Connector Backbone MDWorkbench PLMRequirements Process Engineering Simulation DOORS SoS SoS Architecture Architecture Design Design MEGA EA SoS Architecture Design SA
  • 25. SODIUS IPSE Components SODIUS is developing CASSIDIAN integration and automation tooling for the IPSE framework  MDWorkbench Authoring tool to configuration management client application Configuration Management Web Server Web services MEGA CLIENT MDWorkbench DOORS CLIENT  MDWorkbench Model Artifacts Web Viewer Configuration Management Web Server Web Client HTTP MDWorkbench
  • 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) M E G A D O O RConfiguration SManagement Authoring Tools MDWorkbench “Interface Layer”
  • 27. SODIUS IPSE Components Authoring Tools MDWorkbench Exported Model “Unit” Interface Layer Authoring Checkin Model Specify, Design, Produce DB Requirement/Architecture Configuration Management MDWorkbench Web Viewer Inspect/Review Architecture &Produce Change Request
  • 28. Questions
  • 29. Contact Yann LEBEAUPIN – SODIUS – CTO – ylebeaupin@sodius.com Paris Nantes 1 Rue André Gide 2 impasse Joseph Marie Fourage 75015 Paris 44300 NANTES France France Tel. : +33 (0)1 43 21 16 12 Tel. : +33 (0)2.28.23.60.60 Fax : +33 (0)2.28.23.60.57 Fax : +33 (0)2.28.23.60.57 http://www.mdworkbench.com