The Project EASIS

Electronic Architecture and System Engineering for

Integrated Safety Systems

From a technical point of view todays 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.

.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
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.
Agreement protocol
Watchdog management. Watchdogs
can be used to detect situations where for malicious attacks from external
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
sources. In order to handle these attacks
and ensure that the state of the vehicle is
secure, firewall services are required.

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
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 todays
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.

www.easis.org | info@easis-online.org
 WP 2: Hardware Architecture
Overall outcome
The 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 vehicle
system 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
Main contributors
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 with
fail 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
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
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
EASIS Dependability Activity Framework
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.
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-
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.
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 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
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.

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
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 software
The 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.

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
(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 when
verifying 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 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