Posted to News on 8th Apr 2009, 16:02
New CANopen functions suit industrial automation
CANopen, the standardised communication system for decentralised and distributed embedded control systems, provides basic communication services such as transmitting in real-time messages containing process data (PDO communication). However, this broadcast or multicast service is not confirmed. To read or write to a parameter list (object dictionary) of another device the confirmed SDO client/server service is used. The CANopen application layer also provides network management (NMT) functionality, in that the device with the NMT master functions controls the NMT state machine of all networked devices. As an add-on, the CANopen NMT slave devices may request the NMT master to start or to stop other devices. This function, as well as self-starting CANopen devices, are described in the recently released CiA 302 series of specifications (version 4.0).
The CiA 302 specification has been completely re-chaptered. Part 1 contains some general definitions. Part 2 defines in detail the NMT boot-up procedure and the flying NMT master concept. Flying NMT masters are required in mission- or safety-critical network applications, where a single failure should not lead to a complete network shutdown. In case the NMT master device fails, another NMT master-capable device takes over. If the original NMT master device recovers from the failure situation, master functions revert back from the redundant NMT master device to the original NMT master. This mechanism is controlled by four different protocols described in CiA 302-2. Note that there may be more than two NMT master-capable devices in the network. The system designer assigns different priorities to the NMT master capable devices; the highest prior NMT master device will always be the actual NMT master.
Part 3 of CiA 302 specifies the program download and configuration manager. These additional functions are used in decentralised control systems where one entity - the CANopen manager device - configures all devices after power-on. In extreme circumstances, the CANopen manager always downloads the entire application into the connected devices. This guarantees that all application programs are compliant with each other. Otherwise one substituted device may use a software version that is not consistent with the software running in some other devices. The software download is performed by means of segmented SDO communication. There are special object dictionary entries reserved for up to 254 application programs. Other entries in the object dictionary provide optionally information of the software version, date, etc.
In part 4, the use of network variables is described. Programmable devices have no pre-defined process data. For that reason, the object dictionary provides in the address range from A000h to AFFFh network variables. After device programming, they have a specific meaning and may be mapped into PDOs are accessed by means of SDO communication. Network variables are the process image of programmable devices. In CANopen networks, there may be installed several programmable devices. They may even share simple pre-programmed I/O modules, sensors or actuators. This is then a real distributed control system with several application masters.
Part 5 specifies the SDO manager, an additional CANopen function for NMT master devices. The SDO manager is necessary if a simple CANopen device with just the SDO default server needs to be configured online by an external tool. In this case the tool rents the corresponding SDO client from the NMT master device. This avoids two devices accessing the simple CANopen device using the same CAN-IDs. increasingly, more sophisticated CANopen manager devices are supporting the SDO manager function.
Part 6 defines Bus-line redundancy, as requested in marine and other mission-critical application fields. There is a default bus-line and a redundant bus-line. If the default bus-line is corrupted, all connected devices automatically switch to the redundant bus-line. An additional PDO error counter is used to decide when to activate the redundant bus-line. The first applications to combine bus-line redundancy and safety-related communication as specified in CiA 304 (CANopen Safety protocol) are in trains.
Part 7 describes the CANopen-to-CANopen router and bridge functions. The original request came from companies that have cascaded several CANopen networks - for example, in mining machinery. Regarding SDO and Emergency communication, it is a router function. PDOs are forwarded with the bridge functionality; this means the content of the PDOs are not changed; only the CAN-ID may be changed. The SDO router function requires an additional SDO command, which is sent before the normal or expedited SDO. This SDO router command indicates which device in which network shall be addressed by the following SDO. Of course, the system designer must configure the router by means of router tables. The same has to be done for remote emergencies, which are forwarded by the router to another network. The number of networks in hierarchical or meshed network systems is limited to 127. The configuration of router/bridges devices can be locked in order to avoid accidentally configuration failures.
With the additional CANopen functions defined in the CiA 302 specification set, CANopen users can design complex and sophisticated network systems that are suitable for mission-critical applications. Some of these functions are required in rail-vehicle applications, which is an increasingly important application field. That is why CANopen will be internationally standardised as an in-vehicle network for locomotives, coaches and train-sets (IEC CD 61375-3-3). The additional CANopen application layer functions are also suitable for industrial automation applications; for example, in distributed embedded machine control systems.
