CANopen: Автоматтандыру жүйелері үшін коммуникациялық протокол

Computer network protocol
CANopen is a communication protocol stack and device profile specification for embedded systems used in automation. In terms of the OSI model, CANopen implements the layers above and including the network layer. The CANopen standard consists of an addressing scheme, several small communication protocols and an application layer defined by a device profile. The communication protocols have support for network management, device monitoring and communication between nodes, including a simple transport layer for message segmentation/desegmentation. The lower level protocol implementing the data link and physical layers is usually Controller Area Network (CAN), although devices using some other means of communication (such as Ethernet Powerlink, EtherCAT) can also implement the CANopen device profile. The basic CANopen device and communication profiles are given in the CiA 301 specification released by CAN in Automation. Profiles for more specialized devices are built on top of this basic profile, and are specified in numerous other standards released by CAN in Automation, such as CiA 401 for I/O modules and CiA 402 for motion control.

Every CANopen device has to implement certain standard features in its controlling software. A communication unit implements the protocols for messaging with the other nodes in the network. Starting and resetting the device is controlled via a state machine. It must contain the states Initialization, Pre operational, Operational and Stopped. The transitions between states are made by issuing a network management (NMT) communication object to the device. The object dictionary is an array of variables with a 16 bit index. Additionally, each variable can have an 8 bit subindex. The variables can be used to configure the device and reflect its environment, i. e. contain measurement data. The application part of the device actually performs the desired function of the device, after the state machine is set to the operational state. The application is configured by variables in the object dictionary and the data are sent and received through the communication layer.

For simple network structures, CANopen supports a predefined allocation of message identifiers. The transmit and receive directions are from the device's point of view. So a query to a device on the network would send a 0x600+nodeid and get back a 0x580+nodeid. Communication object COB ID(s) hex Slave nodes Specification NMT node control 000 Receive only CiA 301 Global failsafe command 001 ? CiA 304 Flying master 071 to 076 ? CiA 302 2 Indicate active interface 07F ? CiA 302 6 Sync 080 Receive only CiA 301 Emergency 080 + NodeID Transmit CiA 301 TimeStamp 100 Receive only CiA 301 Safety relevant data objects 101 to 180 ? CiA 301 PDO 180 + NodeID200 + NodeID280 + NodeID300 + NodeID380 + NodeID400 + NodeID480 + NodeID500 + NodeID 1. Transmit PDO1. Receive PDO2. Transmit PDO2. Receive PDO3. Transmit PDO3. Receive PDO4. Transmit PDO4. Receive PDO CiA 301 SDO 580 + NodeID600 + NodeID TransmitReceive CiA 301 Dynamic SDO request 6E0 ? CiA 302 5 Node claiming procedure 6E1 to 6E3 ? CiA 416 1 Node claiming procedure 6F0 to 6FF ? CiA 416 1 NMT node monitoring (node guarding/heartbeat) 700 + NodeID Transmit CiA 301 LSS 7E47E5 TransmitReceive CiA 305

Different kinds of communication models are used in the messaging between CANopen nodes. In a master/slave relationship, one CANopen node is designated as the master, which sends or requests data from the slaves. The NMT protocol is an example of a master/slave communication model. A client/server relationship is implemented in the SDO protocol, where the SDO client sends data (the object dictionary index and subindex) to an SDO server, which replies with one or more SDO packages containing the requested data (the contents of the object dictionary at the given index). A producer/consumer model is used in the Heartbeat and Node Guarding protocols. In the push model of producer/consumer, the producer sends data to the consumer without a specific request, whereas in the pull model, the consumer has to request the data from the producer.

The Process Data Object protocol is used to process real time data among various nodes. You can transfer up to 8 bytes (64 bits) of data per one PDO either from or to the device. One PDO can contain multiple object dictionary entries and the objects within one PDO are configurable using the mapping and parameter object dictionary entries. There are two kinds of PDOs: transmit and receive PDOs (TPDO and RPDO). The former is for data coming from the device (the device is a data producer) and the latter is for data going to the device (the device is a data consumer); that is, with RPDO you can send data to the device and with TPDO you can read data from the device. In the pre defined connection set there are identifiers for four TPDOs and four RPDOs available. With configuration, 512 PDOs are possible. PDOs can be sent synchronously or asynchronously. Synchronous PDOs are sent after the SYNC message whereas asynchronous messages are sent after internal or external trigger. For example, you can make a request to a device to transmit TPDO that contains data you need by sending an empty TPDO with the RTR flag (if the device is configured to accept TPDO requests). With RPDOs you can, for example, start two devices simultaneously. You only need to map the same RPDO into two or more different devices and make sure those RPDOs are mapped with the same COB ID.

The Sync Producer provides the synchronization signal for the Sync Consumer. When the Sync Consumer receive the signal they start carrying out their synchronous tasks. In general, the fixing of the transmission time of synchronous PDO messages coupled with the periodicity of transmission of the Sync Object guarantees that sensor devices may arrange to sample process variables and that actuator devices may apply their actuation in a coordinated fashion. The identifier of the Sync Object is available at index 1005h.

Usually the Time Stamp object represents a time as a 6 byte field: a count of milliseconds after midnight (at most 27 bits, stored in a 32 bit field), and an unsigned 16 bit number of days since January 1, 1984. (This will overflow on 7 June 2163.) Some time critical applications especially in large networks with reduced transmission rates require very accurate synchronization; it may be necessary to synchronize the local clocks with an accuracy in the order of microseconds. This is achieved by using the optional high resolution synchronization protocol which employs a special form of timestamp message to adjust the inevitable drift of the local clocks. The high resolution timestamp is encoded as unsigned32 with a resolution of 1 microsecond which means that the time counter restarts every 72 minutes. It is configured by mapping the high resolution time stamp (object 1013h) into a PDO.

Emergency messages are triggered by the occurrence of a device internal fatal error situation and are transmitted from the concerned application device to the other devices with high priority. This makes them suitable for interrupt type error alerts. An Emergency Telegram may be sent only once per ‘error event’, i. e. the emergency messages must not be repeated. As long as no new errors occur on a device no further emergency message must be sent. By means of CANopen Communication Profile defined emergency error codes, the error register and device specific additional information are specified in the device profiles.

Electronic Data Sheet (EDS) is a file format, defined in CiA306, that describes the communication behaviour and the object dictionary entries of a device. This allows tools such as service tools, configuration tools, development tools, and others to handle the devices properly. Those EDS files are mandatory for passing the CiA CANopen conformance test. Since end of 2007 a new XML based format called XDD is defined in CiA311. XDD is conformant to ISO standard 15745.