Image Processing Reference
In-Depth Information
to be known in advance. With respect to schemes based on centralized-polling such as FIP, it is not
necessary to have a node in the network that acts as the bus arbiter, which can become a single point
of failure for the whole system.
All CAN nodes are masters (at least, from the point of view of the MAC mechanism), so it is very
simple for them to notify asynchronous events, such as, for example, alarms or critical error condi-
tions. In all cases where this aspect is important, CAN is clearly better than the above-mentioned
solutions. hanks to the arbitration scheme, no message can be delayed by lower priority exchanges
(this phenomenon is known as priority inversion). Since communication protocols are not preemp-
tive,amessagecanstillbedelayedbyalowerprioritytransmissionwhichhasalreadybeenstarted.
However, as the frame size in CAN is very small (standard frames are -bit long at most, including
stuff bits), the blocking time experienced by very urgent messages is quite low (usually, well below
ms). his makes CAN a very responsive network, which explains why it is used in many real-time
control systems despite its relatively low bandwidth.
When CAN is compared to newer communication solutions, things are a bit different. In spite of
much higher bit rates, which make them suitable for the use in industrial plants and factory automa-
tion environments, industrial Ethernet solutions are not currently employed (or, better, they are not
very popular) in networked embedded systems. his is due to several reasons, including higher costs
and the fact that such solutions are, in many cases, not completely settled yet. In the same way, CAN
proves to be cheaper and much simpler than solutions purposely designed for the use in automo-
tive systems (e.g., in-vehicle networks), such as, for example, FlexRay. here is no doubt that in the
future such technologies will take over CAN in a number of application fields. But, likely, this will
not happen tomorrow and, as stated in [FRE], CAN will remain in use for many years to come.
15.4.2 Drawbacks
There are a number of drawbacks that affect CAN, the most important being related to performance,
determinism, and dependability. hough they were initially considered mostly irrelevant, as the time
elapsedtheyhavebecomemoreandmorelimitinginanumberofapplicationields,e.g.,thoserelated
to the advanced in-vehicle x-by-wire systems found in the automotive domain.
15.4.2.1 Performance
Even though inherently efficient and elegant, the arbitration technique of CAN poses serious limita-
tions on the performance that can be obtained by the network. In fact, in order to grant the correct
behavior of the arbitration mechanism, the signal must be able to propagate from a node located at
oneendofthebusuptothefarthestnode(attheotherend)andcomebacktotheirstnodebefore
this one samples the level on the bus (every node should see the same logical value at any bit time).
Since the sampling point is located (roughly) just before the end of each bit (the exact position can
be programmed by means of suitable registers), the end-to-end propagation delay, also including
hardware delays of couplers, transceivers, and controllers, must be strictly shorter than about half
the bit time (the exact value depending on the bit-timing configuration in the CAN controller and
the actual hardware-induced overheads).
As the propagation speed of signals is fixed (about m
is on copper wires), this implies that
the maximum length allowed for the bus is necessarily limited, and depends directly on the bit rate
chosen for the network. For example, a kbps CAN network can span at most m; similarly,
the maximum bus length allowed when the bit rate is selected as equal to Mbps is less than m.
This, to some degree, explains why the maximum bit rate allowed by the CAN specification [ISO]
has been limited to Mbps.
It is worth noting that this limitation depends on physical factors, and hence it cannot be over-
come in any way by advances in the technology of transceivers (to make a comparison, it should
/
