Image Processing Reference
In-Depth Information
Mini-slot
Frame ID
n
+1
Frame ID
n
+4
Channel A
n
+5
n
+6
n
+7
n
n
+1
n
+2
n
+3
n
+4
n
+2
n
+3
n
+4
n
n
+1
Channel B
Frame ID
n
+4
Frame ID
n
Frame ID
n
+2
Slot
counter
FIGURE .
Example of message scheduling in the dynamic segment of the FlexRay communication cycle. (From
Navet, N., Song, Y.Q., Simonot-Lion, F., and Wilwert, C.,
Proc. IEEE
., (), , . With permission.)
The FlexRay MAC protocol is more flexible than the TTP/C MAC as in the static window nodes
are assigned as many slots as necessary (up to overall) and as the frames are only transmitted
if necessary in the dynamic part of the communication cycle. In a similar way as with TTP/C, the
structure of the communication cycle is statically stored in the nodes, however, unlike TTP/C, mode
changes with a different communication schedule for each mode are not possible.
The FlexRay frame consists of three parts: the header, the payload segment containing up to
bytes of data, and the CRC of bits. he header of bytes includes the identifier of the frame and the
length of the data payload. he use of identifiers allows to move a software component, which sends a
frame
X
, from one ECU to another ECU without changing anything in the nodes that consume frame
X.
It has to be noted that this is no more possible when signals produced by distinct components
are packed into the same frame for the purpose of saving bandwidth (i.e., which is referred to as
frame-packing or PDU-multiplexing—see Ref. [] for this problem addressed on CAN).
From the dependability point of view, the FlexRay standard specifies solely the bus guardian and
the clock synchronization algorithms. Other features, such as mode management facilities or a mem-
bership service, will have to be implemented in software or hardware layers on top of FlexRay (see, for
instance, Ref. [] for a membership service protocol that could be used along with FlexRay). his will
allow to conceive and implement exactly the services that are needed with the drawback that correct
and efficient implementations might be more difficult to achieve in a layer above the communication
controller.
In the FlexRay specification, it is argued that the protocol provides scalable dependability, i.e.,
the “ability to operate in configurations that provide various degrees of fault tolerance.” Indeed, the
protocol allows for mixing links with single and dual transmission supports on the same network,
subnetworks of nodes without bus-guardians or with different fault-tolerance capability with regard
to clock synchronization, etc. In the automotive context where critical and noncritical functions will
increasingly coexist and interoperate, this lexibility can prove to be efficient in terms of cost and reuse
of existing components if missing fault-tolerance features are provided in a middleware (MW) layer,
for instance such as the one currently under development within the automotive industry project
AUTOSAR (see Section .). .).The reader interested in more information about FlexRay can refer to
Ref. [], and to Refs. [,] for how to configure the communication cycle.
13.2.2.2 TTCAN Protocol
TTCAN(seeRef.[])isacommunicationprotocoldevelopedbyRobertBoschGmbHontopof
theCANphysicalandDLLs.TTCANusestheCANstandardbut,inaddition,requiresthatthe