Creating FlexRay COM Stack Configurations for ECUs in Complex Networks

The ever increasing need for a higher data communication bandwidth in vehicle networks has led to the introduction of FlexRay. FlexRay is the new de facto standard in automotive real-time communication that provides high bandwidth at up to 10 Mbit/s gross data rate and hard real-time capabilities due to cycle-based communication and time-triggered communication. In addition, it enables easier integration of large and complex real-time networks due to off-line scheduling for critical network communication and full determinism.

As a single FlexRay network can carry 20 times more data than an automotive high-speed CAN network, FlexRay communication controllers offer significantly more buffer memory than CAN controllers to accommodate the incoming and outgoing data frames. Instead of a few hundred bytes of RAM for buffers, a FlexRay controller typically offers, or addresses via DMA access, several kilobytes of buffer memory.

AUTOSAR defines a comprehensive set of layers to manage FlexRay communication in an ECU, from high-level signal management in the COM and handling of large data packets in the Transport Protocol layer down to the FlexRay Interface Layer for management of real-time interfaces and the hardware abstraction in the FlexRay Driver layer.

This article highlights an approach to meet a specific challenge: How can we efficiently allocate the FlexRay buffer memory of an ECU to the communication frames transmitted and received by an ECU? How does this affect the CPU load of this ECU, considering that each access to a communication buffer creates some work for the CPU?

The Allocation Challenge

The challenge itself is illustrated by an example: Assume a "telephone service" shop where 10 telephone booths are available for customer use and we are responsible for assigning customers to phones. Customers can "transmit" by making phone calls there, or "receive" by taking incoming calls there. How can we ensure that the use of the booths is optimized?

Since we know our customers, we try to plan ahead: We have to exclusively reserve a booth for each of our "very important" customers. Whenever they require a phone, we need to have a phone booth available for them. Some customers are known for their short phone calls, usually no more than a few minutes. With regard to this additional information or "constraints", we are able to develop efficient strategies for allocating phones to the customers.

This illustrates the challenge that needs to be solved for complex real-time networks: We have a limited number of buffers (phone booths) and a large number of communication frames (customers), transmitted or received by the FlexRay communication controller (the shop) of our ECU. The buffers have to be allocated to the frames in a way so that no information is lost (this happens if no buffer is free upon reception) or unduly delayed (this happens if no buffer is available when a transmission has to be made).

Optimization Goal of AUTOSAR

An additional constraint is related to how AUTOSAR handles the FlexRay communication: The interface handling the access to the FlexRay buffers, called the FlexRay Interface Layer (FrIf), is a software layer executed at certain pre-defined times and with certain pre-defined actions ("jobs") such as packing and unpacking data. It is like the manager at the phone booth shop: he has some overhead getting up to assign a customer to a booth. If there are many booths and many customers, it would be more efficient to do several assignments in one step. These actions correspond to task activation in an ECU. If the FrIf has to be activated for each job (e.g. transmission or reception of a PDU), a lot of CPU time will be spent just on FrIf activations. It reduces the overhead significantly if we can group these jobs.

A FlexRay communication controller offers dozens or hundreds of buffers, depending on the hardware and, in some cases, on the length of the messages. But several dozens or several hundred FlexRay frames may have to be transmitted and received on this node. This is not a fictional scenario: Some ECUs such as gateways need to send or receive many of the frames on a network, and a non-trivial FlexRay system will usually contain hundreds of different frames. For many of these frames ("static frames"), the frequency, phase and order are exactly known from the FlexRay communication schedule, while for others ("dynamic frames"), this is not necessarily so.