Electronic Architecture and System Engineering for Integrated Safety

The Project EASIS
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
.C
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.
Function x
.C
Active Safe
Environment
Detection
Passive
Safety
Redundancies
Safety-Function x
Telematics
Gateways
Vehicle to Vehicle
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 | [email protected]
The Project EASIS
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
Project Plan
WP 0: Integrated Safety
Requirements - Valeo
Veesa Study – DC
(vehicle e-safety Architecture)
WP 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
2003
2004
2005
2006
2007
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
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
Contact:
DaimlerChrysler AG | Research and Technology
Dr. Vera Lauer
HPC 050/G007 | D-71059 Sindelfingen
Phone: +49-(0)7031-4389-340 | Fax: +49-(0)711-3052-1158-05
E-mail: [email protected]
www.easis.org | [email protected]
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 standardized 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
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 mecha-
nisms, 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
Overall outcome
The 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 re quirements 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 intradomain 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.
www.easis.org | [email protected]
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 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.
Firewall for protection against malicious attacks
Main contributors
Contact:
Volvo Technology AB
Dr. Martin Hiller
SE-40508 Göteborg
SWEDEN
Email: [email protected]
www.easis.org | [email protected]
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
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
FS
GW
■ Architectural simplicity
node
■ Capability of handling a large
variety of new kinds of sensors
and actuators
FS
■ Support for fault tolerance, error
FS
detection and error handling
■ Well defined and standardized
FS
interfaces
Domain A
■ Means for functional integration into
silicon components
■ Optimised costs and reliability
Backbone (FlexRay)
FO GW unit
FS
GW
node
Va Vb
FS
GW
node
DRIVERS
SUPERVISOR
FS
MAIN
PROCESSOR
INPUT LOGIC
FS Fail
Operational
FS
FS Unit
DRIVERS
FS
SUPERVISOR
FS
MAIN
PROCESSOR
FS
INPUT LOGIC
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 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.
www.easis.org | [email protected]
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 lowend 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 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 firewalling characteristics.
■
■
Fail Silent node
hardware prototype
Main contributors
Contact:
Centro Ricerche Fiat
Ing. Massimo Osella
Strada Torino 50, 10043 Orbassano (TO),
ITALY
Email: [email protected]
www.easis.org | [email protected]
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 safetycritical 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 controlmechanisms 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 safetycritical 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 volumes, variability, and cost. Current standardization activities (namely the ISO WD 26262)
reveal the need for a suitable automotive
electronics dependability methodology.
EASIS Dependability Activity Framework
www.easis.org | [email protected]
WP 3: System Dependability
The goal of the EASIS work package “System Dependability” is to back up the system
engineering of integrated safety systems
■
by 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 frame work (see Figure 1) based on an evaluation of some existing dependability frameworks defined by commercial consortia, standar
dization 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
EASIS Results
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 formalverification 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.
Main contributors
Contact:
Robert Bosch GmbH, CR/AEA
Mr. Marko Auerswald
P.O. Box 94 03 50
60461 Frankfurt
Email: [email protected]
www.easis.org | [email protected]
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 Integrated 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 hardware, 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 different ISS functions will be a challenge, while
system dependability requirements will increase.
Results and ongoing work
Basic Function
Control Loop
System
Requirements
ISS Control Loop
System
Integration Testing
Software
Requirements
Software
Design
Coding
Acceptance
Testing
Software Integration
Testing
Unit Testing
Towards an ISS
design methodology
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 requirements (collected within EASIS and from other
The achieved results and ongoing activities of
this work are summarized as follows:
■ EASIS Engineering Process Framework
(EEPF): EEPF describes the key compo nents 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 descrip tion 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).
www.easis.org | [email protected]
WP 4: Processes and Tools
EEPF: Process stages based on Meta Models
1T2
feedback
constraint
2T3
feedback
Layer 3: Functional design
to satisfy Level 2
constraint
3T4
Datatypes & names
from meta model
& vocab of Layer 3
feedback
Layer 4: Functionality
needed to support
Level 3
4T5
Abstract datatypes &
names from meta
model & vocab
of Layer 2
KNOWLEDGE BASE
Layer 2: Requirements
spec. analyzable model
...
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 Architecture (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.
„Outer View“
feedback
EEPF: Process stages based on Meta Models
■
■
Application of EAST ADL to ISS develop-
ment. 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 systems 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 develop-
ment process and risk analysis. The EEP described above is equipped with entry points where processes and meth-
odologies aimed at system dependability are integrated.
„Inner View“
Behavior
modeling
tool
UML
Structured
system
requirements
specification
Specify
dynamic
behavior
Specify
functional
architecture
FAA
structural
model
Specify
functional
behavior
UML/
ADL
Meta model
EAST -ADL,
formal verification,
simulation for
validation
FAA
model
Integration of safety
activities such as
system hazard
analysis to update
safety requirements
EEP: Integration of safety related steps
Key concepts and methodologies of this part
of the EASIS project will be validated in order
to demonstrate the applicability of these approaches. 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 limiting engine torque and applying brake torque.
Rapid Prototyping equipment will be used to
quickly build and adapt the function. A hardware-in-the-loop (HIL) test bench will be used
as basis for validation.
Main contributors
Contact:
ZF Friedrichshafen AG
Dr. Jürgen Lucas
D-88038 Friedrichshafen - GERMANY
Email: [email protected]
www.easis.org | [email protected]
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
SAFESPEED
Remote Monitoring
Ethernet
Virtual Dashboard
CAN
FS
Unit
Central Node
SAFESPEED
SAFELANE
Vehicle Dynamics
Simulator
FS
Unit
Telematics Gateway
“Spy“ Node
Steering wheel
sensors
FS
Unit
S1
S2
S3
S4
Steering Column
Steering wheel feedback actuators
www.easis.org | [email protected]
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: [email protected]
www.easis.org | [email protected]
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 functions 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: [email protected]
www.easis.org | [email protected]