Container-handling machines (e.g. ship-to-shore cranes, mobile harbour cranes, straddle carriers, rail mounted gantry cranes and rubber-tyred gantry cranes) are an important business in the increasing market of logistics and transportation. These machines and their spreaders have to exchange command and status information. In the past, the manufacturers bilaterally agreed upon the interface between the crane and spreader, so it was not possible to use a spreader from another manufacturer without re-programming the crane controller.
With increasing functions of spreaders, this has become more complicated. This was the reason why several spreader and crane manufacturers started specifying an open interface standard. Customers and classification authorities demanded new spreader control functions, which is another reason why the interface between container-handling machine and its spreader was standardised.
The specification was developed under the umbrella of the non-profit CAN in Automation (CiA) organisation. CiA is the international users’ and manufacturers’ group for Controller Area Network (CAN), developing CAN-based higher-layer protocols and device profiles together with its members. CiA’s special interest group (SIG) Crane/Spreader decided to use high-speed CAN as communication interface, and CANopen as application layer. The developed CiA 444 CANopen device profile for containerhandling machine add-on devices specifies also the content of the data to be communicated.
This includes the process data (commands and status information), configuration parameters as well as diagnostic data (emergency error codes and failure reports).
The profiles specify the CANopen interfaces for crane spreaders (part 2) and for spreaders of straddle carriers (part 3). Part 1 specifies the general definitions. Here definitions for physical layer, such as transmission rate and cabling recommendations are given. The profile may be extended by additional parts, if further add-on
device interfaces have to be standardised.
The following leading crane and spreader manufacturers and service providers jointly developed the CiA 444 profile within the special interest group: Bromma, Gottwald, ifm electronic, NSL Engineer ing (RAM Spreaders), Kalmar, Liebherr, Noell, Sontheim Industrie Elektronik, Stinis, and VDL Containersystemen. The goal of this standardisation activity was to achieve interoperability and partly interchangeability of spreaders without much reconfiguration effort.
CAN and CANopen
CANopen is a standardised application layer (EN 50325-4) for CAN, an internationally standardised serial bus system (ISO 11898-1/2). The CAN serial bus system with possible transmission rates of maximum 1 Mbit/s, was originally designed for the use in passenger cars, and is therefore very reliable and suitable for outdoor applications. Nowadays almost each passenger car in the world deploys (mostly two) CAN networks.
The CANopen application layer is the standardised solution for embedded control systems. It is applied in many machine control systems, in medical electronics, and in a broad range of off-highway vehicles.
Compared with human-communication CANopen would be a certain language (e.g. English or German) with its grammar and basic vocabulary, which uses the Latin set of characters (CAN data link layer) printed on a paper-sheet (CAN physical layer). The CANopen device profiles define certain ‘phrases’ in order to ‘speak’ with a device in a standardised way.
Technical details
Default transmission rate of 50 kbit/s shall be supported by the devices following the CiA 444 device profile, thus allowing network lengths up to a maximum 1 km. Other transmission rates e.g. 125 kbit/s at 500 m, or 250 kbit/s at 250 m, and 500 kbit/s at 125 m, may be supported as well. No specific connector is defined. During profile development, it was also considered that retrofitting of older cranes and spreaders without a CANopen interface should be possible.
The CiA 444 profile defines that the container-handling machine controller is the network management (NMT) master controlling the NMT status (initialisation, pre-operational, operational, stopped) of the spreader. Both devices have to provide the ‘Heartbeat’ functionality, which indicates that a device is still ‘alive’ and is in the required NMT status.
