The Project EASIS

Electronic Architecture and System Engineering for

Integrated Safety Systems

From a technical point of view todays safety Systems, powerful and highly dependable
systems are mostly stand alone systems with in-vehicle electronic architectures and
a limited degree of interdependency. These appropriate development support are
systems have to be integrated -combined with necessary. These elements must be
upcoming enhanced telematic services- into standardized to achieve an improvement
a complete network of so-called Integrated in system quality with shorter development
Safety Systems. An integrated approach to times and lower system costs.
vehicle safety systems is essential in reaching The goal of the EASIS project is to define and
the road safety targets set by the European develop the mentioned technologies to enable
Commission Transport Policy. the realization of future integrated systems.
For the realization of such Integrated Safety

.C .C
Function x

Active Safe
Passive
Environment Safety
Detection Redundancies
Safety-Function x
Telematics

Vehicle to Vehicle Gateways

Vehicle to Road Infra-structure
Communication
Supplier 1 OEM Supplier 2

.C .C .C

Elements of Integrated Safety Systems

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

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

www.easis.org | info@easis-online.org
 The Project EASIS

Project Objectives
Modular scalable E/E-architecture for Provision of high availability and safety
active, passive and integrated safety Move from fail-silent to fail-operational

systems system behaviour

Services for communication, dependability Provision of introduction plan for new
and gateway functionality concepts into existing automotive system
Embedded system safety analysis architectures
Preparation for standardization

Project Plan

WP 1: Software Architecture Volvo

WP 0: Integrated Safety
(vehicle e-safety Architecture)

Requirements - Valeo

WP 2: Hardware Architecture CRF

Veesa Study DC

WP 3: System Dependability Bosch

WP 4: Processes and Tools ZF

WP 5: Exploitation, Evaluation,
Validation DC

WP 6: Project Coordination and Management

DaimlerChrysler

2003 2004 2005 2006 2007

Project results
A platform for software-based functionality An engineering process and a suitable
in vehicle electronic systems has been tool chain have been defined, enabling the
defined, providing common services upon application of integrated safety systems.
which future applications can be built.
A vehicle on-board electronic hardware The results are validated by two different
infrastructure, which supports the domain overlapping demonstrators:
requirements of integrated safety systems To prove the gateway and firewall
in a cost effective manner has been capabilities of the EASIS architecture, a
specified. telematics gateway is realized
Methods and techniques for handling Overall system dependability e.g. in case
critical dependability-related parts of the of system or component failure is dem-
development lifecycle have been analyzed, onstrated by a commercial vehicle HIL
adapted, extended and defined. testbench with an electronically controlled
Intarder
Project data
The EASIS project is a joint effort of 22
partners from European vehicle manufacturers,
Contact:
automotive suppliers, tool suppliers and
research institutes. DaimlerChrysler AG | Research and Technology
Dr. Vera Lauer
Total Budget 9,4 million HPC 050/G007 | D-71059 Sindelfingen
EU contribution 5 million Phone: +49-(0)7031-4389-340 | Fax: +49-(0)711-3052-1158-05
E-mail: vera.lauer@daimlerchrysler.com
6th Framework Programme IST 2002 - 507690

www.easis.org | info@easis-online.org
 WP 1: Software Architecture

Software Architecture

Background
For 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.

Main Objectives
In the past years, computer-based systems Principles for software topology issues
have taken on a major role in the provision such as common services and mecha-
of functionality in vehicles such as cars nisms, module integration, and interface
and trucks. Computer-based systems and between common modules.
especially future integrated safety systems in Basic fault tolerance and diagnosis
vehicles have high demands on reliability, but mechanisms and their integration in the
also on cost. As the replication of software overall software topology.
is virtually free, this is an attractive way to Concepts for software gateway features,
implement functions. Reusing previously e.g., firewalls for use with telematics.
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:

Layered architecture of the software platform

Overall outcome
The work on Software Architecture has Definition of the software topology of
produced the following results: the platform identifying necessary
Collection and analysis of the overall components as well as interfaces
requirements concerning a software between these components.
architecture that shall provide a platform Concepts and designs of the software
for Integrated Safety Systems. These re- platform for Integrated Safety Systems,
quirements take into account needs from including required services for integrated
the Integrated Safety Systems as well safety, interface between software and
as from external sources (e.g. standards, hardware, gateway services (both intra-
hardware architecture). The identified domain and inter-domain). The design
services cover all aspects, although EASIS suggestions cover functionality, structure
focuses on dependability related services. and interfaces of the services. The
Definition of a functional interchange identified dependability services are
format, i.e., information concerning described in more detail below.
application components which is required Prototype implementation and proof
to perform component integration for of concept for key aspects of the defined
developing integrated safety systems. software architecture.

www.easis.org | info@easis-online.org
 WP 1: Software Architecture

Some dependability and gateway services of the EASIS software platform

In the work on dependability and gateway efficient manner, the platform needs to
functionality in the software platform, a have a good overview of the state of the
number of services have been defined. applications as well as the ECUs. For
Here are some examples: this, a monitoring framework supervising
Agreement protocol. Distributed systematic fault handling activities, e.g.,
decision making and control requires that reconfiguration, is defined.
the components constituting the ISS can Gateway. Future vehicles will
assume that all components have the same communicate with a number of external
view on the information that is used as entities, such as adjacent vehicles, the
the base for decisions or control actions. 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
Agreement protocol
vehicle which can be reached in a
Watchdog management. Watchdogs wireless manner opens up possibilities
can be used to detect situations where for malicious attacks from external
software components malfunction in such sources. In order to handle these attacks
a way that timing is affected, e.g., hanging and ensure that the state of the vehicle is
components and crashed components. secure, firewall services are required.
Fault management framework. To
perform dependability services in an

Firewall for protection against malicious attacks

Main contributors

Contact:
Volvo Technology AB
Dr. Martin Hiller
SE-40508 Gteborg
SWEDEN
Email: martin.hiller@volvo.com

www.easis.org | info@easis-online.org
 WP 2: Hardware Architecture

Hardware Architecture

Background
A 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.

Main Objectives
Main requirements addressed for this Means for functional integration into
hardware architecture are: silicon components
Scalability to support standardized usage Optimised costs and reliability
for safety and non-safety applications
Flexibility to cope with the Backbone (FlexRay)

different application domains and

FO GW unit
vehicle classes Va Vb
FS FS FS
Architectural simplicity GW GW GW DRIVERS

node node node

Capability of handling a large SUPER-
VISOR
MAIN
PROCESSOR

variety of new kinds of sensors FS INPUT LOGIC

and actuators FS Fail

FS Operational
FS
Support for fault tolerance, error FS
FS Unit
DRIVERS

detection and error handling FS SUPER- MAIN

VISOR PROCESSOR

Well defined and standardized FS FS

FS INPUT LOGIC

interfaces
Domain A Domain B

Scalable, dependable hardware architecture

The principle followed in the definition of the combining two FS nodes. In this way we
hardware architecture is composability. reached the requested paradigm shift from
This means that fulfilment of the main the simple overlap of control systems with
requirements has been achieved trough an some information exchange (like in todays
architecture implemented by composing vehicle architectures) to the real integration
several standard electronic elementary of systems and functions running on a
fail silent nodes (FS). The FS nodes are distributed computational network made
connected in a network within a certain of standardized hardware nodes. Secure
application domain and all the domain vehicle external communications with the
networks are linked to each other through infrastructure and with the other road users
gateways (GW) and by means of a common (as required by ISS applications) is also
backbone bus. When safety is required, a supported through the implementation of
Fail Operational (FO) unit is achieved by gateways.

www.easis.org | info@easis-online.org
 WP 2: Hardware Architecture

Overall outcome
The Hardware Architecture work has given Gateway concepts

the following results: Communication services

Collection and analysis of the overall A simulation platform for design and
requirements relating to a hardware configuration of communication systems
architecture that shall provide a platform with multiple sub-networks, gateways
for Integrated Safety Systems. A special modelling, end-to-end latency verification
focus has been given to the functional under critical payload situations.
requirements and to the dependability An electronic control unit prototype with
requirements that are considered the fail silent characteristics proposed as the
innovative parts of this architecture. basic functional standard node that is able to:
show the composability of two fail silent
Design guidelines and general vehicle

system architecture framework solutions nodes (FS) into a fail operational unit (FO);
evaluate the fail silent principles by
for composing the future specific ISS
production applications into high- and low- means of a dual processor architecture;
experiment the redundant power supply
end vehicles. The guidelines address :
Concepts for the system topology strategy and the sensors and actuators
Partitioning between components connection solutions defined in the
and between HW and SW project;
Power supply strategies An electronic control unit prototype
Fail Silent hardware architectures to be used as a gateway to the telematic
Sensors and actuators connections domain, showing the routing and firewal-
Overall communication infrastructure ling characteristics.
Protocols and network topologies

Fail Silent node

hardware prototype

Main contributors
Contact:
Centro Ricerche Fiat
Ing. Massimo Osella
Strada Torino 50, 10043 Orbassano (TO),
ITALY
Email: massimo.osella@crf.it

www.easis.org | info@easis-online.org
 WP 3: System Dependability

System Dependability

Background
Integrated Safety Systems have demanding in terms of the number of inputs and the
requirements in terms of dependability, number of failure modes to be considered,
especially regarding the dependability the possibility of actuator control conflicts
attributes safety, reliability, availability between different safety functions, and the
and security. Moreover, achieving system complexity of the control algorithms.
dependability in a predictable and assessable
way will be significantly harder for integrated The third reason is that no single party
safety systems than for traditional safety- involved in the development of integrated
critical vehicle subsystems. There are safety systems will be able to take over the
three reasons for this: criticality of software, sole responsibility for system safety and
complexity and responsibility. dependability. Methods and approaches
are necessary that support shared
First of all, software-based components will responsibilities.
become more safety critical than in traditional
systems. The more complicated the control- While the transition towards complex safety-
mechanisms of safety-critical actuators critical software-based systems has already
become, the less it will be possible to achieve taken place in other industries (e.g. avionics),
dependability by other technology fallback the approaches followed there for achieving
(e.g. mechanical backup). system dependability are not transferable to
the automotive industry without modification
The second reason is the higher complexity due to different constraints concerning volu-
of integrated safety systems. Aspects of mes, variability, and cost. Current standardi-
complexity in integrated safety systems are a zation activities (namely the ISO WD 26262)
high number of connected ECUs providing a reveal the need for a suitable automotive
function, a high complexity of the functions electronics dependability methodology.

EASIS Dependability Activity Framework

www.easis.org | info@easis-online.org
 WP 3: System Dependability

EASIS Results
The goal of the EASIS work package System identifying potential causes of hazards
Dependability is to back up the system and assessing the probability of a given
engineering of integrated safety systems hazard occurring.
by providing guidelines for dependability- Establishment and verification of
related activities in system development. dependability-related requirements.
The following topics are covered: This work provides suggestions and
EASIS dependability activity framework. guidelines on which activities should
The activities included in any process may be performed, and how these should
be arranged in a framework that shows be performed, in order to collect and verify
how they are related to each other and to requirements that concern dependability.
the overall aim of the process. In EASIS These requirements can be functional
we define a dependability activity frame- requirements, e.g., requirements on
work (see Figure 1) based on an evaluation dependability mechanisms for detection
of some existing dependability frameworks and handling of faults and errors, as
defined by commercial consortia, standar- well as non-functional requirements,
dization bodies, and research projects. e.g., requirements on design and
The aim is to identify a set of dependability- manufacturing processes.
specific activities that should be carried Formal methods. An attractive way of
out during the development of an Integrated guaranteeing correctness, and to
Safety System, or indeed any automotive ascertain that specific dependability
control system. requirements are met by a given system
Hazard identification, classification design, is to provide formal proofs. Formal
and occurrence analysis. This work methods effectively supplement traditional
provides suggestions and guidelines on verification and validation techniques,
how to perform these activities based especially for complex distributed control
on established analysis methodologies systems. This work provides a survey of
and classification schemes, adapted existing approaches for formal specification/
where necessary to fit the automotive modeling and formal verification and a set
environment. Hazard identification deals of case studies showing the applicability of
with identifying undesirable vehicle-level selected approaches to automotive
states and behaviors that may be created system development.
by the system under consideration. Safety cases. A safety case provides a
Hazard classification deals with placing structured argument for why a given system
the identified hazards in categories can be considered adequately safe, and
depending on a set of attributes, such as provides evidence for specific aspects
severity, exposure and controllability. concerning safety. This work provides
Hazard occurrence analysis deals with guidelines for how safety cases should be
constructed in an automotive setting.

Main contributors

Contact:
Robert Bosch GmbH, CR/AEA
Mr. Marko Auerswald
P.O. Box 94 03 50
60461 Frankfurt
Email: Marko.Auerswald@de.bosch.com

www.easis.org | info@easis-online.org
 WP 4: Processes and Tools

Processes and Tools

Background
To 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.

Main Objectives
From the engineering point of view, an Inte- projects) was conducted that revealed new
grated Safety System (ISS) uses intra vehicle challenges for the development process arising
and infrastructure information to influence a from the introduction of ISS: There will be an
real time chassis- or powertrain-control system, shift in implementation, from traditional hard-
thus transforming a basic-function control-loop ware, to software intensive systems, leading
to an ISS control-loop. While the engineering to a composition of safety functions distributed
process for basic-function control-loop systems across different in-vehicle ECUs. In case of
is well understood, ISS control-loop design diverging or conflicting signals or requests to
requires new approaches w.r.t. the development actuators, the coordination / arbitration of dif-
process and supporting tool chain. ferent ISS functions will be a challenge, while
system dependability requirements will increase.

Results and ongoing work

The achieved results and ongoing activities of
Basic Function
Control Loop ISS Control Loop this work are summarized as follows:
EASIS Engineering Process Framework
System System
Requirements Integration Testing (EEPF): EEPF describes the key compo-
Software Acceptance nents of an engineering process necessary
Requirements Testing
to support the development of ISS. It identi-
Software Software Integration
Design Testing fies the need for an ontology or meta-model
Coding Unit Testing to give a well-defined basis for the descrip-
tion of artifacts and activities throughout the
Towards an ISS
design methodology engineering process.
Furthermore, risk assessment and control
The main work in this work package is focused activities must be seamlessly integrated into
on the following three aspects: the standard engineering process and
Systems engineering processes for ISS should be performed as early as possible
and their functional software components. (frontloading). The framework also covers
Tool chains supporting the engineering the reuse of components or modules within
processes. families of similar products based on a
Certification and test activities. standardized software architecture and the
distribution of work between partners (e.g.
Based on the above, an analysis of require- OEM and supplier).
ments (collected within EASIS and from other

www.easis.org | info@easis-online.org
 WP 4: Processes and Tools

EEPF: Process stages based on Meta Models

This produces a complete process for the
1T2 feedback
development of ISS.
Abstract datatypes & Correctness by construction approach.

KNOWLEDGE BASE
Layer 2: Requirements
names from meta
spec. - model & vocab This approach is proposed as a means
analyzable model of Layer 2
to progress from the high level activities
constraint 2T3 feedback defining the Functional Analysis Architec-
ture (FAA) of a vehicle down to the actual
Layer 3: Functional design Datatypes & names
from meta model executable code, via the various views of
to satisfy Level 2 & vocab of Layer 3
the EAST ADL framework.
constraint 3T4 feedback Tools and methods are proposed to aid
in the analysis and design work. These
Layer 4: Functionality ... recommendations are given as annotations
needed to support
Level 3 to the steps and stages of the EEP.

4T5 feedback Outer View Inner View

Meta model
Behavior EAST -ADL,
EEPF: Process stages based on Meta Models UML modeling formal verification,
tool simulation for
validation

Application of EAST ADL to ISS develop- Specify

dynamic
ment. To fulfill the request for a metamodel Structured
system
behavior FAA Specify FAA
requirements structural functional
identified in the EEPF, the EAST-ADL (Archi- specification Specify model behavior
model
functional
tecture Description Language developed in architecture
the project EAST-EEA) is used as a meta
Integration of safety
model for the description of artifacts and UML/
activities such as
system hazard
ADL
activities in the development process. analysis to update
safety requirements
EASIS Engineering Process (EEP). Based EEP: Integration of safety related steps
on the EEPF and the EAST-ADL, the EEP is
proposed as one possible instantiation of the Key concepts and methodologies of this part
framework. It forms a software-specific sys- of the EASIS project will be validated in order
tems engineering process which is aligned to demonstrate the applicability of these ap-
with the needs of the automotive industry. proaches. For this purpose, a validator has
Activities and input/output documents for been created:
every process step are defined. The EEP The EEP is used to develop a safe speed
is organized along the different subsets (or function for use in commercial vehicles. This
abstraction layers) of the EAST-ADL. function automatically reduces truck speed to
Integration of overall system develop- a maximum safe level for the road, by limit-
ment process and risk analysis. The ing engine torque and applying brake torque.
EEP described above is equipped with Rapid Prototyping equipment will be used to
entry points where processes and meth- quickly build and adapt the function. A hard-
odologies aimed at system dependability ware-in-the-loop (HIL) test bench will be used
are integrated. as basis for validation.

Main contributors
Contact:
ZF Friedrichshafen AG
Dr. Jrgen Lucas
D-88038 Friedrichshafen - GERMANY
Email: juergen.lucas@zf.com

www.easis.org | info@easis-online.org
 WP 5.1: EASIS Architecture Validator

EASIS Architecture Validator

Background
To reach a high stage of maturity and a proposals developed in EASIS project,
verification of the results elaborated in the mainly defined in WP1 (software) and WP2
different EASIS work packages, a prototypical (hardware). In particular, WP5.1 Validator will
implementation of EASIS Architecture will be be used to validate the suitability of developed
realized and tested in WP5.1 task. architecture to implement integrated safety
WP5.1 Validator aims to develop, implement functions working across domains in a reliable,
and validate some of the most relevant safe and secure way.

Description
The 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

External
Ethernet SAFESPEED
Remote Monitoring

Virtual Dashboard
CAN
FS
Central Node
SAFESPEED Unit
SAFELANE Spy Node Telematics Gateway

Vehicle Dynamics
Simulator Steering wheel
FS FS sensors
Unit Unit

S1 S2 S3 S4

Steering Column

Steering wheel feedback actuators

www.easis.org | info@easis-online.org
 WP 5.1: EASIS Architecture Validator

In order to show the behavior from application The EASIS Telematics Gateway Validator
point-of-view of EASIS architecture, the WP5.1 incorporates fault injection methodology
Validator includes a safety-critical function for validating dependability services in both
(steer-by-wire) and three demonstrative hardware and software
integrated safety applications: The EASIS Telematics Gateway Validator also
Simplified SAFELANE lane keeping includes several interactive graphical interfaces
support system provided by PREVENT to show, in real time, the behavior of the EASIS
SAFESPEED limitation of vehicle speed architecture and its resilience in front of faults.
by an external commanded value It is possible to inject faults (both hardware
Remote Monitoring using Internet and software) on the system and monitor
Browser the system behavior including a 3D vehicle
dynamics simulation.

Expected Outcomes
The 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)

Main contributors

Contact:
LEAR Corporation
Dr. Antoni Ferr
c/ Fusters 54, 43800 Valls (Tarragona),SPAIN
E-Mail: aferre@lear.com

www.easis.org | info@easis-online.org
 WP 5.2: EASIS Engineering Process Validator

EASIS Engineering Process Validator

Background
Highly 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 the
results 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 Objective
Starting with the EASIS Engineering Process The design faults which are found when
(EEP), all activities to be undertaken when verifying and validating the developed
developing the Safe Speed Function will be Safe Speed Function.
structured and drawn up according to the An indication as to which design faults
defined process steps. The methods developed would have been found later or even not
in other working areas, such as hazard analysis at all in a conventional but state-of-the-art
techniques and formal verification methods, will development process.
be applied as much as possible to this specific How to overcome the practical problem that
development process. Finally, an evaluation will newly developed systems and safety func-
be undertaken, to demonstrate: tions have to be combined with already
The applicability and efficiency of the new existing and reused systems.
process, the new methods and proposed
tools based on practical experiences.

Expected Outcome
On 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.

Main contributors
Contact:
DAF Trucks NV
Mr. Henk Voets
5600 PT Eindhoven
THE NETHERLANDS
Email: henk.voets@daftrucks.com

www.easis.org | info@easis-online.org