Distributed automotive embedded systems: architecture design … · Safety-critical embedded systems have been key innovation drivers E.g. by-wire systems Disadvantage Enormous complexity

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

K plus Kompetenzzentrenprogramm,

eine Förderinitiative des Bundesministeriums für Verkehr, Innovation und Technologie (BMVIT)

Gefördert mit Mitteln des FFG, des Landes Steiermark und der Stadt Graz und der steirischen Wirtschaftsförderung (SFG)









Gefördert mit Mitteln des FFG, des Landes Steiermark und der Stadt Graz und der steirischen Wirtschaftsförderung (SFG)COMET K2 Forschungsprogramm

Eine Förderinitiative des Bundesministeriums für Verkehr, Innovation und Technologie (BMVIT) und dem

Bundesministerium für Wirtschaft und Arbeit BMWA).

Gefördert mit Mitteln der FFG, des Landes Steiermark und der steirischen Wirtschaftsförderung (SFG)

Ein Kompetenzzentrum der

PROJECT

PARTNER

MEMBER OF

Distributed automotive embedded systems:

architecture design and development methods

Dr. Eric Armengaud

VIF - Area E/E & SW

Group leader embedded systems

June 1st, 2010


Content

Electronics in car

The time-triggered architecture & FlexRay

Improving the development methods and processes

Research activities @ Virtual Vehicle Competence

Center


Managing Director: Dr. Jost Bernasch

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

VIRTUAL VEHICLE in a nutshell:

Founded: July 2002

Current Staff: 135

Turnover: EUR 12 Mio.

40%

10%

19%

19%

12%

Shareholder:


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)

VIRTUAL catchwords:


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


PAST TODAY FUTURE ?

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,

automation)

Increasing costs

Affected product quality safety-

critical

Source: AVL List

Electronics in cars


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

Source: Volkswagen Beetle, 1960


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)


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)


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]


Event-Triggered (ET) architecture

Event-triggered architecture System activity triggered by an event

Priority based communication (CAN)

ID 5

ID 3

ID 1 Communication jitter

Constructive integration

Redundancy

Architecture flexibility

Bandwidth use (sporadic events)

ID 5ID 3ID 1

transmission delayedhighest

priority


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

ID 3

ID 1

Communication jitter

Constructive integration

Redundancy, Agreement

Architecture flexibility

Bandwidth use (sporadic events)

ID 1 ID 3 ID 5

transmission slot

a-priori known


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


FlexRay

Overview


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

Static

segment

Dynamic

segmentSW NIT

Static

segment

Dynamic

segmentSW NIT

Cycle n Cycle n+1

NIT

Slot 1 Slot 2 … … Slot i

Network idle time

(synchronization)

i+1 i+2 … … … … k

minislot

Static

segment

Cycle n+2Cycle

n-1

Symbol Window


FlexRay: time synchronization

Aim: provide a global time base within the network to

correct the quartz drift and avoid collision on the bus

Requirement: fault tolerant algorithm No single point of error

Single faults are discarded

Node 1

Node 2

Node 3

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

Frame Frame


Frame


Frame Frame


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


Design of the communication architecture – Fibex

[FIBEX - Field Bus Exchange Format, Version 3.0 ASAM AE, 2008, Fig 10-1]

Topology: ECUs, comm.

channels, HW types

Application:

signals, variable

Communication matrix: mapping

between data models (signal-

PDU-frames), timing information


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)


Interaction between Operating and Communication

system

Operating system

Event-triggered

(interrupts driven)

Time-triggered

(schedule)

Co

mm

un

icatio

n s

yste

m

Event-

triggered

(e.g. CAN)

Priority based communication

+ Flexibility, average response

time

- Complex timing analysis,

- No constructive integration

Static communication scheme

supported by the application

+ Easy timing analysis

- Application overhead (e.g. for

synchronization)

Time-

triggered

(e.g.

FlexRay)

static comm. scheme with

interrupt based data interface

+ constructive integration

(comm. point of view)

- Complex end-to-end timing

analysis

- No constructive integration

(node’s point of view)

Asynchronous systems


- Non optimal end-to-end delays

(synchronization)

- Frames might be missed

Synchronous systems


+ deterministic and optimal end-

to-end delays

- Flexibility


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

Intermediate summary


Improving the development

methods and processes


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 notationse.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 requirementse.g.: UML modeling

Formal model-based: method for definite, orderly and methodical

requirement definition

most precise requirement definition

e.g. Petri nets, timed automata


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

Requirement engineering – structuring (ontology)


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


EAST-ADL (www.atesst.org)


Seamless modeling - vision

Requirements

system architecture

specification and

management (EAST-ADL)

Safety analysis

(HiP-HOPS)

IDE

architecture modeling

(AUTOSAR)

behavioral modeling

(Matlab / Simulink)

Further static analysis


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


ISO 26262


Area E Vehicle Electrics/Electronics and Software












Gefördert mit Mitteln des FFG, des Landes Steiermark und der Stadt Graz und der steirischen Wirtschaftsförderung (SFG)COMET K2 Forschungsprogramm

Eine Förderinitiative des Bundesministeriums für Verkehr, Innovation und Technologie (BMVIT) und dem

Bundesministerium für Wirtschaft und Arbeit BMWA).

Gefördert mit Mitteln der FFG, des Landes Steiermark und der steirischen Wirtschaftsförderung (SFG)

Ein Kompetenzzentrum der

PROJECT

PARTNER

MEMBER OF

Embedded Systems GroupDistributed real-time systems

Safety-relevant applications

Design methods & processes


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]

TEODACS: two development platforms for the analysis

of automotive distributed embedded systems

http://www.teodacs.com/


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)

Data link level: Efficient analysis of the logical

transmission

FlexRay controller (SystemC)

Middleware: Integration of selected AUTOSAR

concepts:

Virtual Function Bus functionality (SystemC/C++)

Integration of SW components:

AUTOSAR-like

Ports/Runnables/Server-Client/

Sender-Receiver/…

FlexRay CC

(SystemC)

FlexRay

transceiver

(VHDL-AMS)

Active Star

(VHDL / VHDL-AMS)

T connector

(VHDL-AMS)

Cable +

ev. termination

(VHDL-AMS)


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


Function A (e.g. move mirror)

Function C

(e.g. infotainment)

Function B

(e.g. vibration reduction)

Optimal Software allocation: analysis and optimisation

of real-time distributed embedded systems

Allocation

Scheduling

Priorities

Bus config.

Discrete optimization

Partners: Magna Powertrain, AUCOTEC


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


Validation challenges

• Node„s validation

COTS development environments

• System validation

industrial FlexRay protocol

analyzers

methods to check the

transmission completeness w.r.t.

Fibex configuration (TEODACS)

Design challenges

• System design

support from functional engineering

• Communication architecture design

industrial tools for comm. planning

• Node„s design

COTS development environments

dedicated configuration exporters for

the different platforms (TEODACS)

TEODACS: Development flow and configuration

management


Goal:

Building ecosystem for development environments for safety-critical real-time embedded

systems supporting avionics, automotive, rail, and space.

CESAR: Design methods & processes for automotive

embedded systems

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

Lead partners: AVL, Airbus, EADS, see www.cesarproject.eu

http://www.cesarproject.eu/


Interoperability Concept

Embedded Software

Development Process

Safety Standards

Domain Requirements Tools

Data Formats

Meta Models

Data Standards

ReposRepos

itory

Management

Console

Application

Domains

Specific Tool Chain (Instance of RTP)

Generic Model Based

Integration Platform

for safety-critical

embedded systems

development

RTP = Reference Technology Platform

Parts of pictures from

A.Keis/EADS

Configuration Tailoring

TCP / IP ToolNetRTP TCP / IP ToolNetRTP


SPEM


DB DB

Service Oriented Architecture (SOA)

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

Integration Concept

Provide an Integration Platform for the exchange of model based data

Application

GUI

Application

GUI

DB

Application

GUI

ModelBus

Model based Core Data Model of Integration Platform

Process

Engine

Model Check

Service

Process

ManagementRules

GUI

Transformation

Service

Model

Mapping GUI

Repository


Tool 1 Tool 2 Tool 3

Tool

Adapter

Tool

Adapter

Platform integrated Services (Examples)


Tool Adapter Concept

Syntactic Transformation, translate data format

Provide exchange of XML model fragments

Speak the same language

Service Integration - Abstract Interface Level

Connecting Tool-API or data file format to platform Interface (e.g. Java

RPC) via HTTP/SOAP requests

Establishing a communication channel

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

Speak from the same thingsRTP

Transformation

RTP

Transformation

Services


Process definition

Definition of the development stages

EAST-ADL2, ISO 26262, AUTOSAR

Interface definition

Seamless integration of the

different development tools

Continuous validation

Integration of requirements

System validation at different

stages

Evaluation

Quality of the resulting system

Efficiency of the development environment

MEPAS – focus on single automotive development

process

Implementation

level

AUTOSAR

Verification

and validation

Requirement

&Specification

(system

features)

Abstract

functional

architecture

level

Detailed

Design Level

(architecture)

Syste

m v

ali

dati

on

Sim

ula

tion, S

iL, H

iL

SW

Qu

alifi

cati

on

sta

ndard

s, norm

s,

pro

cess

Partners: AVL, TU Graz (ITI)


MEPAS: Model-based system design

Lead Project

System

specificationRequirements Behavioral model V1

Simulink

Behavioral model V2

Simulink

….

Refined, multi-view,

high-level system

model V2

Error Model

Process Modeling

/Safety Activities Requirements

Activities

t

High-level system

model V1

(Structure,

Dependencies, …)

Tool selection

Selection of

modeling language

(e.g. EAST-ADL)

Input Input

Data Management Platform

Consistency

checks

Output:

Analysis 1

Traceability

Output:

Analysis 2

Multi-view /

cross domain

check

Output:

Analysis 3

Integration of

Behavior and

system model

Improve quality

of models

Output:

Analysis 4

System model

and safety

aspects

Definition of

further steps

according to

results

(MiL, SiL, PiL

test integration,

etc.)

Improve quality of

modeling approach

for future projects

Verify

requirements


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!


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)

Thank you

for your attention!

www.v2c2.at

http://www.v2c2.at/

Documents

Distributed automotive embedded systems: architecture design … · Safety-critical embedded systems have been key innovation drivers E.g. by-wire systems Disadvantage Enormous complexity