ACESMB 2009

-

Table of Contents.....................................................................................................................................3 Invited Talk - Semantics preservation issues in the design and optimization of SW architectures for automotive systems

Marco Di Natale (Scuola Superiore Sant’Anna, Italy)...........................................................................9 SOPHIA: a Modeling Language for Model-Based Safety Engineering

Daniela Cancila, François Terrier (CEA LIST), Fabien Belmonte (ALSTOM), Hubert Dubois, Huascar Espinoza, Sébastien Gérard and Arnaud Cuccuru (CEA LIST) ............................................................ 11 PaNeCS: A Modeling Language for Passivity-based Design of Networked Control Systems Formal Design Models for Distributed Embedded Control Systems

Christo Angelov, Krzysztof Sierszecki and Yu Guo (University of Southern Denmark, Denmark) .... 43

Improving Timing Analysis for Matlab Simulink/Stateflow

Lili Tan, Björn Wachter, Philipp Lucas and Reinhard Wilhelm (Universität des Saarlandes, Germany) ........................................................................................................................................................... 59 Prototyping of Distributed Embedded Systems Using AADL

Mohamed Yassin Chkouri and Marius Bozga (VERIMAG, France) .................................................... 65 Towards Intelligent Tool-Support for AADL Based Modeling of Embedded Systems

Dries Langsweirdt, Yves Vandewoude and Yolande Berbers (K.U.Leuven, Belgium) ....................... 81

Model-Based Codesign of Critical Embedded Systems

Marco Bozzano, Alessandro Cimatti (Fondazione Bruno Kessler, Italy), Joost-Pieter Katoen, Viet Yen Nguyen, Thomas Noll (RWTH Aachen University, Germany) and Marco Roveri (Fondazione Bruno Kessler, Italy) ..................................................................................................................................... 87 Design Complexity Management in Embedded System Design

Johan Ersfolk, Johan Lilius (Åbo Akademi University, Finland), Jari Muurinen, Ari Salomäki (Nokia Devices, Finland), Niklas Fors and Johnny Nylund (Åbo Akademi University, Finland)..................... 93 Using Higher-order Transformations to Derive Variability Mechanism for Embedded Systems Goetz Botterweck (Lero, Ireland), Andreas Polzer and Stefan Kowalewski (RWTH Aachen University, Germany)....................................................................................................................... 107 Model-Based Extension of AUTOSAR for Architectural Online Reconfiguration

Basil Becker, Holger Giese, Stefan Neumann, Martin Schenck and Arian Treffer (University of Potsdam, Germany)......................................................................................................................... 123

Foreword

The development of embedded systems with real-time and other critical constraints raises distinctive problems. In particular, development teams have to make very specific architectural choices and handle key non-functional constraints related to, for example, realtime deadlines and to platform parameters like energy consumption or memory footprint. In this context, the last few years have seen an increased interest in using model-based engineering (MBE) techniques. MBE techniques are interesting and promising for the following reasons: They allow to capture dedicated architectural and non-functional information in precise (and even formal) domain-specific models, and they support a layered construction of systems, in which the (platform independent) functional aspects are kept separate from architectural and non-functional (platform specific) aspects, where the final system is obtained by combining these aspects later using model transformations. The objective of this workshop is to bring together researchers and practitioners interested in model-based software engineering for real-time embedded systems. We are seeking contributions relating to this subject at different levels, from modeling languages and semantics to concrete application experiments, from model analysis techniques to modelbased implementation and deployment. Given the criticality of the application domain, we particularly focus on model-based approaches yielding efficient and provably correct designs. Concerning models and languages, we welcome contributions presenting novel modeling approaches as well as contributions evaluating existing ones. The workshop targets in particular: •

Architecture description languages (ADLs). Architecture models are crucial elements in system and software development, as they capture the earliest decisions which have a huge impact on the realization of the (non-functional) requirements, the remaining development of the system or software, and its deployment. We are particularly interested in examining: o Position of ADLs in an MDE approach; o Relations between architecture models and other types of models used during requirement engineering (e.g., SysML, EAST-ADL, AADL), design (e.g., UML), etc.; o Techniques for deriving architecture models from requirements, and deriving high-level design models from architecture models; o Verification and early validation using architecture models. • Domain specific design and implementation languages. To achieve the high confidence levels required for critical embedded systems through analytical methods, in practice languages with particularly well-behaved semantics are often used, such as synchronous languages and models (Lustre/SCADE, Signal/Polychrony, Esterel), super-synchronous models (TTA, Giotto), scheduling-friendly models (HRTUML, Ada Ravenscar), or the like. We are interested in examining the model-oriented counterparts of such languages, together with the related analysis and development methods. • Languages for capturing non-functional constraints (MARTE, AADL, OMEGA, etc.) • Component languages and system description languages (SysML, MARTE, EAST-ADL,

AADL, BIP, FRACTAL, Ptolemy, etc.).

We accepted 10 papers for the workshop from 8 different countries: 7 full papers and 3 short papers. We hope that the contributions for the workshop and the discussions during the workshop will help to contribute and provide interesting new insights in Model Based

Architecting and Construction of Embedded Systems.

The ACESMB 2009 organizing committee,

Stefan Van Baelen,

Thomas Weigert,

Ileana Ober,

Huascar Espinoza.

Mamoun Filali,

Sébastien Gérard,

Susanne Graf,

Iulian Ober.

September 2009.

The ACESMB 2009 steering committee,

Acknowledgments

The Organizing Committee of ACESMB 2009 would like to thank the workshop Program

Committee for their helpful reviews.

This workshop is organised as an event in the context of

• The IST-004527 ARTIST2 Network of Excellence on Embedded Systems Design • The research project EUREKA-ITEA SPICES (Support of Predictable Integration of mission Critical Embedded Systems) Semantics Preservation Issues in the Design and Optimization of SW Architectures for

Automotive Systems

Marco Di Natale

Scuola Superiore Sant’Anna, Pisa, Italy Abstract. Architecture selection and design optimization are critical stages of the Electronics/Controls/ Software (ECS) -based vehicle design flow. In automotive systems design, complex functions are deployed onto the physical HW and implemented in a SW architecture consisting of a set of tasks and messages.

The talk will present work performed in cooperation with GM R&D and UC Berkeley, in which we optimized several aspects of the software architecture design, including the definition of the task periods, the task placement and the signal-to-message mapping and we automated the assignment of priorities to tasks and messages in order to meet end-toend deadlines and minimize latencies.

Architecture selection can be accomplished by leveraging worst case response time analysis within an optimization framework and we provide hints on how to use stochastic or statistical analysis to further improve the approach. However, current work has only scantly addressed the issues of preserving the semantics of functional models during implementation. Semantics preservation issues impose additional constraints on the optimization problem, but also reveal very interesting tradeoffs between memory and time/performance. In addition, the need to deal with heterogeneous models and standards (like AUTOSAR in the automotive business) further complicates the scenario. SOPHIA: a Modeling Language for Model-Based

Safety Engineering Daniela Cancila1, Francois Terrier1, Fabien Belmonte2, Hubert Dubois1,

Huascar Espinoza1, S´ebastien G´erard1, and Arnaud Cuccuru1

CEA LIST⋆, ALSTOM⋆⋆ Abstract. Development of increasingly more sophisticated safety-critical embedded systems requires new paradigms, since manual approaches are reaching their limits. Experiences have shown that model-driven engineering is an approach that can overcome many of these limitations. Using model-based approaches however lead to new challenges regarding the cohesive integration of both safety engineering and system design along the system development process. In this paper, we present SOPHIA, a modelling language that formalizes safety-related concepts and their relations with system modelling constructs. We particularly focus on accident models and on how to achieve confidence that the frequency of possible accidents will be tolerable. In addition, we explore some strategies to implement SOPHIA as a complementary modelling language to

SysML and reuse some useful constructs form the UML MARTE profile. 1

Introduction In order to cope with the increasing design complexity of safety-critical systems, safety assurance should be considered as early as possible in the design process. Among other goals, safety assurance allows achieving confidence that the frequency of accidents will be acceptable. For this purpose, safety engineers need to specify all possible safety parameters that directly impact the software architecture design, and then to determine the probability rates of the deviation from fulfilling the system functions. The Safety Integrity Level (SIL) attribute is an example of such a parameter. The design of a given system and its subsystems changes according to the value of the SIL associated with each functionality of the system. Possible values range between “0” (less critical) and “4” (most critical) [ 19 ]. Thus, a system architecture including SIL4-functionalities must guarantee the maximum level of safety integrity, which would for example imply to add redundant hardware nodes. ⋆ CEA

LIST, Laboratoire d’Ing´enierie dirig´ee par les mod`eles pour les Syst`emes Embarqu´es Point Courrier 94, Gif-sur-Yvette, F-91191 France {daniela.cancila, francois.terrier, hubert.dubois, huascar.espinoza, sebastien.gerard,arnaud.cuccuru}@cea.fr ⋆⋆ Alstom Transport Information Solution 48 rue Albert Dhalenne, 93482 Saint-Ouen

Cedex [e-mail]

Recently, the railway safety community has proposed a new methodological guidance to enhance safety evaluation. In this proposal, SIL-to-function allocations exploit a new attribute named Tolerable Accident Rate (TAR). The TAR is defined as the “threshold between what is tolerable and what is undesirable with respect to the consequence of an accident” [ 8, 3 ]. In current industrial practice, the TAR is manually calculated, typically by using pre-defined tables. As the value of TAR influences the value of SIL, it may impact the architecture of a system. More precisely, the value of the TAR for a given accident (e.g. the headon collision between trains) is used to calculate the value of the tolerable hazard for the same accident. Hence, we have a 1:1 correspondence between tolerable hazard and SIL. (We refer the reader interested in the technical details to [ 8, 3 ].)

Most of current practices on system safety assurance rely mainly on manual processes. They are therefore very dependent of the skill and experience of the engineers. This problem is exacerbated by the fact that safety engineering and software design domains have developed their own techniques and methodologies. Let us consider the example of the railway application domain. On the one hand, safety actors adopt standards that provide recommendations for safety assessment. Illustrative examples are fault tree analysis [ 22 ] and formal verification techniques, such as the B method [ 2 ]. On the other hand, actor from the software design and development community follow component-based techniques, such as [ 33, 9, 14 ]. In this context, defining the “right mapping” between safety models and models for software design/development is an essential challenge.

In order to avoid error-prone processes and to integrate both safety engineering and system design, we adopt a model-based safety engineering process. Model-Driven Engineering (MDE) [30, 31] is being successfully adopted in several industrial research projects [ 21, 18, 32, 29 ]. Two kinds of approaches are actually put into practice. In the first case, safety engineers and system designers share the same model of the system while using different views of it. In the second case, they use different models with clearly and formally defined relationships (using for example model transformation descriptors). In both cases, the direct benefits of MDE concern the possibility of automating part of the process of safety assurance, e.g. by automatically calculating certain information such as TAR parameters from the input safety parameters. This capability does not only simplify the process. It also enables to save time and, more importantly, it makes safety assurance as explicit part of an iterative design process. Indeed, new results can be more easily generated once the model has been changed. Moreover, the fact that models are more formally defined reduces the probability of introducing errors or omitting important details, since the analysis information is linked to the architectural model of the system.

As a main contribution within this paper, we introduce for the first time SOPHIA, a modelling language for safety concerns. SOPHIA provides an answer to safety industrial concerns by allowing designers to specify the safety attributes in a software design model. Our paper focuses on the infrastructure of SOPHIA, which is similar to that of MARTE [ 25 ]: It is based on a metamodeling, a profiling and a modeling space. As a result, SOPHIA has an independent language specification that can complement more general-purpose languages such as UML or SysML [ 24 ]. At the profile level, we propose to use some suitable concepts from MARTE, the OMG’s UML profile for real-time embedded systems [ 25 ], in particular the Value Specification Language (MARTE::VSL).

In Section 2, we discuss some related works and we identify fundamental criteria and principles for model-based safety engineering. In Section 3, we explain our industrial motivations. We also provide a rationale for SOPHIA as well as a description of its Fundamental Concepts. Moreover, we investigate the strategies regarding the integration of safety and software design. Section 4 is the central part of the paper. For the first time, we discuss the whole structure of SOPHIA: from its Fundamental Concepts to the implementation. In Section 5, we compare our approach with those given in Section 2. Finally, conclusions and on-going works are presented. 2

Related Work Integrating safety concerns in general-purpose modelling process is a big challenge that has been explored in many directions. In this section, we focus on a few works which are receiving specific attention in the MDE community.

In order to study dependability in AADL (Architecture Analysis & Design Language) [ 1 ], P. Feiler and al. introduce a framework to model the error state propagations in a hierarchical architecture [ 17 ]. Error propagation can occur at component level (by composition of the components), at the hardware level (by interconnecting processors) and between the hardware and the components (“due to their binding to the execution platform” [ 17 ]). In order to limit, or even avoid, the error propagation, the authors provide suitable filters (guards), for example between the interconnection of components. In [ 17 ], P. Feiler and al. addresses error modelling as a complementary view to system architecture, which is an important topic related to safety. However, it does not cope with the problem of accident case modelling and the specification of safety attributes such as the SIL.

In order to complement AUTOSAR (the European industrial standard to specify component-based software infrastructures in automotive applications [ 6 ]), some European industries and academics have defined an architecture description language, so called EAST-ADL [ 5 ]. This includes requirements modelling, feature content at the level of a vehicle description, architecture variability, functional structure of applications, middleware, plant (environment), abstract hardware architecture, and preliminary functional allocation. In addition, EAST-ADL enables the modelling of system failure behaviour and allows analysis of that behaviour using safety analysis tools. In particular, EAST-ADL aimed at using a safety design flow compatible with that defined by the upcoming ISO 26262 standard, including support for concepts such as hazards, safety goals and requirements, and the representation of ASILs (Automotive SILs). Many of these concepts were represented in the first version of EAST-ADL, but there were many others not considered, e.g. accident and its consequences, or ASIL decomposition.

FTA is one of the main safety analysis tools. In [ 10 ], Douglass introduces a UML safety profile defining notions such as fault, hazard, and traceability of requirements. Such notions allow us to create fault tree analysis (FTA) diagrams and, hence, to study how “conditions and faults combine to create hazard”. One of the main contributions of this approach is to adopt UML and its profiling mechanism to provide a common specification language to integrate safety and design activities. This facilitates the collaboration and common understanding between safety engineering teams and system design teams. The underlying approach is the following. First, designers create a model with safety attributes, from which FTA is automatically generated. Engineers then study FTA and then they may manually change the model architecture. In other words, this approach does not deal with “safety reverse engineering”. As a result, safety analysis is made a posteriori. When we deal with real industrial cases, a model quickly increases in complexity and in number of components. Consequently, it also occurs in the related FTA. The study of FTA is then a very complex work. In order to reduce such a complexity, one possible way is to iteractivly integrate safety engineering into model-based engineering of an architectural system. The underlying process is to have an automatic propagation of safety attributes in the architectural model such that it is correct with respect to “given safety requirements”.

In [ 15 ], de Miguel and al. propose an approach similar to work [ 10 ]. Therefore, it has similar advantages and drawbacks. Finally, in [ 26 ], the authors introduces the UML profile for quality of service and fault tolerance analysis, called QoS&FT profile. In this profile, some aspects of safety analysis are covered (such that fault, errors, fault, non desirable events, etc). Notions, such as accidents and SIL are however not here considered. 3

Safety Engineering This section provides some background information that have been taken into account for the definition of SOPHIA. Before describing the safety fundamental concepts, we want to discuss the high-level requirements for safety modelling from an industrial perspective.

Standards EN 50126 [ 11 ], EN 50128 [ 12 ] and EN 50129 [ 13 ] define a safety process plan for programmable electronic signalling devices including risk evaluation, SIL to function mapping and the life cycle recommendations by SIL. In particular, these standards recommend applying fully formal specification to ensure SIL 4. It means that engineers must provide mathematical proven demonstration for the safety properties of a given component.

Typically, in industry there is a gap between formal methods and textual system specifications, as well as between subsystem specifications. The main reason for this gap is that there is no standard and common language can be used to capture the different aspects. Semi-formal modelling approaches can bring a common basis to interconnect these different specification aspects. This is the main motivation for formalizing safety attributes into system models, from the early phases of the development process.

Therefore, SOPHIA has the following objectives: 1. enabling the specification of safety attributes in the architectural model of as sytem; 2. automating the calculation of some safety parameters in order to afford modelbased engineering of safety; 3. providing an environment for system development in which coherence (compatibility of all requirements at the same level of abstraction, i.e., horizontal development) and correction (“good” decomposition of parent requirements into children requirements abstraction, i.e., vertical development) properties can be guaranteed by construction and/or verified a posteriori.

Provided these general needs, we present in the next section an excerpt of some fundamental concepts of SOPHIA related to accident case concerns 3.1

SOPHIA Fundamental Concepts The concepts of SOPHIA (and their relationships) are based on Alstom Ontology [ 7 ] and on Alstom works such as [ 8, 3 ], which model their safety domain knowledge. In this section, we will use metamodels to describe the Fundamental Concepts of SOPHIA. They are organized into a set of packages and libraries. We use packages to introduce notions and their relationships, and we use libraries to specify data types. The package SOPHIA Fundamental Concepts contains two main subpackages, so called respectively SystemDesing and SafetyConcepts. Package SystemDesing specifies the relationships between safety concepts and model elements of a system. Package SafetyConcepts contains the following packages: • package ACCIDENTS, which describes notions and relationships that are involved in an accident. • package MITIGATIONS, which describes notions and relationships about mechanisms (barriers) to mitigate an accident ; • package FaultContainmentRegion, which describes notions and relationships that are involved in error propagations.

In this paper, we focus on package ACCIDENTS. Our intent is to show the details of the whole language design chain, from the formalization of the TAR attribute in the SOPHIA Fundamental Concepts, to the language implementation details. The result of our work is a first, but firm step towards model-based safety engineering.

Figure 1 shows some notions of package ACCIDENTS. Among them, we depict the TAR attribute. The notions are represented as metaclasses.

Hazard is “an event observable at the system boundary, which has potential either directly or in combination with other factors (external to the system), for giving rise to an accident at railway system level” [ 3 ].

AccidentCase is an unintended event with undesirable outcomes. AccidentCase leads to AccidentConsequenques. An AccidentCase is identified by the following properties: a unique ID; an AccidentType chosen from a statically pre-defined list; AutomaticTolerableAccidentRate and TolerableAccidentRate.

AutomaticTolerableAccidentRate is the maximum rate of occurrence that is tolerable for a likely Accident [ 3 ]. It is specified by a number of events per hour (real number) and it is derived from the frequency and the severity of an accident.

TolerableAccidentRate and AutomaticTolerableAccidentRate are similar properties. The only difference is that TolerableAccidentRate is manually set by safety engineers when they have to deal with exceptional cases (i.e., for which a pre-defined table is not available). In Figure 5, Table “a:” identifies the Risk Tolerability of an accident. It is described with combinations of the following properties: severity of the consequences and frequency of the accident. TolerableAccidentRate is undefined by default. However, if TolerableAccidentRate is set to a different value than undefined, then it has a higher priority with respect to AutomaticTolerableAccidentRate. The importance of having both properties (i.e., one automatically specified and the other one manually set), is that: 1.) the modelling process can be automated in a correct way that respects table Risk Tolerability, 2.) we have traced to the computation, which is automatically derived from table Risk Tolerability. Furthermore, we can identify the divergence points specified by the exceptional cases. In case of divergence, designers must motivate their choices with respect to the value automatically calculated from table Risk Tolerability. From an implementation standpoint, designers could motivate their decisions in a suitable dialog box. The implementation of this latter is part of our ongoing work.

AccidentConsequences is the result of a given AccidentCase. It is defined by the severity of the consequences with respect to the given AccidentCase. Severity may take only one of the following four predefined values: Catastrophic, Critical, Marginal, or Insignificant. These values of severity are captured by an enumeration which is part of our SOPHIA Fundamental Model library.

Next, we discuss the strategies to integrate the safety conceptual concepts defined above with a given general-purpose modelling language, in this case SysML. SysML was chosen by Alstom since it is an OMG standard specification for modelling of complex systems. Although SysML provides a formalism to manage requirements and system design together, SysML is lacking of concepts for dealing with specific concerns of safety. We have three possible strategies to integrate SOPHIA and SysML.

Strategy a defines SOPHIA as an extension to SysML. It has the advantage to be optimally tailored to the aimed integration with SysML. One of the main drawbacks of this strategy is that safety concepts will strongly depend on SysML. Then, any modification of SysML might lead to a modification in the SOPHIA extensions. In addition, safety concepts and SysML are conceptually disjoint, although complementary, and directly extending SysML does not make sense in our context.

Strategy b defines SOPHIA from scratch, i.e. as a pure domain-specific modeling specification language (DSML) (i.e. independently of UML) and then combining this metamodel with SysML. Consequently, Strategy b surmounts the drawbacks of Strategy a: safety concepts are independent not only of SysML but also of UML. It provides a framework that is fully dedicated to safety concepts and it is independent from other formalisms. As discussed in work [ 16 ], Strategy b has the following drawback: having safety models defined using two independent formalisms leads to strong difficulties for interfacing both types of models of the same system. This is particularly problematic for tracing safety information with the system architecture models. This problem is mainly reflected at tool level, since traceability always imply an important endeavour.

Strategy c proposes to firstly introduce SOPHIA as a package of Fundamental Concepts via a metamodel, in a way that is independent of the UML formalism. In a second stage, this metamodel (also called domain model ) is implemented as a UML profile. In this way, we overcome the drawbacks of Stategies a and b, because the concepts are defined independently of UML, and, thereby, gain the benefits of a domain-specific approach. Moreover, this approach improves tool interoperability and facilitates the interface and traceability between different modelling aspects of the same system. SOPHIA and SysML languages (which are both designed as UML profiles) may indeed be used jointly in the same UML tool. A successful example of this approach is MARTE [ 25 ]. strategy a strategy b strategy c

Language Engeneering

Domain Metamodel

NO YES YES

Profile YES NO YES

End User Domain Tool environment One single Model

One single Tool YES NO YES

YES NO YES

Fig. 2. Strategies to integrate safety modeling language in the system architecture 4

From SOPHIA Safety Concepts to Implementation

SOPHIA Architecture We adopt Strategy c and we develop it further. First af all, we strategically use the definition of profile, firstly introduced by S. Cook, and successfully adopted by other researchers: a profile is a family of related languages. It suggests the idea of exploiting the composition of pre-existing profiles. Indeed, our intent is not to define completely “new” metamodel and profile, covering all concepts from safety to architectural design. Our intend is indeed to reuse the existing work as much as possible, so that we can take advantage of pre-existing works and related tools.

In spite of SysML role for requirements and system’s architecture (requirement and block diagrams), SysML lacks in the specification of temporal attributes [ 4 ]. Several European research projects are therefore willing to define a combined usage of both SysML and MARTE.

In the context of SOPHIA, we were particularly interested in MARTE to define nonfunctional properties (MARTE::NFP) and MARTE::VSL to valuate these properties. The MARTE::NFP package allows designers to annotate a UML model with non-functional properties. VSL stands for Value Specification Language and allows designers to specify “parameters/variables, constants, and expressions in textual form” [ 25 ]. Moreover, VSL supports arithmetic and logical expressions. Beyond the benefits of the SOPHIA alignment with a recognized international standard, the main advantage of this integration is the ability to support a well-formed syntax and semantics for safety parameters and to consequently enable automated derivation of dependent safety variables (See Section 4.2).

LANGUAGE ENGINEERS

DOMAIN

END

USER DOMAIN

FUNDAMENTAL

CONCEPT

LEVEL PROFILE

LEVEL MODELING

LEVEL

UML

SOPHIA foundamental concepts

MARTE foundamental

concepts <<reference>>

<<reference>> <<mapping>>

<<mapping>> SysML (subset)

MARTE SOPHIA <<import>> (subset)

<<apply>> USER

MODEL

SOPHIA is a UML profile for safety modelling modelling whose definition is based on SOPHIA Fundamental Concepts. In UML, there is not a specific symbol between a profile and its fundamental concepts. To explicitly capture this relationship, we use a dashed arrow annotated with the word “mapping”, following the OMG notation introduced in work [28].

Like SOPHIA, MARTE extends UML and it is based on MARTE Fundamental Concepts, so-called MARTE Domain Model.

At fundamental concepts level, we have UML metamodels respectively denoting SOPHIA Fundamental Concepts and MARTE Fundamental Concepts. 4.2

SOPHIA, a UML profile for safety In this section, we describe the UML profile for SOPHIA. It consists of a set of UML extensions and libraries concretized through stereotypes and data types. They map to the SOPHIA Fundamental Concepts (see Figure 3 for a big picture). Similarly to the SOPHIA Fundamental Concepts packages, the corresponding UML profile the profile is designed following a modular approach by grouping language constructs into individual packages, with the ability to select only those packages that are of direct interest in a given model. Due to space limitations, it is not possible to provide details covering the all profile. Therefore, we will focus on the SOPHIA package ACCIDENTS described in Section 3.1.

In the package ACCIDENTS every fundamental concept will directly result in a UML stereotype with its corresponding properties. In this case, there is a 1:1 mapping between the Fundamental Concepts and the profile element. The bottom package in Figure 4 defines how the metaclasses of the UML metamodel are extended with SOPHIA concepts, while the top-hand package shows a subset of the SOPHIA library with some enumeration types of interest.

Before describing the details of how SOPHIA exploits MARTE::VSL, let us introduce a real industrial railway example of risk assessment.

Example Figure 5 shows a typical example of risk assessment tables used in the railway domain. Such tables are used to identify the tolerable accident rate (TAR) of a given accident case (stereotype AccidentCase in Figure 4) and the occurrence rates of the different consequences of an accident case (stereotype AccidentConsequences in Figure 4). Typically, these tables are standardized by the territory authorities. For the sake of simplicity, we focus on the calculation of the TAR and the consequence occurrence rate parameters for a given country.

Starting from “Table a:” of Figure 5, safety engineers define a severity level for every accident case. This information allows for identifying the threshold of the accident case risk. (annotated with “T” in the figure.) The threshold risk identifies the upper limit of a tolerable risk. For instance, let us consider a Critical severity level. The corresponding threshold risk can be identified in the fourth row of the Critical column. This corresponds to the Undesirable risk level. The obtained threshold risk level can then be used to identify a corresponding threshold frequency of the accident case. In our example, such frequency level is Remote. This yields an input value for “Table b:”.

“Table b:” describes a mapping of frequencies of accident cases and numerical information about the magnitude order of such frequencies. This magnitude order is specified as an interval of real numbers. The lower bound value of this interval, corresponding to the threshold frequency level of a given accident case, represents the LIBRARY <<enumeration>>

SeverityKind Catastrophic Critical Marginal

Insignificant ACCIDENTS <<enumeration>> FrequencyKind Frequent Probable Occasional Remote Improbable Incredible <<enumeration>>

RiskKind Intolerable Undesiderable Tolerable

Negligeable <<import>> PARAMETERS <<apply>> (see fig. 5)

MARTE (subset) <<import>> (uml)

ACTOR <<stereotype>>

Hazard

<<stereotype>>

AccidentConsequences tolerableAccidentRate : THR severity: SeverityKind \automaticTolerableAccidentRate : THR \automaticOccurenceRate: FrequencyMagnitudoMap (uml)

UseCase <<stereotype>>

AccidentCase iD: Identification accidentType: AccidentTypeKind tolerableAccidentRate : TAR \a\utomaticTolerableAccidentRate : TAR

Fig. 4. SOPHIA: focus on TAR TAR value for this accident case. In Figure 5, the TAR value the studied accident case is 1x10-8.

Figure 6 shows the model representation of “Table a:”. In a:RiskTolerabilityAccident, each line of attribute RiskMapping represents a line of “Table a:”. Consider “Table a:”. We can read it as: we taken two values, one for colomn and one for row, then, we uniquely identify one cell, which contains the value of the risk. For example, for the colomn we select severity = critical and, for the row, frequency = Incredible Hence, we achieve a unique cell, which contains risk = N egligeable. The first line in Figure 6 represents the list of these attributes and their values. In instance a:RiskTolerabilityAccident, each line is given by the above procedure. In order to model the threshold between what is tolerable and what is undesiderable (noted by “T” in Figure 5), we introduce the Boolean attribute isThreshold in Figure 6. Therefore, if severity = critical, then risk = U ndesiderable, because isThreshold = T rue.

a:RiskTolerabilityAccident is an instance of class RiskTolerabilityAccident, which contains one attribute riskMapping of type RiskMappingType. We stereotype RiskMappingType with VSL::TupleType. As might be expected, the VSL package (which contains a set of stereotypes extending the data type of UML) is applied to some of the SOPHIA data types. By definition, a TupleType is a data type that combines different types into a single aggregated type [ 25 ]. This allows instances of these tuple types to be annotated as composite values following the textual syntax defined for VSL tuple specifications.

Similarly to Table “a:”, we represents “Table b:” by Figure 7, where some predefined MARTE data types are imported and reused in SOPHIA constructs. For instance, RealInterval (a MARTE’s data type stereotyped VSL::IntervalType) is typing the magnitudoOrder property of FrequencyMapType. This allows instances of IntervalType to 1 module DeriveImplementation ; 2 3 create TARGET : TARGETMETA from SOURCE : SOURCEMETA , CONFIG :

CONFIGMETA ; 17 18 ) to t : TARGETMETA ! Block mapsTo s ( name <− s . name , subsystemblockbody <− s . subsystemblockbody−>

select ( o ∣ o . isVisible ( ) ) , normalblockbody <− s . normalblockbody−>

select ( o ∣ o . isVisible ( ) ) , scopeblockbody <− s . scopeblockbody−>

select ( o ∣ o . isVisible ( ) )

Listing 2. DeriveImplementation.atl, transformation (6), excerpt. – The visibility functions determine whether instances of a certain meta-class will be copied. For instance, Block.isVisible() (see Listing 2, lines 5– 6) calculates this for each instance of Block. In the initial version of DeriveImplementation.atl which is automatically generated from the meta-model all visibility functions default to true. – In a second transformation, DeriveImplementationVisibility.atl Listing 3 these visibility functions are manually redefined. These functions access the product configuration and determine, which elements go into the product and which do not. Later on, these will be overloaded over the default visibility functions, by using ATL’s superimpose mechanisms.

The selective copying is controlled by the function s.isVisible() defined in DeriveImplementationVisibility.atl . This function reads the Application Feature Model a and decides how this influences the filtering of elements in the Domain Implementation Model.

For this decision to be made, it is necessary to know how the various features in the feature model ( d and a) are related to the corresponding elements in the Matlab / Simulink implementation model. 1 module DeriveArchitectureDetermineVisibility ; 2 3 create TARGET : TARGETMETA from SOURCE : SOURCEMETA , CONFIG :

CONFIGMETA ; 4 5 −− t r u e i f B l o c k i s r e f e r e n c e d by a s e l e c t e d f e a t u r e 6 helper context SOURCEMETA ! Block def : isSelected ( ) : Boolean = 7 [ . . ] 8 9 −− t r u e i f B l o c k i s r e f e r e n c e d by an e l i m i n a t e d f e a t u r e 10 helper context SOURCEMETA ! Block def : isDeselected ( ) : Boolean = 11 [ . . ] 12 13 helper context SOURCEMETA ! Block def : isVisible ( ) : Boolean = 14 if self . isSelected ( ) then 15 if self . isDeselected ( ) then 16 true . debug ( ’feature conflict for block’ + self . name ) 17 else 18 true 19 endif 20 else 21 if self . isDeselected ( ) then 22 false 23 else 24 true −− d e f a u l t t o v i s i b l e 25 endif 26 endif ; 27 [ . . ]

Listing 3. DeriveImplementationVisibility.atl, transformation (5), excerpt.

This is represented by the Mapping d between the Domain Feature Model d and the Domain Implementation Model Cd implemented as a model which contains as elements dependencies. These dependencies relate features and the corresponding implementation, with a link mechanisms available from the meta-model. Using this meta-model we are able to map a feature given in the configuration model to a block given in the implementation model.

To implement pruning operations we are currently experimenting with and implementing new user-defined methods. These methods will adopt the copy rules in such a way that the methods given in Section 5 are realized. These pruning operations are influenced by the configuration and the mapping of features. However, they affect model components which are only indirectly referenced by the mapping model.

Related Work Several projects deal with Product Derivation. The ConIPF project provides a methodology for product derivation [ 11 ]. ConIPF concentrates on the formalization of derivation knowledge into a configuration model. Deelstra et al. provide a conceptual framework for product derivation [ 12 ].

When dealing with variability in domain-specific languages a typical challenge is the mapping of features to their implementations. Here, Czarnecki and Antkiewicz [ 13 ] used a template-based approach where visibility conditions for model elements are described in OCL. In earlier work [ 14,15 ], we used mapping models and model transformations in ATL [ 16 ] to implement similar mappings. Heidenreich et al. [ 17 ] present FeatureMapper, a tool-supported approach which can map features to arbitrary EMFbased models [ 18 ].

Voelter and Groher [ 10 ] used aspect-oriented and model-driven techniques to implement product lines. Their approach is based on variability mechanisms in openArchitectureWare [ 19 ] (e.g., XVar and XWeave) and demonstrated with a sample SPL of home automation applications.

In earlier work [ 20,5 ], the authors have experimented with other mechanisms for negative variability (pure::variants Simulink connector [ 21 ] and openArchitectureWare’s Xvar mechanism [ 19 ]) to realize variability in Embedded Systems. The mechanisms were applied to microcontroller-based control systems and evaluated with a product line based on the Vemac Rapid Control Prototyping (RCP) system.

The approach presented here can be seen as an integration and extension of work from Weiland [ 22 ] and Kubica [ 23 ]. Both presented mechanisms to adopt Matlab / Simulink-models based on feature trees. Weiland implemented a tool which influences certain variability points in a Simulink model. However, variability mechanisms are not removed during variability resolution. The approach given by Kubica constructs a new Simulink model for a derived product.

Tisi et al. provide an literature review on higher-order transformations [ 24 ] including a classification of different types of HOT. Oldevik and Haugen [ 25 ] use higherorder transformations to implement variability in product lines. Wagelaar [ 26 ] reports on composition techniques for model transformations. 8

Conclusion In this paper we presented an approach to introduce and adopt variability in a modelbased domain specific language (Matlab / Simulink) for developing embedded systems.

With our approach we are able to simulate and test variable Simulink-models by introducing mechanisms to manage variability and additionally derive models which contains only the product specific components. This provides us with memory and computation time efficient models.

All model transformations were implemented in the ATLAS Transformation Language (ATL) [ 16 ]. The original version was developed with ATL 2.0. We are currently experimenting with ATL 3.0 and its improved support for higher-order transformations. Using this technique we are able to reuse previous work which implements the transformation from a domain specific language and a abstract variability mechanism. This approach is expanded by new methods to decided whether a feature is active and new domain specific methods are needed to adopt the implementation model. 9

Acknowledgements This work was supported, in part, by Science Foundation Ireland grant 03/CE2/I303 1 to Lero – the Irish Software Engineering Research Centre, http://www.lero.ie/. The higher-order transformation ( in the overview) was inspired by an ATL case study by Dennis Wagelaar. Model-Based Extension of AUTOSAR for

Architectural Online Reconfiguration

Basil Becker1, Holger Giese1, Stefan Neumann1,

Martin Schenck2 and Arian Treffer2 Hasso-Plattner-Institute at the University of Potsdam

Prof.-Dr.-Helmert-Str. 2-3 14482 Potsdam, Germany [e-mail] [e-mail] Abstract. In the last years innovations in the automotive domain have more and more been realized by software leading to a dramatically increased complexity of such systems. Additionally automotive systems have to be flexible and robust, e.g., to be able to deal with failures of sensors, actuators or other constituents of an automotive system. One possibility to achieve robustness and flexibility in automotive systems is the usage of reconfiguration capabilities. However, adding such capabilities introduces even higher degree of complexity. To avoid this drawback we propose to integrate reconfiguration capabilities into AUTOSAR, an existing framework supporting the management of such complex system at the architectural level. Elaborated and expensive tools and toolchains assist during the development of automotive systems. Hence we present how our reconfiguration solution has been seamlessly integrated into such a toolchain. 1 Today most innovations in the automotive domain are realized by software. This results in a dramatically increasing complexity of the developed software systems1. The objective of the AUTOSAR framework is to deal with this complexity at the architectural level. Additionally these systems need to deal with diverse situations concerning the context in which the software is operating. Such systems and especially the software, which is realizing essential functionalities of the overall system, need to be flexible to react on changes of its context. Regardless if such a system need to react on failures or on other contextual situations2, flexibility and robustness plays an important role in today’s automotive applications. 1 The complexity concerning the size of the developed software, the functionality realized by the software system and so on. 2 An example for such a situation, which is not related to a failure is in case the car is connected to diagnostic devices.

Reconfiguration is one possibility to facilitate the flexibility and robustness of such systems. There exist different possibilities to realize reconfiguration within automotive software. One is to realize reconfiguration mechanisms at the functional level. Because the AUTOSAR framework primarily provides mechanisms to deal with the complexity at the architectural level also the reconfiguration aspects should be available at the same level. Because deriving architectural information from the functional level could be difficult or even impossible we propose to specify reconfiguration aspects at the architectural level and to automatically derive the needed functionality based on the architectural information.

Further in a typical development scenario one has to deal with black-box components provided by third parties and elaborated information about the included functionality is not available, what also hampers the management of reconfiguration aspects at the functional level. Another possible solution is to introduce a new approach inherently facilitating reconfiguration aspects in the context of automotive systems. Today standard methods and tools already exist for supporting the development process of AUTOSAR. Because adapting existing tools or developing new once is very costly the propagation of such a new approach would be hardly suitable in practice. Summarizing we have identified the need for an development approach that is able to provide reconfiguration capabilities at the architectural level, can be seamlessly integrated into an exiting development solution and can also include third party components into the reconfigurable architecture. In this work we show how reconfiguration capabilities, which are currently not included in the existing AUTOSAR approach can be supported at the architectural level without degrading existing development solutions, tools or the standard itself. We further show how the needed functionality for realizing the reconfiguration logic can be automatically generated based on the architectural information describing the reconfiguration. The used application example for our evaluation is related to the field of fault tolerant systems and from our perspective such systems are one possible field to which reconfiguration like discussed in the remainder of this work can be applied.

The remainder of this paper is organized as follows. In Section 2 we discuss existing approaches supporting reconfiguration relevant for automotive systems and especially those approaches providing reconfiguration capabilities at the architectural level. In Section 3 we briefly introduce the existing toolchain, which builds the technological foundation for our investigation concerning the developed extension for on-line reconfiguration within the AUTOSAR framework. Subsequently in Section 4 we show how such a system is usually modeled with the given tools and how the additional reconfiguration aspects could be formulated based on the input/output of the existing toolchain. In Section 5 we show how these created additional reconfiguration aspects are automatically merged back into the original architecture and how the merged result fits into the existing tools without discarding or degrading parts of the original toolchain. Finally we give short discussion concerning the current results of our work in Section 6.

Related Work In several different areas of computer science ideas have been presented, which are related to the approach we are going to present in this paper. In the field of software product lines and especially dynamic software product lines the topic of variable software has been addressed. The software architecture community has presented some work on the reconfigurability of robotic systems. Work, tailored to the automotive domain, has been done in the DySCAS project. We did some research on self-optimizing mechatronic systems.

In previous work we have presented a modeling technique called Mechatronic UML (mUML), which is suitable for the modeling of reconfigurable and self-optimizing mechatronic systems [ 1, 2 ]. However, the mUML approach differs from the one, which will be presented in this paper, in the fact that mUML uses an own code generation mechanisms and thus could hardly be integrated into existing development tool chains.

In the DySCAS3 project dynamically self-configuring automotive systems have been studied [ 3, 4 ]. DySCAS does not provide a model based development approach, tailored to the specification of reconfiguration. Reconfiguration is specified with policy scripts, which are then evaluated by an engine at run-time (cf. [ 5 ]).

Software Product Line Engineering (SPLE) [ 6 ] aims at bringing the assembly line paradigm to software engineering. Typically a software product line is used to develop multiple variants of the same product. However, as the classical SPLE approach targets the design-time variability of software it is not comparable to the approach we are going to present in this paper. Recently a new research branch has emerged from SPLE called Dynamic Software Product Line Engineering [ 7 ]. In Dynamic Software Product Lines the decision, which variant to run, has moved from design- to run-time. Such an approach is presented in [ 8 ], where the authors describe a dynamic software product line, which is suitable for the reconfiguration of embedded systems. In contrast to our approach this one is restricted to the reconfiguration of pipe-and-filter architectures and the reconfiguration has to be given in a textual form.

In [ 9 ] a framework for the development of a reconfigurable robotic system has been presented. But the presented approach does in contrast to ours not support the model-driven development of reconfiguration. A policy-based reconfiguration mechanism is described in [ 10 ]. The authors present a powerful and expressive modeling notation for the specification of self-adaptive (i.e. reconfigurable) systems but their approach requires too much computational power and is thus only remotely applicable to embedded systems. In [ 11 ] an approach based on mode automata has been presented. However, mode automata only support switching between different behaviors internal to a component and do not cover architectural reconfiguration. For the development of embedded systems – especially in the automotive domain – several tools exist that provide capabilities for model-based development of such systems. Tools used by companies typically are mature, provide reliable and optimized code generation mechanisms and are as expensive as complex. Hence, any technique that claims being usable in the domain of embedded / automotive systems must be integrated into the existing toolchain. We will use this section to exemplary describe a toolchain, which might be used in the context of the AUTOSAR domain specific language. 3.1

AUTOSAR The AUtomotive Open System ARchitecture (AUTOSAR) is a framework for the development of complex electronic automotive systems. AUTOSAR provides a layered software architecture consisting of the Application layer, the Runtime Environment and the Basic Software layer. Figure 14 shows the different layer of the architecture. The Basic Software layer provides services concerning HW access, communication and Operating System (OS) functionality (cf. [ 12 ]). The Basic Software provides several interfaces in a standardized form to allow the interaction between the Basic Software layer and the application layer routed through the Runtime Environment. The Runtime Environment handles the communication between different constituents of the application layer and between the application layer and the Basic Software layer (e.g., for accessing Hardware via the Basic Software, cf. [ 13 ]). The Application layer consists of Software Components, which can be hierarchically structured and composed to so called Compositions. Software Components and Compositions can have ports and these ports can be connected via Connectors (see [ 14 ] for more details). The real communication is realized through the Runtime Environment in case of local communication between Software Components (Compositions) on the same node (Electronic Control Unit) or through the Runtime Environment in combination with the Basic Software in case of communication between different nodes.

The main focus of AUTOSAR is the modeling of architectural aspects and of structural aspects. The behavior modeling (e.g., needed control functionality for reading sensor values and setting actuators) is not the main focus of the AUTOSAR framework. For modeling such behavior existing approaches and tools can be integrated into the development process of AUTOSAR. One commonly used tool for the model based development of behavior is MATLAB/Simulink (like described in Section 3.2). For executing such functionality AUTOSAR provides the concept of Runnables, which are added as a part of the internal behavior of a Software Component. Developed functionality could be mapped to Runnables and these Runnables are mapped to OS tasks. Additionally events 4 Picture taken from components-and-inte.jpg.

http://www.autosar.org/gfx/media pictures/AUTOSARcan be used to decide inside an OS task if specific runnables are executed at runtime (e.g., runnables could be triggered by events if new data has been received via a port of the surrounding Software Component). For more details about the OS provided by the AUTOSAR framework see [ 15 ].

Once the modeling and configuration is done, in the current release version of AUTOSAR5 changes at run-time concerning the structure of the application layer (e.g., restructuring connectors) are not facilitated by the framework. The scheme in Figure 2(a) shows one possible toolchain for the development of AUTOSAR systems. Rectangles with rounded corners represent programs, rectangles with cogwheels stand for processes. The arrows indicate exchange of documents, the type of the document (i.e. models, C-code or parameters) is annotated to the arrows. The system’s architecture (i.e. components, ports and connectors) is modeled in SystemDesk6. Together with the architecture SystemDesk also supports the modeling of the system’s deployment to several ECUs. The components behavior is specified using Matlab with the extension Simulink. For Matlab/Simulink (ML/SL) special AUTOSAR block sets exist, which allow the import of components specified in SystemDesk into Matlab and following the development of the component’s functionality.

Further SystemDesk supports the generation of optimized C-Code, which conforms to the AUTOSAR standard concerning the Runtime Environment (cf. Subsection 3.1). Together with the C implementation of the software components modeled in SystemDesk the generated output also contains a configuration for the basic software layer. This layer is generated from specialized tools (e.g. Tresos 5 Release 3.1 6 http://www.dspace.de (a) Exemplary toolchain for development (b) Tool chain for modeling reconfigurable with AUTOSAR AUTOSAR architectures Fig. 2. The current and the extended toolchain for the development with AUTOSAR by ElectroBit, abbreviated as BSW-C/G in Figure 2) and is specific to the system modeled in SystemDesk and the available hardware.

At the integration step a build environment compiles the generated C-Code and builds the software running on each ECU. The used application example for showing the reconfiguration capabilities that are supplemented to the existing AUTOSAR framework in our approach is the reconfiguration of a set of adjacent aligned distance sensors. The discussed evaluation example allows reacting on sensor failures in the manner that the failure of individual sensor instances is compensated.7

Such adjacent aligned sensors are commonly used in a modern car, e.g., in case of a parking distance control. Such a parking distance control uses sensors (e.g., ultrasonic sensors) embedded in the front or rear bumper for measuring the distance to nearby obstacles.

Additionally in Section 5.3 we discuss the evaluation results of experiments we have made on an evaluation platform using the techniques described in Section 4. 4

Modeling Reconfiguration In order to make an AUTOSAR system architecture reconfigurable, some additional concepts are needed. The toolchain needs to be extended in a certain way that extensions do not make the existing toolchain invalid. From our perspective the best way is to integrate an optional tool that can be plugged into the existing toolchain. 7 For our application example we assume that a sensor failure can be observed at the level of Software Components. 4.1

Extended Toolchain Our modeling approach is currently restricted to the modeling of AUTOSAR software architectures. The toolchain in Figure 2(b) shows our approach of extending the existing toolchain by another tool without degrading existing ones. By using this proposal the developer is free to choose, whether he wants to use our given enhancement or not. He can either model an architecture, that does not provide any reconfiguration or he can use our tool in addition and empower himself to specify and realize reconfiguration aspects. The advantages are obvious: better control and overview due to the diagrammatic depiction.

SystemDesk SystemDesk is a tool provided by dSPACE 8 supporting the modeling of AUTOSAR conform systems. Among other things it supports the modeling of the AUTOSAR HW and SW architectures. For modeling the SW architecture Software Components, compositions as well as ports, interfaces and connectors are provided as modeling artifacts. These artifacts can be used to describe the architectural aspects of a concrete SW architecture for a specific system like shown in Figure 3.9 Besides modeling the architecture in SystemDesk, the tool also allows the linking of the Software Components to their behavior, written in C-Code or given in form of MATLAB/Simulink models.

Additionally the HW architecture including the used types of ECUs (Electronic Control Unit), the deployment of Software Components to these ECUs as well as additional information concerning the configuration (e.g., configuration concerning communication and the OS) can be specified. Based on this information SystemDesk automatically generates code, which can be compiled for the specified platform. Besides the code for the application layer SystemDesk also generates source code realizing the Runtime Environment functionality.

Figure 3 shows the relevant part of the SW architecture concerning our application example modeled in SystemDesk. Like depicted on the right side of Figure 3 the composition consists of four Software Components representing the distance sensors10 connected to another composition SensorLogic evaluating the sensor values to a single value provided by the port ShowDistanceOut.11

The above mentioned elements (Software Components, ports and connectors) are used to describe the software when no reconfiguration is intended. Some additional elements shown in Figure 3 are described in more detail in the following section. These elements (Interpolation, Reconfiguration and the unused ports of the sensors) are used later to realize the reconfiguration functionality. 8 www.dspace.de 9 For the realization of control functionality other constituents can be imported into SystemDesk, e.g. in form of C-Code or Matlab/Simulink models, to realize the implementation of internal behavior of Software Components. 10 The ports accessing the HW via the Runtime Environment and Basic Software are not shown here because they are not object of reconfiguration. 11 To allow a better understanding SensorLogic calculates a single output value based on the different input values. Potentially also several output values can be computed.

Fig. 3. Configuration in SystemDesk dTool The usual modeling procedure is not altered until the modeling in SystemDesk12 is initially done like described above. After the model from SystemDesk is exported in form of an XML file13 and loaded into the dTool the constituents concerning the reconfiguration could be specified. Using the dTool we are now able to model two different aspects, relevant for the reconfiguration. On the one hand our tool allows creating new configurations, which differ from the initial one. Such differences are alternative connections (in form of connectors) between components and/or compositions. Which parts of the architecture are relevant concerning reconfiguration is indicated by the Software Component Reconfiguration included in the original SystemDesk model. Alternatively the dTool allows to manually choosing relevant parts of the imported architecture. On the other hand our dTool allows to model an automaton, which specifies how to switch between the modeled configurations.

Figure 4(a) depicts the configuration (modeled in the dTool) associated with the state that sensor two is broken. In the shown configuration the value of the port DistanceOut from the broken sensor Sensor 2 is not available. Consequently the value sent to the port Distance 2 In of the composition SensorLogic is interpolated from the to sensor values of the first and the third sensor via the additional composition Interpolation.

Figure 4(b) shows the configuration associated with the state that sensor four is broken and the value sent to the port Distance 3 In of the composition SensorLogic is interpolated based on the sensor values of the second and the fourth sensor. 12 http://www.dspace.de/ww/en/ltd/home/products/sw/system architecture

software/systemdesk.cfm 13 The AUTOSAR framework specifies XML-Schemes for exchanging AUTOSAR models in a standardized form. (a) Configuration in case Sensor 2 is bro- (b) Configuration in case Sensor 3 is broken ken

Fig. 4. Two configurations of the architecture for two different scenarios

The composition Interpolation used here provides some functionality for interpolating two different sensor values. This functionality has been added specifically for our application example.14 This interpolation functionality is used to approximate the value of a broken sensor based on the values of two adjacent sensors. It is potentially possible to integrate this functionality into an existing Software Component, but for a better understanding, we decided to introduce a new Software Component for this purpose.

The second part, which could be modeled in the dTool relevant for the reconfiguration is the automaton shown in Figure 5 specifying how to switch between different configurations. The automaton consist of the initial state initial, where all four sensors work correctly, the state sensor2broke where the second sensor is broken, the state sensor3broke where the third sensor is broken and state allfail where the first or the fourth sensor or more than one sensor is broken. Transitions between these states specify which reconfiguration is applied at runtime. The transitions are further augmented with guards. These guards are expressions over the values provided by components within the reconfigurable composition, which provide information relevant for the reconfiguration (in our case these information are provided via the Status-ports of the four Sensor-Software Components). An example for such a guard is shown at the transition from state initial to state sensor2broke requiring that the status port of the Software Component Sensor 2 provides the value 0 (indicating a broken sensor).

For the application example we assume that such status ports of the Software Components representing the sensors exist as we otherwise were not able to observe each sensors’ status.15 14 In our application example this functionality has been realized using Matlab/Simulink. 15 Alternatively an observer could be realized in form of an additional Software Component evaluating the sensor values over time and providing the status ports. If the 5

Merge In its current version the AUTOSAR standard does not support reconfiguration as a first class modeling element. Thus, SystemDesk also does not support modeling of diagrams that represent different variations of one composition. Hence the direct import of the reconfiguration, we have modeled in the dTool, is impossible. Nevertheless we want to make use of SystemDesk’s elaborated and AUTOSAR standard conform code generation capabilities. We had to find a way to translate the reconfiguration behavior into a SystemDesk/AUTOSAR model. This is done by merging all configurations to one final model. In the final model, the reconfiguration logic will be encapsulated by two components, the RoutingComponent and the StateManager. 5.1

Merging configurations Our modeling approach only allows the reconfiguration of connections between components but is not suitable for the addition and removal of components at run-time16. Hence, a merged configuration consists of all components, which have been modeled in SystemDesk at the early stages (cf. Subsection 4.1). Connections, which do not exist in all configurations, are redirected via a special component, called RoutingComponent. Therefore, the first step is to build the intersection of all configurations. Connections found here are directly inserted into the merged model. Next the RoutingComponent is added.

Generating the RoutingComponent The RoutingComponent intersects every connection, which is not invariant to the reconfigurable composition. Followmeasured values of consecutive points in time repeatedly have improper values (too big differences) a malfunction can be deduced. 16 Please note that the dTool allows to modeling configurations, which do not contain all components. The semantic is that the components are hidden, a dynamic loading of components is not supported by AUTOSAR. ing the RoutingComponent has to know at each point in time, which configuration is currently the active one. Which configuration is active, is determined by the evaluation of the current configuration and the valuation of the variables used in the guards of the reconfiguration automaton (cf. Figure 5). As an evaluation of the automaton at each point in time a value is sent to the RoutingComponent, is much too expensive we have implemented a different strategy.

Listing 1. Excerpt of the RoutingComponent’s code

The configurations modeled in the dTool get a unique number each. The RoutingComponent receives the number of the currently active configuration via a special input port. Using this information the RoutingComponent can be implemented as a sequence of switch statements. The computation of the current active configuration is done in a second component – the StateManager. The dTool automatically generates a runnable for the RoutingComponent containing the described behavior. An excerpt of the RoutingComponent’s implementation is shown in Listing 1. The variables configuration 0 and distance 1 hold the values of the current configuration and the second sensor’s distance respectively. The excerpt is responsible for routing the value provided by the second distance sensor. In configuration allfail (cf. line 44) and sensor2broke (cf. line 47) no routing takes place. In the initial configuration the sensor’s distance value is simply forwarded (cf. line 41) and in case the third distance sensor broke down, the value is forwarded as in initial (cf. line 51) but it is also sent to the Interpolation component (cf. line 52).

StateManager The StateManager – as briefly mentioned above – is responsible for the computation of the currently active configuration. Therefore, it has to be connected with all ports that provide values, which are used in the guards of reconfiguration automaton. Each time the StateManager receives an update on its ports, it has to evaluate the automaton again and change the value of the currently active configuration accordingly. 55 56 57 58 59 60

} break ; 49 c o n f i g u r a t i o n 0 = R t e I r v R e a d c o n f i g u r a t i o n ( ) ; 50 switch ( c o n f i g u r a t i o n 0 ) { 51 // S t a t e change l o g i c f o r c o n f i g u r a t i o n 52 // i n i t i a l 53 case 0 : 54 // T r a n s i t i o n t o CGConfiguration#s e n s o r 2 b r o k e ( i d : 1 ,

name : s e n s o r 2 b r o k e ) i f ( S t a t u s S e n s o r 2 1 0 == 0 ) { c o n f i g u r a t i o n 0 = 1 ; R t e I r v W r i t e c o n f i g u r a t i o n ( c o n f i g u r a t i o n 0 ) ;

R t e I W r i t e c o n f o u t c o n f i g u r a t i o n ( c o n f i g u r a t i o n 0 ) ;

Listing 2. Excerpt from the StateManager’s implementation

Updates to the StateManager’s ports are signaled by events, which then trigger the StateManager’s evaluation function.17 A small part of this evaluation function is shown in Listing 2. At line 49 of the listing the currently active configuration is read, which then is used as input for the switch statement in the following line. In case the second distance sensor is broken (identified by StatusSensor2 10 equals zero) the configuration is changed (cf. line 56). Then the changed configuration is written to the StateManager’s internal configuration variable (cf. line 57) and provided to other components through the conf out port (cf. line 58).18 5.2

Final SystemDesk project Figure 6 shows the Sensor-Composition after exporting the merged model to SystemDesk again. The components for the distance sensors are all connected to the RoutingComponent, which is named Reconf in this diagram. The system modeled in our application example does not allow an interpolation for the sensor components one and four. Following these components are always directly connected with the SensorLogic component and are not handled by the RoutingComponent. Nevertheless they also have to be connected to the RoutingComponent as the sensor values are used to interpolate the second respective third sensor in case of a failure.

The StateManager is depicted below the RoutingComponent and is connected to the RoutingComponent through the Conf ports, which provide information about the currently active configuration. As defined in the reconfiguration automaton (cf. Figure 5) the decision which configuration to use, depends on the values of the sensor components’ status ports. Following the StateManager is connected to those ports. As the reconfiguration automaton does not 17 Event mechanisms in form Runtime Environment events provided by the AUTOSAR framework have been used to trigger the runnable realizing the functionality of the StateManager. More information about Runtime Environment events can be found in [ 13 ].

18 E.g., provided to the RoutingComponent. rely on any values provided by the Interpolation or SensorLogic component the StateManager is not connected with them. 5.3 The above described approach for the modeling and realization of reconfiguration aspects has been evaluated within a project arranged at Hasso-Plattner-Institute in collaboration with the dSPACE GmbH.

As an evaluation platform for the shown approach the Robotino robot19 has been used, which provides an open platform for running C/C++ programs (among others) on a Real-Time Operating System (RTOS). The RTOS is provided in form of RTAI20, which is a real-time extension for the Linux operating system. To be able to evaluate the developed concepts on this platform an execution environment has been realized based on the existing RTAI Linux, which allows to compile and execute the outcome of the above described extended toolchain including the resulting parts of the reconfiguration functionality.

The robot provides nine distance sensors uniformly distributed around its chassis. In the context of our evaluation experiments we modeled the reconfig19 http://www.festo-didactic.com/int-en/news/learning-with-robots.htm 20 For more details see https://www.rtai.org. uration of distance sensors accordingly to the above used evaluation example using nine instead of four sensors.21

The generated source code of the different tools has been compiled and executed on the platform to show the applicability of our approach. In addition we analyzed the overhead resulting from the reconfiguration functionality added by our approach in comparison to the original functionality without any reconfiguration capabilities. For this purpose we measured the execution time of the generated reconfiguration automaton included in the added StateManager in combination with the parts resulting from the routing functionality realized in the additional RoutingComponent (both components are shown in Figure 6).

In case of the nine sensors provided by the robot we measured execution times of the relevant parts concerning the reconfiguration functionality between 20 and 100 microseconds depending on the type of reconfiguration (react on the defect of one or several sensors at the same point in time). The tests have been realized on the equivalent execution platform on which the real functionality has been executed when running the application example on the robot.22 While the robot provides a more powerful processor like it is the case for the most Electronic-Control-Units (ECUs) used within a modern car, even by using a platform or processor, which has only a tenth of the computation power we will not reach an overhead concerning the reconfiguration leading to an execution time much greater than one millisecond.

Conclusion In this paper we have presented an approach to extend AUTOSAR architectures with reconfiguration capabilities. The approach fits into existing toolchains for the development of AUTOSAR systems and allows reusing tools, which where currently used. The overhead added to the resulting reconfigurable architecture has been shown to be minimal but the developer rewards an easier development of reconfiguration logic, which otherwise has to be done manually at the functional / implementation level. We have successfully shown that it is possible to use high-level architectural modeling techniques without generating massive run-time overhead.

Although our approach has only been evaluated in the context of AUTOSAR it should be applicable to almost any component based development approach.

For the future we plan to also support the reconfiguration of distributed compositions. From an architectural point of view a distributed composition does not differ from a local one, as AUTOSAR completely hides the communication details in the Runtime Environment-layer from perspective of the application layer. Anyway, a distributed scenario contains enough challenges such as timing delays, Basic Software configuration, deployment decisions concerning RoutingComponents, just to name a few. Further the high-level architectural modeling 21 For a better understanding we decided to only show four sensors in the previous sections.

22 The robot is equipped with 300 MHz processor. we have introduced in this paper also allows the verification of the modeled systems. First attempts in these directions have been very promising and we are looking forward to look into the details.

Acknowledgment We thank the dSPACE GmbH and especially Dirk Stichling and Petra Nawratil for their support in setting up the project. We want to thank the participants of the student project “A run-time environment for reconfigurable automotive software” : Christian Lu¨ck, Johannnes Dyck, Matthias Richly, Nico Rehwaldt, Thomas Beyhl, Thomas Schulz and Robert Gurol.

References

References

1. Clements , P. , Northrop , L.M. : Software Product Lines: Practices and Patterns. The SEI series in software engineering . Addison-Wesley, Boston, MA, USA ( 2002 )

2. Pohl , K. , Boeckle , G., van der Linden , F.: Software Product Line Engineering : Foundations, Principles, and Techniques. Springer, New York, NY ( 2005 )

3. Beuche , D. , Weiland , J.: Managing flexibility: Modeling binding-times in simulink . [ 27 ] 289 - 300

4. Eclipse-Foundation : Xtext http://www.eclipse.org/Xtext/.

5. Polzer , A. , Botterweck , G. , Wangerin , I. , Kowalewski , S. : Variabilitt im modellbasierten engineering von eingebetteten systemen . In: 7. Workshop Automotive Software Engineering, collocated with Informatik 2009 , Luebeck, Germany ( September 2009 )

6. Botterweck , G. , Polzer , A. , Kowalewski , S.: Interactive configuration of embedded systems product lines . In: International Workshop on Model-driven Approaches in Product Line Engineering ( MAPLE 2009), colocated with the 12th International Software Product Line Conference (SPLC 2008 ). ( 2009 )

7. Kang , K. , Cohen , S. , Hess , J. , Novak , W. , Peterson , S. : Feature oriented domain analysis (FODA) feasibility study . SEI Technical Report CMU/SEI-90-TR-21 , ADA 235785, Software Engineering Institute ( 1990 )

8. Czarnecki , K. , Eisenecker , U.W.: Generative Programming . Addison Wesley , Reading, MA, USA ( 2000 )

9. Schobbens , P.Y., Heymans , P. , Trigaux , J.C. : Feature diagrams: A survey and a formal semantics . In: Requirements Engineering Conference, 2006 . RE 2006 . 14th IEEE International. ( 2006 ) 136 - 145

10. Voelter , M. , Groher , I. : Product line implementation using aspect-oriented and model-driven software development . In: 11th International Software Product Line Conference (SPLC 2007 ), Kyoto, Japan ( September 2007 )

11. Hotz , L. , Wolter , K. , Krebs , T. , Nijhuis , J. , Deelstra , S. , Sinnema , M. , MacGregor , J.: Configuration in Industrial Product Families - The ConIPF Methodology . IOS Press ( 2006 )

12. Deelstra , S. , Sinnema , M. , Bosch , J.: Product derivation in software product families: a case study . The Journal of Systems and Software 74 ( 2005 ) 173 - 194

13. Czarnecki , K. , Antkiewicz , M. : Mapping features to models: A template approach based on superimposed variants . In: GPCE'05 , Tallinn, Estonia (September 29 - October 1 2005 )

14. Botterweck , G. , Lee , K. , Thiel , S. : Automating product derivation in software product line engineering . In: Proceedings of Software Engineering 2009 ( SE09 ), Kaiserslautern, Germany (March 2009 )

15. Botterweck , G., O 'Brien , L. , Thiel , S. : Model-driven derivation of product architectures . In: Proceedings of the twenty-second IEEE/ACM international conference on Automated software engineering (ASE 2007 ), Atlanta, GA , USA ( 2007 ) 469 - 472

16. Eclipse-Foundation: ATL (ATLAS Transformation Language ) http://www.eclipse. org/m2m/atl/.

17. Heidenreich , F. , Kopcsek , J. , Wende , C. : Featuremapper: Mapping features to models . In: ICSE Companion '08: Companion of the 13th international conference on Software engineering , New York, NY, USA, ACM ( 2008 ) 943 - 944

18. Eclipse-Foundation: EMF - Eclipse Modelling Framework http://www.eclipse. org/modeling/emf/.

19. openarchitectureware.org: Official open architecture ware homepage http://www. openarchitectureware.org/.

20. Polzer , A. , Kowalewski , S. , Botterweck , G.: Applying software product line techniques in model-based embedded systems engineering . In: 6th International Workshop on Modelbased Methodologies for Pervasive and Embedded Software (MOMPES 2009 ), Workshop at the 31st International Conference on Software Engineering (ICSE 2009 ), Vancouver, Canada (May 2009 )

21. Pure::systems: pure::variants Connector for Simulink http://www.mathworks.com/ products/connections/product_main.html?prod_id= 732 .

22. Weiland , J. , Richter , E. : Konfigurationsmanagement variantenreicher simulink-modelle . In: Informatik 2005 - Informatik LIVE !, Band 2, Koellen Druck +Verlag GmbH, Bonn ( September 2005 )

23. Kubica , S. : Variantenmanagement modellbasierter Funktionssoftware mit SoftwareProduktlinien . PhD thesis , Universita¨t Erlangen-Nu¨rnberg, Institut fu¨r Informatik ( 2007 ) Arbeitsberichte des Instituts fu¨r Informatik, Friedrich-Alexander-Universita¨t Erlangen Nu¨rnberg.

24. Tisi , M. , Jouault , F. , Fraternali , P. , Ceri , S. , Be´zivin, J.: On the use of higher-order model transformations . [ 27 ] 18 - 33

25. Oldevik , J. , Haugen , O. : Higher-order transformations for product lines . In: 11th International Software Product Line Conference (SPLC 2007 ), Washington, DC, USA, IEEE Computer Society ( 2007 ) 243 - 254

26. Wagelaar , D. : Composition techniques for rule-based model transformation languages . In Vallecillo, A. , Gray , J. , Pierantonio , A., eds. : ICMT . Volume 5063 of Lecture Notes in Computer Science., Springer ( 2008 ) 152 - 167

27. Paige , R.F. , Hartman , A. , Rensink , A., eds.: Model Driven Architecture - Foundations and Applications , 5th European Conference, ECMDA-FA 2009 , Enschede, The Netherlands , June 23-26, 2009 . Proceedings. In Paige, R.F., Hartman , A. , Rensink , A., eds. : ECMDAFA . Volume 5562 of Lecture Notes in Computer Science., Springer ( 2009 )

1. Burmester , S. , Giese , H. , Mu¨nch, E., Oberschelp , O. , Klein , F. , Scheideler , P. : Tool Support for the Design of Self-Optimizing Mechatronic Multi-Agent Systems . International Journal on Software Tools for Technology Transfer 10 ( 3 ) ( 2008 ) 207 - 222

2. Giese , H. , Burmester , S. , Sch¨afer, W., Oberschelp , O. : Modular design and verification of component-based mechatronic systems with online-reconfiguration . In: Proc. SIGSOFT '04/FSE-12 , New York, NY, USA, ACM Press ( 2004 ) 179 - 188

3. Feng , L. , Chen , D., T¨orngren, M.: Self configuration of dependent tasks for dynamically reconfigurable automotive embedded systems . In: Proc. of 47th IEEE Conference on Decision and Control . ( 2008 ) 3737 - 3742

4. Anthony , R. , Ekeling , C. : Policy-driven self-management for an automotive middleware . In: HotAC II: Hot Topics in Autonomic Computing on Hot Topics in Autonomic Computing , Berkeley, CA, USA, USENIX Association ( 2007 )

5. DySCAS Project : Guidelines and Examples on Algorithm and Policy Design in the DySCAS Middleware System , Deliverable D2 .3 Part III. ( February 2009 ) Available online: http://www.dyscas.org/doc/DySCAS D2. 3 part III.pdf .

6. Pohl , K. , B¨ockl, G., van der Linden , F.: Software Product Line Engineering . Foundations, Principles, and Techniques. Springer, Berlin Heidelberg New York ( 2005 )

7. Hallsteinsen , S. , Hinchey , M. , Park , S. , Schmid , K. : Dynamic Software Product Lines . Computer 41 ( 4 ) ( 2008 ) 93 - 95

8. Kim , M. , Jeong , J. , Park , S. : From product lines to self-managed systems: an architecture-based runtime reconfiguration framework . In: DEAS ””05: Proc. of the 2005 workshop on Design and evolution of autonomic application software , New York, NY, USA, ACM ( 2005 ) 1 - 7

9. Kim , D. , Park , S. , Jin , Y. , Chang , H. , Park , Y.S. , Ko , I.Y. , Lee , K. , Lee , J. , Park , Y.C. , Lee , S.: SHAGE: a framework for self-managed robot software . In: Proc. SEAMS '06 , Shanghai, China, ACM ( 2006 ) 79 - 85

10. Georgas , J.C. , Taylor , R.N.: Policy-based self-adaptive architectures: a feasibility study in the robotics domain . In: Proc. SEAMS '08 , New York, NY, USA, ACM ( 2008 ) 105 - 112

11. Talpin , J.P. , Brunette , C. , Gautier , T. , Gamati´e, A.: Polychronous mode automata . In: EMSOFT '06: Proc. of the 6th ACM & IEEE International conference on Embedded software , New York, NY, USA, ACM ( 2006 ) 83 - 92

12. AUTOSAR GbR: List of Basic Software Modules. Version 1.3.0.

13. AUTOSAR GbR: Specification of RTE. Version 2.1.0.

14. AUTOSAR GbR: Specification of the Virtual Functional Bus . ( 2008 ) Version 1 .0.2.

15. AUTOSAR GbR: Specification of Operating System . (2009) Version 3.1.1.