A common meta-model for the interoperation oftools with heterogeneous data models

ECMFA 2010

Third Workshop on Model-Driven Tool & Process Integration

2010-06-16

Andreas Baumgart

2

11.06.10

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

3

11.06.10

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

4

11.06.10

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

5

11.06.10

Identication of concepts in different meta-models

Artifact Reference EAST-ADL 2 Reference

Component Part typed by Component

ADLFunctionType ADLFunctionPrototype.type [1]

Part Component has Parts

ADLFunctionPrototype ADLFunctionType.part [*]

Ports Component has Data Ports

ADL[In|Out]FlowPort ADLFunctionType.flowPort [*]

Component has Service Interface

ADL[Client|Server]Port ADLFunctionType.clientServerPort [*]Service

Connector Interfaces connected

ADLConnectorPrototype ADLConnectorPrototype.[flow, clientServer]Port [*]

Behaviour Component has Behaviour

ADL[Native, External]Behavior

ADLFunctionType.behavior [0..1]

Data Type Port is typed ADLDesignDataType ADLFlowPort.type [1]

6

11.06.10

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

7

11.06.10

• 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

8

11.06.10

• 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