Analysing Real-Time Communications: Controller Area Network (CAN) *

Transcription

1 Analysing Real-Tie Counications: Controller Area Network (CAN) * Abstract The increasing use of counication networks in tie critical applications presents engineers with fundaental probles with the deterination of response ties of counicating distributed processes. Although there has been soe work on the analysis of counication protocols, ost of this is for idealised networks. Experience with single processor scheduling analysis has shown that odels which abstract away fro ipleentation details are at best very pessiistic and at worst lead to unschedulable syste being deeed schedulable. In this paper, we derive idealised scheduling analysis for the CAN network, and then study two actual interface chips to see how the analysis can be applied. 1. Introduction K. W. Tindell, H. Hansson A. J. Wellings Departent of Coputer Systes, Departent of Coputer Science, University of Uppsala, Sweden University of York, England One of the fundaental difficulties in engineering hard real-tie systes is the developent of analysis to bound the tiing behaviour of the syste. Much work in recent years has been developing this analysis for a run-tie dispatching algorith known as fixed priority preeptive scheduling. This work has recently addressed the scheduling of essages on shared broadcast buses [6], and in particular token-passing and priority pre-eptive buses. The work akes certain assuptions about the ideal behaviour of the interface between the host processor and the counications adapter for these buses. However, a given ipleentation ay not eet these assuptions, and so recent research has exained a particular bus protocol and ipleentations fro a nuber of different anufacturers. This paper reports on this analysis, and shows how sall differences in the ipleentation of an interface can have draatic effects on the worst-case tiing perforance of essages. The real-tie bus we exaine in this paper is called Controller Area Network (CAN) [1]. In particular we exaine in detail two interface chips: the controller fro Intel, and the 82C200 controller fro Philips. We show how the Intel controller has a very * This work was supported in part by the U.K. EPSRC, grant nuber 06R00456 Departent of Coputer Systes, P.O. Box 325, S Uppsala, Sweden (E-ail: ken@docs.uu.se) uch better worst-case tiing perforance than the Philips controller. CAN is a broadcast bus designed to operate at speeds of up to 1 Mbit/sec. Data is transitted in essages containing between 0 and 8 bytes of data. An 11 bit nuber is associated with each essage. The identifier is required to be unique, in the sense that two siultaneously active essages originating fro different sources ust have distinct identifiers (typically, an identifier corresponds to a particular type of essage fro a specific source). The identifier serves two purposes: (1) assigning a priority to the essage, and (2) enabling receivers to filter essages. A station filters essages by only receiving essages with particular bit patterns (typically using coparitors and ask registers). Thus CAN essages have no explicit destination, since any station with an appropriate filter ay receive a essage. The use of the identifier as priority is the ost iportant part of CAN with respect to real-tie perforance. Like Ethernet, CAN is a collision-detect broadcast bus, but takes a uch ore systeatic approach to contention. The identifier field of a CAN essage is used to control access to the bus after collisions by taking advantage of certain electrical characteristics of a CAN bus: if ultiple stations are transitting concurrently and one station transits a 0, then all stations onitoring the bus will see a 0. Conversely, only if all stations transit a 1 will all processors onitoring the bus see a 1. In effect, the CAN bus acts like a large AND-gate, with each station able to see the output of the gate. This behaviour is used to resolve collisions: each station waits until bus idle (as with Ethernet). When silence is detected, each station begins to transit the highest priority essage held in its output queue whilst onitoring the bus. The identifier is the first part of the essage to be transitted; the identifier is transitted fro ost-significant to least-significant bit. If a station transits a recessive bit ( 1 ), but onitors the bus and sees a doinant bit ( 0 ), then it stops transitting since it knows that the essage it is transitting is not the highest priority essage in the syste. Because identifiers are deeed unique within the syste, a station transitting the last bit of the identifier without detecting a collision ust be transitting the highest priority

2 queued essage, and hence can start transitting the body of the essage. The CAN essage forat contains 47 bits of protocol control inforation (the identifier, CRC data, acknowledgeent and synchronisation bits, etc.). The data transission uses a bit stuffing protocol which inserts a stuff bit after five consecutive bits of the sae value. Because the nuber of inserted stuff bits depends on the bit pattern of a essage, a given essage type can vary in size, e.g. a CAN essage with 8 bytes of data (and 47 control bits) is transitted with between 0 and 19 stuff bits. 2. Counications odel & notation We define a essage to be either a data essage, or a reote transission request essage. A essage has a size (between zero and eight bytes), and an identifier (as described earlier). The set of all essages in the syste is denoted essages. In a typical syste, a essage is queued by an application task. We assue that each task is invoked repeatedly (a task is said to have arrived when invoked by soe action). Each task has a iniu inter-arrival tie tered the period. Note that the period is a iniu tie between subsequent arrivals, rather than a strict fixed interval. If the essage queued by a given task is potentially sent each tie the task is invoked, then the essage inherits a period equal to the period of the task. We denote as T the period of a given essage. A given task i has a worst-case response tie, denoted R i, which is defined as the longest tie between the arrival of a task and the tie it copletes soe bounded aount of coputation. Existing analysis for single processors is able to deterine this worst-case response tie. In general, the queuing of a essage can occur with jitter [2] (variability in queuing ties). Correct analysis requires that jitter be taken into account. Queuing jitter can be defined as the difference between the earliest and latest possible ties a given essage can be queued. As with the period, the jitter of a given essage ay be inherited fro the sender task. For an application task i (with worst-case response tie R i ) sending essage, this queuing window is no ore than R i in duration (i.e. the difference between the earliest and latest queuing ties of the essage). The jitter of a given essage is denoted J. In any realistic syste all essages will have soe queuing jitter. The worst-case response tie of a given essage is denoted R and defined as the longest tie taken for the essage to reach the destination stations, easured relative to the arrival tie of the sender task. The longest tie taken to transit a given essage we denote as C. For an eight byte essage (the largest essage peritted with CAN) transitted on a 1 Mbit/sec network, C is 130s (64 bits for the data, 47 bits of overhead CRC and identifier fields, etc. and up to 19 stuff bits). Figure 1 illustrates the tiing of a CAN essage. J R T C Figure 1: Tiing odel for CAN essages 3. Basic processor scheduling theory Scheduling essages on a CAN bus is analogous to scheduling tasks by fixed priorities. It is possible to take existing analysis and apply it to CAN essages. We therefore take a brief detour into scheduling theory for fixed priority scheduling of tasks on a single processor. Audsley et al [2] and Burns et al [3] show how the analysis of Joseph and Pandya [4] can be updated to include blocking factors introduced by periods of non-preeption, release jitter, and accurately take account of a task being non-pre-eptive for an interval before terination. The following equations represent this analysis: Ri = Ji + wi + Ci (1) where w i is given by: w i n + 1 w + J + = Bi + τ j hp( i) T j i n j res C Where hp(i) is the set of tasks of higher priority than task i, C i is the worst-case coputation tie required by a given task i, and T j is the period of a given task j. B i is the blocking factor of task i (a bound on the tie that a lower priority task can execute and prevent the execution of task i); the priority ceiling protocol [5] controls this priority inversion and defines how B i can be coputed. t res is the resolution with which we easure tie. On CAN bus we deal with tie units as ultiples of the bit-tie, which we denote as t bit ; with a 1 Mbit/sec bus this is equal to 1 s. J i is the release jitter of task i, analogous to the queuing jitter of a essage. Note that if a task is invoked by an incoing essage, then the task inherits a release jitter (and period) fro the essage (in just the sae way as a essage inherits a queuing jitter fro a sending task); this is known as attribute inheritance, and leads to an approach known as holistic scheduling (see [7] for a full treatent). The feasibility of a given task can be trivially assessed by coparing the worst-case response tie of the task against its deadline. Note that the deadline of a given task i, denoted D i is assued to be less than or equal to T i. Another assuption is that a task cannot voluntarily j (2)

3 suspend itself (and hence the processor cannot be idle when tasks have work to do). Equation 2 describes a recurrence relation, where the (n + 1)th approxiation to the value of w i is found in ters of the nth approxiation, with the first approxiation set to zero. A solution is reached when the (n + 1)th approxiation equals the nth. Having introduced this analysis we can apply it to CAN bus scheduling. We do this by first deriving ideal CAN analysis, and then discussing how the analysis is affected by the behaviour of ipleented hardware. We discuss two ipleented CAN controllers: the Intel and the Philips 82C Analysis for ideal CAN In this section we will derive scheduling analysis to bound the worst-case response tie of a given essage. The analysis of the previous section can be applied to ideal CAN by the analogy between task scheduling and essage scheduling: a task is released at soe tie (i.e. is placed in a priority-ordered queue of runnable tasks), and contends with other tasks (both lower and higher priority tasks) until it becoes the highest priority runnable task. Because of the operation of the priority ceiling protocol, a task need only contend with at ost one lower priority task. In addition, it contends with all higher priority tasks until these have all copleted and the processor is freed. With the odel of Burns et al [3], the task is then dispatched and runs until copletion. Upon copletion it is returned to the waiting queue until next ade runnable. The sae behaviour holds for CAN essages: a essage is queued at soe tie, and contends with other essages until it becoes the highest priority essage. It coences transission, and is transitted without interruption until copletion. Note that this assues that the bus cannot becoe idle between the transission of essages if there are pending essages (this is analogous to the assuption that a task ust not voluntarily suspend itself). This assuption does not hold with the Philips 82C200 controller, and we exaine the raifications of this in section 6. The worst-case response tie of a queued data essage, easured fro the arrival of the queuing task to the tie the essage is fully transitted, is given fro the analogy (equation 1) by: R = J + w + C (3) J is the queuing jitter of essage, inherited fro the worst-case response tie R sender() (where sender() denotes the task queuing essage ). The ter w represents the worst-case queuing delay the longest tie between placing the essage in a priority-ordered queue, and the essage coencing transission. By analogy with equation 2: w = B + j hp( ) w + J + τ j bit T j C where the ter B is the worst-case blocking tie of essage, and is analogous to the blocking factor defined by the analysis of the priority ceiling protocol. B is equal to the longest tie taken to transit a lower priority essage, and given by: B = ax k lp( ) ( C ) k lp() is the set of essages in the syste of lower priority than essage. If is the lowest priority essage then B is zero (just as the lowest priority task has a blocking factor of zero with the priority ceiling protocol). t bit is the tie taken to transit a bit on the bus and hp() is the set of essages in the syste of higher priority than essage. C is the longest tie taken to transit essage. As entioned earlier, CAN has a 47 bit overhead per essage, and a stuff width of 5 bits. Only 34 of the 47 bits of overhead are subject to stuffing, so C can be defined by: C 34+ 8s = 5 j (4) (5) s bit τ (6) where s is the nuber of data bytes in the essage. Equation 4 above can be solved in the sae way as equation 2. We next exaine how the analysis copes with the ipleentation details of different controllers, starting with the Intel Real-tie behaviour of the The queuing of essages in the Intel is undertaken in the controller and interfaced to the host processor via dual-ported RAM. The intention is to ap peranently essage identifiers to eory locations (tered slots), so that both outgoing and desired incoing essages are assigned unique slots. A slot is tagged with a essage identifier, and arked as an incoing or outgoing slot. If a essage is received with the sae identifier as a slot arked as incoing then the essage contents are stored in that slot (the slot also contains an interrupt enable flag so that an interrupt can be raised when the essage arrives). If the host processor wishes to initiate the transission of the essage then it is able to ark the essage as ready for transission.

4 Because of hardware liitations, only 15 slots are available for outgoing and incoing essages (instead of the ideal 2032 the full range of CAN identifiers). However, these 15 slots can be prograed to ap to any CAN identifier. The controller will transit essages in order of slot nuber, rather than the essage identifier, and therefore it is iportant that the essages are allocated to the slots in identifier order. It should be noted that in ost envisaged autootive systes, 15 essages per station is sufficient [8]. There is also a dedicated double-buffered receive buffer: when a essage has been received in the controller without errors, a essage received interrupt ay be raised on the host processor. If the identifier of the essage does not atch the identifier in one of the slots in the controller then the interrupt handler ust copy the contents of the essage fro the buffer and store it in ain eory. The handler then issues a reoved essage signal to the controller, indicating that the receive buffer is free. This is needed because the receive buffer is double buffered: while the host processor is reoving data fro one buffer, the controller ay be placing data in the other buffer. The controller needs to synchronise with the host processor in order to place data in a free buffer. There is an iplicit deadline on handling the essage received interrupt: if the host processor fails to reove the data and signal reoved essage before the controller has received the subsequent essage then any further incoing essages ay be lost (the sallest tie between two successive essages is 47 t bit ). In any ways the dual-ported eory approach is an elegant way of ipleenting a controller, but one drawback is that there is an iplicit restriction on essage deadlines: a essage cannot be queued if the previous queuing of the sae essage has not yet been transitted. Therefore, we ust have D T (an assuption also ade by the scheduling analysis in this paper). Apart fro the liitations discussed, the Intel controller behaves as an ideal CAN controller with respect to the analysis derived in this paper. 6. Real-Tie behaviour of the 82C200 In this section we discuss the behaviour of the Philips 82C200 CAN controller, and show its worst-case realtie properties are poor (space liitations preclude the developent of analysis for this controller). The Philips controller is a siple controller, with two essage buffers on-chip: a single 10 byte transission buffer, and a 10 byte double-buffered receive buffer. The controller is typically interfaced to the processor as a eory apped I/O device, and can raise two interrupts: essage received, and essage sent. The controller accepts three signals fro the host processor: send essage, abort essage, and reoved essage. The controller requires essages to be held on the host processor, and software drivers to copy the essages fro the processor to the controller when appropriate. To send a essage, the host processor fills the transit buffer with up to eight bytes of data, the identifier of the essage, and soe control bits, and then sends a transit essage signal to the controller. We denote the longest tie to do this as t copy. The controller attepts to transit the essage according to the CAN protocol; when the essage has been sent, a essage sent interrupt is raised on the host processor. The reception of essages is very siilar to the Intel controller: when a essage has been received in the controller without errors a essage received interrupt is raised on the host processor and the interrupt handler ust copy the 10 bytes of essage data fro the controller and store it in ain eory. The signal abort essage is to aid in the writing of software device drivers for pre-eptive queuing. Without the signal, the real-tie perforance of the controller would be very poor indeed. Consider the situation where there is a low priority essage in the transit buffer of the controller, and a high priority essage has just been queued by the host processor software. If the host processor were unable to reove the low priority essage, then the high priority essage would blocked until the low priority essage is sent. The low priority essage will only be sent when all other higher priority traffic on the bus has finished; this could be very long. Instead of succubing to this proble, the device driver should abort the transission of the low priority essage, and copy the high priority essage to the transit buffer. The controller will only abort the essage if it has not yet begun transission. This is a sensible approach, since if the low priority essage has begun transission then there will be only a short delay (equal to the transission tie of the essage) before the transission buffer is freed. There reains a ajor proble with the anageent of the transission buffer: the tie between essage sent and the host processor copying the next essage to the transit buffer is non-zero (although short if the host processor is fast). In this short interval the bus could be claied by a low priority essage fro another station and defer the transission of the newly copied essage. This proble also occurs when a essage is pre-epted: the short interval between a lower priority essage being aborted, and the higher priority essage being copied into the buffer, releases the bus to low priority traffic. For every pre-eption (i.e. when a essage is aborted, and replaced by a higher priority essage) in an interval, The software drivers supplied by Motorola for the 82C200 appear to exhibit this priority inversion proble.

5 the bus ay potentially be claied twice by lower priority traffic at other stations: once when the higher priority essage pre-epts, and once when the essage has been transitted. To illustrate this, consider the following scenario: a essage M is to be sent fro a given station. Also sent fro this station are a high priority essage H and a low priority essage L1. Other stations also have low priority traffic to send (essages L2, L3, and L4). In this scenario, essage M can be delayed four ties by lower priority essages whilst being pre-epted just once. This is solely a result of the buffer anageent echanis. The first delay occurs when essage M is queued: as entioned earlier, the 82C200 controller is not able to abort a essage if the essage has begun transission. Therefore essage M can be delayed by L1. After the essage has been sent, the host processor copies essage M to the transission buffer (taking at ost t copy ). In this tie the bus is released and ay becoe idle, or ay be claied by lower priority essages fro other stations. When essage M has been copied to the buffer, and is ready for transission, it ay be delayed by a lower priority essage that has just started transission fro another station (L2). Just before essage M starts transitting, a higher priority essage H can pre-ept M: the 82C200 controller aborts essage M, and copies the higher priority essage to the transission buffer. Again, the bus is released, and again lower priority essage can be transitted (L3), delaying both essage H and essage M. When essage H has been transitted the host processor copies essage M back to the transission buffer. Again, the bus is released, and again essage M can be delayed (by L4). It is straightforward to bound the delays due to this priority inversion, and the delays due to copying essages. This priority inversion can be very large, and lead to very poor worst-case perforance of the controller. The following table details a set of essages based on the above scenario. They confor to the rate onotonic odel of deadlines equal to periods. Message T D C util n H % M % L % L % L % L % In the above table, all ties are in icroseconds. Messages are assued to be queued with zero jitter. A sall value for t copy is assued: large enough to release the bus to lower priority essages when copying a essage to the transission buffer, but not large enough to for a significant part of the response tie of a essage (in practice, such a sall value would be unattainable). The exaple essage set is unschedulable: in the scenario described, we find that the response tie of essage M is 614 s. The bus utilisation in this exaple is just under 16%. By coparison, the worst-case response tie of M with the Intel controller is 224 s. It is possible to find unschedulable scenarios with bus utilisations as low as 11%. Clearly using the Philips controller could lead to very poor resource utilisation. Note that in the situation where there is a large aount of low priority soft real-tie traffic on the bus, the ipact of higher priority traffic on lower priority traffic sent fro the sae station is at least trebled when copared to the ideal CAN behaviour (and when copared to the behaviour of the Intel 82527), and that worst-case response ties will therefore be very uch larger. 7. Conclusions This paper has derived scheduling analysis for the CAN counication protocol. In particular, it has bounded essage response ties for ideal behaviour. It has shown that this ideal odel can be inadequate, and that it is necessary to consider the actual behaviour of the controller technology. Two controllers have been considered: the Intel and the Philips 82C200. The Intel controller perfors ideally, whereas the Philips controller potentially leads to a large aount of priority inversion (and hence requires the ideal analysis to be updated). This paper has considered only essage delivery, but another aspect of real-tie counication is the processing overheads incurred when sending and receiving essage. Analysis bounding such overheads can be developed (see Tindell et al [6] for a full discussion). 8. References [1] Road Vehicles Interchange of Digital Inforation Controller Area Network (CAN) for High Speed Counication, ISO/DIS (Feb. 1992). [2] Audsley, N., Burns, A., Richardson, M., Tindell, K. and Wellings, A., Applying New Scheduling Theory to Static Priority Pre-eptive Scheduling, Software Engineering Journal 8(5), pp (Sept. 1993). [3] Burns, A., Nicholson, M., Tindell, K. and Zhang, N. Allocating and Scheduling Hard Real-Tie Tasks on a Point-to-Point Distributed Syste, Proc. Workshop on Parallel and Dist. Real-Tie Syst., pp (Apr. 1993) [4] Joseph, M. and Pandya, P., Finding Response Ties in a Real-Tie Syste, Coputer J. 29(5), pp (Oct. 1986) [5] Sha, L., Lehoczky, J. P., Rajkuar, R., Priority Inheritance Protocols: An Approach to Real-Tie Synchronization, IEEE Trans. on Coputers, 39(9), pp (Sept. 1990)

6 [6] Tindell, K., Analysis of Hard Real-Tie Counications, YCS 222, Dept. Coputer Science, Univ. of York (1994) (to appear in Real-Tie Systes) [7] Tindell, K., and Clark, J., Holistic schedulability analysis for distributed hard real-tie systes, Microprocessing and Microprograing, 40(2-3), pp (Apr. 1994) [8] Tindell, K., Burns, A., Guaranteed Message Latencies for Distributed Safety Critical Hard Real-Tie Networks, YCS 229, Dept. Coputer Science, Univ. of York (1994).