CAN
The Controller Area Network (CAN) is one of the most common bus protocols in the
automotive industry. It was introduced in 1986 by Bosch. The main driver for its
development was the reduction of cables in motor vehicles and the associated cost
reduction in manufacturing. Since 1993, CAN has been standardized in ISO 11898 and
regularly adapted to the new technical conditions. The CiA (CAN in Automation) takes
care of the further development of the CAN standard. Today many many motor vehicles and
industrial devices use the CAN standard.
The CAN protocol defines the data transmission on the physical layer and the data link
layer of the OSI 7 layer model. In the following, a rough overview of the function of
CAN will be given.
Since CAN is mainly used to connect several electronic control units, which all have to
send and receive data, a multi-master bus architecture is used. This means that all
nodes (e.g. a control unit) can read and write on the bus. In order to resolve
collisions caused which can occur when several nodes access the bus at the same time,
the CSMA/CR method is used. It ensures that only the node with the highest message
priority accesses the bus.
A CAN message, also called a frame, consists of seven fields:
- The start field (1 bit): Marks the start of a frame.
- The arbitration field (12 bits): Consists of the message identifier (11 bits) and the bit to distinguish between data or
remote frame.
- The control field (6 bits): Composed of the 4 bits indicating the length of the following data field and two bits reserved
for extensions.
- The data field (0-64Bits): Contains the actual data of the CAN message.
- The data protection field (16 bits): Contains the CRC check sequence(15 bits) and a delimiter bit.
- The end field (7 bits): Marks the end of a frame.
BLE
Bluetooth Low Energy (BLE) is a Bluetooth standard originally developed by Nokia to
reduce the high power consumption of conventional Bluetooth modules. For this, smaller
amounts of data are exchanged at longer intervals. BLE is part of the Bluetooth 4.0
specification from 2010. In the meantime, the standard has become established and many
smartphones and other devices, such as fitness trackers, use BLE for data
transmission.
In the BLE standard, devices can assume different roles. In our use case, there would be
a device that takes the Peripheral role and sends Connectable Advertiser events, which
another device can use to connect to the device and start data transmission.
CAN2BLE
To transmit CAN messages via BLE, a hardware interface is required, which is either
permanently installed in a device or can be plugged into a free CAN connector. This
interface would take on the peripheral role. Depending on the configuration, the
interface can offer a connection on demand. Another device can now connect to the
interface and data can be transferred.
There are two other things to keep in mind here:
- In most cases, the interface should prepare the data for transmission with BLE.
- Since over-the-air transmission takes place via BLE, data should be encrypted before transmission.
The preparation of the data can look diverse. Since a lot of information in the frame of
a CAN message is uninteresting for processing, it makes sense to pack the data from the
data field into a separate protocol and send it with that. If encryption is necessary,
the interface must also implement it.
Use cases
In the following, two hypothetical use cases for the described technology will be presented.
1.) CAN2BLE in a production machine for maintenance data
In our specific case, a company wants to improve its maintenance process. Until now, an
employee had to go to each machine with a dedicated CAN diagnostic device, plug in a
cable and read out the data. He then decides whether the machine needs readjustment or
other maintenance.
Alternatively, the machines could be equipped with a
CAN2BLE module. Instead of a dedicated device, the employee could use a smartphone that
has already been used to optimize other processes in the company. Now he connects to a
machine via BLE and receives the data on his smartphone. Depending on the requirements,
an app can be developed here that displays, evaluates and visualizes the data and sends
it to a central system. The decision for maintenance could be made directly made by the
system, e.g. if certain values are above the acceptable limit.
2.) CAN2BLE in an excavator for work documentation and performance evaluation
In our specific case, an excavator manufacturer wants to offer his customer added value
for their excavators and use the data collected by the excavator's internal systems.
For this purpose, he is installing a CAN2BLE module in his new excavators and
retrofitting old excavators. In addition, he is having an application developed that,
when the smartphone connects to the interface of the excavator, allows the data (e.g.,
weight on the bucket) to be tracked during a work step. The app offers the dredger
operator a visual preparation of the data during the work. After the work, the app
offers the excavator operator the possibility to view the complete data again in order
to check whether all values are in order. In addition, the app offers him to create and
send a report with the data. In this way, a construction company that owns several
machines can collect all the data centrally. It can also be used to check whether work
has been carried out properly. Another added value can be collecting the data for a
machine in order to measure its performance and thus to determine whether maintenance is
necessary.
In the future, one could imagine that by reading out data from all machines on a
construction site, it will be possible to track exactly how, where and when what was
done, to enable better planning and more efficient work. In addition, communication
between the machines via smartphones would theoretically also be conceivable in order to
further optimize, document or automate processes.