S Voget
email: stefan.voget@continental-corporation.com

SAFE RTP: An open source reference tool platform for the safety modeling and analysis

Keywords: automotive, reference tool platform, safety modeling, safety analysis

Seamless modeling and implementation from requirements down to SW code-generation of safety critical systems in the automotive industry is still a challenge. Often, neither the modeling principles nor the tools are consistent. This paper will introduce Eclipse based platform implementations Artop, EATOP and SAFE RTP and will show how a seamless modeling of a safety related automotive system can be realized by using the composite of all three platforms.

Introduction

Modern vehicles are extremely complex embedded systems that integrate software and hardware from a large set of contributors. In order to cope with this complexity during development, it is getting more and more common to use suitable abstractions, i.e., models that allow for an early validation of important properties. In particular, hardware models are used for analysis. Functional models, like Matlab/ Simulink or ASCET, are used in software development, in order to allow for an early validation of software. On Electric/ Electronic (E/E) architecture level, domain specific architecture description languages like EAST-ADL [5], SysML or the AUTOSAR [1] standard enable properties of the system architecture to be modeled which facilitates system wide analysis, design space exploration, reuse of development artifacts and change management.

For safety related aspects, in 2011 a new standard -the ISO26262 [START_REF]International Organization for Standardization Road Vehicles Functional Safety[END_REF] -were finalized. The standard is an adaptation of the functional safety base norm IEC 61508 [START_REF]International Electrotechnical Commission (IEC): Functional Safety of Electrical /Electronic / Programmable Electronic Safety-Related Systems[END_REF] for specific needs of related E/E systems in road vehicles. This adaptation applies to all activities during the safety lifecycle of safety-related systems related with electrical, electronic, and software elements that provide safety-related functions.

It is still not clear how the artifacts and models necessary for safety documentation and analysis can and should be integrated in order to minimize modeling effort, to keep consistency between artifacts and to enable effective reusability and change management. Methods which allow automotive products developed according to the ISO26262 have to be applicable to such an integrated model. Furthermore, tool chains -or better -tool platforms are necessary to support the developer keeping the consistency.

Current research and standardization activities are on the way to develop methods, meta-models and domain specific languages (DSL's) to enable integrated modeling through the whole development life cycle [START_REF] Ljungkrantz | Case study about ISO26262 in the EAST-ADL / Autosar context, Experiences with ISO26262-2013 conference[END_REF] [12] [START_REF] Voget | Definition of a standard for model based safety development and analysis compliant to ISO26262[END_REF]. Important activities are driven by the EAST-ADL association [3], the MAENAD project [5], the SAFE project [6] and by AUTOSAR. The EAST-ADL provides a DSL based on abstraction levels from functional modeling through system architecture to detailed HW-and SW-design. AUTOSAR supplements this DSL by a meta-model for software configuration of electronic control units. Several activities are on the way to develop associated tool platforms. ARTOP [2] is an industry driven user group to develop a tool platform for the AUTOSAR meta-model. A similar project for providing a technology reference platform for EAST-ADL is the Eclipse project EATOP [4]. To enable and push the realization of this technology platform it had been introduced by the Eclipse industry automotive working group "I-AWG" [START_REF] Graf | Collaboration in Automotive -The Eclipse Automotive Industry Working Group[END_REF]. In addition utilities from Sphinx [7] are closely related. Sphinx is an Eclipse project that develops necessary extensions of EMF based platform support to enable ARTOP, EATOP and others.

The ITEA2 project SAFE (Safe Automotive software architecture) [6] is a European funding project. It provides methods for integrated safety modeling and safety analysis [START_REF] Cuenot | Peikenkamp; model based development for functional safety[END_REF], e.g. efficient capturing of safety goals and requirements or safety evaluation. The results ensure and speed up the efficient development of safety features in cars. To allow evaluation of the methods within significant industrial case studies, a reference technology platform (RTP) is defined and extended with a set of appropriate plug-Ins [START_REF] Voget | The SAFE technology platform -an open source tool platform for safety modeling and analysis[END_REF]. The DSL provided by SAFE is related to EAST-ADL and AUTOSAR and extend these with safety related information. The RTP provided by SAFE is based on EATOP and ARTOP.

In the remaining paper we will give a short overview about the mentioned DSL's and will introduce the Eclipse based tool platforms EATOP, ARTOP and SAFE RTP. An use case with the SAFE RTP demonstrator illustrates the relationships between the three platforms and how it can help to model seamless in the development of safety related electronic control units.

The DSL's EAST-ADL and AUTOSAR

EAST-ADL is a domain specific language to model functional-, system-, software-, and hardware-architecture in the automotive domain. EAST-ADL has been initiated in 2001 by the ITEA funded project EAST/EEA. Further development has been done in two funded projects ATESST and ATESST2. Since 2010 a European funded project MAENAD [5] maintains and extends the language with respect to electrified vehicles and safety development lifecycle modeling. For long-term maintenance and dissemination, the EAST-ADL association [3] has been founded. It maintains the meta-model definition and makes the latest version available to the public.

AUTomotive Open System ARchitecture (AUTOSAR) [1] is a worldwide development partnership of car manufacturers, suppliers and other companies from the electronics, semiconductor and software industry. It facilitates the exchange and update of software and hardware over the service life of the vehicle. So, AUTOSAR is thought for implementation needs rather than architectural planning.

EAST-ADL serves on a more abstract level than AUTOSAR. It provides the possibility to model systems on different abstraction levels. It is much like the well-known, Uniformed Modeling Language (UML) but as an automotive specific specialization in an own DSL. UML for example defines six different structure diagrams and seven behavior and interaction diagrams whereas EAST-ADL only defines class diagrams, which capture the structure of the relevant concepts.

The EAST-ADL specifies four levels of abstraction to model an automotive electronic system: Vehicle Level (VL), Analysis Level (AL), Design Level (DL) and Implementation Level (IL) as shown in Figure 1.

Figure 1: Structure of EAST-ADL (see also [3])

At the vehicle level the system is described from a very abstract position with the means of features. These describe, 'what' is included in the system, not 'how' it is realized. The features are organized in a feature model and which relates to requirements and use cases. The analysis level realizes the features from a functional view point. Abstract functions and devices are defined and their interaction with the environment is specified. The technical view point is allocated to the design level. It provides means to model concrete hardware architecture and a function-to-hardware allocation. The previous defined models are now more implementation-oriented. Finally, the implementation level is reserved for the software-based implementation of the system. EAST-ADL does not define an own meta-model for this level but refers and connects to AUTOSAR.

The goals of modeling with EAST-ADL are to handle complexity and improve safety, reliability, cost, and development efficiency through model-based development.

The SAFE project

Model based safety analysis is in scope of current automotive system and software engineering. The international research project SAFE has the goal to enable the ISO26262 compliancy of an model based development process. SAFE started in July 2011 and will end in December 2014. The concepts, an integrated meta-model, the technology platform and a process model are already published in 2013 (see [6]). Evaulations will follow mid of 2014.

The three main objectives of SAFE are:

 Extension of EAST-ADL and AUTOSAR, to enable effective integration of artifacts associated with the application of ISO26262. The extended model is implemented in a reference technology platform (SAFE RTP).  Methods, e.g. for efficient capturing of safety goals and requirements as well as for safety evaluation, are enhanced in order to benefit from the integrated model. The SAFE RTP is extended with a set of appropriate plug-Ins.  An ISO26262 compliant process is defined on top of model-based development and evaluated in realistic and measurable industrial case studies.

Due to the complexity of the challenge and the need to define interfaces between the industrial parties, this can only be tackled effectively in a joint initiative that includes carmakers, their tier-1 suppliers, chipmakers and tool suppliers -as well as research organizations which provide a significant background in relevant fields. One of the main contributions of SAFE for the automotive industry is a high impact on the standards and regulations as the SAFE project is strongly connected to EAST-ADL, AUTOSAR and ISO26262. Strongly connected is meant in two levels: 1) To prevent double work there is a strong organizational coordination of the activities with a main moderation role at the I-AWG, 2) The SAFE meta-model extends the other DSL's and minimizes the overlap. To enable a process that covers all defined abstraction levels, the tools are a critical aspect. So far, often the refinement and traceability of the requirements, the safety information and the cross correlation cannot be controlled seamlessly due to missing tool interfaces. In the remaining paper we describe a tool platform that provides basic handling of all three DSL's in one environment such that the realization of a seamless process can be enabled.  focusing the competition among tool vendors in their area of expertise  increased interoperability and integration of AUTOSAR tools The introduction of Artop had been a big success in the automotive industry. Today, the implementation states a reference and is widely accepted [2].

"SAFE RTP": An Eclipse tool platform for SAFE meta-model SAFE RTP is an Eclipse-based Java implementation of the SAFE meta-model that integrates with the AUTOSAR meta-model from Artop and the EAST-ADL meta-model from EATOP.

It offers a basic authoring experience, i.e., an Eclipse perspective with a tree-based model explorer view for navigating through SAFE model files and their contents as well as some exemplary form and tree-based editors enabling safety-related extensions for EAST-ADL and AUTOSAR models to be edited.

An important aspect of the SAFE RTP is interoperability. It supports the integration and exchange of safety-enriched architecture, dynamic behaviour, execution environment and hardware descriptions with existing non-Eclipse based engineering tools by defining an appropriate XSD schema-based exchange format. The corresponding serialize/de-serialize features enable the file based exchange of the data with other tools. As commercial tool vendors but also university institutes that implement research tools are members of the SAFE project, several implementations of such tools are already provided.

The SAFE RTP enables the integration with other Eclipse-based tools and plug-ins such as those providing the implementations of the EAST-ADL and AUTOSAR meta-models as detailed above. Related to this, two main features are provided:

1. The SAFE meta-model platform is based on Sphinx. Sphinx is an Eclipse project that provides an extensible platform to ease the creation of integrated modeling tool environments supporting individual or multiple modeling languages [7]. Using Sphinx simplifies the integration of the SAFE meta-model with EATOP and Artop. 2. Already the SAFE meta-model encloses links to EAST-ADL elements and AUTOSAR elements. These links are implemented in the SAFE RTP, such that a user can create an integrated model using EAST-ADL, AUTOSAR and SAFE DSL's together in one editor.

SAFE RTP Demonstrator

To show how all three platforms can be composed in one tool and how this behaves, lets consider a simplified headlight example following step by step the structure illustrated in Figure 3. In that example we will focus on the software realization only to keep the example simple.

Figure 3: Elements of demonstrator example

The left column shows the refinement and traceability of requirements. A requirement "Headlamp shall turn on when requested" is refined on the level of analysis functions to a requirement "Headlamp shall turn on if switch is on" and on the level of design functions to a requirement "Headlamp switch shall indicate status with LED". Therefore, the top level requirement is refined through several steps -i.e. indicated by the vertical arrows defining the flow through the boxes. On each level we get to know more detailed information about the headlamp switch.

The same abstraction pronciple are followed in the architecture model which is also part of EAST-ADL and AUTOSAR. This is shown in the second column. A feature that fulfills the requirement on highest abstraction level may be "Headlamp". The analysis function is a decomposed, more detailed architecture consisting of a sensor, a controller and an actuator. The design function encloses further detailed components, i.e. now one gets to know that the sensor is a hardware element which has an associated AUTOSAR Sensor-SW-Component. Now we consider the modeling and analysis of safety related information in the SAFE part of Figure 3. In our case the Item is not the whole headlamp but the switch only as the safety analysis will only be done for the switch in this example. A critical situation may come up if the switch is on but the headlamp not. This may course an accident, i.e. an hazard. Therefore, a safety goal is derived: "Indicate if headlamp is not on although switch is on". On different architecture levels one has to detail the safety goal, e.g. one adds the information that the indication is done by a LED.

The arrows indicate the information flow of the safety modeling. A different meaning have the arrows that start on the SAFE model and end in the EAST-ADL or AUTOSAR model. These are "satisfy" links, i.e. they show which architectural element satifies a dedicated safety requirement. The safety analysis has to ensure that one can trust such a satisfy link.

Although there already exist integrated tools that are able to handle the functional as well as the safety modeling, normally an architecture is done in another specialized tool than the safety analysis. To keep this information consistent is often a problem.

Figure 4 presents a screenshot of the SAFE RTP demonstrator that encloses Artop, EATOP and the SAFE RTP. The project explorer on the left side shows, that the serialization of the model information is done in separate files. One for AUTOSAR model, one for EAST-ADL model and one for SAFE model. These serialization / de-serialization is done by the integration of Artop, EATOP and SAFE RTP. But, the right side displays an editor showing a common model, which is based on all three languages. This enables to model the architecture and to run the safety analysis in the same tool. At the end it enables a seamless methodology from requirements down to the software code generation. The SAFE explorer is based on the basic example Ecore editor from Eclipse. It illustrates the integration aspect but cannot replace user friendly user interfaces that enable the handling of bigger models. But such user interfaces are no longer part of the platform development. The implementation of such user interfaces is left to the tool vendors.

Outlook

Of course, the user interface of such a demonstrator is for modeling experts only. Normally the architect or the safety analyser need a more adequate user interface. As the SAFE RTP is open source, a community already provides adequate and adapted user interfaces in form of plugins that can be added to the platform easily. Initial plugins are already implemented within the SAFE [6] and the MAENAD [5] projects. Further contributions are done within the Eclipse community in the EATOP [4] project.

Figure 2 :

 2 Figure 2: Scope of the SAFE meta-model. The red bordered actions are supported by the SAFE RTP Figure 2 illustrates the relationship between the three DSL's taking part in the safety modeling and analysis story. The architecture and implementation of the functionality is done via EAST-ADL and AUTOSAR -this is illustrated in the left column of Figure 2. The safety information of the SAFE meta-model are closely related to the abstraction level structure of EAST-ADL -which is shown in the vertical structure. An important aspect is to ensure at each level of abstraction that the safety requirements are still fulfilled. To express this, a satisfy link can be drawn on each level of abstraction, i.e. the horizontal links between the SAFE meta-model on the one end and EAST-ADL resp. AUTOSAR on the other end.

Figure 4 :

 4 Figure 4: Screen shot from SAFE RTP user interface.

  The tool platform is based on three parts  EAST-ADL is implemented in the Eclipse based tool platform "EATOP"  AUTOSAR is implemented in the Eclipse based tool platform "Artop"  SAFE meta-model is implemented in the Eclipse based tool platform "SAFE RTP" Implementation of important versions and revisions of the EAST-ADL meta-model in EMF  Serialization/de-serialization of EAST-ADL models/files conforming to the EAST-ADL XSD schema  A tool platform and an exemplary basic IDE experience for creating, managing, editing, validating, transforming or otherwise processing EAST-ADL models in the Eclipse workspace.EATOP supports the work of the EAST-ADL association by providing an Eclipse-based tool platform implementation for the EAST-ADL standard. Up to now, there are multiple initiatives to create Eclipse-based implementations of EAST-ADL which led to a quite cluttered and redundant tool landscape. The goal of EATOP is to reconcile these initiatives, consolidate the different implementations and shape like a reference implementation of EAST-ADL under one umbrella. Since 2013 EATOP is an official Eclipse project and open source available[4].Due to the complementarity nature and close relation between EAST-ADL and AUTOSAR, EATOP is closely aligned with Artop.

	Eclipse based tool platforms
	"EATOP": An Eclipse tool platform for EAST-ADL
	EATOP is an Eclipse-based implementation of the EAST-ADL standard. It focus on providing the following main
	features:
	

"Artop": An Eclipse tool platform for AUTOSAR Artop is an Eclipse-based implementation of the AUTOSAR meta-model. From features point of view it is similar to the features implemented in EATOP. Artop is organized by the Artop user group, a cooperation of several companies from the automotive industry. The availability of Artop is restricted to AUTOSAR members only. Similar to the goals of EATOP, the goals of Artop are to enable:

 the creation of commercial AUTOSAR tools with shared platform functionality  the availability of AUTOSAR tools close to the point in time when AUTOSAR specifications are released

Acknowledgment

Many thanks to the partners from EATOP, ARTOP and the SAFE project that enable the tool platforms in a common effort.

This document 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.


Using Yocto Project to build rich and reliable embedded Linux distributions

Keywords: embedded linux distribution, embedded linux tools, Yocto project, reliability, reproducibility

Linux is often used as an embedded Operating System for smart devices with rich features (along with Android). Using such an OS with its quickly evolving ecosystem needs strong tools to insure the embedded distribution will remain reliable in an industrial context. This paper aims to quickly review tools developed by the embedded community to address this challenge, then focusing on Yocto who tends to become the standard, due to its support by many major actors.

Introduction

During the last 15 years, Linux rank in Operating Systems used in embedded market has constantly grown, and it is now a major solution to build embedded devices that are not subject to security constraints or certification process. 10 years ago, Linux could be seen as an alternative to legacy RTOS, like pSOS, VxWorks etc... (as long as hard real time was not mandatory). At that time only the very basic components were used, such at the kernel itself, the C library (glibc) and a few basic tools provided by Busybox, the Swiss Army Knife of Embedded Linux.

Building the complete software of the device under development was mainly developing from scratch the specific application, built over these basic components. The model was very similar to the one with legacy RTOS, with the substitution of legacy OS by Linux. Developers used another operating system but there was no real rupture in the development paradigm.

Nowadays, there is an endless pressure to build devices with much more features than before, including high connectivity through a lot of channels (Wifi, 3G, Bluetooth etc...), rich Man Machine Interfaces, high level graphic features, audio and video performances etc....

Along with this feature level pressure, there is also a need for reduced Time To Market, as product development cycle becomes shorter and shorter, due to competition on innovation.

These evolutions in embedded devices requirements are driven by the generalization of smart devices like smartphones and tablets, and the leadership of iOS and Android in this kind of smart devices. People want to have the same features level they find on their smartphone, on embedded devices in their car, on the machine they use or in the product they interact with.

It is the reason why there are emerging projects for the embedded market built on top of Android, which becomes a challenger for Linux as embedded OS. Nevertheless Android is a good solution for telephony and tablets (it was designed for this segment), but it is not necessary an easy solution when used for other purposes it was not originally designed for.

Thanks to the great Linux ecosystem, it is possible to get high feature level and reduced TTM, and go on building smart devices on a Linux base, but this means that developing on Embedded Linux today is completely different that 10 years ago. Software teams will have to collect very various components from the Linux ecosystem (libraries, codecs, stacks, frameworks ...), use them as "modular bricks" they will assemble unchanged or locally adapted, and build the final software image of the device. In such a scheme, the number and even the volume of code of components assembled from the ecosystem can be much more important than the software developed from scratch.

All these software components are driven by distinct organizations, communities, or companies, without anyone that could centrally manage the evolutions, interactions of the components : Linux ecosystem is very dynamic, very innovative, but also very fragmented, and this fragmentation has to be addressed in order to build reliable products.

Managing this complexity is the daily work of Linux distribution suppliers for the desktop. But using a Linux distribution as is for an embedded device is not the solution, unless the embedded device is very similar to a PC.

So the Linux embedded community need tools to help engineers build attractive products that can integrate many components from the Linux ecosystem, without giving up reliability and long term maintenability.

Embedded distribution tools overview

As a very first solution, it is possible to use a Do It Yourself strategy, doing things manually :

• select the software components you need and download them

• configure them • compile them
• install them in an embedded file system image on the development PC

• condition this embedded file system image in the final deployable format.

The problem quickly tend to be insoluble due to dependencies between software components : the high level components generally rely on a lot of shared libraries, basic services etc …. Finally all needed components build a dependency graph that must be treated in the right order, from basic elements to final ones. The coherence of versions between all the software components adds difficulty to this Do It Yourself process, as each dependency not only is a relationship between 2 components, but between precise version of these 2 components (not necessary the last one).

So Do It Yourself manually, without automation tools, can only be envisaged on a very small number of pieces, i.e. on simple applications.

Over the years, a few dedicated tools to automate the build of an embedded Linux distribution have emerged. All the major solutions share the same philosophy as Do It Yourself strategy : download software components from the Linux ecosystem (upstream projects), if necessary apply local patches, then configure and cross compile them, and finally build the deployable software image. But they use additional informations to solve dependencies problem on a large base. Such tools are built around an engine for tasks execution, meta data that describe dependencies and actions on components and optional patches. With the exception of patches, these tools don't include source code, but the rules to efficiently use source code from upstream projects. LTIB is the build tool used up to now by Freescale, but Freescale is currently swapping to Yocto, so LTIB will be soon deprecated.

Buildroot is still active, but focused on simpler images than Open Embedded / Angstrom / Yocto (less available components).

Before a closer look on Open Embedded / Angstrom / Yocto, the following

Yocto development environment

These 3 tools are close cousins, Angstrom and Yocto inherit from Open Embedded.

Open Embedded was originally developed to build the Linux Distribution Open Zaurus for Sharp Zaurus (an ARM based PDA). It is now used for all kind of hardware platforms.

Angstrom and Yocto share with Open Embedded the same task engine (Bitbake) and the same kind of meta data, allowing constant exchanges between the 3 environments.

Today Yocto (the real name is Yocto Project, but for convenience we will use Yocto in this document) is hosted by the Linux Foundation, and is supported by major actors like silicon vendors (Texas Instruments, Intel, Freescale) 1 , major tools vendors (Wind River, MontaVista, Mentor Graphics) 2 , embedded consultants etc.... So the document focuses on Yocto, but the majority of concepts remains applicable for Angstrom and Open Embedded.

To describe Yocto features, we will use the paradigm of a black box, with inputs and outputs (see Figure 1).

Yocto's inputs are :

• Upstream projects source code (projects picked from the Linux ecosystem).

• Local source code (code components developed internally).

• Meta data : recipes + local patches to apply to source code.

• Configuration files : hardware platform, toolchain tunings, preferred components versions, misc parameters.

These input are used by the bitbake task engine to produce a set of main outputs :

• a final deployable image in various formats (tar.bz2, UBI, ext3 / ext4 ….).

• an application development SDK, to allow developments from outside the framework.

• Packages for each built software component (RPM, DEB or IPK format available).

1 This list does not pretend to be exhaustive 2

This list does not pretend to be exhaustive

Other interesting output are the packages and licenses manifest of the final image, as correct license management is an important point when developing a Linux based embedded device. After the image is built, the list of packages used in the image, and the associated licenses, is available.

Inside the black box, the bitbake engine builds a dependencies tree of all individual tasks necessary to perform the asked job, then automate their execution in the right order (don't put the roof if you haven't yet build the walls).

Individual tasks performed by bitbake on a component are :

• fetch the source 3 .

• unpack it.

• patch it with local patches.

• configure the software component (autotools appreciated).

• compile it.

• stage it (install headers and libraries in the right location, so that others can use them).

• package it (build RPM or DEB or IPK package).

• deploy it (copy the package in the package feed). For a final image, the tool will also build the complete root file system in a temporary directory, then build the final deployable image in the chosen format : compressed tar archive, ext3/ext4 image, UBIFS, live image based on initramfs, image for Qemu or VirtualBox, etc....

Thanks to bitbake, meta data and the dependencies tree, it is possible to build a complete QT Embedded demo image with the single command "bitbake qt4edemoimage" (this single command will perform a few thousands of elementary tasks, and require large disk space, and hours of machine computing).

The magic of dependencies tree resides in the recipes that describe the actions to build a software component, but also that manage the complexity of components interactions through dependencies description and components version management (see Figures 2 and3).

3 Fetched source is stored locally, so that reproducibility is ensured if source disappeared from then Net. With this kind of distributed database of components versions and interactions (the complete set of recipes), Yocto solves the complexity of assembling a rich embedded distribution in a constantly moving upstream projects ecosystem.

The set of meta data is maintained by the Yocto user's community, who works in order to deliver recipes of components who will correctly assemble as the versions in the meta data set are coherent. The recipes developer's community does the same job as standard PC distributions do at binary packages level.

Modularization of recipes

Yocto provides mechanism to modularize such an amount of software components. The modularization is based on two main ideas : a prioritized layers structure and the possibility to modify recipes without duplication.

Recipes are grouped in layers that overlap each other, depending on their priority. The more general layer is meta (Open Embedded Core meta data), and then layers are stacked. For instance Yocto specific's recipes are in the meta-yocto layer, then machine specific recipes (BSP) are in a meta-xxx-bsp layer etc... If a recipe is present in 2 layers, the version from the highest priority layer is used.

Additional layers can be defined for local in house developments, for instance one layer for recipes global to the company, one layer per software product, one layer per specific hardware BSP ... Through configuration files, layers necessary to build the final image are selected. From a product to the other, active layers may differ, sharing a common basic set of layers, and then enabling those layers that make sense for the product. By this way reusability between projects without duplication is easier, reducing maintenance problems.

Figure 4 : assembling layers in projects

It is possible to customize a recipe located in an underlying layer, without recipe duplication : the creation of an append recipe file modifies the underlying recipe differentially (same idea than a patch modifies a source code differentially). For instance this mechanism allows to modify password files located in Open Embedded core from an append recipe located in the company software layer.

Using append recipes (bbappend files), developers can customize recipes coming from each underlying layer, avoiding recipes duplication so that new versions of the recipe will be easier to adopt (see Figure 5 and6).

Reproducible images

When developing software for an industrial product, the same image must be generated during years, whatever the circumstances. Simply cloning a master to ensure reproducibility is not a good solution as sometimes bugs must be corrected or new features must be added, implying image regeneration. So it is recommended to suppress any manual task during image generation or deployment (automatic tasks are much more reliable than manual ones). When building a software image, the problem often comes when parameterizing the image, with things like network addresses, user accounts and password (if used), or every parameter that is normally defined interactively on a standard desktop distribution, by installer or by administrator.

In Yocto, all these parameters are defined prior installation, during the building phase of the image. By defining all these parameters set in the recipe of the ad hoc component (for instance IP addresses in the netbase component), the built image is completely defined prior to installation, removing manual configuration tasks, and increasing reliability. If the image has to be rebuilt for any reason, the definition of all parameters in the recipes set guarantees that the final result will be what was expected when designing the embedded distribution, without risk of error due to manual actions.

During the image build, many tools are used on the developer's PC : autotools, make, cross toolchain, potentially perl, python, bison, yacc, etc ….

Normally all these tools would come from the developer's PC distribution : they are subject to change each time the distribution is updated (distribution update is quite current in Linux's world).

To avoid any risk of change in the generated elements, Yocto first compiles the complete set of tools necessary for packages and images builds. It then systematically uses these specific native tools instead of their counterparts coming from the PC distribution (see Figure 7). This isolation from the developer's machine guarantees that updates on this machine won't affect the embedded distribution generated with Yocto. It also guarantees that results will remain exactly the same on different machines in a multi developers team.

FILESEXTRAPATHS_prepend := "${THISDIR}/${P}:" SRC_URI += "file://rootpasswd.patch \ "

We set a password to root basepasswd/passwd.master.orig 20050708 06:31:58.000000000 +0200 +++ basepasswd/passwd.master 20130211 14:31:58.000000000 +0200 @@ 1,4 +1,4 @@ root::0:0:root:/home/root:/bin/sh +root:SLvEGe9/3fJBQ:0:0:root:/home/root:/bin/sh daemon:*:1:1:daemon:/usr/sbin:/bin/sh bin:*:2:2:bin:/bin:/bin/sh sys:*:3:3:sys:/dev:/bin/sh Add a patch to underlying recipe Modify root password

Sandboxing

The role of the sandbox is to completely isolate things managed by Yocto, from the native distribution.

Native tools generated by Yocto and used during image generation are the first half of Yocto's sandbox : the native part.

The second (and main) part of the sandbox gathers components that are related to the target. It generally covers items that are cross-compiled 4 . Generally a software component needs precise versions of used libraries, or at least a precise range of accepted versions.

Software versions used on the target part have no reason to be identical as their counterpart in the native distribution, so particular caution is necessary for includes and libraries versions used during configuration and compilation phases.

The most critical part comes from headers inclusion : by default the toolchain will try to use headers from /usr/include (native headers). If a native header corresponding to a library used during compilation is found in /usr/include and used, and if the native library version is not correct, then it can lead to compilation errors or execution bugs. Compilation errors will be relatively easily detected but execution bugs due to wrong interface definitions can be quite difficult to detect (for instance a structure passed as a parameter to a function of the library with different definition in the caller and in the library).

4

Even if target and host development machine architectures are the same, a "cross-compiler" generated toolchain is used, with same host and target platforms selected during configuration.

Sandbox target sysroot

Sandbox target sysroot

With such protection, the success of an application compilation strictly depends on the presence of needed includes and libraries in the sandbox's sysroot. It is the reason why each recipe execution needs a dependency tree resolution and dependent tasks execution in the appropriate order, so that used libraries can be found.

Conclusion

Thanks to its large set of recipes, the investment of major actors and a large users community, Yocto helps embedded developers for complexity management, reproducibility and reliability of the build of a complex embedded image. It offers embedded developers a full feature framework to build embedded Linux distributions that are targeted to the hardware resources of the device (because they are cross compiled for this specific device), and that use all available upstream projects of the Linux ecosystem to fulfill rich feature requirements.

The framework and the community that manage meta data address the complexity and fragmentation of Linux world to allow to offer users high level experience without compromise on quality and reliability of the built images. Nevertheless the tool is mainly a packaging and build tool : the global reliability depends not only on packaging, but also on the intrinsic quality of software components developed in upstream projects. So Yocto contributes to the reliability of embedded developments, but the project is not the only nor ultimate actor to meet this goal.

The framework is used today by major founders to build their Linux Board Support Packages, and by software companies to develop new solutions. Yocto is the foundation of commercial products like Wind River Linux. The release deliveries are predictable, with 2 release per year, one around April and the other around October.

Nevertheless it is not the ultimate tool, and a few drawbacks can be pointed :

• the framework needs a lot of disk space and machine resources.

• the documentation is good for current usages, but advanced usage may require to look under the hood, and a lot of study of internal mechanisms may be necessary to do advanced things the right way (Python knowledge welcome).

• the work is generally done through command line interface. This kind of interface can trouble developers who use to work with Eclipse. A dedicated Eclipse plugin for Yocto is available, but at the moment it can not be used in all use cases.

As a final conclusion Yocto is certainly the framework to use when developing products based on embedded Linux, as long as they need to leverage on the Linux ecosystem and rely on many software components. For simpler embedded distributions, Buildroot can be seen as an alternative, except if the product starts simple but becomes more complex in future versions. In this latter case, it would be better to start directly with Yocto to avoid a package build system change during the lifetime of the product.

  The main solutions in this area are Buildroot[1], Scratchbox [2], LTIB [3] and Open Embedded [4] / Angstrom [5] / Yocto [6].Scratchbox seems not being active (last commit in April 2012).

Figure 1 :

 1 Figure 1 : The Yocto project development environment -Credit : Yocto project

Figure 2 :

 2 Figure 2 : Yocto recipe for a software package

Figure 5 :

 5 Figure 5 : Append recipe base-passwd-3.5.26.bbpappend

Figure 7 :

 7 Figure 7 : Location of native tools used during recipe execution

Table 1 :

 1 table summarizes strong and weak points of the other solutions :

	Tool	Pros	Cons
	Do It Yourself	Complete control on the build	Need to solve all dependencies
		process	manually
			Limited to simple configurations
			(few components)
	Buildroot [1]	Simple to use (Makefile based)	Intermediate set of available
		Active project and community	software components (much more possibilities than Do It Yourself, but
			too limited for smart devices)
			No partial build nor packages
	Scratchbox [2]		Deprecated
	LTIB [3]	De facto standard up to now for	Old solution, Freescale swaps to
		Freescale hardware	Yocto, will be soon deprecated
		Well supported by Freescale	Need old Linux distributions on
		regarding BSPs	developer's PC
		Large set of components available	Not used by many hardware
			providers

other tools comparison

Sandbox native sysroot

To avoid such mistakes, Yocto deploys all headers and libraries inside the target part of the sandbox, and uses the --sysroot option of gcc to forbid any access to native elements.


P Cuenot

C Ainhauser

N Adler

S Otten

F Meurville

Applying Model Based Techniques for Early Safety Evaluation of an Automotive Architecture in Compliance with the ISO 26262 Standard

Keywords: Automotive Architecture Description Language, ISO 26262, Functional Safety Analysis

In 2011, the automotive industry introduced the application of a standardized process for functional safety-related development of automotive electronic products. The related international standard, ISO 26262 functional safety for road vehicles, has high demands on process documentation and analysis. Within an engineering context this challenges the tremendous increase of complexity for modern automotive systems and high productivity demands for industrial competiveness purpose. Model based development techniques based on an Architecture Description Language (ADL) has been identified as the best candidate to manage the system complexity and the related safety analysis with the benefit of formal description and capabilities for test automation. The proposed concept relies on the definition of a compositional error modeling approach tightly coupled with the system architecture model, capable to analyze the software and hardware architectures and implementations. This paper explains the results of the language extension based on the EAST-ADL and AUTOSAR domain model in terms of early safety evaluation of an automotive architecture, automating the qualitative and quantitative assessment of road vehicle products as claimed by the application of the ISO 26262.

Introduction

The international standard ISO 26262 [START_REF]International Organization for Standardization[END_REF], published in November 2011, is the adaptation of the generic safety industry standard IEC 61508 [START_REF]Functional safety of electrical /electronic/ programmable electronic safety-related systems[END_REF] to comply with specific needs of the automotive industry for development of road vehicles of less than 3.5 tons. It defines the process for the overall safety lifecycle of electrical and/or electronic (E/E) systems and specifies safety-related activities to be performed during the development cycle. It emphasizes a system engineering approach with the delivery of process-related work products applicable on each engineering level such as system, hardware, software and on supporting processes.

The relevant safety analysis activities start with the item definition during vehicle concept phase and progress with the evaluation of ability to mitigate or avoid hazards in identified operational situations. This evaluation allows the identification of the corresponding safety goals with a classified Automotive Safety Integrity Level (ASIL), in order to initiate the process-based requirements. Subsequently systematic analysis of causes and effects of the system malfunctions shall be initiated on preliminary safety analysis. During system development, safety measures have to be defined to control, reduce or avoid effects of the malfunctions of the system components. Faults inside components can be random hardware faults or systematic faults. The analysis of causes and effects of these faults has to be performed in order to evaluate if they can violate a safety goal. Technical safety mechanisms shall be specified to detect and control the components faults and mitigate their effects to prevent a system malfunction. Clause 7.4.3 of ISO 26262, Part 4 "Product development at the system level" [START_REF]International Organization for Standardization[END_REF], requires deductive and inductive methods to perform safety analyses. These analyses have to be completed down to the level of hardware and software components as claimed in Part 5, Clause 7.4.3 and Part 6, Clause 7.4.13, respectively for "product development" at "hardware" and "software level" [START_REF]International Organization for Standardization[END_REF]. Moreover, Part 5 demands evaluation of the hardware architectural metrics and of the safety goal violation due to random hardware failures. In actual automotive engineering practice, the safety evaluation of the system architecture is performed lately in the product development. Additionally, due to the increased product complexity and the large amount of components, there is a high risk of inconsistency between the safety analysis and the designed product. This error-proneness is increased by the use of different tools for engineering design and safety/reliability analysis. Therefore, there is a strong need for novel methodologies to facilitate safety design and safety verification activities in an iterative and safety-aware process. These methodologies shall close the gap between the definition of the architecture elements and their associated malfunctions with their failure propagations over the architecture. This eases the definition and the evaluation of the impact of safety mechanisms integration. The required quantification of the hardware metrics, Clause 8 and 9 of ISO 26262 Part 5 [START_REF]International Organization for Standardization[END_REF], shall be aided by methodology through organizing the failure rate of the set of hardware electronic parts to facilitate safety hardware architecture upgrade. From software side, recently, the automotive industry adopted the AUTOSAR [START_REF]AUTOSAR Development Partnership[END_REF] standardized architecture supported by model based technology for describing software component implementation and integration, and the ECU resource configuration. Release 4.0 has been delivered in late 2012, containing already a well-defined set of safety mechanisms responsible for error detection (e.g. watchdog manager) and error handling (e.g. diagnostics or error reporting to the application layer). Moreover, the architecture description language EAST-ADL [START_REF]EAST-ADL Association supporting EAST-ADL2 Language[END_REF] designed to support the vehicle architecture and the control of engineering artifacts (such as requirement, variant management control, etc...) has been harmonized with the AUTOSAR architecture and initiated the direction for supporting safety analyses in the EAST-ADL version 2.1 [START_REF]EAST-ADL Association supporting EAST-ADL2 Language[END_REF]. Thanks to the use of model based techniques, we propose to extend and complement these state of the art architecture languages, to define new methodologies able to support, accelerate and preassess safety analyses complying with ISO 26262 qualitative and quantitative assessments from the architecture level down to the level of the hardware and software implementation. Our paper is structured as following. Section 2 introduces the state of the art of model based safety analysis that has been considered during this work. In section 3 the concept of error modeling and fault propagation to be able to perform safety analyses on automotive products is presented. Section 4 describes the proposed continuous methodology for safety evaluation across different abstracted representations of automotive products in compliance with the ISO 26262 process. Section 5 illustrates the use of the methodology in the context of the hardware architecture supported by a concrete example. Section 6 explains the context for appliance of safety analysis for an AUTOSAR software platform. Section 7 illustrates a case study and depicts a short overview of a tool prototype implementation for this methodology. Finally, conclusions draw the consideration of the designers' as end-users' perspectives, and the description of future work in Section 8.

Related Work

State of the art methods and tools for model based safety analysis have been introduced and are current practice in aeronautics industry. The actual civil avionics recommendation standard for safety assessment ARP4754 [START_REF]ARP4754A, Guidelines for Development of Civil Aircraft and Systems, Aerospace Recommended Practice[END_REF] and the associated methods in ARP4761 [START_REF]Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment is a standard, aerospace recommended Practice[END_REF] toward model techniques have been largely investigated during this decades. In particular during the ESACS project [START_REF] Bozzano | ESACS: an integrated methodology for design and safety analysis of complex systems[END_REF] the use of AltaRica [START_REF] Arnold | The AltaRica formalism for describing concurrent system[END_REF] formal language was evaluated, lessons learnt based on Airbus aircraft safety analysis capitalized [START_REF] Bieber | Safety Assessment with AltaRica -Lessons learnt based on two aircraft system studies[END_REF], and the benefit for the application of the ARP standards demonstrated. On the top of practice for E/E architecture assessment, another usage of AltaRica was proposed in [START_REF] Adeline | Toward a methodology for the AltaRica modelling of multi-physical[END_REF] targeting multi-physicals systems. Nevertheless, most of these successful model based analyses only consider system at equipment level, where the equipment fulfills only a single functionality. Therefore these proposed methods are difficult to apply at software or hardware implementation level due to combinatory explosion of basic technology. Another approach was proposed in the context of the ASSERT project [START_REF]ASSERT Project final[END_REF], by automatic building of dependability-oriented analytical models from high level AADL [START_REF]AADL, Architecture Analysis & Design Language[END_REF] architecture models. Thanks to AADL error model, Markov analysis can be performed and fault trees can be generated and analyzed [START_REF] Rugina | A System Dependability Modeling Framework Using AADL and GSPNs[END_REF]. Advanced experiments were performed on Integrated Modular Avionic (IMA) architecture, having similar software architecture than AUTOSAR. The complexity of automotive ECU integrating tremendous electronics parts with large diversity (e.g. microprocessors or ASIC's) cannot be standardized as for IMA approach by high level modeling. Related to the automotive research project ATESST2, the EAST-ADL [START_REF]EAST-ADL Association supporting EAST-ADL2 Language[END_REF] architecture language description was extended to support safety analyses thanks to the connection of failure synthesizer HiP-HOPS [START_REF] Papadopoulos | Engineering failure analysis and design optimization with HiP-HOPS[END_REF]. The proposed methodology allows performing cut set fault tree analysis (FTA) and failure mode and effect analysis (FMEA) from analysis of the automated generation of faults. Meanwhile, such proposal for analysis is mainly functional oriented to support system modeling. But it does support neither software implementation analysis nor hardware metrics calculation. Focusing on hardware evaluation, the work of Jeon et al. [START_REF] Jeon | Automotive hardware development according to iso 26262[END_REF] describes the process of performing hardware architectural metrics. However, there is neither a semi-formal or formal method nor a prototype implementation available. Additionally, the proposed methodology discussed by K. Svancara [START_REF] Svancara | Experience with the second method for eps hardware analysis: "evaluation of each cause of safety goal violation due to random hardware failures[END_REF] for residual risk evaluation of the violation of a safety goal using Failure Rate Class method (alternative method proposed by ISO 26262 instead of using PMHF) brings strong benefit to ISO 26262. Integration in model based environments would support automation of the analyses. In the article of [START_REF] Adler | Performing Safety Evaluation on Detailed Hardware Level according to ISO 26262[END_REF], a model-based methodology for the implementation of hardware assessment based on detailed hardware level according to ISO 26262 is proposed. It shall be extended to permit hardware metrics evaluation at the architecture level. The current work of the European project 'Safe Automotive soFtware architecture' (SAFE) [START_REF]SAFE project[END_REF] organized in the framework of ITEA2, aims to overcomes these gaps applying model-based approach for automotive safety-related systems.

SAFE Error Modeling Concept

The selected modeling languages for SAFE are EAST-ADL and AUTOSAR. Relationship between these two domain models have been largely discussed and documented in the ATESST project during the elaboration of the EAST-ADL language.

For the description of the automotive system architecture on different abstraction levels, AUTOSAR represents the implementation layer for software and additionally has to be improved to sketch hardware implementation. EAST-ADL has to be enhanced to represent separate but interrelated architecture views of hardware and software component.

Regarding error modeling, the proposed approach extends the structural architecture elements on each abstraction level, by a straight forward relation. The related error model captures the malfunctions and errors relations between the elements. In details, the error model describes the black-box view in terms of error propagation for the referenced structural elements. Thus, the error model reports the visible interfaces external faults for incoming faults and external failures for output failure. The error model is also associated with white-box information as the error behavior of an element. In this case, the internal details of the structural element are known and the respective internal faults (e.g. random internal hardware faults) as well as the process faults (systematic faults such as design, implementation, installation, operation and overstress faults) can be described. It is possible to describe with semi-formal notation how malfunctions as external faults, internal faults and process faults are related with external failures. This behavior is defined as error behavior, as depicted in Figure 1.

Figure 1: Error model overview

Moreover, the integrated view of the error models allows connecting external failures and external faults using the concept of a cause-effect relation named fault failure propagation link. This way it is possible to describe how external faults can be caused from preceding architectural elements and describe a complete error propagation chain from the root fault(s) towards the failure of interest. In addition a vertical propagation error model mapping is introduced to handle assumption made during safety analysis across different abstraction levels. In the scope of the error behavior, the SAFE metamodel allows to either use a selected language (AADL, HiP-HOPS, AltaRica or free format) or the simplified SAFE language for the same purpose. The objective was not to reinvent a complete language, but to build the requirements for the grammar and the semantics of a simplified SAFE language that could be transformed transparently in HiP-HOPS or AltaRica for the user.

Safety Concept Continuous Evaluation

The safety analyses for each safety goal are used to support the safety concept and the development design phase activities. Requirements are derived from safety goals and refined up to HW/SW requirements as reflected in the ISO 26262 Part organization. The top level malfunctions can be formally captured for the identified model element of the item decomposition as recommended in Clause 7.4.2 of Part 3 "Concept Phase" during the hazard and risk analysis phase. The allocation of functional safety requirements onto the functional architecture represented in the analysis level of EAST-ADL allows defining the scope of the initial safety analyses. The analyses are built on local element malfunctions, e.g. similar to FMEA, used to perform systematic analysis of causes and effects of the malfunctions of the system elements. The malfunctions and error behavior are captured in the error model and propagate through the complete system model, finally linked to the top level malfunctions. The transformation of the complete system error model to a failure synthesis tool environment e.g. AltaRica [9] [START_REF]Safety Designer V9[END_REF] or HiP-HOPS [START_REF]HiP-HOPS from University of Hull[END_REF], allows qualitative evaluation of the violation of the safety goal. The tool output shall at least exhibit failure cut sets and sequence failures, extracted from a generated fault tree. To satisfy safety requirements, safety measure requirements are introduced to mitigate or control effects of the malfunction of the system elements. They can then be traced to the structural elements, and may induce modification on architecture elements to mitigate the respective failure. According to the update of the error model, the safety analyses can be re-executed to verify the functional safety concept, as granted by the Clause 8.4.5 of the Part 3 "Concept Phase". The overview of the safety analysis process is summarized in the Figure 2. calculation, the fault shall be tagged as single point fault, residual fault or latent fault. This tag "component fault" of an element depends on the context. It is defined from combination of the result of the qualitative analysis as the cut-set order, a malfunction as a leaf of a fault tree, and from the traceability information identifying its coverage by a safety mechanism. This is identified by a satisfy relationship from hardware component (or its subpart) playing the role of a safety mechanism, to a safety mechanism requirement.

The diagnostic coverage (DC) for latent and residual faults is a property of a "safety mechanism". Their values are used for final SPFM and LFM calculation.

They are defined as targets for the architecture for implementation of a safety mechanism solution element. The target value shall be compatible with the impact in hardware metrics for each safety goal, and be bounded by the worst case value matching the maximum ASIL level. They have to be verified from the detailed design architecture using electronics parts reliability data. The DC target value and fault qualification can then be used to derive hardware safety requirements assigned on selected parts of the electronic design. We propose a quantification of the failure rate of this hardware component by a formula built from the reliability data of the super set of electronic parts. The result of the calculation can then be re-introduced as the value for the failure rate of the respective hardware component, to verify the estimated value from the preliminary SPFM and LFM calculation.

The concept of component failure rate allocation is also applied for the evaluation of residual risks of safety goal violations from Clause 9 of ISO 26262 Part 5. Two alternatives are proposed: Failure Rate Class (FRC) method and "Probabilistic Metric for Random Hardware Failure" (PMHF). FRC method evaluates each hardware component individually, while PMHF presents a global approach using as an example a quantified FTA. As for architectural metrics, the relation to electronic parts super set and associated formula can be used.

AUTOSAR software evaluation

In the AUTOSAR architecture, the software is composed of many interconnected AUTOSAR software components, which are deployed on the microcontrollers within the ECUs. In addition, the microcontrollers also contain an AUTOSAR basic software stack which controls the Microcontroller Unit (MCU) hardware and provides generic services to the software components, like access to input/output channels, persistent memory or partitioning. The use of the error model concept allows creating a clear separation between the application layer and the application environment given from the AUTOSAR infrastructure (ECUhardware, basic software and RTE). This split permits to analyze the software considering the impact of the different malfunctions from the application environment. The set of malfunctions originated from the environment are clustered into computing and communication anomalies. Figure 3 below depicts the separation of the application layer and the application environment for safety analysis purposes.

Figure 3: AUTOSAR error model separation

The failure ports of the application layer match exactly those of the application environment. Moreover, the abstraction of the infrastructure can be improved to reach the level of ECU partition as defined by the AUTOSAR specification. The ECU partition, (e.g. each ECU in Figure 3 could be seen as independent ECU partition) guarantees freedom from interference of software applications and allows to deploy application software with different ASIL allocation to the same ECU.

The application environment describes the malfunctions induced by the execution platform incl. network technology. Horizontal propagation links express how errors propagate from one software component to another on the same level. Having this information as input, a complete AUTOSAR software safety qualitative evaluation can be performed using the same tool environment as proposed in section 4.

Case study and tool prototype support

One of the selected public case studies to exhibit methods and tools developed in the SAFE project is extracted from the ISO 26262 Part 5 Annex E. This initial example is re-engineered to demonstrate safety analysis during the engineering development down to the level of implementation level. This section explains the use of the case study to reach SAFE project objectives. In addition, relation to relevant parts of the SAFE tool environment is given.

The SAFE tool environment is built upon the open source SAFE reference platform connected with specialized safety analysis tools like PREEvision [START_REF] Preevision | Vector Informatik GmbH[END_REF] from Vector or SafetyDesigner from Dassault Systèmes [START_REF]Safety Designer V9[END_REF]. The SAFE reference platform provides an EMF-based Java implementation of the SAFE meta-model and integrates the AUTOSAR meta-model implementation from ARTOP [START_REF] Artop | AUTOSAR Tool Platform User Group[END_REF] as well as the EAST-ADL meta-model implementation from EATOP [START_REF] Eatop | EAST-ADL Tool Platform from Eclipse Automotive Industry Workgroup Lab[END_REF]. The SAFE meta-model platform offers a basic authoring experience, i.e., an Eclipse perspective with a tree-based model explorer view for navigating through SAFE model files. It allows editing safety-related extensions for EAST-ADL and AUTOSAR models. This content is defined as the minimum content and shall facilitate platform extensions, in particular for development of graphical user interface and specialized safety analysis tool development.

Safety Goals

The case study is an automotive system that realizes two functions inside the same ECU. Function one is controlling a sensor temperature in order to open an external valve in case of overheating. The potential hazard is a vehicle catching fire. First hazard and risk analysis leads to the following safety goal classified with ASIL B criticality: "valve 2 shall not be closed for longer than x ms when the temperature is higher than 100 °C". Function two, with the constraints to be integrated into the ECU with only one processor is controlling the vehicle speed to open another external valve in case of upper limit speed, similar to cruise control functionalities. The second hazard can be identified as vehicle accident classifying the safety goal "valve 1 shall not be closed for longer than y ms when the speed is higher than 100 km/h" with ASIL C criticality.

Functional Safety Concept

The initial representation of the functional architecture of the system uses the analysis level of EAST-ADL. It is used to represent the Functional Safety Concept thanks to EAST-ADL analysis blocks complemented by the SAFE error model. For function one (seeFigure 4), the analysis level is represented by a FunctionalDevice for the temperature sensor, a second one for the output valve and an AnalysisFunction for the calculation of the temperature controlling the valve 2 activation. In addition, the internal failure propagation shall be defined according to the SAFE expression language. For Temp_Calculation, the failure propagation is expressed as follows: "ExtFailure_TC_Out.ERROR = ExtFault_TC_In.ERROR OR Internal_TC-F_Error". The implementation of the safety goal for function one corresponds to the deviation of one of the external failures of the top-level error model. This is shown as "valve2 event" in Figure 5. The deviation is represented by the occurrence of the malfunction PError on the MFPFunctionPort output. This first error model representation allows performing qualitative safety analysis on the functional safety concept as recommended in Figure 2 of section 4. The connection of fault synthesis tools to the SAFE reference platform is still under development. So, the error model was re-captured in the syntax of the fault synthesizer using the HiP-HOPS [START_REF]HiP-HOPS from University of Hull[END_REF] analyzer. The functional architecture and SAFE error model element were mapped to the syntax of HiP-HOPS to evaluate function one. Not surprising, the results lead to an order one of the cut set caused by basic event Sensor_Error on the temperature sensor block or by a Function_Error on the temperature calculation and control block. A functional safety requirement is created, where the attribute Tactic field indicates the expected detection and mitigation strategy. For function one, it indicates that the external failures associated with the error models for Temperature_Sensor and Temperature_Calculation shall be mitigated. Thus, a new EAST-ADL analysis block LifeChecker is introduced, as shown in the complete architecture in Figure 6. The hardware watchdog of the example is seen as a possible implementation of the LifeChecker. The hardware architecture is based on EAST-ADL HWComponentPrototypes representing hardware functional blocks, and integrates the electronic driver abstraction (as represented in Figure 8). The software architecture is defined using EAST-ADL DesignFunctionPrototypes. The error propagation between hardware and software needs to consider first via their interface (HSI). For this purpose, SAFE declares the HardwareSoftwareInterfaceElement, allowing to reference port interfaces between the EAST-ADL elements FlowPort and HWPin.

Secondly, the software function allocation to hardware processing units was declared using the Allocation element of EAST-ADL. Then, system error model is built and split into two perspectives, one for the hardware and one for the software. For interfacing the error model, each perspective declares its external faults and/or external failures to describe the incoming faults and propagating failures of the individual perspective. They are modeled as MFPFunctionPort for software and MPFHWPin for hardware and linked by a FaultFailurePropagationLink. This link is referencing the port malfunctions and the source element of this propagation, respectively an HSI element or an Allocation net. HiP-HOPS support the perspective concept and dedicated syntax for fault propagation between perspectives and the previously created SAFE artifacts like MFPFunctionPort or ErrorModel are mapped to the HiP-HOPS syntax. This modeling style allows synthesizing a fault tree including elements from software and hardware perspective. As for functional safety concept analysis, the introduction of malfunction mitigation through technical safety requirements and concrete realizations allows defining the complete technical safety concept. The SAFE reference platform was used to capture the architecture and error model. The HiP-HOPS file has been generated manually. As we can see in the Figure 10 for temperature control (function one), the introduction of the output diagnosis (port OutFbV2) mitigates a bad software control (port HIS_Drv2_out_v2). It can also be noticed that failure of the output power stage hardware driver directly affects the control of the valve 2. associated data), timing_error (data arrives too late/too early), omission_error (data does not arrive) and commission_error (data arrives too often). As a next step, we describe the error model of the considered software. As mentioned in section 6, we distinguish between application layer and application environment. The error model for the application environment includes the malfunctions induced by the complete basic software stack and the hardware components of the ECU. The error model for the application layer includes a hierarchical description of the error propagation within the AUTOSAR software components under consideration. Figure 12 highlights the ErrorModelType of the software component TempControl. The SAFE meta-model allows to link the model elements of the ErrorModelType with the architectural elements. For example, the external failure ExtFailure_TC_Valve2 (see Figure 12) is associated with the respective data element of port TempControl.pTCValve2 (seeFigure 11).

Conclusion and future work

In this paper we presented a methodology for model based safety analysis of automotive systems. Based on a case study, we demonstrated its capability to perform early assessment of safety concepts. The different evaluations comply with the ISO 26262 "Road Vehicle -Functional Safety" and facilitate the design of automotive products via qualitative evaluation of the architecture, from functional abstraction down to implementation layer (e.g. AUTOSAR software architecture). In addition, it provides a proposal to control the complexity of electronic design to compute the quantitative measures required by the ISO 26262 standard.

Results for the hardware architectural metrics

Calculation of the hardware architectural metrics: single-point fault metric and latent-fault metric for each specific safety goal.

SafetyGoal1

Hardware Architectural Metrics The automotive domain, quite conservative for methods but subject to competitive market, requires a fully integrated environment to ease modeling and to abstract the complexity of safety analysis constructs. Despite actual maturity of specialized analyzer, this is still a challenge. In particular, today's tools only partly support the automotive design engineer adequately in its activity to conduct multi domain safety analysis with short iteration loops.

The complete safety assessment of AUTOSAR infrastructure including hardware architecture, in particular the relation between middleware and related hardware element is still under investigation. This is part of future work.

Figure 2 :

 2 Figure 2: Safety analysis process overview for functional safety concept Afterwards, the first version of the technical safety architecture and associated error model can be defined. It is built from requirement refinement (respectively functional safety requirements (FSR) into technical safety requirements (TSR) and from safety measure requirements into concrete hardware or software components as safety mechanisms) as well as from the allocation of technical requirements onto hardware and software architecture elements. Similar to previous methodology, the qualitative evaluation is performed compliant to Clause 7 of the ISO 26262, Part 4 "System Level" and common cause analysis can be preliminary assessed on component level. Before starting the hardware design, the quantitative evaluation of hardware architectural metrics and residual risk targets for each safety goal conforming to Clause 8 and 9 of the ISO 26262, Part 5 for the hardware level can be performed to help refining the hardware safety requirements .More detailed information about additional modeling constructs and methodology is detailed in section 5. Finally, corresponding hardware and software disciplines can start implementation of hardware and software products. The error model and safety analyses can still be applied on the modeling elements using aggregation of error model to AUTOSAR modeling constructs. Failure mitigation and assumption can still be traced and verified according to the architecture thanks to the use of the error model mapping construct.

Figure 4 :

 4 Figure 4: Function one representation The SAFE error model references this top level architecture and is composed by three interconnected ErrorModelPrototypes (see Figure 5), one for each function block. Each ErrorModelPrototypes is typed by a respective ErrorModelType, which defines its MFPFunctionPorts in the role as external faults or failures. They are typed by a general MalfunctionType called "PError" representing the general error as failure propagated through the port. Each MFPFunctionPort is referencing the respective FunctionFlowPort of the selected EAST-ADL block to link the system model and the error model. The ErrorBehavior of each ErrorModelType is enriched by one MalfunctionPrototype in the role as internal fault and typed by one of the general

Figure 5 :

 5 Figure 5: Corresponding Error Model

Figure 6 :

 6 Figure 6: Functional architecture example

Figure 7 :

 7 Figure 7: Temperature Control fault tree analysisThe same process was applied on the wheel speed control (as function two) leading to the introduction of the second sensor and the diagnosis block and for the integration with the LifeChecker block.Technical Safety ConceptNow the technical safety concept is defined, based on technical safety requirements and the allocation of safety requirements to hardware and software.

Figure 8 :

 8 Figure 8: Hardware architecture example

  Figure 9 depicts the software architecture for function with the relation to hardware elements, including an exemplary declaration of software driver abstractions later integrated in the AUTOSAR Software infrastructure (BSW blocks Temp ADC Driver and Current ADC Driver).

Figure 9 :

 9 Figure 9: Design level software architecture example

Figure 12 :

 12 Figure 12: ErrorModelType for TempControl The semantics of the external faults/failures is given through the respective MalfunctionType associated with them. For example, ExtFault_TC_SensorInput has the type CommunicationAnomaly as described above. Moreover, the external faults/failure can be brought into relation, describing the error propagation within the architectural element. Considering TempControl, the external Failure ExtFailure_TC_Valve2 occurs, if a) the sensor input is invalid, or b) the inhibition signal provided by the component TempDiagnosis is invalid or c) the application environment exhibits a computation error leading to the erroneous execution of the software component. This can be described via the following expression: ExtFailure_TC_Valve2.value_error = ExtFault_TC_InhSignal.value_error OR ExtFault_TC_SensorInput.value_error OR ExtFault_ComputationError.* For a complete error model of function one, the unintended behavior of all involved architectural elements must be specified and interlinked. In particular, the ErrorModelType for the application environment describes the malfunctions of the concrete ECU where function one is deployed to. It includes, amongst others, one external failure describing improper computation. This malfunction is then linked with the external fault ExtFault_ComputationError of the error model for TempControl.This way, a complete failure net can be established, which can then be used as input for safety analysis tools to automatically derive safety-relevant

Figure 14 :

 14 Figure 14: Excerpt of report for hardware safety evaluation All analysis results are included in corresponding reports as a PDF file for documentation purposes, as exemplarily shown in Figure 14 for the hardware detailed design of ISO 26262 Part 5 Annex E. The presented hardware safety evaluations and modeling of hardware designs including failure data are also integrated as prototype plug-ins in the model-based tool environment PREEvision to ease consistent modeling and evaluation [25][26].

Realizes ASW "Temp Comparison" of Figure9

Includes ASW "Temp Conversion" of Figure9

Realizes BSW "Current ADC Driver" of Figure9

Realizes BSWs "Current ADC Driver" and "Temp ADC Driver" of Figure9

Acknowledgement

This work was supported by contribution of all the partners of the SAFE project consortium. This SAFE project in running 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).

We model the erroneous behavior of the architectural elements using the SAFE meta-model. Initially, we describe a library of MalfunctionTypes, which are of interest for the system under consideration. In our case, we propose the types ComputationAnomaly and CommunicationAnomaly. Each type can be hierarchically decomposed. In case of CommunicationAnomaly, we further refine this type into the following primitive MalfunctionTypes: value_error (invalid content of the conclusions like Single Point Faults leading to the violation of a safety goal. In the current state, no direct link between the SAFE tool platform and known safety analysis tools like Hip-Hops [START_REF]HiP-HOPS from University of Hull[END_REF] or SafetyDesigner [START_REF]Safety Designer V9[END_REF] is available. However, experimental attempts have shown that SAFE error models can be transformed into the respective representation of the mentioned tools.

Hardware Safety Analysis

Based on the technical safety concept in terms of hardware components as shown in Figure 8, the impact of random hardware failures has to be assessed according to the quantitative evaluations claimed by ISO 26262 Part 5. The determination of the classification is described exemplarily based on the fault tree shown in Figure 10. Failure mode OutputF1.PowerStage.OpenCircuit is directly affiliated via one OR-gate to the top-level event Valve2.PhysicalOutV2. This represents a minimal cut-set of order 1. Therefore, the failure mode is classified as a single-point fault. Failure modes which are contained in the branch of ECU.uController.Out_V2 are affiliated with the toplevel event via at least one AND-gate. Thus, they are represented in a minimal cut-set of order greater than or equals 2 and classified as latent multiplepoint faults. To complement the initial safety evaluation of hardware architectural designs, the hardware component failure rates values represent assumptions taken from previous designs or expert knowledge. In later phases of development, the hardware architectural design is refined at the level of electronic schematics, exemplarily shown in Figure 13. Alternatively to the hardware architectural design, safety evaluation could also be performed directly at the level of electronic schematics [START_REF] Adler | Performing Safety Evaluation on Detailed Hardware Level according to ISO 26262[END_REF].

For the quantitative evaluations according to [START_REF]International Organization for Standardization[END_REF], FZI has set up a research prototype implementation which provides classification of failure modes based on fault tree generation and analysis. Hardware structural and failure data for architectural and detailed designs can be imported using a XMLbased file format. Results of the quantitative evaluations are automatically verified against target values, which can be user-defined or taken from recommendation of [START_REF]International Organization for Standardization[END_REF].