Controller Area Network (CAN) Schedulability Analysis: Refuted, Revisited and Revised
Controller Area Network (CAN) Schedulability Analysis: Refuted, Revisited and Revised
DOI 10.1007/s11241-007-9012-7
A. Burns
e-mail: [email protected]
R. J. Bril · J. J. Lukkien
Technische Universiteit Eindhoven (TU/e), Den Dolech 2, 5600 AZ Eindhoven, The Netherlands
e-mail: [email protected]
J. J. Lukkien
e-mail: [email protected]
Springer
240 Real-Time Syst (2007) 35:239–272
1 Introduction
1.1 Background
In automotive applications, CAN is typically used to provide high speed networks (500
Kbits/s) connecting chassis and power-train ECUs, for example engine management
and transmission control. It is also used for low speed networks (100 or 125 Kbits/s)
350 32-bit
300 16-bit
8-bit
250
Million units
stand alone
200
150
100
50
0
1999 2000 2001 2002 2003
Year
connecting body and comfort electronics, for example door modules, seat modules and
climate control. Data required by ECUs on different networks is typically gatewayed
between the different CAN buses by a powerful ECU connected to both.
The network architecture of the VW Passat (Leohold, 2005) shown in Fig. 2, re-
produced with permission from Nolte (2006), illustrates how a number of CAN buses
are used to connect around 45 ECUs in that vehicle. Also shown in Fig. 2 are three
Local Interconnect Networks (LIN). LIN is a complementary technology to CAN, and
is used to provide inexpensive, low speed (20 Kbits/s) connectivity (LIN Consortium,
2003).
Table 1 summarises the requirements placed on in-vehicle networks for the BMW
7 Series. This is typical of automotive applications, where individual CAN buses are
used to connect between 2 and 32 ECUs at bandwidths ranging from 100 to 500 Kbits/s
(Frischkorn, 2005).
In automotive applications the messages sent on CAN are used to communicate
state information, referred to as signals, between different ECUs. Examples of signals
include: wheel speeds, oil and water temperature, engine rpm, gear selection, accel-
erator position, dashboard switch positions, climate control settings, window switch
positions, fault codes, diagnostic information and so on. In a high-end vehicle, such as
Springer
242 Real-Time Syst (2007) 35:239–272
No. of
No. of ECUs Bandwidth Messages Cycle times
the VW Phaeton, there can be more than 2500 distinct signals (Leohold, 2004), each
effectively replacing what would, in a traditional point-to-point wiring loom, have
been a separate wire.
Many of these signals have real-time constraints associated with them. For exam-
ple, an ECU reads the position of a switch attached to the brake pedal. This ECU
must send a message over the CAN network, carrying information (a signal) that the
brakes have been applied. The ECU responsible for the rear light clusters receives the
message, recognises the change in the value of the signal, and switches the brake lights
on. All within a few tens of milliseconds of the brake pedal being pressed. Engine,
transmission, and stability control systems typically place even tighter time constraints
on signals, which may need to be sent as frequently as once every 5 milliseconds to
meet their time constraints (Society of Automotive Engineers, 1993).
CAN is a serial data bus that supports priority based message arbitration and non-pre-
emptive message transmission. In the early 1990s, a common misconception about
CAN was that although the protocol was very good at transmitting the highest priority
message with low latency, it was not possible to guarantee that less urgent signals,
carried in lower priority messages, would meet their deadlines.
Tindell and Burns (1994) and Tindell et al. (1994b, 1995) showed how research into
fixed priority pre-emptive scheduling for single processor systems could be adapted
and applied to the scheduling of messages on CAN. This analysis provided a method
of calculating the worst-case response times of all CAN messages. Using this analysis
it became possible to engineer CAN based systems for timing correctness, providing
guarantees that all messages, and the signals that they carry, would meet their deadlines.
Tindell’s seminal research heavily influenced the design of on-chip CAN peripherals
such as Motorola msCAN (Motorola, 1998) and has lead to a large body of work into
schedulability theory and error models for CAN (Punnekkat et al., 2000; Nolte et al.,
2002, 2003; Broster et al., 2002, 2005; Hansson et al., 2002; Broster and Burns,
2003), including at least two PhD theses (Broster, 2003; Nolte, 2006). Overall, this
research into CAN scheduling has been cited in over 2002 subsequent papers.
In 1995, Tindell’s research was recognised by Volvo Car Corporation and success-
fully used in the configuration and analysis of the CAN buses for the forthcoming
2As of August 2006, reference (Tindell and Burns, 1994) has 78 citations, reference (Tindell et al., 1995)
199 citations and reference (Tindell et al., 1994b) 110 citations (Google Scholar).
Springer
Real-Time Syst (2007) 35:239–272 243
A 1 2.5 ms 2.5 ms 1 ms
B 2 3.5 ms 3.25 ms 1 ms
C 3 3.5 ms 3.25 ms 1 ms
Volvo S80 (P23) (Casparsson et al., 1998). Following the success of this project, Vol-
cano Communications Technologies AB3 used Tindell’s analysis as the basis of a
commercial CAN schedulability analysis tool, called Volcano Network Architect.
Since 1998, these tools and the Volcano concept (Casparsson et al., 1998) have
been used in the design and development of CAN networks and electronics systems
for the Volvo XC90, S80, S/V/XC70, S60, V50 and S40 as well as many other cars
from different manufacturers.
Prior to Tindell’s work, low levels of bus utilization, up to 30 or 40%, were typical
in automotive applications, with extensive testing required to obtain confidence that
CAN messages would meet their deadlines. With the advent of a systematic approach
based on schedulability analysis, CAN bus utilization could be increased to around
80% (DeMeis, 2005) whilst still guaranteeing that deadlines would be met.
1.4 Motivation
The design and development of many in vehicle Controller Area Networks relies on
the schedulability analysis of CAN given by Tindell and Burns (1994) and Tindell
et al. (1994b, 1995). In this section we show that this analysis is flawed. It may result
in computed worst-case response times for messages that are optimistic, i.e. less than
the response times that may actually occur. The set of CAN messages listed in Table 2
serve to highlight the problem with the existing schedulability analysis of CAN. As
a simple example, we have assumed a 125 Kbit/s network with 3 messages, each of
which carries 7 bytes of signal data. Assuming 11-bit identifiers and worst-case bit-
stuffing, the maximum length of each message is 125 bits. The maximum transmission
time of each message is therefore 1 ms.
The analysis method given by Tindell and Burns (1994) and Tindell et al. (1994b,
1995) calculates the worst-case response times of messages A, B and C as 2 ms, 3 ms
and 3 ms respectively. Hence the system is deemed to be schedulable—the analysis
supposedly guarantees that all of the messages will meet their deadlines in the worst
case, despite the high bus utilisation of 97%.
Figure 3 illustrates the worst-case scenario for transmission of message C. We note
that the first instance of this message is delayed by higher priority messages A and
Fig. 3 Worst-case scenario for
message C
The schedulability analysis for CAN builds on previous research into fixed priority
scheduling of tasks on single processor systems.
Lehoczky (1990) introduced the concept of a busy period and showed that if tasks
have deadlines greater than their periods, referred to as arbitrary deadlines, then it
is necessary to examine the response times of all invocations of a task falling within
a busy period in order to determine the worst-case response time. Harbour et al.
(1991) showed that if deadlines are less than or equal to periods, but priorities vary
during execution, then again multiple invocations must be inspected to determine the
worst-case response time. We note that non-pre-emptive scheduling is effectively a
special case of pre-emptive scheduling with varying execution priority—as soon as a
task starts to execute its priority is raised to the highest level. Tindell et al. (1994a)
improved upon the work of Lehoczky (1990) providing a formulation for arbitrary
deadline analysis based on a recurrence relation.
Building upon these earlier results, George et al. (1996) provided comprehensive
schedulability analysis of non-pre-emptive fixed priority scheduling of single proces-
sor systems.
Bril (2006) refuted the analysis of fixed priority systems with deferred pre-emption
given by Burns (1994), showing that this analysis may result in computed worst-case
response times that are optimistic. The schedulability analysis for CAN given by
Tindell and Burns (1994) and Tindell et al. (1994b, 1995) builds upon Burns (1994)
and suffers from essentially the same flaw. A similar issue with work on pre-emption
thresholds (Wang and Saksena, 1999) was first identified and corrected by Regehr
(2002).
The revised schedulability analysis presented in this paper aims to provide an
evolutionary improvement upon the analysis of CAN given by Tindell and Burns
(1994) and Tindell et al. (1994b, 1995). To do so, it draws upon the analysis of Tindell
Springer
Real-Time Syst (2007) 35:239–272 245
et al. (1994a) for fixed priority pre-emptive scheduling of systems with arbitrary
deadlines and the analysis of George et al. (1996) for fixed priority non-pre-emptive
systems.
A technical report (Bril et al., 2006a) and a workshop paper (Bril et al., 2006b)
highlighted the problem for CAN but did not provide a specific in-depth solution. That
is the purpose of this paper. A further technical report (Bril et al., 2006c) complements
this paper, providing formal proofs of the worst-case response time of tasks under
fixed priority scheduling with deferred pre-emption.
1.6 Organisation
The remainder of this paper is organised as follows: Section 2 describes the CAN
protocol and terminology before outlining a suitable scheduling model and notation
on which to base revised schedulability analysis. Section 3 provides new schedulability
analysis for CAN, correcting the flaws in the existing approach. Section 4 discusses
the system and message parameters needed for the flaws in the existing analysis to
result in incorrect worst-case response times and hence misleading guarantees. Section
5 discusses the issue of optimal priority assignment for CAN messages. Section 6
summarises the implications of flaws in the existing analysis for commercial CAN
applications. Finally, Section 7 concludes with a summary of the main contributions
of this paper and recommendations for further research.
This section describes elements of the CAN protocol and characteristics of a system
model that are needed to formulate a schedulability test. For a complete description
of the CAN protocol, see the CAN specification version 2.0 (Bosch, 1991)
CAN is an asynchronous multi-master serial data bus that uses Carrier Sense Multiple
Access/Collision Resolution (CSMA/CR) to determine access.
CAN was designed as a simple and robust broadcast bus capable of operating at
speeds of up to 1 Mbit/s. Message transfer over CAN is controlled by 4 different types
of frame: Data frames, Remote Transmit Request (RTR) frames, Overload frames and
Error frames.
The layout of a standard format data frame is shown in Fig. 4. Each CAN data frame
is required to have a unique identifier. Identifiers may be 11-bit (standard format) or
29-bit (extended format). The identifier serves two purposes beyond simply identifying
the message. First, the identifier is used as a priority to determine which message,
among those contending for the bus, will be transmitted next. Second, the identifier
may be used by receivers to filter out messages they are not interested in, and so reduce
the load on the receiver’s host microprocessor.
In this paper we are interested in the schedulability of data frames, with error
frames also considered in Section 3.5. The schedulability analysis can however easily
be extended to include RTR frames using the approach given by Tindell et al. (1995).
The CAN physical layer supports two states termed dominant (‘0’) and recessive (‘1’).
If two or more CAN controllers are transmitting at the same time and at least one of
them transmits a ‘0’ then the value on the bus will be a ‘0’. This mechanism is used
to control access to the bus and also to signal errors.
The CAN protocol calls for nodes to wait until a bus idle period4 is detected before
attempting to transmit. If two or more nodes start to transmit at the same time, then
by monitoring each bit on the bus, each node can determine if it is transmitting the
highest priority message (with a numerically lower identifier) and should continue
or if it should stop transmitting and wait for the next bus idle period before trying
again. As the message identifiers are unique, a node transmitting the last bit of the
identifier field, without detecting a ‘0’ bit that it did not transmit, must be transmitting
the highest priority message that was ready for transmission at the start of arbitration.
This node then continues to transmit the remainder of its message, all other nodes
having backed off.
The requirement for a node to be able to overwrite a recessive bit, and the transmit-
ting node detect this change, limits the combination of physical length and speed of a
CAN bus. The duration of each bit must be sufficient for the signal to propagate the
length of the network. This limits the maximum data rate to 1 Mbit/s for a network up
to 40 m in length or to 125 Kbit/s for a 500 m long network.
The arbitration mechanism employed by CAN means that messages are sent as if
all the nodes on the network shared a single global priority based queue. In effect
messages are sent on the bus according to fixed priority non-pre-emptive scheduling.
The above high level description is a somewhat simplified view of the timing be-
haviour of CAN. CAN does not have a global concept of time, rather each CAN
controller typically has its own clock which, within a tolerance specified by the proto-
col, may drift with respect to the clocks of other nodes. The CAN protocol therefore
requires that nodes re-synchronise on each message transmission. Specifically, ev-
ery node must synchronise to the leading edge of the start of frame bit caused by
whichever node starts to transmit first.
Normally, CAN nodes are only allowed to start transmitting when the bus is idle.
Thus, when the bus is idle beyond the 3-bit inter-frame space and a node starts to
transmit a message beginning with the dominant start of frame bit (‘0’), then all the
other nodes synchronise on the leading edge of this bit and become receivers—i.e.
4 A bus idle period is an interval of arbitrary length comprising only recessive bits and beginning with the
last bit of the inter-frame space—the final 3-bit field shown in Fig. 4.
Springer
Real-Time Syst (2007) 35:239–272 247
they are not permitted to transmit until the bus next becomes idle. In this case any
message that becomes ready for transmission after the leading edge of the start of
frame bit has to wait for the next bus idle period before it can enter into arbitration.
However, to avoid problems due to clock drift, the CAN protocol also specifies that,
if a CAN node has a message ready for transmission and detects a dominant bit at the
3rd bit of the inter-frame space, it will interpret this as a start of frame bit, and with the
next bit, start transmitting its own message with the first bit of the identifier without
first transmitting a start of frame bit and without becoming a receiver.5 Again the
leading edge of the start of frame bit causes a synchronisation. This behaviour ensures
that any messages that become ready for transmission, whilst another message is being
sent on the bus, are entered into the next round of arbitration, irrespective of any within
tolerance clock drift.
CAN was designed as a robust and reliable form of communication for short messages.
Each data frame carries between 0 and 8 bytes of payload data and has a 15-bit Cyclic
Redundancy Check (CRC). The CRC is used by receiving nodes to check for errors in
the transmitted message. If a node detects an error in the transmitted message, which
may be a bit-stuffing error (see Section 2.1.3), a CRC error, a form error in the fixed
part of the message, or an acknowledgement error, then it transmits an error flag. The
error flag consists of 6 bits of the same polarity: ‘000000’ if the node is in the error
active state and ‘111111’ if it is error passive. Transmission of an error flag typically
causes other nodes to also detect an error, leading to transmission of further error flags.
Figure 5 illustrates CAN error frames, for further details see (Bosch, 1991;
Punnekkat et al., 2000). The length of an error frame is between 17 and 31 bits.
Hence each message transmission that is signalled as an error can lead to a maximum
of 31 additional bits6 of error recovery overhead plus re-transmission of the message
itself.
Fig. 5 CAN error frames
As the bit patterns ‘000000’ and ‘111111’ are used to signal errors, it is essential that
these bit patterns are avoided in the variable part of a transmitted message—see Fig. 4.
The CAN protocol therefore requires that a bit of the opposite polarity is inserted by
the transmitter whenever 5 bits of the same polarity are transmitted. This process is
referred to as bit-stuffing, and is reversed by the receiver.
The worst-case scenario for bit-stuffing is shown in Fig. 6. Note that each stuff bit
begins a sequence of 5 bits that is itself subject to bit stuffing.
Stuff bits increase the maximum transmission time of CAN messages. Including
stuff bits and the inter-frame space, the maximum transmission time C m , of a CAN
message m containing sm data bytes is given by:7
g + 8sm − 1
Cm = g + 8sm + 13 + τbit (1)
4
where g is 34 for standard format (11-bit identifiers) or 54 for extended format (29-bit
identifiers), a/bis notation for the floor function, which returns the largest integer
less than or equal to a/b, and τbit is the transmission time for a single bit.
The formula given in Eq. (1) simplifies to:
In this section we describe an appropriate system model and notation that can be
used to analyse worst-case response times of messages on CAN and hence determine
system schedulability.
The system is assumed to comprise a number of nodes (microprocessors) connected
via CAN. Each node is assumed to be capable of ensuring that, at any given time when
arbitration starts, the highest priority message queued at that node is entered into
arbitration.
7This formula corrects a similar one by Tindell and Burns (1994) and Tindell et al. (1994b, 1995) which
does not account for the fact that stuff bits are themselves also subject to bit stuffing.
Springer
Real-Time Syst (2007) 35:239–272 249
The system is assumed to contain a static set of hard real-time messages, each
statically assigned to a node on the network. Each message m has a fixed identifier
and hence a unique priority. As priority uniquely identifies each message, in the
remainder of this paper we will overload m to mean either message m or priority m as
appropriate. Each message has a maximum number of data bytes sm , and a maximum
transmission time C m , given by Eq. (1).
Each message is assumed to be queued by a software task, process or interrupt
handler executing on the host microprocessor. This task is either invoked by, or polls
for, the event and takes a bounded amount of time, between 0 and J m , to queue the
message ready for transmission. J m is referred to as the queuing jitter of the message
and is inherited from the overall response time of the task, including any polling delay.
The event that triggers queuing of the message is assumed to occur with a minimum
inter-arrival time of T m , referred to as the message period. This model supports events
that occur strictly periodically with a period of T m , events that occur sporadically with
a minimum separation of T m , and events that occur only once before the system is
reset, in which case T m is infinite.
Each message has a hard deadline D m , corresponding to the maximum permitted
time from occurrence of the initiating event to the end of successful transmission
of the message, at which time the message data is assumed to be available on the
receiving nodes that require it. Tasks on the receiving nodes may place different
timing requirements on the data, however in such cases we assume that D m is the
tightest such time constraint.
The worst-case response time R m , of a message is defined as the longest time from
the initiating event occurring to the message being received by the nodes that require
it.
A message is said to be schedulable if and only if its worst-case response time is
less than or equal to its deadline (R m ≤ Dm ). The system is schedulable if and only if
all of the messages in the system are schedulable.
Engineers wanting to use the analysis given in Section 3 to analyse CAN based systems
must be careful to ensure that all of the assumptions of the above model hold for their
system.
In particular, it is important that each CAN controller and device driver is capable
of ensuring that, at any given time when arbitration starts, the highest priority message
queued at that node is entered into arbitration. This behaviour is essential if message
transmission is to take place as if there were a single global priority queue and for the
analysis given in Section 3 to be applicable. As noted by Tindell and Burns (1994),
the Philips 82C500 CAN controller cannot in general support this behaviour. Also the
Intel 82527 CAN controller has a feature where messages are entered into arbitration
in slot order rather than identifier order. In this case it is important that messages are
allocated to slots in identifier order to preserve the correct priority based behaviour.
Many on-chip CAN controllers have multiple slots that can be allocated to either
transmit or receive a specific message. For example some Motorola, National Semi-
conductor, Fujitsu and Hitachi on-chip CAN peripherals have 14, 15 or 16 such slots.
Springer
250 Real-Time Syst (2007) 35:239–272
These slots typically have only a single buffer and therefore it is necessary to ensure
that the previous instance of a message has been transmitted before any new data
is written into the buffer, otherwise the previous message will be overwritten and
lost. This behaviour provides an additional constraint on message transmission: the
deadline of each message must be less than or equal to its period (D m ≤ Tm ).
Recall that the worst-case response time of a message is from the occurrence of
the initiating event to the end of successful message reception at the receiving nodes.
As noted by Broster (2003), receiving nodes can access the message following the
end of frame marker and before the 3-bit inter-frame space—see Fig. 4. The analysis
given in the remainder of this paper is slightly pessimistic in that it includes the 3-bit
inter-frame space in the computed worst-case response times. To remove this small
degree of pessimism, it is valid to simply subtract 3τbit from the computed response
time values.
The time constraint of interest to engineers is the overall end-to-end response time
from an initiating event occurring, such as the brake pedal switch closing, to the
corresponding output response, for example the brake lights illuminating. The worst-
case response time of a message represents only part of this overall end-to-end response
time. There is an additional delay to consider, corresponding to the worst-case time
between the message becoming available at the receiving node and the output being
made. Processing of the signal information contained in a message is typically done
either by a task that polls for the message or by an interrupt handler that is triggered
by message reception. The worst-case response time of the receiving task or interrupt
handler, including any polling delay, needs to be added to the worst-case response
time of the message to determine the overall end-to-end response time.
The scheduling model assumed in this paper uses only one time domain, whilst
CAN typically has a separate clock source for each node on the network. To ensure
that the schedulability analysis for a real network does not produce optimistic results,
it is necessary to take clock tolerances into account. This can be achieved by convert-
ing to real-time as follows: for message jitters and bit times on the bus the conversion
to real-time should assume that the node clocks run as slowly as their tolerance al-
lows. Similarly, message periods and deadlines derived from node clocks should be
converted to real-time assuming that the node clocks run as quickly as their tolerance
allows.
Response time analysis for CAN aims to provide a method of calculating the worst-case
response time of each message. These values can then be compared to the message
deadlines to determine if the system is schedulable. Initially we provide analysis
assuming no errors on the CAN bus. This analysis is then extended, in Section 3.5, to
account for errors on the bus.
For systems complying with the scheduling model given in Section 2.2, CAN effec-
tively implements fixed priority non-pre-emptive scheduling of messages. Following
the analysis given by Tindell and Burns (1994) and Tindell et al. (1994b, 1995) the
worst-case response time of a message can be viewed as being made up of three
elements:
Springer
Real-Time Syst (2007) 35:239–272 251
(i) The queuing jitter J m , corresponding to the longest time between the initiating
event and the message being queued, ready to be transmitted on the bus.
(ii) The queuing delay w m , corresponding to the longest time that the message can
remain in the CAN controller slot or device driver queue, before commencing
successful transmission on the bus.
(iii) The transmission time C m , corresponding to the longest time that the message
can take to be transmitted.
The worst-case response time of message m is given by:
R m = Jm + wm + Cm (4)
period. This is in contrast to the simpler definition given by Lehoczky (1990), which
unifies two adjacent busy periods, as we have defined them, and therefore sometimes
results in analysis of more message instances than is strictly necessary.
The worst-case queuing delay for message m occurs for some instance of message
m queued within a priority level-m busy period that starts immediately after the longest
lower priority message begins transmission. This maximal busy period begins with
a so-called critical instant (Liu and Layland, 1973) where message m is queued
simultaneously with all higher priority messages and then each of these higher priority
messages is subsequently queued again after the shortest possible time interval. In the
remainder of this paper whenever we refer to a busy period we mean this maximum
length busy period.
If more than one instance of message m is transmitted during a priority level-m
busy period, then it is necessary to determine the response time of each instance, in
order to find the overall worst-case response time of the message.
Tindell and Burns (1994) and Tindell et al. (1994b, 1995) give the following equation
for the worst-case queuing delay:
wm + Jk + τbit
wm = Bm + Ck (6)
∀k∈hp(m)
Tk
where hp(m) is the set of messages with priorities higher than m, and a/b is notation
for the ceiling function which returns the smallest integer greater than or equal to a/b.
Although wm appears on both sides of Eq. (6), as the right hand side is a monotonic
non-decreasing function of wm , the equation may be solved using the recurrence
relation given below.
wn + Jk + τbit
m
wmn+1 = Bm + Ck (7)
∀k∈hp(m)
Tk
A suitable starting value is wm0 = Bm . The recurrence relation iterates until, either
Jm + wmn+1 + Cm > Dm in which case the message is not schedulable, or wmn+1 = wmn
in which case the worst-case response time of the first instance of the message in the
busy period is given by: Jm + wmn+1 + Cm .
The flaw in the above analysis is that, given the constraint Dm ≤ Tm , it implicitly
assumes that if message m is schedulable, then the priority level-m busy period will
end at or before Tm . We observe that with fixed priority pre-emptive scheduling this
would always be the case, as on completion of transmission of message m no higher
priority message could be awaiting transmission. However, with fixed priority non-
pre-emptive scheduling, a higher priority message can be awaiting transmission when
message m completes transmission, and thus the busy period can extend beyond Tm ,
as shown by the example in Section 1.4.
Springer
Real-Time Syst (2007) 35:239–272 253
The length tm , of the priority level-m busy period is given by the following recur-
rence relation, starting with an initial value of tm0 = Cm , and finishing when tmn+1 = tmn :
tmn + Jk
tmn+1 = Bm + Ck (8)
∀k∈hep(m)
Tk
where hep is the set of messages with priority higher than or equal to m. As the right
hand side is a monotonic non-decreasing function of tm , then the recurrence relation is
guaranteed to converge provided that the bus utilisation Um , for messages of priority
m and higher, is less than 1:
Ck
Um = (9)
T
∀k∈hep(m) k
If tm ≤ Tm − Jm , then the busy period ends at or before the second instance of mes-
sage m is queued. This means that only the first instance of the message is transmitted
during the busy period. The existing analysis calculates the worst-case queuing time
for this instance, via Eq. (7), and hence provides the correct worst-case response time
in this case.
If tm > Tm − Jm , then the existing analysis may give an optimistic worst-case re-
sponse time, depending on whether the first, or a subsequent instance of message m
has the longest response time.
We observe that the analysis presented in appendix A.2 of George et al. (1996)
suggests that tm is the smallest value that is a solution to Eq. (8), however this is not
strictly correct. For the lowest priority message Bm = 0, and so tm = 0 is trivially the
smallest solution when all of the messages have zero jitter. We avoid this problem by
using an initial value of tm0 = Cm .
The number of instances Q m , of message m that become ready for transmission before
the end of the busy period is given by:
tm + Jm
Qm = (10)
Tm
w n + Jk + τbit
m
wmn+1 (q) = Bm + qCm + Ck (11)
∀k∈hp(m)
Tk
Springer
254 Real-Time Syst (2007) 35:239–272
A 1 2.5 ms 2.5 ms 1 ms
B 2 3.5 ms 3.25 ms 1 ms
C 3 3.5 ms 3.25 ms 1 ms
The recurrence relation starts with a value of wm0 (q) = Bm + qCm , and ends when
wmn+1 (q) = wmn (q), or when Jm + wmn+1 (q) − qTm + Cm > Dm in which case the mes-
sage is unschedulable. For values of q > 0 an efficient starting value is given by
wm0 (q) = wm (q − 1) + Cm .
The event initiating instance q of the message occurs at time qTm − Jm relative to
the start of the busy period, so the response time of instance q is given by:
We note that the analysis presented above is also applicable when messages have
deadlines that are greater than their periods, so called arbitrary deadlines. However,
if such timing characteristics are specified then the software device drivers or CAN
controller hardware may need to be capable of buffering more than one instance of
a message. Nm , the number of instances of each message that need to be buffered is
bounded by:
Rm
Nm = (14)
Tm
We observe that the analysis presented by George et al. (1996) effectively uses
Q m = tm /Tm + 1 rather than Q m = tm /Tm . This yields a value which is one
too large when the length of the busy period plus jitter is an integer multiple of the
message period. Although this does not give rise to problems, we prefer the more
efficient formulation given by Eq. (10).
3.3 Example
In Section 1.4 we showed, with the aid of a simple example, how the existing
analysis can provide optimistic worst-case response times and hence flawed guar-
antees that messages will meet their deadlines. We return to this example to illus-
trate how the analysis presented in this paper computes the correct worst-case re-
sponse times. For ease of reference, the table of message parameters is repeated
below.
Using the new analysis, the worst-case response time of message C (m = 3) is
calculated as follows: As there are no lower priority messages, B3 = 0. Starting with
Springer
Real-Time Syst (2007) 35:239–272 255
a value of t30 = C3 = 1, the recurrence relation given by Eq. (8) iterates as follows:
t31 = 3, t32 = 4, t33 = 6, t34 = 7, converging as t35 = t34 = 7. The length of the busy
period is therefore 7.0 ms, and the number of instances of message C that need to be
examined is given by Eq. (10):
7.0
Q3 = =2
3.5
This tells us that there is the possibility that the existing analysis will calculate an
optimistic worst-case response time. The value could, however, still be correct if the
first instance of the message has the longest response time.
Calculation of the response time of the first instance proceeds using Eq. (11):
w30 (0) = 0, w31 (0) = 2, converging as w32 (0) = w31 (0) = 2. Using Eq. (12), we have
R3 (0) = 3, the same response time calculated by the existing analysis.
Moving on to the second instance, w30 (1) = w3 (0) + Cm = 3, w31 (1) = 4, w32 (1) =
5, w33 (1) = 6. At this point computation would normally stop as the response time,
given by J3 + w3 (q) − qT3 + C3 , has reached 3.5 ms which is greater than the message
deadline. However, if we continue iterating, assuming a longer deadline, then the
recurrence relation converges on w34 (1) = w33 (1) = 6 and hence R3 (1) = 3.5 ms. The
worst-case response time of message C is in fact 3.5 ms, as previously illustrated by
Fig. 3 in Section 1.4.
The analysis given in Sections 3.1 and 3.2 corrects a significant flaw in the existing
schedulability analysis for CAN. However, the schedulability test presented is more
complex, potentially requiring the computation of multiple response times.
In this section we present two simpler but more pessimistic schedulability tests.
These tests are “sufficient but not necessary”. By “sufficient” we mean that all systems
deemed to be schedulable by the tests are in fact schedulable, and by “not necessary”
we mean that not all systems deemed to be unschedulable by the tests are in fact
unschedulable.
The schedulability tests given in this section are only applicable given the constraint
that message deadlines do not exceed their periods.
The response time of the first instance of a message in the busy period is given by
Eq. (7). Assuming that this first instance completes transmission before its deadline
and hence before the end of its period, then we have two possibilities to consider.
(i) If the busy period ends before the next instance of message m is queued, then
Eq. (7) gives the correct worst-case response time.
(ii) Alternatively, if the busy period continues beyond the time at which the next
instance of message m is queued, then we must also consider the response time
of the second and any subsequent instances of message m, queued before the end
of the busy period.
First, we derive an upper bound on the maximum length of the interval [sm,q , sm,q+1 ),
between the times, sm,q and sm,q+1 , at which two arbitrary but consecutive instances,
Springer
256 Real-Time Syst (2007) 35:239–272
q and q + 1, of message m start transmission. We then show that this upper bound
is also an upper bound on the queuing delay for instance q + 1, and can therefore be
used as the basis for a sufficient schedulability test.
We assume that:
We observe that at time sm,q , when instance q starts transmission, there can be no
other messages currently being transmitted, and no messages of higher priority than
m awaiting transmission. Thus, an upper bound on the length of the time interval
[sm,q , sm,q+1 ) can be found by making the potentially pessimistic assumption that all
higher priority messages are queued just as instance q starts transmission. The smallest
solution to Eq. (15) provides an upper bound on the length of this interval.
w n + Jk + τbit
m
wmn+1 = Cm + Ck (15)
∀k∈hp(m)
Tk
8 We observe that the queuing delay of the (q + 1)th instance is in fact at least Cm less than the bound given
by Eq. (15). This is because, to be schedulable, instance q must start transmission at least Cm before the
end of its period. As accurate analysis is available, presented in Section 3.2, we do not pursue this potential
improvement in the sufficient analysis further.
Springer
Real-Time Syst (2007) 35:239–272 257
This result suggests a simple sufficient but not necessary schedulability test, formed
by combining Eqs. (7) and (15) into a single equation—Eq. (16).
w n + Jk + τbit
m
wmn+1 = max(Bm , Cm ) + Ck (16)
∀k∈hp(m)
Tk
We observe that the schedulability analysis embodied in Eq. (16) equates to as-
suming that an instance of message m can be subject to blocking; either of Bm , due
to non-pre-emptive transmission of lower priority messages; or of Cm , due to the
non-pre-emptive transmission of the previous instance of message m itself.
A further simplification is to assume that the blocking factor always takes its maxi-
mum possible value. This leads to a further sufficient but not necessary schedulability
test:
wn + Jk + τbit
m
wm = B
n+1 MAX
+ Ck (17)
∀k∈hp(m)
Tk
where B MAX corresponds to the transmission time of the longest possible CAN mes-
sage (8 data bytes), irrespective of the characteristics and priorities of the messages in
the system.9
So far we have assumed that no errors occur on the CAN bus; however, as originally
shown by Tindell and Burns (1994) and Tindell et al. (1994b, 1995), schedulability
analysis of CAN may be extended to include an appropriate error model.
In this paper we consider only a very simple and general error model. We assume
that the maximum number of errors present on the bus in some time interval t is given
by the function F(t). We assume no specific details about this function; save that it is a
monotonic non-decreasing function of t. For a more detailed discussion of appropriate
error models for CAN, see Punnekkat et al. (2000) and Broster et al. (2002, 2005).
We now modify the schedulability equations to account for the error recovery
overhead. The worst-case impact of a single bit error is to cause transmission of an
additional 31 bits of error recovery overhead plus re-transmission of the affected mes-
sage. Only errors affecting message m or higher priority messages can delay message
m from being successfully transmitted. The maximum additional delay caused by the
error recovery mechanism is therefore given by:
9 Tindell et al. (1995) state that the blocking time on CAN is defined as the longest time that a message can
take to be physically transmitted on “the bus”. This simplified view provides a sufficient but not necessary
schedulability test that corresponds to Eq. (17). However, later in Tindell et al. (1995), the blocking term is
described as “the longest time that any lower priority message can occupy the bus”. This description, also
in Tindell and Burns (1994) and Tindell et al. (1994b), results in a flawed schedulability test.
Springer
258 Real-Time Syst (2007) 35:239–272
Revising Eq. (8) to compute the length of the busy period we have:
tmn + Jk
tmn+1 = E m tmn + Bm + Ck (19)
∀k∈hep(m)
Tk
w n + Jk + τbit
m
wmn+1 (q) = E m wmn + Cm + Bm + qCm + Ck (20)
∀k∈hp(m)
Tk
Eq. (20) extends Eq. (11) to account for the error recovery overhead. Note that as
errors can impact the transmission of message m itself, the time interval considered in
calculating the error recovery overhead includes the transmission time of message m
as well as its queuing delay. Eqs. (20), (12) and (13) can be used together to compute
the response time of each message instance q, and hence find the worst-case response
time of each message m in the presence of errors at the maximum rate specified by
the error model.
The sufficient schedulability tests given in Section 3.4 can be similarly modified
via the addition of the term E m (wmn + Cm ) to account for the error recovery overhead.
4 Discussion
In this section we consider various characteristics of CAN systems and discuss whether
flaws in the existing analysis can result in erroneous guarantees under specific circum-
stances that are relevant to real-world systems.
We seek to answer the following questions.
1. Can the existing analysis give faulty guarantees to messages of any priority?
2. If the bus utilization is low, can the existing analysis still result in optimistic response
times?
3. Do error models give sufficient engineering margin for error to account for the flaw
in the analysis?
4. Does the omission of diagnostic messages during normal operation reduce interfer-
ence/blocking enough to ensure that the deadlines of the remaining messages will
be met?
5. Which message guarantees can we be sure are not at risk?
We have found that the existing analysis gives the correct worst-case response times
for the highest priority and the 2nd highest priority message. However; it can compute
Springer
Real-Time Syst (2007) 35:239–272 259
incorrect worst-case response times for messages from the 3rd highest priority to the
lowest priority.
This is illustrated by the example message set constructed below and depicted in
Fig. 7. The example message set consists of;
(i) a high priority message H ;
(ii) a group of n (where n ≥ 1) intermediate priority messages, represented by I ,
which all have the same periods and transmission times;
(iii) a message X with a priority below those messages in group I,which highlights
the flaw in the analysis and
(iv) a group of k (where k ≥ 0) low priority messages represented by L, which all
have the same transmission times.
The transmission times of the messages are C H , C I , C X and C L respectively, with
the constraint that C X > C L .
The low priority messages L, are assumed to have very large periods and no jitter.
These messages contribute only blocking to the response time of message X . (Note
that if there are no lower priority messages, i.e. k = 0, then the example still holds
with C L = 0).
The period of message H is:
TH = (C L + 2C H + 2nC I + C X )/2
TX = (C L + 3C H + 2nC I + 2C X )/2
TI − JI = C L + 2C H + nC I + C X
We now show that under certain conditions message X exhibits the problem with
the existing analysis. The length of the busy period for message X , given by Eq. (8),
is:
t X = C L + 3C H + 2nC I + 2C X = 2TX
Hence, according to Eq. (10), there are two instances of message X in the busy
period. We now compute the response times of these two instances. According to Eq.
(11), and as C X > C L , the queuing delay of the first instance of message X is:
w X (0) = C L + C H + nC I
w X (1) = C L + 3C H + 2nC I + C X
According to Eq. (12), the response times of the two instances are:
R X (0) = C L + C H + nC I + C X
and
Comparing the formulas for R X (0) and R X (1), then, provided that C H > C L , the
response time of the second instance is greater than that of the first. Meaning that
message X exposes the flaw in the existing analysis. (In fact, assuming that D X = TX ,
the second instance of message X is only just schedulable with R X = TX ).
As we can choose an arbitrary number (n ≥ 1) of intermediate priority messages,
and similarly an arbitrary number (k ≥ 0) of lower priority messages, message X may
lie anywhere from the 3rd highest to the lowest priority in a set of messages with
cardinality greater than or equal to 3. We conclude that any message from the lowest
priority to the 3rd highest priority in a set of 3 or more messages can be given an
optimistic response time and therefore a faulty guarantee by the existing analysis.
The example in Section 1.4 has a bus utilisation of 97%. It is interesting to ask if
the existing analysis can yield optimistic worst-case response times for systems with
much lower utilisation.
Returning to the example message set, constructed in Section 4.1, we now consider
how low the utilisation of that message set can be.
To achieve the lowest possible utilisation, we need only consider the contribution
from messages H and X ; as the utilisation of both the intermediate messages I , and
the low priority messages L, tends to zero when their periods are increased to an
Springer
Real-Time Syst (2007) 35:239–272 261
In Section 3.5 we saw how a generalised error model could be included in the revised
schedulability analysis. Bit error rates on CAN are typically very low: 10−11 up to
10−6 depending on environmental conditions (Ferreira et al., 2004). However, errors
do occur and it is therefore appropriate that any commercial application of CAN
schedulability analysis should include at least a simple error model to account for
sporadic errors on the bus. These errors are typically caused by external sources of
Electromagnetic Interference (EMI) such as mobile phones, radar, radio transmitters,
and lightning as well as other possible causes such as switch contacts, and shielding
or wiring faults. As such errors are typically completely uncorrelated with message
Springer
262 Real-Time Syst (2007) 35:239–272
transmission, it is reasonable to assume that any useful error model allows for the
possibility of an error occurring at any given time, and hence the error function F(t) ≥
1 for a time interval of any length t.
Let us now consider the situation where the schedulability analysis given by Tindell
and Burns (1994) and Tindell et al. (1994b, 1995) has been used along with an error
model with F(t) = 1 to determine the schedulability of a system. The recurrence
relation used by the existing analysis is given below:
wn + Jk + τbit
m
wmn+1 = Bm + E m wmn + Cm + Ck (21)
∀k∈hp(m)
Tk
Given that F(t) ≥ 1, then from Eq. (18), the maximum additional delay to message
m due to the error recovery mechanism is always longer than the transmission time of
message m, i.e. E m (t) > Cm . Substituting Cm for E m (t) in Eq. (21) gives:
wn + Jk + τbit
m
wm = Bm + Cm +
n+1
Ck (22)
∀k∈hp(m)
Tk
We note that as E m (t) > Cm , the solution to Eq. (22) cannot be larger than the
solution to Eq. (21).
Recall that Eq. (16) provides a correct sufficient but not necessary schedulability
test for the case where there are no errors on the CAN bus. Comparing Eqs. (22) and
(16), we observe that, as max(Bm , Cm ) ≤ Bm + Cm , the solution to Eq. (16) cannot
be larger than the solution to Eq. (22) and hence cannot be larger than the solution to
Eq. (21). This means that if message m is deemed to be schedulable given the queuing
delay computed by Eq. (21) for the case where there are errors on the bus, then it must
also be schedulable given the queuing delay computed via Eq. (16) for the case where
there are no errors on the bus.
This is an important result. It means that if the existing analysis showed that every
message was schedulable in the presence of any reasonable error model, with F(t) ≥ 1,
then, despite the flaw in the existing analysis, every message is actually guaranteed to
be schedulable when no errors are present. Put another way, the engineering margin for
error provided by the error model is sufficient to account for the error in the analysis.
We observe however, that the robustness of systems analysed using the schedula-
bility analysis given by Tindell and Burns (1994), and Tindell et al. (1994b, 1995)
may not be all that was expected. Flaws in the existing analysis could lead to message
configurations that will miss their deadlines in the presence of errors at a rate within
the parameters of the specified error model, even though we can be sure that they will
not miss their deadlines when no errors are present on the bus.
Many CAN applications allow for 8 data byte diagnostic messages that are not trans-
mitted during the normal mode of operation. These messages are transmitted only
when the system is in diagnostic mode10 and linked to service equipment. In this
section we consider whether the omission of diagnostic messages provides sufficient
10 Typically, all normal mode messages continue to be transmitted during diagnostic mode.
Springer
Real-Time Syst (2007) 35:239–272 263
In this section we consider the circumstances under which the first instance of a
message in the busy period is guaranteed to have the longest response time. Under
these circumstances, despite its flaws, the existing analysis gives correct results.
Assuming that message deadlines do not exceed their periods, then Eq. (16) in
Section 3.4 provides an upper bound on the queuing delay for the second and subse-
quent instances of message m in the busy period. Comparing Eqs. (7) and (16), we
observe that if B m ≥ Cm , then the first instance of message m is guaranteed to have
a response time at least as long as subsequent ones. From the definition of B m given
in Eq. (5), we conclude the following important result: the existing analysis gives the
correct response time for any message where there exists at least one lower priority
message with equal or longer transmission time/message length.
B. This example shows that the priority assignment policies assumed by Tindell and
Burns (1994) and Tindell et al. (1995) to be optimal are not.
George et al. (1996) claimed that deadline monotonic priority assignment is optimal
for non-pre-emptive systems with no jitter, provided that deadlines and execution times
are in the same order i.e. D i < D j implies C i ≤ C j . The proof, given by George et al.
(1996), assumes that “as ∀i, Di ≤ Ti the worst-case response time of any task is found
in its first instance”; however, this assumption is false, as we have seen with the simple
example in Section 1.4, and so the proof is undermined. The theorem may or may not
still be true.
George et al. (1996) also showed that the optimal priority assignment algorithm
devised by Audsley (1991) is applicable to non-pre-emptive systems. In general, Aud-
sley’s algorithm is applicable provided that the worst-case response time of a message:
(i) does not depend upon the specific priority ordering of higher priority messages
and,
(ii) does not get longer if the message is given a higher priority.
Inspection of the various equations presented in this paper shows that both of the
above conditions hold. Neither the length of the queuing delay, nor the length of
the busy period depends upon the specific priority order of higher priority messages.
Similarly, although the blocking term can get larger with increased priority this is
always counteracted by a decrease in interference that is at least as large; hence the
length of the busy period and the length of the queuing delay cannot increase with
increasing message priority. The optimal priority ordering of CAN messages can
therefore be determined using Audsley’s priority assignment algorithm, given below.
Springer
266 Real-Time Syst (2007) 35:239–272
CAN schedulability analysis tools need to take account of the findings presented in
this paper. This will involve checking, and if necessary updating, the analysis they
employ; ensuring that it cannot provide optimistic worst-case response times and
false guarantees.
The sufficient but not necessary schedulability tests given in Section 3.4 provide
a “quick-fix” solution with minimal changes required to the existing analysis. These
tests are however pessimistic and implementing the revised analysis given in Section
3 would potentially lead to a better technical solution.
Whilst “deadline minus jitter” or (D-J)-monotonic priority ordering is still a good
heuristic to use, it is not necessarily the optimal priority assignment policy for CAN.
Implementing priority ordering based upon Audsley’s optimal priority assignment
algorithm would ensure that a schedulable priority ordering is found whenever one
exists.
System Designers configuring commercial CAN applications often take the engineer-
ing approach that all messages in the system should remain schedulable given the
addition of any number of low priority messages that can be used for development
and test purposes. Such analysis based on Tindell and Burns (1994) and Tindell et al.
(1994b, 1995) would assume that every message is subject to the maximum blocking
factor, as per the sufficient schedulability test given by Eq. (17). This schedulability
test computes a correct upper bound on the actual response time of each message,
and so provides a correct guarantee that the configured messages will meet their
deadlines.
Given the flaws in the existing schedulability analysis, it would however be prudent
for System Designers to check the precise details of the analysis used to compute worst-
case response times for their systems. If the analysis used has the potential to compute
Springer
Real-Time Syst (2007) 35:239–272 267
erroneous worst-case response times, then the feasibility of all the CAN configurations
designed, developed and deployed using that analysis should be checked to ensure that
they are in fact schedulable, and robust to errors at the rate specified by the prescribed
error model.
Many deployed CAN systems, for example those in automotive applications, will have
been analysed using the pragmatic engineering approach described in the previous
section. The flaws in the existing analysis cannot lead to a problem with a deployed
system in this case.
Many CAN applications allow for maximum length (8 data byte) diagnostic mes-
sages that are not transmitted during normal operation. Assuming that the existing
analysis deemed the deployed system to be schedulable with these diagnostic mes-
sages present, then Section 4.4 showed that the omission of a single diagnostic message
provides sufficient reduction in interference/blocking to ensure that the flaws in the
existing analysis cannot lead to other messages missing their deadlines during normal
operation.
In Section 4.5 we saw that the existing analysis gives the correct response time for
any message where there is at least one lower priority message with equal or longer
transmission time/message length. Many CAN applications use exclusively 8 data
byte messages as a means of addressing the high ratio of overhead to useful data on
CAN. In this case, the existing analysis is guaranteed to compute correct response
times for all but the lowest priority message.
Even if a message has the potential to be given an erroneous worst-case response
time by the existing analysis, then, unless that message is close to being unschedulable,
the computed worst-case response time is still likely to be the true value. Even if an
optimistic value is computed, then the true value may still be less than the message
deadline. Finally, for a deadline miss to actually happen in a deployed system requires
that the worst-case message phasing occurs, and at that point a number of messages
take close to their maximum transmission times. This requires worst-case or near
worst-case bit stuffing to occur which is, in itself, highly unlikely (Nolte et al., 2002).
Normal practice with commercial CAN configurations is to ensure that the schedu-
lability analysis used includes provision for a plausible error model. In this case,
Section 4.3 showed that such systems are guaranteed to be schedulable when no errors
are present on the CAN bus provided that they were deemed to be schedulable in the
presence of errors by the existing analysis.
We conclude that deadline misses in deployed CAN systems due to flaws in the
existing analysis are extremely unlikely. Any such deadline failures are more likely
to occur due to errors occurring on the bus at a higher rate than that accounted for by
the error model.
We note that embedded CAN-based systems are built to be resilient to some mes-
sages missing their deadlines, and to much simpler forms of error such as wiring faults.
CAN is not used, in its basic form, for safety critical systems due to known issues such
as the “double receive” and “babbling idiot” problems (Rufino et al., 1998; Broster
and Burns, 2003; Rufino, 2002).
Springer
268 Real-Time Syst (2007) 35:239–272
1. The existing analysis can provide optimistic worst-case response times for messages
from the 3rd highest priority to the lowest priority.
2. The existing analysis can lead to broken guarantees and hence deadline misses in
systems with low bus utilisation.
3. Where an error model has been considered, the flaw in the existing analysis is not
sufficient to lead to CAN configurations that will result in missed deadlines when
no errors are present on the bus. The desired robustness to errors may not however
be achieved.
4. The omission of a single maximum length diagnostic message, accounted for by the
existing analysis, reduces interference/blocking enough to ensure that the deadlines
of all the remaining messages are met during normal operation.
5. Despite its flaws, the existing analysis gives the correct response time for any
message where there is at least one lower priority message with the same or longer
transmission time/message length.
We discussed the implications of these results for commercial CAN systems de-
veloped using flawed analysis and provided two simple, sufficient schedulability tests
enabling a “quick-fix” to be made to commercial CAN schedulability analysis tools.
Finally, we showed that neither deadline monotonic nor (D-J)-monotonic priority
assignment is optimal for CAN. Audsley’s priority assignment algorithm is however
optimal for fixed priority non-pre-emptive systems and can be used to obtain a schedu-
lable priority ordering for CAN whenever one exists.
A considerable body of academic work has grown up from Tindell’s seminal analysis
of CAN. The flaws in that original work may have partly undermined some of the
subsequent research built upon it. Authors that have cited the original CAN analysis
in their work are therefore encouraged to check the implications. In particular the
academic work most likely to be affected is that which extends the original analysis
and pushes system schedulability to its limits, for example work on error models.
7.2 Postscript
Volcano Network Architect (VNA) is a commercial CAN design and analysis tool
originally developed by Volcano Communications Technologies AB, and now owned
by Mentor Graphics Corporation. By 2004, over 20 million cars, with an average of
20 ECUs per car, had been programmed using this technology (Oswald, 2004).
Springer
Real-Time Syst (2007) 35:239–272 269
The engineering team responsible for Volcano Network Architect was given early
visibility of this paper, enabling them to check the validity of the schedulability analysis
used in their commercial products.
The analysis provided by Volcano Network Architect was found to be sufficient: it
assumes the longest possible blocking time irrespective of message priority (Horvath,
2006) and therefore computes an upper bound on response times, similar to that given
by the sufficient schedulability tests described in Section 3.4.
Acknowledgments This work was partially funded by the UK EPSRC funded DIRC project, the EU funded
FRESCOR project and the IST-004527 funded ARTIST 2 network of excellence on Embedded Systems
Design.
References
Audsley NC (1991) Optimal priority assignment and feasibility of static priority tasks with arbitrary start
times. Technical Report YCS 164, Dept. Computer Science, University of York, UK
Bosch (1991) CAN Specification version 2.0. Robert Bosch GmbH, Postfach 30 02 40, D-70442 Stuttgart
Bril RJ (2006) Existing worst-case response time analysis of real-time tasks under fixed-priority scheduling
with deferred pre-emption is too optimistic. CS-Report 06-05, Technische Universiteit Eindhoven
(TU/e), The Netherlands
Bril RJ, Lukkien JJ, Davis RI, and Burns A (2006a) Message response time analysis for ideal Controller Area
Network (CAN) refuted. CS-Report 06-19, Technische Universiteit Eindhoven (TU/e), The Nether-
lands.
Bril RJ, Lukkien JJ, Davis RI, Burns A (2006b) Message response time analysis for ideal Controller Area
Network (CAN) refuted. In: Proceedings of the 5th International Workshop on Real-Time Networks
(RTN’06)
Bril RJ, Lukkien JJ, Verhaegh WFJ (2006c) Worst-case response time analysis of real-time tasks under
fixed priority scheduling with deferred preemption revisited. CS Report 06-34, Technische Universiteit
Eindhoven (TU/e), The Netherlands
Broster I (2003) Flexibility in dependable communication. PhD Thesis, Department of Computer Science,
University of York, UK
Broster I, Burns A, Rodrı́guez-Navas G (2002) Probabilistic analysis of CAN with Faults. In: Proceedings
of the 23rd IEEE real-time systems symposium (RTSS’02), pp 269–278
Broster I, Burns A (2003) An analysable bus-guardian for event-triggered communication. In: Proceedings
of the 24th real-time systems symposium. IEEE Computer Society Press, pp 410–419
Broster I, Burns A, Rodriguez-Navas G (2005) Timing analysis of real-time communication under electro-
magnetic interference. Real-Time Systems 30(1–2):55–81
Burns A (1994) Pre-emptive priority based scheduling: An appropriate engineering approach. In: S. Son
(ed), Advances in Real-Time Systems, Prentice-Hall, pp 225–248
Casparsson L, Rajnak A, Tindell K, Malmberg P (1998/1) Volcano—a revolution in on-board communica-
tions. Volvo Technology Report
DeMeis R (2005) Cars sag under weighty wiring. Electronic Times, 10/24/2005
Ferreira J, Oliveira A, Fonseca P, Fonseca JA (2004) An experiment to assess bit error rate in CAN. In:
Proceedings of 3rd international workshop of real-time networks (RTN2004). Cantania, Italy, pp 15–18
Frischkorn H-G (2005) Automotive architecture requirements. In: Proceedings of the summer school on
architectural paradigms for dependable embedded systems. Vienna, Austria,. Vienna University of
Technology, pp 45–74
George L, Rivierre N, Spuri M (1996) Pre-emptive and non-pre-emptive real-time uni-processor scheduling.
Technical Report 2966, Institut National de Recherche et Informatique et en Automatique (INRIA),
France
Hansson H, Nolte T, Norstrom C, Punnekkat S (2002) Integrating reliability and timing analysis of CAN-
based Systems. IEEE Transactions on Industrial Electronics 49(6):1240–1250
Harbour MG, Klein MH, Lehoczky JP (1991) Fixed priority scheduling of periodic tasks with varying
execution priority. In: Proceedings 12th IEEE real-time systems symposium. IEEE Computer Society
Press, pp 116–128
Springer
270 Real-Time Syst (2007) 35:239–272
Springer
Real-Time Syst (2007) 35:239–272 271
Robert I. Davis received a DPhil in Computer Science from the University of York in
1995. Since then he has founded three start-up companies, all of which have succeeded in
transferring real-time systems research into commercial product. At Northern Real-Time
Technologies Ltd. (1995–1997) he was responsible for development of the Volcano CAN
software library. At LiveDevices Ltd. (1997–2001) he was responsible for development of
the Real-Time Architect suite of products, including an OSEK RTOS and schedulability
analysis tools. In 2002, Robert returned to the University of York, and in 2004 he was
involved in setting up a spin out company, Rapita Systems Ltd., aimed at transferring worst-
case execution time analysis technology into industry. Robert is a member of the Real-Time
Systems Research Group at the University of York, and a director of Rapita Systems Ltd.
His research interests include scheduling algorithms and schedulability analysis for real-
time systems.
Alan Burns is head of the Real-Time Systems Research Group at the University of York.
His research interests cover a number of aspects of real-time systems including the as-
sessment of languages for use in the real-time domain, distributed operating systems, the
formal specification of scheduling algorithms and implementation strategies, and the de-
sign of dependable user interfaces to real-time applications. He has authored/co-authored
over 370 papers and 10 books, with a large proportion of them concentrating on real-time
systems and the Ada programming language. Professor Burns has been actively involved in
the creation of the Ravenscar Profile, a subset of Ada’s tasking model, designed to enable
the analysis of real-time programs and their timing properties.
Springer
272 Real-Time Syst (2007) 35:239–272
Reinder J. Bril received a B.Sc. and an M.Sc. (both with honours) from the University
of Twente, and a Ph.D. from the Technische Universiteit Eindhoven, the Netherlands. He
started his professional career in January 1984 at the Delft University of Technology. From
May 1985 until August 2004, he was with Philips, and worked in both Philips Research
as well as Philips’ Business Units. He worked on various topics, including fault tolerance,
formal specifications, software architecture analysis, and dynamic resource management,
and in different application domains, e.g. high-volume electronics consumer products and
(low volume) professional systems. In September 2004, he made a transfer back to the
academic world, to the System Architecture and Networking (SAN) group of the Mathe-
matics and Computer Science department of the Technische Universiteit Eindhoven. His
main research interests are currently in the area of reservation-based resource management
for networked embedded systems with real-time constraints.
Johan J. Lukkien has been head of the System Architecture and Networking Research
group at Eindhoven University of Technology since 2002. He received an M.Sc. and
a Ph.D. from Groningen University in the Netherlands. In 1991, he joined Eindhoven
University, after two years leave at the California Institute of Technology. His research
interests include the design and performance analysis of parallel and distributed systems.
Until 2000 he was involved in large-scale simulations in physics and chemistry. Since 2000,
his research focus has shifted to the application domain of networked resource-constrained
embedded systems. Contributions of the SAN group are in the area of component-based
middleware for resource-constrained devices, distributed co-ordination, Quality of Service
in networked systems and schedulability analysis in real-time systems.
Springer