CANBus: A Simple Overview for Understanding Digital Communication

Protocols Used with Hydraulic Cylinder Sensors

As the value of installing on-vehicle network systems have continued to increase, more and more cylinder
manufacturers have started implementing "smart cylinders" with integrated sensors that can take advantage of these
networks.

Many sensors available today support various configurations of analog and digital signal outputs. The Temposonics®
linear position sensors for mobile hydraulics applications are just such a sensor. The same magnetostrictive sensor
technology is available with simple analog outputs that report position as a function of current or voltage as well as
digital outputs in numerous protocols. For those whose systems are moving from the analog world to the digital one,
understanding this mix of different outputs can be overwhelming. To help get a basic understanding of the most
common digital communication protocols for off-highway positioning sensors, it is best to start with a discussion of
SAE J1939 and CANopen which are two CANBus protocols.

What is CANBus?

Before we can understand J1939 or CANopen, it is critical to have a basic knowledge of CANBus. CANBus is a serial
communication bus standard designed to allow microcontrollers and devices to communicate with each other without
a host computer. The CAN in CANBus stands for Controller Area Network.

CANBus was first designed in the 1980s by Robert Bosch GmbH to reduce the amount of copper wiring used when
manufacturing automobiles. At the time, manufacturers were increasing the adoption of Electronic Control Units
(ECUs). Each ECU would control one or more electrical system on the vehicle. These automobile ECUs included
critical system components such as an ECM (Engine Control Module), and less critical controllers such as those for
powered windows, air conditioning and entertainment systems. Without a standardized way of exchanging data, each
ECU required direct point-to-point wiring which became increasingly complex as more units were added.

Because it is a message-based protocol, cars using CANBus could treat each ECU as a node on a network which
could exchange data using only a single pair of wires.

Although originally designed for the automotive industry, CANBus is flexible and rugged enough to have become
adopted for use in many industries and applications. These include industrial manufacturing machines, medical
devices, construction equipment, airplanes, ships, and military vehicles.

How communication works on a CANBus network

Each node on the network communicates by way of a CAN frame. Each frame consists of the following bit fields:

• SOF (Start of Frame)

• ID (frame identifier)
• RTR (Remote Transmission Request indicates if the node is sending or requesting data)
• Control (sets priority and length of the data bytes to be transmitted)
• Data
• CRC (Cyclic Redundancy Check)
• ACK ("Acknowledgement" of data received)
• EOF (End of Frame)
Each node on a CAN network broadcasts these frame messages to the entire network. Because of this, each
communication is prioritized as either dominant (0) or recessive (1). A recessive state indicates that the differential
voltage is lesser than a minimum threshold. A dominant state indicates that the differential voltage is larger than that
threshold and will override a recessive state during arbitration. In this manner, the data in a frame is transmitted
sequentially but in such a way that if more than one device transmits at the same time, the highest priority device can
continue while the others back off. Frames are received by all devices, including by the transmitting device.

CAN specifies four different message types which determine how the frames are constructed and handled on the
network:

The Data Frame

A standard CAN data frame will include all the bit fields listed above. It is important to note that in data frames both
the RTR and ID bits are prioritized as dominant. If the receiving node has a recessive acknowledge bit overwritten by
a dominant bit, both the transmitter and receiver recognize this as a successful transmission.

The Remote Frame.

Remote frames are used to request data from a node. A CAN remote frame is similar to a data frame, but it does not
contain any data bits. To identify itself as a remote frame, this frame type is sent with the RTR bit in a recessive state.

Error Frame
When a node detects an error in a message that it has received, it transmits an error frame to the entire network. All
other nodes respond by also sending an error frame. Following this, the node where the error occurred retransmits
the initial message.

The Overload Frame

The overload is sent when a node is receiving frames faster than it can process. It is sent in a similar manner to an
error frame, but also provides a time buffer so the node can catch up.

CANopen and J1939

CANBus provides only the foundation for exchanging messages. It is does not specify how to decode the raw data on
the network or how to handle messages larger than 8 bytes. This is where other protocols such as CANopen and
J1939 come in. These standardized, Higher-Level Protocols (HLPs) exist to further define how data is communicated
between nodes on a given CANBus network. CANBus gives ECUs a method to communicate with each other, but
these higher-level protocols create a language for that communication.
There are several HLPs that work with CANBus, the most common of CANBus Timeline
which are SAE J1939, ODB2 CAN FD, and CANopen. The two most 1986: CAN protocol officially released
relevant to off-highway vehicles with hydraulic or pneumatic systems are
J1939 and CANopen. 1987: First CAN controller microprocessors introduced
by Intel and Philips

1991: Bosch published CAN 2.0 (CAN 2.0A: 11 bit

Some history is helpful here. In 1991 CAN 2.0 was codified into the
ISO11898-1 standard. Then the Society of Automotive Engineers [SAE]
developed a higher-level version of the standard to address the needs of
heavy-duty vehicles. In the late 1990s this was published as SAE J1939.
Around that time, the European Union was developing a framework based
on CANBus designed for motion control of machine systems. In 1995 the
specifications from that project were transferred to the organization CiA
e.V. (CAN in Automation) and became known as CANopen. Starting in
2002 CANopen has officially been part of the European standard (EN
50325-4 2002 Part 4: CANopen).
identifier, 2.0B: 29 bit identifier). Mercedes Benz W140
is the first production vehicle to feature CAN-based
miultiplex wiring system.
1993: CAN is adopted as international standard (ISO
11898)
1994 – SAE first publishes J1939
1995: CANOpen framework acquired by CiA e.V.
(CAN in Automation)
2002: European standard EN 50325-4 2002 Part 4:
CANopen approved
2003: ISO 11898 becomes a standard series

So does this mean that SAE J1939 is for Heavy Duty Vehicles and 2012: Bosch releases CAN FD 1.0 (flexible data rate)
CANopen is only for machine control? Not quite. Let's start with J1939. 2016: The physical CAN layer for data-rates up to 5
Mbit/s standardized in ISO 11898-2

SAE J1939

As stated above, CANBus does not specify how to decode the raw data on the network. In the automotive world, this
led to manufacturers using proprietary, OEM specific protocols when implementing CANBus networks. With J1939,
the SAE's intention was to provide a standardized, common language across manufacturers of heavy-duty
commercial vehicles. It does so by detailing how the raw data from the CAN network can be translated into a human
readable form as well as providing for a standard method of transferring messages beyond 8 bytes of data. Further, it
specified physical attributes related to voltages, wiring, etc. As a result, OEMs manufacturing construction,
agricultural, military, municipal and other vehicles (and their suppliers) had a common setup and "language" for their
communication.

This standardization was a key to enabling datalogging features needed for things like fleet management systems.
From a datalogging perspective, J1939 provides an overlay to CAN including a set of standardized messages and
conversion rules that apply across a wide array of vehicles.

J1939 is based on CAN 2.0A which specifies a 29-bit message identifier. It typically communicates with a 250k baud
rate, though there is support for other values. Most J1939 data messages are broadcast serially on the network
(broadcast), but some data is only available by requesting from a CAN device explicitly using commanded messages
(peer-to-peer).

The messages themselves are identified using an 18-bit Parameter Group Numbers (PGN). This PGN number acts
as a unique identifier within the J1939 standard. Signal information is identified using a defined Suspect Parameter
Numbers (SPN). These SPNs can be assigned to multiple PGNs. Data packets are sent in hexadecimal format, with
the least significant byte first (Intel byte order). Data Messages larger than 8-bytes are supported using J1939
transport protocol [BAM – Broadcast Announce Messages]. PGNs and SPNs are listed in the J1939-71 standard
documentation. For example, a SPN may refer to a specific parameter (SPN 110 - engine coolant temperature) which
is part of a PGN (PGN 65262 - engine temperature).
CANopen

Although CANopen was initially designed for motion control of machine systems, it has grown to be used in many
vehicle applications such as agricultural sprayers and harvesters, tractors, railway cars, trailers, in addition to
maritime electronics, building automation as well as power generation. Like J1939, CANopen builds on CAN in terms
of the physical layer (lines used, voltages, etc.) and the data link layer (utilizing a CAN frame message-based
protocol). It likewise provides a common "language" on top of the CANBus communication protocol that enables off-
the-shelf interoperability between devices (nodes).

Unlike J1939, CANopen is optimized for embedded network design. CANopen also clearly separates between data
and services. At the heart of CANopen is the object dictionary (OD), which is essentially a table that stores
configuration and process data. Instead of PGNs and SPNs, in CANopen all parameters are organized in a table,
where a cell is accessed via its unique row (object index) and column (object sub-index). It is a requirement for all
CANopen devices to implement an object dictionary. It contains references (indices) for all used data types and
stores all communication and application parameters.

CANopen can also be configured for use in 3 different communication models: master/slave, client/server, and
producer/consumer. In any configuration each node on the network is required to implement a server that handles
read/write requests to the object dictionary. To transport data into and out of the object dictionary as well as between
nodes, CANopen defines various services. The most common CANopen services are SDO (Service Data Object)
and PDO (Process Data Object). Using SDO, one node can read or edit the value of another node’s object dictionary.
PDO is used to rapidly move data from one node to another or to share real time information. With PDO it is possible
trigger data to be shared from one node, such as a sensor, to the rest of the network when a measurement from the
sensor changes. PDOs can also be used to sync data between nodes at predetermined intervals.

Putting it all together

As we have learned, CANBus is the basis for communication that is shared by the Higher-Level Protocols (HLPs)
CANopen and SAE J1939. These two HLPs are the most common digital communication protocols used in heavy
duty off-highway vehicles. CANopen specifies differences between data and services allowing for multiple ways for a
user to set up the network. CANopen organizes all of its parameters in a user defined table (object dictionary) giving
a great amount of flexibility. CANopen also offers the possibility of manufacturer-specific parameters. SAE J1939 is
more focused on automotive applications and is optimized for specific applications related to that industry. It specifies
only data (not services) which are grouped into pre-defined parameters (PGNs and SPNs).

So how do you choose which protocol to use? In many cases, the choice may already be determined by customers
who are already trained and experienced in using certain equipment. It may also be determined by the specific
vehicle or industry. If unsure, or just need help adding devices to an existing network the best place to start is with
your equipment supplier.

MTS provides expert technical assistance with their selection of linear position sensors which are available in various
analog and digital protocols (including SAE J1939, CANopen, CAN Safety, and more). The MTS sales and
applications teams have years of industry experience to help you find and support your optimum solution. MTS also
provides detailed protocol manuals that detail the commands that are used to get the sensors working on your
application. MTS offers a Digital Test kit which can be used with a standard windows laptop for diagnosis and
programming of sensors in the field.