A Recipe for Tool Interoperability

Andreas Baumgart and Christian Ellen

OFFIS, Escherweg 2, 26121 Oldenburg, Germany

Keywords:

RTP, Tool Interoperability, Tool Integration, Tool Adapter, OSLC, IOS, Meta-Model.

Abstract:

Typical engineering and veriﬁcation workﬂows for safety-relevant systems are performed with many different

tools. For such workﬂows safety standards like the automotive ISO 26262 require traceability of all V&V-

related work products. Therefore, efﬁcient tool-integration, while ensuring all traceability needs for functional

safety, is a highly relevant topic for industrial domains. Recent research projects like CESAR have addressed

this topic by reusing tools and methods for different workﬂows in the context of requirements and systems en-

gineering as well as veriﬁcation and validation. This reuse is done in a Reference Technology Platform (RTP)

with common services and a common understanding of exchanged information based on an Interoperability

Speciﬁcation (IOS). Recently, OSLC is discussed for such an IOS. The open question is how tools are con-

nected efﬁciently and how traceability is ensured. This document provides a guideline on how to use the IOS

for engineering workﬂows performed with different tools based on OSLC. We call it recipe. The recipe was

developed in the MBAT project. It considers a systematic deﬁnition of semantic concepts for an IOS ensuring

traceability and the level of granularity required to perform workﬂows with a set of tools.

1 INTRODUCTION

Workﬂows related to different engineering disciplines

like requirement deﬁnition, system design, analysis,

and testing are typically performed with several dis-

tributed tools. These workﬂows have to comply with

standards like the automotive ISO 26262 (ISO, 2011)

for functional safety which e.g. requires traceability

of engineering information. Yet, this engineering in-

formation is normally very heterogeneous with regard

to the tools and their interfaces. Lately, Open Ser-

vices for Lifecycle Collaboration (OSLC) has become

a promising approach for tool interoperability (OSLC

Community, 2013). It can be used as a foundation

for an Interoperability Speciﬁcation (IOS) that en-

ables communication between tools to support engi-

neering lifecycle workﬂows in a Reference Technol-

ogy Platform (RTP). Typical engineering disciplines

like architecture management or requirements man-

agement are addressed by the semantic concepts of

OSLC. Yet, they are quite generic and do not reﬂect

workﬂows that shall actually be implemented in an

RTP. Therefore, the semantic concepts of OSLC must

be extended when implementing workﬂows with in-

teroperating tools.

This publication addresses a practical problem of

developers responsible for tool integration. They typ-

ically have to create or modify tool adapters to sup-

port workﬂows and need to comply with existing pro-

cesses and standards. Tool integration effort is a

highly relevant cost factor for industrial projects. Cre-

ation and extension of many point-to-point connec-

tions is very expensive and complicates traceability

required by standards. A logical consequence is the

reduction of interfaces. It is possible to reduce the set

of interfaces to one big meta-model covering the data

models of all tools. Yet, with this approach common-

alities are not shared and traceability is not necessar-

ily enabled. The level of granularity required for the

interfaces and a useful modularization of exchanged

information elements is therefore crucial. An efﬁcient

solution for tool interoperability is tailorable to differ-

ent workﬂows, implemented with different tools, and

supports traceability.

Our contribution is a development guideline in the

form of a recipe. It allows systematic deﬁnition of the

semantic concepts for an interoperability speciﬁcation

and takes into account the implementation of work-

ﬂows with different tools. The guideline considers

the usage of agreed semantic concepts from existing

meta-models and standards. With this approach a ho-

mogeneous view on the tools is established in which

all information is fully traceable at the right level of

granularity required for the workﬂows.

300

Baumgart A. and Ellen C..

A Recipe for Tool Interoperability.

DOI: 10.5220/0004702203000308

In Proceedings of the 2nd International Conference on Model-Driven Engineering and Software Development (MODELSWARD-2014), pages 300-308

ISBN: 978-989-758-007-9

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

This document is structured as follows. Subse-

quent to this introduction we describe the basic prin-

ciples needed for the proposed guideline and discuss

the related work. In our main section we deﬁne the

guideline, which we call “recipe”. Finally, we evalu-

ate the manual application of the recipe for a typical

engineering scenario and ﬁnish with our conclusion.

2 BASICS

The guideline for tool interoperability, that we pro-

pose as a recipe, considers some basic concepts which

will be explained in this section. The ﬁrst is an Inter-

operability Speciﬁcation (IOS) whose semantic con-

cepts are deﬁned with regard to tools and workﬂows.

The other basic concept is a Reference Technology

Platform (RTP) with multiple logical layers address-

ing workﬂows, tools, and interoperability.

2.1 Interoperability Speciﬁcation

The purpose of the IOS is to provide basic technical,

syntactical, and semantical principles for interoper-

ability between tools. Together with implementation

guidelines, tools can be easily integrated to achieve

speciﬁc workﬂows. The proposed recipe builds upon

the systematic deﬁnition of the semantic concepts as

a reﬁnement of OSLC speciﬁcations by using meta-

models:

OSLC is an open community project aiming to ease

integration of tools with other tools. The approach

builds upon ubiquitously established internet and

linked-data standards like HTTP, RDF/XML, REST-

ful services, as well as open and extendible minimal-

istic data speciﬁcations. RDF/XML provides com-

mon syntax for data resources using a triplet struc-

ture that gives them the form subject-predicate-object.

Resource type speciﬁcations contain deﬁnitions of

such resources, their semantics, links to other re-

sources, and simple properties. They are deﬁned

based on OSLC core principles like resources and

properties allowing their usage for OSLC-based ser-

vice deﬁnitions. Common namespaces such as RDFS

(W3C, 2004), FOAF (Brickley and Miller, 2010) or

DC (Dublin Core Metadata Initiative, 2012) are used

for standardized communication of resource proper-

ties. OSLC resource types are modular with regard

to domains like Requirements Management or Archi-

tecture Management that reﬂect different engineering

disciplines. Yet, for typical workﬂows these resource

types need to be extended for which we propose the

usage of meta-models.

Meta-Models consist of concepts, relationships, and

properties with deﬁned semantics. They allow ex-

pressing parameters and results of methods used for

workﬂows. The meta-model concepts are abstractions

from domain-speciﬁc work products and from tool-

speciﬁc data elements. As such they are usable to de-

ﬁne interfaces for tools and services that support the

methods. These interfaces can be reused with other

tools that comply with the needed concepts from the

meta-model. For instance methods for requirements

can be performed with tools that can handle require-

ments.

The set of meta-model concepts and relationships

required in an RTP depends on the workﬂows and

methods that shall be supported. For their support

tool-speciﬁc data models must be mappable to these

meta-model concepts and relationships. Since tools

and workﬂows can vary the meta-model is no static

structure but is ﬂexible with regard to the usage sce-

nario. Therefore, deﬁning one big meta-model cov-

ering all considerable concepts does not help to spec-

ify needed tool interfaces. The meta-model should be

minimalistic with regard to the information exposed

or required by the tools to support the workﬂows

and allowing traceability of exchanged information.

Yet, the usage of widely agreed concepts from ex-

isting standards like UML/SysML (OMG, 2010) and

EAST-ADL (EAST-ADL Association, 2013) as well

as project results like HRC (SPEEDS Project, 2009),

the SPES 2020 methodology (Pohl et al., 2012), or the

meta-model of the CESAR project (Rajan and Wahl,

2013) for the names of the concepts is highly recom-

mended.

Meta-model concepts and methods are typically

related to engineering disciplines like Requirements

Management or Architecture Management. There-

fore, the meta-model concepts can be associated with

respective modules like the resource types in OSLC.

Such a modular meta-model providing common con-

cepts with the scope of analysis and testing methods

is in development in MBAT (MBAT Project, 2013).

2.2 Reference Technology Platform

A Reference Technology Platform (RTP) is a collec-

tion of tools and services that can interact with each

other to support speciﬁc engineering scenarios and

workﬂows. The RTP includes common principles for

tool interoperability and can therefore be regarded at

three different logical layers (Vasaiely et al., 2012).

These layers are workﬂow layer, tool layer, and IOS

layer. They are depicted in Figure 1 illustrating a

small RTP example for which the proposed recipe has

been applied.

ARecipeforToolInteroperability

301

Meta-Model

Tools

Engineering Models

Workflows

Work Products

IOS

Resource Types

Requirement Architecture

DOORS

ID Description Allocation

R1 always x<3 F1

HTTP RDF OSLC

ios_rm:

Requirement

ios_tm:

SatisfyLink

Component

Satisfy Link

Requirement

ios_am:

Component

„Allocate requirement

to architecture“

Architecture

Management

Traceability

Management

Requirements

Management

satisfiedBy

satisfies

Papyrus

Figure 1: IOS and Meta-Model.

Workﬂows and Work Products: On the ﬁrst RTP

layer activities and work products of domain-speciﬁc

but tool-independent workﬂows and methods are

described. The work products are part of pre- and

post-conditions of the activities. In Figure 1 the

typical engineering workﬂow “Allocate requirement

to architecture” is shown as an example. It is

described within all systems engineering standards

(e.g. the ISO 26262) and requires traceability of

architectures and allocated requirements. The pre-

conditon of the workﬂow is a deﬁned requirement.

The example workﬂow could consist of activities

like “deﬁne architecture” and “allocate requirement”.

Post-condition is that the requirement is allocated to

an architecture.

Tools and Engineering Models: On the second

layer different tools and services are considered

which shall be used to perform the activities of

the workﬂow layer. Work products are mapped to

elements native to the data models of the tools and

services – we will call them engineering models. In

the depicted example the activities are mapped to the

UML modeling tool Papyrus with an EAST-ADL

proﬁle and to the requirements management tool IBM

Rational DOORS. An architecture as work product

is represented by an EAST-ADL model in Papyrus.

Requirements are stored in DOORS together with the

allocation information.

IOS and Resource Types: The third layer addresses

the IOS and provides basic technical, syntactical, and

semantical principles for the interoperability of tools.

For the semantics of communicated data elements the

IOS layer includes resource types. These resource

types are speciﬁcations of concepts, relationships, and

properties. They reﬂect a meta-model with concepts

and relationships needed for interoperability between

the tools to achieve the workﬂows.

The meta-model concepts used for the IOS are an

abstraction of data elements that shall be communi-

cated between the tools. This abstraction allows a

common understanding and traceability of informa-

tion shared among the tools by establishing a ho-

mogeneous view. In this view methods required for

workﬂows can be performed on different tools that re-

late to the same meta-model concepts. All engineer-

ing information in this homogeneous view is traceable

with regard to the traceability concepts of the meta-

model.

As mentioned in Section 2.1 the meta-model con-

cepts can typically be modularized with regard to spe-

ciﬁc engineering disciplines like requirements man-

agement or architecture management. Such modules

reﬂect the role of the tools and their data elements

in a workﬂow. In the illustrated example the meta-

model concepts Requirement, Satisfy Link, and

Component are identiﬁed from the requirement al-

location workﬂow that is mapped on DOORS and

Papyrus. A Requirement is a concept from Re-

quirements Management expressing a speciﬁc need.

A Component is a concept from Architecture Man-

agement expressing a reusable architectural element

that has deﬁned interfaces, which can be decomposed

and which can have an implemented behavior. The

Satisfy Link is a Traceability Management concept

having the semantics that the Component shall sat-

isfy the Requirement. It enables traceability required

for the allocation of requirements to architectures

given by component models. On the IOS layer the

corresponding resource types ios rm:Requirement,

ios tm:SatisfyLink, and ios am:Component are

deﬁned all representing the respective meta-model

concepts and modules.

3 RELATED WORK

In this section related work done in research projects

is discussed and used to motivate our approach.

The topic of tool interoperability has been discussed

in many research projects like CESAR or iFEST.

Several commercial platforms and freely available

frameworks support tool interoperability like Enovia

from Dassault Syst

emes, ModelBus from Fraunhofer

FOKUS, the ATHENA Interoperability Framework,

EIF or IADBC. Many recent approaches are related

to OSLC. On the commercial side OSLC is supported

by the Jazz platform from IBM.

Partners of the iFEST project (Zhang et al., 2012)

propose an artifact model and the usage of OSLC-

technologies for implementing adapters. They real-

ize interoperability between tools in contrast to our

solution directly by accessing tool APIs. The arti-

fact model allows an abstraction of tool-speciﬁc meta-

model elements as artifacts and considers trace-links

MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

302

between such artifacts in different tools. Yet, special-

izations of artifacts are tool-speciﬁc. Semantic com-

monalities for engineering disciplines or different en-

gineering domains are not considered for the model.

The approach allows light-weight tool integration and

traceability by using the generic artifact concept for

information exchange. It does not abstract from tool-

speciﬁc data to common meta-model concepts that

support the implemented workﬂows.

CESAR partners (Vasaiely et al., 2012) discuss

a common interoperability approach for heteroge-

neous tool environments. The approach consid-

ers an open interoperability speciﬁcation including

a service-oriented architecture, a common data for-

mat with deﬁned syntax like RDF and semantics as

well as common communication protocols like HTTP

and REST. These principles are those addressed by

OSLC. The approach considers an interoperability

speciﬁcation as part of a layered RTP as described in

section 2.2. Each layer has semantic concepts. It is

mentioned that those on the IOS layer can be based

on OSLC domain speciﬁcations but typically require

additional concepts and shaping with regard to higher

domain layers. Yet, it is neither deﬁned which con-

cepts should belong to this layer nor it is deﬁned how

the concepts are chosen to support speciﬁc engineer-

ing workﬂows.

In our prior work (Baumgart et al., 2012) we pro-

posed the usage of a meta-model as semantic model

to deﬁne common interfaces that support tool interop-

erability in an RTP. The meta-model was developed

in CESAR and addresses different topics of systems

engineering like requirements, component-based de-

sign or veriﬁcation and validation. The idea is that

the common interfaces establish a homogeneous view

on a heterogeneous set of tools that shall interact with

each other. Tools can be easily integrated into this

view as data-repositories by implementing the inter-

faces in tool-adapters. Other tools can be integrated

as clients and use the common interfaces for engi-

neering scenarios independently from those tools they

interact with. Yet, in this prior work we did not men-

tion how meta-model types are derived for the inter-

faces with regard to engineering workﬂows that shall

be supported.

In contrast to the approaches discussed above our

recipe addresses interoperability with OSLC by iden-

tifying and adapting semantic concepts based on ex-

isting models to enable a speciﬁc workﬂow on differ-

ent integrated tools.

4 THE RECIPE

Our recipe for tool interoperability targets a system-

atic implementation of an IOS ﬁtting the needs of

workﬂows and methods that shall be achieved with

different interoperating tools. Like a cooking recipe,

we describe the ingredients in terms of work products

and steps that need to be performed. These steps and

work products are depicted in Figure 2. The recipe

considers ﬁve steps which will be described in detail

in the following section together with the prerequi-

sites and the expected outcome.

Engineering Model Elements

Identify engineering model

elements exposed by tools

Engineering Model Elements

Scenario

mapped

on tools

Common Meta-Model Concepts

Define common meta-model

concepts

Common Meta-Model Concepts

OSLC Resource Types

Identify OSLC resource types

matching meta-model concepts

OSLC Resource Types

IOS Resource Types

Refine OSLC resource types

towards meta-model concepts

IOS Resource Types

Existing

Meta-Models

and

Standards

OSLC

resource type

specifications

IOS Implementation

Implement the resource types

Figure 2: The Recipe with its inputs, outputs, and steps.

4.1 Prerequisites

Before applying the recipe it is assumed that a work-

ﬂow or method with activities and work products is

deﬁned and mapped to involved tools. Therefore, it

is deﬁned which activities are performed with which

tools. In particular, it is also deﬁned how the work

products are represented by the tools and their engi-

neering models.

4.2 Identify Engineering Model

Elements exposed by Tools

In a ﬁrst step all relevant engineering model elements

are identiﬁed. Relevant elements are those provided

or consumed by the tools in order to perform the ac-

tivities that are mapped to the respective tools. The

step is done when all engineering model elements of

the tools are identiﬁed which represent work products

of the scenario activities. It is not necessary to look

deeper into further details of the engineering models

because all model elements, relationships, and prop-

erties needed to support the workﬂow or methods are

ARecipeforToolInteroperability

303

identiﬁed by now. The outcome of this step is a min-

imal set of engineering elements that is sufﬁcient to

implement the methods or scenarios with the tools.

4.3 Deﬁne Common Meta-Model

Concepts

In a second step a meta-model is deﬁned for the iden-

tiﬁed engineering model elements. The meta-model

is an abstraction of these elements and must be rich

enough to cover them. It shall on the one hand repre-

sent the commonalities of the engineering model ele-

ments and on the other hand represent their speciﬁcs

where needed. Generally the meta-model must cover

all traceability needs coming with the workﬂows to

be implemented with the tools and their engineering

models.

Granularity depends on the information needed

for the implementation of the workﬂows with the

tools. Therefore, the concepts of the meta-model can

be deﬁned in a granularity range between the full en-

gineering model and only abstract artifacts and re-

lationships. For example if single components have

to be assigned to an implemented behavior in a sim-

ple traceability scenario, the meta-model must only

provide abstract concepts for components, behavior,

and the implementation link between them. Yet, in a

more enhanced integration testing scenario the single

components have to be more detailed and are imple-

mented and interconnected via their ports with other

components to form a component architecture. In this

case also the information about the parts of the com-

ponent architecture, the ports, the implemented in-

terfaces and the interconnections is needed. The re-

quired level of abstraction can be even ﬁner and very

speciﬁc to an engineering model. A typical example

is a tool-speciﬁc formalism used to deﬁne the imple-

mented behavior.

The meta-model concepts should be deﬁned based

on already existing concepts. Many concepts, rela-

tionships, and properties are provided by standards or

project results as described in Section 2.1. Typically,

the exact scope of the workﬂow at hand varies, but

concepts can be reused and extended in a way that

the workﬂow is supported. Trace-links between el-

ements should be represented explicitly as elements.

This allows bidirectional relationships with additional

attributes, direct traceability of proof obligations, and

external storage of links for tools that do not support

additional relationships.

This step of the recipe is ﬁnished when the meta-

model is rich enough to cover every identiﬁed engi-

neering model element, relationship, and property. In

the end, every identiﬁed engineering object is mapped

to a corresponding concept, relationship, or property

in the meta-model. Therefore, it is ensured that the

meta-model can be used to express the work products

of the workﬂow and to implement it with the tools.

4.4 Identify Matching OSLC Resource

Types

In a third step, all concepts, relationships, and proper-

ties of the meta-model are mapped to OSLC resource

types. The OSLC project deﬁnes several domains for

typical engineering disciplines specifying resource

types with speciﬁc links and properties. Therefore,

the meta-model concepts are grouped with regard to

engineering domains and then they are mapped to re-

source types. The relationships and properties of the

meta-model concepts are mapped to existing links and

properties deﬁned by the OSLC resource types where

applicable. Examples of OSLC domains are the Re-

quirements Management (OSLC

RM) which deﬁnes the

basic requirement resource type and the Architecture

Management (OSLC AM) which deﬁnes abstract archi-

tecture resources and links.

If a meta-model concept cannot be mapped to a re-

source type of an existing OSLC engineering domain

then it has to be mapped to a Resource as deﬁned by

the OSLC Core.

The step is done when all meta-model concepts

are mapped to OSLC resource types and when all re-

lationships and properties of the meta-model concepts

are processed and mapped to links and properties of

the resource types where applicable.

4.5 Reﬁne OSLC Resource Types

towards Meta-Model Concepts

In a fourth step the OSLC resource types are re-

ﬁned. The purpose of this reﬁnement is to support the

level of granularity required for the workﬂows on IOS

level. This level of granularity is given by the iden-

tiﬁed meta-model concepts, relationships, and prop-

erties that are mapped to the OSLC resource types.

Therefore, OSLC resource types must be made fully

compliant to the concepts, relationships, and prop-

erties of the meta-model. Further type information,

properties, and links maybe needed. By adding them

to the OSLC resource types, reﬁned IOS resource

types are deﬁned that support the level of granularity

required for the workﬂows.

The reﬁnement of the resource types is done in

a systematic way. All mappings of meta-model con-

cepts to OSLC resource types are processed. If the

identiﬁed OSLC resource type is fully representing

the mapped meta-model concept with its properties

MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

304

and relationships then the step is done for that meta-

model concept. Typically, the corresponding OSLC

resource type is not fully sufﬁcient to represent the

meta-model concept. Thus, it has to be extended to-

wards the respective meta-model concept.

The extension of an OSLC resource type towards

a meta-model concept is also a systematic procedure.

The OSLC resource type is considered as a base type.

The meta-model concept must become visible as a

reﬁnement. This can be done by deﬁning an own

namespace and a URL for the identiﬁcation of the

meta-concept as resource type. This resource type

URL is simply added to the deﬁnition of the resource

type. Typically, the type of an OSLC resource is iden-

tiﬁed either by the URI of an RDF node or the value

provided with the rdf:type. Therefore, the addi-

tional resource type URL identifying the meta-model

concept is either one of a set of RDF types or it is the

identiﬁer of the RDF node. This can be formulated as

a constraint as part of the description of the resource

type.

As an example the meta-model concept of

a Component is deﬁned related to the Architec-

ture Management engineering domain. There-

fore, the concept of a Component is mapped to

the OSLC Architecture Management resource type

(AM) Resource as base type. In order to iden-

tify Component as extended resource type a URI is

deﬁned for that type which addresses the concept

and its namespace. In this example the namespace

is IOS AM and has a URI http://ios.artemis.

eu/am# with a deﬁned preﬁx ios am. Therefore, a

Component resource can be identiﬁed via the URI

http://ios.artemis.eu/am#Component or via the

shorter preﬁxed URI ios_am:Component. The

rdf:type is constrained in its description that it must

contain the URIs ios_am:Component and oslc\am:

Resource if not already addressed by the RDF node

identiﬁer. Thus, a Component resource is understood

as Component and as OSLC (AM) Resource.

For the extension of an OSLC resource type to-

wards a meta-model concept also the additional ref-

erences and properties of the meta-model concept

have to be made available. Therefore, for each

reference or property an OSLC link or property is

deﬁned extending the speciﬁcation of the resource

type. It is highly recommended to reuse links and

properties from existing namespaces in order to im-

prove compatibility and common understanding of

relationships and properties communicated via IOS.

A typical namespace used by OSLC is DC (Dublin

Core Metadata Initiative, 2012) which contains many

common properties and links like dcterms:title,

dcterms:description, or dcterms:identifier.

If existing links and properties cannot be reused

for a reference or property of a meta-model concept

then a new link or property has to be deﬁned accord-

ing to the OSLC core speciﬁcation guideline “Deﬁn-

ing OSLC Properties”: For the deﬁnition the link or

property requires a URI which typically consists of

a namespace part and an appended identiﬁer for the

property or link. Furthermore, a set of properties

needs to be deﬁned, e.g. the number of occurring val-

ues for a property (“Occurs”), the value-type or the

range of resource types allowed for linked resources.

As an example the meta-model concept

Component has a port reference. This port reference

cannot be mapped to an existing link or property.

Therefore the new link ios am:port is speciﬁed for

the namespace ios am and added to the speciﬁcation

of the resource type ios am:Component. The value

of the “Occurs” property is zero-or-many – a com-

ponent may have an arbitrary number of ports. The

value-type is Resource and the value of the Range

property is ios am:Port. Therefore, the value of

this link may only consist of ios am:Port resources.

The “Representation” property is set to “Either” so

a port may either be contained or referenced. The

“Read-only” property is considered false because

ports may be added. The link also has a description.

This step of the recipe is done when all resource

types are deﬁned in a way that they are fully sufﬁcient

to represent the corresponding meta-model concepts.

Result of this step is a set of reﬁned resource types

which we call IOS resource types.

4.6 Implement IOS Resource Types

In the ﬁnal step of the recipe the IOS resource types

are implemented. For that purpose technological prin-

ciples deﬁned by OSLC (OSLC Community, 2013)

for the IOS are applied (e.g. RDF and HTTP). Dif-

ferent ways are possible to implement resource types

together with OSLC-compliant communication. We

consider two possible implementations. One imple-

mentation is based on existing Java technologies like

the Eclipse Modeling Framework (EMF), the servlet-

engine, and HTTP-server Jetty from the Eclipse Foun-

dation, as well as the RDF-library and the serializer

Jena from the Apache Software Foundation. The

other implementation is based on the reference im-

plementation Lyo respectively OSLC4J which is also

hosted by the Eclipse Foundation.

ARecipeforToolInteroperability

305

<rdf:RDF

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:rdfs=“http://www.w3.org/TR/rdf-schema/#”

xmlns:dcterms=“http://purl.org/dc/terms/”

xmlns:ios_am="http://ios.artemis.eu/ns/am#"

xmlns:ios_tm="http://ios.artemis.eu/ns/tm#"

xmlns:mylinktool="http://linkage.com/mylinktool/">

<rdf:Description rdf:about="http://127.0.0.1:8005/00002722/links/1">

<ios_tm:implementedBy rdf:nodeID="A0"/>

<ios_tm:implements rdf:nodeID="A1"/>

<dcterms:title rdf:datatype=" http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral ">C0_implements_B0</dcterms:title>

<rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string">satisfy</rdfs:label>

<rdf:type>http://ios.artemis.eu/ns/tm#ImplementationLink http://linkage.com/mylinktool/Link</rdf:type>

</rdf:Description>

<rdf:Description rdf:nodeID="A0">

<rdf:_1 rdf:resource=“http://modelserver.local/models/testcomponents.model#12693 "/>

<rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag"/>

</rdf:Description>

<rdf:Description rdf:about="http://modelserver.local/models/testcomponents.model#12693">

<rdf:type>http://ios.artemis.eu/ns/am#Component</rdf:type>

</rdf:Description>

<rdf:Description rdf:nodeID="A1">

<rdf:_1 rdf:resource="http://simulinkserver.local/models/testmodel.slx/19238# "/>

<rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag"/>

</rdf:Description>

<rdf:Description rdf:about=" http://simulinkserver.local/models/testmodel.slx/19238# ">

<rdf:type>http://ios.artemis.eu/ns/am#Behavior</rdf:type>

</rdf:Description>

</rdf:RDF>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#” xmlns:rdfs=“ttp://www.w3.org/TR/rdf-schema/#” xmlns:dcterms=“http://purl.org/dc/terms/”

xmlns:oslc_rm="http://open-services.net/ns/rm#" xmlns:ios_rm="http://ios.artemis.eu/ns/rm#"

xmlns:myrequirements=“http://mycompany.com/local/ns/requirements/”

xmlns:ios_am="http://ios.artemis.eu/ns/am#" xmlns:ios_tm="http://ios.artemis.eu/ns/tm#">

<rdf:Description rdf:about="http://127.0.0.1:8005/00002722/278#//@attribute1">

<dcterms:title rdf:datatype=“http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral">

Assumption</dcterms:title>

<dcterms:description rdf:datatype="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral ">

always speed < 30 km/h</dcterms:description>

<rdf:type>http://rtp.artemis.eu/ns/rm#Assertion http://mycompany.com/local/ns/requirements/Attribute</rdf:type>

</rdf:Description>

<rdf:Description rdf:about="http://127.0.0.1:8005/00002722/278#//@description">

<dcterms:title rdf:datatype=“http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral">

Promise</dcterms:title>

<dcterms:description rdf:datatype=" http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral ">

whenever crash_detected occurs deploy_airbag does not occur</dcterms:description>

<rdf:type>http://ios.artemis.eu/ns/rm#Assertion http://mycompany.com/local/ns/requirements/Description</rdf:type>

</rdf:Description>

<rdf:Description rdf:about="http://127.0.0.1:8005/00002722/278">

<ios_rm:promise rdf:resource="http://127.0.0.1:8005/00002722/278#//@description"/>

<ios_rm:assumption rdf:resource="http://127.0.0.1:8005/00002722/278#//@attribute1"/>

<dcterms:title rdf:datatype=" http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral ">R0</dcterms:title>

<rdf:type> http://ios.artemis.eu/ns/rm#Contract

http://open-services.net/ns/rm#Requirement

http://mycompany.com/local/ns/requirements/MyCompanySpecialRequirement</rdf:type>

</rdf:Description>

<rdf:Description rdf:about="http://127.0.0.1:8005/00002722/links/1">

<oslc2_tm:satisfiedBy rdf:nodeID="A0"/>

<oslc2_tm:satisfies rdf:nodeID="A1"/>

<dcterms:title rdf:datatype=" http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral ">C0_satisfy_R0</dcterms:title>

<rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string">satisfy</rdfs:label>

<rdf:type>http://ios.artemis.eu/ns/tm#SatisfyLink http://linkage.com/mylinktool/Link</rdf:type>

</rdf:Description>

<rdf:Description rdf:nodeID="A0">

<rdf:_1 rdf:resource=“http://modelserver.local/models/testcomponents.model#12693 "/>

<rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag"/>

</rdf:Description>

<rdf:Description rdf:about="http://modelserver.local/models/testcomponents.model#12693">

<rdf:type>http://ios.artemis.eu/ns/am#Component</rdf:type>

</rdf:Description></rdf:RDF>

DOORS

Papyrus

Link Tool Simulink

Contract Satisfy Link Component Implementation Link Behavior

OSLC

Resource Type:

oslc_rm:Requirement

dcterms:title

dcterms:description

dcterms:subject

…

OSLC

Resource Type:

oslc_am:Resource

dcterms:title

…

OSLC

Resource Type:

oslc_am:Resource

dcterms:title

dcterms:description

…

OSLC

Resource Type:

oslc:Resource

dcterms:title

rdfs:label

…

IOS

Contract /

Requirement

IOS

Assertion

(promise)

IOS

Assertion

(assumption)

Contract

<< satisfy >>

IOS

Component

(satisfiedBy)

IOS

Satisfy Link

satisfies

satisfiedBy implementedBy implements

IOS

Behavior

(implements)

IOS

Component

(implementedBy)

IOS

Implementation Link

<< implementation >>

Implementation Link

<< satisfy >>

<< implementation >>

Refined

IOS Resource Type:

ios_rm:Contract

ios_rm:assumption

ios_rm:promise

ios_rm:specificationType

Refined

IOS Resource

Type:

ios_tm:SatisfyLink

ios_tm:satisfiedBy

ios_tm:satisfies

OSLC

Resource Type:

oslc:Resource

dcterms:title

rdfs:label

…

Refined

IOS Resource Type:

ios_am:Component

ios_am:interconnection

ios_am:part

ios_am:port

Refined

IOS Resource Type:

ios_tm:ImplementationLink

ios_tm:implementedBy

ios_tm:implements

Refined

IOS Resource

Type:

ios_am:Behavior

OSLC Base Type:

oslc_am:Resource

RDF

Figure 3: Application of the different steps of the recipe to a black-box testing scenario using DOORS (requirements), Papyrus

(component model), and Matlab Simulink (implementation model).

5 EVALUATION OF THE RECIPE

In this section we present our evaluation of the recipe

on an extended scenario based on the requirement al-

location workﬂow described in Section 2.2. For the

scenario we wanted to create an RTP which facilitates

interoperability between different industrial relevant

tools hosting data. The idea is to not only support

linking of requirements to components (satisfy link),

but also support linking of implementation models to

components (implementation link). This enables the

RTP to perform black-box testing of the implementa-

tion of a component against its requirements. Similar

to the original scenario (see Section 2.2), the com-

ponents are modeled in Papyrus by using the EAST-

ADL proﬁle and function types. The requirements are

managed within DOORS. In addition, we extended

DOORS to support the contract-based speciﬁcation

of requirements, which allows to specify assumptions

on the environment in which a requirement must hold

and the guaranteed/required behavior. For the imple-

mentation of a component we decided to use Matlab

Simulink / Stateﬂow models and for the creation of

the link elements we used an inhouse RTP link tool.

The ﬁrst step was the identiﬁcation of the ele-

ments of the internal engineering models which are

part of the scenario (Figure 3, step 1). From DOORS

we need to be able to access the tables / modules of

the database which store the individual requirements

and their additional information in different columns.

In addition, DOORS supports tracing of requirements

and therefore the satisfy relationship between require-

ments and components is the second model element.

EAST-ADL is a very rich model. Therefore, within

the scenario it is important to limit the scope of ex-

posed elements. Only the function types deﬁning a

component hierarchy are relevant for the scenario to

be able to link requirements and implementations to

individual (sub-)components. Since the implementa-

tion shall be linked as basically a black box object, the

work item is only the full model itself without the de-

tailed behavior description. The implementation rela-

tion between components and implementation mod-

els is the last work item needed for the scenario. In

contrast to the satisfy links, the management of these

links is not supported by any of the tools and had to

be realized in a separate link repository.

The next step was to map the engineering model

elements to concepts of a common meta-model (Fig-

ure 3, step 2). As suggested by the recipe, we derived

our meta-model concepts from existing meta-models

which were in this case HRC and the concepts from

the SPES 2020 methodology. The DOORS table en-

tries are assigned to the concept of a Contract which

explicitly names its assumptions and its guarantees.

The EAST-ADL function types are mapped to the

Component concept and the Matlab implementation

to the Behavior concept. Finally, both traceability

links are mapped to the concepts of Implementation

Link respectively Satisfy Link. After this step, a

MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

306

ﬁrst high level view connecting the different engineer-

ing models had been established.

Within the third step we allocated the meta-

model concepts to basic elements of the dif-

ferent OSLC domains (Figure 3, step 3). A

Contract is a specialization of the generic concept

of a oslc rm:Requirement and the Component is

mapped to the basic concept of a oslc am:Resource.

For the Behavior we decided to also use the

oslc am:Resource as a basis because it is an archi-

tectural related artifact. For both trace-link concepts

there is no direct counterpart in the OSLC domains

and they could only be mapped to the basic OSLC

core Resource.

Within the fourth step we reﬁned the OSLC con-

cepts by adding additional properties to the original

OSLC concepts. In this example we created the new

domain identiﬁers IOS RM, IOS AM, and IOS TM

to denote these extensions (Figure 3, step 4). Espe-

cially the basic OSLC core Resource type does not

deﬁne any properties and had to be extended for the

representation of the trace-link concepts.

The last step was the implementation of the newly

reﬁned IOS concepts. For this we implemented server

application using the Jena and Jetty libraries (as sug-

gested in Section 4.6). Figure 3 illustrates in step 5

how the ﬁnal RDF for data interchange looks like.

To further evaluate the beneﬁts of the recipe ap-

proach, we modiﬁed the scenario by replacing one of

the integrated tools. We replaced the requirement and

link storage in DOORS with a solution based on MS

Excel sheets. In this case, we only had to identify

and map the relevant structures of the Excel sheets

to the meta-model artifacts (step 1 and step 2) and

could reuse the rest of our implementation. Within the

MBAT project we extended the presented scenario it-

eratively to support deﬁnitions of faults, failures, ver-

iﬁcation / validation activities, as well as their results.

We realized the extended scenario in an RTP by a fur-

ther application of the recipe and by implementing

OSLC-compliant consumers and providers.

6 CONCLUSIONS

In this document we described a recipe on how to sys-

tematically connect tools with an OSLC-based inter-

operability speciﬁcation to support engineering work-

ﬂows. The recipe is a guideline for developers for

which it eases tool integration and enables traceabil-

ity required by standards. With the recipe a common

meta-model is constructed which establishes a homo-

geneous view on the semantic concepts of the tools

and therefore allows common understanding of ex-

changed engineering information at the level of gran-

ularity required for the workﬂows. The evaluation

showed an easy integration of tools for a typical engi-

neering workﬂow. It revealed reuse capabilities com-

ing with the separation of tool-speciﬁc engineering

models and meta-model concepts that support such a

workﬂow. Tools can be replaced with limited effort by

other tools whose engineering models can be mapped

to the same meta-model concepts. It is also possible

to extend a workﬂow by adding meta-model concepts

which only leads to minor modiﬁcations of existing

tool adapters. Since our evaluation was purely man-

ual, future work could address automatization of the

recipe’s steps e.g. derivation of needed meta-model

concepts based on ontologies.

ACKNOWLEDGEMENTS

The research leading to these results has received

funding from the ARTEMIS Joint Undertaking within

the European project MBAT under grant agreement

◦

269335 and from the German Federal Ministry of

Education and Research (BMBF) under grant number

01IS11003L. The responsibility for the content of this

publication lies with the authors.

REFERENCES

Baumgart, A., Ellen, C., Oertel, M., Rehkop, P., Farfeleder,

S., and Schulz, S. (2012). A reference technology

platform with common interfaces for distributed het-

erogeneous data. In Proceedings of the of the Embed-

ded World 2012 Exhibition and Conference.

Brickley, D. and Miller, L. (2010). FOAF Vocabulary Spec-

iﬁcation. http://xmlns.com/foaf/spec/. Version 0.98.

Dublin Core Metadata Initiative (2012). DCMI Metadata

Terms. http://dublincore.org.

EAST-ADL Association (2013). EAST-ADL Domain Model

Speciﬁcation. Version V2.1.11.

ISO (2011). Road Vehicles - Functional Safety. Interna-

tional Standard Organization. ISO 26262.

MBAT Project (2013). Combined Model-based Analysis

and Testing of Embedded Systems . http://www.mbat-

artemis.eu/. ARTEMIS Call 2010 269335, 2011-

2014.

OMG (2010). Systems Modeling Language (OMG SysML

). Object Management Group. Version 1.3.

OSLC Community (2013). Open Services for Lifecycle

Collaboration. http://open-services.net/.

Pohl, K., H

onninger, H., Achatz, R., and Broy, M. (2012).

Model-Based Engineering of Embedded Systems: The

SPES 2020 Methodology. Springer. ISBN 978-

3642346132.

ARecipeforToolInteroperability

307

Rajan, A. and Wahl, T., editors (2013). CESAR - Cost-

efﬁcient Methods and Processes for Safety-relevant

Embedded Systems. Springer. ISBN 978-3709113868.

SPEEDS Project (2009). SPEEDS L-1 Meta-Model.

SPEEDS WP.2.1 Deliverable D.2.1.5, Revision 1.0.1.

Vasaiely, P., Keis, A., and Ersch, R. (2012). Towards an

European Reference Technology Platform for the de-

velopment of safety relevant embedded systems: The

CESAR Interoperability Speciﬁcation. In Proceed-

ings of the Embedded World 2012 Exhibition and Con-

ference.

W3C (2004). RDF Vocabulary Description Language 1.0:

RDF Schema. http://w3.org/TR/rdf-schema/. W3C

Recommendation.

Zhang, W., Møller-Pedersen, B., and Biehl, M. (2012). A

light-weight tool integration approach : From a tool

integration model to oslc integration services. In IC-

SOFT 2012 - Proceedings of the 7th International

Conference on Software Paradigm Trends, pages 137–

146.

MODELSWARD2014-InternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

308