Open search

CAN Newsletter magazine

History and trends: CAN on construction sites

In cranes, pavers, earth-moving machinery, and other equipment used on construction sites, embedded CAN networks are used for many purposes. CANopen and J1939 are the most applied higher-layer protocols. The next step is the migration to CANopen FD and J1939-22.

(Source: Adobe Stock)

The complete article is published in the September issue of the CAN Newsletter magazine 2022. This is just an excerpt.

In 1994, CAN in Automation (CiA) established already the Special Interest Group (SIG) for mobile applications. It was chaired by Alfons Horn working with Moba. The CiA working group started to develop a CAN Application Layer (CiA 200 series) communication profile for construction machines. When the CANopen application layer and communication profile was handed over to CiA, the group decided to follow this path. Nowadays, Moba provides CANopen products for levelling and quality control of pavers, compactors, and milling machines.

At the same time mid of the 90s, U. S. manufacturers of earth-moving machinery adapted J1939 to control diesel engines. It took some time, to introduce worldwide CAN-based networks into construction machines and equipment, because this industry is conservative in adapting new technologies. Good things come to those, who wait. End of the 1990s, Prof. Dr. Wolfgang Poppy from the Otto-von-Guericke-Universität Magdeburg (Germany) was the pioneer developing an excavator prototype controlled by CANopen networks. Some years later, many German suppliers of construction machines utilized CANopen in their products. In the meantime, many other European companies implemented CANopen in their machinery. They are supported by host controller manufacturers (e.g. Epec, Intercontrol, ifm, Moba, and STW) as well as sensor and actuator suppliers. The benefits are the standardized interfaces for encoders (CiA 406), inclinometers (CiA 410), modular I/O devices (CiA 401), etc. Products compliant with these CiA profiles are interoperable with the CANopen host controllers. However, exchangeability of such devices is limited to the mandatory functions.

Figure 1: The Big Sonic-Ski from Moba with four CAN-connected sensors for asphalt paving (Source: Moba)

Paving the future

Modern paving machines need multiple sensors. This includes especially sensors to control the levelling of road construction machines. Moba is one of the early birds providing such sensors with CANopen connectivity. Apparently, Chinese companies copied them. Some of these copies looked from the housing like the originals, but the function and quality were different. Paving roads and highways as well as runways require a sophisticated temperature control of the asphalt. This was also achieved with CANopen-connectable sensors. Furthermore, CANopen networks are used in vehicle-mounted lifting equipment. Hirschmann (today: Wika) was one of the early users of CANopen Safety (EN 50325-5) for overload protection purposes in container, gantry, lattice boom, telescopic, and other cranes. For such kind of applications functional safe sensors are needed. CANopen Safety has been developed at the beginning of the millennium, originally released as CiA 304 specification.

Today, several CANopen host controllers (e.g. from ifm, Intercontrol, and STW) provide CANopen Safety support. There are also functional-safe pressure sensors, encoder, inclinometers, etc. available. For example, FSG and TWK have recently introduced new CANopen Safety encoders. The miniature rotary encoder of the MH609y-II-CAN series from FSG feature CANopen and CANopen Safety. The starting point for the development was a previous customer solution for a small rotary encoder with a downstream signal converter for CAN, explained the company. FSG then developed the MH609y-II-CAN series, a cheaper and more compact solution without additional separate converters, the company continued. Signal output was via two CAN interfaces using the CANopen protocol.

Figure 2: ABN sensor with a 22-bit resolution and CANopen or CANopen Safety connectivity (Source: TWK)

At Hannover Messe 2022, TWK exhibited its rotary encoders. They provide CANopen or CANopen Safety connectivity. The latest ABN encoder model has a resolution that divides the circle of 360° into over 4 million steps, which means a 22-bit resolution. This is impressive with better than ±10 arcsec, which is less than ±0,003°. Precise measurements of positions and speeds up to 10000 1/min are thus possible. These values are achieved by scanning an optical code disc. Equipped with the CANopen or CANopen Safety interface, the encoder can be used for safety-related applications. The requirements for SIL 2 (safety integrity level) according to IEC 61508 are fulfilled. Moba has developed the MSS Slope CANopen Sensor family, which has been EN ISO 13849 certified by TÜV Nord. These sensors support CiA 301.

The next step: Migration to CAN FD

Some construction and earth-moving vehicles – nicknamed as “machines on wheels or caterpillars” – use multiple CAN-based networks. Some of them still use proprietary higher-layer protocols. But most utilize CANopen or J1939. In powertrain, J1939 dominates. CANopen is often used in the machine parts. If the CAN-based networks do not provide sufficient bandwidth, just another network segment is introduced. This is why many host controllers provide multiple CAN ports. In some applications, the separation of functions is not because of the busload, but because of functional separation provided by different development teams or sub-system suppliers. If the busload is an issue, CAN FD could help. This second generation’s CAN protocol is now available in most of the micro-controllers. CAN HS (high-speed) transceivers and transceivers featuring signal improvement capability (so-called SIC transceiver) are provided by several chipmakers. But there is a hurdle to migrate to CAN FD: There is no specification for the network system design. CiA is going to fill the gap. The nonprofit association is looking for an academic partner to develop design recommendations for larger CAN FD networks. The research results should be usable for CANopen FD as well as J1939-22 (CAN FD based transport and application layer). J1939-22 adopted the multi-PDU (protocol data unit) concept, originally introduced in the CiA 602-2 specification (withdrawn after publication of J1939-22).

Figure 3: CiA 415 sensor system architecture example. Profile-compliant sensors require a sensor controller (application commander and CANopen manager) supporting self-configuration of the CANopen network.

CiA profiles for construction machinery

In 2003, CiA released the CANopen application profile for sensor systems in road-construction and earth-moving machines (CiA 415 version 1.0.0). The predecessor of this specification was jointly developed by the Osyris (open system for road information support) consortium (terminated) and the European Asphalt Pavement Association (EAPA, The CiA 415 version 2.2.0 was released in April 2009. This application profile specifies the communication interfaces for sensors and a sensor controller of such road construction and earth moving machines as pavers, compactors, graders, dozers, mills, heaters, and trucks.

Figure 4: CANopen networks are used in vehicle-mounted lifting equipment. Wika, for example, uses CANopen Safety for overload protection purposes in container, gantry, lattice boom, telescopic, and other cranes.

Profile-compliant sensors require a sensor controller (application commander and CANopen manager) supporting self-configuration of the CANopen network. During the start-up, the sensor controller scans the entire network for available sensors. Then, the number of process data entries provided by each sensor is read and verified using a plausibility test. If the number is valid, each process data entry is read out. Then, the sensor controller creates the necessary TPDOs for each device and downloads them to the sensors via SDO. First the PDO mapping parameters are configured followed by the PDO communication parameters. The same procedure is repeated for the required process data whereby the RPDOs for each sensor are created. After this process, the sensor controller switches the involved devices to the NMT operational state and tests whether the established PDO connections are working correctly.

Important system information is transferred with high priority using defined events for request/response of available sensor data, generic error transmission, machine state (stop, working etc.), leveling status (manual, auto, etc.), closed-loop control (automatic on/off), and begin of a new project (reset mode). Thus, the sensor controller device (usually residing in the on-board computer) is always informed on this information.

If you would like to read the full article, you can download it free of charge or you download the entire magazine.


Publish date

CAN Newsletter September 2022