Maged Khalil
email: khalil@fortiss.org|schaetz@fortiss.org|voss@fortiss.org

Bernhard Schätz

Sebastian Voss

A Pattern-based Approach towards Modular Safety Analysis and Argumentation

Keywords: Safety-critical systems, pattern-based design, architectures, safety cases, automotive

Safety standards recommend (if not dictate) performing many analyses during the concept phase of development as well as the early adoption of multiple measures at the architectural design level. In practice, the reuse of architectural measures or safety mechanisms is widely-spread, especially in well-understood domains, as is reusing the corresponding safety-cases aiming to document and prove the fulfillment of the underlying safety goals. Safety-cases in the automotive domain are not well-integrated into architectural models and as such do not provide comprehensible and reproducible argumentation nor any evidence for argument correctness. The reuse is mostly ad-hoc, with loss of knowledge and traceability and lack of consistency or process maturity as well as being the most widely spread and cited drawbacks.

Using a simplified description of software functions and their most common error management subtypes (avoidance, detection, handling, ..) we propose to define a pattern library covering known solution algorithms and architectural measures/constraints in a seamless holistic model-based approach with corresponding tool support. The pattern libraries would comprise the requirement the pattern covers and the architecture elements/ measures / constraints required and may include deployment or scheduling strategies as well as the supporting safety case template, which would then be integrated into existing development environments. This paper explores this approach using an illustrative example.

Introduction

From advanced driver assistance and hybrid drives over autonomous high-speed rail and high precision medical equipment to Unmanned Aerial Vehicles: software-intensive systems that perform safety-critical tasks are increasingly prevalent and pervasive in today's world. Driven by the incessant increase in the number of integrated control units, communication systems and software, managing architectural complexity, let alone mastering it, is becoming an increasingly difficult task. This difficulty in turn translates into a heightened possibility of design and implementation errors going undetected with hazardous consequences. This challenging situation is further exacerbated by the coupling of new development methods being employed for innovative technologies with increasingly complex international safety standards. Safety standards recommend (if not dictate) performing many analyses during the concept phase of development as well as the early adoption of multiple measures at the architectural design level [START_REF]Certification considerations for highly integrated aircraft[END_REF], [START_REF]178B: Software considerations in airborne systems and equipment certification[END_REF], [START_REF]178C: Software considerations in airborne systems and equipment certification[END_REF], [START_REF]European Committee for ElectroTechnical Standardization, EN-50126 Railway Standard[END_REF], [START_REF]Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems[END_REF], [START_REF]ISO 26262 Standard, Road Vehicles Functional Safety[END_REF], most of which has become part of the day-to-day business of safety-critical development, yet has to receive adequate tool support. This is particularly true if one wishes to front-load these aspects into an integrated solution environment, in which these (mostly) repetitive tasks can be automated. Dealing with non-functional requirements, especially safety, at later development stages is difficult and highly costly [START_REF] Breitman | The World's Stage: A Survey on Requirements Engineering Using a Real-Life Case Study[END_REF], [START_REF] Cysneiros | Integrating Non-Functional Requirements into Data Model[END_REF], [START_REF] Lindstrom | Five Ways to Destroy a Development Project[END_REF].

Because these analyses and architectural measures have to be conducted during the design phase of the systems, they cannot be based on physical prototypes and implemented software, and, hence, have to rely on the design information in terms of requirements, the structural design, functional specifications, and the principled knowledge about the (nominal and potential deviating) behavior of the components used [START_REF]Funktionale Sicherheit: Grundzüge sicherheitstechnischer Systeme[END_REF]. The field of model-based problem solving [START_REF] Struss | A Conceptualization and General Architecture of Intelligent Decision Support Systems[END_REF] has generated theoretical foundations, prototypical solutions, and products for modeling artifacts and natural systems and for using models to solve a variety of tasks, with a major focus on automated diagnosis, but also solutions for failure modeling as well as for automated software FMEA [START_REF] Price | An Automated Software FMEA[END_REF], [START_REF] Struss | Automated Model-based FMEA of a Braking System[END_REF].

The use of patterns in safety-critical software development in conjunction with model-based development techniques is documented and well suited for these needs. Patterns of safety cases for well-known problems have been suggested in academic literature as well [START_REF] Kelly | Safety case construction and reuse using patterns[END_REF], [START_REF] Wagner | A Case Study on Safety Cases in the Automotive Domain: Modules, Patterns, and Models[END_REF], [START_REF] Khalil | Pattern-based methods for model-based safety-critical software architecture design[END_REF], [START_REF] Weaver | The Safety of Software -Constructing and Assuring Arguments[END_REF], [START_REF] Hawkins | Using a Software Safety Argument Pattern Catalogue: Two Case Studies[END_REF], [START_REF] Ye | Justifying the Use of COTS Components within Safety Critical Applications[END_REF] and [START_REF] Wu | Safety Tactics for Software Architecture Design[END_REF]. A safety case is "a documented body of evidence that provides a convincing and valid argument that a system is adequately SAFE for a given application in a given environment", where an argument is "a connected series of claims intended to establish an overall claim." A safety case should communicate a clear, comprehensive and defensible argument that a system is acceptably safe to operate in a particular context [START_REF] Kelly | The Goal Structuring Notation . A Safety Argument Notation[END_REF].

Reuse in a safety-critical context, and particularly the reuse of safety cases, is neither systematic nor adequate [START_REF] Kelly | Safety case construction and reuse using patterns[END_REF]. In this paper we will show how reuse is simplified in a safety-critical context through the encapsulation of all information into a library element, along with the corresponding safety case to support it.

Chapter 2 details the problem. Chapter 3 explains our approach and gives an example of a pattern library element, as well as its usage in a wider context. In chapter 4 we discuss the impact of this contribution and, in conclusion, we summarize our work and detail open research questions and future work in Chapter 5.

Problem

In practice, the reuse of architectural designs, development artifacts and entire code sequences is widely-spread, especially in well-understood domains. This trend holds true for the development of safety-critical products, with well-established architectural measures and safety mechanisms in wide reuse, as is reusing the corresponding safety-cases aiming to document and prove the fulfillment of the underlying safety goals. This however, is marred by several problems:

• Safety-cases in the automotive domain are not well integrated into architectural models and as such • they do not provide comprehensible and reproducible argumentation • nor any evidence for the correctness of the used arguments.

• Most analyses (FMEA, FTA, etc.) have to be performed at system level, yet the components/ measures / safety mechanisms themselves need to be reused independently, • and are not tied in any structured manner to other elements needed to provide the relevant context.

The reuse of safety-cases is mostly ad-hoc, with loss of knowledge and traceability and lack of consistency or process maturity as well as inappropriate artifact reuse being the most widely spread and cited drawbacks [START_REF] Kelly | Safety case construction and reuse using patterns[END_REF].

The typical reuse scenario would, in this context, involve reusing an architectural measure or design pattern, e.g., homogenous (hardware) duplex redundancy, in which a vulnerable critical single processing channel is duplicated to increase reliability as seen in Fig. [START_REF]Certification considerations for highly integrated aircraft[END_REF], or a development artifact, such as a comparator function. If the previous safety case is at all reused, it serves as a detached guide of what needs to be provided to close the case, i.e. serving a prescriptive role, which is better than nothing.

Figure (1): Homogenous (Hardware) Duplex Redundancy Pattern

Yet be it the design pattern or the development artifact, the single item does not tell the entire story. For example, to correctly deploy homogenous redundancy, many other aspects have to be covered:

• one has to define the requirements the pattern fulfills, • refine the requirements and draw up a specification, • detail a (logical) component architecture,

• and optimize a deployment strategy that guarantees the duplicate components will not run on the same hardware resource.

This has to be preceded by checking the availability or making the explicit assumption that the system layout allows, for example, a second hardware channel, which is a contextual bit of information. This is not all; to justify reusing this pattern, one would also have to include any tests or information proving that this particular pattern is suitable for the goal it targets.

Finally, all parts comprising this information, as well as their relations, which are more complex than simple tracing, must be captured in a comprehensive and comprehensible manner which should also provide a suitable interface to the environment the reused element will be deployed in.

As such, the reuse of well-understood and trusted design patterns or safety mechanisms cannot be confined to reusing the central artifact alone. Much of the information, in this case highly critical information, remains trapped in the heads of the developer and if mentioned at all retains a high measure of implicitness.

This gives rise to the need of some kind of encapsulation of the reusable safety mechanism (with requirements, specification, components, etc.), along with a minimum set of guarantees that can be achieved at that level and support via a solid argumentation.

Approach

Using a simplified description of software functions and their most common error management subtypes (avoidance, detection, handling, ..) it is possible to define a pattern library covering known solution algorithms and architectural measures/constraints in a seamless holistic model-based approach with corresponding tool support. The pattern libraries would comprise the requirement the pattern covers and the architecture elements/ measures / constraints required and may include deployment or scheduling strategies as well as the supporting safety case template, based on the established structure notation known as GSN [START_REF] Kelly | Goal Structuring Notation (GSN). GSN COMMUNITY STANDARD VERSION 1, Origin Consulting[END_REF] which would then be integrated into existing development environments. This enables an early analysis of hazards and risks, which is recommended by many safety standards. Subsequently, fault types can be matched both to probable hazards but more importantly to the problem categories they fall into or are most similar to, from a system architecture design viewpoint. Combining this with known architectural constraints and patterns for solving them, we can thus reason about which types of architectural patterns are relevant for the system under analysis. The fault types, along with their requirements, are bundled with solution arguments, comprising components, their (sub-) architectures, deployment plans and schedules, into pattern libraries, which are rounded up by the corresponding safety-case templates or skeletons to provide argumentation for achieving the goals.

Underlying the approach is the consistent use of patterns from the categorization of hazard types, over the abstract modeling of the respective safety concepts, and down to their implementation in the system architecture description, with a focus on providing argument chains in a seamless model-based environment.

In this paper, we mainly focus on the contents of the library of reusable patterns, and the necessary structure of the problem and solution patterns to support a structured description of the argument and provide the necessary seamless integration into a model-based system development environment. While we furthermore sketched the necessary mechanisms for the application of those patterns and the checking of the constructed argument, automation via tool-support is essential to achieve the intended advantages.

Figure [START_REF]178B: Software considerations in airborne systems and equipment certification[END_REF] gives a sketch of a generic library element with some, not all, possible content, side by side with the supporting safety case view. The left part of the schematic gives possible parts of the reusable pattern, as detailed in Chapter 2, while the right part shows the corresponding safety case and connections to the relevant artifacts, displayed in a graphical notation using GSN.

Figure (2): Generic Pattern Library Element

While the left part of the schematic can entirely originate in one seamless tool, as will be shown in our implementation example in Section 3.1, this is not necessary. The development artifacts may reside in multiple repositories and be in varying formats; the binding element is the safety case shown on the right hand side, which gives the story and rationale behind the reusable pattern. This particular aspect is particularly important for reuse in a safety-critical development context.

Figure (3): Data Model for GSN Representation

In our work we evaluated several possible ways to express safety cases and settled on the Goal Structuring Notation (GSN), in its Community Standard Version 1.0 [START_REF] Kelly | Goal Structuring Notation (GSN). GSN COMMUNITY STANDARD VERSION 1, Origin Consulting[END_REF], as it was the most mature option suited to our needs. GSN is a structured (yet not formal) notation, which provides graphically differentiated basic safety case element types, such as goals, evidence, strategy, justification and so on, as well as a clear description of necessary and allowed connection types between these elements. A data model of safety cases according to GSN is provided in figure [START_REF]178C: Software considerations in airborne systems and equipment certification[END_REF]. A comparison with the Toulmin argumentation pattern used in EAST-ADL 2.1 is provided in [START_REF]Proposal for extension of Meta-model for safety-case modeling and documentation[END_REF]. An illustrative implementation example is given in section 3.2.

Pattern types

The library of patterns can be categorized according to types, such as problem patterns, design patterns, and so on. As patterns may in fact belong to or satisfy more than one category, a cross referencing system using keywords will more likely be a more adequate approach. This will be explored in further work.

The use of patterns in the development of safety-critical products is already in wide spread use. Catalogues exist [START_REF] Wu | Safety Tactics for Software Architecture Design[END_REF] that discuss highly organized and well-known safety mechanisms, such as comparators or "1outof2" voters. Safety case templates can be generated, stored and reused for many categories of patterns. Some of these patterns are truly abstract and tackle higher system description levels, such as the "High Level Software Safety Argument Pattern Structure" presented in [START_REF] Hawkins | Using a Software Safety Argument Pattern Catalogue: Two Case Studies[END_REF], while some can target a certain context, such as the use of Commercial Off The Shelf Components (COTS) in a safety-critical context, as discussed in [START_REF] Ye | Justifying the Use of COTS Components within Safety Critical Applications[END_REF].

Safety case patterns can also be grouped according to their applications, such as:

• Strategy (Problem solving) patterns
The range of problems developers in a domain face, and subsequently the algorithms they favor in solving them, are not unlimited. By identifying recurring paradigms and analyzing them, it is possible to generate templates of their safety cases. The strategy node is the core element of the actual argumentation in a problem pattern safety case template, supporting the justification of goals being fulfilled by sub-goals. By applying strategy patterns, it is possible to build argumentations using only accepted justifications. This way confidence in the correctness of the argument can be increased. Still the appropriateness and correct use of a pattern has to be evaluated before trusting a safety case, but the question of the fundamental validity of each single argumentation step itself need not be argued. On the long run, it is desirable to establish general and domain-specific patterns as a pattern library for a faster and easier creation of safety arguments [START_REF] Wagner | A Case Study on Safety Cases in the Automotive Domain: Modules, Patterns, and Models[END_REF].

Example: Logical transformation

The required safety goal is a logical combination leading to desirable or undesirable situations. It is possible to generate a safety case skeleton that represents the pattern of avoiding a situation in which the constraint is violated, e.g. to keep the gap to the forward car larger than or equal to a minimum safe distance in an adaptive cruise control. This is simplified by transforming the goal into avoiding a gap which is smaller than the safe distance [START_REF] Wagner | A Case Study on Safety Cases in the Automotive Domain: Modules, Patterns, and Models[END_REF], as shown in figure [START_REF]European Committee for ElectroTechnical Standardization, EN-50126 Railway Standard[END_REF].

Figure (4): Logical Transformation Pattern for ACC distance control [15]

• Design (Constraints) patterns Safety standards, such as the ISO26262, require that component architectures, independently of their functionalities, display certain characteristics or adhere to constraints. Some of these such as modularity, simplicity, and an adequate level of granularity and encapsulation are simply good engineering practices aimed at avoiding failures arising from unnecessary complexity.

Other requirements, such as freedom from interference, which is the absence of dependent failures (cascading and common cause failures) in safety-critical components [START_REF]ISO 26262 Standard, Road Vehicles Functional Safety[END_REF], are aimed at guaranteeing correct operation of safety-critical functions.

According to ISO26262, there are several ways for components to have freedom from interference. The components can be deployed redundantly, or be functionally diverse (the use of totally different approaches to achieve the same results), or be based on diverse technologies (the use of different type of equipment to perform the same result), or be physically separated such that foreseeable failures do not affect redundant safety-related systems and so on.

Example: Redundancy

The guidelines above have in turn matured into various design patterns, many of which revolve around redundancy and partitioning, which is the separation of functions or component elements to achieve a design, which can be used for fault containment to avoid cascading failures. The design patterns vary in their addressed context, structure, and presented solution and can be categorized in many ways. For example, for redundancy alone, [START_REF] Armoush | Design Patterns for Safety-Critical Embedded Systems[END_REF] lists 8 hardware patterns, i.e. patterns that contain explicit hardware redundancy, 5 Software patterns, and two combined patterns.

All of the above patterns do however, represent one general paradigm and as such can be covered by a general safety case pattern template as shown in figure [START_REF]Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems[END_REF], namely that of solving the lack of confidence in the safetycritical channel using a redundancy strategy. This general template can in turn be instantiated and subsequently further specified and extended to suit the specific case and used solution, for example using context elements [START_REF]Proposal for extension of Meta-model for safety-case modeling and documentation[END_REF], and would for the case of our Homogeneous Duplex Redundancy Pattern example yield the more detailed safety case discussed in the example in section 3.2 and seen in figure [START_REF]ISO 26262 Standard, Road Vehicles Functional Safety[END_REF]. The choice of which method or pattern to employ depends on the system constraints, and thus does not tell the whole story on its own.

Figure (5): Pattern Library Element: Homogeneous Duplex Redundancy Pattern [18]

As shown by the example in the following section, the approach should lend itself well to any well-understood reusable pattern or component. We will implement further examples in future work.

Implementation example

We have carried out a specification in the integrated development environment for the ITEA2 SAFE project [START_REF]The ITEA2 SAFE Project / The EUROSTARS SAFE-E Project[END_REF], [START_REF]Proposal for extension of Meta-model for safety-case modeling and documentation[END_REF] as well as examined a proof-of-concept in the research CASE tool AUTOFOCUS3(AF3) [START_REF]AutoFOCUS 3, research CASE tool[END_REF] to support seamless safety-case modeling and partially automated generation in a model-based development environment. While we haven't yet fully implemented a library, preliminary results show the approach is feasible and should scale well. This will be proven at a later stage when safety cases are fully supported in AF3.

It also identified compositionality of argumentation as being a major hurdle and open research question for the successful reuse of safety cases. The underlying approach was well received by the reviewing OEM advisory board industry experts (SAFE project) and published in [START_REF]Proposal for extension of Meta-model for safety-case modeling and documentation[END_REF], [START_REF] Khalil | Pattern-based methods for model-based safety-critical software architecture design[END_REF] and [START_REF] Voss | A step towards Modular Certification using integrated model-based Safety Cases[END_REF].

Using the example of homogenous hardware redundancy, introduced in Chapter 2 and shown in figure [START_REF]Certification considerations for highly integrated aircraft[END_REF], figure [START_REF]ISO 26262 Standard, Road Vehicles Functional Safety[END_REF] shows an exemplary pattern library element. On the left are snapshots of screen grabs of potential candidate functionalities for the generation of pattern artifacts from the research CASE tool AF3 [START_REF]AutoFOCUS 3, research CASE tool[END_REF] [21] [START_REF] Voss | Deployment and Scheduling Synthesis for Mixed-Critical Shared-Memory Applications[END_REF] and on the right is the corresponding (simplified) safety case.

Figure (6): Pattern Library Element: Homogeneous Duplex Redundancy Pattern

This single reusable pattern element would thus contain the requirements and their refinement, specification, logical components and logical architecture design, deployment strategy as well as all relevant tests and their results, held together by the links from all relevant artifacts to the corresponding safety case elements. Using the relations described in the GSN data model described in figure [START_REF]178C: Software considerations in airborne systems and equipment certification[END_REF], it is possible to perform completeness and consistency checks on the safety case, such as "solutions must stem from goals and no other elements" or "no open goals remain". All the information required to reuse the pattern is now encapsulated in a clear defensible package, enabling modular argumentation.

Modular and compositional argumentation

The use of patterns as a way of documenting and reusing successful safety argument structures was pioneered by Kelly [START_REF] Kelly | Arguing Safety -A Systematic Approach to Managing Safety Cases[END_REF], who developed an example safety case pattern catalogue which provided a number of generic solutions identified from existing safety cases. Although providing multiple useful generic argument strategies, the catalogue merely represents a cross-section of useful solutions for unconnected parts of arguments. The safety argument pattern approach was further developed by Weaver [START_REF] Weaver | The Safety of Software -Constructing and Assuring Arguments[END_REF], who specifically developed a safety pattern catalogue for software. The crucial difference being that this catalogue not only specifically targeted software aspects of the system under development, the set of included patterns were specifically designed to connect together in order to form a coherent argument. The solution was, however, not generic.

A number of weaknesses have since been identified with Weaver's pattern catalogue. First, the patterns take a fairly narrow view of assuring software safety, in that they focus on the mitigation of known failure modes in the design. Mitigation of failure modes is important, but there are other aspects of software assurance which should be given similar prominence. Second, issues such as safety requirement traceability and mitigation were considered at a single point in Weaver's patterns. This is not a good approach; as it does not reflect the building up of assurance relating to traceability and mitigation over the decomposition of the software design. Finally, Weaver's patterns have a rigid structure that leaves little scope for any alternative strategies that might be needed for novel technologies or design techniques [START_REF] Hawkins | Using a Software Safety Argument Pattern Catalogue: Two Case Studies[END_REF].

A software safety pattern catalogue was also developed by Ye [START_REF] Ye | Justifying the Use of COTS Components within Safety Critical Applications[END_REF], specifically to consider arguments about the safety of systems including COTS software products. Ye's patterns provide some interesting developments to Weaver's, including patterns for arguing that the evidence is adequate for the assurance level of the claim it is supporting [START_REF] Hawkins | Using a Software Safety Argument Pattern Catalogue: Two Case Studies[END_REF].

These approaches all focused on generating safety case templates for known patterns, whereas the safety case templates alone are the end result. Our approach encourages the encapsulation of the reusable development artifacts along with the supporting safety cases to enable true and speedy reuse in a safety-critical context.

The cognitive process of employing patterns is a fairly straightforward example of normal human pattern matching; the developer finds a problem or need, which can be expressed in a requirement, namely to eliminate the problem or satisfy the need, and then proceeds to firstly recall similar past problems and subsequently identify the most probable solution, based on his experience. Thus the entry point is a goal, which the developer believes they can satisfy by reusing previously successful solutions. We postulate the same adage holds for employing our patterns library elements. The interface to the system, whose problems the pattern solves, would be at the safety goal boundary.

To illustrate this we return to the example provided in section 3.1 and the corresponding safety case shown in figure [START_REF]European Committee for ElectroTechnical Standardization, EN-50126 Railway Standard[END_REF]. The arbitrator we choose to employ can be a COTS HW/SW unit we buy from a trusted supplier who also provides the corresponding detailed safety case for the arbitrator. That (sub-) safety case would then snap on to the larger safety case, shown in figure [START_REF]European Committee for ElectroTechnical Standardization, EN-50126 Railway Standard[END_REF], at the safety sub-goal G1.2.2 it satisfies. The entire safety case in figure (4) would then itself snap into the parent (system) safety case at the G1 goal boundary defining its purpose, and this process would repeat itself hierarchically and cumulatively. As such, satisfying all the system's goals at the interface would enable not only modular but also compositional argumentation. This approach does, however, give rise to at least three as yet open questions:

1-Is the safety goal the most adequate boundary interface for modular compositional argumentation? 2-How do we guarantee that all goals (and sub-goals) have been identified? and more importantly, 3-How do we guarantee that the introduced pattern or component has no negative impact on the system?

The answers to these questions lie outside the scope of this paper and are the subject of future work.

Impact and use

The design of functional-safety systems is largely driven by best practices -like use of fault monitors, safe states, or redundant paths. These best practices can often be presented in form of patterns -both to describe a possible solution but also to document an argumentation about their contribution to a safety case. The provision of library of such patterns allows the identification and (re-)use of suitable architectural measures and of corresponding components along with their safety cases in a pattern-library based approach that allows compositional argumentation about the achieved safety goals. Thus, it contributes to the optimization of the development with respect to system safety in general, and specifically to safety-critical component reuse, but also COTS (Commercial Of-The Shelf) components. It further more provides support for the "Safety Element out of Context" clause cited in safety standards, such as the ISO26262 [START_REF]ISO 26262 Standard, Road Vehicles Functional Safety[END_REF].

Conclusion and future work

This paper presents a concise overview of pattern-based methods for safety analysis and argumentation, a pattern-based approach for the encapsulated reuse and modular argumentation in a safety-critical context and an outlook at tool implementation. We furthermore explored the possibilities and show the opportunities supported by this approach. A holistic pattern-based approach to the construction of safety-cases in a seamless model-based development of safety-critical systems requires several elements, the main constituents of which we have identified. These are:

1-

A library of reusable argumentation patterns -both in form of problem patterns (e.g., faults like early, late, or wrong sensor information; temporal or spatial interference between functions) and solution patterns (e.g., error avoidance, detection, mitigation; sensor fault detection and correction mechanisms; partitioning mechanisms) -built from elements of a model-based description of the system under development (e.g., requirements, functions, SW-/HW-components, channels, busses, deployment strategies) as well as GSN safety cases (e.g., goals, solutions, justifications, contexts)

2-

A mechanism for the instantiation (e.g., stuck at-/noise-like faults; different filter for fault detection) and application (e.g., linking to the corresponding HW-and SW-elements) of those patterns in a compositional fashion.

3-

A mechanism to check the soundness of the constructed argumentation (e.g., no open sub-goals; all context are covered by corresponding system elements) w.r.t. to its structure.

Using the example in Section 3.1, we have discussed the feasibility of (at least partially) handling all three of the above points.

In the next step we are focusing on expanding our pattern library with more implementation examples to test for general application and scalability as well as examining adequate methods for cross-referencing and categorizing patterns. The following stage will tackle the research questions pertaining to the compositionality of argumentation discussed briefly in section 3.3, particularly the identification of an appropriate boundary interface for integrating safety cases.

Acknowledgments

The AF3 project is a long term ongoing tools development effort led by the fortiss department of "Software and Systems Engineering". The functionality provided currently by the tool is mainly the result of the joint work of the following persons:

• Florian Hölzl (mailto:hoelzl@fortiss.org): project lead, tooling infrastructure for developing views and modular languages • Sabine Teufl (mailto:teufl@fortiss.org): MIRA -model-based requirements engineering • Mou Dongyue (mailto:mou@fortiss.org): MIRA -model-based requirements engineering (partly under the IMES project [START_REF]IMES -Integrierte modellbasierte Entwicklung softwareintensiver Systeme[END_REF]), model based testing, refinement modelling • Sebastian Voss (mailto:voss@fortiss.org): design space exploration, GSN-based modelling of safety cases, ASIL allocation, and optimized (saftey-oriented) deployment and schedule generation under the SPES XT [30], RECOMP [START_REF] Automotive | [END_REF] and ARAMiS [START_REF] Automotive | [END_REF]projects • Daniel Ratiu (mailto:ratiu@fortiss.org): user friendly formal specification and verification Many thanks also to the other members of the AF3 team.

  Many thanks also go to the project partners from the SAFE/SAFE-E projects. The concept for the pattern-based approach presented in this work is based on the SAFE and SAFE-E projects. SAFE is in the framework of the ITEA2, EUREKA cluster program Σ!3674. The work has been funded by the German Ministry for Education and Research (BMBF) under the funding ID 01IS11019, and by the French Ministry of the Economy and Finance (DGCIS). SAFE-E is part of the Eurostars program, which is powered by EUREKA and the European Community (ID 01|S1101). The work has been funded by the German Ministry of Education and Research (BMBF) and the Austrian research association (FFG) under the funding ID E!6095. The responsibility for the content rests with the authors.

List of references


Matthias Schneider
email: matthias.schneider10@de.bosch.com

Adrian Thomys
email: adrian.thomys@de.bosch.com

PREDICTIVE POWERTRAIN -NEW OPPORTUNITIES BY NETWORKING SYSTEMS

Keywords: ACC, Connected Cruise Control, Connected Systems, Hybrid Control Strategy, Control Unit Interaction, Cross-Systems Networking, Electronic Horizon, Hybrid System, Predictive Powertrain

These days it is not enough to think about downsizing of engines or the use of hybrid systems to keep upcoming CO 2 regulations as well as customer demands. Furthermore most of the vehicles' components are highly optimized. The realization of further significant optimizations is only possible through a connection between these components. Intensive research activities play a major role in making Bosch a market and innovation leader in electronic powertrain and safety systems. And in diesel and gasoline engines as well, there are technological possibilities for reducing consumption even further. What all powertrains have in common is the potential to reduce emissions and fuel consumption even further through networking of existing vehicle systems across all vehicle domains. The advent of electromobility is bringing together two areas of automotive technology that were traditionally regarded in isolation from one another -powertrains and chassis. Furthermore Bosch links automotive systems with data from the electronic horizon, which senses the vehicle's environment and provides a detailed preview of the road ahead. Bosch Engineering GmbH is using cross-system networking within a concept vehicle as well as with external systems to develop new functions. The networking of vehicle systems encompasses the ACC (Adaptive Cruise Control), the electronic stability program ESP® and the whole powertrain (ICE and hybrid). Going beyond vehicle systems, automotive systems are also linked to data from the electronic horizon (interface to navigation system), this feature acts as a sensor to the environment to provide a detailed virtual preview of the route ahead. New functions thereby reduce fuel consumption and increase the level of comfort and safety. This paper provides an overview on the system approach and practical developments of Bosch Engineering in this area.

Introduction

The steady increase in the number of intelligent vehicle systems means that the networking of these systems is playing an increasingly important role. In addition to the challenge of ensuring that these different electronic systems can co-exist effectively, there is also an opportunity to use the networking and interaction of the sensors, actuators and control units to add value in the areas of driving comfort, safety and driving pleasure. These new system solutions are increasingly gaining importance with OEMs and are forcing suppliers to rethink certain areas: Products can no longer only be produced within a development divisionthey must be developed across domains. Bosch Engineering GmbH is acting on this idea and using its advantages as a development service provider with various skills concentrated in one location -this approach is based on the development expertise for Bosch systems in the fields of vehicle dynamics and driver assistance, as well as engine management, hybridization and passive safety. System solutions require an interplay between a wide variety of components; only rarely are these components developed and provided by one supplier. For a service provider to do this, it is crucial that, in addition to networking its own subsystems, it enables integration and interaction with thirdparty systems so that it can offer the customer the best possible overall system. The Bosch Engineering GmbH approach of creating added value through intelligent networking within the vehicle places a primary focus on using only the existing systems in the vehicle and thereby representing new and/or improved functionalities without the need for additional hardware or components. Rather than being restricted to premium-segment vehicles as an optional package, a large number of electronic systems are now increasingly included as standard in mid-range vehicles available in the market. This increases the potential for system solutions, as well as the motivation for new and intelligent approaches that make tangible yet cost-effective functions a reality for end customers. The following figure shows some of these systems, which are currently being used in many vehicles. In reference to the powertrain, the integration of environment information is one way to increase the efficiency of the vehicles during actual driving cycles. Information from a radar and video system can provide information on upcoming events in just the same way as map data stored in a navigation system in combination with the current position, which is determined by GPS. Through this type of interaction between multiple control units, the vehicle can support the driver during anticipatory driving or can itself access the system within the driver's specifications. For example, it can influence the engine start/stop behavior and the loading strategy of hybrid vehicles, comfort optimization of cruise control and speed limitation functionality, as well as the diagnostic cycles and component protection measures. Intelligent networking of systems in the area of driver assistance also creates potential for optimization and enhancement of safety and comfort functions. Interaction with the navigation system plays a crucial role in this regard: Information from the peripheral sensors is combined with information from map data and prospective routes, enabling an anticipatory and thus optimized driving strategy. This allows such factors as speed zones, cornering characteristics and the course of roads to be taken into account, thereby enhancing driver assistance functions or even making them a possibility for the first time. As part of an internal innovation project at Bosch Engineering GmbH, a test vehicle was set up to make intelligent system networking a tangible reality using example functions.

Connected Systems

To illustrate the possibilities of networking in the area of the powertrain, a Porsche Panamera S Hybrid series-production vehicle was used as a platform as part of the "Control Unit Interaction" innovation project. Based on the installed series components, a wide variety of functions in the area of operating strategy, GPS connection and driver assistance have been developed, implemented and tested. This section describes some of these functions and their added value, which is created solely by networking the various existing systems.

Figure 2 Components of the test vehicle

Figure 2 illustrates the components of the test vehicle that were used for functional expansion and thus for networking the systems. Only a navigation PC and rapid prototyping hardware were added to the test vehicle. These components offer quick access to the development platform and would not be required for in series production of the functions presented below, as these components would be replaced by the series control unit and an integrated navigation system.

Curve Assistant

The basic concept of the Curve Assistant is to prepare the driver for the course of the route ahead using map data information. In specific terms, this means providing a visual and acoustic representation of relevant speed limits, curve geometry and curve speeds, as well as the next brake and acceleration point. A smartphone is used here as the HMI (human-machine interface), as shown in Figure 3. Although GPS-based map navigation technology has been established in vehicles for over a decade, it is only recently that map data has started to be used across control units. The basis for this development is the standardized ADASIS protocol created by a range of manufacturers. It provides the control units with data on the route ahead via CAN ("electronic horizon"). In the Bosch innovation, the provider of the ADASIS data stream runs in this case as a prototype on a powerful car PC in the vehicle's trunk. A GPS receiver connected via USB provides the location information. The lack of accuracy and stability of the GPS signal, particularly in forested areas or tunnels, represented a challenge in the implementation of this solution. This was tackled with an intermediary application developed in-house. When used via a Kalman filter in combination with vehicle sensors (speed and acceleration), this enabled precise positioning even when the GPS signal was poor.

Figure 3 HMI of the Curve Assistant

Curve Assistant processes data on an ES910; a control unit for rapid prototyping from the Bosch subsidiary ETAS. This receives the ADASIS protocol of the car PC via CAN and is connected to the vehicle CAN via a second bus. The data output for the display is also completed via CAN, with subsequent radio transmission via Bluetooth to the smartphone. The visual representation and the voiceovers are provided by a specially developed Android app. The Curve Assistant can be set by the user as desired, ranging from comfortable to sporty. In practice, the Curve Assistant has now demonstrated the performance and the range of the concept on numerous customer journeys. This assistant not only offers significant comfort, but can also increase safety and efficiency, particularly on winding country roads with changing speed limits.

Connected ACC

In recent years, the importance of driver assistance systems has risen steadily. Better sensors and more powerful control units have enabled new assistance functions to be developed that support the driver and remove certain driving tasks. One such example is the "Adaptive Cruise Control" (ACC) driver assistance system from Bosch. ACC uses radar to record the vehicle's environment and adjusts the speed to the traffic situation independently by intervening in the powertrain. During normal driving, the system acts as a conventional cruise control system, i.e. it maintains a speed set by the driver. As ACC works on the basis of radar data, it has only a limited amount of information about the route ahead. In particular, curves and changing regulatory speed limits may require the driver to adjust the set speed or to brake. As part of the "Control Unit Interaction" advance development project, Bosch Engineering GmbH has been developing an extension of ACC since 2012 that takes into account information about the route ahead using map data. The system, known as "Connected Cruise Control" (CCC), undertakes full longitudinal control of the vehicle. It does this completely independently in most situations, without the driver, who monitors the function, needing to actively intervene. This makes it the logical next development of the Curve Assistant presented here. The driver has the option to set, as desired, how sporty or economical the vehicle is when driving. It brakes precisely at curves, speed limits and ahead of junctions. This does not affect the normal function of the ACC in any way. If the system detects another vehicle in front of it, then a safe distance is maintained. The function is of course easy to override at any time using the pedal. The CCC receives the information about the route ahead, also known as the "electronic horizon," from the navigation device via the ADASIS protocol. This is a standardized interface definition that allows the navigation device to be connected to the vehicle control units. The CCC can also access all route information in the navigation device, including speed limits, curve radii, intersections and information on the gradient of the road. This data is available even if the driver has not entered a route in the navigation system, meaning is not clear whether he wants to turn or go straight ahead at intersections and turning points. When this occurs, the system calculates the most likely route and provides the relevant details.

Figure 4 Example speed curve

Based on this information and the driver's desired vehicle dynamics, the CCC calculates optimal cornering speeds. Together with the statutory speed limits, this produces a top speed band that the vehicle cannot exceed, making for a safe, legally compliant journey. The speed band is composed of different sections of constant maximum speeds, as shown in red in Figure 4 (horizontal bars). It can be seen that the maximum speed for curves depends on the desired vehicle dynamics. The CCC optimizes the speed trajectory based on the upper speed band. Each section of the speed band is divided into four phases: acceleration, cruise, coasting and braking phase. Since the target speed is known before the acceleration phase starts, a smooth and comfortable acceleration trajectory can be calculated. Depending on the desired vehicle dynamics, acceleration is performed with high power (sport mode) or an attempt is made to keep the engine in its most efficient operating state (efficiency mode). The braking trajectory in the braking phase is also predicted in this way. In efficiency mode, deceleration procedures are normally completed through recuperation and without applying the hydraulic brake. In the cruising phase, the vehicle retains the maximum speed specified by the top speed band at a constant level. Short sections of road between two curves are an exception in this regard: To prevent the vehicle from accelerating and immediately decelerating, the cruising phase continues at a reduced speed, which is significantly more comfortable for the driver. The cruising phase is followed by a coasting phase where the powertrain is switched to the torque-free setting so that the vehicle coasts without consuming fuel. The sportier the CCC setting, the shorter the coasting phase. Figure 4 depicts a typical speed curve using a schematic illustration, and shows the differences between sport mode and efficiency mode. Connected Cruise Control offers the driver a number of advantages: In normal usage, the vehicle undertakes full longitudinal guiding. It is no longer necessary to adjust the set speed, and the accelerator and brake pedal do not need to be operated. This significantly reduces the driver's workload. The driver can be confident that the vehicle is complying with the legal speed limit, and so does not need to look away from the road to check the speed or the set speed on the instrument cluster. In addition to increased comfort, this also enhances driving safety. Additional safety is achieved by the fact that Connected Cruise Control complies precisely with the applicable speed limits. A further advantage is the significantly reduced fuel consumption. Through an adjusted driving strategy and connection to other engine control features, a fuel saving of up to 15% could be achieved. This fuel saving is achieved through a variety of measures: Connected Cruise Control takes into account the circumstances of the powertrain and configures acceleration processes specifically so that the engine is operated in its optimum state. As mentioned above, braking processes in normal conditions are completed solely through recuperation. The extensive coasting phase in efficiency mode reduces fuel consumption further. Based on the calculated driving trajectory, the vehicle is able to brake specifically at speed limits or curves and to accelerate again once these have been cleared. As soon as the driver switches the Connected Cruise Control to sporty, it offers a new driving experience and level of driving pleasure, as the vehicle drives around curves dynamically and the driver can concentrate fully on steering. This is also evident in the measured load point distribution, which is illustrated in Figure 5. The load points in automated longitudinal guiding are significantly more focused in the effective areas (Figure 5b) than in manual driving, where they are widely dispersed (Figure 5a). For the top speed band, the function in its prototype version has until now used speed limits and curve information. The plan for future versions is for them to take into account traffic circles and intersections. In addition, based on the data relating to road gradient, it should be possible to calculate the coasting processes with even more precision so that fuel efficiency can be further improved.

An additional networking step is also already under analysis: In addition to the Robert Bosch GmbH video systems for example, smartphone applications already exist that recognize traffic signs and make this information available. With reliable traffic sign recognition and transfer, Connected Cruise Control would also be able to respond to temporary speed restrictions that are not noted on the maps of the horizon providers.

Operating Strategy

In a parallel hybrid vehicle, two operating states with sub-states can be distinguished. The first operating state is hybrid driving. This offers the possibilities of load point shift (load point raising and lowering) as well as pure combustion engine operation. The second operating state is pure electric driving. The relevant choice of optimum operating state is described as the operating strategy. The solution to this problem can be split into two related sub-problems: start/stop of the combustion engine as well as determining the optimal torque of the electric machine. This is possible because each operating state is characterized by exactly one permutation of these sub-problems. The ECMS procedure [START_REF] Ambühl | Energy Management Strategies for Hybrid Electric Vehicles[END_REF] offers one possible solution. In this procedure, the "costs" of electric driving or hybrid driving (with the optimum torque of the electrical machine) are calculated and compared with one another. The more favorable variant at a set point in time is then set by the hybrid control. The most important input variables are the driver's request and the battery charge level. To calculate the "costs," the efficiency characteristics of the combustion engine, electric machine, pulse inverter and battery are also used.

As electric driving requires that sufficient energy is always stored in the battery, the recuperation potential cannot always be fully exploited when operating a hybrid vehicle. This is especially true for long descents or very frequent braking. The battery is then becomes "too full" prematurely if it has not previously been emptied. One example shows driving on the flat at a speed at which electric driving would be possible. If the flat is followed by a descent, then purely electric driving is more efficient on the flat as the energy required for this can be recuperated on the subsequent descent. However, the data in the hybrid control is not sufficient to make this decision.

The predictive operating strategy developed by Bosch Engineering GmbH can determine the sections that are suitable for the recovery of braking energy using topographic data from the navigation system such as inclines, descents or curve radii. Long before these situations are reached, the battery charge status is adapted on a predictive basis, e.g. through electric driving, so that optimum recuperation can be achieved.

Figure 6 Predictive operating strategy

The Bosch development constitutes a CO2-reducing measure under EU certification. By connecting the navigation system to the operating strategy of the hybrid vehicle, the Bosch system therefore delivers a creditable, vehicle-specific advantage for the respective automotive manufacturer's fleet usage and can thereby counteract the threat of penalties for exceeding the legally prescribed average CO2 emissions [2].

Inverter DCS

In hybrid and electric vehicles, the electric motor adds another braking option. The recuperation is particularly useful with regard to energy recovery, as the energy fed back in relieves the battery and thus reduces the system costs. Essentially, this is relevant for topologies where the electric motor is permanently connected to the wheels. The objective is therefore to regain as much energy as possible. But what happens during recuperation with an electric vehicle on a slippery road? And what possibilities are there for getting as close as possible to the goal of the maximum, electrical brake energy exploitation? It must first be considered how the driver can report the recuperation requirement as this can be done in various ways: via the brake pedal, the accelerator pedal or a new interface. Conventionally, the brake pedal would be the suggested input method, as the driver has a braking requirement. This is also the approach in the ESP hev and iBooster systems. In the former, a vacuumbased brake booster is used and the brake interventions are decoupled in such a way that the rear axle can brake purely electronically. In the iBooster, the brake pressure is built up in a vacuumindependent process via an electrical actuator. The brake pressure for the friction brake can therefore be withdrawn and assigned to the electric motor. The advantage of inputting via the brake pedal is the familiar user interface and the integration of all braking interventions relevant to vehicle dynamics.

If you want to take advantage of the opportunity to read the recuperation requirement using the accelerator pedal, this can be done through replication of the drag torque, for example. In practice, this means that if the driver takes his foot off the accelerator and does not release the clutch, the vehicle will be braked via the (electric) motor drag torque. The advantage here is that this torque can be freely changed via the electric motor, provided the motor is connected directly to the axle. The use of new interfaces involves using such features as an additional rocker switch that reads the recuperation requirement individually and directly. Alternatively, entries could be made by briefly pressing the accelerator or brake pedal in order to vary the recuperation level.

While a new interface does require an initial rethink, it also separates safety-critical braking maneuvers from a request to recover energy during non-critical coasting. But how do these input types differ in terms of their recuperation level? If we consider the request for each brake pedal, combined braking demonstrates a certain time delay in the electrical part in comparison to conventional braking via the friction brake. The recuperative share must be requested via CAN from the superordinate Vehicle Control Unit (VCU). The VCU uses this to generate the target torque which, in turn for each CAN, is sent to and set by the power electronics. This does not initially present a problem when setting the brake requirement as the down time can be taken into account using the brake actuator. However, if the objective is as high a share of recuperation as possible, the following may occur: The wheel locks on a slippery road, but the complete braking power is applied via the electric machine. This means that the braking power cannot be immediately withdrawn as the aforementioned down time still needs to be taken into account. In order to respond with the brake flexibly and in the safest possible way, it is usually only a small proportion of braking that is completed in a recuperative process. For maximum recuperation, however, a different method is more appropriate. When there is a recuperation requirement, the aim of the recuperation stability system (RSS) is initially to recover as much electrical energy as possible in a non-critical driving situation. Any locking of the wheels and thus instability must be avoided. To ensure safety is not compromised and to avoid any change to the vehicle and ESP, the RSS intervenes in the torque of the electric machine sooner and more rapidly. It can do this as it monitors the engine parameters directly in the software of the INVCON power electronics.

To detect wheel lock, it is important to consider three parameters: the relative speed difference between the wheel and the ground, the braking force relative to the normal force, and their maximum value that is still just permissible on the current ground composition.

If we consider an electric vehicle braking on a slippery road, the driver will report the braking request between point 1 and point 3. The electric motor sets this request as quickly as possible. Provided this is permitted by the adhesion coefficient, the vehicle speed is then reduced. Shortly before point 2, however, the vehicle reaches the slippery ground and as the braking force is too strong, the wheels start to lock. This can be clearly detected from the speed of the electric motor. In the figure, it would be reduced to half (axle-specific drive) or to zero (wheel-specific drive) without any intervention. Based on a power and slip model, as well as a vehicle model, the RSS is able to detect this situation and trigger an intervention (Figure 7). This reduces the torque and the wheel can rotate freely again. A modeling approach reduces the wheel lock period. The intervention means that the friction coefficient is also now known, allowing the maximum permissible torque to be predicted. The controller now attempts to oscillate around this value (e.g. as shown as a two-position controller).

In the additional interventions, the calculated parameters can be used as a reference point so that interventions can be made more quickly.

For the RSS-in contrast to the ESP calculations-the absolute values of slippage and adhesion coefficient are not known accurately enough as speed and torque are not measured at the wheel. However, value generation is completed much more frequently in the inverter, so that an intelligent filter can be used, taking the history into account. In addition, the implementation does not require target slippage formation, as is completed in ESP.

Future System Technologies

In future vehicle architectures, the internal and external networking of the control units will play an even greater role. The different domains in the vehicle will be connected via a rapid communication line and the respective domain controllers. This forms a backbone structure that enables additional new functions to be implemented that are the result of intelligent linking of different domains. Special requirements are placed on these central nodes in terms of hardware and software.

The hardware of such a domain control unit must have high computing power and a large capacity of permanent and non-permanent memory for a wide variety of tasks. For flexible usage, many different communication interfaces with medium to high data rates are required, ranging from today's widespread CAN, LIN, and SENT interfaces, to the increasingly emerging and future-oriented FlexRay and Ethernet buses. The task here is to use the available and proven automotive technology from large-scale production to minimize costs and installation space. The compact design and the high density of high-frequency signals and computing power offer particular challenges with regard to loss of power and electromagnetic compatibility (EMC). The device should be prepared for a wide variety of energy management roles of future network topologies in the overall vehicle assembly. It should therefore be available for activation through various channels (CAN, Flexray, digital inputs) or even via its own clock (internal downtime counter) so that it can activate other parts of the network or control units as a master if required. The device must only have extremely low standby power consumption. To allow further functions to be adopted that cannot be assigned to the existing subsystems, it is useful to have some digital and analog inputs and outputs available. The highly flexible functional scope described above is achieved by quickly adapting a wide base unit as an assembly option to the required functional scope. This also allows several different functions to be generated in a network from the same base. This flexibility offers the customer the advantage of converting existing topologies step-by-step to the future target topologies, without the need to convert each individual participant immediately in a time-consuming process. Existing bus networks can therefore be connected to the new bus architecture via the communications interface. The functionality can be further expanded by connecting connectivity modules, such as any number of "CAN to wireless" extensions. This allows networking to be opened up for the Internet of things and services, for example.

Figure 9 Interfaces of a Communication Interface Box

Hypervisor allows various operating systems to run on the domain controllers, enabling different functional safety levels to be implemented on an ECU. Connecting to the Internet means that special security measures are necessary in the backbone. In future, it will not be possible to achieve security through a strict separation and encapsulation of the vehicle from the Internet, as the connection itself will make new functions possible. On the one hand, system and vehicle data will be transferred into the Cloud in order to supply crowd services with data and to cover car-to-car and car-to-infrastructure issues. On the other hand, information from the Internet can have a direct influence on the parameterization of vehicle functions (location-based services, software updates, remote access to vehicle functions). Through integration of smart connections from smartphones, functions can also be removed from the vehicle and computed on the ever-growing computing power of mobile devices. Additional comfort features or functions with extremely complex calculations can also be made available, and can be used retrospectively in older vehicles.

Conclusion

By networking vehicle systems with electronic horizon data, Bosch is able to develop numerous new functions that are made for a safer, more comfortable and efficient driving experience. Information such as curve radii, inclines and speed limits are directly integrated into vehicle systems using the standardized interface protocol (ADASIS v2). Thus with the resulting functions, vehicle manufacturers can differentiate between vehicle features and characteristics specific to each brand.

Outlook

The illustrated functions demonstrate the opportunities created by intelligent networking of existing components within the vehicle with regard to safety, comfort and efficiency. The possibilities offered by connecting map information to the engine control system and the ACC are illustrated in particular.

In future, the subject of environmental sensor systems and sensor fusion will play an increasingly important role in this regard -the combination of radar, video, ultrasound, and map information will provide the data mix required to illustrate the functions described in this paper or other, similar functions in a safe and reliable way. One possible extension here is the use of clouds, which enable data to be collected and thereby provide other vehicles with additional information. This requires an Internet connection, which can be realized via a smartphone or a control unit with a corresponding interface.

Another important issue in future will be the use of smartphones as external processing units with a great deal of storage capacity and high-performance processors. End-customers can always install new applications on their smartphones, as well as view the information from the vehicle and even intervene in the vehicle behavior using appropriate secure interfaces. In general, innovations demonstrate the possibilities and potential for future series applications and are therefore only the first step of the product development process. For this reason, the focus at BEG now lies in working with the OEMs to address, discuss and develop the illustrated ideas so that they can be brought to market together.

Figure 1

 1 Figure 1 Illustration of networking between various components in the vehicle (VCU, ACC, HMI and PDC)

Figure 5

 5 Figure 5 Load point distribution in manual driving (a) and with activated CCC (b)

Figure 7

 7 Figure7Sequence of an RSS intervention. During the braking request (1-3), wheel lock is detected internally in the inverter and is counter-steered by withdrawing torque. The control system attempts-provided there are no interventions by the driver or ESP-to drive as closely as possible to the slip limit.

Figure 8

 8 Figure 8 Scope of future domain control units


Antoine Blin
email: antoine.blin@renault.com

Youssef Laarouchi

Philippe Quéré

Fault-Injection using Virtualization for Critical Software Validation in Automotive

Keywords: Fault injection, dependability, virtualisation, automotive, safety, ISO 26262

In the field of critical and embedded systems in the automotive industry, where human life is at stake, manufacturers and suppliers must develop robust and reliable systems while being confronted with real time, cost and energy consumption constraints. The increasing complexity of electronic and electronic control units (ECU) in the context of the automotive industry has positioned dependability in the heart of the concerns of manufacturers.

The ISO 26262 safety standard published in November 2011 in the automotive industry refers to fault injection during software integration and testing (part 6, chapter 10, requirement 10.4.3, table 13, method 1c). It is recommended for ASIL A and B, and highly recommended for ASIL C and D. The meaning is that for ASIL C and D a rational shall be provided if the injection tests are not performed.

In this paper, we first introduce the context concerning the fault injection technics, the software architecture in automotive, and the virtualisation technics. A state of the art and a quick discussion concerning each topic is presented to justify the choice we made in our work. In a second part we describe our proposal to perform fault injection using emulation on an x86 standard platform. In a third part we describe fault injection using virtualization with respect to specific embedded platform characteristics. We conclude on pros and cons of our proposals, by specifying the technical issues that were treated in each phase of our experimentations. We then present some prospective views for future work.

Introduction

Historically, the automotive software architectures were heterogeneous. To counter this situation, two new standards have been developed, AUTOSAR software architecture for real-time systems and GENIVI a Linux based open source platform for In-Vehicle Infotainment. These new automotive architectures aims at making as standard as possible the software interfaces between different software products. For instance, AUTOSAR defines the different software layers (Basic Software, AUTOSAR Runtime Environment, Software Components …) as well as the interaction between these layers. This standardization aims essentially at reducing cost of software products, which is a great challenge for car manufacturer.

In addition, these architectures have been deployed in parallel with the emergence of ISO 26262, a new safety standard dealing with embedded EE systems in automotive. This standard adds technical requirements on software that shall be respected during the whole lifecycle (design, development, validation…). In this paper, we are interested in specific ISO 26262 requirements; those dealing with fault injection. We assume that fault injection, a traditionally costly validation technique, can be done through a "low cost" approach when using virtualization. In next section, we briefly present the fault injection techniques, then the virtualization to inject faults.

Fault injection techniques

Fault injection is a technique for improving the robustness of the system by introducing faults to test error handling mechanisms. Different faults can be triggered according to the failure we are targeting to tolerate. As presented in [START_REF] Laprie | Guide de la Sûreté de fonctionnement[END_REF], we distinguish between hardware faults and software faults. Each fault category can be triggered by different fault injection technique:

 Hardware Fault Injection is achieved through electrical or physical component deterioration. This fault injection type is particularly long and expensive. In fact, it requires the establishment of dedicated infrastructure and does not allow precise control of the location of injected faults.  Software Fault Injection is achieved on target software in its environment. The injection can be done on the component itself or on its entries by altering the functioning through spatial (essentially memory space) or temporal (CPU, resource usage, etc.) unwanted interactions. This type of injection is generally presented as cheaper than the hardware injection since it does not require any special equipment. Moreover, the injection can be well mastered if the target of test is clearly specified as discussed later.

The fault injection common architecture can be summarized in the following points (cf. Figure 1):

The Library: contains all errors to be injected into the system. Its content is defined during the system design and especially when defining safety mechanisms. These mechanisms will be the target of test later in the process of fault injection.

1. The injector: designed to activate faults on the target system with respect to the safety mechanisms requirements previously included in the library. 2. The target is the system under test. 3. The monitor observes the injections and logs obtained results 4. The collector saves the data issued from the system. 5. The analyzer processes the collected data to determine whether the system has properly reacted to the injected faults. 6. The controller coordinates the fault injection with the system response observation process.. According to the test target, the Software Fault Injection can be applied, either on the operating system or on the application or on both. The choice of the injection layer (Operating System or Application) depends on the aim of the analysis. In our case, the safety analysis deals with an ECU functional behavior implemented in the applicative layer. We assume that the operating system is trusted and we focus on software safety mechanisms implemented in the application layer. Consequently, our targeted test system is the application implementing safety mechanisms and dealing with critical signals.

Notice that fault injection on application layer requires a strong interaction with the underlying Operating System. In fact, the injector module presented in Figure 1 can be implemented in different software layers:

Library Injector

Controller

Target Monitor

Collector Analyzer

1. The first layer is the application itself. In this case, we need to have access to the source code in order to insert the necessary mutations for fault injections. Notice that this implementation is too intrusive and requires the modification of the application source code, which is not always possible. 2. The second layer is a middleware which consists in altering the tested applications I/Os and tests its behavior. This implementation is less intrusive but does not affect the internal application behavior (for instance it does not inject fault in critical application functions). 3. The third layer is the Operating System. In this case, we implement an injector module to insert in the OS. This implies the modification of the OS which is not always possible, especially in industrial context.

We think that intrusive fault injections are the major inconvenient of classical Software fault injection.

In this paper, we aim at performing non-intrusive faults injections on Software Applications. Layers 1 and 3 previously described are clearly intrusive and do not correspond to our objective. Layer 2 (middleware) is interesting but does not have sufficient coverage for the tested application.

We propose the use of an additional software layer between Hardware and Operating System. Such a layer would allow us alter OS I/O without altering the source code of neither the OS nor the application. This layer is technically enabled through the use of virtualization, as presented in next section.

Virtualization and Emulation

What is Virtualization?

Virtualization technology allows multiple operating system instances run simultaneously on the same hardware. Each virtualized OS (Called "guest OS") is hosted in a logical container called "partition". Different partitions may exist and run while being managed by a hypervisor (Called "host").

The main hypervisor role is to share hardware resources between different hosted OS. Virtualization technology must guarantees strict isolation between partitions: if one virtualized system fails, the hypervisor ensures that it does not disturb other virtualized OS. The isolation mechanisms are important since they forbid spatial and temporal interference between hosted OS. Such properties are being considered closely in current R&D automotive industry. In fact, through virtualization, we would be able to make AUTOSAR real time system coexist with GENIVI on the same hardware.

Emulation Technique

An emulator is a program that emulates Operating Systems compiled for architecture (ARM...) on different machine architecture (X86, PowerPC, etc.). This mechanism is different from the virtualization in which the instructions of the host Operating Systems are directly executed on the target.

With emulation, the instructions of the guest Operating Systems are translated by the emulator into host architecture instructions. To emulate real time characteristics, the emulated clock rate is clocked with the number of emulated instructions executed. Therefore a real time system emulated cannot communicate with non-emulated devices plugged to the host.

In our work, we used both emulation and virtualization. Emulation was used when testing our fault injection approach on a standard x86 machine. During this phase, we explored the technique of injection from the emulator platform as detailed in section 4. Once the fault injection correctly set up, we worked on a real embedded target platform by using virtualization, as detailed in section 5.

Fault Injection on X86 Platform

Let us remind first our main objective: we aim at injecting faults on automotive application software, running on a real time automotive OS. In our work, the final hardware target was not easily available (delivery delay, cost, etc.). We decided to begin our study by using a standard x86 machine by emulating an embedded platform.

For this, we require the following main components:  An automotive operative system respecting some hard real time requirements. This requirement aims at making the tested runtime environment as representative as possible of a standard automotive ECU platform. In our work, the chosen Operating System was Trampoline [START_REF] Irccyn | Trampoline -OpenSource RTOS project Available on[END_REF], an Open Source OS respecting AUTOSAR standard and running standard Basic Software.  An emulator used to inject fault on basic software. In our case, QEMU [START_REF]QEMU-Open Source processor emulator[END_REF] was the emulator of an i.MX27 ARM platform.

The fault injection architecture consists of six layers (cf. Figure 2): For both injection types, we suppose that we have a least access to the name of critical variables (generally used) and the critical functions signature (especially name and arguments). We strongly think that this hypothesis is realistic. In fact, from a car manufacturer perspective, it is always possible to have this information without being too intrusive in software implementation.

Notice that other software fault injection types can be considered (such as injections on control structure, local variables, etc.). However each introduced type needs to be linked to the application functioning first and then attached to the emulator and/or hypervisor structure to ensure correct fault injection.

Fault Injection on Global Variables

To fully understand the fault injection process we propose to first detail the different memory management strategies used by the different software layers.

Linux uses virtual memory management technic. Each process uses a virtual address space. Virtual addresses to physical addresses translation is done by the Memory Management Unit.

Trampoline doesn't use Memory Management Unit. Each address used in basic software is directly mapped to physical memory. QEMU allocates physical emulated memory used by Trampoline on virtual memory. Furthermore, it implements a Software translation mechanism to translate physical emulated addresses to virtual addresses.

The fault injection process consists in the following steps:

1. Reading the physical emulated address of the targeted global 2. Converting it to the emulator virtual address 3. Updating memory pointed by emulator virtual address in the Linux page table 4. The MMU used by Linux converts virtual to physical addresses and update physical memory.

Fig. 3. Fault injection on Global Variables

The first step requires global variables (corresponding to a critical signal) address reading in the compiled binary (called "elf" file). The "elf" operating system format contains a header describing the general structure of the file and its sections. One of the sections presents the symbol table in which a translation between the names of functions and global variables on one hand and memory addresses on the other hand is made. Accessing and reading this table is a first important step in our fault injection process.

The next steps are set up on the memory management in Trampoline and QEMU.

For Trampoline, the system code and application is compiled into a binary, with no use of virtual memory device. The addresses used in the OS thus correspond to physical hardware addresses. This feature significantly simplifies the fault injection process. In fact, it is not necessary to translate application addresses into emulated addresses. Moreover, since no "swap" mechanism is used in Trampoline, it is not necessary to consider the case where OS memory pages have been temporarily saved on the emulated memory space.

For QEMU, the memory management QEMU uses two mechanisms:  The mechanism of paged virtual memory, provided by Linux. Indeed, QEMU runs as a user process, its allocated memory (used for QEMU and emulated OS) uses standard Linux virtual addresses. At the start of emulation, QEMU allocates as much memory as needed by the emulated OS.  A software translation mechanism aiming at translating each physical address required by the emulated OS into virtual address within the memory blocks allocated by QEMU (to the emulated OS). This mechanism uses an internal QEMU page table.

4) Physical Memory Upadate

The fault injection is then done by a QEMU developed module. This module has as input the name of the variable to alter and the new value to affect and modifies directly the QEMU virtual memory as explained in Figure 3.

Fault Injection on Function Calls

Unlike fault injection on global variable in which the memory address of the variable remains unchanged, the function parameters are temporarily stored in the stack or in registers when the function is being called. We have to act when the function is executed to inject the faults on its arguments.

Our new fault injection process is updated as described below:

1. Reading the physical emulated address of the targeted function 2. Converting it to emulator virtual address 3. Setting a software breakpoint on this emulator virtual address 4. When breakpoint is triggered 5. The emulated OS is stopped 6. The arguments values is changed on the emulated stack 7. We restart the emulated OS with its new context To implement this fault injection on function arguments within QEMU, it is necessary to first determine how the arguments are passed to functions called. These conventions depend on the hardware architecture for which the code is compiled, the compiler and the call conventions used. Conventions used by Trampoline are detailed on the official website of ARM Holdings and are quite complex. They can be summarized as following: the first four arguments are passed in registers; the following are passed on the stack. This injection technic suffers from some limitations. For instance, when compiler optimizations (inlining) are enabled, function calls are integrated to the code and fault injection becomes impossible.

More generally, fault injection on emulated application has several limitations and benefits. One major benefit of emulation is the entire control of the timing aspects of emulated OS. In fact, the internal clocks of emulated OS are cadenced by the emulator; the emulator can freeze guest OS without temporal impact on its behavior. This makes fault injection overhead less. Moreover, emulation allows quick unit testing without deploying the software application on real target which is energy and time consuming. Limitations can be summarized in the following; emulation cost (all the hardware has to be entirely emulated), representativeness (when emulating the whole runtime environment).

Fault injection on embedded hypervisor

As previously discussed, emulation has several limitations and especially representativeness. In fact, emulation hides the complexity of runtime environments and makes some assumptions about the interaction of the application with its environment. The use of hypervisor is more representative of embedded platform. We propose to first present fault injection architecture and then detail the fault injection on global variables and functions.

Architecture

It's necessary to have three tools to perform a fault injection campaign on embedded platforms:  an operating system running applications,  a hypervisor used to inject fault on basic software  the targeted platform board.

In our case, we used an open source hypervisor called CodeZero. This choice is justified by the fact that we need a hypervisor supporting ARM architecture, and CodeZero was one of the rare open source hypervisors fulfilling this requirement. Using CodeZero raised some restrictions. For instance, there were no OS running on this hypervisor, but just POSIX applications running in bare metal mode.

Since we are interested in checking safety mechanisms in application, we performed fault injection on

Hyper call Injection

Task1 { } virtualized POSIX application (Figure 4). The platform used to launch wasPB926-Versatile (This board wasn't available we used QEMU to emulate it).

The platform used to launch was a PB926-Versatile. During our experiments, this board was not available, so we decided to emulate it with QEMU, as shown in Figure 4.

Global Variables Fault Injection

CodeZero provides the notion of partitions for virtualization. Each partition implements an isolated execution environment with its own set of resources (threads, address spaces, memory resources…). Access to virtualized resources is done through hyper calls from partition to hypervisor. In a first part, we choose to trigger fault injection on a partition when the partition itself makes a hyper call as described in Figure 5.

The steps used for this fault injection are:  Compilation of targeted applications  Reading the virtual address of the targeted global  Starting the hypervisor  On application hyper call: fault injections are done from the hypervisor on the application targeted global variable

In this solution, we notice that the injector is integrated within the hypervisor. Such a solution induces some modifications in hypervisor code, which is not always possible. Consequently, we tried to implement the injection monitor within a second partition (cf. Figure 6). This specific partition is in charge of injecting faults on other partition using hyper calls. The algorithm used is summarized in the following steps:

 Compilation of targeted applications  Reading the virtual address of the targeted global  Starting the hypervisor  The injection partition makes an "injection fault hyper call" with virtual addresses of targeted global variables as argument  The hypervisor handles the hyper call, maps the address space of the targeted partition, updates the global variable value and re-maps the address space of the "fault injection partition".

Notice that this solution adds an overhead since the address space swaps are costly.

Function Argument Fault Injection

This fault injection technique is similar to that used in section 4.2. Hardware breakpoints on targeted functions are used to inject faults. When a breakpoint is triggered, the fault is injected in the stack and in specific registers before normal execution resumes.

The main difference between "Function argument injection" technics on "QEMU" and "Function argument injection" technic on "CodeZero" is the following: with QEMU we can use the software debugging layer implemented on the emulator while in "CodeZero" we had to use the hardware debugging layer.

We propose to detail, by an illustrated example, the operation of hardware debugging layer on arm platform. The first argument of a function "fi", executed on an ARM platform, is targeted by a fault injection. First we save the first instruction of "fi" function (Figure 6, Step 1) and replace it by a breakpoint instruction (Figure 6, Step 2).

When the function is called, the processor executes the breakpoint instruction (Step 1, Figure 7) and raise a Prefetch Abort interrupt (Step 2, Figure 7) handled by the Prefetch Abort ISR (Interrupt Service Routine, see Step 3, Figure 7).

The Prefetch Abort ISR perform the fault injection by updating the processors register that contains the first argument of the "fi" function (Step 1, Figure 8) and replace the breakpoint instruction by the old instruction(Step 2, Figure 8). The fault injection handler returns the control to the "fi" function that continues its execution (Fig. 9).

The difference between software debugging layer implemented by QEMU and hardware debugging layer implemented is linked to timing issues. On one hand, CodeZero adds a significant CPU time overhead, with no control on the guest OS clock. This can lead to uncontrolled time drift. On the other hand QEMU freezes the guest virtual machine until the injection is done. The virtual machine does not realize that it is frozen.

Conclusion

We briefly presented fault injection techniques and described how virtualization can be used to inject mutants in memory without altering the source code of the applications.

Let us remind that fault injection cannot be done without a previous knowledge of the application behavior, which is an important hypothesis of this technique. However, fault injection supposes that we entirely know the software functional and dysfunctional specifications. This is necessary to observe any abnormal behavior when injecting faults.

We also focused on two main application fault injections types: the global variables and the functions parameters. During our experiments, we noticed that this injection technique has some limitations. First, it is sensitive to optimizations that are applied to the code. For instance, when options like "inlining" are enabled, function calls are included in the code and fault injection on their arguments becomes impossible. In addition, this technique is non deterministic. In fact, the state of the program when the breakpoint is set affects the result of the injection. For example, if a function is called twice in a code we cannot determine on which call the injection will be performed. We identified several solutions to figure out this issue. It generally consists in synchronizing fault injection with the running application. The purpose is to trigger the injection according to the inputs and the internal state of the program.

The described techniques have been tested on a proof on concept applications with safety requirements (ASIL C for instance). It could be possible to extend our work to additional fault injection types

Fig. 1 .

 1 Fig. 1. Fault Injection Common Architecture

Fig. 2 .

 2 Fig. 2. Fault Injection Architecture

Fig. 5 . 6 .Fig. 4 .

 564 Fig. 5. Inter Partition Fault Injection with Hypervisor Fig. 6. Intra fault injection using hypervisor

1 Fig. 8 .Fig. 9 .

 189 Fig. 8. Fault Injection

  As presented in section 2, fault injection can be done on different layers, and we are interested in the application layer, by injecting fault in the emulated (or virtualized) hardware. Many software injection fault types exist, depending on the objective and limitations of the tests. As we set as an objective to leave unmodified the source code of tested applications, the fault injection has to deal with the dynamic behaviour of the application. In this paper, we are interested in two software fault injection types that directly impact the application functioning:

	1. The X86 Hardware
	2. An open source Operative System: Linux
	3. An emulator, QEMU, running as a standard Linux user mode process
	4. The embedded emulated hardware (Armadeus apf27 board [10])
	5. Trampoline: the embedded real time OS
	6. The application software targeted by fault injection

 Fault injection on global variables: we modify application global variables to introduce nonconsistent states.  Fault injection on function calls: we modify functions parameters to impact program behavior.