Distributed automotive embedded systems:

architecture design and development methods

Dr. Eric Armengaud

VIF - Area E/E & SW
Group leader embedded systems

June 1st, 2010

Ein Kompetenzzentrum der MEMBER OF

K plusKKompetenzzentrenprogramm,
plus Kompetenzzentrenprogramm,

COMET K2 Forschungsprogramm
eine Förderinitiative
eine Förderinitiative
Gefördert
Gefördert
mit Mitteln
des Bundesministeriums
mit Mitteln
des Bundesministeriums
des FFG,des
des
FFG,
Landes
für Verkehr,
des Landes
Steiermark
für Verkehr,
Innovation
Steiermark
und derund
Innovation
Stadt
und Technologie
derGraz
Stadt
und Technologie
und
Graz
derund
(BMVIT)(BMVIT)
steirischen
der steirischen
Wirtschaftsförderung
Wirtschaftsförderung
(SFG) (SFG)

Eine Förderinitiative des Bundesministeriums für Verkehr, Innovation und Technologie (BMVIT) und dem
Bundesministerium für Wirtschaft und Arbeit BMWA).
PROJECT
Gefördert mit Mitteln der FFG, des Landes Steiermark und der steirischen Wirtschaftsförderung (SFG) PARTNER

2010-06-01 TU Wien, HW-SW Co-Design 1

 Content

Electronics in car

The time-triggered architecture & FlexRay

Improving the development methods and processes

Research activities @ Virtual Vehicle Competence

Center

2010-06-01 TU Wien, HW-SW Co-Design 2

 VIRTUAL VEHICLE in a nutshell:

Founded: July 2002

Current Staff: 135
Turnover: EUR 12 Mio.

Shareholder:
40%

19%

19%
12%
10%

Managing Director: Dr. Jost Bernasch

Scientific Director: Prof. Hermann Steffan
(Vehicle Safety / Frank Stronach Institute, TU Graz)

2010-06-01 TU Wien, HW-SW Co-Design 3

 VIRTUAL catchwords:

Independent Research Platform

(not tied to specific bodies or corporations)

Applied Research and Scientific Services

Driven by the demand of leading companies

(> 50 industry partners)

Comprehensive international Research Network

(> 35 scientific partners and university institutes)

Extensive financial funding programs available

(no overhead as in customary funded projects)

2010-06-01 TU Wien, HW-SW Co-Design 4

 Semiconductor vs. Automotive industry

“If the automotive industry had advanced as rapidly as the

semiconductor industry we’d all be driving a Rolls Royce, it
would do half a million miles to the gallon and it would be
cheaper to throw away than to park”

And as a friend pointed out, Moore said,

"it would only be a half-inch long and a
quarter-inch high."

2010-06-01 TU Wien, HW-SW Co-Design 5

 Electronics in cars

Vehicles a decade ago

 A few embedded systems per vehicle

Vehicles nowadays
 Up to a few hundreds of computing
devices per vehicle
 Multiple networks per vehicle

Advantage
 Safety-critical embedded systems have
been key innovation drivers
 E.g. by-wire systems

Disadvantage
 Enormous complexity is challenging
industry (automotive, aerospace, rail,
Source: AVL List automation)
 Increasing costs
 Affected product quality  safety-
PAST TODAY FUTURE ? critical

2010-06-01 TU Wien, HW-SW Co-Design 6

 Networks in cars

Snapshot 2004: the VW Phaeton

 2110 cables
 3860 meters cable
 Weight: 64kg
 70 ECUs

Wide requirements
 Low cost for non safety-critical Source: Volkswagen Beetle, 1960
systems (e.g. LIN, CAN)
 High bandwidth for infotainment
(e.g. MOST)
 Dependability for safety-critical
applications (e.g. FlexRay)

Source: Technology review, July 2004

2010-06-01 TU Wien, HW-SW Co-Design 7

 Needs for new architectures

Automotive electronics organized as complex distributed systems

 Local connection between sensors, processors and actuators
 Information dissemination within the car
 Point to point connection inefficient (reliability, weight)

System complexity difficult to manage

 Number of ECU, intensity of the communication
 Different technologies
 Complexity of the application

The system can not be assumed fault-free

 High temperature range and thermal gradients
 High humidity, splashes from oil, petrol, chemicals…
 Conducted emissions (electric motors) and radiated emissions
(power lines, radio or TV transmitters)

2010-06-01 TU Wien, HW-SW Co-Design 8

 Needs for improved development processes

Methods for requirement engineering

 First description of the system; contract between OEM and supplier
 Requirements needs to be precise, unambiguous and complete
 Formalization of multi viewpoint, multi criteria and multi level
requirements

Methods for component-based design

 Global understanding of the system for efficient analysis
 Provide traceability within the system design
 Design space exploration comprising multi-view, multi-criteria and
multi level architecture trade-offs

Safety methods and processes

 Ensure the quality of a product via the execution of safety related
activities and the definition of a standardized development process
 Provide traceability of the development process
 Formalization of the dev. process for analysis, reporting (certification)
and automation (service orchestration)

2010-06-01 TU Wien, HW-SW Co-Design 9

 Time-triggered architectures for
complex control applications
“… in the event-triggered approach, all communication and processing
activities are initiated whenever a significant change of state, i.e., an event
(e.g., interrupt), is noted. In the time-triggered approach, all communication
and processing activities are initiated at predetermined points in time.”

[Real-Time Systems, Kopetz, 1997, Kluwer Acacemic]

2010-06-01 TU Wien, HW-SW Co-Design 10

 Event-Triggered (ET) architecture

Event-triggered architecture
 System activity triggered by an event
 Priority based communication (CAN)

ID 1
 Communication jitter
 Constructive integration
ID 3  Redundancy
ID 5  Architecture flexibility
 Bandwidth use (sporadic events)
highest
priority transmission delayed

ID 1 ID 3 ID 5

2010-06-01 TU Wien, HW-SW Co-Design 11

 Time-triggered (TT) architecture

Time-triggered architecture
 Action derived from progression of time
 Static, periodic, a-priori known schedule
 Global notion of time

ID 5  Communication jitter
ID 3
 Constructive integration
 Redundancy, Agreement
ID 1  Architecture flexibility
 Bandwidth use (sporadic events)
transmission slot
a-priori known

ID 1 ID 3 ID 5

2010-06-01 TU Wien, HW-SW Co-Design 12

 ET versus TT Transmission paradigm

Event-based communication
 A communication is triggered for each new event – i.e. major
state change (e.g. temperature increase of +5 degree)
 Each event (communication) has to be detected and processed
in the same time order it arrived
 Optimal use of the bandwidth
 Not robust – lost of message might lead to system
inconsistencies

Status-based communication
 Periodic communication for updating system state
(e.g. temperature is currently 55 degree)
 Events (communication elements) might be missed or processed
in different time order than reception time
 Worse-case use of the bandwidth
 Robustness: lost of message only induce additional processing
delays – no system inconsistencies

2010-06-01 TU Wien, HW-SW Co-Design 13

 FlexRay
Overview

2010-06-01 TU Wien, HW-SW Co-Design 14

 FlexRay – TDMA Scheme

Periodical communication scheme

 Static segment for time-triggered communication
 Dynamic segment for event-triggered communication
 Symbol window for medium test
 Network idle time for resynchronization

Cycle
n-1 Cycle n Cycle n+1 Cycle n+2

Static Dynamic Static Dynamic Static

NIT SW NIT SW NIT
segment segment segment segment segment

Network idle time

Symbol Window
(synchronization)

Slot 1 Slot 2 … … Slot i i+1 i+2 … … … … k

minislot

2010-06-01 TU Wien, HW-SW Co-Design 15

 FlexRay: time synchronization

Aim: provide a global time base within the network to

correct the quartz drift and avoid collision on the bus
Slot 1 Slot 2 Slot 3 Slot 4 Slot 5 Slot 6 Slot 7 Slot 8
Node 1 Frame Frame

Slot 1 Slot 2 Slot 3 Slot 4 Slot 5 Slot 6 Slot 7 Slot 8

Node 2 Frame

Slot 1 Slot 2 Slot 3 Slot 4 Slot 5 Slot 6 Slot 7 Slot 8

Node 3 Frame Frame

Requirement: fault tolerant algorithm

 No single point of error
 Single faults are discarded

2010-06-01 TU Wien, HW-SW Co-Design 16

 FlexRay: Wake-up & Start-up

Motivation
 Wake-up the network and provide initial synchronization
 Fault tolerant (network operation relies on start-up)
 Fast operation (fault recovery)

Three phases
 Wakeup: to wake-up the network (active stars, nodes) if it
is still asleep
 Startup: to begin communication (initialize schedule) when
the nodes are awake
 Reintegration: to integrate single nodes within a running
cluster

2010-06-01 TU Wien, HW-SW Co-Design 17

 Design of the communication architecture – Fibex

Topology: ECUs, comm.

channels, HW types

Communication matrix: mapping

between data models (signal-
PDU-frames), timing information Application:
signals, variable

[FIBEX - Field Bus Exchange Format, Version 3.0 ASAM AE, 2008, Fig 10-1]
2010-06-01 TU Wien, HW-SW Co-Design 18
 Integration issues within the software architecture

Control flow – integration within the SW architecture

 Event-triggered (action triggered with rxd / txd interrupt)
flexibility but control flow difficult to handle (interrupts)
 Time-triggered (comm. task synchronous to bus schedule)
a-priori known behavior (time domain) but complex dependencies
between operating system and communication system

Data flow – transmission scheme

 Buffer: frame filtering (ID, cycle) performed in hardware,
Time-triggered comm.: latest data stored (old version discarded)
 FIFO: frames stored sequentially, further processing in software
Event-triggered comm.: all frames are available

System configuration – amount of data

 Protocol configuration: FlexRay schedule / syntax (>70 param.)
 Data access and interpretation: buffer configuration, mapping
between frame and signals (>50 parameters)
2010-06-01 TU Wien, HW-SW Co-Design 19
 Interaction between Operating and Communication
system
Operating system
Event-triggered
(interrupts driven)
 Priority based communication
Event- + Flexibility, average response
Communication system
triggered time
(e.g. CAN) - Complex timing analysis,
- No constructive integration
 static comm. scheme with
interrupt based data interface
+ constructive integration
Time- (comm. point of view)
triggered - Complex end-to-end timing
(e.g. analysis
FlexRay) - No constructive integration
(node’s point of view)
2010-06-01 TU Wien, HW-SW Co-Design
Time-triggered
(schedule)
 Static communication scheme
supported by the application
+ Easy timing analysis
- Application overhead (e.g. for
synchronization)
 Asynchronous systems
+ Easy timing analysis
- Non optimal end-to-end delays
(synchronization)
- Frames might be missed
 Synchronous systems
+ Easy timing analysis
+ deterministic and optimal end-
to-end delays
- Flexibility
20
 Intermediate summary

Automotive electronics
 Cars are forming complex distributed systems, evolving in harsh
environments; however their reliability requirements increase
 Time-triggered architectures aim at improving the system reliability
and support system development and integration

Some challenges
 System level: transmission scheme
 ECU level: integration within software architecture (control)
 Design process: handling of the configuration information
 Design process: network technology abstraction for SW functions

2010-06-01 TU Wien, HW-SW Co-Design 21

 Improving the development
methods and processes

2010-06-01 TU Wien, HW-SW Co-Design 22

 Requirement engineering – specification language

Free text: no constraint

 no training required
e.g.: the system shall count time between eyelid movement and warn driver if the time is
less than 2 sec
Guided natural language: limited vocabulary from a dictionary
 reduce ambiguity
e.g.: driver: person who drives the car // warn: inform the driver about an event
Structured textual: template for requirement description
 further reduce ambiguity, support transition to formal notations
e.g. IF <trigger> THEN <subject> SHALL DO <action list> WITHIN <time bound>
Semi-formal model-based: formal and precise syntax while their
semantics are imprecise and allow different interpretation
 support the analysis of the requirements
e.g.: UML modeling
Formal model-based: method for definite, orderly and methodical
requirement definition
 most precise requirement definition
e.g. Petri nets, timed automata
2010-06-01 TU Wien, HW-SW Co-Design 23
 Requirement engineering – structuring (ontology)

Traceability: „Requirements traceability refers to the ability to

describe and follow the life of a requirement, in both a forwards
and backwards direction, …“

post-requirements traceability links

 satisfies
 verify
 realize
pre-requirements traceability links
 explicit traceability links
• owns
• hasRationale
• hasSource
 possible operations performed on requirements
• refine
• decompose
• copy
• depend

2010-06-01 TU Wien, HW-SW Co-Design 24

 Multi-view system design – traceability

Motivation
 Method for the system architecture description (ADL: Architecture
Description Language)
 Provide traceability of the product

Approach
 Template for how engineering information is organized and
represented (UML profile such as SysML, EAST-ADL, AADL)
 Include different views such as architecture, requirements, safety
analysis as well as link between these views

2010-06-01 TU Wien, HW-SW Co-Design 25

 EAST-ADL (www.atesst.org)

2010-06-01 TU Wien, HW-SW Co-Design 26

 Seamless modeling - vision
Safety analysis
system architecture
(HiP-HOPS)
Requirements specification and
management (EAST-ADL)

behavioral modeling Further static analysis

(Matlab / Simulink)

IDE

architecture modeling
(AUTOSAR)
2010-06-01 TU Wien, HW-SW Co-Design 27
 Safety methods and development process

Safety
 Freedom from unacceptable risk
 Risk: combination between probability and severity of a failure

Safety related project activities

 Risk: Hazard and risk analysis
e.g. “what could happen if”
 Safety: safety concept
e.g. “what is the safe state”
 Safety functions: safety requirements
e.g. “How to provide the safe state”
 SIL decomposition: Implementation and processes
e.g. “what SIL (Safety Integrity Level) applies for individual units”

ISO 26262: “Road vehicles – Functional safety”

 Based on IEC 65801
 Defines safety process for the development of road vehicles
 Draft International Standard – will be released in 2011

2010-06-01 TU Wien, HW-SW Co-Design 28

 ISO 26262

2010-06-01 TU Wien, HW-SW Co-Design 29

 Area E
Vehicle Electrics/Electronics and Software

Embedded Systems Group

Distributed real-time systems
Safety-relevant applications
Design methods & processes
Ein Kompetenzzentrum der MEMBER OF
K plusKKompetenzzentrenprogramm,
plus Kompetenzzentrenprogramm,

COMET K2 Forschungsprogramm
eine Förderinitiative
eine Förderinitiative
Gefördert
Gefördert
mit Mitteln
des Bundesministeriums
mit Mitteln
des Bundesministeriums
des FFG,des
des
FFG,
Landes
für Verkehr,
des Landes
Steiermark
für Verkehr,
Innovation
Steiermark
und derund
Innovation
Stadt
und Technologie
derGraz
Stadt
und Technologie
und
Graz
derund
(BMVIT)(BMVIT)
steirischen
der steirischen
Wirtschaftsförderung
Wirtschaftsförderung
(SFG) (SFG)

Eine Förderinitiative des Bundesministeriums für Verkehr, Innovation und Technologie (BMVIT) und dem
Bundesministerium für Wirtschaft und Arbeit BMWA).
PROJECT
Gefördert mit Mitteln der FFG, des Landes Steiermark und der steirischen Wirtschaftsförderung (SFG) PARTNER

2010-06-01 TU Wien, HW-SW Co-Design 30

 TEODACS: two development platforms for the analysis
of automotive distributed embedded systems
 Analysis of the communication/interactions between different components
 Evaluation of the internal (configuration, topology) and external effects (EMC) influencing
the communication

Partners: austriamicrosystems, AVL, CISC, TU Graz (ITI), FH Joanneum

[see http://www.teodacs.com]
2010-06-01 TU Wien, HW-SW Co-Design 31
FlexRayXpert.Sim co-simulation platform: Simulation
of the entire communication architecture

Analog level: Advanced analysis of the FlexRay physical layer (topology)

 Bus line: Cable line, ESD Diode, Common mode chock, termination
 Active & passive star, transceivers (VHDL-AMS / VHDL) Active Star
(VHDL / VHDL-AMS)
FlexRay CC
(SystemC)

Data link level: Efficient analysis of the logical

transmission
 FlexRay controller (SystemC) T connector
(VHDL-AMS)

Middleware: Integration of selected AUTOSAR

concepts:
Cable + FlexRay
 Virtual Function Bus functionality (SystemC/C++) ev. termination transceiver
(VHDL-AMS) (VHDL-AMS)

Integration of SW components:
 AUTOSAR-like
 Ports/Runnables/Server-Client/
Sender-Receiver/…

2010-06-01 TU Wien, HW-SW Co-Design 32

FlexRayXpert.Lab – realistic HW platform for the analysis
of safety-relevant applications (e.g. Drive-By-Wire)

Realistic prototype with efficient interfacing strategy

 Integration challenge: realistic topology, different hardware providers
 Methodologies for efficient development of embedded systems
 X-in-the-Loop: Integration analysis of software modules, ECUs, or network configuration
within the system

2010-06-01 TU Wien, HW-SW Co-Design 33

Optimal Software allocation: analysis and optimisation
of real-time distributed embedded systems
Function A (e.g. move mirror)

Function B
(e.g. vibration reduction)
Function C
(e.g. infotainment)
Discrete optimization
Allocation

Scheduling

Priorities

Bus config.
Partners: Magna Powertrain, AUCOTEC
2010-06-01 TU Wien, HW-SW Co-Design 34
TEODACS / ADACS: Methods for advanced analysis and
evaluation of the network

Advanced analysis of the distributed system

 Different abstraction levels to obtain different degrees of accuracy
 Dedicated tests for the different abstraction levels
Partners: AIT
2010-06-01 TU Wien, HW-SW Co-Design 35
 TEODACS: Development flow and configuration
management

Design challenges Validation challenges

• System design • Node„s validation

 support from functional engineering  COTS development environments
• Communication architecture design • System validation
 industrial tools for comm. planning  industrial FlexRay protocol
• Node„s design analyzers
 COTS development environments  methods to check the
 dedicated configuration exporters for transmission completeness w.r.t.
the different platforms (TEODACS) Fibex configuration (TEODACS)

2010-06-01 TU Wien, HW-SW Co-Design 36

CESAR: Design methods & processes for automotive
embedded systems

Cost-efficient methods and processes for safety-relevant embedded systems

Goal:
Building ecosystem for development environments for safety-critical real-time embedded
systems supporting avionics, automotive, rail, and space.
Lead partners: AVL, Airbus, EADS, see www.cesarproject.eu
2010-06-01 TU Wien, HW-SW Co-Design 37
Interoperability Concept

Generic Model Based

Integration Platform
for safety-critical
embedded systems
development Management Repos
Console
itory

RTP = Reference Technology Platform

Application
Domains
Embedded Software
Development Process
Configuration Tailoring

Safety Standards SPEM

Domain Requirements Tools
Data Formats
Specific Tool Chain (Instance of RTP)
Meta Models
Data Standards

TCP / IP RTP
ToolNet TCP / IP RTP
ToolNet
TCP / IP RTP
ToolNet TCP / IP RTP
ToolNet

Parts of pictures from

A.Keis/EADS

2010-06-01 TU Wien, HW-SW Co-Design 38

Integration Concept

Provide an Integration Platform for the exchange of model based data

TCP / IP RTP
ToolNet

 Service Oriented Architecture (SOA)

TCP / IP RTP
ToolNet

 Tool-Adapters and internal Services realized as Web-Services, connected

via model-aware Enterprise Service Bus, called ModelBus
 Integration Platform has model-based core data model , build up upon
abstracted models of integrated tools, processes, standards
 Model-Repository, Services for e.g. model compare, transformation, check

Tool 1 Tool 2 Tool 3

GUI GUI GUI Platform integrated Services (Examples)

Application Application Application Model Process

Rules
Mapping GUI GUI Management

DB Tool DB Tool DB
Adapter Adapter Transformation Model Check Process
Service Service Engine

Model based Core Data Model of Integration Platform

Repository

ModelBus

2010-06-01 TU Wien, HW-SW Co-Design 39

Tool Adapter Concept

Establishing a communication channel

 Service Integration - Abstract Interface Level
 Connecting Tool-API or data file format to platform Interface (e.g. Java
RPC) via HTTP/SOAP requests

Speak the same language

 Syntactic Transformation, translate data format
 Provide exchange of XML model fragments

RTP
Speak from the same things Transformation
Services
 Semantic Transformation - map elements
with the same meaning (test cases, software architecture elements…)
 Manage links between different elements (e.g. requirements to software
architecture blocks)
 Usually mapping of tool elements to meta-model elements provided by
platform
 Supported by meta models building an meta model layer scheme
 Done by transformation services which are part of the platform

2010-06-01 TU Wien, HW-SW Co-Design 40

MEPAS – focus on single automotive development
process

Process definition
 Definition of the development stages
 EAST-ADL2, ISO 26262, AUTOSAR Requirement
&Specification
(system
Interface definition features)

standards, norms, process

Simulation, SiL, HiL

 Seamless integration of the

System validation
SW Qualification
different development tools Abstract
functional
architecture Verification
level and validation
Continuous validation
 Integration of requirements
Detailed
 System validation at different Design Level
stages (architecture)

Evaluation Implementation
level
 Quality of the resulting system AUTOSAR

 Efficiency of the development environment

Partners: AVL, TU Graz (ITI)
2010-06-01 TU Wien, HW-SW Co-Design 41
 MEPAS: Model-based system design

Requirements Process Modeling

Activities /Safety Activities Output:
Tool selection
Analysis 4
System model
and safety
aspects

Output:
Analysis 3
Integration of
Behavior and
Selection of system model
modeling language High-level system Refined, multi-view,
(e.g. EAST-ADL) Definition of
model V1 high-level system
further steps
(Structure, model V2
Output: according to
Dependencies, …) Error Model
Analysis 2 results
Output: (MiL, SiL, PiL
Analysis 1 Multi-view /
cross domain test integration,
Traceability etc.)
check
Consistency
Input Input
checks

Verify Improve quality

Data Management Platform requirements of models

Improve quality of
modeling approach
for future projects

….
System Requirements Behavioral model V1 Behavioral model V2
specification
Simulink Simulink t
Lead Project
2010-06-01 TU Wien, HW-SW Co-Design 42
 Conclusion

Automotive embedded systems from two perspectives

 System architecture (event- vs. time-triggered)
 Development methods (requirement engineering, traceability of
the system and development process)

The question is not anymore “how can I develop a given function”

but “how can I make my system more dependable for lower costs”
 Meta-information for the description of the product are important
 Traceability between the system views required
 Traceability of the development process required
 (model-based) tool-chain as central elements to achieve these
goals

Do not forget Verification and Validation!

2010-06-01 TU Wien, HW-SW Co-Design 43

 Thank you
for your attention!

www.v2c2.at

K2 / K plus Competence Center - Initiated by the Federal Ministry of Transport, Innovation and
Technology (BMVIT). Funded by FFG, Land Steiermark and Steirische Wirtschaftsförderung (SFG)

2010-06-01 TU Wien, HW-SW Co-Design 44