interoperability specification (ios) v2 d601 · version nature date page v1.0 r 2015-04-30 2 of 230...

PROPRIETARY RIGHTS STATEMENT

THIS DOCUMENT CONTAINS INFORMATION, WHICH IS PROPRIETARY TO THE CRYSTAL 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 CRYSTAL 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 EUROPEAN UNION’S SEVENTH FRAMEWORK PROGRAM (FP7/2007-2013) FOR CRYSTAL – CRITICAL SYSTEM ENGINEERING ACCELERATION JOINT UNDERTAKING UNDER GRANT AGREEMENT N° 332830 AND FROM SPECIFIC NATIONAL PROGRAMS AND / OR FUNDING AUTHORITIES.

CRitical SYSTem Engineering AcceLeration

Interoperability Specification (IOS) – V2

D601.022

Version Nature Date Page

V1.0 R 2015-04-30 2 of 230

DOCUMENT INFORMATION

Project CRYSTAL

Grant Agreement No. ARTEMIS-2012-1-332830

Deliverable Title Interoperability Specifications (IOS) – V2

Deliverable No. D601.022

Dissemination Level PU

Nature R

Document Version 1.0

Date 2015-04-30

Contact Frédéric Loiret

Organization OFFIS

Phone +49 441 9722 481

E-Mail [email protected]


V1.0 R 2015-04-30 3 of 230

AUTHORS TABLE

Name Company E-Mail

Frédéric Loiret OFFIS [email protected]

Jean-Luc Johnson Airbus [email protected]

Gray Bachelor IBM [email protected]

Rainer Ersch Siemens AG [email protected]

Andreas Keis Airbus Group [email protected]

David Honey IBM [email protected]

Andreas Mitschke Airbus Group [email protected]

Anne Monceaux Airbus Group [email protected]

Linda Oosterheert TNO [email protected]

Gianpaolo Massaroli Ansaldo STS [email protected]

Thomas Karbe TU Berlin [email protected]

Michael van Bekkum TNO [email protected]

Kerstin Hartig TU Berlin [email protected]

Jose María Alvarez-Rodríguez Carlos III University of Madrid (UC3M) [email protected]

Juan Llorens Carlos III University of Madrid (UC3M) [email protected]

Jose Fuentes The Reuse Company (TRC) [email protected]

Omar Kacimi OFFIS [email protected]

Christian Ellen OFFIS [email protected]

Wilke Trei OFFIS [email protected]

Peter Tummeltshammer Thales Austria peter.tummeltshammer@thalesgr

oup.com

Cecilia Ekelin Volvo [email protected]

Christian Ekholm Volvo [email protected]

Thomas Kuhn Fraunhofer IESE [email protected]

Sytze Kalisvaart TNO [email protected]

Tom van den Berg TNO [email protected]

Andrea Leitner VIF [email protected]

Christian El Salloum AVL [email protected]

Rubén de Juan Marín

ITI [email protected]


V1.0 R 2015-04-30 4 of 230

REVIEWERS TABLE

Name Company E-Mail

Cecilia Ekelin Volvo [email protected]

Christian Hein Fraunhofer [email protected]

CHANGE HISTORY

Version Date Reason for Change Pages

Affected

0.1 14-03-2015 Initial version.

0.2 03-04-2015 IOS V2 inputs merged.

0.3 28-04-2015 Review comments from the reviewers taken into account.

1.0 30-04-2015 Final version.


V1.0 R 2015-04-30 5 of 230

CONTENT

1 INTRODUCTION.................................................................................................................................................... 11

1.1 PREAMBLE ........................................................................................................................................................... 11 1.2 ROLE OF DELIVERABLE ....................................................................................................................................... 11 1.3 RELATIONSHIP TO OTHER CRYSTAL DOCUMENTS ............................................................................................. 12 1.4 STRUCTURE OF THIS DOCUMENT ......................................................................................................................... 12 1.5 CHANGES WITH THE PREVIOUS VERSION ............................................................................................................. 12

2 IOS PREREQUISITES ........................................................................................................................................... 13

2.1 IOS & RTP OVERVIEW ........................................................................................................................................ 13 2.2 IOS ADOPTION HISTORY ..................................................................................................................................... 14 2.3 BASIC TERMINOLOGY .......................................................................................................................................... 15

2.3.1 Interoperability Scenarios ............................................................................................................................ 15 2.3.2 Engineering Artefacts and Lifecycle Artefacts ............................................................................................. 15 2.3.3 Adapters and Service Consumers/Providers ................................................................................................ 16

2.4 CRYSTAL IOS CONTENT & SCOPE OVERVIEW .................................................................................................. 17 2.4.1 IOS High-Level Concepts ............................................................................................................................. 17 2.4.2 IOS Positioning with OSLC ......................................................................................................................... 20 2.4.3 IOS Positioning with other existing Engineering Standards ........................................................................ 20 2.4.4 IOS Technical Concerns & Boundaries ....................................................................................................... 21

2.5 CRYSTAL IOS V2 INPUTS COLLECTION PROCESS ............................................................................................. 23 2.5.1 IOS V2 Inputs ............................................................................................................................................... 23 2.5.2 CRYSTAL Approach: Engineering Methods to IOS Services ....................................................................... 23 2.5.3 CRYSTAL Ontology Working Group............................................................................................................ 25

2.6 IOS EXTENSION MECHANISMS & PROCESS ......................................................................................................... 26 2.6.1 IOS Extensions Mechanisms for Lifecycle Interoperability ......................................................................... 26 2.6.2 IOS Extension Mechanisms for Non-Lifecycle Interoperability ................................................................... 27

2.7 GUIDELINES FOR SUPPORTING INFORMATION EXCHANGES NOT YET DEFINED AS PART OF THE IOS .................... 28 2.8 NEXT STEPS TOWARDS IOS SUSTAINABILITY ..................................................................................................... 28

3 OVERVIEW OF THE IOS CHAPTERS .............................................................................................................. 30

4 INTEROPERABILITY SPECIFICATIONS V1 .................................................................................................. 32

4.1 IOS V1 BASIC LIFECYCLE INTEROPERABILITY SCENARIOS ................................................................................. 32 4.1.1 Overview of the Scenarios ............................................................................................................................ 32 4.1.2 Descriptions of the Scenarios ....................................................................................................................... 32

4.2 CORE CONCEPTS AND PRINCIPLES INHERITED FROM OSLC ................................................................................. 36 4.2.1 IOS Vocabulary ............................................................................................................................................ 36 4.2.2 Resources ..................................................................................................................................................... 36 4.2.3 Linktypes ...................................................................................................................................................... 36 4.2.4 Properties ..................................................................................................................................................... 36

4.3 NOTES ON APPLICATION OF OSLC V2.0 AT IOS V1.0 ......................................................................................... 36 4.4 IOS CHAPTER – CORE CAPABILITIES ................................................................................................................... 36

4.4.1 Common Core Capabilities .......................................................................................................................... 37 4.4.2 Service Provider Capabilities ...................................................................................................................... 37 4.4.3 Service Consumer Capabilities .................................................................................................................... 38 4.4.4 Advanced Core Capabilities ........................................................................................................................ 38

4.5 IOS CHAPTER – DOMAIN SUPPORT: REQUIREMENT MANAGEMENT .................................................................... 39 4.6 IOS CHAPTER – DOMAIN SUPPORT: ARCHITECTURE MANAGEMENT ................................................................... 39 4.7 IOS CHAPTER – DOMAIN SUPPORT: ASSET MANAGEMENT ................................................................................. 40 4.8 IOS CHAPTER – DOMAIN SUPPORT: CHANGE REQUEST MANAGEMENT .............................................................. 40 4.9 IOS CHAPTER – DOMAIN SUPPORT: QUALITY MANAGEMENT ............................................................................. 41

5 INTEROPERABILITY SPECIFICATIONS V2 – PROPOSALS ....................................................................... 42

5.1 CHANGE AND CONFIGURATION MANAGEMENT ................................................................................................... 42 5.1.1 Authors and Contributors ............................................................................................................................ 42


V1.0 R 2015-04-30 6 of 230

5.1.2 Context ......................................................................................................................................................... 42 5.1.3 Supported Engineering Methods .................................................................................................................. 42 5.1.4 Specification ................................................................................................................................................. 43 5.1.5 Integration Guidelines ................................................................................................................................. 45

5.2 TRACKED RESOURCE SET .................................................................................................................................... 46 5.2.1 Authors and Contributors ............................................................................................................................ 46 5.2.2 Context ......................................................................................................................................................... 46 5.2.3 Supported Engineering Methods .................................................................................................................. 46 5.2.4 Specification ................................................................................................................................................. 47 5.2.5 Integration Guidelines ................................................................................................................................. 51

5.3 ONTOLOGY IOS ................................................................................................................................................... 53 5.3.1 Authors and Contributors ............................................................................................................................ 53 5.3.2 Context ......................................................................................................................................................... 53 5.3.3 Supported Engineering Methods .................................................................................................................. 53 5.3.4 Specification ................................................................................................................................................. 54

5.4 KNOWLEDGE MANAGEMENT ............................................................................................................................... 65 5.4.1 Authors and Contributors ............................................................................................................................ 65 5.4.2 Context ......................................................................................................................................................... 65 5.4.3 Supported Engineering Methods .................................................................................................................. 70 5.4.4 Specification ................................................................................................................................................. 72 5.4.5 Integration Guidelines (optional subsection) ............................................................................................... 85

5.5 THE MBAT [MBAT, 2015] INTEROPERABILITY SPECIFICATION ......................................................................... 86 5.5.1 Authors and Contributors ............................................................................................................................ 86 5.5.2 Context ......................................................................................................................................................... 86 5.5.3 Supported Engineering Methods .................................................................................................................. 89 5.5.4 Specification ................................................................................................................................................. 94 5.5.5 Derived Concepts ....................................................................................................................................... 151

5.6 FORMAL REQUIREMENTS MANAGEMENT OFFIS ............................................................................................... 152 5.6.1 Authors and Contributors .......................................................................................................................... 152 5.6.2 Context ....................................................................................................................................................... 152 5.6.3 Supported Engineering Methods ................................................................................................................ 153 5.6.4 Specification ............................................................................................................................................... 157

5.7 SAFETY MANAGEMENT OFFIS .......................................................................................................................... 170 5.7.1 Authors and Contributors .......................................................................................................................... 170 5.7.2 Context ....................................................................................................................................................... 170 5.7.3 Supported Engineering Methods ................................................................................................................ 171 5.7.4 Specification ............................................................................................................................................... 171 5.7.5 Integration Guidelines ............................................................................................................................... 179

5.8 VERIFY TEST COVERAGE ................................................................................................................................... 180 5.8.1 Authors and Contributors .......................................................................................................................... 180 5.8.2 Context ....................................................................................................................................................... 180 5.8.3 Supported Engineering Methods ................................................................................................................ 180

5.9 DRAFT PROPOSAL ON EAST-ADL/AUTOSAR FOR IOS ................................................................................... 183 5.9.1 Authors and Contributors .......................................................................................................................... 183 5.9.2 Context ....................................................................................................................................................... 183 5.9.3 Supported Engineering Methods ................................................................................................................ 183 5.9.4 Specification ............................................................................................................................................... 186

5.10 FUNCTIONAL MOCKUP UNITS FOR CO-SIMULATION ........................................................................................ 189 5.10.1 Authors and Contributors ........................................................................................................................ 189 5.10.2 Context ..................................................................................................................................................... 189 5.10.3 Supported Engineering Methods .............................................................................................................. 189 5.10.4 Specification ............................................................................................................................................. 194

6 TERMS, ABBREVIATIONS AND DEFINITIONS ........................................................................................... 200

7 REFERENCES ....................................................................................................................................................... 201

8 ANNEX ................................................................................................................................................................... 203

8.1 TRACKED RESOURCE SET - VOCABULARY......................................................................................................... 203 8.2 ONTOLOGY IOS - VOCABULARY ....................................................................................................................... 206

8.2.1 Requirement Management resource ........................................................................................................... 206 8.2.2 Architecture Management resources ......................................................................................................... 207


V1.0 R 2015-04-30 7 of 230

8.2.3 Quality Management resources ................................................................................................................. 215 8.2.4 Safety Risk Management resources ............................................................................................................ 217 8.2.5 Variability Management resources ............................................................................................................ 218

8.3 KNOWLEDGE MANAGEMENT - VOCABULARY.................................................................................................... 223 8.4 MBAT [MBAT, 2015] INTEROPERABILITY SPECIFICATION- VOCABULARY ...................................................... 228 8.5 EXAMPLE OF CONCRETE SCENARIOS ................................................................................................................. 228 8.6 IOS V1 ARCHITECTURE REPRESENTATION ........................................................................................................ 230


V1.0 R 2015-04-30 8 of 230

Content of Figures

Figure 1: RTP & RTP Instances ....................................................................................................................... 14 Figure 2: Lifecycle Artefacts and Engineering Artefacts. .................................................................................. 16 Figure 3: IOS High-Level Concepts .................................................................................................................. 18 Figure 4: IOS Technical Concerns. .................................................................................................................. 21 Figure 5: IOS Based Linked Data Representation and Exchange between Integrated Tools & Data Repositories. ..................................................................................................................................................... 22 Figure 6: Example of an EM – IOS Service Mapping table (excerpt) ............................................................... 25 Figure 7: Convergence between CRYSTAL Domain Ontology WPs towards IOS V2 Inputs .......................... 26 Figure 8: IOS Extension Mechanisms for Lifecycle IOS ................................................................................... 27 Figure 9: IOS Chapters mapped onto IOS High-Level Concepts. .................................................................... 31 Figure 10: IOS Interoperability Pattern 1: Access remote Lifecycle Artefact ................................................... 33 Figure 11: IOS Interoperability Pattern 1: Access remote artefact - Sequence diagram ................................. 33 Figure 12: IOS Interoperability Pattern 2: Store link to remote artefact ........................................................... 34 Figure 13: IOS Interoperability Pattern 2: Store link to remote artefact - Sequence diagram .......................... 34 Figure 14: IOS Interoperability Pattern 3: Access remote artefact with UI redirection ..................................... 35 Figure 15: IOS Interoperability Pattern 2: Access remote artefact using a delegated UI - Sequence diagram35 Figure 16: Group of Engineering Methods for CRYSTAL WP2.08 .................................................................. 47 Figure 17: Tracked Resource Set resources .................................................................................................... 49 Figure 18: RDF/XML document of the TRS URI .............................................................................................. 49 Figure 19: RDF/XML TRS Change log document ............................................................................................ 50 Figure 20: RDF/XML TRS Base document ...................................................................................................... 51 Figure 21: PAUC Modelica resource preview within IBM RELM ...................................................................... 52 Figure 22: PAUC 3D geometry resource preview with IBM RELM .................................................................. 52 Figure 23: The resources FeatureModel, Feature, and Variant are extensions of Architecture Management Resource. ......................................................................................................................................................... 61 Figure 24: Relations with OSLC AM domain .................................................................................................... 61 Figure 25: relationships between the QM resource types defined within the IOS ontology specification and the existing OSLC ones .................................................................................................................................... 62 Figure 26: domain and cross-domain relationships of QM resource types defined within the IOS ontology specification. ..................................................................................................................................................... 63 Figure 27: Common processes in Knowledge Management, adapted from [8] ............................................... 66 Figure 28 The RSHP representation model using UML. .................................................................................. 68 Figure 29 An iterative process of requirements sub-activities by [16]. ............................................................. 71 Figure 30 Layers of an ontology-driven approach to guide requirements writing ............................................ 71 Figure 31: The simplified RSHP representation model using UML. ................................................................. 77 Figure 32 OSLC Knowledge Management and other OSLC specification. ...................................................... 83 Figure 33: Relationship between Pattern groups and Patterns. ....................................................................... 83 Figure 34: MBAT IOS Revision process ........................................................................................................... 87 Figure 35: Change Impact Analysis – Overview .............................................................................................. 91 Figure 36: AT pattern: reduce warnings from Static Code Analysis ................................................................. 92 Figure 37: IOS resources used for the first step of the pattern ........................................................................ 93 Figure 38: IOS resources after the execution of the analysis........................................................................... 93 Figure 39: IOS resources before the model analysis ....................................................................................... 94 Figure 40: Architecture Management – Structural Viewpoint – Overview ........................................................ 97 Figure 41: Architecture Management – Structural Viewpoint – Component .................................................... 97 Figure 42: Architecture Management – Structural Viewpoint – Prototype ....................................................... 99 Figure 43: Architecture Management – Structural Viewpoint – Port ................................................................ 99 Figure 44: Architecture Management – Structural Viewpoint – Connector .................................................... 100 Figure 45: Architecture Management – Structural Viewpoint – Connector End ............................................. 101 Figure 46: Architecture Management – Structural Viewpoint – Abstraction Level ......................................... 101 Figure 47: Architecture Management – Structural Viewpoint – Architecture Description – Illustration .......... 102 Figure 48: Architecture Management – Structural Viewpoint – Perspective .................................................. 103 Figure 49: Architecture Management – Structural Viewpoint – Operational Perspective .............................. 103 Figure 50: Architecture Management – Behavior Viewpoint – Component ................................................... 105 Figure 51 : V&V Management – Overview ..................................................................................................... 115 Figure 52: V&V Management – VV Suite ....................................................................................................... 116 Figure 53: V&V Management – VV Objective ................................................................................................ 118


V1.0 R 2015-04-30 9 of 230

Figure 54: V&V Management – VV Suite ....................................................................................................... 120 Figure 55: V&V Management – AT Model ...................................................................................................... 121 Figure 56: V&V Management – VV Log ......................................................................................................... 122 Figure 57: V&V Management – Verdict .......................................................................................................... 123 Figure 58: Overview of the mapping between the OSLC QM domain to the IOS VV specification ............... 136 Figure 59: Traceability Management – Overview ........................................................................................... 137 Figure 60: Traceability Management – Refine link ......................................................................................... 137 Figure 61: Traceability Management – Derive Link ........................................................................................ 138 Figure 62: Traceability Management – Satisfy Link ....................................................................................... 138 Figure 63: Traceability Management – Implementation Link.......................................................................... 139 Figure 64: Traceability Management – Realize Link ...................................................................................... 139 Figure 65: Traceability Management – Mapping End ..................................................................................... 140 Figure 66: Traceability Management – Allocate Link ..................................................................................... 140 Figure 67: Combined T&A Pattern “MBT with analysis” ................................................................................. 153 Figure 68: Combined T&A Pattern “Target MBT to Failing Test-Case” ......................................................... 154 Figure 69: Combined T&A Pattern “Slice Large Model by Test run” .............................................................. 154 Figure 70: Tools connected within the use case ............................................................................................ 155 Figure 71: Automotive use-case 2 scenarios for the combined T&A Pattern "MBT with analysis" ................ 156 Figure 72: MBAT meta model representation of a contract with an assumption and promises [MBAT MM,2014] ........................................................................................................................................................ 157 Figure 73: Safety Management - Hazard ...................................................................................................... 172 Figure 74: Safety Management – Failure ....................................................................................................... 173 Figure 75: File-based work flow including OSLC links ................................................................................... 184 Figure 76: EAST-ADL based timing analysis ................................................................................................. 185 Figure 77: EAST ADL class diagram excerpt ................................................................................................. 187 Figure 5-63 Traversing the EAST ADL ECORE meta model to produce an XMI file describing the resources and their properties ......................................................................................................................................... 188 Figure 79: Generating an OSLC Service Provider including resource shapes .............................................. 188 Figure 80: Design Space Exploration - Sequence diagram ........................................................................... 191 Figure 81: system validation sequence diagram ............................................................................................ 193 Figure 82: Searching for simulation models diagram ..................................................................................... 194 Figure 83: Model Exchange diagram .............................................................................................................. 195 Figure 84: FMI for Co-Simulation interface routines ....................................................................................... 195 Figure 85: Co-simulation on a single computer .............................................................................................. 196 Figure 86: Co-simulation with tool coupling on a single computer. ................................................................ 196 Figure 87: Distributed co-simulation infrastructure. ........................................................................................ 196 Figure 88: The CRYSTAL IOS V1 Layered Architecture. ............................................................................... 230

Content of Tables

Table 1: Descriptions of the IOS High-Level Concepts .................................................................................... 18 Table 2: Description of the main IOS Technical Concerns. .............................................................................. 21 Table 3: IOS Chapters Overview. ..................................................................................................................... 30 Table 4: A comparison between RDF and RSHP in the context of knowledge representation and exploitation.69 Table 5: Alignment of knowledgement management processes to a combined approach OSLC/RDF/RSHP.74 Table 6: Regular Tree Grammars of RDF, and RSHP, . ........................................................ 74 Table 7: Set of mapping rules, to transform RDF in RSHP. ............................................................................. 75 Table 8: OSLC Resource Shapes description for Knowledge Management. .................................................. 82 Table 9: OSLC Resource Shapes description for Patterns Management. ....................................................... 85 Table 10: summary of step 1 of the AT pattern ................................................................................................ 92 Table 11: summary of step 2 of the AT pattern ................................................................................................ 94 Table 12: IOS AM – Structural Viewpoint – Component Resource ................................................................ 107 Table 13: IOS AM – IOS AM – Structural Viewpoint – Prototype Resource .................................................. 108 Table 14: IOS AM – IOS AM – Structural Viewpoint – Port Resource ........................................................... 109 Table 15: IOS AM – IOS AM – Structural Viewpoint – Type Resource .......................................................... 110 Table 16: IOS AM – IOS AM – Structural Viewpoint – Connector Resource ................................................. 111 Table 17: IOS AM – IOS AM – Structural Viewpoint – Connector End Resource.......................................... 112 Table 18: IOS AM – IOS AM – Structural Viewpoint – Abstraction Level Resource ...................................... 113 Table 19: IOS AM – IOS AM – Structural Viewpoint – Perspective Resource ............................................... 114 Table 20: IOS AM – IOS AM – Structural Viewpoint – Behavior Resource ................................................... 115


V1.0 R 2015-04-30 10 of 230

Table 21: IOS VV – VV Suite Resource ......................................................................................................... 125 Table 22: IOS VV – VV Case Resource ......................................................................................................... 127 Table 23: IOS VV – VV Test Vector Resource ............................................................................................... 128 Table 24: IOS VV – VV Objective Resource .................................................................................................. 130 Table 25: IOS VV – VV Log Resource ........................................................................................................... 131 Table 26: IOS VV – VV Outcome Resource ................................................................................................... 132 Table 27: IOS VV – VV AT Model Resource .................................................................................................. 133 Table 28: IOS VV – VV Verdict Resource ...................................................................................................... 135 Table 29: IOS VV – VV Script Resource ........................................................................................................ 136 Table 30: IOS TM – Refine Link Resource ..................................................................................................... 142 Table 31: IOS TM – Derive Link Resource ..................................................................................................... 143 Table 32: IOS TM – Refine Satisfy Resource................................................................................................. 145 Table 33: IOS TM – Implementation Link Resource ...................................................................................... 146 Table 34: IOS TM – Realize Link Resource ................................................................................................... 148 Table 35: IOS TM – Mapping End Resource.................................................................................................. 149 Table 36: IOS TM – Allocate Link Resource .................................................................................................. 150 Table 37 - IOS RM – Requirement Resource................................................................................................. 162 Table 38 - IOS RM – Contract Resource ........................................................................................................ 163 Table 39 - IOS FRM – Requirement Pattern Resource .................................................................................. 167 Table 40 - IOS FRM –Pattern Parameter Resource ...................................................................................... 168 Table 41 - IOS FRM –Pattern Instance Resource .......................................................................................... 168 Table 42 - IOS FRM –Pattern Instance Resource .......................................................................................... 169 Table 43: IOS FM – Hazard Resource ........................................................................................................... 175 Table 44: IOS FM – Failure Resource ............................................................................................................ 176 Table 45: IOS FM – Fault Resource ............................................................................................................... 177 Table 46: IOS FM – Cause Relation Resource .............................................................................................. 178 Table 47: IOS FM – Safety Mecanism Resource ........................................................................................... 179 Table 48: Terms, Abbreviations and Definitions ............................................................................................. 200 Table 49: Examples of Concrete Scenarios related to "Lifecycle Interoperability" and "other Interoperability Topics" ............................................................................................................................................................ 228


V1.0 R 2015-04-30 11 of 230

1 Introduction

1.1 Preamble

CRYSTAL aims at fostering Europe’s leading edge position in embedded systems engineering in particular

regarding quality and cost effectiveness of safety-critical embedded systems and architecture platforms.

However, because of the heterogeneity and complexity of such systems covered by the project, requiring

multiple engineering competences across various engineering disciplines, their developments become a

huge challenge to overcome by European developing organizations, notably because of:

The heterogeneity of engineering tools & data involved in their development platforms across the

development lifecycle (encompassing requirements engineering, design, wide range of V&V

activities from dynamic testing, formal analysis, fault-tree analysis, etc.),

The increasing need in the context of safety-critical systems to bridge the gap between development

platforms and operational ones (e.g., for including human in-the-loop or virtual testing,

heterogeneous co-simulation, or for monitoring and maintaining large-scale distributed applications),

with the goal to improve the development and decision-making processes in large developing

organizations,

The distributed and multi-tiers nature of development teams in nowadays’ large European

organizations, spread over multiple countries and suppliers.

In order to overcome these challenges, CRYSTAL leverages on a momentum initiated by past and on-going

ARTEMIS projects1 around a common vision for the Establishment of Recognized International Open

Standards of Lifecycle Tool & Data Integration Platforms for Systems Engineering (or “Tool Chains”). The

main idea of the so-called Interoperability Specifications (IOS) initiated in these projects is to rely on common

interoperability services, providing a common ground for integrating lifecycle and engineering tools across

different engineering disciplines and from multiple stakeholders involved in the development of large scale

safety-critical systems (e.g., requirements engineers, developers, V&V experts, but also business analysts

and managers). The common denominator of the IOS across the projects, and among the CRYSTAL’s

partners, is based on a combination of (i) a lightweight and domain-agnostic approach, providing basic

capabilities for handling the whole lifecycle of engineering artefacts manipulated throughout the development

of safety-critical embedded systems, and of (ii) existing Systems Engineering Standards widely adopted by

CRYSTAL partners. The CRYSTAL IOS V2 is presented in this document, as a refinement of an initial

version released in 2014 within the CRYSAL consortium [4].

1.2 Role of Deliverable

This second iteration of the CRYSTAL IOS deliverable presents outcomes of extensive technical activities that have been conducted in the second year of the project among representatives of all CRYSTAL’s stakeholders (i.e., end-users from aerospace, automotive, healthcare and rail domains, tool and integration solution providers, and technology brick providers from SP6), in order to reach a second level of consensus regarding the shape, scope, and content of the CRYSTAL IOS, and based on the approach that has been initially proposed, adopted and refined in the ARTEMIS projects CESAR, iFEST and MBAT, and on which CRYSTAL use case owners put a clear focus.

Indeed, the IOS V1 [4] was considered as a first baseline for reaching a consensus in the project, and for presenting directions on how the CRYSTAL IOS could be extended. This document steps forward by presenting CRYSTAL specific IOS extension candidates that have been proposed either by dedicated

1 In particular CESAR, iFEST and MBAT.


V1.0 R 2015-04-30 12 of 230

working groups that have been implemented in the project or by specific partners on their own. Therefore, these new inputs presented in this deliverable (IOS V2 Proposals, in section 5) have not yet been consolidated, harmonized and formally evaluated at project level. This process will be implemented in the remaining year of the project, and its final outcomes will be released by the end of the project in the last iteration of this deliverable (i.e., the IOS V3).

The content of the IOS V1 initially presented in the former deliverable (and also integral part of the IOS V2 in the current document) was used as a first reference document for implementing basic IOS-compliant CRYSTAL bricks focused on lifecycle interoperability scenarios, already covering a large part of the V-model, from requirements engineering to architecture and quality management, and including change request management, and traceability throughout the development process. This version of the IOS deliverable significantly extend this initial version by presenting pre-standardized specifications that are already being implemented by CRYSTAL brick providers and/or that will be consolidated in the last year of the project towards sustainable IOS chapters.

1.3 Relationship to other CRYSTAL Documents

This document is related to the following deliverables:

ID Title

D601.031 Report on Standardisation Work – V1

D601.032 Report on Standardisation Work – V2

D601.021 Interoperability Specification – V1

D209.021 Aerospace ontology definition – V1

D308.021 Automotive Ontology Definition & Assessment Report – V1

D407.021 Health Care ontology definition – V1

D504.021 Rail Ontology Definition & Assessment Report – V1

1.4 Structure of this Document

This deliverable is structured as follows:

The section 2 provides the prerequisites for comprehending the main concepts and principles behind the CRYSTAL Interoperability Specification (IOS), presents its scope and content from a high-level perspective and the processes that have been implemented in the project for providing the inputs of the IOS V2 (and towards standardization).

The section 3 gives on overview of the technical content of the IOS V1 and the IOS V2 proposals.

The section 4 is focused on the IOS V1 by providing basic and generic lifecycle interoperability scenarios and patterns from the CRYSTAL use cases that have been elicited, and by providing the technical specifications of the IOS V1.

The section 5 presents the technical IOS V2 candidates for IOS specifications that have been collected within the CRYSTAL consortium.

1.5 Changes with the Previous Version In comparison to the first version of this deliverable (IOS V1):

The section 2 is based on inputs already presented in the IOS V1, but the structure has been

updated and many new inputs have been provided, it can be considered as a new section then.

The section 3 is new.

The section 4 is a merge of two sections from the IOS V1, no new inputs have been provided in this

document.

The section 5 is new.


V1.0 R 2015-04-30 13 of 230

2 IOS Prerequisites

2.1 IOS & RTP Overview

The IOS – as it has been defined by former ARTEMIS projects (see next section, IOS Adoption History) – consists of a specification for achieving common Tool & Data Interoperability in heterogeneous Systems Engineering development environments. In particular, it encompasses the specification of three main aspects:

The specification of communication paradigms and protocols to be used for exchanging information between integrated Tools and Data repositories,

The specification of data exchange formats (or syntax, referring to the formats used for serializing data as strings, e.g., RDF/XML, XMI/XML, JSON, etc.), and

The specification of the semantics of the information to be interpreted and exchanged across these Tools and Data repositories (or abstract syntax, referring to the definition of sets of concepts for lifecycle integration, defined with their properties and relationships).

In general, the CRYSTAL Interoperability Specification (IOS):

Relies on Common Interoperability Principles,

Is based on existing Interoperability Standards,

Is based on, and related to, other relevant Interoperability & Engineering Standards,

Is open (i.e., IOS is royalty-free use),

Is extensible,

Aims to be widely accepted by industrial users and tool vendors.

In particular, the CRYSTAL IOS (as described in detail section 2.4) is focused on:

Lifecycle Interoperability, and on

Non-Lifecycle Interoperability for supporting In Depth Systems Engineering Activities.

The part of the IOS focused on Lifecycle Interoperability is based on Artefacts used in Systems Engineering Development Environments (“Tool Chains”):

To support collaboration between stakeholders of different roles, different engineering disciplines, and different industrial domains,

To enable status reporting, traceability, dashboarding, analysis, prediction, data collection for reports, automation support, etc., between Tools and Data Repositories.

The key idea pushed forward in the IOS consists in relying on standardized integration interfaces for supporting lifecycle interoperability, with the goal to overcome redundant integration problems (e.g., related to point-to-point and ad-hoc integration architectures, isolated tool silos, users locked-in, reusability & maintenance of integration assets) across the boundaries of engineering disciplines, application domains and tool providers. Such standardized integration interfaces have to define lightweight and generic concepts as a common denominator for all the artefacts used holistically throughout the development cycle of CRYSTAL Use Cases. In the context of lifecycle interoperability, the main focus is put on the semantics of the links and dependencies between the artefacts crossing the boundaries between the engineering disciplines (i.e., related to requirement engineering, design & implementation, and V&V related activities).

The part of the IOS focused on Non-Lifecycle Interoperability for supporting In Depth Systems Engineering Activities will be based on existing Engineering Standards identified as already widely used among CRYSTAL partners and European developing organizations. Indeed, CRYSTAL aims at supporting engineering activities focused on end-users’ businesses, and which require detailed, specific and “bespoke” semantics and methodologies besides lifecycle interoperability. Such engineering activities encompass


V1.0 R 2015-04-30 14 of 230

heterogeneous co-simulation, combination of dynamic testing and formal static analysis, variability management, design space exploration, just to name a few.

It is worth noting that by nature, activities related to lifecycle interoperability on the one hand, and those related to in depth Systems Engineering on the other hand are entangled. It is therefore in the scope of CRYSTAL to clearly elaborate on the complementarities and areas of overlap between these two dimensions of interoperability in order to fully fulfil integration requirements and needs from the CRYSTAL Use Cases.

The concept of a European Reference Technology Platform (RTP) has also emerged within the ARTEMIS eco-system (initially introduced in the CESAR project). Basically, the main assets of the RTP are the following:

A library of ready-to-integrate Engineering Tools, with their respective adapters implementing IOS-compliant integration interfaces,

A set of Integration Software Development Kits (SDKs) and dedicated Support Tools (e.g., CRYSTAL Platform Builder related tools) for specifying, implementing, instantiating, tailoring, deploying and maintaining RTP instances (or “Tool Chains”),

A set of Methodologies and guidelines for supporting advanced lifecycle interoperability scenarios and in depth Systems Engineering activities by the CRYSTAL technical work packages.

The Figure 1 presents a graphical representation of the RTP and RTP instances. The latter consists of an integrated subset of RTP bricks based on the IOS.

CRYSTAL RTP

Integration Interface

Tool


Tool


Tool


Tool Integration Interface

Tool


Tool


Tool


Tool


Tool


Tool


Tool


Tool


Tool


Service Integration Interface

Tool


Tool


Tool


Tool


Tool


Service


Tool


Tool


Tool



Tool


Tool


Tool


Tool

IOS Integration Interfaces

Tool


Tool


Tool


Tool M

etho

dologies

Integration Software Development Kits (SDKs), and

Support Tools for instantiating RTP Instances

CRYSTAL RTP Instance


Tool


Tool


Tool


Service


Tool


Tool


Tool



Tool


Tool IOS Integration

Interfaces

Tool


Tool


Tool

Tailoring, Instantiation and Deployment

from End-User Scenarios and Integration Needs



Tool


Tool


Tool


Service


Tool


Tool


Tool



Tool


Tool IOS Integration

Interfaces

Tool


Tool


Tool



Tool


Tool


Tool


Service


Tool


Tool


Tool


Tool


Tool


Tool


Tool


Tool


Tool

Figure 1: RTP & RTP Instances

2.2 IOS Adoption History

Embedded systems are getting more and more complex and the different engineering disciplines and stakeholders are using more and more highly specialized methods and tools to execute their tasks. Unfortunately, most of those methods and tools manage their information in isolated environments and keep them behind private APIs. Attempts to bring all information together in one single, universal repository to connect them better typically failed because the universal repositories do not provide enough functionality for the highly specialized tasks. In addition, new innovative approaches to optimize tasks in the engineering process, because they cannot be introduced due to the inflexibility of such centralized environments. Therefore, the importance of Interoperability in Engineering Environments is rising and it is becoming more


V1.0 R 2015-04-30 15 of 230

and more crucial for successful and efficient systems engineering. The CESAR project2 introduced the idea of a “Reference Technology Platform“(RTP), where the different parts where connected based on a standardized Interoperability Specification (IOS).

After some investigations in different interoperability technologies, the CESAR project has selected the emerging open standard OSLC3 (Open Services for Lifecycle Collaboration) as basis for the CESAR Interoperability Specification IOS. Other projects (iFEST4, MBAT5, and now CRYSTAL) followed this approach. The iFEST project came in an independent evaluation to the same conclusion that OSLC is the right solution for their interoperability needs. MBAT continued with the IOS foundation laid by CESAR and adopted it for their “Combined Model-based Analysis and Testing of Embedded Systems” methodologies. CRYSTAL has now taken over with writing the story further. In the meantime, the OSLC open initiative has grown up from a “loosely coupled” web community, to a member section of the open standard organization OASIS6. Many commercial and open source products have adopted the open standard and the number of participating organizations is constantly growing. The ARTEMIS projects are very well connected with the OSLC standard organization though key project members serving as OSLC Steering Committee members and workgroup leads. Although OSLC is already an excellent basis for the CRYSTAL IOS, the project has already identified some additional needs for interoperability in their use cases, which will most likely lead to enhancements of the OSLC standard and an extension of the CRYSTAL IOS by other standards.

2.3 Basic Terminology

In this section are simply given definitions of the most important terms to be grasped by the readers as a prerequisite for understanding the basic concepts underlying the IOS.

2.3.1 Interoperability Scenarios

In the context of Systems Engineering development environments, an Interoperability Scenario elicits a workflow for which each activity explicitly captures an exchange of information between stakeholders, tools, and data repositories, and in particular across the boundaries of engineering disciplines. These activities are either performed manually or automatically. Elicitations of Interoperability Scenarios with the characterization of information to be exchanged for each activity (e.g., types of artefacts to be exchanged) and by which means (e.g., via browsing or graphical representations of artefacts, via manual or automatic notification mechanisms, etc.), constitute the main inputs to be considered for defining the IOS and its extensions.

The CRYSTAL Engineering Methods can be considered as elicitations of Interoperability Scenarios (but it is worth noting that in some cases, some activities defined by the end-users are not directly related to interoperability per se, but are focused on engineering activities performed internally from within a tool without any need of exchanging information beyond its scope).

2.3.2 Engineering Artefacts and Lifecycle Artefacts

The Figure 2 below illustrates two integrated engineering tools (or RTP Bricks) with their adapters (see the definition of the latter in the next subsection, an adapter basically consists of Service Providers and/or Service Consumers, only the providers are represented on Figure 2), and introduces the notions of Lifecycle Artefact and Engineering Artefact.

2 http://www.cesarproject.eu 3 http://open-services.net 4 http://www.artemis-ifest.eu 5 http://www.mbat-artemis.eu 6 http://oasis-oslc.org

http://open-services.net/

http://oasis-oslc.org/


V1.0 R 2015-04-30 16 of 230

Integrated Engineering Tool

(RTP Brick)

IOS/Lifecycle Artefacts

Adapters

Engineering Artefacts

Textual Req

Formal Req.

Expose

Test Case

TC Exec Res.

Expose

Integrated Engineering Tool

(RTP Brick)

Specific Semantics

Generic Semantics

Link

ElemA ElemB

ElemC

Engineering Model Engineering Artefact

ElemA ElemB

ElemC

Engineering Model Engineering Artefact

RTP Bricks

Figure 2: Lifecycle Artefacts and Engineering Artefacts.

Basically, Engineering Artefacts constitute the assets used internally within the Engineering Tools (e.g., as files or as data chucks stored in a database). Their semantics and syntaxes are defined by standard formats (e.g., UML/XMI or standard C and executable files) or by proprietary formats (e.g., MDL files used within Simulink). An Engineering Artefact is generally defined as a container and namespace of Artefact Elements (e.g. a set of classes stored in a UML class diagram).

Engineering Artefacts and their Elements are mapped onto Lifecycle Artefacts, the latter being the first class entities used for supporting Lifecycle Interoperability scenarios. The syntax and semantics of Lifecycle Artefacts, the basic services defined for manipulating them (read and write access), and the communication protocols used for serializing them between integrated tools and data repositories are defined by the IOS, as presented in section 2.4.

2.3.3 Adapters and Service Consumers/Providers

As already introduced above, an Adapter consists of Service Consumers and Providers.

As described in the IOS layered architecture (see section 2.4), major parts of the IOS will be based on RDF/XML and HTTP & Core Web Technologies. The preferred architectural style, to be used with the IOS, is the so-called Representational state transfer (REST7). One basic concept of this architectural style is the separation of concerns in Clients and Servers. This means clients do not have direct access to data stored (or “owned”) by a server, but the server “provides” services which can be “consumed” by the client to read, query and manipulate the data. In the IOS we call the servers providing services “Providers” and the client consuming services “Consumers”.

Typical services are:

C.R.U.D Services:

- Create a resource using HTTP POST and content being resource format of choice,

- Read a resource using HTTP GET and standard HTTP content negotiation,

- Update a resource using HTTP GET to get resource properties to be updated and HTTP PUT to send updated resource,

- Link a resource using properties where values are just URIs (Unified Resource Identifiers),

- Delete a resource using HTTP DELETE.

Querying for resources

7 For a detailed description of REST, see http://en.wikipedia.org/wiki/Representational_state_transfer

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


V1.0 R 2015-04-30 17 of 230

- Query Capability, which has a base URI,

- Clients form query URI and HTTP GET the results,

UI Preview & Delegation

- Rich hover: Scenario supported: hover over link to get in context preview of resource

- Resource Delegation: Simple resource format defined and retrieved using HTTP content negotiation (e.g. Resource Picker for links, or Creation Factory)

Many of these services are defined in the specification of the OSLC standard. They are clustered by so called (engineering) domains: Change (Request) Management, Requirements Management, Quality Management, Architecture Management and others. Common principles are defined in the Core Specification (presented in section 4.2).

Ideally, the tools, used to build the Engineering Environments for the CRYSTAL Use Cases, would provide these services out of the box. As a matter of fact, there are already some commercial and open-source products which have IOS compliant service interfaces and some of the CRYSTAL partners have agreed to build such services for their products. In these cases the tools with the out of the box service interfaces would be already suitable bricks for the RTP library. If a tool does not have an IOS compliant interface, an adapter can be built, containing a web component to provide the needed IOS service(s) and uses internally the proprietary APIs to connect to the backend of the application. The tool together with the IOS adapter will then constitute an RTP brick. Where necessary, the brick providers in the CRYSTAL project are responsible for building the adapters for the tools needed for the CRYSTAL Use Cases.

2.4 CRYSTAL IOS Content & Scope Overview This section presents the content and the scope of the IOS, which has been enhanced in CRYSTAL from the CESAR, iFEST and the MBAT IOS. The following subsections are focused on presenting the main high-level concepts for describing the content of the IOS, its main technical concerns8, and its positioning with OSLC and existing Systems Engineering Standards.

2.4.1 IOS High-Level Concepts

The Figure 3 below gives an overview of the main concepts defined for characterizing the content of the IOS and their descriptions are provided in the following table.

8 It is worth noting that these two subsections replace the initial IOS architecture representation used in the first iteration

of this deliverable [4] that can be found in Annex of this document.


V1.0 R 2015-04-30 18 of 230

Figure 3: IOS High-Level Concepts

Table 1: Descriptions of the IOS High-Level Concepts

Term Description

IOS The CRYSTAL Interoperability Specification.

Lifecycle IOS The part of the CRYSTAL IOS focused on Lifecycle Interoperability, the latter being based on Artefacts used in Systems Engineering Development Environments (“Tool Chains”): (i) to support collaboration between stakeholders of different roles, different engineering disciplines, and different industrial domains, (ii) to enable status reporting, traceability, dashboarding, analysis, prediction, data collection for reports, automation support, etc., between Tools and Data Repositories.

Non-Lifecycle IOS

The part of the CRYSTAL IOS focused on Non-Lifecycle Interoperability for supporting In Depth Systems Engineering Activities. This part is based on existing Engineering Standards identified as already widely used among CRYSTAL partners and European developing organizations. CRYSTAL aims at supporting engineering activities focused on end-users’ businesses, and which require detailed, specific and “bespoke” semantics and methodologies besides lifecycle interoperability. Such engineering activities encompass heterogeneous co-simulation, combination of dynamic testing and formal static analysis, variability management, design space exploration, just to name a few.

OSLC Based Specification

The Interoperability Specifications defined by OSLC (Open Services for Lifecycle Collaboration) [5]. The OSLC initiative is creating a family of web services specifications for products, services and other tools that support all phases of the software and product lifecycle. The purpose of these specifications is to enable integration between products that support Application Life-cycle Management (ALM) and Product Life-cycle Management (PLM).

OSLC Core The OSLC Core specifications [6]. It sets out the common features that every OSLC Service can be expected to support using terminology from the World Wide Web Consortium (W3C). This specification is mostly about OSLC Services, it specifies what


V1.0 R 2015-04-30 19 of 230

OSLC Services MUST, SHOULD and MAY do. It also contains some required behaviors for OSLC clients and rules for OSLC domain specifications that extend this specification.

OSLC Domain The OSLC Domain Specifications [7]. Each domain (or part of the lifecycle) has its own group and specification, for example there are Change Management, Quality Management, Estimation & Measurement and more.

OSLC Resource Vocabulary

OSLC relies on the concept of Resource, the latter being managed by OSLC Services. An OSLC Resource is typically something like a Change Request, a Requirement or some other ALM or PLM artifact or record. Within each OSLC Domain is specified a vocabulary, consisting of a set of resource types, each of them defined by a URI – Unified Resource Identifiers, and a set of properties and relationships.

OSLC Core Service

The Core Services defined by OSLC for handling OSLC Resources. Typical services are:

C.R.U.D services (for Creating a resource using HTTP POST and content being resource format of choice, Reading a resource using HTTP GET and standard HTTP content negotiation, Updating a resource using HTTP GET to get resource properties to be updated and HTTP PUT to send updated resource, Linking a resource using properties where values are just URIs, Deleting a resource using HTTP DELETE),

Querying for resources, and

UI Preview & Delegation.

OSLC Domain Service

OSLC Services defined for an OSLC Domain-specific purpose, e.g., related to extensions of OSLC Query Capabilities via new query parameters.

CRYSTAL IOS Lifecycle Extension

The set of extensions to existing OSLC specifications proposed by the CRYSTAL consortium for supporting interoperability scenarios from the CRYSTAL Use Cases.

Extended OSLC Vocabulary

The vocabularies related to Lifecycle Interoperability defined by the CRYSTAL consortium as extensions of the existing ones defined within the OSLC Domains or as new IOS Domains (e.g., for Risk/Safety Management, Ontology Management, Formal Requirement Management, etc).

Extended Service

Extended (or added-value) Services related to Lifecycle Interoperability defined by the CRYSTAL consortium, e.g., related to Change Impact Analysis, Testing/Requirement Coverage, Automation support between Simulation & Design Activities, Advanced Services related to Ontology Management (e.g., pattern matching algorithms), etc.

CRYSTAL Ontology

The activities covered by the CRYSTAL Ontology workroup (encompassing the Ontology Work Packages on Aerospace, Automotive, Healthcare and Rail). This workgroup assesses:

domain-agnostic interoperability concerns (e.g., on Safety/Risk Management, Simulation, Digital Mockup, Variability Management, User Management),

and domain-specific standards and glossaries (e.g, coming from the Aerospace industrial domain: ISO DIS 10303-233, ISO 10303-239 PLCS, Behavioural Digital Aircraft, from the Automotive domain: ASAM-ODS, AUTOSAR, EAST-ADL, FMI, from the Healthcare domain: FDA. Part 820, DICOM GSDF, GMDN, ICPS, IEC 60601-1, IEC 60601-2, IEC 62304, IEC 62366, and from the Rail domain (IOP) that can be used as inputs of the CRYSTAL IOS Lifecycle Extension.

For more information about these activies, see [8, 9, 10, 11].

NLC Domain Non-Lifecycle Domains as part of the CRYSTAL Non-Lifecycle IOS for supporting In Depth Systems Engineering Activities based on existing Engineering Standards identified as already widely used among CRYSTAL partners and European developing organizations. Indeed, CRYSTAL aims at supporting engineering activities focused on end-users’ businesses, and which require detailed, specific and “bespoke” semantics and methodologies besides Lifecycle Interoperability. Such engineering activities encompass heterogeneous co-simulation, combination of dynamic testing and formal static analysis, variability management, design space exploration, just to name a few.

NLC Service Non-Lifecycle Interoperability Services defined in the context of Non-Lifecycle Domains.

Engineering Standard

Existing Engineering Standards defined by Standardization Bodies which have been adopted by the CRYSTAL consortium for supporting Non-Lifecycle Systems Engineering


V1.0 R 2015-04-30 20 of 230

Activities, and which are already widely used by CRYSTAL partners.

IOS Service A generic term for characterizing OSLC Core and Extended Services (as part of the Lifecycle IOS) and the NLC Services (as part of the Non-Lifecycle IOS).

2.4.2 IOS Positioning with OSLC

The Lifecycle Interoperability related part of the CRYSTAL IOS is based on a subset of OSLC (Open Services for Lifecycle Collaboration9). OSLC defines a set of specifications10 focusing on the support of lifecycle activities, and the following ones have been assessed to be part of the CRYSTAL IOS V1:

OSLC Core specification (see detail in section 4.4), relying on HTTP and core Web technologies, defining standardized ways for encoding and representing lifecycle artefacts, defining basic services for creating, requesting, updating, and deleting artefacts,

OSLC Requirement Management specification (see detail in section 4.5), defining primary requirement lifecycle artefacts,

OSLC Architecture Management specification (see detail in sectio 4.6), defining primary architecture lifecycle artefacts,

OSLC Asset Management specifications (see detail in section 4.7), mainly used in the context of CRYSTAL for defining a standardized way for wrapping Engineering Artefacts (i.e., assets used internally within the engineering tools as described in section 2.3.2),

OSLC Quality Management specification (see detail in section 4.9), defining primary lifecycle artefacts related to testing activities,

OSLC Change Request Management specification (see detail in section 4.8), defining primary lifecycle artefacts for handling change requests across the engineering disciplines.

These OSLC specifications have been considered to be integral part of the IOS for lifecycle interoperability after evaluations conducted on CRYSTAL Engineering Methods and across the CRYSTAL Industrial Domains (i.e., from SP2 to SP5). En example of such an assessment is presented in section 2.5.2.

Additionally, the following specifications have also been proposed as IOS V2 Candidates:

OSLC Configuration and Change Management specification (see detail in section 5.1),

OSLC Tracked Resource Set specification (see detail in section 5.2), allowing a server to expose an exact set of resources, track additions to and removals from the set, and track changes to the resources in the set,

2.4.3 IOS Positioning with other existing Engineering Standards

Besides Lifecycle Interoperability, the CRYSTAL IOS will also cover other interoperability topics for system engineering activities and will include relevant specifications and standards. Examples for topics that have been identified in the use cases are:

Functional Mock-up Interface (FMI) for co-simulation,

ASAM ODS for measurement data,

Semantic-preserving model transformations between input and output models,

ReqIF to interchange requirements,

AUTOSAR specifications in the automotive sector.

In several scenarios these standards are employed independently of each other, but in many cases a conceptual link has to be established between such standards and OSLC for Lifecycle Interoperability. The IOS may define specifications to bridge such standards and guidelines for their integration.

9 http://open-services.net 10 http://open-services.net/specifications/


V1.0 R 2015-04-30 21 of 230

Bottom line, the CRYSTAL Interoperability Specification will consist of a set of existing standards covering lifecycle and systems engineering activities, and of CRYSTAL specific extensions to these standards.

2.4.4 IOS Technical Concerns & Boundaries

On a technical standpoint, the CRYSTAL IOS relies on four main concerns for supporting data & tool interoperability (see Figure 4 and Table 2 below). It is worth noting that these concerns are characterized on the one hand for the Lifecycle IOS (i.e., OSLC and its CRYSTAL extensions), and on the other hand for its Non-Lifecycle part (i.e., the set of existing Systems Engineering Standards that will be adopted for supporting Systems Engineering activities). Examples for each of these concerns are given in Table 2 as well.

Figure 4: IOS Technical Concerns.

Table 2: Description of the main IOS Technical Concerns.

Term Description

Foundation Principles The core philosophies and main design considerations on which the IOS standards rely. In the case of the Lifecycle IOS with OLSC, the foundation principles are the following: the approach is built on W3C standards and technologies according to RESTful principles11, and aligned with the W3C Linked Data Initiative. In the case of the Non-Lifecycle IOS, e.g., if we consider FMI for heterogeneous co-simulation, the foundation principles are based on differential, algebraic and discrete equations with time, state and step-events.

Communication Protocols The system of rules for data exchange within or between computers for

11 http://en.wikipedia.org/wiki/Representational_state_transfer


V1.0 R 2015-04-30 22 of 230

supporting data & tool interoperability. For instance, OSLC relies on HTTP whereas FMI relies on linked executable files executed on a single computer.

Syntax Syntax (or concrete syntax) refers to as the formats used for serializing data as strings. For instance RDF/XML in the case of OSLC, or C headers and XML files in the case of FMI.

Semantics Semantics (or abstract syntax) refers to as the definition of a set of concepts with their properties and relationships used for data exchanges between integrated engineering tools and repositories. For instance, OSLC Resource vocabularies, or FMU concepts, respectively in the context of OSLC and FMI.

The IOS boundaries are then explicitly characterized by these four concerns. Indeed, for the Lifecycle IOS, OSLC core specifications define the Foundation Principles, Communication Protocols and Syntax of the data to be exchanged between IOS based integrated tools and repositories, and its Semantics is explicitly defined by the OSLC Resource Vocabularies and the CRYSTAL Extended Resource Vocabularies specified in the section 5 of this document. In the context of the Non-Lifecycle IOS for which Systems Engineering Standards are being adopted, these concerns are specified by their technical specifications, as it is the case for FMI for co-simulation for instance, and as further detailed in section 5.10.

The upper part of the Figure 5 below informally illustrates how IOS compliant adaptors, respectively in parts (A) and (B) of the Figure, expose and exchange Lifecycle and Non-Lifecycle Linked Data between two engineering tools or data repositories (as already presented in the subsection 2.3.2). In these both cases, the IOS compliant adaptors implement the technical concerns presented above. In some other cases however, subparts of an interoperability scenario might rely on tool specific exchanges of data that are out-of-scope of the IOS, as illustrated on the part (C) of the Figure. Therefore, tool or repository specific adaptors might have to be implemented for providing and consuming these non-IOS data. Finally, within the IOS related activities implemented within CRYSTAL, we are striving for eliciting as many common interoperability patterns and scenarios as possible across the CRYSTAL industrial domains, use cases and partners in order to harmonize, consolidate and pre-standardize IOS Domains that will be pushed forward in relevant Interoperability and Systems Engineering standards. The guidelines that have been implemented in CRYSTAL for supporting such a process are given in section 2.7.

Figure 5: IOS Based Linked Data Representation and Exchange between Integrated Tools & Data Repositories.


V1.0 R 2015-04-30 23 of 230

2.5 CRYSTAL IOS V2 Inputs Collection Process

2.5.1 IOS V2 Inputs

The CRYSTAL IOS V1 deliverable [4] was exclusively focused on Lifecycle Interoperability, and based on a subset of the existing OSLC specifications. In this version of the IOS deliverable (V2) has been collected a set of inputs coming from the following sources:

1. From IOS extensions that have been already adopted in former ARTEMIS projects, notably from MBAT (e.g., MBAT proposed IOS lifecycle interoperability extensions for supporting tight combination of testing and analysis methodologies),

2. From existing Systems Engineering Standards as part of the Non-Lifecycle IOS, for which areas of overlap with the concepts defined for Lifecycle Interoperability may be identified,

3. From existing OSLC domain specifications that have been assessed in CRYSTAL after the release of the IOS V1 deliverable,

4. From CRYSTAL SP6 Technical Work Packages,

5. From the CRYSTAL approach that has been implemented in the project for identifying IOS Domains and Services from CRYSTAL Use Cases & Engineering Methods,

6. And finally, from the Ontology Working Group that has been put on place in CRYSTAL, and consisting of the Ontology Work Packages from the Aerospace, Automotive, Healthcare and Rail industrial domains.

In the following two subsections, we give an overview of the activities that have been respectively implemented within the CRYSTAL approach, and by the Ontology Working Group.

2.5.2 CRYSTAL Approach: Engineering Methods to IOS Services

This subsection aims at providing a short overview of the process that has been implemented among the CRYSTAL Use Case providers in order to identify the IOS Services and Domains required for fulfilling their interoperability needs. From an IOS standpoint, the IOS V1 specifications and some IOS V2 proposals presented in this deliverable result from this process.

2.5.2.1 Engineering Method (EM) to IOS Services Mapping Methodology

For the CRYSTAL scenario based approach, it is important to identify where and which IOS functionality is needed to make the scenario interoperable. During analysis steps of the scenarios/use cases, the required building blocks (Bricks) are already identified and reusable “sub scenarios” (Engineering Methods, EMs) are defined as described in the overall CRYSTAL Technical Management Process.

The identification of the IOS needs is based on these EMs. In order to do this, the Use Case owners need to describe their EMs on a detail level, which allows assigning the necessary IOS functionality (IOS services) to the individual EM steps (e.g., the EM step “get a list of requirements” can be mapped to an “OSLC basic query service” provided by a requirement management brick).

For the Lifecycle Interoperability based on OSLC, many services are already defined by the OSLC standard and can be used as a first set to be assigned to EM steps. Missing services (Lifecycle Interoperability and others services) can be described in addition. If such a service is needed by multiple EMs, it can be a candidate for an IOS extension. If the service is not chosen to be a part of IOS, it can still be implemented as an individual solution for the EM. Detailed criteria for accepting services to be part of IOS still need to be defined, but the general applicability in multiple EMs and in multiple industrial domains as well as the chances for standardization will be among them.

This approach allows, and the Use Case owners are encouraged to, to define the IOS mapping in multiple iterations. In a first iteration, only those IOS services should be listed which are obvious or needed for a first implementation of the Use Case. With later iterations, more and more IOS services can be added.

Owners of the EM description and the IOS mapping are the Use Case owners; the IOS team has appointed IOS experts for each domain to help identifying the right IOS services. Also the brick owner of the bricks used for the EM should be involved in the IOS service identification process.


V1.0 R 2015-04-30 24 of 230

Training material for the IOS mapping has been provided and multiple webcasts have been conducted to train this mapping process.

Already during the first EM step to IOS service mapping exercises, this process has be shown to be very useful, not only to define the necessary services but also to clarify the engineering steps and make decisions regarding the implementation.

2.5.2.2 Engineering Method Steps – IOS service mapping table

In order to do the mapping of the EM steps and IOS service, the EM description template has been extended by the EM step to IOS service mapping table.

This table has the following columns:

IOS Domain: Identifies the IOS (engineering) domain where the service is selected from

Examples: OSLC-RM, OSLC-QM, OSLC-CM, FMI or other

The value “none” should be used if the EM step is completely handled within a brick and no interoperability with other bricks is required.

IOS Service: IOS service to be used for the EM step

Examples: create, read, update, basic-query, DUI-picker, export-FMU

IOS Service Detail (optional): Additional service parameters can be specified (e.g., properties to be used, special values required)

Brick Allocation (provider): Identifies the brick that need to provide the service (typically the data owner)

Brick Allocation (consumer): Identifies the brick that consumes the service (typically user interactions)

EM / EM Step: EM name as defined in the EM sheet of the same document

EM step number as assigned in the EM sheet of the same document

Comments: Any additional comment, e.g., for the implementer of the service, or remark why this IOS service was chosen in favour of another possible IOS service.

2.5.2.3 Engineering Method Steps – IOS service mapping table example

This is an (abbreviated) example of an EM step – IOS mapping table to illustrate how such a table can look like. It is a part of UC 401 of the Healthcare domain and describes IOS services used for the EM “Verify Requirements”.


V1.0 R 2015-04-30 25 of 230

Figure 6: Example of an EM – IOS Service Mapping table (excerpt)

2.5.3 CRYSTAL Ontology Working Group

This subsection presents the methodology agreed between the CRYSTAL ontology WPs in order to contribute to the IOS. It is a summary of the detailed process presented in the CRYSTAL deliverables released by the Ontology Work Packages on Aerospace, Automotive, Healthcare and Rail industrial domains [8, 9, 10, 11].

A coordination team involving these CRYSTAL ontology WPs and SP6 representatives was set up; this initiative addresses the recommendations from the first project review. At each ontology WP level, a similar approach is defined about how to identify IOS V2 candidates from both the project use cases and from supplementary standards and glossaries. The main steps of the process implemented in this Working Group are the following (and are represented on the Figure 7 below):

A first step within the group consisted in capturing domain specific Engineering Artefacts from the CRYSTAL Use Cases in their respective industrial domains (see sections 3 of [8, 9, 10, 11] for detailed explanations).

An Excel template has been defined in order to help structuring the information captured from the use cases, based on (i) the Engineering Method worksheets (from the CRYSTAL approach described in section 2.5.2), (ii) the reading of some use cases’ deliverables, as well as of (iii) direct use cases contributions. The process for filling out this template has been iterative among all the partners of the Ontology Working Group.

Finally, after some harmonization and consolidation of these inputs, Extended Resource Vocabularies (as represented on Figure 3) have been proposed as IOS V2 candidates in this deliverable.


V1.0 R 2015-04-30 26 of 230

Figure 7: Convergence between CRYSTAL Domain Ontology WPs towards IOS V2 Inputs

2.6 IOS Extension Mechanisms & Process As represented on the Figure 3, the CRYSTAL IOS can be extended either (1) for supporting Lifecycle Interoperability via extensions of the existing OSLC specifications, or (2) by adopting existing and already widely adopted Systems Engineering Standards.

2.6.1 IOS Extensions Mechanisms for Lifecycle Interoperability

This subsection aims at clarifying the links between existing OSLC specifications and the CRYSTAL extensions for Lifecycle Interoperability12.

In OSLC, a Resource Type Definition pertains to a given domain. The Resource Type Definition basically consists of:

A name

A type URI

A set of common properties and relationships

o Defined by OSLC (Common Properties & Resource Type Definitions)

http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA

o Or reused from existing standards, e.g.:

Dublin Core Properties (http://dublincore.org/documents/2010/10/11/dces/ )

RDF/RDFS (http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/).

A set of Resource specific properties and relationships

o They are tool or use case specific properties that have to be exposed via an existing resource type. In this document the expression “Existing Resource specific properties and relationships” refer to those that have already been agreed by OSLC.

Various options may arise while extending the OSLC specifications by CRYSTAL IOS V2 input providers. They are described in the following, and sketched on the Figure 8 below:

12 A document that has been distributed internally within the consortium can be found from the following link for more details (restricted access): https://projects.avl.com/IOS_OSLC_Vocabulary_Extension_Guidelines.

http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA

http://dublincore.org/documents/2010/10/11/dces/

http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/

https://projects.avl.com/IOS_OSLC_Vocabulary_Extension_Guidelines


V1.0 R 2015-04-30 27 of 230

1. An IOS Domain defined in CRYSTAL may take over an existing OSLC domain.

2. The artefacts’ properties defined in CRYSTAL may be “industrial domain” specific (Rail, Aerospace, etc.) or eligible as a CRYSTAL core property if they are common to all or several industrial domains.

3. A CRYSTAL IOS domain candidate may extend an existing OSLC resource, meaning that it refers to the same resource type but adds either common or CRYSTAL specific properties to it.

4. A CRYSTAL IOS candidate may not match with any existing OSLC resource, but still pertain to an existing OSLC domain; in this case a new resource type is created in that domain and its properties are specified. These properties may come from existing OSLC properties or from CRYSTAL specific properties.

5. A new CRYSTAL IOS domain can be proposed, with new IOS candidates, exhibiting again, properties that may come from existing OSLC domains or from CRYSTAL specific properties (core or specific to an IOS Domain).

Figure 8: IOS Extension Mechanisms for Lifecycle IOS

2.6.2 IOS Extension Mechanisms for Non-Lifecycle Interoperability

Finally, in order to support other interoperability concerns related to in depth (Safety-Critical) Systems Engineering activities, other existing Engineering Standards can be adopted and will then consist of new IOS chapters as well. As an example, this version of the deliverable proposes the adoption of FMI13 for supporting heterogeneous co-simulation. These IOS candidates may also define bridges between Non-Lifecycle related concepts and the concepts defined by IOS Lifecycle Domains (as represented on the Figure 3).

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

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


V1.0 R 2015-04-30 28 of 230

2.7 Guidelines for Supporting Information Exchanges not yet defined as part of the IOS This subsection aims at providing an overview of the process to be followed when information not (yet) standardized by the IOS has to be exchanged between engineering tools or data repositories as defined by industrial use cases. This process has been implemented in CRYSTAL (as part of the so-called CRYSTAL approach), and its preliminary outcomes are presented as IOS V2 candidates in section 5. The process is the following:

1. The interoperability scenarios defined by use cases have to be derived into a set of Engineering Methods (EMs). For this purpose, CRYSTAL provides an Excel template from which workflows (consisting of a set of Steps, as introduced in section 2.5.2) can be clearly elicited. This template also provides the capability to list the generic engineering artifacts to be exchanged and/or linked across these steps.

2. Within CRYSTAL, SP6 experts give some advices to use case owners for defining Engineering Methods in order to make the best use of IOS, i.e., (1) in alignment with the IOS foundation principles, and (2) related to the mapping of EM Steps to CRYSTAL Bricks and IOS Services (as described in section 2.5.2.3).

3. In order to address interoperability issues not yet covered by the IOS, the two following cases apply:

1. The IOS is enhanced:

o By proposing new CRYSTAL specific concepts and extensions (as described in section 2.6),

o And by promoting these extensions to relevant Standardization Bodies (see section 2.8 on the next steps towards IOS Sustainability).

2. Or the exchange of information is performed in a non-standardized way:

o Using IOS extension points but only defined in the context of a specific use case (i.e., used in the context of a single developing organization),

o Or not using the IOS at all.

4. Finally, within the RTP Working Group that has been implemented in CRYSTAL, Generalized Engineering Methods are being defined, and will be serving as reference solutions on how to use the IOS concepts for a given purpose.

2.8 Next Steps Towards IOS Sustainability As already mentioned in section 1.2, the IOS V2 inputs presented in the section 5 of this deliverable have been provided by multiple CRYSTAL working groups and partners. However, at that stage, these inputs have not been exhaustively evaluated, consolidated and harmonized at project level. In consequence, this process will be implemented in the remaining year of CRYSTAL, and the outcomes of these pre-standardization activities will be presented in the final iteration of this deliverable (i.e., the IOS V2) to be released at the end of the project.

Moreover, in order to make the CRYSTAL Interoperability Specification a sustainable result, it is important to gather experience and to start communication with existing bodies regarding interoperability standardization (or de- facto standardization). The CRYSTAL deliverables D601.031 and D601.032 (Report on Standardisation Work - V1 & V2 [12, 13]) reports on activities and achievements with regard to the standardization of the Interoperability Specification. Furthermore, within these deliverables, alignments with other projects are documented and evaluated.

Finally, an IOS Support Action, called CP-SETIS, which has been incubated by the MBAT and CRYSTAL projects in 2014, has been recently founded by H2020, and has been officially kick-started in March 2015.

The two main challenges to be addressed by CP-SETIS can be summarized as follow:

Challenge 1 (Organizational & Strategic): A common vision and mission, shared by all major stakeholders, for supporting lifecycle data and tool interoperability for CPS Engineering has to be established urgently and acted upon, aligning the as yet only partially coordinated European IOS-related activities and paving the way for establishing the IOS as a major standard in CPS Engineering.

Challenge 2 (Technical): A clear bridge has to be defined between the on-going definition of the IOS and other wide spread Interoperability and Engineering Standards commonly used by European


V1.0 R 2015-04-30 29 of 230

developing organizations (e.g., ASAM14, FMI15, AUTOSAR16, STEP17, OMG ReqIF18, etc.) for supporting CPS Engineering activities.

In order to tackle these issues, CP-SETIS is articulated by the following goals and objectives:

• Goal 1: The alignment of all IOS-related forces within Europe to support a common IOS Standardization Strategy, aiming at a formal standardization process of the IOS.

• Goal 2: The definition and implementation of sustainable IOS Standardization Activities supporting formal standardization of IOS versions and its extensions, if possible within existing structures that survive the lifespan of single projects.

Bottom line, the IOS related activities in CRYSTAL will be directly anchored to CP-SETIS in order to promote standardization of CRYSTAL outcomes to relevant standardization bodies and project consortia.

14 Association for Standardisation of Automation and Measuring Systems, http://asam.net 15 Functional Mockup Interface for model exchange and tool coupling, https://www.fmi-standard.org 16 AUTomotive Open System Architecture, http://autosar.org 17 STEP – standing for "Standard for the Exchange of Product model data" is the informal name used for the ISO 10303 standard for the computer-interpretable representation and exchange of product manufacturing information. The official title is “Automation systems and integration — Product data representation and exchange”. 18 Requirements Interchange Format, http://www.omg.org/spec/ReqIF/

http://asam.net/

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

http://autosar.org/

http://www.omg.org/spec/ReqIF/


V1.0 R 2015-04-30 30 of 230

3 Overview of the IOS Chapters

An overview of the IOS chapters presented in this deliverable is given on the Table 3 below. The table presents the list of IOS Domains covered by these chapters, their types (i.e., Lifecycle or Non-Lifecycle) and their sources. The Figure 9 also presents a mapping of these IOS chapters onto the IOS High-Level Concepts already presented in the section 2.4.1. Please note that most of the detailed Resource and Property types of the IOS Lifecycle Domains are given in appendix of this deliverable.

Table 3: IOS Chapters Overview.

# IOS Chapter ID IOS Domain Name Type19

IOS Version

Source Deliverable’s Section

1 IOS V1 LC V1 CRYSTAL WP6.1 / OSLC

OSLC Core Capabilities Section 4.4

OSLC Requirement Management Section 4.5

OSLC Architecture Management Section 4.6

OSLC Asset Management Section 4.7

OSLC Change Request Management Section 4.8

OSLC Quality Management Section 4.9

2 IOS CCM LC V2 CRYSTAL WP6.11 / OSLC

OSLC Change and Configuration Management Section 5.1

3 OSLC TRS LC V2 CRYSTAL WP6.11 / OSLC

OSLC Tracked Resource Set Section 5.2

4 CRYSTAL Ontologies IOS

LC V2 CRYSTAL Ontologies Working Group

IOS Requirement Management Section 5.3

IOS Architecture Management Section 5.3

IOS Variability Management Section 5.3

IOS Quality Management Section 5.3

5 IOS KM LC V2 CRYSTAL SP6 Brick Provider / REUSE

IOS Knowledge Management Section 5.4

IOS Pattern Management Section 5.4

6 MBAT IOS Meta Model

LC V2 MBAT IOS from the MBAT Meta Models

MBAT IOS MM Architecture Management Section 5.5

MBAT IOS MM Verification & Validation Management Section 5.5

MBAT IOS MM Traceability Management Section 5.5

7 IOS FRM LC V2 CRYSTAL WP6.3 / OFFIS

IOS Formal Requirement Management Section 5.6

8 IOS SM LC V2 CRYSTAL WP6.4 / OFFIS

IOS Safety Management Section 5.7

9 IOS VTC LC V2 CRYSTAL RTP Team

Verify Test Coverage Section 5.8

10 Support of Automotive Standards

LC V2 CRYSTAL WP6.5 / Volvo

IOS for EAST-ADL and AUTOSAR Section 5.9

11 FMU NLC V2 CRYSTAL Working Group on Co-Simulation

Functional Mockup Units for Co-Simulation Section 5.10

19 LC: Lifecycle IOS, NLC: Non-Lifecycle IOS.


V1.0 R 2015-04-30 31 of 230

IOSChapters1,3

IOSChapters1,2

IOSChapters4,5,6,7,8,9,10

IOSChapters11

Figure 9: IOS Chapters mapped onto IOS High-Level Concepts.


V1.0 R 2015-04-30 32 of 230

4 Interoperability Specifications V1

4.1 IOS V1 Basic Lifecycle Interoperability Scenarios

4.1.1 Overview of the Scenarios

As already detailed around the Figure 9 presenting the CRYSTAL IOS layered architecture, this first version of the deliverable is focused on the support of Lifecycle Interoperability activities, and the current content of the IOS consists of the OSLC Core specifications defining the cornerstone principles of the IOS, and of the OSLC specifications for Requirement, Architecture, Quality Management (respectively OSLC RM, AM and QM), and the OSLC Change Request Management and Asset Management specifications.

This set of specifications can be notably used for supporting the following generic lifecycle interoperability operations and scenarios:

1. The Creation, Request, Update and Delete (CRUD) operations to be performed on Lifecycle Artefacts (from OSLC Core),

2. The creation of links, and navigation between and across Lifecycle Artefacts in a systematic way (from the W3C Linked Data principle, part of OSLC Core),

3. The redirection of User Interfaces (UI) for basic query or creation of remote Lifecycle Artefacts, or for displaying user friendly graphical representations of Engineering Artefacts across the engineering disciplines and stakeholders (from OSLC Core),

4. Included here are examples of the application of these basic services patterns across the domains as defined today by OSLC:

a) The exposition of basic Lifecycle Artefacts from different engineering phases (from OSLC RM, AM and QM),

b) The lifecycle scenario for supporting basic change requests (from OSLC Change Request Management),

c) The scenarios for which Engineering Artefacts (i.e., not IOS/OSLC based) have to be exposed as “raw data/file” (from OSLC Asset Management).

4.1.2 Descriptions of the Scenarios

The basic multiple brick interoperability scenarios covered here use the following convention:

Brick A is a “local” tool which originates the transaction from either a User Interface (UI) or a program event. Local meaning as initiating or having primary control of processing or receiving the results of remote processing, or being the place that flow returns to after some secondary processing.

Brick B is a “remote” tool which receives and responds to the transaction. Remote meaning as directed or secondary processing or receiving temporary control of processing or parallel processing or relinquishing control to another tool.

Brick C is an “intermediate” or “additional” tool needed to complete the transaction, e.g. it may be a specific UI component of say Brick A or B but its purpose is to enable Web compliant information rendering (i.e. via HTTP and HTML) in response to say a GET.

Bricks can have local, or remote, or distributed functions, e.g., thick client, thin client, browser, and server components. No distinction is made whether tools have user interfaces.

Bricks, in IOS V1 use services to communicate and so may use infrastructure components like Web or proxy servers, these are out of scope (transparent) for the basic tool interoperability scenarios.

The IOS V1 specification addresses the external interfacing needed for tool interoperability and not the enabling infrastructure, like co-existence of operating systems or protocol conversion.

These schemes aim to indicate recurring patterns of interoperability and do not show any needed authentication of users or services, nor the internal interfaces required to add or enable service-based transaction, nor do they address licensing needs.


V1.0 R 2015-04-30 33 of 230

4.1.2.1 Interoperability Pattern 1: Access remote artefact

Within Brick A access a remote artefacts for Create, Read, Update or Delete (CRUD) in remote Brick B.

Figure 10: IOS Interoperability Pattern 1: Access remote Lifecycle Artefact

Note: Implementers need to ensure the idempotency (i.e., the result of the request should be independent of the number of times the service is executed) of HTTP operations on remote artefacts, particularly PUT and POST.

An overview of the main transactions to achieve this scenario follows on the Figure below.

Figure 11: IOS Interoperability Pattern 1: Access remote artefact - Sequence diagram

4.1.2.2 Interoperability Pattern 2: Store link to remote artefact

Within Brick A saves (holds) a local link (URI) to a remote artefact owned by Brick B


V1.0 R 2015-04-30 34 of 230

Figure 12: IOS Interoperability Pattern 2: Store link to remote artefact

It is assumed that the URI is used to associate Artefact A with Artefact B, it is also possible that Brick A just registers the URI in a catalogue.


Figure 13: IOS Interoperability Pattern 2: Store link to remote artefact - Sequence diagram

4.1.2.3 Interoperability Pattern 3: Access remote artefact with UI redirection

Redirected user interface for remote artefact to Brick C, e.g., a browser.


V1.0 R 2015-04-30 35 of 230

Figure 14: IOS Interoperability Pattern 3: Access remote artefact with UI redirection

Note: Brick C is a separate UI component. It can be hosted by Brick A, B or a separate Brick C. An example is an OSLC delegated UI which is Brick B UI hosted by Brick A.


Figure 15: IOS Interoperability Pattern 2: Access remote artefact using a delegated UI - Sequence diagram

Within scenario 3 the IOS provides multiple options such as query and creation dialogs and delegated user interfaces. A delegated UI removes the burden from Brick A of processing data that is likely to be incompatible with its own native data.


V1.0 R 2015-04-30 36 of 230

These basic scenarios are tailored by the use of domain vocabulary such as for:

1. Exposing of Lifecycle Artefacts from different engineering phases like Requirements, model Resources and Test Plans (using OSLC RM, AM and QM respectively),

2. Support for change requests (OSLC Change Management). Note here that there is no implied lifecycle state control; any consumer wishing to change the state of a resource is assumed to do so by a POST of a new status property/value pair to a Change Request resource.

3. Support where Artefacts are exposed without reference to one of the lifecycle domain directly (e.g. not IOS/OSLC based) examples could be part of a file system used by a tool which is not available as a Brick “raw data/file” (using the OSLC Asset Management spec).

4.2 Core Concepts and Principles inherited from OSLC

At V1 the CRYSTAL IOS is concerned with the following tool interoperability styles:

Service based tool interoperability used WWW and loosely coupled principles.

CRYSTAL IOS adopts:

Service based tool interoperability from OASIS20, which defines service as "a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description21."

RESTful22 Web service technologies.

4.2.1 IOS Vocabulary

Crystal IOS V1.0 adopts an information model that is defined through OSLC V2.0 domains. The IOS vocabulary is defined with the domain specifications selected from OSLC V2.0.

4.2.2 Resources

The various defined Resources are detailed below with the domains.

4.2.3 Linktypes

The various defined linktypes are defined below with the domains

4.2.4 Properties

The various defined properties are defined below with the domains.

4.3 Notes on application of OSLC V2.0 at IOS V1.0 There are certain logs of issues with the OSLC V2.0 that implementers should also refer to, these are noted. It is recommended that implementers follow, review and join the OASIS OSLC working group proceedings around these issues to draw upon the community experience.

4.4 IOS Chapter – Core Capabilities

20 http://en.wikipedia.org/wiki/OASIS_%28organization%29 21 http://en.wikipedia.org/wiki/Service_%28systems_architecture%29 - cite_note-1 22 http://en.wikipedia.org/wiki/Representational_State_Transfer

http://en.wikipedia.org/wiki/OASIS_%28organization%29

http://en.wikipedia.org/wiki/Service_%28systems_architecture%29#cite_note-1

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


V1.0 R 2015-04-30 37 of 230

4.4.1 Common Core Capabilities

IOS ref.

Capability Description Source Org Source ref Notes

1 Service entry point

Uniform Resource Identifier (URI)

W3C/IETF http://tools.ietf.org/html/rfc3986

2 Service protocol Hypertext Transfer Protocol (HTTP)

W3C/IETF http://tools.ietf.org/html/rfc2616

3 Resource definition & operations

Resource Description Framework

OSLC

W3C LDP

http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;table=up - OSLC_Defined_Resources

http://www.w3.org/TR/PR-rdf-syntax/

http://www.w3.org/2000/01/rdf-schema - >

4 Service document types

RDF/XML W3C http://www.w3.org/TR/REC-rdf-syntax/

http://www.w3.org/TR/2014/REC-turtle-20140225/

5 Error responses HTTP status codes W3C http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

6 Namespace extension

W3C http://www.w3.org/TR/REC-xml-names/

7 Paging Resource Paging OSLC http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;up= - Resource_Paging

http://open-services.net/resources/tutorials/oslc-primer/resource-paging/

8 Simple query A simplified and specific query

OSLC http://open-services.net/bin/view/Main/OslcCoreSpecification#Query_Capabilities

Non SPARQL query

4.4.2 Service Provider Capabilities

IOS ref.

Capability Description Source Org

Source ref Notes

9 Discovery Engage a provider to understand service content available

OSLC

http://open-services.net/wiki/core/Discovery-3.0/

10 Service provider

Service Provider OSLC http://open-services.net/bin/view/Main/O

http://tools.ietf.org/html/rfc3986




http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;table=up#OSLC_Defined_Resources







http://www.w3.org/2000/01/rdf-schema#>

http://www.w3.org/2000/01/rdf-schema#>

http://www.w3.org/TR/REC-rdf-syntax/

http://www.w3.org/TR/REC-rdf-syntax/



http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html



http://www.w3.org/TR/REC-xml-names/

http://www.w3.org/TR/REC-xml-names/

http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;up=#Resource_Paging









http://open-services.net/bin/view/Main/OslcCoreSpecification#Query_Capabilities







http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;up=#Service_Provider_Resources



V1.0 R 2015-04-30 38 of 230

catalogue slcCoreSpecification?sortcol=table;up= - Service_Provider_Resources

11 Resource CRUD services

Create, Read, Update and Delete Resource through GET, PUT POST and DELETE transactions

OSLC http://open-services.net/wiki/reconciliation/OSLC-Reconciliation-Specification-Version-2.0/

PUT should not be assumed to be idempotent

12 Creation Factory

A service to create new resources

OSLC

13 Dialogs User interaction dialog OSLC http://open-services.net/bin/view/Main/OslcCoreSpecification

See resource: Dialog

14 Delegated User Interface (DUI)

In-context information displayed from a link

OSLC http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;table=up;up= - Delegated_User_Interface_Dialogs

http://open-services.net/wiki/core/User-Interface-Previews-3.0/

15 UI preview User interface or resource preview

OSLC http://open-services.net/bin/view/Main/OslcCoreUiPreview

4.4.3 Service Consumer Capabilities

IOS ref.


16 Provider registration

A consumer client registers a Service provider (URI and description)

OSLC http://open-services.net/resources/tutorials/integrating-products-with-oslc/implementing-an-oslc-provider/providing-service-providers-and-catalogs/

Tutorial

17 Provider authentication

A consumer can authenticate successfully with a Service Provider

OSLC http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;up= - Authentication

18 Service selection

A consumer can locate a service type from a provider

OSLC http://open-services.net/bin/view/Main/OslcCoreSpecification

See Overview

19 Delegated UI usage

A consumer client can provide a frame for a provider UI and render the content

OSLC http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;table=up;up= - Delegated_User_Interface_Dialogs

4.4.4 Advanced Core Capabilities




http://open-services.net/wiki/reconciliation/OSLC-Reconciliation-Specification-Version-2.0/




http://open-services.net/bin/view/Main/OslcCoreSpecification



http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;table=up;up=#Delegated_User_Interface_Dialogs









http://open-services.net/bin/view/Main/OslcCoreUiPreview



http://open-services.net/resources/tutorials/integrating-products-with-oslc/implementing-an-oslc-provider/providing-service-providers-and-catalogs/






http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;up=#Authentication














V1.0 R 2015-04-30 39 of 230

IOS ref.


20 Service and User Authentication

Open standard for Authentication (OAUTH)

IETF RFC5849 - The OAuth 1.0 Protocol

OSLC http://open-services.net/resources/tutorials/oslc-primer/oauth/

Guideline

4.5 IOS Chapter – Domain Support: Requirement Management

IOS ref.


21 Requirement

Primary Requirements Management artefact

OSLC http://open-services.net/bin/view/Main/RmSpecificationV2

22 Vocabulary for Resources

Requirements Management vocabulary

OSLC http://open-services.net/bin/view/Main/RmSpecificationV2?sortcol=table;up= - RM_Resource_Definitions

23 Linkage predicates

Requirements Management specification

OSLC http://open-services.net/bin/view/Main/RmSpecificationV2?sortcol=table;up= - RM_Relationship_Properties

24 Resource states

Requirement lifecycle states

OSLC Not defined in OSLC V2.0 as not present in OSLC V2.0

25 Issues V2.0 Spec issues OSLC http://open-services.net/wiki/requirements-management/OSLC-Requirements-Management-version-2.0-issues/

4.6 IOS Chapter – Domain Support: Architecture Management

IOS ref.


Source ref Notes

26 Resource Primary Architecture Management resource

OSLC http://open-services.net/wiki/architecture-management/OSLC-Architecture-Management-Specification-Version-2.0/


Architecture Management vocabulary

OSLC http://open-services.net/wiki/architecture-management/OSLC-Architecture-Management-Specification-Version-2.0/ - AM-Resource-Definitions

28 Linktype Architecture Management specification

OSLC http://open-services.net/wiki/architecture-management/OSLC-Architecture-Management-Specification-Version-2.0/ - Resource_Link_Type_Resource_LTR



http://open-services.net/resources/tutorials/oslc-primer/oauth/



http://open-services.net/bin/view/Main/RmSpecificationV2



http://open-services.net/bin/view/Main/RmSpecificationV2?sortcol=table;up=#RM_Resource_Definitions





http://open-services.net/bin/view/Main/RmSpecificationV2?sortcol=table;up=#RM_Relationship_Properties






http://open-services.net/wiki/requirements-management/OSLC-Requirements-Management-version-2.0-issues/






http://open-services.net/wiki/architecture-management/OSLC-Architecture-Management-Specification-Version-2.0/



http://open-services.net/wiki/architecture-management/OSLC-Architecture-Management-Specification-Version-2.0/#AM-Resource-Definitions




http://open-services.net/wiki/architecture-management/OSLC-Architecture-Management-Specification-Version-2.0/#Resource_Link_Type_Resource_LTR





V1.0 R 2015-04-30 40 of 230

29 Resource states

Resource lifecycle

OSLC Not provided in IOS V1 as not present in OSLC V2.0

30 Issues OSLC V2.0 issues

OSLC http://open-services.net/wiki/architecture-management/OSLC-Architecture-Management-v2.0-Specification-Issues/

4.7 IOS Chapter – Domain Support: Asset Management

IOS ref.


Source ref Notes

31 Asset Primary Asset Management resource

OSLC http://open-services.net/wiki/asset-management/OSLC-Asset-Management-2.0-Specification/ - Asset

32 Artefact Primary Asset Management resource

OSLC http://open-services.net/wiki/asset-management/OSLC-Asset-Management-2.0-Specification/ - Artifact

33 Artefact media

Primary Asset Management resource

OSLC http://open-services.net/wiki/asset-management/OSLC-Asset-Management-2.0-Specification/ - Artifact_Media


Asset Management vocabulary

OSLC http://open-services.net/wiki/asset-management/OSLC-Asset-Management-2.0-Specification

See OSLC Asset: Start of additional properties


Asset Management specification

OSLC http://open-services.net/wiki/asset-management/OSLC-Asset-Management-2.0-Specification

See Relationship Properties

36 Resource states

Resource lifecycle OSLC Not provided in V1.0 as not present in OSLC V2.0

37 Issues OSLC V2.0 Issues

OSLC http://open-services.net/wiki/asset-management/OSLC-Asset-Management-2.0-specification-issues/

4.8 IOS Chapter – Domain Support: Change Request Management

IOS ref.


Source ref Notes

38 Change Request

Primary Change Management artefact

OSLC http://open-services.net/bin/view/Main/CmSpecificationV2?sortcol=table;up= - Resource_ChangeRequest


Change Management vocabulary

OSLC


Change Management specification

OSLC http://open-services.net/bin/view/Main/CmSpecificationV2?sortcol=table;up= - Resource_ChangeRequest

Relationship properties

http://open-services.net/wiki/architecture-management/OSLC-Architecture-Management-v2.0-Specification-Issues/



http://open-services.net/wiki/asset-management/OSLC-Asset-Management-2.0-Specification/#Asset




http://open-services.net/wiki/asset-management/OSLC-Asset-Management-2.0-Specification/#Artifact




http://open-services.net/wiki/asset-management/OSLC-Asset-Management-2.0-Specification/#Artifact_Media




http://open-services.net/wiki/asset-management/OSLC-Asset-Management-2.0-Specification






http://open-services.net/wiki/asset-management/OSLC-Asset-Management-2.0-specification-issues/




http://open-services.net/bin/view/Main/CmSpecificationV2?sortcol=table;up=#Resource_ChangeRequest









V1.0 R 2015-04-30 41 of 230

41 Change Request states1

Change Management Specification

OSLC http://open-services.net/bin/view/Main/CmSpecificationV2?sortcol=table;up= - State_Predicates

See also

OSLC CM: Start of additional properties and State predicate properties


OSLC http://open-services.net/wiki/change-management/Issues-2.0/

Note: Neither IOS V1 nor OSLC V2.0 provide control over Artefacts through events e.g. like a POST. Artefact state change is achieved through normal use of PUT.

4.9 IOS Chapter – Domain Support: Quality Management

IOS ref.


Source ref Notes

43 Test Plan Primary Quality Management artefact

OSLC http://open-services.net/bin/view/Main/QmSpecificationV2?sortcol=table;up= - Resource_TestPlan

44 Test Case Primary Quality Management artefact

OSLC http://open-services.net/bin/view/Main/QmSpecificationV2?sortcol=table;up= - Resource_TestCase

45 Test Script Primary Quality Management artefact

OSLC http://open-services.net/bin/view/Main/QmSpecificationV2?sortcol=table;up= - Resource_TestScript

46 Test Execution Record

Primary Quality Management artefact

OSLC http://open-services.net/bin/view/Main/QmSpecificationV2?sortcol=table;up= - Resource_TestExecutionRecord

47 Test result Primary Quality Management artefact

OSLC http://open-services.net/bin/view/Main/QmSpecificationV2?sortcol=table;up= - Resource_TestResult


Quality Management vocabulary

OSLC http://open-services.net/bin/view/Main/QmSpecificationV2


Quality Management specification

OSLC http://open-services.net/bin/view/Main/QmSpecificationV2

Relationship properties

50 Resource states

Quality Management Specification

OSLC Not provided in IOS V1.0 as not present in OSLC V2.0

See status under additional properties


OSLC http://open-services.net/bin/view/Main/QmSpecV2Issues

http://open-services.net/bin/view/Main/CmSpecificationV2?sortcol=table;up=#State_Predicates



http://open-services.net/wiki/change-management/Issues-2.0/

http://open-services.net/wiki/change-management/Issues-2.0/

http://open-services.net/bin/view/Main/QmSpecificationV2?sortcol=table;up=#Resource_TestPlan



http://open-services.net/bin/view/Main/QmSpecificationV2?sortcol=table;up=#Resource_TestCase



http://open-services.net/bin/view/Main/QmSpecificationV2?sortcol=table;up=#Resource_TestScript




http://open-services.net/bin/view/Main/QmSpecificationV2?sortcol=table;up=#Resource_TestExecutionRecord




http://open-services.net/bin/view/Main/QmSpecificationV2?sortcol=table;up=#Resource_TestResult




http://open-services.net/bin/view/Main/QmSpecificationV2






http://open-services.net/bin/view/Main/QmSpecV2Issues




V1.0 R 2015-04-30 42 of 230

5 Interoperability Specifications V2 – Proposals

5.1 Change and Configuration Management

5.1.1 Authors and Contributors

The authors and contributors for this chapter are people involved in the several SP ontology work packages:


David Honey IBM [email protected]

Andreas Mitschke Airbus Group [email protected]

Jean-Luc Johnson Airbus Group [email protected]

5.1.2 Context

5.1.2.1 Overview & Scope of the IOS Chapter

Configuration Management is a prevailing topic directly or indirectly affecting most activities along the systems and product lifecycle.

The aim is to provide selected Configuration Management interoperability capability that leverage the OASIS OSLC lifecycle integration Core Specification and enable interoperation of essential configuration management processes across the entire application and product lifecycle to improve transparency, traceability, and agility.

In line with the OASIS OSLC Technical Committee mission, configuration management addresses the management of configurations, configuration items, baselines, and change sets for information resources from any domain.

5.1.2.2 Link to External Material

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=oslc-ccm#overview

5.1.3 Supported Engineering Methods

As noted above configuration management is prevalent in most aspects of system engineering, therefore all partner use-cases and engineering methods have direct or indirect need for configuration management. To provide a realistic basis for IOS support, a generalised Engineering Method was distilled from analysis across a reasonably representative set of use-cases and Engineering Methods.

Maintain Configuration is proposed as a generalised Engineering Method covering the certain selected aspects of configuration management, namely:

Identify and select a configuration context

Create a new baseline from an existing configuration

Create a new branch or stream (working configuration) from an existing baseline

Report on configuration content, conflicts or problems

Introduce artefact into a configuration

Contribute configuration to global configuration

Archive configuration

In proposing these a number of terms have been defined. It should be noted that versioning is also available to support the above capability.

A full description of Maintain Configuration generalised engineering method is to be found on the AVL Crystal project site.

mailto:[email protected]





V1.0 R 2015-04-30 43 of 230

5.1.4 Specification

5.1.4.1 Introduction & Positioning

The Configuration Management specification defines capabilities that can be added to OSLC existing resources, for instance to add versioning to a Requirement or Test Case resource or to define new resources of type defined in this specification, such as a Linked Data Platform Container which contains a list of members of a configuration like a Requirements baseline or contributions to a aggregated configuration like a system baseline across a variety of artefact configuration contributions Requirements baselines, Model baselines, Test baselines etc..

A Linked Data Platform as proposed by W3C aims to clarify and standardise well known application integration patterns using Resource Description Framework (RDF), and a Linked Data Platform Container is proposed as the approach to enable standard http interaction methods for groups of resources, especially heterogeneous resources represented by (RDF). LDPC’s can be used for specific purposes like creating resources, finding out available resources, providing a common query result or report over resources or, and most interesting for system engineering, a managed or identified collection like a configuration.

https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-primer/ldp-primer.html

http://www.w3.org/TR/ldp-bp/

This presentation provides a summarised introduction

http://www.slideshare.net/alehors/www2014-linked-data-platform-20140410-33367843

5.1.4.2 Capabilities Supported by the Specification

Ref Term Capability Working definition origin Status

V Versioning

Create & maintain versions

Create and maintain an artefact version e.g. Latest

UC208, UC203 US205_Sign on SEE and create New Artefact

Included

V Versioning Associate artefact

Link to an available or configured version of an artefact

Included

V Query Query artefact relationships

See the current version of all related artefacts

UC208, UC203 US205_Search Data

Included

V Query Query artefact See the history of artefact versions

UC203 US205_Create Baseline Set Definition_EM205_01_01 Step 4, UC203 US205_List Change History

Implicit no specific service

V Versioning Branch artefact Create a branch from any version

UC208, UC203 US205_Branch_Baseline

Implicit no specific service

CfgM Configuration Configure workspace

Select the configuration context of a workspace

Not addressed

CfgM Configuration Configure Artefact

Select/de-select artefacts and relationships for a configuration e.g. baseline

UC203 US205_Create Baseline Set Definition_EM205_01_01 Step 4, UC203 US205_Create Baseline Set Definition

Included

CfgM Configuration Assemble Artefact

Present candidates to include or exclude in a configuration from criteria

UC203 US205_Create Baseline Set Definition_EM205_01_01 Step 7 & 8, UC203 US205_Create Baseline Set Definition

Included

CfgM Configuration Merge Resolve and merge UC203 US205_Merge Not


http://www.w3.org/TR/ldp-bp/

http://www.slideshare.net/alehors/www2014-linked-data-platform-20140410-33367843


V1.0 R 2015-04-30 44 of 230

configuration configurations based upon criteria

Baselines addressed

CfgM Query Query artefact

Compare configurations and available versions between artefacts UC208

Included

ChM Notify Notify artefact changes

Be notified about any change of the artefacts that are allocated to me

UC208, UC202 Change Impact Analysis & Maintain Consistency, UC203 US206_Analyse Trace

Via OSLC TRS

ChM Query Query change history

See versions by applied change request UC208

Not addressed

ChM Query Query artefact

See the status of artefacts and relationships following change

UC208, UC203 US206_Analyse Trace; UC203 US_206_Perform Coverage Analysis

Not addressed

5.1.4.3 IOS Data Models

5.1.4.3.1 Overview of the IOS Domain Resources


V1.0 R 2015-04-30 45 of 230

5.1.4.3.2 Detailed IOS Domain Resource Properties

The properties for each Resource type are defined at:

http://tools.oasis-open.org/version-control/browse/wsvn/oslc-ccm/trunk/specs/config-mgt.html

5.1.4.3.3 Open-issues

The major open issue is that the proposed OASIS OSLC Configuration Management is in Draft status. The propagation through to Accepted and Finalised can be assisted from clear feedback from Crystal partners on the feasibility and relevance to their use cases, engineering methods and bricks.

5.1.5 Integration Guidelines

Two main usages of the spec in relation to resource linking re envisaged:

1) Direct link to a versioned resource, this may be a basic or entry approach however over time we expect this approach will become less common due to the needs around maintenance.

E.g. a specific release or latest version of an artefact regardless of the configurations that it appears like a simulation model where multiple versions may evolve in parallel

2) Version resource resolved by global context, this is the more advanced capability which is expected to prevail due to the benefits of efficiency over re-use and governance

E.g. a version of an artefact that is released into and so selected by a configuration baseline.


V1.0 R 2015-04-30 46 of 230

5.2 Tracked Resource Set


Name: Tracked Resource Set V 2.0

Contact: Jean-Luc Johnson, Airbus Group Innovations UK

Email: [email protected]

Phone: +44 1633 71 4523

Dependencies IOS OSLC CORE Capabilities and OSLC Engineering Domains

Additional information

TRS domain is an OSLC Core domain.

5.2.2 Context


Today, embedded Systems are getting more and more complex. They require the collaboration of multiple engineering domains. Innovations in the 3 main transportation domains and Healthcare domain are delivered with software. This situation results in the generation of huge amounts of engineering data stored in various IOS persistence containers. The purpose of this chapter is to describe the mechanism for lifecycle resource providers to notify other tools involved in the same engineering process of any changes that occur on engineering model elements managed locally by these applications. The interoperability specification Tracked Resource Set is a protocol to help IOS applications to track all updates, additions to, and removals from lifecycle artefacts containers. This protocol is suitable for processes/tool chains dealing with large containers, as well as highly active IOS resource sets that undergo continual change. Like the IOS Core domain specification, this protocol is HTTP-based and follows RESTful principles.


OSLC CORE Tracked Resource Set V2.0 domain:

http://open-services.net/wiki/core/TrackedResourceSet-2.0/

Linked data platform:


https://dvcs.w3.org/hg/ldpwg/raw-file/default/TR/ldp-ucr.html


CRYSTAL work packages like the WP 2.08 - Public Aerospace Use Case, provides examples related to data interoperability. A large set of engineering methods defined by the CRYSTAL use case providers can be organised in 2 main groups: RTP related engineering methods and “Common Services” related. The TRS specification could widely contribute to the improvement of the second category of engineering methods. We can mention Traceability, Change impact analysis, support of collaborative working, versioning/archiving, configuration management, maintain consistency between multi-viewpoint models.




https://dvcs.w3.org/hg/ldpwg/raw-file/default/TR/ldp-ucr.html


V1.0 R 2015-04-30 47 of 230

Figure 16: Group of Engineering Methods for CRYSTAL WP2.08

5.2.4 Specification


This specification is an extension of the OSLC Core domain to provide an event notification system for large IOS server applications. The goal is to specify an IOS capability which allows real time integration between tools involved in the same engineering process.


The namespace used for the resources and properties defined in the Tracked Resource Set specification is:

http://open-services.net/ns/core/trs# . The default associated prefix is trs.

Term Capability Working Definition Origin

Trs:trackedResourceSet Retrieve, create operations

This resource is created by an OSLC service provider application while an OSLC consumer application can only pull a document representing this resource.

Trs:changeLog Retrieve, create operations


Trs:base Retrieve, create operations


http://open-services.net/ns/core/trs


V1.0 R 2015-04-30 48 of 230

5.2.4.3 IOS Data Models – Tracked Resource Set


The Tracked Resource Set specification can apply to most of lifecycle management domains. Therefore most of CRYSTAL domain use cases that make use of lifecycle domain have implicit need of resource set management. A Resource set provider maintains a Resource Set. The latter consists of a finite, enumerable set of engineering artefacts like requirements, architecture resources... Each Resource is identified by a URI. The Server will have its own criteria for determining the exact set of member Resources at any point in time. This method and associated criteria are tools specific. Therefore, clients need not be aware of the Server’s criteria, and will instead discover a Resource Set’s members by interacting with the Server using the Tracked Resource Set protocol.

The Server must provide an HTTP(S) URI corresponding to its Resource Set. This is referred to as the Tracked Resource Set URI.

A HTTP GET request sent to the Tracked Resource Set URI returns a representation of the state of the Resource Set characterized in terms of a Base and a Change Log: the Base provides a point-in-time enumeration of the members of the Resource Set, and the Change Log provides a time series of adjustments describing changes to members of the Resource Set. When the Base is empty, the Change Log describes a history of how the Resource Set has grown and evolved since its inception. When the Change Log is empty, the Base is a simple enumeration of the Resources in the Resource Set. This hybrid base + delta form gives the Server flexibility to structure the representation in ways that are most useful to its Clients.

The Base portion of a Tracked Resource Set representation is a Linked Data Platform (LDP) Container where each member references a Resource that was in the Resource Set at the time the Base was computed. The Change Log portion is represented as multiple same-subject and same-predicate triples, where the objects correspond to Change Events. The order information is indicated within the Change Event entry itself. There must not be a gap between the Base portion and the Change Log portion of a Tracked Resource Set representation; however, the Change Log portion may contain earlier Change Event entries that would be accounted for by the Base portion. A “cutoff” property of the Base identifies the point in the Change Log at which processing of Change Events can be cut off because older changes are already covered by the Base portion.

The term Linked Data Platform as proposed by W3C refers to an approach to publishing linked data, and uses the linking technologies provided by the Web to enable the weaving of a global distributed database. It aims at standardising well established integration patterns using semantic web format like RDF, and a Linked Data Platform Container is proposed as the approach to enable standard http interaction methods for heterogeneous resources.

The OSLC TRS domain specifies 3 concepts or resources that are:

trackedResourceSet

changeLog

base


V1.0 R 2015-04-30 49 of 230

Figure 17: Tracked Resource Set resources

An OSLC Client application should perform a HTTP GET command on the Tracked Resource Set URL. The server application returns a document that provides a reference to the Changelog and the Base. The picture below shows an example using RDF/XML format.

Figure 18: RDF/XML document of the TRS URI


V1.0 R 2015-04-30 50 of 230

A typical client will periodically poll the TRS looking for recent Change Events.

A change log provides a set of changes. The next picture illustrates the content of a change log document.

Figure 19: RDF/XML TRS Change log document

A Change Log provides a set of Change Event entries in a multi-valued RDF property called trs:change.

Change Events must have URIs to allow Clients to recognize entries they have seen before. The URI is only used to identify an event and therefore MAY be a URN, as shown in the example.

Each Change Event has a sequence number, trs:order; sequence numbers are non-negative integer values that increase over time. A Change Event entry carries the URI of the changed Resource, trs:changed, and an indication, via rdf:type of whether the Resource was added to the Resource Set, removed from the Resource Set, or changed state while a member of the Resource Set. The entry with the highest trs:order value (example 103 in this example) is the most recent change. As changes continue to occur, a Server MUST add new Change Events to the newest Change Log segment. The sequence number ( or trs:order) of newer entries must be greater than previous ones. The sequence numbers may be consecutive numbers but do not need to be.

The URI of a Change Event MUST be guaranteed unique, even in the wake of a Server rollback where sequence numbers get reused. A time stamp may be used to generate such a URI, as in the above example, although other ways of generating a unique URI are also possible.

A Change Log represents a series of changes to its corresponding Resource Set over some period of time. The Change Log must contain Change Events for every Resource creation, deletion, and modification during that period. A Server must report a Resource modification event if a GET on it would return a semantically different response from previously. For a resource with RDF content, a modification is anything that would affect the set of RDF triples in a significant way. A Server may safely report a modification event even in cases where there would be no significant difference in response. Some cases of modifications that would be considered semantically different from previous or significant difference would be: inserted triple, removed triple, triple replaced (new object/literal, for example changing Boolean literal “true” to “false”), replaced vocabulary term used (for example change from dcterms:title to rdfs:label).

A HTTP GET call on a Base URI returns an LDP Container with the following structure:


V1.0 R 2015-04-30 51 of 230

Figure 20: RDF/XML TRS Base document

Each Resource in the Resource Set must be referenced from the container using an LDP membership predicate. Because of the highly dynamic nature of the Resource Set, a Server may have difficulty enumerating the exact set of resources at a point in time. Because of that, the Base can be only an approximation of the Resource Set. A Base might omit mention of a Resource that ought to have been included or include a Resource that ought to have been omitted. For each erroneously reported Resource in the Base, the Server MUST at some point include a corrective Change Event in the Change Log more recent that the base cutoff event. The corrective Change Event corrects the picture for that Resource, allowing the Client to compute the correct set of member Resources. A corrective Change Event might not appear in the Change Log that was retrieved when the Client dereferenced the Tracked Resource Set URI. The Client might only see a corrective Change Event when it processes the Change Log resource obtained by dereferencing the Tracked Resource Set URI on later occasions.

A Server MUST refer to a given resource using the exact same URI in the Base (membership triple) and every Change Event (trs:changed reference) for that resource.

The response representation of a Base MUST include a trs:cutoffEvent property, whose value is the URI of the most recent Change Event in the corresponding Change Log that is already reflected in the Base. This corresponds to the latest point in the Change Log from which a Client can begin incremental monitoring/updating if it wants to remain synchronized with further changes to the Resource Set. When the trs:cutoffEvent is rdf:nil, the Base enumerates the (possibly empty) Resource Set at the beginning of time.


The OSLC community has developed a Java reference implementation for most of the OSLC domains. This software development kit is named Eclipse Lyo. It is an initiative to enable adoption of OSLC. It helps tools developers to extend their commercial applications or home grown tools with the support of OSLC capability. The Lyo project offers a reference implementation of the TRS V 2.0 specification and a sample code. The CRYSTAL Work Package 2.08, Public Aerospace Used Case (PAUC) has developed a prototype that makes use of the LYO TRS reference implementation for integrating their OSLC applications with IBM Jazz Rational Enterprise Lifecycle Manager. The following figures show the result of the TRS protocol implementation in IBM Rational Enterprise Lifecycle Manager (RELM). In this configuration, RELM is a consumer application to the PAUC OSLC adapter.


V1.0 R 2015-04-30 52 of 230

Figure 21: PAUC Modelica resource preview within IBM RELM

Figure 22: PAUC 3D geometry resource preview with IBM RELM

RELM uses the TRS protocol to build a local copy of all the references or links to the CRYSTAL server’s Resource Set. Therefore, any modifications that occur on the aerospace domain artefact are processed automatically by RELM. The tool relies on the linked data principles and the link type to navigate from a domain resource to another on the fly.


V1.0 R 2015-04-30 53 of 230

5.3 Ontology IOS


The authors and contributors for this chapter are people involved in the several SP ontology work packages:

Anne Monceaux Airbus Group [email protected]

Linda Oosterheert TNO [email protected]

Gianpaolo Massaroli Ansaldo STS [email protected]

Thomas Karbe TU Berlin [email protected]

Michael van Bekkum TNO [email protected]

Kerstin Hartig TU Berlin [email protected]

5.3.2 Context


All four industrial domains that are represented in CRYSTAL have a work package that concentrates on developing a domain-specific ontology for that industry domain. The purpose of these work packages is to provide an extension to IOS, by relating the Engineering Artefacts found in that domain to IOS Resources. However, these work packages together are also concerned with merging the input they get from the domain-specific use cases. When Engineering Artefacts may prove to be generic or relevant to multiple domains they search for consolidation of the artefacts across domains. This IOS chapter describes exactly these domain-agnostic artefacts, which are proposed as IOS Resources.

This common activity of the CRYSTAL ontology work packages is not focused on specific engineering activities of methods. It tries to cover all system engineering activities, at least those that are addressed in one or multiple use cases across the industry domains.


The most important input materials for this IOS chapter are the deliverables of the CRYSTAL ontology work packages. In particular the deliverables that define a first version of the domain-specific ontologies are relevant, as in these deliverables the engineering artefacts that are proposed as IOS Resources are identified. The deliverables are:

D209.021 (Aerospace): Ontology Definition – V1

D308.021 (Automotive): Ontology definition & assessment Report - V1

D407.021 (Healthcare): Ontology Definition – V1

D504.021 (Rail): Ontology Definition – V1


As mentioned earlier, this common activity of the CRYSTAL ontology work packages in not focused on specific engineering methods. The input that is gathered is based on all engineering methods across the project. Most of the engineering methods could thus be supported by the IOS Resources that are proposed in this IOS chapter. Depending on the nature of the engineering methods, one or multiple of the proposed IOS domains are relevant.

In the deliverables D209.021, D308.021, D407.021 and D504.021 a complete list of all the considered engineering methods can be found. The appendices in these deliverables with lists of engineering artefacts address which artefact origins in which engineering method.


V1.0 R 2015-04-30 54 of 230

5.3.4 Specification


This chapter concerns multiple IOS domains. For this second version of IOS the CRYSTAL ontology work packages choose to focus on the following domains:

Requirement management

Architecture Management

Quality Management

Estimation & Measurement

Safety Risk Management

Variability Management

Some of the proposed IOS domains are extensions of existing OSLC domains. Others are new domains. The following figure depicts the relationship of the six proposed IOS domains with the existing OSLC domains.

5.3.4.2 IOS Data Models – Requirements Management


The only resource that is proposed for the IOS Requirements Management domain by the ontology work packages is Requirement. This Requirement resource should be an extension of the existing OSLC resource Requirement.

The proposed IOS resource Requirement has additional properties in comparison with the OSLC resource Requirement. No additional relationships to other resources, either IOS resources or OSLC resources, are proposed. However, emphasis must be placed on the existing property validatedBy in the OSLC


V1.0 R 2015-04-30 55 of 230

Requirements Management domain. From the input of the ontology work packages an explicit relationship between a Requirement and a TestCase is desired. The range of this relationship is specified as Any. Therefore an IOS property is proposed that is a restriction on this OSLC property and of which the range is an OSLC TestCase resource.


Below a table can be found with all the proposed properties for the IOS resource Requirement.

Prefixed Name Description

Ios ontol rm:rationale Description of rationale to be added

Ios ontol rm:state

State of validation; the confirmation, through the provision of objective evidence, that the requirement for a specific intended use or application has been fulfilled (based on: ISO/IEC 15288:2008) (possible permitted values: verified/validated, not verified/validated)

Ios ontol rm:systemLevel Description of systemLevel to be added

Ios ontol rm:version Identified instance of a requirement (based on ISO/IEC 12207:2008)

Ios aero:annotation Further documentation accompanying a requirement such as background information and/or descriptive material (IEEE Std 1233-1998)

Ios aero:reviewState

State of requirements review; process or meeting during which the requirements for a system, hardware item, or software item are presented to project personnel, managers, users, customers, or other interested parties for comment or approval (ISO IEC IEEE 24765)

Ios aero:assumption

Factors that, for the requirement, are considered to be true, real, or certain without proof or demonstration (based on: A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition)

Ios aero:baseline

Specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures (ISO/IEC 12207:2008)

Ios auto:acceptanceCriteria

The criteria that a requirement must satisfy in order to be accepted by a user, customer, or other authorized entity (based on ISO 24765)

Ios auto:stakeholderComment

Information that provides clarification to human readers about the requirement but does not affect machine interpretation, provided by a stakeholder (based on ISO 24765)

https://www.eca-ios.org/mediawiki/index.php/Ios_ontol_rm:rationale

https://www.eca-ios.org/mediawiki/index.php/Ios_ontol_rm:state

https://www.eca-ios.org/mediawiki/index.php/Ios_ontol_rm:systemLevel

https://www.eca-ios.org/mediawiki/index.php/Ios_ontol_rm:version

https://www.eca-ios.org/mediawiki/index.php/Ios_aero:annotation

https://www.eca-ios.org/mediawiki/index.php/Ios_aero:reviewState

https://www.eca-ios.org/mediawiki/index.php/Ios_aero:assumption

https://www.eca-ios.org/mediawiki/index.php/Ios_aero:baseline

https://www.eca-ios.org/mediawiki/index.php/Ios_auto:acceptanceCriteria


https://www.eca-ios.org/mediawiki/index.php/Ios_auto:stakeholderComment



V1.0 R 2015-04-30 56 of 230


Ios auto:priority The level of importance assigned to a requirement (based on ISO 24765)

Ios auto:stakeholderID A unique identifier for an individual or organization having a right, share, claim, or interest in the requirement (based on ISO/IEC 12207:2008)

Ios ontol rm:validatedBy Restriction of oslc_rm:validatedBy property.

Prefixed Name Occurs Read-only

Value-type

Representation Range

Ios ontol rm:rationale

Zero-or-many

Unspecified XMLLiteral n/a N/a

Ios ontol rm:state Exactly-one Unspecified String n/a N/a

Ios ontol rm:systemLevel

Zero-or-many

Unspecified String n/a N/a

Ios ontol rm:version Zero-or-one Unspecified String n/a N/a

Ios aero:annotation

Zero-or-many


Ios aero:reviewState Zero-or-one Unspecified String n/a N/a

Ios aero:assumption

Zero-or-many


Ios aero:baseline

Zero-or-many

Unspecified XMLliteral n/a N/a

Ios auto:acceptanceCriteria

Zero-or-many


Ios auto:stakeholderComment

Zero-or-many


Ios auto:priority Zero-or-one Unspecified String n/a N/a

Ios auto:stakeholderID

Zero-or-many

Unspecified String n/a N/a

Ios ontol rm:validatedBy

Zero-or-many

False Resource Reference Oslc qm:TestCase


Some open issues exist for the current list of proposed properties:

- Some properties are not yet properly defined.

- The mapping of engineering artefacts and their properties to IOS resources and IOS properties must be checked with use case owners. The merge of inputs from all industry domains is now executed by the ontology work packages, but the correctness of this generalization is not checked in practice.

- Only properties that were self-explaining or that could be explained by one of the members of the ontology work packages are put on the list. Properties that were unclear are not included.

5.3.4.3 IOS Data Models – Architecture management

The resources that are proposed for the IOS Architecture Management domain below should be extensions of the existing OSLC am:Resource.

https://www.eca-ios.org/mediawiki/index.php/Ios_auto:priority

https://www.eca-ios.org/mediawiki/index.php/Ios_auto:stakeholderID

https://www.eca-ios.org/mediawiki/index.php/Ios_ontol_rm:validatedBy

https://www.eca-ios.org/mediawiki/index.php/Ios_ontol_rm:rationale

https://www.eca-ios.org/mediawiki/index.php?title=N/a&action=edit&redlink=1

https://www.eca-ios.org/mediawiki/index.php/Ios_ontol_rm:state


https://www.eca-ios.org/mediawiki/index.php/Ios_ontol_rm:systemLevel


https://www.eca-ios.org/mediawiki/index.php/Ios_ontol_rm:version


https://www.eca-ios.org/mediawiki/index.php/Ios_aero:annotation


https://www.eca-ios.org/mediawiki/index.php/Ios_aero:reviewState


https://www.eca-ios.org/mediawiki/index.php/Ios_aero:assumption


https://www.eca-ios.org/mediawiki/index.php/Ios_aero:baseline







https://www.eca-ios.org/mediawiki/index.php/Ios_auto:priority


https://www.eca-ios.org/mediawiki/index.php/Ios_auto:stakeholderID


https://www.eca-ios.org/mediawiki/index.php/Ios_ontol_rm:validatedBy

https://www.eca-ios.org/mediawiki/index.php/Oslc_qm:TestCase

https://www.eca-ios.org/mediawiki/index.php/Oslc_qm:TestCase


V1.0 R 2015-04-30 57 of 230


Both new Resources and relationships are proposed for extending Architecture Management domain. They are organized below following a similar pattern, within three sub domains respectively for functional, logical and physical architecture layers.

The diagram below presents the relationships between the four Resource Types defined within the IOS Functional architecture specification.

Some concepts are actually not mentioned as such in the current description of the engineering methods. Here “FAPort” and “FAExchange” resource types are proposed as the possible representation for a functional interface. It is possible that in most cases only the Resources Function and ExchangedItem are actually exchanged between engineering tools. But one can also imagine cases where information about such links and ports, i.e. interfaces, needs to be defined or analyzed through dedicated engineering methods.

The diagram below presents the relationships between the Resource Types defined within the IOS Logical architecture specification, including allocation and refinement relationships with functional architecture elements. Functional architecture elements are marked in blue color for readability.


V1.0 R 2015-04-30 58 of 230

At this stage we don’t propose additional relationships to OSLC or IOS interoperability domains other than existing relationships already owned by the parent am:resource (i.e. satisfies, refines, elaborates, verifies, relation).

The existing oslc am:refines relationship is reused here for relating architecture elements from the different layers.

We consider that it is not likely that relationships to other the new IOS Safety domain is represented within the architecture models’ data; it is more likely that this is done the opposite way and that the Safety domain resources refer to the architecture model elements. Exceptions can arise. For example in the Aerospace industry domain, some safety related information such as the DAL (Development Assurance Level) may be a property of some architecture model elements (most probably Components) and then can be used for integration purpose.

The diagram below presents the relationships between the Resource Types defined within the IOS Physical architecture specification, including allocation and refinement relationships with functional and logical architecture elements, marked in blue color for readability.


V1.0 R 2015-04-30 59 of 230


The detailed resource types and properties are given in appendix of this deliverable.


The proposed Resource Types are closer to architecture modeling concepts than most proposed engineering artefacts actually were. We refer to appendices of deliverables D209.021, D308.021, D407.021 and D504.021 for a complete list of all captured engineering artefacts and their originating methods). The mapping of engineering artefacts and their properties to the proposed IOS resources and properties must be checked with use case owners. The merge of inputs from all industry domains is now executed by the ontology work packages, but the correctness of this generalization is not checked in practice.

The mapping with the related Use Cases is thus incomplete.

Resources related to operation and mission description are not yet included or complete. The retained concepts are Use cases, Operational cases. They properties will be added later.

5.3.4.3.4 Integration Guidelines (optional subsection)

There should be a way to make the link between logical or physical architecture components with more industry domain specific taxonomies of systems. For example in the Aerospace domain, the ATA chapter taxonomy is commonly used to name the systems. Creating such a link is possible for example using some explicit property of Components (e.g. ios areo:hasATAnumber) or using constraints over the allowed value of dcterm: name.


V1.0 R 2015-04-30 60 of 230

5.3.4.4 IOS Data Models – Variability


The ontology work packages propose to introduce six new resources in the new Variability Management domain. With these resources classical feature trees can be modeled, which are the standard means to express variability.

The main resource is the FeatureModel, which contains all Features, and marks one Feature as the root of the feature tree. A Feature can have multiple children, and thus, the feature tree is constructed by adding children to the root Feature of the FeatureModel, and then adding children to its children.

A child Feature belongs to exactly one of four categories: It can be a

mandatory child: the child must be selected, when the parent is selected

optional child: the child can be selected, when the parent is selected

child in a “at least one”-selection

child in a “exactly one”-selection

Those four options are modeled by up to four FeatureGroups. A FeatureGroup has contains Features of which some must or can be selected when the parent Feature is selected. As an example, a feature that must be selected, when its parent is selected must be placed into the hasMandatoryChildren-FeatureGroup.

Features are usually connected to multiple other engineering artefacts, e.g. requirements, models, model components, or pieces of code. This is represented by the refersTo relation. If we want to express additional information about a link from a feature to some other resource, instead we can instantiate a FeatureLink. A FeatureLink connects a Feature with some resource and adds information, e.g. reasoning behind the link by the ios_ontol_vm:linkInformation property

Additionally, a feature model can contain global constraints, e.g. two features that need to be selected together, or that exclude each other. Those global constraints are represented by FeatureConstraints.

By selecting or actively deselecting Features of a FeatureModel, one derives a Variant of the FeatureModel. The Variant is represented by all selected and deselected Features. Further derived selections or deselections are not represented, since the information is redundant.


V1.0 R 2015-04-30 61 of 230

Figure 23: The resources FeatureModel, Feature, and Variant are extensions of Architecture Management Resource.

Figure 24: Relations with OSLC AM domain


The detailed resource types and properties are given in appendix of this deliverable.


V1.0 R 2015-04-30 62 of 230


So far, feature models were modeled for the variability domain, since they are the most used tool to express variability. However, there are other ways to represent variability. So far, we could not identify the need to express those other types of variability.

Furthermore, there are multiple properties that currently have been left out of the model, e.g. derived selected features of a variant, or the parent feature of another feature. The reasoning behind that decision is that we wanted to provide a minimal model. The left-out properties are properties that can be derived from already existing properties.

5.3.4.5 IOS Data Models – Quality Management


The IOS resources defined in the Quality Management domain by the ontology work packages are the following ones:

TestCase

TestScript

TestResult

Each of them should be an extension of the respective existing OSLC resource, as described here below:

Figure 25: relationships between the QM resource types defined within the IOS ontology specification and the existing OSLC ones

Among the above-mentioned proposed IOS resources, ‘TestCase’ and ‘TestScript’ have an additional property in comparison with the OSLC ones, named ‘Version’, which will contribute, together with ‘dcterms:identifier’ (present in the respective existing OSLC resources) to allow the univocal identification of the aggregated resource (we can think that more instances of the same Test Case or Test Script can be produced, hence their id, alone, is not sufficient to identify the resource itself).

Then, additional relationships to other resources, either IOS resources or OSLC resources, have been proposed. Their basic graphical representation is depicted here below:


V1.0 R 2015-04-30 63 of 230

Figure 26: domain and cross-domain relationships of QM resource types defined within the IOS ontology specification.


Below a table can be found with all the proposed properties for the IOS resources defined in the Quality Management domain by the ontology work packages:

TestCase (http://ios.crystal-artemis.eu/ns/ontology/qm#TestCase)


Ios ontol qm:version Identified instance of the Test Case

Ios ontol qm:associatedSystemModel System Model to which the Test Case is referred

Ios ontol qm:versionOfAssociatedSystemModel

Identified instance of the System Model to which the Test Case is referred


Value-type


Ios ontol qm:version Exactly-one

False String n/a N/a

Ios ontol qm:associatedSystemModel Exactly-one


Ios ontol qm:versionOfAssociatedSystemModel

Exactly-one


http://ios.crystal-artemis.eu/ns/ontology/qm#TestCase


V1.0 R 2015-04-30 64 of 230

TestScript (http://ios.crystal-artemis.eu/ns/ontology/qm#TestScript)


Ios ontol qm:version Identified instance of the Test Script

Ios ontol qm:associatedTestCase Test Case associated to the Test Script

Ios ontol qm:versionOfAssociatedTestCase Identified instance of the Test Case associated to the Test Script


Value-type


Ios ontol qm:version Exactly-one


Ios ontol qm:associatedTestCase Exactly-one


Ios ontol qm:versionOfAssociatedTestCase

Exactly-one


TestResult (http://ios.crystal-artemis.eu/ns/ontology/qm#TestResult)


Ios ontol qm:versionOfAssociatedTestScript Identified instance of the associated Test Script


Value-type


Ios ontol qm:versionOfAssociatedTestScript

Exactly-one



An issue that has to be addressed in the next version of the deliverable is represented by the fact that each Test Case should be linked to a behavioral model of the system through the relationships ‘associatedSystemModel’ and ‘versionOfAssociatedSystemModel’, but, at the moment, the resource ‘SystemModel’ is not defined yet and can be considered as a specification (to be formalized) of the OSLC Architecture Management ‘Resource’.

Moreover, another open issue depends on the fact that the current list of proposed properties has to be considered as partial, because several properties coming from the use case owner experience have not been well defined (and hence they have not been included in these lists), as well as the mapping of engineering artefacts and their properties to IOS resources and IOS properties realized by the use case owners has shown a lot of ambiguities, which have to be solved during the last year of the project (thanks to the cooperation among the ontology team and the use case owners themselves).

http://ios.crystal-artemis.eu/ns/ontology/qm#TestScript

http://ios.crystal-artemis.eu/ns/ontology/qm#TestResult


V1.0 R 2015-04-30 65 of 230

5.4 Knowledge Management


Name Affiliation Email

Jose María Alvarez-Rodríguez Carlos III University of Madrid

(UC3M)

[email protected]

Juan Llorens Carlos III University of Madrid

(UC3M)

[email protected]

Jose Fuentes The Reuse Company (TRC) [email protected]

5.4.2 Context


The creation and spreading of organization’s knowledge is a crucial activity in today’s knowledge

economy. Knowledge is becoming a commodity that is embedded in products, business or

manufacturing processes and it is also embedded in the tacit knowledge of employees. Thus,

knowledge is a kind of new intellectual asset that can be used to transform a simple organization in

a learning organization, creating a real collaborative environment, reducing costs and time to

market, generating competitive advantage and taking the most of existing tools and techniques to

improve the daily work activities. Knowledge as a kind of asset includes also some relevant

characteristics [1]:

Use of knowledge does not consume it.

Transfer of knowledge does not imply losing it.

Knowledge is abundant; the problem lies on the proper use and exploitation.

Much of an organization’s valuable knowledge walks out the door at the end of the day.

In this sense knowledge management, as a concept, has been widely studied, it was initially

defined in [2] as the process of applying a systematic approach to the capture, structuring, store,

management and dissemination of knowledge pieces throughout an organization to work faster,

reuse best practices and reduce costs. Building on the previous definitions, other valuable

definitions can be found in [3], [4], [5] ,[6] or [7]. Although it is hard to draw big differences among

the different approaches and definitions, it is possible to extract a common agreement on the

processes and on the needs to share data, information and knowledge within the organization, see

Figure 27: Common processes in Knowledge Management, adapted from [8].

In our opinion, based on the experience and on existing works, the next underlying necessities are

considered the cornerstone to successfully address the challenge of taking the most of the

knowledge generated in a business process:

Representation of every piece of knowledge under a common and shared data model.

Interoperability and integration between processes.

Other issues regarding provenance of information, graphical representation of every

knowledge item or common services that can be implemented on top of these knowledge

items, are other key points to address in a knowledge-based environment to develop a real

and holistic knowledge-based strategy.





V1.0 R 2015-04-30 66 of 230

ApplicationPeople

Management

Capture/Acquire Organize/Store

Access/Search/Disseminate

Use/Discover/Trace/Exploit

Create

Share/Learn

Figure 27: Common processes in Knowledge Management, adapted from [8]

In this sense, one of the cornerstones to provide the proper knowledge management services lies

on the selection of an adequate knowledge representation paradigm. After a long time [9], this

problem still persists since the choice of a suitable representation format (and syntax) can be

reached in several ways. Obviously, different types of knowledge require different types of

representation [10] [11] including a type of inference process and a target type of dynamic system.

In this light, expressions, rule-based systems, regular grammars, semantic networks, object-oriented

representations, frames, intelligent agents or case-based models to name a few are some of the main

approaches to information and knowledge modeling.

More specifically, knowledge management implies the standardization of data and information,

that is, any bit of information must be structured and stored for supporting other application

services, creating an impedance mismatch between the system and the outside world. In this sense,

semantic networks seem to be a very good candidate to represent any general knowledge item with

the aim of describing and linking different types of information using relationships. In particular,

two main approaches can be highlighted for the purpose of knowledge representation (input/output

interface and internal representation in the context of Systems Engineering):

The Resource Description Framework [12] (RDF) is a framework for representing

information resources in the Web using a directed graph data model. The core structure of

the abstract syntax is a set of triples, each consisting of a subject, a predicate and an object.

A set of such triples is called an RDF graph. AN RDF graph can be visualized as a node and

directed-arc diagram, in which each triple is represented as a node-arc-node link. Assume

there are a pairwise disjoint unlimited sets (IRIs- Internationalized Resource Identifier),

(Blank nodes) and (Literales). A triple is

called . In this triple, is the subject, the predicate and the object.

According to this definition an RDF triple encodes an RDF statement, a simple logical

expression and an RDF graph is the conjunction (logical AND) of its triples. An IRI within

an RDF is a UNICODE string to uniquely represent an information resource. A blank node

is a local resource identified by an IRI and a literal in an RDF graph consists of two main

elements: 1) a lexical form, being a UNICODE string, a data type IRI, being an IRI to

identifying a data type that determines how the lexical form maps to a literal value and if

and only if the data IRI is rdf:langString and 2) a non-empty language tag. RDF has been

used as underlying data model for building RDFS/OWL ontologies, gaining momentum in

the web-based environment due to the explosion of the Semantic Web and Linked Data

initiatives that aim to represent and exchange data (and knowledge) between agents and

services under the web-based protocols


V1.0 R 2015-04-30 67 of 230

The RSHP23 universal knowledge representation model [13] [14] is based on the ground idea

that whatever information can be described as a group of relationships between concepts.

Therefore, the leading element of an information unit is the relationship. For example,

Entity/Relationship data models are certainly represented as relationships between entity

types; software object models can also be represented as relationships among objects or

classes; in the process modeling area, processes can be represented as causal/sequential

relationships between sub-processes. Moreover, UML or SysML metamodels can also be

modeled as a set of relationships between metamodel elements. RSHP also includes a

repository model to store information and relationships with the aim of reusing all kind of

knowledge chunks. Furthermore, free text information can certainly be represented as

relationships between terms by means of the same structure. Indeed, to represent human

language text, a set of well-constructed sentences, including the subject+verb+predicate

(SVP) should be used. The SVP structure can be then considered as a relationship typed V

between the S and the predicated P. More specifically, the RSHP formal representation

model, see Figure 28 , is based on the following principles:

1. The main description element is the relationship since it is the element in charge of

linking knowledge elements.

2. A Knowledge Element (KE) is an atomic knowledge component that appears into an

artifact and that is linked by one or more relationships with other KEs to build

information. It is defined by a concept, and it can also be an artifact (an information

container found inside a wider artifact). A concept is represented by a normalized

term (a keyword coming from a controlled vocabulary, or domain). Artifacts are

knowledge containers of KEs and their relationships.

In RSHP, the simple representation model for describing the content of whatever artifact type

(requirements, risks, models, tests, maps, text docs or source code) should be: RSHP representation

for artifact α = = where every single RSHP is called RSHP-

description and must be described using KE. One important consequence of this representation

model is that there is no restriction to represent a particular type of knowledge. Furthermore, RHSP

has been widely used as underlying information model to build general-purpose indexing and

retrieval systems, domain representation models [14], quality assessment of requirements and

knowledge management tools such as knowledgeMANAGER [15] .

23 RSHP stands for RelationSHip, pronounced “arship”.


V1.0 R 2015-04-30 68 of 230

Artifact

KnowledgeElement

1

0..*

RSHP

10..*

MetaProperty

-tag

1

0..*

-value

0..1

Term TermTag

SemanticCluster

0..*

1

0..10..*

11

0..* 1

1..*

0..1

dynamicAction

staticConcept

1

0..*

Figure 28 The RSHP representation model using UML.

As a summary of both approaches, Table 4 shows the main characteristics and capabilities that

can be found in RDF and RSHP with special focus on those regarding knowledge management and

more specifically knowledge representation. Nevertheless the main difference lies on the

expressivity and the underlying data model, RDF is based on a directed graph and can only

represent binary relationships (unless reification and blank nodes are used) while RSHP is based on

an undirected graph and it can natively represent N-ary relationships. Other minor differences such

as target design and use, underlying semantics, query language and storage are also relevant but

somehow compatible. This situation leads us to assume that a combination of both approaches can

create the proper environment for knowledge management using RDF as input/output interface for

exchanging data and RSHP as internal data model to provide advanced services on knowledge

management. To do so, two main options should be designed and implemented:

1) Transform the RSHP metamodel into an RDF-based vocabulary or more specifically,

into an OSLC Resource Shape. For instance, OSLC has been designed to exchange data between

two agents in the same specification but cooperation of agents to support collaborative engineering

among different specifications is still open. Furthermore, the type of information that can be

exchanged through OSLC is restricted to a set of specifications to represent and serialize knowledge

as RDF. Thus, if there is no RDF vocabulary or OSLC Resource Shape to model a type of

information, RHSP can be used instead.

2) Create a set of mappings to represent any piece of RDF in RSHP (external to internal

representation). Thus, it is possible to import any kind of existing RDF data source into RSHP

(backward compatibility).


V1.0 R 2015-04-30 69 of 230

Table 4: A comparison between RDF and RSHP in the context of knowledge representation and exploitation.

Feature RDF [12] RSHP [13]

Designed for Representation of logical statements Representation of relationships

between knowledge items

Target use Data exchange of facts, rules and

ontologies

Universal knowledge representation

and re-use

Data model Directed graph Undirected graph

Underlying semantics RDF formal semantics Explicit metamodel

Expressivity Simple RDF triples to represent

binary relationships.

RDF is the data model in which RDFS,

OWL2 (DL, QL, EL, F-Logic) ontologies

can be serialized.

Any kind of relationship .

N-ary relationships.

No logic formalism.

Knowledge containers. (reification)

Validation RDF Data Shapes, OSLC Resource

Shapes, SHACL, SheX, SPIN and

SPARQL Rules

Metamodel conformity

Inference Not at graph level. Not at graph level.

Identifiers URIs (HTTP URIs if Linked Data).

Unique Name Assumption (UNA).

Internal IDs and UNA.

Access protocol HTTP-based (REST resources) Native API

Query language SPARQL, RDQL, etc. RSHP query language

Storage RDF repository (native RDF

repositories, graph-based databases, and

wrappers on top of existing relational

databases)

SQL or NoSQL database

Formats (syntax) RDF/XML, JSON, Turtle, N3,

Manchester

RDF/XML, ISO 25964-“The

international standard for thesauri and

interoperability with other

vocabularies”, etc.

Visualization RDF visualization libraries such as

Allegro graph or RDFgravity and other

general-purpose graph visualization

frameworks Graphviz, Touchgraph,

Gephi, Cytoscape, D3.js.

RSHP visualization language and the

aforementioned general-purpose graph

visualization frameworks.

Application Integration of databases, applications

and services through a common and

shared data model.

Semantic-based information retrieval

using a natural language interface to

support other services such as

traceability or quality.

Status W3C recommendation Industry-oriented

Tools Protégé, SWOOP, Terminae, etc.

(ontology editors)

knowledgeMANAGER (a complete

suite for knowledge management with

RDF import/export capabilities)


Notes: Material from CRYSTAL, from other external projects or partner-specific sources to be anchored to this

specification.


V1.0 R 2015-04-30 70 of 230

[1] D. Morey, M. T. Maybury, and B. M. Thuraisingham, Knowledge management: classic and

contemporary works. Cambridge, Mass.: MIT Press, 2002.

[2] I. Nonaka and H. Takeuchi, The knowledge-creating company: How Japanese companies

create the dynamics of innovation. New York: Oxford University Press, 1995.

[3] D. Grey, “Knowledge vs Information.” 1996.

[4] G. Dosi, R. Nelson, and S. Winter, The nature and dynamics of organizational capabilities.

Oxford University Press, 2000.

[5] T. H. Davenport and L. Prusak, Working knowledge: how organizations manage what they

know. Boston, Mass.: Harvard Business School Press, 2000.

[6] Open University, Managing knowledge: an essential reader, 2nd ed. Thousand Oaks, CA:

SAGE Publications, 2005.

[7] S. M, “Keynote address to ICICKM (International Conference on Intellectual Capital,

Knowledge Management and Organisational Learning,” 2008.

[8] S. McIntyre, M. Gauvin, and B. Waruszynski, “Knowledge management in the military

context,” Can. Mil. J., vol. 4, no. 1, pp. 35–40, 2003.

[9] R. Hull and R. King, “Semantic database modeling: Survey, applications, and research

issues,” ACM Comput. Surv. CSUR, vol. 19, no. 3, pp. 201–260, 1987.

[10] R. Davis, H. Shrobe, and P. Szolovits, “What is a knowledge representation?,” AI Mag., vol.

14, no. 1, p. 17, 1993.

[11] T. Groza, S. Handschuh, T. Clark, S. Buckingham Shum, and A. de Waard, “A short survey

of discourse representation models,” 2009.

[12] P. Hayes, “RDF Semantics,” World Wide Web Consortium, Feb. 2004.

[13] J. Llorens, J. Morato, and G. Genova, “RSHP: an information representation model based on

relationships,” in Soft Computing in Software Engineering, vol. 159, E. Damiani, M. Madravio, and

L. Jain, Eds. Springer Berlin Heidelberg, 2004, pp. 221–253.

[14] I. Dı́az, J. Llorens, G. Genova, and J. M. Fuentes, “Generating domain representations using

a relationship model,” Inf. Syst., vol. 30, no. 1, pp. 1–19, Mar. 2005.

[15] The Reuse Company Inc., “knowlegeMANAGER (KM),” knowledgeMANAGER, 2014. .

[16] K. E. Wiegers, Software Requirements, 2nd ed. Redmond, WA, USA: Microsoft Press,

2003.

[17] T. R. Gruber, “A Translation Approach to Portable Ontology Specifications,” Knowl Acquis,

vol. 5, no. 2, pp. 199–220, Jun. 1993.

[18] N. Guarino, “Formal Ontology, Conceptual Analysis and Knowledge Representation,” Int J

Hum-Comput Stud, vol. 43, no. 5–6, pp. 625–640, Dec. 1995.

[19] D. Beckett, “RDF/XML Syntax Specification (Revised),” W3C, W3C Recommendation,

2008.

[20] S. Powers, Practical RDF. Beijing ; Sebastopol: O’Reilly, 2003.

[21] N. Noy and A. Rector, “Defining N-ary Relations on the Semantic Web,” W3C Working

Group, 2006.

[22] V. Nguyen, O. Bodenreider, and A. Sheth, “Don’t like RDF reification?: making statements

about statements using singleton property,” 2014, pp. 759–770.

[23] A. Mallea, M. Arenas, A. Hogan, and A. Polleres, “On blank nodes,” in The Semantic Web–

ISWC 2011, Springer, 2011, pp. 421–437.

[24] M. Arenas, A. Bertails, E. Prud’hommeaux, and J. Sequeda, “A Direct Mapping of

Relational Data to RDF http://www.w3.org/TR/rdb-direct-mapping/,” 2012.


Although the purpose of this domain is to support the exchange and representation of any piece of

information, the motivation emerges for the necessity of re-using domain-based knowledge in the


V1.0 R 2015-04-30 71 of 230

context of Requirements Engineering. In this light, requirements engineering comprises a set of

incremental and iterative activities as follows (apart from management):

Figure 29 An iterative process of requirements sub-activities by [16].

In the context of Requirements Engineering, Validation and Verification are key concepts to

ensure a work product accomplishes with a requirements specification. Nevertheless, writing of

requirements is not a mere task of creating a text-based description that can be easily checked. It

can contain a good number of errors: inconsistencies, vocabulary and grammar errors and, in case

of using pattern-based requirements, pattern errors. To tackle this situation, domain-based

vocabularies or ontologies have been used to guide the writing of requirements. Some of the

classical definitions [17] [18] describe an ontology as a specification of a conceptualization; that is,

as a set of concepts (classes), attributes and relationships aiming to share and reuse knowledge. In

the context of requirements authoring, the use of an ontology can help to restrict the concepts that

can be used to describe a requirement from all lexical, syntax and semantic/category levels, see

Figure 30 In general, a knowledge base built as an ontology can be layered as follows:

Controlled Vocabulary

Domain Thesaurus

POS elementsInvalid POS elements

Patterns Layer

Formalization Layer

Inference Layer

Figure 30 Layers of an ontology-driven approach to guide requirements writing

Controlled vocabulary layer contains all those concepts with a specific meaning in a

domain.

o Part-of-Speech (POS) elements layer includes all those terms that are part of the

speech and are used to build domain-based terminology and concepts such as

prepositions, conjunctions, articles, etc.

o Invalid POS elements is the set of terms that should be avoided in textual

requirements to reach desirable quality characteristics

Domain thesaurus layer is comprised of those concepts and terms that have relevance in

a domain but including more sophisticated and particular relationships such as hierarchical

relationships (e.g. broader/narrower) or composition (e.g. part-of/whole-part).

Pattern layer defines the proper grammar to create pattern-based requirements. It makes use of the existing definitions (concepts) by exploiting relationships such as the lexical and semantic ones (e.g. synonymy or part-of).


V1.0 R 2015-04-30 72 of 230

Formalization layer is the layer in charge of managing semantic relationships and

exploiting the underlying knowledge [13] [19] that has been formalized through concepts

and relationships.

Inference layer represents the rules that can be used to infer new knowledge based on the

underlying data model (e.g. a semantic graph) and a certain type of logics. In some context

such as expert systems, this layer corresponds to the use of a semantic-based reasoner or a

rule-based engine.

There are many advantages of using formalized knowledge from ontologies in Systems Engineering processes:

In regards to requirements authoring:: a. Identify the concepts used to write a requirement.

b. Model and automatic process the structure (grammar) of requirements.

c. Formalize, as a semantic graph, the textual content of the requirement so that further

correctness, consistency and completeness analysis becomes easier.

In regards to continuous quality assessment of individual requirements : a. Knowledge for calculating correctness metrics (requirement level).

b. Knowledge for calculating consistency metrics (specification level).

c. Knowledge for calculating completeness (requirement and specification level).

Requirements traceability by exploiting the underlying semantics (concepts and relationships) used to describe requirements. In this case, the process is based on matching similar underlying graphs (since every piece of knowledge is modeled as a semantic graph).

As a major conclusion, sharing knowledge pieces during the different stages of the development

lifecycle can ease particular tasks based on reusing domain knowledge. In particular, the task of requirements writing can take advantage of exploiting ontology relationships and concepts to guide and aid in the proper writing of pattern-based requirements. Furthermore, this approach can be also applied to any other context in which text-based descriptions are used. That is why the purpose of this specification is to share the aforementioned layers of concepts (relationships) and patterns with special focus (but not restricted to) on requirements writing and quality (see section describing OSLC KPIs domain).

5.4.4 Specification


Recent times have seen the development of the Open Services for Lifecycle Collaboration

(OSLC) initiative to tackle some of the existing needs regarding interoperability and integration in

the Systems Engineering (SE) discipline. This emerging effort is seeking new methods to easily

integrate SE tools and build an ideal development and operations environment. At present time,

OSLC is comprised of several specifications to model shared resources between applications with

the aim of sharing more data, boosting the use of web-based standards (RDF and HTTP) and

delivering robust products through the collaboration of development and operational tools. OSLC

Core is now an OASIS standard, for products and services that support all phases of the software

and product lifecycle. Its main objective lies in the integration between work products that support

Application Life-cycle Management (ALM) and Product Life-cycle Management (PLM).

In the context of knowledge management, the Assets Management and Tracked Resource Set

specifications are the more convenient for these purposes. However, there is no RDF vocabulary to

represent information such as a simulation model, a set of executable business rules (in this case the


V1.0 R 2015-04-30 73 of 230

W3C Rule Interchange Format recommendation could be used), a model (there is an on-going effort

powered by the OMG to create an OSLC-MBSE specification (Model-Based Systems Engineering)

or a physical circuit. On the other hand, some common and useful services such as indexing,

naming, retrieval, quality assessment, visualization or traceability must be provided by all tool

vendors creating a tangled environment of query languages, interfaces, formats and protocols.

OSLC represents a big step towards the integration and interoperability between the agents

involved in the lifecycle development. However, RDF has been also demonstrated [20] to contain

some restrictions to represent certain knowledge characteristics such as n-ary relationships [21] and

practical issues when dealing with reification [22] and blank nodes [23] preventing the proper use

of a linked data environment. On the other hand, some common services such as indexing, retrieval

or quality assessment of any kind information are restricted to the internal storage and the query

capabilities offered by each particular tool (usually a SPARQL interface). Finally, there is also the

need of aligning the OSLC effort to existing standards such as STEP (ISO 10303-“Standard for the

Exchange of Product model data”). Although some initial insights can be found, this is an open

question that a common knowledge management specification can address enabling the

interoperability between different standards.

Taking into account some of the open issues such as the lack of RDF vocabularies to represent

any kind of information, the known problems of RDF as a knowledge representation model or the

lack of common native services such as indexing or retrieval lead us to fill these gaps through a

combination of RDF and an universal representation model see Table 4.

As an implementation of this approach and according to the capabilities presented in Table 5,

RSHP is selected as universal representation model. Thus, it is possible to address the challenge of

providing a common and standardized layer of knowledge management in the Systems Engineering

discipline by using RDF and OSLC-based services as an input/output interface and by taking

advantage of an industry-oriented approach such as RSHP and its existing set of services offered in

the knowledgeMANAGER tool [15].

As it has been previously outlined and in order to combine RDF and RSHP it is necessary to

provide a shape, an OSLC Resource Shape, that defines the entities and relationships in the RHSP

representation model to make this specification publicly available and enable the possibility of

expressing any piece of knowledge using RSHP. On the other hand and due to the fact that a huge

amount of data, services and endpoints based on RDF and the Linked Data principles are already

publicly available, a mapping between any RDF vocabulary and RSHP is completely necessary to

support backward compatibility and being able to import any piece of RDF data into RSHP.


V1.0 R 2015-04-30 74 of 230

Table 5: Alignment of knowledgement management processes to a combined approach OSLC/RDF/RSHP.

Process Support

Capture Access to OSLC repositories in the context of Systems

Engineering for all existing specifications and other RDF-based

services or SPARQL endpoints

Structure/Store RDF as public exchange data model and syntax and a universal

internal representation model to build the System Knowledge

Repository (SKR).

Access/Search/Disseminate RDF query language (e.g. SPARQL), natural language or a native

query language (if any). A set of entities and relationships creating

an underlying graph.

Traceability Entity reconciliation based on graph comparison.

Visualization A generic graph-based visualization framework that can show

entities and relationships but also interpret them as type of diagram.

E.g. Class diagram

Exploit Index, search, traceability or quality based on the internal

representation model.

Share An OSLC interface on top of the SKR that offers both data and

services.

Create Third-party tool that exports artifacts using an OSLC-based

interface.

5.4.4.1.1 Mapping between RDF and RSHP

The emerging use of RDF to tackle interoperability issues in different contexts has created a new

data-based environment in which data and information can be easily exchanged. On the other hand,

RSHP has been used for a long time in the Systems Engineering discipline for knowledge

management and, more specifically, for requirements engineering and quality.

Given this situation a strategy to map RDF-encoded data to RSHP abound must be defined

similar to the one presented in the mapping between relational databases and RDF [24]. To do so a

direct mapping is defined to perform simple transformations and to provide a basis for defining and

comparing more complex transformations. This mapping can also be used to materialize existing

RHSP graphs that can be encoded using RDF.

In order to design this direct mapping, both models are represented using the commonly defined

abstract data types set and list. This algebraic formalization of the core fragment of RDF to be

translated into RSHP, that is, RDF without RDFS vocabulary and literal rules allows us to make a

graph syntax transformation. The definitions follow a type-as-specification approach; thus models

are based on dependent types that can also include cardinality. More specifically, Table 6 shows

both specifications as a kind of regular tree grammars that can be used to specify a rule-based

transformation between two grammars (denotational semantics). Thus a transformation between

RDF and RHSP can be defined as a function, , that takes the RDF grammar, , a

valid RDF graph, , the RSHP grammar and a set of direct mapping rules,

(see Table 7 where sub-indexes refer to attributes and relationships of the elements), to

generate a valid .

Table 6: Regular Tree Grammars of RDF, and RSHP, .

(1) RDF Graph ::= Set(Triple)

(2) Triple ::= (Subject, Predicate, Object)

(1) Artifact ::= (Set(RHSP), MetaProperty{0,*})

(2) RSHP ::= (Subject, Verb, Predicate, Semantics)


V1.0 R 2015-04-30 75 of 230

(3) Subject ::= IRI | BlankNode

(4) Predicate ::= IRI

(5) Object ::= IRI | BlankNode | Literal

(6) BlankNode ::= RDF blank node

(7) Literal ::= PlainLiteral | TypedLiteral

(8) PlainLiteral ::= lexicalForm | (lexicalForm, languageTag)

(9) TypedLiteral ::=(lexicalForm, IRI)

(10) IRI ::= RDF URI-reference as subsequently

restricted by SPARQL

(11) lexicalForm ::= a Unicode String

(3) Subject ::= KE {0,1}

(4) Verb ::= KE {0,1}

(5) Object ::= KE {0,1}

(6) KE :: = (Term {0,1}) | Artifact

(7) Term ::= (lexicalForm, languageTag, TermTag)

(8) TermTag ::= lexicalForm

(9) MetaProperty ::= (Tag, Value)

(10) Tag ::= {KE, lexicalForm}

(11) Value ::= {KE {0,1}, lexicalForm {0,1}}

(12) SemanticCluster ::= (lexicalForm, languageTag, TermTag)

Table 7: Set of mapping rules, to transform RDF in RSHP.

1. RDF Graph ::= Artifact

2. Triple ::= RSHP

3. Subject ::= KE / KEId =IRI, KETERM=(lexicalForm=label(IRI),languageTag=”EN”,SyntaxTag= RSHP.POS_TAGGING.CATEGORY)

4. Predicate ::= KE / KEId =IRI, KETERM=(lexicalForm=label(IRI),languageTag=”EN”,SyntaxTag= RSHP.POS_TAGGING.CATEGORY)

5. Object ::=

5.1. KE / KEId =IRI, KETERM=(lexicalForm=label(IRI),languageTag=”EN”,

SyntaxTag= RSHP.POS_TAGGING.CATEGORY) /*When the object is a resource.*/

5.2. KE / KEId = auto_generate_id, KETERM=(lexicalForm= PlainLiteral. lexicalForm,languageTag=PlainLiteral.languageTag,SyntaxTag= RSHP.POS_TAGGING.CATEGORY) /*When the object is a

PlainLiteral.*/

5.3. KE / KEId = auto_generate_id, KETERM=(lexicalForm= TypedLiteral. lexicalForm,languageTag=

RSHP.POS_TAGGING.CATEGORY.LANG,SyntaxTag= TypedLiteral.IRI) /*When the object is a TypedLiteral.*/

6. BlankNode ::= KE / KEId =IRI, KETERM=(lexicalForm=label(IRI),languageTag=”EN”,SyntaxTag=RDF.BLANK_NODE)

7. Literal ::= PlainLiteral | TypedLiteral

8. PlainLiteral ::=

8.1. Term / TermlexicalForm = lexicalForm, TermlanguageTag = RSHP.POS_TAGGING.LANG, TermsyntaxTag =

RSHP.POS_TAGGING.CATEGORY |

8.2. Term / TermlexicalForm = lexicalForm, TermlanguageTag = languageTag, TermsyntaxTag = RSHP.POS_TAGGING.CATEGORY

9. TypedLiteral ::= Term / TermlexicalForm = lexicalForm, TermlanguageTag = RSHP.POS_TAGGING.LANG, TermsyntaxTag = IRI

10. LexicalForm ::= TermlexicalForm

11. IRI ::= lexicalForm=label(IRI)

Once a direct mapping between RDF and RSHP has been defined, the completeness and

correctness of the transformation can be demonstrated applying the theory of regular tree grammars.

Taking into account that a regular tree grammar is defined as where is the set of

non-terminal symbols, is the set of terminal symbols, is the set of production rules and the

initial symbol, both grammars, and , are regular tree grammars that accomplish with

the aforementioned definitions and there are automata that can validate and generate both

languages, in a finite time. With these conditions, a transformation from

RDF to RHSP will be complete if:

, that is, there is mapping

rule for every non-terminal and terminal symbol of that generates a valid word in the RSHP

language. Thus and considering the set of mapping rules in (see Table 7) the

transformation between RDF and RSHP is complete.

On the other hand, correctness refers to the fact that only valid RDF and RSHP models will be

accepted and generated. Building on the previous reasoning, the first step to perform a

transformation is the validation of RDF according to the grammar , once the set of mapping

rules is complete, it is worthy to state that every generated by applying the set mapping

rules is a word belonging to the language .

As major conclusion of this section, two options for knowledge representation and exchange has

been outlined:


V1.0 R 2015-04-30 76 of 230

1) Transform the RSHP metamodel into an RDF-based vocabulary or more specifically into

an OSLC Resource Shape. (See next section)

2) Create a set of mappings to represent any piece of RDF in RSHP (external to internal

representation). (See previous section)



Ios_km:Artifact Create, Retrieve, Update,

Delete (CRUD) operations

An artifact can be managed

through the OSLC API. UC203, UC204

Ios_km:MetaProperty Retrieve The list of metaproperties

of an artifact can be

retrieved.

UC203, UC204

Ios_km:RSHP Retrieve The list of RSHPs

describing an artifact can

be retrieved.

UC203, UC204

Ios_km:Concept Create, Retrieve, Update,

Delete (CRUD) operations

A concept can be managed


Ios_km:Concept List synonyms of a given

concept of text-based

description

It is possible to retrieve a

list of synonyms for a given

text or concept.

UC203, UC204

Ios_km:Concept List similar concepts of a

given concept of text-based

description

It is possible to retrieve a

list of similar concepts for a

given text or concept.

UC203, UC204

Ios_km:Concept Normalized a text-based

description

It is possible to elevate the

meaning of text-based

resource retrieving the

concepts that match such

text. From text to concepts.

UC203, UC204

Ios_km:Artifact

Ios_km:Concept

Semantic indexing of an

artifact or concept.

It is possible to

semantically index a new

artifact or concept.

UC203, UC204

Ios_km:Artifact

Ios_km:Concept

Search for an artifact or

concept.

It is possible to search for

an existing artifact or

concept.

UC203, UC204

Ios_km:Pattern CRUD operations A pattern can be managed


5.4.4.3 IOS Data Models – Knowledge Management

The RSHP representation model has been presented in Figure 31. In order to simplify the external

view of this model and ease the creation of an OSLC Resource Shape, two main changes, (see Table

5: Alignment of knowledgement management processes to a combined approach OSLC/RDF/RSHP. have

been made in the representation model:

1) The classes Artifact and KnowledgeElement have been merged. However, the model keeps all

the semantics since an artifact will be considered as a knowledge element (just a concept)

when it does not contain any relationship.

2) The tag and value of a metaproperty now point to a Term instead of a KnowledgeElement.

https://www.eca-ios.org/mediawiki/index.php/Ios_km:Artifact

https://www.eca-ios.org/mediawiki/index.php/UC203


https://www.eca-ios.org/mediawiki/index.php/Ios_km:MetaProperty



https://www.eca-ios.org/mediawiki/index.php/Ios_km:RSHP



https://www.eca-ios.org/mediawiki/index.php/Ios_km:Concept




















https://www.eca-ios.org/mediawiki/index.php/Ios_km:Pattern




V1.0 R 2015-04-30 77 of 230

Artifact

RSHP

10..*

MetaProperty

Term TermTag

SemanticCluster

0..* 1

0..*

1

0..1

11

0..* 1

dynamicAction

10..*

0..1

0..*

tag

value

0..1 0..*

Figure 31: The simplified RSHP representation model using UML.



V1.0 R 2015-04-30 78 of 230


V1.0 R 2015-04-30 79 of 230


V1.0 R 2015-04-30 80 of 230


V1.0 R 2015-04-30 81 of 230


It is important to highlight the strategy followed to model the resource shapes of the elements

presented in Figure 31. Taking into account that the Linked Data Initiative has seen last times the


V1.0 R 2015-04-30 82 of 230

creation of methodologies, guidelines or recipes to publish RDF-encoded data, we have paid special

attention to follow a similar approach reusing existing RDF-based vocabularies. More specifically,

the following rules have been applied to create the OSLC resource shapes:

If there is an RDF-based vocabulary that is already a W3C recommendation or it is being

promoted by other standards organization, it must be used as it is creating an OSLC

Resource Shape.

If there is an RDF-based vocabulary but it is just a de-facto standard, it should be used as

it is including minor changes creating an OSLC Resource Shape.

If there is not an RDF-based vocabulary, try to take advantage (reusing properties and

classes) of existing RDF-based vocabularies to create the OSLC Resource Shape.

In the particular case of knowledge management, we have selected the Simple Knowledge

Organization System (SKOS), a W3C recommendation, to define concepts, since it has been

designed for promoting controlled vocabularies, thesauri, taxonomies or event simple ontologies to

the Linked Data initiative. That is why, in our model, most of the entities can be considered as a

skos:Concept and we have created the shape of this standard definition of concept in the resource Ios_km:Concept.

Table 8: OSLC Resource Shapes description for Knowledge Management.

RSHP Class in Figure 31 OSLC Resource Shape Link Description

Artifact Ios_km:Artifact A container of: relationships between concepts,

metaproperties, etc. to semantically describe any piece of

information. It is the basis for the creation of an

underlying semantic network (not based on logic

formalisms).

Metaproperty Ios_km:MetaProperty A wrapper of a metaproperty containing a tag and value.

Both can be any type of resource or, more specifically,

concepts.

RSHP Ios_km:RSHP An RSHP is a wrapper to create a relationship between

any set of resources. It is possible to add a semantics and

can contain any number of elements representing binary,

ternary, etc. relationships.

Term Ios_km:Concept This concept follows the semantics and shape of an

skos:Concept. More specifically: "the notion of a SKOS

concept is useful when describing the conceptual or

intellectual structure of a knowledge organization system,

and when referring to specific ideas or meanings

established within a KOS (Knowledge Organization

System").

SemanticCluster Ios_km:Concept See previous description.

TermTag Ios_km:Concept See previous description.


As it has been outlined in previous sections, the main objective of this specification is to provide

a way for representing any piece of knowledge using the RSHP model. Since there are a lot of

techniques for knowledge representation, it is important to emphasize that the use of RSHP model is

motivated because: 1) it has been specially designed for information retrieval purposes and 2) it is

fully supported in the knowledgeMANAGER tool. However and with the aim of keeping backward

compatibility, a mapping to existing RDF data has been also presented and implemented. This

approach allows us to provide a mechanism for those that want to publish RDF data for which there



https://www.eca-ios.org/mediawiki/index.php/Ios_km:MetaProperty

https://www.eca-ios.org/mediawiki/index.php/Ios_km:RSHP





V1.0 R 2015-04-30 83 of 230

is no shape or vocabulary (RSHP could be sued) and to enable a way of re-using existing RDF data

sources. Nevertheless, the transformation of RDF to RSHP has been designed at a graph level so a

higher type of transformation (keeping logic formalisms if any) is under study. For instance, an

RDFS (RDF Schema) and OWL (Ontology Web Language), W3C standards for ontology

construction, mapping to RSHP are ongoing work.

On the other hand, this specification can be also seen as a broader effort, see, containing certain

parts of existing specifications such as Asset Management and Tracked Resource Set. In this case,

these specifications should be merged reusing the existing concepts and properties. Furthermore and

in order to support a full knowledge management strategy, the OSLC KM could be extended to:

Support a kind of formal reasoning or underlying logic formalism.

Include more provenance information. E.g. W3C Provenance Ontology.

Expose more services such as traceability of quality checking of any artifact.

Expose a general-purpose visualization service.

Figure 32 OSLC Knowledge Management and other OSLC specification.

5.4.4.4 IOS Data Models – Patterns Management

Although it is possible to share patterns and pattern groups using the OSLC Artifact Shape, we

have found out that for the sake of reusing knowledge a pattern constructor could be very useful.

Furthermore and taking into account the layered view of an ontology presented in Figure 33 It

seems necessary to share and exchange patterns as a high-level entity. That is why, a pattern and

pattern group resource shape have been defined.

A pattern group is a container of patterns, see Figure 33: Relationship between Pattern groups and Patterns.

That can also hold metadata such as authoring, versioning, etc. That is why both entities are also

modeled following the shape of an SKOS concept.

PatternPatternGroup

1 1..*

Figure 33: Relationship between Pattern groups and Patterns.


V1.0 R 2015-04-30 84 of 230



V1.0 R 2015-04-30 85 of 230


Table 9: OSLC Resource Shapes description for Patterns Management.

Resource OSLC Resource Shape Link Description

Pattern Ios_km:Pattern A resource to describe a kind of

grammar to guide the writing of any

piece text. More specifically, patterns

are used to implement pattern-based

requirements.

Pattern Group Ios_km:PatternGroup A collection of patterns.


5.4.5 Integration Guidelines (optional subsection)

In order to show the OSLC adapter on top of the knowledgeMANAGER, the next screencast

provides a walkthrough the different capabilities and resources that have been described in this

document.

See video at: https://dl.dropboxusercontent.com/u/329147/TRC/TRC-2015-March/TRC-2015-

March.mp4

https://www.eca-ios.org/mediawiki/index.php/Ios_km:Pattern

https://www.eca-ios.org/mediawiki/index.php/Ios_km:PatternGroup

https://dl.dropboxusercontent.com/u/329147/TRC/TRC-2015-March/TRC-2015-March.mp4

https://dl.dropboxusercontent.com/u/329147/TRC/TRC-2015-March/TRC-2015-March.mp4


V1.0 R 2015-04-30 86 of 230

5.5 The MBAT [MBAT, 2015] Interoperability Specification


Full Name

Omar KACIMI

Affiliation

OFFIS

e-mail omar.kacimi@offis.

de

Phone +49 441 9722-476

5.5.2 Context

5.5.2.1 Overview and Scope of the chapter

This chapter of the document presents a revised subset of the final version of the interoperability specification (IOS) [MBAT IOS, 2014] of the MBAT (Model-Based Analysis and Testing) [MBAT, 2015] project.

The purpose of the specification of MBAT is covering systems engineering activities related to V&V (Verification and Validation) processes. Hence, the specification consists on the one hand of 1. The compilation of concepts from different systems engineering standards addressing V&V related activities e.g. the UML Testing Profile [UTP, 2005] 2. In addition to extensions specifically dedicated to supporting the innovations of MBAT related to combining Static Analysis and Dynamic Testing. On the other hand, the specification takes care of giving a scope to these concepts in the sense of ensuring their traceability to systems engineering artifacts belonging to domains other than V&V.

During the elaboration of the IOS of MBAT, several engineering domains were considered such as version management and configuration management. However, after the last version of this specification was produced, specifications from the OSLC (Open Services for Lifecycle Collaboration) [OSLC] initiative started to emerge e.g. OSLC CM (Configuration Management) [OSLC-CM] and OSLC TRS (Tracked Resource Set) [OSLC-TRS] addressing the same engineering domains. The ideas motivated by MBAT for these domains were identified to be largely similar to the ones introduced by OSLC and hence, these parts of the MBAT interoperability specification were marked to be irrelevant for the IOS of Crystal and to be replaced by the findings of OSLC.

Finally, the contributions of MBAT identified to be of interest for the Crystal IOS cover the following engineering domains:

Requirements management


V&V Management

Traceability Management

Each one of these contributions was thoroughly revised before they were provided for the Crystal IOS. The changes include the removal of concepts that turned out to be at a granularity level which is too refined for the IOS and the refactoring of existing concepts in order to cover specific Crystal needs. During this revision process, the Formal Requirements Management (FRM) specification was significantly changed. The changes introduced allowed it to support more advanced scenarios from Crystal. Hence, the revised FRM specification will be presented a different IOS chapter (section 5.6) given that its scope exceeds the sole scope of MBAT towards a broader one covering the needs of some of the Crystal use-cases presented in the same chapter.




V1.0 R 2015-04-30 87 of 230

Furthermore, the Safety viewpoint of the architecture management specification was extensively revised by OFFIS and refined towards the support of a broader set of needs that go beyond the requirements of MBAT. Accordingly, the architecture management specification concepts related to safety will be placed in a different IOS chapter (section 5.7) putting in context the additional considerations taken in account during the revision of this specification and the new requirements additional to the ones imposed in MBAT it covers. The other parts of the architecture management module were only slightly refined and no major changes have been introduced and will be accordingly presented in this chapter. The revision process of the MBAT IOS is presented in the figure below.

Figure 34: MBAT IOS Revision process

The subset of the MBAT IOS presented here covers the following engineering domains:


o Excluding the safety viewpoint specification

V&V Management

Traceability Management

In order to represent the relationships between the resources, this chapter introduces two different

notations in addition to the ones offered by the graphics template provided for the IOS:

The first one denotes inheritance between resource types using a special kind of arrow. As an

example this relationship, Figure 49: Architecture Management – Structural Viewpoint –

Operational Perspective shows a possible refinement of the component resource type into the

resource type Actor which inherits the properties and the relationships of the component

resource type.


V1.0 R 2015-04-30 88 of 230

The second one denotes special relationship objects expressed in a different way than as

references between the related resources. These relationship objects will be shown in an orange

color in order to denote these objects. An example is shown in Figure 59.


[AUUDS, 2012] MBAT WP 1.4; “Automotive use cases & demonstrators specification”;

Deliverable D_WP1.4_1

[ALRL, 04] Algidirdas Avižiensis and Jean-Claude Laprie and Brian Randell and Carl

Landwehr, Basic Concepts and Taxonomy od Dependable and Secure

Computing, IEEE Transactions on dependable and secure computing, Vol. 1,

No. 1, January-March 2004

[ARP4754a] Aerospace Recommended Practice, ARP4754, SAE Aerospace, Revision A,

December 2010

[BGP, 2010] Böde, E., Gebhardt, S. and Peikenkamp, T., “Contract based assessment of safety critical systems”, In Proceeding of the 7th European Systems Engineering Conference (EuSEC 2010), Stockholm, Sweden, 2010.

[BPMN, 2015] BPMN; Business Process Modeling Language (BPMN); Version 2.0; January

2011; http://www.bpmn.org/

[CESAR, 2012] CESAR Project, Cost-efficient methods and processes for safety relevant

embedded systems, http://www.cesarproject.eu/

[CMM, 2011] CESAR WP 1.3; “Meta-Model Specification for RTP 2.0”; Deliverable

D_SP1_R.3.2_A_M2, annex of deliverable D_SP1_R3.2_M2 “Specification for

RTP V2”

[EADL, 2010] Advancing Traffic Efficiency and Safety through Software Technology phase 2

(ATESST2); EAST-ADL Domain Model Specification; Version 2.1; Deliverable

D4.1.1; 2010-06-30; http://www.east-adl.info/repository/EAST-ADL2.1/EAST-

ADL-Specification_2010-06-30.pdf

[HRC, 2009] Speculative and Exploratory Design in Systems Engineering (SPEEDS); SPEEDS

L-1 Meta-Model; Deliverable D2.1.5; Revision 1.0.1; 2009-05-15;

http://speeds.eu.com/downloads/SPEEDS_Meta-Model.pdf

[IEC61508] IEC 61508, Functional Safety of Electrical/Electronic/Programmable Electronic

Safety-related Systems

[IEEE 1471, 2000] IEEE Std 1471, Architectural Description of Software-Intensive Systems, IEEE-

SA Standards Board, September 2000.

[ISO26262] Road Vehicles – Automotive Safety, ISO26262, 2011

[MBAT, 2015] MBAT Project, Combined Model-based Analysis and Testing of Embedded

Systems , http://mbat-artemis.eu/home/

[MBAT_AT, 2014] MBAT Methodology and A&T Patterns, http://mbat-

wiki.iese.fraunhofer.de/index.php?title=Main_Page

[MBAT MM, 2014] MBAT D_WP3.1_3; “Meta-Model for RTP 2.0”

[MBAT IOS, 2014] MBAT D_WP3.2_3; “Specification for RTP interoperability v 2.0”

[MBAT FPP, 2010] MBAT Full Project Proposal; 1st September 2010

[MODELSWARD, 2014] Creating a reference technology platform: Performing model-based safety

analysis in a heterogeneous development environment. In MODELSWARDS

2014, second International Conference on model-driven engineering and

http://www.bpmn.org/

http://www.cesarproject.eu/

http://www.east-adl.info/repository/EAST-ADL2.1/EAST-ADL-Specification_2010-06-30.pdf

http://www.east-adl.info/repository/EAST-ADL2.1/EAST-ADL-Specification_2010-06-30.pdf



V1.0 R 2015-04-30 89 of 230

software development

[OSLC] OSLC Community; Open Services for Lifecycle Collaboration; http://open-

services.net/

[OSLC-AM] OSLC Community; “Open Services for Lifecycle Collaboration Architecture

Management Specification”; Version 2.0;

http://open-services.net/bin/view/Main/AmSpecV2

[OSLC-Core] OSLC Community; “Open Services for Lifecycle Collaboration Core

Specification”; Version 2.0; http://open-

services.net/bin/view/Main/OslcCoreSpecification

[OSLC-QM] OSLC Community; “Open Services for Lifecycle Collaboration

Quality Management Specification”; Version 2.0;


[OSLC-RM] OSLC Community; “Open Services for Lifecycle Collaboration

Requirements Management Specification”; Version 2.0;


[OSLC-CM] OSLC Community; “Open Services for Lifecycle Collaboration

Configuration Management Specification”; Version 2.0;

http://open-services.net/wiki/configuration-management/

[OSLC-TRS] OSLC Community; “Open Services for Lifecycle Collaboration

Tracked Resource Set Specification”; Version 2.0;


[OTAM, 2013] MBAT WP2.1; “Overall T&A Methodology”; Deliverable D_WP2.1_2_1; March

2013

[RSL, 2011] CESAR WP 2.2; “RE Language Definitions to formalize multi-criteria

requirements V2”; Deliverable D_SP2_R2.2_M2

[SPEEDS, 2008] SPEEDS Project, Speculative and Exploratory Design in Systems Engineering,

http://www.speeds.eu.com/

[SPES-AM] Software Platform Embedded System 2020, SPES2020 Architecture Modelling,

SPES2020 project deliverable, OFFIS, Version 1.2, February 2011

[SysML, 2012] OMG; OMG Systems Modeling Language (OMG SysML™); Version 1.3;

http://www.omg.org/spec/SysML/1.3/PDF/

[TTCN-3, 2012] ETSI CTI (Centre for Testing & Interoperability), “Methods for Testing and

Specification (MTS); The Testing and Test Control Notation version 3; Part 1:

TTCN-3 Core Language”, ETSI ES 201 873-1, V4.4.1, April 2012,

http://www.ttcn-3.org/

[UML, 2011] OMG; Unified Modeling Language (UML); Version 2.4.1; August 2011;

http://www.omg.org/spec/UML/

[UTP, 2005] Object Management Group; UML Testing Profile; July 2005

[VIT, 2011] Damm, Werner and Hungar, Hardi and Josko, Bernhard and Peikenkamp, Thomas and Stierand, Ingo “Using Contract-based Component Specifications for Virtual Integration Testing and Architecture Design”




http://open-services.net/bin/view/Main/AmSpecV2





http://open-services.net/wiki/configuration-management/


http://www.speeds.eu.com/

http://www.omg.org/spec/SysML/1.3/PDF/

http://www.ttcn-3.org/

http://www.omg.org/spec/UML/


V1.0 R 2015-04-30 90 of 230

5.5.3.1 Change Impact Analysis Scenario

This section describes how the MBAT Meta-Model [MBAT MM, 2014] is applied to the change impact analysis scenario applied in the context of an anonymized MBAT automotive use case [AUUDS, 2012]. During the change impact analysis a guided and VV-oriented change management on all system artefacts is performed. Rationale of this change management is as follows: When a model element is modified an analysis is made in order to see what other model elements are affected. Consequently modification and re-verification can be required. This analysis is important during the verification and testing to maintain the coherence of the design model and implementation.

During the change impact analysis several activities are performed which are: capturing and formalization of requirements, establishing traceability between model elements, entailment analysis and modification of model elements. Following concepts are required for change impact analysis: Requirement (informal / formal) (section 5.6) , Implementation Link, Refine Link, Satisfy Link (section 5.5.4.5), Component, Prototype, Behavior (section 5.5.4.3), VV Objective, VV Suite, VV Case, VV Log (section 5.5.4.4).

In the beginning of the change impact scenario informal requirements are assessed using natural language. These requirements are refined into requirements with a specification-formalism like the RSL (Requirements Specification Language) [RSL, 2011]. Refine links between the formal requirements and the informal requirements indicate the formalization for traceability of the requirements. A component model defines the intended architecture. The formalized requirements are allocated to the respective components using satisfy links. A VV suite is created with a set of VV Cases for the intended system architecture. The objectives for the VV Cases are defined by VV Objectives, which reference the respective, satisfy links assigning requirements to the components of the system architecture. The VV Cases are executed and the results are stored in VV Logs.

Figure 35 depicts model elements involved during the change impact analysis scenario and the steps being performed. The user modifies component properties such as the implemented behavior. The modification is applied by storing the changed elements. This step leads to a new revision of these elements. V&V cases linked to the requirements that shall be satisfied by the changed components are marked as suspect. A re-run of suspect VV cases is performed. If the execution of a VV case fails because of the change then compensation is performed by modifying intended characteristics specified in the requirements. Again, the respective VV case is executed. If it succeeds the change is considered consistent. Otherwise the VV Case remains suspect. A further modification of model elements is performed and the change impact analysis is executed again. Note that in the depicted example, the Requirement belongs to the elements that shall be changed for compensation: Usually, the implemented Behavior would have to be corrected until the VV Case succeeds again.


V1.0 R 2015-04-30 91 of 230

Figure 35: Change Impact Analysis – Overview

5.5.3.2 MBAT AT pattern based scenario

The following demonstrates how the interoperability needs of one of the AT patterns of MBAT are covered by the IOS of MBAT presented in the sections that will follow. The data elements exchanged between the tools realizing the pattern are identified and each element is mapped to an IOS representative. First, the pattern and the ideas behind are presented. Afterwards, the steps of the pattern will be unrolled along the data elements generated at each step. For each step of the pattern, IOS representatives of the data elements will be identified along explanations regarding how these representatives cover the semantics of the data elements.

5.5.3.2.1 Presentation of the AT pattern


V1.0 R 2015-04-30 92 of 230

Figure 36: AT pattern: reduce warnings from Static Code Analysis

One of the analysis methods proposed for systems verification is static code analysis. Along confirmed defects, static code analysis produces warnings that might require additional checking efforts. The pattern proposes to exploit the warnings to produce automatically a new verification activity. This verification activity can be done using a different technique. Ideally, the execution of this newly created activity either confirms the warning or discards it.

5.5.3.2.2 Steps of the pattern

5.5.3.2.2.1 Step 1: preparing and running the static code analysis

As explained in the presentation of the pattern, the purpose is the support of the usage of static code analyzers. The first step of the pattern is getting the data for the static code analysis and running it. The pattern indicates that the preconditions for executing this step are the code to be analyzed and a configuration. The execution of this first step results in the generation of a report. This report summarizes the defects uncovered by the analysis and the warnings that require further checking. The following table summarizes the pre-conditions and the post-conditions of this step.

Pre-Conditions Code, Configuration

Purposes of this step

Identify defects and potential defects (warnings) using static code analysis.

Post-conditions Report, defects, warnings

Table 10: summary of step 1 of the AT pattern

In order to identify IOS resource types suitable for representing the data resource, a positioning in the product lifecycle needs to be made. In this case, a verification activity is performed with the goal of validating an implementation model in respect to some properties. This verification activity needs to be made in the context of a general verification plan. Furthermore, this activity needs to be traced to the properties and the elements it aims to verify.


V1.0 R 2015-04-30 93 of 230

Once this verification activity is executed, several outcomes such as defects and warnings are generated. According to some criteria, these outcomes are assessed and a verdict can be made. Additionally, every execution of this verification activity along the generated artifacts needs to be traceable.

This picture in mind, the semantics of the IOS representatives come naturally as the description of what is needed to accomplish the described scenario. The verification plan is represented by the concept of VV Suite in the meta-model. A single verification effort is represented by the VV Case concept. The concept of VV Outcome denotes any finding generated, like the defects or warnings in the case of static code analysis. To keep track of each execution of the VV Case the meta-model defines the VV Log concept. VV Logs track the verdict that is made per each verification task run and the outcomes leading to making this verdict.

Since the semantics of the configuration are not clearly specified by the pattern. We specified two options to represent it by an IOS resource type. The following figure presents the IOS resources exposed at the interoperability level and the engineering models they are encompassing.

Figure 37: IOS resources used for the first step of the pattern

Once the analysis is executed, several outcomes are generated. First are the defects which need to be corrected. Second, warnings that need further investigation. At last, a report that denotes a summary of all these outcomes. The following figure represents the generated outcomes in this case.

Figure 38: IOS resources after the execution of the analysis


V1.0 R 2015-04-30 94 of 230

5.5.3.2.2.2 Step 2: preparing the second analysis

After the execution of the code analysis, several warnings are generated. The next step of the pattern consists on the execution of another iteration to check automatically these warnings. First, the second process of the combination pattern uses the warnings and additional output of the static code analyzed to generate a property and a model. Checking this property against the generated model will eventually allow either validating or discrediting the warning. IOS representatives for this step of the pattern are out of the scope of this specification. Accordingly, we will place ourselves at the entry of the third process of the pattern. Again, from a lifecycle point of view this consists on creating an additional verification task that will support and extend the initial verification plan. Furthermore, this verification task needs to be linked to the overall verification plan. To realize this, several VV Cases are created. Each VV case has the purpose of checking one of the generated properties against one of the models. Furthermore, The VV Outcomes representing the warnings of the static code analysis are linked as objectives of the VV Suite. In order to keep the traceability to the generated models, we proposed a refinement relation between each one of them and the resource representing the code. The following table represents the precondition of this step and its results.

Pre-Conditions Semantic preserving model, Formal requirement, formalized VV Activity

Purposes of this step

Confirm warnings using alternative analysis method

Post-conditions defects, warnings

Table 11: summary of step 2 of the AT pattern

The following figure represents the IOS resources and their encompassing of the engineering models.

Figure 39: IOS resources before the model analysis

5.5.4 Specification


5.5.4.1.1 Architecture Management Contribution

The architecture management specification addresses the description of the system under development and its environment under different viewpoints, which are structural, behaviour, safety.

This specification is the result of a consolidation work done on the MBAT meta-model in order to converge towards an IOS specification which is as minimal as possible. A As such, this specification is a consolidation of the architecture management module of the MBAT meta-model.


V1.0 R 2015-04-30 95 of 230

The OSLC Architecture Management Specification [OSLC-AM] does not define any domain specific information (i.e. UML [UML, 2011], BPMN [BPMN, 2015]). In order to share a more precise and common vocabulary within the MBAT project, the IOS Architecture Management Specification of MBAT hence extends the OSLC AM Specification with the MBAT Meta-models concepts. While section 5.5.4.3.1 presents these concepts, the section which follows presents the OSLC representation of these concepts.

5.5.4.1.2 Verification and Validation Management Contribution

V&V Management addresses concepts, which are needed for verification and validation activities. This specification has been developed with a focus on the MBAT goal of combining artefacts from the analysis and testing domain. It also allows tracing of requirements and components respectively from requirements management (section 5.6) and architecture management (section 5.5.4.3).

The concepts are defined based on concepts of the UML testing profile and based on concepts of the meta-model developed in CESAR [CMM, 2011]. The concepts of the UML testing profile are purely intended for testing. In CESAR verification and validation (V&V) activities are addressed. The related concepts and their relationships have been adapted for the MBAT RTP to allow combined methods for analysis and testing. The concepts of the analysis and testing meta-model and their relationships are depicted in Figure 51.

As section 5.5.4.4.1 presents the concepts covered by the V&V contribution, section 5.5.4.4.2 presents the proposed representations in terms of OSLC resource shapes and how they extend the concepts from the OSLC QM (Quality Management) domain [OSLC-QM].

5.5.4.1.3 Traceability Management Contribution

Traceability is one of the most important features to be supported by an Interoperability Specification since it defines the cornerstone principles that have to be applied for linking different types of artifacts manipulated throughout the engineering phases of the product design lifecycle (e.g., requirement, design, implementation and testing/analysis artifacts).

Hence, The Traceability Management specification defines concepts for traces between artifacts from different engineering activities such as Requirements Management, Architecture Management and V&V Management. The traceability concepts presented here are based on the meta-model developed in the CESAR project and carried on to the MBAT Project.

For different reasons, one of the design decisions made for the IOS in MBAT is the modelling of the traceability management concepts as own objects instead of relying on the principles of linked data to model relationships. Shortly after the last version of this specification was produced, specifications from the OSLC initiative started to emerge e.g. OSLC CM (Configuration Management) [OSLC-CM] and OSLC TRS (Tracked Resource Set) [OSLC-TRS]. These specifications address requirements very similar to the ones motivating the design decisions of MBAT in regards to traceability management.

Since the Interoperability Specification is based in its totality on the ideas of the OSLC standard and linked data principles, it is planned to look during the next iteration of this deliverable into the alignment of the ideas of the MBAT traceability management module with the new findings of the OSLC community.

While Section 5.5.4.5.1 of the traceability management section presents traceability concepts and the ideas behind them, the section that follows it presents the suggested representation of these concepts in the term of OSLC resource shapes.


V1.0 R 2015-04-30 96 of 230


5.5.4.2.1 Architecture Management Contribution


Query Create system architecture artefacts

Create artefacts representing a system architecture e.g. port, component

-

Query Retrieve system architecture artefacts

Query and maintain artefacts representing a system architecture e.g. port, component

-

5.5.4.2.2 Verification and Validation Management Contribution


Query Create Verification and Validation artefacts

Create system verification and validation, artefacts e.g. Verification and Validation case, plan

-

Query Query existing Verification and Validation artefacts

Query and maintain artefacts for verification and validation activities e.g. Verification and Validation case, plan

-

5.5.4.2.3 Traceability Management Contribution


Query Create complex relationship artefacts

Create complex relations between artefacts e.g. between Test Model and Requirement

-

Query Retrieve complex relationship artefacts

Query and maintain relations between artefacts e.g. between Test Model and Requirement

-

Query Retrieve complex relationship artefacts that need to be verified

Retrieve all relationships between system architecture artefacts and their verification status

-

5.5.4.3 IOS Data Models - Architecture Management Domain

5.5.4.3.1 Overview of the IOS Resource Types and their Relationships

5.5.4.3.1.1 Structural Viewpoint

The structural viewpoint for the architecture management module is using a component-based design

approach. The concepts originate from established concepts of as well as from the SPEEDS project and

from the CESAR project. They are used on system, subsystem / component, and implementation level,

which are design levels regarded in MBAT (section 5.5.4.3.1.1.5 ). Typically, a system description is


V1.0 R 2015-04-30 97 of 230

captured by an implicit top-level component. The figure below depicts the basic entities and their

relationships.

Figure 40: Architecture Management – Structural Viewpoint – Overview

5.5.4.3.1.1.1 Resource Component (structural viewpoint)

Component is a concept, which denotes a reusable structured type of a design entity. Components can be decomposed into a structure of parts, whose interfaces are defined by its ports. They can define a set of connectors as interconnections for the composition of sub-components at their ports. A component shall satisfy a set of requirements as depicted in the figure below

Figure 41: Architecture Management – Structural Viewpoint – Component

A component describes a type of structural units that share the same characterization of features, constraints and dynamics. Components specify design entities that can be structured into parts and uses ports to interact with their environment. A component can typically be reused several times, which means that a component with the same interfaces and properties is used in another context. Structuring components into parts allows hierarchical composition. Parts of a component can be defined by using prototypes. Parts of a component are interconnected at their ports. Components can be subjects to different abstraction levels and perspectives of a development process depending on the respective view on the component. As described in section 5.6 the specification of a component can be defined by requirements,


V1.0 R 2015-04-30 98 of 230

which can be given the form of contracts. These contracts describe promised functional and non-functional characteristics (e.g. nominal behavior, safety or timing) for an assumed usage context of the component. Components can appear in the role of design models and in the role of a design exploration models usable for analysis or test activities as described below.

5.5.4.3.1.1.1.1 Decomposition of components (parts)

A component can be decomposed into a hierarchical structure of smaller parts or sub-components. The sub-components are prototypes typed by components and appear as parts of the decomposed context component. This principle is common for different structural viewpoints such as functional, logical, technical or geometrical. For example functions are decomposed into sub-functions, logical components are decomposed into logical sub-components, hardware components are decomposed into hardware-parts and geometrical installation spaces are decomposed into installation locations. When decomposing components typically a structure of interconnected sub-components is defined. This principle is called composition and is explained in section 5.5.4.3.1.1.4.1.The interconnection of sub-components, each implementing a specific behavior, results in the overall behavior of the composed component. Along with the decomposition of a component into a structure of sub-components requirements are assigned to the sub-components. In a very clean component-design even the requirement specifications of the sub-components should entail or dominate the requirement specifications of assigned to the composed component taking the composition structure into account. A virtual integration test (VIT) [VIT, 2011] allows determining, whether entailment or dominance is given for the composition structure of a component.

5.5.4.3.1.1.1.2 Interfaces of components (ports)

A component’s interfaces are defined by its ports. Such ports provide or require directed interaction points with the environment of a component. At these interaction points characteristics of a component’s implemented behavior are observable and / or manipulable. Ports can be addressed from related component specifications such as property specifications and requirements that shall be satisfied by the component. Knowing only the ports and the specification of a component provides a black-box view on it.

5.5.4.3.1.1.1.3 Satisfaction of Requirements

Requirements can be assigned to a component by using a satisfy-link, which means that the requirement shall be satisfied by the component. Intended behavior characteristics specified by a requirement shall be met by the behavior that is implemented by the component. Promised characteristics of contract-based requirement specification as described in [HRC, 2009] have to be satisfied if the characteristics assumed for the component’s environment are fulfilled. Satisfaction of requirements has to be verified by applying analysis or testing methods that show whether a component meets a requirement.

5.5.4.3.1.1.1.4 Properties of components

In addition to parts, ports, and intended characteristics defined by assigned requirements components can have further properties. Such properties are typically specifications that describe functional or non-functional component characteristics which are assumed for the component at design time or which are defined through the specification of a library component e.g. COTS. A property can be formulated as a contract. As such, it distinguishes between an assumption on the component’s environment and promised characteristics provided that the assumption is fulfilled.

5.5.4.3.1.1.1.5 Design Model

Design models, as defined in [OTAM, 2013] capture the proposed structure of the system under design in terms of subsystems and components. Further, it may contain overall specifications (“what”) for the behavior of its sub-systems (or components) but without stating implementation details (i.e. “how”).


V1.0 R 2015-04-30 99 of 230

5.5.4.3.1.1.1.6 Design Exploration Model

The goal for the usage of a design exploration mode, as defined in [OTAM, 2013], is to allow tool supported analysis of the cost and performance of different design proposals or variations. The design exploration model captures the main influencing variables and focuses on them.

5.5.4.3.1.1.2 Resource Prototype

Prototype is a concept that denotes the occurrence of a component as depicted in the figure below.

Figure 42: Architecture Management – Structural Viewpoint – Prototype

A prototype specifies an occurrence of a component, which can be a part of another component. As such, the interfaces, the structure and the specifications of the occurring component are reused. The occurring component is defined by the type of the prototype. In the role of a component’s part a prototype defines that the occurring component is a sub-component of the component that has the part. Thus, the concept of prototypes appearing as component parts allows the reuse of existing components for (de-)composition steps in component-based design

5.5.4.3.1.1.2.1 Reuse of Components

The usage of components for different parts of in an architecture description is essential for component-based system engineering. That means that a component with its interfaces, its specification and its implementation is defined once but occurs several times as component prototype. In a composition reused components can interact with other component prototypes defining the internal structure of a component-architecture. The reuse of components reduces the development costs for similar sub-systems as well as their verification costs. Typically such design entities are library or COTS components.

5.5.4.3.1.1.3 Resource Port

Port is a concept that denotes typed component interfaces as depicted in the figure below.

Figure 43: Architecture Management – Structural Viewpoint – Port

Ports define component interfaces. As such they declare typed interaction points to the environment of a component. At these interaction points, behavioral characteristics of a component are observable and controllable. Ports can be addressed from properties and requirement specifications for components. Such specifications define expected characteristics, which become visible at the ports. The actual behavior that is controllable and observable at a port is defined by the implementation of a component.

Typically, ports are refined into service-oriented or data-oriented interfaces. Service-oriented interfaces provide or require services. Data-oriented interfaces have data types, which declare the structure of data that can be exchanged via such interfaces. Ports also have a direction that indicates if they enable data flow into the component, data flow out of the component or a bidirectional data exchange. If only the interfaces and the specification of a component are known, a black-box view is provided.


V1.0 R 2015-04-30 100 of 230

5.5.4.3.1.1.3.1 Resource Type

Type is a concept that denotes an interface specification for a component’s port. The port is an instance of the type. This principle is comparable to a component prototype which is an instance of a component defining its type. A type specifies the structure of a component’s port needed for the interaction with its environment. Service-oriented interfaces are declared by a type, which describes required or provided services. A data-oriented interface is declared by a type, which describes all data-items in the interface, their direction and their data-structure.

5.5.4.3.1.1.4 Resource Connector

Connector is a link concept that denotes a data or service interconnection between ports.

Figure 44: Architecture Management – Structural Viewpoint – Connector

A connector specifies control-flow or data-exchange between ports in a context defined by a composed component. Connectors allow the composition of component prototypes as sub-components of a composed component by interconnecting the interfaces defined by the ports of the component prototypes. For these components and sub-components connectors define linkage between signals and events specified by the types of the interconnected ports. Depending on the definition of the connector this linkage can be simple or elaborated. In a very simple case equality is defined. Equality indicates that two components share one date item or one variable. In an elaborated case a complicated forwarding of a signal under some conditions is defined. A connector has connector ends each indicating an interconnected target port belonging to the composed component or belonging to one of the sub-components. Interconnected ports must be compatible to another with respect to type and direction.

5.5.4.3.1.1.4.1 Composition of Components

Components can either be simple (atomic) or they are containers of sub-components defined by component prototypes as parts. When these component prototypes are interconnected in the context of the container component the internal structure of that component is defined by composition. Connectors of the container component allow the interconnection of the component prototypes at their ports together with ports of the container component. They declare which interfaces of the components prototypes and which interfaces of the container component are interconnected. For the purpose of composition connectors typically appear in the role of assembly or delegation connections. Assembly connections define interconnections between ports of sub-components. Delegation connections define interconnections between the ports of a container component and those of its sub-components. Connectors define how services are invoked and how data is exchanged between the ports. This definition is important for the analysis of component compositions.

5.5.4.3.1.1.4.2 Resource Connector End

Connector End is a concept that denotes the identification of a component’s port within its architectural context to define an end of a connector. The component’s port is the target of the connector end and the exact context can be defined by a prototype of the component as depicted in the figure below.


V1.0 R 2015-04-30 101 of 230

Figure 45: Architecture Management – Structural Viewpoint – Connector End

A connector end allows referencing exactly one port of the component that owns the connector or one instantiated port of the component’s parts. In the second case the associated component parts denotes the instantiated context of the component port, which is the target of the reference.

5.5.4.3.1.1.5 Resource Abstraction Level

Abstraction Level is a concept that denotes a level of abstraction for an architecture description with a number of architectural perspectives as depicted below.

Figure 46: Architecture Management – Structural Viewpoint – Abstraction Level

Designing a system-architecture is typically a development process with multiple viewpoints along several process steps and therefore several levels of abstraction according to the concepts of the meta-model developed in the CESAR project. An architecture description at a lower level of abstraction shall be a realization for an architecture description at a higher level of abstraction. Each abstraction level can define several architectural perspectives, each providing a different structural view onto the system design.

According to the Full Project Proposal of MBAT [MBAT FPP, 2010], MBAT considers three levels of abstraction with different characteristics regarding analysis and testing, namely

System Level

T&A models on system level have to deal with the coverage of functional and extra-functional requirements. The assessing of risk and safety, the verification of system functionality and overall timing are activities performed on system level. Sources for test cases on this level are requirements (formal and informal ones), use case scenarios and other kinds of black box system models.

Subsystem Level (Component / Sub-Component Level)

Testing and Analysis requires systematic coverage of control logic, component and ECU properties. Focus is the behavior of components of the system and their interaction. Test cases address timing aspects, communication principles, failure propagation, casual loops and others.

Implementation Level


V1.0 R 2015-04-30 102 of 230

On implementation level verification and validation techniques like static analysis are used- for source code and implementation models. Typical test objectives are e.g. structural coverage criteria, range checks, robustness w.r.t. noise, glitches, delays, failures as well as satisfaction of non-functional requirements like worst-case execution time, worst-case stack consumption or the absence of runtime errors.

The figure below illustrates an architecture description with a system level, a subsystem level and an implementation level having models of an operational, a functional, a logical, a technical and a geometric perspective as well as deployment and realization relationships. The concept of a perspective is described in section 5.5.4.3.1.1.6.

Figure 47: Architecture Management – Structural Viewpoint – Architecture Description – Illustration

5.5.4.3.1.1.5.1 Subject Artifacts

Different kinds of artefacts can be subject to an abstraction level e.g. requirements, Components. These artifacts however are not restricted to this level only but can also appear at the level of other abstraction levels.

5.5.4.3.1.1.5.2 Realization

When a system-architecture is designed incrementally the same system is represented at different levels of abstraction. A component-architecture at a higher abstraction level is realized by component-architecture of a lower abstraction level. A lower abstraction level is typically more fine granular and adds detail to design and specification. Therefore, component prototypes of one abstraction level are refined by component prototypes of a lower abstraction level. The refinement at a lower abstraction level introduces composition of component structures, which was not visible on a higher abstraction level. Various refinement steps can be established by decomposition of components at one abstraction level. This is typically possible as long as a refinement of interfaces is not needed. Yet, refinement of design does not always follow a decomposition approach but can require a realization on a lower level of abstraction. Typically, if a refinement of the interfaces is needed, changing the abstraction level is an appropriate step. The interfaces are refined on the lower level of abstraction. This step involves a proof obligation because the design at the lower level of abstraction shall realize the design at the higher level of abstraction.

5.5.4.3.1.1.6 Resource Perspective

Perspective is a concept that denotes a structured view with an architectural model defined by a component as depicted in the figure below.


V1.0 R 2015-04-30 103 of 230

Figure 48: Architecture Management – Structural Viewpoint – Perspective

Perspectives are a means of partitioning descriptions of the system under development on one abstraction level with respect to structural viewpoints. A perspective has an architecture model defined by a component and its sub-components corresponding to a specific architectural viewpoint (e.g. logical or technical). The components and sub-components with their interfaces defined in different perspectives do not need to be compatible to each other. Component prototypes which are sub-components of architectural models in different perspectives can be allocated to another.

5.5.4.3.1.1.6.1 Subject Artifacts

Different kinds of artefacts can belong to a specific perspective e.g. requirements, Components. These artifacts however are not restricted to this perspective only but can as well appear at the level of other perspectives.

5.5.4.3.1.1.6.2 Kinds of perspectives

According to the concepts of the meta-model developed in the CESAR project, the following perspective kinds of perspectives can be considered: Operational, Functional, Logical, Technical and Geometric.

5.5.4.3.1.1.6.2.1 Operational Perspective

In the operational perspective behavioral capabilities of a system under test are defined. This perspective typically contains an external view on the system under development. A model of an operational perspective has an operational character. That means that it captures the operational context of the actors, which are the system under test and its known environment. The operational perspective describes the actors, which are involved in the operation of the system and it defines procedures and activities which are performed by the actors in the context of the system. They are considered as special components which can be allocated to functions in a functional perspective to define which of the actors belong to the system. A possible refinement of the structural viewpoint concepts for the operational perspective is shown below.

Figure 49: Architecture Management – Structural Viewpoint – Operational Perspective

5.5.4.3.1.1.6.2.2 Functional Perspective

In the functional perspective functions in terms of functional needs of a system under test are specified. This specification consists of system functions, sub-functions and related functional / non-functional constraints, chains of functions as well as functional control- and data-flow. The functional perspective therefore contains


V1.0 R 2015-04-30 104 of 230

an internal view on the system under development in its boundary. Models of a functional perspective have a functional character.

5.5.4.3.1.1.6.2.3 Logical Perspective

In the logical perspective a logical architecture of the system under development is defined. The system under development is refined by decomposition into hierarchical logical components. For all logical components logical ports as well as logical data- and control-flow are specified. This logical control- and data-flow is defined among the logical components occurring as parts of the system under test but also to those occurring as parts of the environment.

5.5.4.3.1.1.6.2.4 Technical Perspective

The technical perspective is oriented towards the technical architecture description for the implementation of the system under test on a physical target platform. It defines the electrical and electronic architecture as well as the software and mechanical parts of the system under test. It considers the component design, its technical interfaces as well as the technical data exchange. The technical perspective encompasses technical components such as mechanical or hydraulic parts as well as electronic control units, buses, and software tasks.

5.5.4.3.1.1.6.2.5 Geometrical Perspective

In the geometrical perspective the physical layout of the system under test is described. A model on the geometric perspective defines spatial dimensions and shapes for the system under test. The geometrical perspective deals for example with the installation of components to specific locations and with cable routes.

5.5.4.3.1.1.6.2.6 Deployment

A deployment addresses component prototypes of one perspective that are allocated to component prototypes of another perspective. The deployment specifies how the related component architectures of different perspectives behave to another. This allows an argumentation about the concretization of a specification. Often two related component prototypes of two perspectives are different regarding their interfaces, composition and implementation. For a deployment these differences have to be stated explicitly. This can help when reasoning that an architecture description at one perspective is the concretization of the component-architecture at another perspective.

D601.022



V1.0 R 2015-04-30 105 of 230

5.5.4.3.1.2 Behavior Viewpoint

The behavior viewpoint for the architecture management specification defines concepts to define behavior in

the context of the system under development. This section does not provide the one and only behavior

model because this is out of scope in MBAT. Instead, a behavior concept is defined that allows addressing

behavior definitions supporting industrial applications. This concept enables the combination of typical

behavior definitions given e.g. by C-code, Simulink models, Sequence Charts or State-Machines.

5.5.4.3.1.2.1 Resource Component (Behavior Viewpoint)

Component is a concept as defined in section 5.5.4.3.1.1.1, which shall satisfy functional requirements and which may have an implemented behavior as depicted below.

Figure 50: Architecture Management – Behavior Viewpoint – Component

The implementation of the component provides a realization of its specification and defines how the component actually behaves. If the implementation is known, the component is considered as a white-box. Otherwise, if only the specification is known, the component is considered as a black-box. The characteristics of its implemented behavior are externally controllable and observable at its ports.

5.5.4.3.1.2.1.1 Implementation

A component can have a related implementation (see Implementation Link in section 5.5.4.5.1.4), which defines its behavior. The implementation therefore defines how the component behaves internally. An implementation can have functional and extra-functional characteristics. Implementation characteristics, which are verified for a component in a specific environment, can be specified as component properties. If a component shall satisfy a requirement then the implementation characteristics have to meet the requirement specification of guaranteed properties for an assumed usage context.

5.5.4.3.1.2.2 Resource Behavior

Behavior is a concept that denotes a behavioral specification or artifact. A behavior defines how inputs are processed to outputs. E.g. in the role of a component’s implementation a behavior realizes internal dynamics and properties of the component. Behavior specifications related to a component as implementation can appear in the role of an implementation model usable for analysis or test activities as described below. They can be given by behavioral models, source code or executable binaries.

D601.022



V1.0 R 2015-04-30 106 of 230

5.5.4.3.1.2.2.1 Implementation Model

Implementation models or component models, as defined in [OTAM, 2013], focus on providing a behavior description of a component, sufficiently detailed that it can easily be turned into an implementation (either via manual programming, or automatic synthesis/code generation). The goal is to describe in detail how a particular task is fulfilled, not only a specification of the desired outcome.

5.5.4.3.2 Detailed IOS Resource Properties

This section specifies the OSLC representation of the Architecture Management concepts defined in the previous section. This specification builds on the Open Services for Lifecycle Collaboration (OSLC) Core Specification and the OSLC Architecture Management (OSLC-AM) Specification to define the resources and properties that are required to support IOS Architecture Management (IOS-AM).

In addition to the namespace URIs and namespace prefixes oslc, rdf, dcterms and foaf defined in the OSLC Core Specification and oslc_am defined in the OSLC Architecture Management Specification, IOS AM defines the namespace URI of http://ios.metamodel.mbat-artemis.eu/ns/am# with a preferred namespace prefix of Mbat_mm_ios_am.

5.5.4.3.2.1 Structural Viewpoint Specification

This section specifies the OSLC representation for the structural viewpoint concepts of the Architecture Management Specification.

5.5.4.3.2.1.1 Resource Component

The Component concept is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.metamodel.mbat-artemis.eu/ns/am#Component MUST conform to the constraints and meaning of properties defined below and to those of http://open-services.net/ns/am#Resource. Notice that partial representations of a Component resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: Component

Type URI: http://ios.metamodel.mbat-artemis.eu/ns/am#Component

Base Type URI: http://open-services.net/ns/am#Resource


Value-type Representation

Range Description

OSLC Core: Common Properties

rdf:

type

zero-or-

many

unspe- cified

Resource Reference n/a The resource type URIs. If not addressed by the element name the rdf:type MUST at least include http://ios.metamodel.mbat-artemis.eu/ns/am#Componen

and http://open-services.net/ns/am#Resource

dcterms: subject

zero-or-many

False String n/a n/a Tag or keyword for a resource. Each occurrence of a dcterms:subject property denotes an additional tag for the resource. A subject indicates a related viewpoint for a component (e.g.

http://ios.artemis.eu/ns/am

http://ios.artemis.eu/ns/am#Component

http://open-services.net/ns/am#Resource







D601.022



V1.0 R 2015-04-30 107 of 230

operational, functional, logical, technical, and geometric).

(others: see http://open-services.net/ns/am#Resource)



Range Description

IOS AM: Additional properties and relationships

Mbat_mm_ios_am:

kind

zero-or- one

False String n/a n/a The component kind. SHOULD be one of

Actor

SystemFunction

HardwareComponent

SoftwareComponent

Mbat_mm_ios_am:

interconnection

zero-or-many

False Resource Either Mbat_mm_ios_am:

Connector

The set of connectors defining interconnections between ports of sub-components and with ports of the component itself.

Mbat_mm_ios_am:

part

zero-or-many


Prototype

The set of sub-components of the component.

Mbat_mm_ios_am:

port

zero-or-many


Port

The set of ports defining the interfaces of the component.

Mbat_mm_ios_am:

fault

zero-or- many

False Resource Either Mbat_mm_ios_am: Fault

A set of hypothetized causes for subsequent component errors.

Mbat_mm_ios_am:

error

zero-or-many


Error

A set of errors as parts of the states the component can have.

Mbat_mm_ios_am:

failure

zero-or-many


Failure

A set of failure denoting failing of functionality provided by the component.

Mbat_mm_ios_am:

safetyMechanism

zero-or-many


Safety Mechanism

A set of safety mechanisms that define implementations to detect faults and to mitigate the occurrence of failures.



Range Description

Relationship properties: This grouping of properties is used to identify relationships between resources managed by

other OSLC Service Providers


Table 12: IOS AM – Structural Viewpoint – Component Resource

5.5.4.3.2.1.2 Resource Prototype

The Prototype concept is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.metamodel.mbat-artemis.eu/ns/am#Prototype MUST conform to the constraints and meaning of properties defined below and to those of http://open-services.net/ns/am#Resource. Notice that partial representations of a Prototype resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: Prototype



http://ios.artemis.eu/ns/am#Prototype


D601.022



V1.0 R 2015-04-30 108 of 230

Type URI: http://ios.metamodel.mbat-artemis.eu/ns/am#Prototype




Range Description


rdf:

type

zero-or-

many

unspe- cified

Resource Reference n/a The resource type URIs. If not addressed by the element name the rdf:type MUST at least include http://ios.metamodel.mbat-

artemis.eu/ns/am#Prototype and http://open-services.net/ns/am#Resource




Range Description


Mbat_mm_ios_am:

type

exactly-one

False Resource Reference Mbat_mm_ios_am:

Component

The component whose occurrence is defined by the prototype.



Range Description




Table 13: IOS AM – IOS AM – Structural Viewpoint – Prototype Resource

5.5.4.3.2.1.3 Resource Port

The Port concept is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.metamodel.mbat-artemis.eu/ns/am#Port MUST conform to the constraints and meaning of properties defined below and to those of http://open-services.net/ns/am#Resource. Notice that partial representations of a Port resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: Port

Type URI: http://ios.metamodel.mbat-artemis.eu/ns/am#Port




Range Description


rdf:

type

zero-or-

many

unspe- cified

Resource Reference n/a The resource type URIs. If not addressed by the element name the rdf:type MUST at least include http://open-

services.net/ns/am#Port and http://open-services.net/ns/am#Resource

dcterms: zero-or- False String n/a n/a Tag or keyword for a









http://ios.artemis.eu/ns/am#Port


http://ios.artemis.eu/ns/am#Port


http://www.mbat-artemis.eu/ns/am#PortComponent

http://www.mbat-artemis.eu/ns/am#PortComponent



D601.022



V1.0 R 2015-04-30 109 of 230

subject many resource. Each occurrence of a dcterms:subject property denotes an additional tag for the resource. A subject defines a related aspect for a port (e.g. functional, safety, timing).




Range Description


Mbat_mm_ios_am:

direction

zero-or-one

False String n/a n/a The direction of the port. SHOULD be one of

in

out

bidirectional

Mbat_mm_ios_am:

type

exactly-one

False Resource Either any The type of the port. This SHOULD be an

Mbat_mm_ios_am:Type.



Range Description




Table 14: IOS AM – IOS AM – Structural Viewpoint – Port Resource

5.5.4.3.2.1.4 Resource Type

The Type concept is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.metamodel.mbat-artemis.eu/ns/am#Type MUST conform to the constraints and meaning of properties defined below and to those of http://open-services.net/ns/am#Resource. Notice that partial representations of a Type resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: Type

Type URI: http://ios.metamodel.mbat-artemis.eu/ns/am#Type




Range Description


rdf:

type

zero-or-

many

unspe- cified


artemis.eu/ns/am#Type and http://open-services.net/ns/am#Resource




Range Description



http://ios.artemis.eu/ns/am#Type









D601.022



V1.0 R 2015-04-30 110 of 230




Range Description




Table 15: IOS AM – IOS AM – Structural Viewpoint – Type Resource

5.5.4.3.2.1.5 Resource Connector

The Connector concept is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.metamodel.mbat-artemis.eu/ns/am#Connector MUST conform to the constraints and meaning of properties defined below and to those of http://open-services.net/ns/am#Resource. Notice that partial representations of a Connector resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: Connector

Type URI: http://ios.metamodel.mbat-artemis.eu/ns/am#Connector




Range Description


rdf:

type

zero-or-

many

unspe- cified


artemis.eu/ns/am#Connector and http://open-services.net/ns/am#Resource




Range Description


Mbat_mm_ios_am: end

one-or-many

False Resource Either any Defines a set of ports interconnected by the connector. Assembly connectors and delegation connectors reference ports of sub-components. Therefore, the exact identification of a port w.r.t. the sub-component is needed as end. This SHOULD be

Mbat_mm_ios_am:ConnectorEnd.



Range Description





http://ios.artemis.eu/ns/am#Connector










D601.022



V1.0 R 2015-04-30 111 of 230

Table 16: IOS AM – IOS AM – Structural Viewpoint – Connector Resource

5.5.4.3.2.1.6 Resource Connector End

The Connector End concept is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.metamodel.mbat-artemis.eu/ns/am#ConnectorEnd MUST conform to the constraints and meaning of properties defined below. Notice that partial representations of a ConnectorEnd resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: ConnectorEnd

Type URI: http://ios.metamodel.mbat-artemis.eu/ns/am#ConnectorEnd



Range Description


rdf:

type

zero-or-

many

unspe- cified

Resource Reference n/a The resource type URIs. If not addressed by the element name the rdf:type MUST at least include http://ios.metamodel.mbat-artemis.eu/ns/am#ConnectorEnd

dcterms:

identifier

exactly- one

unspe- cified

String n/a n/a A unique identifier for a resource. Assigned by the service provider when a resource is created. Not intended for end-user display.

dcterms:

source

zero-or-

one

unspe-

cified

Resource Reference any The resource URI a client can perform a get on to obtain the original non-IOS AM formatted resource that was used to create this resource. The source resource is usually a binary or proprietary format that the service provider can consume and convert into an IOS AM format. The service may use content negotiation with the Accept header to obtain the desired content type.

dcterms:

creator

zero-or-

many

unspe-cified

Resource Either any Creator or creators of resource (reference: Dublin Core). It is likely that the target resource will be a foaf:Person but that is not necessarily the case.

dcterms:

contributor

zero-or-

many

unspe-cified

Resource Either any Contributor or contributors of resource (reference: Dublin Core). It is likely that the target resource will be a foaf:Person but that is not necessarily the

http://ios.artemis.eu/ns/am#ConnectorEnd




D601.022



V1.0 R 2015-04-30 112 of 230

case.

dcterms:

created

zero-or-

one

True DateTime n/a n/a Timestamp of resource creation (reference: Dublin Core).

dcterms:

modified

zero-or-

one

True DateTime n/a n/a Timestamp last latest resource modification (reference: Dublin Core).

oslc:

serviceProvider

zero-or-

many

unspe-cified

Resource Reference oslc:

Service Provider

The scope of a resource is a URI for the resource's OSLC Service Provider.

oslc:

instanceShape

zero-or-

one

unspe-cified


Resource Shape

Resource Shape that provides hints as to resource property value-types and allowed values.



Range Description


Mbat_mm_ios_am:

contextPart

zero-or-one


Prototype

Defines the part which the port of the connector end belongs to. This information is needed for assembly and for delegation connectors.

Mbat_mm_ios_am:

targetPort

exactly-one


Port

The referenced target port.



Range Description



Table 17: IOS AM – IOS AM – Structural Viewpoint – Connector End Resource

5.5.4.3.2.1.7 Resource Abstraction Level

The Abstraction Level concept is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.metamodel.mbat-artemis.eu/ns/am#AbstractionLevel MUST conform to the constraints and meaning of properties defined below and to those of http://open-services.net/ns/am#Resource. Notice that partial representations of a AbstractionLevel resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: AbstractionLevel

Type URI: http://ios.metamodel.mbat-artemis.eu/ns/am#AbstractionLevel




Range Description


rdf:

type

zero-or-

many

unspe- cified

Resource Reference n/a The resource type URIs. If not addressed by the element name the rdf:type MUST at least include http://ios.metamodel.mbat-artemis.eu/ns/am#AbstractionLev

el and http://open-

http://ios.artemis.eu/ns/am#AbstractionLevel








D601.022



V1.0 R 2015-04-30 113 of 230

services.net/ns/am#Resource




Range Description




Range Description



Mbat_mm_ios_am:

subjects

one-or-many

False Resource Reference any The set of artifacts which are subject to this abstraction level SHOULD either be http://ios.metamodel.mbat-

artemis.eu/ns/am#Component, http://open-services.net/ns/rm#Requirement

or http://open-services.net/ns/sm#Fault

Table 18: IOS AM – IOS AM – Structural Viewpoint – Abstraction Level Resource

5.5.4.3.2.1.8 Resource Perspective

The Perspective concept is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.metamodel.mbat-artemis.eu/ns/am#Perspective MUST conform to the constraints and meaning of properties defined below and to those of http://open-services.net/ns/am#Resource. Notice that partial representations of a Perspective resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: Perspective

Type URI: http://ios.metamodel.mbat-artemis.eu/ns/am#Perspective




Range Description


rdf:

type

zero-or-

many

unspe- cified

Resource Reference n/a The resource type URIs. If not addressed by the element name the rdf:type MUST at least include http://ios.metamodel.mbat-artemis.eu/ns/am#Perspective and http://open-services.net/ns/am#Resource




Range Description




Range Description



Mbat_mm_ios_am:

subjects

one-or-many

False Resource Reference any The set of artifacts which are subject to this perspective SHOULD either be http://ios.metamodel.mbat-





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


http://open-services.net/ns/sm#Fault


http://ios.artemis.eu/ns/am#Perspective










D601.022



V1.0 R 2015-04-30 114 of 230

artemis.eu/ns/am#Component, http://open-services.net/ns/rm#Requirement

Or http://open-services.net/ns/sm#Fault

Mbat_mm_ios_am: kind

Exactly-one

True String n/a n/a Used to indicate the nature of this perspective. MUST be

one of

Operational

Functional

Logical

Technical

Geometrical

Table 19: IOS AM – IOS AM – Structural Viewpoint – Perspective Resource

5.5.4.3.2.2 Behavior Viewpoint Specification

This section specifies the OSLC representation for the behavior viewpoint concepts of the Architecture Management Specification.

5.5.4.3.2.3 Resource Behavior

The Behavior concept is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.metamodel.mbat-artemis.eu/ns/am#Behavior MUST conform to the constraints and meaning of properties defined below and to those of http://open-services.net/ns/am#Resource. Notice that partial representations of a Behavior resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: Behavior

Type URI: http://ios.metamodel.mbat-artemis.eu/ns/am#Behavior




Range Description


rdf:

type

zero-or-

many

unspe- cified


artemis.eu/ns/am#Behavior and http://open-services.net/ns/am#Resource

dcterms: subject

zero-or-many

False String n/a n/a Tag or keyword for a resource. Each occurrence of a dcterms:subject property denotes an additional tag for the resource. A subject defines a related aspect for a behavior (e.g. functional, safety, timing).







http://ios.artemis.eu/ns/am#Behavior









D601.022



V1.0 R 2015-04-30 115 of 230



Range Description




Range Description




Table 20: IOS AM – IOS AM – Structural Viewpoint – Behavior Resource

5.5.4.4 IOS Data Models - Verification and Validation Management Domain


Figure 51 : V&V Management – Overview

5.5.4.4.1.1 Resource VV Suite

VV Suite is a concept that denotes an analysis or test effort given by a set of VV Cases together with a set of subject components, environment components, configurations as well as arbiter and scheduler implementations. A VV Suite can have an overall objective and overall results for the coverage of this objective as depicted in the figure below.


D601.022



V1.0 R 2015-04-30 116 of 230

Figure 52: V&V Management – VV Suite

A VV Suite represents a verification or validation effort describing a combination of multiple analyses or tests. The analyses and tests are described by VV Cases as described in section 5.5.4.4.1.2. These are defined within the VV Suite. Analogue to the TestContext in the UML Testing Profile, the VV Suite deploys environment components and the subject component with respect to a given configuration. The environment components (section 5.5.4.4.1.1.5) define interfaces and implement behavior to stimulate and observe the subject component (section 5.5.4.4.1.1.1) within a configuration (see section 5.5.4.4.1.1.2) when a VV Case is executed. How a set of VV Cases related to a VV Suite is executed is defined by the implemented behavior of the scheduler as described in section 5.5.4.4.1.1.4. How the verdicts and the overall verdict related to the execution results of the VV Cases are evaluated is defined by the implemented behavior of the arbiter as described in section 5.5.4.4.1.1.3. Different strategies for the implementations of scheduler and arbiter can be intended for the execution and evaluation of VV Cases. Test and analysis logs, as well as the overall verdict, are stored in a VV Log related to the respective VV Cases.

A VV Suite is mainly used in two roles or in a combination thereof:

In the role of a VV Suite for validation activities effort is defined to analyze or test whether the right engineering decision is taken or the right product is built. This addresses i.e. whether the requirements are valid (consistent, complete, correct, etc.). A validation effort can also confirm that the product, as provided (or as it will be provided), will fulfil its intended usage scenario. Validation (of a product) ensures therefore that the correct product is built. It may be performed in the operational environment or in a simulated operational environment.

In the role of a VV Suite for verification activities effort is defined to analyze or test whether a design or a product is implemented correctly. The verification suite specifies concrete test subjects and targets and provides stimuli and the expected outcome on a concrete technical level. It aims at confirming that work products properly reflect the requirements specified for them.

A VV Suite can have an overall objective e.g. a coverage objective, such as MC/DC of source code. Evaluation results for a VV Suite such as coverage results are addressed by VV Logs related as results to a VV Suite. For the coverage of an overall objective by the VV Cases a VV Suite may have an overall verdict. This verdict can be calculated by the arbiter. The status of the overall verdict is a predefined enumeration specifying the set of possible coverage. For analysis and testing five literals are defined: pass, fail, inconclusive, error, and suspect.

D601.022



V1.0 R 2015-04-30 117 of 230

Pass: The analysis or test results of the VV Cases adhere to the overall objective.

Inconclusive: The execution result of a VV Case cannot be evaluated to be passing or fail.

Fail: The analysis or test results of the VV Cases do not adhere to the overall objective.

Error: An error has occurred within the analysis or testing environment.

Suspect: A VV Case is new or the adherence to the overall objective is suspicious.

5.5.4.4.1.1.1 Subject Component

A VV Suite may know a set of components as subject component. This set consists of components, which are systems or sub-systems to be tested or analyzed. In a testing effort such a subject component is typically called system under test (SUT). A subject component is exercised at its ports by the environment components, which are defined by the VV Suite. Typically no further internal information can be obtained from the subject component as it is a black-box.

5.5.4.4.1.1.2 Configuration

A configuration specifies which and how environment components and subject components belonging to a VV Suite are combined. The concept of a Component (section 5.5.4.3.1.1.1) is reused to define such a configuration. In the UML Testing Profile the configuration concept is defined as a deployment in the role of a test configuration. A configuration is a collection with prototypes of environment components and connections between these objects as well as their connections to prototypes of subject components. For prototypes of subject components a configuration defines both (1) environment component prototypes and connections when a VV Case is started (the initial test/analysis configuration) and (2) the maximal number of environment component prototypes and connections during the test/analysis execution.

5.5.4.4.1.1.3 Arbiter

An arbiter is an implementation in a VV Suite to evaluate test and analysis results. It also assigns the overall verdict of respective VV Cases. The arbiter concept is defined by the UML Testing Profile for this purpose with regard to test efforts. Indeed, test activities need a test oracle to decide the verdict by comparing the expected outcome of a VV Case with the actual outcome after test execution. The expected outcome is often the expected behavior, but can also include non-functional aspects such as response time. In testing practice the arbiter is often not a separate entity but its functions are embedded in test cases. In TTCN-3 [TTCN-3, 2012] for example the test case implementation itself sets the verdict. With regard to setting a verdict the arbiter can be considered as the operational part of a test oracle. The intended outcome of a VV Case may also be defined by a test vector or be part of the test script. However, if the expected outcome of a VV Case is not present in the test vector or the test script, then it must be defined by the Arbiter. Typically, there is a default arbitration algorithm based on functional, conformance testing, which generates Pass, Fail, Inconclusive, and Error as verdict, where these verdicts are ordered as Pass < Inconclusive < Fail < Error. The arbitration algorithm can be user-defined. For the verdict a predefined enumeration is used specifying the set of possible evaluations of an analysis or test. This enumeration is defined with the VV Log concept, which indicates the actual result of the execution of a VV Case. The arbiter typically addresses the values pass, inconclusive, fail, and error.

5.5.4.4.1.1.4 Scheduler

A scheduler is an implementation within a VV Suite that controls the running of the VV Cases. The scheduler concept is defined by the UML Testing Profile for this purpose with regard to test efforts. The information about which environment components exist at any point in time will be kept by the scheduler. Also it will collaborate with the arbiter of the VV Suite to inform it when it is time to issue the final verdict. It keeps control over the creation and destruction of environment components and it knows which environment components take part in each VV Case.

D601.022



V1.0 R 2015-04-30 118 of 230

5.5.4.4.1.1.5 Environment Component

In the context of a VV Suite a component in the role of an environment component is an entity with specified testing or analysis behavior. It stimulates the subject component and provides local validation information to the arbiter. It has a set of interfaces to communicate with the subject component or with other environment components. In the UML Testing Profile, the environment component is defined as TestComponent for testing purpose. During the execution of a VV Case an environment component stimulates the subject component and observes its output. It can also take part in coordination with other components. The classifier behavior of an environment component can be used to specify low-level test behavior, such as test scripts, or it can be automatically generated by deriving the behavior from all VV Cases in which the environment component takes part. Whenever an environment component performs a validation analysis or test action, the Arbiter is notified of the outcome so that it may update the VV Case verdict if necessary.

5.5.4.4.1.1.6 Resource VV Objective

Figure 53: V&V Management – VV Objective

VV Objective is a concept that denotes an objective for a VV case possibly related to an analysis or test model (AT Model) which is derived from a requirement or which targets a verification or validation obligation given by a trace-link.

A VV Objective is a description of the capability to be analyzed or tested in a VV Case or an overall objective for a VV Suite to be covered by many VV Cases. The objective for a VV Case is typically derived from a requirement as defined in [MBAT MM, 2014]or related to an obligation for verification or validation given by a trace-link as defined in [MBAT MM, 2014]. In some cases, this objective could be derived from the outcome of another VV Case.

The evaluation of such an objective is performed in a referenced VV Case. A VV Case can have any number of VV Objectives and a VV Objective can be realized by any number of VV Cases.

Basically each trace-link represents a verification or validation target for a VV Objective and needs an associated analysis or test task defined by a VV Case. A very important VV Objective is the verification of the correct derivation of requirements. Requirements are typically derived when the system-architecture is decomposed, realized or deployed. Derivation of requirements can be indicated by using the trace-link concept of a derive-link. Such a trace-link would become target of a VV Objective describing that the

D601.022



V1.0 R 2015-04-30 119 of 230

derivation of the requirements needs to be analyzed or tested with regard to consistency. The consistency of requirements decides on the ability to build the desired system. Inconsistencies in the requirements are impossible to be compensated in the implementation. Typically requirements to be satisfied by a component, a structural system description of a component and the definition of the behavior implemented by a component are separated from another. The satisfaction of requirements can be defined by using a satisfy-link concept and the implementation of a behavior can be defined by using the implementation-link concept. These trace-links go along with verification or validation obligations to show that the behavior implemented by the component actually satisfies the requirements. The component acts as the interface between the requirement and the implementation. The verification of the satisfy-link between a requirement and a component has the purpose to check if the requirement addresses the elements available in the interface of the component. The verification of the implementation-link between a component and an implemented behavior shall prove very similar the consistency of the interface of the component with the implementation. The extraction of the interface in form of the component makes an additional verification activity necessary: the satisfaction of the requirements through the implementation. A VV Case assigned to this kind of trace-links is assumed to prove that at least one possible implementation is allowed by the requirements and that higher level requirements are properly broken down into the sub-requirements. Refinement of requirements indicated by a refine-link can also be target of a VV Objective. A VV Case for this kind of trace-link shall show whether the refined requirements are complete and correct with regard to the requirement from which they are refined. If single requirements are target of a VV Objective then the requirements themselves shall be analyzed or tested. E.g. the description of single requirements can be inconsistent or some requirements can exclude each other. In the case the objective is derived from the outcome of another VV Case, the goal is to get additional insurances in relation to this outcome. For example, static code analysis may result in different outcomes such as defects and warnings. Accordingly, the VV Objective of a newly generated VV Case could be to verify whether these warnings are actual defects or to discredit them.

The actual verification or validation is a question of the analysis or testing methodology to be applied. A change to a requirement or trace-link which is target to a VV Objective may have an impact on the results of the verification / validation. It therefore leads to a complete re-verification / validation of the VV Objective. For that purpose a change impact analysis can be performed in order to estimate the impact on affected elements.

In other meta-models such a link between an analysis / test effort or task and a requirement indicates that the effort or task connected to the requirement shall verify / validate the requirement. SysML and EAST-ADL define the concept of a verify-link. The meta-model specified in CESAR defines the evaluate link which indicates the verification or validation of requirements. In the UML Testing Profile VV Objective is defined as TestObjective. Concepts from the OMG UML Testing Profile allow modeling objectives and related analysis and test cases.

The concept of a VV Objective allows the description of considerable objectives for analysis and test procedures. Further concepts allow to represent and to link test and analysis objectives with AT Models and metrics.

5.5.4.4.1.2 Resource VV Case

VV Case is a concept that denotes a single analysis or test task in the context of a VV Suite, with a given VV Objective, a set of test vectors, a set of VV Scripts, with a set of VV Logs.

A VV Case is a specification of one case to test or to analyze. It describes interaction between environment components and subject component elements, refers to VV Objectives and lists VV Logs.

A VV Case is an individual task in a VV Suite, which has to be performed within the overall testing or analysis effort. A collection of VV Cases is owned by a VV Suite. It can be a test case, as defined by existing specifications like the UML Testing Profile, TTCN-3 or by OSLC-QM, as well as an analysis task. A VV Case can represent tasks of a verification or validation effort, which have to be performed in order to achieve that effort's overall objective. A verification task is defined with a concrete analysis or testing environment in

D601.022



V1.0 R 2015-04-30 120 of 230

mind. It provides stimuli and the expected outcome of the procedure in a form, which is directly applicable to this analysis or testing environment. One VV Case is a complete technical specification of how a subject component should be tested or analyzed for a given VV Objective. It is a behavioral feature or behavior specifying tests. A VV Case specifies how a set of environment components interacts with a subject component to realize a VV Objective and returns a verdict value. It is defined in terms of sequences, alternatives, loops, and defaults of stimuli to and observations from the subject component. Both the subject component and the different environment components are elements of the VV Suite to which the VV Case belongs. A VV Objective is implemented in the VV Case. The execution of a VV Case may be triggered by a scheduler. Scheduler uses an arbiter to evaluate the outcome of its behavior. A VV Script may be used for the execution of a VV Case defining single steps and procedures to be performed. After the computation of a VV Case a verdict is returned. A VV Case has an overall verdict for its execution with regard to the fulfillment of the objectives. It may also have several verdicts with regard to single objectives and results of test executions. A verdict may be arbitrated - calculated by the arbiter, or non-arbitrated (i.e., provided by the test or analysis behavior).

The status of the overall verdict is a predefined enumeration specifying the set of possible evaluations of an analysis or test. For analysis and testing five literals are defined: pass, fail, inconclusive, error, and suspect.

Pass: The analysis or test result adheres to the VV Objectives.

Inconclusive: The execution result of a VV Case cannot be evaluated to be passing or fail.

Fail: The analysis or test result does not adhere to the VV Objectives.


Suspect: The VV Case is new or the adherence to the VV Objectives is suspicious.

Figure 54: V&V Management – VV Suite

5.5.4.4.1.2.1 Resource Test Vector

Test Vector is a concept that denotes a set of values to be used as stimuli for the system under test and an intended outcome for these stimuli in a VV Case.

A test vector describes the input values used in a test script to stimulate the subject component defined by a VV Suite as system under test when the VV Case is executed. Expected results are described to be compared with the actual result after the execution of a VV Case may also be included in the test vector. VV Cases representing test activities typically need such expected test results, in particular when black-box testing against requirements is performed. This is usually the expected behavior, but can also address non-functional aspects such as response time. The expected result can become part of a test script. The test vector can be considered as the knowledge part of a test oracle because it defines the intended outcome for

D601.022



V1.0 R 2015-04-30 121 of 230

a VV Case. But this is not always the case. The arbiter acts as operational part of the test oracle and compares the actual outcome with the intended outcome to produce the verdict after the execution of the VV Case.

5.5.4.4.1.3 Resource AT Model

The AT model defines a model with emphasis to analysis and testing which can be derived from requirements and refined as depicted in the figure below.

Figure 55: V&V Management – AT Model

According to the MBAT Full Project Proposal an AT Model can be constructed as a formal model systematically for leveraging test and analysis from multiple sources at different abstraction levels. An AT Model can appear in the role of an analysis model or in the role of a test model and it can be used for mutation testing as explained below.

5.5.4.4.1.3.1 Analysis Model

Analysis models, as described in [OTAM, 2013], are made to examine specific properties of a (sub) system, e.g., interaction among system components, timing, or safety / liveness. Such analysis can be made before the system is built, or afterwards (e.g. by deriving from code for code-level analysis, or to “debug” why a system does not work as expected).” Similarly, model-checking models are created with a particular purpose of objective in mind (what requirements / properties should be checked / what precise questions need answering. Given the limitation of model-checking (state-space explosion) it is even plausible that several models are needed targeted at selected subsets of the properties.

5.5.4.4.1.3.2 Test Model

Test models, as described in [OTAM, 2013], are made with the intent of generating (abstract or concrete) test cases that can be executed against the system under test. Test models are different from design and analysis models. They often contain information about the concrete interfaces of the SUT and must reflect the number of component instances and value-ranges provided by the SUT to make test cases realizable. Further, it may contain other test related information and annotations like strategy specifications, test-case goals, model coverage information etc. Similarly development (analysis, design or implementation) models contain details that are irrelevant from a (black-box) testing point of view, where the specified behavior is interesting. Finally, construction of test models may start right after requirements specification is available.

5.5.4.4.1.3.3 AT model derive link

An AT model is designed having in mind a set of requirements that the AT model will be used to check. In some cases, the process of generating the AT model from these requirements can even be automated. The derive link tracing an AT Model to a requirement expresses this relationship.

5.5.4.4.1.3.4 AT model refine link

The refinement of a specification mainly means adding more detail to it while preserving the semantics of the abstraction. For example, requirements are refined for the purpose of formalization of the described properties and of the intended behavior of a component.

D601.022



V1.0 R 2015-04-30 122 of 230

In the case of an AT model, one could think of a scenario where a test model modeling the usage of the system is created in order to generate a set of test cases. Later in the process a formal and a more detailed analysis model is created deriving the same set of requirements than the previous test model to check different kinds of properties. In the sense that the analysis model contains more details but preserves the semantics of the analysis model, the analysis model is a refinement of the test model.

5.5.4.4.1.3.5 Relation between an AT Model and a VV Objective

An AT model may be created as a part of an automated VV Process. The user story introduced in this specification presents an example of such a scenario. An A&T model is generated as a part of an activity that aims at validating warnings that resulted from static code analysis. In order to document the creation of such an artifact as part of a VV Activity, a reference to the A&T model is added to the VV Objective of the VV Case. Alternatively, in model-based testing a VV objective is used to filter the parts of an AT model that are used to generate the VV Cases which will help validate this VV Objective. The VV Objective is in this case the common denominator between an AT model and the VV Cases generated from it.

An AT Model can additionally be referenced by several VV Objectives. In the scenario of the use-story, a new VV Case is created with the VV Objective of validating the warnings resulting from the static code analysis. At the end of the scenario, the V&V engineer may have a hint regarding how to validate the remaining warnings using the A&T model from the scenario. Hence, a new VV Objective is created referencing the same A&T model.

5.5.4.4.1.4 Resource VV Log

VV Log is a concept that denotes a result after the execution of an analysis or test task represented by a VV Case as depicted in the figure below. A VV Log also denotes a coverage result of a VV Suite.

Figure 56: V&V Management – VV Log

VV Log is an adaptation of the TestLog concept defined in the UML Testing Profile. A VV Log is accessible from a VV Case through the log association, as described in section 5.5.4.4.2.2. A VV Log has a status property, which provides a statement whether the execution of a VV Case was successful. Possible values for this status are “success” or “error”.

A VV Log lists the results for the execution of a VV Case under a given configuration. The results are a collection of artefacts, which can take different forms and are represented by the general VV Outcome concept. These artefacts are accessible through the outcome association.

5.5.4.4.1.5 Resource VV Outcome

VV Outcome is a concept denoting a particular result artifact produced during the execution of a VV Case.

A VV Outcome is an actual outcome produced during the execution of a VV Case. Based on a VV Outcome a verdict can be determined for a VV Case. The VV Outcome concept is inspired by the EAST-ADL concept “VVActualOutcome” which “represents the actual output of the testing environment”. Different kinds of outcomes can be produced depending on the applied analysis or test method. E.g. a test outcome can be a trace, an analysis outcome can be a proof or the result of a solver and the outcome of a safety analysis can be an error behavior or a fault-tree.

D601.022



V1.0 R 2015-04-30 123 of 230

5.5.4.4.1.5.1 Resource Verdict

Verdict is a concept denoting a status about the adherence of the analyzed or tested system to the VV Objectives of one or several associated VV Cases.

A VV Case (single verification activity) may be executed with the goal of validating several verification objectives. After its execution, it needs to be decided whether each verification objective is satisfied. Additionally, it needs to be known how this decision was made in relation to the outcomes that were generated as a result of running the VV Case. Therefore, the Verdict concept represents the decision of whether the VV Objective is validated and links it to the VV Outcomes that inhibited this decision.

For example, some verification activity is executed with the two objectives of verifying the blinker emergency and ignition functionalities. Two stimuli are applied simultaneously to the SUT; the outcomes can be a warning that there is a time out for verifying the first objective and a defect in regards to the second one. Hence, two verdicts are created for one VV Case. An inconclusive one for the first verified Objective and a failed verdict for the second VV Objective.

Figure 57: V&V Management – Verdict

The verdict is a response value for an analysis or test. It is a function v(out,obj) defined on the outcome and objective domain which returns an enumerated status value. The status value is calculated and the relationship between outcome and objective is built by the arbiter (section 5.5.4.4.1.1.3).

The status of a Verdict is a predefined enumeration specifying the set of possible evaluations of an analysis or test. For analysis and testing five literals are defined: pass, fail, inconclusive, error, and suspect.

Pass: The analysis or test result adheres to the VV Objective.

Inconclusive: The execution result of a VV Case cannot be evaluated to be passed or fail.

Fail: The analysis or test result does not adhere to the VV Objective.


Suspect: The VV Case is new or the adherence to the VV Objective is suspicious.

5.5.4.4.1.6 Resource VV Script

VV Script is a concept denoting a program or steps used to conduct a test or to execute an analysis.

A VV script defines how a test is performed or how an analysis is executed. It can be e.g. a script or any specification of different steps that need to be performed to conduct an analysis or test. The concept is based on the Test Script concept from OSLC QM and additionally addresses analyses.


This section specifies the OSLC representation of the Analysis and Testing concepts, defined in the previous section. This specification builds on the Open Services for Lifecycle Collaboration (OSLC) Core Specification and the OSLC Quality Management (OSLC-QM) Specification to define the resources and properties that are required to support IOS V&V Management (IOS-VV).

In addition to the namespace URIs and namespace prefixes oslc, rdf, dcterms and foaf defined in the OSLC Core Specification, oslc_rm defined in the OSLC Requirements Management Specification, oslc_am defined in the OSLC Architecture Management Specification and oslc_qm defined in the OSLC Quality Management Specification IOS VV defines the namespace URI of http://ios.metamodel.mbat-artemis.eu/ns/vvm# with a preferred namespace prefix of Mbat_mm_ios_vvm.

http://ios.artemis.eu/ns/vv

D601.022



V1.0 R 2015-04-30 124 of 230

5.5.4.4.2.1 Resource VV Suite

The VV Suite concept is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.metamodel.mbat-artemis.eu/ns/vvm#VVSuite MUST conform to the constraints and meaning of properties defined below and to those of http://open-services.net/ns/qm#TestPlan. Notice that partial representations of a VVSuite resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: VVSuite

Type URI: http://ios.metamodel.mbat-artemis.eu/ns/vvm#VVSuite

Base Type URI: http://open-services.net/ns/qm#TestPlan



Range Description


rdf:

type

zero-or-

many

unspe- cified


artemis.eu/ns/vvm#VVSuite and http://open-services.net/ns/qm#TestPlan

(others: see http://open-services.net/ns/qm#TestPlan)



Range Description

OSLC QM: Additional properties and relationships

oslc_qm: usesTestCase

zero-or-many

False Resource Either any Test Case run by the Test Execution Record. It is likely that the target resource will be an oslc_qm:TestCase but that is not necessarily the case. Represents the case relationship of a VV Suite to a VV Case.



Range Description

IOS VV: Additional properties and relationships

Mbat_mm_ios_vvm: objective

one-or-many

False Resource Either Mbat_mm_ios_vvm:

VVObjective

The purpose of the VV Case describing what the VV Case aims to find out.

Mbat_mm_ios_vvm: result

zero-or-many


VVLog

An overall result indicating how the overall objective of a VV Suite is covered by the VV Cases.

Mbat_mm_ios_vvm: status

zero-or-one

unspe-cified

String n/a n/a Used to indicate the state of the vv suite based on values defined by the service provider. Most often a read-only property. Defines the overall verdict for the coverage of a VV Suite’s

http://ios.artemis.eu/ns/vv#VVSuite

http://open-services.net/ns/qm#TestPlan








D601.022



V1.0 R 2015-04-30 125 of 230

objective by its VV Cases. Before a VV Suite is evaluated the status is either undefined or suspect. MUST be one of

pass

inconclusive

fail

error

suspect



Range Description



Mbat_mm_ios_vvm: arbiter

zero-or-one

unspe-

cified

Resource Either Mbat_mm_ios_am: Behavior

Defines the implementation of an arbiter.

Mbat_mm_ios_vvm:

configuration

zero_or-many

unspe-

cified

Resource Either Mbat_mm_ios_am:

Component

A set of components each being a type that defines an assembly of contained prototypes of environment components and subject components as configurations for the VV Suite.

Mbat_mm_ios_vvm:

environment Component

zero-or-many

unspe-

cified


Component

A set of components that are used in the configuration to provide stimuli to the components which are subject in the VV effort.

Mbat_mm_ios_vvm: scheduler

zero-or-one

unspe-

cified


Behavior

Defines the implementation of a scheduler.

Mbat_mm_ios_vvm: subject Component

zero-or-many

unspe-

cified


Component

A set of components, which are subject to the VV Suite such as a system under test.

(others: see http://open-services.net/ns/qm#TestPlan)

Table 21: IOS VV – VV Suite Resource

5.5.4.4.2.2 Resource VV Case

The VV Suite concept is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.metamodel.mbat-artemis.eu/ns/vvm#VVCase MUST conform to the constraints and meaning of properties defined below and to those of http://open-services.net/ns/qm#TestCase. Notice that partial representations of a VVCase resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: VVCase

Type URI: http://ios.metamodel.mbat-artemis.eu/ns/vvm#VVCase


http://ios.artemis.eu/ns/vv#VVCase

http://open-services.net/ns/qm#TestCase


D601.022



V1.0 R 2015-04-30 126 of 230

Base Type URI: http://open-services.net/ns/qm#TestCase



Range Description


rdf:

type

zero-or-

many

unspe- cified


artemis.eu/ns/vvm#VVCase and http://open-services.net/ns/qm#TestCase

(others: see http://open-services.net/ns/qm#TestCase)



Range Description

OSLC QM: Additional properties and relationships

Prefixed Name Occurs Read-

only Value-type Represent

ation Range Description


Mbat_mm_ios_vvm: context

exactly-one

False Resource Reference Mbat_mm_ios_vvm: VVSuite

The VV Suite defining the context of the VV Case.

Mbat_mm_ios_vvm:

log

zero-or-many


VVLog

A set of results from VV Case executions.


one-or-many


VVObjective

The purpose of the VV Case describing what the VV Case aims to find out.

Mbat_mm_ios_vvm: testVector

zero-or-many

False Resource Either Mbat_mm_ios_vvm: TestVector

A description of stimuli values for the test scripts and a description of expected results for evaluating the results after the execution of the VV Case.


zero-or-one

unspe-cified

String n/a n/a Used to indicate the state of the vv suite based on values defined by the service provider. Most often a read-only property. Defines the overall verdict for the coverage of a VV Suite’s objective by its VV Cases. Before a VV Suite is evaluated the status is either undefined or suspect. MUST be one of

pass

inconclusive

fail

error

suspect



Range Description







D601.022



V1.0 R 2015-04-30 127 of 230



oslc_qm: usesTestScript

zero-or-many

False Resource Either any Test Script used by the Test Case. It is likely that the target resource will be an oslc_qm:TestScript but that is not necessarily the case. The test script can also be defined by an Mbat_mm_ios_am:Behavior resource.

(others: see http://open-services.net/ns/qm#TestCase)

Table 22: IOS VV – VV Case Resource

5.5.4.4.2.3 Resource Test Vector

The VV Suite concept is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.metamodel.mbat-artemis.eu/ns/vvm#TestVector MUST conform to the constraints and meaning of properties defined below. Notice that partial representations of a TestVector resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: TestVector

Type URI: http://ios.metamodel.mbat-artemis.eu/ns/vvm#TestVector



Range Description


rdf:

type

zero-or-

many

unspe- cified

Resource Reference n/a The resource type URIs. If not addressed by the element name the rdf:type MUST at least include http://ios.metamodel.mbat-artemis.eu/ns/vvm#TestVector

dcterms:

identifier

exactly- one

unspe- cified


dcterms:

description

zero-or-

one

unspe-

cified

XMLLiteral n/a n/a Descriptive text (reference: Dublin Core) about resource represented as rich text in XHTML content. SHOULD

include only content that is valid and suitable inside an XHTML <div> element.

dcterms:

creator

zero-or-

many

unspe-cified


dcterms:

contributor

zero-or-

many

unspe-cified

Resource Either any Contributor or contributors of resource (reference: Dublin Core). It is likely that the target resource will be a foaf:Person


http://ios.artemis.eu/ns/vv#TestVector




D601.022



V1.0 R 2015-04-30 128 of 230

but that is not necessarily the case.

dcterms:

created

zero-or-

one


dcterms:

modified

zero-or-

one


oslc:

serviceProvider

zero-or-

many

unspe-cified


Service Provider


oslc:

instanceShape

zero-or-

one

unspe-cified


Resource Shape




Range Description




Range Description



Table 23: IOS VV – VV Test Vector Resource

5.5.4.4.2.4 Resource VV Objective

The VV Suite concept is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.metamodel.mbat-artemis.eu/ns/vvm#VVObjective MUST conform to the constraints and meaning of properties defined below. Notice that partial representations of a VVObjective resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: VVObjective

Type URI: http://ios.metamodel.mbat-artemis.eu/ns/vvm#VVObjective



Range Description


rdf:

type

zero-or-

many

unspe- cified

Resource Reference n/a The resource type URIs. If not addressed by the element name the rdf:type MUST at least include http://ios.metamodel.mbat-artemis.eu/ns/vvm#VVObjective

dcterms:

identifier

exactly- one

unspe- cified


dcterms:

title

exactly-

one

unspe-cified

XMLLiteral n/a n/a Title (reference: Dublin Core) of the resource represented as rich text in XHTML content. SHOULD include only content

that is valid inside an XHTML

http://ios.artemis.eu/ns/vv#VVObjective




D601.022



V1.0 R 2015-04-30 129 of 230

<span> element.

dcterms:

creator

zero-or-

many

unspe-cified


dcterms:

contributor

zero-or-

many

unspe-cified

Resource Either any Contributor or contributors of resource (reference: Dublin Core). It is likely that the target resource will be a foaf:Person but that is not necessarily the case.

dcterms:

created

zero-or-

one


dcterms:

modified

zero-or-

one


oslc:

serviceProvider

zero-or-

many

unspe-cified


Service Provider


oslc:

instanceShape

zero-or-

one

unspe-cified


Resource Shape




Range Description


Mbat_mm_ios_vvm: vvCase

zero-or-many

False Resource Reference Mbat_mm_ios_vvm: VVCase

The set of VV Cases related to the VV Objective.



Range Description



Mbat_mm_ios_vvm: target

zero-or-many

False Resource Either any The set of referenced properties which define the target of the objective. SHOULD be

Mbat_mm_ios_am: Requirement

Mbat_mm_ios_tm: RefineLink

Mbat_mm_ios_tm: DeriveLink

Mbat_mm_ios_tm: SatisfyLink

Mbat_mm_ios_tm: ImplementationLink

Mbat_mm_ios_tm: AllocateLink

Mbat_mm_ios_tm: RealizeLink

Mbat_mm_ios_vvm:

VVOutcome

D601.022



V1.0 R 2015-04-30 130 of 230

Mbat_mm_ios_vvm: ATModel

zero-or-many

False Resource Reference any The AT Model(s) related to this VV Objective

Table 24: IOS VV – VV Objective Resource

5.5.4.4.2.5 Resource VV Log

The VV Suite concept is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.metamodel.mbat-artemis.eu/ns/vvm#VVLog MUST conform to the constraints and meaning of properties defined below and to those of http://open-services.net/ns/qm#TestResult. Notice that partial representations of a VVLog resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: VVLog

Type URI: http://ios.metamodel.mbat-artemis.eu/ns/vvm#VVLog

Base Type URI: http://open-services.net/ns/qm#TestResult



Range Description


rdf:

type

zero-or-

many

unspe- cified


artemis.eu/ns/vvm#VVLog and http://open-services.net/ns/qm#TestResult

(others: see http://open-services.net/ns/qm#TestResult)



Range Description

OSLC QM: Start of additional properties

oslc_qm: status

zero-or-one

unspe-cified

String n/a n/a Used to indicate the state of the VV Log based on values defined by the service provider. Most often a read-only property. Defines whether a VV Case has been successfully executed or not.. MUST be one of

success

error



Range Description

IOS VV: Start of additional properties and relationships

Mbat_mm_ios_vvm:

outcome

zero-or-many

False Resource Either Mbat_mm_ios_vvm: VVOutcome

A set of outcomes produced as a result of a test or analysis task.

Prefixed Name Occurs Read- Value-type Represent Range Description

http://ios.artemis.eu/ns/vv#VVLog

http://open-services.net/ns/qm#TestResult







D601.022



V1.0 R 2015-04-30 131 of 230

only ation




Table 25: IOS VV – VV Log Resource

5.5.4.4.2.6 Resource VV Outcome

The VV Suite concept is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.metamodel.mbat-artemis.eu/ns/vvm#VVOutcome MUST conform to the constraints and meaning of properties defined below. Notice that partial representations of a VVOutcome resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: VVOutcome

Type URI: http://ios.metamodel.mbat-artemis.eu/ns/vvm#VVOutcome



Range Description


rdf:

type

zero-or-

many

unspe- cified

Resource Reference n/a The resource type URIs. If not addressed by the element name the rdf:type MUST at least include http://ios.metamodel.mbat-artemis.eu/ns/vvm#VVOutcome

dcterms:

identifier

exactly- one

unspe- cified


dcterms:

description

zero-or-

one

unspe-

cified



dcterms:

creator

zero-or-

many

unspe-cified


dcterms:

contributor

zero-or-

many

unspe-cified


dcterms:

created

zero-or-

one

True DateTime n/a n/a Timestamp of resource creation (reference: Dublin


http://ios.artemis.eu/ns/vv#VVOutcome




D601.022



V1.0 R 2015-04-30 132 of 230

Core).

dcterms:

modified

zero-or-

one


oslc:

serviceProvider

zero-or-

many

unspe-cified


Service Provider


oslc:

instanceShape

zero-or-

one

unspe-cified


Resource Shape




Range Description


Mbat_mm_ios_vvm: atModel

zero-or-many

False Resource Either Mbat_mm_ios_vvm: ATModel

The set of analysis or test models related to a VV Objective.



Range Description



Table 26: IOS VV – VV Outcome Resource

5.5.4.4.2.7 Resource AT Model

The VV Suite concept is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.metamodel.mbat-artemis.eu/ns/vvm#ATModel MUST conform to the constraints and meaning of properties defined below. Notice that partial representations of an ATModel resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: ATModel

Type URI: http://ios.metamodel.mbat-artemis.eu/ns/vvm#ATModel



Range Description


rdf:

type

zero-or-

many

unspe- cified

Resource Reference n/a The resource type URIs. If not addressed by the element name the rdf:type MUST at least include http://ios.metamodel.mbat-artemis.eu/ns/vvm#ATModel

dcterms:

identifier

exactly- one

unspe- cified


dcterms: zero-or- unspe- XMLLiteral n/a n/a Descriptive text (reference: Dublin Core) about resource

http://ios.artemis.eu/ns/vv#ATModel




D601.022



V1.0 R 2015-04-30 133 of 230

description one cified represented as rich text in XHTML content. SHOULD


dcterms:

creator

zero-or-

many

unspe-cified


dcterms:

contributor

zero-or-

many

unspe-cified


dcterms:

created

zero-or-

one


dcterms:

modified

zero-or-

one


oslc:

serviceProvider

zero-or-

many

unspe-cified


Service Provider


oslc:

instanceShape

zero-or-

one

unspe-cified


Resource Shape




Range Description




Range Description



Table 27: IOS VV – VV AT Model Resource

5.5.4.4.2.8 Resource Verdict

The VV Suite concept is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.metamodel.mbat-artemis.eu/ns/vvm#Verdict MUST conform to the constraints and meaning of properties defined below. Notice that partial representations of a Verdict resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: Verdict

Type URI: http://ios.metamodel.mbat-artemis.eu/ns/vvm#Verdict

http://ios.artemis.eu/ns/vv#Verdict

http://ios.artemis.eu/ns/vv#Verdict

D601.022



V1.0 R 2015-04-30 134 of 230



Range Description


rdf:

type

zero-or-

many

unspe- cified

Resource Reference n/a The resource type URIs. If not addressed by the element name the rdf:type MUST at least include http://ios.metamodel.mbat-artemis.eu/ns/vvm#Verdict

dcterms:

identifier

exactly- one

unspe- cified


dcterms:

description

zero-or-

one

unspe-

cified



dcterms:

creator

zero-or-

many

unspe-cified


dcterms:

contributor

zero-or-

many

unspe-cified


dcterms:

created

zero-or-

one


dcterms:

modified

zero-or-

one


oslc:

serviceProvider

zero-or-

many

unspe-cified


Service Provider


oslc:

instanceShape

zero-or-

one

unspe-cified


Resource Shape




Range Description

OSLC QM: Start of additional properties



Range Description



exactly-one

False Resource Either Mbat_mm_ios_vvm: VVObjective

The objective which the verdict is related to.

http://ios.artemis.eu/ns/vv#VerdictTestVector

http://ios.artemis.eu/ns/vv#VerdictTestVector

D601.022



V1.0 R 2015-04-30 135 of 230

Mbat_mm_ios_vvm:

outcome

zero-or-one

False Resource Either Mbat_mm_ios_vvm: VVOutcome

An outcome produced as a result of a test or analysis task which the Verdict is based on.


zero-or-one

unspe-cified

String n/a n/a Used to indicate the state of the Verdict based on values defined by the service provider. Most often a read-only property. Defines the verdict after the execution of a VV Case for one objective. MUST be one of

pass

inconclusive

fail

error

suspect



Range Description



Table 28: IOS VV – VV Verdict Resource

5.5.4.4.2.9 Resource VV Script

The VV Suite concept is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.metamodel.mbat-artemis.eu/ns/vvm#VVScript MUST conform to the constraints and meaning of properties defined below and to those of http://open-services.net/ns/qm#TestScript. Notice that partial representations of a VVLog resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: VVScript

Type URI: http://ios.metamodel.mbat-artemis.eu/ns/vvm#VVScript

Base Type URI: http://open-services.net/ns/qm#TestScript



Range Description


rdf:

type

zero-or-

many

unspe- cified


artemis.eu/ns/vvm#VVScript and http://open-services.net/ns/qm#TestResult

(others: see http://open-services.net/ns/qm#TestScript)



Range Description



http://ios.artemis.eu/ns/vv#VVScript

http://open-services.net/ns/qm#TestScript








D601.022



V1.0 R 2015-04-30 136 of 230


Table 29: IOS VV – VV Script Resource


The mapping of the IOS resource types proposed here maps the meta-model concepts to semantically equivalent resources from the appropriate OSLC domain. For example, the IOS resource type VV Case is mapped to an OSLC Test Case and an IOS VV Log is mapped to an OSLC Test Result. However, the properties defined by the IOS resources might sometimes carry information already contained by the OSLC resources they are mapped to.

For example, an OSLC Test Case has a property validatesRequirement which is a reference to the element validated by the Test Case. The OSLC QM specification doesn’t put a restriction on the resource type referenced by this property. Alternatively, an IOS VV Case mapped to the OSLC Test Case has a property: VV Objective which also references the target of the verification activity. Since the validatesRequirement property doesn’t put a restriction on the type of the resource, it can be reused as a placeholder for the VV Objective. Such a solution would minimize the semantic gap between IOS and OSLC concepts.

Additionally, the suggested mapping leads in some occasions to the existence of bidirectional relationships between resources. In the case of an OSLC Test Plan, the oslc_qm:usesTestCase property contains a reference to the OSLC Test Cases used by the Test Plan. A bidirectional relationship is caused here by the mapping of an OSLC Test Plan to the IOS type VV Suite. From the MBAT meta-model point of view, such a relationship is contained by the resource type VV Case which references a VV Suite.

Figure 58: Overview of the mapping between the OSLC QM domain to the IOS VV specification

If suggestions are to be made to the OSLC community, there needs to be a consideration of these issues. For this specification, the next step is to identify the relationships and the attributes that can be reused from the OSLC Core domain in order to minimize the additional properties needed for the IOS.


D601.022



V1.0 R 2015-04-30 137 of 230

5.5.4.5 IOS Data Models - Traceability Management Domain

5.5.4.5.1 Overview of the IOS Resource Types and their Relationships

Figure 59: Traceability Management – Overview

5.5.4.5.1.1.1 Resource Refine Link

The refine link is a trace-link concept that denotes that the specification of a requirement refines another requirement or that an AT Model refines another AT Model.

Figure 60: Traceability Management – Refine link

A refine link which relates requirements to another indicates that one requirement specification (section 5.6) refines the other one. In a meta-model like SysML a refine link represents a specific dependency between requirements on different levels of abstraction where one or multiple target requirements add further detail to the source requirement. The existence of the resulting requirements is completely defined by the superior source requirement. If the latter is changed, the resulting requirements of the refinement need to be changed, too. Also AT models (section 5.5.4.4.1.3) can be related to another by a refine link indicating that the refining AT model is more detailed than the refined AT model.

5.5.4.5.1.2 Resource Derive Link

The derive link is a trace-link concept between requirements as well as between requirements and AT Models as depicted in the figure below. It denotes that a requirement on a lower level in the system hierarchy is derived from another requirement at a higher level of system hierarchy respectively that an AT Model is derived from a requirement.

D601.022



V1.0 R 2015-04-30 138 of 230

Figure 61: Traceability Management – Derive Link

A derive link relates a set of requirements to another indicating that a set of requirement specifications is derived from other requirements on a higher level of a system hierarchy. This trace-link concept corresponds to the “DeriveReqt” trace concept from SysML and the “DeriveRequirement” relationship for requirements defined by EAST-ADL. A derive link between a requirement and an AT Model indicates that the AT Model has been derived from the requirement.

5.5.4.5.1.3 Resource Satisfy Link

The satisfy link is a trace-link concept that allocates requirements to components as depicted in the figure below. This kind of link indicates that a requirement shall be satisfied by a component.

Figure 62: Traceability Management – Satisfy Link

When a requirement is allocated to a component by using a satisfy link, this link indicates that the component with its properties and its behavior shall satisfy the requirement. Therefore, the dynamics of the implementation of a component shall meet the intended properties and the behavior that are described by the requirement. This concept is inspired by SysML and by EAST-ADL. The satisfy link concept supports contract-based specification because assumed and guaranteed characteristics can be expressed by requirements that shall be satisfied by a component. The concept of contracts, which are assigned to system components of the system design, is described in the HRC meta-model specification of the SPEEDS project. Satisfaction must be verified by analysis methods that show whether a component meets a requirement or not.

In a meta-model like SysML a Satisfy-link between components (components of different abstraction layers, source code) and system requirements indicates that the artefacts shall satisfy the requirements they are linked to. The justification of this link is done by verification means. A change of a requirement may have an impact on an assigned component. Therefore, a change of a requirement typically leads to the re-verification of a satisfaction justification for a component.

5.5.4.5.1.4 Resource Implementation Link

The implementation link is a trace-link concept that denotes the implementation of a specific behavior through a component or the implementation of a specific failure mode through a fault as depicted in the figure below.

D601.022



V1.0 R 2015-04-30 139 of 230

Figure 63: Traceability Management – Implementation Link

5.5.4.5.1.5 Resource Realize Link

The realize link is a trace-link concept that denotes a realization relationship between component prototypes as depicted in the figure below.

Figure 64: Traceability Management – Realize Link

A realize link is an architectural link addressing the incremental refinement of components during a development process according to the concepts of the meta-model developed in the CESAR project. When a system is designed incrementally the same system is represented at different levels of abstraction. Component prototypes at a higher abstraction level are realized by component prototypes of a lower abstraction level. A lower abstraction level is typically more fine granular and adds detail to design and specification. Therefore, design entities of one abstraction level are refined by design entities of a lower abstraction level. The refinement at a lower abstraction level introduces composition of design entity structures, which were not visible on a higher abstraction level.

Various refinement steps can be established by decomposition of design entities at one abstraction level. This is typically possible as long as a refinement of interfaces is not needed. In other cases changing the abstraction level is more appropriate. Therefore, refinement of design does not always follow a decomposition approach but can require a realization on a lower level of abstraction.

D601.022



V1.0 R 2015-04-30 140 of 230

5.5.4.5.1.6 Resource Mapping End

Mapping End is a concept that denotes the identification of a component’s port or a component’s part in its architectural context to define the end of a mapping relationship. The target is a component’s port or a components part. The exact context of such a port or part is defined by a path through the hierarchy of owning component occurrences, which is given by a list of prototypes as depicted below.

Figure 65: Traceability Management – Mapping End

The Mapping End concept allows referencing exactly one component part or port in its architectural context. Mapping relationships can be defined by the allocate link or by the realize link. They map components’ ports or parts from one architectural context to another. This context is typically given by a path through the hierarchy of owning component occurrences.

5.5.4.5.1.7 Resource Allocate Link

The allocate link is a trace-link concept that denotes an allocation relationship between component prototypes or ports as depicted below.

Figure 66: Traceability Management – Allocate Link

An Allocate Link is an architectural link addressing component prototypes of one perspective that are allocated to component prototypes of another perspective according to concepts of the meta-model developed in the CESAR project. The allocation specifies how the related component prototypes of different perspectives behave to another. This allows an argumentation about the concretization of a specification. Often two related design entities of two perspectives are different regarding their interfaces, composition and

D601.022



V1.0 R 2015-04-30 141 of 230

implementation. For an allocation these differences have to be stated explicitly. This can help when reasoning that a design at one perspective is the concretization of the design at another perspective.


This section specifies the OSLC representation of the Traceability Management concepts defined in section 5.5.4.5.1. This specification builds on the Open Services for Lifecycle Collaboration (OSLC) Core Specification to define the resources and properties that are required to support IOS Traceability Management (IOS-TM).

In addition to the namespace URIs and namespace prefixes oslc, rdf, dcterms and foaf defined in the OSLC Core Specification, oslc_rm defined in the OSLC Requirements Management Specification, oslc_am defined in the OSLC Architecture Management Specification and oslc_qm defined in the OSLC Quality Management Specification IOS TM defines the namespace URI of http://www.ios.artemis.eu/ns/tm# with a preferred namespace prefix of Mbat_mm_ios_tm.

5.5.4.5.2.1 Resource Refine Link

The Refine Link concept , defined in section 5.5.4.5.1.1.1, is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.metamodel.mbat-artemis.eu/tm#RefineLink MUST conform to the constraints and meaning of properties defined below. Notice that partial representations of a RefineLink resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: RefineLink

Type URI: http://ios.metamodel.mbat-artemis.eu/tm#RefineLink



Range Description


rdf:

type

zero-or-

many

unspe- cified

Resource Reference n/a The resource type URIs. If not addressed by the element name the rdf:type MUST at least include http://ios.metamodel.mbat-artemis.eu/tm#RefineLink

dcterms:

identifier

exactly- one

unspe- cified


rdfs:

label

exactly-one

unspe-cified

String n/a n/a The human readable name for this link type. This value is expected to be used in drop down lists and in tables where a link of this type is involved. SHOULD be “refine”.

dcterms:

creator

zero-or-

many

unspe-cified


dcterms:

contributor

zero-or-

many

unspe-cified

Resource Either any Contributor or contributors of resource (reference: Dublin

http://www.ios.artemis.eu/ns/tm

http://ios.artemis.eu/ns/tm#RefineLink




D601.022



V1.0 R 2015-04-30 142 of 230

Core). It is likely that the target resource will be a foaf:Person but that is not necessarily the case.

dcterms:

created

zero-or-

one


dcterms:

modified

zero-or-

one


oslc:

serviceProvider

zero-or-

many

unspe-cified


Service Provider


oslc:

instanceShape

zero-or-

one

unspe-cified


Resource Shape




Range Description

IOS TM: Additional properties and relationships



Range Description



Mbat_mm_ios_tm:

refined

one-or-many

False Resource Reference any The set of requirements or AT models being refined. SHOULD be one of

ios_rm:Requirement, ios_vv:ATModel

Mbat_mm_ios_tm:

refinedBy

one-or-many

False Resource Reference any The set of refining requirements or AT Models. SHOULD be one of


Table 30: IOS TM – Refine Link Resource

5.5.4.5.2.2 Resource Derive Link

The Derive Link concept, defined in section 5.5.4.5.1.2 is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.metamodel.mbat-artemis.eu/tm#DeriveLink MUST conform to the constraints and meaning of properties defined below. Notice that partial representations of a DeriveLink resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: DeriveLink

Type URI: http://ios.metamodel.mbat-artemis.eu/tm#DeriveLink



Range Description


rdf:

type

zero-or-

many

unspe- cified


http://ios.artemis.eu/ns/tm#DeriveLink



D601.022



V1.0 R 2015-04-30 143 of 230

artemis.eu/tm#DeriveLink

dcterms:

identifier

exactly- one

unspe- cified


rdfs:

label

exactly-one

unspe-cified

String n/a n/a The human readable name for this link type. This value is expected to be used in drop down lists and in tables where a link of this type is involved. SHOULD be “derive”.

dcterms:

creator

zero-or-

many

unspe-cified

Resource Either any Creator or creators of resource (reference: Dublin Core). It is likely that the target resource will be an foaf:Person but that is not necessarily the case.

dcterms:

contributor

zero-or-

many

unspe-cified

Resource Either any Contributor or contributors of resource (reference: Dublin Core). It is likely that the target resource will be an foaf:Person but that is not necessarily the case.

dcterms:

created

zero-or-

one


dcterms:

modified

zero-or-

one


oslc:

serviceProvider

zero-or-

many

unspe-cified


Service Provider


oslc:

instanceShape

zero-or-

one

unspe-cified


Resource Shape




Range Description




Range Description



Mbat_mm_ios_tm:

derived

one-or-many

False Resource Reference any The set of requirements or AT Models being derived. SHOULD be one of


Mbat_mm_ios_tm:

derivedFrom

one-or-many

False Resource Reference ios_rm:

Requirement

The set of derivation sources.

Table 31: IOS TM – Derive Link Resource


D601.022



V1.0 R 2015-04-30 144 of 230

5.5.4.5.2.3 Resource Satisfy Link

The Satisfy Link concept, defined in section 5.5.4.5.1.3, is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.metamodel.mbat-artemis.eu/tm#SatisfyLink MUST conform to the constraints and meaning of properties defined below. Notice that partial representations of a SatisfyLink resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: SatisfyLink

Type URI: http://ios.metamodel.mbat-artemis.eu/tm#SatisfyLink



Range Description


rdf:

type

zero-or-

many

unspe- cified

Resource Reference n/a The resource type URIs. If not addressed by the element name the rdf:type MUST at least include http://ios.metamodel.mbat-artemis.eu/tm#SatisfyLink

dcterms:

identifier

exactly- one

unspe- cified


rdfs:

label

exactly-one

unspe-cified

String n/a n/a The human readable name for this link type. This value is expected to be used in drop down lists and in tables where a link of this type is involved. SHOULD be “satisfy”.

dcterms:

creator

zero-or-

many

unspe-cified


dcterms:

contributor

zero-or-

many

unspe-cified


dcterms:

created

zero-or-

one


dcterms:

modified

zero-or-

one


oslc:

serviceProvider

zero-or-

many

unspe-cified


Service Provider


oslc:

instanceShape

zero-or-

one

unspe-cified


Resource Shape




Range Description


http://ios.artemis.eu/ns/tm#SatisfyLink


http://ios.metamodel.mbat-artemis.eu/tm#SatisfyLink

http://ios.metamodel.mbat-artemis.eu/tm#SatisfyLink

D601.022



V1.0 R 2015-04-30 145 of 230



Range Description



Mbat_mm_ios_tm:

satisfiedBy

One-or-many


Component

The set of referenced components.

Mbat_mm_ios_tm:

satisfies

Zero-or-many

False Resource Reference ios_rm:

Requirement

The set of requirements that shall be satisfied.

Table 32: IOS TM – Refine Satisfy Resource

5.5.4.5.2.4 Resource Implementation Link

The Implementation Link concept, defined in section 5.5.4.5.1.4 is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.metamodel.mbat-artemis.eu/tm#SatisfyLink MUST conform to the constraints and meaning of properties defined below. Notice that partial representations of a SatisfyLink resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: ImplementationLink

Type URI: http://ios.metamodel.mbat-artemis.eu/tm#ImplementationLink



Range Description


rdf:

type

zero-or-

many

unspe- cified

Resource Reference n/a The resource type URIs. If not addressed by the element name the rdf:type MUST at least include http://ios.metamodel.mbat-artemis.eu/tm#ImplementationLink

dcterms:

identifier

exactly- one

unspe- cified


rdfs:

label

exactly-one

unspe-cified

String n/a n/a The human readable name for this link type. This value is expected to be used in drop down lists and in tables where a link of this type is involved. SHOULD be

“implementation”.

dcterms:

creator

zero-or-

many

unspe-cified


dcterms:

contributor

zero-or-

many

unspe-cified



http://ios.artemis.eu/ns/tm#ImplementationLink




D601.022



V1.0 R 2015-04-30 146 of 230

dcterms:

created

zero-or-

one


dcterms:

modified

zero-or-

one


oslc:

serviceProvider

zero-or-

many

unspe-cified


Service Provider


oslc:

instanceShape

zero-or-

one

unspe-cified


Resource Shape




Range Description

IOS TM: Start of additional properties



Range Description



Mbat_mm_ios_tm:

implementedBy

exactly-one

False Resource Reference any The component that implements a specific behavior or the fault that implements a specific failure mode. SHOULD be one of

Mbat_mm_ios_am:Component, Mbat_mm_ios_am:Fault

Mbat_mm_ios_tm:

implements

exactly-one

False Resource Reference any The implemented behavior or the failure mode. SHOULD be

one of Mbat_mm_ios_am:Behavior, Mbat_mm_ios_am:FailureMode.

Table 33: IOS TM – Implementation Link Resource

5.5.4.5.2.5 Resource Realize Link

The Realize Link concept, defined in section 5.5.4.5.1.5, is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.metamodel.mbat-artemis.eu/tm#RealizeLink MUST conform to the constraints and meaning of properties defined below. Notice that partial representations of a RealizeLink resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: RealizeLink

Type URI: http://ios.metamodel.mbat-artemis.eu/tm#RealizeLink



Range Description


rdf:

type

zero-or-

many

unspe- cified

Resource Reference n/a The resource type URIs. If not addressed by the element name the rdf:type MUST at least include http://ios.metamodel.mbat-artemis.eu/tm#RealizeLink

http://ios.artemis.eu/ns/tm#RealizeLink




D601.022



V1.0 R 2015-04-30 147 of 230

dcterms:

identifier

exactly- one

unspe- cified


rdfs:

label

exactly-one

unspe-cified

String n/a n/a The human readable name for this link type. This value is expected to be used in drop down lists and in tables where a link of this type is involved. SHOULD be “realize”.

dcterms:

creator

zero-or-

many

unspe-cified


dcterms:

contributor

zero-or-

many

unspe-cified


dcterms:

created

zero-or-

one


dcterms:

modified

zero-or-

one


oslc:

serviceProvider

zero-or-

many

unspe-cified

Resource Reference oslc:Service Provider


oslc:

instanceShape

zero-or-

one

unspe-cified


Resource Shape




Range Description




Range Description



Mbat_mm_ios_tm:

source

one-or-many

False Resource Either any The set of ports or prototypes which are sources of realization. Since the architectural context can be different the exact identification of ports and prototypes within their context is needed. This SHOULD be done using Mbat_mm_ios_tm:MappingEnd.

Mbat_mm_ios_tm:

target

One-or-many

False Resource Either any The set of ports or prototypes, which are targets of realization. Since the architectural context can be different the exact

D601.022



V1.0 R 2015-04-30 148 of 230

identification of ports and prototypes within their context is needed. This SHOULD be done using Mbat_mm_ios_tm:MappingEnd.

Table 34: IOS TM – Realize Link Resource

5.5.4.5.2.6 Resource Mapping End

The Mapping End concept, defined in section 5.5.4.5.1.6 is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.metamodel.mbat-artemis.eu/tm#MappingEnd MUST conform to the constraints and meaning of properties defined below. Notice that partial representations of a MappingEnd resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: Mapping End

Type URI: http://ios.metamodel.mbat-artemis.eu/tm#MappingEnd



Range Description


rdf:

type

zero-or-

many

unspe- cified

Resource Reference n/a The resource type URIs. If not addressed by the element name the rdf:type MUST at least include http://ios.metamodel.mbat-artemis.eu/tm#MappingEnd

dcterms:

identifier

exactly- one

unspe- cified


dcterms:

creator

zero-or-

many

unspe-cified


dcterms:

contributor

zero-or-

many

unspe-cified


dcterms:

created

zero-or-

one


dcterms:

modified

zero-or-

one


oslc:

serviceProvider

zero-or-

many

unspe-cified


Service Provider


oslc:

instanceShape

zero-or-

one

unspe-cified


Resource Shape

Resource Shape that provides hints as to resource property value-types and allowed

http://ios.artemis.eu/ns/tm#MappingEnd




D601.022



V1.0 R 2015-04-30 149 of 230

values.



Range Description

IOS TM: Start of additional properties



Range Description



Mbat_mm_ios_tm:

contextPart

Zero-or-or-many

False Resource Reference Mbat_mm_ios_am: Prototype

A list of prototypes describing a path through the hierarchy of owning component occurrences that explicitly defines the context of the target port or target part.

Mbat_mm_ios_tm:

targetPart

zero-or-one

False Resource Reference Mbat_mm_ios_am: Prototype

A referenced part which is target for a mapping end.

Mbat_mm_ios_tm:

targetPort

zero-or-one

False Resource Reference Mbat_mm_ios_am: Port

The referenced port which is target for a mapping end.

Table 35: IOS TM – Mapping End Resource

5.5.4.5.2.7 Resource Allocate Link

The Allocate Link concept, defined in section 5.5.4.5.1.7 is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.metamodel.mbat-artemis.eu/tm#AllocateLink MUST conform to the constraints and meaning of properties defined below and to those of http://open-services.net/ns/am#Resource. Notice that partial representations of a Allocate Link resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: Allocate Link

Type URI: http://ios.metamodel.mbat-artemis.eu/tm#AllocateLink



Range Description


rdf:

type

zero-or-

many

unspe- cified

Resource Reference n/a The resource type URIs. If not addressed by the element name the rdf:type MUST at least include http://ios.metamodel.mbat-artemis.eu/tm#AllocateLink

dcterms:

identifier

exactly- one

unspe- cified


rdfs:

label

exactly-one

unspe-cified

String n/a n/a The human readable name for this link type. This value is expected to be used in drop down lists and in tables where a link of this type is involved. SHOULD be “allocate”.

http://ios.artemis.eu/ns/tm#AllocateLink






D601.022



V1.0 R 2015-04-30 150 of 230

dcterms:

creator

zero-or-

many

unspe-cified


dcterms:

contributor

zero-or-

many

unspe-cified


dcterms:

created

zero-or-

one


dcterms:

modified

zero-or-

one


oslc:

serviceProvider

zero-or-

many

unspe-cified


Service Provider


oslc:

instanceShape

zero-or-

one

unspe-cified


Resource Shape




Range Description




Range Description



Mbat_mm_ios_tm:

source

one-or-many

False Resource Either any The set of ports or prototypes which are sources of allocation. Since the architectural context can be different the exact identification of ports and prototypes within their context is needed. This SHOULD be done using Mbat_mm_ios_tm:MappingEnd.

Mbat_mm_ios_tm:

target

One-or-many

False Resource Either any The set of ports or prototypes which are targets of allocation. Since the architectural context can be different the exact identification of ports and prototypes within their context is needed. This SHOULD be done using Mbat_mm_ios_tm:MappingEnd.

Table 36: IOS TM – Allocate Link Resource


D601.022



V1.0 R 2015-04-30 151 of 230

As mentioned before, the design decision taken during MBAT of representing relationships between resources as objects is not completely aligned with the principles of linked data. The reasons behind following such a design pattern may not apply anymore after the new contributions of the OSLC community. Given that the projects is enriched by the participation of the same people that were at the source of these new findings, the next step for specifying how traceability shall be handled Is to work together with the OSLC community in order to align the results of MBAT for traceability management with the OSLC technology. Additionally, the concept of a Mapping End seems to be a viable candidate for covering the need covered by the connector End concept in the Architecture management specification. One of the next steps should be looking into the replacement of one of the concepts with the other.

5.5.5 Derived Concepts

The IOS concepts mentioned may use a diverging terminology when compared to other IOS systems. Especially it may be that the IOS objects proposed have technical capacities, that would allow much more use cases to be addressed, but do not reflect the necessary terminology and relationship on the logical or conceptual level.

Therefore we propose to add derived concepts in a future version of the IOS to add a logical layer that allows more flexibility without introducing new IOS objects or marker classes. One example of such a derived concept could be functions. In the current IOS, a function of the system under development can be modelled by a Component which is subject of a functional perspective. It may be necessary to define a function explicitly with additional properties and relations.

Other examples are technical and software components. It should be possible to express, that a software component shall be executed on a specific technical hardware component.

We assume that the introduction of derived concepts allows a broader use of the IOS without introducing new OSLC classes and would yield a wider acceptance. Furthermore by derived concepts it would be possible to use domain specific terminology which eases verification of the IOS objects with regards to norms applying to the domain specific development processes.

D601.022



V1.0 R 2015-04-30 152 of 230

5.6 Formal Requirements Management OFFIS


Full Name

Christian ELLEN

Affiliation

OFFIS

e-mail christian.ellen@offi

s.de

Phone +49 441 9722-511

Full Name

Omar KACIMI

Affiliation

OFFIS

e-mail omar.kacimi@offis.

de

Phone +49 441 9722-476

5.6.2 Context


The formalization of requirements within an engineering process is a hard task which involves many tools to interact with each other and exchange artefacts. The formal requirements management IOS proposed within this chapter addresses such a process by definition of resource shapes to support a contract-based requirement formalization process, as well as, IOS extensions to support the definition and exchange of requirement patterns.

The scope of this chapter comprises two main contributions: The first is to provide proposals for a definition of an IOS domain ios_rm for Contract-based design which is better aligned with the specifications in the oslc_rm domain than the existing definitions. The second contribution is a proposal to define an IOS for the syntax of requirement patterns within the domain ios_frm.


[MBAT,

2015]

MBAT Project, Combined Model-based Analysis and Testing of Embedded Systems ,

http://mbat-artemis.eu/home/

[CESAR,

2012]

CESAR Project, Cost-efficient methods and processes for safety relevant embedded

systems, http://www.cesarproject.eu/

[CMM, 2011] CESAR WP 1.3; “Meta-Model Specification for RTP 2.0”; Deliverable D_SP1_R.3.2_A_M2,

annex of deliverable D_SP1_R3.2_M2 “Specification for RTP V2”

[CESAR

DODT,

2014]

CESAR Project Deliverable - Public - Revised Definitions of Improved RE

Methods – D_SP2_R3.3_M3_Vol 2

[HRC, 2009] Speculative and Exploratory Design in Systems Engineering (SPEEDS); SPEEDS

L-1 Meta-Model; Deliverable D2.1.5; Revision 1.0.1; 2009-05-15;







http://www.cesarproject.eu/


D601.022



V1.0 R 2015-04-30 153 of 230



[RSL, 2011] CESAR WP 2.2; “RE Language Definitions to formalize multi-criteria requirements V2”;

Deliverable D_SP2_R2.2_M2

[SPES-AM] Software Platform Embedded System 2020, SPES2020 Architecture Modelling, SPES2020

project deliverable, OFFIS, Version 1.2, February 2011

[MBAT MM,

2014]

MBAT D_WP3.1_3; “Meta-Model for RTP 2.0”

[MBAT IOS,

2014]

MBAT D_WP3.2_3; “Specification for RTP interoperability v 2.0”

[ISO/IEC,

1996]

ISO/IEC 14977 : 1996(E) Syntactic meta language -- Extended BNF

[CRYSTAL-

RBE, 2015]

Requirements Based Engineering, CRYSTAL Deliverable, D607.902

[BTC-ES

Pattern,2014

]

BTC Embedded Systems: BTC EmbeddedSpecifier. http://www.btc-

es.de/index.php?idcatside=52


5.6.3.1 Formal Requirements Analysis Scenarios from MBAT

Three combined T&A patterns from the MBAT methodology [MBAT_AT, 2014] were identified to be relevant

for the requirements management specification and analyzed for the usage of the OSLC [OSLC] and MBAT

IOS specifications:

1. Model-Based Testing (MBT) with Test Model analysis

2. Target MBT to failing test-cases

3. Slice large model by test run

Figure 67: Combined T&A Pattern “MBT with analysis”


http://www.btc-es.de/index.php?idcatside=52

http://www.btc-es.de/index.php?idcatside=52

D601.022



V1.0 R 2015-04-30 154 of 230

Figure 68: Combined T&A Pattern “Target MBT to Failing Test-Case”

Figure 69: Combined T&A Pattern “Slice Large Model by Test run”

D601.022



V1.0 R 2015-04-30 155 of 230

It is worth to notice that actually every pattern, containing testing and analysis activities may relate to

requirements. But in the most cases this is resolved only by the traceability links and does not involve any

specific activities on the requirements. Thus, only the three mentioned T&A patterns were considered as

specific to the requirements formalization.

These patterns were evaluated with the examples of the scenarios from two automotive use-cases in MBAT.

The formal and semi-formal requirements are used as inputs for the preparation of a T&A model. They are

then linked to the analysis objectives and test objectives via traceability relationships.

5.6.3.1.1 MBAT Automotive Use-Case 1 scenario

Figure 70: Tools connected within the use case

In this use case, during the preparation of the test model, requirements are formalized within two MBAT

requirements tools the Pattern Editor [MODELSWARD, 2014] tool from OFFIS and an anonymized tool.

An example of a formalize d requirement is

{Req. 38} assume overvoltage’ guarantee state’=SAFE

Where variables used in the “assume” and “guarantee” statements have attributes indicating if a variable is

to be considered as input, output or internal.

When requirements are formalized in the considered requirements tools, they can be checked automatically

within these tools for consistency, diagnosis of the involved contracts, and traceability. After that, test cases

can be generated for SUT.

5.6.3.1.2 MBAT Automotive Use-Case 2 Scenarios

D601.022



V1.0 R 2015-04-30 156 of 230

Figure 71: Automotive use-case 2 scenarios for the combined T&A Pattern "MBT with analysis"

In this scenario, requirements are first available in natural language and then formalized or semi-formalized

in dedicated tools. The requirements are provided and consumed by OSLC adapters following the MBAT

IOS RM specification. In the resource type of IOS RM Requirement, the property specificationType specifies

whether the requirement is in natural language, formal or semi-formal. Conceptually this property can also be

assigned to requirements that are not directly provided via OSLC but refined internally in a tool. The IOS RM

Requirement extends the OSLC RM [OSLC-RM] Requirement and holds the requirement text, whether it is in

natural language or in a formal format dictated by a specific tool. No format of the formal Requirement text is

specified by the MBAT IOS, the used specification language can however be specified by name in a string

attribute.

Traceability of the requirements as well as the actual link between the requirements and components of the

model is an interface with the TWG Traceability Management. Note that by using separate resources for the

linking e.g. IOS TM Satisfy Link, the OSLC RM properties of the resource Requirement for relationships are

not used.

5.6.3.1.3 Open Issues / Suggestions

The usage of the IOS specifications in the use cases during the preparation of T&A models (as defined in the

patterns above) spotted a case where a small extension of the specification can be useful. Especially for

formal requirements one of the following may be of benefit when exchanging requirements:

1. Elements of contracts containing properties to mark them as input, output or internal.

2. Trace links to architecture elements of special kind with properties specifying how this architecture

elements are used in the contract formalization: as input, output or internal

This proposal was identified as a potential addition, currently not suggested for the change of the final IOS

specification, because there are only few examples of its usage in the considered scenarios. More thorough

analysis of the use cases and scenarios may reveal more potential usage within and outside the MBAT use

cases.

5.6.3.2 CRYSTAL Requirements CCC Methods

In CRYSTAL, the proposed formal requirements are applied within WP6.7 to address analysis question on the correctness, consistency, and the completeness of requirements. The full description of these analysis metrics can be found in the deliverable D_607_902.

D601.022



V1.0 R 2015-04-30 157 of 230

Examples of the consistency analysis are:

Hierarchical Property consistency

This analysis metric checks, if a property specified by a requirement is consistent w.r.t. to the decomposition of the components and the requirements of the sub-components. Such a property could be the maximum weight of a technical component, which can be checked against the actual or the specified upper bounds of the weights of the sub-components.

Interface consistency

This analysis uses information on the interconnection and interfaces of components, which are specified by requirement and ontological system models. It computes, if the current interface specification of the system model is consistent.

Completeness of assumption combinations

This completeness check analyses if all possible combinations of system modes are addressed by requirements. If a requirements addresses only a specific mode, there has to be at least one other requirement which covers the remaining modes.

5.6.4 Specification


This specification proposes an extension to the existing OSLC RM domain to support a contract-based approach, as well as, a new IOS domain Formal Requirements Management, which allows support of requirement patterns during a requirement formalization process. The goal is to have an IOS which allows the exchange of syntactical pattern definitions.

5.6.4.1.1 Contracts

Within the research project MBAT there has been a first effort to specify OSLC IOS extensions to the existing resource shapes defined in the OSLC_RM domain which are compliant to the engineering meta-models such as the MBAT MM, CESAR CMM or the SPEEDS HRC model. For the CRYSTAL IOS we propose an updated version of the artefacts used within the RM domain of the MBAT IOS.

The main issue we want to address within this proposal is the representation of a contract as an extension of the OSLC_RM requirement which is highly influenced by the original meta-model elements and not optimized for the usage as an OSLC extension. Figure 72 shows part of the MBAT meta-model for contracts. Specifically, a contract needs two additional separate resources (Assertions), the assumption and the promise resources.

Figure 72: MBAT meta model representation of a contract with an assumption and promises [MBAT MM,2014]

Within the MBAT IOS [MBAT IOS, 2014] the meta-model concept of an external Assertion has been translated into a separate resource shapes and a Contract has links to these artifacts. An OSLC_RM requirement specifies only a single resource shape which represents the requirement. The textual representation of such a requirement is stored within the description field of the resource. The MBAT IOS approach with Contracts and Assertions would not use the description field of the contract to store this

D601.022



V1.0 R 2015-04-30 158 of 230

information, but rather store this information in the description field of the promise Assertion. Therefore, is a pure OSLC_RM consumer would receive such a Contract it is not defined what is the content of the description field of the Contract. This would violate the aspect of having an interchangeable and backwards compatible format within the IOS to the original OSLC specifications.

Our main proposal is to specify a Contract as a Requirement (as defined in the MBAT IOS) with the exception that a text of a promise is not within a separate Assertion, but is integrated into the contract itself by using the “description” property of a standard OSLC_RM requirement. Likewise, the assumptions of a contract can be textually represented within the Contract itself. An assertion or any other resource may still be referenced by the contract to provide a more detailed description of the assumption/guarantees. Furthermore, there are other changes which will be discussed within the following sections.

5.6.4.1.2 Requirements and Contracts as Instances of Patterns

Our second proposal is a definition of an IOS to support a pattern-based requirement formalization process. Patterns are a means to formalize requirements by using structured text phrases which parameters. A pattern can be instantiated by filling its parameters with values of the correct type. A requirement which has been formalized with a pattern may be analysed by different formal analysis method. Such methods may check the correctness, the consistency, or the completeness of requirements.

Many different pattern languages and tools for the formalization process have been developed (e.g. RQS, BTC Embedded Specifier [BTC-ES Pattern, 2014], DODT [CESAR DODT, 2011] but there is no standardized format for the definition of patterns defined. Within the CRYSTAL IOS we want to establish at least a syntactical IOS format for interchanging pattern definitions. Even the name pattern is not uniformly used. One common related concept is a boilerplate, which references a kind of pattern which does not have a full formal semantic, but still applies to structural rules. These kinds of patterns are therefore called semi-formal. A pattern is addressing at least one category, such as functional, safety, timing or architectural, which defines the main application purpose of a pattern. As an example, a typical functional pattern defined in RSL [RSL, 2011], has the following structure:

Whenever P occurs Q holds during I.

,where P denotes an event, Q a condition and I a time interval. An instance of this pattern would be:

Whenever ButtonPressed occurs Doorbell==active holds during [5ms, 300ms].

The semantic of this pattern can be defined by using timed automata or LTL and requires that the engineer specifies the keywords and the parameters in the correct order and correctly substitute the parameters following their expected type. The proposed IOS for patterns should allow such ridged formal pattern specifications, but shall also allow to more flexible patterns which are closer to natural language. For instance, the aforementioned example could be formulated as:

Whenever a guest presses the button of the doorbell, the doorbell shall be active within the next 300ms starting after 5 milliseconds.

The processing of such a requirement to capture the semantics is much harder, because it requires the knowledge of the underlying ontological concepts as well as methods form the natural language processing area. Therefore, this version of the IOS will only address the syntactical aspect of patterns, by using an adapted version of EBNF grammatical rule specifications.

D601.022



V1.0 R 2015-04-30 159 of 230



Query Query Artifact Which component satisfies a requirement

-

Query Query Artifact Get the pattern definition which matches to a requirement

-

Query Query Artifact Get a list of potential matching patterns, given a requirement (pattern suggestion)

-

Query Query Artifact Retrieve ontological information of a term (term semantic and relationships)

-

5.6.4.3 IOS Data Models – IOS_RM

This IOS domain extents the base OSLC_RM domain and refines the MBAT_RM domain, by refining a contract. A contract is a requirement which states explicitly its assumptions on the environment (e.g. inputs) and its assertions (sometimes also called promise or guarantee) a component shall provide, if these assumptions are fulfilled. The refined version of a Contract as an extended OSLC_RM requirement is fully backwards compatible to a plain requirement in the sense that a plain requirement does not explicitly state its assumptions, but only its assertions. Therefore, the description field of a contract which is inherited from an OSLC_RM requirement is used to store the promise. This design is an improvement over the resource shape of a contract designed with in the MBAT_RM IOS specification, because the MBAT_RM requires the assertion of a contract to be an independent resource which is only lined to a requirement and does not specify the role of the original description field of the contract itself.

Following this design, the assumption is also no explicit resource and is modelled as part of the contract resource itself.


D601.022



V1.0 R 2015-04-30 160 of 230

5.6.4.3.1.1 Requirement

The semantic specification of a requirement follows the specification provided by the MBAT meta-model specification of a requirement:

“

A requirement for a system under development and for its parts specifies a capability or condition that must

(or should) be satisfied according to the SysML specification [SysML, 2012]. A requirement may specify a

function that a system must perform or a performance condition that a system must satisfy. Requirements

are used to establish a contract between the customer (or other stakeholder) and those responsible for

designing and implementing the system. Requirements can be described by using contracts in order to

specify intended characteristics for an assumed environment. During a development process requirements

are derived while refining the system architecture. Requirements are furthermore refined into more detailed

requirements. Standardized specification formalisms should be used in order to describe testable and

analyzable requirements. It is desirable to have one formal requirements specification language. Such an

approach has been followed in the SPEEDS project for speculative system design and refined in the CESAR

project for the formalization of requirements by using formalisms like boilerplates or the RSL [RSL, 2011].

Requirements can appear in the role of specification models usable for analysis or test activities as

described below.

“[MBAT IOS, 2014]

The structure of a requirement is updated by including optional “assertion” references. A requirement may link to a list of resources which describe the semantic of the required capability or condition in more detail, than the pure text of the “description“ property. For example an assertion of a requirement could be modeled with an explicit instance of a requirement pattern (see section 5.6.4.4) or a formula defining explicitly the required timing behavior (e.g. a TimingConstraint from the ARAMiS Meta Model). It is even possible to express the assertion by providing a reference to a picture which depicts a sequence diagram or a partial component model.

For compatibility with the OSLC_RM specification and for ease of data exchange, these linked assertions are not considered to be mandatory and a “description” text should always be provided. In case there is a pattern used for the requirement, the description could contain the serialized form of the requirement pattern, such that even if a consumer does not support a pattern based approach (or even the IOS), the requirement could still be communicated.

By using the description field together with the linked assertions, a certain kind of redundancy may be introduced. This can be avoided by automatic generation of the description text based on the assertion. Even on cases where this is not possible, the assertions are supplementary descriptions and the requirement has to be understandable without them. Further notice, that adding a formal assertion to a natural language requirement is not a substitution for a requirement formalization process.

5.6.4.3.1.2 Contract

A contract is proposed to be an extension of an IOS requirement, which allows specifying not only the assertion of a requirement, but also the assumptions which have to be fulfilled from the context in which the contract is allocated. The semantic definition is the same as within the MBAT Meta model:

“

A contract is a component-specification in terms of promised component characteristics, which must hold

provided that assumed characteristics of the component’s environment are fulfilled. Such a contract-based

specification therefore distinguishes between assumptions on the usage context of a component and

promised characteristics for the specified usage context. This is the basic principle of contract-based design

approach in the SPEEDS project and of the HRC meta-model specification [HRC, 2009]. The approach

D601.022



V1.0 R 2015-04-30 161 of 230

allows the definition of specifications in negotiations between OEMs and component suppliers. Typically in

the beginning of a development process informal requirements are defined. Assumptions are not necessarily

formulated because the system context is not yet explicitly known. When deriving requirements for parts of

the system, assumptions are typically elaborated more clearly. Contract-based component specifications can

be analyzed in a virtual integration test (VIT) or entailment analysis. As illustrated in the figure below, the

composition of interconnected component prototypes each having contract-based specifications is analyzed

in such a VIT on entailing or dominating a contract-based specification of a composed component.

“[MBAT IOS, 2014]

The structure of a contract also is updated compared to the MBAT model, by providing a textual description of the assumptions directly within the contract and allowing to link external resources as assumptions to the contract.


5.6.4.3.2.1 Resource Requirement

The Requirement concept is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.artemis.eu/ns/rm#Requirement MUST conform to the constraints and meaning of properties defined below and to those of http://open-services.net/ns/rm#Requirement. Notice that partial representations of a requirement resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: Requirement

Type URI: http://ios-artemis.eu/ns/rm#Requirement

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



Range Description


rdf:

type

zero-or-

many

unspe- cified

Resource Reference n/a The resource type URIs. If not addressed by the element name the rdf:type MUST at least include

http://ios.artemis.eu/ns/rm#Requirements and http://open-services.net/ns/rm#Requirement

dcterms:

description

zero-or-one

unspecified



SHOULD be used to specify

the textual representation of the requirements assertions.

(others: see http://open-services.net/ns/rm#Requirement)

Prefixed Name Occurs Read- Value-type Represent Range Description

http://ios.artemis.eu/ns/rm#Requirement


http://ios-artemis.eu/ns/rm#Requirement


http://ios.artemis.eu/ns/rm#Requirements

http://ios.artemis.eu/ns/rm#Requirements




D601.022



V1.0 R 2015-04-30 162 of 230

only ation

IOS RM: Additional properties and relationships

ios_rm:

specification Language

zero-or-one

False String n/a n/a The name of the requirement specification language used for the description of the requirement.

ios_rm:

assertion

zero-or-

many

False Resource Either any Resources which define the detailed assertions which define the promised characteristics of this requirement. For example, a PatternInstance or a timingconstraint.

ios_rm:

specificationType

exactly-one

False XMLLiteral n/a n/a The type of the requirement specification. SHOULD be

one of

Natural Language

Semiformal

Formal

ios_rm:


zero-or-one

False String n/a n/a The name of the requirement specification language used for the description of the requirement.



Range Description




Table 37 - IOS RM – Requirement Resource

5.6.4.3.2.2 Resource Contract

The Contract concept is represented in OSLC as follows. Any resource asserted to be of rdf:type http://ios.artemis.eu/ns/rm#Contract MUST conform to the constraints and meaning of properties defined below and to those of http://ios.artemis.eu/ns/rm#Requirement (and thereby http://open-services.net/ns/rm#Requirement). Notice that partial representations of a Property resource are admitted by this specification (for example, in query results, or where oslc.properties has been used), and such partial representations will in general not conform to these constraints.

Name: Contract

Type URI: http://ios.artemis.eu/ns/rm#Contract

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



Range Description


rdf:

type

zero-or-

many

unspe-

cified

Resource Reference n/a The resource type URIs. If not addressed by the element name the rdf:type MUST at least include http://ios.artemis.eu/ns/rm#Contra

ct and http://ios.artemis.eu/ns/rm#Requirement



http://ios.artemis.eu/ns/rm#Contract











D601.022



V1.0 R 2015-04-30 163 of 230



Range Description

IOS RM: Additional properties and relationships

Ios_rm:

assumptionDescription

zero-or-one

unspecified

XMLLiteral n/a n/a Descriptive text (reference: Dublin Core) about the assumptions represented as rich text in XHTML content. SHOULD include only content

that is valid and suitable inside an XHTML <div> element.

SHOULD be used to specify

the textual representation of the contracts assumptions.

Ios_rm:

assumption

zero-or-many

False Resource Either any Resources which define the detailed assertions which define the assumptions on the environment or context of this contract. For example, a PatternInstance or a timingconstraint.



Range Description




Table 38 - IOS RM – Contract Resource


The next version should verify that the proposed usage of textual descriptions for assertions and assumptions in combination with additional resources is compatible with the engineering practice.

5.6.4.4 IOS Data Models – IOS_FRM

The formal requirements management domain has a focus on supporting a pattern-based approach during requirement formalization with the goal to define a first IOS for the definition and exchange of requirement patterns and instances of these patterns.


D601.022



V1.0 R 2015-04-30 164 of 230


5.6.4.4.1.1 Pattern

The proposed IOS defines the syntactical structure of a requirement pattern; thereby a pattern is understood as a textural template consisting of static text elements and parameters, which has a specific, well-defined semantics. The pattern not only defines the grammatical rules to which requirement instances have to be compliant, but also the types of concepts, which can be used within the parameters.

“ Patterns consist of static text elements and attributes being filled in by the requirements engineer. Each pattern has a well-defined semantic in order to ensure a consistent interpretation of the written system specification across all project participants. On the one hand this limit the possibilities of writing a requirement on the other hand it prevents misunderstandings regarding the interpretation of the sentences. To gain a set of unambiguous requirements this limitation is necessary. However writing requirements shall still be possible in an intuitive way. Patterns allow the writing of natural sounding requirements with defined semantics while being expressive enough to formalize complex requirements. “[RSL, 2011]

A pattern provides standard OSLC properties, like a “title”, an “identifier”, or a “description” and defines a set of addition new properties. The most relevant property is the “syntax”. This property is a textual representation of the grammatical rule of the pattern. The property “syntaxType” specifies which language is used to define the grammar. For example EBNF is a standardized format for defining grammar rules, which may be used to define the syntactical rules of a pattern. But it is also possible to use other languages. For example, the functional “whenever” pattern of the RSL has the following grammar string:

“whenever”, P, “occurs”, Q, (“holds”|, “does”, “not”, “hold”), “within”, I

Words in quotes are terminal symbols which have to appear as keywords in instances of the pattern. The capitalized letters represent placeholders for parameters of the pattern.

A pattern must specify which parameter its supports independent of the used specification language. A parameter is a tuple consisting of an (locally) unique parameter identifier and an expected type. In the

D601.022



V1.0 R 2015-04-30 165 of 230

provided example, the parameters are P of type event, Q of type condition, and I of type time-interval. The

IOS does not limit the scope of supported types. Some common used parameter types are:

Functional

o Condition

o Event

o Real

o Integer

o String

Timing

o Time-Interval

o Time-bound

Safety

o Failure mode

o Cutset

Stochastic

o Rate

o Probability

System Ontological Concepts

o System

o Interface

o Connection

o Mode

o Activity

o Quantity

o Capability

o Actor

A parameter of a pattern may also be instantiated by using a pattern as a sub-pattern. Therefore, a pattern may specify its semantic type. For example the parameter P of type event could be instantiated with a sub-pattern of the same type, like:

S, “receives”, Q

, with the parameters S: System and Q: Quantity, such that the text of the sub-pattern is could be:

button receives press signal

5.6.4.4.1.2 Pattern Instance

A pattern instance describes an assertion or an assumption of a requirement by instantiation of the parameters of a pattern.

The type of pattern instantiated by the resource is determined by the patternType property. Since the syntactical structure may be instantiated in different ways according to its grammar specification, the PatternInstance has to define which concrete grammar instance is used. Therefore, the property syntaxInstance stores a string, which contains all keywords and all parameter names as they appear in this instance. For example, a syntaxInstance property of the functional pattern from section 5.6.4.4.1.1 could look like:

Whenever P occurs Q holds within I

, which represent the non-negated case of the pattern.

The pattern instance needs also to describe how the parameters of the patterns are instantiated. This can be done by either by using a ParameterValue resource or by using a sub-pattern instance.

D601.022



V1.0 R 2015-04-30 166 of 230

In both cases, the title property is used to specify, which parameter is instantiated by the resource. In case of a ParamterValue, the value of the parameter is specified by the property ios_frm:value. If the parameter is instantiated by a sub-pattern, a pattern-instance of this sub-pattern is referenced.


Name: RequirementPattern

Type URI: http://ios-artemis.eu/ns/frm#RequirementPattern



Range Description


rdf:

type

zero-or-

many

unspe- cified


http://ios.artemis.eu/ns/rm#RequirementsPattern

dcterms:

title

Exactly-one

Unspecified


that is valid inside an XHTML <span> element.

dcterms:

description

zero-or-one

unspecified



dcterms:

Identifier

Zero-or-many

True String n/a n/a An identifier for a resource. This identifier may be unique with a scope that is defined by the FRM provider. Assigned by the service provider when a resource is created. Not intended for end-user display.

dcterms:

creator

Zero-or-many

Unspecified

Resource or Local Resource

Either Reference or inline

Any Creator(s) of resource (reference: Dublin Core). It is likely that the target resource will be an foaf:Person but that is not necessarily the case.

dcterms:

Contributor

Zero-or-many

Unspecified


Either Reference or Inline

Any Contributor(s) to resource (reference: Dublin Core). It is likely that the target resource will be an foaf:Person but that is not necessarily the case.

dcterms:

created

zero-or-

one


dcterms:

modified

zero-or-

one




Range Description

http://ios-artemis.eu/ns/frm#RequirementPattern



D601.022



V1.0 R 2015-04-30 167 of 230

IOS FRM: Additional properties and relationships

ios_frm:


Exactly-one

Unspecified

String n/a n/a The name of the requirement specification language to which this pattern belongs to.

Ios_frm:

category

one-or-

many

Unspecified

String n/a n/a Classification of the pattern. For example “functional”, “safety”

Ios_frm:

Syntax

Exactly-one

Unspecified

String n/a n/a Description of the syntactical structure of the pattern as a String in the language specified in ios_frm:syntaxType

Ios_frm:syntaxType

Exactly-one

Unspecified

String n/a n/a Definition of the grammar language used by this pattern. For example, “EBNF”, “Keyword-parameter list”

Ios_frm:parameter

One-or-many

Unspecified


Inline Ios_frm:requirementPatternParameter

This property contains the list of parameters which are used to instantiate this pattern. The names of the parameters are unique within the scope of the pattern. The parameter resources SHOULD be stored inline with the pattern resource (e.g. as key-value-pairs).

Ios_frm:subPatternType

Zero-or-one

Unspecified

String n/a n/a If specified, an instance of this pattern MAY be used as a sub-pattern to instantiate a parameter of type ios_frm:subPattern. For example: If the subPatternType is set to “condition”, the pattern may be used whenever a parameter of type “condition” is expected.

If this property is not specified, the pattern SHOULD not be used as a sub-pattern.

Table 39 - IOS FRM – Requirement Pattern Resource

Name: PatternParameter

Type URI: http://ios-artemis.eu/ns/frm#PatternParameter



Range Description


rdf:

type

zero-or-

many

unspe- cified


http://ios.artemis.eu/ns/rm#PatternParameter

Oslc:name Exactly-one

Unspecified

String n/a n/a The name of the parameter instance

dcterms: zero-or-one

unspecified

XMLLiteral n/a n/a Descriptive text (reference: Dublin Core) about resource

http://ios-artemis.eu/ns/frm#RequirementPatternParameter



D601.022



V1.0 R 2015-04-30 168 of 230

description represented as rich text in XHTML content. SHOULD




Range Description


ios_frm:

parameterType

One-or-many

Unspecified

String n/a n/a This property specifies the expected types of parameter. A parameter instantiating this parameterType MUST conform to at least one of the listed parameter types.

Table 40 - IOS FRM –Pattern Parameter Resource

Name: ParameterInstance

Type URI: http://ios-artemis.eu/ns/frm#ParameterInstance



Range Description


rdf:

type

zero-or-

many

unspe- cified


http://ios.artemis.eu/ns/frm#ParameterInstance

Oslc:name Exactly-one

Unspecified

String n/a n/a The name of the parameter instance



Range Description


ios_frm:

value

Exactly-one

Unspecified

Unspecified

n/a n/a The value of the parameter. The value may be an RDF literal or a resource. If the value is an RDF literal, then it SHOULD be an RDF string

literal, in case it is a resource, it should be of type ios_frm:PatternInstance.

ios_frm:

parameterType

One-or-many

Unspecified

String n/a n/a This property specifies the provided types of the parameter. A parameter using this value MUST conform to at

least one of the listed parameter types.

Table 41 - IOS FRM –Pattern Instance Resource

Name: PatternInstance

Type URI: http://ios-artemis.eu/ns/frm#PatternInstance

http://ios-artemis.eu/ns/frm#ParameterInstance



http://ios-artemis.eu/ns/frm#PatternInstance

D601.022



V1.0 R 2015-04-30 169 of 230



Range Description


rdf:

type

zero-or-

many

unspe- cified


http://ios.artemis.eu/ns/frm#PatternInstance

dcterms:

title

Exactly-one

Unspecified


that is valid inside an XHTML <span> element.

dcterms:

Identifier

Zero-or-many

True String n/a n/a An identifier for a resource. This identifier may be unique with a scope that is defined by the FRM provider. Assigned by the service provider when a resource is created. Not intended for end-user display.



Range Description


ios_frm:

patternType

Exactly-one

Unspecified

Resource Reference RequirementPattern

This property specifies the type of pattern used for this pattern instance.

Ios_frm:

SyntaxInstance

Exactly-one

Unspecified

String n/a n/a Specifies exactly the syntax variation used within this instance of the patternType. The syntax contains all used keywords and the parameter placeholders, s.t. it matches the grammar defined by the syntax of the pattern.

Ios_frm:

parameterInstance

Zero-or-many

Unspecified

Resource Either Reference or inline

PatternInstance or ParameterValue

Specifies the actual instantiation of the parameters of the pattern. This is either another pattern as sub-pattern (PatternInstance) or a ParameterValue

Table 42 - IOS FRM –Pattern Instance Resource


The proposed IOS for patterns does not address the semantic of a pattern and only defines the syntactical structure. It is unclear if an IOS for the semantics of a pattern should be defined or if such a model is too specific (e.g. should the IOS define how LTL formulas or timed automata have to be represented)?



D601.022



V1.0 R 2015-04-30 170 of 230

5.7 Safety Management OFFIS


Full Name

Wilke Trei

Affiliation

OFFIS

e-mail [email protected]

Phone +49 441 9722-504

5.7.2 Context


One of the central requirements for each development process is to keep track of unexpected behaviour of the system under test and its environment as well as tracking the impact on the user and the systems environment.

The safety management IOS objects proposed in this chapter addresses this requirement and provides IOS extensions for defining and sharing reasoning of component failures and their environmental impact.

Beside IOS objects itself we additionally provide an alignment of the concepts defined in the safety related norms [ARP4754a] and [ISO26262] to the resource shape in order to proof that norm compliant development processes are supported by the proposed IOS objects.

In order to represent the relationships between the resources, this chapter introduces two different

notations in addition to the ones offered by the graphics template provided for the IOS:

The first one denotes inheritance between resource types using a special kind of arrow. As an

example this relationship Figure 66: Traceability Management – Allocate Link shows a possible

refinement of the component resource type into the resource type Actor which inherits the

properties and the relationships of the component resource type.

The second one denotes special relationship objects expressed in a different way than as

references between the related resources. These relationship objects will be shown in an orange

color in order to denote these objects. An example is shown in Figure 59: Traceability

Management – Overview.


[ARP4754a] Aerospace Recommended Practice, ARP4754, SAE Aerospace, Revision A, December

2010

[ISO26262] Road Vehicles – Automotive Safety, ISO26262, 2011

[MBAT, 2015] MBAT Project, Combined Model-based Analysis and Testing of Embedded Systems ,

http://mbat-artemis.eu/home/

[MBAT MM,

2014]

MBAT D_WP3.1_3; “Meta-Model for RTP 2.0”

[MODELSWARD,

2014]

Creating a reference technology platform: Performing model-based safety analysis in a

heterogeneous development environment. In MODELSWARDS 2014, second

International Conference on model-driven engineering and software development


D601.022



V1.0 R 2015-04-30 171 of 230





5.7.3.1 Model Based Safety Analysis

The proposed IOS objects allow the analysis as described in [MODELSWARD, 2014]. In the paper it is described that for a component in the functional perspective functional models are generated that allow the simulation of the component. In this setting one now can add models simulating faults on parts of the component model. Common choices are random values at ports or port stuck at their old value. The purpose of the engineering method is now to simulate the functional model of the component with insertion of fault models and check for top level safety requirements promises have been broken by the faults. The results can be stored using e.g. fault trees or more complex relations describing the procedure. Furthermore it should be possible to add fault detection mechanisms preventing the component to fail and to rerun the analysis with them. The goal in component design should be preventing single points of failures. The proposed IOS objects with their links and purposes are designed to support this process.

5.7.4 Specification


This specification proposes an extension to the existing OSLC RM domain to support the description and analysis of unintended or unexpected behaviour of the system under test as well as failure preventing mechanisms.

This specification is the result of a consolidation work done on the MBAT meta-model [MBAT, 2015] in order to converge towards an IOS specification which is as minimal as possible and necessary for norm compliant development.

We will start in section 5.7.4.3.1 with the description of the objects required for safety management, while the OSLC resource shapes will be described in section 5.7.4.3.2.



Query Provide IOS Objects for Model Based Safety Analysis

Create IOS Objects representing faults, failures and causing relations in order to allow model bases safety analysis.

-

Query Perspectives for MBSA Create IOS Objects of different perspectives in order to perform MBSA on non-functional level.

-

Query Hazard and Safety Management

Create IOS Objects that allow management of Hazards, their Classification and the resulting top level requirements.

-


D601.022



V1.0 R 2015-04-30 172 of 230

5.7.4.3 IOS Data Models – Safety Management


The graphic below gives an overview about the objects introduced in this section as well as their most important connections in between and to other domains.

5.7.4.3.1.1 Resource Hazard

A hazard is potentially unsafe condition resulting from failures, external events, or combinations thereof.

Figure 73: Safety Management - Hazard

D601.022



V1.0 R 2015-04-30 173 of 230

The definition of a hazard includes a link “system” to a component in the functional perspective that represents the typical system in which the component under development will be integrated in. The system may consist of arbitrarily many sub-components in the functional perspective, whose functions are related to the component under development or whose functions or the absence of a function is related with any hazard.

With respect to the system a hazard is defined for, a hazard is linked to a description of the hazard, which does not have to be of any specific form. This description should be free of any assumptions of the currently used operational scenario the system is in.

Furthermore each hazard is linked to a component in the functional perspective representing an operational situation in which the hazard appears. The distinction between the misbehaviour itself and the situation in which the misbehaviour occurs eases reusing scenarios as well as assists in considering all possible combinations and thus leads to simpler verifiable completeness of the considered combinations.

A hazard furthermore may be linked to a classification that rates the hazard in terms of its impact for the environment and the user of the system. Note that for most norms regarding safety the classification is mandatory and a fixed procedure is given to yield a classification. Examples are the ASIL classes of ISO26262 [ISO26262] or IDAL in ARP 4754a [ARP4754a].

It is usual to derive one or many special top level requirements “safety goal” from a hazard, that are usually of functional perspective. In order to be able to track back the derivation of a requirement from a hazard we use the “Derive Relation” from the traceability management domain. This way each derived requirement inherits the most relevant classification of the hazards it is derived of or of which it is refined of in case of requirements refined with arbitrarily many stages in between from a safety goal.

5.7.4.3.1.2 Resource Failure

A failure is a concept indicating the deviation from the required functionality provided by a component. Thus a failure denotes the breach of the promise of a requirement regarding a component while the assumptions of the requirement are still valid.

As depicted below the central object failure is linked to the broken safety requirement and the component it affects.

A failure can be caused by one or many faults. Since this causality may be complex we use a special kind of relationship defined by a Causing Relation.

A failure inherits the abstraction level and perspective from the component it enters or the requirement it violates. Thus a failure itself can be functional or technical nature.

Figure 74: Safety Management – Failure

D601.022



V1.0 R 2015-04-30 174 of 230

5.7.4.3.1.3 Resource Fault

A fault is an abnormal condition that can cause a component or function to fail.

Technically a fault can be thread as misbehaviour of parts, e.g. sub-components, of a component in terms of their inherited requirements or specification in case of atomic parts. Therefore we inherit the resource fault from failure.

The manner in which a fault appears, i.e. the observable divergence of sub-components behaviour at its output from its intended behaviour, can be implemented using so called failure modes, which is a component describing the divergence. This implementation can be used for automatically testing the causality of faults on failures.

As it is for failures, faults are subsect to different perspectives and abstraction levels. The linked implementation should match the perspective and abstraction level.

5.7.4.3.1.4 Resource Causing Relation

A causing relation is an object that defines the relation between one or many faults causing a single failure.

Beside the linkage to the involved faults and failures a resource is expected which defines the manner in which the faults cause the failure. Examples for this manner could be cut-sets or cut-sequences that are classical concepts in the safety domain. The concept can easily extend to other domains, for example in form of attack graphs in the security domain.

5.7.4.3.1.5 Resource Safety Mechanism

A Safety Mechanism is a special kind of component denoting the definition of a function or an implementation to detect faults and to mitigate failures as depicted below.

As given in the definition a safety mechanism is subject to a certain perspective defining the kind of safety component the mechanism is.

Furthermore a safety mechanism can itself be part of a component as depicted. In this case the safety mechanism is to be related with its parent component by using a realize link from the traceability management domain, since the safety mechanism is part of the more failure resistant realization of the components purpose.


5.7.4.3.2.1 Resource Hazard

Name: Hazard

Type URI: http://ios.metamodel.mbat-artemis.eu/sm#Hazard




Range Description

http://ios.metamodel.mbat-artemis.eu/sm%23Hazard


D601.022



V1.0 R 2015-04-30 175 of 230


rdf:

type

zero-or-

many

unspe- cified


http://ios.metamodel.mbat-artemis.eu/sm#Hazard




Range Description


Mbat_mm_ios_sm:

hazard_description

exactly-one

False String n/a n/a A description of the unintended system behavior, independent of the operational situation.

Mbat_mm_ios_sm:

context_description

exactly-one

False String n/a n/a A description of the operational context the hazard is related to

Mbat_mm_ios_sm:

class_description

zero-or-one

False String n/a n/a A description of the classification of the hazard, if any

Mbat_mm_ios_sm:

system

exactly-one


Component

The component that defines the system that is affected by the hazard

Mbat_mm_ios_sm:

operational_context

exactly-one


Component

The component that defines the exact operational context the hazard may appear in

Mbat_mm_ios_sm:

classification

zero-or-one

False Resource Reference any A resource describing the classification of the hazard

Mbat_mm_ios_sm:

Safety_goal

zero-or-many

False Resource Reference Mbat_mm_ios_tm:

DeriveLink

References to all linking objects that describe top level requirements derived from this Hazard



Range Description




Table 43: IOS FM – Hazard Resource

5.7.4.3.2.2 Resource Failure

Name: Failure

Type URI: http://ios.metamodel.mbat-artemis.eu/sm#Failure




Range Description


rdf:

type

zero-or-

many

unspe- cified

Resource Reference n/a The resource type URIs. If not addressed by the element name the rdf:type





http://ios.metamodel.mbat-artemis.eu/sm%23Failure

http://open-services.net/ns/am%23Resource

D601.022



V1.0 R 2015-04-30 176 of 230

MUST at least include

http://ios.metamodel.mbat-artemis.eu/sm#Failure




Range Description


Mbat_mm_ios_sm:

requirement

exactly-one

False Resource Reference Mbat_mm_ios_rm:

Requirement

The requirement of which its promise is broken by the failure

Mbat_mm_ios_sm:

component

exactly-one


Component

The component that the failure belongs to

Mbat_mm_ios_sm:

safety_mechanism

zero-or-one


Component

A safety mechanism component that is able to mitigate the failure

Mbat_mm_ios_sm:

causes

zero-or-many

False Resource Reference Mbat_mm_ios_sm:

CausesRelation

One or many causes relations that describe probable causes of the failure.

Mbat_mm_ios_sm:

is_subject_to

zero-or-many


Perspective,

Mbat_mm_ios_am:

AbstractionLevel

The failure can be subject to different abstraction levels and perspectives



Range Description




Table 44: IOS FM – Failure Resource

5.7.4.3.2.3 Resource Fault

Name: Failure

Type URI: http://ios.metamodel.mbat-artemis.eu/sm#Fault

Base Type URI: http://ios.metamodel.mbat-artemis.eu/sm#Failure



Range Description


rdf:

type

zero-or-

many

unspe- cified


http://ios.metamodel.mbat-artemis.eu/sm#Fault





http://ios.metamodel.mbat-artemis.eu/sm%23Fault




D601.022



V1.0 R 2015-04-30 177 of 230

(others: see http://ios.metamodel.mbat-artemis.eu/sm#Failure)



Range Description


Mbat_mm_ios_sm:

failure_mode

zero-or-one


Component

A component implementing the manner in which the fault appears. Will be used as model of the fault for automatic analysis

Mbat_mm_ios_sm:

is_part_of

zero-or-many


CausesRelation

One or many causes relations the fault appears in

Mbat_mm_ios_sm:

Detecting_safety_mechanism

zero-or-many


Component

An arbitrarily large set of safety mechanism components that is able to detect the fault

Mbat_mm_ios_sm:

error

zero-or-many

False Resource Reference any If the failure is subject to several errors, these can be linked here



Range Description



(others: see http://ios.metamodel.mbat-artemis.eu/sm#Failure)

Table 45: IOS FM – Fault Resource

5.7.4.3.2.4 Resource Cause Relation

Name: Failure

Type URI: http://ios.metamodel.mbat-artemis.eu/sm#CauseRelation




Range Description


rdf:

type

zero-or-

many

unspe- cified


http://ios.metamodel.mbat-artemis.eu/sm#CauseRelation




http://ios.metamodel.mbat-artemis.eu/sm%23CauseRelation

http://open-services.net/ns/am%23Resource




D601.022



V1.0 R 2015-04-30 178 of 230



Range Description


Mbat_mm_ios_sm:

failure

exactly

-one


Failure

The failure that is caused

Mbat_mm_ios_sm:

fault

one-or-many


Fault

One or many faults, that are part of the failure causing

Mbat_mm_ios_sm:

definition

exactly

-one

False Resource Reference any A resource that gives the definition of the causing implication



Range Description




Table 46: IOS FM – Cause Relation Resource

5.7.4.3.2.5 Resource Safety Mechanism

Name: SafetyMechanism

Type URI: http://ios.metamodel.mbat-artemis.eu/sm#SafetyMechnism

Base Type URI: http://ios.metamodel.mbat-artemis.eu/am#Component



Range Description


rdf:

type

zero-or-

many

unspe- cified


http://ios.metamodel.mbat-artemis.eu/sm#CauseRelation

(others: see http://ios.metamodel.mbat-artemis.eu/am#Component)



Range Description


Mbat_mm_ios_sm:

failure

exactly

-one


Failure

The failure that is mitigated

Mbat_mm_ios_sm:

fault

one-or-many


Fault

One or many faults, that are detectable by the safety mechanism

Mbat_mm_ios_sm:

definition

exactly

-one

False Resource Reference any A resource that describes the way of detection and mitigation. Note that functional models or implementations of the safety mechanism will be given as realization, since


http://ios.metamodel.mbat-artemis.eu/sm%23SafetyMechnism

http://ios.metamodel.mbat-artemis.eu/am%23Component




D601.022



V1.0 R 2015-04-30 179 of 230

safety mechanisms are components.



Range Description



(others: see http://ios.metamodel.mbat-artemis.eu/am#Component)

Table 47: IOS FM – Safety Mecanism Resource


In the following section we show how the proposed objects can be used in a way such that every MBAT [MBAT, 2015] use case should be realizable. Therefore we also have strong evidence that the used objects fulfil the requirements on engineering processes stated in ISO26262 [ISO26262] or in ARP 4754a [ARP4754a], but a detailed verification is yet to be done.


The following lines will give an introduction on how to use the proposed IOS objects for users that had previously worked with other terminologies. The sections headlines are given in a way that they represent the concept of the old terminology, while the corresponding text describes how the realization is done using our proposed IOS objects. Therefore concepts proposed in this document are written using bold letters, while any external terminology is written in italics.

5.7.5.1 MBAT Objects

The proposed IOS objects are derived from the MBAT meta-model [MBAT MM, 2014] for architecture management in the safety viewpoint.

5.7.5.1.1 Hazard / Hazardous Event / Operational Situation and Item / Safety Goal

The concept of a Hazard as proposed in this document is a replacement for Hazardous Event in the terminology of MBAT. The corresponding Hazard as well as the Operational Situation are given by linked Objects of a Hazard. The operational situation was renamed to operation context. Since these objects themselves can be given as models or more or less formal descriptions, we consider them to be Components or other Resources.

The same applies for Item, which is of Type Component in our proposed Resource suggestions.

As for Safety Goals we consider them as usual Requirements, which can be distinguished from normal Requirements, since they are directly derived from a Hazard.

5.7.5.1.2 Cut-Set, Error, Failure, Fault and Safety Mechanism

The concepts Fault, Failure and Safety Mechanism of the MBAT meta-model can realized with the proposed IOS objects with the same named objects. The concept of a cut-set can be realized using the more versatile causing relation. The concept of an error as own object was dropped, but errors that become visible as failures can be linked to the failure.


D601.022



V1.0 R 2015-04-30 180 of 230

5.8 Verify Test Coverage


Peter Tummeltshammer, Thales Austria , [email protected]

Technical Contributions by:

The whole RTP team in several phone calls.

5.8.2 Context


This chapter describes the generalized engineering method of “test to requirements coverage”, which describes the linking process between requirements and test results. The gEM is built upon existing engineering methods found in the CRYSTAL SharePoint.


OSLC specifications: www.open-services.net


This gEM used the following CRYSTAL engineering methods as an input:

Engineering Method Description

UC203 Create Verification Case

The verification case and traceability to verification objective and requirement will be created.

UC203 Create Verification Objective

The verification objective and traceability to the selected requirement will be established.

UC203 Create Verification Procedure

The verification procedure steps and traceability to verification case and requirement will be created. The verify links of the procedure will replace the links of the verification case. The ones from the verification case will be deleted.

UC301 TestCaseGeneration

Provide test cases from requirements model for component or system testing

UC303 DVP Generation Test Engineer to generate Design Verification Plan based on defined test environment, requirements, test methods etc.

UC303 semi-automated requirements tracing

Using the requirements to ensure no loss of context through the requirements traceability

UC401 Verify Requirement

Provide a clear and condensed overview of applicable requirements, associated tests, the outcome of the tests, and - derived from this - the engineering status of a work product.

UC405 RequirementsTraceability

UC406 Requirement Traceability 004

UC406 Validation Plan Definition

Definition of the validation plan and the requirements for the tools needed for the execution of such a plan

UC502 ModelBasedTesting

Automatically generate tests from a model and achieve a linking between Model Elements and requirements as well as tests and requirements.

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

D601.022



V1.0 R 2015-04-30 181 of 230

Many of the use cases deal with linking requirements to model elements as well. This requires the introduction of linking between model elements, requirement and tests. Furthermore, automated test case generation as used in UC 501 and UC 502 can benefit from automation interfaces, which can trigger and monitor a process in another tool.

This gEM is also closely related to change impact analysis as given in the configuration management gEM as the user needs to be informed about changes to elements in requirements/model elements/test cases/test results. Consistent versioning must be ensured across the linked elements.

The table below shows the required IOS domains/services for the given classes of engineering methods. This can be used as an input for introducing additions to IOS which enable the gEM of “test to requirements coverage”. Domains which are missing in the current version of IOS (v1.0) are highlighted red.

Class of Engineering methods

IOS domains

IOS services

IOS service details Description

Filter requirements for set of tests

requirement management

basic-query/DUI-picker

http://open-services.net/ns/rm#RequirementCollection query

Given a set of tests all linked requirements shall be displayed

Filter requirements for related features


basic-query/DUI-picker


Given a set of features all linked requirements shall be displayed

Test plan definition


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

Define the tests to verify a requirement

Test fail check requirement management

Query http://open-services.net/ns/rm#RequirementCollection query

Verify the affected requirements from failed tests

Test coverage check


Query http://open-services.net/ns/qm#TestCase query

Verify test coverage of requirements

Modify test plan quality management

Edit http://open-services.net/ns/qm#TestPlan Update

Modification of the current test plan

Release test plan

Missing domain: document management

Missing service: generation factory

OSLC: DocM: Release A document is generated from the test plan

Notification on changed requirements


Query http://open-services.net/ns/rm#RequirementCollection query

The user is informed on any updated requirements from a given list

Link architectural artefacts to requirements


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

For full tracability in automated testcase generation architectural elements like e.g. model elements must be linked to requirements

Generate test cases from model

quality management

Create http://open-services.net/ns/qm#TestCase create

The test case generation can be started automatically from the V&V management tool









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







http://open-services.net/ns/qm#TestCase query



http://open-services.net/ns/qm#TestPlan Update










http://open-services.net/ns/qm#TestCase create



D601.022



V1.0 R 2015-04-30 182 of 230

Text in red is missing OSLC domain or service.

D601.022



V1.0 R 2015-04-30 183 of 230

5.9 Draft proposal on EAST-ADL/AUTOSAR for IOS


Cecilia Ekelin, Volvo, [email protected]

Christian Ekholm, Volvo, [email protected]

5.9.2 Context


EAST-ADL and AUTOSAR are two standards devised particularly for information modelling within the automotive industry. AUTOSAR is commonly used and covers information related to the implementation of automotive software e.g. software components, topology, communication and operating system. EAST-ADL is so far not widely adopted but complements AUTOSAR by focusing on information on the higher levels e.g. features, functions, design components and interfaces. Both AUTOSAR and EAST-ADL provide tool independent representations of the information model and tool interoperability is addressed through import and export of XML-files. Thus, each tool in a tool chain is expected to import a (partial) XML-file, add some information to the model and then export a more complete file. The benefit of this approach is that the tools in the chain are independent and need not be aware of each other. The drawback is that all tools in principle need to implement the entire standard (and in the same way) in order not to lose (corrupt) information during import/export.

Due to that EAST-ADL, AUTOSAR and their file-based information exchange is predominant in the automotive industry, this is also visible in the automotive use cases in CRYSTAL and especially in use case 3.1. In timing analysis of a system both EAST-ADL and AUTOSAR formats are used to provide the timing information necessary for an analysis tool. The AUTOSAR format is also used throughout definition of software architecture, network design, behavioural modelling and platform configuration in order to obtain software executing on the target system. To support a work flow relying on EAST-ADL, AUTOSAR and file-based information exchange in the context of IOS and OSLC we have pursued two approaches:

1) Extension of EAST-ADL and AUTOSAR XML-formats with information on OSLC links.

2) Automatic generation of OSLC resource shapes and provider classes for EAST-ADL and AUTOSAR based on their meta-models.

Both approaches are currently being implemented and we have not yet any conclusive evidence that the approaches are valid. In the next release of the IOS specification we expect to have more concrete results.


The AUTOSAR specification and meta-model can be found at www.autosar.org. The EAST-ADL specification and meta-model can be found at www.east-adl.info. Information about the OSLC Service Provider Generator can be found at: http://wiki.eclipse.org/Lyo/AdaptorCodeGeneratorWorkshop.


The concepts are proposed in order to address needs detected in use case 3.1. However, since the needs stem to the typical application of EAST-ADL and AUTOSAR, the applicability of the concepts is not limited to use case 3.1 but their purpose is to provide a generic solution on how to facilitate the use of EAST-ADL and AUTOSAR in an OSLC context. The concepts also represent a roadmap towards a stepwise OSLC introduction since it is unlikely that the current tools would replace the existing interoperability solutions in a single step.



http://www.autosar.org/

http://www.east-adl.info/

http://wiki.eclipse.org/Lyo/AdaptorCodeGeneratorWorkshop

D601.022



V1.0 R 2015-04-30 184 of 230

5.9.3.1 Concept A: OSLC links in file exchange

Supported engineering methods: Create AUTOSAR interface contract, Design AUTOSAR SW application architecture AUTOSAR ECU integration – extract

Figure 75 represents a work flow from UC3.1 combining XML-file exchange with OSLC links. In this work flow a software architecture consisting of software component compositions (SWCC) is expected to be defined in a design tool (SystemWeaver) based on design components (DC). As part of this activity it is expected that links are being established between the software component compositions and the design components in the design tool. When exporting the software architecture, the links should also be exported in order to avoid the need to manually recreate the links in the AUTOSAR tool (ExtractBuilder). At import, the AUTOSAR tools can instead automatically recreate the links and also create links to other related resources such as requirements linked to the design components.

So far the concept is only applied in the engineering methods mentioned above but it could potentially be used in other engineering methods of UC3.1 utilizing file exchange if the proposed concept is successfully validated.

Figure 75: File-based work flow including OSLC links

D601.022



V1.0 R 2015-04-30 185 of 230

5.9.3.2 Concept B: Automatic generation of OSLC provider for EAST-ADL

Supported engineering methods: Timing analysis

Figure 76 represents a work flow utilizing EAST-ADL as a basis for information exchange. In order to perform timing analysis, the information needed e.g. design components, topology, timing requirements, need to be made available in the timing analysis tool (Rubus Analyzer) from the design tool (SystemWeaver). The traditional way to approach this is to 1) translate information in the design tool to EAST-ADL, 2) export/import the information as an EAXML-file, 3) translate the EAST-ADL information into the analysis tool. The same procedure then has to be reversed in order to update the design tool with the analysis results or additional annotations made. A potentially smoother way to exchange the information is through OSLC as this would enable exchange at a finer granularity and remove the necessity of files. The proposed concept therefore consist of automatically generating OSLC resource shapes and provider classes for EAST-ADL elements based on its meta-model which is available in EMF. Once the resource shapes and classes are available it should be possible not only to exchange complete EAST-ADL models through OSLC but also to provide e.g. linking of arbitrary EAST-ADL elements.

5.9.3.3 Concept C: Automatic generation of OSLC provider for AUTOSAR

Supported engineering methods: Create AUTOSAR interface contract, Network design, Design AUTOSAR SW application architecture, Generate SW components, Consume AR interface contract, AUTOSAR ECU integration – extract, Timing analysis

This concept is essentially the same as concept B since the only difference is the targeted meta-model. A practical difference is that the AUTOSAR meta-model is considerably larger than EAST-ADL but since the meta-meta model is the same for both EAST-ADL and AUTOSAR the automatic generation should be rather straight-forward once the EAST-ADL generation approach is finalized. Another difference is that AUTOSAR is more commonly used which would potentially imply a high community interest in the resulting OSLC provider.

Figure 76: EAST-ADL based timing analysis

D601.022



V1.0 R 2015-04-30 186 of 230

5.9.4 Specification


The proposed concept A represents a bridge between the interoperability solution adopted by AUTOSAR and OSLC interoperability. Concepts B and C represents introducing EAST-ADL and AUTOSAR as two new OSLC domains. From a technology roadmap perspective, concept A represents a solution relevant for introduction in the short-term while the full adoption of concepts B and C represent a long-term solution.



EAST-ADL Manage EAST-ADL artefacts

Create, read, update, delete and link EAST-ADL elements

UC3.1

AUTOSAR Manage AUTOSAR artefacts

Create, read, update, delete and link AUTOSAR elements

UC3.1

5.9.4.3 IOS Data Models – EAST-ADL

5.9.4.3.1 Overview of the EAST-ADL Resources

EAST-ADL specifies engineering information at higher abstraction levels and covers vehicle features, functional architecture and hardware architecture. It also allows specification of information that crosscuts through abstraction levels such as requirements, timing, safety and variability. The meta-model defining the elements can be found here: www.east-adl.info.

http://www.east-adl.info/

D601.022



V1.0 R 2015-04-30 187 of 230

5.9.4.3.2 Detailed EAST-ADL Resource Properties

Figure 77: EAST ADL class diagram excerpt

In figure 1-3 part of the EAST ADL meta model is shown. Each meta class will be translated to an OSLC resource and each attribute and association will be translated to OSLC properties. For example the metaclass EAElement will have the following OSLC properties:

Name Value type Cardinality Comment

name String Zero-or-one

ownedComment Resource Zero-or-one

category Resource Zero-or-one Inherited from Identifiable. The EAST-ADL type is “Identifier” which is a string with some restrictions placed upon it. How to best handle this is still to be determined.

uuid String Zero-or-one Inherited from Identifiable

shortName Resource Exactly-one Inherited from Referrable. The EAST-ADL type is “Identifier” which is a string with some restrictions placed upon it. How to best handle this is still to be determined.

The generation of resources are made programmatically by traversing the ECORE representation of the EAST-ADL meta model to produce an XMI-file that the OSLC Provider Generator can use to generate

D601.022



V1.0 R 2015-04-30 188 of 230

resource shapes and Java classes, see Figure 1-4 and Figure 1-5. There are about 250 meta classes in the EAST ADL model that will become OSLC resources.

The presented contribution has been provided by task WP6.5.2 and a more detailed description of the approach can be found in deliverable D605.902 “Specification, Development and Assessment Report V2”.


The process of transforming EAST-ADL Meta classes to OSLC resources are work in progress and work has to be performed to verify that the resulting OSLC resources contain all needed information.

5.9.4.4 IOS Data Models – AUTOSAR

5.9.4.4.1 Overview of the AUTOSAR Resources

AUTOSAR specifies engineering information at the implementation level and covers software, runtime environment and hardware architecture. Similar to EAST-ADL, AUTOSAR also contains extensions to handle additional information regarding timing and safety. The meta-model defining the elements can be found here: www.autosar.org.

5.9.4.4.2 Detailed AUTOSAR Resource Properties

The AUTOSAR resources and resource properties will be handled analogous as for EAST ADL. All Meta classes will be transformed to resources with corresponding properties.

EAST-ADL ECORE Metamodel

EAST-ADL XMIGenerator

XMI-file

Resources

Resource Properties

Figure 5-63 Traversing the EAST ADL ECORE meta model to produce an XMI file describing the resources and their properties

OSLC Lyo Service Provider Generator

EAST-ADL OSLC Service Provider (incl

resource shapes)

XMI-file

Resources

Resource Properties

Figure 79: Generating an OSLC Service Provider including resource shapes

http://www.autosar.org/

D601.022



V1.0 R 2015-04-30 189 of 230

5.10 Functional Mockup Units for Co-Simulation



Technical Contributions by:


Sytze Kalisvaart TNO [email protected]

Tom van den Berg TNO [email protected]

Andrea Leitner VIF [email protected]

Christian El Salloum AVL [email protected]


Rubén de Juan Marín ITI [email protected]

Andreas Mitschke EADS [email protected]

5.10.2 Context


The purpose of this chapter is to summarize the needs for managing simulation models in the context of lifecycle collaboration (see Section 5.10.3) and the Functional Mock-up Interface (see Section 5.10.4).


FMI specification, version 2.0:

- https://svn.modelica.org/fmi/branches/public/specifications/v2.0/FMI_for_ModelExchange_and_CoSimulation_v2.0.pdf

FMI specification, version 1.0 (Co-Simulation and Model Exchange)

- https://svn.modelica.org/fmi/branches/public/specifications/v1.0/FMI_for_ModelExchange_v1.0.pdf

- https://svn.modelica.org/fmi/branches/public/specifications/v1.0/FMI_for_CoSimulation_v1.0.pdf

FMI PLM Interface, Specification for Product Lifecycle Management (PLM) of modelling, simulation and validation information – MODELISAR (ITEA 2 – 07006)

- http://www.3ds.com/fileadmin/PRODUCTS-SERVICES/CATIA/PDF/FMI_for_PLM_v1.0.pdf

Distributed Simulation Engineering and Execution Process (DSEEP):

- http://standards.ieee.org/develop/wg/DSEEP.html


In our discussions we saw that from a lifecycle point of view, simulation and co-simulation are much alike, since the specifics of the co-simulation can be described using FMI. Therefore the sample scenarios described below can be generalized to simulations in general. When talking about a simulation, this could be either a single simulation or a co-simulation.

This section describes the following sample lifecycle scenarios for simulations:

- Design space exploration









https://svn.modelica.org/fmi/branches/public/specifications/v2.0/FMI_for_ModelExchange_and_CoSimulation_v2.0.pdf

https://svn.modelica.org/fmi/branches/public/specifications/v2.0/FMI_for_ModelExchange_and_CoSimulation_v2.0.pdf

https://svn.modelica.org/fmi/branches/public/specifications/v1.0/FMI_for_ModelExchange_v1.0.pdf

https://svn.modelica.org/fmi/branches/public/specifications/v1.0/FMI_for_CoSimulation_v1.0.pdf

http://www.3ds.com/fileadmin/PRODUCTS-SERVICES/CATIA/PDF/FMI_for_PLM_v1.0.pdf

http://standards.ieee.org/develop/wg/DSEEP.html

D601.022



V1.0 R 2015-04-30 190 of 230

- System validation

- Searching for simulation models

These three scenarios have been defined as reference scenarios for simulation models and are especially related to co-simulation using Functional Mock-up Units.

It is important to note that these scenarios and the respective mapping to the IOS domains and services are an example. There are other potential realizations for these scenarios, which are dependent on the context and the set of scenarios is not complete. However, these seem to be the most common (generic) scenarios and the examples have been extensively discussed in a cross-domain team, leading to a reasonable consensus. This work has shown that the several lifecycle needs for (co-)simulation scenarios can properly be covered with the existing (i.e. AM, QM, AssetM and Auto) OSLC specifications.

Design Space Exploration:

The purpose of this scenario is to support system architecture evaluation with (co-)simulation.

Architecture evaluation is used to verify whether a certain architecture (of a System Of Interest, SOI) will achieve the required performance measures, or whether one architecture performs better than another architecture w.r.t. some given performance measures. This scenario defines the general steps to develop and execute a (co-)simulation environment for architecture evaluation and identifies the OSLC services to support this method.

Depending on the requirements, this scenario may be a quick practice, or a lengthy process that needs to be managed as a project.

The term ‘Technical capability’ is used as a synonym for the Platform Builder term ‘Engineering Function’. It specifies what needs to be enabled from a user perspective.

Technical Capability / Engineering Function

IOS domains IOS services IOS service details

Analysis and evaluation plan QM create OSLC:QM:TestPlan

Simulation environment objective RM create OSLC:RM:Requirement

Simulation environment objective RM read OSLC:RM:Requirement

Simulation conceptual model AM create OSLC:AM:Resource

Simulation scenario QM create OSLC:QM:TestCase

Simulation environment requirement

RM create OSLC:RM:Requirement

Simulation conceptual model AM read OSLC:AM:Resource

Simulation scenario QM read OSLC:QM:TestCase

Simulation environment requirement

RM read OSLC:RM:Requirement

Search repository for exiting FMU slave and master

AM basic-query OSLC:AM:Asset

Simulation environment design AM create OSLC:AM:Resource

Simulation environment design AM read OSLC:AM:Resource

Get exiting FMU slave and master from repository

AM read OSLC:AM:Asset

Store new FMU slave and master in repository

AM create OSLC:AM:Asset

Simulation scenario instance QM create OSLC:QM:TestScript

Simulation scenario instance QM read OSLC:QM:TestScript

Get exiting FMU slave and master from repository

AM read OSLC:AM:Asset

Execution environment description AUTO create OSLC:AUTO:AutomationPlan

Execution environment description AUTO read OSLC:AUTO:AutomationPlan

Run simulation AUTO read/create OSLC:AUTO:AutomationRequest

Raw execution output AUTO create OSLC:AUTO:AutomationResult

Derived output QM create OSLC:QM:TestResult

Derived output QM read OSLC:QM:TestResult

Analyzed data QM create OSLC:QM:TestExecutionRecord

Final report QM create OSLC:QM:TestExecutionRecord

The main steps, inputs and outputs of the scenario are summarized in the figure below. The figure shows an activity diagram that consists of two parts. The part on the left shows the (some of the general) engineering

D601.022



V1.0 R 2015-04-30 191 of 230

steps w.r.t. the engineering of the SOI; the part on the right shows the simulation environment engineering steps associated with design space exploration in the context of the engineering activities of the SOI.

The latter part is the focus of this scenario and consists of three swim lanes. The left swim lane shows (orange colored) OSLC resources related to the SOI and which are inputs to or a result of the steps. The right swim lane shows (grey colored) OSLC resources related to the simulation environment and which are results of the steps. The middle swim lane shows the main steps, described further below.

act Analyze and Ev aluate Architecture

OSLC (Simulation Env ironment)OSLC (SOI) Simulation Env ironment

Analyze and Ev aluate

Architecture

:Define Simulation

Env ironment

Objectiv es

:Design

Simulation

Env ironment

«OSLC Requirement»

Simulation Env ironment

Requirement

:Perform

Conceptual

Analysis

:Dev elop

Simulation

Env ironment

:Integrate and Test

Simulation

Env ironment

:Execute

Simulation

:Analyze Data and

Ev aluate Results



Objectiv e

«OSLC TestPlan»

Analysis and Ev aluation Plan

«OSLC Resource»

Conceptual Model

«OSLC TestCase»

Scenario«OSLC Resource»

System Architecture

Description


System Requirement

«OSLC Resource»


Design

«OSLC Asset»

FMU Slav e

«OSLC Asset»

FMU Master

«OSLC TestScript»

Scenario Instance

«OSLC AutomationPlan»

Execution Env ironment

Description

«OSLC AutomationRequ...

Run

«OSLC AutomationResult»

Raw Execution Output

«OSLC TestExecutionRe...

Analyzed Data

«OSLC TestResult»

Deriv ed Output

«OSLC Resource»

Architecture Ev aluation

«OSLC TestExecutionRe...

Final Report

«OSLC Resource»

Concept Description


Stakeholder Requirement

Figure 80: Design Space Exploration - Sequence diagram

D601.022



V1.0 R 2015-04-30 192 of 230

The main steps and results are:

1. Define simulation environment objectives

• architecture analysis and evaluation plan;

• set of objectives for the simulation environment (e.g. MOE/MOPs to measure).

2. Perform conceptual analysis

• conceptual model of the SOI (which is a simplification and abstraction of the SOI architecture that is to be represented within the simulation environment);

• general scenario(s) to evaluate (e.g. system loads);

• (modeling) requirements for the simulation environment.

3. Design simulation environment

• simulation environment design;

• identification of required FMU master and FMU slaves.

4. Develop simulation environment:

• FMU master and FMU slave implementations

• Scenario instances (specific situations, conditions, values, etc.)

5. Integrate and test simulation environment

• Description of the execution environment of the simulation environment

6. Execute simulation

• Simulation configurations to run

• Raw execution output

• Derived output (e.g. reduced raw output)

7. Analyze data and evaluate results

• Analyzed data

• Final report (i.e. architecture evaluation results)

This follows the DSEEP standard.

System validation:

The aim of this scenario is to perform a system validation using an existing simulation (reuse of simulation).

The prerequisites for this scenario are as follows: 1. The requirements have been defined in a requirements management tool and 2. The test cases for validation have been defined in a test management tool.

In this case, simulations are used for testing a certain system. In order to automatically execute the simulation, it is represented as an Automation Plan. The simulation results need to be validated against the requirements and the actual decision if the test for this requirement has been passed or failed needs to be linked to the requirement.

Technical Capability / Engineering function

IOS domains IOS services IOS service details

Retrieve test case to be executed QM read oslc_qm: Test Case

Retrieve related test script QM read oslc_qm: Test Script

The test script references the (co-)simulation and respective input parameters QM

read oslc_qm:executionInstruction

Run simulation Auto read oslc_auto: AutomationRequest

Run Simulation Auto read oslc_auto: AutomationPlan

Simulation result Auto create oslc_auto: AutomationResult

Simulation result QM create oslc_qm:TestResult

QM read oslc_qm:reportsOnTestCase

Retrieve test case QM read oslc_qm:TestCase

Test result linked to the test case QM read oslc_qm:TestResult

Retrieve linked requirements RM query oslc_rm:Requirement

Validation result (passed/failed) QM create oslc_qm:TestResult

Conclude pass/fail RM update oslc_rm:validationResult

D601.022



V1.0 R 2015-04-30 193 of 230

Why does it pass / fail RM write QM: TestResults: Description

Figure 81: system validation sequence diagram

Searching for simulation models:

This scenario is about the identification of simulation models that are necessary for performing a simulation.

The prerequisites for the scenario are the following: the type of simulation that is to be performed has been defined, and the main models (e.g. the models with algorithms under test) are available. Then, additional models that are necessary for completing the simulation scenario need to be found in a database.

Depending on available rights, found simulation models may be downloaded. These simulation models either contain binaries for selected platforms only, obfuscated source code that can be compiled, but that does not serve as documentation, or fully commented source code and/or source models are included.

Technical Capability / Engineering function

IOS domains

IOS services

IOS service details

Collect desired configuration (see system validation sheet)

Create test case defining desired simulation topic, acceptance criteria etc. QM create OSLC:QM:TestCase

Simulation scenario instance QM create OSLC:QM:TestScript

Create short list of simulations AssM query Simulation Domain, Topic, Discipline, output Variables

Read FMI details, display to user FMI read FMI details/meta data

Select best matching FMU, write simulation configuration AssM write OSLC:AssM / FMI Master

Copy existing FMU from repository / Get FMU reference for simulation server from repository AssM read OSLC:AssM:Asset

D601.022



V1.0 R 2015-04-30 194 of 230

Figure 82: Searching for simulation models diagram

5.10.4 Specification


We propose to add the FMI domain to the IOS in order to support the services described in the scenarios above.



Query Query FMU Metadata Query FMU Metadata

Run Run FMU Simulation Run a simulation that consists of functional mockup units

5.10.4.3 Non-Lifecycle IOS Spec – FMI for co-simulation

The Functional Mock-up Interface (FMI) is a standard software programming interface to a model of a dynamic system that is described by a set of differential algebraic equations (DAEs). The model is referred to as a Functional Mock-up Unit (FMU). The FMI is used by a simulation environment to create, use, and destroy FMU instances. An FMU may either have its own solvers (FMI for Co-Simulation) or require the simulation environment to perform numerical integration (FMI for Model Exchange). In either case, the FMI defines an interface for both cases.

The FMI standard consists of two main parts:

- The FMI for Model Exchange interface defines an interface to the model of a dynamic system described by differential, algebraic and discrete-time equations and to provide an interface to evaluate these equations as needed in different simulation environments, as well as in embedded control systems, with explicit or implicit integrators and fixed or variable step-size. The interface is designed to allow the description of large models.

- The FMI for Co-Simulation interface is designed both for the coupling of simulation tools (simulator coupling, tool coupling), and coupling with subsystem models, which have been exported by their simulators together with its solvers as runnable code. The goal is to compute the solution of time dependent coupled systems consisting of subsystems that are continuous in time (model components that are described by differential-algebraic equations) or time-discrete (model components that are described by difference equations, for example discrete controllers).

D601.022



V1.0 R 2015-04-30 195 of 230

The goal of the Model Exchange interface is to numerically solve a system of differential, algebraic and discrete-time equations. In this version of the interface, ordinary differential equations in state space form with events are handled (abbreviated as “hybrid ODE”). The hybrid ODEs supported by FMI are described as

piecewise continuous-time systems. Discontinuities can occur at time instants 𝑡0, 𝑡1, ⋯ , 𝑡𝑛 where 𝑡𝑖 < 𝑡𝑖+1. These time instants are called “events”. Events can be known beforehand (= time event), or are defined implicitly (= state and step events). A schematic view of a model in “FMI for Model Exchange” format is shown in the figure below. The data flow between the environment and the FMU is shown in blue/red arrows.

Figure 83: Model Exchange diagram

FMI for Co-Simulation defines interface routines for the communication between the Master and all slaves (subsystems) in a co-simulation environment. A Co-Simulation Slave (FMU Instance) consists of a Simulation Model and a Solver.

Figure 84: FMI for Co-Simulation interface routines

D601.022



V1.0 R 2015-04-30 196 of 230

For co-simulation two basic groups of functions have to be realized:

Functions for the data exchange between subsystems;

Functions for algorithmic issues to synchronize the simulation of all subsystems and to proceed in communication steps tci → tci+1 from initial time tc0 := tstart to end time tcN := tstop;

In FMI for Co-Simulation both functions are implemented in one software component, the co-simulation master. The data exchange between the subsystems (slaves) is handled via the master only. There is no direct communication between the slaves. The master functionality can be implemented by a special software tool (a separate simulation backplane) or by one of the involved simulation tools. In its most general form, the coupled system may be simulated in nested co-simulation environments and FMI for Co-Simulation applies to each level of the hierarchy. FMI for Co-Simulation is designed both for coupling with subsystem models, which have been exported by their simulators together with its solvers as runnable code, and for coupling of simulation tools. In its most general form, a tool coupling based co-simulation is implemented on distributed hardware with subsystems being handled by different computers. The definition of the communication layer is not part of the FMI standard.

Figure 85: Co-simulation on a single computer

Figure 86: Co-simulation with tool coupling on a single computer.

Figure 87: Distributed co-simulation infrastructure.

5.10.4.4 Non-Lifecycle IOS Spec – Looking up of Functional Mockup Units

To support the retrieval of functional mock-up units and to enable developers to better find the right simulation models, we propose an extension to the FMU standard that defines additional TAGs for the XML

D601.022



V1.0 R 2015-04-30 197 of 230

Schema that defines FMU descriptions. We distinguish between extensions for the FMI master and the FMI slave.

FMI slave description (new schema):

The following tags are proposed for FMU slaves:

Tag Values Description

SimulationModel Discrete, Continuous, Hybrid Describe the implemented simulation model

Domain Open list: Avionics, Automotive, Railway, etc.

Tag those domains that the model is intended to use in

Topic Open list, e.g. Dictionary based:

- Function

- De-Icing Controller

- UI

- Ice-Removal Model

- Cross-Cutting (e.g. temperature)

- Interaction Specification

Defines what is implemented by the simulation model

Discipline Open list, dictionary based

- Mechanical

- Environment

- Hardware

- Software

- Function

Defines the discipline that is simulated by a FMU

ModelFamilyInterfaces Open list, dictionary based

- AUTOSAR

- CAN Bus

Defines required interfaces, e.g. from base software that are necessary for running the FMU

Purpose Open list, dictionary based

- Function - Performance

o Latency o Energy consumption o Heating o Throughput o Queue size

Defines for which activities the model should be used

Quality One out of the following possible values:

- Under development [Unfinished, pre-release]

- Complete [Feature complete, but not released yet]

- Finished [Finished, but not validated in any way]

- Reviewed [Finished and reviewed, but not tested]

- Tested [Finished and tested against given scenarios, no real validation]

- Validated [Finished and validated against some test data]

- Reliable [Finished and extensively validated]

Defines the quality of the FMU

ProvenAlgorithm - Yes/No

- Link to Source/Documentation

Defines whether a generally accepted (simulation) algorithm is implemented by the model

ExpectedRuntime - Real-Time

- Near Real-Time

- …

Defines the runtime of the simulation model based on categories

Validated input ranges Defines the validated input range(s) for each input port and

D601.022



V1.0 R 2015-04-30 198 of 230

provides an optional link to documentation

Permissions - Execute (execute simulation model on server)

- May connect to port (connect to given list of input/output ports)

- May connect (all ports)

- May Download (all rights)

Defines the permission rights associated with a FMU. Realization of these rights requires partially the implementation of simulation servers to prevent downloading of FMUs.

Confidentiality - Source (Human understandable source code)

- Obfuscated (Compilable but obfuscated source code)

- Compiled (Only binary distribution)

o List of supported platforms

Describes the contents of the FMU and the kind of the used source code

Documentation Yes/No Availability of extra documentation

Version A Version String like 0.1

TimeManagement - Variable

- Fixed

- Event Driven

- Paced (sync. with clock)

- Hybrid

- Staggered

Documents the time management scheme of the FMU (the time management scheme the FMU can deal with)

FMI master description (new schema):

The following table lists the proposed information to be included in a new FMI master description schema.

The FMI master description schema and FMI model description schema share a number of common tags, such as version, name, author, permissions, confidentiality, documentation. These are not repeated in the following table and it is proposed to define these in a common schema.

Tag Values Description

fmiVersion Version value Supported FMI version

Coupling Strategies Multiple values:

- Loose

- Strong

- Parallel

- StaggeredSequential

- Other

Supported coupling strategies.

Time Management Schemes

Multiple values:

- variable timeStepped

- fixed timeStepped

- eventDriven

- optimisticSynchronization

- paced

- Hybrid (mix of the previous)

- Other

Supported time management schemes.

Infrastructure Distributed or Monolithic Distributed or monolithic master.

Distributed: FMUs can be distributed across multiple host computers.

Monolithic: FMUs all run on the same host computer.

D601.022



V1.0 R 2015-04-30 199 of 230

An example of a distributed master is the HLA-RTI (*)

PlatformList List of values A list of platforms (Windows, Linux, etc.) that the master can run on.

Model locations URL(s) Optional URL(s) where the Master can be found. The URL

may refer to a specific Master version in for example a GIT

or SVN repository.

(*) HLA-RTI: https://standards.ieee.org/findstds/standard/1516-2010.html

D601.022



V1.0 R 2015-04-30 200 of 230

6 Terms, Abbreviations and Definitions

Please add additional terms, abbreviations and definitions for your deliverable.

Table 48: Terms, Abbreviations and Definitions

Term Description Source

Brick A tool conforming to the IOS Crystal term

Capability A function that achieves some useful

measurable outcome

TOGAF

DODAF

Engineering

Method (EM)

Crystal specific

IT Information Technology

Reference

Technology

Platform

(RTP)

The RTP (Reference Technology Platform) is a

set of pre-integrated tools and services that can

randomly be compiled and installed based on a

respective business or engineering use case.

Crystal specific

(from MBAT)

Resource In general something made available on the

web, in V1.0 this is using RDF

Resource A specific Resource (RDF) representation in the

OSLC AM Spec

Resource

Description

Framework

A means to model information resources in

subject-predicate-object expressions, aka

triples, specifically in V1.0 this is RDF/XML

W3C

Scenario A path through or subset of a use-case

Service A mechanism to provide capabilities using a

prescribed interface. Here we refer to IT based

services.

Tool A software program which works with or on data

to transform or product it

Tool flow or

Tool chain

Combination of tools and services which are

used in scenarios, to fulfil the IT part a use case.

The tool chain respects a specific work and data

flow (engineering process, architecture).

Based on MBAT RTP V1.5

Tool Interoperability

The ability of two or more tools to exchange information and to use the information that has been exchange

Based on IEEE610

Use case A description of the steps through an expected

functionality of a system to reach a business

goal.

Based on MBAT RTP V1.5

D601.022



V1.0 R 2015-04-30 201 of 230

7 References

[1] OASIS OSLC

http://www.oasis-

oslc.org/node/2

[2] OASIS OSLC

Community site


[3] CRYSTAL Deliverable

D601.031 - Report on

Standardisation Work -

V1

https://projects.avl.com/11/0154/Data

Exchange/006_Results/Deliverables_Submitted_to_JU/SP6/CRYSTAL_D

_601_031_v1.0.pdf


D601.021 –

Interoperability

Specification V1

http://www.crystal-artemis.eu/deliverables.html

[5] OSLC (Open Services

for Lifecycle

Collaboration) website

http://open-services.net

[6] OSLC Core

Specifications V2

http://open-services.net/specifications/core-2.0/

[7] OSLC Domain

Specifications

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


D209.021 – Aerospace

ontology definition–

Version 1

[9] CRYSTAL Deliverable D D308.021 – Ontology

Definition & Assessment

Report - V1 (Automotive

Industrial Domain)


D407.021 – Health Care

ontology definition–

Version 1


D504.021 – Rail

Ontology Definition &

Assessment Report

[12] CRYSTAL Deliverable D D601.031 – Report on

http://www.oasis-oslc.org/node/2

http://www.oasis-oslc.org/node/2


https://projects.avl.com/11/0154/Data%20Exchange/006_Results/Deliverables_Submitted_to_JU/SP6/CRYSTAL_D_601_031_v1.0.pdf



http://www.crystal-artemis.eu/deliverables.html


http://open-services.net/specifications/core-2.0/

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

D601.022



V1.0 R 2015-04-30 202 of 230

Standardisation Work

V1

[13] CRYSTAL Deliverable D D601.032 – Report on

Standardization Work

V1

D601.022



V1.0 R 2015-04-30 203 of 230

8 Annex

8.1 Tracked Resource Set - Vocabulary

D601.022



V1.0 R 2015-04-30 204 of 230

D601.022



V1.0 R 2015-04-30 205 of 230

D601.022



V1.0 R 2015-04-30 206 of 230

8.2 Ontology IOS - Vocabulary

8.2.1 Requirement Management resource

D601.022



V1.0 R 2015-04-30 207 of 230

8.2.2 Architecture Management resources

D601.022



V1.0 R 2015-04-30 208 of 230

D601.022



V1.0 R 2015-04-30 209 of 230

D601.022



V1.0 R 2015-04-30 210 of 230

D601.022



V1.0 R 2015-04-30 211 of 230

D601.022



V1.0 R 2015-04-30 212 of 230

D601.022



V1.0 R 2015-04-30 213 of 230

D601.022



V1.0 R 2015-04-30 214 of 230

D601.022



V1.0 R 2015-04-30 215 of 230

8.2.3 Quality Management resources

D601.022



V1.0 R 2015-04-30 216 of 230

D601.022



V1.0 R 2015-04-30 217 of 230

8.2.4 Safety Risk Management resources

D601.022



V1.0 R 2015-04-30 218 of 230

8.2.5 Variability Management resources

D601.022



V1.0 R 2015-04-30 219 of 230

D601.022



V1.0 R 2015-04-30 220 of 230

D601.022



V1.0 R 2015-04-30 221 of 230

D601.022



V1.0 R 2015-04-30 222 of 230

D601.022



V1.0 R 2015-04-30 223 of 230

8.3 Knowledge Management - Vocabulary

D601.022



V1.0 R 2015-04-30 224 of 230

D601.022



V1.0 R 2015-04-30 225 of 230

D601.022



V1.0 R 2015-04-30 226 of 230

D601.022



V1.0 R 2015-04-30 227 of 230

D601.022



V1.0 R 2015-04-30 228 of 230

8.4 MBAT [MBAT, 2015] Interoperability specification- Vocabulary The domain vocabulary and their representation for the MBAT Interoperability specification is directly

described in the section 5.5.4

8.5 Example of Concrete Scenarios

Table 49: Examples of Concrete Scenarios related to "Lifecycle Interoperability" and "other Interoperability Topics"

Lifecycle Interoperability Scenarios

Other Interoperability Topics related to Lifecycle

Interoperability Scenarios

Other Interoperability Topics NOT related to Lifecycle

Interoperability Scenarios

Traceability between Artefact Elements to requirements and test/analysis cases

Querying lifecycle artefacts (e.g., Requirements) from multiple repositories

Browsing the changes history on artefacts from multiple tools and repositories

Displaying the impact of a requirement update on a set of design artefacts and simulation tasks

FMI for co-simulation with a FMI for co-simulation and model

D601.022



V1.0 R 2015-04-30 229 of 230

mapping, e.g., from FMI simulation inputs and results onto IOS-based lifecycle artefacts traced back to requirements and design artefacts

exchange

Relating ECU measurement and calibration data from ASAM Standards to other Lifecycle Artefacts (e.g. Requirements)

Gathering and transferring of ECU measurement and calibration data based on the ASAM standard

Traceability between Requirements and EAST-ADL Models from multiple repositories

Traceability between Requirements and Models based on EAST-ADL repository

Creating a list of requirements using selection criteria from different repositories

Exchange a list of requirements in ReqIF Format via offline collaboration to an external project partner

Relating artefacts within one repository according to a proprietary format

Creating a list of requirements based on attributes in one requirement proprietary repository

Relating artefacts of the same type (e.g. change request) between different instances of the same tool

Working toolset with established interoperability within one client (e.g., with Modelbus, Eclipse or vendor proprietary solutions)

Relating artefacts stored in a central repository (e.g., Requirement) with standard artefacts in a vendor specific toolset

Change Impact Analysis on multiple artefact types (e.g., change on a requirement impacting on design models, test cases, formal analysis results, etc.)

Semantic-preserving model transformations with traceability between input and output artefacts

Merging on a dashboard attributes from artefacts manipulated at different engineering phases which are of relevance for a particular tool chain stakeholder (e.g., analyst,

D601.022



V1.0 R 2015-04-30 230 of 230

project manager, Testing/Analysis expert)

8.6 IOS V1 Architecture Representation The figure below depicts the CRYSTAL IOS Architecture as it has been presented in the previous version of this deliverable (CRYSTAL D601.021 – Interoperability Specification V1 [4]). The top part of the figure encompasses the tool and domain-specific syntax and semantics, possibly based on proprietary and island solutions, which is basically out-of-scope of the IOS. On the contrary, the bottom part sketches the scope of the IOS, (a) specifying a common way for handling Lifecycle Interoperability (with respect to communication protocols, syntax, services and semantics used as a common ground for exchanging lifecycle artefacts and control flows between integrated engineering tools in a standardized way), and (b), the set of other Engineering/Interoperability Standards, supporting in depth Systems Engineering activities, and to be interfaced with Lifecycle Interoperability concepts.

SpecificSeman cLayer

SpecificSyntaxLayer

SyntaxLayer

Communica onLayer

ServicesLayer

InteroperabilitySeman cLayer

EngineeringToolsforCyber-PhysicalSystems

LanguagesandFormalismsManagement/EngineeringMethods&

Workflows

Tool-Specific, Proprietary & Domain-Specific Layers (out-of-scope of the IOS)

CRYSTAL IOS

Other Interoperability Topics for In Depth Systems Engineering Activities

…

…

(e.g., for Measurement and Calibration)

Other

Other

Other

(e.g., for Heterogeneous Co-Simulation)

Other

Other

Other

Other

HTTP & Core Web Technologies

Authen ca on IndexingQuery

Addi onalConcepts RM AM

RDF/XML

Addi onalServices

Lifecycle Interoperability

Scope of the IOS V1 based on a subset of OSLC

Guidelines for Integration

Mapping implemented by Brick Providers

QM

AssetM ChangeReq.M

OSLCCore

Scope of the IOS V2

Figure 88: The CRYSTAL IOS V1 Layered Architecture.