Image Processing Reference
In-Depth Information
(theoldvalueofavariableissimplyreplacedwithanewone).heIntelandCAN
controllers are based on the FullCAN architecture.
FullCAN controllers, in general, free the host controller of a number of activities, so they are con-
sidered to be more powerful than BasicCAN controllers. It is worth noting, however, that recent
CAN controllers are somehow able to embed the operating principles of both architectures, so the
classification mentioned above is progressively being superseded.
15.3 Schedulability Analysis of CAN Networks
From a theoretical point of view, the CAN protocol can be seen as a priority-based nonpreemptive
distributed system. his means that several techniques are available in literature, most of which are
derived from fixed-priority scheduling in real-time operating systems, to analyze timings in a CAN
network. In particular, under well-defined (yet typical, for networked embedded systems) assump-
tions, it is possible to determine the maximum latency a message may experience before it is delivered
to the destination. his, in turn, enables to assess whether or not a given set of messages exchanged
over the network, as a consequence of the operation of a real-time distributed control application, is
really schedulable (i.e., timing requirements are fulfilled).
From a general viewpoint, nothing can be said about communication latencies if messages are
generated in a completely arbitrary way. However, if the message generation pattern is known in
advance (e.g., each message is exchanged periodically), worst-case transmission times can be easily
evaluated. his applies also when message generation processes on different nodes are not coordered
in any way (i.e., different transmission patterns are displaced by arbitrary offsets).
The theory behind such an analysis is not trivial, and has been clearly introduced and thoroughly
explained in several papers [TINa] [TINb] [TIN]. In the following, a simplified approach, first
appeared in , will be described, that provides nevertheless useful results in real-world operating
conditions, particularly for the networked embedded systems typically found in most automotive
applications.
15.3.1 Communication Requirements
The first step for analyzing schedulability in CAN is the exact definition of the set of messages
exchanged by the distributed control application. Let
MS
be this message
set, where
m
i
is the (unique) identifier of the
i
ith message in
MS
.Fromthepointofviewofthe
schedulability analysis, each message
m
={
m
,
m
,...,
m
n
}
(
m
∈
MS
)
is completely described by means of the following
parameters:
•
Period
: Cycle time for periodically exchanged messages. For messages generated
sporadically, instead, it specifies the minimum interarrival time (i.e., the shortest time
between any two consecutive generations of the same message).
•
Deadline
(
T
m
)
: Maximum time for completing the reception of message
m
by the
intended destination node(s). If exceeded, the correct behavior of the control application
is no longer ensured (and safety problems might occur as well); this is clearly a condition
that should never happen in properly operated systems.
•
Jitter
(
D
m
)
: his parameter models all latencies that are not directly caused by the commu-
nication protocol. It mainly depends on the actual implementation of network controllers
and is basically related to hardware overheads. In particular,
J
m
represents the worst-case
delay they may affect message
m
.
•
Size
(
J
m
)
: Specifies the size (in bytes) of the message (or, better, of its payload). In real
applications a message may include one or more signals, each one encoded on several bits.
(
S
m
)
