1 / 24

Experimental Jitter Analysis in a FlexCAN based DbW Automotive Application

Experimental Jitter Analysis in a FlexCAN based DbW Automotive Application. Juan R. Pimentel Kettering University and Jason Paskvan Mentor Graphics Corporation. Presentation Outline. Introduction Characterization of Jitter in CAN Summary of FlexCAN How FlexCAN reduces Jitter

noelani
Télécharger la présentation

Experimental Jitter Analysis in a FlexCAN based DbW Automotive Application

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Experimental Jitter Analysis in a FlexCAN based DbW Automotive Application Juan R. Pimentel Kettering University and Jason Paskvan Mentor Graphics Corporation

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

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

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

  5. CAN: Features and Limitations Great Features: • Global, priority-based bus access (bit-wise arbitration) • Instant bit monitoring • Instant acknowledgement • Bwxdelay < 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

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

  7. 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 FlexCAN: Main Features

  8. Node replication (1, 2, 3, …) Channelreplication (1, 2, 3, …) FlexCAN: Architecture Controller FTU Safeware Safeware Sensor 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

  9. 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) FlexCAN: Composability 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

  10. FlexCAN: Highly Deterministic Sampling Period Ts Sn Sn WSn Sensing Un WUn WAn Computation An Actuation CSn CUn Bus E 1 E 8 E 1 E 2 E 8 E 2 E 3 E 4 E 5 E 6 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 B C D Network HW S 1 T 1 C ( P ) Nodes P S 2 T 2 C ( S ) FR Sub cycle

  11. FlexCAN is an architecture that supports safety critical systems FlexCAN and its underlying protocol (SafeCAN) has the following features: FlexCAN Summary • Flexible • Simple • Deterministic • Cost effective • Dependable • Modular • Scaleable but bounded • Based on COTS CAN chips and tranceivers • Compatible with native CAN message IDs

  12. Experimental Jitter MeasurementsDrive by Wire (DbW) System • Drive-by-Wire (DbW) systems are electro-mechanicalsystems. • 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

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

  14. 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 under faults) ECU Vehicle Speed ECU Drive Status From Dashboard ECU

  15. 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 DbW: Control ECU Functions Vehicle Management Under Faults • Upon fault detection: All I/O ECU’s 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.

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

  17. 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 DbW Message Specifications

  18. Msg Size (bits) ECU Functional Description M132 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 DbW Message Definitions

  19. DbW Network Layout Hand Acceleration Control Wheel Pedal 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

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

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

  22. Summary of Experiments

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

More Related