20100601 armengaud tu wien print
TRANSCRIPT
-
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)
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)
K plus Kompetenzzentrenprogramm,
eine Frderinitiative des Bundesministeriums fr Verkehr, Innovation und Technologie (BMVIT)
Gefrdert mit Mitteln des FFG, des LandesStei ermark undder Stadt Graz und der steirischen Wirtschaftsfrderung (SFG)
K plus Kompetenzzentrenprogramm,
eine Frderinitiative des Bundesministeriums fr Verkehr, Innovation und Technologie (BMVIT)
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
-
8/6/2019 20100601 Armengaud TU Wien Print
2/44
2010-06-01 TU Wien, HW-SW Co-Design 2
Content
Electronics in car
The time-triggered architecture & FlexRay
Improving the development methods and processes
Research activities @ Virtual Vehicle CompetenceCenter
-
8/6/2019 20100601 Armengaud TU Wien Print
3/44
2010-06-01 TU Wien, HW-SW Co-Design 3
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:
-
8/6/2019 20100601 Armengaud TU Wien Print
4/44
2010-06-01 TU Wien, HW-SW Co-Design 4
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:
-
8/6/2019 20100601 Armengaud TU Wien Print
5/44
2010-06-01 TU Wien, HW-SW Co-Design 5
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."
-
8/6/2019 20100601 Armengaud TU Wien Print
6/44
2010-06-01 TU Wien, HW-SW Co-Design 6
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
-
8/6/2019 20100601 Armengaud TU Wien Print
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
-
8/6/2019 20100601 Armengaud TU Wien Print
8/442010-06-01 TU Wien, HW-SW Co-Design 8
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)
-
8/6/2019 20100601 Armengaud TU Wien Print
9/442010-06-01 TU Wien, HW-SW Co-Design 9
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)
-
8/6/2019 20100601 Armengaud TU Wien Print
10/442010-06-01 TU Wien, HW-SW Co-Design 10
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]
-
8/6/2019 20100601 Armengaud TU Wien Print
11/442010-06-01 TU Wien, HW-SW Co-Design 11
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
-
8/6/2019 20100601 Armengaud TU Wien Print
12/442010-06-01 TU Wien, HW-SW Co-Design 12
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
-
8/6/2019 20100601 Armengaud TU Wien Print
13/442010-06-01 TU Wien, HW-SW Co-Design 13
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
-
8/6/2019 20100601 Armengaud TU Wien Print
14/442010-06-01 TU Wien, HW-SW Co-Design 14
FlexRay
Overview
-
8/6/2019 20100601 Armengaud TU Wien Print
15/442010-06-01 TU Wien, HW-SW Co-Design 15
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
-
8/6/2019 20100601 Armengaud TU Wien Print
16/442010-06-01 TU Wien, HW-SW Co-Design 16
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
Slot 1 Slot 2 Slot 3 Slot 4 Slot 5 Slot 6 Slot 7 Slot 8
Frame
Slot 1 Slot 2 Slot 3 Slot 4 Slot 5 Slot 6 Slot 7 Slot 8
Frame Frame
-
8/6/2019 20100601 Armengaud TU Wien Print
17/442010-06-01 TU Wien, HW-SW Co-Design 17
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
-
8/6/2019 20100601 Armengaud TU Wien Print
18/442010-06-01 TU Wien, HW-SW Co-Design 18
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
-
8/6/2019 20100601 Armengaud TU Wien Print
19/442010-06-01 TU Wien, HW-SW Co-Design 19
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)
-
8/6/2019 20100601 Armengaud TU Wien Print
20/442010-06-01 TU Wien, HW-SW Co-Design 20
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
+ 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
-
8/6/2019 20100601 Armengaud TU Wien Print
21/44
2010-06-01 TU Wien, HW-SW Co-Design 21
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
-
8/6/2019 20100601 Armengaud TU Wien Print
22/44
2010-06-01 TU Wien, HW-SW Co-Design 22
Improving the development
methods and processes
-
8/6/2019 20100601 Armengaud TU Wien Print
23/44
2010-06-01 TU Wien, HW-SW Co-Design 23
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
-
8/6/2019 20100601 Armengaud TU Wien Print
24/44
2010-06-01 TU Wien, HW-SW Co-Design 24
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)
-
8/6/2019 20100601 Armengaud TU Wien Print
25/44
-
8/6/2019 20100601 Armengaud TU Wien Print
26/44
2010-06-01 TU Wien, HW-SW Co-Design 26
EAST-ADL (www.atesst.org)
-
8/6/2019 20100601 Armengaud TU Wien Print
27/44
2010-06-01 TU Wien, HW-SW Co-Design 27
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
-
8/6/2019 20100601 Armengaud TU Wien Print
28/44
2010-06-01 TU Wien, HW-SW Co-Design 28
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
-
8/6/2019 20100601 Armengaud TU Wien Print
29/44
2010-06-01 TU Wien, HW-SW Co-Design 29
ISO 26262
-
8/6/2019 20100601 Armengaud TU Wien Print
30/44
2010-06-01 TU Wien, HW-SW Co-Design 30
Area EVehicle Electrics/Electronics and Software
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)
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)
K plus Kompetenzzentrenprogramm,
eine Frderinitiative des Bundesministeriums fr Verkehr, Innovation und Technologie (BMVIT)
Gefrdert mit Mitteln des FFG, des LandesStei ermark undder Stadt Graz und der steirischen Wirtschaftsfrderung (SFG)
K plus Kompetenzzentrenprogramm,
eine Frderinitiative des Bundesministeriums fr Verkehr, Innovation und Technologie (BMVIT)
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
-
8/6/2019 20100601 Armengaud TU Wien Print
31/44
Fl R X t Si i l ti l tf Si l ti
-
8/6/2019 20100601 Armengaud TU Wien Print
32/44
2010-06-01 TU Wien, HW-SW Co-Design 32
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
-
8/6/2019 20100601 Armengaud TU Wien Print
33/44
2010-06-01 TU Wien, HW-SW Co-Design 33
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
-
8/6/2019 20100601 Armengaud TU Wien Print
34/44
2010-06-01 TU Wien, HW-SW Co-Design 34
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
-
8/6/2019 20100601 Armengaud TU Wien Print
35/44
2010-06-01 TU Wien, HW-SW Co-Design 35
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
-
8/6/2019 20100601 Armengaud TU Wien Print
36/44
2010-06-01 TU Wien, HW-SW Co-Design 36
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
-
8/6/2019 20100601 Armengaud TU Wien Print
37/44
2010-06-01 TU Wien, HW-SW Co-Design 37
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/ -
8/6/2019 20100601 Armengaud TU Wien Print
38/44
2010-06-01 TU Wien, HW-SW Co-Design 38
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
-
8/6/2019 20100601 Armengaud TU Wien Print
39/44
2010-06-01 TU Wien, HW-SW Co-Design 39
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)
-
8/6/2019 20100601 Armengaud TU Wien Print
40/44
2010-06-01 TU Wien, HW-SW Co-Design 40
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
-
8/6/2019 20100601 Armengaud TU Wien Print
41/44
2010-06-01 TU Wien, HW-SW Co-Design 41
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)
-
8/6/2019 20100601 Armengaud TU Wien Print
42/44
2010-06-01 TU Wien, HW-SW Co-Design 42
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
-
8/6/2019 20100601 Armengaud TU Wien Print
43/44
2010-06-01 TU Wien, HW-SW Co-Design 43
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!
-
8/6/2019 20100601 Armengaud TU Wien Print
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/