We have really known it all along: there is no such thing as a singlecommunication technology that is suitable for every purpose.Quasi- religious fundamentalism for a certain network is not in theindustrial users best interest.
Users are always spoilt for choice, even the introduction ofEthernet-based solutions to industrial automation has not changed thisfact. By now more than 15 systems compete for users' grace.
The criteria for choosing one network over another are not onlytechnical ones. Also historical and economical, as well as personal(training, standard of knowledge) reasons play a role in the selectionof a bus system or a network. It is therefore not remarkable that mostcomplex machines and plants use more than just one communicationtechnology.
To avoid having to use the diverse bus systems and networks asstand-alone solutions, users connect systems via bridges and gateways.Bridges are devices that translate the lower-layer protocol of acommunication system, the higher-layer protocols stay identical.
In the human communication this equals translating Latin charactersinto Chinese characters or vice versa. The language is not translatedthereby. This would be done, to stay with the comparison, by a gateway.Gateways translate the higher-layer protocols.
There are many gateways and bridges made by even more manufacturersfor a multitude of bus systems. However, it is here as it is in humancommunication: every translator/interpreter translates details a tinybit differently. This means, gateways and bridges by one manufacturermay not necessarily be exchanged for those made by anothermanufacturer. Users, however, demand just this.
Two years ago, ModbusIDAand CANin Automation (CiA)started standardizing a ModbusTCP/CANopen gateway. The CiA 309 specification has beenavailable for a year and is being improved to correct minor mistakesand to define additional functions.
The first part of the specification describes the communicationservices in the Ethernet-based network, with which the communicationservices in the sublayered CANopen network are triggered. Thus it ispossible to access any CANopen device via SDO (service data object)from a controller or a software tool from Ethernet and via the gateway.
Several CANopen networks may be connected to a gateway according tothe CiA 309 specification (Figure 1,below ). The second part of CIA 309 describes the ModbusTCPprotocols that implement the services defined in the first part. Theformat of the protocols complies to the ModbusTCP rules. It has beendeveloped in co-operation with experts from ModbusTCP. The third partof CiA 309 specifies ASCII protocols that can be used in anyEthernet-based network.
|Figure1. Block diagram of the CAN/Ethernet gateway according to CIA 309|
Networks that are based upon the CANopen application layer (e.g. EtherCatand Ethernet-Powerlink) do not needthese protocols. For these a bridge specification would enable a directconversion of the communication services. However, a standardizedsolution is not available yet.
The standardization of a CANopen/ProfinetIO gateway is beingdiscussed with ProfiNet.org (PNO) and CiA.This cooperation has just started, results will be available furtherdown the line.
Some applications, e.g. cranes, require connecting CANopen networksto ASI bus systems. Somespreaders (a crane add-on device thatgrabs containers ) use AS-Interface for the internalcommunication, cranes are being standardized with a CANopen interface(CiA444). Proprietary CANopen/AS-Igateways have existed for a long time, though they are not standardizedwith regards to their CANopen interface.
CiA members are currently working on an CANopen interface profile,which will not just map the AS-I process data but also make accessiblethe configuration parameters and diagnosis information of the CANopenobject dictionary at specified addresses (16-bit index and 8-bitsub-index).
Gateways according to CiA 446 canserve two AS-I bus systems per logical CANopen device. Since a CANopendevice can represents up to eight logical devices, altogether 16 AS-Ibus systems are connectable to one gateway. It is interesting thatCANopen networks can implement several controllers. Thus severalcontrollers may share an AS-I bus system. While this cuts down on thenumber of gateways used, it may also do so with sensors and actuators,which can be shared by the networks.
Complex control systems increasingly use several CANopen networks.These are networkable via a standardized bridge (CiA 400)hierarchically and non-hierarchically. The CiA 400 specification evensupportsmeshed network topologies, meaning every CANopen device is able tocommunicate with any other CANopen device via several gateways and viaseveral network paths.
This may be looked at as a CANInternet . CiA 400 defines a RemoteSDO service that enables forwarding an SDO service via one or severalbridges with the aid of a unique network identification. Even Emergencymessages may be transmitted to CANopen devices in different networks.Requests to the Network Management of another network may betransmitted with the help of the Remote SDO services. This functions isdefined in detail in the CiA 302 specification (additional functions ofthe CANopen application layer).
Process data objects (PDO) – messages that transmit process data inreal-time – will just be forwarded by the bridge if it has beenspecifically configured to do so. For this system variables weredefined that are unique in a system with multiple CANopen networks.Bridges according to CiA 400 may implement up to 32 independent andequally ranked CANopen interfaces (seeFigure 2, below ). The overall system may consist of up to 128network segments. This should suffice even for very complex systems.
|Figure2. Internal structure of a CANopen/CANopen bridge|
Standardization of devices that connect CANopen networks with other bussystems and networks save investments users have made and allowswapping devices by different manufacturers and with differentfunctions with small effort. Up to now, standardization has been mostlyinitiated by manufacturers of devices. However, also users mustarticulate their requirements in order that their point of view will beconsidered during standardization.
Holger Zeltwanger is managingdirector of CAN in Automation (CiA).