Report about decision on meta model and tools for PIM...

Version: 1.0r Status: Released DECOS_deliv_PIM_Specification.doc

DECOS

Dependable Embedded Components and Systems

Report about decision on meta model and tools for PIM

specification

D 1.1.1

Project DECOS Contract Number 511764

Document Id 1.1-004_1.0r Date 2004-12-06 Deliverable D 1.1.1

Contact Person A. Pataricza Organisation BUTE

Fax +36 1 4632667 E-Mail [email protected]

DECOS Deliverable 1.1.1 /86


Distribution Table

Name Company Department No. of copies

Hardcopy/ Softcopy

all partners e-Mail



Change History

Version Date Reason for Change Pages

Affected

0.1w 2004-11-11 Initial version all

0.2w 2004-11-24 UML profile for SCADE added Appendix

0.3w 2004-11-24 Onthologies inserted Section 4.5

0.4w 2004-11-24 SysML description inserted Section 5.3.4

0.5w 2004-11-25 Application workflow insterted Section 8

0.6w 2004-11-25 Objectives inserted, Profile and Scade scade description corrected

Section 2, 5, 11

0.7w 2004-11-25 Final formatting all

0.8w 2004-12-01 Modified metamodel, profile, minor corrections, Abbreviations section added

all

0.9w 2004-12-02 Modified metamodel Section 5

0.10w 2004-12-06 Diagnostic requirements updated, modified profile and onthological model, minor corrections

all

0.11w 2004-12-08 Updated metamodel, onthological description, minor corrections

all

1.0w 2004-12-13 Suggestions of the technical board incorporated. all

1.0w 2004-12-21 Final proofreading all



Authors

This deliverable is based on the contributions of all DECOS partners and it was created by the DECOS team at the Budapest University of Technology and Economics (A. Balogh, Gy. Csertán, O. Dobán, P. T. Kovács, I. Majzik, A. Pataricza, D. Varró, Sz. Varró-Gyapay).



Contents

1 Executive summary.............................................................................................................................8

1.1 Introduction ............................................................................................................................................8 1.2 Aim of the workpackage ........................................................................................................................8 1.3 Results achieved ...................................................................................................................................8

2 Objectives.............................................................................................................................................9

3 PIM requirements ..............................................................................................................................11

3.1 Introduction ..........................................................................................................................................11 3.1.1 Purpose and Scope .............................................................................................................................11 3.1.2 Requirements Attributes ......................................................................................................................11 3.1.3 Partners ...............................................................................................................................................12 3.2 Platform Independent Model (PIM) Description ..................................................................................12 3.2.1 Background..........................................................................................................................................12 3.2.2 Support for PIM to PSM transformation ..............................................................................................14 3.3 Requirements ......................................................................................................................................15 3.3.1 Context Information .............................................................................................................................15 3.3.2 Common requirements ........................................................................................................................15 3.3.3 Functional requirements ......................................................................................................................21 3.3.4 Performance requirements ..................................................................................................................28 3.3.5 Dependability requirements.................................................................................................................32 3.3.6 Diagnostic Requirements ....................................................................................................................34

4 Relation to modeling standards.......................................................................................................36

4.1 MOF.....................................................................................................................................................36 4.2 MDA.....................................................................................................................................................37 4.3 UML .....................................................................................................................................................38 4.4 XML/XMI ..............................................................................................................................................39

5 PIM metamodel ..................................................................................................................................41

5.1 General introduction of the metamodel ...............................................................................................41 5.2 Detailed description of the PIM metamodel.........................................................................................41 5.2.1 Explanation of model elements ...........................................................................................................41 5.2.2 Tabular definition of model elements ..................................................................................................46 5.3 Implementation of PIM requirements ..................................................................................................60 5.3.1 Common requirements ........................................................................................................................60 5.3.2 Functional requirements ......................................................................................................................63 5.3.3 Performance requirements ..................................................................................................................66 5.3.4 Dependability requirements.................................................................................................................68

6 Relation to domain specific standards ...........................................................................................70

6.1 Importance of standards......................................................................................................................70 6.2 Development standards.......................................................................................................................70 6.2.1 DO-178B..............................................................................................................................................70 6.2.2 ISO/IEC 61508 ....................................................................................................................................71 6.2.3 SAExx ..................................................................................................................................................72 6.2.4 Implementation technology standards.................................................................................................72 6.3 SysML..................................................................................................................................................72 6.3.1 Introduction ..........................................................................................................................................72 6.3.2 SysML metamodel...............................................................................................................................73 6.3.3 Comparison of SysML and DECOS PIM.............................................................................................74



7 Application workflow ........................................................................................................................76

7.1 Interfacing to existing technologies .....................................................................................................76 7.2 Transformational approach..................................................................................................................76 7.2.1 Basic transformation............................................................................................................................76 7.2.2 Usage of patterns ................................................................................................................................77 7.2.3 The role of additional information ........................................................................................................78 7.3 Example tool chain ..............................................................................................................................78 7.4 The role of PIM-PSM mapping in the DECOS HW-SW integration ....................................................79

8 An Example PIM.................................................................................................................................81

9 Abbreviations and Definitions..........................................................................................................85

10 References .........................................................................................................................................86



List of Figures

Figure 1: Metamodel definition workflow ..........................................................................................................10 Figure 2: SP1 activity interoperation.................................................................................................................13 Figure 3: PIM to PSM transformation (with optional marked PIM) ...................................................................14 Figure 4: MOF 4-layer framework (source: MOF Specification by OMG [MOF 2002]) ....................................37 Figure 5: Packages of the PIM metamodel ......................................................................................................42 Figure 6: Content of the functionality package .................................................................................................42 Figure 7: Content of the Performance package ...............................................................................................45 Figure 8: Content of the Dependability package ..............................................................................................46 Figure 9: Development life-cycle according to DO-178B .................................................................................71 Figure 10: SysML extension of UML ................................................................................................................73 Figure 11: SysML package structure................................................................................................................74 Figure 12: Mapping based transformation of the PIM (source MDA specification [MDA 2001] [MDA2003])...77 Figure 13: Pattern based transformation of the PIM (source MDA specification [MDA 2001] [MDA2003]).....77 Figure 14: The role of additional information in the transformation (source MDA specification [MDA 2001] [MDA2003]).......................................................................................................................................................78 Figure 15: DECOS modeling workflow.............................................................................................................79 Figure 16: The role of PIM-PSM mapping during DECOS HW-SW integration...............................................80 Figure 17: Wheel job structure of the example PIM .........................................................................................81 Figure 18: The control and pedal jobs of the exampel PIM..............................................................................82 Figure 19: Message dependability and -performance objects of the example PIM .........................................83 Figure 20: Job performance and -dependability objects of the example PIM ..................................................84



1 Executive summary

1.1 Introduction

The work presented in this document is part of Workpackge 1.1 (WP1.1) of Sub-project 1 (SP1) of DECOS. SP1 addresses three issues:

♦ the Platform Interface Layer (PIL) and its application programming interface (API);

♦ allocation of Distributed Application Subsystem (DAS) jobs to available hardware and software by transforming the Platform Independent Model (PIM) of these DASs to a Platform Specific Model (PSM);

♦ support for DAS development.

The specification models developed in SP1 are based on requirements provided by the application and the technology sub-projects and partners. The current work focuses on the specification of a metamodel for the PIM.

1.2 Aim of the workpackage

The aim of the workpackage is to develop representation models to capture the fundamental properties of each DAS / job in a platform independent way. In addition requirements with respect to dependability and performance have to be expressed.

1.3 Results achieved

In the frame of Work package 1.1 the following results have been achieved:

♦ A collection of requirements has been created. Project partners have collected operational-, dependability-, and performance requirements a PIM or a DAS has to fulfill.

♦ According to the requirements a metamodel has been created that can be used in the initial phases of system development to capture the requirements of DASs.

♦ The metamodel has been defined in UML but the role of UML is solely to define the elements of the metamodel and the connection among the elements of the metamodel. The metamodel itself is modeling language independent.

♦ The conformance of the PIM metamodel to the current mainstream modeling technology- and application domain specific standards has been checked.

♦ The possible role of the PIM metamodel and PIM in the development workflow has been identified.



2 Objectives

According to the project proposal, the main objective of DECOS is to significantly strengthen the leading European competitive position in the application of dependable embedded real-time systems in a broad range of domains, especially in the automotive, aerospace and control markets.

The increasing pervasiveness of embedded systems in providing fundamental services in these domains and the vision of their usage in networked critical infrastructures demands an increasing reliance of their dependable operation. On the other hand, the rapidly growing functional and non-functional system requirements cause an enormous increase of system complexity.

In order to keep development and production costs at an affordable level or even reduce these costs considerably, it is necessary to provide pre-validated, certifiable hardware and software components and an appropriate integration methodology for the design of future dependable embedded systems.

The goal for the integrated project DECOS is to develop a generic component based building block infrastructure for dependable embedded systems, which is technology and platform independent.

Specifically, DECOS will establish a framework for:

♦ Development of component level interactions and interfaces to result in (a) platform independent design guideline for system elements, system services and communication structures and (b) technology neutral interfaces;

♦ Development of fundamental middleware services for cohesive integration of operational and dependability criteria. This applies to both HW-SW and communication partitioning and integration following systematic dependability considerations;

♦ Design, implementation and validation of component level services;

♦ Application Development.

In this context the aim of the elaboration of the metamodel related to the main DECOS concepts serves multiple purposes:

♦ At first, it provides a well-organized form of presentation of the core ideas of DECOS in a semiformal way, thus it represents the core concepts and their interrelations in such a mathematically well-founded model which uniquely identifies the potential interpretations. The use of the mathematically precise formulation allows for an automated partial check of the soundness of the metamodel.

♦ As the metamodel describes the features used in creating DECOS compliant models in a compact form, the metamodel serves as a basis for comparison to other system engineering approaches.

♦ One of the main objectives of DECOS is to support to the reuse of existing, best practice industrial design methodologies. As the metamodel summarizes the peculiarities of the DECOS approach, it serves as basis for adapting existing modelling notations to DECOS specific features in a form compliant to the metamodel.

♦ As the creation of the platform independent model (PIM) is the first step in the design flow, the metamodel defines the maximum extent of interaction between the functional modelling and implementation tools.

The workflow of the metamodel definition is depicted in Figure 1.

At first, requirements were collected covering the requirements originating in the intended DECOS architecture. The requrements are listed in Chapter 3. The main method applied here was the generalization and unification of the requirements characteristic to the envisaged fields of application and implementation technologies.



This common and functional requirements were complemented by the most important non-functional ones, like those related to performance and dependability related ones. Here special care was given to the general standards relating to mission-critical embedded systems and to the domain specific formal and de facto requirements.

The set of requirements was target of an expert judgment by the representatives of the individual partners in several versions.

After collecting and consolidating the basic requirements at first, initial metamodel was elaborated. Its soundness can be checked by several means:

♦ The compliance to the set of requirements was analyzed and documented by expert judgment in a checklist like form.

♦ The completeness and uniqueness of the metamodel can be analyzed by using formal mathematical analysis based on description logic. This step can be inserted into the workflow with the secondary goal to present a formal checking methodology to be used in the derivation of modelling dialects by merging the DECOS metamodel into existing modelling paradigms.

As further work, an initial version of a UML DECOS profile should be elaborated to check the feasibility of merging the metamodel with existing standard design methodologies.

♦ This UML profile should be compared to one of the evolving OMG standards still in the preparation phase, SysML. It is intended to cover the entire spectrum of modelling issues related to systems engineering with a special emphasis on embedded systems. The comparison should show, that the DECOS UML profile can be formulated as a specialization of SysML assuring the reuse of systems engineering tools based on this later standard proposal.

♦ Another comparison should be made to assess the feasibility of integrating the PIM level UML models with state of the art implementation related modelling tools. This can be done by comparing DECOS UML with the SCADE UML profile currently under elaboration for one of the leading technologies in mission-critical system design and implementation.

Figure 1: Metamodel definition workflow



3 PIM requirements

3.1 Introduction

3.1.1 Purpose and Scope

The purpose of this chapter is to define the requirements for the PIM. Based on these requirements, a metamodel of PIM will be developed that allows expressing the following specifications of DASs:

♦ Operational requirements and out-of-norm assertions

♦ Dependability aspects, including criticality and fault-tolerance.

♦ Performance and resource requirements of components including timeliness, periodicity, duration.

All relevant details are identified for these requirements. The requirements for the evolving metamodel can be categorized into two main groups:

The first group of requirements describes the way of creating the metamodel and its interfaces from the very general point of view of metamodeling technologies.

The second group of requirements summarizes the demanded information content of the models from the domain specific point of view of engineering.

Requirements have been categorised into common, functional, performance, dependability and marked PIM. The domain specific requirements sent by the partners were cumulated and merged together. Therefore no categorisation of requirements into industrial domains (e.g. automotive, aerospace, automation) is done, because a requirement may be relevant for more than one domain (e.g. timely delivery of messages).

Requirements that are not platform independent but are necessary to support the PIM to PSM transformation are grouped into the marked PIM requirements.

3.1.2 Requirements Attributes

In order to support elaboration of requirements as well as tracing their consideration during the development of PIM metamodel, a uniform way has been chosen for capturing requirements. The main attributes such as

♦ ID

♦ Description

♦ Responsibility

♦ Acceptance (in case of a "should" requirement)

are mandatory. Other attributes such as

♦ Name

♦ Rationale

♦ Assumptions

♦ Additional info

♦ Link to



♦ Priority

♦ Submitter

are optional. Commonly used attributes are described below:

Identifier is unique and corresponds to the following format:

<deliverable number>_<theme>_<requirements_type>_<number>

Example: 1.1.1_FUNC_JOB_04 - 4th job related functional requirement of deliverable 1.1.1 "Report about decision on meta model and tools for PIM specification"

Description clearly specifies the requirement. The word “shall” is used to specify a mandatory requirement. The word “should” is used in case a decision needs to be made in the future whether the requirement is necessary.

Responsibility specifies the organisation and if possible the person responsible for implementing and maintaining a requirement.

Acceptance (condition) is mandatory in case if the word "should" is used in the description attribute. It specifies when the decision will be made and the criteria the decision will be based upon.

Name denotes a unique name that complements the ID, but is easier to memorize.

Rationale is an explanation why this requirement is necessary.

Assumption represents the facts we already know about the requirement or design decisions we already made.

Additional info contains further details that are not given under Description.

Link to describe the connection to other requirements or points to an URL related to the requirement.

Priority denotes the importance of the requirement. High denotes a requirement with the word "shall" in its description. Medium and low denote requirements with the word "should" in its description.

Submitter describes the acronym of DECOS-partner who raised the requirement.

3.1.3 Partners

The following partners contributed to the requirements specification:

♦ ARCS

♦ AIRB

♦ AUDI

♦ PROF

♦ SP

♦ TTT

♦ TUDA

♦ TUHH

♦ TUVI

♦ UNIK

3.2 Platform Independent Model (PIM) Description

3.2.1 Background

In order to achieve a technology-invariant system design of the final application, a DECOS architecture design starts with a Platform Independent Model (PIM) of each Distributed Application Subsystem (DAS). As part of this activity the core operational semantics of the desired system services is captured.



In the beginning, a specification model for PIM is developed, which permits not only to capture PIM in a uniform way, but also to support the transformation to Platform Specific Models (PSM) as well as both PIM and PSM verification.

We distinguish three vertical lines (see Figure 2), which have to be taken into consideration by the mapping of the PIM to the PSM:

Functional design: The functional specifications in the PIM should be satisfied by proper function allocation, configuration of the communication network and set-up of the (encapsulated) execution environment.

Performance related design: The performance specifications in the PIM should be satisfied by proper resource allocation, communication and task scheduling according to the resource attributes offered by the platform.

Dependability related design: The dependability specifications in the PIM should be satisfied by proper fault-tolerance techniques (redundancy management) that are selected on the basis of the available dependability attributes and failure modes of the platform.

Figure 2: SP1 activity interoperation

The objective of WP 1.1 is to develop representation models and tools to capture the fundamental properties of each component/sub-system in their PIM’s. In addition, it will be necessary to express requirements with respect to dependability and performance.

According to the objectives described above, the metamodel of the PIM serves several objectives during the design flow:

Functional Requirements

Performance Requirements

Dependability Requirements

Apps Functional/Op Elements

Performance Properties

Dependability Properties

SYS

Function allocation, network configuration, execution environment

Resource allocation, communication scheduling, task scheduling

Selection of FT scheme, redundancy management

Functional access

Performance related services (clock sync, etc.)

Dependability related services (fault isolation)

Platform

Resource functionality

Performance characteristics

Dependability characteristics

DAS

PIM

PSM

PIL

Platform

Platform Independent Specs

Integrated HW-SW

DAS: Distributed Application Subsystem PIM: Platform Independent Model PSM: Platform Specific Model PIL: Platform Interface Layer



♦ It provides a structured form to describe the functional requirements and properties of the target DAS and their interrelations up to the level of modeling details of a simulation-ready behavioral specification of the system under design (but obviously having no platform specific details).

♦ It defines interfaces to import complete designs of systems or subsystems (reuse of the existing solutions) and design patterns describing best practice solutions.

♦ It defines interfaces to the services offered by the lower layers.

3.2.2 Support for PIM to PSM transformation

A model transformation (i.e. PIM to PSM transformation) is the process of converting one model to another model of the same system. The mapping provides specifications for a transformation of a PIM into a PSM for a particular platform. Optionally model instance mappings can define marks. A mark represents a concept in the PSM, and it is applied to an element of the PIM to indicate how that element is to be transformed. This way marks can guide the process of transformation.

The marks, being platform specific, are not a part of the platform independent model. The architect can take the platform independent model and mark it for use on a particular platform. The marked PIM is then used to prepare a platform specific model for that platform. The marks can be thought of as being applied to a transparent layer placed over the model.

PIM

marked

PIM

Marks

Mapping PIL

Transformation

PSM

Figure 3: PIM to PSM transformation (with optional marked PIM)

Figure 3 shows more details on the way the transformation is done. As mentioned a particular platform is chosen. In DECOS it is described by the model of the PIL. A mapping for this platform is prepared. This mapping can optionally include a set of marks. The marks can be used to mark elements of the model to guide the transformation of the model. The marked PIM is further transformed, using the mapping, to produce the PSM. If marking is not used, that is the normal case of transformation, then marked PIM and marks are not necessary, transformation is done by a direct mapping of PIL and PIM concepts onto the PSM.



If the PIM is prepared using a platform independent UML profile it can be transformed into a PSM expressed using a second, platform specific UML profile. In this case the marking of the PIM occurs by using the marks provided with the platform specific profile.

3.3 Requirements

3.3.1 Context Information

Technology related requirements for the evolving metamodel include, but are not limited to the following:

♦ The metamodel shall be precise enough to be used in the subsequent steps to the definition and implementation of the DECOS technology.

♦ The compliance of the DECOS metamodel with OMG's Meta Object Facility (MOF) has to be guaranteed in order to fit into the mainstream of the industrial best practice in designing modeling languages. Consequently, the metamodel should have a standards compliant XML-based schema, which may serve as the interface format between the modeling tools and the tools processing the PIM.

♦ The metamodel should be able to cover the information content in the currently used design methodologies. Models designed in these environments should be targets of an algorithmic transformation into the DECOS metamodel. ("Algorithmic" means here only the feasibility of a systematic transformation independently whether it will be implemented in the form of an automated transformation in the framework of the current project or not).

♦ The DECOS metamodel should comply with the evolving standards, like those of SAE and/or the SysML community.

♦ The definition of a UML profile is a favorite candidate for formulating the metamodel, but it is not mandatory.

♦ If a UML profile is defined for the metamodel, OMG's Model Driven Architecture (MDA) can be used to capture the PIM to PSM transformation.

Since a PIM is a mean for requirement formulation, the PIM requirements are collected and listed as seen from a DAS developer’s perspective.

The Platform Independent Model of a DAS contains model elements representing domain entities or services and the functional and non-functional requirements referring to the properties of these domain elements. Moreover, there are also requirements that refer to the DAS as a whole.

Requirements are collected for different types of DAS. Here "type" means that DASs characterised by a given set of domain elements and corresponding properties are considered to be belonging to a given type (e.g. multimedia transfer DAS, low-level control DAS, diagnostic DAS etc.). The collected set of information will form the basis of the construction of the PIM meta model. The following characteristics are identified:

♦ the DAS type,

♦ the domain elements and their (functional and non-functional) properties,

♦ the additional design constraints that restrict the design space,

♦ the verification and validation requirements,

♦ the process (life cycle) requirements,

♦ the applied domain-specific standards.

3.3.2 Common requirements



3.3.2.1 General requirements

The general requirements describe the way of creating the metamodel and regulate the way a PIM is composed.

ID: 1.1.1_GEN_01 Name: requirements

Description: The PIM shall represent the requirements for the DASs.

Responsibility: BUTE

Rationale: It should not describe any implementation details or decisions.

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: BUTE

Acceptance: -

ID: 1.1.1_GEN_02 Name: platform_independency

Description: The PIM shall be platform-independent.


Rationale: It should not contain any platform-specific concepts like specific bus systems or runtime environments.

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: BUTE

Acceptance: -

ID: 1.1.1_GEN_03 Name: paradigm_independency

Description: The PIM shall be paradigm-independent.


Rationale: When defining the requirements, one should not go into implementation details like ET or TT.

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: BUTE

Acceptance: -

ID: 1.1.1_GEN_04 Name: description

Description: Every entity shall have a description / specification field.


Rationale: To offer the possibility to embed design documentation in the model.

Assumptions: -

Additional info: Since this is a general requirement, it will not be listed at each entity.

Link to: -

Priority: high

Submitter: BUTE, TUVI

Acceptance: -

ID: 1.1.1_GEN_05 Name: name

Description: Every entity shall have a name field.


Rationale: The name serves as a system-wide unique identifier of the entity.



Assumptions: -

Additional info: Since this is a general requirement, it will not be listed at each entity.

Link to: -

Priority: high


Acceptance: -

ID: 1.1.1_GEN_06 Name: verifiability

Description: The PIM shall be verifiable in order to enable component-based verification of subsystems. This may affect in particular the technology/methodology decision.


Rationale: High priority is assigned otherwise the effort for validation and verification of the system would be significantly higher.

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: ARCS

Acceptance: -

ID: 1.1.1_GEN_07 Name: extensibility

Description: The PIM shall be modifiable and extensible.


Rationale: -

Assumptions: -

Additional info: High priority is assigned since entirely new DASs implemented in the future may require new PIM properties.

Link to: -

Priority: high

Submitter: ARCS

Acceptance: -

ID: 1.1.1_GEN_08 Name: xml_syntax

Description: XML based syntax definition of the metamodel.


Rationale: The XML-based format shall become the interface format between the modeling tools and the tools processing the PIM. This provides a possibility to check the PIM against conformancy to the PIM metamodel.

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: BUTE

Acceptance: -

3.3.2.2 Technology and design methodology requirements

The following table lists the technologies and design methodologies PIM shall / should support in order to be able to use it in the everyday work of project partners. The transformation will transform the PIM to the input model of these supported technologies and methodologies.

ID: 1.1.1_TECHN_01 Name: MATLAB_Simulink

Description: MATLAB/Simulink support shall be provided.




Rationale: Most fault-tolerant mechatronic systems in the aerospace domain as well as the high-lift test-bench in DECOS are designed in and simulated with MATLAB Simulink/Stateflow. Steer-by-wire systems are designed exclusively in Simulink/Stateflow.

Assumptions: -

Additional info: Support is provided by a PIM to MATLAB/Simulink transformation.

Link to: www.matlab.com

Priority: high

Submitter: TUHH, PROF

Acceptance: -

ID: 1.1.1_TECHN_02 Name: Simulink_Stateflow

Description: Simulink/Stateflow support shall be provided.


Rationale: Most fault-tolerant mechatronic systems in the aerospace domain as well as the high-lift test-bench in DECOS are designed in and simulated with MATLAB Simulink/Stateflow. Steer-by-wire systems are designed exclusively in Simulink/Stateflow.

Assumptions: -

Additional info: Support is provided by a PIM to Simulink/Stateflow transformation.


Priority: high

Submitter: TUHH, PROF

Acceptance: -

ID: 1.1.1_TECHN_03 Name: Simulink_Coder

Description: MATLAB/Simulink-Coder support shall be provided.


Rationale: Automatic code generation based on Matlab/Simulink-Coder. The target platform should be supported by the coder.

Assumptions: -

Additional info: Support is provided by a PIM to MATLAB/Simulink-Coder transformation.


Priority: high

Submitter: PROF

Acceptance: -

ID: 1.1.1_TECHN_04 Name: SCADE dataflow

Description: SCADE support shall be provided.


Rationale: Growing relevance for modeling safety-critical real-time systems.

Assumptions: -

Additional info: Support is provided by a PIM to SCADE transformation.

Link to: www.esterel-technologies.com

Priority: -

Submitter: UNKI

Acceptance: -

ID: 1.1.1_TECHN_05 Name: SCADE_CG

Description: SCADE Code Generator support shall be provided.


Rationale: Automatic code generation based on SCADE. The target platform should be supported by the coder.

Assumptions: -

Additional info: Support is provided by a PIM to SCADE CG transformation.


Priority: high

Submitter: EST



Acceptance: -

ID: 1.1.1_TECHN_06 Name: SCADE_SSM

Description: SCADE Safe State Machines support shall be provided.


Rationale: Growing relevance for modeling safety-critical real-time systems.

Assumptions: -

Additional info: Support is provided by a PIM to SCADE SSM transformation.


Priority: -

Submitter: UNKI

Acceptance: -

ID: 1.1.1_TECHN_07 Name: TTP_support

Description: All services, functionalities and tools of TTP shall be supported by all DECOS developments.


Rationale: -

Assumptions: -

Additional info: Services and functionalities: applications, virtual communication links, gateways, models, tools.

Link to: DECOS-SP6-REQ-Dx.y-0039

Priority: -

Submitter: AIRB, BUTE

Acceptance: -

3.3.2.3 Identification of standards

Since the PIM is platform independent it shall not support specific technology standards, but it should cover the functionality of the following standards in order to help the application of the standard during the design.

ID: 1.1.1_STAND_01 Name: UML_SPT

Description: The PIM shall support the UML Profile for Schedulability, Performance, and Time Specification


Rationale: Basic guidelines for the definition of an UML profile for the PIM metamodel.

Assumptions: -

Additional info: Issued by OMG.

Link to: http://www.omg.org/technology/documents/spec_catalog.htm

Priority: high

Submitter: BUTE

Acceptance: -

ID: 1.1.1_STAND_02 Name: TTP/C

Description: The PIM shall support the TTP/C standard.


Rationale: The TTP/C specification describes the operation of the TTP/C protocol and the services provided to applications.

Assumptions: -

Additional info: -

Link to: www.tttech.com

Priority: high

Submitter: TUVI

Acceptance: -



ID: 1.1.1_STAND_03 Name: CAN

Description: The PIM shall support the CAN Specification Version 2.0.


Rationale: Specification of the CAN serial communication protocol.

Assumptions: -

Additional info: -

Link to: http://www.can.bosch.com/content/Literature.html

Priority: high

Submitter: TUVI

Acceptance: -

ID: 1.1.1_STAND_04 Name: LIN

Description: The PIM shall support the LIN Specification Package Revision 1.3.


Rationale: The LIN specification includes the LIN protocol, a uniform format for the description of an entire LIN network and the interface between a LIN network and the application.

Assumptions: -

Additional info: -

Link to: www.lin-subbus.org

Priority: high

Submitter: TUVI

Acceptance: -

ID: 1.1.1_STAND_05 Name: Profibus

Description: The PIM shall support the Profibus standard.


Rationale: PROFIBUS is an open, communication system with a wide range of applications, particularly in the fields of factory and process automation.

Assumptions: -

Additional info: -

Link to: www.profibus.com

Priority: high

Submitter: PROF

Acceptance: -

ID: 1.1.1_STAND_06 Name: FlexRay

Description: FlexRey support shall be provided.


Rationale: -

Assumptions: -

Additional info: -

Link to: www.flexray.com

Priority: -

Submitter: AUDI

Acceptance: -

ID: 1.1.1_STAND_07 Name: internet_protocol

Description: The PIM shall support Internet Protocols (e.g., TCP/IP, UDP).


Rationale: RFC 768, RFC 791, RFC 793 - Internet Protocol Standards.

Assumptions: -

Additional info: -

Link to: http://www.rfc-archive.org

Priority: high

Submitter: TUVI

Acceptance: -



ID: 1.1.1_STAND_08 Name: DO178B

Description: DO178B support shall be provided.


Rationale: -

Assumptions: -

Additional info: -

Link to: -

Priority: -

Submitter: TTT

Acceptance: -

ID: 1.1.1_STAND_09 Name: compliance

Description: To satisfy all validation & verification, safety, certification and legal requirements all tools, applications, software and hardware developed in DECOS subprojects shall show compliance to the following documents.


Rationale: -

Assumptions: The requirement model (i.e. PIM) should not satisfy these standards. These will be satisfied by the engineering model that is generated from the PIM. From the PIM by a transformation a human readable format of the requirements can be extracted that complies these standards.

Additional info: SAE ARP 4754 “Certification Considerations For Highly Integrated Or Complex Aircraft Systems”; SAE ARP 4761 “Guidelines & Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment"; SAE ARP 5580 “Recommended Failure Modes and Effects Analysis (FMEA) Practices for Non-Automobile Applications”; RTCA/DO-178B “Software Considerations in Airborne Systems and Equipment Certification”; RTCA/DO-254 “Design Assurance Guidance for Airborne Electronic Hardware“; RTCA/DO-160 “DO-160A, Environmental Conditions and Test Procedures for Airborne Equipment”; AC 25.1309 “System Design and Analysis, Advisory Circular”, FAA; AMJ 25.1309 “System Design and Analysis, Advisory Material Joint”, JAA


Priority: -

Submitter: AIRB

Acceptance: -

3.3.3 Functional requirements

3.3.3.1 DAS related requirements

The system consists of DASs that can interact and cooperate.

ID: 1.1.1_FUNC_DAS_01 Name: das

Description: The PIM shall represent DASs.


Rationale: -

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: BUTE

Acceptance: -



ID: 1.1.1_FUNC_DAS_02 Name: das_type

Description: The PIM shall represent DAS types.


Rationale: -

Assumptions: DAS types are: safety-critical, non-safety-critical, time-triggered, event-triggered, Profibus, distributed control, TTA

Additional info: If partners express their need the general PIM metamodel can be specialized in a later phase of the project to describe a given type of DAS by removing the modeling elements belonging to other DAS types.

Link to: -

Priority: high

Submitter: TUVI, PROF, TTT

Acceptance: -

ID: 1.1.1_FUNC_DAS_03 Name: das_interface

Description: The PIM shall represent the interface of DASs to the environment and to each other.


Rationale: Interface to relevant signals of the environment. The elements and messages that are imported / exported via an inter-DAS gateway.

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: PROF, BUTE

Acceptance: -

ID: 1.1.1_FUNC_DAS_04 Name: das_operating_mode

Description: The PIM shall represent operating modes of DASs.


Rationale: -

Assumptions: Some examples of these operating modes are: normal operation, startup, flashing, maintenance, degraded.

Additional info: -

Link to: -

Priority: high

Submitter: BUTE

Acceptance: -

ID: 1.1.1_FUNC_DAS_05 Name: das_initial_operating_mode

Description: The PIM shall represent the initial operating mode of DASs.


Rationale: -

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: BUTE

Acceptance: -

ID: 1.1.1_FUNC_DAS_06 Name: das_operating_mode_change

Description: The PIM shall represent operating mode changes of DASs.


Rationale: -

Assumptions: -

Additional info: -

Link to: -



Priority: high

Submitter: BUTE

Acceptance: -

3.3.3.2 Job related requirements

DASs are composed of communicating jobs.

ID: 1.1.1_FUNC_JOB_01 Name: job

Description: The PIM shall represent jobs.


Rationale: -

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: BUTE, TUVI, TTT

Acceptance: -

ID: 1.1.1_FUNC_JOB_02 Name: job_interface

Description: The PIM shall represent the interface of jobs.


Rationale: This is the base of component integration. Components that are not part of the DAS will be described in the PIM as external services.

Assumptions: -

Additional info: This attribute can be used to describe the application programming interface expected by the job (e.g. Interface File System, LIN API).

Link to: -

Priority: high

Submitter: TUVI, BUTE

Acceptance: -

ID: 1.1.1_FUNC_JOB_03 Name: job_produce/publish_property

Description: The PIM shall represent the produce/publish property of jobs.


Rationale: The messages and data streams produced by the job.

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: TUVI

Acceptance: -

ID: 1.1.1_FUNC_JOB_04 Name: job_consumer/subscriber_property

Description: The PIM shall represent the consumer/subscribe property of jobs.


Rationale: The messages and data streams consumed by the job.

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: TUVI

Acceptance: -



3.3.3.3 Message related requirements

ID: 1.1.1_FUNC_MESS_01 Name: message

Description: The PIM shall represent messages.


Rationale: -

Assumptions: -

Additional info: -

Link to: -

Priority: high


Acceptance: -

ID: 1.1.1_FUNC_MESS_02 Name: message_elements

Description: Messages shall consist of primitive elements.


Rationale: -

Assumptions: -

Additional info: -

Link to: -

Priority: high


Acceptance: -

ID: 1.1.1_FUNC_MESS_03 Name: message_producer

Description: The PIM shall represent the producers of a specific message.


Rationale: -

Assumptions: -

Additional info: -

Link to: -

Priority: high


Acceptance: -

ID: 1.1.1_FUNC_MESS_04 Name: message_consumer

Description: The PIM shall represent the consumers of a specific message.


Rationale: -

Assumptions: -

Additional info: -

Link to: -

Priority: high


Acceptance: -

ID: 1.1.1_FUNC_MESS_05 Name: message_transmission_type

Description: The PIM shall represent message transmission types.


Rationale: -

Assumptions: Transmission types are: unicast, multicast, broadcast.

Additional info: -



Link to: DECOS-SP6-REQ-Dx.y-0004, DECOS-SP6-REQ-Dx.y-0005, DECOS-SP6-REQ-Dx.y-0006

Priority: high

Submitter: BUTE, AIRB

Acceptance: -

ID: 1.1.1_FUNC_MESS_06 Name: message_validity_span

Description: The PIM shall represent the validity span of a specific message.


Rationale: Length of time the message remains valid. A data is valid if the time between the reception of this data and the time the application / partition reads this data is lower than a parameter associated to the port and defined as the maximum age of the data.

Assumptions: -

Additional info: -


Priority: high

Submitter: AIRB, TUVI, TTT

Acceptance: -

ID: 1.1.1_FUNC_MESS_07 Name: message_RDA

Description: The PIM shall represent the properties of a message that are needed to decide the Replica Determinism Algorithm if needed.


Rationale: E.g. can it be averaged or not. One should decide the algorithm here, just give hints to the transformation to choose the most appropriate one.

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: BUTE, TTT

Acceptance: -

ID: 1.1.1_FUNC_MESS_08 Name: message_types

Description: Messages shall have types.


Rationale: -

Assumptions: Message types are: job-job, sensor-job, job-actuator, interrupt.

Additional info: -

Link to: -

Priority: high

Submitter: BUTE

Acceptance: -

ID: 1.1.1_FUNC_MESS_09 Name: message_job-job

Description: Job-job messages shall have subtypes.


Rationale: -

Assumptions: Job-job messages subtypes are: state message, event message.

Additional info: -

Link to: -

Priority: high

Submitter: BUTE

Acceptance: -

ID: 1.1.1_FUNC_MESS_10 Name: message_dependency

Description: The PIM shall represent a “depends” relation amongst messages.




Rationale: Sequence constraints for messages. This is required for functional design.

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: TTT

Acceptance: -

ID: 1.1.1_FUNC_MESS_11 Name: inter-system_communication

Description: The Communication Bus System shall support all types of inter-system communication including periodic and aperiodic data transfer.


Rationale: -

Assumptions: -

Additional info: -


Priority: -

Submitter: AIRB

Acceptance: -

ID: 1.1.1_FUNC_MESS_12 Name: message_transmission_mechanism

Description: The PIM shall represent the transmission mechanism of messages.


Rationale: Control flow in relation to data flow for message transmission (information push or information pull mechanism).

Assumptions: Transmission mechanisms are: push, pull.

Additional info: -

Link to: -

Priority: high

Submitter: TUVI

Acceptance: -

ID: 1.1.1_FUNC_MESS_13 Name: message_reception_mechanism

Description: The PIM shall represent the reception mechanism of messages.


Rationale: Control flow in relation to data flow for message transmission (information push or information pull mechanism).

Assumptions: Reception mechanisms are: push, pull.

Additional info: -

Link to: -

Priority: high

Submitter: TUVI

Acceptance: -

ID: 1.1.1_FUNC_MESS_14 Name: message_sender_status

Description: The PIM shall represent the sender status of messages.


Rationale: Specifies if a sender-status information is transmitted along with the message. A sender-status allows the sending host to tell the receivers of the message that the message value is not valid (low quality).

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: TTT

Acceptance: -



ID: 1.1.1_FUNC_MESS_15 Name: message_phase_shift

Description: The PIM shall represent the phase shift of messages.


Rationale: Phase shift relationship to construct phase-aligned transactions.

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: TUVI

Acceptance: -

3.3.3.4 Element related requirements

ID: 1.1.1_FUNC_ELEM_01 Name: element

Description: The PIM shall represent primitive elements.


Rationale: Messages are built of these primitive elements.

Assumptions: -

Additional info: -

Link to: -

Priority: high


Acceptance: -

ID: 1.1.1_FUNC_ELEM_02 Name: element_type

Description: The PIM shall represent the type / syntax of a primitive element.


Rationale: The syntactic description of an element denotes the structure of the element as a combination of predefined data types (e.g. octet, integer, float, string) and other elements.

Assumptions: -

Additional info: -

Link to: -

Priority: high


Acceptance: -

ID: 1.1.1_FUNC_ELEM_03 Name: element_size_type

Description: The PIM shall represent the size type of a primitive element.


Rationale: The size of the element is either fixed or variable.

Assumptions: Size type is: fixed, variable.

Additional info: -

Link to: -

Priority: high

Submitter: TUVI

Acceptance: -

ID: 1.1.1_FUNC_ELEM_04 Name: element_length

Description: The PIM shall represent the length / size of a primitive element.


Rationale: Only relevant for fixed length messages.

Assumptions: -

Additional info: -



Link to: -

Priority: high


Acceptance: -

ID: 1.1.1_FUNC_ELEM_05 Name: element_initial_value

Description: The PIM shall represent the initial value of a primitive element.


Rationale: -

Assumptions: -

Additional info: -

Link to: -

Priority: high


Acceptance: -

3.3.3.5 Node and resource related requirements

ID: 1.1.1_FUNC_NODE_01 Name: resource

Description: The PIM shall represent resources.


Rationale: Resource is an abstract device. Resource description is needed to be able to map jobs to nodes that have a specific device that is needed by a job. A job using a sensor or actuator can be found by locating the jobs that send / receive messages to / from a sensor / actuator.

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: BUTE

Acceptance: -

3.3.3.6 Data stream requirements

ID: 1.1.1_FUNC_STREAM_01 Name: data_stream

Description: The PIM shall describe data streams.


Rationale: Data stream is the specialization of message.

Assumptions: -

Additional info: -

Link to: -

Priority: high


Acceptance: -

3.3.4 Performance requirements

3.3.4.1 DAS performance requirements



ID: 1.1.1_PERF_DAS_01 Name: das_operating_mode

Description: The PIM shall represent operating mode performance requirements of DASs.


Rationale: -

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: BUTE

Acceptance: -

3.3.4.2 Job performance requirements

ID: 1.1.1_PERF_JOB_01 Name: job_schedulability

Description: The PIM shall represent properties of jobs that are needed for schedulability analysis.


Rationale: -

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: BUTE

Acceptance: -

ID: 1.1.1_PERF_JOB_02 Name: job_period

Description: The PIM shall represent the period of jobs.


Rationale: Execution period of the job.

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: TUVI

Acceptance: -

ID: 1.1.1_PERF_JOB_03 Name: job_phase

Description: The PIM shall represent the phase of jobs.


Rationale: Phase shift relationship to construct phase-aligned transactions.

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: TUVI

Acceptance: -

ID: 1.1.1_PERF_JOB_04 Name: job_outgoing_bandwidth

Description: The PIM shall represent the outgoing bandwidth of jobs.


Rationale: Bandwidth required to ensure extensibility for additional messages and data streams.

Assumptions: -

Additional info: -



Link to: -

Priority: high

Submitter: TUVI

Acceptance: -

ID: 1.1.1_PERF_JOB_05 Name: job_incoming_buffering

Description: The PIM shall represent buffering capacity for incoming messages of jobs.


Rationale: The size of the incoming message queues.

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: TUVI

Acceptance: -

ID: 1.1.1_PERF_JOB_06 Name: job_outgoing_buffering

Description: The PIM shall represent buffering capacity for outgoing messages of jobs.


Rationale: The size of the outgoing message queues.

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: TUVI

Acceptance: -

3.3.4.3 Message performance requirements

ID: 1.1.1_PERF_MESS_01 Name: message_schedulability

Description: The PIM shall represent properties of messages that are needed for schedulability analysis.


Rationale: -

Assumptions: -

Additional info: -

Link to: -

Priority: high


Acceptance: -

ID: 1.1.1_PERF_MESS_02 Name: message_period

Description: The PIM shall represent the period of messages.


Rationale: Transmission period of the message.

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: TUVI

Acceptance: -

ID: 1.1.1_PERF_MESS_03 Name: message_interarrival_time

Description: The PIM shall represent the interarrival time of messages.




Rationale: Minimum time between transmissions of the message.

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: TUVI

Acceptance: -

ID: 1.1.1_PERF_MESS_04 Name: message_service_time

Description: The PIM shall represent the service time of messages.


Rationale: Maximum time between fetch operations for the message.

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: TUVI

Acceptance: -

ID: 1.1.1_PERF_MESS_05 Name: message_latency_time

Description: The PIM shall represent the latency of messages.


Rationale: Maximum permitted time between transmission and reception of the message.

Assumptions: -

Additional info: -


Priority: high

Submitter: TUVI, AIRB

Acceptance: -

3.3.4.4 Data stream performance requirements

ID: 1.1.1_PERF_STREAM_01 Name: data_stream_bandwidth

Description: The PIM shall represent the bandwidth requirement of a data stream.


Rationale: -

Assumptions: -

Additional info: Bandwidth means effective bandwidth, that is, protocol overhead and other platform specific overheads are not included.

Link to: -

Priority: high


Acceptance: -

ID: 1.1.1_PERF_STREAM_02 Name: data_stream_jitter

Description: The PIM shall represent the jitter requirement of a data stream.


Rationale: Needed to determine buffer sizes.

Assumptions: -

Additional info: -

Link to: -

Priority: high



Submitter: BUTE

Acceptance: -

ID: 1.1.1_PERF_STREAM_03 Name: data_stream_latency

Description: The PIM shall represent the latency requirement of a data stream.


Rationale: -

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: BUTE

Acceptance: -

3.3.5 Dependability requirements

3.3.5.1 DAS dependability requirements

ID: 1.1.1_DEP_DAS_01 Name: das_operating_mode

Description: The PIM shall represent the operating mode dependability requirements of DASs.


Rationale: -

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: BUTE

Acceptance: -

ID: 1.1.1_DEP_DAS_02 Name: das_sil

Description: The PIM shall represent the Safety Integrity Level (SIL) of DASs.


Rationale: A classification number which determines the techniques and measures that have to be applied in order to reduce residual software faults to an appropriate level.

Assumptions: -

Additional info: -

Link to: -

Priority: high


Acceptance: -

ID: 1.1.1_DEP_DAS_03 Name: dual_redundancy

Description: All system functions shall be implemented with at least dual redundancy, except if the aircraft can be dispatched following loss of the function, without any time limitation and without any operational consequence.


Rationale: -

Assumptions: The application will be developed for aircraft.

Additional info: -


Priority: -

Submitter: AIRB



Acceptance: -

ID: 1.1.1_DEP_DAS_04 Name: das_failure_mode

Description: The PIM shall represent the failure mode of DASs.


Rationale: -

Assumptions: Failure modes are: fail-silent, fail-safe, etc.

Additional info: -

Link to: -

Priority: high

Submitter: BUTE

Acceptance: -

3.3.5.2 Job dependability requirements

ID: 1.1.1_DEP_JOB_01 Name: job_failure_mode

Description: The PIM shall represent the failure mode of a job.


Rationale: -

Assumptions: Failure modes are: fail-silent, fail-safe, etc.

Additional info: -

Link to: -

Priority: high

Submitter: BUTE

Acceptance: -

3.3.5.3 Message dependability requirements

ID: 1.1.1_DEP_MESS_01 Name: message_idempotency

Description: The PIM shall represent whether a message is idempotent.


Rationale: -

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: BUTE

Acceptance: -

ID: 1.1.1_DEP_MESS_02 Name: message_redundancy

Description: The PIM shall represent the redundancy degree of messages.


Rationale: Number of channels for transmission of this message.

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: TTT

Acceptance: -



3.3.5.4 Data stream dependability requirements

ID: 1.1.1_DEP_STREAM_01 Name: data_stream_error_rate

Description: The PIM shall represent the error rate requirement of a data stream.


Rationale: -

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: BUTE

Acceptance: -

3.3.6 Diagnostic Requirements

The integrated diagnostic services of the DECOS integrated architecture support both application and system specific diagnosis. While system specific diagnosis focuses on the detection of internal and external hardware faults, the discrimination between hardware and software faults, and the detection of precursors for pending hardware problems (i.e. condition based maintenance), the task of the application diagnosis as part of the PIM is to reveal application-specific hardware and software faults.

ID: 1.1.1_DEP_DIAG_01 Name: symptom_name

Description: The symptom name should uniquely identify the symptom.

Responsibility: BUTE, TUVI

Rationale: The domain element symptom has an attribute called name that has the type text.

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: TUVI

Acceptance: -

ID: 1.1.1_DEP_DIAG_02 Name: symptom_expression

Description: The symptom expression should define the relationship in time, space, and value of interface state variables.


Rationale: The domain element symptom has an attribute called expression that has the type of text.

Assumptions: -

Additional info: -

Link to: -

Priority: High

Submitter: TUVI

Acceptance: -

ID: 1.1.1_DEP_DIAG_03 Name: ONA_name

Description: The Out-of-Norm Assertion (ONA) name should uniquely identify the ONA.


Rationale: The domain element ONA has an attribute called name that has the type of text.

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: TUVI



Acceptance: -

ID: 1.1.1_DEP_DIAG_04 Name: ONA_expression

Description: The ONA expression defines the relationship in time, space, and value of symptoms.


Rationale: The domain element ONA has an attribute called expression that has the type of text.

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: TUVI

Acceptance: -

ID: 1.1.1_DEP_DIAG_05 Name: job_diagnostic_output

Description: The diagnostic output of the job is optional diagnostic information, provided in addition to the diagnostic information gathered at the architecture level.


Rationale: The domain element job has an attribute called diagnostic output that has the type of message.

Assumptions: -

Additional info: -

Link to: -

Priority: high

Submitter: TUVI

Acceptance: -



4 Relation to modeling standards

Modeling technology standards are important in order to provide widely accepted up-to-date modeling and model based development technology for the user. The accordance with these standards is a key element to the portability, interchangeability and reusability of the model.

4.1 MOF

The Meta-Object Facility (MOF) is a standard of the Object Management Group (OMG) - www.omg.org/mof. The MOF specification defines an abstract language and a framework for specifying, constructing, and managing technology neutral metamodels. Since the proposed DECOS PIM and PIM metamodel should be technology independent, MOF seems to be a natural mean to describe DECOS applications. A metamodel is in effect an abstract language for some kind of metadata. Examples include the metamodels for UML, CWM, SysML and the MOF itself.

The specification of MOF includes the following DECOS relevant aspects:

♦ a formal definition of the MOF meta-metamodel; that is, the abstract language for specifying MOF metamodels,

♦ an XMI format for MOF metamodel interchange.

The XML Metadata Interchange (XMI) specification defines technology mappings from MOF metamodels to XML DTDs (Document Type Definition) and XML documents. These mappings can be used to define an interchange format for metadata conforming to a given MOF metamodel (see more in the section about XML).

UML and MOF are normally viewed in the context of a conceptual layered metadata architecture. Although the metamodels for MOF and UML are designed to be architecturally aligned, sharing a common subset of core object modeling constructs, this does not bind the modeler to stick to UML as the modeling language. Just on the contrary, the whole metamodeling mechanism is useful to provide a common modeling framework where model instantiation can occur using different modeling languages.

The classical framework for metamodeling is based on an architecture with four metalayers. These layers are conventionally described as follows:

1. the information layer with the data that should be described;

2. the model layer with an abstract representation of the data in the information layer;

3. the metamodel layer with the descriptions that define the structure and semantics of metadata;

4. the meta-metamodel layer with the description of the structure and semantics of meta-metadata.

Figure 4 describes this classical four layer framework.



Figure 4: MOF 4-layer framework (source: MOF Specification by OMG [MOF 2002])

As the first adopted technologies specified using a metamodeling approach, the UML, MOF, and XMI provide the foundation for OMG's Metamodel Driven Architecture (MDA) - see the section about MDA. Future metamodel standards should reuse MOF and UML’s core semantics and emulate their systematic approach to architecture alignment.

The PIM metamodel by its construction corresponds to the third layer of the 4-layer MOF metamodeling framework. As the MOF metamodel has a strong correlation with UML so has the DECOS PIM metamodel too. Please note again, that this strong correlation does not automatically impose that the modeling language, i.e. the concrete syntax and semantics of the language that is used to describe the model, of DECOS is UML. The result of work package WP1.1 in the DECOS project provides a PIM metamodel and additionally as a usage example of this metamodel of how to incorporate it into a given modeling language as extension, a UML profile for DECOS that extends UML by the aspects of the PIM metamodel.

4.2 MDA

The Model-Driven Architecture (MDA) is a specification of the Object Management Group (OMG) - www.omg.org/mda. MDA starts with the well-known and long established idea of separating the specification of the operation of a system from the details of the way that system uses the capabilities of its platform.

MDA provides an approach for and enables tools to be provided for:

♦ specifying a system independently of the platform that supports it,

♦ specifying platforms,

♦ choosing a particular platform for the system, and

♦ transforming the system specification into one for a particular platform.

The three primary goals of MDA are:

♦ portability,

♦ interoperability,

♦ reusability.

According to all of the above MDA suits very well to be the methodological base behind the suggested DECOS tool chain and product development life-cycle. The notions of PIM, PSM, and PIM to PSM transformation of the DECOS project proposal fit perfectly to the MDA approach.



The main concepts of MDA are (excerpts from the specification):

system - A system may include anything that exists or is planned to exist: a program, a single computer system, some combination of parts of different systems, a federation of systems, each under separate control, people, an enterprise, a federation of enterprises.

model - A model of a system is a description or specification of that system and its environment for some certain purpose. A model is often presented as a combination of drawings and text. The text may be in a modeling language or in a natural language.

application - An application is a functionality being developed. A system is described in terms of one or more applications supported by one or more platforms.

platform - A platform is a set of subsystems and technologies that provide a coherent set of functionality through interfaces and specified usage patterns, which any application supported by that platform can use without concern for the details of how the functionality provided by the platform is implemented.

platform independent model - A platform independent model is a view of a system from the platform independent viewpoint. A PIM exhibits a specified degree of platform independence so as to be suitable for use with a number of different platforms of similar type.

platform specific model - A platform specific model is a view of a system from the platform specific viewpoint. A PSM combines the specifications in the PIM with the details that specify how that system uses a particular type of platform.

platform model - A platform model provides a set of technical concepts, representing the different kinds of parts that make up a platform and the services provided by that platform. It also provides, for use in a platform specific model, concepts representing the different kinds of elements to be used in specifying the use of the platform by an application. A platform model also specifies requirements on the connection and use of the parts of the platform, and the connections of an application to the platform.

model transformation - Model transformation is the process of converting one model to another model of the same system.

implementation - An implementation is a specification, which provides all the information needed to construct a system and to put it into operation.

MDA is said to be model-driven because it provides a means for using models to direct the course of understanding, design, construction, deployment, operation, maintenance and modification. It suggests using different models at the different levels of abstraction and at different phases of development during system development. The process of development will consist of the composition and refinement of models. Transformations serve as means of progressive refinement of models from abstract, platform independent, requirement centric towards concrete, platform specific, implementation centric.

The DECOS model application workflow strongly resembles the suggestion of MDA. Therefore the usage of MDA (how the MDA models relate to each other and how they are used, how model transformation is done) is discussed in more details in the section of "Application workflow".

4.3 UML

The Unified Modeling Language (UML) is a standard of the Object Management Group (OMG) - www.omg.org/uml. UML is a visual language for specifying, constructing and documenting the artifacts of systems. It is a general-purpose modeling language that can be used with all major object and component



methods, and that can be applied to all application domains and implementation platforms. During the last few years UML has emerged as the software industry’s dominant modeling language. It is widely accepted among system designers, analysists and programmers. The UML specification is defined using a metamodeling approach that adapts formal specification techniques. While this approach lacks some of the rigor of a formal specification method, it offers the advantages of being more intuitive and pragmatic for most implementors and practitioners.

In the DECOS project UML was selected as the description format of the PIM metamodel due to its wide acceptance in the system designer community; natural correspondence to metamodeling, especially MOF; well elaborated extensibility and broad tool support. This way the PIM metamodel has a semi-formal description that can be combined with the power of Object Constraint Language (OCL) in order to define a more rigorous syntax.

Using this UML description, tool vendors can take the metamodel and implement it according to the input language of their modeling tool. One such implementation is done in the framework of DECOS workpackage 1.1 where as a descriptive example UML was chosen to be enriched by the notions of the PIM metamodel. The result is a profile called UML profile for DECOS. UML tools that can utilize the profiling mechanism can import this UML profile for DECOS. Modelers can use the extended tool to capture the requirements of DASs of DECOS.

4.4 XML/XMI

The Extensible Markup Language (XML) is a W3C recommendation - www.w3c.org/xml. XML is a subset / application profile of Standard Generalized Markup Language (SGML) [ISO 8879]. Its goal is to enable generic SGML to be served, received, and processed on the Web. XML has been designed for ease of implementation and for interoperability with both SGML and HTML. XML describes a class of data objects called XML documents and partially describes the behavior of computer programs which process them. By design, XML documents are conforming SGML documents.

XML documents are made up of storage units called entities, which contain either parsed or unparsed data. Parsed data is made up of characters, some of which form character data, and some of which form markup. Markup encodes a description of the document's storage layout and logical structure. XML provides a mechanism to impose constraints on the storage layout and logical structure.

The DECOS related properties of XML are:

♦ XML supports a wide variety of applications.

♦ XML documents are easy to create.

♦ XML documents are human-legible and reasonably clear.

♦ It is easy to write programs which process XML documents.

♦ The XML design can be prepared quickly.

♦ The design of XML is formal and concise.

The XML Metadata Interchange (XMI) is a standard of the Object Management Group (OMG) - www.omg.org/xmi. XMI is a widely used interchange format for sharing data object using XML. Sharing objects in XML is a comprehensive solution that builds on sharing data with XML. XMI is applicable to a wide variety of data objects: analysis, software, components, and databases.

XMI defines many of the important aspects involved in describing data objects in XML:

♦ The representation of data objects in terms of XML elements and attributes is the foundation.



♦ Since objects are typically interconnected, XMI includes standard mechanisms to link data objects within the same file or across files.

♦ Object identity allows data objects to be referenced from other data objects in terms of IDs and UUIDs.

♦ The versioning of data objects and their definitions is handled by the XMI model.

♦ Validation of XMI documents using DTDs and Schemas.

XMI is a model driven XML integration framework for defining, interchanging, manipulating and integrating XML data and objects. XMI-based standards are in use for integrating tools, repositories, applications and data warehouses. The XMI standard provides rules by which a schema can be generated for any valid XMI-transmissible MOF-based metamodel.

The primary role of XMI in DECOS modeling is the support of integration of different tools by allowing the interchange of PIM among the different tools of the tool chain or even between different tools of different providers.

Furthermore the validation of the produced XML file is part of the verification which proves that the model data conforms to a metamodel. Certainly such checking alone cannot assure that the transferred information satisfies all the semantic constraints of the metamodel - see the proposed role of OCL. However the constraints (i.e. rules formulated in OCL) necessary for the full semantic check can be encoded in the schema manually and thus transferred from one tool to the other.



5 PIM metamodel

5.1 General introduction of the metamodel

In order to achieve a technology-invariant system design of the final application, its DECOS architecture design starts with a Platform Independent Model (PIM) of each Distributed Application Subsystem (DAS). As part of this activity the core operational semantics of the desired system services is captured.

At the beginning, a specification model (metamodel) for PIM is developed, which permits not only to capture PIM in a uniform way, but also to support the transformation to Platform Specific Models (PSM) as well as both PIM and PSM verification.

The design and the PIM to the PSM mapping consist of three parallel parts:

♦ Functional design: The functional specifications in the PIM should be satisfied by proper function allocation, configuration of the communication network and set-up of the (encapsulated) execution environment.

♦ Performance related design: The performance specifications in the PIM should be satisfied by proper resource allocation, communication and task scheduling according to the resource attributes offered by the platform.

♦ Dependability related design: The dependability specifications in the PIM should be satisfied by proper fault-tolerance techniques (redundancy management) that are selected on the basis of the available dependability attributes and failure modes of the platform.

Accordingly the PIM metamodel is built of 3 interdependent packages: the functionality package, the dependability package and the performance package. They are described in detail in the following chapters.

5.2 Detailed description of the PIM metamodel

5.2.1 Explanation of model elements

If possible, we refer to the DECOS Technology Paper for definitions. This is the document that should serve as a common reference for definitions. Definitions are typeset in italic and where not noted differently are cited from the technology paper.

The metamodel consists of three packages, see Figure 5. The FUNCTIONALITY package contains the model elements that describe the purely functional part of the design. The other two packages depend on the functionality package, because they use some of its elements. The PERFORMANCE and DEPENDABILITY packages introduce elements that describe the performance and dependability related aspects of the elements, respectively.



Functionality

Performance Dependability

Figure 5: Packages of the PIM metamodel

In general, every entity in the DAS has a name that uniquely identifies it. Moreover, they have a description field that can be used by the designer to embed documentation in the model.

5.2.1.1 Functionality package

Figure 6: Content of the functionality package

A DAS in the PIM represents a Distributed Application Subsystem. The definition of Distributed Application Subsystem is:

“A Distributed Application Subsystem (DAS) is a nearly independent distributed subsystem of a large distributed real-time system that provides a well-specified application service. Examples of DASs in a present day automotive application are body electronics, the power-train system, and the multimedia system. Examples of DASs in a present day avionic application are the cabin pressurization system, the fly-by-wire



system, and the in-flight entertainment system. DASs are often developed by different organizational entities (e.g., by different vendors) and maintained by different specialists. DAS may use different platform services, e.g., different communication protocols and real-time operating systems. Since DASs may be of different criticality (e.g., vehicle dynamics control vs. multimedia system), the probability of error propagation across DAS boundaries must be sufficiently low to meet the dependability requirements. Error propagation is prevented by encapsulating DASs and assigning a private execution domain (partitions for jobs) and a virtual network to each DAS. A DAS can be implemented as a stand-alone system on its own self-contained hardware base (nodes, networks in a federated architecture) or a DAS can coexist with other DAS in a shared integrated architecture. Different DAS communicate across well-defined interfaces.”

It is reflected in the PIM so that a DAS is a set of logically cohesive JOBS. This is denoted by the aggregation relation from Job to DAS.

A DAS has OPERATINGMODES. It is represented by the aggregation relation from OperatingMode to DAS. Some examples of operating modes are: normal operation, startup, flashing, maintenance, degraded. The specific jobs of the DAS run in these operating modes. It means that a different set of jobs can be run in different operating modes. It is represented by the association RUNSIN between Job and OperatingMode.

Possible operating mode changes are described in the model by using the AFTER association that denotes a transition between the operating modes. The initial operating mode always has to be defined. This is denoted by the INITIAL association between DAS and OperatingMode.

An ABSTRACTUNIT is an abstract entity, that serves metamodeling purposes solely, namely to describe the common features of jobs and RESOURCES. It is described by the inhertance relation between Job and AbstractUnit as well between Resource and AbstractUnit. Abstract units cannot be placed into a model.

The definition of Job is:

“A job is a software subsystem of a DAS and the basic unit of distribution. A job is also the object of temporal and spatial partitioning and executes within a partition, i.e. an encapsulated execution space in a component with statically fixed communication and component resources. The integrated system architecture treats jobs as black boxes. A job interacts with other jobs solely by the exchange of messages via ports provided by complex connector units or safety-critical connector units. In order to support legacy integration, a job can be assigned a virtual machine, inside which the job executes together with a secondary operating system. An example for a job in a safety-critical brake-by-wire DAS of a car would be the software, which fits into a single partition, for computing the brake force based on the actual wheel slip. For fault-tolerance reasons, multiple instances of the job will be executed redundantly at different components, e.g., three instances in a triple-modular redundancy configuration.”

That is, jobs are stand-alone, schedulable software entities which communicate with each other. There are two types of jobs: TIMETRIGGEREDJOB and EVENTTRIGGEREDJOB. It is described by the inheritance relation between Job and TimeTriggeredJob as well between Job and EventTriggeredJob.

Jobs can have STATEVARIABLES. It is described by the aggregation relation from StateVariable to Job. A state variable is a primitive type, its type and length is supplied by the designer. The initial value of the state variable can be defined too. A state variable can be fixed or variable in length. The possible values of state variables form the state space of the job. The values of the state variables at a particular instant denote the state of the system at that instant. The DECLAREDSTATE is a projection of the state that is relevant for the future behaviour of the system. The declared state is defined as:

“The declared state is the state of a subsystem, which is considered as relevant by the system designer for future behavior of the subsystem (forward view).”



State declaration is done by defining an expression (STATEDECLARATION) over the set of state variables. It is denoted by the association between StateVariable and DeclaredState and the association class StateDeclaration. State declaration is a specialization of ASSERTIONS.

Jobs can have INTERFACES. It is described by the aggregation relationship between Interface and Job. The definition of interface is as follows:

“An interface is a common boundary between two subsystems and consists of one or more ports. The interface to the controlled object is denoted as the controlled object interface (COI). An interface for the interconnection of jobs is denoted as a linking interface (LIF) [Kopetz and Suri, 2003]. A job exploits the services of other jobs via service requesting linking interfaces (SRLIFs) and offers its own services via service providing linking interfaces (SPLIFs).”

There are five types of Interfaces, Service Providing Linking Interface (SPLIF), Service Requesting Linking Interface (SRLIF), Controlled Object Interface (COI), Configuration Planning interface (CP) and Diagnostic and Management interface (DM). SPLIF, SRLIF, COI, CP and DM are specializations of Interface. Four of these five interfaces serve for job-job communication. The controlled object interface is for communicating with SENSORS and/or ACTUATORS. Sensor and Actuator are specializations of Resource. Resource itself is an abstract entity; it will never be used by the designer. It is used to group resource-like entities together. Currently, two types of resources are defined, Sensor and Actuator, but this is a primary point of extension, since the product of resource modeling activities can appear here in a complete tree structure.

An interface consists of one or more PORTS through which jobs communicate. It is described by the aggregation relation between Port and Interface. The definition of port is the following:

“A port is an access point where a job reads/consumes an input message (input port) or writes/produces an output message (output port). A port to a time-triggered virtual network is a state message port, while a port to an event-triggered virtual network is denoted as an event message port.”

Through the ports, MESSAGES can be sent or received to or from other ports. Two ports can be used for communication if they belong to different jobs and use the same message type. Ports can see the state variables of the job they are assigned to. It is described by the ISVISIBLE assocaiton between StateVariable and Port. Actually, the state variables of the port are a subset of the state variables of the job the port is assigned to. This way a clear distinction can be done between the state of a LIF and the state of the job.

Over the state variables expressions can be defined that poses restrictions on the value of the variables. This is represented by the class ACCEPTANCECRITERIA holding the expression. Using this, it can be checked, whether the interface is in a specific state (i.e. if all the expressions on the values are satisfied). This way operational input assertions on interfaces / ports can be realized. Please note that as a special case, an expression can contain a constant value.

The image or the change of state variables can be packed in messages. This way a message can carry the value of one or more variables, and variables can be transmitted through multiple messages. The PARTID identifies the parts of the message. In case of communicating ports, the PartIDs of the message parts must match. STATEMESSAGES carry the image (i.e. the exact copy) of state variables while EVENTMESSAGES carry the change of state variables. It is represented by the associations IMAGE and DELTA respectively.

The definition of state message is:

“A state message is a periodic message that contains state observations. An observation is a state observation, if the value of the observation contains the state of a real-time entity. The time of a state observation denotes the point in time when the real-time entity was sampled. The handling of state messages occurs through an update in place and nonconsuming read.”

The definition of event message is:



“An event message is a message that contains event observations. An event observation contains the difference between the “old state” (the last observed state) and the “new state”. The time of the event observation denotes the point in time of the state change. In order to maintain state synchronization, the handling of event messages requires exactly-once semantics. The arrival of an event message usually gives rise to a control signal, which triggers subsequent computational and communication activities.”

The entity called Message is abstract, therefore it cannot be instantiated. It serves only to describe the common features of state messages and event messages. Both state- and event messages are subtypes of message. Messages can depend on each other, this is represented by the self-association.

A DATASTREAM is a specialization of messages, a data stream consists of periodically sent data chunks. It is described by the specialization relation between Message and DataStream.

ONA (Out-of Norm Assertion) and SYMPTOM are used by the Diagnostics. A symptom is an expression over interface state variables. That is why Symptom is a specialization of Assertion and has an association to StateVariable. An ONA is an expression over symptoms. That is why ONA is a specialization of Assertion and has an association to Symptom.

RESTRICTION expresses an offline restriction, that is, an assertion that will be used as a fact by the analysis.

5.2.1.2 Performance package

DataStream(from Functionality)

DataStreamPerformance

bandwidth : Integer

jitter : Duration

latency : Duration

EventMessage(from Functionality)

EventMessagePerformance

priority : Integer

minimalInterarrivalTime : Duration

meanInterarrivalTime : Duration

maximalInterarrivalTime : Duration

serviceTime : Duration

latencyTime : Duration

StateMessage(from Functionality)

StateMessagePerformance

period : Duration

phaseShift : Duration

Job(from Functionality)

JobPerformance

period : Duration

outgoingBandwidth : Integer

deadline : Duration

WCET : Duration

TimeTriggeredJobPerformance

phase : Double

TimeTriggeredJob

(from Functionality)

dataStreamPerformanceInOperatingMode

0..n0..n

0..n0..n

eventMessagePerformanceInOperatingMode

0..n0..n

0..n0..n

stateMessagePerformanceInOperatingMode

0..n0..n

0..n0..n

jobPerformanceInOperatingMode

0..n0..n

0..n0..n

timeTriggeredJobPerformanceInOperatingMode

0..n0..n

0..n0..n

EventTriggeredJob(from Functionality)

EventTriggeredJobPerformance

priority : Integer

OperatingMode

0..n0..n

eventTriggeredJobPerformanceInOperatingMode

0..n0..n

0..n0..n

Figure 7: Content of the Performance package

Jobs (both event and time triggered), state messages, event messages and data streams have performance requirements in operating modes. These elements can have different performance parameters in different modes. These shall be attached together in the model using the 3-ary association called e.g. JOB

PERFORMANCEINOPERATING MODE for jobs. The performance requirements are contained in classes called TIMETRIGGEREDJOBPERFORMANCE and EVENTTRIGGEREDJOBPERFORMANCE for jobs, STATEMESSAGE

PERFORMANCE for state messages, EVENTMESSAGEPERFORMANCE for event messages and DATASTREAM

PERFORMANCE for data streams.

All of these classes are derived from QOSCHARACTERISTIC, which is defined in the UML Profile for QoS and Fault Tolerance modeling and represents a general entity describing all sorts of QoS values.

5.2.1.3 Dependability package



DataStream(from Functionality)

dataStreamDependability

errorRate : Double

Message(from Functionality)

MessageDependability

idempotent : Boolean

redundacyDegree : Integer

availability : Double

Job(from Functionality)

JobDependability

failureMode : Enum

dataStreamDependabilityInOperatingMode

0..n0..n

0..n0..n

messageDepenadabilityInOperatingMode

0..n0..n

0..n0..n

jobDependabilityInOperatingMode

0..n0..n

0..n0..n

DAS

DASDependability

safetyIntegrityLevel : Integer

redundancyDegree : Integer

failureMode : Enum

availability : Double

noSPOF : Boolean

OperatingMode(from Functionality)

DASDependabilityInOperatingMode

0..n0..n

0..n0..n0..n0..n

Figure 8: Content of the Dependability package

DASs, jobs, messages and data streams have dependability requirements in operating modes. These elements can have different dependability parameters in different modes. These shall be attached together in the model using the 3-ary association called e.g. JOBDEPENDABILITYINOPERATINGMODE for jobs. The performance requirements are contained in classes called DASDEPENDABILITY for DASs, JOBDEPENDABILITY for jobs, MESSAGEDEPENDABILITY for messages and DATA STREAMDEPENDABILITY for data streams.

All of these classes are derived from QOSCHARACTERISTIC, which is defined in the UML Profile for QoS and Fault Tolerance modeling and represents a general entity describing all sorts of QoS values.

5.2.2 Tabular definition of model elements

The following tables list the defined metamodel elements in a tabular format. Please note that the documentation found in these tables is embedded in the metamodel file too.

5.2.2.1 Functionality package

Name DAS

Description A Distributed Application Subsystem.

Superclass -

Name name

Type String

Description Unique name identifying the entity.

Name description

Type String

Description Detailed description of the entity.

Name type

Type String

Attributes

Description Specialized type of the DAS.

DAS types are eg.: time-triggered, event-triggered, Profibus, distributed control, TTA.

Name initial

To OperatingMode

Associations

Multiplicity 1 (DAS); 1 (OperatingMode)



Description Marks the initial operating mode of the DAS.

Job Contains

OperatingMode

Name AbstractUnit

Description Abstract entity describing the common properties of Jobs and Resources.

Superclass -

Name name

Type String


Name description

Type String


Name externalDescriptor

Type String

Attributes

Description URL or file name describing the Component (can be used in transformation and code generation)

Contains Interface

Name Job

Description A job running in the DAS.

Superclass AbstractUnit

Attributes -

Name runsIn

To OperatingMode

Multiplicity 0..n (OperatingMode); 1..n (Job)

Description Marks that a specific Job is running in a specific Operating mode.

Name needs

To Resource

Multiplicity 0..n (Job); 0..n (Resource)

Associations

Description Represents that a Job uses a Resource.

Contains StateVariable

Name TimeTriggeredJob

Description -

Superclass Job

Attributes -

Name EventTriggeredJob

Description -

Superclass Job



Attributes -

Name Interface

Description Abstract entity representing linking-, control-, configuration-, and diagnostic interfaces. An Interface is a common boundary between two DASs and consists of one or more ports.

Superclass -

Attributes -

Contains Port

Name SPLIF

Description Service Providing Linking Interface. Can be used to provide services to others.

Superclass Interface

Attributes -

Name SRLIF

Description Service Requesting Linking Interface. Can be used to use other's services.


Attributes -

Name COI

Description Controlled Object Interface. Can be used to communicate with Resources (e.g. Sensors).


Attributes -

Name CP

Description Configuration Planning interface.


Attributes -

Name DM

Description Diagnostic and Management interface.


Attributes -

Name Resource

Description An abstract device. Resource description is needed to be able to map jobs to a specific device that is needed by a job.

Resource has concrete specializations that can be extended.

Superclass AbstractUnit



Name needs

To Job

Multiplicity 0..n (Job); 0..n (Resource)

Associations

Description Represents that a Job uses a Resource.

Name Actuator

Description An Actuator.

Superclass Resource

Attributes -

Name Sensor

Description A Sensor.

Superclass Resource

Attributes -

Name Port

Description A Port is an access point where a job reads an input message or writes an output message.

Superclass -

Name name

Type String


Name description

Type String


Name direction

Type Enum

Description Direction of communication through the Port. Possible velues: In, Out, Bidirectional

Name incomingBuffer

Type Integer

Description Buffering capacity for incoming messages of the port. (in bytes)

Name outgoingBuffer

Type Integer

Attributes

Description Buffering capacity for outgoing messages of the port. (in bytes)

Name communicate

To Port

Multiplicity 1 (Port); 1..n (Port)

Description Represents that a Port communicates with another Port.

Associations



Name Read

To Message

Multiplicity 0..n (Port); 0..n (Message)

Description Represents that the State Variable is received in the Message.

Name Write

To Message

Multiplicity 0..n (Port); 0..n (Message)

Description Represents that the State Variable is sent in the Message.

Name isVisible

To StateVariable

Multiplicity 0..n (StateVariable); 0..n (Port)

Description Defines if a state variable is visible in the port.

Name StateMessagePort

Description A Port that transmits StateMessages.

Superclass Port

Name EventMessagePort

Description A Port that transmits EventMessages.

Superclass Port

Name StateVariable<T>

Description A State Variable represents a part of the state of a job.

Superclass -

Name name

Type String


Name description

Type String


Name type

Type String

Description Data type of the State Variable.

Name fixedLength

Type Boolean

Description Marks whether the State Variable has fixed length.

Attributes

Name length



Type Integer

Description Length in bits. In case of variable length, it means maximal length.

Name initialValue

Type Depends on the type <T>

Description Initial value of the State Variable.

context StateVariable

inv: T.name = type

Name averagable

Type Boolean

Description Marks whether the values of the State variable can be averaged during an RDA algorithm.

Name -

To AcceptanceCriteria

Multiplicity 0..n (StateVariable); 0..n (AcceptanceCriteria)

Description Acceptance criteria of a received state variable. Can be used in an RDA or to define a State.

Name image

To StateMessage

Multiplicity 0..n (StateVariable); 0..n (StateMessage)

Description A State Message transmits the values of a state variable, that is, it serves as an image of the value.

Name delta

To EventMessage

Multiplicity 0..n (StateVariable); 0..n (EventMessage)

Description An Event Message transmits the change of a state variable.

Name -

To DeclaredState

Multiplicity 1..n (StateVariable); 0..n (DeclaredState)

Description A declared state consists of expressions restricting the values of state variables.

Name -

To Restriction

Multiplicity 0..n (StateVariable); 0..n (Restriction)

Description Represents an offline constraint for a state variable that can be used during analysis.

Name -

To Symptom

Multiplicity -

Description -

Associations



Name isVisible

To Port

Multiplicity 0..n (StateVariable); 0..n (Port)

Description Defines if the state variable is visible in a port.

Name DeclaredState

Description Represents a well defined state of the job. It can restrict the value of the state variables to satisfy a given expression.

Superclass -

Name name

Type String


Name description

Type String

Attributes


Name -

To StateVariable

Multiplicity 1..n (StateVariable); 0..n (State)

Associations

Description A State consists of expressions restricting the values of StateVariables.

Name Message

Description Abstract message entity.

Superclass -

Name name

Type String


Name description

Type String


Name transmissionType

Type Enum

Description Transmission type of the message.

Possible values are: Unicast, multicast or broadcast.

Name validitySpan

Type Duration

Description Length of the time the message remains valid.

Name senderStatus

Attributes

Type Boolean



Description Specifies if a sender-status information is transmitted along with the message.

Name depends

To Message

Multiplicity 0..n (Message); 0..n (Message)

Description Message depends on Message.

Name Read

To Port

Multiplicity 0..n (Message); 0..n (Port)

Description Represents that the State Variable is received in the Message.

Name Write

To Port

Multiplicity 0..n (Message); 0..n (Port)

Associations

Description Represents that the State Variable is sent in the Message.

Name StateMessage

Description A State Message.

Superclass Message

Attributes -

Name image

To StateVariable

Multiplicity 0..n (StateVariable); 0..n (StateMessage)

Associations

Description A State Message transmits the values of a State Variable, that is, it serves as an image of the value.

Name Event message

Description An Event Message.

Superclass Message

Attributes -

Name delta

To StateVariable

Multiplicity 0..n (StateVariable); 0..n (EventMessage)

Associations

Description An Event Message transmits the change of a State Variable.

Name MessagePartIdImage

Description Identifies the StateVariable in the Message.

Superclass -

Name PartID

Type String

Attributes

Description Identifies the StateVariable in the Message.

Name (association class) Associations

To StateVariable, StateMessage



Description -

Name MessagePartIdDelta

Description Identifies the state variable in the event message.

Superclass -

Name PartID

Type String

Attributes

Description Identifies the state variable in the event message.

Name (association class)

To StateVariable, EventMessage

Associations

Description -

Name DataStream

Description A Data Stream.

Superclass Message

Attributes -

Name OperatingMode

Description An operating mode of a DAS.

Superclass -

Name name

Type String


Name description

Type String

Attributes


Name initial

To DAS

Multiplicity 1 (Operating mode); 1 (DAS)

Description Marks the initial operating mode of the DAS.

Name after

To Operating mode

Multiplicity 1 (Operating mode); 1..n (Operating mode)

Description Marks the possible operating mode changes.

Name runsIn

To Job

Multiplicity 1..n (OperatingMode); 1..n (Job)

Associations

Description Marks that a specific job runs in a specific operating mode.



Name Assertion

Description An abstract assertion expression.

Superclass -

Name name

Type String


Name description

Type String


Name expression

Type String

Attributes

Description Defines the relationship in time, space, and value of state variables.

Name Symptom

Description An observable effect of a fault which is available for further handling by the system.

Superclass Assertion

Attributes -

Name -

To ONA

Description -

Name -

To StateVariable

Associations


Name Restriction

Description Represents an offline constraint for a StateVariable that can be used during analysis.


Attributes -

Name -

To StateVariable

Multiplicity 0..n (Restriction); 0..n (StateVariable)

Associations


Name AcceptanceCriteria

Description AcceptanceCriteria of a received state variable. Can be used in an RDA or to define a State.


Attributes -

Name - Associations

To StateVariable



Multiplicity 0..n (AcceptanceCriteria); 0..n (StateVariable)

Description Acceptance criteria of a received state variable. Can be used in an RDA or to define a State.

Name StateDeclaration

Description Declaration for the value of a state variable in a declared state.


Attributes -

Name (as an association class)

To State, StateVariable

Associations


Name ONA

Description Out-of Norm Assertion.


Attributes -

Name -

To Symptom

Associations

Description Defines the relationship in time, space, and value of symptoms.

5.2.2.2 Performance package

Name JobPerformance

Description Performance properties of a Job.

Superclass QoSCharacteristic

Name period

Type Duration

Description Execution period of job.

Name outgoingBandwidth

Type Integer

Description Bandwidth required to ensure extensibility for additional messages and data streams. This can be used to override the transformation in assigning the minimal required bandwidth, and to provide spare bandwidth to the Job with a possible extension in mind. (in bit/s)

Name deadline

Type Duration

Description The time instant until which the job should finish.

Name WCET

Type Duration

Attributes

Description Worst Case Execution Time

Associations Name JobPerformanceInOperatingMode



To Job, OperatingMode

Description Required performance parameters of a Job in a specific Operating mode.

Name TimeTriggeredJobPerformance

Description Performance properties of a time triggered job

Superclass JobPerformance

Name phase

Type Double

Attributes

Description Phase shift relation to construct phase-aligned transactions. Optional, percentage of period when to start, expressed as Real [0.0..1.0]

Name TimeTriggeredJobPerformanceInOperatingMode

To TimeTriggeredJob, OperatingMode

Associations

Description Required performance parameters of a time triggered job in a specific Operating mode.

Name EventTriggeredJobPerformance

Description Performance properties of an event triggered job

Superclass JobPerformance

Name priority

Type Double

Attributes

Description Phase shift relation to construct phase-aligned transactions. Optional, percentage of period when to start, expressed as Real [0.0..1.0]

Name EventTriggeredJobPerformanceInOperatingMode

To EventTriggeredJob, OperatingMode

Associations

Description Required performance parameters of a time triggered job in a specific Operating mode.

Name StateMessagePerformance

Description Performance properties of a State message.


Name period

Type Duration

Description Transmission period of the message.

Name phaseShift

Type Duration

Attributes

Description Phase shift relationship.

Name StateMessagePerformanceInOperatingMode

To State message, OperatingMode

Associations

Description Required performance parameters of a State message in a specific Operating mode.



Name EventMessagePerformance

Description Performance properties of an Event message.


Name priority

Type Integer

Description Abstract priority level. Can be mapped to concrete priority values of an implementation technology.

Name minimalInterarrivalTime

Type Duration

Description Minimum time between transmissions of the message.

Name meanInterarrivalTime

Type Duration

Description Mean time between transmissions of the message.

Name maximalInterarrivalTime

Type Duration

Description Maximal time between transmissions of the message.

Name serviceTime

Type Duration

Description Maximum time between fetch operations for the message.

Name latencyTime

Type Duration

Attributes

Description Maximum permitted time between transmission and reception of the message.

Name EventMessagePerformanceInOperatingMode

To EventMessage, OperatingMode

Associations

Description Required performance parameters of an Event message in a specific Operating mode.

Name DataStreamPerformance

Description Performance properties of a Data stream.


Name bandwidth

Type Integer

Description Bandwidth requirement of the data stream.

Effective bandwidth that is, protocol overhead and other platform specific overheads are not included. (in bit/s)

Name jitter

Type Duration

Description Jitter requirement of the data stream.

Attributes



Name latency

Type Duration

Description Latency requirement of a data stream.

Name DataStreamPerformanceInOperatingMode

To DataStream, OperatingMode

Associations

Description Required performance parameters of a Data stream in a specific Operating mode.

5.2.2.3 Dependability package

Name DASDependability

Description Dependability properties of a DAS.

Superclass

Name safetyIntegrityLevel

Type Integer

Description Safety Integrity Level (0-4).

Name redundancyDegree

Type Integer

Description Minimal redundancy degree for all components of the DAS.

(optional, should be filled in by the transformation based on dependability if empty)

Name availability

Type Double

Description Availability requirement of the DAS.

Name noSPOF

Type Boolean

Attributes

Description Expresses that a DAS cannot have a Single Point of Failure.

Name DASDependabilityInOperatingMode

To DAS, OperatingMode

Associations

Description Required dependability parameters of a DAS in a specific Operating mode.

Name JobDependability

Description Dependability properties of a Job.

Superclass

Name failureMode

Type Enum

Attributes

Description Failure mode of the Job. Possible values are e.g.: fail-silent, fail-safe

Name JobDependabilityInOperatingMode

To Job, OperatingMode

Associations

Description Required dependability parameters of a Job in a specific Operating mode.



Name MessageDependability

Description Dependability properties of a Message.

Superclass

Name idempotent

Type Boolean

Description Marks whether the message is idempotent.

Name redundancyDegree

Type Integer

Description Represents the redundancy degree of the message. If this value is set to 2, then two instances of the message will be transmitted. This attribute is optional, should be filled in by the transformation based on dependability if empty

Name availability

Type Double

Attributes

Description Availability requirement of the Message.

Name MessageDependabilityInOperatingMode

To Message, OperatingMode

Associations

Description Required dependability parameters of a Message in a specific Operating mode.

Name DataStreamDependability

Description Dependability properties of a Data stream.

Superclass

Name errorRate

Type Double

Attributes

Description Error rate requirement of the data stream.

Name DataStreamDependabilityInOperatingMode

To DataStream, OperatingMode

Associations

Description Required dependability parameters of a Data stream in a specific Operating mode.

5.3 Implementation of PIM requirements

5.3.1 Common requirements

5.3.1.1 General requirements

The general requirements describe the way of creating the metamodel and regulate the way a PIM is composed.



ID: 1.1.1_GEN_01 Name: requirements

Description: The PIM shall represent the requirements for the DASs.

Solution: The PIM does not describe implementation details, only the requirements for the system.

ID: 1.1.1_GEN_02 Name: platform_independency

Description: The PIM shall be platform-independent.

Solution: The PIM does not contain any references to platforms or technologies. After finalizing a PIM the elements can be marked to give control information to the PIM-PSM transformation process on the deployment of a function onto a particular platform.

ID: 1.1.1_GEN_03 Name: paradigm_independency

Description: The PIM shall be paradigm-independent.

Solution: The concepts in the PIM do not restrict the implementation to either TT or ET. A system described by the PIM can be implemented by using any feasible technology.

ID: 1.1.1_GEN_04 Name: description

Description: Every entity shall have a description / specification field.

Solution: Every entity has a description field where documentation can be inserted. The actual content of documentation is subject of a later agreement. It will contain of informal and / or formal descriptions. (In case of subclasses, description isn’t redefined because it inherits it from the parent)

ID: 1.1.1_GEN_05 Name: name

Description: Every entity shall have a name field.

Solution: Every entity has a name field. Assuring that this name is unique is the task of the modeling tool, or a syntax checker. (In case of subclasses, name isn’t redefined because it inherits it from the parent)

ID: 1.1.1_GEN_06 Name: verifiability

Description: The PIM shall be verifiable in order to enable component-based verification of subsystems. This may affect in particular the technology/methodology decision.

Solution: UML is an open standard, and the standard XMI exchange format assures the interoperability of different tools, moreover it supports the transformation of models to any other format that can be verified with existing or future verification tools.

ID: 1.1.1_GEN_07 Name: extensibility

Description: The PIM shall be modifiable and extensible.

Solution: The proposed metamodel can be modified and extended later as a need arises for changing. Moreover, the PIM is generic enough to be able to describe a wide variety of systems.

ID: 1.1.1_GEN_08 Name: xml_syntax

Description: XML based syntax definition of the metamodel.

Solution: XMI serves as an XML based exchange format as it is standardized and most UML modeling tools support it. Conformance can be checked using a DTD, moreover, a rigorous syntax check assures the compliance with the metamodel.

5.3.1.2 Technology and design methodology requirements

The following table lists the technologies and design methodologies that the PIM shall / should support in order to be able to use it in the everyday work of project partners. The transformation will transform the PIM to the input model of these supported technologies and methodologies.

ID: 1.1.1_TECHN_01 Name: MATLAB_Simulink

Description: MATLAB/Simulink support shall be provided.

Solution: The proposed metamodel is a structured ontology of the DECOS related concepts. It is independent of the actual modeling paradigm used. The UML profile is one type of representation of the concepts contained in the metamodel. One can specialize Simulink to enhost the metamodel concept independently of the UML profile. Moreover, a UML model compliant with the profile can be transformed to Simulink if needed.



ID: 1.1.1_TECHN_02 Name: Simulink_Stateflow

Description: Simulink/Stateflow support shall be provided.

Solution: The proposed metamodel is a structured onthology of the DECOS related concepts. It is independent of the actual modeling paradigm used. The UML profile is one type of representation of the concepts contained in the metamodel. One can specialize Simulink to enhost the metamodel concept independently of the UML profile. Moreover, a UML model compliant with the profile can be transformed to Simulink if needed.

ID: 1.1.1_TECHN_03 Name: Simulink_Coder

Description: MATLAB/Simulink-Coder support shall be provided.

Solution: The proposed metamodel is a structured onthology of the DECOS related concepts. It is independent of the actual modeling paradigm used. The UML profile is one type of representation of the concepts contained in the metamodel. One can specialize Simulink to enhost the metamodel concept independently of the UML profile. Moreover, a UML model compliant with the profile can be transformed to Simulink if needed.

ID: 1.1.1_TECHN_04 Name: SCADE dataflow

Description: SCADE support shall be provided.

Solution: Esterel Technologies are currently developing a UML profile. As soon as it will be ready, a transformation between the PIM and that profile can be developed.

ID: 1.1.1_TECHN_05 Name: SCADE CG

Description: SCADE Code Generator support shall be provided.


ID: 1.1.1_TECHN_06 Name: SCADE SSM

Description: SCADE Safe State Machines support shall be provided.


ID: 1.1.1_TECHN_07 Name: TTP_support

Description: All services, functionalities and tools of TTP shall be supported by all DECOS developments.

Solution: The PIM represents generic entities that build up a system that can be implemented on any platform, including TTP.

5.3.1.3 Identification of standards

Since the PIM is platform independent it shall not support specific technology standards, but it should cover the functionality of the following standards in order to help the application of the standard during the design.

ID: 1.1.1_STAND_01 Name: UML_SPT

Description: The PIM shall support the UML Profile for Schedulability, Performance, and Time Specification

Solution: The PIM does not contradict the guidelines of the SPT profile, the elements defined can be expressed as specialized types of that profile. On the other hand, the SPT profile defines not only the performance requirements of a system but the performance provided by resources, which is not the aim of the PIM.

Moreover, the UML Profile for QoS (which is used in the PIM) uses the concepts defined in the Profile for PST.

ID: 1.1.1_STAND_02 Name: TTP/C

Description: The PIM shall support the TTP/C standard.

Solution: The PIM represents generic entities that build up a system that can be implemented on any platform, including TTP.

ID: 1.1.1_STAND_03 Name: CAN

Description: The PIM shall support the CAN Specification Version 2.0.



Solution: The PIM represents generic entities that build up a system that can be implemented on any platform, including CAN.

ID: 1.1.1_STAND_04 Name: LIN

Description: The PIM shall support the LIN Specification Package Revision 1.3.

Solution: The PIM represents generic entities that build up a system that can be implemented on any platform, including LIN.

ID: 1.1.1_STAND_05 Name: Profibus

Description: The PIM shall support the Profibus standard.

Solution: The PIM represents generic entities that build up a system that can be implemented on any platform, including Profibus.

ID: 1.1.1_STAND_06 Name: FlexRay

Description: FlexRay support shall be provided.

Solution: The PIM represents generic entities that build up a system that can be implemented on any platform, including FlexRay.

ID: 1.1.1_STAND_07 Name: internet_protocol

Description: The PIM shall support Internet Protocols (e.g., TCP/IP, UDP).

Solution: Providing support for specific protocols is the task of the PIL, message transmissions described in the PIM can be implemented over any protocol, including TCP/IP or UDP.

ID: 1.1.1_STAND_08 Name: DO-178B

Description: DO-178B support shall be provided.

Solution: This happens by transforming the PIM of critical parts to DO-178D compliant tools.

ID: 1.1.1_STAND_09 Name: compliance

Description: To satisfy all validation & verification, safety, certification and legal requirements all tools, applications, software and hardware developed in DECOS subprojects shall show compliance to the documents relevant to safety critical system design in the target field of application.

Solution: This happens by transforming the PIM of critical parts to DO-178D compliant tools. Additionally an analysis will be provided comparing the DECOS metamodel and designed UML profile with SysML an evolving standard in the field.

5.3.2 Functional requirements

5.3.2.1 DAS related requirements

The system consists of DASs that can interact and cooperate.

ID: 1.1.1_FUNC_DAS_01 Name: das

Description: The PIM shall represent DASs.

Solution: The PIM has an entity called DAS that represents DASs.

ID: 1.1.1_FUNC_DAS_02 Name: das_type

Description: The PIM shall represent DAS types.

Solution: DAS has an attribute called type that describes the DAS type.

ID: 1.1.1_FUNC_DAS_03 Name: das_interface

Description: The PIM shall represent the interface of DASs to the environment and to each other.

Solution: A DAS consists of jobs that can have Interfaces to the environment and each other.

ID: 1.1.1_FUNC_DAS_04 Name: das_operating_mode

Description: The PIM shall represent operating modes of DASs.

Solution: There is an entity called OperatingMode that can be attached to a DAS.

ID: 1.1.1_FUNC_DAS_05 Name: das_initial_operating_mode



Description: The PIM shall represent the initial operating mode of DASs.

Solution: The association called “initial” between DAS and OperatingMode shows the initial operating mode.

ID: 1.1.1_FUNC_DAS_06 Name: das_operating_mode_change

Description: The PIM shall represent operating mode changes of DASs.

Solution: The association “after” between OperatingModes shows the possible operating mode changes.

5.3.2.2 Job related requirements

DASs are composed of communicating jobs.

ID: 1.1.1_FUNC_JOB_01 Name: job

Description: The PIM shall represent jobs.

Solution: The PIM has an entity called Job that represents Jobs.

ID: 1.1.1_FUNC_JOB_02 Name: job_interface

Description: The PIM shall represent the interface of jobs.

Solution: Jobs can have interfaces to the environment and each other.

ID: 1.1.1_FUNC_JOB_03 Name: job_produce/publish_property

Description: The PIM shall represent the produce/publish property of jobs.

Solution: The messages and data streams produced by a job can be found through its Interfaces, Ports and the State variables that are mapped to messages.

ID: 1.1.1_FUNC_JOB_04 Name: job_consumer/subscriber_property

Description: The PIM shall represent the consumer/subscribe property of jobs.

Solution: The messages and data streams consumed by a job can be found through its Interfaces, Ports and the State variables that are mapped to messages.

5.3.2.3 Message related requirements

ID: 1.1.1_FUNC_MESS_01 Name: message

Description: The PIM shall represent messages.

Solution: The PIM has an entity called Message that represents Messages. Moreover, it has subtypes StateMessage and EventMessage.

ID: 1.1.1_FUNC_MESS_02 Name: message_elements

Description: Messages shall consist of primitive elements.

Solution: Both StateMessages and EventMessages consist of StateVariables that can be thought as elements of messages.

ID: 1.1.1_FUNC_MESS_03 Name: message_producer

Description: The PIM shall represent the producers of a specific message.

Solution: The Job producing a message can be found through its Ports and Interfaces.

ID: 1.1.1_FUNC_MESS_04 Name: message_consumer

Description: The PIM shall represent the consumers of a specific message.

Solution: The Job consuming a message can be found through its Ports and Interfaces.

ID: 1.1.1_FUNC_MESS_05 Name: message_transmission_type

Description: The PIM shall represent message transmission types.

Solution: Message has an attribute called transmission type that describes the transmission type of a Message.

ID: 1.1.1_FUNC_MESS_06 Name: message_validity_span

Description: The PIM shall represent the validity span of a specific message.



Solution: Message has an attribute called validity span that describes the validity span of a Message.

ID: 1.1.1_FUNC_MESS_07 Name: message_RDA

Description: The PIM shall represent the properties of a message that are needed to decide the Replica Determinism Algorithm if needed.

Solution: Since messages can consist of multiple data elements that can have different RDA requirements, these are placed in StateVariables. StateVariable has an attribute called averagable that describes whether the values of multiple instances of the data can be averaged or not (e.g. a variable consisting of binary flags can not be averaged). Moreover, expressions called Acceptance criteria can be attached. These together should make it possible to determine the possible RDA algorithms in a specific case, from which one should be chosen during the transformation.

ID: 1.1.1_FUNC_MESS_08 Name: message_types

Description: Messages shall have types.

Solution: The composite type of a message is determined by its consisting elements.

ID: 1.1.1_FUNC_MESS_09 Name: message_job-job

Description: Job-job messages shall have subtypes.

Solution: The entity Message has two subtypes, namely State message and Event message.

ID: 1.1.1_FUNC_MESS_10 Name: message_dependency

Description: The PIM shall represent a “depends” relation amongst messages.

Solution: There can be an association between Messages called depends, that expresses this relation.

ID: 1.1.1_FUNC_MESS_11 Name: inter-system_communication

Description: The Communication Bus System shall support all types of inter-system communication including periodic and aperiodic data transfer.

Solution: The entity message has two subtypes, namely state message and event message. State message is for periodic, event message is for aperiodic data transfer.

ID: 1.1.1_FUNC_MESS_12 Name: message_transmission_mechanism

Description: The PIM shall represent the transmission mechanism of messages.

Solution: The transmission mechanism of a message element is determined by the association it is connected to the message (namely read or write). Transmission mechanism of the message depends on the transmission mechanism of its elements.

ID: 1.1.1_FUNC_MESS_13 Name: message_reception_mechanism

Description: The PIM shall represent the reception mechanism of messages.

Solution: The reception mechanism of a message element is determined by the association it is connected to the message (namely read or write). Reception mechanism of the message depends on the reception mechanism of its elements.

ID: 1.1.1_FUNC_MESS_14 Name: message_sender_status

Description: The PIM shall represent the sender status of messages.

Solution: Message has an attribute called sender status that describes the need for a senderStatus in a Message.

ID: 1.1.1_FUNC_MESS_15 Name: message_phase_shift

Description: The PIM shall represent the phase shift of messages.

Solution: State message has an attribute called phaseShift that describes the phase shift of a State message.

5.3.2.4 Element related requirements

ID: 1.1.1_FUNC_ELEM_01 Name: element

Description: The PIM shall represent primitive elements.

Solution: Messages consist of the representations of StateVariables thus they can be thought of as elements of message.



ID: 1.1.1_FUNC_ELEM_02 Name: element_type

Description: The PIM shall represent the type / syntax of a primitive element.

Solution: StateVariable has an attribute called type that describes the type of a StateVariable.

ID: 1.1.1_FUNC_ELEM_03 Name: element_size_type

Description: The PIM shall represent the size type of a primitive element.

Solution: StateVariable has an attribute called fixed length that shows whether it is fixed or variable in length.

ID: 1.1.1_FUNC_ELEM_04 Name: element_length

Description: The PIM shall represent the length / size of a primitive element.

Solution: StateVariable has an attribute called length that describes the length of a StateVariable.

ID: 1.1.1_FUNC_ELEM_05 Name: element_initial_value

Description: The PIM shall represent the initial value of a primitive element.

Solution: StateVariable has an attribute called initial value that describes the initial value of a StateVariable.

5.3.2.5 Node and resource related requirements

ID: 1.1.1_FUNC_NODE_01 Name: resource

Description: The PIM shall represent resources.

Solution: The PIM has an entity called Resource that represents resources.

5.3.2.6 Data stream requirements

ID: 1.1.1_FUNC_STREAM_01 Name: data_stream

Description: The PIM shall describe data streams.

Solution: The PIM has an entity called Data stream that represents data streams.

5.3.3 Performance requirements

5.3.3.1 DAS performance requirements

ID: 1.1.1_PERF_DAS_01 Name: das_operating_mode

Description: The PIM shall represent operating mode performance requirements of DASs.

Solution: The performance requirements of the DAS components can be attached to the DAS and the Operating mode using the appropriate connections (see the Performance package).

5.3.3.2 Job performance requirements

ID: 1.1.1_PERF_JOB_01 Name: job_schedulability

Description: The PIM shall represent properties of jobs that are needed for schedulability analysis.

Solution: Job has attributes describing the period and phase of a Job. These are enough to perform scheduling in a time triggered environment.

ID: 1.1.1_PERF_JOB_02 Name: job_period

Description: The PIM shall represent the period of jobs.

Solution: Job has an attribute called period that describes the period of a job.



ID: 1.1.1_PERF_JOB_03 Name: job_phase

Description: The PIM shall represent the phase of jobs.

Solution: TimeTriggeredJob has an attribute called phase that describes the phase of a job.

ID: 1.1.1_PERF_JOB_04 Name: job_outgoing_bandwidth

Description: The PIM shall represent the outgoing bandwidth of jobs.

Solution: Job has an attribute called outgoing bandwidth that describes the outgoing bandwidth requirement of a job.

ID: 1.1.1_PERF_JOB_05 Name: job_incoming_buffering

Description: The PIM shall represent buffering capacity for incoming messages of jobs.

Solution: Port has an attribute called incoming buffer that describes the size of the incoming buffer required by a port. The total bandwidth requirement of a job is the sum of it’s ports’.

ID: 1.1.1_PERF_JOB_06 Name: job_outgoing_buffering

Description: The PIM shall represent buffering capacity for outgoing messages of jobs.

Solution: Port an attribute called outgoing buffer that describes the size of the outgoing buffer required by a job. The total bandwidth requirement of a job is the sum of it’s ports’.

5.3.3.3 Message performance requirements

ID: 1.1.1_PERF_MESS_01 Name: message_schedulability

Description: The PIM shall represent properties of messages that are needed for schedulability analysis.

Solution: Both state messages and event messages have attributes that should be enough to do scheduling in either a time triggered or event triggered environment.

ID: 1.1.1_PERF_MESS_02 Name: message_period

Description: The PIM shall represent the period of messages.

Solution: State message has an attribute called period that describes the period of a state message.

ID: 1.1.1_PERF_MESS_03 Name: message_interarrival_time

Description: The PIM shall represent the interarrival time of messages.

Solution: Event message has attributescalled minimalInterarrivalTime, meanInterarrivalTime and maximalInterarrivalTime that describe the interarrival time of an event message.

ID: 1.1.1_PERF_MESS_04 Name: message_service_time

Description: The PIM shall represent the service time of messages.

Solution: Event message has an attribute called serviceTime that describes the service time of an event message.

ID: 1.1.1_PERF_MESS_05 Name: message_latency_time

Description: The PIM shall represent the latency of messages.

Solution: Event message has an attribute called latencyTime that describes the maximal latency of an event message.

5.3.3.4 Data stream performance requirements

ID: 1.1.1_PERF_STREAM_01 Name: data_stream_bandwidth

Description: The PIM shall represent the bandwidth requirement of a data stream.

Solution: Data stream has an attribute called bandwidth that describes the bandwidth requirement of a data stream.

ID: 1.1.1_PERF_STREAM_02 Name: data_stream_jitter

Description: The PIM shall represent the jitter requirement of a data stream.

Solution: Data stream has an attribute called jitter that describes the maximal jitter requirement of a data stream.



ID: 1.1.1_PERF_STREAM_03 Name: data_stream_latency

Description: The PIM shall represent the latency requirement of a data stream.

Solution: Data stream has an attribute called latency that describes the latency requirement of a data stream.

5.3.4 Dependability requirements

5.3.4.1 DAS dependability requirements

ID: 1.1.1_DEP_DAS_01 Name: das_operating_mode

Description: The PIM shall represent the operating mode dependability requirements of DASs.

Solution: The dependability requirements of the DAS components can be attached to the DAS and the Operating mode using the appropriate connections (see the Dependability package).

ID: 1.1.1_DEP_DAS_02 Name: das_sil

Description: The PIM shall represent the Safety Integrity Level (SIL) of DASs.

Solution: DAS has an attribute called safety integrity level that describes the safety integrity level of a DAS.

ID: 1.1.1_DEP_DAS_03 Name: dual_redundancy

Description: All system functions shall be implemented with at least dual redundancy, except if the aircraft can be dispatched following loss of the function, without any time limitation and without any operational consequence.

Solution: DAS has an attribute called redundancyDegree that describes the redundancy degree of a DAS.

ID: 1.1.1_DEP_DAS_04 Name: das_failure_mode

Description: The PIM shall represent the failure mode of DASs.

Solution: DAS has an attribute called failure mode that describes the failure mode of a DAS.

5.3.4.2 Job dependability requirements

ID: 1.1.1_DEP_JOB_01 Name: job_failure_mode

Description: The PIM shall represent the failure mode of a job.

Solution: Job has an attribute called failure mode that describes the failure mode of a job.

5.3.4.3 Message dependability requirements

ID: 1.1.1_DEP_MESS_01 Name: message_idempotency

Description: The PIM shall represent whether a message is idempotent.

Solution: Message has an attribute called idempotency that describes whether the message is idempotent.

ID: 1.1.1_DEP_MESS_02 Name: message_redundancy

Description: The PIM shall represent the redundancy degree of messages.

Solution: Message has an attribute called redundancy degree that describes the redundancy degree of the message.

5.3.4.4 Data stream dependability requirements



ID: 1.1.1_DEP_STREAM_01 Name: data_stream_error_rate

Description: The PIM shall represent the error rate requirement of a data stream.

Solution: Data stream has an attribute called error rate that describes the error rate requirement of the data stream.

5.3.4.5 Diagnostic Requirements

The integrated diagnostic services of the DECOS integrated architecture support both application and system specific diagnosis. The following table defines the requirements that are necessary to describe the diagnostic services.

ID: 1.1.1_DEP_DIAG_01 Name: symptom_name

Description: The symptom name should uniquely identify the symptom in the DAS.

Solution: The PIM has an entity called Symptom that represents symptoms.

ID: 1.1.1_DEP_DIAG_02 Name: symptom_expression

Description: The symptom expression should define the relationship in time, space, and value of interface state variables.

Solution: Symptom has an attribute called expression that holds the expression of the symptom.

ID: 1.1.1_DEP_DIAG_03 Name: ONA_name

Description: The ONA name should uniquely identify the ONA in the DAS.

Solution: The PIM has an entity called ONA that represents ONAs. As every entity in the PIM, it has a name attribute that identifies it.

ID: 1.1.1_DEP_DIAG_04 Name: ONA_expression

Description: The ONA expression defines the relationship in time, space, and value of symptoms.

Solution: ONA is a subtype of Assertion which has an attribute called expression that holds the expression of the ONA.

ID: 1.1.1_DEP_DIAG_05 Name: job_diagnostic_output

Description: The diagnostic output of the job is optional diagnostic information, provided in addition to the diagnostic information gathered at the architecture level.

Solution: On Interface type is Diagnostic and Management interface that can be used to transmit diagnostic information. Every job can have this type of interface.



6 Relation to domain specific standards

6.1 Importance of standards

DECOS provides a dependable architecture and development framework for embedded systems. During the development process following the DECOS approach, the PIM metamodel and the tools that implement the PIM metamodel play a very important role. This is the primary means for capturing the requirements. Therefore the PIM metamodel, the PIM and the PIM development tools are related to some extent to the standards of embedded, dependable, real-time applications.

Since the PIM metamodel and the PIM model are platform independent they must not support specific technology standards, but they should cover the functionality of the corresponding standards in order to help the application of the standard during the design.

Related standards can be divided into two main groups:

1. Standards that describe the development of dependable, real-time, embedded systems. They describe the different steps of the development and prescribe some tasks that has to be done at a given development step.

2. Standards that describe the way of metamodeling and model based development. They are mainly technology related standards and gives help implement a standardized, up-to-date modeling technology that yields models that can be interchanged between different modeling and development tools.

6.2 Development standards

6.2.1 DO-178B

DO-178B, Software Considerations in Airborne Systems and Equipment Certification, published by RTCA, provides guidelines for the production of airborne systems equipment software. It is used internationally to specify the safety and airworthiness of software for avionics systems. It describes techniques and methods appropriate to ensure the integrity and reliability of such software. It has been used to secure FAA approval of digital computer software.

The guidelines for software development and verification are described for each of six software levels. Level A is used when anomalous behavior causes catastrophic failure condition. Level E is used when anomalous behavior has no effect on operational capacity. Guidelines are provided in the areas of software planning, development, verification, configuration management, quality assurance, certification, and maintenance. The guideline defines processes where safety is the Focus. The processes are imposed so that safety is designed into a product. A System Safety Assessment process is required to associate criticality levels with the various system elements.

The guidelines impose criteria on the software life-cycle processes to ensure that the development results in a safe system. The processes can be categorized as developmental or integral. Figure 9 illustrates the basic elements of a software life-cycle model, independent from a prescribed software engineering method. This model reflects the basic activities of capturing the requirements and performing design, implementation, and integration. It is not intended to imply the "waterfall" model or a particular development methodology. The relative size of each activity is not meant to be representative of any collected data; it is strictly used to illustrate the concurrent nature of the activities in the software development process. The software development activities are the main product-oriented activities and can have some degree of parallelism. The other integral processes (e.g., verification, configuration management, quality assurance) provide



software engineering process support that helps ensure the completeness and quality of the software development activities. A productive process uses a constructive approach that satisfies the completion criteria of the integral processes (e.g., testing, verification, etc.) during the software development activities.

Figure 9: Development life-cycle according to DO-178B

There is also a requirement to perform tool qualification if a tool is used to automate software development processes that are typically performed by humans. Tool Operational Requirements must be provided, and the tool must be verified against the operational requirements.

The PIM and the PIM metamodel themselves should allow their usage in a product development life-cycle that corresponds to DO-178B. Since PIM construction is mainly a mean for requirement formulation, the tools that implement the PIM metamodel for some modeling language in order to create the PIM of a DECOS application are not used to automate software development processes. Therefore these tools should not be certified according to DO-178B.

Actually, DO-178B support happens by transforming the PIM of critical parts to DO-178D compliant tools that can be used to automate some software development steps like code generation. The models generated by the suggested approach will be transformed during the synthesis process to the input language of a certified paradigm in a human readable form. This way the approach supports the reuse of existing certified industrial tools without the immediate need to certify the entire tool chain used in the workflow. Obviously this does not exclude the certification of the tools used in the initial phases of the workflow if needed, but it is unfeasible in the framework of the current project. As a summary, certification will be assured by reusing best practice of certified tools.

6.2.2 ISO/IEC 61508

The international standard IEC 61508, Functional Safety of Electrical/Electronic/ Programmable Electronic (E/E/PE) safety-related systems aims to:

♦ release the potential of E/E/PE technology to improve both safety and economic performance;

♦ enable technological developments to take place within an overall safety framework;

♦ provide a technically sound, system based approach, with sufficient flexibility for the future;

♦ provide a risk-based approach for determining the required performance of safety-related systems;

♦ provide a generically-based standard that can be used directly by industry but can also help with developing sector standards (e.g. machinery, process chemical plants, medical or rail) or product standards (e.g. power drive systems);



♦ provide a means for users and regulators to gain confidence when using computer based technology;

♦ provide requirements based on common underlying principles

IEC 61508 covers the whole safety lifecycle of an installation from initial concept, to hazard analysis and risk assessment, development of the safety requirements, specification, design and implementation, operation and maintenance, and modification, to final decommissioning and/or disposal.

The relation of IEC 61508 to PIM and PIM metamodel is identical with that of DO-178B; it makes its application possible but it does not have direct implication on PIM. A concrete support for the application of IEC 61508 is the possibility to define the SIL levels the standard suggests to use.

6.2.3 SAExx

For the full list of these standards see the requirement specification of PIM (Section 3 of this document). The correspondence to these standards occurs similarly to the case of DO-178B.

6.2.4 Implementation technology standards

Implementation technology standards are a subset of the development technology standards, they correspond to the implementation phase of the development. Despite of this fact there are a few from the point of view of DECOS important standards (see Section 3) we have to mention:

♦ CAN

♦ Profibus

♦ LIN

♦ FlexRay

♦ TTP

They are all related to possible implementation platforms. Since the PIM is platform independent it should not contain any platform specific details and these standards do not relate to the PIM metamodel directly. However each implementation on the above platforms should be described by PIM, therefore the PIM metamodel should cover the union of abstracted features of these platforms in order to support all possible constructs of them.

6.3 SysML

6.3.1 Introduction

The System Modeling Language (SysML) is a general-purpose modeling language for systems engineering applications. SysML aims to support the specification, analysis, design, verification and validation of a broad range of large and complex systems that include hardware and software components.

SysML is being defined by the “SysML Partners” which is an informal partnership of organizations, including large and well-known companies like IBM, Motorola, I-Logix, Gentleware, Telelogic, from the field of aerospace and defense: Boeing, Nasa/Jet Propulsion Laboratory, BAE Systems, Northrop Grumman, THALES etc. (the whole list of SysML partners is enumerated on the www.sysml.org website).



The original aim of the SysML initiative was to customize the Unified Modeling Language (UML) for systems engineering applications. This collaboration resulted in the submission of SysML in response to the OMG’s UML for Systems Engineering Request for Proposal (RFP) issued in 2003.

The latest available version of SysML was submitted to the OMG on the 11th of October 2004., It is available

for download from the above mentioned website.

SysML is architecturally aligned with the evolving ISO AP-233 data interchange standard for systems engineering in order to support interoperability between systems engineering tools and other tools that interface with them.

Since our aim in the DECOS project is to propose a PIM metamodel, which is able to describe complex, embedded, real-time systems from high-level, system wide view, it was obvious to survey the SysML metamodel from the point of view of dependable embedded system design. Our aim was to compare our PIM metamodel with the SysML to detect the newly defined PIM metamodel’s possible defects or to prove its completeness.

The following section gives a brief overview of the SysML metamodel, placing emphasis mainly on the dependable, embedded system specific aspects of this novel proposal. In conclusion a table summarizes the main novelties of SysML with a reference to its analogous PIM elements/properties.

6.3.2 SysML metamodel

The proposed SysML specification is defined as an extension of the UML 2.0 Superstructure Specification (see Figure 10), this way reuses the UML syntax and semantics roles.

<<metamodel>>MOF

<<metamodel>>

UML

<<instanceOf>>

<<import>>

<<instanceOf>>

<<modelLibrary>>

SysML

<<userModel>>

XYZsystem<<reuse>>

<<instanceOf>>

<<metamodel>>

SysML

Figure 10: SysML extension of UML

As shown on the Figure 10 SysML reuses a subset of UML (<<IMPORT>> relationship) and creates extensions to support the specific requirements needed to model complex engineering systems. Several extension mechanisms are used including stereotypes, metaclasses and model libraries. The SysML



stereotypes and metaclasses are instantiated in the <<USERMODEL>> while classes are grouped into subclasses in the <<MODELLIBRARY>>.

The SysML package structure is shown in more details on the Figure 11. Among these packages there are some imported from the UML without any modification, like State Machines, Interactions and Use Cases.

New SysML packages are Requirements, Parametrics and Allocation. The Assemblies package uses structured classes from COMPOSITESTRUCTURES (UML2.0) and contains some minor extensions.

Common

BehaviorsUse Cases

Actions Activities

StateMachines

Auxillary

Constructs

Classes

Requirements

Assemblies

Interactions Parametrics

Allocation

Profiles

<<metamodel>>

SysML

Figure 11: SysML package structure

6.3.3 Comparison of SysML and DECOS PIM

The approach of SysML and the DECOS PIM is somewhat different. SysML targets the definition of a general-purpose modeling language, while the PIM is targeted for the description of distributed, dependable, embedded systems. The designers of SysML do not intend to be more specific than this as can be seen in the SysML proposal:

“This specification defines a general-purpose modeling language for systems engineering applications, called the Systems Modeling Language (SysML). SysML supports the specification, analysis, design, verification and validation of a broad range of complex systems. These systems may include hardware, software, data, personnel, procedures, and facilities.”

However, they leave the specification open for specialization to specific application domains. Because of this generality, there are lots of open points in the specification. SysML is defined as an extension to the UML 2.0 standard, as opposed to our metamodel, which is defined as a general metamodel, that can be mapped to any extensible modeling formalism.

Diagrams



In DECOS PIM most of the UML 2.0 diagrams are used in the same way as used in SysML. The Assembly diagram of SysML is a specialized version of Component diagram, so since in DECOS PIM Component diagrams are used for the same purpose, the difference is minor. As you will see later, in DECOS a Requirement diagram is not used explicitly, rather a possibility to embed this kind of information into the model is offered.

Elements

SysML describes the structure of the system using Assemblies, Parts and Ports. Assembly is the specialization of Class, and contains Parts. The Parts and Assemblies are connected through Ports. Parts can contain more Parts, and using this recursive embedding feature, multi-level hierarchies can be described in the system. In the PIM, the structure of the system is described using DASs and Jobs, and on the other hand, with Nodes and Resources. Jobs are defined as the basic unit of distribution, thus a two level hierarchy can be described. This is in accordance with the DECOS Technology Paper. SysML describes the connections using Ports. We have a two-level hierarchy for this, namely Interfaces and Ports, which allows the partitioning of Ports into logical groups depending on their usage.

SysML uses and slightly specializes the Action semantics and Activity diagrams of standard UML 2.0 for describing the behaviour of the system. Since we do not restrict the usage of the PIM metamodel to UML, the description of behaviour is not defined in it. The current PIM metamodel leaves the description paradigm of the semantics intentionally open, but provides a proper slot (documentation) for the elements. The metamodel compliant implementations of the modeling concept, like the UML profile proposed, can reuse the original semantics of the modeling paradigm extended by the DECOS concepts. If needed a general semantics description language like ASM can be used to provide a uniform semantics definition language out of which the input description of a particular implementation paradigm can be transformed in an automated way.



7 Application workflow

7.1 Interfacing to existing technologies

Openness towards a variety of design and implementation technologies is one of the main objectives of the DECOS initiative. The PIM metamodel as described in Chapter 5, serves as a pilot experiment to indicate the feasibility of merging DECOS concepts with widely used design paradigms and tools supporting it. From the viewpoint of designing non-mission-critical applications such an integration of a general purpose CASE paradigm with the metamodel summarizing the peculiarities of DECOS is the most appropriate solution.

However, one crucial point related to this approach is the fulfillment of the certifiability of the design technologies needed in designing mission-critical applications. Relevant standards, like DO-178B demand an extremely workload intensive certification of all tools used. Additionally, each enterprise working in such a specific application field has already developed his own methodology based on existing, specialized toolsets and paradigms implemented by them. This way, the introduction of a new technology would need an effort most probably unproportional with the benefits reached, at least in the initial few years.

Accordingly, in the DECOS initiative it is recommended that the initial PIM level models, or at least those parts of it which face special certification requirements, should be transformed into a human readable form of some certified tool, for instance SCADE. This generated model should be reviewed to serve as the basis of the certification process.

7.2 Transformational approach

As already discussed in the Section about MDA, development is done by creating and transforming models. A model transformation (i.e. PIM to PSM transformation) is the process of converting one model to another model of the same system. The approach is presented in Figure 12 and is detailed below.

7.2.1 Basic transformation

In the first step a platform independent model, a PIM, is built. It describes the system, but does not show details of its use of its platform. A PIM might consist of enterprise, information and computational ODP (Open Distributed Processing) viewpoint specifications. A platform independent model will be suited for a particular or several architectural styles.

In the second step the developer selects a platform that enables implementation of the system with the desired architectural qualities. The developer will have at hand a model of that platform. Often, at present, this model is in the form of software and hardware manuals or is even in the developer's head. MDA is based on detailed platform models, for example, models expressed in UML and OCL, and stored in a MOF compliant repository.

To each platform a mapping is defined that provides specifications for transformation of a PIM into a PSM for a particular platform. The platform model will determine the nature of the mapping. Model instance mappings will define marks. A mark represents a concept in the PSM, and is applied to an element of the PIM, to indicate how that element is to be transformed. This way marks guide the process of transformation.

In the third step the developer uses the markings that correspond to the selected platform to mark the elements of PIM, generating the so called marked PIM. The marks, being platform specific, are not a part of the platform independent model, but they do not contain enough information about platform details therefore they are neither part of the PSM. The marks can be thought of as being applied to a transparent layer placed over the PIM.



Figure 12: Mapping based transformation of the PIM (source MDA specification [MDA 2001] [MDA2003])

In the forth step the marked PIM is used to prepare a platform specific model for that platform. The marked PIM to PSM transformation uses the platform specific mappings and can be done manually, semi-automatically or automatically. Actually the transformation tool might transform a marked PIM directly to deployable code, without producing a PSM, but usually a PSM is produced in this case to, for use in understanding or debugging the code. Additionally to producing the PIM the transformation also produces a record of transformation that includes a map from the element of the PIM to the corresponding elements of the PSM, and shows which parts of the mapping were used for each part of the transformation.

7.2.2 Usage of patterns

Extension of the model and metamodel mapping approaches include patterns along with the types or the modeling language concepts. In addition to platform independent types, a generic model can supply patterns. Both the types and patterns can be mapped to platform specific types and patterns. In this case PIM modeling language elements are matched to PSM modeling language elements. These matchings are stored as patterns. When the platform is selected the patterns (the matchings of language elements) can be used to mark the PIM and to control the transformation. In this case the names of design patterns that are specific to a platform identify the names of platform specific marks. See Figure 13.

Figure 13: Pattern based transformation of the PIM (source MDA specification [MDA 2001] [MDA2003])



7.2.3 The role of additional information

In both variants, model markings can be stored and subsequent transformations may use these marking, asking only for additional decisions required by additions or changes to the model. In many cases in addition to the PIM and the platform specific marks, additional information should be supplied to guide the transformation. Often the additional information will draw on the practical knowledge of the designer. This will be both knowledge of the application domain and knowledge of the platform.

Figure 14 describes the steps of transformation when additional information is used. The drawing is intended to be suggestive. In the process of preparing a PIM, in addition to using the pattern names provided, other information can be added to produce the marked PIM. More information, in addition to the patterns, can be used when the marked PIM is further transformed to produce the PSM.

Figure 14: The role of additional information in the transformation (source MDA specification [MDA 2001] [MDA2003])

7.3 Example tool chain

The planned DECOS transformation chain, i.e. modeling workflow is depicted in Figure 15 The PIM metamodel is defined in this deliverable. The metamodel covers all planned application domains of DECOS.



í PIM metamodel

PIM

language specific

PIM metamodel

marked PIM

PSM

platform files

conceptual view

engineering view

domain specific

PIM metamodel

Figure 15: DECOS modeling workflow

However developers can optionally define a subset of the metamodel that contains only constructs relevant to their application domain only and does not contain disturbing, unnecessary, irrelevant details from other domains.

DECOS does not force developers to use a given tool to compose the PIM. They can use their favourite, well known design tool that is part of the corporate tool chain. The only restriction for the tool is that its modeling language should be able to handle / express the constructs defined in the metamodel. Such construct is a job for example. The PIM metamodel is described in this document in UML. As a language specific PIM metamodel a UML profile for DECOS is defined in the previous Sections. A further although optional restriction for the tool is that it should be able to import / export the model in XML / XMI format.

The next step in the workflow is to create the PIM in the selected tool using the accustomed modeling formalism. The PIM metamodel can be saved in the format supported by the modeling tool. If for modeling a UML tool is used, it is a further benefit if the tool can handle UML profiles and evaluate OCL expressions. This way the correctness of the PIM regarding the PIM metamodel can be checked automatically on-the-fly and no externet correctness checking is necessary.

Afterwards the developer marks the PIM. In DECOS the platform model will be a model of the Platform Interface Layer (PIL). PIL describes all platform specific details of the DECOS architecture. The developer selects which DASs will be implemented on which platform and marks the elements of the PIM by the corresponding platform names.

Finally the marked PIM to PSM transformation is done. In DECOS this transformation is done semi-automatically in an interactive fashion by asking the developer to assign the values of control variables in order to guide the next step of transformation. The prepared PSM is than the direct source of platform files, e.g. configuration files, executable files, libraries, etc.

7.4 The role of PIM-PSM mapping in the DECOS HW-SW integration

In the results of DECOS workpackage 1.4 a picture is given about the HW-SW integration in DECOS. It is shown in Figure 16. At the top of the Figure one can see the PIMs of the different DASs and the platform model in the form of a PIL description. The transformation from PIM to PSM is called here as HW/SW integration since PIMs describe the functional view of application subsystems, while the PIL description describe the hardware resources and architecture of the underlying platform.



After the integration the PSM will contain the platform specific description of DASs and provides a configuration description for the deployment tools. The deployment tools prepare from the different DAS modules the PIL layer modules and the PIL middleware (API) modules, the software configuration for the different nodes.

PIL for conn. units

DAS jobs + PIL APIs

PIM DAS 1

Resource-

layer spec.

incl.

PIL descr.

HW/SW-

Integration

PSM

PIM DAS k…

…PIL modules

PIL APIs

PIL for conn. units

DAS jobs + PIL APIs

per node

„PIL pool“

DAS 1

modules

DAS k

modules

Deployment

selection/configuration

Figure 16: The role of PIM-PSM mapping during DECOS HW-SW integration



8 An Example PIM

The example model (see Figure 17, Figure 18, Figure 19, Figure 20) is a simplified brake-by-wire system for cars. It contains a single DAS, and 6 jobs. Each wheel has its own job that is responsible for reading the wheel rotate sensor and the brake actuator. There is a separate job for the control algorithm, which calculates the desired brake force.

The wheel jobs have two state variables, one for the current rpm, and one for the brake force. There are also two port, one for reading the rpm, and one for writing the brake force.

The controller job has state variables for all of the rpm and force data, and separate ports for reading and writing their values. It also has a variable for the pedal state, and a port for reading the value.

The pedal job has only one basic function, the reading of the pedal sensors. It has only one port that enables access to the value read.

The dependability and performance measures defined in this model are only examples, and do not comply with the requirements of a real system.

cd fl

Unregistered Trial Version EA 4.50 Unregistered Trial Version










«Job»

FrontLeftWheelJob

«Sensor»

FLWheelSensor

«Actuator»

FLBrakeActuator

FLWheelNodeInterface

«StateMessagePort»

FLRPMPort


FLForcePort

«StateVariable»

brakeForce

tags

type = float

«StateVariable»

rpm

tags

type = float

«isVisible» «isVisible»

«needs»«needs»

Figure 17: Wheel job structure of the example PIM



cd sampleEA 4.50 Unregistered Trial Version EA 4.50 Unregistered Trial Version EA 4.50 Unregistered Trial Version EA 4.50 Unregistered Trial Version

EA 4.50 Unregistered Trial Version EA 4.50 Unregistered Trial Version EA 4.50 Unregistered Trial Version EA 4.50 Unregistered Trial Version




























«Job»

PedalSensorJob

«Job»

ControlJob

«Sensor»

PedalSensor

«Interface»

ControlInterface

«Interface»

PedalInterface

«Interface»

SensorInterface


PedalPort


FLFPort


FRFPort


RLFPort «StateMessagePort»

RRFPort


FLRPort«StateMessagePort»

FRRPort


RLRPort


RRRPort

«Interface»

PedalStateInterface


PedalSensorPort

«StateVariable»

rpmRR

«StateVariable»

rpmLR

tags

type = float

«StateVariable»

rpmLL

tags

type = float

«StateVariable»

rpmLR

tags

type = float

«StateVariable»

forceRL

tags

type = double

type = float

«StateVariable»

forceRR

tags

type = float

«StateVariable»

foreFR

tags

type = float

«StateVariable»

forceFL

tags

type = float

«StateVariable»

pedalState

tags

type = float

«StateVariable»

pedalState

tags

type = float

«needs»

«isVisible»

«isVisible»

«isVisible»

«isVisible»

«isVisible»

«isVisible»

«isvisible»

«isVisible»

«isVisible» «isVisible»

Figure 18: The control and pedal jobs of the exampel PIM



cd messages

EA 4.50 Unregistered Trial Version EA 4.50 Unregistered Trial Version EA 4.50 Unregistered Trial Version




















SensorRPM_FL

«StateVariable<T>»

rpm


FLRPMPort


FLRPort


FLForcePort


FLFPort


brakeForce

«State message»

ActuatorForce_FL


PedalPort


PedalSensorPort

«State message»

PedalMessage


pedalState

«Message Dependabili ty»

SensorRPMDep

tags

idempotent = true

RedundancyDegree = 2

NormalMode

«State message Performance»

ActForceMsgDep

tags

idempotent = true



PedalMsgDep

tags

idempotent = true


«StateMessagePerformance»

ActForceMsgPerf

tags

period = 30 ms«State message Performance»

PedMsgPerf

tags

period = 100 ms


SensorMsgPerf

tags

period = 30 ms

«Acceptance criteria»

ActuatorAccCrit

tags

expression = 0<=value<=1

«Acceptance criteria»

RpmAccCrit

tags

expression = 0<=value<500

«Acceptance cri teria»

PedalStateAccCrit

tags

expression = 0<=value<=1

+write +read

+read

+write

image

image

+write«messageDepenadabil ityInOperatingMode»

image

«stateMessagePerformanceInOperatingMode»


+read

«messageDepenadabil ityInOperatingMode»

«messageDepenadabil ityInOperatingMode»


Figure 19: Message dependability and -performance objects of the example PIM



cd wheelnode





















«Job»

WheelSensorJob

«Job»

WheelActuatorJob

«DAS»

BrakeByWire

«Job»

DiagnosticsJob

NormalMode

«Operating mode»

InitialMode

«Job»

PedalSensorJob

«Job»

ControlJob

«TimeTriggeredJob Performance»

PedalJobPerformance

tags

deadline = 100 ms

outgoingBandwidth = 0

period = 100 ms

phase = 0

WCET = 12 ms


ControlJobPerformance

tags

deadline = 30 ms

period = 30 ms

phase = 0.5

WCET = 26 ms


SensorJobPerformance

tags

deadline = 30 ms

period = 30 ms

phase = 0.2

WCET = 10 ms


ActuatorJobPerformance

tags

deadline = 30 ms

period = 30 ms

phase = 0.3

WCET = 15 ms

«DAS Dependability»

BrakeByWireDep

tags

availabili ty = 99.999

failure mode = fail-safe

noSPOF = yes

redundancy degree = 2

safety integrity level = 3

«runsIn»

«runsIn»«runsIn»

4

«DASRunsJobInOperatingMode»

+after

+initial

«runsIn»

«timeTriggeredJobPerformanceInOperatingMode»

«DASDependabilityInOperatingMode»




Figure 20: Job performance and -dependability objects of the example PIM



9 Abbreviations and Definitions

API Application Programming Interface

DAS Distributed Application Subsystem

DECOS Dependable Embedded Components and Systems

DTD Document Type Definition

FT Fault Tolerant

HIS Hersteller Initiative Software

HL High Level

ISO International Standardisation Organisation

LIN Local Interconnect Network

MDA Model Driven Architecture

MOF Meta Object Facility

OMG Object Management Group

ONA Out of Norm Assertion

OSI Open Systems Interconnect

PI Platform Interface

PIL Platform Interface Layer

PIM Platform Independent Model

PSM Platform Specific Model

QoS Quality of Service

SPOF Single Point Of Failure

UML Unified Modeling Language

XMI XML Metadata Interchange

XML Extensible Markup Language



10 References

[Annex I, 2004]

Annex I – “Description of Work” to DECOS, approved version (“DECOS Annex version 2.0 approved 14.5.04.doc”)

[Kopetz e.a., 2004]

H. Kopetz, R. Obermaisser, P. Peti, N. Suri; From a Federated to an Integrated Architecture for Dependable Real-Time Embedded Systems; as distributed at DECOS kickoff-meeting (“DECOS_Technology.pdf”)

[Bosch 1991] Robert Bosch Gmbh. CAN Specification. Version 2.0. Stuttgart, Germany. 1991.

[Deline 1999]

R.Deline. Resolving Packaging Mismatch. Carnegie Mellon University, Computer Science Department. Pittsburgh. June, 1999.

[Ostroff, 1989] J.S. Ostroff. Verifying finite state real-time discrete event processes. In 9th International Conference on Distributed Computing Systems, pages 207–217, Washington, D.C., USA, June 1989. IEEE Computer Society Press.

[TTTech 2002]

TTTech. Time-Triggered Protocol TTP/C -- High Level Specification Document. July, 2002.

[MDA 2001] Model Driven Architecture [MDA], Object Management Group, http://www.omg.org, 2001

[MDA 2003] MDA Guide Version 1.0.1, Object Management Group, http://www.omg.org, 2003

[MOF 2002] Meta Object Facility (MOF) Specification Version 1.4, Object Management Group, http://www.omg.org, 2002

[ODM03]

OMG Ontology Definition Metamodel-RFP (2003).

Available: http://www.omg.org/cgi-bin/doc?ad/2003-03-40

[Straeten03]

Van Der Straeten, R., Mens, T. and Simmonds, J. Maintaining Consistency between UML Models Using Description Logic. Workshop on Consistency Problems in UML-based Software Development II, Blekinge Institute of Technology, Research Report, L. Kuzniarz, Z. Huzar, G. Reggio, J.L. Sourouille, M. Staron (Eds), October 2003, San Francisco, USA, pp. 71-77.

[Straeten04] Van Der Straeten, R. Inconsistency Detection between UML Models Using RACER and nRQL. CEUR Workshop Proceedings, Fourth International Workshop on Applications of Description Logics (ADL'04). Edited by Sean Bechhofer, Volker Haarslev, Carsten Lutz and Ralf Moeller. September 24, 2004, Ulm, Germany.

[Haarslev04] Haarslev, V., Möller, R., Van Der Straeten, R. and Wessel, M. Extended Query Facilities for Racer and an Application to Software Engineering Problems. Proceedings of the 2004 International Workshop on Description Logic (DL2004), Volker Haarslev and Ralf Moeller, Editors, Whistler, Canada.

[Moeller03] Ralf Möller , Volker Haarslev. Description Logic Systems. In: The Description Logic Handbook. Franz Baader, Diego Calvanese, Deborah McGuinness, Daniele Nardi, Peter Patel-Schneider (Eds.), Cambridge University Press, 2003, Chapter 8, pp. 282-305.

[Haarslev01]

Volker Haarslev , Ralf Möller. Description of the RACER System and its Applications. Proceedings of the International Workshop on Description Logics (DL-2001), Stanford, USA, 1.-3. August 2001, pp. 132-141.

[Berardi02] Daniela Berardi. Using DLs to reason on UML Class Diagrams. In Proc. of the KI-2002 Workshop W6 on “Applications of Description Logics” ADL’02.

[Berardi01]

D. Berardi, D. Calvanese and G. De Giacomo. Reasoning on UML Class Diagram using Description Logic Based System.In Proc. of the KI-2001 Workshop W6 on Applications of Description Logics, ADL’01.

[Horrocks00] Horrocks, U. Sattler and S. Tobies. Reasoning with Individuals for the Description Logic SHIQ. In Proceedings of the 17th International Conference on Automated Deduction, CADE-17, 2000.

Report about decision on meta model and tools for PIM...

Documents

Transcript of Report about decision on meta model and tools for PIM...