USING PRIORITY INHERITANCE TECHNIQUES

USING PRIORITY INHERITANCE TECHNIQUES TO OVERRIDE THE SIZE LIMIT OF CAN MESSAGES Cesare Bartolini ∗ Giuseppe Lipari ∗ Lu´ıs Almeida ∗∗

∗

Scuola Superiore Sant’Anna, Pisa, Italy {cbartolini,lipari}@sssup.it ∗∗ IEETA-DETI, Universidade de Aveiro, Aveiro, Portugal [email protected]

Abstract: The CAN bus, highly appreciated for its efficiency and low cost, is widely adopted in many fields, especially where real-time properties are required. However, it is particularly tailored for short data, supporting up to eight data bytes per frame. Larger data entities need to be fragmented so that they can be transferred over the network. Such fragmented messages may experience long delays caused by preemption by higher priority messages, even when these still exhibit slack. This problem has been found in lift control systems in which multiframe CAN messages had to be sent regularly and were also subject to timing constraints. This paper shows how to use current analysis to deduce response times for multi-frame CAN messages and then it proposes using resource management policies in the CAN bus, namely the Priority Inheritance Protocol, to exploit the slack of higher priority messages and reduce those response times. The paper presents several results that show the efficiency of the proposed mechanisms and highlight their benefits and drawbacks. Keywords: CAN bus, embedded system, fixed priority, resource management.

1. INTRODUCTION

Controller Area Network (CAN) is a suitable protocol for several distributed embedded systems applications. Originally developed in the early 80s by Bosch (Bosch GmbH, 1991), aiming at the automotive industry, this protocol gained wide acceptance and today practically all current car manufacturers inlcude CAN in their models. The protocol also expanded into a large number of application domains, from industrial automation to medical equipment, agricultural machinery, robots, building automation, etc. It is, nowadays, one of the most widely used networking protocols within distributed embedded systems, being a mature and well-known technology, with a very low

number of reported failures. It is thus foreseeable that CAN will continue being used for many years. Probably the most attractive features in CAN are its medium bandwidth (up to 1Mbit/s), high efficiency for short data transfers, asynchronous medium access control (CSMA type) with deterministic arbitration based on unique message identifiers that establish the access priority, electrical robustness and its low cost. Not so attractive features are the strong limitation on the maximum data payload (up to 8 bytes), an inverse relationship between maximum bus length and bit-rate (40m at 1Mbit/s), and also the moderate bandwidth, which is also pointed out, in certain applications, as scarce.

Recent experience of the authors in the field of lift control raised the attention to situations in which frequent messages with more than 8 bytes have to be transferred. In such situations, the messages are fragmented into several CAN frames. However, the priority-based arbitration might impose a long total transfer time for each such message, especially those with low-priority, even when the higher priority messages have substantial slack. This paper suggests a simple software-based solution to overcome this problem and send multiframe CAN messages while limiting their total transmission latency, taking advantage of the slack available in higher priority messages. The proposed technique is based on the principle of priority inheritance, which has been successfully used for many years in scheduling tasks with shared resources. Overall, this proposal allows a more efficient use of the CAN bus in the situations referred above. The paper is organized as follows: Section 2 discusses related work and puts the proposal in perspective; Section 3 discusses the basic scenario, including the scheduling model and a summary of the existing timing analysis for CAN; Section 4 shows the timing analysis for multiframe messages still without any specific mechanism; Section 5 shows and discusses the main proposal of the paper; Section 6 shows an illustrative example; Section 7 shows some experimental results and Section 8 presents the conclusion.

2. RELATED WORK Extensive research has been conducted on the CAN bus, including its real-time properties. The arbitration within CAN is priority-based, with priorities set by the frames’ identifiers. Normally, identifiers are static leading to fixed-priority scheduling (Tindell et al., 1995) but several works also proposed reproducing the behavior of dynamic schedulers (Di Natale, 2000), (Pedreiras and Almeida, 2002) and obtain higher bus bandwidth utilization. The fixed-priority scheduling allows analysis of the CAN bus traffic by means of traditional response-time analysis (Joseph and Pandya, 1985), providing an easy way to compute transmission delays over the bus under the assumptions of zero errors and sporadic traffic, i.e., every message has a minimum interarrival time that is never violated. A significant amount of research in this direction has been done by Tindell and Burns, for example in (Tindell et al., 1995), where they also introduced the effects of release jitter following their previous research (Audsley et al., 1993). The impact of errors was also substantially covered, e.g. (Broster, 2003) and (Ferreira et al., 2004), as well as dependability aspects such as consensus (Rufino et al., 1998) and (Lima and

Burns, 2003), and confinement of babbling idiot behavior (Tindell and Hansson, 1995) and (Ferreira et al., 2005). Generally, these issues will not be covered in this work but (Tindell and Hansson, 1995) deserves a special reference for using a similar technique as proposed in this paper, despite for a different purpose. There, a dual priority mechanism is proposed in order to cope with nodes that could start sending high priority frames more often than specified (babbling idiots), leading to possible starvation of lower priority levels. When such situation is detected, correct nodes change their identifiers to a high priority level, allowing them to preempt the babbling interference. In our case, we use a similar technique but with the purpose of enforcing the consecutive transmission of the several frames composing a message. This issue will be revisited later. Curiously, the timing issues related to the transmission of amounts of data larger than a single CAN message can actually carry, to the best of our knowledge, have not been addressed. While a single CAN frame cannot be preempted once its transmission has begun, if a message has to be split into several frames, some higher-priority messages might be released between frames. This can occur for instance when diagnostic information has to be sent across the CAN bus which often exceeds the maximum data length limitation of CAN. Such situations can arise where a CAN bus is used for both control signals (Richardson et al., 2001), (Johansson et al., 2005), usually with high rates and hence short periods, and diagnostic information such as alarm checking and data integrity checks with longer periods. Such heteregeneous use of CAN-based systems provides the benefits of using only a single bus and hence a cost advantage, but creates a more complex situation to analyze in terms of timing due to the large difference in signal periods and data lengths. The analysis proposed in (Tindell et al., 1995) covers the response times of every single frame, but does not provide an overall bus latency for a multi-frame message as a whole. The proposal suggested in this paper is based on the Priority Inheritance Protocol by Sha and Rajkumar (Sha et al., 1990). In this context, transmission of a message over the CAN bus is viewed as a problem of concurrency on a shared resource and the priority inheritance is used to avoid bus preemption during the transmission of multi-frame messages. 3. ANALYTICAL BACKGROUND We consider a network with a certain number of nodes sending messages. For our purposes, knowledge of the number of nodes is unimportant. Messages exchanged between the network nodes

can have any size, bounded only by technical limitations. Since the network is based on a CAN bus, communication can only happen in CAN-compliant packets. We will refer to such packets as frames, and they are limited to 8 data bytes (64 bits) in length.

3.1 General model A message m includes bm data bits plus the CAN overhead, including the message identifier (11 or 29 bits depending on the CAN version) and bitstuffing (Tindell et al., 1995). Given the data length limitation of each frame, sending a message with bm > 64 requires a m number N of frames, with N ≥ b64 . We will denote different frames using a high index (i.e., mn denotes the n-th frame of message m), with the index starting from 1 for the first frame. The n-th individual frame will contain bnm data bits n and have a transmission time of Cm , and the total transmission time for the whole message PN n n is Cm = n=1 Cm . The transmission time Cm n for each frame is a function of bm which can be computed according to (Davis et al., 2007). The bus bandwidth will be denoted with W ; its 1 reverse, τbit = W , is the bit time. A message m will be sent periodically on the network, with a period Tm and release jitter Jm . We assume the message deadline to be equal to its period and referred to the periodic release. Thus, every instance must be completely transmitted before the next instance is released.

3.2 Current analysis If all messages are short enough (bm ≤ 64) then they can be transmitted with a single CAN frame. Previous research (Tindell et al., 1995) has bounded the delay to transmit a single frame on the CAN bus. These bounds were updated recently (Davis et al., 2007) since there are cases in which the worst-case response time does not occur at the synchronous release, despite occuring within the synchronous busy period (Lehoczky, 1990). The busy period of message m will be denoted bpm and can be determined as follows:

bpm = Bm + Jm +

X

k∈hep(m)





bpm + Jk + τbit Ck , Tk

where Bm is the blocking time due to lowerpriority messages and hep(m) denotes the set of messages with priority equal to or higher

than m including m itself. The former expression can be solved through an iterative algorithm as in response-time analysis (Joseph and Pandya, 1985). If bpm ≤ Tm then only one instance of m occurs in the busy period and the usual analysis is sufficient. Otherwise, all Qm instances within l them busy m period must be analyzed with Qm = bp Tm . For each q = 0 . . . Qm − 1, the worst-case interference that the q-th instance of m will suffer is given by Eq. 1 and its response time by Eq. 2.

wm (q) = Bm + qCm + X  wm (q) + Jk + τbit  + Ck Tk

(1)

k∈hp(m)

Rm (q) = Jm + wm (q) − qTm + Cm .

(2)

The worst-case response time of message m with bm ≤ 64 is given by Eq. 3. Rm =

max {Rm (q)}.

(3)

q=0...Q−1

4. MULTI-FRAME MESSAGES Messages longer than 64 bits need a different analysis that takes into account their multiple frames. As a first approach, we will assume that all frames of the same message have the same CAN identifier. Figure 1 shows a possible scenario with the transmission of a long message that is split into three CAN frames. The message suffers an initial blocking by a lower-priority message as well as interference and preemption between frames by higherpriority messages. Each frame will have a different delay with respect to the initial release of the n message, which we will denote with wm . high priority

high priority m1

high priority m2

low priority

m3 time

Total transmission time Message data CAN overhead Preemption points

Fig. 1. Transmission of a long message over a CAN bus The first frame will be sent according to expressions 1 and 2. Subsequent frames might or might not be already queued, depending on the CAN controller and software driver. If the controller has multiple transmission buffers, then each frame will be already queued when the previous one has finished transmission and enters arbitration at once. For this to be true, we also assume that the

software driver keeps the transmission buffers full and that the time needed to enqueue a frame in a transmission buffer is less than the transmission time of the shortest frame in the system. If, on the other hand, the CAN controller has a single transmit buffer (a common situation with older controllers), then a following frame will have to be queued after the previous one has finished. Assuming that this time is longer than the interframe gap, then it is possible that a queued lower priority frame starts transmission right away, thus creating an additional blocking delay between the consecutive frames of the nessage. In this case, the analysis becomes more complex to account for the extra blockings that multi-frame messages can suffer. However, since CAN controllers with multiple transmission buffers are quite common today, many times referred to as full-CAN controllers, and also because their use results in substantial timeliness and efficiency gains, we will not cover the single transmission buffer case in this paper. Therefore, we assume that the frames that follow the first one are already queued when the previous n ones finish transmission. The interference wm for the n-th frame is given by Eq. 4 and it considers the initial blocking that the first frame might have suffered, the transmission time of previous frames in the message together with the higherpriority messages that were enqueued during the process. In this expression, hep(m) is changed to hp(m) because the contribution of message i is now considered outside the summation as a separate addendum.

n wm = Bm +

n−1 X i=1

i Cm +

X

∀j∈hp(m)



 n + Jj + τbit wm Cj Tj

n The response time for frame n is given by Rm = n n Jm + wm + Cm , while the response time for the whole message equals that of its last frame, i.e., N Rm = Rm .

Again, this is accurate when bpm ≤ Tm , only. The busy period computation must now account for all frames of the message as in Eq. 4.

bpm



 bpm + Jj + τbit = Jm +Bm + Cj + Tj j∈hp(m)   bpm + Jm + τbit Cm . (4) + Tm X

In turn, the interference suffered by the n-th frame of the q-th message instance in the busy period is given by Eq. 5.

n wm (q) = Bm + qCm +

+

X

j∈hp(m)



n−1 X

i Cm +

i=1  n wm (q) + Jj + τbit Cj . (5) Tj

This equation accounts for, respectively, the blocking time due to lower-priority messages, the transmission of previous instances of the current message, past frames of the current instance, and the interference by higher-priority messages. The response time for the n-th frame of the q-th instance is given by: n n n Rm (q) = Jm + wm − qTm + Cm ,

Similarly to the previous case, the response for the N whole q-th instance is given by Rm (q) = Rm (q) and the worst-case response time for m is the maximum Rm (q) for all values of q as expressed in Eq. 3. As referred in Section 1, this response time can be rather high because of the preemption caused by higher priority messages. However, if such high priority messages have slack enough to tolerate extra blocking, then it might be desirable to inhibit preemption during the transmission of long messages to reduce their response times. This is the rationale behind the main proposal in this paper, which is presented next.

5. PROPOSAL A possible solution to the problem is very simple and relies on the concept of priority inheritance. The basic idea is to sufficiently raise the priority of messages after the first frame so that other higher-priority messages cannot preempt it. This is equivalent to raising the priority of a task (message in this case) once it has gained access to a shared resource (the CAN bus). For this purpose, we split the space of CAN identifiers into two sets. A lower priority set L, used by the first frame of all messages, which contains the actual messages priorities, thus setting their relative priority, too. Then, a set H with higher priority identifiers is used for all the continuation frames of long messages, i.e., all but the first ones. Notice that the specific allocation of identifiers in H is not significant because no other message can start transmission before the transmission of the previous message ends, given that its first frame has an identifier in L and the continuation frames of the message being transmitted have identifiers in H. This scheme effectively prevents preemption in between the frames of long messages. The CAN transceivers and controllers need not be aware of the additional protocol, which is

done exclusively at a software level. However, it is important that the CAN controller flushes its transmission buffers to the bus according to a configurable order that is independent from the identifiers of the messages placed within the buffers. This is, for example, provided by the CAN controllers from Microchip. With this feature, it is possible to enqueue the frames of a long message in a way that enforces a desired transmission order. Particularly, it is possible to enqueue the first and a second or even third messages in the CAN controller, knowing that the first frame will be the first to enter arbitration, as desired, despite having an identifier with lower priority than that of the other enqueued frames. high priority m1

m2

m3

low priority

time Total transmission time

Message data CAN overhead

Fig. 2. Transmission of a long message over a CAN bus without interruption Figure 2 shows the same scenario depicted in 1) but when the proposed solution is used. Higherpriority messages cannot win bus arbitration once the transmission of the long message has started because of the higher priority identifiers of the continuation frames.

5.1 Non-alternating frames A property of the proposed solution, which arises directly from the selective assignment of identifiers between first and continuation frames, is that it is impossible for the frames of two separate long messages to alternate, i.e., to create a transmission pattern with alternating frames of both messages. The reason is the same as explained above. Once a message starts, the identifiers of all its remaining frames will have a priority higher (they are in H) than the identifiers of the first frames of all other messages (which are in L). This is convenient since such a situation would lead to increase the transmission time of all long messages, unnecessarily. Again, notice that this property does not hold if single transmission buffer CAN controllers are used. In this case, the gap between the transmission of two consecutive frames of the same message might be larger than the minimum interframe gap, allowing other messages to obtain control of the bus. This might result in two messages actually alternating in the transmission of their frames. However, it is guaranteed that no more than two messages will alternate, provided the time needed to enqueue a frame is less than the shortest frame transmission time in the system.

5.2 Latency bounds Using the proposed extension, the upper bound for any message which is sent on the network, independently of its length, can be described using expressions 1 and 2, taking into consideration that Bm =

max {Cj }.

(6)

∀j∈lp(m)

This upper bound is easier to compute than the one in Equation 3, since it considers whole messages instead of separate frames, and it ensures that after a message gains control of the bus, it will be transmitted entirely. Of course, this introduces a potentially longer delay due to blocking on higher-priority messages. For this reason, care must be taken to ensure that high-priority messages will not be overly delayed because of the length of lower-priority messages. However, it is also possible to allow some really critical messages (such as failure alerts) to overcome this problem and still be able to preempt a long message between two subsequent frames. This is very easy, and involves reserving a pool of CAN message identifiers, be it H ′ , with priorities higher than those in H, to transmit such messages. In fact, with a little effort, it is possible to selectively choose which messages will be able to preempt other messages between frames. This is similar to the concept of non-preemption groups introduced in (Davis et al., 2000). Of course, since this technique involves only reordering the frames of a message with higherpriority ones, it won’t affect latencies of lowerpriority messages, whose delay remains the same.

5.3 Overhead Few considerations can be made about the overhead. Sending a single 64-bit frame on the CAN bus introduces an overhead which ranges from approximately 42% to 60%, depending on the CAN version and the bit-stuffing. Table 1 summarizes the possible values. Table 1. Bit overhead for 64 bits of data CAN version 2.0A 2.0B

Bit-stuffing 0 24 0 29

Total size 111 135 131 160

Overhead 42% 53% 51% 60%

In multiple-frame messages, subsequent frames add the same amount of overhead as the first one. This means that the total overhead is approximately proportional to the number of frames. The approximation comes from the data size and the bit-stuffing. Therefore, the overhead percentages remain the same for long messages.

5.4 Fragmentation Since a message is split into several CAN frames, the introduction of some technique for preserving message consistency might be required in some cases, e.g. when an error occurs or when a message can have a variable length. This can be achieved in many ways, and a very simple solution might be to have one byte of the CAN data reserved as an index. This way, messages which cannot exceed 64 bits would still be sent as a single frame with a maximum of 8 significant data bytes, while messages which can exceed 64 bits would be split into chunks of 7 significant data bytes plus one byte containing the progressive number. 5.5 Active error frames The possibility of transmission errors does not expose specific weaknesses of our proposal. When a transmission error occurs, the error frame is issued and an extra delay is introduced, moreso because the frame needs to be retransmitted. If an error occurs during the transmission of a frame beyond the first in a long message, then after the resynchronization of the CAN controllers the transmission will continue from the point it was interrupted. It is impossible that any other message is transmitted immediately after the error, because the frame subject to the error is still the highest-priority CAN frame which is currently queued (any other queued frame must be the first one of any message due to the considerations in Section 5.1), so apart from the extra delay the correctness of the proposed scheme is not broken. In (Tindell et al., 1995) several methodologies are presented to include the impact of errors in the computation of the worst-case response times. We believe that such methods are equally applicable to our proposal just by considering the longer transmission times of messages. 6. EXAMPLE The effect of our proposal can be shown with a simple example. We will consider a CAN bus over which six different messages are sent. The CAN bus in consideration follows the 2.0A standard, so it has an 11-bit identifier; the bandwidth of the bus will be W = 512 Kbits/s. Since the bitstuffing is highly dependent on the content of the message, we will assume a worst-case bit-stuffing. Table 2 shows the structure of the message set. Periods and transmission times are expressed in µs. CAN identifiers also represent the message priorities, with lower numbers for higher priorities. If the second and third frames of message m5 have the same identifier as the first frame, then the resulting response times are shown in Table 3.

Table 2. Message properties Message m1 m2 m3 m4 m5 m6

CAN id 0x7 0x8 0x9 0xA 0xB 0xC

b 64 64 64 48 160 64

C1 265 265 265 226 265 265

T 2000 1600 1800 3000 2600 4000

C2

C3

265

187

Table 3. Response times without priority inheritance Message m1 m2 m3 m4 m5 m6

bp 530 795 1060 1286 4536 5066

Q 1 1 1 1 2 2

R(0) 530 795 1060 1286 2798 2798

R(1)

1936 801

R 530 795 1060 1286 2798 2798

On the other hand, if the priority of message m5 is raised, for example by assigning to the second and third frame a CAN identifier of 0x5, the results are shown in Table 4. Table 4. Response times with priority inheritance Message m1 m2 m3 m4 m5 m6

R(0) 982 1247 1512 1738 2003 2798

R(1)

915 801

R 982 1247 1512 1738 2003 2798

Difference −452 −452 −452 −452 795 0

The table clearly shows that all high-priority messages are delayed by 452 µs, which is the time required to transmit the second and third frame of message m5 . In this example, this is tolerable, since the additional delay does not exceed the periods. However, there is a benefit for message m5 , which now has a response time shorter than its period, thus making the system feasible. It should be noted that, although these are worstcase values, they are close to the actual transmission times (the only variable is the bit-stuffing). If release jitter is added, the effect of raising the priority can be even more notable. Table 5 shows sample values for the release jitters. Table 5. Release jitter Message Jitter

m1 50

m2 300

m3 200

m4 100

m5 500

m6 0

The new values for the upper bounds on the response times are displayed in Table 6. Ra shows the response time when priority is not raised, while Rb shows those with priority inheritance. In this situation, changing the priority of message m5 allows its deadline to be met, however this solution cannot improve the response time of message m6 , which will still miss its deadline. Of course, if any of the higher-priority messages were going to have a response time higher than

Message m1 m2 m3 m4 m5 m6

Ra 580 1095 1260 1386 3298 4536

Rb 1032 1547 1712 2633 2503 4536

Difference −452 −452 −452 −1247 795 0

their period, this solution would not have been applicable. It can be used only if it doesn’t compromise the timing of higher-priority messages.

4000

time (µs)

Table 6. Response times with release jitter

Message 1 Message 2 Message 3 Message 4 Message 5 Message 6

3500 3000 2500 2000 1500 1000 500 0 0

5

10

15

20

25

30

length of m5 (bytes) Fig. 3. Normal transmission times

7. SIMULATION time (µs)

4000

We have extended the previous example with some simulations, to compare the behavior of a CAN system when the proposed solution is used against a situation when the priority of long messages is not raised.

Message 1 Message 2 Message 3 Message 4 Message 5 Message 6

3500 3000 2500 2000 1500 1000 500

7.1 Simulation setup

0 0

The base structure for the testing system is the same presented in Table 2, along with the jitters introduced in Table 5. The length of m5 has been used as the variable parameter, starting from a message of 0 (only a CAN header carrying an empty message), and increasing the message length by 1 byte at a time up to a maximum size of 32 bytes (four CAN frames). No fragmentation method as depicted in Section 5.4 is applied. For each system thus created, the worst-case transmission times for all messages have been computed, both without and with our proposal. 7.2 Simulation results When the priority of the additional frames of m5 is not raised, the results are shown in Figure 3, while Figure 4 shows the same results when those priorities are raised according to the proposal. The plots show the transmission times of the messages as long as they can be transmitted within their period, otherwise they are not shown. As can be expected, until the length does not exceed 8 bytes, the behavior of the two plots is identical. However, when more than one frame is required, the behavior is different: In the first case, the transmission times for higher-priority messages do not change, since they will only be affected by the blocking time of a single frame; in the second case, these times will increase in an almost linear way, because the blocking time they will be subject to increases. The increase is not completely linear, there are some leaps because additional frames also add a new CAN header,

5

10

15

20

25

30

length of m5 (bytes) Fig. 4. Transmission times with raised priority

even if they are used to carry a single bit. Leaps are due to the fact that an increase in the transmission time can lead to additional interference from higher-priority messages, further increasing the total transmission time. The variable bitstuffing adds an extra irregularity in the ramps. It can be seen that, under normal circumstances, the long message would not be schedulable, because as soon as it exceeds 8 bytes (becoming two frames long), it exceeds its period. With priority inheritance, the long message does not exceed its deadline up to 24 bytes long, but m2 and m3 do exceed theirs when m5 is more than 22 bytes long. This means that the length limit for m5 for the five messages to be schedulable is 22 bytes with priority inheritance, and only 8 bytes without. If m6 is included, too, the former limit reduces to 16 bytes, to get a schedulable set. The proposed approach provides an extra level of design flexibility letting the designer trade slack in higher-priority messages for shorter response times of lower-priority long messages. As shown in the case discussed above, this might improve the schedulability of the whole system. On the other hand, if the extra blocking in higher-priority messages is not tolerable, then the proposed nonpreemptive scheme cannot be used but, yet, nonpreemptive groups could still be set up as referred in Section 5.2. In the limit, lower-priority long message must be transmitted using the same identifier to provide preemption between frames.

8. CONCLUSIONS Controller Area Network became a largely disseminated protocol for distributed embedded systems. This is manily due to its good electrical and timing properties, and also with its bandwidth efficiency to convey short data. However, in many practical situations there is the need to transmit both short and long data and it is not convenient to use a different bus for the latter type, thus requiring both types of messages to be conveyed over CAN. This implies fragmentation of long messages, i.e., with more than 8 bytes. However, the transmission of such messages can be preempted several times by higher priority frames, increasing its transmission time. This preemption occurs independently of the slack of the higher priority frames, thus enlarging the transmission time of long messages without a real need. In this paper we provided an analysis for multiframe messages without using any specific mechanism, with all frames of the message sharing the same identifier. Then, we proposed using priority inheritance to enforce a consecutive, nonpreemptive, transmission of all the frames that compose a message. This means increasing the priority of all frames of a message following the first one, whose identifier sets the message priority. The identifier of the following frames is shared within each message. This mechanism can be readily implemented with COTS CAN controllers that have multiple transmission buffers and it increases the design flexibility allowing to trade response time of lowpriority long messages with slack of high-priority messages, potentially resulting in an improvement of the system schedulability. This trade-off is illustrated with an example, and simulations are carried out showing the effectiveness of the proposal. Future work will be focused on providing actual testing with real CAN-based hardware; additionally, heuristics for finding an optimal priority assignment, or an evaluation of the effect of nonpreemption groups on the current proposal might be the source of further research.

REFERENCES Audsley, A.N., A. Burns, M. Richardson and K. Tindell (1993). Applying new scheduling theory to static priority pre-emptive scheduling. Software Engineering Journal 8, 284– 292. Bosch GmbH, R. (1991). CAN specification 2.0. Broster, I. (2003). Flexibility in Dependable Communication. PhD thesis. University of York. Davis, R.I., A. Burns, R.J. Bril and J.J. Lukkien (2007). Controller area network (CAN)

schedulability analysis: Refuted, revisited and revised. Real-time Systems 35(3), 239–272. Davis, R.I., N. Merriam and N. Tracey (2000). How embedded applications using an RTOS can stay within on-chip memory limits. In: Proceedings of the Work in Progress and Industrial Experience Session, Euromicro Conference on Real-Time Systems. Euromicro. Di Natale, M. (2000). Scheduling the CAN bus with earliest deadline techniques. In: Proceedings of the 21st IEEE Real-Time Systems Symposium. IEEE. pp. 259–268. Ferreira, J., A. Oliveira, P. Fonseca and J. Fonseca (2004). An experiment to assess bit error rate in CAN. In: Proc. of RTN 2004 - the 3rd Int. Workshop on Real-Time Networks. Ferreira, J., L. Almeida and J. Fonseca (2005). Bus guardians for CAN: a taxonomy and a comparative study. In: Proc. of WDAS 2005 - Int. Workshop on Dependable Automation Systems. Johansson, K.H., M. T¨orngren and L. Nielsen (2005). Vehicle applications of controller area network. In: Handbook of Networked and Embedded Control Systems. pp. 741–766. Birkhauser. Joseph, M. and P. Pandya (1985). Finding response times in a real-time system. The Computer Journal (British Computer Society) 29(5), 390–395. Lehoczky, J.P. (1990). Fixed priority scheduling of periodic task sets with arbitrary deadlines. In: Proceedings of the 11th IEEE Real-Time Systems Symposium. pp. 201–209. Lima, G. and A. Burns (2003). A consensus protocol for CAN-based systems. In: Proc. of RTSS 2003 - IEEE Symp. on Real-Time Systems. Pedreiras, P. and L. Almeida (2002). EDF message scheduling on controller area network. Computing & Control Engineering Journal pp. 163–170. Richardson, P., L. Sieh and P. Haniak (2001). A real-time control network protocol for embedded systems using controller area network (CAN). In: Proceedings of the IEEE Electronics and Information Technology Conference. IEEE. Rufino, J., P. Verissimo, G. Arroz, C. Almeida and L. Rodigues (1998). Fault-tolerant broadcast in CAN. In: Proc. of FTCS 1998 - IEEE Symp. on Fault-Tolerant Systems. Sha, L., R. Rajkumar and J.P. Lehoczky (1990). Priority inheritance protocols: an approach to real-time synchronization. IEEE Transactions on Computers 39(9), 1175–1185. Tindell, K., A. Burns and A. Wellings (1995). Calculating controller area network (CAN) message response times. Tindell, K. and H. Hansson (1995). Babbling idiots, the dual-priority protocol, and smart can controllers. In: Proc. of 2nd Int. CAN Conference.