FlexRay is primarily used in extremely safety and time-critical automotive applications. Organizing communication in the FlexRay cluster into static communication cycles and linking time slots to the FlexRay nodes provide for a smooth deterministic communication flow. FlexRay nodes that have gotten out of step with the pace may disturb this harmony by unauthorized transmissions within time slots not assigned to them. Preventing this is the task of the so-called bus guardians.

In the local bus guardian concept, a bus guardian (BG) is assigned to each FlexRay transceiver. It only allows the FlexRay transceiver to place data received from the FlexRay controller on the bus, if it conforms to the communication schedule.

The data is located in reserved slots in the static communication segment. Within the dynamic communication segment, there cannot be such protection, since the messages are only sent by the FlexRay nodes if an event occured. It is only possible to either completely allow a FlexRay node to send in the dynamic communication segment or completely prohibit it from sending.

To implement its functionality, the bus guardian must know the communication schedule and the time in the FlexRay cluster. Ideally, the bus guardian does not rely on the local time base generated by the FlexRay controller, but instead generates its time base independent of the FlexRay controller. This is the only way a bus guardian can assure that a FlexRay node can only send in its time slots, because in addition to checking the time slots themselves, all errors of the FlexRay controller’s clock are detected as well.

However, this means that the bus guardian must be equipped with nearly the same functions as the FlexRay controller, giving the bus guardian a similar level of complexity, which would result in increasing costs for FlexRay communication. Regardless of how a bus guardian determines the time, there have not been any implementations of a local bus guardian to date. The related specification node local bus guardian specification is in Version 2.0.9 and its status is preliminary.

The same applies to Version 2.0.9 of the central bus guardian specification. The state is preliminary and no implementations of a central bus guardian exist yet. The concept here involves the bus guardian being located on an active star coupler. Within the communication cycle, the central bus guardian always activates the communication branch whose end is connected to the FlexRay node with authorization to send as specified in the communication schedule. This provides a way to prevent signal collisions.