sprint · d5.7+d5.3 architectural principles for internet of system design and the iot version...

PROPRIETARY RIGHTS STATEMENT

THIS DOCUMENT CONTAINS INFORMATION, WHICH IS PROPRIETARY TO THE SPRINT CONSORTIUM. NEITHER THIS DOCUMENT NOR THE INFORMATION CONTAINED HEREIN SHALL BE USED, DUPLICATED OR COMMUNICATED BY ANY MEANS TO ANY THIRD PARTY, IN WHOLE OR IN PARTS, EXCEPT WITH THE PRIOR WRITTEN CONSENT OF THE SPRINT CONSORTIUM THIS RESTRICTION LEGEND SHALL NOT BE ALTERED OR OBLITERATED ON OR FROM THIS DOCUMENT

THE RESEARCH LEADING TO THESE RESULTS HAS RECEIVED FUNDING FROM THE SVENTH FRAMEWORK PROGRAMME UNDER GRANT AGREEMENT N° 257909

Project Number: 257909

SPRINT

Software Platform for Integration of Engineering and Things

Collaborative project

Information and Communication Technologies

D5.7 Architectural principles for Internet of System Design and High

and

D5.3 low level design description of System Design and Semantic Interoperable Integration.

Start date of project: October, 1st 2010

Duration: 36 months

Deliverable D5.7 Architectural principles for Internet of System Design and the IoT

Confidentiality PU Deliverable type R

Project SPRINT Date 2014-02-16

Status Final Version 1.0

Contact Person Uri Shani Organisation IBM

Phone +97248296282 E-Mail [email protected]

D5.7+D5.3 Architectural principles for Internet of System Design and the IoT

Version Status Date Page

1.0 Final 2014-02-18 2 of 63

AUTHORS TABLE

Name Company E-Mail

Uri Shani IBM [email protected]

Massimiliano Dangelo ALES [email protected].

com

Kullo Raiend Elvior [email protected]

Michael Wagner FOKUS [email protected]

Otto Tronarp Wofram [email protected]

CHANGE HISTORY

Version Date Reason for Change Pages

Affected

0.0 2013-12-24 Initial version – based on D5.6 all

0.1 2014-02-10 Layout of sections and scope all

0.2 2014-02-12 Contributions from ALES and Elvior and IBM Chapters: 3,4,5

0.3 2014-02-13 Contributions from MC Chapters: 3

0.4 2014-02-15 Contributions from Elvior, content on mediation Chapter 3.10,

3.4.2, Appendix 9.3

0.5 2014-02-16 Minor changes Chapter 3.10.6, 4.

1.0 2014-02-18 Finalizing 3.10.5,6.

1.0 2014-10-09 Designated as PU Intro pages



1.0 Final 2014-02-18 3 of 63

CONTENT

1 INTRODUCTION ...................................................................................................................................................... 7

1.1 OVERVIEW, PURPOSE AND SCOPE .................................................................................................................... 7

2 HIGH LEVEL ARCHITECTURE ............................................................................................................................ 9

2.1 ARCHITECTURAL LAYERS AND ACTORS ROLES ................................................................................................. 9 2.2 FIRST TIER – THE CONTENT PROVIDER ............................................................................................................ 10 2.3 SECOND TIER – SII SERVER ............................................................................................................................. 10 2.4 THIRD TIER - APPLICATIONS ............................................................................................................................. 11 2.5 FOURTH TIER – COUNTER SII SERVER ............................................................................................................ 11

3 MID LEVEL ARCHITECTURE............................................................................................................................. 12

3.1 THE COMPREHENSIVE ARCHITECTURE ............................................................................................................ 12 3.1.1 Components of the Extended Architecture......................................................................................... 12

3.1.1.1 Components .......................................................................................................................................................... 13 3.1.1.2 Tools and applications: ........................................................................................................................................ 14

3.2 ARCHITECTURE FUNDAMENTAL ASSUMPTIONS AND REQUIREMENTS ............................................................ 15 3.3 FINAL ARCHITECTURE OF THE SEMANTIC MEDIATION CONTAINER ................................................................. 15

3.3.1 Concepts of the solution architecture .................................................................................................. 15 3.3.2 IoSE tool interaction protocol - OSLC ................................................................................................. 16

3.3.2.1 OSLC Support on the SMC ................................................................................................................................ 18 3.3.2.1.1 Looking at the Jazz/DM Root Services........................................................................................................ 18 3.3.2.1.2 Looking at the SMC OSLC service providers ............................................................................................. 18 3.3.2.1.3 The OSLC Services of the SMC OSLC Service Providers ....................................................................... 18

3.3.3 The Extended SMC Protocol (Over OSLC) ........................................................................................ 21 3.3.4 Sharing Objects through the SMC ....................................................................................................... 22 3.3.5 Validation Scenarios .............................................................................................................................. 23

3.3.5.1 Model Sharing....................................................................................................................................................... 23 3.3.5.2 Model Behavior Sharing ...................................................................................................................................... 24

3.4 THE SMC MEDIATORS ..................................................................................................................................... 25 3.4.1 The SMC Mediator Framework ............................................................................................................ 25 3.4.2 The SSI – SPRINT Semantic Mediation via Ontologies ................................................................... 25

3.4.2.1 Mediated Models vs. Relations .......................................................................................................................... 27 3.5 LOW LEVEL SMC ARCHITECTURE .................................................................................................................... 28 3.6 MANAGING THE SMC ....................................................................................................................................... 29

3.6.1 User levels of the SMC .......................................................................................................................... 29 3.6.2 The SMC configuration console ........................................................................................................... 30 3.6.3 The SMC utilities .................................................................................................................................... 33

3.6.3.1 Authoring ontologies with Protégé ..................................................................................................................... 33 3.6.3.2 Implementing clients with the SMC SDK .......................................................................................................... 34 3.6.3.3 Browsing SMC contents via the web console .................................................................................................. 35

3.7 SII AGENTS AND INTERNAL APPLICATIONS ...................................................................................................... 38 3.8 DISTRIBUTION OF THE SMC ............................................................................................................................. 38

3.8.1 Inter Corporate Collaboration ............................................................................................................... 39 3.8.2 IT Aspects of the SMC Distribution ...................................................................................................... 39

3.9 THE SMC SCALABILITY .................................................................................................................................... 40 3.10 THE SII CLIENTS ............................................................................................................................................... 40

3.10.1 The SMC Software Development Kit for Client Development ......................................................... 41 3.10.2 The IBM Rhapsody Client ..................................................................................................................... 41 3.10.3 The Wolfram SystemModeler Client .................................................................................................... 43 3.10.4 The ALES DESYRE Client ................................................................................................................... 44 3.10.5 The Fraunhofer Physical Devices Client ............................................................................................. 44 3.10.6 The Elvior TestCast Client .................................................................................................................... 45

4 TESTING OVER THE INTERNET ....................................................................................................................... 47



1.0 Final 2014-02-18 4 of 63

5 SIMULATION AND CO-SIMULATION ............................................................................................................... 50

5.1 ARCHITECTURAL COMPONENTS ....................................................................................................................... 50 5.2 INTERACTION AMONG THE SIMULATION ACTORS .............................................................................................. 51

6 INTERNET OF THINGS........................................................................................................................................ 53

7 ABBREVIATIONS AND DEFINITIONS ............................................................................................................. 54

8 REFERENCES ....................................................................................................................................................... 56

9 APPENDIX .............................................................................................................................................................. 58

9.1 THE MEDIATOR INTERCEPTOR INTERFACE....................................................................................................... 58 9.2 INSTALLING INTERCEPTORS VIA THE PLUGIN DESCRIPTION ............................................................................ 59 9.3 MEDIATION RULES USER GUIDE ...................................................................................................................... 59

9.3.1 Classification of mediation rules .......................................................................................................... 59 9.3.2 Equivalence Replacements .................................................................................................................. 60 9.3.3 Replacement with a Super-Property or a Super-Class..................................................................... 60 9.3.4 Replacement with a Sub-Property or a Sub-Class ............................................................................ 61 9.3.5 Complex Equivalence Replacements ................................................................................................. 61 9.3.6 Type-Inference from Property Domain or Range .............................................................................. 62 9.3.7 Expansion, and Contraction, by Domain, Class, and Range ........................................................... 62



1.0 Final 2014-02-18 5 of 63

Content of Figures

Figure ‎2-1 – SPRINT Collaboration Environment .............................................................................................. 9 Figure ‎2-2 – SPRINT SII platform high level view ........................................................................................... 10 Figure ‎2-3 – Elaborated distributed configuration of multi corporations collaborating over multiple projects. 11 Figure ‎3-1 – SII Server Architecture Block Diagram ........................................................................................ 12 Figure ‎3-2: Exchanging models from different tools via the common semantic model ................................... 16 Figure ‎3-3 – The flow of model data into SII from Rhapsody .......................................................................... 16 Figure ‎3-4 – IoSE-specific RESTful protocol between SII and tools. .............................................................. 17 Figure ‎3-5: Root services of Jazz/DM, including the SMC services. ............................................................... 18 Figure ‎3-6: Rhapsody tool models service provider ........................................................................................ 18 Figure ‎3-7: OSLC Service providers of the SMC ............................................................................................. 19 Figure ‎3-8: Details of the Rhapsody repository OSLC service provider .......................................................... 20 Figure ‎3-9: Query result for all resources which are “a” FlowPort ................................................................... 20 Figure ‎3-10: Reviewing the first resource in the query results shown in Figure 3-9, which is “a” FlowPort in the Rhapsody ontology. .................................................................................................................................... 20 Figure ‎3-11: Simplified flow diagram for the SMC protocol ............................................................................. 21 Figure ‎3-12: The attachments architecture of SMC ........................................................................................ 22 Figure ‎3-13: The SM ontology, including the properties pertaining to the attachment semantics of SMC. .... 22 Figure ‎3-14: Flow diagram of tools creating an attachment and associating it with a model element. ........... 23 Figure ‎3-15 – Semantic mediation status at end of Y2 .................................................................................... 24 Figure ‎3-16: Mediating between Rhapsody UPDM through a generic UPDM with the System Architect NAF models – a DANSE EU project scenario. ......................................................................................................... 24 Figure ‎3-17: Installing a mediator in the SMC by extending an SMC extension point. ................................... 25 Figure ‎3-18: The staged flow of models into and out of the SSI components of the SII (i.e., the SMC). ........ 26 Figure ‎3-19: Multi common meta-models within a multi staged mediation tree of processes. ........................ 27 Figure ‎3-20 – Mediation and relations among SII resources and tools' resources. ........................................ 28 Figure ‎3-21: Architecture schematic of the Semantic Mediation container over Jazz/DM .............................. 29 Figure ‎3-22: Configuring the semantic mediation container for a tool collaboration through model exchange29 Figure ‎3-23: SMC Console for the SPRINT validation use case. .................................................................... 30 Figure ‎3-24: Operational graph of the mediation network used in the validation use case. ............................ 31 Figure ‎3-25: Configuring a mediator shows the choice of implementation installed in the SMC as interceptor plugins............................................................................................................................................................... 32 Figure ‎3-26: The Protégé console. The model explorer and the model graph visualization. .......................... 33 Figure ‎3-27: Protégé discovery of its plugins, including the SMC plugin. ....................................................... 33 Figure ‎3-28: The SMC plugin dialog for loading Protégé with SMC ontologies or rule-sets. .......................... 34 Figure ‎3-29: UI dialog of the SMC SDK ........................................................................................................... 35 Figure ‎3-30: Browsing in the “Table view” of an RDF – for a repository, or an ontology. ............................... 36 Figure ‎3-31: Modifying an individual resource via the browser ....................................................................... 36 Figure ‎3-32: The SPARQL query dialog of SMC ............................................................................................. 37 Figure ‎3-33: Viwing a mediator shows the browseable URLs of its associations ........................................... 37 Figure ‎3-34: SMC Log of jobs execution. ........................................................................................................ 37 Figure ‎3-35: Configuring a remote SMC Friend, and the Exporter Port to connect with it. ............................. 39 Figure ‎3-36: Distributed implementation of the SII over the internet ............................................................... 39 Figure ‎3-37: Server(s) on the cloud providing SaaS to client across fire-walls, intranets and the internet. .... 40 Figure ‎3-38: UI dialog of the SMC SDK ........................................................................................................... 41 Figure ‎3-39: Invoking export of a model element. ........................................................................................... 42 Figure ‎3-40: Importing from IoSE (SMC) into a new Rhapsody project. ......................................................... 42 Figure ‎3-41: Exporting an FMU and integrating into an SMC model. .............................................................. 42 Figure ‎3-42: Integrating the exported FMU object into the SMC model as the “hasFMU” property of some Rhapsody Block. ............................................................................................................................................... 43 Figure ‎3-43: The IoSE export dialog of SystemModeler .................................................................................. 43 Figure ‎3-44: The IoSE import dialog of SystemModeler ................................................................................. 44 Figure ‎3-45: The IoSE import dialog of SystemModeler ................................................................................. 44 Figure ‎3-46: The IoSE import dialog of SystemModeler ................................................................................. 45 Figure ‎3-47: The TestCast OSLC client UI: IoSE communication, browsing the retrieved model elements, publishing and downloading attachment properties ......................................................................................... 46 Figure ‎4-1 – Actors involved in the distributed Testing over the Internet ........................................................ 47



1.0 Final 2014-02-18 6 of 63

Figure ‎4-2 – Distributed planning and execution of testing over the internet .................................................. 48 Figure ‎4-3 – Test execution over the internet sequence diagram ................................................................... 49 Figure ‎5-1 – Actors involved in the distributed HiL simulation ......................................................................... 50 Figure ‎5-2 – Sequence diagram of the distributed HiL simulation ................................................................... 51

Content of Tables

Table ‎3-1: Fundamental assumptions of the SII architecture .......................................................................... 15



1.0 Final 2014-02-18 7 of 63

1 Introduction

1.1 Overview, Purpose and Scope

This is the final revision of the SPRINT platform architecture, high middle and low design decisions and architectural concepts. All of these aspects are discussed rather than splitting them to two distinct deliverables D5.3 and D5.7, as has been originally designed in the project DOW. This arrangement follows up on the trend used on the earlier deliverables D5.2, D5.5 and D5.6, so that the evolution of the architecture concepts and the solution design are reposted periodically throughout the project life-time.

This document is built on top of the D5.6 report version ‎‎[21] finalizing all open issues and setting up the stage for future research and development.

With the finalization of the SPRINT technologies, some important components have been subject to exploitation efforts, especially with other EC projects. The DANSE ‎[22] project (in which several of the SPRINT partners are also members) has adopted (by intention) the semantic mediation approach for model sharing, and uses the same Jazz-based platform to carry out that function among its tools. SPRINT tools capable and compliant with semantic mediation are also included in the DANSE portfolio of tools – the TestCast® and Wolfram SystemModeler® (which initially has been the MathModelica tool by MathCore – now Wolfram), and the DESYRE® simulation tool by ALES (which since has been joined into UTC).

The purpose of this document is to present the high, mid and low level architectural principles of the Semantic Interoperable Integration (SII) platform. The described architecture has been implemented into the second prototype at the end of Y2 of the "Internet of System Designers", enable collaborative work over common design models over the internet in a distributed environment.

Other aspects of the internet of design are related to the execution of co-simulation and hardware in the loop of physical devices over the internet. These aspects are covered by other deliverables in the respective work packages, and within the final prototype (D5.11) ‎[23].

The material in this repost will be divided into 5 sections:

1. This high-level architecture in which we will deliberate on the concepts of the SPRINT SII architecture. That is the high level architecture concepts as evolved during the initial stages of the project and were also reported in previous revisions of this report.

2. The tools interoperability platform based on Semantic Mediation and based on the IBM Jazz/DM foundation. This includes also tools adaptations to work within this environment, serving design as well as validation and testing, and simulation. This middle and low level architecture of the platform to support the semantic interoperability eco-system of the SPRINT tools has been evolved to practical and effective working prototype at its 3rd revision during the last year and this document will elaborate on its architecture.

3. Performing validation through testing on the distributed SPRINT SII environment.

4. The global distributed simulation environment of SPRINT, using the DESYRE tool, the FMI standard and the FMU capabilities of the SPRINT design tools Rhapsody and Wolfram System Modeler. While the development of FMI capabilities by tools has been done to a large degree during the last project year, the concepts did not change from the earlier versions, but reached a practical and effective materialization.

5. The internet of things where physical devices are in the loop of the simulation environment, following what has been established as a foundation in the earlier revisions of this document – to be perfected during the last year as also been demonstrated in the final prototype.



1.0 Final 2014-02-18 8 of 63

Some notes about the acronyms used in SPRINT:

SII - Semantic Integrated Interoperability is the environment of interoperability and collaboration of SPRINT. That environment has later been identified as the IoSE for Internet of Systems Engineering to match the foundation term IoT on which SPRINT focuses. So the term IoSE is used extensively to describe the working environment of the engineers during product design, simulation, testing and execution with physical devices an an IoT.

The term SSI has evolved into the mechanism and technology for semantically mediating models of different tools, which has also evolved into a component in the IoSE environment – the mediator in the Semantic Mediation Container platform.



1.0 Final 2014-02-18 9 of 63

2 High Level Architecture

2.1 Architectural Layers and Actors Roles The SPRINT architecture is a federated deployment of multiple independent SII server nodes with multiple exclusive data spaces. This architecture solution applies two distinct configuration roles:

Role – I: Cross tool collaboration environment, allows a single community to define set of internal-projects (i.e. SII projects). Associate each one of them with set of content provider projects. These content providers covering different domains (i.e. RM –DOORS, AM – SA, Simulation – Rhapsody etc.). The SII server accepts published data resources (May it be raw samples or indexing data) and stores them in the server-node owned exclusive data space. Actors shall be able to collaborate within the context of single internal-project between the tools attached to this project. The collaboration may be governed by relaxed security protocols. The IT/security aspects for interaction between the tools is considered simple since they all should reside on the same or directly connected intranets. Yet, the semantic integration among these tools is a significant SII problem.

Role – II: Cross organization collaboration environment, extends the core capabilities of the first role with distribution across organization boundaries, enabling independent SII nodes from different organizations to establish cross-organization extended projects. Users in different organizations should be able to access the information following over agreed security communications, within a hostile territory. The interaction between tools at different server-node endpoint may be trickier, as the internet is masked with firewalls, and require the mediation capabilities of the Distributed-SII system.

A collaboration environment example is depicted in next Figure 2-1.

Figure ‎2-1 – SPRINT Collaboration Environment

This architecture environment consists of four tiers as described in the next sections.



1.0 Final 2014-02-18 10 of 63

2.2 First Tier – the content provider The first tier layer is that of the content provider also referred to as a Tool. The Tool is a software program which maintains shareable design contents, modelling some aspects of the product's design. A tool is also an independent program with its own data repository, management and usability functions that allow users to work with it, totally independent of other tools. We say that a tool holds some view of the engineered system. The content provider internal data owned by the tool is accessible to third party, may it be a tool or an application or an SII server, using REST‎[6]

interface.

This interface should follow OSLC‎[1] specifications for a domain covered by the OSLC community. In cases where SPRINT's work identifies new domains not specified in this community, a corresponding definition of REST interface will be created, in turn, and may become an extension contributed to the OSLC community. The way tools and applications (see next) are working with the SII are depicted schematically in the next Figure 2-2

Figure ‎2-2 – SPRINT SII platform high level view

2.3 Second tier – SII server The second tier layer is the SII server node that plays two roles.

1. The first role is to enable internal collaboration between participating content providers in the context of specific internal-projects. Usually, this kind of role exists within the boundaries of an organization. The organization deploys an SII server node to serve its own engineering projects. The SII server stores any collaboration data (see next section for detail discussion) in its owned exclusive data-space. The SII server exposes a set of REST service, enabling tools and applications to access the collaboration data, again, using OSLC specification for existing domains whenever possible. The server can extend over the OSLC wherever it is needed, and indeed the SPRINT SII solution for the server does that to enable the unique semantic mediation capability of the Semantic Service Integration – SSI component of the SII. A web interface to the server is used to manage and configure the server.



1.0 Final 2014-02-18 11 of 63

2. The second role of the SII server is to facilitate "Internet of Design Model Element" endpoint, enabling collaboration between two independent deployments of SII server across the internet.

2.4 Third Tier - Applications The third tier layer consists of Applications, a software program which provides an added value based on the shared contents of the tools by applying functions that have not been addressed by the individual tools and which is possible due to the integration of data from multiple tools. Obviously, applications are such that they add a new value to the data in the SII repository. Notably, some tools may also play the role of an application.

For instance, a design tool which can also perform analysis, simulation, and so on, and generate a report on the results of that value-adding function – is such. Application works on input data that is usually gathered through set of queries against the SII server, and possibly requires transformations defined at the Semantic Service Integration (SSI) layer.

2.5 Fourth Tier – Counter SII server The fourth tier layer is the Counter-SII server serving partners across the internet as their SII server in the collaboration environment. Usually, this counter endpoint resides in a different organization, participating in engineering tasks of additional sub-components. The set of SII servers across the internet are the Distributed – SII, enabling federated search and query over the shared data across the tools, applications and organizations. The distributed collaboration is done through REST interfaces, following the OSLC-Core specification, with possibly extensions to the standard domain under the OSLC realm.

We elaborate on this collaboration in Figure 2-4, where 5 collaboration SII servers are federated over the internet in the Distributed SII (DSII) network, each serving one corporation. There are several collaborative projects that are marked in this figure through colour areas in which some subset of the SII servers are included, marking the collaborative context among the related corporations of some project. This scenario is an elaboration of the duo situation of Figure 2-1.

9 November, 2011 23

DSII

T1

A1

A2

Am

Tn

T2

Partner A

Partner B

Partner C

SIIB

SIIASIIC

SIIDSIIE

T1

A1

Am

Partner EPartner D

A2

Tn

Multi-project Distributed Colalboration

Figure ‎2-3 – Elaborated distributed configuration of multi corporations collaborating over multiple projects.



1.0 Final 2014-02-18 12 of 63

3 Mid Level Architecture In this chapter, we describe the Semantic Mediation Container – the SMC, which is a realization of the SII and SSI high-level architecture over the IBM Jazz/DM open platform. We start with a comprehensive description of an SMC server environment, covering all the 4 roles laid out above, and then dive into the actual implementation of the SMC over Jazz/DM, and the capabilities built into it per semantic mediation and the connectivity with tools and applications, as well as the distributed aspects of the environment.

The environment in which SMC servers operate with their tools is the Internet of System Engineering, which we term IoSE in our presentation in this document and other related SPRINT documents.

3.1 The Comprehensive Architecture The SII server provides a set of components and services to support both roles of cross-tool internal-project collaboration environment, and the federated cross-organization collaboration system. The SII architecture solution adopts key fundamental concepts applied by the Jazz Integration Architecture (JIA)‎[2]. The basic conceptual guideline is to interconnect technologies and specifications using RESTful‎[6] API's instead of being a monolithic integrated platform. In this architecture, tools, applications and servers need to expose their functionality in a resource-oriented Web service, enabling direct access to facilities and data offered by the tools. The provided REST API's interfaces consist of:

(i) A unique stable identification of data resources in the form of a URL

(ii) A representation of these using the RDF‎[3] format (Resource Descriptive Framework)

(iii) Protocol and operations for manipulating those data resources based on standard HTTP methods; the resource basic life cycle of Create, Read, Update and Delete (CRUD) is easily supported by POST, PUT, GET and DELETE HTTP methods.

The following Figure 3-1 depicts the different SII components deployed on top of the JTS server, and different configurations of tools and applications.

Legacy Tool R

SII on Jazz DM

OSLC Server

Data

Extractor –

Importer

UI

OSLC ClientIoSE Specific

SII RDF Repository

UI Extension

OSLC ClientIoSE Specific

(Generic)

OSLC Client

UI

Application R

OSLC Client

UI Extension

RDF IoSE Specific

Semantic Mediation Container

Repository Management

UI

Ext.

OSLC Tool R

UI ExtensionOS

LC

Se

rver

OS

LC

Cra

wle

r

Web

UI

Inte

rnal

Ap

plic

atio

nAp

p

UI

A

1

2

3

B

C

D

E

F

4

5

67

8

9F

7

Figure ‎3-1 – SII Server Architecture Block Diagram

The SII server is built as extensions of Jazz in a Jazz Team Server (JTS) ‎[2] which includes the Jazz Foundation Services (JFS) which enables server-based facilities and utilities. One such utility is the data storage repository which is an RDF (Resource Description Framework)‎[3], which SII adopts as its exclusive data space. Another utility example is the SPARQL‎[4] query service which JTS support for carrying out SPARQL querying over based data instances.

3.1.1 Components of the Extended Architecture

The components of the architecture are all depicted in Figure 3-1, where we numbered components in the tools and in the collaborative SII platform, and marked with letters the different tools and application patterns. The components ‎(1)-‎(4) and ‎(9) are extensions of the JTS platform,



1.0 Final 2014-02-18 13 of 63

whereas those numbered ‎(5)-‎(8) are parts of the tools and applications. Tools and applications marked ‎(A)‎(E) are external to the platform, while ‎(F) is an application built within the platform as a Jazz application. The other parts (in dark blue) in this figure are existing tools and applications that are used within the SPRINT tool-net ecosystem.

3.1.1.1 Components

(1) IoSE Specific. An extension in the RESTful internet interface of the SII which is developed specifically for exchanging RDF models between tools and the platform so that the semantic mediation container can work with them. That is no longer specific to a tool, yet the semantic level of programming ontologies and ontological rules causes tool specifications to be applied when corresponding tools content is exchanged with the platform.

(2) Semantic Mediation Container. A framework of mediation interceptors to the platform each of which performs a certain step in the composition of transformations between concrete tools’ models and a multi-level structure of common semantic models of various domains.

(3) Repository Management. A layer within the platform to manage specific capabilities such as access control to data, distributed federation of model data over multiple, and the change management of models shared by the tools. Of all these capabilities, the distribution and federation of the data is most critical and will be embedded within the repository access software layer between mediation and the RDF repository. The additional important capabilities are of a secondary urgency for the project and may also be provided by the Jazz platform as it evolves during the project.

(4) UI Extension on the platform. The additional SPRINT services to the Jazz platform may need GUI extensions that will be integrated within the GUI framework of the platform as GUI plug-ins. This extension will support the management services of the repository and its configuration over a distributed.

(5) UI and its possible extensions for the integration of tools with the platform. Tools, agents, and applications integrated into the SPRINT SII ecosystem need some UI extensions over their native GUI framework, or on top of that, which will support the specific operations of end-users taking advantages of the added value offered by the SII platform.

(6) OSLC client for tools and applications. OSLC client functionality is a subset of the full OSLC server capabilities and is a minimal entry-point requirement of tools in the SPRINT tools ecosystem. An OSLC client function allows the tool to work against the OSLC Server interface of the SII. With this interface, model elements in the SII repository can be queried, read, modifies, created or deleted by tools. Note that this interface can also work through the semantic-mediation layer as much as it can be done through the tool-specific interface (see also ‎(7) in this list)

(7) IoSE Specific interface that may not be OSLC compliant, yet it is still RESTful compliant. This is a complementary interface in the tools to the interface on the server, allowing direct and massive exchange of models between tools and the SII repository through the semantic mediation layer.

(8) OLSC server is a fully developed OSLC compliancy of a tool that can provide full access to content of the tool. When a tools is OSLC server, its content can be interrogated and accessed automatically by the SII server (see next point ‎(9)) with the tool being agnostic to the SII server altogether. That is a great advantage for integrating tools into the SPRINT ecosystem.

(9) OSLC crawler is a powerful capability of the SII that is not mandatory, but a very convenient way to integrate OSLC compliant tools into the SPRINT tool-net ecosystem. As the OSLC protocol - when fully implemented on a server - is fully self-descriptive, a crawler can find out the content of a tool as much as web crawlers can detect contents over the internet.



1.0 Final 2014-02-18 14 of 63

3.1.1.2 Tools and applications:

(A) Data extractor and importer. This is an application which helps to integrate a legacy tool into the SII tool-net ecosystem, w/out making any changes to the tool. Having its own OSLC client interface and the tool-specific interface, a UI, and a full access to the internal data of a tool – this application can communicate contents of the tool projects with the SII. An example for that is the Java API of Rhapsody which allows developing such application which is able to work with Rhapsody project repositories w/out doing any changes to the Rhapsody product.

(B) Legacy tool is a non-OSLC compliant tool which can be integrated using the Data Extractor-Importer. In this variation, the tool is extended (as most of the tools today are capable of) with the needed functionality that will allow them to integrate with the SII eco-system. In fact, the same interfaces and UI extensions required for the stand-alone application described in ‎(A) above are also required to be extended into the legacy tool. Again, our example with Rhapsody can be performed by applying the added functionality via a Rhapsody plug-in, which extends the Rhapsody functionality via a profiles mechanism that uses the Java API to access the tool’s data and interface it with the SII eco-system.

(C) Application interacts with the SII in order to perform some value-added function over the model data stored in the SII repository. Examples of such applications are simulators and analysers, test generators and optimizers and the like. The application needs an OSLC client interface to obtain model data from SII at a minimum. However although not shown in this diagram, an application may also have its own specific interface (RESTful though) by which massive model data can be obtained in its own specific representation – mush the same as it is done for tools (i.e., ‎(1) and ‎(7) above).

(D) OSLC tool is a contemporary tool that is OSLC compliant, meaning that it has full OSLC server capabilities. An advanced capability of SII to “crawl” the network can take advantage of such tools and work with them w/out the tool being aware of the SII eco-system altogether.

(E) OSLC client is a generic application that can execute OSLC client functions for querying, reading, modifying, creating and deleting OSLC resources of the SII. The OSLC client is also an OSLC sample project which can be used to customise specific clients for different tools as much as the “Data Extractor – Importer” in ‎(A) above.

(F) Internal SII application takes advantage of the SII platform itself to support extensions such as to perform specific value-added functions over the SII repository. For instance, an impact analysis application, or a validation application which have their own UI extensions through the UI plug-in framework of the SII platform and which work directly with the content of the SII repository.



1.0 Final 2014-02-18 15 of 63

3.2 Architecture Fundamental Assumptions and Requirements

Table ‎3-1: Fundamental assumptions of the SII architecture

# Requirement/Assumption Description

A1 Source Data Ownership Tools own their data objects and relations. Tools may decide to use SII as repository but this is not mandatory. When a tool exports its data to the server, the server creates a medited repository from the exported model. The repository contents are owned by the server, and have local URLs as resources which can be used via the OSLC protocol.

A2 Inter – Link Ownership OSLC compliant tools will follow the principle that they store any interlink created at their internal repository.

SII server will provide the facility for legacy tools to store their inter-links at designated Unit of Content owned by the tool.

A3 Indexing Data Publishing Tools will publish data resources required for carrying out indexing; these data resource may be the actual original tool data, but not necessarily. That is an optional capability which can be used to integrate into advance facilities over the Jazz tools family.

A4 REST - OSLC interoperability centric role

Any interaction between participating actors is based on the adoption of the OSLC specification. When such specification is missing tools will provide REST interface.

A5 Publish – Re Publish consistency

Tools, and Tools Adapter are the primer responsible entity for identifying CUD elements (CREATE, UPDATE, and DELETE)

A6 SII Resources Common semantic models are maintained by the SII which is the owner of resources in these models, stored in the SII repository (see also A1 above).

A7 Co-Simulation and HiL Co-Simulation and Hardware-in-the-Loop (HiL) interaction with physical devices over the internet uses best of breed technology to facilitate near-real-time interaction. SII is only used to coordinate, set up and share information.

A8 ACID Is a secondary objective

A9 Performance Over SII Is a secondary objective, yet a reasonable ingteractive response time is expected. It is a prime objective for HiL.

A10 Interoperability SII cannot and should not bridge over intranet and will not be used to exchange information directly between tools of different intranets. As depicted in the diagrams in Figure 2-1, tools in each organization intranet work with their own SII server, whether local, or over a cloud service.

3.3 Final Architecture of the Semantic Mediation Container

3.3.1 Concepts of the solution architecture

Initial design of the solution was realized in the first year of SPRINT and presented a solution as depicted in Figure 3-2 below, with a typical tool data-flow as in Figure 3-3. The basic semantic mediation allows tools using different languages to share the common semantic of their languages at some higher abstraction that can indeed commonly abstract all these languages.



1.0 Final 2014-02-18 16 of 63

The common semantic ontology for these tools can be used to describe the structure of designs rather than the behaviour of components, and is termed Basic Structure Ontology (BSO), with close relation to SysML ‎[12], but limited to classes, instances of classes as parts of larger

elements, connectors, data elements that flow in these connectors, which connect through flow ports. This limitation can still make meaningful engineering models.

9 November, 2011 5

SysML DoDAF

IBM Rational Rhapsody

IBM System

Architect

Common

Language

Read/Write

Modelica

Math-Modelica

Simulink

MATLAB/Simulink

Modelling

Language

Software

Tool/Application

OSLC

(Open Services for Lifecycle Collaboration)

SemanticsRDFSemantic

Mediation

IoSE Story in a Nutshell - 2

Figure ‎3-2: Exchanging models from different tools via the common semantic model

Taking for example the flow of data from Rhapsody to the repository, this is depicted in the next Figure 3-4, showing a sequence of activities following the interaction of the sequence diagram in Figure 3-5. That sequence diagram is the implementation of the tool-specific protocol, which is shown in the overall block architecture diagram (Figure 3-1) as items ‎(7) (in the tool) and ‎(1) (in

the server).

9 November, 2011 17

Step 2:

Plain RDF Model

Step 3:

OSLC-AM RDF Model

Step 4:

Common Model

OSLC extension

SII [Rhp-plugin]

SSI [SM]

RDF

OSLC-AMRDF

OSLC-?RDF

Common Semantic

SII Repository

IBM Rational RhapsodySysMLStep 1:

SysML Model Tool provides the translation into

plain RDF.

Tool post the RDF to SII.

Tool plugin in SII takes care of

transformation to OSLC

NOTE: In this step there are may

different versions of the RDF

representation (*.nt, *.rdf)

NOTE: In this step there are just the

OSLC domain-specific versions.

Translating the OSLC-AM RDF into

a common model using the Common

Semantic meta-model of the SSI.

Physical adding of the common

model to RDF repository.Step 5:

Common Model in

relation to other

common model

elements

SPRINT Data and Control Flow – upload models

NOTE: After this step just one

model exists. This is an OSLC

extension

NOTE: Tool uses RESTful POST

API

Figure ‎3-3 – The flow of model data into SII from Rhapsody

3.3.2 IoSE tool interaction protocol - OSLC

The OSLC REST protocol three flows are described in Figure 3-5:

(1) Initial model posting to the server



1.0 Final 2014-02-18 17 of 63

(2) Getting that model by another tool to initiate its own model

(3) Posting an update to the SII model by that last tool.

9 November, 2011 27

Adding a new

element into the

Lyo SII

Requesting a

element from the

Lyo SII

Modifying an

existing element

from the Lyo SII

1

3

2

Rhapsody MathModelica SII

createAnnotation

{plainRhpRDF }

post({plainRDF , ID} )

add(bsoRDF )

all_bsoRDF

{ URL, ID}

SII-Rep .

createBSO (plainRDF , URL )

createAnnotation

transform (bsoRDF )

post ({plainRDF , ID, URL} )

getURL (FQN)

createBSO (plainRDF )

update(bsoRDF )

{URL, ID}

add(bsoRDF )

getBSO (URL )

createAnnotation

get(URL_root )

get(URL _root )

Figure ‎3-4 – IoSE-specific RESTful protocol between SII and tools.

(1) The first flow is the posting of new model data into the server from the MathModelica (now SystemModeler) tool. That is also the flow shown in Figure 11 - for the Rhapsody tool though. In the initial posting of a model data from the tool, an RDF model (instance of the tool’s taxonomy and meta-model) is posted into the server, which in turn converts it to a BSO model and stores the new resources in the SII repository. In response to a successful post, a list of matching URIs – those in the SII and those coming from the tool – are returned for the tool to store as annotations (or other means) in the tool for follow up activities.



1.0 Final 2014-02-18 18 of 63

(2) The second flow above is where a second tool (in this case – Rhapsody) is fetching the BSO model into its internal modelling language. Being a new model in the tool, it is fetched via the GET API of the HTTP protocol (on top of which the RESTful protocol is applied). The returned RDF model is queried from the RDF store of SII, converted by the Rhapsody plug-in in the SII to a Rhapsody DRF representation (or any representation preferred by the tool), and returned to the tool. In this particular case, Rhapsody would generate comparable elements in its internal modelling language for the elements obtained from the SII, and also maintain an association between the URIs internally generated in the tool and those coming from the SII.

(3) The third flow is an update of an existing shared model in a tool with the SII, where some additional elements are modelled in the tool, which have not been previously shared with the SII. The tool posts to the SII very much like it did in the first flow, yet at this time, a target elements in the SII model (BSO model) is already identified so that only the new elements are converted and stored in the SII RDF, associated with the older identified elements which are not recreated, nor duplicated.

3.3.2.1 OSLC Support on the SMC

OSLC support on the SMC is according to the standard and can be queried along the following steps:

3.3.2.1.1 Looking at the Jazz/DM Root Services

On the SMC server – a Jazz/DM server – this is the root services initial query URL: https://<host>:<port>/dm/rootservices. E.g., https://sprint.haifa.il.ibm.com:9444/dm/rootservices,

resulting with this next report:

Figure ‎3-5: Root services of Jazz/DM, including the SMC services.

3.3.2.1.2 Looking at the SMC OSLC service providers

Clicking on the link for the amSeriviceProviders of SMC as highlighted in Figure 3-5, that is https://sprint.haifa.il.ibm.com:9444/dm/sm/oslc_am, brings up a summary of all the OSLC service providers of the SMC project, as is listed on Figure 3-7, with more details of a certain service provider in this next Figure 3-6:

Figure ‎3-6: Rhapsody tool models service provider

The information is according to the OSLC specifications and also states the organization providing these services, the OAuth protocol specifications.

3.3.2.1.3 The OSLC Services of the SMC OSLC Service Providers

Clicking any of the links of Figure 3-7 will bring up information per that specific service provider. For instance, https://sprint.haifa.il.ibm.com:9444/dm/sm/repository/rhp_2014, is the link for the Rhapsody repository. Clicking this link brings up the display in Figure 3-8 below, showing, title, description, and the associated ontology of that tool. There are three areas marked with numbers:

https://sprint.haifa.il.ibm.com:9444/dm/rootservices

https://sprint.haifa.il.ibm.com:9444/dm/sm/oslc_am

https://sprint.haifa.il.ibm.com:9444/dm/sm/repository/rhp_2014



1.0 Final 2014-02-18 19 of 63

1. Query capability, using the link https://sprint.haifa.il.ibm.com:9444/dm/sm/repository/rhp_2014/resource. Clicking this link brings up a response to an OSLC query which will list all the resources in this repository – as shown in Figure 3-9 as a result of actually specifying some conditions on this query for a certain type of resources.

2. Selection dialog capabilities is the link https://sprint.haifa.il.ibm.com:9444/dm/sm/?id=Prt-2883&action=ShowList, which responds with an HTML visualization page.

3. A list of all the name-spaces recognized and coded by that service provider. This helps when writing OSLC queries via the query capability. These name-spaces are used in the query example of Figure 3-9.

Figure ‎3-7: OSLC Service providers of the SMC

https://sprint.haifa.il.ibm.com:9444/dm/sm/repository/rhp_2014/resource

https://sprint.haifa.il.ibm.com:9444/dm/sm/?id=Prt-2883&action=ShowList

https://sprint.haifa.il.ibm.com:9444/dm/sm/?id=Prt-2883&action=ShowList



1.0 Final 2014-02-18 20 of 63

Figure ‎3-8: Details of the Rhapsody repository OSLC service provider

Figure ‎3-9: Query result for all resources which are “a” FlowPort

Figure ‎3-10: Reviewing the first resource in the query results shown in Figure 3-9, which is “a” FlowPort in the Rhapsody ontology.



1.0 Final 2014-02-18 21 of 63

3.3.3 The Extended SMC Protocol (Over OSLC)

The SMC extends the OSLC protocol to an exchange of full models rather than the basic CRUD steps of the RESTful protocol of OSLC. That protocol is shown in the diagram of Figure 3-11.

Client tools communicate with the SMC in HTTPS (OAuth) over this protocol, where the OAuth specifications are defined in accordance with OSLC – as described in the previous section.

Figure ‎3-11: Simplified flow diagram for the SMC protocol

The major distinction is that a POST action over a model exports multiple resources of the model, perhaps even the full model in an RDF payload to the SMC, with user credentials. User is validated for access and payload is validated for correctness as an RDF graph. When stored into a repository it triggers a chain of mediations (that are not shown in this diagram), but a response is returned of pairs of URLs – those URLs defined in the RDF, and those URLs created for (or matched with) them in the repository. This list of pairs is also termed “associations” in the protocol.

The rule of conduct is that the entity which exports keeps the association information so that whenever the model is re-exported, the association information is integrated into the exported model. This helps SMC identify which resources are not new in the target recipient of the mediated model. The benefits are clear; without this mechanism, each time a tool re-export the model, it will create a whole new set of new resources in the recipient rather than update it.

In a bit more details, when a model is exported, given that the association information is available to the exporter, every resource <r> in the model is added an additional triple

<r> sm:hasSmResource <paired resource to r> .



1.0 Final 2014-02-18 22 of 63

Where, sm: is the namespace (http://com.ibm.ns/haifa/sm#) of the “SMC ontology” – a built in ontology consisting of the concepts introduced by the SMC and used to manage it and the mediation process.

3.3.4 Sharing Objects through the SMC

The purpose of this capability is to support heterogeneity of content over the SII/SSI – which are the IoSE environment using the SMC platform. Prime usage case is of FMU (Functional Mock-up Units of the FMI‎[24]‎[25] standard) – see also section 3.3.5.2 below, and for performing distributed

testing, sharing pictures, reports of any kinds, and so forth.

The SMC attachment service consists of a repository – PrtAR and ontological properties (in the SM ontology) that can be used by model designers (or ontology authors) to create SMC identifiable relations with such attachments. The internal attachment repository PrtAR is not mandatory when using this feature and any active URL of the attachment unit can be used instead.

The relations between the PrtAR repository and other repositories in SMC are depicted in the next Figure 3-12. The ontology structure related to attachments is also diagramed in the following Figure 3-13, and the protocol showing how would a tool publish an attachment (e.g., an FMU) and associate it with a certain model element resource is the flow diagram of Figure 3-14.

Fuller details are provided in the Prototype III public report.

Figure ‎3-12: The attachments architecture of SMC

Figure ‎3-13: The SM ontology, including the properties pertaining to the attachment semantics of SMC.



1.0 Final 2014-02-18 23 of 63

Figure ‎3-14: Flow diagram of tools creating an attachment and associating it with a model element.

3.3.5 Validation Scenarios

The overall scenarios implemented for Y3 follow a similar variety of used cases as in Y2, yet extended in their capacity and expressiveness richness over the same underlying technology of semantic mediation which is not hard coded and not tool-specific at the coding (i.e., Java) level, but at the semantic ontological level. There are several scenarios described in the following sections:

3.3.5.1 Model Sharing

Using semantic mediation, 3 tools share models using their own ontologies, with a common BSO ontology service as an intermediary. A typical mediation flow is shown in Figure 3-12 as follows:

(1) Rhapsody exports a model directly to the RhP repository (and OSLC service provider), using the SMC extended protocol.

(2) Automatic mediation step flows the model to the BSO repository.

(3) Automatic mediation step flows the BSO model to the Wolfram SystemModeler repository and ontology.

(4) Automatic mediation step flows the BSO model also to the DESYRE repository and ontology.

(5) SystemModeler can now import a model from its repository as a SystemModeler model in the Modelica language.

(6) DESYRE can too import a model from its repository, and create is in its own workspace using its own language.



1.0 Final 2014-02-18 24 of 63

Figure ‎3-15 – Semantic mediation status at end of Y2

The semantic mediation platform of SMC has been exploited in the DANSE project in which additional tools interact in a similar way as depicted in the next Figure 3-13.

Figure ‎3-16: Mediating between Rhapsody UPDM through a generic UPDM with the System Architect NAF models – a DANSE EU project scenario.

3.3.5.2 Model Behavior Sharing

Model behavior is defined differently in each modeling tool and serves also as a differentiator of that tool. In Rhapsody that is defined with state-charts. In Simulink and in Modelica tools – that is done differently.

The SPRINT approach is to view this aspect of design in the domain of (co-)simulation, for which DESYRE is a prime tool of execution and monitoring, and with the FMI‎[25] standard. The SMC

support for that aspect is via attachments so that FMU units of functional mock-up, generated by Rhapsody or SystemModeler are shared over the semantic mediation platform.

The concept adopted in this case is that not all modeling information needs to be shared. FMI is one of the fruits of this thinking, allowing to integrate diverse technologies together. The testing with Elvior TestCast, using XMI objects adopt the same concept. Moreover, the sharing of contracts for analysis of models and of the physical device HLA interface details – are all part of the same philosophy – providing the extra information as properties over the models shared with mediation. Tool comprehending the structure being mediated, and whose semantics are formally



1.0 Final 2014-02-18 25 of 63

defined, can also find the necessary additional information they need – so does the TestCast tool, and so does the DESYRE tool, and so do the physical devices integration tools.

The means to obtain these properties is supported as part of the OSLC capabilities of the SMC platform.

3.4 The SMC Mediators

3.4.1 The SMC Mediator Framework

If the SMC is the realization of the SII framework of SPRINT, than mediators is the realization of the SSI idea of SPRINT. This section describes how this realization should be implemented, and how it is installed into the runtime environment of the SMC.

The mediators are software components which implement a specific Java interface, and which are integrated into the SMC as plugin Eclipse projects, and which implement an “Interceptor” design pattern. The interface is listed in Appendix 9.1.

To install a mediator into the SMC, it needs to extend an “extension point” as a plugin of the SMC, and that is done in the plugin descriptor file as in the example in the next figure for the IBM mediator, extending the com.ibm.dm.sm.container.interceptors.SmMediator extension point.

As can be seen in this figure there are several possible medaitors, and there are additional mediators that can be added to the SMC runtime as long as they are implemented in plugin projects which extend the proper extension point.

That extension point allows to define the following properties:

Name – the name of this mediator as it will be identified in the SMC configuration web console.

Class – The implementation Java class of the interceptor to carry out the mediation process.

Description – a more detailed textual description of the mediator’s function

RequireLicense – a Boolean flag indicating whether the configurator of this mediator needs to agree to some licensing terms.

LicentText – a textual description of the terms of the license which is shown in case the configurator wants to agree to these terms when configuring the mediator.

Figure ‎3-17: Installing a mediator in the SMC by extending an SMC extension point.

3.4.2 The SSI – SPRINT Semantic Mediation via Ontologies

The Semantic mediation framework in SII is introduced in three levels of complexity.



1.0 Final 2014-02-18 26 of 63

1. The basic level has been demonstrated in Y1. This level consists of a simple transformation from a subset of a tool-specific model to a common model and vice versa. A single step in each direction.

2. The next level of elaboration is depicted in Figure 3-18, showing a multi-staged path over several levels of abstractions, each represents a common semantic meta-model at increasing commonality levels. In fact, the basic level of Y1 is a simplification of this diagram using a single stage, going from the tool-specific model data to the repository and back.

a. At the structure aspect of model data, flowing through this multi-stages processing path (sown on the upper side of this diagram), there is a quick departure from the proprietary tool-specific structure to a common standard structure of the OSLC (extendible) structure.

b. At the format aspect, there is a quick departure from the tool specific and proprietary model representation format into the RDF format. That aspect is marked on the bottom of this diagram. The conversion from the proprietary format to RDF is pretty mechanical and can be done within the tool (or its proxies – see block architecture diagram in Figure 3-1), so that the data transferred into SII is already in RDF, yet (as can be seen on the top of this diagram) initially it corresponds to a proprietary structure according to the tool’s meta-model (or language).

c. The first stage is indeed tool-specific and it complements the work done in the tool to transform the tool-specific structure or language by which the model is defined, into an OSLC compliant structure. That can already be some common domain-specific meta-model. That is marked in this figure by showing a specific OSLC domain modelling language at this early stage. Such a domain may play a common target to tools in that domain.

d. The follow-up stages after the initial one are all working within the RDF format. Each of these subsequent stages is a refinement of the model data to more common meta-model languages. All of these stages are additions missing from the simple basic Y1 case.

9 November, 2011 16

SII – SPRINT Information BusSSI – Semantic Services Integration

Common semantic

Tool

domain

Plugin

R

SII RDFRepository

Proprietary Tool format

RDF format of Proprietary Tool structure

One of intermediary OSLC domain structures

Intermediary OSLC format step 1

Intermediary OSLC format step 2

OSLC CommonSemantic structure

RDF formatProprietary

format

OSLC structure Proprietary structure

ExportTransformTransformTransformTransform

Domain

Interm 1

Plugin

Interm1

Interm 2

Plugin

Interm 2

common

Plugin

Data processing path T

OSLC

RDF

OSLC

RDFSII Repository

Example:IBM Rational RhapsodySysML

RDF

SPRINT Platform Server Dataand Control Flow

Figure ‎3-18: The staged flow of models into and out of the SSI components of the SII (i.e., the SMC).

3. An elaboration of the simplified path into a tree of common meta-models as diagrammed in the following Figure 3-19, showing multiple tools, each with its own language, where



1.0 Final 2014-02-18 27 of 63

intermediate common models are used. In this level, there are multiple multi-staged paths from tools to the SII RDF repository and back, each path is termed “Semantic Mediation flow”, and the collection of such flows constitute a “Semantic Mediation Network”. While a comprehensive discussion of the he semantic mediation concepts is presented in WP3 deliverables, a public version is also presented blow.

Projection

Semantic Mediation

Tool BTool A

SII / RDF Jazz Repository

Tool AVocabulary

Tool BVocabulary

Tool DVocabulary

Tools

Vocabulary

Domain AB

Tool C

Tool CVocabulary

Vocabulary

Tool D

Domain CD

Semantic Mediation

Data Storage

(without transformation)

Syntatctic conversion

(data import/export)

Figure ‎3-19: Multi common meta-models within a multi staged mediation tree of processes.

3.4.2.1 Mediated Models vs. Relations

A schematic diagram of the data processed by the semantic mediation is depicted in Figure 2-20 below with a combined diagram of all involved parties. On the two sides are two different tools’ models (represented with a single RDF triple for a single model element – the “car”), using taxonomies of the tools, yet we assume that the format is already taking the shape of the RDF graphs of triples. The model element car is modelled as having a Rhapsody type predicate rhp:type to a Rhapsody rhp:block. On the right side, a SystemModeler instance of this car, has the SystemModeler type predicate wsm:type, with a Modelica wsm:MModel.

The correspondence between these two triples is obtained via a transformation shown in the middle representing any complex application of mediation rules which create the relation rdf:type to the BSO bso:component element. The BSO bso:component is the extension applied in SII to represent the commonly semantic notion of a Block in Rhapsody and of MModel in SystemModeler.



1.0 Final 2014-02-18 28 of 63

Figure ‎3-20 – Mediation and relations among SII resources and tools' resources.

Having this process in place, we now identify three model elements of the car: the one in Rhapsody (on the bottom left), the one in BSO in the middle, and the SystemModeler one on the right. Each of these elements is owned by another entity, being it the Rhapsody “GUID” space, the SII OSLC resources space of the SII server in use, and the SystemModeler unique identifiers name space.

In the bottom of the diagram, we notify this relation with a “same-as” relation, which in the OWL ontology language is specified as the following relation triples:

1. rhp:block owl:equivalentClass bso:component .

2. wsm:MModel owl:equivalentClass bso:component .

The first relation is used to mediate Rhapsody to BSO and back. The second relation is used to mediate BSO to SystemModeler and back. Note that these are totally symmetric relations (according to the OWL interpretation that we adopt here), and therefore can be used for any transformation direction.

This relation helps to create a global picture of the collaborative modelling environment of SPRINT. In SMC, such relations constitute a “Rule” ontology which governs the mapping done in this process. More specifically, this rule is an inference rule which can drive an inference engine which works over these RDF models and constructs new entities and relations accordingly. The process which implements this inference process is a mediator interceptor within the SM container framework.

A short user guide for the mediation rules used in the SPRINT mediator is provided in the appendix chapter 9.3 at the end of this document.

3.5 Low level SMC architecture

The SM container is the “Semantic Mediation” framework which activates “Semantic Mediators” which are interceptors of services, invoked by the container to service exportation of models and importation of model parts with tools.

The SM container architecture is given in Figure 3-21, with details of the tool interface depicted in the following Figure 3-22. The architecture can should be viewed in reference to the comprehensive architecture diagram of Figure 3-1 at the top of this chapter. Showing what of that



1.0 Final 2014-02-18 29 of 63

elaborate description has been implemented for SPRINT, and which is adequate for delivering the use cases required in the project.

In practice, SMC is a plugin of the Design Management (DM) Jazz application. DM is a server which works with the Jazz Team Server to manage projects, users, and work spaces. SMC being a plugin of DM resolves all the issues of managing these resources for the SII, and providing also through extension points the hooks by which mediators – that implement the SSI part of the SPRINT solution – can be installed and later on to be configured.

Figure ‎3-21: Architecture schematic of the Semantic Mediation container over Jazz/DM

Tools need to extend with the drivers that can bridge their internal representations and languages to the RDF format of models, according to the ontologies which represent these languages.

The next figure highlights the concepts included in the SMC framework, and which are used to configure it for practical use cases. These are detailed in the next sections, and are highly detailed in the final prototype document‎[23].

Figure ‎3-22: Configuring the semantic mediation container for a tool collaboration through model exchange

3.6 Managing the SMC

3.6.1 User levels of the SMC

We identify 4 levels of SMC users:

1. Engineers

Users of tools who are not agnostic to their working environment and are aware of remote information resources, and the notion of sharing models with SMC, and importing models from that environment.



1.0 Final 2014-02-18 30 of 63

2. Power users

Ontological and semantic-web experts who can enhance interoperability capabilities, create ontologies and write ontological mediation rules.

Special tools experts, such as the DESYRE tool. Other special analytic tools will also come with their integration expertise.

3. Eco-system designers

IT specialists who manage IP zones, security and access rights.

Managers of containers, servers and complex distributed projects structures and relations

4. Tool vendors

Develop adapters and agents to implement collaboration protocols, adopt modeling techniques

The SMC comes with several means to help at some of these levels:

At level 2, for ontology experts, there is a Protégé plugin which integrate that popular tool with the SMC environment, allowing the ontology expert to create and modify ontologies and tools residing on the SMC platform.

At level 4, there is the SMC software development kit (SDK) for tool vendors. This kit comes with a library of OAuth, a library of methods to execute the SMC protocol, and a UI implementation of the dialogs for users of these tools to operate the model sharing activity.

3.6.2 The SMC configuration console

In the SPRINT validation example, we demonstrate a simply mediation network as in the diagram of Figure 3-26. This configuration has been created with the SMC web console application in the next figure.

Figure ‎3-23: SMC Console for the SPRINT validation use case.

The console shows 4 relevant sections: The ontologies, in which the specific ontologies involved are:



1.0 Final 2014-02-18 31 of 63

1. (Ont-137) “Rhapsody SysML”, with name space http://com.ibm.ns/rhapsody/haifa/sm#,

2. (Ont-198) “System Modeler”, with name space http://www.wolfram.com/wsm-rdf/,

3. (Ont-203) “BSO”, with name space http://www.sprint-iot.eu/bso/,

4. (Ont-299) “BSO-desyre”, with name space http://www.sprint-iot.eu/bso-desyre/ .

There are the 3 rule sets to mediate between these the 3 tool ontologies and the BSO:

1. (Rul-2796) “BSO2BSO” with name space http://www.sprint-iot.eu/owl/ontologies/BSOAndBSO.owl which mediates between the two BSO ontologies.

2. (Rul-2881) “Rhapsody/BSO Rules - 2014” with name space http://www.sprint-iot.eu/owl/ontologies/2014/RhapsodyAndBSO.owl, to mediate BSO with the Rhapsody tool ontology.

3. (Rul-2882) “SystemModeler/BSO Rules – 2014” with name space http://www.sprint-iot.eu/owl/ontologies/2014/ModelicaAndBSO.owl, to mediate BSO with the Wolfram SystemModeler tool ontology.

The “operational” network consists of the 4 repositories, one for each tool and one for the intermediary BSO:

1. (Prt-2883) – “Rhapsody-2014”, using the Ont-137 ontology.

2. (Prt-2884) – “BSO – 2014”, using the Ont-203 ontology.

3. (Prt-2885) – “SystemModeler – 2014”, using the Ont-198 ontology.

4. (Prt-2886) – “BSO Desyre – 2014”, using the Ont-299 ontology.

The mediators used among these repositories are defined in the “Mediator” section, and the entire operational graph is diagramed automatically by the SMC as in the next figure.

Figure ‎3-24: Operational graph of the mediation network used in the validation use case.

There are 6 mediators defined in this network between the BSO and the 3 tools, 2 mediators per each pair of tools in this “star” architecture, working each in one direction, even though they can (and in our case indeed do so) use the same rule-set. Since the mediator used is capable of interpreting the rules in both directions, it is used by both mediators:

1. (MDT-2887) “Rhapsody-To-BSO(2014)”, whose input is the Rhapsody repository (Prt-2883), and output is the BSO repository (Prt-2884), using ruleset “Rhapsody/BSO Rules - 2014” (Rul-2881), and the “Haifa Semantic Mediator” implementation.

2. (MDT-2888) “BSO-To-Rhapsody (2014)” is mediating in the inverse direction, and is similar to Mdt-2887 above, just inversing the input and output ports (repositories).

http://com.ibm.ns/rhapsody/haifa/sm

http://www.wolfram.com/wsm-rdf/

http://www.sprint-iot.eu/bso/

http://www.sprint-iot.eu/owl/ontologies/BSOAndBSO.owl

http://www.sprint-iot.eu/owl/ontologies/BSOAndBSO.owl

http://www.sprint-iot.eu/owl/ontologies/2014/RhapsodyAndBSO.owl

http://www.sprint-iot.eu/owl/ontologies/2014/RhapsodyAndBSO.owl

http://www.sprint-iot.eu/owl/ontologies/2014/ModelicaAndBSO.owl

http://www.sprint-iot.eu/owl/ontologies/2014/ModelicaAndBSO.owl



1.0 Final 2014-02-18 32 of 63

3. (MDT-2889) “BSO-To-SystemModeler (2014)” is mediating from the BSO repository to the SystemModeler repository, using the ruleset “SystemModeler/BSO Rules - 2014” (Rul-2882), and the same “Haifa Semantic Mediator” implementation.

4. (MDT-2890) “SystemModeler-To-BSI (2014)” works in the inverse direction to the mediator MDT-2889).

5. (MDT-2891) “BSO-To-BSO_desyre (2014)”, is mediating from the BSO repository to the BSO-Desyre repository, using the ruleset “BSO2BSO” (Rul-2796), and the same “Haifa Semantic Mediator” implementation.

6. (MDT-2892) “BSO_desyre-To-BSO”, works in the inverse direction to mediator (Mdt-2891).

In Figure 3-24, we also specify for the different repositories their access URLs. That is since these repositories have the same ontology as the tool, and are defined as “Direct” meaning that tools can post and get directly to them w/out any mediation (or what was known in SPRINT in earlier versions as the “Null Mediator”. That mediator still exists and can be used for various purposes as needed. The access points as appearing in that figure are:

1. /dm/sm/tool/rhp_2014 – where that is the URL path following the machine:port parts of the URL. The complete access URL for the SPRINT server on the IBM yellow-zone server is: https://sprint.haifa.il.ibm.com:9444/dm/sm/tool/rhp_2014. This is the access point for the Rhapsody tool, for this particular repository.

2. For the SystemModeler tool, the access point is https://sprint.haifa.il.ibm.com:9444/dm/sm/tool/sysmod_2014.

3. For the DESYRE tool, the access point is https://sprint.haifa.il.ibm.com:9444/dm/sm/tool/bso_desyre_2014.

We are not showing the details of configuring each of these items. Yet, to complement the description of the SSI integration via mediators, the information that is provided in the plugin configuration file by extending the com.ibm.dm.sm.container.interceptors.SmMediator extension point, here is where the mediators discovered by the SMC from these installed mediators is presented to the administrator:

Figure ‎3-25: Configuring a mediator shows the choice of implementation installed in the SMC as interceptor plugins.

https://sprint.haifa.il.ibm.com:9444/dm/sm/tool/rhp_2014

https://sprint.haifa.il.ibm.com:9444/dm/sm/tool/sysmod_2014

https://sprint.haifa.il.ibm.com:9444/dm/sm/tool/bso_desyre_2014



1.0 Final 2014-02-18 33 of 63

3.6.3 The SMC utilities

SMC offers a few utilities to help working with the environment as power users who need to define onotologies, and as vendors who need to implement SMC drivers for their tools.

3.6.3.1 Authoring ontologies with Protégé

The most popular ontology authoring tool is Protégé – its console view is depicted in the next figure with a diagramming of some ontology. It is

An open-source ontology editor – http://protege.stanford.edu

Provides stand-alone client, and web client (“Web-Protégé”)

Is extensible through a “plugin” framework.

SMC extended Protégé with a plugin which enables to work with SMC ontologies and rule-sets directly from the Protégé console (see Figure 3-26).

The SMC plugin is installed in the Protégé installation location on the computer and is discovered when Protégé starts up, as depicted in Figure 3-27.

Figure ‎3-26: The Protégé console. The model explorer and the model graph visualization.

Once started, the plugin is initializing its dialog as seen in the next figure with the annotated explanation of each area on this dialog and its behavior. In essence, the relevant configuration information also appears on this dialog, allowing applying filters, select rule-sets or ontologies to be loaded to Protégé, at which point the ontology can be edited as any loaded ontology with this tool.

Figure ‎3-27: Protégé discovery of its plugins, including the SMC plugin.



1.0 Final 2014-02-18 34 of 63

Figure ‎3-28: The SMC plugin dialog for loading Protégé with SMC ontologies or rule-sets.

The usage of Protégé with SMC is detailed in the SPRINT final prototype document‎[23].

3.6.3.2 Implementing clients with the SMC SDK

As describe in the final prototype document ‎[23], here is again a short description of this facility.

The SMC Software Development Kit is intended to help tool vendors to join the SMC eco-system and it comes as an Eclipse project that includes:

1. Jar of an implementation which offers:

1. Implementations of the SMC export/import protocol. The client uses this API to work with the RDF model it wishes to export, and with RDF models obtained as imports. The client tool needs to develop the conversion from/to its internal format and the RDF format.

2. A Java GUI panel (see Figure 3-29) with which a user can operate the model exchange with the SMC server, executing export/import activities while taking care of logins, working with files as well as network, and keeping up booking of URL associations.

2. ANT script for importing needed open-source jars to build up the application

3. JavaDoc documenting the API.



1.0 Final 2014-02-18 35 of 63

Figure ‎3-29: UI dialog of the SMC SDK

3.6.3.3 Browsing SMC contents via the web console

From the configuration web console, users can access content of repositories through a built-in OSLC access services, to view entire models, individual resources in the models, and even editing elements in the models.

Excessive services beyond OSLC open up SPARQL querying of model content, and for comparison of model revisions. Beyond that, models of ontologies – which are also RDF structures, yet not being resources managed by the SMC like repositories – the browsing capabilities are more limited, but comparable per viewing content and comparing revisions.

In addition, this facility opens up more possibilities such as graphing diagrams of models, of configurations, and of operational mediation networks. Mediators can also be tested, the associations of resources being mediated among repositories (local and remote) can also be browsed to validate and examine how the mediation has been done. All these capabilities are discussed at length in the prototype III document, and are represented her with a few screen shots as follows:

1. Browsing a model in a tabular format

2. Browsing individual resources of a model

3. Querying a repository with SPARQL

4. Viewing the association of a mediator

5. Log of a mediation flow execution.



1.0 Final 2014-02-18 36 of 63

Figure ‎3-30: Browsing in the “Table view” of an RDF – for a repository, or an ontology.

Figure ‎3-31: Modifying an individual resource via the browser



1.0 Final 2014-02-18 37 of 63

Figure ‎3-32: The SPARQL query dialog of SMC

:

Figure ‎3-33: Viwing a mediator shows the browseable URLs of its associations

Figure ‎3-34: SMC Log of jobs execution.



1.0 Final 2014-02-18 38 of 63

3.7 SII Agents and Internal Applications This part of the comprehensive SII architecture described at the top of this chapter is not implemented or architected in the SMC realization of SII. Such agents and internal applications are still possible to implement and add to the SMC container framework, but they can also be implemented as external tools to the SMC, much like any of the other design, testing and simulation tools.

There is no real justification to use the SMC for that, although this line of thought may change in future considerations. Therefore, this part of the document that was discussed in earlier versions is removed.

3.8 Distribution of the SMC The distributive aspects of the SMC are important for two reasons:

1. The project requirement that SII can support a collaborative work among partners over the internet, and manage the sharing of design artefact through that.

2. So that the SII is scalable. In this case – scaling out through the plurality of servers.

The initial versions of SII have implemented a distributive capability at the level of work spaces managed by Jazz. That architecture has been considered generic and powerful as it creates a facility that can be used by all Jazz application. Therefore, its scope is much beyond SPRINT SII, and is not appropriate for the scope of such a project.

A more practical solution through the concepts of SMC have been introduced and implemented in SMC to support that capability.

The SMC supports distribution through two type of items: An “Exporter Port”, and a “Friend”. The Friend is the specification of another server to which it is possible to connect for the purpose of model exchange using the SMC extended protocol – same one that is used with engineering tools. The Exporter is a type of a Port (which is SMC mean an entity that can serve as a source of model data, or as a sink to which model data is delivered – we have not discussed these concepts in this document referring the reader to the details in the final prototype document‎[23]).

The combination of these two concepts works as follows:

1. A “Friend” item identifies a remote SMC server via its URL – machine address and port. This means that multiple SMC servers can reside on the same machine IP address. This item also holds the credential by which the remote server will be accessed. More elaborate solutions for such “friendship” can be applied in the future. Therefore, in a given configuration, the remote friends of a server are accessed with the credentials of a user, rather than as a server.

2. The “Exporter” port type is associated with a certain entry point of a certain Friend item. This is in fact a link to that remote server. There may be many such links.

Example:

The following Figure 3-35 depicted Exporter Prt-546, associated with the Friend SMC Frn-545. Having tested that friend for a certain IP address and port, and a certain user credentials, it has been marked as ready in its status field. On that SMC server, the access name “rhp4cae” is defined for some post port, and that name has been entered for the access name field on the Exporter Prt-546. When that Exported has been updated with this information, the remote SMC friend has been queried based on that and returned the ontology namespace associated with that port. This information – in turn – was resolved against the ontologies defined in the local SMC, which matched that of Ontology Ont-137 – see marked area in red in the next figure. This Exporter is now ready as is also marked on its Status field – also marked red in this figure.



1.0 Final 2014-02-18 39 of 63

Figure ‎3-35: Configuring a remote SMC Friend, and the Exporter Port to connect with it.

When processing, a mediation network may be created to flow into remote servers, and then even back to the same server and so on.

3.8.1 Inter Corporate Collaboration

This aspect of the SII has been considered a requirement, though not one that was expected to be solved within the SPRINT project. The distribution solution through the above mechanism does not support that, and neither the protocols of SMC. The exchange of data is protected through the OAutho protocol inherited from OSLC and the Jazz/DM platform to which the SMC is a plugin, but not the enforcing of hiding of portions of the shared information among collaborating parties.

Engineers should have control on what is it that they want to share. This is a capability of the engineering design tool. In SPRINT, the Wolfram SystemModeler driver, enables the user to select what to share. That is not available on the Rhapsody at this point in time. Any elaboration of this capability, is an extension of the semantics of the SII export. This means that tools will be able to mark what portions of a shared model are protected and let the SMC manage that for them. It would be logical to assume that the best protection is not to share.

In a configuration where each partner owns its own SMC server (cf. Figure 2-3), the protection needs to be defined on the boundaries between SMC servers, those executed via the distribution facility described above, which turns the administration of these rights to be a problem of the SMC administrator.

3.8.2 IT Aspects of the SMC Distribution

One of the user categories of SMC is identified as the IT specialist of manager. This role is responsible for the connectivity over the distributed SMC.

The IT environment has a significant bearing to setting up the operational environment as seen in the next Figure 3-36. Here, two SMC servers play their role across the internet, through the firewalls set up by the two different sites. Any number of such sites is possible to operate and create the logical view in Figure 2-3. Tools work with their local servers and the server’s remote access bridges the distance.

Figure ‎3-36: Distributed implementation of the SII over the internet



1.0 Final 2014-02-18 40 of 63

Another solution is the “Cloud” way – services are installed on the cloud, and client tools communicate with these servers over the internet. This is in-fact the nature of work done within SPRINT by most of the industrial partners – working with their tools against the SPRINT SMC server installed on a YZ (Yellow zone) machine: https://sprint.haifa.il.ibm.com:9444/dm/web. That option is depicted in the next figure.

Figure ‎3-37: Server(s) on the cloud providing SaaS to client across fire-walls, intranets and the internet.

3.9 The SMC Scalability The scalability of SMC is discussed at length in the prototype III report. In essence, this scalability

consists of scale-up of a single SMC server, and scale-out of a distributed configuration.

The scale-up of SMC consists of the following capabilities:

1. Multiple Jazz/DM projects and project areas for individual domains where models,

ontologies and mediation network flows are configured.

2. Multiple focal sub-areas in each such Jazz/DM project area which is managed through the

SMC tagging facility – allowing the user to filter configuration items as if belonging to

different projects, while sharing the same server facility.

3. Efficient mediators – which have been demonstrated as very effective (see execution log in

Figure 3-34 above.

4. On top of that, being a Jazz server, that platform has its own scale-up capabilities through

clustering at the product quality level.

The other factor of scale-out beyond the clustering of SMC servers on a single site, or on a cloud

facility, serves both distributed collaborative eco-system, and scale-out of services over multiple

and disjoint capabilities. This allows specialized SMC servers to participate and contribute their

unique differentiators also at the SMC level, in addition to the variety of tools working with them in

their own protected working zone.

3.10 The SII Clients

https://sprint.haifa.il.ibm.com:9444/dm/web



1.0 Final 2014-02-18 41 of 63

3.10.1 The SMC Software Development Kit for Client Development

The SMC Software Development Kit is intended to help tool vendors to join the SMC eco-system and it comes as an Eclipse project that includes:

1. Jar of an implementation which offers:

1. Implementations of the SMC export/import protocol. The client uses this API to work with the RDF model it wishes to export, and with RDF models obtained as imports. The client tool need to develop the conversion from/to its internal format and the RDF format.

2. A Java GUI panel (see next figure) with which a user can operate the model exchange with the SMC server, executing export/import activities while taking care of logins, working with files as well as network, and keeping up booking of URL associations.

2. ANT script for importing needed open-source jars to build up the application

3. JavaDoc documenting the API.

Figure ‎3-38: UI dialog of the SMC SDK

3.10.2 The IBM Rhapsody Client

The Rhapsody client implements a Rhapsody plugin in which is able to interrogate the internal Rhapsody project data, using a published Rhapsody API, and convert it to RDF. Likewise, it can also convert an RDF back to this internal representation, and even work our merging of these models. Having an RDF ready for export, or being ready to import an RDF and merge it into a project (new or old), is managed through an implementation of the SMC extended protocol, within the OAuth envelop as required by Jazz/DM.

To facilitate all these services, the tool comes with an extended GUI as is detailed in the final prototype document ‎[23]. That is not repeated here, but we share a few screenshots of the Rhapsody model sharing capabilities: 3 steps in exporting a model to an SMC server (Figure 3-39), steps in the import of a model (Figure 3-40), and the export of an FMU object (Figure 3-41), and integrating it into an SMC model (Figure 3-42).



1.0 Final 2014-02-18 42 of 63

Figure ‎3-39: Invoking export of a model element.

Figure ‎3-40: Importing from IoSE (SMC) into a new Rhapsody project.

Figure ‎3-41: Exporting an FMU and integrating into an SMC model.



1.0 Final 2014-02-18 43 of 63

Figure ‎3-42: Integrating the exported FMU object into the SMC model as the “hasFMU” property of some Rhapsody Block.

3.10.3 The Wolfram SystemModeler Client

The SystemModeler client is embedded into its modelling environment, ModelCenter, and provides a graphical user interface that lets the user import and export models from and to DM. When exporting a SystemModeler model, the user can choose to export the model to a file, or to the DM, or to both. Normally the model and all of its dependencies will be converted from the internal representation to RDF. However, to make it possible to protect IP it’s also possible to control the export, on a component basis, so that a component only is exported as a black box. It’s also possible to export the model as an FMU and attach it to the exported model using the attachment service.

Figure ‎3-43: The IoSE export dialog of SystemModeler

When importing, the user can choose to import either from a file or from DM. When importing from DM, the user is required to specify the URI of the model that is to be imported. DM will return the specified model and all of its dependencies. SystemModeler will merge imported elements with existing Modelica elements within SystemModeler as a final stage of the import.



1.0 Final 2014-02-18 44 of 63

Figure ‎3-44: The IoSE import dialog of SystemModeler

3.10.4 The ALES DESYRE Client

The Desyre tool is composed by two major parts: the Desyre simulation engine, which provides a simulation engine to execute models (e.g., FMU components), and a simulation dashboard, which serves as graphical editor of the model and simulation user front-end. The simulation dashboard is interfaced with the DM framework to

Fetch the system architecture model, to use it for contract specification and to setup the simulation

Publish contracts

Fetch FMUs to be executed in Desyre

The user can hence edit the shared model in the simulation dashboard to add contracts on it, or to select and fetch model implementations to be executed by the Desyre simulation engine.

The system architecture is published by Rhapsody or SystemModeler and mediated by the enhanced DM platform into the Desyre ontology. FMUs are not mediated by DM; the FMI standard defines a common format for models, which is supported by the tools connected to the DM platform. Rhapsody and SystemModeler publish model in FMI format, and the Desyre tool fetches and execute them without any modification.

3.10.5 The Fraunhofer Physical Devices Client

The physical devices fetch complete BSO models from the DM via the bulk load interface. This information is then been merged with the physical device meta information and bushed back to the DM server via the same interface. Typical elements been pushed are components, parts ports and types. Connectors are usually not contained and can later be added as input for simulation.




1.0 Final 2014-02-18 45 of 63


3.10.6 The Elvior TestCast Client

On TestCast Generator, a TestCast OSLC Client plugin extends the TestCast Generator API with IoSE Import and Export commands. The client utilizes services of the SMC import/export protocol and allows a client to get any resource in any repository managed by the SMC as well as put (update) it with new information such as the TestCast produces.

The TestCast OSLC client enables the user to

Provide the repository connection and request parameters as the server URL and user credentials

Fetch the requested resources and browse the retrieved model elements

Publish and retrieve attachments as properties of the model component element. The attachments can comprise of test model, test scripts, test execution report, FMU or diagram.

Based on the Rhapsody SysML ontology the TestCast OSLC client allows to associate attachment resources to the element of type Block using attachment services of the SMC. For publishing an attachment the user is promted to select files related to the block and the client posts the files in the attachment repository and adds property to the block with link to the attachment resource. The TestCast plugin supports the following properties of a block: hasTestModel, TestScript, TestResult, hasFMU, hasDiagram.

For importing from IoSE properties of the block element containing attachments the TestCast OSLC client supports download of attachment resources to the local environment. The user can select the property and the client imports attachment associated with that model element from the repository and saves in the file system. The command DeleteAttachment is intended to remove the selected attachment property of the block element.

The next Figure ‎3-47 illustrates the UI of the TestCast OSLC client showing entering the IoSE

communication parameters, browsing the retrieved model elements, publishing and downloading the attachment properties.



1.0 Final 2014-02-18 46 of 63

Figure ‎3-47: The TestCast OSLC client UI: IoSE communication, browsing the retrieved model

elements, publishing and downloading attachment properties



1.0 Final 2014-02-18 47 of 63

4 Testing over the Internet The actors in the Testing over the Internet are shown in the next Figure 4-1 where each of the tools/applications in this diagram may be activated by different Testers in different locations over the internet, as well as working on the model data designed by a different systems engineer.

Figure ‎4-1 – Actors involved in the distributed Testing over the Internet

All the interactions over the internet are using the RESTful protocol under the OSLC standard exchanging information in RDF formats. An exception is with the Test Execution activity in which additional internet protocols to collaborate with other test execution agents can be done over the internet. An example of the distributed execution is depicted in the Figure ‎4-2 , showing the collaboration of different players contributing to the design (in Tel-Aviv), implementation (in Linköping), test modeling for that design and requirements (in London), test scripts generation (in Tallin), test scripts execution (in Haifa), and finally a validation and analysis of the test execution results (in Tel-Aviv) by the design engineer responsible for the tested component.



1.0 Final 2014-02-18 48 of 63

Figure ‎4-2 – Distributed planning and execution of testing over the internet

The Systems requirements based on which the test is designed may be a contract language, or any other language. In the example, that has been the Rhapsody SysML language which is comprised of system structure, component interfaces and behavior definition . Therefore, for different contracts languages, different tools may be involved in this process.

The interaction sequence goes as follows.

(1) System requirement is extracted from the Internet of Systems Engineering (IoSE) and modeled for testing purposes using Rhapsody and TestCast T3 to create a Test Model. This Test Model is stored via an TestCast OSLC client protocol into the IoSE.

(2) A test generator (e.g., TestCast Generator) is pulling the Test Model from the IoSE, possibly in a different location and by a different user, and producing a Test Script. The Test Script is published into the IoSE.

(3) A test execution application (e.g., TestCast T3) pulls the Test Script artifact and the implementation executable from the IoSE and performs a test execution, generating a Test Report document. This step can also be distributed over the internet as described below using the internet with different protocols than REST/OSLC as for the other activities. The Test Report document is published into the IoSE and associated with the respectful model elements.

(4) An Engineer verifies and analyses the Test Results by firstly pulling them from the IoSE. The analysis tool (e.g., TestCast T3) helps the engineer to decide if requirements are satisfied or not, at which case a change request according to these results is issued (not shown in this diagram).

If interface of the System Under Test (SUT) supports communication over the internet then interactions during the test script execution can involve access to the IoSE to get the SUT communication information as shown in Figure 4-3.



1.0 Final 2014-02-18 49 of 63

Figure ‎4-3 – Test execution over the internet sequence diagram

Three mandatory actors collaborate at test execution by TestCast T3 tool – the test executable (TE), the SUT adaptor and the SUT. The SUT adaptor implements the real SUT interface and is responsible to propagate send requests from the TE to the SUT, and to notify the TE of any received test events by appending them to the port queues of the TE.

The SUT adaptor needs to know the SUT port addresses and communication protocols supported by the SUT. By the sequence diagram the activation activities of the SUT adaptor include interaction with the IoSE to get an available SUT and communication information of the SUT.



1.0 Final 2014-02-18 50 of 63

5 Simulation and Co-Simulation

This section refines the general architecture of the SPRINT platform introducing additional details about the logical components that are involved in the distributed HiL simulation.

5.1 Architectural components

User front-end

Monitor

synthesisSimulator

Physical

device

Simulation

coordinator

Simulation

manager

SSI/SII

SIM interface

REST interface

Internet

Figure ‎5-1 – Actors involved in the distributed HiL simulation

Figure 5-1 shows a refined view of the architecture in Figure 2-2. A few additional components have been introduced; their description is provided in the following.

User front-end: the user front-end acts as user interface to the services of the SPRINT platform. It must allow the user to select the available subsystem prototypes, compose them and request their simulation. A modelling tool interfaced with the SPRINT platform can act as user front-end.

Simulation manager: the simulation manager provides a set of high level services to perform a simulation, which abstracts the implementation of the distributed simulation platform. The services of the simulation manager are invoked by the user front-end.

Monitor synthesis tool: the monitor synthesis tool must generate monitors out of contracts. Monitors are needed in simulation to check that the contracts attached to a particular component, which express the requirements on the component behaviour in terms of assumptions and guarantees, are actually satisfied by the component prototype. The architecture may contain multiple monitor synthesis tools to support the generation of monitors from contracts expressed in different languages.

Simulator: a simulator is responsible for executing a subsystem model expressed in a particular modelling language. Multiple simulation tools allow to support the execution of models captured using different modelling languages.

Physical device: a physical device is a physical prototype of a subsystem component. Several physical devices may be part of the distributed simulation architecture.

Simulation Coordinator: the coordinator is responsible for scheduling the execution of the simulators and physical devices, so as to perform a distributed HiL simulation. It is responsibility of the coordinator to synchronize the execution of the simulators and of the physical devices, so as to keep their internal time



1.0 Final 2014-02-18 51 of 63

aligned. In the IEEE1516 standard‎[15] on distributed simulation (High Level Architecture), the functionalities of the coordinator are implemented by the Run-Time Infrastructure module (RTI).

SSI/SII: the SSI/SII layer supports the distributed HiL simulation by providing an inventory of the resources that are available to perform a distributed simulation. All the actors involved in the simulation can hence use the SSI/SII for resource discovery. The term resource identifies here an heterogeneous set of elements, which contains the simulation models and the contracts of a particular subsystem component (previously shared by a user), as well as all the actors which may be involved in the distributed simulation (simulators, physical devices, coordinators, monitor synthesis tools). The SSI/SII must provide the information that are needed to access the services of a particular simulation actor (e.g., a URL of the resource), as well as a description of the resource capabilities (e.g., the kind of models that a simulator is capable of executing). To put in relation the elements in Figure 5-1 with the more general architecture in Figure 2-1, we observe that the simulation manager, the user front-end, the simulator(s), and the monitor synthesis tools, they all play the role of “Applications”.

5.2 Interaction among the simulation actors

As shown in Figure 5-1, all the distributed simulation actors have a REST interface to expose and request services to the other actors. Coordinators, simulators and physical devices have an additional interface (tagged as “SIM” in the picture, and coloured in red) for communication. This interface will serve the communication required during the run-time execution of the simulation, and will use a protocol stack suitable for real-time interaction.

Figure ‎5-2 – Sequence diagram of the distributed HiL simulation

The sequence diagram in Figure 5-2 describes the interaction among the actors to perform a distributed simulation. A user, through the user front-end, accesses the SSI/SII layer to select a set of subsystem prototypes and related contracts out of the modeling elements previously shared by other users. Subsystem prototypes are instantiated and composed together to create a system model, and contracts are attached to the component instances. The user requests the simulation of the system model by invoking a service provided by the simulation manager.

To verify contracts in simulation, a monitor must be generated out of a contract. The simulation manager interacts with the SSI/SII to discover the availability of a monitor synthesis tool capable of handling a contract in a particular language, and interact then directly with the synthesis tool to get a monitor component. Once monitors are available, the simulation manager is used to integrate together the different components, so as to create a system model. The simulation of the system model is required to a coordinator, whose availability is again discovered through the SSI/SII.



1.0 Final 2014-02-18 52 of 63

The coordinator needs to interact with the SSI/SII to identify the available simulators that can be used to execute the models of the subsystem components. After this step, the execution of the simulation can start.

A simulation involves several interactions between the coordinator and the simulators and physical devices to synchronize their executions, as well as frequent data exchange among the models running in the simulators and the physical devices. These interactions occur through the SIM interface.

At the end of the simulation, the coordinator provides the simulation results back to the simulation manager, which in turn delivers them to the user front-end for visualization to the user.



1.0 Final 2014-02-18 53 of 63

6 Internet of Things Comment for revision D5.7:

This section has not changed and represents the accepted architecture for the IOT in SPRINT. A collaboration with the IoT-A ‎[17] project has been started this year and its effect should be felt in

the Y3 review. The architecture adopted by SPRINT for the interoperability of physical devices and simulators according to shared models is sound and stable. This is same as 5.6.

In Figure 2-2 we also depict the internet of things as devices on the same network which also serves the engineers – the IoSE. That is the internet. Yet, there are different protocols for physical devices and for models, namely HLA for devices and simulation, and Http/REST for the models.

Physical devices: The relation of the terminology used here with the IoT-A reference model is discussed in a separate document that is written in parallel to this document. In this document we still use a simple terminology. Physical devices (PD) are physical manifestation of designs in the SII and are enabled to operate over the internet through certain internet communications protocols. A separate chapter in this document described this part of the architecture. The physical devices are registered in the SII model data to indicate their relation with the designs they implement as well as the activation records by which they can be activated over the internet. Devices are of two types:

1. Actuators perform some action based on messages sent to them

2. Readers perform some measurements and send that data to their listener. Readers are activated to perform these readings also via a message.

Coordinator: The physical devices are controlled by a coordinator, which do that based on design data and the physical devices registration information – read out of the SII, and performs this activity over the internet. A coordinator is in fact an application according to the description above.

The protocols used to communicate physical devices with the coordinator are such that can satisfy timing constraints. An example of a coordinator application is a simulator which is extended with the ability to interact with external simulators, where a physical device is a "kind" of a simulator. This part of the SPRINT internet of systems engineering, facilitates hardware in the loop (HiL) simulation capabilities.



1.0 Final 2014-02-18 54 of 63

7 Abbreviations and Definitions

Term Definition

ACID Atomicity, Consistency, Isolation and Durability are the four base properties

which makes a database and ensure its value proposition as a service in a

concurrent and distributed environment.

Application A software program that provides added value on top of tools by applying

functions that have not been addressed by individual tools and that are

possible due to the integration of data from multiple tools.

Applications that add a new value to the data in the SII repository are

referred to as AVAs – Added Value Applications.

AVA Added Value Applications – see Application above.

CRUD Create, Read, Update and Delete – basic atomic actions in working with a

consistent data base.

FMI Functional Mock-up Interface

FMU Functional Mock-up Unit

HTTP Hypertext Transfer Protocol is the communication protocol over the Internet

which is used to connect Web clients (browsers and applications) and

servers.

JIA Jazz Integration Architecture lays out the architecture for integrating

services and application within the Jazz framework.

JTS Jazz Team Server is the core services provider of the Jazz platform

OAUTH An Authentication protocol that is used by Jazz to provide secured

interaction over the internet of users and the Jazz platforms.

Open Services for

Lifecycle Collaboration

Open Services for Lifecycle Collaboration (also known as OSLC or Open

Services) is a community and set of specifications for Linked Lifecycle

Data. The community’s goal is to help product and software delivery teams

by making it easier to use lifecycle tools in combination. (See: http://open-

services.net/html/Home.html)

OSLC See: Open Services for Lifecycle Collaboration

OSLC-AM The Architecture domain of the OSLC specifications.

OSLC-CM The Change Management domain of the OSLC specifications.

OSLC-RM The Requirement Management domain of the OSLC specifications.

Resource Description

Framework

It’s a family of W3C specifications for conceptual description or modelling of

information that is implemented in web resources. (See:

http://www.w3.org/TR/rdf-primer/)

RDF See: Resource Description Framework

SII The Semantic Interoperable Integration information bus platform

SPARQL SPARQL (SPARQL Protocol And RDF Query Language) is a query

language for RDF. http://www.w3.org/TR/rdf-sparql-query/

SSI The Semantic Services Integration layer of SII

http://open-services.net/html/Home.html

http://open-services.net/html/Home.html

http://www.w3.org/TR/rdf-primer/

http://www.w3.org/TR/rdf-sparql-query/



1.0 Final 2014-02-18 55 of 63

Term Definition

SUT System Under Test

Tool A software program that models some aspects of a product's design. Tools

have internal models of the design and can serve as part of a group of tools

that together serve the full engineering process. However, used by itself, a

tool is also an independent program with its own data repository and

management and usability functions that allow users to work with it totally

independent of other tools. A tool generally is said to hold some information

about the engineered system.

UOC Unit of Content is the basic collection of information data (model

components) in a tool and which can be shared with the SII via publication

and/or import.

URI and URL Unique Resource Identifier and Unique Resource Location are standards

for qualified names of tangible resources over the Internet.

REST and RESTful Representational State Transfer is a Web protocol defined on top of HTTP

that helps work with data repositories over the internet while maintaining a

CRUD quality of the data interaction.

XML eXtensible Markup Language is a common textual representation of

structured data for transfer over internet protocols and in use in other

application areas such as model representation and exchange.



1.0 Final 2014-02-18 56 of 63

8 References

[Author, Year] Authors; Title; Publication data (document reference)

[1] OSLC Open Services Lifecycle Collaboration (OSLC), www.open-services.net

[2] Jazz Jazz Integration Architecturte (JIA),

http://jazz.net/projects/DevelopmentItem.jsp?href=content/project/plans/jia-

overview/index.html

[3] RDF Resource Description Framework RDF, http://www.w3.org/RDF/

[4] SPARQL SPARQL Query Language for RDF, http://www.w3.org/TR/rdf-sparql-query/

[5] Eclipse Lyo

Eclipse Lyo Project – Enabling Tools Integration with OSLC (Provides SDK of a Simple

OSLC Reference Implementation) http://www.eclipse.org/lyo/

[6] REST RESTful, Representational State Transfer,

http://en.wikipedia.org/wiki/Representational_State_Transfer

[7] OAuth OAuth, Open Protocol for secure API Authorization, http://oauth.net/

[8] D5.8 "D5.8: Prototype Iteration I"

[9] D5.4 "D5.4 Architectural principles for Internet of System Design and the IoT"

[10] D5.1 "D5.1 "High and Low level design description of System Design and Semantic

Interoperable integration"

[11] Linked data

“Linked Data”, W3C Standard, http://www.w3.org/standards/semanticweb/data

[12] SysML OMG Systems Modeling Language, http://www.omgsysml.org/

[13] Apache Tomcat

Apache Tomcat web server, http://tomcat.apache.org/

[14] ECSAM Jonah Z. Lavi and Joseph Kudish, “Systems Modeling & Requirements Specification

Using ECSAM: A Method for Embedded Computer-Based Systems Analysis,“ 11th IEEE

International Conference and Workshop on the Engineering of Computer-Based Systems

(ECBS'04), http://doi.ieeecomputersociety.org/10.1109/ECBS.2004.1316676

[15] IEEE1516 1516-2010, “IEEE Standard for Modeling and Simulation (M&S) High Level Architecture

(HLA)-- Framework and Rules,”

http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5553440


[17] IoT-A “Internet of Things Architecture,” EU FP7 project,” http://www.iot-a.eu/public/front-

page

[18] D5.9 “D5.9 Prototype Iteration II” of the SPRINT project deliverables.

[19] OWL “Web Ontology Language, ” http://www.w3.org/TR/owl-features/

[20] D3.2 “D3.2 Definition of the Semantic Services Integration Layer “

[21] D5.6 “D5.6 Architectural principles for Internet of System Design and the IoT"

[22] DANSE “Designing for Adaptability and evolutioN in System of systems Engineering,“

https://www.danse-ip.eu/home/

[23] D5.11 “D5.11 SPRINT Final Report” TBD in the SPRINT project public deliverables.


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

http://jazz.net/projects/DevelopmentItem.jsp?href=content/project/plans/jia-overview/index.html

http://jazz.net/projects/DevelopmentItem.jsp?href=content/project/plans/jia-overview/index.html

http://www.w3.org/RDF/

http://www.w3.org/TR/rdf-sparql-query/

http://www.eclipse.org/lyo/

http://en.wikipedia.org/wiki/Representational_State_Transfer

http://oauth.net/

http://www.w3.org/standards/semanticweb/data

http://www.omgsysml.org/

http://tomcat.apache.org/

http://www.computer.org/search/results?action=authorsearch&resultsPerPage=50&queryOption1=DC_CREATOR&sortOrder=descending&queryText1=Jonah%20Z.%20Lavi

http://www.computer.org/search/results?action=authorsearch&resultsPerPage=50&queryOption1=DC_CREATOR&sortOrder=descending&queryText1=Joseph%20Kudish

http://doi.ieeecomputersociety.org/10.1109/ECBS.2004.1316676

http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5553440

http://www.iot-a.eu/public/front-page

http://www.iot-a.eu/public/front-page

http://www.w3.org/TR/owl-features/

https://www.danse-ip.eu/home/



1.0 Final 2014-02-18 57 of 63

[25] FMI “Functional Mock-up Interface,” https://www.fmi-standard.org/.

[26] Interceptor The “Interceptor pattern” in the Wikipedia. http://en.wikipedia.org/wiki/Interceptor_pattern

https://www.fmi-standard.org/

http://en.wikipedia.org/wiki/Interceptor_pattern



1.0 Final 2014-02-18 58 of 63

9 Appendix

9.1 The Mediator interceptor interface package com.ibm.dm.frontService.sm.intfc;

/**

* Interface for a semantic mediation module.

* @author shani

*

*/

public interface ISmModuleIntercept {

/**

* Called by the interception container once a new module is created. For future use

* when a pool of modules is maintained by the container. Should be called once

* per the lifetime of the module.

* @return boolean to indicate that all creation-related processing are completed

* in case a chain of agents may be implemented by the container. A true value indicates

* that no further creation-related work is needed.

*/

boolean created();

/**

* Called by the interception container to initialize the module with specific

* context information so that the module can initialize various states.<br>

* This may be called many times during the life-time of a modul whenever there are

* changes in the context.

* @param context a reference to a context structure TBD.

* @return boolean to indicate that all initialization-related processing are completed

* in case a chain of activities may be implemented by the container. A true value indicates

* that no further initialization-related work is needed.

*/

boolean initialized(ISmModuleContext context);

/**

* Resets state of the module to an initialization type of state.

* @return boolean to indicate that all resetting-related processing are completed

* in case a chain of activities may be implemented by the container. A true value indicates

* that no further resetting-related work is needed.

*/

boolean reset();

/**

*

* @param sourceOntology

* @param sourceModel

* @param targetOntology

* @param mediationRules

* @param targetModel

* @return

* @throws MediationException

*/

boolean invoke(IOntologyHandle sourceOntology, IInputModelHandle sourceModel, IOntologyHandle

targetOntology,

IRulesHandle mediationRules, IOutputModelHandle targetModel) throws

MediationException;

/**

*

* @param ontologyLocator

* @param sourceModel

* @param targetModel

* @return

* @throws MediationException

*/

boolean invoke(IOntologyLocator ontologyLocator, IInputModelHandle sourceModel,

IOutputModelHandle targetModel) throws MediationException;

/**

* Kills the resources used by this module in case the container implements a pool of

* modules so that this module can release all its allocated resources.

* <br>

* Can be called only once at the end of the lifetime of a module.

* @return boolean to indicate that all tear-down-related activities are done in case the

* interception container implements a chain of activities.

*/

boolean tearDown();



1.0 Final 2014-02-18 59 of 63

/**

* Resets the module back to an inactive state that needs to be initialized before use.

* <br>

* Can be called multiple times during lifetime of a module.

* @return boolean to indicate that all close-related activities are done in case the

* interception container implements a chain of activities.

*/

boolean close();

}

9.2 Installing Interceptors via the Plugin Description <extension point="com.ibm.dm.sm.container.interceptors.SmMediator">

<InterceptorClass

class="com.ibm.dm.frontService.sm.service.SmPlainMediationModule"

description="Null mediation, needs no rules, performs no trnasformation over the input

model, produces exactly the same model as the input, should be used only between two models of the

same or compatible ontologies."

name="NullMediator"

requiresLicense="false">

</InterceptorClass>

<InterceptorClass

class="com.ibm.dm.frontService.sm.interceptor.ExtractInterceptor"

description="Extracts a model substructure in plain mediation, so both models should be

of same ontology."

licenseText="This mediator is an IBM (TM) 2013 copyright (R), and is provided by IBM for

parties working under a valid agreement with IBM.\n It is used "AS-IS" w/no liabilities

from 'IBM' "

name="ExtractMediator"

requiresLicense="true">

</InterceptorClass>

<InterceptorClass

class="com.ibm.dm.frontService.sm.interceptor.viewMediator"

description="Mediator of models for visualization purposes."

name="ViewMediator">

</InterceptorClass>

<InterceptorClass

class="com.ibm.dm.frontService.sm.interceptor.TestMediator"

description="Mediator of models for testing purposes."

licenseText="For use by IBM Only."

name="TestMediator_do_not_use"


</InterceptorClass>

<InterceptorClass

class="com.ibm.dm.frontService.sm.interceptor.HaifaSemanticMediator"

description="An experimental ontology-and-rule-based mediator"

licenseText="This mediator is an IBM (TM) 2013 copyright (R), and is provided by IBM for

parties working under a valid agreement with IBM.\n It is used "AS-IS" w/no liabilities

from 'IBM' "

name="Haifa Semantic Mediator"


</InterceptorClass>

</extension>

9.3 Mediation Rules User Guide

9.3.1 Classification of mediation rules

The rules can be classified as follows (discussed below with some examples):

1. Equivalence replacements

2. Replacement with a super-property or a super-class

3. Replacement with a sub-property or a sub-class

4. Complex equivalence replacements

5. Type-inference from property domain or range

6. Expansion, and contraction, by domain, class, and range.



1.0 Final 2014-02-18 60 of 63

9.3.2 Equivalence Replacements

In many cases, mediation of resource classes (types), properties (predicates), and itemized values (individuals) can be simply done through the OWL equivalence relation. For instance (for the Rhapsody-SysML/BSO mediation): rhapsody1:Block owl2:equivalentClass bso3:Component .

dcterms4:title owl:equivalentProperty bso:name .

rhapsody:int owl:sameAs bso:Integer .

This means, for example, that a “Block” of a Rhapsody model is to be transformed into a “Component” when mediated to BSO; and its Rhapsody “title” should be converted into the new Component’s “name”. In other words, the following RDF turtle: <https://my-host.com/my-resource-uri>

a rhapsody:Block ;

dcterms:title "GateTester" .

Would be transformed into: <https://my-host.com/my-resource-uri>

a bso:Component ;

bso:name "GateTester" .

9.3.3 Replacement with a Super-Property or a Super-Class

The simple equivalence can be enhanced by applying the rdfs:subPropertyOf relation to a “super” property. For example, assume the mediation rules contain the following triples: rhapsody:hasAttributeType owl:equivalentProperty rhp-bso5:attributeType .

rhp-bso:attributeType rdfs6:subPropertyOf bso:type .

From these, one infers that a rhapsody:hasAttributeType predicate is a bso:type predicate, though

the converse not necessarily holds. This has led to model triples like the following: <https://my-host.com/my-resource-uri>

rhapsody:hasAttributeType rhapsody:RhpReal .

Is mediated to: <https://my-host.com/my-resource-uri>

bso:type rhapsody:RhpReal .

In combination with the equivalence of individual objects, as here: rhapsody:RhpReal owl:equivalentProperty bso:BsoReal .

A proper mediation to this triple would happen: <https://my-host.com/my-resource-uri>

bso:type bso:BsoReal .

Replacement of a class with a super-class works similarly.

1 Rhapsody: is the namespace prefix for the “input” model ontology, in this case for the Rhapsody design

tool. 2 Owl: is the namespace for the OWL ontology language.

3 bso: is the namespace prefix for the BSO “output” ontology.

4 dcterms: is the namespace prefix for a commonly used standard ontology.

5 rhp-bso: is the namespace for the rules ontology to mediate between the Rhapsody and the bso

ontologies. 6 rdfs: is the namespace prefix for RDFS – a basic ontological language that OWL extends.



1.0 Final 2014-02-18 61 of 63

9.3.4 Replacement with a Sub-Property or a Sub-Class

This is the converse of replacing a property with a super-property (or a class with a super-class). This type of replacement arises when the same property in the source model has to be replaced with different sub-properties in the target model, depending on context. The context is typically defined by the domain or the range of the property to be replaced, as in the following example: bso:subpackages

rdfs:subPropertyOf modelica7:localClass ;

rdfs:range modelica:MPackage .

bso:declared

rdfs:subPropertyOf modelica:localClass ;

rdfs:range modelica:MModel .

When mediating a BSO model into the Modelica ontology, one has to replace both the bso:subpackages

and the bso:declared property with the modelica:localClass property. But mediating from

Modelica into BSO is a little more subtle: When a Modelica triple has modelica:localClass as its

predicate, one has to look further at the triple’s object. If it’s a resource of type modelica:MPackage then

one should choose bso:subpackages as the new predicate; if it’s of type modelica:MModel, then one

should choose bso:declared.

9.3.5 Complex Equivalence Replacements

Sometimes equivalence replacements can get complex. In some cases, as in the example below, one has to replace a set of property-value specifications with a set of equivalent property-value specifications in the target ontology Below is the typical definition of an input port of type “integer” in the BSO ontology: <https://my-host.com/my-resource-uri>

a bso:Port ;

bso:direction bso:IN ;

bso:name “An input port of type integer” ;

bso:type bso:Integer

Here is how this resource should look like after being mediated to Modelica: <https://my-host.com/my-resource-uri>

a modelica:MConnectorComponent ;

modelica:identifier “An input port of type integer” ;

modelica:type modelica:IntegerInputConnector

The easy part of the mediation consists of transforming the object’s (RDF) type from a BSO “Port” into a Modelica “Connector Component”, and vice-versa; and transforming a BSO “name” into a Modelica “identifier”, and vice-versa. This is achieved with the following straightforward equivalences: bso:Port owl:equivalentClass modelica:MConnectorComponent

bso:name owl:equivalentProperty modelica:identifier

Furthermore, the rules need to state that if a BSO port is of (BSO) type “Integer”, and its direction is “IN”, then its Modelica type should be “IntegerInputConnector”. This is achieved through the use of an intersection of restrictions:

[ a owl:Restriction ;

owl:hasValue modelica:IntegerInputConnector> ;

owl:onProperty modelica:type

]

owl:sameAs

7modelica: is the namespace prefix for the Modelica ontology.



1.0 Final 2014-02-18 62 of 63

[ owl:intersectionOf (


owl:hasValue bso:Integer ;

owl:onProperty bso:type

]


owl:hasValue bso:IN ;

owl:onProperty bso:direction

]

)

] .

9.3.6 Type-Inference from Property Domain or Range

The type of a resource can be inferred from its being the domain, or range, of a property, and that property exists for the resource. Then, the inferred type can be subject to further equivalence rules as seen above. For these mediation rules: rhapsody:hasAttributeType owl:equivalentProperty rhp-bso:attributeType .

rhp-bso:attributeType rdfs:domain rhapsody:FlowProperty .

rhapsody:FlowProperty owl:equivalentClass bso:Flow .

This leads to assume that resources having the rhapsody:hasAttributeType predicate to be assigned

the bso:Flow type, even though they did not originally had the

rhapsody:FlowProperty type originally.

For example, the following triples: <https://my-host.com/my-resource-uri>

a rhapsody:Attribute ;

rhapsody:hasAttributeType rhapsody:RhpReal .

is mediated into:

<https://my-host.com/my-resource-uri>

a bso:Flow ;

bso:type rhapsody:RhpReal .

Note that we use here the rules ontology name-space (rhp-bso) to create new entity to connect and enable

this inference. The case where a rule specifies the range of a property, rather than its domain, is analogous. One has to assign the inferred type to the triple’s object, instead of the subject.

9.3.7 Expansion, and Contraction, by Domain, Class, and Range

This category of rules allows facilitating new resources as a result of mediation where there is no equivalent concept between the two ontologies, by associating a property with a set of 3 triple rules using the ontological “domain property”, a “property class”, and a “range property” domain specification. In such cases, the general case of a model triple: subject predicate object . Applying these domain-range specifications in our rules for its predicate: predicate

sm8:domainProperty domain-property-of-predicate;

sm:propertyClass property-class-of-predicate;

8 Sm: is the name-space prefix for the “Rules language” ontology



1.0 Final 2014-02-18 63 of 63

sm:rangeProperty range-property-of-predicate.

Is mediated into three new triples, as follows: subject domain-property-of-predicate new-resource . new-resource rdf:type property-class-of-predicate . new-resource range-property-of-predicate object . For example, given the following model triple: <https://my-host.com/my-subject-uri>

rhapsody:hasEndPoint_1 <https://my-host.com/my-object-uri> .

With the following rules: rhapsody:hasEndPoint_1

sm:domainProperty bso:interconnectionEnds ;

sm:propertyClass bso:InterconnectionEnd1 ;

sm:rangeProperty bso:part .

Results with a new resource link and definition: <https://my-host.com/my-subject-uri>

bso:interconnectionEnds <https://my-host.com/my-new-resource-uri> .

<https://my-host.com/my-new-resource-uri>

a bso:InterconnectionEnd1 ;

bso:part <https://my-host.com/my-object-uri> .

For mediation in the reverse direction, one has to identify trios of triples matching the required pattern, and then replace each such trio by a single triple. Searching for such matches can be algorithmically more expensive, but it does not pose any additional logical challenges.

sprint · d5.7+d5.3 architectural principles for internet of system design and the iot version...

Documents