A Model-driven Approach for Validating Safe Adaptive ...

A Model-driven Approach for Validating Safe Adaptive Behaviors Mahmoud Hussein1,3, Reda Nouacer2, Ansgar Radermacher1 1

CEA, LIST, Laboratory of Model Driven Engineering for Embedded Systems, 2 CEA, LIST, Software Reliability and Security Laboratory P.C. 174, Gif-sur-Yvette, 91191, France 3 Faculty of Computers and Information, Menofia University, Egypt

{mahmoud.hussein, reda.nouacer, and ansgar.radermacher}@cea.fr, [email protected]

Abstract- Adaptive embedded software systems have the ability to adapt themselves in response to hardware/software failures at runtime. However, ensuring safe adaptive behaviors of these systems is a major challenge. In this paper, we propose an approach to facilitate the validation of such adaptive behaviors. To do so, an architecture description language for automotive embedded systems (EAST-ADL) is used for designing the software. The system design model is then used for generating the embedded software. To ensure that the system behaves correctly at runtime, its adaptive behavior is analyzed using fault injection and monitoring techniques on a virtual platform. This work is part of the European project SafeAdapt, which provides a novel architecture for adaptive systems in the automotive domain. It also describes a particular aspect, virtual validation, in the evolution of the EQUITAS project. Keywords- Adaptive Software Systems; Model-driven Development; Safety; Virtual Platform

I.

INTRODUCTION

It is largely recognized that the architectures of embedded systems are becoming more and more complex both at hardware and software levels. Thanks to the constant advances in microelectronic, embedded system engineers are now able to integrate more system functions on a powerful System-onChips (SoCs) [1]. The automotive industry also benefits from these advances in microelectronics and the engineers are now able to integrate advanced vehicle functions on high performance electronic control units (ECUs). Due to the integration level, the clock frequency and the functioning conditions (e.g. temperature, magnetic fields, etc.), the circuit failure rate increases by approximately √2 in an eighteen month period [2]. Therefore, the issue of robustness and reliability becomes crucial in the design phase. The promising advent of Fully Electric Vehicles (FEVs) also means a shift towards fully electrical control of the existing and new vehicle functions. In particular, critical X-bywire functions require sophisticated redundancy solutions. As a result, the overall Electric/Electronic (E/E) architecture of a vehicle is becoming even more complex and costly [3] [4]. The main idea of SafeAdapt project is to develop novel architecture concepts based on adaptation to address the need of a new architecture for fully electric vehicles regarding safety, reliability and cost-efficiency [5] [6]. This will reduce This work was partially supported by the European Commission within the 7th Framework Program as part of the SafeAdapt project under grant number 608945.

the system complexity and the interactions by generic, systemwide fault and adaptation handling. It also enables extended reliability despite failures, improvements of active safety, and optimized resources. This is especially important for increasing reliability and efficiency regarding energy consumption, cost, and design simplicity. In this paper, we propose an approach to facilitate the validation of the adaptive behavior of embedded software. For the validation, we follow a model-driven approach. Modeldriven development (MDD) is the notion of constructing a model of a system that can be transformed to a real system [7]. Therefore, we have used EAST-ADL (an architecture description language for automotive embedded systems) for creating the system design model which captures the system functionality and its adaptive behavior. The design model is then used for generating the embedded software. To ensure that the system is going to behave correctly during its execution, the system adaptive behavior is analyzed using a virtual platform (i.e. UNISIM-VP [8]). To simulate a faulty system state and to ensure that the system has the ability to cope with this fault, we use simulation fault injection (i.e. robustness study) [9]. The remainder of the paper is organized as follows. In Section II, we give a short description of the related works. The main parts of the SafeAdapt project are explained in Section III. Our approach for modelling an embedded software system and its adaptive behavior are described in Section IV. In Section V, we focus on the validation of the system adaptive behavior. Finally, we conclude the paper in Section VI. II.

RELATED WORKS

The work introduced in this paper is related to two research areas: adaptive software systems and virtual validation. Thus, in this section, we discuss the related works from both angels. A. Adaptive Software Systems Adaptation is a technique to increase the reliability of highly safety-relevant applications that run without mechanical fall back solutions. The FP7 project ACTORS [10] (Adaptivity and Control of Resources in Embedded Systems) addressed the design of complex embedded systems. It also aimed to provide an adaptive resource management during runtime based on feedback control loop. However, the adaptation of the entire networked embedded system is not considered in this project.

In order to increase the reliability of FEVs, the HEMIS (electrical powertrain Health Monitoring for Increased Safety in FEVs) project developed a prognostic health monitoring system which monitors the electric powertrain of the vehicle and provides a failsafe state [11]. Since this project provides a specific approach to increase the reliability and availability of electric power-train functionality, SafeAdapt project aims to provide a generic failure handling mechanism for any kind of electronic or software controlled functions in FEVs. Such novel features need reconfiguration techniques on top of realtime capable communication networks such as CAN, FlexRay and TTEthernet in automotive domain [12]. DySCAS (Dynamically Self Configuring Automotive Systems) project, which was funded by the European commission (FP6), focused on dynamic reconfiguration in automobiles and proposed a middleware supporting dynamic reconfiguration and context awareness [13]. Another project focusing on dynamic systems is iLand (mIddLewAre for deterministic dynamically reconfigurable NetworkeD embedded systems) [14]. It aimed at improving the system flexibility, scalability, and composability by developing a modular component-based middleware for deterministic dynamic functional composition and reconfiguration. The IPAC (Integrated Platform for Autonomic Computing) project developed a novel embedded middleware and service provision platform that brings considerable intelligence to devices [15]. The POLLUX project investigated and developed architectural concepts for e-vehicles. However, POLLUX did not consider runtime adaptation/reconfiguration in automotive E/E architectures as required for safety-relevant applications where redundancy concepts are needed [16]. Siemens developed an integrated and open ECU platform with sophisticated redundancy concepts within the RACE (Robust and Reliable System Architecture for Future eCars) project [17]. RACE is a German national research project, funded by the German ministry of economics and technology. The goal was to develop a uniform and open platform for safety-critical functions. Fail-operational behavior is achieved by dual-duplex architecture (i.e. two fail-silent nodes being composed to a fail-operational platform). Additional features are a clear “layering” (sensor/actor level, vehicle data level, function level) and the support for extensibility with new components and functions at runtime. Out of this project scope is standardization (e.g. towards AUTOSAR). All the projects on adaptation and reconfiguration aimed to develop novel middleware-based approaches. Thus, they are not compliant to the current standards in the automotive domain (e.g. AUTOSAR or ISO 26262). Moreover, none of these projects addressed the special issues of safety-relevant applications in the e-vehicles domain. B. Virtual Validation The use of virtual platforms (VP) in both hardware and software development allows mastering the complexity of applications, meeting the production deadlines, parallelization of hardware/software development, anticipation of integration, and in particular the detection and continuous rise of inconsistencies and specification errors [18] [19].

Embedded system designer needs tools that allow studying the impact of hardware faults on the behavior of the embedded software. A large number of techniques have been developed for injecting faults into a system prototype or a model. There are four main fault injections categories: hardware-based [20], software-based [20], simulation-based [9] [21], and emulationbased [22]. As part of the project EQUITAS [23], we have proposed the approach in [9], described hereafter, that takes as inputs the application, the target hardware, and the system requirements. We have defined and implemented the following services in the simulation environment UNISIM-VP: 1) Fault Quantification. A physical model of the fault is defined through studying the architectural features of the target hardware and a number of parameters/phenomena associated with it. This model calculates the probability of the fault occurrence. 2) Fault Injection. Once the fault model is defined, the test scenarios base is instrumented in order to fix the relevant injection points for the current use case. These injection points will serve as triggers during the scenario execution to inject hardware faults. 3) Traces Analysis. Two timestamped traces are generated as a result of the simulation: instructions trace and monitored data trace. These traces are compared with functional traces (without fault injection). The result is used as data support during reliability quantification. 4) Reliability Quantifier. The goal is to determine the level of robustness by analyzing the effects of the injected fault and its probability of occurrence in order to take corrective decisions or to compute failure rate (i.e. mean time between failure) when a system failure happens as a consequence of the injected fault. Unlike other proposed approaches, we do not inject a fault arbitrarily, but we made the choice of determinism through two steps. Firstly, the probability computation of the hardware fault occurrence depends on hardware characteristics and aging of the embedded system. Secondly, the fault injection is driven by the test scenario and hence enables choosing the perimeter of the study. III.

SAFEADAPT PROJECT METHODOLOGY

To address the need for safety, reliability and cost efficiency in future FEVs, the development of a novel adaptive architecture to manage complexity through generic, adaptive, and system-wide fault handling is essential. Moreover, design simplicity, cost efficiency, and energy consumption are especially important elements. In addition, the embedded system designer needs tools that allow, on the one hand, to model and study the system operations in different operating conditions to correctly size its architecture and, on the other hand, to identify the impact of hardware faults on the behavior of the applications. SafeAdapt project [5] provides an integrated approach for engineering adaptive, complex and safe systems, ranging from tool chain support, reference architectures, modelling of system

design and networking, up to early validation and verification. For realistic validation of the adaptation and the redundancy concepts, an actual vehicle prototype with different and partly redundant applications is developed. The core phases of SafeAdapt project are presented in Figure 1. Firstly, use cases and requirements for safe adaptation in FEVs are collected by the industrial partners. Secondly, based on the collected requirements and use cases for safe adaptation, a runtime control (i.e. safe adaptation core) for enforcing safe adaptation in embedded systems with respect to safety-critical applications has been designed and implemented. It also manages the system resources during runtime by means of reconfiguration algorithms.

1

2

Specifying Scenarios and Requirements

Development of Safe Adaptation Runtime Core

4

3

Design Methodology and Tools

Prototyping and Evaluation Figure 1 – Main parts of SafeAdapt project

The System Functionality. The system functionality consists of functions that interact with each other to meet the user requirements. To model such functionality, an architecture description language for automotive domain (i.e. EAST-ADL [24]) is used. In EAST-ADL, the architecture is modeled at two levels of abstraction: an abstract functional model and a refined in form of a design model. Both levels are modelled as a composite structure that consists of a set of components that interact with each other through functional ports. In our approach, we use cardinality of the system components to specify the system variability. A component with cardinality {0 or 1} is optional, while the cardinality {2} means that it has two instances and the system can switch between them at runtime. A cardinality {1} specifies that the component is mandatory and should always exist while the system is in operation (i.e. permanent). A component may have two instances to increase the system availability and ensuring that the functionality of this component is always provided [7]. These two instances need to be allocated to different processing units, so that a failure does not lead to a total failure of the functionality. To specify such allocation, the system hardware platform need to be modelled and the software allocation components can be then defined. Similar to the system functions, the hardware model is specified using EAST-ADL modelling language. It is modelled a composite structure that contains the system hardware elements such as processing units, sensors, actuators, etc.

Thirdly, a detailed specification for the integrated design process and the necessary tool flow for safe adaptation of the networked embedded software systems for the FEVs domain is performed. This specification is complemented with the ISO26262 functional safety goals for the runtime adaptation scenario. The design tools allow code generation from the system model (in EAST-ADL, exported and refined as AUTOSAR model) targeting either the real hardware platform or simulators. Fourthly, a prototype e-vehicle is used for evaluation of the achieved results [17]. In addition, metrics for evaluation of reliability, availability, efficiency, and flexibility are set up. Finally, the obtained results are compared to current state-of-the-art. IV.

PROCESS FOR MODEL-DRIVEN SIMULATION

The proposed two-phase process that a software engineer follows to validate the adaptive behaviors of software systems by simulation is presented in Figure 2. In the first phase, the software engineer models a system that has the ability to cope with changes that are known beforehand. In the second phase, the system model is transformed to a real software system which can be executed on a virtual platform to check the system adaptive behavior. In the following, we describe the two phases and in next section we describe our tool support. A. Modelling Adaptive Embedded Software System To model a safe adaptive software system, two aspects need to be captured: the system functionality and adaptive behavior. The latter specifies the system reactions to anticipated context changes (e.g. hardware/software failure). In the following, we present our approach to model such system while considering these requirements (i.e. Step 1).

Figure 2-A process for model-driven simulation of safe adaptive software system The System Adaptive Behavior. To adapt the system in response to context changes, we introduce the system management component [25]. This component switches from a system configuration/state to another in response to an adaptation trigger (e.g. failure of a software component). Therefore, we need to model the adaptation triggers and the different runtime configurations (states) of the system. Both represent a runtime system state. To model a system state, we adopted the concept of UML instance specifications where an instance of the system design (i.e. functionality and hardware platform) is created and configured to specify a system runtime configuration or an adaptation trigger [26].

In order to model an adaptive behavior of a system, we adopted the state machine approach [27]. This technique makes adaptation policies easy to understand and it is useful for validation and verification purposes. In this machine, states correspond to the system configurations where transitions represent the adaptation between these configurations. Each transition is guarded and triggered by an adaptation event (i.e. context change). For example, in response to a hardware failure during a specific running state, the system moves from its initial configuration to a configuration that recovers from this failure. B. Generating and Validating Adaptive Software System To validate a system adaptive behavior, the system models are transformed to a software system which is then executed into a virtual platform to observe its behavior (i.e. Step 2). Generating the Software System. The functional model is used as a blueprint for generating the implementation of the system functionality (i.e. an empty skeleton for each software component is generated). In addition, to adapt the system in response to runtime changes, the system adaptive behavior model is transformed to a code that manages the system while it is in operation (i.e. the system management). The manager is responsible for executing the adaptation scenarios. It has three main tasks: “trigger adaptation”, “decide the system reactions”, and “executing the reactions”. The “trigger adaptation” task is responsible for firing a scenario specified by the adaptation state machine. The “decide reactions” task finds the adaptation plan that should be executed in response to the trigger. The “execute reactions” task changes the states of the system components based on the system target configuration.

V.

IMPLEMENTATION

In this Section, we use the concepts previously explained in Section IV to model and validate the adaptive behavior of an adaptive vehicle software system. We also describe the tools that support our approach. A. Modelling an Adaptive Vehicle Software System As discussed previously, to model an adaptive embedded system, there is a need to model its functionality and adaptive behavior. In the following, we discuss the model of an adaptive vehicle system. Modelling the System Functionality. To design the adaptive vehicle software following our approach, we use the Papyrus UML modeler [28]. A functional model of the vehicle system is shown in Figure 4. The model consists of a set of software components (applications) that are linked with each other through ports. In Figure 4, the full adaptive cruise control (ACC) has the cardinality {2} which means it has two instances at runtime. The two instances can replace each other in case of the failure of one of them. The SomnoAlert is an optional component, i.e. it can exist or not while the system is in operation (the cardinality is {0 or 1}). A simple hardware model of the vehicle system is designed as a composite structure that consists of two electronic control units (i.e. Delphi TMDP (Trusted Multi Domain Platform) and RACE [17]) is shown in Figure 4. In addition, the two units are connected with each other through a hardware connector.

Validating the Software System. To ensure that the system is behaving correctly, the system adaptive behavior is analyzed using simulation-based fault injection approach. The embedded code is executed using a virtual platform (i.e. UNISIM-VP) as shown in Figure 3. We simulate the different anticipated adaptation scenarios that can occur during the real system execution. The system execution is observed to ensure that it is going to execute correctly in real situations. In addition, faults are injected into the simulated system and its reaction is observed to check its reliability [9]. In case that the system does not react correctly (i.e. the system becomes in a faulty state), the system adaptation scenarios are updated to cope with this fault (see Figure 3).

Figure 3 – Fault-injection and impact analysis

Figure 4- Design model for the embedded system

Modelling the System Adaptive Behavior. To model the adaptive behavior of the system, both adaptation triggers and system configurations need to be specified. We model both of them using the instance specification concept. A set of UML instances specifications that describe the component instances along with values for their attributes. Such a set is called deployment plan, a term inspired from the CORBA component model. In our approach, a deployment plan represents a system configuration. An example of an adaptation trigger, modeled as an instance specification, is shown in Figure 5 (see the top part). For each software component (application), a runtime state is defined {Active, Inactive, Hot, Cold, Failed}. In this example: SBW0, BBW0, SMA, and AEB are in “Active” state, SBW1 is “Hot”, BBW1 and ACC1 are in “Cold” state, and ACC0 is “Failed”. A system configuration to recover from the failure of ACC0 is shown in Figure 5 (the bottom part). The instance specification of each software component is defined as where this configuration is defined as follows: {, , , , , , , , }

in Figure 6 (i.e. “ACCFailure”). In this transition, the state of the first instance of the ACC is changed from “Failed” to “Inactive” while the state of the second instance of the ACC is changed from “Hot” to “Active”.

Figure 6- Adaptive behavior for the vehicle software system

B. Generating and Executing the Vehicle Software System To validate the adaptive behavior of the vehicle, the system models are transformed to software which is executed on the UNISIM-VP simulator to observe its behavior. Generating the Software System. For generating an executable system from the model described previously, we have created a Papyrus plugin that generates an Eclipse project from the designed models. The software engineer can use the modelled state machine for the system adaptive behavior to generate and execute the project automatically. The generated project (as shown in Figure 7) consists of: simulator files, an adaptation manager, system applications and scheduler. Firstly, the simulator files include the UNISIM-VP and its configuration file which specifies, for example, the binary to run (e.g. main.c.elf) and the starting address for executing the binary based on the simulator memory map (see Figure 7). Secondly, the adaptation manager is responsible for the automatic execution of the adaptation scenarios.

Figure 5- Specifying an adaptation trigger and the system response to that trigger

To model the switching between the system configurations in response to the adaptation triggers, a state machine is created as shown in Figure 6. For example, in response to a failure of the adaptive cruise control (the adaptation trigger specified on the top part of Figure 5), the system moves from its initial configuration to another one that recovers this failure (i.e. the system configuration shown in the bottom part of Figure 5). This system switching is specified using first transition shown

Figure 7- The generated “C” project that runs on UNISIM-VP

Thirdly, for each software component defined in the design model, we generate the corresponding empty “C” code for the application (i.e. the application skeleton). Fourthly, to coordinate the execution of the system functionality and the adaptation manager, we generate a system scheduler that manages the execution of the applications and the adaptation scenarios. Finally, to monitor the execution of the adaptation scenarios, the telnet connection output printouts that display the current system state, the trigger of the system adaptation, and the adaptation plans execution. Validating the Software System. Using our Eclipse plugin, the software engineer can execute the generated “C” code. The simulator is launched using the configuration file and the telnet terminal is also launched and connected to the simulator. When the simulator starts, it moves the system from the non-set state to its initial configuration as shown in Figure 8. Then, it starts the pre-defined adaptation scenarios (i.e. the adaptation scenarios 1-4Figure 8). An example execution of a scenario is shown in Figure 8, where in response to a failure of the first instance of the adaptive cruise control, two actions are identified: change the first instance state from “Failed” to “Inactive” and change the second instance state from “Hot” to “Active” then its outputs are taken into account afterward.

Figure 9 – Injecting faults to the running software

VI. CONCLUSION Modern adaptive software systems have the ability to adapt themselves while in operation to cope with hardware/software failures. However, ensuring safe adaptive behaviors of such systems is a major challenge. In this paper, we have proposed an approach to assist the software engineer in validating the adaptive behaviors of an embedded software system. To model the system functionality and its adaptive behaviors, an architecture description language (e.g. EAST-ADL) is used. Based on the system design model, the embedded software system is then generated automatically. Finally, to validate the system adaptive behaviors, fault injection and monitoring techniques on UNISIM-VP virtual platform are used. As future work, first, we plan to extend our approach to take into account non-functional requirements such as timing and power consumption constraints during adaptation modelling. Second, further evaluations will be carried out to assess the robustness and applicability of the approach through applying it to a number of case studies. ACKNOWLEDGEMENT This work was supported by the European Commission, Bpifrance and the General Counsel of Essonne (Conseil Général de l'Essonne-France). REFERENCES

Figure 8 -Executing the specified adaptation scenarios

To inject faults, UNISIM-VP allows instrumenting the variables of the embedded software. An example of an injected fault is shown in Figure 9 where the states of the running applications/instances are changed using an instrumentation service of the simulator. The state of the instance “SBW0” is set to “Active” while the state of the instance “SBW1” is set to “Failed” (see Figure 9-2). When the system manager detects events that trigger an adaptation, it selects a scenario which is then executed in response to this trigger. In Figure 9-3, the injected fault cannot be handled by the simulated software (i.e. there is no scenario to cope with this change/fault). Thus, an adaptation scenario that specifies the system reaction(s) in response to such type of failure need to be defined.

[1] U. Abelein, H.Lochner, D. Hahn, and S. Straube, "Complexity, quality and robustness - the challenges of tomorrow's automotive electronics," in Design, Automation, Test in Europe (DATE ), Dresden, Germany, 2012, pp. 870-871. [2] A. Hava, J. Qin, J. B. Bernstein, and Y. Bot, "Integrated circuit reliability prediction based on physics-of-failure models in conjunction with field study," in Proceedings of Reliability and Maintainability Symposium (RAMS), Orlando, FL, USA, 2013, pp. 1-6. [3] S. Fürst, "Challenges in the design of automotive software," in Design, Automation & Test in Europe (DATE), Dresden, Germany , 2010, pp. 256-258. [4] A. Pretschner, M. Broy, I. H. Kruger, and T. Stauner, "Software Engineering for Automotive Systems: A Roadmap," in Future of Software Engineering (FOSE), Minneapolis, MN, USA, 2007, pp. 5571. [5] P. Schleiss, M. Zeller, G. Weiss, and D. Eilers, "SafeAdapt-Safe Adaptive Software for Fully Electric Vehicles," in 3rd Conference on Future Automotive Technology (CoFAT), Munich, Germany, 2014. [6] SafeAdapt: Safe Adaptive Software for Fully Electric Vehicles. [Online]. http://www.safeadapt.eu/ [7] R. France, and B. Rumpe, "Model-driven Development of Complex

Software: A Research Roadmap," in Future of Software Engineering (FOSE 2007), Minneapolis, MN, USA, 2007, pp. 37-54. [8] UNISIM Virtual vp.org/site/index.html

Platforms.

[Online].

http://unisim-

[9] R. Nouacer, M. Djemal, and S. Niar, "Using Virtual Platform for Reliability and Robustness Analysis of HW/SW Embedded Systems," in 1st International ESWEEK Workshop on Resiliency in Embedded Electronic Systems, In conjunction with Esweek 2015, Amsterdam, The Netherlands, 2015. [10] ACTORS: Adaptivity and Control of Resources in Embedded Systems. [Online]. http://cordis.europa.eu/project/rcn/85458_en.html [11] HEMIS: electrical powertrain Health Monitoring for Increased Safety in FEVs. [Online]. http://cordis.europa.eu/project/rcn/104132_en.html [12] N. Navet, Y. Song, F. Simonot-Lion, and C. Wilwert, "Trends in Automotive Communication Systems," Proceedings of the IEEE, vol. 93, no. 6, pp. 1204-1223, 2005. [13] DYSCAS: Dynamically Self Configuring Automotive Systems. [Online]. http://cordis.europa.eu/pub/ist/docs/dir_c/ems/dyscasv1_en.pdf [14] iLand: mIddLewAre for deterministic dynamically reconfigurable NetworkeD. [Online]. https://www.utwente.nl/ctit/research/research_projects/concluded/inter national/artemis/iland/ [15] IPAC: Integrated Platform for Autonomic Computing. [Online]. http://ipac.di.uoa.gr/ [16] POLLUX: Process Oriented Electrical Control Units for Electrical Vehicles Developed on a Multi-system Real-time Embedded Platform. [Online]. http://cordis.europa.eu/project/rcn/103720_en.html

[20] H. Ziade, R. Ayoubi, and R. Velazco, "A survey on Fault Injection Techniques," The International Arab Journal of Information Technology, vol. 1, no. 2, pp. 171-186, 2004. [21] E. Jenn, M. Rimen, J. Ohlsson, J. Karlsson, and J. Arlat, "Design Guidelines of a VHDL-Based Simulation Tool for the Validation of Fault Tolerance," in Proceedings of 1st ESPRIT Basic Research Project PDCS-2 Open Workshop LAAS/CNRS, San Miniato, Italy, 1993, pp. 461-483. [22] L. Macchiarulo, M. Rebaudengo, M. Sonza Reorda and M. Violante P. Civera, "Exploiting FPGA-based techniques for fault injection campaigns on VLSI circuits," in IEEE International Symposium on Defect and Fault Tolerance in VLSI Systems, San Francisco, CA, 2001, pp. 250 - 258. [23] R. Nouacer, M. Djemal, S. Niar, G. Mouchard, N. Rapin, J.P. Gallois, P. Fiani, F. Chastrette, T. Adriano and B. Mac-Eachen, "Enhanced Quality Using Intensive Test and Analysis on Simulators," in 18th Euromicro Conference on Digital System Design (DSD), pp 152-157, Funchal, Portugal, 2015, pp. 152 - 157. [24] D.J. Chen, S. Gerard, H. Lonn, M.O. Reiser, D. Servat, C.J. Sjostedt, R.T. Kolagari, M. Torngren, and M. Weber P. Cuenot, "Managing Complexity of Automotive Electronics Using the EAST-ADL," in 12th IEEE International Conference on Engineering Complex Computer Systems (ICECCS '07), Washington, DC, USA, 2007, pp. 353-358. [25] M. Salehie, and L. Tahvildari, "Self-adaptive software: Landscape and research challenges," ACM Trans. Auton. Adapt. Syst, vol. 4, no. 2, pp. 1-42, 2009. [26] M. Fowler, "UML Distilled: A Brief Guide to the Standard Object Modeling Language (3 ed.).," , Boston, MA, USA, 2003.

[17] RACE: Robust and Reliable System Architecture for Future eCars. [Online]. http://www.projekt-race.de/

[27] B. Morin, O. Barais, J.M. Jezequel, F. Fleurey, and A. Solberg, "Models@ Run.time to Support Dynamic Adaptation," Computer, vol. 42, pp. 44-51, 2009.

[18] R. Leupers, F. Schirrmeister, G. Martin, T. Kogel, R. Plyaskin, A. Herkersdorf, and M. Vaupel, "Virtual platforms: Breaking new grounds," in Design, Automation & Test in Europe (DATE), Dresden, Germany , 2012.

[28] S. Gérard, C. Dumoulin, P. Tessier, and B. Selic, "Papyrus: a UML2 tool for domain-specific language modeling," in International Dagstuhl conference on Model-based engineering of embedded real-time systems (MBEERTS'07), Berlin, Heidelberg, 2007, pp. 361-368.

[19] T. D. Schutter, "Better Software. Faster! Best Practice in Virtual Prototyping," in Synopsys press, USA, 2014.