“The FlexRay Communications System is a robust, scalable, deterministic, and fault-tolerant digital serial bus system designed for use in automotive applications.” (www.flexray.com)
In the following article you’ll find a possible solution for managing the communication between several nodes in a vehicle, using FlexRay. This solution has been provided for the System Architecture and Engineering course held at the Technikum Wien University of Applied Sciences.
Let’s start with a short description of our available hardware. The picture below shows an illustration of the system.
There are five nodes in our system, running parallel and communicating with each other using FlexRay frames. Our job is to design the FlexRay cluster, and build error handling scenarios.System specification:
- Pedal node: each of the pedal nodes has to send the current pedal position to the calculation node.
- Calculation node: it has to calculate the motor speed that is to be set from the read in pedal positions. It is a must-have that both pedals have an impact on the motor speed.
- Motor node: this node reads in the motor speed from the calculation node and controls the motor.
- Control node: this node has to monitor the other four nodes and has to send a warning message to all nodes if one or more nodes are not functional. The warning message has to be handled on each node.
- Specifying the FlexRay configuration: e.g. length of one communication cycle, number of slots in one cycle.
- Specifying the FlexRay frames: e.g. data messages that the nodes exchange, synchronization frames
- Specifying application tasks: e.g. estimate WCET for every task, define offsets
Number of FlexRay channels: 1.
In safety critical systems usually both FlexRay channels are used, as redundant channels. In this example, I’ve decided to only “use” one channel, for more simplitciy.
Cycle length: 5000 us
Number of static slots: 21
Static slot length: 200 us
Payload length of static slots: 4 byte
Dynamic segment – Minislot length: 6 us (the dynamic segment in this example is not used)
Network Idle Time: 200 us
On the following figure you can find the used FlexRay frames, together with slot numbers, frame producer node and frame consumer nodes.
“A FlexRay system needs at least two nodes which transmit frames specifically marked for synchronization (SyncFrames) so that the other nodes can synchronize to the FlexRay cycle and participate in the communication. If one of the two nodes is disconnected the whole FlexRay cluster would stop working. Therefore each node in this system has to transmit a SyncFrame to all other nodes. The SyncFrame can also be used as a data frame, but in this solution it will be used only for synchronization.” (DI Andreas Puhm)
“A simple dispatcher runs on every node which provides an environment for the application. This dispatcher is synchronized with the FlexRay cycle and starts the different tasks at their pre-defined time. It cannot stop a task on its own so the developer has to assure that each task can finish its process before the next task should be started.” (DI Andreas Puhm)
Below you can find the WCET (worst-case execution time) estimation, which helps in the decision for different activation times of the tasks on one node and should prevent the case that one task misses its activation time because the previous task is still running (this has to be avoided at all costs).
Each node needs one SystemTask (WCET 500 us) and one or more application tasks.
The WCET for each task has been calculated using following algorithm: 100 us is needed to read or write one FlexRay slot. So the total time needed for one task is: (Nr. of frames) * 100 us + 100 us margin.
In this configuration, there is no separate task for sending the synchronization frames, so in our case Nr. of frames = Nr. of Data Frames + 1 SyncFrame. (If both FlexRay channels are used, the WCET time should be calculated with the formula: 2*Nr. of Frames + Margin)
In order to set the offsets for each task, it is easier to create a timeline first. After the timeline is created, the offset values can be easily read from the graphic.
Conclusions – Lessons learned
- design your system so that your well written, tested applications task could be used in as many cases as possible (reuse)
- an application task must be always scheduled to start only after all messages needed by the task are available
- avoid one servant – multiple masters configuration between application tasks. Slave tasks will not work as intended if they receive commands from multiple master processes
Note: the FlexRay cluster design provided in this article is not an optimized version!