A common meta-model for the interoperation of tools with heterogeneous data models ECMFA 2010 Third Workshop on Model-Driven Tool & Process Integration Andreas Baumgart

Motivation Embedded system development processes with various tools and different meta-models Cover requirements and models at different abstraction levels and with different viewpoints during process Meta-model transformations expensive when required between various meta-models Giant meta-model covering all specific artefacts difficult to handle Common meta-model provides common understanding of model artefacts and traceability Currently developped in european research project CESAR

Related Work SysML (OMG, UML based unification of standards for systems engineers) Structural modeling with blocks, properties, connectors, data types, physical units, dimensions Behavioral descriptions in terms of activity diagrams and state machines Requirements descriptions, use cases, trace links and test cases HRC (SPEEDS) Generic and formal description of hierarchical components with connectors, ports, port specifications and data types State Machines, Expression Language, Action Language (C like) Contracts with assumption / promise pairs on components and viewpoints EAST-ADL (ATESST, Automotive Domain Specific Language) Hierarchical modelling at different abstraction levels, features, functional and hardware models, connectors, flow / client-server / hardware ports, variability External nominal behavior, error behavior, timing descriptions Textual requirements, trace links, verification and validation

Concepts and artefacts of a common meta-model Heterogeneous Components hierarchical, reuse, connectors, ports, port specifications, data flows, services, data types, behavior Requirements, models and verification / validation along development process requirements, levels of abstraction / formalization, traceability, viewpoints (safety, realtime, …), fault models, product lines, test cases

Identication of concepts in different meta-models ArtifactReferenceEAST-ADL 2Reference ComponentPart typed by Component ADLFunctionType ADLFunctionPrototype.type [1] PartComponent has Parts ADLFunctionPrototype ADLFunctionType.part [*] PortsComponent has Data Ports ADL[In|Out]FlowPort ADLFunctionType.flowPort [*] Component has Service Interface ADL[Client|Server]Port ADLFunctionType.clientServerPort [*] Service ConnectorInterfaces connected ADLConnectorPrototype.[flow, clientServer]Port [*] BehaviourComponent has Behaviour ADL[Native, External]Behavior ADLFunctionType.behavior [0..1] Data TypePort is typedADLDesignDataType ADLFlowPort.type [1]

Tool interoperation using the common meta-model Common understanding of model artefacts Mapping needed Exchange format Native format (i.e. for analysis) Common interface Identify foreign model artefacts Provide traceability between heterogeneous model elements Provide model with elements coming from different models Further trace model can provide linkage to original model elements Get language specific information from original model

Modelling and analyzing a hybrid engine controller EAST-ADL (Papyrus) Automotive model HRC (A/P-Editor) Common model HRC (Dominance analysis) Model with contracts ModelBus Model driven tool integration framework Plugged Papyrus, A/P-Editor, Dominance Analysis Service Plugged model transformation service (QVT, EAST-ADL  HRC) Model repository Common meta-model provides common interface to requirements and structure Scenario

A common-meta-model for the interoperation of tools with heterogeneous data-models No combination of all elements of different data-models Provides common concepts Hierarchical components with data flows and behaviour Requirements, traceability, abstraction levels, verification / validation, product lines … (to be identified) Mapping between data-models and common-meta-model required Provide common view / interface for a heterogeneous set of model artefacts Conclusion