SDS, DeviceNet and CAN Kingdom A brief comparison by Kent Lennartsson and Lars-Berno Fredriksson, © KVASER AB
	[You are here: Home > CAN Index > Higher Layer Protocols > SDS-DN-CK]
	The KVASER company started working with CAN in 1989 after five years of experience in distributed control systems. CAN is not a complete protocol for distributed control systems. A "Higher Layer Protocol" is always needed. In 1990 KVASER started developing such a protocol with the aim: System designers may design their CAN systems to their own ideas, still using independently developed "standard" modules. The next year the first edition of CAN Kingdom was issued and the current version is 3.0. Both Honeywell and Allen-Bradley recognized the need for a higher layer protocol and have respectively presented "Smart Distributed System" (SDS) and DeviceNet. We often get questions about the difference between CAN Kingdom, SDS and DeviceNet. It may seem improper that we do a comparison between our own higher layer protocol and the other two but as nobody else has published such a comparison, we have decided to do it. The protocols do not really compete. The question: "Which of the CAN higher layer protocols is the best one?" is like "Which way is best for transportation: Car, boat or airplane?" The answer depends on what problem should be solved. At KVASER we are currently working with all three protocols in different projects. In fact, DeviceNet and SDS (and J1939) modules can be integrated into CAN Kingdom systems (but not vice versa.) Overview DeviceNet, SDS and CAN Kingdom are all based on the ISO 11898 CAN communication protocol and circuits meeting the CAN specification. This implies that modules following any of the protocols can be connected to a very same CAN-bus. However, when modules following different protocols are connected to the same CAN bus, most often problems will arise due to conflicting interpretation of messages at the application level. CAN Kingdom differs from SDS and DeviceNet in one major principle way: CAN Kingdom assumes the presence of one node organizing the system (the "King") during start-up, SDS and DeviceNet does not. The presence of a "King" simplifies the design work of complex realtime systems and reduces the needed number of module coordinating specifications, often called "profiles." SDS is very effective when it comes to connect I/O devices (e.g., on/off switches, proximity sensors, etc.) to a PLC, as SDS fundamentally is a point to point communication between a master (Host) and remote I/O:s. DeviceNet is basically an open bus system where all modules have the same right to use the bus and the use of the bus is only restricted by a few rules. A module designer can give away communication control to other modules, e.g., to a master in the Predefined Master/Slave mode, but there is nothing in DeviceNet that forces modules into such behavior. The characteristics of DeviceNet are very close to SDS when it is used with I/O-devices following the DeviceNet subset "Predefined Master/Slave Connection Set." CAN Kingdom is a protocol concentrating on generating, linking and controlling systems and does not include profiles for devices like digital and analog devices. The fundamental part of CAN Kingdom is that a module, when connected to a system, has no right to do anything at all but waiting for instructions from the King. All CAN priorities/IDs are owned by the King. During a startup sequence each module is configured by the King assigning priorities/IDs to consuming or producing objects in the module. A King is like a master, but only during the configuration of the system. The King may not be involved in runtime communication between working applications in different modules. The King can then often be removed after configuration and consistency checks have been made and each module has stored its received instructions in a non-volatile memory. Node numbers CAN does not need any physical addresses, e.g., node numbers, for communication. This is an important feature of CAN as then modules do not have to have any knowledge about the system in which they are working. However, during the configuration of a system and often also at service, specific nodes have to be addressed. For this purpose at least one CAN priority/ID has to be reserved and each module has to be assigned a node number. For configuration and service messages to and from modules it is convenient relating addresses to node numbers. CAN Kingdom, DeviceNet and SDS are all using this technique. Node numbers can be assigned in several ways and some suggestions are made in the list below: DIP switches Drawbacks: High probability for human errors and errors due to bad connection points. Usually there is no checksum detecting errors. Most often a switch has to be protected from ambient environment and then a screwdriver or a similar tool is needed to access the switch. Settings of open switches are prone to be changed by accident. Advantage: The node number can be read by a human without any service instrument. Coding by connector pins. Drawbacks: High probability for human errors and errors due to bad connection points. Usually there is no checksum detecting errors. The setting of a connector can only be read if it is opened or through a window in the casing. Requires documentation on how to encode the setting in the connector. Few combinations are possible. Connector pins are expensive, especially in sealed connectors. Advantages: The coding is stored in the cabling and not in the module. In case of replacement the new module will get the node number at installation. The node number can be read without a service instrument. Stored in an internal memory. Drawbacks: Node number has to be programmed into the module with a tool before it is connected to the system. (If the module has a default number which is not already used in the system, a reassignment when the module is installed might be possible.) Advantages: No window or connector pins are needed for the node number. Usually the number is stored with a checksum in a nonvolatile memory. Low cost as only a few bytes is necessary. The memory can also store other parameters. Memories show a low probability for failures compared with connectors and switches. Stored in a memory in the connector. Drawbacks: No connectors including a memory yet available on the market. One or two additional pins are required in the connector to read the information from the connector. Advantages: The same as for internal memory. If the node address is stored both in the connector and in a non-volatile memory in the module, a very high security against misplaced modules is obtained. The module does not need to be connected to a service instrument before installation. Neither of the three CAN higher layer protocols has specified a method for node number setting. Both the SDS and the DeviceNet specifications describe the use of switches at a module and setting via the CAN bus with some kind of tool. The first DeviceNet module (The Flex-I/O) from Allen-Bradley uses switches. SDS modules from Honeywell use internal storage of the node number that can be changed via CAN. The default node number is 125, the highest node number allowed. (The first SDS modules from Honeywell used zero as default number, which caused new nodes to have the highest priority messages when connected to a system. This has later been changed.) The DeviceNet specification allows for modules having their node number stored in a memory. The default number is then 63, also the highest node number allowed. SDS does not have any test or checking for duplicate node numbers. SDS always assumes a host to each I/O-module and this host has to make all needed checking. By reading the vendor number and the serial number from all devices, it can be checked whether duplicate node numbers exist or not. Either a change of an I/O-module's node number may be performed by the host, or the system can be shut down. When more than one host in a system, some communication between the hosts has to take place in order to secure that the I/O node numbers are unique. In DeviceNet each module is assigned some priorities/IDs to be used for its messages. These IDs are given as a function of the node number (in DeviceNet called MAC ID). It is important that no modules use the same MAC ID as they would then use the same CAN IDs for transmissions, violating the CAN specification. A procedure at startup, called "Duplicate MacID check," secures a system from duplicate MAC IDs: If a node, with a MacID already in use in the system, makes the duplicate MAC ID check it will receive a message telling "Get off the bus!" from the module already using the same MAC ID. In CAN Kingdom all priorities/IDs but one receive ID for "the King's message" are owned by the King at start-up. Every module listens for "the King's message." Thus no node can make any communication before the King has allowed. The King can make a consistency check of the system before distributing identifiers and other setup parameters. If any modules having the same node number are detected, the King can rename them or disable them from any further use of the bus. When modules unknown to the King or missing nodes are detected, the King can refuse to start the system. CAN Kingdom makes it possible for a system designer to design a safe system with "Plug and Play" capability for the end user. Both SDS and CAN Kingdom assume some kind of machine control system with at least one supervising node that can check the system. Usually it is no use to start a node if it is not known to the system or if a supposed module is missing. Even if all modules are there but at incorrect places, it is no use to start the system. The checking task is simplified if the node numbers are stored in the bus connectors. Each connector represents a certain place in the system. Any misplaced module can then be detected as each node number is matched to a module type (or even a specific individual). By having the node number stored both in the connector and in the module, recognizing any change made in the system, accidentally or not, is possible. It also has to be a double fault of the node number before a module is lost from the system. Bit Rate In a CAN network it is important that all modules are set to the same bit rate. Next to shortcutting the CAN bus the simplest way to destroy communication is to install a node set to an incorrect and very low bit rate. Usually the consequence is all other modules going OFF-BUS. SDS, CAN Kingdom and DeviceNet suggest different methods to avoid such a situation. SDS describes a recommended practice for "autobauding." The bit rate is set by the master with the lowest possible address. All other modules will check for the bit timing of bit streams on the bus and set their bit rate accordingly. Four bit rates are recommended: 125k, 250k, 500k and 1M. DeviceNet specifies three bit rates, 125k, 250k and 500k, but no protection against a faulty bit rate setting. Even if not specified, some DeviceNet modules are using autobauding. CAN Kingdom does not specify any predefined bit rates or autobauding. It is specified that a module during the first 200 ms after power-up has to listen passive at 125 kbit with a fixed and specified setting. By this procedure a miss programmed module can always be reached at this fixed setting. Passive communication means that the modules only listen to the CAN communication but are prevented from transmitting dominant bits on the bus. A node set to an incorrect bit rate can then never destroy the communication on the bus. CAN Kingdom also specifies how to change a bit rate. Use of Priority The bus access priority in CAN is given by the first 11 or 29 bits of a message, called the "Identifier field." (A more correct designation would be "Priority field" as bus access priority is the only service specified.) The 11-bit ID is called Standard ID and the 29-bit Extended ID. SDS and DeviceNet specify the use of Std. IDs. CAN Kingdom is specified for use of both Std. and Ext. IDs. SDS allows for 125 modules to be connected to a net and each module is given a set of IDs, related to its node number: Receive IDs from (N·8) to ( N·8+7) Transmit IDs from (N·8+1024) to ( N·8+1031) where N = node number. The list below shows the range of priorities/identifiers specified in SDS for some of the 125 node numbers allowed: Node nr. From Host/Master To Host/Master 0 0-7 1024-1031 1 8-15 1032-1039 . 63 504-511 1528-1535 . 124 992-999 2016-2024 125 1000-1007 2024-2031 The use of 1008-1023 is not specified in SDS. Priorities not owned by a device or a corresponding master can be used without interfering the behavior of any SDS device. Device Net allows for 64 nodes and has a more complex way to distribute priorities/IDs. The IDs are divided into three groups reflecting high, medium and low priorities. In DeviceNet net each module owns a set of each group according to the following formula: Group 1: M·64+N M=[0..15] Group 2: M+1024+N·8 M=[0..7] Group 3: M·64+1536+N M=[0..6] where N is the node number, called MAC ID in DeviceNet. The scheme above will not cover all CAN priorites/IDs.The remaining [1984..2031] are reserved for future use in a Group 4. The scheme forms a bit pattern in the CAN identifier field: Identifier bits                     Identity usage 10 9 8 7 6 5 4 3 2 1 0   0 Group 1 Message ID       Source MAC ID           Message Group 1 1 0 MAC ID           Group 2Message ID     Message Group 2 1 1 Group 3Message ID     Source MAC ID           Message Group 3 1 1 1 1 1 Group 4 Message ID           Message Group 4 (reserved for future use) 1 1 1 1 1 1 1 x x x x Invalid CAN IDs The distribution of IDs to different nodes is shown below: Node nr. Group 1 Group 2 Group 3 0 0,64,128,...960 1024-1031 1536,1600,1664,..1920 1 1,65,129,..961 1032-1039 1537,1601,1665,..1921 . . 62 62,126,190,..1022 1520-1527 1598,1662,1726,..1982 63 63,127,191,..1023 1528-1535 1599,1663,1727,..1983 Each node owns 31 IDs but three of them are reserved for connection establishment and one is reserved for "Duplicate MAC ID Messages." Thus IDs are distributed to all modules in a system a priori. Group 1 and 3 are transmit IDs as they include the source MAC ID but Group 2 might be either transmit or receive IDs, i.e., the owner of a Group 2 ID can choose to use this ID for reception and give it away the right for transmission to another module. Hence, at the start only transmission IDs are distributed. But it takes receivers to form a communication. Obviously there has to be a mechanism for establishing connections that sorts out which IDs to be used for transmit or receive messages at each module. In fact there are two procedures: UnConnected Message Manager and Predefined Master/Slave Connection Set. UnConnected Message Manager (UCMM) UCMM is the recommended method for connecting modules to each other. Two Group 3 messages are reserved for this purpose, one for Unconnected Explicit Request Messages and one for Unconnected Expilcit Response Messages. A module that wants to establish contact with another module sends an Unconnected Explicit Request Message with the MAC ID of the other module in the data field. When this other module detects its MAC ID in the message, it responds with an Unconnected Explicit Response Message. In this process a bidirectional communication is established and each of the two modules will assign one of the free priorities/IDs for the communication. By this bidirectional communication any available information in the modules can be read or written. A module can have many such channels to one or many modules. There is no restriction in DeviceNet about that. A consequence of UCMM is that a module must be prepared to receive 63 different Unconnected Explicit Request Messages, one from any other node possible. The procedure above mirrors the basic idea of DeviceNet as an open bus. By the node number some resources (priority/ID channels) are assigned to the module and it is in total control of these resources. The owner of the system can try to get in contact with the installed modules and kindly ask each module to use certain resources of the bus system, but the final decision is always in the hand of the individual module. All of the 31 priorities/IDs are intended to be used by the module for transmitting and all other are free to be received when a consumption path for the information into the module is established. Predefined Master/Slave Connection Set The UCMM procedure requires all modules to receive 63 priorities/IDs, one from each other possible module in a system, and to accomplish quite a lot of administration services. Such a task requires much computer power and RAM/ROM, too much for a small eight-bit processor with an integrated CAN Controller. To make it possible to use such simple devices in DeviceNet there is an alternative called Predefined Master/Slave Connection Set. One Group 2 message is reserved for this purpose. Usually all MAC IDs in the priority/ID field are the source MAC ID, but this is not always true for IDs in Group 2. Group 2 opens a possibility to use low cost CAN devices capable of only receiving IDs with a partly specific pattern. The MAC ID pattern can then be used for filtration. With a reserved Group 2 message a module can request another module to hand over the transmission rights to two of its Group 2 messages. When accepting the request the module turns these two IDs into receive and the requesting module has now got two new IDs for transmit messages. By this procedure a communication channel is established that requires small computer resources. CAN Kingdom Since birth of CAN there has been a wish for a fully open higher layer protocol that would enable any module just to be hooked on the bus and then start working as a perfect team mate in the system. We are far from such a solution. One major problem is the distribution of identifiers. Both SDS and DeviceNet have taken the approach to make the distribution included in the specification. SDS makes in a simple way but to a high system performance cost. DeviceNet is more flexible but the procedure is more complex and each node owns only a few identifiers to use. Still, one big question remains: "How can a module know which other modules to communicate?" CAN Kingdom has taken another approach than SDS and DeviceNet. One node in a system, the King, is responsible for organizing the system. The King has a complete knowledge about the system architecture and how it should work. At start-up the King owns all identifiers and then distributes these to the modules. As the King knows the connection scheme he assigns a transmit ID to each message a module will transmit and a receive ID to each message a module will receive. This procedure has three major advantages: A module does not have to know anything about the system, the CAN priorities can be used in the most efficient way and even modules designed for some other higher layer protocols (as SDS and DeviceNet) can be integrated into a CAN Kingdom net. Application Layer Both SDS and DeviceNet have specified profiles for many different devices including behavior of and data structures to and from the modules. This is needed as no system responsible node is defined in either protocol. In CAN Kingdom there is always a system responsible node, at least when the system is started for the first time. Instead of specifying how modules should be finally designed, CAN Kingdom specifies how modules can be adjusted to actual systems need, e.g., by profiles for system data like bit rate, node number and priorities etc. Comparisons in tabular form Below some characteristics of SDS, DeviceNet and CAN Kingdom are compared in a tabular form. Bit Rates   SDS DeviceNet CAN Kingdom Possible bit rates 125k, 250k, 500k, 1M 125k, 250k, 500k Any bit rate,Service at 125k Protection against modules with incorrect bit rate. Yes. No Yes Autobaud Yes specified Possible, but not specified. Possible, but notspecified. Changeable by the HLP No Only autobauding. Yes No if set by switches. Yes. Node numbers   SDS DeviceNet CAN Kingdom Possible node numbers. 0-125 0-63 (0) 1-255 Default node number. 125 63 None Set in service mode or read from connector. Protection against duplicate numbers. No/Yes HLP supports checking by the Host. Yes Duplicate MAC ID Check. No/Yes HLP supports checking by the King. Changeable by the HLP Yes. Yes No if set by switches. Yes. Fundamentals about priorities/identifiers etc Property SDS DeviceNet CAN Kingdom Priorities owned by a module at power on. 8 + (8) 31 + (63) 0/1 + (2) Priorities open for general use. None 26 at each module. Any not already used. CAN Remote Transmit Request No No Yes Extended CAN No No Yes System control of priorities. No, given by the selection of the node number. 3 groups containing 16, 5 and 5 given priorities from which to select. Yes, controlled by system design. Free priorities. None None All Start with predefined settings Fixed by the HLP. Always predefined settings. No support by the HLP. Any module is free to do what it wants with the 27priorities/IDs owned by the module. The King can command the modules to start with settings from nonvolatile storage. Automatic start at power on. Yes, after autobaud, by setting the solicited bit Any module is free to do what it wants with the 27priorities/IDs owned by the module. Yes, if allowed previously by the King. This is a degenerated Kingdom. PredefinedPrioritiy/IDs at the start and reserved for the module. At the start:8Tx, 8 Rx From Host: N*8-N*8+7 To Host: 1024+ N*8-N*8+7 At the start:2 Tx, 3 Rx Grp1:N+M*64 M=0-15Grp2:N*8+1024+M M=0-7 Grp3:N+1536+M*64M=0-6 At the start:During the first 200 ms:0 Tx, 2Rx0 and 2031. Then any number as previously set by the King. N= Node number, where N can be any node number used by a module in the system. M=The Message-Id as defined in the DeviceNet specification. System controls Property SDS DeviceNet CAN Kingdom Reset of a module. No Yes, from an established connection. Yes Assigning a module to a group. Yes, 1 group. No Yes, 255 minus the number of modules in the system Setting of CAN reception masks No No Yes. Assignment for priorities/identity from system Property SDS DeviceNet CAN Kingdom Assignment of priority to new connection No Yes, by connection objects, max 26 producer objects. Yes. Only limited by the number of free priorities and module memory. Real-time support Property SDS DeviceNet CAN Kingdom Real Time Clock(RTC). No No. Yes. RTC Resolution     1ns .. 1h RTC deviation between modules     Within 1 bit length. Restricted repetition rates of prioritiy/IDs No No Yes Timed HLP production Yes, 10,24ms [0..255] units Yes, 1ms resolution. Yes, at RTC resolution. Production within a time window. No No Yes, at RTC resolution. HLP production at consumption events No Only in "Predeifned Master/SlaveConnection Set." Yes, at HLP level. Application support Property SDS DeviceNet CAN Kingdom Functions and data structures (Profiles) in HLP. Yes, by Honeywell defined devices. Yes, by ODVA defined devices. No specification. Possibility to build new data structures from application layer primitives. No Yes, it is possible to have an assembly object Yes, HLP includes tools to make new data structures by linking primitives to generic objects. Possibility to have data in the priority bits. Yes, but it is fixed by the HLP No Yes, any bit sequence can be linked to an internal data structure HLP support for Appl. data struc tures larger than 8 byte Yes, up to 255 bytes, max 4 bytes in each transfer Yes, unlimited length. 7 or 6 bytes in each transfer No HLP support. Block transfer No No Yes, unlimited length. Six bytes in each transfer. Multiplexed data No No Yes, by extending identification into the data bytes. Module identity registration Property SDS DeviceNet CAN Kingdom Administrator. Honeywell ODVA EAN International, UCC Vendor Id number 16 bits, 0..65535 16 bits, 0..65535 Incl. in product code. Device type 5*8 bits 16 bits, 0..65535 Incl. in product code. Product code None, see ASCII information. 16 bits, 0..65535 40 bits EAN-13 code. Serial number 32 bit 32 bit 40 bit Software version 12 bit ASCII 16 bit Major16 bit Minor Incl. in or an additional EAN-13 code. ASCII information Date 4 bytes Catalog 32 bytes Vendor 32 bytes Device 32 bytes Product name0 to 255 bytes Not specified   To Summarize SDS Small and effective way to connect small devices to a master controller. Master has 100% control of all modules. No support for communication between modules without a master PLC. Supports only Std. CAN. DeviceNet An open system where each module is a local master. A system designer cannot always get control of the modules (the local master). Supports the production/consumption model for module to module transfer. Limited number (27) of freely usable priorities in one module. A small kernel only in Predefined Master/Slave Connection Set. Supports only Std. CAN. CAN Kingdom The system designer has always 100% control of all modules by "The King." Supports the production/consumption model for module to modules transfers. Possibilities to control the real time behavior on the CAN-bus. Full utilization of the priority function in the CAN protocol. Any number of priorities can be assigned to a module. Support for making data structure conversion in the HLP. Small kernel, typically 500-1500 byte code and 24-48 byte RAM. Supports Std. and Ext. CAN.