Design of embedded mixed-criticality CONTRol systems under ... · CONTREX/UC/R/2.1.1 Public CONTREX System meta-model Page 2 History of Changes ED. REV. DATE PAGES REASON FOR CHANGES

CONTREX/UC/R/2.1.1 Public

CONTREX System meta-model

Page 1

Public

FP7-ICT-2013- 10 (611146) CONTREX

Design of embedded mixed-criticality CONTRol

systems under consideration of EXtra-functional

properties

Project Duration 2013-10-01 – 2016-09-30 Type IP

WP no. Deliverable no. Lead participant

WP2 D2.1.1 UC


Prepared by Julio Medina (UC)

Issued by Universidad de Cantabria

Document Number/Rev. CONTREX/UC/R/2.1.1/Snapshot version 1.0

Classification CONTREX Public

Submission Date 2014-06-25

Due Date 2014-06-30

Project co-funded by the European Commission within the Seventh Framework Programme (2007-2013)

© Copyright 2016 OFFIS e.V., STMicroelectronics srl., GMV Aerospace and Defence

SA, Cobra Telematics SA, Eurotech SPA, Intecs SPA, iXtronics GmbH, EDALab srl, Docea

Power, Politecnico di Milano, Politecnico di Torino, Universidad de Cantabria, Kungliga

Tekniska Hoegskolan, European Electronic Chips & Systems design Initiative, ST-Polito

Societa’ consortile a r.l..

This document may be copied freely for use in the public domain. Sections of it may be

copied provided that acknowledgement is given of this original work. No responsibility is

assumed by CONTREX or its members for any application or design, nor for any infringements

of patents or rights of others which may result from the use of this document.



Page 2

History of Changes

ED. REV. DATE PAGES REASON FOR CHANGES

JM 0.0 2014-02-18 28

Initial draft version for discussion of the structure. It

includes initial contributions from UC, KTH and

EDALabs

FeHe 0.1 2014-03-

1X

Editions and comments proposed by KTH on the

structure, and content related to strategy for CONTREX

Metamodel build, regarding SoA; related to Mixed-

Criticalities, and to the support of Models of

Computation

JM 0.5 2014-06-19 38 Insertion of content in Annex A and references to the

concrete sections of the MARTE Standard

JM 0.5 2014-06-19 38 Contributions from EDA-Lab to Chapter 5

JM 0.6 2014-06-24 Insertion of Contract Based Design section, survey and

revision of safety standards annexes

JM 0.8 2014-06-24 Addition of assessment of modelling capabilities for

MoC (provided by KTH)

JM 0.9 2014-06-25 81 Snapshot for partial reviewing

JM 0.9 2014-06-25 82 Snapshot for partial reviewing to send to EC authorities

KG 1.0 2014-06-25 81 Prepared snapshot for 1st review meeting



Page 3

Contents

1 Introduction ........................................................................................................................ 4

1.1 Strategy for the construction of the CONTREX Meta-model ..................................... 5 2 Analysis of the Requirements for the CONTREX meta-model ......................................... 8

2.1 Results of the survey.................................................................................................... 8 2.2 State-of-the-Art .......................................................................................................... 10 2.3 Analysis of needs ....................................................................................................... 12

3 The MARTE meta-model ................................................................................................. 14 4 Extensions for Mixed-criticality ....................................................................................... 15

4.1 Annotations ................................................................................................................ 15

4.2 Scheduling ................................................................................................................. 20 4.3 Contract based design ................................................................................................ 21

5 Extensions for Networking ............................................................................................... 37 5.1 Topology and platform overheads due to communication ........................................ 37

5.2 Extensions for modeling general purpose networking workloads ............................. 39 5.3 Allocation and models for network analysis ............................................................. 41

6 Extensions for the management of modeling configurations ........................................... 42 6.1 Stages in the development process: Refinement and abstraction .............................. 42

6.2 Perspectives viewpoints and views............................................................................ 42 6.3 Management of V&V for specific NFPs of interest .................................................. 42

7 Link to other formalisms .................................................................................................. 43 7.1 System-Level modeling Specification and Modelling Methodologies ..................... 43

8 References ........................................................................................................................ 53

A. Annex: Abstract syntax and overall description of modelling elements taken from MARTE

domain views ............................................................................................................................ 55 B. Annex: Results of the CONTREX meta-model survey. .................................................. 59 C. Annex: Brief assessment of modelling elements in the industrial computing standards for

safety. ....................................................................................................................................... 66 1 Introduction ...................................................................................................................... 68 2 Access to standards and complementary documentation ................................................. 68

2.1 Regarding the sources of this assessment .................................................................. 68 3 Assessment of standards for Mixed-Criticality ................................................................ 69

3.1 IEC 61508/61511 ....................................................................................................... 69 3.2 Safety related Aviation Standards ............................................................................. 72 3.3 ISO 26262 .................................................................................................................. 75

4 Considerations for the construction of the CONTREX meta-model and analysis&design

methodologies .......................................................................................................................... 79

5 References ........................................................................................................................ 81



Page 4

1 Introduction

This document describes the contributions from CONTREX to the modeling needs expressed

by the partners and initially described in the DoW. It represents the outcome of the work done

in task T2.1 of WP2, denominated “Meta-model for heterogeneous, distributed, control

systems”.

The DoW includes the following modeling aspects as requirements that need to be addressed,

and hence may impact on the meta-model:

The ability to establish concrete views (concerns) for each non-functional property (NfP) to

be modeled. Besides functional behavior, this comprises: time, power, and temperature.

The specification of diagrams/languages to handle the different perspectives in the design

process. Perspectives explicitly mentioned are: Feature, Functional, Logical, Technical, and

Geometrical.

The capacity to represent all these views and perspectives at progressively richer levels of

detail, coming from highly abstract specification levels to the physical implementation one.

Specific abstraction levels are: Requirements, system, virtual resources, nodes, and system-

on-chip.

Specific aspects to be supported are in the domains of: control systems, mixed-criticality,

and networking.

The multiple aspects here mentioned can be seen in Figure 1.1 (taken from the description of

work).

Figure 1.1: Prospective organization of models made with the CONTREX meta-model



Page 5

This picture shows a prospective organization/categorization of models that can be made by

using elements proposed in the CONTREX meta-model in specific diagrams. The idea of these

models is to support a meet-in-the-middle approach to link mixed-critical system design with

annotated extra-functional requirements (top-down) with extra-functional properties from

execution platform services (bottom-up). Perspectives: Divide the description of a system

within a level of abstraction into different aspects: user's perspective (e.g. functional and

requirement aspects), logical perspective, technical perspective, geometric perspective;

Abstraction Levels: Allow the description of the same system with different levels of detail and

possibly different description techniques; Viewpoints: Divide the view of a component within

a perspective based on functional / extra-functional properties of this component (E.g. behavior,

real-time, power, temperature, etc.)

It is important to note that the actual satisfaction of these requirements implies in practice

requirements for a modeling methodology, and development practices. These will in their turn

require support from the underlying modeling language and hence from the corresponding

meta-model (if expressed on MOF or ecore for example). However, the aforementioned

requirements will not necessarily require by themselves new modeling elements directly

inserted in the modeling language (i.e. in the meta-model).

1.1 Strategy for the construction of the CONTREX Meta-model

In the information science context, an ontology can be understood as a set of concepts within a

domain, where such concepts refer to elements and their interrelationships, and to their types,

attributes and an associated semantics which makes sense in that domain. Stating an ontology

means stating a common vocabulary (terms and their syntax) and semantics.

The definition of a common agreed ontology is especially important in a project like

CONTREX, where multiple partners with different interests, providing different tools, which

in turn handle different information, and likely making different presumptions and

interpretations of the same or similar concepts. A synergistic integration of techniques, tools,

and flows requires an early joint effort in the definition of a common ontology.

The term meta-model can be taken as a synonymous of ontology in a model-driven context. In

model-driven approaches, such as MOF or Ecore, an ontology can be captured (e.g. as an Ecore

model), and then the standards and/or tool infrastructure around that meta-model (e.g. for model

transformation languages and engines, for code generation languages and engines, etc) can be

exploited.

In the context of this document, meta-model will be used as synonymous of ontology, and will

be the term used extensively because indeed, this work takes MARTE, a well-known standard

in the model-driven context, as a reference and starting point for the generation of an ontology

for CONTREX, which will be called CONTREX meta-model.

Adopting the MARTE domain views meta-models as a starting point and reference work,

was a first strategic decision. The MARTE meta-model reflects an actual and unambiguous

ontology, covering the modeling and design of real time embedded systems, and thus avoiding

to tackle the build of a large ontology from scratch, and so reuse an important amount of

previous meta-modeling effort.



Page 6

A second relevant point is that the definition of the CONTREX meta-model has come after a

survey on the consortium scope, in order to ensure that the meta-model cover the needs of the

current and coming modeling and design practices of the consortium.

Moreover, the design of the meta-model has considered an analysis on the state of art on both

safety-standards and research work, especially to encompass relevant aspects of CONTREX,

namely control, networking and mixed-criticality, in order to promote a widen applicability of

the meta-model.

It is important to note that the CONTREX meta-model does not commit the adoption of a

model-driven or even a UML front-end (this is applicable to both CONTREX partners and

potential third party users). To the contrary it provides a set of useful and agreed (in the ambit

of the project) set of terms for the modeling of mixed-critical distributed embedded systems.

At the same time, the CONTREX meta-model contributes an extension to the MARTE meta-

model, which can be implemented either as an extension of the MARTE profile, or as a specific

CONTREX profile, and which can be used by UML-based methodologies and tools.

In order to clarify the previous claims, it is convenient to consider the conceptual organization

of the MARTE standard, sketched in Figure 1.2.

Figure 1.2: Structure of the MARTE standard.

The MARTE standard is expressed as a profile that extends the UML meta-model. The

document is organized in sections, each presenting a sub-profile. The explanation of the

concepts that are included in each sub-profile is made in two parts. First all concepts are

presented in the form of a meta-model with comprehensive text describing its semantics in the

context of the modeling and analysis of real-time and embedded systems. These parts are called

the “domain view”. In a second and normative part, called the “UML representation”, those

concepts are mapped either to concrete elements of the UML meta-model, or to the necessary

extensions to UML, which are made in the form of stereotypes collected in the corresponding

sub-profile. Therefore, notice that the “MARTE Profile” box in Figure 1.2 refers to both

elements already comprised in UML, capable to support the concepts of the domain view, and

the new stereotypes. In turn, these stereotypes are organized and presented in diagrams that

follow the structure of packages used to describe the corresponding meta-models in the domain

view.

Once this is taken into account, the approach adopted has been to build the CONTREX meta-

model by:

NFP domai

n

MARTE

meta-model (non-normative)

Domain

View

MARTE

Profile (normative)

…

NFP subprofile

UML

Representation …

Time domai

n

GQAM domain

NFP subprofile

GQAM subprofile

MARTE standard



Page 7

Selecting and taking from the MARTE meta-model (domain view) all the concepts

required by CONTREX that are already in MARTE.

Provide as an extension of the MARTE meta-model (domain view) all the concepts

required by CONTREX that are not present in MARTE. This extension has been done

as specializations (by inheritance) or as additions to the domain views of the MARTE

model libraries.

The result is the CONTREX meta-model, a meta-model oriented to the modeling and design of

mixed criticality distributed systems, and which means at the same time a focused application

of the standard and potentially a novel contribution to the MARTE standard itself.

Then, notice that the CONTREX meta-model may be implemented as either:

A domain specific language, e.g. based on a specific syntax or wrapped by a host

language such as XML (shown as (1) in Figure 1.3).

As UML profile, which could be in turn done either as a MARTE profile extension, or

as the addition of the MARTE profile plus a CONTREX specific profile (the approach

exemplified as (2) in Figure 1.3), with potentially a new graphical notation and specific

ad-hoc support.

Therefore, as it was claimed before, the CONTREX meta-model does not enforce a specific

implementation.

Figure 1.3: The CONTREX meta-model has been generated by selection on the MARTE

domain-view, and by extending such a domain view for supporting relevant concepts, related

to mixed-criticality (MC) and network modelling.

domain MARTE

meta-model (non-normative)

Domain

View

MARTE

Profile (normative)

…

Sub-

profile UML

Representation …

MARTE standard

MC domai

n

domain

Sub-

profile

network domain

… …

…

domain

Sub-

profile

CONTREX meta-model

Selected MARTE

domain concepts

MC sub-profile

network sub-profile

CONTREX profile (2)

CONTREX DSL (1)



Page 8

2 Analysis of the Requirements for the CONTREX meta-model

This section, reports the main features that need to extend the reference the MARTE meta-

model, in order to fulfil the expectations of the CONTREX meta-model, for satisfying the needs

of the consortium, and to make it suitable for control-oriented, mixed-criticality embedded

distributed systems. Before doing so, namely the main sources for the analysis, namely, the

consortium-context survey, and the analysis of the State-of-Art (SoA) on research and available

standards, is reported.

2.1 Results of the survey

The initial step for the composition of the meta-model was to explore in detail the state of the

art in the modeling of embedded systems, networking and mixed critical systems, plus the needs

of the consortium. To do this, besides the traditional literature and industrial standards

exploration, a survey was issued to the consortium and then the responses received from the

interested partners were analyzed as initial requirements for the meta-model. This has also

served as a way to know a bit better some of the technical challenges that each partner is willing

to face in the context of CONTREX.

Annex B holds a set of tables that summarize the full results of the survey realized at the

beginning of this effort. Also there the questionnaire of the survey itself is presented for

documentation purposes. Here we summarize some concrete requirements expressed in the

responses that have influenced this meta-model.

Please note that the survey has been used to obtain data related to several other labors in WP2,

not only for the meta-modeling activity in Task 2.1. In particular a significant number of

requirements are actually addressed by the different modeling methodologies that will be

prepared in Task 2.2. Here we consider those that are relevant for the meta-model only.

The following paragraphs condensed most of the needed requirements:

It should be possible to express in the meta-model block diagrams and state diagrams (resp.

real-time state charts)

A methodology that enables the user to define a design space (mainly regarding the HW/SW

mapping) for a system whose components may have different criticalities

We expect CONTREX to introduce techniques for abstraction at all levels (from hardware

representation to design modeling) that will increase our flexibility in several directions:

architectural design alternatives, hardware alternatives, quality of service tradeoffs,

introduction of new features for optimizing other extra functional characteristics than just

timing – such as power and thermal characteristics.

We assume that the CONTREX meta-model will be coherent with the design methodologies of

the CONTREX partners that we are planning to experiment with during the project. This

includes the platform modeling techniques proposed by partner EDALabs and the application

modeling techniques proposed by partner KTH. We hope that these will all be aligned so that

we do not have to switch between potentially confusing abstractions over the course of the

project.



Page 9

To transform the constraint into a feature is one the results we expect.

We want to use the meta-model for later development strategies in the early stages of the

development process

The proposed Joint Analytical and Simulation based DSE methodology in cooperation with UC

and PoliMi should lead to a methodology that ensures the fulfillment of highly critical time

constraints, while optimize the resources and/or performance for a finite set of resources for the

remaining non-critical (or less critical) constraints referred to non-critical time constraints and

other extra-functional constraints.

For that, we believe that enabling an XML-based interface between tools is a practical and

feasible approach. Moreover, such XML formats can be derived from model-based

specifications through model-to-text tools. XML-to-XML transformation could be found also

useful.

The CONTREX meta-model shall provide a common vocabulary and semantics to ensure the

coherence of the integration of the tools provided by KTH and other CONTREX tools provided,

and to guarantee that it fulfills the expectations in terms of supported models and analysis.

In particular:

The meta-model shall suit the ForSyDe methodology, which is based on models of

computations, where systems are modeled as concurrent process networks, where

processes (actors) only communicate via signals.

The meta-model shall be able to express models of computation. Most important for the

project are the synchronous MoC, SDF-MoC and other analyzable data-flow MoCs.

Further, the meta-model shall also capture independent periodic tasks and task graphs.

The meta-model shall be able to express the platform at a high abstraction level so that

it can be used for the analytical DSE.

The meta-model shall enable to express design constraints in several dimensions

(throughput, power, …) of mixed-criticality.

The meta-model shall be able to express performance figures for an instantiation of an

actor on a platform component (for instance execution time or memory size on a specific

CPU).

The meta-model shall be able to express the results of the DSE, i.e. allocation of

components, mapping of actors to components, and the scheduling of actors and

communications on platform elements, and the corresponding performance metrics for

the solution (i.e. throughput, memory size, utilization, power, …)

We require a component model and attach extra-functional properties and constraints as

contracts. Reason about compatibility of functional and extra-functional contracts horizontally

(composition of components on the same abstraction level) and vertically (refinement,

decomposition and mapping of components towards implementation level).

The goal is to obtain traceability (cause-effect analysis) from the specification to the

implementation level.



Page 10

For run-time services we expect to identify the modeling elements necessary to express the

contracts and the necessary characterization of the platforms suitable for mixed critical

applications.

At design-time, we want to be able to do design space exploration by analyzing the performance

of the complete mixed critical system and find the optimal pareto points

We plan to use the meta-model to generate execution artifacts as well as simulation models

from design intent models. We require from this meta-model the capacities needed to deploy

them on distributed platforms as well as making the design space exploration including the

criticality as an additional constraint to consider during the optimization process.

2.2 State-of-the-Art

Here we include summaries of the main aspects studied along this task due to its relevance for

the definition of the modeling elements to include in the CONTREX meta-model. The research

directions beyond our initial commitments come from the responses to the survey. The included

ones are particularly of interest in the topics of modeling models of computation, mixed-

criticality and models for the validation/simulation of networking needs.

2.2.1 Models-of-Computation Support of models of computation is an important feature for an abstract modeling and design

methodology. By relying on Models-of-Computation (MoC in short) theory, a modeling

methodology can guarantee properties such as functional determinism, continuity, deadlock

protection, etc, which are difficult to obtain when concurrent models are tackled in an

undisciplined way [6].

Moreover, Models-of-Computation theory concerns also to the support of heterogeneous

models [6], that is models where different parts obey different MoCs. These types of models

are inherent to the modeling of cyber-physical systems (CPS) [7]. Heterogeneous models will

be required also in CONTREX, where not only the plant and the controlling system will likely

required different MoCs. Moreover, a complex, distributed control system might require the

modeling of RF parts, digital parts, and network parts relying on different MoCs.

At the same time, model-driven development has introduced concepts which have proven to be

useful in the complex and cooperative software development. This has motivated work such as

the one developed by the University of Cantabria (UC), in the past [8]-[13], targeting a model-

driven methodology which not only coupled model-driven development (MDD) and electronic

system-level (ESL) design, but also integrated MoCs theory. More specifically, in [8][9],

elements from specific MARTE sub-profiles, specially, the Generic Resource Modelling or

GRM, are selected to describe a MARTE modeling methodology supporting the description of

the structure of concurrency (concurrent elements and communications among them) and

semantics attributes that allow the association of the model to a specific MoC. It enabled the

mapping of the MARTE model to a HetSC model. Later on, in [10][11] deeper arguments for

the interoperability of MARTE and associated SystemC models where provided. A main

contribution was to open the application of MoC theory to more generic SystemC code, and not

just HetSC models. It relied on an insight on the generic rules that sustain HetSC, and which at

the same time can lead to more generic SystemC code, which while it alters some of the HetSC

rules, it is still formally supported as long as higher order rules are fulfilled. Such higher order

rules were found in the relation of the SystemC model to its ForSyDe counterpart. In that work,

the capability of the ForSyDe metamodel to express dynamic dataflows, by expressing the

concurrent processes as finite state machines where input and output data partition is described

through a partition function. In [12][13], previous results are exploited for the description of an



Page 11

automatic generation engine, capable to produce the SystemC executable code out of the

MARTE model. One interesting contribution of this work is that the generator relies not only

on the preservation of the hierarchical component structure, but also in the preservation of the

communication semantics and of the process behaviours of the UML/MARTE model in its

mapping to SystemC. Specifically, a specific MARTE communication media is mapped to a

specific SystemC channel with equivalent semantics. Moreover, process behaviours are defined

by means of UML sequence diagrams describing the sequence of computation and

communication interactions. The mapping into SystemC processes preserves such sequencing.

This way, both, the MARTE model and the resulting SystemC code can be related in the same

way to the ForSyDe formal counterpart.

Other recent work from the University of Cantabria has dealt with a component-based and

holistic modeling approach (holistic in the sense of covering both the application modeling and

the description of the platform and platform mapping) to cover design activities such as design

space exploration [14] and system-level synthesis [15] for MPSoC platforms. The modeling

part in this work strictly relies on MARTE semantics, while the relation to specific MoCs has

not been developed.

While [8]-[13] work has been a pioneer step in the connection of MDD with MoC, further

extension may be useful and required in the context of CONTREX. There are several reasons

for it. The support of relevant important Models of Computations, such as the untimed SDF

MoC, the synchronous MoC (Synchronous reactive in HetSC terms), or the continuous time

models can be improved. In addition, the work in [8]-[13] adopts an approach which requires

the user to capture channel semantics via a set of attributes. Then, a pattern matching analysis

for the semantics attributes is required to extract the MoC out of the MARTE model.

Approaches where mechanism to associate an implicit semantics, e.g. of the communication

media, could help to simplify the modeling and facilitate the flow development.

Moreover, the MARTE-HetSC mapping proposed uses a limited set of MARTE attributes. An

assessment of whether such mappings can cause ambiguities, taking into consideration the

varieties of MoCs to be used is convenient, to enhance the possibilities of exchangeability of

the CONTREX model. Specially, if an scenario where close variants of the same MoC is

assessed as useful, e.g. SDF, Scenario-Aware SDF, cyclo-static SDF, then it might convenient

a more detailed and precise posing of the semantics distinction, and of the attributes and

elements capturing them.

An “explicit alternative” is possible where each MoC is explicitly stated, either in a given

context (as it is done with directors in Ptolemy II), or via explicit attributes associated to the

modeling elements (e.g. in ForSyDe a signal can be untimed, synchronous or timed), or through

specific elements associated to each MoC (e.g. as it is done in HetSC or in Metropolis II). In

turn, these options can be translated into parallel schemes in MARTE.

Other parts of MARTE, such as CCSL are suitable for precisely capturing the time semantics

of a model. This would fulfill the requirements of accurate semantics. However, there is the

question if such a description, especially if it is required to be captured in each model, is suitable

for an abstract and agile capture. Finally, additional attempts to link Model-driven technologies

with Models-of-Computation, should be accounted also, e.g. ModelHex [16].



Page 12

2.2.2 Mixed-criticality

2.2.2.1 Standards A brief summary on the main aspects related to the safety standards that have been considered

in this effort

Annex C presents a detailed report on the relevant aspects taken from the industrial computing

standards for safety.

2.2.2.2 Research A brief summary on the main aspects about how mixed criticality has been tackled in research

The literature on mixed criticality systems points out particularly two aspects that are

significantly relevant for the assessment of timing properties. These aspects are partitioning

(also called segregation of resources), and the efficient calculation/measurement/analysis of

worst-case execution times (wcet) in case of hardly predictable platforms.

Partitioning/segregation is concerned with keeping components of different criticalities apart,

so that the execution of a lower criticality function/task/component do not impact negatively

on the functional or temporal behavior of higher criticality functions/tasks/components.

The efficient use of resources according to the criticality level implies the assignment of values

progressively more conservative (i.e. larger) for the wcet of independent

functions/tasks/components in direct relation to the criticality level. The highest the criticality

the more conservative value is used from those attainable with the tools/techniques available.

Section 4 describes the implications of these tendencies in the modeling of real-time and

embedded systems enabling mixed-criticality.

2.2.3 Networked embedded systems

Regarding the modeling of distributed embedded systems, different standard approaches for

system description have been proposed to introduce all the information required in the first

steps of the design process, e.g., UML and SysML. The use of standard frameworks enable tool

interoperability and the generation of widely understandable documentation. In particular,

functional modeling has been described by using models of computation [27, 46], tools like

Matlab/Simulink and Ptolemy as well as languages like Compositional Interchange Format.

Moreover, De Miguel et al. [17] introduce UML extensions for the representation of temporal

requirements and resource usage for real-time systems. Their tools generate a simulation model

for OPNET simulator [18]. Hennig et al. [19] describe a UML-based simulation framework for

early performance assessment of software/hardware systems described as UML Deployment

and Sequence diagrams. Their simulator is based on the discrete event simulation package

OMNet++.

2.3 Analysis of needs

Considering the requirements expressed for the CONTREX meta-model, it was observed that

most of them are covered by MARTE and UML, though some requirements needed additional

modeling elements.



Page 13

It is important to note that the requirements about the modeling for control systems are not

proposing specific conceptual elements into the meta-model. The control oriented nature of the

modeled systems as well as its capacities to address cyber physical systems is expected to

appear in the models in general as specific non-functional requirements. These requirements

are stated as constraints for the computing system and may be eventually formalized as such

and labeled for tracing purposes. That is, the meta-model is not expected to hold elements and

concepts which support modeling and analysis specific from control theory, e.g. models

supporting the statement of differential equations (in the time domain) or pole/zero

representations (in a frequential or complex domain), typically used, for instance, to study

response times in analog input/outputs signal traces, or to analyze the stability of the feedback

loops.

2.3.1 Elements needed as extensions to MARTE.

The analysis of needs revealed that the following three potential extensions to the MARTE

standard (later on presented in three corresponding sections) are required:

Extensions to manage mixed-criticality

Extensions to support communication through general purpose networking

Extensions to support the handling of modeling configurations

2.3.2 Links to other formalisms

As stated in the requirements, some concrete formalisms are to be hold/connected to the

CONTREX meta-model. The way to interact with them is a methodological concern that

will be essayed and provided in other task T2.2. Equivalently we identify the need to

generate of modeling examples as model libraries that may serve to validate the support for

MoC in UML and MARTE.



Page 14

3 The MARTE meta-model

The sections of the MARTE standard that are of interest for understanding the semantics and

the abstract syntax of the elements that are relevant for this effort are essentially the subsections

denominated as domain views of the following clauses in the MARTE specification:

- Core Elements (Section 7)

- Non-functional Properties Modeling (Section 8)

- Time Modeling (Section 9)

- Generic Resource Modeling (Section 10)

- Allocation Modeling (Section 11)

- High-Level Application Modeling (Section 13)

- Generic Quantitative Analysis Modeling (Section 15)

Additionally, elements of interest to understand the proposed extensions are in:

- Normative MARTE Model Libraries (Annex D), and

- Domain Class Descriptions (Annex F)

The main diagrams in the domain view of those MARTE sub-profiles represent the abstract

syntax for the elements in MARTE that will be used in the CONTREX meta-model.

Instead of copying all the diagrams and textual descriptions, the interested reader is referred to

the actual specification, which can be downloaded from the OMG repository at

http://www.omg.org/spec/MARTE/1.1/PDF.

Annex A include as a general reference a very brief summary of distinctive aspects of some of

the main sections of MARTE. The descriptions of specific modeling elements used in this

document may be retrieved from the Annex F of the UML profile for MARTE specification,

which have the description of the semantics of all elements in the domain views.

http://www.omg.org/spec/MARTE/1.1/PDF



Page 15

4 Extensions for Mixed-criticality

Though made in principle in the context of scheduling, the review of mixed criticality systems

(MCS) given by Burns and Davis in [UC-1] is largely valid for our analysis. According to them,

criticality is a designation of the level of assurance against failure needed for a system

component. A mixed criticality system is one that has two or more distinct levels (consider for

example safety critical, mission critical and non-critical). Reviewing the standards in the field,

(IEC 61508, DO-178B, DO-254 and ISO 26262 standards), they propose to use up to five

levels. As noted in another very interesting effort by Graydon and Bate [UC-2], it should be

noted that not all papers on MCSs assign to ‘criticality’ the same meaning. These appreciations

are also noticeable by looking at the assessment we have conducted of computing standards for

safety in Annex C.

The extensions to MARTE proposed here are organized in three parts: Annotation of values

that may vary according to the level of criticality, scheduling mixed-critical applications, and

non-functional properties constraints for contract-based design.

4.1 Annotations

One aspect to considering mixed-criticality in the meta-model is the support of the association

of criticalities to non-functional annotations in such a way that different values may be assigned

according to the different levels of criticality, (e.g. by overestimation or relaxation) though all

referring to the same magnitude. For instance, different WCETs can be considered for a real-

time schedulability analysis depending on the criticality. Under this perspective, mixed-

criticality analysis considers involvements on annotated data, a specific input of the analysis.

Moreover, there is another possibility, which makes considerations on the requirements of the

system, another important input of the analysis. Specifically, in [KTH-1], the association of

criticalities to constraints on the performance metrics characterizing the performance of the

system is proposed. Systems in general can have constraints of many types, and not all of them

are equally critical in general. Moreover, while a constraint on throughput in a system can be

critical, e.g. for a digital TV, other constraints, e.g. response time might be the critical one in

other application domains, e.g. the response time of a wheel reaction to a movement of the

steering wheel. And at the same time, a system can present constrains on both types of

constraints. E.g., the throughput is the most important constraint for the digital TV, which has

to refresh the image of a certain resolution every 1/100s, but optimizing the latency, e.g., to

avoid the user to have to wait too much to see the 1st frame after zapping is subject to

optimisation, and likely to be constrained for a minimum QoS. Although one can agree that it

is a less important constraint than the frame refresh rate.

Because of that, [KTH-1] proposed that a meta model for MCS and MCSoS systems should

support the annotations or associations of criticality levels to performance metric constraints.

Moreover, in [KTH-1] the idea that constraints, and so the application of their respective

criticalities, could refer to other type of properties, e.g. deadlock protection, etc. was launched.

In [KTH-1], the criticality level is also associated to SIL or a generalized SIL, after considering

that the criticality can refer indirectly to functional integrity, by means of considering

performance and formal properties with involvements on such function integrity.

In [KTH-2], a joint analytical and simulation-based (JAS) design space exploration (DSE)

method which relies in this distinction between constraints on performance metrics with higher



Page 16

and lower criticalities. For simplicity, [KTH-2] considers two criticality levels, and focuses on

time-constraints for the high-criticality level.

Then, the need to have annotations with the specific levels of criticality is clear, and these may

affect many modeling elements of MARTE, but annotations need to be made in the context of

the specific aspects in which they play a role. Concretely, in our case they will be inserted in

regard of the specific NfP’s that will be studied in this project: timelines, temperature, and

power.

Temperature and power as well as timing properties are aspects that are treated in general as

extra-functional-properties, and hence they are represented with annotations in concrete NFP

data types. For this reason, the more efficient way to link them in the models to the level of

criticality at which they are relevant is by enhancing the basic representation of NFP with the

necessary information. This is done in a way similar to its characterization in different modes

of configuration.

Two are the basic elements proposed by MARTE to manage non-functional properties in UML:

NFP_Types and NFP_Constraints. These are used in many attributes and types defined in

MARTE. The introduction of the levels of criticality in them may be made in specific types,

but in principle adding them in the root library element may solve the problem from the

expressiveness point of view and may also help further exploitation of the approach for other

NFPs.

The concrete elements to extend in the context of the MARTE profile are then

NFP_CommonType and NFP_Constraint. NFP_CommonType is not an element of the meta-

models in the domain views of MARTE, but it is the root of all predefined non-functional

property types in MARTE. NFP_Constraint instead is indeed an element of the MARTE domain

view and may be extended to encompass criticality in the same way it handles configuration

modes.

From the methodological point of view, we may further need to discuss whether it is advisable

to actually include an additional element or simply use the mode attribute to implement

criticality. From the meta-model point of view it is much cleaner to use an additional attribute,

but from the implementation point of view, and considering compatibility with the standard, it

may be more convenient to use ad-hoc state charts with the configuration of the criticality levels

for the concrete standard to use and then define in there each level as a Mode.



Page 17

Definition of NFP_Constraint in MARTE

- UML profile diagram for NFPs modeling (Implementation of the NfpType and

NfpConstraint stereotypes in MARTE)



Page 18

Hierarchy of NFP types defined in the library of MARTE.

As seen, the assumption made by most authors refers to the fact that for different levels of

criticality concrete values used for annotating WCET (or other NFPs) shall be different (e.g. by

overestimation or relaxation) though all referring to the same magnitude. The strategy proposed

here by extending the MARTE NFP_CommonType allows handling those values by means of

common annotations on UML attributes. The new attribute in it will indicate the level of

criticality assigned to the concrete value of the annotation. Observe that this qualification is

orthogonal to the others already in MARTE like the source, the statistical qualifier, or the

configuration mode. The correct interpretation of all possible combinations is left to the

concrete modeling methodologies defined for the usage of the CONTREX meta-model.



Page 19

expr: VSL_Expression

source: SourceKind

statQ: StatisticalQualifierKind

dir: DirectionKind

mode: string [*]

criticality: Integer [*]

« dataType »

« nfpType »

{ exprAttrib= expr }

NFP_CommonType

kind:ConstraintKind [0..1]

criticality: Integer [*]

NFP_Constraint

Extension of NFP_CommonType and NFP_Constraint elements of MARTE with criticality.

NFP_CommonType

This is the parent NfpType that contains common parameters (modeled as UML Properties)

and common operations of the various NfpTypes defined in MARTE.

Attributes

- • expr: VSL_Expression [0..1]

Attribute representing an expression. MARTE uses the VSL language to define expressions.

- • source: SourceKind [0..1]

Peculiarity of NFPs associated with the origin of specifications. Predefined kind of sources for

values are estimated, calculated, required and measured.

- • statQ: StatisticaQualifierKind [0..1]

Statistical qualifier indicates the type of “statistical” measure of a given property (e.g.,

maximum, minimum, mean, percentile, distribution).

- • dir: DirectionKind [0..1]

Direction attribute (i.e., increasing or decreasing) defines the type of the quality order relation

in the allowed value domain of NFPs. Indeed, this allows multiple instances of NFP values to

be compared with the relation “higher-quality-than” in order to identify what value represents

the higher quality or importance.

- • mode: String [*]

Operational mode(s) in which the NFP annotation is valid. The string should contain the name

of an existing UML element stereotyped as «MARTE::CoreElements::Mode».

- • criticalityLevel: Integer [*]

Value(s) that defines the level(s) of criticality at which the NFP annotation is valid.

NFP_Constraint

NFP Constraints are conditions or restrictions to modelled elements providing the ability to

define if these are of “required,” “offered,” or “contract” nature.



Page 20

Associations

• constrainedElement: AnnotatedElement [*] Set of Annotated Elements referenced by this

NFP Constraint.

• context: AnnotatedModel [0..1] Namespace that is the context for evaluating this constraint.

• specification: ValueSpecification [1] Condition that must be true when evaluated in order

for the constraint to be satisfied.

• mode: Mode [*] The set of modes in which the NFP constraint annotations are valid.

Attributes

• kind: ConstraintKind [0..1] Tagged definition qualifies NFP constraints by either required,

offered, or contract nature.

• criticality: Integer [*]Value(s) that defines the level(s) of criticality at which the NFP

constraint is valid.

Semantics

NFP Constraints are conditions or restrictions to modeled elements. Specifically, NFP

constraints support textual expressions to specify assertions regarding performance,

scheduling, and other embedded systems’ features, and their relationship to other features by

means of variables, mathematical, logical, and time expressions.

Both, NFP_CommonType and NFP_Constraint have been extended with a new attribute of

the type Integer to hold the level of criticality that is necessary.

Here we may also consider a new specific data type to hold specially defined levels of

criticality. Integer has been used since all standards reviewed use a simple discrete approach.

In case it results necessary a more elaborated choice type may be defined with different

enumerated values for each standard.

4.2 Scheduling

About the scheduling capabilities, the key mechanism is the partitioning/segregation of

resources. This is managed from the scheduling point of view as a hierarchical scheduling

platform. The primary level implements the partitioning by assigning fractions of the processing

capacity to the primary schedulable resources (known as servers or virtual resources). These

are in turn re-scheduled by secondary schedulers according to the rules of the guest operating

system among the final schedulable resources (threads or processes) of the guest OS. This

partitioning encompasses not only time but also memory and eventually other resources like

energy and the capacity of rising temperature.

As a modeling example let us show the MARTE meta-model for scheduling, which supports

natively hierarchical scheduling. Further work in task T2.2 may provide examples of an IMA

platform. The modeling of the case studies will help to verify the initial vision according to

which we do not need in principle additional elements



Page 21

The domain model for scheduling in MARTE

4.3 Contract based design

For the specification of deployment contracts, a library or a methodological approach may be

created using NFP_constraint’s and a state chart specific to the modeling configurations

representing areas/points in the perspectives/views/ abstraction-levels matrix.

Following the SPES proposal a list of examples of NFP_constraints may be described with the

way in which concrete annotations of contracts will be refined along abstraction levels.

Also a model library with predefined expressions representing the contracts may be offered.

No additional elements have been so far identified for inclusion into the meta-model but this

section describe extensively the way these constraints are formally specified

4.3.1 Background Based on the principles of assume-guarantee reasoning (AGR) [CBD-19 - DBD-23], the

emergence of contract based design (CBD) started in [CBD-24 – CBD-27]. To improve the

reliability within the modular, re-use based paradigm of object-oriented software programming,

the correct interaction of software components was assured by proving required preconditions

and ensured post conditions before respectively right after each communication across the

components' interfaces. If one of these formal assertions – expressed by means of software state

predicates – failed, the interaction, and thus the observed composition of the components, was

not valid. Subsequently, in [CBD-28 – CBD-31] these concepts have been applied to digital

automata and hardware modules, claiming assumptions on their interfacing environment and

reversely providing behavioral guarantees, if those assumptions were satisfied. Derived from

that, formal expressions were defined for compatibility of interfaces, composition of

components and the implementation-/refinement-relation of digital hardware modules, enabling

formal verification by improved compositional methods. As liveliness is a significant property

for a valid composition of reactive system components, in [CBD-32 – CBD-35] the formal



Page 22

notion of receptiveness was introduced, to denote, that there exists a proper behavior for each

sequence of environmental inputs – i.e. without constraining the components environment.

Subsequently, based on the modeling concepts of timed and hybrid automata [CBD-7, CBD-

36, CBD-37], the extension to continuous and hybrid systems was presented in [CBD-38, CBD-

39], expanding receptiveness, as well as the composition-functions of parallel and serial

composition, variable and location renaming and variable and location hiding, which are

necessary to build formal refinements/abstractions and compositions out of formal atomic

hybrid components. More recently, in [CBD-40 - CBD-42] the principles of contract- and

component-based design were jointly applied with the idea of abstract semantics [CBD-43 -

CBD-46] – which enables separation of concerns for different modeling aspects and models of

computation (MoC) – by using heterogeneous rich components (HRC) [CBD-47 - CBD-53]

and multi-viewpoint state-machines [CBD-53, CBD-54] to formally analyze functional stability

and safety aspects of hybrid systems. Up to that, an overview of CBD can be found in [CBD-

55, CBD-56], but despite the aforementioned scientific achievements [CBD-57 - CBD-59] and

the ongoing research [CBD-60, CBD-61], according to [CBD-4, CBD-60, CBD-62] further

research is necessary on: 1) the mathematical, formal foundations of contracts, to enable a

comprehensive design flow for system specification, exploration, refinement/abstraction and

verification of extra-functional properties and hybrid systems, using heterogeneous rich

components; 2) the development of system engineering frameworks with methodologies and

tools for the aforementioned design flow across different abstraction levels; and 3) the

integration of these into design- and life-cycle management frameworks for appropriate

organization of cross-boundary design-flows and configuration management.

According to the general definition of power as the time derivative of the energy

𝑃 = 𝑑𝑊(𝑡)

𝑑𝑡

and according to a simplified discrete interpretation as a time discrete rate of energy

consumption,

𝑃 =Δ𝑊

Δ𝑇= Δ𝑊 ∙ 𝑓

power is used as a time- and state-dependent parameter for device characterization and a

common basis for the calculation of further use-case specific properties, as e.g. energy

consumption, device heating or influences on aging and reliability.

However, to the author's best knowledge, there currently exists no exhaustive investigation of

a formal component- or contract-based design in the domain of power. Paying attention to

battery driven mobile systems and the past years' technology scaling – i.e. shrinking of the

microelectronic basic devices and structures, as especially the transistor gate-lengths in digital

CMOS processes – power became one of the most important parameters for the development

of energy-efficient, reliable high-performance integrated circuits (IC) and systems on chip

(SoC) [CBD-63 - CBD-67]. According to that, early power analysis, power-related design space

exploration and power optimization became a more and more important aspect, too [CBD-68 -

CBD-71]. As it applies for power dissipation as well, that the influence of design decisions

increases with the abstraction level [CBD-67], high-level approaches are needed for the

efficient modeling of power aspects. According to [CBD-68], these can generally be

categorized into bottom-up power characterization and abstraction methods, achieving accurate



Page 23

power information from previous low-level implementations, and methods for top-down power

estimation, predicting power estimations already without knowledge about the technological

circuit or system structure. At that, analytical methods try to relate high-level power models to

fundamental low-level quantities, whereas empirical methods derive those from observing the

system's power behavior during execution [CBD-65]. Over the past 20 years, these power

models and estimation approaches have significantly been improved [CBD-66, CBD-69 - CBD-

78], especially in terms of accuracy and speed. Moreover, since several kinds of power

properties can be mapped to more abstract static power properties – i.e. a static part of the power

intent, contained within the structural view of the design – methods for the structural analysis

and verification of compositional designs and their interconnect become necessary, too [CBD-

79 - CBD-84]. To that end, the power intent description standards CPF (common power format)

[CBD-80] and UPF (unified power format) [CBD-81] were defined to provide unified standards

for the description of the systems' static power intent. A first approach, how to use and extend

UPF specifications for a semi-formal verification of also the dynamic part of the power intent

is given in [CBD-84 - CBD-86]. Nevertheless, most methods are largely simulation-based and

only little research [CBD-82, CBD-83, CBD-87 - CBD-89] is focused on formal methods,

having the main emphasis rather on functional verification of the power management [CBD-

90, CBD-91] than on attaining power closure across different abstraction levels. As a

consequence, the advanced methods of high-level power modeling barely support interfaces to

the compositional design methods of CBD and consequently can barely profit from the

improvements of contract-based design and verification methods.

4.3.2 Problem Statement The ability of successfully realizing the complex functionality of today's digital

microelectronics is largely due to the compatibility between advanced methods, models and

appropriate libraries for formal or semi-formal functional design, especially with respect to

refinement and abstraction based on structural composition and decomposition. In contrast –

due to the previously explained missing of compatible formal methods, models and libraries in

the power-domain – power-aware design flows are lack of such a continuous consistency. One

of the main reasons for that is the missing of a formal methodology, which combines formal

specification, characterization, refinement/abstraction and verification of power properties with

the concepts of compositional design – enabling a sound and compatible, formal model and

library development; and with a clear separation of concerns – enabling for a flexible and

exchangeable cross-domain mapping between functional specifications and extra-functional

models of corresponding implementation alternatives.

4.3.3 Related Work While [CBD-16, CBD-42, CBD-92 - CBD-94] concentrate on investigating contract-based

specification and verification of safety, stability and real-time requirements, there is only little

work on continuous design flows for other extra-functional properties within or cross-cutting

several domains, as power or temperature. This is especially true for analog/mixed-signal

(AMS) or multi-physical systems, for which already the functional view is spread across

multiple, heterogeneous development domains, namely the analog and the digital domain plus

mechanics or chemistry, for example. Indeed, recent reports [CBD-4 - CBD-95] show an initial

approach, optimizing the power consumption of a UWB receiver's RF frontend, using analog

contracts within analog platform-based design (APBD) [CBD-96 - CBD-99], but at that several

issues remain still unsolved. The maybe most challenging questions among these might be: 1)

how to apply CBD formalisms to mixed-signal and multi-physical systems? [CBD-4]; and 2)

how to apply formalisms for handling continuous-time and state-dependent cross-domain

aspects? [CBD-60]. Thus [CBD-100 - CBD-103] most recently extend the compositional



Page 24

formalisms of CBD for a usage within multiple, intertwined and maybe extra-functional

domains. But while this work provides the basic semantics and theories, the extra-functional

specifications and characteristics of heterogeneous systems are specified, refined/abstracted

and characterized mostly different, according to the heterogeneity of different domains and

systems. As an example, whereas a static, timing- and stimuli-independent, extra-functional

performance-vector [CBD-4, CBD-95] may be a good characterization for the UWB receiver

or its components, other devices may need a more variable characterization – e.g. due to

programmability or time- input- or state-dependencies. For that, a good example would be

today's low-power systems with dynamic power-management, whose power consumption

depends significantly on a timed trace of power states, consequently being hard to describe

without knowledge about the specific use-case scenario. As a consequence of this dependency

between functional and extra-functional system characteristics, the aforementioned low-power

system demands for cross-domain contracts, cross-cutting the power, timing and functional

domains. For multi-physical systems, this becomes even more complicated, considering e.g.

the intertwined functional and/or extra-functional dependencies of micro-electro-mechanical

systems (MEMS) for energy-harvesting [CBD-104, CBD-105]. As a result, design-flows are

still lack of consistent formalisms for the specification, exploration, refinement/abstraction and

verification of continuous or cross-domain extra-functional properties as they are necessary for

developing the complicated mixed-signal or multi-physical systems of today.

4.3.4 Basic concept

4.3.4.1 A simple component model A Heterogeneous Rich Component (HRC) denotes a structural design element – onwards

component – which is semantically enriched with contracts, with contracts being a formal

specification over the component’s interfaces, declaring assumptions on the component’s

environment and guarantees on its externally observable behavior. Hence, the external

interaction of an HRC is solely restricted to its explicitly declared interface. On top of that, its

heterogeneity results from combining the behavioral descriptions of different, functional and

extra-functional aspects within the same HRC.

Figure 4.1: Contract Based Design (CBD): identifiers and basic concept.

To explain the most relevant concepts of HRCs and CBD, we introduce different identifiers

according to



Page 25

Figure 4.1, onwards denoting contracts by the letter 𝐶 and HRCs by the letter 𝑀, additionally

indexed by 𝑖 𝜖 ℕ+ to refer to the 𝑖-th HRC of a decomposition of 𝑀 into 𝑛 sub-HRCs {𝑀1, … , 𝑀𝑛}, also denoted as parts of the system. Additionally, we define the interface of an

HRC 𝑀 as the set of its directed in and output variables 𝑥 ∈ Χ𝑀 ∶= {�⃗�𝑖𝑛, �⃗�𝑜𝑢𝑡}, called ports.

To choose only the functional-, timing- and power-specific subsets of 𝑀, 𝐶, Χ and �⃗� we provide

the subscripts fct, time and pwr, corresponding to the internal, non-structural but aspect-specific

segregation of the HRC behavior according to these aspects.

Finally, we define an HRC’s interconnection network 𝑁𝑒𝑡 ∶= {𝑁𝑒𝑡𝑎𝑠𝑚, 𝑁𝑒𝑡𝑑𝑒𝑙} by the sets of

its internal connectors, consisting of: the assembly connectors 𝑁𝑒𝑡𝑎𝑠𝑚 ⊆ Χ𝑀𝑖

𝑜𝑢𝑡 × Χ𝑀𝑗

𝑖𝑛 which

internally link ports between different parts of the system; and its delegation connectors

𝑁𝑒𝑡𝑑𝑒𝑙 ⊆ {Χ𝑀𝑖

𝑜𝑢𝑡 × Χ𝑀𝑜𝑢𝑡} × {Χ𝑀

𝑖𝑛 × Χ𝑀𝑖

𝑖𝑛 } which link up the port of the HRC’s parts with

the HRC’s external ports. The direction of the interconnect 𝑛𝑒𝑡(𝑥𝑠𝑟𝑐 , 𝑥𝑠𝑛𝑘) ∈ 𝑁𝑒𝑡 is defined by

position, naming the driving source 𝑥𝑠𝑟𝑐 of the net in front of the reader’s sink 𝑥𝑠𝑛𝑘.

4.3.4.2 Contracts The contracts 𝐶 of a component 𝑀 are formally defined as triples 𝐶 ∶= (𝐴, 𝐵, 𝐺). While the

strong assumptions 𝐴 delimit the component’s maximum permissible input state space over the

input variables �⃗�𝑖𝑛 of 𝑀, the weak assumptions 𝐵 over �⃗�𝑖𝑛 perform a further division to

subspaces, for which 𝑀 assures the associated guarantees 𝐺 over its output variables �⃗�𝑜𝑢𝑡, if

and only if the individual use case satisfies the corresponding assumptions. Hence, 𝐶 is

semantically interpreted as [[C]] ≔ 𝐴 ∧ 𝐵 ⇒ 𝐺, with 𝐴, 𝐵 and 𝐺 being time bounded LTL or

CTL properties, representing sets of timed traces 𝑆𝐴(�⃗�𝑖𝑛), 𝑆𝐵(�⃗�𝑖𝑛) and 𝑆𝐺(�⃗�𝑜𝑢𝑡) over the I/O

variables �⃗�𝑖𝑛, �⃗�𝑜𝑢𝑡 ∈ Χ𝑀 of 𝑀.

Declaring the type of a variable 𝑥 to be 𝜈(𝑥) ∈ {ℕ, ℤ, ℝ, … } and declaring the notion of time

as the discrete but infinitely increasing variable 𝑡 ∈ ℕ0+, a timed trace 𝑠𝑥(𝑡) is a discrete

sequence of events {𝑒(𝑥, 𝑡0), 𝑒(𝑥, 𝑡1), … } ∈ 𝑆𝑥 ∶= {𝑥 → [ℕ0+ → 𝜈(𝑥)]}, mapping the

variable 𝑥 to its values 𝑣(𝑥, 𝑡𝑖) ∈ 𝜈(𝑥) for each point of time. A complete property

specification 𝐶 of a component 𝑀 is then defined as 𝐶 ∶= ⋀𝑎𝑠𝑝⋀𝑖=0

𝑛𝑎𝑠𝑝𝐶𝑎𝑠𝑝𝑖 , considering all

contracts {𝐶𝑎𝑠𝑝1 , … , 𝐶𝑎𝑠𝑝

𝑛𝑎𝑠𝑝} of all aspects 𝑎𝑝𝑠 ∈ {𝑓𝑐𝑡, 𝑡𝑖𝑚𝑒, 𝑝𝑤𝑟, … }.

To extract a purified, port-specific expression of the effect of the assumptions, guarantees or

even complete contracts, the restriction function ↓𝑋 denotes the restriction of these constraints

to solely the subset 𝑋 of their original variables. Furthermore, 𝜌𝑖 and 𝜌 denote the so-called port

mapping or port substitution functions, with: 𝜌𝑖 identifies the port variables 𝑥𝑖𝑖𝑛, 𝑥𝑖

𝑜𝑢𝑡 ∈ Χ𝑀𝑖 of

a part 𝑀𝑖 with the corresponding assembly and delegation connectors 𝑛𝑒𝑡(𝑥𝑖𝑖𝑛,∗), 𝑛𝑒𝑡(∗

, 𝑥𝑖𝑜𝑢𝑡) ∈ 𝑁𝑒𝑡 and 𝜌 identifies the external ports 𝑥𝑖𝑛, 𝑥𝑜𝑢𝑡 ∈ Χ𝑀 of the system 𝑀 with the

corresponding delegation connectors 𝑛𝑒𝑡(𝑥𝑖𝑛,∗), 𝑛𝑒𝑡(∗, 𝑥𝑜𝑢𝑡) ∈ 𝑁𝑒𝑡.

That way, the contracts explicitly relate the formal and possibly more abstract behavioral

specifications of a component’s bottom-up characterization with the appropriate validity

constraints, the underlying model implementations and abstractions would otherwise assume to

be satisfied without verification. Hence, CBD enables to formally check for:



Page 26

compatibility: 𝐺𝑀𝑠𝑟𝑐↓𝑥𝑠𝑟𝑐

𝜌𝑀𝑠𝑟𝑐 ⟹ 𝐴𝑀𝑠𝑛𝑘

↓𝑥𝑠𝑛𝑘𝜌𝑀𝑠𝑛𝑘

between the connected

components of a system;

refinement: 𝐶′ ⇒ 𝐶 of a system 𝑀’s specification 𝐶 w. r. t. its component-based

bottom-up composition by 𝑛 parts {𝑀1, … , 𝑀𝑛}, specified by their contracts 𝐶𝑖 and

logically composed to the Virtual Integration 𝐶′ ≔ ((⋀𝑖=1𝑛 𝐶𝑖𝜌𝑖) 𝜌 ↓Χ𝑀

).

Figure 4.2: Basic idea of the design steps within a power-aware design flow with power

contracts.

Applying the concepts of HRCs and CBD to build a consistent, design flow, our primary goal

is to formally ensure the correct re-use of bottom-up leaf-node power models to improve power

closure. Our basic idea for that design and verification flow is outlined in Figure 4.2, covering:

1) the structural decomposition of the initial HRC with possibly a refined partitioning of

its initial contracts;

2) the implementation of the HRC’s parts;

3) the formal bottom-up characterization of the parts’ functional and extra-functional

behavior in terms of contracts;

4) the satisfaction checking between the parts’ contract based bottom-up characterization

and their specification;

5) the compatibility checking between all components’ connected ports;

6) the virtual integration to a composed top-level specification;

7) the refinement checking between the composed top level contract and those of the initial

specification.



Page 27

4.3.5 Textual contract specification We are using the LTL-based specification language OTHELLO (Object Temporal with Hybrid

Expressions Linear-Time Logic) [CBD-129, CBD-130] for the formal specification of

contracts. This is a very expressive hybrid specification language. The Extended Backus-Naur

Form (EBNF) of OTHELLO below describes the temporal, arithmetic and logic expressiveness

and is given as [CBD-129]:

constraint = atom | "not" constraint | constraint "and" constraint | constraint "or" constraint | constraint "implies" constraint | "always" constraint | "never" constraint | "in the future" constraint | "then" constraint | constraint "until" constraint | constraint "releases" constraint ; atom = "TRUE" | "FALSE" | term relational_op term | "time_until" "(" term ")" relational_op term | term ; term = variable | constant | term "+" term | term "-" term | term "*" term | term "/" term | "der" "(" variable ")" | "next" "(" variable ")" ; relational_op = ("="|"!="|"<"|">"|"<="|">=") ;

where:

constant is a constant number;

variable is a string.

The structural view is described using OSS, the OTHELLO System Specification. OSS defines

unique identifier – the HRC reference of the top-level HRC – its external ports Χ and its data

types 𝜈(𝑥). For the description of the hierarchical decomposition of the overall system,

subcomponents {𝑀1, … , 𝑀𝑛} and their interconnection 𝑁𝑒𝑡 ∶= {𝑁𝑒𝑡𝑎𝑠𝑚, 𝑁𝑒𝑡𝑑𝑒𝑙} can be

specified. This way, Contracts can be specified during system and component description

through linking components with contracts using unique identifiers. In the following, the EBNF

of OSS [CBD-129] is given:

OSS = system_comp component* ;



Page 28

system_comp = "COMPONENT" comptype? "system" interface refinement? ; component = "COMPONENT" comptype interface refinement? ; interface = "INTERFACE" var* contract* ; refinement = "ASYNC"? "REFINEMENT" subcomponent* connection* refinedby* ; var = port | parameter | operation ; port = ("IN" | "OUT")? "PORT" name ":" type ";" ; parameter = "PARAMETER" name ":" type ";" ; operation = ("PROVIDED" | "REQUIRED") "OPERATION" "PORT"? name "(" op_parameter* ")" ":" (type | "void") ";" ; op_parameter = ("IN" | "OUT")? name ":" type ; type = "boolean" | "integer" | "real" | "continuous" | "event" | "{" (number | name)+ "}" | number ".." number; contract = "CONTRACT" name "assume" ":" constraint ";" "guarantee" ":" constraint ";" ; subcomponent = "SUB" name ":" comptype ";" ; connection = "CONNECTION" name ":=" constraint ";" formula = "CONSTRAINT" constraint ";" refinedby = "CONTRACT" name "REFINEDBY" contr_id+ ";" ; contr_id = name "." name ;

where:

name is a string;

there cannot be two components with the same name;

for every component, there cannot be two subcomponents with the same name;

comptype is a string that matches one of the components’ name;

in the list of components forming the OSS, there exists a component whose name is

system;

the relationship that links a component to its subcomponents is not circular and form

a tree rooted in the system component;

the constraint in the definition of a contract in an interface must be an Othello

constraint as defined above where every variable must match a variable of the interface;

the constraint in the definition of a connection in the refinement of a component

must be an Othello constraint as defined above where every variable must either match

a port of the interface or be in the form sub.var where sub matches a

subcomponent’s name of the refinement and var matches a variable of the

interface of such subcomponent.

4.3.6 References [CBD-1] Martens, E. S. J.; Gielen, G.: High-level modeling and synthesis of analog

integrated systems. Springer-Verlag, Dordrecht, 2008.



Page 29

[CBD-2] Gielen, G. G. E.; Rutenbar, R. A.: Synthesis of Analog and Mixed-Signal

Integrated Electronic Circuits. In: Antonsson, E. K.; Cagan; J. (Eds.): Formal

Engineering Design Synthesis. Cambridge University Press, Cambridge, 2001.

[CBD-3] Gielen, G.; Rutenbar, R.: Computer-aided design of analog and mixed-signal

integrated circuits. In: Proceedings of the IEEE. Volume: 88, Issue: 12, 2000.

[CBD-4] Nuzzo, P.; Sangiovanni-Vincentelli, A.; Sun, X.; Puggelli, A.: Methodology for

the Design of Analog Integrated Interfaces Using Contracts. In: IEEE Sensors

Journal. Volume: 12, Issue: 12, 2012.

[CBD-5] Blum, L.; Cucker, F.; Shub, M.; Smale, S.: Complexity and Real Computation:

A Manifesto. In: International Journal of Bifurcation and Chaos. Volume: 6, 1995.

[CBD-6] Henzinger, T. A.; Kopke, P. W.; Puri, A.; Varaiya, P.: What's decidable about

hybrid automata. In: Journal of Computer and System Sciences. ACM Press, 1995.

[CBD-7] Alur, R.; Courcoubetis, C.; Halbwachs, N.; Henzinger, T. A.; Ho, P.-H.;

Nicollin, X.; Olivero, A.; Sifakis, J.; Yovine, S.: The algorithmic analysis of hybrid

systems. In: Theoretical Computer Science. Volume: 138, Issue: 1, 1995.

[CBD-8] Asarin, E.; Maler, O., Pnueli, A.: Reachability analysis of dynamical systems

having piecewise-constant derivatives. In: Theoretical Computer Science. Elsevier

Science Publishers Ltd., 1995

[CBD-9] Gupta, V.; Jagadeesan, R.; Saraswat, V. A.: Computing with continuous

change. In: Science of Computer Programming - Special issue on concurrent constraint

programming. Elsevier North-Holland, Inc., Amsterdam, 1998.

[CBD-10] Blum, L.: Computing over the reals: Where Turing meets Newton. In: Magid,

A. (Ed.): Notices of the American Mathematical Society. Volume: 51, Issue: 9, 2004.

[CBD-11] Gentilini, R.; Schneider, K.; Mishra, B.: Successive Abstractions of Hybrid

Automata for Monotonic CTL Model Checking. In: Sergei N. A.; Anil N. (Eds.):

Logical Foundations of Computer Science. Springer-Verlag, Berlin, Heidelberg, 2007.

[CBD-12] Chee, K.Y.: Theory of real computation according to EGC*. In: Hertling, P.;

Hoffmann, C.M.; Luther, W.; Revol, N. (Eds.): Reliable Implementation of Real

NumberAlgorithms: Theory and Practice. Springer-Verlag, Berlin, Heidelberg, 2008.

[CBD-13] Jones, K. D.: Analog and mixed signal verification. Invited Paper. FMCAD,

2008.

[CBD-14] Maler, O.: Reachability for continuous and hybrid systems. In: Proceedings of

the 3rd International Workshop on Reachability Problems. Springer-Verlag, Berlin,

Heidelberg, 2009.

[CBD-15] Hainry, E.: Decidability and undecidability in dynamical systems. Technical

Report. Nancy, 2009.

[CBD-16] Damm, W.; Ihlemann, C.; Sofronie-Stokkermans, V.: Decidability and

complexity for the verification of safety properties of reasonable linear hybrid

automata. In: Proceedings of the 14th international conference on Hybrid systems:

computation and control. ACM, New York, 2011.

[CBD-17] Doboli, A.; Vemuri, R.: Behavioral modeling for high-level synthesis of analog

and mixed-signal systems from VHDL-AMS. In: IEEE Transactions on Computer

Aided Design of Integrated Circuits and Systems. Volume: 22, Issue: 11, 2002.

[CBD-18] Kundert, K.: Principles of top-down mixed-signal design. In: The Designers

Guide Community. 2003.

[CBD-19] Owicki, S.; Gries, D.: Verifying properties of parallel programs: An axiomatic

approach. In: Communications of the ACM. Volume: 19, Issue: 5, 1976.

[CBD-20] Misra, J.; Chandy, K.: Proofs of Networks of Processes. In: IEEE Transactions

on Software Engineering. Volume: 7, Issue: 4, 1982.



Page 30

[CBD-21] Jones, C. B.: Tentative steps toward a development method for interfering

programs. In: ACM Transactions on Programming Languages and Systems (TOPLAS).

Volume: 5, Issue: 4, 1983.

[CBD-22] Lamport, L.: Specifying Concurrent Program Modules. In: ACM Transactions

on Programming Languages and Systems (TOPLAS). Volume: 5, Issue: 2, 1983.

[CBD-23] Pnueli, A.: In transition from global to modular temporal reasoning about

programs. In: Logics and models of concurrent systems. Springer-Verlag, New York,

Berlin, 1985.

[CBD-24] Meyer, B.: Design by Contract. Technical Report: TR-EI-12/CO. Interactive

Software Engineering Inc., 1986.

[CBD-25] Meyer, B.: Eiffel: programming for reusability and extendibility. In: SIGPLAN

Notices. Volume 22, Issue: 2, 1987.

[CBD-26] Meyer, B.: Design by Contract. In: Dino M.; Meyer, B. (Eds.): Advances in

Object-Oriented Software Engineering. Prentice Hall, New York, 1992.

[CBD-27] Meyer, B.: Applying design by contract. In: IEEE Computer Society: Computer.

Volume: 25, Issue: 10, 1992.

[CBD-28] Grumberg, O.; Long, D. E.: Model checking and modular verification. In:

Baeten, J. C.M.; Groote, J.F. (Eds.): Proceeding of the 2nd International Conference on

Concurrency Theory (CONCUR'91). Springer-Verlag, Berlin, Heidelberg, 1991 .

[CBD-29] McMillan, K. L.: A compositional rule for hardware design refinement. In:

Grumberg, O. (Ed.): Computer Aided Verification. Springer-Verlag, Berlin, Heidelberg,

1997.

[CBD-30] Alur, R.; Henzinger, T. A.: Reactive Modules. In: Formal Methods in System

Design. Volume: 15, Issue: 1, 1999.

[CBD-31] Alfaro, L.; Henzinger, T. A.: Interface Automata. In: Proceedings of the Ninth

Annual Symposium on Foundations of Software Engineering. 2001.

[CBD-32] Dill, D. L.: Trace theory for automatic hierarchical verification of speed-

independent circuits. Ph.D.Thesis. MIT Press, Cambridge, 1989.

[CBD-33] Gawlick, R.; Segala, R.; Sogaard-Andersen, J. F.; Lynch, N. A.: Liveness in

Timed and Untimed Systems. In: Proceedings of the 21st International Colloquium on

Automata, Languages and Programming. Springer-Verlag, Berlin, Heidelberg, 1994.

[CBD-34] Gawlick, R.; Segala, R.; Sogaard-Andersen, J.; Lynch, N.: Liveness in Timed

and Untimed Systems. Technical Report: MIT/LCS/TR-587. Massachusetts Institute of

Technology. Cambridge, 1994.

[CBD-35] Segala, R.; Gawlick, R.; Sogaard-Andersen, J.; Lynch, N.: Liveness in Timed

and Untimed Systems. In: Information and Computation. Volume: 141, Issue: 2, 1998.

[CBD-36] Alur, R. & Dill, D. L.: The Theory of Timed Automata. In: Proceedings of the

REX Workshop Real-Time: Theory in Practice. Springer-Verlag, Berlin, Heidelberg,

1991.

[CBD-37] Henzinger, T. A.: The Theory of Hybrid Automata. In: Proceedings of the

Eleventh Annual IEEE Symposium on Logic in Computer Science (LICS '96.'). IEEE

Computer Society Press, 1996.

[CBD-38] Alur, R.; Henzinger, T. A.: Modularity for Timed and Hybrid Systems. In:

Mazurkiewicz, A.;Winkowski, J. (Eds.): Proceedings of the 8th International

Conference on Concurrency Theory. Springer-Verlag, Berlin, Heidelberg, 1997.

[CBD-39] Henzinger, T. A.; Minea, M.; Prabhu, V.: Assume-Guarantee Reasoning for

Hierarchical Hybrid Systems. In: Di Benedetto, M.D.; Sangiovanni-Vincentelli, A.

(Eds.): Proceedings of the 4th International Workshop on Hybrid Systems: Computation

and Control. Springer-Verlag, London, 2001.



Page 31

[CBD-40] Benvenuti, L.; Ferrari, A.; Mangeruca, L.; Mazzi, E.; Passerone, R.; Sofronis,

C.: A contract-based formalism for the specification of heterogeneous systems. In:

Forum on Specification, Verification and Design Languages. 2008.

[CBD-41] Benvenuti, L.; Ferrari, A.; Mazzi, E.; Vincentelli, A. L.: Contract-Based Design

for Computation and Verification of a Closed-Loop Hybrid System. In: Proceedings

of the 11th international workshop on Hybrid Systems: Computation and Control.

Springer- Verlag, Berlin, Heidelberg, 2008.

[CBD-42] Damm, W.; Dierks, H.; Oehlerking, J.; Pnueli, A.: Towards component based

design of hybrid systems: Safety and stability. In: Manna Z.; Peled, Doron A.: Time for

verification - Essays in Memory of Amir Pnueli. Springer-Verlag, Berlin, Heidelberg,

2010.

[CBD-43] Lee, E. A.; Sangiovanni-Vincentelli, A. L.: A framework for comparing models

of computation. In: IEEE Transactions on Computer-Aided Design of Integrated

Circuits and Systems. Volume: 17, Issue: 12, 1998

[CBD-44] Burch, J.; Passerone, R.; Sangiovanni-Vincentelli, A. L: Overcoming

heterophobia: Modeling concurrency in heterogeneous systems. In: Proceedings of

the Second International Conference on Application of Concurrency to System Design.

IEEE Computer Society, 2001.

[CBD-45] Balarin, F.; Lavagno, L.; Passerone, C.; Sangiovanni-Vincentelli, A.; Sgroi, M.;

Watanabe, Y.: Modeling and Designing Heterogeneous Systems. In: Concurrency and

Hardware Design, Advances in Petri Nets. Springer-Verlag, Berlin, Heidelberg, 2002.

[CBD-46] Gössler, G.; Sifakis, J.: Composition for Component-Based Modeling. In: de

Boer, F. S.; Bonsangue, M. M.; Graf, S.; de Roever, W. P. (Eds.): Formal Methods for

Components and Objects. Springer-Verlag, Berlin, Heidelberg, 2003.

[CBD-47] Damm, W.; Votintseva, A.; Metzner, A.; Josko, B.; Peikenkamp, T.; Böde, E.:

Boosting Re-use of Embedded Automotive Applications Through Rich Components.

In: Proceedings of Foundations of Interface Technologies, 2005.

[CBD-48] Damm, W.: Controlling speculative design processes using rich component

models. In: Fifth International Conference on Application of Concurrency to System

Design, 2005.

[CBD-49] Basu, A.; Bozga, M.; Sifakis, J.: Modeling Heterogeneous Real-time

Components in BIP. In: Proceedings of the Fourth IEEE International Conference on

Software Engineering and Formal Methods. IEEE Computer Society, Washington, DC,

2006.

[CBD-50] Graf, S.; Quinton, S.: Contracts for BIP: Hierarchical Interaction Models for

Compositional Verification. In: Proceedings of the 27th IFIP WG 6.1 International

Conference on Formal Techniques for Networked and Distributed Systems.Springer-

Verlag, Berlin, Heidelberg, 2007.

[CBD-51] Josko, B.; Ma, Q.; Metzner, A.: Designing Embedded Systems using

Heterogeneous Rich Components. Proceedings of the INCOSE International

Symposium, 2008.

[CBD-52] Baumgart, A.; Böde, E.; Büker, M.; Damm, W.; Ehmen, G.; Gezgin, T.; Henkler,

S.; Hungar, H.; Josko, B.; Oertel, M.; Peikenkamp, T.; Reinkemeier, P.; Stierand, I.;

Weber, R.: Architecture Modeling. Technical report. OFFIS e.V. Oldenburg, 2011.

[CBD-53] Benveniste, A.; Caillaud, B.; Ferrari, A.; Mangeruca, L.; Passerone, R.; Sofronis,

C.: Multiple viewpoint contract-based specification and design. In: Formal Methods

for Components and Objects. Springer-Verlag, Berlin, Heidelberg, 2008.

[CBD-54] Benveniste, A.; Caillaud, B.; Passerone, R.: Multi-viewpoint state machines

for rich component models. In: Model-Based Design of Heteroeneous Systems. 2009



Page 32

[CBD-55] Lee, E. A.; Sangiovanni-Vincentelli, A. L.: Component-based design for the

future. In: Design, Automation & Test in Europe. Conference & Exhibition (DATE),

2011.

[CBD-56] Damm, W.; Hungar, H.; Josko, B.; Peikenkamp, T. & Stierand, I.: Using

contract-based component specifications for virtual integration testing and

architecture design. In: Design, Automation & Test in Europe. Conference &

Exhibition (DATE), 2011.

[CBD-57] SPEEDS. European Union 6th Framework Project in Embedded Systems

Development (2006-2009). IP Contract No 033471. URL: http://www.speeds.eu.com/.

Accessed: 22nd Mar. 2013.

[CBD-58] CESAR. ARTEMIS Joint Undertaking Project. ART Call 2008 100016. URL:

http://www.cesarproject.eu/. Accessed: 22nd Mar. 2013.

[CBD-59] SPES 2020. BMBF-Project. FKZ: 01IS08045W. URL:

http://spes2020.informatik.tumuenchen.de/spes-home.html. Accessed: 22nd Mar. 2013.

[CBD-60] Sangiovanni-Vincentelli, A.; Damm, W., Passerone, R.: Taming Dr.

Frankenstein: Contract-Based Design for Cyber-Physical Systems. In: European

Journal of Control. Volume: 18, Issue: 3, 2012.

[CBD-61] SPES_XT. BMBF-Project. FKZ: 01IS12005M. URL:

http://spes2020.informatik.tumuenchen.de/spes_xt-home.html. Accessed: 22nd Mar.

2013.

[CBD-62] Benveniste, A.; Caillaud, B.; Nickovic, D.; Passerone, R.; Raclet, J.-B.;

Reinkemeier, P.; Sangiovanni-Vincentelli, A.; Damm, W.; Henzinger, T.; Larsen, K.:

Contracts for Systems Design. Technical report RR-8147. Research Centre Rennes –

Bretagne Atlantique. Rennes Cedex, 2012.

[CBD-63] Borkar, S.: Design challenges of technology scaling. In: IEEE Micro. Volume:

19, Issue: 4, 1999.

[CBD-64] Borkar, S.; Jouppi, N. P.; Stenstrom, P.: Microprocessors in the era of terascale

integration. In: Proceedings of the conference on Design, Automation and Test in

Europe. EDA Consortium, San Jose, 2007.

[CBD-65] Borkar, S.; Chien, A. A.: The future of microprocessors. In: Communications

of the ACM. Volume: 54, Issue: 5, 2011.

[CBD-66] Mudge, T.: Power: A First-Class Architectural Design Constraint. In:

Computer. Volume: 34, Issue: 4, 2001.

[CBD-67] Borkar, S.; Karnik, T.; Narendra, S.; Tschanz, J.; Keshavarzi, A.; De, V.:

Parameter variations and impact on circuits and microarchitecture. In: Proceedings

of the 40th annual Design Automation Conference. ACM, New York, 2003.

[CBD-68] Mehra, R.; Rabaey, J.: Behavioral level power estimation and exploration. In:

Proceedings of the International Workshop on Low Power Design. Napa Valley, 1994.

[CBD-69] Landman, P.: In: High-level power estimation. In: Proceedings of the

International Symposium on Low Power Electronics and Design, 1996.

[CBD-70] Macii, E.; Pedram, M. & Somenzi, F.: High-level power modeling, estimation,

and optimization. In: IEEE Transactions on Computer-Aided Design of Integrated

Circuits and Systems. Volume: 17, Issue:11, 1998.

[CBD-71] Stammermann, A.; Kruse, L.; Nebel, W.; Pratsch, A.; Schmidt, E.; Schulte, M.

& Schultz, A.: System Level Optimization and Design Space Exploration for Low

Power. In: Proceedings of the 14th international symposium on systems synthesis, 2001.

[CBD-72] Gupta, S.; Najm, F. N.: Power Macromodeling for High Level Power

Estimation. In: Proceedings of the 34th annual Design Automation Conference. ACM,

New York, 1997.



Page 33

[CBD-73] Najm, F.: A survey of power estimation techniques in VLSI circuits. In: IEEE

Transactions on Very Large Scale Integration (VLSI) Systems. Volume: 2, Issue: 4,

1994.

[CBD-74] Pedram, M.: Power simulation and estimation in VLSI circuits. In: Chen, W.

K. (Ed.): The VLSI handbook. CRC Press, IEEE Press, New York, 1999.

[CBD-75] Anderson, J. H.; Najm, F. N.: Power estimation techniques for FPGAs. In:

IEEE Transactions on Very Large Scale Integration (VLSI) Systems. Volume: 12, Issue:

10, 2004.

[CBD-76] Ahuja, S.: High Level Power Estimation and Reduction Techniques for Power

Aware Hardware Design. PhD thesis. Virginia Polytechnic Institute and State

University, 2010.

[CBD-77] Lorenz, D.; Grüttner, K.; Bombieri, N.; Guarnieri, V.; Bocchio, S.: From RTL

IP to functional system-level models with extra-functional properties. In: Jerraya, A.;

Carloni, L. P.; Chang N.; Fummi, F. (Eds.): Proceedings of the 8th IEEE/ACM/IFIP

international conference on Hardware/software codesign and system synthesis. ACM,

New York, 2012.

[CBD-78] Kosmann, Lars; Reimer, A.; Helms, D.; Nebel, W.: Profilbasierte

Energieabschätzung integrierter Schaltungen auf algorithmischer Ebene. In:

Proceedings of the 16. Workshop Methoden und Beschreibungssprachen zur

Modellierung und Verifikation von Schaltungen und Systemen.

[CBD-79] Lescot, J.; Bligny, V.; Medhat, D.; Chollat-Namy, D.; Lu, Z.; Billy, S.;

Hofmann, M.: Static low power verification at transistor level for SoC design. In:

Proceedings of the ACM/IEEE International Symposium on Low Power Electronics and

Design. ACM, 2012.

[CBD-80] Silicon Integration Initiative (Si2): Si2 Common Power Format Specification.

2011.

[CBD-81] IEEE Computer Society; Design Automation Committee; IEEE Standards

Association; Corporate Advisory Group; Institute of Electrical and Electronics

Engineers; IEEE-SA Standards Board: IEEE Standard for Design and Verification

of Low-Power Integrated Circuits. 2013.

[CBD-82] Mukherjee, R.; Srivastava, A.; Bailey, S.: Static and Formal Verification of

Power Aware Designs at the RTL using UPF. In: Proceedings of DVCon, 2008.

[CBD-83] Hazra, A.; Mitra, S.; Dasgupta, P.; Pal, A.; Bagchi, D.; Guha, K.: Leveraging

UPFextracted assertions for modeling and formal verification of architectural power

intent. In: Proceedings of the 47th Design Automation Conference. ACM Press, New

York, 2010.

[CBD-84] Mbarek, O.; Khecharem, A.; Pegatoquet, A.; Auguin, M.: Using model driven

engineering to reliably accelerate early Low Power Intent Exploration for a

system-on-chip design. In: Proceedings of the Annual ACM Symposium on Applied

Computing. 2012.

[CBD-85] Mbarek, O.; Pegatoquet, A.; Auguin, M.: A methodology for power-aware

transaction-level models of systems-on-chip using UPF standard concepts. In:

Integrated Circuit and System Design. Power and Timing Modeling, Optimization and

Simulation. Springer, 2011.

[CBD-86] Mbarek, O.: An Electronic System Level Modeling Approach for the Design

and Verification of Low-Power Systems-on-Chip. PhD Thesis. Université de Nice-

Sophia- Antipolis, 2013.

[CBD-87] Saptarshi, B.: Low-Power Design Applications for Formal Verification.

SOCcentral, 7th May 2010. URL:



Page 34

http://www.soccentral.com/results.asp?CatID=488&EntryID=31280. Accessed: 24th

Feb. 2013.

[CBD-88] Hazra, A.; Dasgupta, P.; Banerjee, A.; Harer, K.: Formal methods for coverage

analysis of architectural power states in power-managed designs. In: Proceedings of

the 17th Asia and South Pacific Design Automation Conference (ASP-DAC), 2012.

[CBD-89] Loh, L.: Formal Methods for Power-Aware Verification. EE Times, 17. Dec.

2012. URL: http://www.eetimes.com/design/eda-design/4403514/Formal-methods-for-

power-awareverification?Ecosystem=eda-design. Accessed: 24th Feb. 2013.

[CBD-90] Benini, L.; Bogliolo, A.; De Micheli, G.: A survey of design techniques for

system-level dynamic power management. In: IEEE Transactions on Very Large Scale

Integration (VLSI) Systems. Volume: 8, Issue: 3, 2000.

[CBD-91] Chedid, W.; Yu, C.: Survey on power management techniques for energy

efficient computer systems. Technical report. Mobile Computing Research Lab.

Cleveland State University, Cleveland, 2002.

[CBD-92] Damm, W.; Mikschl, A.; Oehlerking, J.; Olderog, E.-R.; Pang, J.; Platzer, A.;

Segelken, M.; Wirtz, B.: Automating Verification of Cooperation, Control, and

Design in Traffic Applications. In: Formal Methods and Hybrid Real-Time Systems.

Springer-Verlag, Berlin, Heidelberg, 2007.

[CBD-93] Bhaduri, P.; Stierand, I.: A Proposal for Real-time Interfaces in SPEEDS. In:

Proceedings of the Conference on Design, Automation and Test in Europe. European

Design and Automation Association, Belgium, 2010.

[CBD-94] Baumgart, A.; Reinkemeier, P.; Rettberg, A.; Stierand, I.; Thaden, E.; Weber,

R.: A Model–Based Design Methodology with Contracts to Enhance the Development

Process of Safety–Critical Systems. In: Min, S.L.; Pettit, R.; Puschner, P.; Ungerer Th.

(Eds.): Proceedings of the 8th IFIP WG 10.2 international conference on software

technologies for embedded and ubiquitous systems. Springer-Verlag, Berlin,

Heidelberg, 2011.

[CBD-95] Sun, X.; Nuzzo, P.; Wu, C.-C.; Sangiovanni-Vincentelli, A.: Contract-based

system-level composition of analog circuits. In: Proceedings of the 46th Annual Design

Automation Conference. ACM, New York, 2009.

[CBD-96] Ferrari, A.; Sangiovanni-Vincentelli, A.: System Design: Traditional Concepts

and New Paradigms. In: Proceedings of the 1999 IEEE International Conference on

Computer Design. IEEE Computer Society, Washington, DC, 1999.

[CBD-97] Ferrari, A.; Sangiovanni-Vincentelli, A.: System-level design:

orthogonalization of concerns and platform-based design. In: IEEE Transactions on

Computer-Aided Design of Integrated Circuits and Systems. Volume: 19, Issue 12,

1999.

[CBD-98] Carloni, L.; De Bernardinis, F.; Pinello, C.; Sangiovanni-Vincentelli, A.; Sgroi,

M.: Platform-Based Design for Embedded Systems. In: The Embedded Systems

Handbook. CRC Press, 2005.

[CBD-99] De Bernardinis, F.; Nuzzo, P.; Vincentelli, A. S.: Mixed signal design space

exploration through analog platforms. In: Proceedings of the 42nd annual Design

Automation Conference. ACM, New York, 2005.

[CBD-100] Quinton, S.; Graf, S.; Passerone, R.: Contract-based reasoning for

component systems with complex interactions. Verimag Research Report n. TR-

2010-12. 2010

[CBD-101] Bauer, S. S.; David, A.; Hennicker, R.; Guldstrand Larsen, K.; Legay,

A.; Nyman, U.; Wąsowski, A.: Moving from specifications to contracts in

component-based design. In: Proceedings of the 15th international conference on

Fundamental Approaches to Software Engineering. Springer-Verlag, 2012.

http://www.soccentral.com/results.asp?CatID=488&EntryID=31280



Page 35

[CBD-102] Le, T. T. H.; Fahrenberg, U.; Legay, A.; Passerone, R.: An Operational

Contract Framework for Heterogeneous Systems. Technical Report n. DISI-12-029.

University of Trento. Povo, 2012

[CBD-103] Graf, S.; Passerone, R., Quinton, S.: Contract-Based Reasoning for

Component Systems with Rich Interactions. In: Sangiovanni-Vincentelli, A.; Zeng,

H.; Di Natale, M.; Marwedel, P. (Eds.): Embedded Systems Development. Springer-

Verlag, New York, 2014.

[CBD-104] Beeby, S. P.; Tudor, M. J.; White, N. M.: Energy harvesting vibration

sources for microsystems applications. In: Measurement science and technology,

Volume: 17, Issue: 12, 2006.

[CBD-105] Liu, Y.; Zhu, H.: In: A survey of the research on power management

techniques for high-performance systems. In: Software: Practice and Experience,

Volume: 40, Issue: 11, 2010.

[CBD-106] ENERSAVE. BMBF-Project. FKZ:16BE1102. URL: www.tu-

chemnitz.de/EnerSave/. Accessed: 27th Feb. 2013.

[CBD-107] Steinhorst, S.; Jesser, A.; Hedrich, L.: Advanced Property Specification

for Model Checking of Analog Systems. In: ITG-Fachbericht: ANALOG'06. VDE-

Verlag, Berlin, Offenbach, 2006.

[CBD-108] Steinhorst, S.: Formal Verification Methodologies for Nonlinear

Analog Circuits. PhD thesis. Goethe-Universität Frankfurt. Frankfurt, 2011.

[CBD-109] Maler, O.; Nickovic, D.: Monitoring Temporal Properties of

Continuous Signals. In: Lakhnech, Y.; Yovine, S. (Eds.): Formal Techniques,

Modelling and Analysis of Timed and Fault-Tolerant Systems - Proceedings of the Joint

International Conferences on Formal Modelling and Analysis of Timed Systems

(FORMATS) and Formal Techniques in Real-Time and Fault-Tolerant Systems

(FTRTFT). Springer, Berlin, Heidelberg, 2004.

[CBD-110] Accellera: Property Specification Language - Reference Manual.

Version 1.01. 2003.

[CBD-111] IEEE/IEC: Standard for Property Specification Language (PSL) –

International Standard IEEE 1850-2005 / IEC 62531-2007. The Institute of Electrical

and Electronics Engineers Inc. (IEEE) / International Electrotechnical Commission

(IEC) Central Office. Edition 1.0, 2007.

[CBD-112] Maler, O.: Extending PSL for Analog Circuits. PROSYD Deliverable

(D1.3/1), 2005.

[CBD-113] Nickovic, D.: Checking Timed and Hybrid Properties: Theory and

Applications. PhD thesis. University Joseph Fourier Grenoble. Grenoble, 2008.

[CBD-114] Lämmermann, S.; Jesser, A.; Rathgeber, M.; Ruf, J.; Hedrich, L.; Kropf,

T.; Rosenstiel, W.: Checking Heterogeneous Signal Characteristics Applying

Assertion-Based Verification. In: Proceedings of the Conference on Formal

Verification of Analog Circuits. Grenoble, 2009.

[CBD-115] Lämmermann, S.; Ruf, J.; Kropf, T.; Rosenstiel, W.; Viehl, A.; Jesser,

A.; Hedrich, L.: Towards assertion-based verification of heterogeneous system

designs. In: Proceedings of the Conference on Design, Automation and Test in Europe.

Dresden, 2010.

[CBD-116] Lämmermann, S.: Domänenübergreifende temporale

Eigenschaftsverifikation heterogener Systeme. PhD thesis. Eberhard Karls Universität

Tübingen. Tübingen, 2011.

[CBD-117] Mitschke, A.: Definition and exemplification of RSL and RMM.

CESAR Deliverable (D_SP2_R2.1_M1), 2010.

http://www.tu-chemnitz.de/EnerSave/

http://www.tu-chemnitz.de/EnerSave/



Page 36

[CBD-118] Reinkemeier, P.; Stierand, I.; Rehkop, P.; Henkler, S.: A pattern-based

requirement specification language - Mapping automotive specific timing

requirements. In: Software Engineering 2011 Workshopband. Köllen Druck + Verlag

GmbH, Bonn, 2011.

[CBD-119] Wolf, E.: Evaluation formaler Spezifikationssprachen für den

Entwurf gemischt analog-digitaler Systeme. Masterarbeit. Technische Universität

Ilmenau, 2012.

[CBD-120] Cimatti, A.; Tonetta, S.: A Property-Based Proof System for Contract-

Based Design. In: 38th EUROMICRO Conference on Software Engineering and

Advanced Applications (SEAA). 2012

[CBD-121] Cimatti, A.; Roveri, M.; Susi, A.; Tonetta, S.: Validation of

requirements for hybrid systems: A formal approach. In: ACM Transactions on

Software Engineering and Methodology (TOSEM). ACM, 2013.

[CBD-122] Nitsche, G.; Grüttner, K.; Nebel, W.: Power Contracts: A Formal Way

Towards Power-Closure?! In: Proceedings of the 23rd International Workshop on

Power and Timing Modeling, Optimization and Simulation (PATMOS'13). IEEE, 2013.

[CBD-123] Baumgart, A.: A common meta-model for the interoperation of tools

with heterogeneous data models. In: Proceedings of the 3rd Workshop on Model-

Driven Tool & Process Integration (MDTPI2010) at the European Conference on

Modelling Foundations and Applications (ECMFA2010). Paris, 2010.

[CBD-124] Baumgart, A.; Ellen, C.; Oertel, M.; Rehkop, P.; Farfeleder, S.; Schulz,

S.: A Reference Technology Platform with Common Interfaces for Distributed

Heterogeneous Data. In: Proceedings of the Embedded World 2012 Exhibition and

Conference. Nürnberg, 2012.

[CBD-125] IEEE: Standard for IP-XACT – Standard Strcuture for Packaging,

Integrating, and Reusing IP within Tool Flows. IEEE Standard 1685-2009. The

Institute of Electrical and Electronics Engineers Inc. (IEEE). Edition 1.5, 2009.

[CBD-126] Lorenz, D.; Hartmann, P. A.; Grüttner, K.; Nebel, W.: Non-invasive

Power Simulation at System-Level with SystemC. In: Ayala, J. L.; Shang, D.;

Yakovlev, A. (Eds.): Proceedings of the International Workshop on Power and Timing

Modeling, Optimization and Simulation (PATMOS) 2012. Springer-Verlag, 2012,

[CBD-127] Urdahl, J.; Stoffel, D.; Bormann, J.; Wedler, M.; Kunz, W.: Path

Predicate Abstraction by Complete Interval Property Checking. In: Proceedings of

the International Conference on Formal Methods in Computer-Aided Design

(FMCAD). 2010.

[CBD-128] Urdahl, J.; Stoffel, D.; Wedler, M.; Kunz, W.: System Verification of

Concurrent RTL Modules by Compositional Path Predicate Abstraction. In:

Proceedings of the 49th Annual Design Automation Conference (DAC). 2012.

[CBD-129] Alessandro Cimatti, Michele Dorigatti and Stefano Tonetta: OCRA: A

tool for checking the refinement of temporal contracts. In: Conference on Automated

Software Engineering (ASE), 2013 IEEE/ACM 28th International, pages 702–705,

2013.

[CBD-130] Alessandro Cimatti, Marco Roveri, Angelo Susi and Stefano Tonetta:

Validation of requirements for hybrid systems: A formal approach. ACM

Transactions on Software Engineering and Methodology (TOSEM), 21(4), February

2012



Page 37

5 Extensions for Networking

Here we include modeling elements that are useful to realize the validation of distributed

applications deployed on communication resources subject to certain error rate. This allows for

the modeling of embedded systems connected through partially reliable networks and a high

level characterization of the network.

MARTE is suitable for the low level accounting of resource usage in time, and this is also

applicable to the networks when they are schedule with concrete arbitration strategies; but when

general purpose networks are used or when not detailed accounting of networking needs is

available, a high level characterization of communication needs and available capacities can be

used. This scales up well not only to general purposes traditional internet protocols but also to

wireless and mobile communication.

This chapter is organized in three sections. The first consider extensions to MARTE that help

to model the network topology, and the overheads on processors due to the handling of packets

to be sent and received. The second proposes extensions to the modeling of the necessary

workloads, both, in communication and computing oriented. The last proposes a complete set

of modeling elements to capture specific analysis contexts for the validation of required

communication needs deployed on the available platforms.

5.1 Topology and platform overheads due to communication

Since MARTE profile is devoted to model real time embedded systems, it lacks precise

semantics related to networked embedded systems which are mainly for the communication

aspects between embedded elements.

Fortunately, and contrary to an often expressed opinion, MARTE had addressed the main

elements of such systems and it is not necessary to add new fundamental modeling concepts to

MARTE profile. Instead, the work being done in the specification consisted of defining new

stereotypes for the communication aspects of embedded systems such as network interfaces.

Therefore, we have introduced new stereotypes to extend the semantics of MARTE profile,

stereotypes are:

1. AbstractChannel,

2. NetworkInterface



Page 38

CommunicationResource

elementSize : Integer

CommunicationMedia

packetSize : Integer

CommunicationEndPoint

0..* 1..*mediaendPoint

overhead : WorkloadBehabior

NetworkInterface

ComputingResource

speedFactor: NFP_Real

ProcessingResource

0..*

1..*host

nwInterface

resMult: Integer

isProtected : Boolean

isActive : Boolean

Resource

errorRate : NFP_Percentage

wireless: Boolean

AbstractChannel

1..* nwInterface

A ProcessingResource generalizes the concepts of CommunicationMedia,

ComputingResource, and active DeviceResource. It introduces an element that abstracts

the fundamental capability of performing any behavior assigned to the active classifiers

of the modeled system. Fractions of this capacity are brought to the

SchedulableResources that require it.

A CommunicationResource represents any resource used for communication and may

be considered as a collector of communication services. It generalizes the two kinds of

communication resources defined, communicationEndpoint and communicationMedia.

A ComputingResource represents either virtual or physical processing devices capable

of storing and executing program code. Hence, its fundamental service is to compute,

what in fact is to change the values of data without changing their location. It is active

and protected.

A CommunicationEndPoint acts as a terminal for connecting to a communication

media, and it is characterized by the size of the packet handled by the endpoint. This

size may or may not correspond to the media element size. Concrete services provided

by a CommunicationEndPoint include the sending and receiving of data, as well as a

notification service able to trigger an activity in the application.

A CommunicationMedia represents the means to transport information from one

location to another (e.g., message of data). It has as an attribute the size of the elements

transmitted; as expected, this definition is related to the resource base clock. For



Page 39

example, if the communication media represents a bus, and the clock is the bus speed,

“element size” would be the width of the bus, in bits. If the communication media

represents a layering of protocols, “element size” would be the frame size of the

uppermost protocol.

A NetworkInterface acts as an interface to connect a physical device with a

communication media. It has an attribuite WorkloadBehavior which represents a given

load of processing flows triggered by external (e.g., environmental events) or internal

(e.g., a timer of the communication protocol) stimuli. The processing flows are modeled

as a set of related steps that contend for use of processing resources and other shared

resources. It may contain the communication protocol agent.

A Node represents physical processing devices capable of storing and executing

program code. It can be seen as a container of tasks. At the end of the application design

flow, nodes will become HW entities with CPU and network interface and tasks will be

implemented either as HW components or as SW processes. It can be fixed or mobile

node.

An AbstractChannel is a generalization of network channels since it contains the

physical channel, and all the protocol entities up to level N-1. It has an attribute

errorRate which defines the bit error rate of it. It has an attribute wireless to define if it

is wire or wireless channel.

5.2 Extensions for modeling general purpose networking workloads

As it was mentioned in section 5.1 that MARTE has provided the main elements for modeling

embedded systems but it lacks some semantics related to networked embedded systems.

Therefore, MARTE elements may be extended to compensate such lack. For example, Quality

of Service of the communication media between embedded device in terms of, delay,

throughput, error rate, is considered as an important feature to measure the performance of such

applications.

Therefore, we have introduced new stereotypes to extend the semantics of MARTE profile,

stereotypes are:

1- CommunicationRequirements

2- CommunicatingTask



Page 40

msgSize: NFP_DataSize

CommunicationStep

maxErrorRate: NFP_Percentage

maxThroughput: NFP_Frequency

maxDelay: NFP_Duration

CommunicationRequirements

RtUint

CommunicatingTask

isDynamic : Boolean

isMain : Boolean

memorySize : NFP_DataSize

srPoolPolicy : PoolMgtPolicy

srPoolWaitingTime : NFP_Duration

requiresMobility: Boolean

isPeriodic: Boolean

A CommunicationStep is an operation of sending a message over a

CommunicationResource that connects the host of its predecessor Step, to the host of

its successor Step.

A CommunicationRequirements are the requirements of a data flow to be assigned to

an abstract channel and that to establish the communication between two tasks. It has

three attribuites, maxErrorRate is the maximum number of errors tolerated by the

destination; maxThroughput is the maximum amount of transmitted information in the

time unit; maxDelay is the maximum permitted time to deliver data to destination.

A RtUnit is real-time unit and it owns at least one schedulable resource but can also

have several ones. If its dynamic attribute is set to true, the resources are created

dynamically when required. In the other case, the real-time unit has a pool of scheduling

resources. When no schedulable resources are available in the possible, the real-time

unit may either wait indefinitely for a resource to be released, or wait only a given

amount of time (specified by its poolWaitingTime attribute), or dynamically increase

its pool of thread to adapt to the demand, or generate an exception. A real-time unit may

own behaviors. It also owns a message queue used to store incoming messages. The size

of this message queue may be infinite or limited. In the latter case, the queue size is

specified by its maxSize attribute. In addition, a real-time unit owns a specific behavior,

called operational mode. This behavior takes usually the form of a state-based behavior

where states represent a configuration of the real-time unit and transition denotes

reconfigurations of the unit.

A CommunicatingTask represents a basic functionality of the whole application; it

takes some data as input and provides some output. It should be allocated in a Node to

perform its operation. It has an attribute named requiresMobility to define its

requirement to be allocated in a mobile or fixed node. It can be periodic or aperiodic

task and it is specified from isPeriodic attribute.



Page 41

5.3 Allocation and models for network analysis

In this section we extend MARTE communciationChannel element by a new stereotype for

DataFlow to express the communication requirements of the data flow from the communication

channel.

msgSize: NFP_DataSize

utilization: NFP_Real

CommunicationChannel

communciationRequirements:

CommunicationRequirements [*]taskSource: Task [*]

taskDestination: Task [*]

DataFlow

A CommunicationChannel is logical communications layer connecting

SchedulableResources.

A DataFlow represents the communication requirements between two tasks; output

from a source task (taskSource) is delivered as input to a destination task

(taskDestination). It has an attribuite communciationRequirements which describes the

communication requires to perform the communcaition between two tasks. It should be

allocated in an abstractChannel to perform its operations.



Page 42

6 Extensions for the management of modeling configurations

The extensions that may become useful to manage the different models and diagrams that are

necessary along the variants of the development process used by the different partners in the

project, are not really a fundamental increment in the modelling power of the meta-model, but

may be a methodological enhancement that really helps to trace models along the development

process. By modeling configurations we understand the concrete diagrams and models

necessary for each combination of viewpoints, abstraction levels and NFPs of interest as they

are presented in the introduction of this document.

6.1 Stages in the development process: Refinement and abstraction

Here we consider the management of requirements for tracing them along the development

process. This is heavily dependent on the development procedures of the practitioner normative

environment.

6.2 Perspectives viewpoints and views

We consider here the new proposals for the managements of viewpoints in recent versions of

UML plus the discussions on the SySML revision task force at the OMG.

6.3 Management of V&V for specific NFPs of interest

Here it is important to assess the use of current NFP types in MARTE for modeling those

properties in the CONTREX use cases. Additional practical experience is necessary to identify

tools and methodologies to manipulate NFP annotations.



Page 43

7 Link to other formalisms

Being this a requirement identified in the survey, and considering the convenience of having at

hand the semantics of other formalisms for facilitating the link to them, here we include the

study of certain MoC. There have not been so far elements to add to MARTE in the CONTREX

meta-model, but its formalization with UML will require the semantics clarifications here

included.

7.1 System-Level modeling Specification and Modelling Methodologies

As mentioned in Section 2.2.1, a number of works, and specifically, UC and KTH, have

background and tooling to support system-level specification relying on MoC theory.

Moreover, background tackling the support of MoC-based modeling in UML/MARTE was

referred.

However, it was also mentioned that an assessment of MoC support for the purposes of

CONTREX was also convenient, to ensure the applicability of the MoC based available tools

and flows.

Because of that, an assessment to confirm the suitability of the currently defined metamodel

under MoCs perspective has been done. So far, no need for the extension has been found.

However, the task of defining a synthetic and useful metamodel is better defined once the

modeling and design methodologies it serves are completely defined, it makes sense the update

of this assessmentafter the development of the modeling (T.2.2) and analysis methodologies

(T2.3).

In order to perform the assessment in a structured way, the objectives (and the priority order)

with regard to the modeling methodology are the following:

Completeness: the elements of the metamodel shall be sufficient for capturing the

information and semantics of the targeted MoCs without ambiguity.

Semantics coherence: the CONTREX metamodel should support UML+MARTE

models supporting the SDF and SR MoC semantics, without semantic incompatibilities.

Suitability for later design phases: the CONTREX metamodel shall support the

extension of the UML/MARTE model with additional annotations and information

regarding functionality. For instance, the KTH analysis and tools require the annotation

of worst-case execution times and memory usages for each actor in the input SDF graph

which describes the application.

Feasibility: tool development and integration, and the application of the partner

methodologies shall be feasible in the CONTREX effort and time bounds.

Efficient Modelling: The task of the modeler should be as light as possible



Page 44

Moreover, a procedure for the assessment has been defined. A first decision made in the

assessment was to first focus on the Synchronous Dataflow (SDF) untimed model of

computation. This is a well-know MoC and with much associated literature and precise

executive semantics and modeling conditions described, e.g. [18]. Moreover, some CONTREX

partners provide tools based on this MoC, and other third party tools, e.g. SDF3, are also

available and of high utility for ensuring the correctness and analyzability of the model. After

assessing SDF, the (ForSyDe) synchronous MoC is considered. For it, it will be exploited that

the (ForSyDe) synchronous MoC can be related to a homogeneous SDF where the signals are

extended with the no-value, plus additional constraints on signal events related to time

semantics.

Moreover, for the analysis, the tutorial examples of the ForSyDe methodology have been

selected as a reference. They are simple, but yet rich in modeling elements and aspects requiring

consideration. They enable the introduction of basic and important aspects on semantics,

initialization and feedback loops. These aspects are analyzed first. Later on, composability is

tackled, since these aspects are not straightforward when preservation of semantics, properties

and analyzability are considered. Such aspects are discussed through the implementation of the

example both in ForSyDe-SystemC and in HetSC methodologies. Then, the same aspects are

tackled for devised UML/MARTE approaches, where the background is considered too.

Figure 7.1 shows the graph representation of the example proposed for the assessment of the

support of the SDF MoC [18] in UML/MARTE.

Figure 7.1: Example used for assessing SDF MoC in UML/MARTE.

Such an apparently simple example serves for introducing practically all the aspects of the

information carried by and implicit in an SDF model (kinds of computation nodes,

communication edges, semantics, aspects not involved by the semantics, feedback, etc). A

detailed discussion is given in [17], where the support of MoCs in MARTE for the CONTREX

methodologies is assessed and reported.

Moreover, Figure 7.1 serves to show that an important part of the information in a SDF model

can be captured as an SDF graph, or SDFG in short. The only SDFG enables the application of

several system-level analyses. Specifically, [17] shows how by capturing such graph under the

SDF3 format, we can confirm the consistency of the graph, that it is deadlock free, etc.

Additionally, Figure 7.1 shows the link of specific functionality to the graph nodes. Adding

such information enables an SDF executable model. To build a SDF executable model,

ForSyDe-SystemC or a SDF HetSC methodologies can be used, which, as well as executable,

can also serve for early functional validation.

As was mentioned, the first aspect tackled is a precise discussion on how the structure of

concurrency is captured and which is the specific executive semantics of the model. Figure 7.2

src us

11

av

g

ds

1

sn

k

src upsrc res

din

downres 1 1

3

2 2

2 3 2 1 2

src_fun us_fun avg_fun ds_fun snk_fun

init_fun



Page 45

and Figure 7.3 show a sketch the same abstract model of Figure 7.1 under the ForSyDe-

SystemC and HetSC methodologies respectively, thus showing the modeling elements each of

these methodologies employ. In the former case, it is relevant the use of process constructors,

which in ForSyDe-SystemC (SystemC implementation of ForSyDe) are encapsulated within

SystemC modules. Therefore, an SDF node is modeled as a SystemC module enclosing a

SystemC process. HetSC instead, directly relates the SDF node to a SystemC process, without

preventing the user to wrap up it with a SystemC module.

Figure 7.2: Sketch of the example (single level of hierarchy) in ForSyDe-SystemC

Figure 7.3: Sketch of the HetSC model with a single level of hierarchy.

A more distinguishing characteristic of the HetSC methodology is that much of the semantics

of the model rely on channels semantics. This explains that in the HetSC SDF model rates are

defined as an attribute of the channel employed, a HetSC provided channel called uc_arc.

There are other less remarkable distinctions. For instance, ForSyDe-SystemC uses a delay

element in order to capture the initial tokens, while in HetSC the initial tokens can be directly

injected into the uc_arc channel.

Other distinctions not so apparent in the model refer to the extent at which both ForSyDe-

SystemC and HetSC guarantee some of the constraints or conditions associated to the model

e.g. about process structure, limitation on the number of processes writing and or reading, etc.

However, there are many similarities, apart from abiding SDF rules and executive semantics,

such as that each SDF node is mapped to a SystemC process, thus a concurrent activity, or that

modular hierarchy is supported and that it is orthogonal to the executive semantics, i.e. without

involvements on the executive semantics.

us1 avg

1 ds1 snk src

avginit

SDF::delay

SDF::comb2 SDF::comb SDF::comb SDF::source SDF::sink

SDF::signa

l SDF::signa

l SDF::signa

l

SDF::signa

l

0,0


src upsrc

dout din

res downres 1 1 1

2

2

2

3

2

2 2 3

us

1

avg1 ds

1 snk sr

c

uc_arc

SDF_NODE SDF_NODE SDF_NODE SDF_NODE SDF_NOD

E

uc_arc

0,0


src upsrc

din

res downres

uc_arc uc_arc uc_arc 1 1 2 3

2 2

2 3 2 1



Page 46

A detailed overview of SDF aspects and semantics, and how they are captured in ForSyDe-

SystemC and HetSC are provided in [17].

Once the modelling elements, modelling constraints and semantics defining SDF MoC are

stated, the next step is to explore UML/MARTE models which can be linked directly or

indirectly (through transformations) to SDF executable and analyzable counterparts, always

aiming the objective declared at the beginning of this section.

A first fact that has been realised is that given the richness of modelling elements and extension

mechanisms provisioned by UML, there is a large variety of possible approaches that can be

proposed. The ForSyDe-SystemC and HetSC methodologies and the aforementioned objectives

have been considered to limit the alternatives to be assessed in the definition of the modelling

methodology. However, the assessment of several alternatives ranging from the generality to

versions close to the aforementioned methodologies is convenient yet. More generic

UML/MARTE modelling approaches push model exchange and reuse, while more specific

versions “flavoured” to be closer to specific methodologies enables potentially more efficient

modelling approaches and synthetic models, and surely intermediate representations which can

facilitate the bridging between a generic UML/MARTE model (the main target) and the existing

MoC-based modelling and analysis methodologies.

Starting by “flavoured” approaches facilitates also initial proposals and the reasoning about

how to abstract them towards a common UML/MARTE model. Figure 7.4 shows a composite

diagram of a ForSyDe flavoured UML/MARTE model capturing the Figure 7.1 example.

Figure 7.4: ForSyDe flavoured UML/MARTE model for the assessed example.

By means of a composite diagram, UML enables to capture most of the structural information

of the SDFG. Specifically, SDFG nodes and edges are captured as properties typed as UML

components and connectors.

A composite diagram matches well specific aspects of ForSyDe-SystemC. In effect, the SDF

nodes are captures as UML component instances, that is as UML properties, which matches

well the way ForSyDe-SystemC processes are captured in SystemC, that is as SystemC module

instances with ports (to abide the pattern imposed by a process constructor), UML Connectors

enable a very synthetic capture of the SDF edge, also enabling a one to one correspondence to

the ForSyDe-SystemC SDF::signal.

UML port multiplicity (e.g. 1..* for the out port of the avg1 instance in Figure 7.4) enables to

capture the output multiport connection supported by ForSyDe-SystemC. Similarly, a

multiplicity 1 can be declared for input ports (shown for some ports in Figure 7.4), which



Page 47

ensures that the SDF composition rule which limits the number of readers of an arc is directly

captured in UML. SDF has another rule which states that there should be a single writer to an

actor. This is applied strictly in HetSC, and also in ForSyDe-HetSC, since a SDF signal

connects only to one port of the output multi-port. In the UML/MARTE model shown in Figure

7.4 this means that the number of arcs connected shall not exceed the multiplicity of the port.

MARTE specific aspects are also visible in the Figure 7.4 composite diagram. Specifically,

ports with the MARTE <<FlowPort>> stereotype are used to capture the direction of the data

(recall that a SDFG is a directed graph).

To complete the capture of a SDFG, the modelling of consumption and production rates is

required. For this, an approach inspired on the solution adopted in [8] is shown. Specifically, it

consists in associating the MARTE stereotype <<CommunicationEndPoint>> to both the input

and output flow ports. This stereotype adds the attributes “resMult” and “packetSize”, in such

a way that the value of the “restMult” attribute is interpreted as the amount of packets sent,

when referring to the output flow port, and to the amount of packets received, when referring

to the input port, for each node firing1. The “packetSize” enables to model the data volume

moved and associated to each packet (token in SDF terms) and transferred through a connector

(arc in SDF terms). This data is useful for later performance analysis activities.

1 The solution in [8] uses a <<storageResource>> for the receiving side. This would cover the proposed case, but it also adds an additional semantics in the sense that it assumes that the consumer node has a receiver buffer. SDF does not fix if an implementation should use a transmission buffer, a receiver buffer, or both. Therefore, the solution proposed seems to corresponds more the to the abstraction level of the SDF semantics, and to provide a solution with the same symmetry that theoretical work attributes to the SDF MoC.



Page 48

Figure 7.5: Capture of rates in the ForSyDe flavoured UML/MARTE model of the assessed

example.

In order to enable a SDF functional model, yet information regarding the data type transferred,

and links to functionality are required. UML and MARTE provide mechanisms for capturing

data primitive types and complex types, for instance, through the UML Datatype for primitive

types, and through classes, for complex types. In turn, UML ports can be typed by referring

the aforementioned types, classes and complex types. Therefore, the model can capture not only

the amount of data associated to the token (through the “packetSize” attribute in the ports), but

also the logic structure of such tokens or “packets” transferred. This scheme requires checking

the coherence of the packet sizes and data types associated to connected input and output ports.

Figure 7.6: Port Data typing in the ForSyDe flavoured UML/MARTE model. Data types are

previously captured in the model.

In order to capture the functionality, elements as the UML Opaque behavior enable the

association (through UML usage relationships) of functionality. The opaque behavior enables

the description of a functionality name and also of input and output parameters.



Page 49

Figure 7.7: Association of functionality to the nodes in the ForSyDe flavoured UML/MARTE

model.

The example shown until here, regardless other variants being assessed in the definition of the

modelling methodology, serves to illustrate that there is no immediate need for elements out of

the UML or the MARTE metamodel for enabling the capture of the information which can be

associated to a SDF system-level model.

However, to ensure that the enabled model has a specific executive semantics which prevents

any kind of ambiguity when the model is exchanged among parties is as important as enabling

means for capturing the structure and the explicit information associated to a model. A common

mechanism employed and enabled by UML for associating more specific semantics to model

elements is the definition of a methodology specific profile. Figure 7.8 shows a reduced SDF

profile which would be sufficient for the purposes of the shown example.

Figure 7.8: Sketch of ForSyDe SDF profile for the ForSyDe flavoured UML/MARTE model.



Page 50

Figure 7.9: Applying an SDF stereotype to a whole component to involve SDF semantics on

the whole inner content.

With this profile, the semantics of a specific MoC can be associated to an ambit, specifically to

the internal ambit of a UML component. Figure 7.9 shows how it can be done in the example,

by applying the “SDF” stereotype, defined in the Figure 7.8 profile, to the “top” component.

Through this synthetic mechanism it is stated that all the inner elements of the component have

associated a SDF specific semantics [18]. This mechanism saves modelling effort and enables

to keep and distinguish different MoCs in a heterogeneous model, by means of different

components with the corresponding “MoC stereotypes”.

In case the user desires to merge modelling elements belonging to different models of

computation within a single component model (which is often called amorphous

heterogeneity), then the remaining profile elements shown in Figure 7.8 are useful.

Figure 7.10 illustrates how the modelling patterns can be captured as a library of components,

where each component captures process constructors semantics. In Figure 7.10 solution, the

specific semantics of each component is stated by stereotyping (with stereotypes of the profile

sketched in Figure 7.8).

These components can be instantiated within a component together with components belonging

to other MoC, thus enabling the aforementioned amorphous heterogeneity.

Figure 7.10: Component library where each component is stereotyped for associating a specific

semantics.



Page 51

Therefore, profile definition enables a synthetic an unambiguous modelling approach. This can

be also exploited in the support of the synchronous Mo. The capability to define types can cover

the modelling of the “no-value”. It can be then safely said that UML, the MARTE profile and

a methodology specific profile ensure the possibility to cover SDF and synchronous MoC-based

models.

However, as mentioned, CONTREX aims a generic modelling methodology, which is the main

goal of task T2.2. As part of that activity, we tackle the challenge to look for a methodology

which minimizes the use of methodology specific profiles (ideally eliminating them), to

improve the generality and wide applicability of the model, while at the same time minding the

other objectives stated at the beginning of the section, which mind a practical approach.

Figure 7.11: A more generic approach looking for using more UML/MARTE elements and the

minimization of methodology specific stereotypes.

Although the definition of the modelling methodology is in progress, it is possible to advance

the idea. For instance, Figure 7.11 shows a different version of the ForSyDe-like components

library shown in Figure 7.10. There, instead of SDF specific stereotypes related to the ForSyDe

methodology, the MARTE <<ConcurrencyResource>> is used. This serves to state that each

actor of the SDF model is a concurrent activity, which therefore could potentially execute in

truly parallelism.

Notice that using a component library facilitates the reuse of the models based on the

component library, since it hides the way the semantics of the components is stated, e.g. by

using MARTE stereotypes or other methodology specific sterotypes).

The assessment ha to consider all the semantics requirements. From one side, the MARTE

<<ConcurrencyResource>> stereotype, can define additional aspects on the semantics, stated

by the attributes “isActive”, “isProtected” and “resMult”. However, we need to look from the

SDF perspective. Specifically, there are additional assumptions regarding how the SDF actor

must compute which are not captured by the <<ConcurrencyResource>> stereotype, i.e. that it

must be side-effect free and follow a specific scheme typical of dataflow models, where each

actor first reads all its inputs, then computes, and finally send all the output data.

Similar considerations have to be taken into account on other aspects relative to how to capture

the executive semantics, e.g. to define the semantics of the arc/edge (connector in the model)



Page 52

as a dataflow stream. Otherwise, and without any specific stereotype application, nothing

prevents to interpret the connector in a very different way, e.g. a triggering signal, a rendez-

vous, a wire, etc.

How such information shall be captured, and moreover, the possibility/convenience to capture

such information implicitly in the model by abiding patterns and reusing MARTE stereotypes,

or described as a separable part of the model which can be reused and transferred with the

models is being considered. The progress of the activity is reported in [17].



Page 53

8 References

[1] "Description of Work". CONTREX – Design of embedded mixed-criticality CONTRol

systems under consideration of EXtra-functional properties, FP7-ICT-2013- 10

(611146), 2013.

[2] [UC-1] Alan Burns and Rob Davis. Mixed Criticality Systems - A Review. http://www-

users.cs.york.ac.uk/~burns/review.pdf

[3] [UC-2]P. Graydon and I. Bate. Safety assurance driven problem formulation for mixed-

criticality scheduling. In Procceedings of WMC, RTSS, pages 19-24, 2013.

[4] [KTH-1] Herrera, F.; Niaki, S.H.A.; Sander, I., "Towards a Modelling and Design

Framework for Mixed-Criticality SoCs and Systems-of-Systems," Digital System

Design (DSD), 2013 Euromicro Conference on , vol., no., pp.989,996, 4-6 Sept. 2013

doi: 10.1109/DSD.2013.112

URL:http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6628385&isnumber=

6628240ccce

[5] [KTH-2] Herrera, Fernando; Sander, Ingo, "Combining analytical and simulation-based

design space exploration for time-critical systems," Specification & Design Languages

(FDL), 2013 Forum on , vol., no., pp.1,8, 24-26 Sept. 2013

URL:http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6646657&isnumber=

6646617jhkjhlkj

[6] E. A. Lee, Disciplined Heterogeneous Modeling, in D.C. Petriu, N. Rouquette, O.

Haugen (Eds.): MODELS 2010, PRT II, LNCS 6395, Springer-Verlag, pp. 273-287,

2010. Proceedings of the ACM/IEEE 13th International Conference on Model Driven

Engineering, Languages, and Systems (MODELS), Oct. 3-8 , 2010.

[7] Patricia Derler, Edward A. Lee, Alberto Sangiovanni-Vincentelli. Modeling Cyber-

Physical Systems, Proceedings of the IEEE (special issue on CPS), 100(1):13-28,

January 2012.

[8] P. Peñil, J. Medina (CTR), H. Posadas, E. Villar"Generating Heterogeneous Executable

Specifications in SystemC from UML/MARTE Models" in "Innovations in Systems and

Software Engineering", V.6, N.1-2, March, Springer. 2009-12.

[9] P. Peñil, E. Villar, H. Posadas, Julio Medina (CTR). "Executable SystemC specification

of the MARTE generic concurrent and communication resources under different Models

of Computation". Workshop on the Definition, evaluation, and exploitation of

modelling and computing standards for Real-Time Embedded Systems, STANDRTS'09

Satellite Workshop of the the 21st EuroMicro Conference on Real-Time Systems,

Dublin. 2009-06.

[10] P. Peñil, F. Herrera, E. Villar. "Formal Foundations for MARTE-SystemC

Interoperability". Forum on specification & Design Languages 2010, FDL'2010, IEEE.

2010-09.

[11] P. Peñil, F. Herrera, E. Villar. "Formal Support for Untimed MARTE-SystemC

Interoperability". T. Kazmierski & A. Morawiec (Eds.): "Systems Specification and

Design Languages", Lecture Notes in Electrical Engineering, V.106, Springer. 2012-06.

[12] P. Peñil, F. Herrera, E. Villar. "Formal Foundations for the Generation of Heterogeneous

Executable Specifications in SystemC from UML/MARTE Models". Kiyofumi Tanaka:

"Embedded Systems - Theory and Design Methodology", InTech, Croatia. 2012-02.

[13] P. Peñil, H. Posadas, A. Nicolás, E. Villar. "Automatic synthesis from UML/MARTE

models using channel semantics". International Workshop on Model-Based

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6628385&isnumber=6628240ccce

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6628385&isnumber=6628240ccce

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6646657&isnumber=6646617jhkjhlkj

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6646657&isnumber=6646617jhkjhlkj



Page 54

Arquitecting and Construction of Embedded Systems, ACES-MB 2012, doi:

10.1145/2432631.2432640. 2012-09.

[14] F. Herrera, H. Posadas, P. Peñil, E. Villar, F. Ferrero (GMV), R. Valencia (GMV), G.

Palermo. "The COMPLEX methodology for UML/MARTE modeling and design-space

exploration of embedded systems". Journal of Systems Architecture, V.60, N.1,

Elsevier, pp.55–78. 2014-01.

[15] H. Posadas, P. Peñil, A. Nicolás, E. Villar. "System synthesis from UML/MARTE

models: The PHARAON approach". Electronic System Level Synthesis Conference,

ESLsyn, 2013, IEEE. 2013-05.

[16] B. Combemale, C. Hardebolle, C. Jacket, F. Boulanger and B. Baudry. “Bridging the

Chasm between Executable Metamodeling and Models of Computation”. 5th

International Conference, SLE 2012 7745 (2012) 184-203.

[17] F. Herrera, H.Attarzadeh, Ingo Sander, and J. Medina. “Formal UML/MARTE

modelling relying on Models of Computation&Communication (MoCC): An

assessment considering ForSyDe and HetSC Methodologies”. V0.4. Internal document

of the CONTREX project. 2014. Found on the CONTREX redmine repository.

[18] E.A.Lee et al. “Synchronous data flow”. Proceedings of the IEEE, 75 (9), 1987.



Page 55

A. Annex: Abstract syntax and overall description of modelling elements taken from MARTE domain views

The elements that are relevant for the project modelling needs from the MARTE standard are

essentially all the meta-models placed in the domain views for each sub-profile in MARTE. In

this annex we provide just a guide to navigate through them as may be of interest for the reader.

The initial step to understand and follow the standard is its clause 2.4.1, there it is where the

modeling needs of the reader define the sections of the specification that are necessary to take

into account. To do this table 2.2 is used. In our case the Methodologist Compliance Case at

the Base level plus some additional units may be sufficient. For convenience, the units selection

table is shown here in Table A.1.

CASE Level GRM NFP VSL Time CHF SRM HRM GCM Alloc HLAM GQAM PAM SAM RSM

Software Base X X X X

Full X X X X

Hardware Base X X X X

Full X X X X X

System Base X X X X X

Full X X X X X X

Performance Base X X X X X

Full X X

Schedulability Base X X X X X

Full X X

Infrastructure Base X X X X

Full X X X X

Methodologist Base X X X X X X

Full X X X X X X X X

Table A.1: Matrix of sections or sub-profiles in MARTE of interest for different kinds of

readers.

The sections of MARTE of interest for understanding the semantics and the abstract syntax of

the elements that are relevant for this effort are essentially the subsections denominated as

domain views of the following clauses in the MARTE specification:

- Core Elements (Section 7)

- Non-functional Properties Modeling (Section 8)

- Time Modeling (Section 9)

- Generic Resource Modeling (Section 10)

- Allocation Modeling (Section 11)

- High-Level Application Modeling (Section 13)

- Generic Quantitative Analysis Modeling (Section 15)

Plus:



Page 56

- Normative MARTE Model Libraries (Annex D), and

- Domain Class Descriptions (Annex F)

The main diagrams in the domain view of those MARTE sub-profiles represent the abstract

syntax for the elements in MARTE that will be used in the CONTREX meta-model.

Instead of copying all the diagrams and textual descriptions, the interested reader is referred to

the actual specification, which can be downloaded from the OMG repository at

http://www.omg.org/spec/MARTE/1.1/PDF.

Here we include as a general reference a very brief summary of distinctive aspects of some of

the main sections of MARTE. The descriptions of specific modeling elements used in this

document may be retrieved from the Annex F of the UML profile for MARTE specification,

which have the semantics description of all elements in the domain views.

Time modeling

The MARTE subprofile describes concepts for modelling time and timing mechanisms (clocks,

timers). MARTE relies on models of time that are based on partial ordering of instants.

Applying the Clock Constraint Specification Language (CCSL) the timing structures can be

related in order to capture a behaviour with well-defined semantics.

Application modeling

In addition to the RtUnit concept, new MARTE concepts have to be considered for modeling

the application. Specifically, concepts about how the application are communicated between

them. These concepts are included in the MARTE subprofile Generic Component Model

(GCM) and specified the ports and interfaces defining the interfaces elements involved in the

communication process. The GCM package is a general model package that is not tied to any

particular execution semantics. It includes interaction ports, flow ports, and message ports.

GCM separates the definition of structural properties and the definition of behavioural

properties.

http://www.omg.org/spec/MARTE/1.1/PDF



Page 57

HW modeling

For modeling the internal structure of the nodes, the concept included in the MARTE subprofile

Detailed Resource Modeling (DRM) are used. Specifically, the concepts of HW_computing

package (processors), HW_storage package (memories), HW_Communication package (buses)

and HW_device package (I/O elements and sensors) will be mainly used.

Allocation

For enabling the different resource allocation scenarios, the concepts of the MARTE sub-profile

Allocation Modeling are used. It models the allocation of functional application elements onto

the available platform resources. The allocation could be time or space related. Application and

execution platform models are built separately, before their pairing through the allocation

process.



Page 58



Page 59

B. Annex: Results of the CONTREX meta-model survey.

This annex is a compendium of requirements, tables and references resulting from the responses

of the partners to the CONTREX meta-model survey. Also an exemplar of the survey is

provided for documentation purposes.

Preliminars

Surveys received from 8 partners.

Considering the explicit requirements taken from the DoW:

Intec

s

EDAla

b

OFFI

S

iXtronic

s

GM

V

POLIT

O

DOCE

A

U

C

Tota

l

Control 5

Networke

d

3

Embedded 7

Mixed-

critical

5

Platforms, network configuration/characterization parameters, extra-functional properties

PowerPC / Zynq

Intec

s

EDAla

b

OFFI

S

iXtronic

s

GM

V

POLIT

O

DOCE

A

U

C

Tota

l

CAN

Ethernet

N.Delay

N.Throughpu

t

N.Latency

Packet Loss

rate

N.BitErrorRa

te

Cost

Security

Dependability

Power

consumption

Fairness

No starvation

No deadlock

Stack

overflow

Scheduled

concurrency



Page 60

Auto Tx Pw

Control

Utilization

ResponseTim

e

Throughput

Relationship with other formalisms:

Standards –

Languages

/formalisms

Intec

s

EDAla

b

OFFI

S

iXtronic

s

GM

V

POLIT

O

DOCE

A

U

C

Tota

l

UML 5

MARTE

UTP

SySML

SystemC 3

ARINC 653

fUML/PSCS

EDALab

profile

SPESMM +

HRC

VDI 2206

CAMEL-

View

MathLab/

Simulink

LabView

AMS

SystemC/TL

M

IP-Xact

C / C++

VHDL

Verilog

Property

Specification

Language

PSL

Ravenscar

State chart



Page 61

The questionnaire used for the survey

1. In general:

1.1. Please indicate the name/acronym of the CONTREX partner on behalf of whom you

write this response.

UC

1.2. What kind of systems you design under the CONTREX scope of networked, embedded,

mixed-criticality, control systems. (select all appropriate)

Control Networked Embedded Mixed-critical

mixed-critical avionics/flight-control and telecom systems

1.3. Are there any relevant standards that fix the modeling vocabulary, tools, or practices

that you use or plan to use in the context of this project? (AADL, UML, MARTE,

SySML, ARINC 653, AUTOSAR, etc.)

UML/MARTE, UTP, SysML and SystemC. Some elements of ARINC 653 may be

needed in addition to those that are already in MARTE Annexes. For the execution

semantics in the models also the fUML and PSCS (precise semantics for Composite

Structures) OMG standards shall be used.

1.3.1. If so, can you give some references to the concrete version or specific material

you use as paradigm for its exploitation in this project?

UML2.4.1 , MARTE 1.1, UTP 1.1, SysML 1.3, SystemC 3.0, fUML 1.1, and PSCS 1.0

(to be issued in 2014)

1.4. Is there any specific research effort that you consider relevant as part of the state-of-

the-art, or state-of-the-practice in your domain at which we should definitely look at in

the elaboration of this meta-model? Please point them out by providing references

and/or links to them.

UML/MARTE modeling methodology F. Herrera, H. Posadas, P. Peñil, E. Villar, F. Ferrero (GMV), and R. Valencia (GMV): "A MDD Methodology for Specification of Embedded Systems and Automatic Generation of Fast Configurable and Executable Performance Models", ESWeek 2012 Compilation Proceedings, CoDes+ISSS’12, ACM, 2012. http://dl.acm.org/citation.cfm?id=2380527 (find file “01-UML-MARTE modeling methodology.pdf” in the UC literature section) Models of Computation in UML/MARTE P. Peñil, F. Herrera, and E. Villar: "Formal Foundations for the Generation of Heterogeneous Executable Specifications in SystemC from UML/MARTE Models", Kiyofumi Tanaka: "Embedded Systems - Theory and Design Methodology", InTech, Croatia, 2012. (find file “02-Models of Computation in UML-MARTE.pdf” in the UC literature section) UML/MARTE-SystemC interoperability P. Peñil, F. Herrera, and E. Villar: "Formal Support for Untimed MARTE-SystemC Interoperability", T. Kazmierski & A. Morawiec (Eds.): "Systems Specification and Design Languages", Lecture Notes in Electrical Engineering, V.106, Springer, 2012. http://link.springer.com/chapter/10.1007/978-1-4614-1427-8_15 (find 03-UML-MARTE-SystemC interoperability.pdf in the UC literature section) Wireless Networked Embedded Systems simulation E. Emad, F. Fummi, D. Quaglia, H. Posadas, and E. Villar: “A Framework for Design Space Exploration and Performance Analysis of Networked Embedded Systems”, proc. of the 6th Workshop on: Rapid Simulation and Performance Evaluation: Methods and Tools, 2014. (pdf to appear... about now it is in press, once it is available it will be uploaded in the UC literature section as “04-Wireless Networked Embedded Systems simulation.pdf”)

http://dl.acm.org/citation.cfm?id=2380527

http://link.springer.com/chapter/10.1007/978-1-4614-1427-8_15



Page 62

2. About your design & development flow

2.1. What are the kind/kinds of design & development process that you follow?

Waterfall V model Y model

Spiral model Iterative & incremental Agile Extreme

Programming

Unified Process Microsoft Solutions Framework

HW/SW co-design based on the performance analysis of the UML/MARTE PSM. The

design space exploration is made using some form of iterative process when needed, in

particular for the assessment of extra-functional properties.

2.2. Please identify concrete stages and models in the development process whose artifacts

need specific elements in our meta-model to be expressed, if any.

1. Data model for I/O and interfaces

2. Application modeling (PIM: components, interfaces, component architecture and

C/C++)

3. Platform modeling (PDM: HW, OS and memory spaces)

4. Use case modeling (functional and extra-functional requirements)

5. Architecture modeling (PSM: PIM allocated to PDM)

6. Functional verification by simulation and testing

7. Performance analysis end optimization

2.3. Do these stages, models, or artifacts need (or use now) in your development chain any

specific formalism to be represented, stored, or refined?

Yes

UML/MARTE (HLAM, GCM, Allocation and DRM) and UTP. For the timing

verification SAM models will be used if needed.

2.4. How and when in this process do you express: system properties, extra-functional

properties, requirements, and the respective figures of merit for them?

They are used as requirements in initial model. Domain requirements are defined in the

Use Cases and they are assessed during functional verification. System properties

(functional and extra-functional) are expressed by written text in initial models; later

they use concrete VSL annotations on NFP values and constraints (following the

MARTE modelling approach).

3. About the relevant formalisms in your development chain

3.1. Please indicate programming or design languages you use, as well as validation

techniques and/or tools to which you need to provide input data/models, or from which

you need to retrieve results back in your development chain.

Programming languages: C, C++



Page 63

Verification tool: Compositional native simulation and performance analysis from the

PSM. For timing verification by schedulability analysis MAST can be used.

3.2. What kind of applications do you target?

Please make a short description and then mark all appropriate:

Mixed-critical flight control system running on a multi-core SoC. Several possible

kinds of applications will be considered; some use OS threading, others are directly

programmed in modules and hardware devices.

Object oriented

Aspect oriented

Component-based

Only functions organized in a

top-down decomposition

Concurrent with common

memory

Concurrent with separate

memory

There is not an OS.

There are OSs and they provide

scheduling and arbitration of

mutual exclusive resources

3.3. Do they have extra-functional constraints? Are they hard or soft constraints?

Real-time and energy (peak, average, total) constraints estimated by simulation

3.4. Do you have in mind or work with any particular model of computation when you face

the design in your application domain? Can you specify it?

MoCs can be identified at the UML/MARTE model but we do not restrict the designer

to any in particular

The UML/MARTE model supports different MoCs

3.5. If you use control theory at some point in time in the development process, how do the

specifications of the controller are transposed into requirements and constraints in the

system? Is there any language, model of computation, or ad-hoc transformation that

allows you to have confidence in the correctness of the final implementation compared

to those specifications?

No, we do not use it. We do target control applications, but we assume the control

algorithms and timing are already part of the software algorithms and timing constraints

in the high level models of the applications to deploy.

4. About the platforms to which you target the applications.

4.1. Which kind of processing platforms do you use?

Xilinx Zynq 7020 (under different internal configurations) + Linux

TI OMAP+ Linux

Samsung Exynos + Linux

4.2. Please specify the processors, or alternative technology to implement your

functionality, special purpose devices, operating system, etc.? Could you please

indicate the interconnection mechanism in place (Bus, NoC….) as well as the memory



Page 64

structure (hierarchies, all local, all global, any combination…)? Do they provide some

service guarantees in terms of timing, power or temperature?

ARM Cortex Ax

MicroBlaze

Linux Xenomai

4.3. Do you implement several applications on a single platform? (Please indicate the level

of abstraction for their specification and the kind and technology used for the

concurrency among them)

Yes

UML/MARTE: HLRM using threads for RTUnits and processes to implement different

applications

4.4. If so, are they validated independently one from another or they are treated as a whole

for the system’s validation?

They are validated as a whole by simulation

4.5. Which network technologies do you use?

CAN Ethernet Flex-ray AFDX

Ethernet among boards and the internal on-chip bus

4.6. Please specify the magnitudes, protocols, and tuning parameters that you use/consider

to evaluate and manage the quality of service and/or to assure predictability in the

exploitation of the network.

The network is characterized by its bandwidth

5. About mixed criticality

5.1. How do you conceive/understand mixed criticality in your application domain?

We design high critical systems by using periodic tasks subject to the ravenscar profile

limitations on the code architecture. The approach to mixed critical systems is made by

resource reservations offered in the way of virtual processing resources, managed by

contracts.

5.2. Which standards do you use?

Ada with the Ravenscar profile for critical applications and ARINC 653 (IMA) for strict

resource sharing in mixed critical systems.

5.3. Is this treated as a feature that you use (or expect to have available) among those

embedded in the platform that manages the available resources at run time, or it is

basically a constraint/characteristic of the whole system’s architecture and behavior at

design time?

We require the platform to offer mechanisms to manage the processing capacity that is

granted to each application according to its criticality.



Page 65

5.4. Regarding mixed critical systems, and the results you expect out of CONTREX, can

you identify specific terms, transformations, or models that will help you to adopt those

final assets in your domain? Could you briefly summarize as well the results you

expect in CONTREX?

For run-time services we expect to identify the modeling elements necessary to express

the contracts and the necessary characterization of the platforms suitable for mixed

critical applications.

At design-time, we want to be able to do design space exploration by analyzing the

performance of the complete mixed critical system and find the optimal pareto points.

6. Please tell us how you want to use the CONTREX meta-model and state any additional

requirement that you consider relevant to it.

We plan to use it to generate execution artifacts as well as simulation models from design

intent models. We require from this meta-model the capacities needed to deploy them on

distributed platforms as well as making the design space exploration including the

criticality as an additional constraint to consider during the optimization process.



Page 66

C. Annex: Brief assessment of modelling elements in the industrial computing standards for safety.

Safety Standards Assessment

V0.5

Internal document of the CONTREX Project, Task 2.1

Contributors: Fernando Herrera (KTH), John Favaro (INTECS) and Carmen Lomba

(GMV)

Date: May 13th, 2014

Version Table:

version Contributors date Description

0.1 FeHe January 14th, 2014 1st version

0.2 JoFa, FeHe March11th, 2014 Adding remarks from John Favaro (INTECS), conclusions, and index

0.3 JoFa March 17, 2014 Revision taking into account discussions

0.4 FeHe March 28th, 2014 Minor polishing (spell checking, grammar)

0.5 CaLo, FeHe May 13th, 2014 Integration of GMV contributions (CaLo) and minor revision (FeHe)

Contributor’s Code:

Institution Person Person Code

KTH Fernando Herrera FeHe

INTECS John Favaro JoFa

GMV Carmen Lomba CaLo

https://contrex.offis.de/home/



Page 67

Content 1 Introduction .............................................................................................................. 68

2 Access to standards and complementary documentation ......................................... 68

2.1 Regarding the sources of this assessment ......................................................... 68

3 Assessment of standards for Mixed-Criticality ........................................................ 69

3.1 IEC 61508/61511 .............................................................................................. 69

3.2 Safety related Aviation Standards .................................................................... 72

3.2.1 Introduction ............................................................................................... 72

3.2.2 DO-178C ................................................................................................... 74

3.2.3 Integrated Modular Avionics: RTCA DO-297 - EUROCAE ED-124 ...... 75

3.3 ................................................................................................................................ 75

3.4 ISO 26262 ......................................................................................................... 75

4 Considerations for the construction of the CONTREX meta-model and analysis&design

methodologies ................................................................................................................. 79

5 References ................................................................................................................ 81



Page 68

1 Introduction

The following study focus on the aspect of standards that can be relevant for the definition of a

meta-model suitable for the modelling of mixed criticality systems.

2 Access to standards and complementary documentation

The following table summarizes the access cost of a number of relevant standards:

Standard Purpose Access

IEC 61508/61511 Standards from the International Electrotechnical Commission for Functional Safety

331€ in webstore of http://www.iec.ch/functionalsafety/

DO-178B(RTCA/FAA) ED-12B (EUROCAE/EASA)

Software Considerations in Airborne Systems and Equipment certification

160.5$ (non-member price of electronic version)

128.4$ (non-member price paper) in wev store of http://www.rtca.org

DO-254 Design Assurance Guidance for Airborne Electronic Hardware

195.5$ (non-member price of electronic version)

in web store of http://www.rtca.org

ISO 26262 Road vehicles -- Functional safety (Parts 1 to 10)

1000-1500€ (approximated price from the prices of each of the 10 parts, after converting price in CHF) In http://www.iso.org

As seen, all of them are non-free. However, there are some documents freely available that can

provide information in a more or less indirect manner for the purposes of defining a meta-model

for mixed criticality.

2.1 Regarding the sources of this assessment

This document compiles and structures information sourced from different references in order

to assess how the different standards approach the topic of safety and criticality. The intent is

to provide a basis for supporting the meta-model proposal done in the WP2 of CONTREX

project. Specifically, the following sources have been used for the document: [1][2] for IEC

61508/61511;[3] for DO-178B/ED12B;[4] for DO-278B/ED109;and [5][6] for ISO 26262.

Moreover, this document has been revised from partners with access to the actual standards

(INTECs and GMV).

http://www.iec.ch/functionalsafety/

http://www.rtca.org/

http://www.rtca.org/



Page 69

3 Assessment of standards for Mixed-Criticality

3.1 IEC 61508/61511

These standards come from the automated control domain, and oriented to systems comprised

of both electrical and/or electronic elements. The IEC61508 standard,entitled “Functional

Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems (E/E/PE, or

E/E/PES)”, is extremely relevant to CONTREX since it directly refers to electronic systems

and to control systems. Moreover, IEC 61508 has inspired many other standards applied to

domains such as automotive (see ISO26262), nuclear, medical, transport, etc.

The IEC61508 standard introduces Functional Safety, a concept “applicable across all

industry sectors”[1], and which is defined as “part of the overall safety relating to the EUC

(Equipment Under Control) and the EUC control system which depends on the correct

functioning of the E/E/PE safety-related systems, other technology safety-related systems and

external risk reduction facilities”[2].

That is, the standard assumes a specific reference architecture, sketched in Figure 12.

Figure 12. IEC 61508“reference architecture”.

That “reference architecture” assumes specific system architecture, composed of the EUC and

EUC control system (following the classical control theory scheme). In addition, there is a

traversal perspective, which distinguishes a “non-safety” part from a “safety” part composed of

functionalities devoted to risk reduction. Those functionalities are called safety functions.

The IEC 61508 standard grants that safety functions can rely on E/E/PE safety-related systems,

and also on other technologies. Moreover, a third possibility is also contemplated where

external risk reduction facilities are added (external in the sense they do belong neither to the

EUC nor to the EUC control system).

Risk is a major concept in the IEC 61508 standard. Risk is a function of the likelihood

(frequency) of occurrence of the hazardous event and of the consequence severity.

Risk = f(freq. Hazardous event, consequence severity)

Figure 13shows an structured sketch (based on the information given in [2]) of one qualitative

analysis proposed by the standard to assess the risk, which considers 6 categories of likelihoods

EUC

EUC

Control System

overal safety

E/E/EP

safety-

related

systems

Other

Tech.

Safety-

related

system

s

External

risk

reductio

nfacilitie

s

Functional Safety

Scope of IEC 61508 normative and

recommendations



Page 70

and 4 categories of consequences. As it is shown, the range of the risk function consists in 4

classes of risks.

Figure 13.A risk assessment function proposed by IEC 61508.

This standard also defines the safety integrity level (SIL), which is literally defined as “the

probability (likelihood) of a safety-related system performing the required safety function under

all the stated conditions within a stated period of time”.

Informally, it can be understood as the confidence that the safety function will perform at the

given moment in time.

The SIL is categorized through the probability of failure, which is the inverse of SIL, instead.

The reason is that it is easier to “identify and quantify possible conditions and causes leading

to failure of a safety function than it is to guarantee the desired action when called upon”.

SIL = 1/pf

category Range (failurers/year)

Frequent 10-3

Probable [10-3 , 10-4)

Occasional [10-4 , 10-5)

Remote [10-5 , 10-6)

Improbable [10-6 , 10-7)

Incredible < 10-3

category Definition

Catastrophic MultipleLost of life

Critical Loss of a single life

Marginal Major injuries to oneor more persons

Negligible Minor injuries at most

Risk Class Range (failurers/year)

I Unaceptable

II Undesirable

III Tolerable

IV Acceptable

Consequence

Likelihood catastrophic Critical Marginal Negligible

Frequent I I I II

Probable I I II III

Occasional I II III III

Remote II III III IV

Improbable III III IV IV

Incredible IV IV IV IV

Likelihood Consequence

RiskFunction

Risk



Page 71

In addition, [1] also states that the specification of the safety function includes both the actions

to be taken in response to the existence of particular conditions and also the time for that

response to take place. In other words, a safety function requires the definition of a functionality

plus some related response time bounds:

Safety function = (functionality, response time bounds)

Therefore, the definition of SIL refers to the probability:

1. to perform the right functionality (function integrity),

2. respecting the response time bounds,

3. during a given period of time

This scheme corresponds to a discrete (or, in other words, reactive) safety function. That is, the

safety function is triggered a discrete number of times and has to react within specific time

bounds. The SIL then measures or characterizes the probability that the function works as

expected, that is, corresponds to an expected functional behaviour and with some response time

bounds, within a given period of time. This is called “on-demand” mode (sketched in Figure

14) and the standard defines specific SIL figures for it.

Figure 14.Sketch of the mode of operation “on-demand”.

More specifically, the standard distinguishes three modes operation, which are defined in the

standard as shown in the excerpt of

Figure 15.Excerpt of the standard IEC 61508 where the mode of operation of the safety function is

defined.

As can be seen, the former two modes refer both to an “on-demand” model and are different

only in quantitative terms (which regard to how often the safety function is called). A third class

of mode operation (or a second category if desired)refers to a “continuous mode”. In this mode

t

Calls of safety

function

Boundsonthe response time

Period of time



Page 72

it is assumed that the safety function is “in place continuously, in order to keep the EUC in safe

state2.

The Safety Integrity Level (SIL) is then defined as a function of the probability of failure and

of the mode of operation, as shown inTable1.

Table1 Safety integritylevel (SIL) isdefinedontheprobability of failure and ontheoperationmode.

SIL On-demand (average pf) Continuous (pf / h)

4 [10-5,10-4] [10-9,10-8]

3 [10-4,10-3] [10-8,10-7]

2 [10-3,10-2] [10-7,10-8]

1 [10-2,10-1] [10-6,10-5]

Considering the mode of operation for defining the SIL makes sense if it is considered that a

safety function operation in continuous mode has to execute more often during the same period

of time. Therefore, the failure rate for it need to be lower for the same SIL.

The SIL provides a criterion for a relative classification of the safety requirements of a system

or subsystem and thus it is relevant for its consideration in a meta-model suitable for mixed-

criticality system models.

Moreover, SIL definition provides also a link closer to an absolute reference, since each SIL

level is related to specific bounds on failure rates and operation times.

These standards define and handle the Safety Life Cycle (SLC), which directs the user to

consider all the phases of the life cycle (design or analysis, implementation, installation and

operation) related to the safety function of a system. IEC 61508/61511 standards also deal with

different aspects of processes, and of the software and hardware elements used and developed.

3.2 Safety related Aviation Standards

3.2.1 Introduction

The European Aviation Safety Agency (EASA) is a European Union (EU) agency with regulatory and executive tasks in the field of civilian aviation safety. On 28 September 2003, the EASA took over responsibility for the airworthiness and environmental certification of all aeronautical products, parts, and appliances designed, manufactured, maintained or used by persons under the regulatory oversight of EU Member States.

The Certification work also includes all post-certification activities, such as the approval of changes to, and repairs of, aeronautical products and their components, as well as the issuing of airworthiness directives to correct any potentially unsafe situation. All type-certificates are therefore now issued by the EASA and are valid throughout the European Union.

EASA uses industry Standards adapted with its own certification standards as well as advisory

material to provide guidance with the applicable regulations.

The list of Industry Standards related to safety are:

Safety: “Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment” SAE ARP 4761 -- EUROCAE ED-135

2However, we have no more specific data to state in a quantitative manner how many times per year it means, or if even it means a “permanent operation”. In any case, it is sufficient to later understand that different modes of operation lead to different exigency in the probability of error. Actually, the differences between those probabilities can indicate the current understanding of the standard about “continuous mode”. For instance, since there seems to be a difference of 104, it might mean that the standard assumes that a continuous model could be equivalent to a triggering of a discrete safety function of 104 or more times a year.

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

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

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

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



Page 73

System: “Guidelines For Development Of Civil Aircraft and Systems”SAE ARP 4754A - EUROCAE ED-79A

“Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations “ RTCA DO-297 - EUROCAE ED-124

Software: ”Software Considerations in Airborne Systems and Equipment Certification” RTCA DO-178C - EUROCAE ED-12C

Hardware : “Design Assurance Guidance For Airborne Electronic Hardware” RTCA DO-254 -- EUROCAE ED-80

Environmental: ”Environmental Conditions and Test Procedures for Airborne Equipment ” RTCA DO-160-G - EUROCAE ED-14-G

Aircraft Systems and items are assigned a “development assurance level” (DAL) based on failure condition classifications associated with the most severe aircraft-level functions implemented in the systems and items. The Item DAL is allocated on the basis of the overall system architecture through allocation of risk determined using the PSSA (Preliminary System Safety Assessment per SAE ARP-4761).

The following are the defined Development Assurance Level (DAL) levels and associated failure conditions:

DAL

Failure Condition

A Catastrophic: Failure Condition which would prevent the continued safe flight and landing of the aeroplane.

B Hazardous: Failure Condition which would reduce the capability of the aeroplane or the ability of the crew to cope with adverse operating, conditions to the extent that there would be (i) a large reduction in safety margins or functional capabilities; (ii) physical distress or higher workload such that the flight crew cannot be relied upon to perform their tasks accurately or completely, or (iii) serious or fatal injury to a relatively small number of the occupants.

C Major: Failure Condition which would reduce the capability of the aeroplane or the ability of the crew to cope with adverse operating conditions to the extent that there would be, for example, a significant reduction in safety margins or functional capabilities, a significant increase in crew workload or in conditions impairing crew efficiency, or discomfort to occupants, possibly including injuries.

D Minor: Failure Condition which would not significantly reduce aeroplane safety, and which involves crew actions that are well within their capabilities

E No safety consequences

In case that the system has multiple categories of failure conditions associated with its different functions, architectural means (redundancy, monitoring or partitioning) may be used to limit the interaction between items. When partitioning is used to handle multi criticality application over platforms, further activities have to be addressed to sustain demonstration that partitioning is correctly handled. The DAL determines the necessary software and hardware design levels (A to E) of DO-178 and DO-254.



Page 74

Software level: DO-178C standard details the activities to be performed per each SW level.

Software is a key component that contributes to system behaviour and performance and DO-

178B specifies five levels of SW criticality, Level A through Level E. The software level

establishes the rigor necessary to demonstrate compliance with DO-178C Hardware level: DO-254 applies per allocated DAL in case that deterministic techniques cannot be used or are insufficient to demonstrate the safety of hardware design (complex hardware).

In the context of CONTREX project only DO-178C and RTCA DO-297 are taken into consideration.

It has to be remarked, that the certification process is out of the scope of the CONTREX project, which aims to provide suitable and better model-driven and system-level modelling and analysis techniques of Mixed-Criticality systems and systems-of-systems.

3.2.2 DO-178C

The DO-178 standard, published by the Radio Technical Commission for Aeronautics (RTCA)

defines guidelines for the development of aviation computer systems. DO-178B was adopted

by the Federal Aviation Administration (FAA) authority of USA. Europe has created its own

version, officially called it ED-12B, through the European Organization for Civil Aviation

Equipment (EUROCAE), and adopted by the European Agency for Aeronautic security

(EASA).

RTCA DO-178C addresses software life cycle processes, including acquisition, supply, development, operation, and maintenance.

DO-178C annex A, describes the objectives to be satisfied that are determined by the software level A-E.

DO-178 requires a documented connection (called a trace) between the certification artifacts. For example, a Low Level Requirement (LLR) traces up to a High Level Requirement (HLR). A traceability analysis is then used to ensure that each requirement is fulfilled by the source code, that each requirement is tested, that each line of source code has a purpose (is connected to a requirement), and so forth. Traceability ensures the system is complete. The rigor and detail of the certification artifacts is related to the software level.

The DO-178C introduces several supplements:

DO-330: Software Tool Qualification Supplement

DO-331: Model- Based and Verification Supplement

DO-332: Object Oriented Supplement

DO-333: Format Methods Supplement

It is to be taken into account that the CONTREX metamodel should take into consideration

DO-178C guidelines (see D1.1.1) . DO-178C, DO-331 Model- Based and Verification

Supplement must be taken into consideration.

DO-331 contains the modifications and additions to DO -178C objectives, activities and

software life cycle that should be addressed when model-based development and verification

are used as part of the software life cycle. This includes the artefacts that would be expressed

using the models and the verification evidences that could be derived from them.

Models may represent software requirements and/or architecture partially or completely.

Models are characterized by the modelling technique that is used and by the type of life cycle

data they will represent. A modelling technique is a combination of a modelling language and

a particular manner of using the modelling language. The supplement introduces two types of

models: Specification models and Design models



Page 75

A Specification Model represents high-level requirements that provide an abstract

representation of functional, performance, interface or safety characteristics of the software

components.

A Design Model describes software component internal data structures, data flow and/or control

flow. A design model includes low level requirements and/or architecture. This model may be

used to produce code.

A high level requirement refers to any of the following:

Any requirement contained within the specification model

Any requirement form which a design model is developed

Low level requirement refers to any requirement contained within the design model.

3.2.3 Integrated Modular Avionics: RTCA DO-297 - EUROCAE ED-124

RTCA DO-297 contains guidance for Integrated Modular Avionics (IMA) developers,

application developers, integrators, certification applicants and those involved in the approval

and continued airworthiness of IMA systems in civil certification projects. ED-12/DO-297

describes an IMA system and its design elements, the IMA system architecture and the

associated considerations.

IMA (Integrated Modular Avionics) simplifies the development and integration of software

components for environments with strict safety requirements. IMA decouples software from

hardware. An IMA platform shall provide robust partioning and other protection means that

allow multiple applications to share a platform and its resources. Robust partitioning separates

applications, such that even programs with strict hard real-time constraints and different

criticality levels can co-exist on the same processing hardware without interfering with each

other.

3.3 ISO 26262

ISO26262:2011 is an international standard in the automotive domain, inspired on IEC 61508

standard.

ISO26262:2011 defines the Automotive Safety Integrity Level (ASIL) in a clear relation with

SIL. Four levels from A to D, being D the more demanding, are defined.

Up to SIL2, SIL and ASIL are comparable. A (non-full) correspondence between SIL0 of IEC

61508 to the “Quality Management” (QM) of ISO 26262 can be done.

ASIL C is positioned“ somewhere between SIL2 and SIL3”.”" This is because the ISO 26262

standard defined ASIL C to reflect the set of practices carried out “de facto” in the automotive

industry, whose systems needed the development practices corresponding roughly to those of

IEC 61508 SIL 2, but the stronger validation practices of SIL 3.

Particularly interesting is that ASIL D only corresponds to SIL 3, and that there is no

counterpart to SIL 4 in the automotive standard. Recalling that IEC 61508 comes from the

industrial process control domain, where an accident can really cause thousands of deaths, e.g.

“Chernobyl”, there is simply no corresponding type of accident in the automotive industry. An

auto accident usually involves a relatively small number of people. However, it is likely a higher

ASIL level is required in the close future, since an extension of ISO 26262 covering buses in

under discussion, where dozens of persons can be involved in an accident.



Page 76

This discussion enables the extraction of two main facts to be considered in the proposition of

the CONTREX meta-model:

There is no exact correspondence between SIL and ASIL levels.

The equivalence may involve the different types of the activities, e.g. verification or

development.

Another interesting aspect is that ASIL conjugates three main aspects of the hazardous event:

- Exposure: Frequency of the situation

- Severity: Impact of the Damage

- Controllability

Therefore, with regard to IEC 61508, if we assume that exposure and severityin ISO 26262

directly relates to likelihood and consequence in IEC 61508, an interesting novelty is the

consideration of the controllability.

Criteria for coexistence of elements

Criteria for co-existence of elements is an important aspect in the ISO26262 standard, because

it directly refers to mixed-criticality and so is relevant for this aspect of the CONTREX meta-

model. Moreover, this aspect appears in one or another shape in most of the other standards.

A first observation is that in ISO-26262 standard terminology refers to “co-existence” of

elements (mixed-criticality) where each element can have (or not) a certain ASIL (criticality).

For instance, Figure 16 shows an excerpt of ISO26262 where criteria for co-existence of

elements is stated. These criteria enable to consider both technical and economical objectives.

Both of them are important when concerning safety, since, the more expensive (and so less

affordable) the implementation of the safe system, the more limited the ubiquity of safety

systems.

A first criterion for co-existence of sub-elements is a conservative one. It consists in raising the

ASIL of all sub-elements to the highest one, and to assign such highest ASIL to the sub-

elements that did not have one. This is done by default or whenever there is not possibility to

show the “freedom from interference” between sub-elements. This also means that the system

will be more expensive since, in order to ensure the ASIL of the critical parts, all the parts of

the system have to be designed and developed according to the highest ASIL.



Page 77

Figure 16.Excerpt of the standard

A second criterion enables the coexistence of sub-elements, where these sub-elements either

preserve their ASIL or at least a lower ASIL than the highest one. This is interesting since it

enables cheaper and more efficient implementations of the system.

Specifically, the standard talks about “guidance for determining the ASIL of sub-elements”.

That is, an analysis may be possible which leads to determine for each sub-element the lowest

ASIL it can have. This analysis is based on an “analysis of interference” along sub-elements.

As Figure 16 shows, “interference” is defined as the presence of “cascading failures” from

elements with lower or no ASIL to sub-elements with higher ASIL, leading to the violation of

a safety requirement.

So far, the following observations can be made:

1. This second criterion for co-existence of elements with different ASILs effectively

states a necessary condition to support mixed criticality;

2. The criterion is based on the “freedom from interference”;

3. The “freedom for interference” can be determined by a “dependent failure analysis”;

4. The definition of interference is unidirectional, that is, it cares about the effect of the

lower (or no) ASIL element on the higher ASIL element. In other words, there is not

full bilateralism in the “interference” definition, so concerning the effects of allowing

mixed-criticality system under standard criterion, it is fine if a higher ASIL sub-

element interferes with a lower ASIL element. A different question is if this is

convenient or simply tolerable for a given application.

5. The definition of interference is abstract in the sense it refers to the cause-effect

relation of failures. It neither explicitly refers to specific analysis techniques, nor to

specific application/hardware architectures, nor to specific techniques for “freedom

of interference”. Moreover, the definition of interference demands effective



Page 78

impact, in the sense that it requires that the effects caused on the high ASIL elements

by the lower ASIL elements cause a violation of the safety requirement3.

3 These observations are later on the basis for conclusión on the design techniques for mixed-criticalities.



Page 79

4 Considerations for the construction of the CONTREX

meta-model and analysis&design methodologies

From the previous assessment, it can be concluded that:

At least a relative scale reflecting the criticality of each actor or component of the

system is required

It might be required to reflect if such actors belong to the control system or to the

system under control

In order guarantee a wise applicability of the CONTREX meta-model, some links

between the criticalities and the related concepts to the different standards is

convenient.

In the case of IEC 61508, the criticality could be related to the Risk, or to the SIL:

Criticality ≡ Risk or Criticality ≡ SIL (in IEC 61508)

Criticality ≡ ASIL (in IEC 26262)

Etc.

In the case of DO-178, SW criticality shall be classified as DAL (A to E).

Up to five levels of criticality may be taken into account.

Moreover, the aforementioned links need to be flexible. Not only it is required to

enable some mapping of the criticality levels to the different levels defined in the

different standards, but it is also convenient to enable that such mapping can be aware

of the design activity:

o E.g., the SIL-ASIL mapping might depend on the consideration of either of a

development process or a verification process.

A Mixed-criticality system design has to pay attention to both technical and

economical objectives:

o Technical: constructing the mixed criticality system in such a way that it all

works correctly and every sub-system criticality is respected.

o Economic: being allowed by a given governing safety standard to assign

mixed criticalities to the components and develop each in the most economical

fashion possible according to its criticality, rather than having to develop all of

them in the most expensive way just because a few of them are high criticality.

In connection with the economic objective, the safety standards do have rules about

when mixed-criticality systems are allowed. These rules invariably concern the safe

isolation of the different parts of the system from each other. Essentially, they require

the demonstration that the different parts do not interfere with each other.

Such demonstrations have associated interference analysis or, in other terms,

dependent failure analysis. This is a first class type of analysis related to mixed

criticality systems, to be considered as well as other traditional design activities.

Therefore, support for these types of analysis is of interest in the meta-model and in

the Mixed-Criticality (MC) design methodologies.

The conditions for allowing mixed-criticality essentially relies on “freedom from

interference”. In turn, “interference” refers in an abstract way to chaining of failures



Page 80

provoking an effective safety violation on the higher criticality element. This means

that:

o Different techniques, from those based on isolation of platform resources, e.g.

virtualization, to those based on design-time techniques, can be applicable as

long as “freedom from interference” is demonstrated.

o Such “freedom from interference” requires showing that no safety constraints

are violated on the higher criticality elements by failures in the lower ones. In

other words, this does not obligate a null impact in the higher criticality

element. An impact either on its functionality or its performance would be

possible as long as it is not affected to a point leading to the violation of a

safety requirement associated to its criticality.

o The previous point is important because it opens the design of standard mixed-

criticality systems to more efficient design techniques, architectures, and

failure dependency analysis techniques which go beyond the techniques based

on the strict separation of resources. Regardless their scalability and

composability (merit figures which can serve to rank each approach),

techniques enabling more efficient and less expensive safety systems are

enabled. Furthermore, the portfolio of solutions and choices available to the

system-level designer.



Page 81

5 References

[1] “Manual on Safety Integrity Level (SIL) IEC 61508/61511” PEPEERL’FUCHS. (German

company which produces industrial sensors and products for process automation)

[2] http://en.wikipedia.org/wiki/IEC_61508

[3] T. K. Ferrell, U.D. Ferrell. “RTCA DO-178B/EUROCAE ED-12B” in “The avionics

Handbook”. CRC Press LLC. 2011.

[4] E. Kesseler. “Standards” in RTO-TR-IST-027. Available in

http://ftp.rta.nato.int/public/PubFullText/RTO/TR/RTO-TR-IST-027/TR-IST-027-05.pdf.

[5] C. Madritsch. “ISO 26262 Introduction”. Presentation Available in http://ext02.fh-

kaernten.at/rts/intern/downloads/Automotive%20Systems/ISO26262%20Introduction.pdf .

[6] Shrikant. LDRA. “ISO 26262 the Emerging Automotive Safety Standard” (Presentation).

Available in

http://www.siliconindia.com/events/siliconindia_events/Softec_Conf_Pune/Shrikant.pdf

http://ftp.rta.nato.int/public/PubFullText/RTO/TR/RTO-TR-IST-027/TR-IST-027-05.pdf

http://ext02.fh-kaernten.at/rts/intern/downloads/Automotive%20Systems/ISO26262%20Introduction.pdf

http://ext02.fh-kaernten.at/rts/intern/downloads/Automotive%20Systems/ISO26262%20Introduction.pdf

http://www.siliconindia.com/events/siliconindia_events/Softec_Conf_Pune/Shrikant.pdf

Documents

Design of embedded mixed-criticality CONTRol systems under ... · CONTREX/UC/R/2.1.1 Public CONTREX System meta-model Page 2 History of Changes ED. REV. DATE PAGES REASON FOR CHANGES