Flexray Slot Id
Flexray Slot

Of FlexRay messages given timing characteristic (periodicity, jitters, deadlines) of the messages and the mapping of the mes-sages onto the different FlexRay slots along with the message priorities. The authors of 6 provide an analysis of Flexible FTDMA (FTDMA) that ﬁnds the maximum frame identiﬁer for messages so that the delays are reduced. The FlexRay nodes assigned to the static slots can transmit the static messages assigned to the static slots during periodic communicative operation. The precondition for this process are synchronized local counters, each of which are incremented at the beginning of a static slot.

“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)

FlexRay™ Protocol Controller Key Features Customer Benefits Highlights E-Ray module performs communication according to the FlexRay™ protocol specification v2.1 E-Ray module supports data rates of up to 10 Mbit/s on each channel. Configuration of up to 128 message buffers Filtering based on slot, cycle, and channel value. The FlexRay is a deterministic, fault-tolerant, and high-speed automotive networking communication system protocol developed by the FlexRay Consortium to control the automotive ECU’s. The deterministic terminology is used here for Time-division multiple access technologies.

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.

Designing a FlexRay cluster includes following steps:

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

FlexRay configuration

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

FlexRay frames

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)

Application Tasks

“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)

Lac leamy casino reopens. 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)

Flexray Slot Id

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.

It is important to have a margin between the time slot in which one frame can be read/written and the start/finish of a task which reads/writes data from/in that frame.

Handling errors

It is an essential safety requirement to continuously monitor each node, and detect if any of them is not working as expected.

Flexray Slot

On every node an Emergency Task is implemented, which sends in each cycle a Warning message to the Control node about the actual status of the corresponding node. It is very important that the Warning message contains some continuously changing data (e.g. counter or system time). In this way the Control node is able to detect if one node is stuck.

The Control Node must respond with a global Warning message, which has to contain information about the status of each node in the system. For each node failure special error handling algorithms must be implemented, but I think for this we already need some more detailed hardware model, so I will not consider this issue in this article.

Conclusions – Lessons learned

Try to consider following aspects when designing a FlexRay cluster:

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!

Flexray Slots