Presentation kit

1
(No Transcript)
2
Experimental Jitter Analysis in a FlexCAN based
DbW Automotive Application

• Juan R. Pimentel
• Kettering University
• and
• Jason Paskvan
• Mentor Graphics Corporation

3
Presentation Outline

• Introduction
• Characterization of Jitter in CAN
• Summary of FlexCAN
• How FlexCAN reduces Jitter
• FlexCAN based Drive by Wire Application
• Experiments to measure Jitter
• Results
• Conclusions

4
Introduction

• CAN is a mature protocol for many small
  areaapplications due to its
• error control features
• low latency
• priority-based bus access
• instant bit monitoring
• CAN limitations
• Speed up to 1 Mbps
• Limited distance (related to speed)
• Limited dependability
• There is an ongoing debate of whether CAN,with
  proper enhancements, can support safety-critical
  applications

5
Introduction

• Although highly advantageous, the priority-based
  bus access has the negative side effect of
  causing substantial network delay jitter
• A large jitter can have a detrimental impact on
  the performance of many distributed embedded
  systems
• There has been several proposals to make CAN more
  deterministic and dependable
• One of such proposals is FlexCAN that combines
  features of
• CAN
• FlexRay

6
CAN Features and Limitations

• Great Features
• Global, priority-based bus access (bit-wise
  arbitration)
• Instant bit monitoring
• Instant acknowledgement
• Bwxdelay lt 1 bit time
• Excellent error control features

• Limitations
• Speed (1 Mbps)
• Distance (40 m)
• No unidirectional communications
• Limited error confinement
• Large and variable jitter
• Limited fault-tolerant and safety-critical
  features

7
Message Latency Jitter in CAN

• Three sources of jitter
• due to bit stuffing
• due to jitter in scheduled tasks
• due to the dynamic mixture of TT and ET traffic
• Jitter involving jitter in scheduled tasks is due
  to variations in the time to actually execute
  software tasks in a node
• It is assumed that software tasks are responsible
  for sending CAN messages
• The third type of jitter results from periodic
  messages waiting for higher priority event
  traffic that arrive at arbitrary and
  unpredictable times

8
FlexCAN Main Features

• Architecture
• Node replication (1, 2, 3, )
• Channel replication (1, 2, 3, )
• Synchronization
• CST (TT from application)
• node replication
• channel replication
• Replication management
• Protocol SafeCAN
• Replacement for primary node is always ready
  thanks on an ranking protocol based on hardware
  addresses.

• Support for Composability in time domain
• Communication cycle
• Reference message
• Timer based
• Enforcement of fail-silent behavior
• Transient failures
• Similar to FTT-CAN
• Permanent failures SafeCAN, Bus guardian

9
FlexCAN Architecture

• Node replication (1, 2, 3, )
• Channel replication (1, 2, 3, )

Controller
FTU
Safeware
Sensor
Safeware
Safeware
Sensor
Actuator
Safety
Network
Standard
Standard
Safety
Layer
Manager
Application
Safety
Application
Layer
2
2
2
Layer
2
2
2
2
2
2
2
2
2
2
2
1
1
1
1
1
1
1
1
1
1
1
1
1
1
Replicated CAN channels
10
FlexCAN Composability

• Communication Cycle (Defines Cycle Time)
• Reference message (one per cycle time)
• Timer based (resolution of at least 0.1 ms)
• Integral number of sub-cycles per comm. cycle
• In fig. below there are four sub-cycles
• Messages are scheduled into sub-cycles
• Messages from different sub-cycles do not
  interferewith one another (principle of
  independence, enforcedby removing messages from
  transmit buffer at the endof the sub-cycle)

Cycle Time
Angle, speed
Angle, speed, status
Angle, speed
Gateway
commands
and force fdk
references
M4, m5, m6
M1, m2
M3
M9
m7, m8
HW_Position
HW_Position
HW_Position
HW_Position
HW_Position
HW_Position
T
T
T
T
1
4
2
3
11
FlexCAN Highly Deterministic
Sampling Period Ts
Sn
Sn
WSn
Sensing
Un
WUn
Computation
WAn
An
Actuation
CSn
CUn
Bus
E
1
E
8
E
1
E
2
E
3
E
4
E
5
E
6
E
8
E
2
Communication cycle
Steering speed
,
Angle
,
speed
Angle
,
speed
Traction speed
status and force
references
,
commands
and status
fdk
Gateway
m
1
,
m
2
m
6
,
m
7
,
m
8
m
4
,
m
5
m
3
,
m
9
HW
_
Position
HW
_
Position
HW
_
Position
HW
_
Position
HW
_
Position
R
R
R
R
A
D
B
C
Network
HW
S
1
T
1
C
(
P
)
Nodes
P
S
2
T
2
C
(
S
)
FR
Sub cycle
12
FlexCAN Summary

• FlexCAN is an architecture that supports safety
  critical systems
• FlexCAN and its underlying protocol (SafeCAN) has
  the following features

• Flexible
• Simple
• Deterministic
• Cost effective
• Dependable

• Modular
• Scaleable but bounded
• Based on COTS CAN chips and tranceivers
• Compatible with native CAN message IDs

13
Experimental Jitter MeasurementsDrive by Wire
(DbW) System

• Drive-by-Wire (DbW) systems are
  electro-mechanical systems.
• Expected to replace the mechanical/hydraulic
  means transmitting and actuating driving commands
• DbW systems can enhance the safety of the vehicle
  occupants only if
• Dependability issues are addressed
• Main issues
• Assessment of suitable control and communication
  architectures
• Validation of their dependability
• safety-critical functionql units (sub-systems)
• Steering
• Acceleration
• Braking

14
Padova Lift Truck

• Manufacturer Cesab S.p.A.
• Source 48 Volt Battery pack
• Hydraulics
• Steering, hoisting, braking
• Traction two front electric drives (IM)
• Steering mechanism engage rear wheels.
• Safety requirements
• fault-operational
• fault-safe

15
DbW Control Architecture
Force Feedback Reference
Steering Reference
Steering Command
Control
Hand Wheel
Steering
ECU
ECU
ECU
Steering Angle
Steering Status
(Command
Conditioning,
Speed Reference
Vehicle
Accelelator
Speed Command
Traction
management
Pedal
ECU
under faults)
Vehicle Speed
ECU
Drive Status
From Dashboard ECU
16
DbW Control ECU Functions

• Command Conditioning
• Increase stability of system
• Assist driver in maneuvers
• Speed is reduced to avoid overturning the vehicle
  if
• a tight swerve is commanded
• load is up-lifted
• Adaptation of steering ratio to truck speed to
• ease maneuvers at low speed
• avoid quick changes of trajectories at high speed

• Vehicle Management Under Faults
• Upon fault detection All I/O ECUs stop sending
  messages
• This helps I/O units to be ready to receive
  appropriate commands from the Central ECU
• Central ECU prepares commands to put the system
  in a safe state according to the fault.

17
DbW Network Specifications

• A wrong command could be executed with
  potentially dangerous consequences if
• message is missing or late
• data is corrupted
• transmission channel breaks
• A missing message is handled by the Central ECU
• Corrupted data is not recognized by the Central
  ECU and handled by the protocol via CRCs.
• Two channels are needed

• Specification parameters
• communication reliability
• network load
• application load
• data update rate
• Reliability requirement
• A DBW operates properly if
• messages reach destination without error
• within a bounded time interval

18
DbW Message Specifications

• speed command
• speed reference
• actual speed and status (current, temperature)of
  the traction drives
• steering angle command
• steering angle reference
• actual steering angle and status (curr, temp)of
  the steering drives
• force feedback reference
• An additional message is used to convey the
  datacoming from the CAN network through the
  gateway

19
DbW Message Definitions

• Msg Size (bits) ECU Functional
  Description
• M1 32 Hand wheel (HW) Steering angle command
• M2 32 Pedal (P) Acceleration command
• M3 64 Central (C) Acceleration Reference (32
  bits)
• Steering angle Ref. (32 bits)
• M4 56 Traction 1 (T1) Speed and status
• M5 56 Traction 2 (T2) Speed and status
• M6 56 Steering 1 (S1) Speed and status
• M7 56 Steering 2 (S2) Speed and status
• M8 32 Force reaction (FR) Force feedback
• M9 64 Central (C) Gateway message

20
DbW Network Layout
Acceleration
Hand
Control
Pedal
Wheel
C
C
HW
P
CAN bus 1
CAN bus 2
S1
S2
FR
T1
T2
Steering 1
Force
Steering 2
Traction 1
Traction 2
Reaction
21
FlexCAN Global Mesg. Schedule
Basic Cycle
Angle, speed
Angle, speed
Steering speed,
Traction speed
references,
commands
status and force fdk
and status
Gateway
m1, m2
m6, m7, m8
m4, m5
m3,m9
HW_Position
HW_Position
HW_Position
HW_Position
HW_Position
R1
R4
R2
R3
Bus
Guardians
Network
C(S)
HW
S1
T1
C(P)
Nodes
P
S2
T2
FR
22
Experiments

• EXPERIMENT 1 Only periodic traffic
• EXPERIMENT 2 Mixed traffic
• Size of event traffic 8 Bytes
• Priority of event traffic Lower than any
  periodic message
• Event traffic Uniform distribution 2,11 ms
  Inter-arrival time
• EXPERIMENT 3 Mixed traffic
• Same as that of experiment 2 except
• Priority of event traffic Higher than any
  periodic message

23
Summary of Experiments
24
Conclusions

• Sources of jitter in CAN
• bit stuffing
• task schedulers
• interference from other messages
• Simple FlexCAN message scheduling helps reduce
  jitter and make CAN more predictable
• Message schedule of a safety-critical DbW
  application has been implemented and experiments
  were conducted to measure jitter
• Jitter can be controlled in a system based on the
  FlexCAN architecture