Longer user data and higher data rates - many CANopen supporters have been demanding this for some time. In response to this, CiA members have adapted the CAN-open protocol to the more powerful CAN-FD protocol since February 2015 and at the same time specified functional extensions for some CAN-open communication services. The network management, including the heartbeat function, has remained unchanged, as have the time and sync protocols. While the time protocol is used to synchronize the local clocks in the hardware components with an accuracy of one millisecond, the sync protocol can be used to synchronize the CANopen devices, which is particularly useful in drive technology.

The user data (payload) provided by the CAN FD protocol is eight times longer than with the classic CAN protocol (maximum 8 bytes). The FD application layer uses this for the PDO protocol. A PDO message can now transmit up to 64 bytes of process data. This significantly improves the protocol efficiency. In order to make the PDO configuration as simple as possible with regard to the compilation of process data, bit-by-bit mapping has been dispensed with. The minimum size of a process data is 1 byte.

Figure 2: Unlike the SDO protocol, the USDO protocol is not limited to a point-to-point connection, so that all or even different groups can be addressed; this speeds up the configuration of similar devices, for example.

© CAN in Automation

In CANopen-FD, the classic SDO protocol is replaced by the USDO protocol (see Fig. 2). It not only has additional functions, but also uses a different addressing scheme to enable broad and multicast transmissions. This means that several similar devices can now be configured simultaneously. The CAN identifiers used result from an offset (600 h for the client plus the client's node ID and 580 h for the server plus the server's node ID). This means that the sender is coded in the CAN identifier. The recipient is coded in the protocol header of the user data - i.e. the node ID of an exclusive device (1 to 127), the ID of a group (128 to 255) or all participants (0). This long-cherished wish of many users has so far failed due to the protocol header of only 4 bytes. Other functional enhancements include the session number, information about the data type of the transmitted parameter and the option of transmitting several parameters in one USDO message.

Even if not all functions are implemented in the first version of CANopen-FD, these are already planned and will be available shortly. SDO remote access to devices in other network segments has also already been prepared, replacing the SDO remote access protocol (CiA 302-7) that was previously required.

Although various scientists had already submitted proposals similar to CAN-FD at the turn of the millennium, it was not necessarily to be expected that the automotive industry would improve the CAN protocol. This only came about in the second decade, when some car manufacturers called for CAN to be accelerated. Of course, CAN FD messages can also be transmitted 'slowly' if there is only interest in the longer messages, for example to encrypt data or authorize access. In this case, the bit rate is not accelerated in the data phase.

However, if you want to take advantage of the speed benefits of the CAN FD protocol, you need to pay more attention to design recommendations when developing the devices and the physical network than before. In particular, care must be taken to ensure that the rising and falling edges are as symmetrical as possible and that the impedance is as identical as possible over the entire distance.

Impedance jumps as well as unconnected stubs lead to 'ringing' on the signal lines. In the worst case, such effects lead to incorrect bit values and are recognized as errors by the controllers. The CANopen FD specification therefore refers to CiA documents in which corresponding guidelines and design recommendations are described. For example, it is important to configure the time quanta (atomic time unit in a network) in the arbitration and data phase to be the same size or to keep them as short as possible so that the unavoidable quantization error when switching from the slow to the faster bit rate is minimized.

The topic of the cloud is now an integral part of industrial communication. Taking this into account, CiA is currently standardizing access from the 'clouds' to CANopen networks - in the CiA 309-5 specification, which is about to be published. The Restful application programming interface (API) defined here forwards the data coming from the CANopen network via a CANopen IoT gateway and the http protocol to the 'cloud' or is the interface for the information sent to the cloud. The data and services are JSON formatted. However, the API does not support event-oriented processes. The MQTT protocol is used for these tasks.

Who way to the cloud

Both the physical and logical addressing of the devices and networks are specified in CiA 309-5.

Physical addressing is a mapping of CANopen services in ASCII format to the Restful API, as specified in CiA 309-3. For logical addressing, a device identifier is introduced which is used to address networks and devices at a logical level. A distinction is made between three types of this so-called reference designator. This allows the individual CANopen parameters to be uniquely identified system-wide as ParamRefd, the CAN-open devices as NodeRefd and the CANopen networks as NetRefd. As described in IEC 81346, this identification can relate to product, function and location. This means that the system developer does not have to deal with network and node numbers or parameter indexes during logical addressing.

In addition to direct access from the 'clouds', CANopen networks can be connected to the cloud via Ethernet-based backbone networks in order to process the data collected in CANopen networks - keyword 'big data processing'. Gateways to Profinet have been described for some time in the CiA 309-4 specification developed jointly with Profibus International (PI). A gateway to OPC UA networks is still under development. This specification is also about to be published and will be published by the OPC Foundation in a so-called compendium standard.

The data generated in 'embedded' and 'deep-embedded' CANopen networks can thus be transferred directly or indirectly to the 'clouds' in a standardized manner. However, communication also works in the other direction. This means that the CANopen networks can be configured and partially controlled from the cloud. In this way, no physical network access is required.
It is not yet clear when all of the new functions mentioned, including the conformity test, will be available. At the end of September, at least the first version of the CiA 1301 specification will be published, in which the majority of the CANopen FD services and protocols mentioned above are described. The first CANopen profiles should specify a PDO mapping for 64-byte messages so that they can be "launched" at this year's SPS IPC Drives. There is already a PDO mapping for 64-byte messages for the widely used CiA 402 drive profile.

Author:
Holger Zeltwanger is an executive board member of CAN in Automation e.V. (CiA).