Chien-Chih(Paul) Chao

1
Introduction of FlexRay

• Chien-Chih(Paul) Chao
• Chih-Chiang(Michael) Chang
• Instructor Dr. Ann Gordon-Ross

2
Summary

• General Background
• Performance Analysis of FlexRay-based ECU
  Networks
• Motivations
• Basic framework
• Modeling FlexRay
• Case Study
• Conclusion
• FlexRay Schedule Optimization of the Static
  Segment
• Background Introduction
• Motivation
• Problem definition
• Methodology
• Experimental Results
• Conclusion

3
General Background

• What is FlexRay?

A next generation automotive network
communications protocol.

• When was it released?

First public release(Version 2.0) on Jun
2004. The latest version 3.0.1 was released on
Oct 2010.

• Why uses FlexRay?

1. High bandwidth
2. Flexibility
3. Fault-tolerance
4. Reliability

4
General Background

• FlexRay

• Controller Area Network(CAN)

• 10Mbps x 2 bandwidth
• Time-triggered for real-time transmission
• Event-triggered for low-priority data
• Synchronous
• Deterministic system design

• Bandwidth up to 1Mbps
• Contention resolved by priority.
• Asynchronous
• Acknowledgment and retransmission when message is
  corrupted

5
General Background

• Who developed FlexRay?

• Where used FlexRay?

BMW X5 on 2006, BMW 5-Series, BMW 7-Series Audi
A8, Bentley Mulsanne, Rolls-Royce Ghost
6
General Background

• How does it work?
• Dual channel - scalable system fault-tolerance
• Bus Guardian
• Interconnect topologies centralized or bus

7
General Background

• Macrotick- the nodes own internal clock or
  timer.
• Microtick- a cluster wide synchronized clock.

8
Performance Analysis of FlexRay-based ECU Networks

• Andrei Hagiescu, Unmesh D. Bordoloi, Samarjit
  Chakraborty
• Department of Computer Science, National
  University of Singapore
• Prahladavaradan Sampath, P. Vignesh V. Ganesan,
  S. Ramesh
• General Motors RD India Science Laboratory,
  Bangalore
• Design Automation Conference (DAC) 2007,
• San Diego, California, USA

9
Motivation

• In a high-end car there are up to 70 electronic
  control units (ECUs) exchanging up to 2500
  signals.
• Commonly used protocols include CAN, local
  interconnection network(LIN).
• Previous implementations of FlexRay using only
  static segment, with the dynamic segment being
  unutilized.
• Dynamic part of protocol is more complex.
• The potential messages for dynamic segment is
  more irregular.
• Techniques for analyzing the static segment are
  known(TDMA scheme).

10
Basic Framework
11
Difficulties in Modeling FlexRay

• A message cannot straddle two communication
  cycles.
• Once a task misses in the dynamic segment, it
  will wait till the next cycle.
• A task can send at most one message in each
  dynamic segment.
• One minislot is consumed from the available
  service when a task is not ready to transfer a
  message.

12
Modeling FlexRay

• Step 1 Extract k1 minislots of service during
  each communication cycle from ?l .
• Step 2 Discretize the service bound obtained
  from step 1.
• Step 3 The resulting service bound is shifted by
  d time units.
• Step 4A minislot is lost even when a task does
  not transmit any message.

13
Modeling FlexRay
14
Case Study

• Adaptive Cruise Control application.
• Implemented framework using Matlab as a
  front-end.
• Using Java to handle all the function
  transformation.

15
Results
16
Conclusion

• Present a compositional performance model for a
  network of ECUs communicating via FlexRay bus.
• Formal model of the protocol governing the
  dynamic segment of FlexRay.
• The framework can also be used for deriving the
  parameters of the FlexRay protocol.
• Help in resource dimensioning and determining
  optimal scheduling policies for multitasking ECUs.

17
FlexRay Schedule Optimization of the Static
Segment

• Martin Lukasiewycz, Michael Glaß, and Jürgen
  Teich
• University of Erlangen-Nuremberg, Germany
• Paul Milbredt
• I/EE-81, AUDI AG, German
• CODESISSS 2009, Grenoble, France

18
Quick View

• Presenting a Scheduling Optimization scheme for
  the static segment of the FlexRay bus in
  compliance with the AUTOSAR specification.
• What is AUTOSAR?

19
Background Introduction

• AUTOSAR
• AUTomotive Open System ARchitecture
• FlexRay
• An Automotive Communication System
• Protocol Data Units (PDUs)

20
Background AUTOSAR

• AUTomotive Open System Architecture
• Open and Standardized automotive software
  architecture
• Partnership for automotive E/E (Electrics/Electron
  ics) architectures
• Standardization
• Basic systems functions,
• Scalability to different vehicle
• Transferability throughout the network
• Maintainability throughout the entire product
  life-cycle
• Etc.

21
Background FlexRay

• Static Segment
• Time-triggered
• Enable a guaranteed real-time transmission of
  critical data
• Periodic and Safety-critical data
• Reserved slots for deterministic data that
  arrives at a fixed period
• Dynamic Segment
• Even-triggered
• For low priority data
• Maintenance and Diagnosis data
• does not require determinism

22
Background FlexRay (Cont.)

• Communication Cycle
• Symbol WindowTypically used for network
  maintenance and signaling for starting the
  network. 
• Network Idle TimeA known "quiet" time used to
  maintain synchronization between node clocks.

23
Background FlexRay Static Seg.

• Static Segment

24
Background FlexRay Static Seg.

• Made up of n equally sized slots
• each slots is uniquely assigned to one node
• Node may occupy more than one slot

1
2
3
25
Background FlexRay Static Seg.

• Each slot header, trailer, and payload segment

PDU
PDU
PDU
PDU
PDU
PDU
PDU
PDU
26
Background PDUs

• The mechanism for communicating information
  between protocols, they are most generally called
  protocol data units (PDUs).

OSI Layer PDU Name
Application Data
Presentation Data
Session Data
Transport Segment
Network Packet
Data Link Frame
Physical Bits
27
Motivation

• To minimize the number of used slots in order to
  maximize the utilization of the bus
• Scheduling optimization scheme for the static
  segment of the FlexRay bus

28
Problem definition

• Scheduling Problem
• Scheduling Requirements
• the static time-triggered segment
• Why optimization?
• high flexibility for incremental schedule changes
• for future automotive networks with a higher data
  volume
• fast scheduling techniques are necessary
• to allow for an effective parameter
  exploration
• AUTOSAR Interface Specification
• cycle multiplexing for a single slot
• maximizes the utilization of the
• static segment in compliance with
• the high requirements for reliability
• and robustness

29
Methodology
30
Methodology
Bin
Slot
Optimal
31
Methodology

• Problem Transformation
• Transform the scheduling problem into a special
  two-dimensional bin packing problem
• 1 slot ?? 1 bin
• Constraints

32
Methodology

• Bin Packing
• The Heuristic Approach
• Fast Greedy Heuristic
• Better with Unconstrained Problems
• ILP Approach
• Better with Constrained Problems
• Enhanced ILP
• Mutex Packing
• Add Mutual Exclusion to the bin packing
• Reordering
• For Extensibility of a bin and a slot

33
Fast Greedy Heuristic

• Greedy implies Local Optimal ? Global Optimal
• To put elements into bins
• The Order of the elements (by height and weight)
• Allocated new empty bin

34
Integer Linear Programming (ILP)

• Placing the elements starting from the highest
  element to the most left void space in the bin s
  at the level l results in a feasible solution of
  the bin packing problem.
• Enhanced ILP
• This constraint improves the runtime of the ILP
  If the optimal solution is reached and equals the
  lower bound, the optimization process terminates
  immediately.

35
Experimental Results

• Schedule Optimization
• Incremental Scheduling
• Scalability Analysis
• ILP Heuristic
• Slot Size Exploration
• Supportive Test Case

36
Results - Schedule Optimization

• Intel Pentium 4 3.20 GHz machine with 512 MB RAM
• highly heterogeneous in terms of their period and
  size
• the only approach currently, TTX Plan

37
Results - Incremental Scheduling

• In contrast to the ILP approach, the heuristic
  scheduling method allows an incremental
  scheduling.
• An incremental scheduling might be favored if the
  number of allocated slots is still not critical
  since integration tests are time-consuming and
  expensive.

38
Results Scalability
39
Results - Supportive Test Case
40
Conclusion

• There exists no publication regarding the FlexRay
  bus scheduling in compliance with the industrial
  AUTOSAR Interface Specification.
• The case study show that the heuristic and ILP
  approach are superior to a commercial tool in
  runtime and quality.
• A supportive case study shows the flexibility and
  robustness of the proposed algorithms

41
Thank you!