20100601 Armengaud TU Wien Print

8/6/2019 20100601 Armengaud TU Wien Print

1/44

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

K plus Kompetenzzentrenprogramm,

eine Frderinitiative des Bundesministeriums fr Verkehr, Innovation und Technologie (BMVIT)

Gefrdert mit Mitteln des FFG, des LandesSteier mark undder Stadt Graz undder steirischen Wirtschaftsfrderung (SFG)






Gefrdert mit Mitteln des FFG, des LandesStei ermark undder Stadt Graz und der steirischen Wirtschaftsfrderung (SFG)



Gefrdert mit Mitteln des FFG, des LandesStei ermark undder Stadt Graz und der steirischen Wirtschaftsfrderung (SFG)COMET K2 Forschungsprogramm

Eine Frderinitiative des Bundesministeriums fr Verkehr, Innovation und Technologie (BMVIT) und dem

Bundesministerium fr Wirtschaft und Arbeit BMWA).

Gefrdert mit Mitteln der FFG, des Landes Steiermark und der steirischen Wirtschaftsfrderung (SFG)

Ein Kompetenzzentrum der

PROJECT

PARTNER

MEMBER OF

Distributed automotive embedded systems:architecture design and development methods

Dr. Eric ArmengaudVIF - Area E/E & SW

Group leader embedded systems

June 1st, 2010


2/44


Content

Electronics in car

The time-triggered architecture & FlexRay

Improving the development methods and processes

Research activities @ Virtual Vehicle CompetenceCenter


3/44


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: 135Turnover: EUR 12 Mio.

40%

10%

19%

19%

12%

Shareholder:


4/44


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:


5/44


Semiconductor vs. Automotive industry

If the automotive industry had advanced as rapidly as the

semiconductor industry wed 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 aquarter-inch high."


6/44


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 challengingindustry (automotive, aerospace, rail,

automation)

Increasing costs

Affected product quality safety-

critical

Source: AVL List

Electronics in cars


7/442010-06-01 TU Wien, HW-SW Co-Design 7

Networks in cars

Snapshot 2004: the VW Phaeton

2110 cables

3860 meters cable

Weight: 64kg

70 ECUs

Wide requirements

Low cost for non safety-criticalsystems (e.g. LIN, CAN)

High bandwidth for infotainment(e.g. MOST)

Dependability for safety-criticalapplications (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 levelrequirements

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 andmulti level architecture trade-offs

Safety methods and processes

Ensure the quality of a product via the execution of safety relatedactivities 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 communicationand 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 foreach new event i.e. majorstate change (e.g. temperature increase of +5 degree)

Each event (communication) has to be detected and processedin the same time order it arrived

Optimal use of the bandwidth

Not robust lost of message might lead to systeminconsistencies

Status-based communication

Periodic communication forupdating system state(e.g. temperature is currently 55 degree)

Events (communication elements) might be missed or processedin different time order than reception time

Worse-case use of the bandwidth

Robustness: lost of message only induce additional processingdelays 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 tocorrect 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) whenthe nodes are awake

Reintegration: to integrate single nodes within a runningcluster



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: mappingbetween 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)

Communication

system

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

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


21/44


Automotive electronics

Cars are forming complex distributed systems, evolving in harshenvironments; 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


22/44


Improving the development

methods and processes


23/44


Requirement engineering specification language

Free text: no constraint

no training requirede.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 ambiguitye.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 THEN SHALL DO WITHIN

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


24/44


Traceability: Requirements traceability refers to the ability todescribe 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)


25/44


26/44


EAST-ADL (www.atesst.org)


27/44


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


28/44


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


29/44


ISO 26262


30/44


Area EVehicle Electrics/Electronics and Software









Gefrdert mit Mitteln des FFG, des LandesStei ermark undder Stadt Graz und der steirischen Wirtschaftsfrderung (SFG)



Gefrdert mit Mitteln des FFG, des LandesStei ermark undder Stadt Graz und der steirischen Wirtschaftsfrderung (SFG)COMET K2 Forschungsprogramm

Eine Frderinitiative des Bundesministeriums fr Verkehr, Innovation und Technologie (BMVIT) und dem

Bundesministerium fr Wirtschaft und Arbeit BMWA).

Gefrdert mit Mitteln der FFG, des Landes Steiermark und der steirischen Wirtschaftsfrderung (SFG)

Ein Kompetenzzentrum der

PROJECT

PARTNER

MEMBER OF

Embedded Systems Group

Distributed real-time systemsSafety-relevant applications

Design methods & processes


31/44

Fl R X t Si i l ti l tf Si l ti


32/44


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 logicaltransmission

FlexRay controller (SystemC)

Middleware: Integration of selected AUTOSARconcepts:

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)

Fl R X t L b li ti HW l tf f th l i


33/44


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

O ti l S ft ll ti l i d ti i ti


34/44


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 M th d f d d l i d


35/44


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

TEODACS: Development flow and configuration


36/44


Validation challenges

Nodes 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

Nodes design

COTS development environments

dedicated configuration exporters for

the different platforms (TEODACS)

TEODACS: Development flow and configuration

management

CESAR: Design methods & processes for automotive


37/44


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/http://www.cesarproject.eu/


38/44


Interoperability Concept

Embedded Software

Development Process

Safety Standards

Domain Requirements ToolsData Formats

Meta Models

Data Standards

Repos

itory

Management

Console

Application

Domains

Specific Tool Chain (Instance of RTP)

Generic Model Based

Integration Platform

for safety-criticalembedded systems

development

RTP = Reference Technology Platform

Parts of pictures from

A.Keis/EADS

Configuration Tailoring

SPEM


39/44


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 CheckService

Process

ManagementRules

GUI

TransformationService

Model

Mapping GUI

Repository

Tool 1 Tool 2 Tool 3

Tool

Adapter

Tool

Adapter

Platform integrated Services (Examples)


40/44


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

Services

MEPAS focus on single automotive development


41/44


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

Implementationlevel

AUTOSAR

Verification

and validation

Requirement

&Specification(system

features)

Abstractfunctional

architecture

level

DetailedDesign Level

(architecture)

Systemvalidation

Simulation,

SiL,

HiL

SWQ

ualificatio

n

sta

ndards,norms,pr

ocess

Partners: AVL, TU Graz (ITI)


42/44


MEPAS: Model-based system design

Lead Project

System

specificationRequirements Behavioral model V1

Simulink

Behavioral model V2

Simulink

.

Refined, multi-view,

high-level systemmodel V2

Error Model

Process Modeling

/Safety ActivitiesRequirements

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 safetyaspects

Definition of

further steps

according to

results

(MiL, SiL, PiL

test integration,

etc.)

Improve quality of

modeling approach

for future projects

Verify

requirements


43/44


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

Do not forget Verification and Validation!


44/44

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

Thank youfor your attention!

www.v2c2.at
http://www.v2c2.at/http://www.v2c2.at/

20100601 Armengaud TU Wien Print

Documents

Transcript of 20100601 Armengaud TU Wien Print