Download - HANSER automotive
Download - HANSER automotive
Download - HANSER automotive
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
© Carl Hanser Verlag, München www.hanser-<strong>automotive</strong>.de Nicht zur Verfügung im Intranet- und Internet-Angeboten sowie elektronischen Verteilern<br />
22lA UTOMOTIVE 2008l SPECIAL EDITION FLEXRAY<br />
Fig. 2: A valid whitelist has to be within the validity span of a buffer.<br />
can be assigned to each slot, independent of the frame<br />
received in that slot. The buffer then needs to be read in<br />
each communication cycle, and the number of buffers is an<br />
upper limit for the number of nodes in a communication<br />
cluster, because a buffer is not allowed to be assigned to<br />
more than one slot. This relaxes constraints quite a bit: we<br />
may have hundreds of frames, but only dozens of slots and<br />
the number of buffers typically is sufficient for this strategy.<br />
But is it always possible?<br />
Validity Spans and Grouping of FrIf Jobs<br />
The following example illustrates how the buffer allocation<br />
can support the optimal FlexRay Interface layer configuration<br />
with respect to CPU load. For demonstration we choose<br />
a single-channel FlexRay network schedule with 8<br />
cycles (instead of the full 64) and 8 static slots (instead of<br />
the several dozens that large FlexRay schedules have). As<br />
shown in the figure 1, there are 2 PDUs sent in this slot –<br />
the first one (green) is sent every odd cycle and the other<br />
one (blue) is sent every even cycle. Initially, all frames of<br />
one static slot for transmission (or reception) could share<br />
one buffer. The disadvantage with this approach is that one<br />
FlexRay Interface interrupt has to be raised in every communication<br />
cycle to copy the PDUs from the system<br />
memory into the controller buffers for transmission (or the<br />
other way round, for reception).<br />
If the real-time constraints for the PDUs allow, one FlexRay<br />
Interface interrupt per two cycles would be sufficient. For<br />
this, two buffers have to be used, and FlexRay controller<br />
configuration specifies when (i.e. in which slot and cycle)<br />
which buffer is to be sent. Such a “cycle filtering” configuration<br />
is specified by a “base cycle” parameter (the first<br />
transmission will occur in cycle N of the 64 cycles) and a<br />
“cycle repetition” parameter (the transmission will reoccur<br />
every N cycles throughout the 64 cycles) for each<br />
buffer. One FlexRay Interface job can now be executed in<br />
the beginning of every odd cycle, copying both PDUs to the<br />
corresponding buffers.<br />
In this example configuration, the “validity span” of each<br />
of these two buffers is “two cycles”: Each buffer can be<br />
updated in a time interval lasting two cycles, before the<br />
transmission is performed by the FlexRay controller, and<br />
new data needs to be provided. It is easier to compute a<br />
schedule for the jobs of a FrIf to operate on buffers with<br />
large validity spans, just as it is easier for humans to enter<br />
a slow-moving merry-go-round than a fast-moving one. And<br />
larger validity spans usually mean that more FrIf jobs can<br />
be grouped together, resulting in lower CPU usage for FrIf<br />
activations/context switches.<br />
Application Constraints and Automatic<br />
Scheduling<br />
A more sophisticated buffer allocation algorithm is required<br />
when the application has additional timing constraints<br />
about “when does the communication have to take place”.<br />
We assume a communication schedule where several relevant<br />
PDUs are transmitted in a single slot (X). As shown in<br />
figure 2,<br />
<br />
<br />
<br />
© <strong>automotive</strong><br />
PDU_A is transmitted with base cycle 0 and cycle<br />
repetition 4,<br />
PDU_B is transmitted with base cycle 0 and cycle<br />
repetition 1,<br />
PDU_C is transmitted with base cycle 1 and repetition<br />
2.<br />
Therefore, each frame in slot X contains 2 PDUs (in one<br />
case, one PDU is missing; this is “currently unused” frame<br />
space that can be used for later extensions to the schedule).<br />
In cycle 0 (with repetition 4), the frame contains PDUs<br />
A and B, in cycle 1 (with repetition 2!) the frame contains<br />
PDUs B and C, and in cycle 2 (with repetition 4), the frame<br />
contains just PDU B. Assuming an application is concerned<br />
with data in PDU_A and PDU_C, FlexRay data for this application<br />
will be received in 3 out of every 4 cycles. However,<br />
let’s say the application requires – here is the additional<br />
constraint (in complex systems there will be several of<br />
these) – that the AUTOSAR COM functions are only executed<br />
at the end of every second communication cycle.<br />
(Such a constraint is typically defined to ensure that legacy<br />
applications are not interrupted by basic software activations).<br />
Allocating one buffer for slot X is now forbidden,<br />
because we get new data in three out of four cycles, but<br />
we are not allowed to schedule one FlexRay Interface activation<br />
per cycle. Hence a smart buffer allocation algorithm<br />
is necessary to maximize the validity span of buffers: two