Improving Information Throughput and
Transmission Predictability in Controller Area
Networks
Imran Sheikh and Musharraf Hanif
Embedded Systems Laboratory
Engineering Department
University of Leicester, UK, LE1 7RH.
Email: si52,mah26@le.ac.uk
Abstract—The Controller Area Network (CAN) protocol was
originally developed for distributed automotive applications in
the 1980s, and has previously proved to be extremely popular for
the implementation of low-cost distributed systems. Whilst CAN
has many features that make it suitable for such applications,
it also has a number of well-discussed drawbacks; data trans-
mission is limited to a fixed 8-byte payload at 1 Mbps, and the
hardware bit-stuffing mechanism and automatic retransmission
scheme can act to severely decrease the predictability of a CAN
network. This paper will describe a modified CAN-like protocol
controller that can be implemented on a programmable-logic
device such as an FPGA. The modified protocol controller can
help to ameliorate one of the drawbacks of CAN, whilst operating
as closely as is possible to the original protocol specification.
Specifically, this paper will discuss an implementation of a simple
extension to the original protocol that allows for larger payloads,
coupled with modifications to the bit-stuffing mechanism to
increase predictability. The effectiveness of this modified CAN
controller is illustrated in a series of experiments employing
a novel test facility. The paper also discusses the potential
drawbacks of the new controller, and is then concluded by
suggesting possible areas of further research.
I. I NTRODUCTION
This paper is concerned with the implementation of dis-
tributed embedded systems where predictable timing be-
haviour and high information throughput are key system
requirements. The Controller Area Network (CAN) protocol
[1] has previously proved to be extremely popular for the
implementation of low-cost distributed systems that require
predictable timing behaviour. Whilst CAN has a number of
beneficial features - such as comparatively low overheads, non-
destructive priority-based message arbitration, low message
latency and good error detecting abilities-it also has a number
of well-discussed drawbacks. These drawbacks include (but
are not limited too) predictability and replica-determinism
issues, information throughput restrictions, and variability in
message transmission times due to bit-stuffing.
Although many modification to the CAN protocol have
previously been reported to help overcome these drawbacks
this will discussed in more depth in section 2 - many of these
techniques can be complex to implement, place measurable
978-1-4244-6392-3/10/$26.00 ©2010 IEEE
Michael Short
Control & Electronics Group
University of Teeside
Middlesborough, UK.
Email: m.short@tees.ac.uk
CPU loads in a given system, and cannot be implemented
without changes at the hardware level. Additionally, with
the evolution of mechatronic technology, in many situations
the increased complexity and distribution of modern control
system requirements also dictates a need for high-bandwidth
networks, capable of delivering information throughput at a
level that is not directly achievable with CAN, or any software-
based protocol to be employed with its standard hardware.
This paper will describe a modified CAN-like protocol
controller that can be implemented on a programmable-logic
device such as an FPGA. The modified protocol controller can
help to ameliorate many of these drawbacks inherent in CAN,
whilst operating as closely as is possible to the original
protocol specification. It is suitable for use in distributed
and embedded systems which require one (or more) of the
following features:
1) The modified protocol controller can be operated, if
desired, as a fully-conformant, standard CAN controller;
2) One or more messages can be sent with a fixed (and
hence predictable) transmission time regardless of the
payload contents;
3) One or more messages can carry a payload of up to 1024
bytes;
4) The bit-rate of one or more messages can be dynamically
increased to up to 10 Mbps during data transmissions,
whilst maintaining the priority-based arbitration scheme;
The remainder of this paper is organised as follows. Section
2 reviews previous related work that has been performed with
CAN in this area. Section 3 builds on this discussion, and
proposes an enhancements to the CAN protocol to achieve
the additional features as listed above. Section 4 describes
the implementation of this modified CAN controller on an
FPGA platform and a case-study that have been performed to
assess the performance of the new controller, using a novel
test-facility. Section 5 discusses the results of the case study
presented in section 4 and section 6 will discuss the benefits -
and drawbacks - of the enhanced protocol and concludes the
paper.
1736

Fig. 1. Software Bit Stuffing
II. P REVIOUS RELATED WORK ON CAN
Controller Area Network is one of the most widely em-
ployed protocols for creating distributed embedded systems,
with applications as far ranging as vehicle electronics, pro-
cess control and many other important industrial applications.
Traditionally, the use of CAN was mostly restricted to non-
critical, event-triggered and soft real-time applications [2], for
example vehicle body electronics and industrial applications
in which allocation of message priorities, bandwidth and
transmission jitter are trivial requirement. This is perhaps
due to the fact that the CAN protocol suffers from several
significant drawbacks with respect to hard real-time systems.
This section will consider some of the previous work that
has been done to ameliorate the effects of bit stuffing on the
predictability of CAN message lengths and transmission times.
A. Bit stuffing and transmission jitter
CAN uses a Non Return to Zero (NRZ) coding technique.
and includes a bit-stuffing mechanism. In order to provide an
effective mechanism for clock synchronization with such an
encoding scheme, a bit-stuffing mechanism is also employed.
When 5 or more consecutive bits of the same polarity are to
be transmitted, a stuff bit of the opposite polarity is inserted
by the transmitting hardware, and subsequently removed by
the receiver hardware. Although this mechanism is effectively
transparent to the application software, a side-effect is that it
causes the total CAN frame length i.e. the number of bits
actually transmitted to become (in part) a complex function
of the data contents. For example, a CAN 2.0A message
with 11-bit identifier and 8-bytes of data, the minimum and
maximum message lengths are 111 and 135 bits respectively.
This translates to a possible variation in transmission time
(jitter) of approximately 22% of the total message length. It
has previously been argued that the bit-stuffing inducement
of message transmission jitter at these levels can lead to
detrimental behaviour, even in statically-scheduled real-time
systems ([3], [4], [5]). Additionally, since message jitter is
cumulative for successively transmitted frames, in non-idling
priority driven systems, low priority messages can suffer from
largely unacceptable jitter magnitudes.
Several software-based protocols to help ameliorate this
phenomenon have previously been proposed. Nolte and col-
leagues ([3], [6]) described a simple scheme based on applying
1737
an XOR mask to the transmitted data, which is subsequently
re-applied by the receivers to recover the original frame.
Although the original results seemed to indicate a measurable
reduction in jitter, it was subsequently argued by [4] that
this effect was somewhat illusory, and results of a similar
positive nature cannot be guaranteed for arbitrary datasets.
Nahas [7] also showed that if the transmission data is screened
on-line, such that an XOR mask can be selectively applied
on a byte-by-byte basis, then a 20% reduction of jitter can
be observed in the general case; however this comes with
a penalty of increased software complexity in the embedded
system nodes, and a slight penalty in terms of information
throughput (a payload byte must be reserved to hold XOR
encoding information).
In a subsequent paper, [5] introduced a further technique
known as Software Bit Stuffing (SBS). This technique applies
a high-level bit-stuffing algorithm prior to data transmission,
such that stuff bits are inserted by the application itself, there-
fore reducing the levels of hardware-induced stuff bits. The
principle of SBS is shown in Figure 1. It was found that the
technique further reduces the expected levels of jitter by 40%,
but again this is at the expense of further increased software
complexity and a greater penalty in terms of information
throughput (2 payload bytes must now be reserved to hold
XOR information). Although both techniques are successful in
jitter reduction, for many applications a 25% (or even 12.5%)
reduction in the available information throughput capacity of
the CAN network - along with increased CPU and memory
overheads in each node - will be unacceptable.
B. Overclocking and improving information throughput
Overclocking in CAN networks is a technique that has
previously been suggested to artificially decrease the bit-time,
and hence the transmission time, of a message. Each CAN
controller in a given network is driven by a local clock source.
This clock signal is typically stepped down by an internal
prescaler register, before being used to drive - via the bit timing
registers - the protocol controller and bit stream processor. As
such, overclocking most often refers to the deliberate use of
a faster oscillator - in combination with appropriate settings
in the prescaler and bit timing registers - to increase the
transmission rate.
However, great care must be taken when overclocking a
CAN network. As mentioned, the CAN protocol employs non-
destructive priority-based arbitration. The wired-AND nature
of the physical layer that is used to achieve this arbitration
requires that all nodes in the network achieve a logical
consensus on the instantaneous bit-patterns appearing on the
bus lines. it is this requirement of the protocol that it acts to
severely limit both the maximum transmission speed and bus
length of a given CAN network. The maximum transmission
rate is inversely proportional to the length of the bus, and has
an upper limit of 1 MBit/s; due to its design a CAN frame may
carry up to a maximum of 8 data bytes. In statically scheduled
implementation of a CAN-based system, the overclocking
problem does not in itself pose many serious problems, save

Fig. 2. CAN frame format showing S and M zones
perhaps for certification issues in critical systems. This is
because the message schedule ensures such that no run-time
message collisions and hence message arbitrations actu-
ally take place. Since no run-time collisions take place, the
arbitration mechanism becomes redundant and there is no
need for system-wide consensus as only a single node is
in control of the bus; if an adequate technique is employed
to deal with the ACK slot (e.g. by using local message
acknowledgment) the CAN controllers may be overclocked by
a significant factor, resulting in a proportional increase in data
throughput. For event-driven and hybrid systems, however,
the arbitration mechanism must be heavily relied upon, and
simply overclocking the CAN controllers is not guaranteed to
work; the requirement for node-wide temporal consensus of
bit values is violated by signal propagation delays.
One possible way around this problem has previously
been suggested by [8], who suggest using a dual-channel
approach known as FastCAN, with one ’forward’ channel and
one ’reverse’ channel. With appropriate modifications to the
physical and datalink layers, they have suggested that such
an approach would theoretically allow a bit-rate of up to 16
MBit/s.The basis for another (simpler) technique was also
outlined by Cena & Valenzano in a short communication [9].
The technique is based upon the observation that a CAN frame
may be divided into different zones, as depicted in Figure 2 .
The M-zones of the frame are the portions in which multiple
writers are allowed (i.e. during arbitration, acknowledgement,
EOF sequence, and inter-message space). The S-zones of the
frame are those portions in which only a single-writer is
allowed (i.e. transmitting the DLC, payload and CRC). During
the S-zone, only a single node has ’won’ the arbitration and -
save for error signalling - is in total control of the bus. As such,
the CAN network may be operated at its normal transmission
rate during the M-zones, ensuring temporal bit-wise consensus
across the network; when the S-zone is entered, the CAN
network may be overclocked to decrease the transmission time
of the payload.
1738
III. P ROPOSED ENHANCEMENTS TO CAN AT THE
HARDWARE LEVEL
With recent advances in the development of programmable
logic devices (PLD’s) such as FPGA’s, as demonstrated by the
authors of the current paper, it is now possible to implement
the required changes with (relative) ease. The Overclocking
technique has previously been implemented using an FPGA
by the current authors [10], and is demonstrated in Figure 3.
A variation of this basic technique, in which only data field
in the S-zone is overclocked, was recently described in [11].
Although in this latter implementation backward compatibility
to the original CAN protocol is claimed, no elaboration of how
consensus is achieved on the received CRC calculation among
nodes working on different data rates is provided; hence this
claim would seem to be a little erroneous. The Overclocking
implementation considered in this paper follows that of [10],
in that it not only covers the Data but also the CRC field;
although backward compatibility is not claimed, CRC error
detection and confinement plus recovery schemes are close to
that of the original CAN standards.
As can be seen from the discussions presented in previous
section, although many enhancements to CAN have been
proposed, each is limited by the fact that it either requires
additional CPU overheads along with increase the complexity
of software running in local CAN-enabled nodes or requires
modifications at the hardware level for implementation. Ad-
ditionally, early experiments have shown that FPGA-based
designs can provide the flexibility with which to implement
sophisticated schemes, which cannot be implemented by the
use of software-based protocols alone.
The current enhancement is to eliminate the effect of jitter
due to the presence of stuff bits, which are unpredictable in
their occurrence. A message of similar data length may have
variable size and hence unpredictable transmission times. The
current enhancement attempts to partially eliminate the effects
of transmission jitter due to the presence of stuff bits, which
are a complex function of the transmitted data and effectively
unpredictable in their occurrence. The technique proposed in
this paper is to add an extra field to the CAN standard frame,
which is known as the ’Data Plus’ field. The actual length
of this field is variable - the number of bits it contains is
determined dynamically by the CAN controller - and will
depend upon the worst-case stuffed frame lengths [6] given
by Equation 1.
8di + 34 − 1
8di + 34 + 13 + b c (1)
4
The length of Data Plus is the difference of the transmitted
frame length to the result obtained by Equation 1. This will
ensure that each message sent should be of the same length
as a worst-case stuffed frame depending upon the value of
di which represents the number of data bytes sent in the
CAN frame. The working of this enhanced CAN controller can
be understood by the given Figure 3. As we had mentioned
previously that enhanced CAN controller can transmit more
 Fig. 3. Chipscope Snapshot of Enhanced CAN Transmitter
than 8 bytes upto 1024 bytes and also can overclock in S-
zone reference Figure 2. This snapshot depicts a 15 byte
message overclocked from 1 Mbps to 5 Mbps been with
additional Data Plus field transmitted successfully, we give
a brief account of the transmission state machine.
1) Tx State xxx signals indicates different states of trans-
mission cycle, the states before Tx State Data are send-
ing data at 1 Mbps, then the Data, CRC and Data Plus
fields are overclocked to be transmitted at 5 Mbps. This
is also shown by the Sample Point field which indicates
the sampling interval of the CAN bits.
2) Number of bits field indicate the count of CAN mes-
sage bits transmitted since the start of the frame includ-
ing any stuff bits, Marker ’X’ shows the same count
which is ’168’ i.e. the total number of bits already
transmitted before Data Plus field.
3) The Length of Data Plus field as explained before will
be the difference calculated by subtracting Equation 1
from Number of bits. This difference is indicated by
the Max bit diff field which in this test case is 28.
4) The Data Plus field will last for 28 bit time and will send
alternate ’0’ and ’1’ to compensate for the worst case
message, (the choice of alternate bits is the minimize
the chances of stuffing even in case of erroneous trans-
mission/reception of a single or number of bits). This
will make the total bits sent as ’196’ added the fixed 9
bits of Acknowledgement and End of frame fields. This
number is equal to possible worst case frame length of
a 15 byte CAN frame.
The enhancement has been designed such that in case of any
erroneous bit transmission in Data Plus field no error frame
will be generated because
1739
1) The fact that the integrity of the data in this field is not
a required feature
2) The Data Plus field has not been added to the Error
Management Logic of the CAN protocol [1].
3) The Length of Data Plus is calculated on the local
node and it depends upon the CAN DLC (Data Length
Code) field hence there is zero possibility of this type
of error. In case of DLC been received incorrectly by
the receiving nodes an error frame is generated and no
further transmission takes place [1].
IV. C ASE S TUDY
In this section we will discuss the results obtained in our
case study, before this we will give a brief account of the Test
bench formed to conduct this study.
The test bench consist of 4 CAN nodes, each node consist
on a development board with integrated FPGA and a host
ARM controller. One of the CAN nodes was working as a
transmitter node while the other three nodes primarily worked
as receiver’s but was setup to generate messages randomly to
create a real world CAN network. The transmitter node was
setup to generate a message at an interval of 1 millisecond,
where a message of random length and contents was generated
each time, also after every 50 message transmissions a best
and worst case stuffed message was inserted. An independent
ARM board was setup to receive two signals one each from
transmitter and one of the slave node, this was used to capture
the transmission time between start of a message on transmitter
and successful reception on a receiver node. These test were
conducted over different periods ranging from 2 to 24 hours
continuously.
The results of the study is given in Figure 4 and Table-I,
 Fig. 4. Average vs Ideal transmission times Fig. 5. Worst Case vs Best Case transmission times

Bytes Ideal time(µsec) Average time Std Dev Max-Min time

1 37 37.6907 0.1783 3.1734
the ideal transmission times for case stuffed frames has been 2 39 38.9368 0.1786 2.9766
calculated using Equation 2 modified from [3]. 3 41 40.9210 0.1674 3.2226
  4 43 42.1386 0.1668 3.075
15 + 8di − 1 5 45 44.1220 0.1891 3.075
ci = 31.τm + 16 + 8di + b c .τs (2)
4 6 47 46.1165 0.1626 2.8782
7 49 48.1082 0.1774 3.2226
In which the parameter di is again the number of bytes in the 8 51 50.0901 0.1807 3.799
payload of frame i. The network bit times for M-zone and 9 53 52.0856 0.1574 3.0012
S-zone are given as τm and τs respectively. 10 55 54.0808 0.1684 3.2964
11 57 56.0700 0.1691 3.1242
The results in Figure 4 indicate the average transmission 12 59 58.0500 0.1707 3.198
times of worst case stuffed messages for number of bytes 13 61 60.0303 0.1757 3.198
ranging from 1 to 15 compared with the ideal worst case 14 63 62.0106 0.1672 3.0504
15 65 63.9915 0.1617 3.1242
transmission times. It is clearly evident that the average values
are very close to the calculated ideal values; messages with TABLE I
longer data lengths have transmission time averages less than S TATISTICS FROM THE C ASE STUDY
the ideal worst case values, as evident in the enlarged view of
Figure 4, hence strengthening our argument that the addition
of padded bits with overclocking mechanism has little effect
on transmission times. respectively when using the SBS technique on almost identical
The statistics presented in Table I is a comparison between hardware, and sending 5 bytes of random data in an 8-byte
calculated worst case transmission times to the observed be- CAN frame @ 1Mbps (please note that the remaining 3 bytes
haviour of our proposed implementations such as the standard are reserved for use by the SBS protocol employed by Nahas
deviation from the mean values is varying in range of 0.1- et al). As can be seen in Table I, our data suggests a further
0.2 µsec which is a considerable achievement to the previous improvement over SBS with max-min and average jitter figures
techniques keeping in view the transmission jitter of existing of 3.07 µs and 0.19 µs respectively, when sending 5 bytes of
CAN 2.0B messages which are in range of 1 to 34 µsec for data. Also, please note that in this case (unlike when using
message lengths of upto 8 bytes when clocked at 1 Mbps. SBS) only 5 actual data bytes need be sent; maximum and
The Figure 5 shows a comparison between the worst and best average message transmission times are therefore reduced by
case transmission times of our proposed scheme and the CAN a significant factor (>50%), thus making potentially significant
2.0 B messages an evident gap exists between the worst case improvements in the total information throughput.
and best case transmission times while the statistics of Table The previous paragraph states the improved results achieved
I also shows that the difference between peak maximum and in reduction of transmission jitter as compared to the previous
minimum transmission times for various data length messages techniques, but this fact should be appreciated that this only
recorded using the proposed scheme is on average around become possible by changing the protocol in hardware layer
3.1 µsec, it is a substantial improvement of 10 times over with few modifications to the basic CAN protocol [1]. The
conventional CAN worst case frame transmission times. backward compatibility is considered as an issue with these
proposed modifications but with the advent of new protocols
V. R ESULTS AND O BSERVATIONS such as TTP [12] and Flexray [13], CAN also need to be
These data would suggest a significant improvement over modified (retaining its basic architecture and advantages) not
previous methods, both in terms of transmission jitter and only to keep up with the new protocol advancements but also
information throughput. For example, Nahas et al [5] quote retain/increase its market share.
difference and average jitter figures of 4.1 µs and 0.7 µs Also the CAN nodes running the modified protocol can

1740
easily be integrated with nodes running the standard CAN [5] M. Nahas, M. Pont, and M. Short, “Reducing message-length variations
protocol by utilizing the CAN reserved bits r0 and r1. Hence in resource-constrained embedded systems implemented using the con-
troller area network (can) protocol,” Journal of Systems Architecture,
a particular logic level of r0 and r1 will indicate the CAN vol. 55, pp. 344–354, 2009.
controller not to overclock and add the Data Plus field making [6] T. Nolte, H. Hansson, C. Norstrm, and S. Punnekkat, “Using bit-stuffing
this implementation backward compatible. Also, in any given distributions in can analysis,” in IEEE Real-Time Embedded Systems
Workshop, Proceeding, Dec 2001.
design the use of the Data Plus field need not be employed [7] M. Nahas and M. Pont, “Using xor operations to reduce variations in
for every message that requires transmission over the CAN the transmission time of can messages: a pilot study,” in Proceedings of
network. It is especially suitable for systems which utilize the Second UK Embedded Forum 2005, A. Koelmans, Bystrov, A. Pont,
R. M Ong, and A. Brown, Eds., Birmingham, UK, October 2005, pp.
periodic time reference messages such as the shared clock 4–17.
familly of protocols described by [14]. [8] G. Cena and A. Valenzano, “Fastcan: a high-performance enhanced can-
like network,” Industrial Electronics, IEEE Transactions on, vol. 47,
VI. C ONCLUSION no. 4, pp. 951–963, Aug 2000.
[9] G. Cena and Valenzano, “Overclocking of controller area networks,”
This paper has considered an implementation of a modified Electronics Letters, vol. 35, no. 22, pp. 1923–1925, Oct 1999.
CAN controller which can help to improve the transmission [10] I. Sheikh and M. Short, “”improving information throughput in con-
troller area networks: Implementing the dual-speed approach”,,” in 8th
predictability of some (or all) messages in a CAN network. As International Workshop on Real-Time Networks, Proceedings, Dublin,
has been shown in the paper, the addition of a ’data plus field’, Ireland, 6 2009.
has the ability to virtually eliminate transmission jitter. The [11] S. Ziermann, T. Wildermann and J. Teich, “Can+: A new backward-
compatible controller area network (can) protocol with up to 16x higher
modified controller has been shown capable of transmitting data rates,” in 2009 Design, Automation and Test in Europe, April 2009,
CAN frames with an increased data payload size, and the pp. 1088–1093.
presented techniques are also applicable and effective in these [12] H. Kopetz and G. Grunsteidl, “Ttp - a time-triggered protocol for fault-
tolerant real-time systems,” pp. 524–533, 1993.
cases. [13] FlexRay communications system - protocol specification v3.0, Flexray
Although initial experiments with the technique indicate its Consortium, December 2009. [Online]. Available: www.flexray.com
effectiveness, it does have several drawbacks; it seems unlikely [14] D. Ayavoo, M. Pont, M. Short, and S. Parker, “Two novel shared-clock
scheduling algorithms for use with ’controller area network’ and related
that such a scheme can be made backwardly-compatible with protocols,” Microprocess. and Microsyst., 2007.
existing CAN implementations. When employed in a mixed [15] I. Sheikh, M. Pont, and M. Short, “Hardware implementation of a
system with one or more standard CAN controllers, numerous shared-clock scheduling protocol for can: A pilot study,” in Fourth UK
Embedded Forum, proceedings, University of Southampton, September
errors (most notably bit stuffng and CRC errors) are observed 2008.
and signalled. A potential area of future work would be
examining any possible impact of the techniques on bit-error
susceptibility and message transmission failure-rates in noisy
environments. In conclusion, with appropriate care in the
implementation stages, the proposed modifications to the CAN
protocol described in this paper seem to indeed be feasible and
may have the capability to further increase the applicability of
this popular protocol for systems that have stringent real-time
requirements.
ACKNOWLEDGMENT
The work in this paper is supported by the award of a
PhD scholarship to Sheikh Imran from the NWFP University
of Engineering & Technology, Peshawar, Pakistan through
the Higher Education Commission of Pakistan. Preliminary
versions of the some of the material described in this paper
were presented at the 4th UK Embedded Forum ([15]) and the
8th International workshop on realtime networks ([10]).
R EFERENCES
[1] ISO 11898-1 Road Vehicles -interchange of digital information
-controller area network (CAN) for high -speed communication, Inter-
national Standardization Organization (ISO), 1993.
[2] H. Kopetz, “A comparison of can and ttp,” vol. 24, 2000, pp. 177–188.
[3] T. Nolte, H. Hansson, and C. Norstrm, “Minimizing can response-
time jitter by message manipulation,” in 8th Real-time and Embedded
Technology and Applications Symposium, Proceedings, 2002, pp. 197–
206.
[4] M. Nahas, M. Short, and M. Pont, “The impact of bit stuffing on the real-
time performance of a distributed control system,” in 10th International
CAN conference,Proceeding, Rome, Italy, March 2005, pp. 10–1 to 10–
7.

1741