electronic architecture and system engineering for ... · electronic architecture and system...

www.easis.org | [email protected]

Electronic Architecture and System Engineering for Integrated Safety Systems

From a technical point of view today’s safety systems are mostly stand alone systems with a limited degree of interdependency. These systems have to be integrated -combined with upcoming enhanced telematic services- into a complete network of so-called Integrated Safety Systems. An integrated approach to vehicle safety systems is essential in reaching the road safety targets set by the European Commission Transport Policy.For the realization of such Integrated Safety

Systems, powerful and highly dependable in-vehicle electronic architectures and appropriate development support are necessary. These elements must be standardized to achieve an improvement in system quality with shorter development times and lower system costs.The goal of the EASIS project is to define and develop the mentioned technologies to enable the realization of future integrated systems.

The Project EASIS

Challenges■ Integration of domain (Cabin, Chassis, Powertrain) overlapping safety functions with high dependability■ Handling of high system complexity■ Integration and multi-usage of environment sensing ■ Integration of telematics services for safety systems

Vehicle to VehicleVehicle to Road Infra-structureCommunication

EnvironmentDetection Redundancies

Gateways

Supplier 1 OEM Supplier 2

Function x

Safety-Function x

Active Safe

Telematics

PassiveSafety

.C .C.C

.C.C

Elements of Integrated Safety Systems

EASIS Approach■ Develop a modular scalable electronic architecture and a standardized system engineering approach for integrated safety systems■ Provide enabling technologies for the introduction of integrated safety systems


Project Objectives■ Modular scalable E/E-architecture for active, passive and integrated safety systems■ Services for communication, dependability and gateway functionality■ Embedded system safety analysis

■ Provision of high availability and safety ■ Move from fail-silent to fail-operational system behaviour

■ Provision of introduction plan for new concepts into existing automotive system architectures■ Preparation for standardization

WP

0: In

tegr

ated

Saf

ety

Req

uire

men

ts -

Vale

oWP 1: Software Architecture – Volvo

WP 2: Hardware Architecture – CRF

WP 3: System Dependability – Bosch

WP 4: Processes and Tools – ZF

WP 5: Exploitation, Evaluation, Validation – DC

WP 6: Project Coordination and Management – DaimlerChrysler

Vees

a St

udy

– D

C(v

ehic

le e

-saf

ety

Arc

hite

ctur

e)

2003 2004 2005 2006 2007

Project Plan

Project results■ A platform for software-based functionality in vehicle electronic systems has been defined, providing common services upon which future applications can be built. ■ A vehicle on-board electronic hardware infrastructure, which supports the requirements of integrated safety systems in a cost effective manner has been specified. ■ Methods and techniques for handling critical dependability-related parts of the development lifecycle have been analyzed, adapted, extended and defined.

■ An engineering process and a suitable tool chain have been defined, enabling the application of integrated safety systems.

The results are validated by two different domain overlapping demonstrators:■ To prove the gateway and firewall capabilities of the EASIS architecture, a telematics gateway is realized■ Overall system dependability e.g. in case of system or component failure is dem- onstrated by a commercial vehicle HIL testbench with an electronically controlled Intarder

Contact:

DaimlerChrysler AG | Research and Technology Dr. Vera LauerHPC 050/G007 | D-71059 SindelfingenPhone: +49-(0)7031-4389-340 | Fax: +49-(0)711-3052-1158-05E-mail: [email protected]

Project data The EASIS project is a joint effort of 22 partners from European vehicle manufacturers, automotive suppliers, tool suppliers and research institutes. Total Budget 9,4 million €EU contribution 5 million € 6th Framework Programme IST 2002 - 507690

The Project EASIS


Software Architecture

BackgroundFor the realization of Integrated Safety Systems (ISS) a powerful, highly dependable in-vehicle electronic architecture – both hardware and software – is necessary.Those elements, which are not competition-relevant for OEMs and suppliers, must be stan-dardized to achieve an improvement in system quality with shorter development times and lower system costs. One major part of this electronic architecture is the software architecture upon which the Integrated Safety Systems shall be executed.

WP 1: Software Architecture

Overall outcomeThe work on Software Architecture has produced the following results:■ Collection and analysis of the overall requirements concerning a software architecture that shall provide a platform for Integrated Safety Systems. These requirements take into account needs from the Integrated Safety Systems as well as from external sources (e.g. standards, hardware architecture). The identified services cover all aspects, although EASIS focuses on dependability related services.■ Definition of a functional interchange format, i.e., information concerning application components which is required to perform component integration for developing integrated safety systems.

■ Definition of the software topology of the platform identifying necessary components as well as interfaces between these components.■ Concepts and designs of the software platform for Integrated Safety Systems, including required services for integrated safety, interface between software and hardware, gateway services (both intra- domain and inter-domain). The design suggestions cover functionality, structure and interfaces of the services. The identified dependability services are described in more detail below.■ Prototype implementation and proof of concept for key aspects of the defined software architecture.

Main ObjectivesIn the past years, computer-based systems have taken on a major role in the provision of functionality in vehicles such as cars and trucks. Computer-based systems and especially future integrated safety systems in vehicles have high demands on reliability, but also on cost. As the replication of software is virtually free, this is an attractive way to implement functions. Reusing previously verified and validated software also contributes to reducing the cost of ensuring the quality of the software. The main objective is to provide a basis for software-based functionality in vehicle electronic systems providing common services upon which further applications can be built, including:

■ Principles for software topology issues such as common services and mechanisms, module integration, and interface between common modules.■ Basic fault tolerance and diagnosis mechanisms and their integration in the overall software topology.■ Concepts for software gateway features, e.g., firewalls for use with telematics.

Layered architecture of the software platform


Contact:

Volvo Technology ABDr. Martin HillerSE-40508 GöteborgSWEDENEmail: [email protected]

Main contributors

In the work on dependability and gateway functionality in the software platform, a number of services have been defined.Here are some examples:■ Agreement protocol. Distributed decision making and control requires that the components constituting the ISS can assume that all components have the same view on the information that is used as the base for decisions or control actions.

■ Watchdog management. Watchdogs can be used to detect situations where software components malfunction in such a way that timing is affected, e.g., hanging components and crashed components.■ Fault management framework. To perform dependability services in an

efficient manner, the platform needs to have a good overview of the state of the applications as well as the ECUs. For this, a monitoring framework supervising systematic fault handling activities, e.g., reconfiguration, is defined.■ Gateway. Future vehicles will communicate with a number of external entities, such as adjacent vehicles, the road infrastructure and external service providers. This communication needs to be routed and translated such that the information can be transported from the wireless telematics networks to the wired automotive networks. To this end, a transport protocol is developed called the Common Transport Protocol (CTP).■ Firewall. Having an access point in the vehicle which can be reached in a wireless manner opens up possibilities for malicious attacks from external sources. In order to handle these attacks and ensure that the state of the vehicle is secure, firewall services are required.

Some dependability and gateway services of the EASIS software platform

WP 1: Software Architecture

Agreement protocol

Firewall for protection against malicious attacks


Hardware Architecture

BackgroundA prerequisite for the near future introduction of Integrated Safety Systems (ISS) is the definition of a vehicle on-board electronic hardware infrastructure that supports in a cost effective manner the very high ISS application demands in terms of dependability, computational power, high speed and accurate information exchange.This infrastructure consists of a distributed electronic architecture composed by several Electronic Control Units (ECUs) with a proper internal fault tolerant design, connected by means of a complex communication system and a dependable power supply network. Such hardware architecture must support the different software layers defined in the Software Architecture.

WP 2: Hardware Architecture

Main ObjectivesMain requirements addressed for this hardware architecture are:■ Scalability to support standardized usage for safety and non-safety applications■ Flexibility to cope with the

different application domains and vehicle classes

■ Architectural simplicity■ Capability of handling a large

variety of new kinds of sensors and actuators

■ Support for fault tolerance, error detection and error handling

■ Well defined and standardized interfaces

■ Means for functional integration into silicon components

■ Optimised costs and reliability

Backbone (FlexRay)

FSGWnode

FSGWnode

FS

FS

FS

FO GW unit

FS

FS

FS

FS

Domain B

FSGWnode

FS

FS

FS

Domain A

FailOperationalUnit

INPUT LOGIC

DRIVERS

MAINPROCESSOR

SUPER-VISOR

INPUT LOGIC

DRIVERS

MAINPROCESSOR

SUPER-VISOR

Va Vb

Scalable, dependable hardware architecture

The principle followed in the definition of the hardware architecture is “composability”. This means that fulfilment of the main requirements has been achieved trough an architecture implemented by composing several standard electronic elementary fail silent nodes (FS). The FS nodes are connected in a network within a certain application domain and all the domain networks are linked to each other through gateways (GW) and by means of a common backbone bus. When safety is required, a Fail Operational (FO) unit is achieved by

combining two FS nodes. In this way we reached the requested paradigm shift from the simple overlap of control systems with some information exchange (like in today’s vehicle architectures) to the real integration of systems and functions running on a distributed computational network made of standardized hardware nodes. Secure vehicle external communications with the infrastructure and with the other road users (as required by ISS applications) is also supported through the implementation of gateways.


WP 2: Hardware Architecture

Contact:

Centro Ricerche Fiat Ing. Massimo Osella Strada Torino 50, 10043 Orbassano (TO), ITALYEmail: [email protected]

Main contributors

Overall outcomeThe Hardware Architecture work has given the following results:■ Collection and analysis of the overall

requirements relating to a hardware architecture that shall provide a platform for Integrated Safety Systems. A special focus has been given to the functional requirements and to the dependability requirements that are considered the innovative parts of this architecture.

■ Design guidelines and general vehiclesystem architecture framework solutions for composing the future specific ISS production applications into high- and low-end vehicles. The guidelines address :

■ Concepts for the system topology ■ Partitioning between components and between HW and SW ■ Power supply strategies ■ Fail Silent hardware architectures ■ Sensors and actuators connections ■ Overall communication infrastructure ■ Protocols and network topologies

■ Gateway concepts ■ Communication services■ A simulation platform for design and

configuration of communication systems with multiple sub-networks, gateways modelling, end-to-end latency verification under critical payload situations.

■ An electronic control unit prototype withfail silent characteristics proposed as the basic functional standard node that is able to:

■ show the composability of two fail silent nodes (FS) into a fail operational unit (FO); ■ evaluate the fail silent principles by means of a dual processor architecture; ■ experiment the redundant power supply strategy and the sensors and actuators connection solutions defined in the project;■ An electronic control unit prototype

to be used as a gateway to the telematic domain, showing the routing and firewal-ling characteristics.

Fail Silent node

hardware prototype


WP 3: System Dependability

System Dependability

BackgroundIntegrated Safety Systems have demanding requirements in terms of dependability, especially regarding the dependability attributes safety, reliability, availability and security. Moreover, achieving system dependability in a predictable and assessable way will be significantly harder for integrated safety systems than for traditional safety-critical vehicle subsystems. There are three reasons for this: criticality of software, complexity and responsibility.

First of all, software-based components will become more safety critical than in traditional systems. The more complicated the control-mechanisms of safety-critical actuators become, the less it will be possible to achieve dependability by other technology fallback (e.g. mechanical backup).

The second reason is the higher complexity of integrated safety systems. Aspects of complexity in integrated safety systems are a high number of connected ECUs providing a function, a high complexity of the functions

in terms of the number of inputs and the number of failure modes to be considered, the possibility of actuator control conflicts between different safety functions, and the complexity of the control algorithms.

The third reason is that no single party involved in the development of integrated safety systems will be able to take over the sole responsibility for system safety and dependability. Methods and approaches are necessary that support shared responsibilities.

While the transition towards complex safety-critical software-based systems has already taken place in other industries (e.g. avionics), the approaches followed there for achieving system dependability are not transferable to the automotive industry without modification – due to different constraints concerning volu- mes, variability, and cost. Current standardi-zation activities (namely the ISO WD 26262) reveal the need for a suitable automotive electronics dependability methodology.

EASIS Dependability Activity Framework


Main contributors

WP 3: System Dependability

The goal of the EASIS work package “System Dependability” is to back up the systemengineering of integrated safety systemsby providing guidelines for dependability-related activities in system development.The following topics are covered:■ EASIS dependability activity framework. The activities included in any process may be arranged in a framework that shows how they are related to each other and to the overall aim of the process. In EASIS we define a dependability activity framework (see Figure 1) based on an evaluation of some existing dependability frameworks defined by commercial consortia, standardization bodies, and research projects. The aim is to identify a set of dependability- specific activities that should be carried out during the development of an Integrated Safety System, or indeed any automotive control system. ■ Hazard identification, classification and occurrence analysis. This work provides suggestions and guidelines on how to perform these activities based on established analysis methodologies and classification schemes, adapted where necessary to fit the automotive environment. Hazard identification deals with identifying undesirable vehicle-level states and behaviors that may be created by the system under consideration. Hazard classification deals with placing the identified hazards in categories depending on a set of attributes, such as severity, exposure and controllability. Hazard occurrence analysis deals with

identifying potential causes of hazards and assessing the probability of a given hazard occurring. ■ Establishment and verification of dependability-related requirements. This work provides suggestions and guidelines on which activities should be performed, and how these should be performed, in order to collect and verify requirements that concern dependability. These requirements can be functional requirements, e.g., requirements on dependability mechanisms for detection and handling of faults and errors, as well as non-functional requirements, e.g., requirements on design and manufacturing processes.■ Formal methods. An attractive way of guaranteeing correctness, and to ascertain that specific dependability requirements are met by a given system design, is to provide formal proofs. Formal methods effectively supplement traditional verification and validation techniques, especially for complex distributed control systems. This work provides a survey of existing approaches for formal specification/ modeling and formal verification and a set of case studies showing the applicability of selected approaches to automotive system development.■ Safety cases. A safety case provides a structured argument for why a given system can be considered adequately safe, and provides evidence for specific aspects concerning safety. This work provides guidelines for how safety cases should be constructed in an automotive setting.

EASIS Results

Contact:

Robert Bosch GmbH, CR/AEAMr. Marko AuerswaldP.O. Box 94 03 5060461 FrankfurtEmail: [email protected]


Processes and Tools

BackgroundTo meet future safety requirements, the automotive community is faced with a demand for E/E architecture and a systems engineering process that fits the needs of Integrated Safety Systems. The activities of this work package focus on the systems engineering process, which needs to be as uniform as possible and supported by a cross-competitive and seamless tool chain. Efforts concentrate on a specific automotive tool environment which has to correspond to the desired vehicle architecture, as defined by the EASIS work on Software and Hardware, taking the System Dependability results into consideration.

WP 4: Processes and Tools

Main ObjectivesFrom the engineering point of view, an Inte-grated Safety System (ISS) uses intra vehicle and infrastructure information to influence a real time chassis- or powertrain-control system, thus transforming a basic-function control-loop to an ISS control-loop. While the engineering process for basic-function control-loop systems is well understood, ISS control-loop design requires new approaches w.r.t. the development process and supporting tool chain.

The main work in this work package is focused on the following three aspects: ■ Systems engineering processes for ISS and their functional software components. ■ Tool chains supporting the engineering processes.■ Certification and test activities.

Based on the above, an analysis of require-ments (collected within EASIS and from other

projects) was conducted that revealed new challenges for the development process arising from the introduction of ISS: There will be an shift in implementation, from traditional hard-ware, to software intensive systems, leading to a composition of safety functions distributed across different in-vehicle ECUs. In case of diverging or conflicting signals or requests to actuators, the coordination / arbitration of dif-ferent ISS functions will be a challenge, while system dependability requirements will increase.

Results and ongoing workThe achieved results and ongoing activities of this work are summarized as follows:■ EASIS Engineering Process Framework (EEPF): EEPF describes the key components of an engineering process necessary to support the development of ISS. It identi- fies the need for an ontology or meta-model to give a well-defined basis for the description of artifacts and activities throughout the engineering process.■ Furthermore, risk assessment and control activities must be seamlessly integrated into the “standard” engineering process and should be performed as early as possible (“frontloading”). The framework also covers the reuse of components or modules within families of similar products based on a standardized software architecture and the distribution of work between partners (e.g. OEM and supplier).

SystemIntegration Testing

SystemRequirements

SoftwareRequirements

AcceptanceTesting

SoftwareDesign

Software Integration Testing

Coding Unit Testing

ISS Control Loop Basic Function Control Loop

Towards an ISSdesign methodology


Contact:

ZF Friedrichshafen AGDr. Jürgen LucasD-88038 Friedrichshafen - GERMANYEmail: [email protected]

Main contributors

WP 4: Processes and Tools

■ Application of EAST ADL to ISS development. To fulfill the request for a metamodel identified in the EEPF, the EAST-ADL (Archi- tecture Description Language developed in the project EAST-EEA) is used as a meta model for the description of artifacts and activities in the development process.■ EASIS Engineering Process (EEP). Based

on the EEPF and the EAST-ADL, the EEP is proposed as one possible instantiation of the framework. It forms a software-specific sys-tems engineering process which is aligned with the needs of the automotive industry. Activities and input/output documents for every process step are defined. The EEP is organized along the different subsets (or abstraction layers) of the EAST-ADL.

■ Integration of overall system development process and risk analysis. The EEP described above is equipped with entry points where processes and methodologies aimed at system dependability are integrated.

This produces a complete process for the development of ISS.

■ Correctness by construction approach. This approach is proposed as a means to progress from the high level activities defining the Functional Analysis Architec-ture (FAA) of a vehicle down to the actual executable code, via the various views of the EAST ADL framework.

■ Tools and methods are proposed to aid in the analysis and design work. These recommendations are given as annotations to the steps and stages of the EEP.

Key concepts and methodologies of this part of the EASIS project will be validated in order to demonstrate the applicability of these ap-proaches. For this purpose, a validator has been created:The EEP is used to develop a safe speed function for use in commercial vehicles. This function automatically reduces truck speed to a maximum safe level for the road, by limit-ing engine torque and applying brake torque. Rapid Prototyping equipment will be used to quickly build and adapt the function. A hard-ware-in-the-loop (HIL) test bench will be used as basis for validation.

EEPF: Process stages based on Meta Models

Layer 2: Requirements spec. - analyzable model

Layer 3: Functional design to satisfy Level 2

Layer 4: Functionality needed to support Level 3

Abstract datatypes & names from meta model & vocab of Layer 2

Datatypes & names from meta model & vocab of Layer 3

...

constraint

constraint

feedback

feedback

feedback

feedback

KNOWLEDGE

BASE

2T3

1T2

3T4

4T5Meta model EAST -ADL,formal verification,simulation for validation

Integration of safety activities such as system hazard analysis to update safety requirements

FAA model

Structuredsystem

requirementsspecification

Specifydynamicbehavior

Specifyfunctionalarchitecture

Specifyfunctionalbehavior

UML

„Outer View“ „Inner View“

FAA structural

model

Behaviormodelingtool

UML/ADL

EEP: Integration of safety related steps

EEPF: Process stages based on Meta Models


EASIS Architecture Validator

BackgroundTo reach a high stage of maturity and a verification of the results elaborated in the different EASIS work packages, a prototypical implementation of EASIS Architecture will be realized and tested in WP5.1 task.WP5.1 Validator aims to develop, implement and validate some of the most relevant

proposals developed in EASIS project, mainly defined in WP1 (software) and WP2 (hardware). In particular, WP5.1 Validator will be used to validate the suitability of developed architecture to implement integrated safety functions working across domains in a reliable, safe and secure way.

WP 5.1: EASIS Architecture Validator

DescriptionThe EASIS Telematics Gateway Validator includes:■ Fault tolerant communication network ■ Fault tolerant hardware with dual duplex architecture showing the composability of two fail silent nodes to built a fail operational node■ Fault tolerant software services providing common services upon which further applications can be build, including: ■ Agreement protocol ■ Fault management framework ■ Software watchdog ■ Dual-duplex fault tolerant signal processing ■ Telematics Gateway between internal buses (fault-tolerant FlexRay network and CAN network) and external Telematics network (WLAN/Ethernet) with protocol conversion and security services

FSUnit

FSUnit

Vehicle DynamicsSimulator

Central NodeSAFESPEEDSAFELANE “Spy“ Node

FSUnit

Ethernet

CAN

Telematics Gateway

External SAFESPEEDRemote Monitoring

Virtual Dashboard

Steering wheel sensors

Steering Column

S1 S2 S3 S4

Steering wheel feedback actuators


Expected OutcomesThe work in WP5.1 is expected to give the following results:■ Demonstration of the EASIS Architecture supporting both safety-critical function and integrated safety applications ■ Test and report on the performance of EASIS Architecture in several situations (normal, degraded, faulty)

Contact:

LEAR CorporationDr. Antoni Ferrèc/ Fusters 54, 43800 Valls (Tarragona),SPAINE-Mail: [email protected]

In order to show the behavior from application point-of-view of EASIS architecture, the WP5.1 Validator includes a safety-critical function (steer-by-wire) and three demonstrative integrated safety applications:■ Simplified SAFELANE – lane keeping support system – provided by PREVENT■ SAFESPEED – limitation of vehicle speed by an external commanded value■ Remote Monitoring using Internet Browser

The EASIS Telematics Gateway Validator incorporates fault injection methodology for validating dependability services in both hardware and softwareThe EASIS Telematics Gateway Validator also includes several interactive graphical interfaces to show, in real time, the behavior of the EASIS architecture and its resilience in front of faults. It is possible to inject faults (both hardware and software) on the system and monitor the system behavior including a 3D vehicle dynamics simulation.

Main contributors

WP 5.1: EASIS Architecture Validator


WP 5.2: EASIS Engineering Process Validator

Main contributors

EASIS Engineering Process Validator

BackgroundHighly dependable safety systems with highly dependable architectures can only be guaranteed by sophisticated engineering methods and engineering processes. Within the activities of this work task the methods, process and tools originating from work packages 3 and 4 will be validated in a co-development process with a truck manufacturer and a system supplier and theresults will be applied to the development of a so-called “Safe Speed Function” in a truck. Based upon external information about the maximum allowable speed and the current truck location, the Safe Speed Function overrules the commands of the driver when the truck speed exceeds or tends to exceed the maximum allowable speed on a specific section of road.

Main ObjectiveStarting with the EASIS Engineering Process (EEP), all activities to be undertaken when developing the Safe Speed Function will be structured and drawn up according to the defined process steps. The methods developed in other working areas, such as hazard analysis techniques and formal verification methods, will be applied as much as possible to this specific development process. Finally, an evaluation will be undertaken, to demonstrate:■ The applicability and efficiency of the new

process, the new methods and proposed tools based on practical experiences.

■ The design faults which are found whenverifying and validating the developed Safe Speed Function.

■ An indication as to which design faults would have been found later or even not at all in a conventional but state-of-the-art development process.

■ How to overcome the practical problem that newly developed systems and safety func-tions have to be combined with already existing and reused systems.

Expected OutcomeOn a Hardware-In-the-Loop (HIL) simulator the developed Safe Speed Function will be prototyped. This simulator allows the demonstration and evaluation of the complete truck behavior with all its electronic systems in a wide range of conditions. The truck behavior in case of software and hardware failures will be investigated in a thorough and structured way. All activities and evaluations with respect to the process,

methods and tools will be reported for this development process. Based on this report, feedback and recommendations for improving the process will be given.

Contact:

DAF Trucks NVMr. Henk Voets5600 PT EindhovenTHE NETHERLANDSEmail: [email protected]

electronic architecture and system engineering for ... · electronic architecture and system...

Documents