Safe adaptation of vehicle software systems

Accepted Manuscript

Safe Adaptation of Vehicle Software Systems Mahmoud Hussein , Reda Nouacer , Ansgar Radermacher PII: DOI: Reference:

S0141-9331(16)30417-3 10.1016/j.micpro.2017.06.014 MICPRO 2584

To appear in:

Microprocessors and Microsystems

Received date: Revised date: Accepted date:

9 January 2017 11 May 2017 16 June 2017

Please cite this article as: Mahmoud Hussein , Reda Nouacer , Ansgar Radermacher , Safe Adaptation of Vehicle Software Systems, Microprocessors and Microsystems (2017), doi: 10.1016/j.micpro.2017.06.014

This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting proof before it is published in its final form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.

ACCEPTED MANUSCRIPT

Safe Adaptation of Vehicle Software Systems 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]

CR IP T

Abstract- 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-by-wire 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. The SafeAdapt project provides an integrated approach for engineering such adaptive, complex and safe systems, ranging from tool chain support, reference architectures, system modelling and networking, up to early validation and verification. In this paper, we give an overview of the SafeAdapt project methodology. We also describe a particular aspect of the project which is the validation of the system adaptive behavior. To validate the adaptive behavior of a vehicle system, an architecture description language for automotive embedded systems (i.e. EAST-ADL) is used for designing the system. 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.

AN US

Keywords— Fully Electric Vehicles; Adaptive Software Systems; Safety; Virtual Platform; Model-driven Development.

1. Introduction

PT

ED

M

It is largely recognized that the architectures of embedded systems are becoming more and more complex both at hardware and software components. Thanks to the constant advances in micro-electronics, embedded system engineers are now able to integrate more system functions on a powerful System-on-Chips (SoCs) [1]. The automotive industry also benefits from these advances in micro-electronics 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.

AC

CE

The automotive industry faces an era of rapid change with the advent of electric drives. Fully electric drive trains promise to reduce exhaust emissions or even achieve the “Zero Emission” dream in case of Fully Electric Vehicles (FEVs) [3]. The trend towards electric vehicles also means a shift towards fully electrical control of existing and new functions. This requires a dramatic change of the system architecture of vehicles. Highly integrated subsystems, like wheel-hub drives, brake-by-wire systems, steer-by-wire systems, active body control etc. must be coordinated and controlled by novel hardware approaches and software implementations since they provide highly safety relevant applications [4]. Due to this, redundant, systems are acting as a fall-back system in case of failure. Initially, these were designed as mechanical fall-backs to electrical systems. As a result of the above, new trend, the overall Electric/Electronic (E/E) architecture of a vehicle is becoming extremely complex [5]. This accelerates the existing trend of This work was funded by the European Commission within the 7th Framework Program as part of the SafeAdapt project under grant number 608945.

growing complexity of the E/E architecture in current vehicles (see Fig. 1). Today, the functions of the vehicles are provided in several sub-domains with different criticalities, ranging from low critical infotainment systems with typically soft realtime constraints, up to the very safety-critical control software with hard real-time constraints (e.g. steer-by-wire or brake-bywire). Each of these domains is typically hosted on a different set of Electronic Control Units (ECUs). The control units of each domain are connected by various networks and busses, tailored for the domain requirements, forming a networked embedded system. The number of networks and ECUs of the E/E architecture are permanently growing to fulfil the increasing demand for more automated functions and electronic controls (see Fig. 1). Nowadays, up to 90% of the innovations in the automotive industry are realized by hardware and software [6], resulting in between 2000 and 3000 atomic functions realized in a software distributed over up to 100 electronic control units (ECUs) in modern high-end cars [7]. In addition, applications like brake-by-wire have another need to replace mechanical systems by E/E systems. In this case, the recuperation of energy is another reason to abandon mechanical systems. The trend towards fully electric vehicles significantly increases the amount of highly complex safety-critical functionality. It is expected that mechanical back-up systems will be replaced by full X-by-wire in the near future since having mechanically and electrically/electronically controlled systems operating in parallel is too costly and adds too much weight and complexity. In addition, more and more systems, like advanced driving assistance require electric/electronic control of systems such as brakes, drive train, or steering. The vision of “autonomous driving”, which according to major OEMs such as VW can be possible by 2028 [8], clearly needs fully electric/electronically controlled systems in order to be implemented in a safe and cost-efficient way.

ACCEPTED MANUSCRIPT

Centralized ICT architecture ~70 ECUs (2010)

Introduction of CAN as standard bus (1987) Bosch ABS introduced in Mercedes S-Class 1978

~43 ECUs (2005) Amount of functions (~ necessary complexity)

~10 ECUs (1996)

1st million of “VW Kafer” produced

Age of cable ~ 40 yrs

1955

1965

1975

1985

CR IP T

Complexity and number of functions

Cloud/swarm-oriented ICT architecture Actual complexity

Age of busses and ECUs ~ 26 yrs

1995

2005

2015

Age of services ~17 yrs

2025

2035

Time

AN US

Fig. 1. Evolution of vehicle systems complexity and functionality [9]

[11]. Multi-domain controllers could be used to reduce the overall functional safety overhead on the complete E/E architecture by handling critical functions centrally. But, an architecture with multi-domain controllers does not provide any hardware redundancy between its controllers which affect the availability of the functions. Thus, it is not possible today to implement the upcoming functions of FEVs (e.g. x-by-wire, autonomous driving, etc.) by current E/E architectures based on pure multi-domain controllers (since they are fail-passive).

PT

ED

M

With regard to highly-reliable systems, it is important to follow the developments in the aerospace domain. In modular avionics, hot redundant systems with dissimilar designs using fully by-wire controls have taken over mechanically driven systems [10]. This resulted in a very high number of ECUs and rather complex and expensive solutions suitable for the aerospace industrial domain. This is also justifiable since the safety-critical functions in the aerospace domain need to be fully fault tolerant and fail operational. The automotive industry may still profit from the technical solutions followed in the aerospace domain although the implementation in aerospace is much more complex. This simply results from the fact that an aircraft cannot just be stopped during flight in case of failure. However, as soon as E/E systems are taking over mechanical solutions, similar requirements will arise. They will ask at minimum for a reduced function still available in case of failure in order to be able to stop the vehicle safely.

AC

CE

Taking these ideas from the aerospace to the automotive industrial domain is not directly possible, due to cost reasons. Furthermore, it is not required to have dual or triple redundant and dissimilar systems in the same complex manner as in the aerospace. A tailored approach suitable for automotive shall copy the principal ideas of redundant systems but optimizes the number of ECUs, as well as the required replication of functions. This is needed to achieve the cost effectiveness required in the automotive industrial domain. Also, adapting the aerospace concepts to the automotive world will reduce energy consumption due to more efficient utilization of ECUs. To address these very complex challenges about the E/Earchitecture and systems, recent development aims at consolidation of the E/E architecture. The Single Domain Controllers represent one of the possible approaches, where different functions of a vehicle sub-domain are integrated (i.e. vertical integration as shown in Fig. 2). Furthermore, MultiDomain Controllers are under development to consolidate the vehicle architecture (i.e. horizontal integration, see Fig. 2)

Fig. 2. Current automotive E/E architecture

ACCEPTED MANUSCRIPT

To be able to implement upcoming critical functions of FEVs and increase their availability, hardware and software redundancy, which makes the system more complex, needs to be introduced. To manage this complexity, the vehicle hardware needs to be used efficiently by allocating multiple functions on the same processing unit [7]. In addition, the system should have an adaptation (reconfiguration) feature, where non-critical functions can be removed or deactivated to give more processing power to the critical ones [12]. Also, in the case of a critical function failure, an inactive component that performs the same functionality is activated, so that the system availability and reliability are increased. Furthermore, to ensure that the system is going to behave correctly at runtime, the system pre-defined adaptations need to be studied early at the design time [13].

to generate 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 [20]). In addition, to simulate a faulty system state and to ensure that the system has the ability to cope with this fault, we use a simulation-based fault injection approach (i.e. robustness study) [21].

The SafeAdapt project addresses the issue of complex E/E architectures by a new, substantial revision of the architecture and a technology leap beyond multi-domain controllers. In this way, only a new approach can bring the actual complexity back down to the necessary level, which results in significant improvements regarding cost and energy efficiency. A similar effect has been noted (see Fig. 1) with the introduction of the CAN bus, which consolidated the networking and application development [6] [7].

2. Related Work

CR IP T

The remainder of the paper is organized as follows. In Section 2, we give a description of the related work. The SafeAdapt project methodology is explained in Section 3. Our approach for modelling an embedded software system and its adaptive behavior is described in Section 4. In Section 5, we focus on the validation of the adaptive behavior. Finally, we conclude the paper in Section 6. The work introduced in the paper is related to two research areas: adaptive software systems and virtual validation. Thus, in this section, we discuss the related work from both angles. 2.1 Adaptive Software Systems

AN US

Adaptation is a technique to increase the reliability of highly safety-relevant systems that run without mechanical fall back solutions. The FP7 project ACTORS (Adaptivity and Control of Resources in Embedded Systems) has addressed the design of complex embedded systems [22]. 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.

M

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 [14] [15]. This reduces 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 to increase reliability and efficiency regarding energy consumption, cost, and design simplicity.

CE

PT

ED

SafeAdapt follows a holistic approach to build adaptive systems in safety-critical environments. It comprises methods, tools, and building blocks for safe adaptation. The project also includes certification support of safety-critical systems in the e-vehicle domain. The technical approach is built on a SafeAdapt Platform Core, encapsulating the basic adaptation mechanisms for re-allocating and updating functionalities in the networked, automotive control systems [16]. The core is the basis for an interoperable and standardized solution for adaptation and fault handling in AUTOSAR. The SafeAdapt approach also considers functional safety with respect to the ISO 26262 standard [17].

AC

In this paper, we present the methodology of SafeAdapt project with a particular focus on the virtual validation aspect. For validating the adaptive behavior of an embedded software system, we follow a model-driven approach. Model-driven development (MDD) is the notion of constructing a model of a system that can be transformed to a real system [18]. Thus, we have used EAST-ADL (an architecture description language for automotive embedded systems, in form of a UML model with an EAST-ADL profile) for creating the system design model which captures the system functionality and adaptive behavior. The functional model is then used for generating an AutoSAR model [19] which is used with the adaptation model

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 [23]. Since this project provides a specific approach to increase the reliability and availability of electric power-train functionality, the 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 the automotive domain [24]. 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 [25]. Another project focusing on dynamic systems is iLand (mIddLewAre for deterministic reconfigurable NetworkeD embedded systems) [26]. It aimed at improving the system flexibility, scalability, and composability by developing a modular component-based middleware for dynamic composition and reconfiguration. The IPAC project (Integrated Platform for Autonomic Computing) developed a novel embedded middleware and service provision platform that bring considerable intelligence to devices [27]. The POLLUX project investigated and developed architectural concepts for e-vehicles. However, POLLUX did not consider runtime adaptation/reconfiguration

ACCEPTED MANUSCRIPT

Siemens developed an integrated and open ECU platform with sophisticated redundancy concepts within the RACE (Robust and Reliable System Architecture for Future eCars) project [29]. 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). It also has additional features such as a clear “layering” (sensor/actor level, vehicle data level, function level) and support for extensibility with new components and functions at runtime. Standardization (e.g. towards AUTOSAR) was out of this project scope. The RACE ECU is used within SafeAdapt by the project partner “Siemens”.

Morin et al. have proposed a technique to handle the exponential growth of the number of configurations that are derived from the system variability [12]. To cope with the complexity of adaptive systems, they combined model driven and aspect oriented approaches. CEVICHE is a framework that combines complex event processing and business process adaptation to enable runtime changes to composite services [36]. It has a language called SBPL (Standard Business Process Language). This language is an extension of the BPEL (Business Process Execution Language) to make business processes more flexible through defining adaptation points in a process at design time.

M

AN US

A design methodology with an associated framework for exploring the design space of embedded systems has been developed in the COMPLEX project (COdesign and power Management in PLatform-based design space Exploration) [30]. The project includes five main stages: the system design entry, specification of the executable system, estimation and model generation, exploration and optimization, and overall system simulation [31]. The project supports a UML/MARTE design entry with an automatic generation of an executable SystemC model. In addition, to allow a fast and a unitary simulation of the complete functional and extra-functional properties of the system, a virtual prototype is generated. This prototype helps the designer in identifying and eliminating power peaks and performance bottlenecks.

[35]. To do so, they separate the system adaptation logic from its core artifacts (i.e. system functionality). They also design the adaptation logic as condition-action rules that specify the required adaptation actions in response to context changes. Each rule consists of two parts: (1) adaptation condition as an expression based on context attributes; (2) adaptation actions that represent the required changes to the system to cope with context changes. These rules are constructed as a componentbased system that can be changed at runtime.

CR IP T

in automotive E/E architectures as required for safety-relevant applications, where redundancy concepts are needed [28].

ED

In addition to the research projects described above for the development of adaptive vehicle systems, we now describe a number of approaches that have been proposed for developing adaptive software systems in general.

AC

CE

PT

The Rainbow framework provides mechanisms to monitor the environment, analyze it, select the required adaptation strategy, and effecting the needed changes to a running system [32]. To capture the system reaction to environment (context) changes, they used a language called Stitch. MUSIC project is a component-based framework that is used for optimizing a system overall utility in response to environment changes [33]. They have a quality of service (QoS) model that describes the system composition together with its relevant QoS dimensions and how they are affected when the system is changed from a configuration to another. The quality of service model is used to select a configuration that has the best utility and able to cope with the runtime context changes. Heaven et al. have developed an approach to adapt the system structure in response to environment changes while preserving the high level goals of the system [34]. They use Labeled Transition Systems (LTS) to model the system domain. This model captures the states of the system and its environment. The context changes are the actions that move (adapt) the system from a state to another. Andrade et al. proposed an approach to cope with unanticipated changes in the adaptive behavior of a system

PLASTIC is a model-driven approach to support a web service life cycle from design to implementation and to runtime execution [37]. It also supports the runtime adaptation of the service based on context or quality of service changes to ensure that the users get the best quality of service. Sheng et al. proposed a model-driven approach to ease the development of context-aware services [38]. In this approach, the context information is used by a set of adaptation rules to adapt the service output parameters (i.e. they do not support adaptation of the service functionality). All the work 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. 2.2 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 [39] [40]. Embedded system designer needs tools that allow studying the impact of hardware faults on the behavior of the embedded software. Therefore, a large number of techniques has been developed for inserting faults into a system prototype or a model. There are four main fault injections categories: hardware-based, software-based, simulation-based, and emulation-based. Hardware-based fault injection uses additional hardware to introduce faults into the target hardware. Depending on the faults and their locations, there are two hardware-based fault injection methods [41]. First, the fault is introduced using a direct physical contact with the target system by introducing

ACCEPTED MANUSCRIPT

For what concerns the emulation-based fault injection, the considered circuit is implemented on an FPGA [42]. The circuit is then connected to a computer to control the fault insertion triggers and display the results. This technique has the same drawback as hardware-based fault injection.

Requirements file

Hardware target

M

Finally, simulation-based fault injection focus on inserting the faults in high level models (virtual platform) [21] [43]. It involves the construction of a simulation model of the system, including a detailed simulation model of the processor in use. Simulation is faster than hardware emulation where embedded code is not instrumented and faults can be easily introduced.

PT

ED

As part of the EQUITAS project [44], an approach for fault injection has been proposed (shown in Fig. 3 and described hereafter) [21]. It takes as input an application, the system requirements, and a target hardware. The following services have been defined and implemented in the simulation environment UNISIM-VP [21]:

CE

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.

AC

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 points will serve as triggers during the scenario execution to introduce 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 the 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 inserted fault and its probability of occurrence in order to take corrective

Application

Fault quantifier

Fault probability of occurrence Fault injection engine & simulation (UNISIM-VP)

Execution trace (code/data) with faults

Test scenarios (MaTeLo)

Reference execution trace (code/data)

Comparator and analyzer of execution traces Alert ?

AN US

Software-based fault injection is used to introduce faults into the source code [41]. Several kinds of faults may be introduced such as register/memory errors, dropped or replicated network packets and erroneous flags. Such fault injection technique is attractive because it does not require expensive hardware. This approach is flexible. However, it has two drawbacks: it cannot insert faults into locations that are inaccessible to software, and it requires a modification of the source code that may disturb the workload running on the target system.

decisions or to compute the failure rate (i.e. the mean time between failure) when a system failure happens as a consequence of the injected fault.

CR IP T

voltage or current pulses into the circuit, or modifying the value of the circuit pins. Second, the faults are inserted without direct physical contact with the target system by disturbing the hardware with parameters of the environment (e.g. heavy ion radiation, electromagnetic interferences, etc.). Hardware-based fault injection presents several benefits, such as it can access locations that are hard to be accessed by other means, it is more suitable for the low level fault models, and experiments are fast. However, this method can introduce high risk of damage for the system. It also presents a limited observability and controllability.

No

Reliability quantifier?

Yes

silence

- Fault effects analysis - Corrective Decisions - Compute error ratio

Fig. 3. Hardware fault injection in design and test flow

Unlike other proposed approaches, in this approach a fault is not insert arbitrarily, but the choice of determinism is made through two steps. Firstly, the probability computation of the hardware fault occurrence depends on aging of the embedded system and hardware characteristics. Secondly, fault injection is driven by a test scenario and hence enables choosing the study scope. 3. 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. In addition, design simplicity, cost efficiency, and energy consumption are especially important elements. Moreover, 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. The SafeAdapt project provides an integrated approach for engineering adaptive, complex and safe systems, ranging from tool chain support, reference architectures, modelling of system and networking, up to early validation and verification [14]. For realistic validation of adaptation and redundancy concepts, an actual vehicle prototype with different and partly redundant applications is developed. The core phases of the SafeAdapt project are presented in Fig. 4. 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 [45])

ACCEPTED MANUSCRIPT

Fig. 4. Main parts of SafeAdapt project

Regarding the architecture of an individual computing platform (central computing core (CCC) or control unit), each platform must be able to reliably diagnose its own faults, in order to remove itself from the computing network and not causing any further damage. This fail-silent behaviour is attained through strengthening of the platforms diagnostic capabilities. In detail, every computation step is recalculated on a 2nd core within the ECU and compared (HW lockstep), data is protected from corruption through error checking systems, and the processing unit is monitored to rapidly detect if it failed or got stuck during an operation [46].

M

AN US

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, which exported and refined as AUTOSAR model [19]) targeting either the real hardware platform or simulators. Fourthly, a prototype e-vehicle is used to evaluate the achieved results [29]. In addition, metrics for evaluation of reliability, availability, efficiency, and flexibility are set up. The obtained results are also compared to current state-of-the-art.

Consequently, the SafeAdapt consortium developed a generic hardware architecture that is capable of proving multiple individual functions simultaneously as compared to state-of-the-art domain-based solutions. This consolidation of functionalities allows minimising the required amount of redundant backup hardware, as a single device can be a potential replacement of a multitude of other devices in the case of an unlikely hardware failure. In the event of such a failure, the remaining computing resources are reconfigured to ensure that all critical functionality remains operational. This concept benefits from the fact that a lot of functionalities only provide comfort and not relevant from a safety perspective. As such, in the event of a severe failure, non-critical functions can be deactivated so that all safety-relevant features can remain operational. This type of reconfiguration, frequently also referred to as graceful degradation, is a key factor in reducing the amount of required control units in a vehicle. In essence, this concept enables all installed computing platforms to compensate for any failure occurring in another part of the vehicle network. Thus, it safeguards the availability of critical functionality.

CR IP T

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.

A 1-out-of-2 safety design with diagnostic capabilities (1oo2D) is created when a fail-silent behaviour on a platform level is combined with failure properties of the entire system. Thus, a fail-operational behaviour for critical functionalities is attained. It is the most efficient resource variant to reach failoperational behaviour as it only requires two control units. The concept is schematically depicted in Fig. 5.

CE

PT

ED

Within the SafeAdapt project, a number of technological challenges are addressed to overcome current impediments for the advance of e-vehicles and automated systems to improve road safety. The project has created three technological and methodical pillars in form of a new E/E architecture, a smart software-based management of the vehicle subsystems, and an accompanying development process. Through the application of these three innovative pillars, it is possible to economically create clean and safe vehicles in small as well as large quantities. To showcase the viability of this concept, multiple demonstrators were developed by the consortium in form of a full-scale e-vehicle as well as an assortment of model cars and simulators to proof and highlight individual research results in more detail.

AC

3.1 Vehicle Safety Architecture

Fail-operation system behaviour is well known in aviation, manufacturing, or the petrochemical industry. An architecture normally consists of a set of sensors, redundant computing platforms, actuating units, and interlinking field buses or networks in order to provide the required functionality with the desired availability. But, solutions to ensure availability are either limited to individual functions or utilise highly redundant hardware architectures with up to four components performing the same computational workload. To meet the cost pressure of the automotive industry, fail-operational systems must be made possible with a less resource intensive architecture [14].

Fig. 5. 1-out-of-2 safety design with diagnostics [47]

As the communication links are also a potential source of a failure, it must further be ensured that sensors, platforms, and actuators can communicate over two independent channels, which are realised through two dedicated networks. Moreover, a multitude of different signals are transmitted over the same

ACCEPTED MANUSCRIPT

To demonstrate this novel architecture with enhanced robustness, availability, and efficiency of safety-relevant systems, while preserving the functional safety in FEVs, the evehicle of the project consortium was equipped with the aforementioned hardware layout. The system architecture is generally partitioned into two sections. The core network consists of different hardware platforms with strong diagnostic capabilities, such as the Trusted Multi Domain Platform (TMDP) or the RACE DCC [29]. They are interconnected by a redundant time-triggered network to provide the required fail-operation behaviour [48]. In addition, the sensors and actuator are connected through a ring topology to improve the cable of the vehicle layout.

AN US

In essence, this introduced concept for fail-operational E/E architectures lays the foundation for reducing the amount of control units and cables in a vehicle, consequently leading to lower material costs and weight.

its standby status. More precisely, a backup application may be completely deactivated to attain highest level of resource saving or alternatively hold some state information so that activation period of this application can be shortened after a failure. As this is highly dependent of the respective function, the SAPC technology supports both strategies (i.e. being applicable to a broad range of use cases). Further, through the decentralised nature of this recovery strategy the possibility of a single point of failure is eliminated, where no central coordinating role is required to perform a reconfiguration of the vehicle system [51] [52]. Therefore, the safety of future cars can be further increased. The schematic software architecture of this concept is shown in Fig. 6.

CR IP T

bus system. Without any coordination, these signals may lead to a congestion of the network, subsequently bearing the risk of time-critical messages being received too late. To overcome this risk, a time-triggered technology is utilised, which ensures each message is guaranteed a time slot by partitioning the underlying network into several short dedicated transmission windows [48].

3.2 Safe Adaptation Platform Core

ED

M

Building on this fault-tolerant hardware architecture, a smart solution is required to correctly coordinate the system reconfiguration in every anticipatable scenario [49]. For this, the project consortium has developed a Safe Adaptation Platform Core (SAPC) [45]. It is a central software component installed on every control unit, that can instruct the underlying platform to perform a reconfiguration (i.e., to activate or deactivate software required for a certain functionality). The SAPC increases safety and availability through the ability to handle complex failures, especially failures where current systems do not degrade gracefully.

AC

CE

PT

The SAPC is capable of performing a reconfiguration of the entire system in a few milliseconds to ensure that the vehicle always remains safe and fully operational [50]. For this, each SAPC monitors the status of its own computing platform to determine if all of the hosted software applications can still operate on the hardware. This status information is then cyclically transmitted to all other SAPCs installed on the other control units. As soon as this information (called Health Vectors) is exchanged, each SAPC starts to evaluate the state of the entire system. In the unlikely event of a failure within the monitored vehicle system, each SAPC will instruct its computing platform to perform a predefined recovery plan to bring the system back into a safe and operational state. The plans are stored in a database on each control unit, which is the result of an extensive safety analysis performed during the development of the system. The size of the plans database depends on the number of failure events that need to be taken into account at runtime (i.e. for “N” failure events, there is “N” adaptation plans). From a technical point of view, the backup application that is only activated after a failure can be categorised according to

Fig. 6. SafeAdapt safety software architecture [16]

It is especially noteworthy that the current automotive standards were considered in order to allow for simple application of the project results throughout the industry. With regard to software, the AUTOSAR standard defines a layered architecture to differentiate between operating system, platform services, hardware drivers, and application software. Consequently, the SAPC was developed to be integrated seamlessly into systems developed, according to the standard. However, it can also be used as a technology-independent solution, thereby easily transferred to other domains. In addition to the previously addressed safety aspects, the SAPC technology can be utilised to perform reconfiguration for other reasons, such as to save energy or activate different software for newly added components. Through the flexibility of the reconfiguration concept, it is possible to effortlessly transfer this technology to even more complex use cases of the future. Consequently, the technology developed during the SafeAdapt project already now holds a key to develop efficient solutions for the upcoming era of clean transportation and automated driving. 3.3 Automated Development Process While the hardware and software architecture of a vehicle are important, an accompanying development process is crucial for the successfulness evolution of such complex systems. With regard to any safety-critical systems, the end product must be flawless. As such, a rigorous development process is mandatory to eliminate any source of error. This normally includes a fine grained specification of requirements,

ACCEPTED MANUSCRIPT

To reduce the manual effort, the concept of automation has also reached the system engineering domain of the automotive industry. In this automation process, software tools are used to automate design decisions, create configurations in form of source code, and verify software behaviour. Based on this notion, additional tooling was developed during the SafeAdapt project to automate the configuration of fail-operational systems. The creation of these configurations manually is too costly and error-prone activity, where all potential hazards of the system and a detailed recovery plan for every control unit of the system need to be specified.

Moreover, through the automation of such configurations the chance of human errors during the development process is largely reduced. The correct functioning of the automated tooling itself has to be verified only once, as compared to the continuous verification requirement for manually created configurations. Effectively, this tooling workflow developed during SafeAdapt project provides a best-practice reference to any vehicle manufacturer targeting to successfully integrate fail-operations systems into their cars in a safe and costeffective manner. 4. Process for Model-driven Simulation

In this section, we present a particular aspect of the SafeAdapt project which is model-driven simulation for validating the system adaptive behavior. Fig. 8 presents our proposed two-phase process that a software engineer follows to validate the adaptive behavior of a software system through simulation. 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 turned into 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.

M

AN US

In SafeAdapt, a workflow between tools through the entire system development cycle was created (see Fig. 7). It begins with a high-level formalisation of an individual functionality requirements such as steering, braking, or automated driving. This formalism is then used to derive the system software and hardware architecture. Based on this information and the data collected from a safety analysis of individual hardware components, each potential hazard is automatically matched with a suitable failure plan. Finally, this failure management knowledge is automatically integrated into the source code of individual control units to ensure that the vehicle can handle any failure occurring in any imaginable driving situation. The development cycle is depicted in Fig. 7, and the tools that are used during the project are described in Table. 1.

critical steer by wire functionality could be implemented in a short time in comparison with the state-of-the-art software development processes.

CR IP T

reviews of software artefacts, assessments of work products through independent parties, extensive tests, verification and validation techniques, and documentation of every decision and development step. Through such structured deployment activities, the safety of the developed system can be ensured. At the same time, these activities require a manifold of manual effort in comparison to non-safety-critical projects.

Prossurance / OpenCert

ERNEST

System Model

UNISIM Papyrus Export

TTE Tools

FMEDA express / ComposeR

AUTOSAR XML

Key

Automated System Synthesis

Design Tool

CE

Network Requirements

Simulator

Arctic Studio

Implementation

SAPC

Roding E-Vehicle

…

Model-Car

System Requirements Anticipated Changes 1 System Design Model

Functional Model

Adaptation Model

Verification/ Validation Assurance Tool

RT-MAPS

DynaCar

Data

Refined AUTOSAR XML

AC

Network Configuration

To model a safe adaptive system, three aspects need to be captured: the system functionality, timing requirements, and adaptive behavior. The latter specifies the system reactions to anticipated context changes (e.g. hardware/software failures). In the following, we present our approach to model such system while considering these requirements (i.e. Step 1).

Sophia

PT

Platform Specification

ED

Papyrus Designer

4.1 Modelling Adaptive Embedded Software Systems

Target Systems

Fig. 7. Tool workflow

To show the applicability of this workflow within the automotive domain, the tooling was made compatible with the well-established AUTOSAR standard. This step enabled the SafeAdapt consortium to easily utilise existing software and tooling. Thus, a realistic model of an e-vehicle with safety-

2

AutoSAR Model

Model-to-Code

System Validation by Simulation

System Functionality

System Management

Fig. 8. A process for model-driven simulation of safe systems

ACCEPTED MANUSCRIPT

Table. 1. SafeAdapt tools

Purpose

Tool

composR (Siemens AG )

Safety analysis tool compliant to FTA analysis as defined by various standards such as IEC 61508 or ISO 26262.

Dynacar RT (Tecnalia )

Help during SW and HW testing phase. Configurable vehicle model running in a http://www.dynacar.es real-time system. Models from third parties (Simulink, Dymola) can be integrated on the same platform. ERNEST(Fraunhofer) Verification and validation of nonhttp://www.esk.fraunho functional properties of networked fer.de/ embedded systems at early design FMEDAexpress (Siemens AG )

Safety analysis tool for FME(D)A analysis according to IEC 61508 or ISO 26262.

Purpose

Papyrus (CEA):

General purpose UML modelling tool supporting SysML (including SysML specific diagrams), MARTE and EAST-ADL www.eclipse.org/papyrus profiles. Moreover, it offers several possibilities to customize the user interface. Papyrus software Design tool for code generation & deployment (of componentdesigner (CEA): based systems). Used to manage instances within SafeAdapt. www.eclipse.org/papyrus Supports a separation of concerns by enabling containers that /components/designer embed the original component and intercept its communication with the environment. Sophia (CEA): Safety analysis, supports FTA analysis (Papyrus add-on). https://www.polarsys.org /esf/

OpenCert (Tecnalia ):

CR IP T

Export AUTOSAR from UML/EASTADL models (Papyrus add-on)

OpenCert supports compliance assessment and certification of https://www.polarsys.org safety-critical products. Construction of safety cases. /proposals/opencert UNISIM-VP (CEA): http://unisim-vp.cea.fr

Cross-platform open source simulation environment. It is used during co-design, integration and validation of hardware/software systems. The simulation environment comprises a set of tools and services such as program loaders, OS ABI translators, instrumentation and graphical debugger.

AN US

Tool AUTOSAR Gateway (CEA)

PT

ED

M

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 [53]) is used. In EAST-ADL, the architecture is modeled at two levels of abstraction: an abstract functional model and its refinement in form of a design model. Both levels are modelled as a composite structure that consists of components that interact with each other through functional ports. In our approach, we use the 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).

AC

CE

A component may have two instances to increase the system availability and to ensure that the functionality of this component is always provided [18]. These two instances need to be allocated to different processing units, so that a failure of a unit does not lead to a total failure of the functionality. To specify such allocation, the system hardware platform needs to be modelled and the software allocation can be then defined. Similar to the system functionalities, the hardware model is specified by EAST-ADL modelling language. It is modelled as a composite structure that contains the hardware elements such as processing units, sensors, actuators, etc. The System Timing Requirements. To model the system timing requirements, we have adopted the technique proposed in TIMMO-2-USE [54] (TIMing MOdel - TOols, algorithms, languages, methodology, and USE cases) project. To specify a timing requirement, events that are associated with a software function or one of its ports are defined. These events are then used for defining timing constraints such as execution time

constraint, periodic constraint, reaction constraint, etc. Using TIMMO, the execution time of a function is specified by the ExecutionTimeConstraint concept where the start and the stop events of the function are defined with lower and upper bound for the delay between them. Similarly, to specify a periodic constraint, an event that is associated with a function is defined. Then, the PeriodicConstraint concept is used, where a periodic constraint is specified that references this event. This constraint specifies the inter-arrival time and the period of a function (e.g. 60 milliseconds). The System Adaptive Behavior. To adapt the system in response to environment changes, we introduce a management component [13]. This component switches from a system configuration/state to another in response to an adaptation trigger (e.g. a 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 which can be modeled by adopting the concept of UML instance specifications, where an instance of the system design (functionality and hardware platform) is created and configured to specify a runtime configuration or an adaptation trigger of the system [55]. In order to model an adaptive behavior of a system, we have adopted the state machine approach [56]. This technique makes adaptation policies easy to understand and 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. a 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.

ACCEPTED MANUSCRIPT

To validate a system adaptive behavior, the system design model is transformed to an AutoSAR model that is used for generating the software system. This system is then executed into a virtual platform to observe its behavior (i.e. Step 2 as shown in Fig. 8).

Table 2. Mappings between EAST-ADL and AutoSAR AutoSAR concept Software architecture

Design Function Type (a composition)

Composition Sw Software Component Type

Design Function Prototype (inside a composition)

Sw Component Prototype

Design Function Type (part of a composition)

Application Sw Component Type

Design Function Prototype (inside part of a composition)

Sw Internal Behavior

Function Flow Port (in, out)

RPort/ PPort Prototype

Client Server Interface

Client/Server Interface

All allocations

ED

Test bench

Embedded System Simulator

Monitor and Data Analyzer

Failure?

Operation

No

Silence

Yes

System Mapping Update Adaptation Scenarios

Swc To Ecu Mapping

CE

A Specific Allocation

Faults Scenarios

Reference

PT

Operation

Inject Fault

M

EAST-ADL concept Functional Design Architecture

Validating the Software System. To ensure that the system is behaving correctly, its 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 Fig. 9. The different anticipated adaptation scenarios that can occur during the real system execution are simulated. The system behavior 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 [21]. In case that the system does not react correctly (i.e. it becomes in a faulty state), the system adaptation scenarios are updated to cope with this fault.

AN US

Generating AutoSAR model. EAST-ADL and AutoSAR models represent the vehicle system at two different levels of abstraction. The EAST-ADL is used for specifying the high level model of the software system, while the AutoSAR model represents its low level implementation. For generating the AutoSAR model, a technique has been proposed. In this technique, each concept in the design model is transformed to an implementation concept (these mappings are summarized in Table 2). First, each system application is transformed to a package that includes a “composition component type”. This composition type has input and output ports, and a number of “component prototypes”. In addition, for each component, there are timing requirements defined using “system timing”. Second, internal functions of an application is transformed to “application component types” that include “required and provided ports”, “internal behaviours”, timing constraints (e.g. “execution time”) on a processing element.

Generating the Software System. The generated AutoSAR model is used as a blueprint for generating the implementation of the system functionality by Arctic studio [57]. In addition, to adapt the system in response to runtime changes, the system adaptive behavior model is transformed to code that manages the system at runtime (i.e. the management component). This manager is responsible for executing the adaptation scenarios. It includes three main tasks: “trigger adaptation”, “decide the system reactions”, and “execute 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 target configuration.

CR IP T

4.2 Generating and Validating Adaptive Systems

ECU Instance

Timing Information

System Timing

Periodic Constraint

Periodic Event Triggering

5. Implementation

Execution Time Constraint

Execution Time Constraint

In this Section, we use the concepts previously explained in Section 4 to model and validate the adaptive behavior of an adaptive vehicle software system. We also describe the tools that support our approach.

AC

Processing Node

Third, the system hardware model is transformed to two packages: ECUs and Communication. Each processing node in the EAST-ADL model is transformed to an “ECU instance” with communication ports to interact with each other. A communication package is also generated that captures the properties of the communication between the ECU instances. Finally, the software components allocation to the hardware nodes are transformed to a “system mapping” element that includes “software to ECU mapping” to specify on which ECU, the functions are allocated. It also includes references to the functions that are allocated to a specific ECU.

Fig. 9. Fault-injection and impact analysis

5.1 Modelling an Adaptive Vehicle Software Systems As discussed previously, to design an adaptive embedded software system, there is a need to specify its functionality and underlying hardware (Fig. 10), timing requirements (Fig. 11), and adaptive behavior (Fig. 12 and Fig. 13). In the following, we discuss the design model of an adaptive vehicle system.

ED

M

AN US

CR IP T

ACCEPTED MANUSCRIPT

Fig. 10. Design model for the embedded software system

constraints have been defined. Some of them are presented in Fig. 11. First, to specify a periodic constraint, an event associated with the full cruise control (FullACC) function is defined (i.e. FACCEvent). Then, a periodic constraint is specified that reference this event (see Fig. 11). The FullACC function has a minimum inter-arrival time and period of 300 milliseconds. Second, execution time (i.e. 50 milliseconds) of the steering controller function is defined based on the event (SCEvent) as shown in Fig. 11.

AC

CE

PT

Modelling the System Functionality. To design the adaptive vehicle software following our approach, we use the Papyrus UML modeler [58]. A functional model of the vehicle system is shown in Fig. 10. The model consists of a set of software components (applications) that are linked with each other through ports. In Fig. 10, the full adaptive cruise control (ACC) has the cardinality {2} which means it has two runtime instances. The two instances can replace each other in case of one of them fails. 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 hardware model of the vehicle system is designed as a composite structure as shown in Fig. 10. It contains two electronic control units (i.e. Delphi TMDP (Trusted Multi Domain Platform) and RACE [29]). In addition, the two units are connected with each other through a hardware connector. It also includes a number of sensors and actuators such as brake pedal, steering box, and steering wheel, etc. Modelling the System Timing Requirements. To model the system timing requirements, we have followed TIMMO modelling. For the adaptive vehicle system, a number of

Fig. 11. Example of timing requirements

ACCEPTED MANUSCRIPT

An example of an adaptation trigger, modeled as an instance specification, is shown in Fig. 12 (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 Fig. 12 (the bottom part). The instance specification of each component is defined as , where this configuration is defined as follows:

Failure of Adaptive Cruise Control

5.2 Generating and Executing the Vehicle Systems To validate the adaptive behavior of the vehicle system, its models are transformed to a software which is executed on the UNISIM-VP simulator to observe its behavior. Generating AutoSAR Model: An existing Eclipse plugin (AR Gateway [59]) that generates an AutoSAR model has extended to consider timing information. Using this plugin, the AutoSAR model for the vehicle system specified above is generated. For example, first, the steer by wire application is transformed to “steer by wire” package that has a composition type. This composition includes component prototypes such as steering control, steering wheel, etc. as shown in Fig. 14. In addition, it has a periodic constraint and inter-arrival time of 120 milliseconds.

M

State Active Hot Active Cold Active Failed Cold Hot Active

Fig. 13. Adaptive behavior for the vehicle software system

AN US

{, , , , , , , , }

CR IP T

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 instance specifications describe component instances along with values for their attributes. This set is called a deployment plan, a term inspired from CORBA component model. In our approach, a deployment plan represents a system trigger or configuration (state).

Allocation RACE TMDP RACE TMDP TMDP RACE TMDP TMDP RACE

CE

PT

State Active Hot Active Cold Active Inactive Cold Active Active

ED

Recovery of the Failed Adaptive Cruise Control

AC

Fig. 12. Specifying an adaptation trigger and the system response

To model the switching between the system configurations in response to adaptation triggers, a state machine is created as shown in Fig. 13. For example, in response to a failure of the adaptive cruise control (the adaptation trigger specified on the top part of Fig. 12), 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 Fig. 12). This system switching is specified using first transition shown in Fig. 13 (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”.

Fig. 14. The system application in the AutoSAR model

Second, internal functions of the steer by wire are translate to application component types. These components include internal behaviours and source code. They also include timing information about the internal behaviours such as execution time of the steering controller on the TMDP ECU as shown in Fig. 14 (i.e. 10 milliseconds).

ACCEPTED MANUSCRIPT

run (e.g. main.c.elf) and the starting address for executing the binary based on the simulator memory map. Secondly, the adaptation manager is responsible for the automatic execution of the adaptation scenarios. Thirdly, for each software component generated in the AutoSAR model, a corresponding “C” code is generated using the Arctic studio. Fourthly, to coordinate the execution of the system functionality and the adaptation manager, we generate a scheduler that manages the execution of the applications and the adaptations. Finally, to monitor the execution of the adaptation scenarios, an output terminal shows printouts that display current system state, trigger of the system adaptation, and adaptation plans execution (see Fig. 17).

CR IP T

Third, processing elements (nodes) in the hardware model are transformed to ECU instances with communication ports to interact with each other (e.g. TMDP and RACE in Fig. 15). Finally, the allocation of software components to the hardware elements are transformed into software to ECU mapping for each processing unit. Inside this mapping, references to functions allocate to the ECU are generated (e.g. the break by wire function is allocated to the TMDP as shown in Fig. 15).

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 an output terminal and the high level model are also launched and connected to the simulator.

AN US

Fig. 15. The hardware platform in the AutoSAR model

When the simulator starts, it moves to initial configuration of the system. Then, it starts the execution of the pre-defined adaptation scenarios (i.e. adaptation scenarios 1-4 presented in Fig. 17). An example execution of a scenario is shown in Fig. 17, where in response to a failure of the first instance of the steer by wire, two actions are identified: change first instance state from “Failed” to “Inactive”, and change second instance state from “Hot” to “Active” then the second instance outputs are taken into account afterward. These transitions are also visualized using the animation framework of Papyrus Moka [60] (see the last part of Fig. 17).

Last Adaption Plan Simulator controls

1

PT

ED

M

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 model. The software engineer can use the state machine of the system adaptive behavior to generate and execute the project automatically. The generated project (as shown in Fig. 16) consists of: simulator files, an adaptation manager, system applications and scheduler.

Simulator and its configuration file Executing the scenarios

CE

Initialize adaptation plans

System Execution on UNISIM-VP

2

AC

Scheduling the applications Connection with Telnet terminal

Binary to be deployed into the simulator

Fig. 16. The generated “C” project that runs on UNISIM-VP

Firstly, the simulator files include the UNISIM-VP and its configuration file which specifies, for example, the binary to

3

Active Configuration

Fig. 17. Executing the specified adaptation scenarios

ACCEPTED MANUSCRIPT

1

As future work to the presented aspect of the SafeAdapt project, firstly, we plan to extend our approach to consider the non-functional requirements such as power consumption and timing constraints during the adaptation modelling. Secondly, further evaluations will be carried out to assess the robustness of the approach by applying it to a number of case studies. Finally, our approach will be extended to enable the system runtime reconfiguration to cope with unanticipated changes.

SafeAdapt Consortium

Not Adaptation Plan Found

We would like to acknowledge and thank the SafeAdapt project partners, without their contributions, the project would not have been possible. The project has nine partners from six European countries. The project partners are:

State to be Injected

Delphi Deutschland GmbH (Germany). DuraCar Holding B.V. (Netherlands). Fico Mirrors S.A. (Spain). Fraunhofer Institute for Embedded Systems and Communication Technology ESK (Coordinator, Germany). French Alternative Energies and Atomic Energy Commission LIST (France). Fundación Tecnalia Research & Innovation (Spain). Pininfarina SPA (Italy). Siemens AG (Germany). TTTech Computertechnik AG (Austria).

AN US

   

2 No adaptation actions to be performed

M



Fig. 18. Injecting faults to the running software

6. Conclusion

requirements, and adaptive behavior, the EAST-ADL is used. Second, the design model of the system is transformed to an AutoSAR model which is then used to generate the embedded software system automatically. Finally, to validate the system adaptive behavior, fault injection and monitoring techniques on the UNISIM-VP virtual platform are used.

CR IP T

To inject faults, UNISIM-VP allows instrumenting the variables of the embedded software. An example of an injected fault is shown in Fig. 18, where the states of the running instances are changed by an instrumentation service of the simulator. The state of the instance “ACC2” is set to “Active”, and the state of the instances “ACC0” and “ACC1” are set to “Inactive” (see Fig. 18.2) using our graphical user interface (GUI) shown in Fig. 18.1. When the system manager detects events that trigger an adaptation, it selects a scenario which is then executed in response to this trigger. In Fig. 18, 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 needs to be defined.

AC

CE

PT

ED

SafeAdapt follows a holistic approach to build adaptable systems in safety-critical environments. It comprises methods, tools, and building blocks for safe system adaptation. It also includes the required certification support of safety-critical systems in the vehicle domain. The technical approach builds on a Safe Adaptation Platform Core (SAPC) encapsulating the basic adaptation mechanisms for re-allocating and updating functionalities in networked automotive control systems. This will be the basis for an interoperable and standardized solution for adaptation and fault handling in the ongoing AUTOSAR. The SafeAdapt approach also considers functional safety with respect to the applicable standard ISO26262 and intends to reflect attained results back into such standardization bodies. The SafeAdapt project has provided 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 the realistic validation of the adaptation and redundancy concepts, an actual prototype of the vehicle with different and partly redundant system applications has been developed. In this paper, we presented an aspect of the project which is model-driven simulation. This aspect assists the system engineers in validating the adaptive behavior of an embedded software system. First, to model system functionality, timing

   

The SafeAdapt project has been started in 1st July 2013 with a total duration of 36 months. The total cost of the project is € 9.2 million which includes € 5.9 million that has been funded by the European commission.

References [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. M. Rezvanizaniani, Z. Liu, Y. Chen, J. Lee, "Review and recent advances in battery health monitoring and prognostics technologies for electric vehicle (EV) safety and mobility," Journal of Power Sources, vol. 256, pp. 110-124, June 2014. [4] D. B. Richardson, "Electric vehicles and the electric grid: A review of modeling approaches, Impacts, and renewable energy integration," Renewable and Sustainable Energy Reviews, vol. 19, pp. 247-254, March 2013. [5] K. V. Prasad, M. Broy and I. Krueger, "Scanning Advances in Aerospace and Automobile Software Technology," Proceedings of the IEEE, vol. 98, no. 4, pp. 510-514, April 2010.

ACCEPTED MANUSCRIPT

[6] S. Fürst, "Challenges in the design of automotive software," in Design, Automation & Test in Europe (DATE), Dresden, Germany , 2010, pp. 256-258.

https://www.utwente.nl/ctit/research/research_projects/concluded/int ernational/artemis/iland/ [27] IPAC: Integrated Platform for Autonomic Computing. [Online]. http://ipac.di.uoa.gr/

[7] 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. 55-71.

[28] 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

[8] U. Hackenberg. (2017, Jan.) Autonomous driving feasible by 2028. [Online]. http://www.automotiveit.com/vws-hackenberg-saysautonomous-driving-feasible-by-2028/news/id-00129

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

[9] S. Chakraborty, M. Lukasiewycz, C. Buckl, S. Fahmy, N. Chang, S. Park, Y. Kim, P. Leteinturier, and H. Adlkofer, "Embedded systems and software challenges in electric vehicles," in the Conference on Design, Automation and Test in Europe (DATE '12), San Jose, CA, USA, 2012, pp. 424-429.

CR IP T

[30] Grüttner, K., Hartmann, P.A., Hylla, K., Rosinger, S., Nebel, W., Herrera, F., Villar, E., Brandolese, C., Fornaciari, W., Palermo, G., Ykman-Couvreur, C., Quaglia, D., Ferrero, F., Valencia, R., "The COMPLEX reference framework or HW/SW co-design and power management supporting platform-based design-space exploration," Microprocessors and Microsystems, vol. 37, pp. 966-980, 2013.

[10] "DO-297: Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations," Radio Technical Commission for Aeronautics Inc. (RTCA), 2005.

[31] F. Herrera, H. Posadas, P. Peñil, E. Villar, F. Ferrero and R. Valencia, "An MDD Methodology for Specification of Embedded Systems and Automatic Generation of Fast Configurable and Executable Performance Models," in International Conference on Hardware/Software Codesign and System Synthesis (CODES+ISSS'2012), Tampere, Finland, October 2012, pp. 529– 538.

[11] D. Reinhardt and M. Kucera, "Domain Controlled Architecture," in Third International Conference on Pervasive and Embedded Computing and Communication Systems, Barcelona, Spain, 2013.

[13] 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. [14] 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. [15] SafeAdapt: Safe Adaptive Software for Fully Electric Vehicles. [Online]. http://www.safeadapt.eu/

M

[16] A.Ruiz, G. Juez, P. Schleiss, and G. Weiss. , "A safe generic adaptation mechanism for smart cars ," in International Symposium on Software Reliability Engineering (ISSRE) , Washington, DC, USA, 2015, pp. 161-171.

ED

[17] "ISO/DIS 26262: Road vehicles – Functional safety," International Organization for Standardization (ISO), 2011. [18] 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.

[20] UNISIM Virtual vp.org/site/index.html

PT

[19] (2010, Dec.) AUTOSAR Consortium, AUTOSAR. [Online]. http://www.autosar.org/ Platforms.

[Online].

http://unisim-

CE

[21] 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.

AC

[22] ACTORS: Adaptivity and Control of Resources in Embedded Systems. [Online]. http://cordis.europa.eu/project/rcn/85458_en.html

[32] D. Garlan, S. Cheng, A. Huang, B. Schmerl, and P. Steenkiste, "Rainbow: Architecture-Based Self-Adaptation with Reusable Infrastructure," Computer , vol. 37, no. 10, October 2004.

AN US

[12] B. Morin, O. Barais, G. Nain, and J. Jezequel , "Taming Dynamically Adaptive Systems using models and aspects," in the 31st International Conference on Software Engineering, 2009.

[33] R. Rouvoy, P. Barone, Y. Ding, F. Eliassen, S. Hallsteinsen, J. Lorenzo, A. Mamelli, and U. Scholz, "MUSIC: Middleware Support for Self-Adaptation in Ubiquitous and Service-Oriented Environments," Software Engineering for Self-Adaptive Systems, vol. LNCS 5525, pp. 164-182, 2009. [34] W. Heaven, D. Sykes, J. Magee, and J. Kramer, "A Case Study in Goal-Driven Architectural Adaptation," Software Engineering for Self-Adaptive Systems, vol. LNCS 5525, pp. 109-127, 2009. [35] S. S. Andrade and R. J. de Araujo Macedo, "A non-intrusive component-based approach for deploying unanticipated selfmanagement behaviour," in Software Engineering for Adaptive and Self-Managing Systems (SEAMS '09), 2009. [36] G. Hermosillo, L. Seinturier, and L. Duchien, "Creating ContextAdaptive Business Processes," in Int. Conference on ServiceOriented Computing, San Francisco, CA, USA, 2010. [37] M. Autili, L. Berardinelli, V. Cortellessa, A. Marco, D. Ruscio, P. Inverardi, and M. Tivoli, "A Development Process for Self-adapting Service Oriented Applications," in 5th international conference on Service-Oriented Computing, 2007. [38] Q. Z. Sheng, S. Pohlenz, J. Yu, H. S. Wong, A. H. H. Ngu, and Z. Maamar, "ContextServ: A platform for rapid and flexible development of context-aware Web services," in 31st International Conference on Software Engineering, 2009. [39] 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. [40] T. D. Schutter, "Better Software. Faster! Best Practice in Virtual Prototyping," in Synopsys press, USA, 2014.

[23] HEMIS: electrical powertrain Health Monitoring for Increased Safety in FEVs. [Online]. http://cordis.europa.eu/project/rcn/104132_en.html

[41] 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.

[24] 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.

[42] 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.

[25] DYSCAS: Dynamically Self Configuring Automotive Systems. [Online]. http://cordis.europa.eu/pub/ist/docs/dir_c/ems/dyscasv1_en.pdf [26] iLand: mIddLewAre for deterministic dynamically reconfigurable NetworkeD. [Online].

[43] 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

ACCEPTED MANUSCRIPT

Project PDCS-2 Open Workshop LAAS/CNRS, San Miniato, Italy, 1993, pp. 461-483.

[53] 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.

[44] 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.

[54] O. Scheickl, M. Rudorfer, "Automotive Real-Time Development Using Timing augmented AUTOSAR Specification, BMW Car IT," in 4th European Congress Embedded Real-Time Software (ERTS 2008), Toulouse, France, January 29 - February 1, 2008.

[45] D. Penha, G. Weiss, and A, Stante, "Pattern-Based Approach for Designing Fail- operational Safety-Critical Embedded Systems," in 13th International Conference on Embedded and Ubiquitous Computing, Paris, France, 2015, pp. 52-59.

[55] M. Fowler, "UML Distilled: A Brief Guide to the Standard Object Modeling Language (3 ed.).," , Boston, MA, USA, 2003.

[46] J. Frtunikj, J. Frohlich, T. Rohlfs, and A. Knoll, "Qualitative evaluation of fault hypotheses with non-intrusive fault injection," in IEEE International Symposium on Software Reliability Engineering Workshops, Washington, DC, USA, 2015, pp. 160-167.

CR IP T

[56] 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.

[47] G. Weiss, P. Schleiss, and C. Drabek, "Towards flexible and dependable E/E-architectures for future vehicles," in 4th International Workshop on Critical Automotive Applications: Robustness & Safety, Göteborg, Sweden, September 6, 2016.

[57] (2017, April) Arctic Studio. https://www.arccore.com/products/arctic-studio

[Online].

[49] M. Sadjadi, E. P. Kasten, and B. H. C. Cheng, and P. K. McKinley, S., "Composing adaptive software," IEEE Computer, vol. 7, no. 37, pp. 56-64, 2004.

[59] Ernest Wozniak, Model-based Synthesis of Distributed Real-time Automotive Architectures. Orsay, France: University of Paris-Sud, 2014.

[50] M. Zeller, G. Weiss, D. Eilers, R. Knorr, "An approach for providing dependable self-adaptation in distributed embedded systems," in the 2011 ACM Symposium on Applied Computing (SAC '11), TaiChung, Taiwan, 2011, pp. 236-237.

[60] J. Tatibouet, A. Cuccuru, S. Gérard, F. Terrier, "Towards a Systematic, Tool-Independent Methodology for Defining the Execution Semantics of UML Profiles with fUML ," in MODELSWARD, 2014.

[51] P. Oreizy, M. Gorlick, R. Taylor, D. Heimbigner, G. Johnson, N. Medvidovic, A. Quilici, D. Rosenblum, A. Wolf, "An ArchitectureBased Approach to Self-Adaptive Software," IEEE Intelligent Systems, vol. 14, no. 3, pp. 54-62, 1999.

M

[52] G. Weiss, M. Zeller, D. Eilers, and R. Knorr, "Towards Selforganization in Automotive Embedded Systems," in the 6th International Conference on Autonomic and Trusted Computing (ATC'09), Brisbane, Australia, 2009, pp. 32-46.

AN US

[48] (2012, Jan.) TTTech, TTEthernet. [Online]. http://www.tttech.com/products/ttethernet/technology.html

[58] 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 realtime systems (MBEERTS'07), Berlin, Heidelberg, 2007, pp. 361-368.

PT

ED

Mahmoud Hussein received his BSc. and MSc. in Computer Science from Menoufia University, Faculty of Computers and Information in 2006 and 2009 respectively and received his PhD in Software Engineering from Swinburne University of Technology, Faculty of Information and Communications Technology in 2013. His research interest includes Software Engineering, Data Mining, Machine Learning, Data Privacy, and Security. Currently, He is working as postdoctoral researcher at Laboratory of Model Driven Engineering for Embedded and Real-Time Systems, CEA/LIST, France.

AC

CE

Reda Nouacer is a research engineer at CEA, LIST, Software Reliability and Security Laboratory where he works on design space exploration and virtual platforms. Before, he worked at Prosilog SA and then at Texas Instruments. His research interests include design space exploration, hardware simulation, and dependability using virtual platforms. Reda NOUACER is and has been involved in many interdisciplinary national and international basic research projects as well as industrial research projects. He earned a HW/SW Engineer degree and the Magister degree in Computer Engineering from the Badji–Mokhtar University (AnnabaAlgeria). His thesis entitled „CAMELEON: A Parallel Architecture Emulator‟ summarizes his work on building a low-cost emulator of parallel architectures for parallel programs validation. Ansgar Radermacher did his PhD thesis at the technical university of Aachen. He then worked for Siemens Corporate Technology in Munich in the domain of software for embedded and automotive systems. In 2004, he joined the model-driven engineering team of the CEA/LISE laboratory, working in the area of embedded and real-time middleware technology and execution platforms for UML models. Technically, his work is integrated in the open-source, Eclipse-based UML editor Papyrus. He designed the execution support for component models with flexible interactions. Ansgar contributed to the OMG standards QoS for CCM, DDS for CCM and UCM. Currently, he is working on model-code synchronization and re-configuration, validation and safety aspects of generated code.