Design of embedded mixed-criticality CONTRol systems under consideration of EXtra-functional properties. CONTREX System meta-model

Transcription

1 FP7-ICT (611146) CONTREX Design of embedded mixed-criticality CONTRol systems under consideration of EXtra-functional properties Project Duration 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 Submission Date Due Date Project co-funded by the European Commission within the Seventh Framework Programme ( ) 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 1

2 History of Changes ED. REV. DATE PAGES REASON FOR CHANGES JM FeHe X JM Initial draft version for discussion of the structure. It includes initial contributions from UC, KTH and EDALabs 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 Insertion of content in Annex A and references to the concrete sections of the MARTE Standard JM Contributions from EDA-Lab to Chapter 5 JM JM Insertion of Contract Based Design section, survey and revision of safety standards annexes Addition of assessment of modelling capabilities for MoC (provided by KTH) JM Snapshot for partial reviewing JM Snapshot for partial reviewing to send to EC authorities KG Prepared snapshot for 1 st review meeting Page 2

3 Contents 1 Introduction Strategy for the construction of the CONTREX Meta-model Analysis of the Requirements for the CONTREX meta-model Results of the survey State-of-the-Art Analysis of needs The MARTE meta-model Extensions for Mixed-criticality Annotations Scheduling Contract based design Extensions for Networking Topology and platform overheads due to communication Extensions for modeling general purpose networking workloads Allocation and models for network analysis Extensions for the management of modeling configurations Stages in the development process: Refinement and abstraction Perspectives viewpoints and views Management of V&V for specific NFPs of interest Link to other formalisms System-Level modeling Specification and Modelling Methodologies References A. Annex: Abstract syntax and overall description of modelling elements taken from MARTE domain views B. Annex: Results of the CONTREX meta-model survey C. Annex: Brief assessment of modelling elements in the industrial computing standards for safety Introduction Access to standards and complementary documentation Regarding the sources of this assessment Assessment of standards for Mixed-Criticality IEC 61508/ Safety related Aviation Standards ISO Considerations for the construction of the CONTREX meta-model and analysis&design methodologies References Page 3

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 systemon-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 4

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 5

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 metamodel, 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. MARTE standard UML Representation MARTE Profile (normative) NFP subprofile NFP subprofile GQAM subprofile Domain View MARTE meta-model (non-normative) NFP domai Time domai GQAM domain 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 metamodel by: Page 6

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. UML Representation MARTE Profile (normative) MARTE standard Subprofile Subprofile Subprofile CONTREX profile (2) MC sub-profile network sub-profile Domain View MARTE meta-model (non-normative) domain domain domain MC domai network domain CONTREX meta-model Selected MARTE domain concepts CONTREX DSL (1) 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. Page 7

8 2 Analysis of the Requirements for the CONTREX metamodel This section, reports the main features that need to extend the reference the MARTE metamodel, 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 8

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 9

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, mixedcriticality and models for the validation/simulation of networking needs 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 modeldriven 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 10

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 11

12 2.2.2 Mixed-criticality 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 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 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 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 12

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 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 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 13

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 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. Page 14

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 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 realtime schedulability analysis depending on the criticality. Under this perspective, mixedcriticality 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 15

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 metamodels 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 16

17 Definition of NFP_Constraint in MARTE - UML profile diagram for NFPs modeling (Implementation of the NfpType and NfpConstraint stereotypes in MARTE) Page 17

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 18

19 «datatype» «nfptype» { exprattrib= expr } NFP_CommonType expr: VSL_Expression source: SourceKind statq: StatisticalQualifierKind dir: DirectionKind mode: string [*] criticality: Integer [*] NFP_Constraint kind:constraintkind [0..1] criticality: Integer [*] 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 19

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 20

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 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 21

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 P = dw(t) dt and according to a simplified discrete interpretation as a time discrete rate of energy consumption, P = ΔW ΔT = ΔW f 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 22

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 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 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 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 CBD-103] most recently extend the compositional Page 23

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 Basic concept 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 24

25 Figure 4.1, onwards denoting contracts by the letter C and HRCs by the letter M, additionally indexed by i ε N + to refer to the i-th HRC of a decomposition of M into n sub-hrcs {M 1,, M n }, also denoted as parts of the system. Additionally, we define the interface of an HRC M as the set of its directed in and output variables x Χ M = {x in, x out }, called ports. To choose only the functional-, timing- and power-specific subsets of M, C, Χ and x 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 Net = {Net asm, Net del } by the sets of out in its internal connectors, consisting of: the assembly connectors Net asm Χ Mi Χ Mj which internally link ports between different parts of the system; and its delegation connectors out Net del {Χ Mi Χ out in M } {Χ M Χ in Mi } which link up the port of the HRC s parts with the HRC s external ports. The direction of the interconnect net(x src, x snk ) Net is defined by position, naming the driving source x src of the net in front of the reader s sink x snk Contracts The contracts C of a component M are formally defined as triples C = (A, B, G). While the strong assumptions A delimit the component s maximum permissible input state space over the input variables x in of M, the weak assumptions B over x in perform a further division to subspaces, for which M assures the associated guarantees G over its output variables x out, if and only if the individual use case satisfies the corresponding assumptions. Hence, C is semantically interpreted as [[C]] A B G, with A, B and G being time bounded LTL or CTL properties, representing sets of timed traces S A (x in ), S B (x in ) and S G (x out ) over the I/O variables x in, x out Χ M of M. Declaring the type of a variable x to be ν(x) {N, Z, R, } and declaring the notion of time as the discrete but infinitely increasing variable t N + 0, a timed trace s x (t) is a discrete sequence of events {e(x, t 0 ), e(x, t 1 ), } + S x = {x [N 0 ν(x)]}, mapping the variable x to its values v(x, t i ) ν(x) for each point of time. A complete property specification C of a component M is then defined as C = asp i=0 contracts {C 1 n asp,, C asp asp } of all aspects aps {fct, time, pwr, }. n asp i C asp, considering all To extract a purified, port-specific expression of the effect of the assumptions, guarantees or even complete contracts, the restriction function X denotes the restriction of these constraints to solely the subset X of their original variables. Furthermore, ρ i and ρ denote the so-called port mapping or port substitution functions, with: ρ i identifies the port variables x in i, x out i Χ Mi of a part M i with the corresponding assembly and delegation connectors net(x in i, ), net(, x out i ) Net and ρ identifies the external ports x in, x out Χ M of the system M with the corresponding delegation connectors net(x in, ), net(, x out ) Net. 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 25

26 compatibility: G Msrc xsrc ρ Msrc A Msnk xsnk ρ Msnk between the connected components of a system; refinement: C C of a system M s specification C w. r. t. its component-based bottom-up composition by n parts {M 1,, M n }, specified by their contracts C i and logically composed to the Virtual Integration C (( n i=1 C i ρ i ) ρ ΧM ). 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 26

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 ν(x). For the description of the hierarchical decomposition of the overall system, subcomponents {M 1,, M n } and their interconnection Net = {Net asm, Net del } 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 27

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 References [CBD-1] Martens, E. S. J.; Gielen, G.: High-level modeling and synthesis of analog integrated systems. Springer-Verlag, Dordrecht, Page 28

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, [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, [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, [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, [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, [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, [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, [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, [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, [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, [CBD-13] Jones, K. D.: Analog and mixed signal verification. Invited Paper. FMCAD, [CBD-14] Maler, O.: Reachability for continuous and hybrid systems. In: Proceedings of the 3 rd International Workshop on Reachability Problems. Springer-Verlag, Berlin, Heidelberg, [CBD-15] Hainry, E.: Decidability and undecidability in dynamical systems. Technical Report. Nancy, [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, [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, [CBD-18] Kundert, K.: Principles of top-down mixed-signal design. In: The Designers Guide Community [CBD-19] Owicki, S.; Gries, D.: Verifying properties of parallel programs: An axiomatic approach. In: Communications of the ACM. Volume: 19, Issue: 5, [CBD-20] Misra, J.; Chandy, K.: Proofs of Networks of Processes. In: IEEE Transactions on Software Engineering. Volume: 7, Issue: 4, Page 29

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, [CBD-22] Lamport, L.: Specifying Concurrent Program Modules. In: ACM Transactions on Programming Languages and Systems (TOPLAS). Volume: 5, Issue: 2, [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, [CBD-24] Meyer, B.: Design by Contract. Technical Report: TR-EI-12/CO. Interactive Software Engineering Inc., [CBD-25] Meyer, B.: Eiffel: programming for reusability and extendibility. In: SIGPLAN Notices. Volume 22, Issue: 2, [CBD-26] Meyer, B.: Design by Contract. In: Dino M.; Meyer, B. (Eds.): Advances in Object-Oriented Software Engineering. Prentice Hall, New York, [CBD-27] Meyer, B.: Applying design by contract. In: IEEE Computer Society: Computer. Volume: 25, Issue: 10, [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, [CBD-29] McMillan, K. L.: A compositional rule for hardware design refinement. In: Grumberg, O. (Ed.): Computer Aided Verification. Springer-Verlag, Berlin, Heidelberg, [CBD-30] Alur, R.; Henzinger, T. A.: Reactive Modules. In: Formal Methods in System Design. Volume: 15, Issue: 1, [CBD-31] Alfaro, L.; Henzinger, T. A.: Interface Automata. In: Proceedings of the Ninth Annual Symposium on Foundations of Software Engineering [CBD-32] Dill, D. L.: Trace theory for automatic hierarchical verification of speedindependent circuits. Ph.D.Thesis. MIT Press, Cambridge, [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, [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, [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, [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, [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, [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, [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, Page 30

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 [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, [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, [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, [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, [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, [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, [CBD-48] Damm, W.: Controlling speculative design processes using rich component models. In: Fifth International Conference on Application of Concurrency to System Design, [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, [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, [CBD-51] Josko, B.; Ma, Q.; Metzner, A.: Designing Embedded Systems using Heterogeneous Rich Components. Proceedings of the INCOSE International Symposium, [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, [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, [CBD-54] Benveniste, A.; Caillaud, B.; Passerone, R.: Multi-viewpoint state machines for rich component models. In: Model-Based Design of Heteroeneous Systems Page 31

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), [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), [CBD-57] SPEEDS. European Union 6th Framework Project in Embedded Systems Development ( ). IP Contract No URL: Accessed: 22 nd Mar [CBD-58] CESAR. ARTEMIS Joint Undertaking Project. ART Call URL: Accessed: 22nd Mar [CBD-59] SPES BMBF-Project. FKZ: 01IS08045W. URL: Accessed: 22nd Mar [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, [CBD-61] SPES_XT. BMBF-Project. FKZ: 01IS12005M. URL: Accessed: 22nd Mar [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 Research Centre Rennes Bretagne Atlantique. Rennes Cedex, [CBD-63] Borkar, S.: Design challenges of technology scaling. In: IEEE Micro. Volume: 19, Issue: 4, [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, [CBD-65] Borkar, S.; Chien, A. A.: The future of microprocessors. In: Communications of the ACM. Volume: 54, Issue: 5, [CBD-66] Mudge, T.: Power: A First-Class Architectural Design Constraint. In: Computer. Volume: 34, Issue: 4, [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 40 th annual Design Automation Conference. ACM, New York, [CBD-68] Mehra, R.; Rabaey, J.: Behavioral level power estimation and exploration. In: Proceedings of the International Workshop on Low Power Design. Napa Valley, [CBD-69] Landman, P.: In: High-level power estimation. In: Proceedings of the International Symposium on Low Power Electronics and Design, [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, [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, [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, Page 32

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, [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, [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, [CBD-76] Ahuja, S.: High Level Power Estimation and Reduction Techniques for Power Aware Hardware Design. PhD thesis. Virginia Polytechnic Institute and State University, [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, [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, [CBD-80] Silicon Integration Initiative (Si2): Si2 Common Power Format Specification [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 [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, [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, [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 [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, [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, [CBD-87] Saptarshi, B.: Low-Power Design Applications for Formal Verification. SOCcentral, 7 th May URL: Page 33

34 Accessed: 24th Feb [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), [CBD-89] Loh, L.: Formal Methods for Power-Aware Verification. EE Times, 17. Dec URL: Accessed: 24th Feb [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, [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, [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, [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, [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, [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, [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, [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, [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, [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, [CBD-100] Quinton, S.; Graf, S.; Passerone, R.: Contract-based reasoning for component systems with complex interactions. Verimag Research Report n. TR [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, Page 34

35 [CBD-102] Le, T. T. H.; Fahrenberg, U.; Legay, A.; Passerone, R.: An Operational Contract Framework for Heterogeneous Systems. Technical Report n. DISI 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, [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, [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, [CBD-106] ENERSAVE. BMBF-Project. FKZ:16BE1102. URL: Accessed: 27th Feb [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, [CBD-108] Steinhorst, S.: Formal Verification Methodologies for Nonlinear Analog Circuits. PhD thesis. Goethe-Universität Frankfurt. Frankfurt, [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, [CBD-110] Accellera: Property Specification Language - Reference Manual. Version [CBD-111] IEEE/IEC: Standard for Property Specification Language (PSL) International Standard IEEE / IEC The Institute of Electrical and Electronics Engineers Inc. (IEEE) / International Electrotechnical Commission (IEC) Central Office. Edition 1.0, [CBD-112] Maler, O.: Extending PSL for Analog Circuits. PROSYD Deliverable (D1.3/1), [CBD-113] Nickovic, D.: Checking Timed and Hybrid Properties: Theory and Applications. PhD thesis. University Joseph Fourier Grenoble. Grenoble, [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, [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, [CBD-116] Lämmermann, S.: Domänenübergreifende temporale Eigenschaftsverifikation heterogener Systeme. PhD thesis. Eberhard Karls Universität Tübingen. Tübingen, [CBD-117] Mitschke, A.: Definition and exemplification of RSL and RMM. CESAR Deliverable (D_SP2_R2.1_M1), Page 35

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, [CBD-119] Wolf, E.: Evaluation formaler Spezifikationssprachen für den Entwurf gemischt analog-digitaler Systeme. Masterarbeit. Technische Universität Ilmenau, [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) [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, [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, [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, [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, [CBD-125] IEEE: Standard for IP-XACT Standard Strcuture for Packaging, Integrating, and Reusing IP within Tool Flows. IEEE Standard The Institute of Electrical and Electronics Engineers Inc. (IEEE). Edition 1.5, [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) 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) [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 49 th Annual Design Automation Conference (DAC) [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 , [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 36

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 37

38 Resource resmult: Integer isprotected : Boolean isactive : Boolean ProcessingResource CommunicationResource speedfactor: NFP_Real CommunicationEndPoint packetsize : Integer CommunicationMedia elementsize : Integer ComputingResource 0..* endpoint media 1..* host 1..* AbstractChannel 1..* nwinterface NetworkInterface nwinterface overhead : WorkloadBehabior 0..* errorrate : NFP_Percentage wireless: Boolean 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 38

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 39

40 CommunicationStep msgsize: NFP_DataSize RtUint isdynamic : Boolean ismain : Boolean memorysize : NFP_DataSize srpoolpolicy : PoolMgtPolicy srpoolwaitingtime : NFP_Duration CommunicationRequirements maxerrorrate: NFP_Percentage maxthroughput: NFP_Frequency maxdelay: NFP_Duration CommunicatingTask 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 40

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. CommunicationChannel msgsize: NFP_DataSize utilization: NFP_Real DataFlow communciationrequirements: CommunicationRequirements [*] tasksource: Task [*] taskdestination: Task [*] 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 41

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 42

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 43

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. src init_fun din src 1 us upsrc av res ds downres g sn k src_fun us_fun avg_fun ds_fun snk_fun 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 Page 44

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. 2 SDF::delay avginit 2 dout 0,0 din SDF::source src SDF::comb SDF::comb2 SDF::comb src us1 upsrc 2 avg res ds1 downres 1 SDF::signa 1 2 SDF::signa SDF::signa SDF::signa l l l l SDF::sink snk src_fun us_fun avg_fun ds_fun snk_fun Figure 7.2: Sketch of the example (single level of hierarchy) in ForSyDe-SystemC din 0,0 2 uc_arc 2 SDF_NODE sr c src SDF_NODE us 1 upsrc SDF_NODE avg1 SDF_NODE uc_arc uc_arc uc_arc uc_arc ds 1 SDF_NOD E src_fun us_fun avg_fun ds_fun snk_fun res downres snk 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. Page 45

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 46

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 firing 1. 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 47

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 48

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 49

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 50

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 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 51

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 rendezvous, 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 52

53 8 References [1] "Description of Work". CONTREX Design of embedded mixed-criticality CONTRol systems under consideration of EXtra-functional properties, FP7-ICT (611146), [2] [UC-1] Alan Burns and Rob Davis. Mixed Criticality Systems - A Review. [3] [UC-2]P. Graydon and I. Bate. Safety assurance driven problem formulation for mixedcriticality scheduling. In Procceedings of WMC, RTSS, pages 19-24, [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 doi: /DSD URL: ccce [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, Sept URL: jhkjhlkj [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 , Proceedings of the ACM/IEEE 13th International Conference on Model Driven Engineering, Languages, and Systems (MODELS), Oct. 3-8, [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 [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 [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 [10] P. Peñil, F. Herrera, E. Villar. "Formal Foundations for MARTE-SystemC Interoperability". Forum on specification & Design Languages 2010, FDL'2010, IEEE [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 [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 [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 Page 53

54 Arquitecting and Construction of Embedded Systems, ACES-MB 2012, doi: / [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 [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 [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) [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 Found on the CONTREX redmine repository. [18] E.A.Lee et al. Synchronous data flow. Proceedings of the IEEE, 75 (9), Page 54

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 55

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 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. Page 56

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 57

58 Page 58

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 3 d Embedded 7 Mixedcritical 5 Platforms, network configuration/characterization parameters, extra-functional properties PowerPC / Zynq Intec s EDAla b 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 OFFI S ixtronic s GM V POLIT O DOCE A U C Tota l Page 59

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 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 U C Tota l Page 60

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 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-ofthe-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, (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, (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, (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, (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 ) Page 61

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 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 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 62

63 Verification tool: Compositional native simulation and performance analysis from the PSM. For timing verification by schedulability analysis MAST can be used 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 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 63

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 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 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 64

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 65

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: (GMV) Fernando Herrera (KTH), John Favaro (INTECS) and Carmen Lomba Date: May 13 th, 2014 Version Table: version Contributors date Description 0.1 FeHe January 14 th, st version 0.2 JoFa, FeHe March11 th, 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 28 th, 2014 Minor polishing (spell checking, grammar) 0.5 CaLo, FeHe May 13 th, 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 Page 66

67 Content 1 Introduction Access to standards and complementary documentation Regarding the sources of this assessment Assessment of standards for Mixed-Criticality IEC 61508/ Safety related Aviation Standards Introduction DO-178C Integrated Modular Avionics: RTCA DO EUROCAE ED ISO Considerations for the construction of the CONTREX meta-model and analysis&design methodologies References Page 67

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 DO-178B(RTCA/FAA) ED-12B (EUROCAE/EASA) DO-254 ISO Software Considerations in Airborne Systems and Equipment certification Design Assurance Guidance for Airborne Electronic Hardware Road vehicles -- Functional safety (Parts 1 to 10) 331 in webstore of $ (non-member price of electronic version) 128.4$ (non-member price paper) in wev store of $ (non-member price of electronic version) in web store of (approximated price from the prices of each of the 10 parts, after converting price in CHF) In 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 Moreover, this document has been revised from partners with access to the actual standards (INTECs and GMV). Page 68

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 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. EUC E/E/EP safetyrelated systems EUC Control System Other Tech. Safetyrelated system s External risk reductio nfacilitie s overal safety Functional Safety Scope of IEC normative and recommendations Figure 12. IEC 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 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 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 Page 69

70 and 4 categories of consequences. As it is shown, the range of the risk function consists in 4 classes of risks. 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 Likelihood Consequence RiskFunction 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 Risk Risk Class I II III IV Range (failurers/year) Unaceptable Undesirable Tolerable Acceptable Figure 13.A risk assessment function proposed by IEC 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 Page 70

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. Calls of safety function Period of time t Boundsonthe response time 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 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 Page 71