CANopen-based Distributed Intelligent AutomationK. Etschberger, C. Schlegel, IXXAT Automation

First the main benefits of distributed processing will be discussed and the require-ments summarized, which have to be met for the implementation of intelligent distrib-uted systems. With the additional CANopen standard DSP 302 a framework for distrib-uted systems is now specified which, besides other items, comprises the introductionof network variables, the support of program download and control, a standardizedsystem boot-up procedure as well as the definition of a configuration managementinstance. As system configuration is one of the most important practical aspects forthe establishment of distributed intelligent systems, an introduction into the configu-ration process of those systems will be given and a versatile configuration tool shortlypresented. Finally, it is shown how the implementation of programmable CANopendevices can be facilitated considerably on the basis of an available CANopen Mastersoftware package.

1. Benefits and Requirements of Distrib-uted Intelligence

Distributed processing in automation sys-tems today is still not widely in use. Onereason is that popular fieldbus communi-cation systems do not efficiently supportmulti-master communication. On the otherhand, there are many advantages of dis-tributed intelligence. CAN-based commu-nication systems supporting producer-consumer oriented communication arewell suited for the establishment of sys-tems with distributed intelligence. Themain benefits of distributed processingare:

���� Lower processing requirements andhigher system performance, respec-tively: Since in a system with distributedintelligence the overall processing task isdistributed to a number of processingunits, the processing load of each unit isconsiderably lower than in a system withonly one central processing unit – or at thesame processing capacity per processingunit, a much higher system performance ispossible.

���� Higher modularity and flexibility: In awell designed distributed intelligent auto-mation system processing capacity it allo-cated to independent functional units orsubsystems. Therefore adding and ex-tending of further functional units or sub-systems should be much simpler than insystems with central processing.

���� Easier system development, installa-tion and testing: Due to the implementa-tion of the system in form of independentfunctional units or subsystems develop-ment, installation and testing of the inde-pendent functional units can be accom-plished in parallel. Since the processing islimited to smaller subsystems, programdevelopment should be simplified as welland integration of the subsystems shouldbe much easier than with a centrally con-trolled system.

���� Better real-time behavior: Due to thelocal processing capacity even very timecritical tasks, like closed-loop control canbe performed on a system with distributedprocessing.

���� Lower bus load and lower bit rate re-quirement, respectively: A system withdistributed processing does not need totransmit each single signal or event via thecommunication system to a central controlunit, since most of the processing is per-formed directly at the remote subsystems.This should result in a considerable reduc-tion of the bus load or alternatively in areduction of the bit rate.

���� Higher system availability: If it is pos-sible to organize the system into highlyindependent subsystems or functionalunits, the system can remain at least par-tially operational even when one subsys-tem or functional unit fails. In a centrally

controlled system, a failure of the centralcontrolling unit causes the failure of thecomplete system.

Of course, distribution of intelligence is notwithout costs. Besides the non-availabilityof the appropriate technology certainly thehigher costs of utilizing multiple processingunits was one of the main reasons for therelatively minor usage of distributed intelli-gent systems until now. In addition, thereare several specific requirements for dis-tributed processing, such as:

• Globally (network-wide) accessible pro-gram variables

• Support of system configuration andprogramming by efficient tools

• Powerful network management func-tionality featuring plug-n-play capabili-ties

• Support of program download and re-mote program control

In the following, it is shown that with theextension DSP 302 of the CANopen stan-dard a comprehensive framework for theimplementation of distributed intelligentsystems is provided; also efficient systemconfiguration tools and universal, cost-efficient processing devices and I/O-modules based on DSP 302 are nowavailable in the marketplace.

As an example, Figure 1 shows a coalconveyor plant, which is completely con-trolled by a CANopen-based automationsystem according to DSP 302. The sys-tem, developed and installed by theHelmut Mauell company [1], comprises 11IEC-61131-3 programmable control unitsand 44 universal I/O modules. The com-plete system consists of more than 1000data points and 280 network variables.More than 500 PDOs have been estab-lished for the transmission of process dataand network variables more than 500PDOs have been established.

Figure 1: Coal conveyor plant of the harbor powerplant, City of Bremen/Germany, controlled by aCANopen-based automation system with distributedintelligence (Foto: Helmut Mauell GmbH).

2. CANopen DSP 302: A Framework forDistributed Intelligent Systems

The CANopen Communication Profile [2,3] specifies the basic mechanism for ex-changing process and service data via theCAN bus. The Communication Profile alsodescribes the heart of the CANopen stan-dard, the CANopen Object Dictionary (OD)which provides a standardized descriptionof any communication and application pa-rameters, data and functions of a CAN-open device which are accessible from theCAN bus via so-called Service Data Ob-jects (SDOs). Also services for networkmanagement, emergency messaging, theprovision of a global system time and syn-chronization are specified in this part ofthe standard.

Within an additional framework for pro-grammable CANopen devices, specified in[4], further functions are specified for theimplementation of distributed intelligentsystems. Main parts of this specificationare the

• Definition of “Network variables”• A mechanism for program download

and program control• A standardized system “Bootup-Proce-

dure” as well as functions for configura-

tion management and the dynamic es-tablishment of SDO-channels.

For IEC 61131-3 compatible programma-ble devices a detailed application profile isbeing specified in [5].

2.1 Network Variables

As the most essential requirement for dis-tributed intelligence the interaction be-tween application programs running ondifferent nodes of a network must be pos-sible. This means that an application pro-gram on node X can communicate directlywith an application program on node Y justby reading or writing of a common vari-able. Of course, this variable has to bedeclared on both application programs as“remote” or “external” or, according toCANopen, as “Network Variable”. There-fore CANopen DSP 302 specifies vari-ables which may be accessed via the net-work as a new type of application objects,to be described in the object dictionary ofa programmable device. Since the usageof network variables cannot be specifiedbefore programming of an application, aprogrammable device only can provide themeans for specifying of network variablesin its object dictionary. Thereby the spe-cific attributes of a network variable are itsdirection (input or output) and its datatype. Network variables are mapped intothe object dictionary in form of data direc-tion - and data type -specific index-seg-ments. DS 302 does not specify where inthe index range of the object dictionarynetwork variables are to be described. Asan important type of standardized pro-grammable devices DSP 405 [5] specifiesthis for IEC 61131-3 compatible program-mable devices. There, for any of thespecified data types 64 main-indices witheach 254 sub-indices are available. This isshown in Table 1. A further introductioninto this topic is given in [6].

Table 1: Mapping of input network variables into theCANopen Object Directory according to IEC 61131-3 compatible devices

Start Index Data TypeA000H Integer8A040H Unsigned8A080H BooleanA0C0H Integer16A100H Unsigned16A140H Integer24A180H Unsigned24A1C0H Integer32A200H Unsigned32A240H Float32A280H Unsigned40A2C0H Integer40A300H Unsigned48A340H Integer48A380H Unsigned56A3C0H Integer56A400H Integer64A440H Unsigned64

Figure 2 shows the relationship between alocal application program with remote ap-plication programs via network variables.Remote or external input and output vari-ables defined in a local application pro-gram refer to network variables located inthe object dictionary of the local CANopenInterface. Network variables are denotedaccording to the direction as seen from thenetwork. Therefore input network variablesare seen as inputs to the network. Thiscorresponds to outputs of the local appli-cation programs and inputs of the remoteapplication programs, respectively andvice versa.

Figure 2: Definition of CANopen input andoutput network variables

Most programming systems support amechanism for the definition of resources.This can be used to assign the CANopenattributes of a Network Variable like in-dex/sub-index of the location in the ODand its associated data type to the corre-sponding symbolic name of a variable inthe application program. Based on a user-friendly system configuration tool this canbe accomplished by importing a so-calledDevice Configuration File (DCF) createdas the result of the configuration process(See 3.1).

In order to allow programmable devicesthe usage of a so-called “process image”for input and output variables – a methodwhich is especially common for PLCs - arelationship between the process imageand the location of the network variables inthe CANopen OD is necessary. The net-work variables storage capacity of a pro-grammable device is described in the sec-tion “Dynamic Channels” of the ElectronicData Sheet (EDS) of the device. Besidesthe number of storage segments available,the data type, direction, index range, offsetrelated to the base address of the processimage and maximum number of objectswhich can be allocated are specified foreach segment.

After configuration of a programmable de-vice, i.e. allocation of the used networkvariables, the specified variables in com-bination with the information of the EDS isprovided by the Device Configuration File(DCF) for usage in the application pro-gramming system.

2.2 Program Download and Control

Downloading of a complete applicationprogram or parts of a program, for exam-ple from a system configuration tool, mayalso be considered as a mandatory capa-bility of a distributed intelligent system. Tosupport this feature, a device needs toprovide only a basic CANopen bootstrap-loader.Downloading of the program code anddata is supported by means of a standardSDO transfer protocol, e.g. the SDO blocktransfer protocol, by addressing the spe-cific “Download Program Data” - object

(Index 1F50H) in the OD. With up to 254sub-indices the downloading of up to 254different application programs or parts ofthem is possible.

For controlling of a remote applicationprogram via the bus, the “Program Con-trol” – object (Index 1F51H) has to be ad-dressed. By writing a specific control wordto the corresponding sub-index starting,stopping or resetting of a specific programis possible.

With a third object (1F52H), the “VerifyApplication SW” – object, the latest dateand time of an update of the applicationprograms can be stored.

2.3 Network and Configuration Manage-ment

Network Management

The network management in a CANopensystem is organized in form of a master-slave relationship between a node whichacts as the master – this node is called a“NMT-Master” – and the other nodeswhich act as slaves (“NMT-Slaves”).Please note that the master/slave featureonly refers to network management. Net-work management in the context of aCANopen system comprises the functionsof controlling and monitoring the commu-nication status of the nodes.

Since in such a system only one devicecan perform the NMT-mastership, butseveral devices may have the capability todo this, it is necessary to have the possi-bility to configure this functionality. For thispurpose a specific “NMT-Start-Up” – ob-ject (1F80H) has been defined to specifythe NMT-mastership as well as the spe-cific start-up behavior of an assignedNMT-Master. It should be mentioned here,that there is also a pending standardiza-tion proposal for a “Flying-Master” featurefor CANopen networks. It is intended thatthis feature will get an optional part of DS302.

Standardized System Boot-up

As a further extension to DS 301, DSP302 introduces a standardized systemboot-up procedure to be performed by theNMT-Master during initialization of aCANopen system. To perform these func-tions, the NMT-Master needs to knowwhat nodes (NMT-Slaves) are to be man-aged. This information together with fur-ther data is available to the NMT-Master inform of several network related objects.

The first of these objects, the so-called“Slave-Assignment”- object (1F81H) pro-vides information about the slave nodesassigned to the NMT-Master, how theyhave to be booted (there are severalbooting options), specifies the differenterror control parameters and the re-quested actions in case of an error controlevent detected by the NMT-Master.

There are further data structures (objects)specified for checking the system identifi-cation such as Device Type, Vendor Iden-tification, Product Code, Revision Numberor Serial Number of any of the devices.This information is used by the NMT-Master to verify the correct system con-figuration during each system boot-up.

Figure 3 shows only the basic principle ofthe system boot-up-process with somesimplifications.

Reset Communication all nodes

set NMT master operational

yes no

for all nodes assigned to the NMT master

haltnetworkboot-upprocedure

set network operational

Boot Slave Procedure ( see Fig. 4 )

start network ?

error status o.k. ?yes no

notify error status

all mandatory nodes booted successfully ?yes no

Figure 3: CANopen system boot-up procedure (onlybasic principle)

First the NMT-Master performs a reset ofthe communication interface of any of theassigned nodes to ensure a properly de-

fined environment. Then, any of the as-signed slave devices are booted individu-ally. The basic principle of this procedureis shown in Figure 4.

Request device type

response received ?

check identity objects (if required)

yes

error status o.k. ?yes

yes

yes

no

no

no

no

check configuration

notifyapplication

notifyapplication

notifyapplication

notifyapplication

mandatory node ?

error status o.k. ?

repeatcyclicallybooting of slave until

slaveresponseuntil boot

time expired

start error control( node guarding / heartbeat )

start slave individually ?

yes no

set node operational

Figure 4: CANopen Slave boot-up procedure (prin-ciple)

To boot a Slave device, the NMT-Masterchecks the Device Type by reading of the“Device-Type”- object (1000H) of the de-vice and compares it with the device typestored in the corresponding network iden-tification object. If there is no response tothe Device Type read request and the de-vice is mandatory, the application processis notified and the system boot-up processstopped after expiration of the “boot-up”-time. If on the other hand a non-mandatorydevice does not answer a read DeviceType request, the read request is repeateduntil the slave is found or the applicationprocess stops polling. This allows thesystem to identify even devices which arelater connected to the network.Of course, if the device type of a nodedoes not correspond to the stored devicetype, the application is notified and theSlave boot-up procedure stopped.

After a successful verification of the devicetype further identification data of the de-vice is checked, in case this data is pro-vided by the device.

Optionally (not shown in Figure 4) theSlave boot-up process continues withverifying the version of the applicationsoftware including an automatic update ofthe application software in case of a ver-

sion inconsistency. This function is per-formed in cooperation with the Configura-tion Manager (CM). The function of theCM is described later.

After the successful verification of theidentification data, the device configurationdate and time parameters are being readby the CM. If the CM detects a mismatchof this data with the corresponding valuesstored by the CM, or if the CM is re-quested to configure the device with eachboot-up, it initiates downloading of theconfiguration data to the device.

After a successful verification or down-loading of the device configuration datathe Slave error control services are finallystarted by the NMT-Master. In case thatthe device refers to the Heartbeat protocol,the reception of a Heartbeat messagewithin the NMT-Masters Heartbeat Con-sumer Time is being checked. If the devicesupports Node Guarding, it will be startedright after.

When all nodes are successfully booted(see Figure 3) the NMT-Master sets itselfand all its assigned Slaves into the “op-erational” state. Now the transmission ofprocess data via PDOs is enabled.

The Configuration Manager

The main function of the ConfigurationManager (CM) is to configure a deviceduring boot-up if requested. Therefore theCM uses the configuration data providedby the Device Configuration File (DCF) ofthe device. If the CM is not located on thecomputer used for setting-up the DCF, it isnecessary to transfer the DCF via CAN-open. The DCFs of the network devicesare written to the CM, e.g. by a configura-tion tool via the “Store DCF” – object(1F20H) with the sub-indices correspond-ing to the node-ID of the devices. TheDCF of a device can be read from the CMby reading the “Store DCF” – object withsub-index according to the node-ID of thedevice. A DCF can be stored “as it is” or incompressed form.

To further reduce the storage require-ments a concise configuration data format

is specified in DSP 302. This format doesnot contain all of the information includedin the DCF. The information to be storedconsists of the parameter values of theobject dictionary entries which differ fromthe default values and is written to the CMin form of a stream of data to the “ConciseDCF” – object (1F22H) with the sub-indexequal to the node-ID of a device.

To allow the CM to determine whether adevice needs to be reconfigured, DS 301provides the “Verify Configuration” – object(1020H). If a device supports the savingof parameters in non-volatile memory, theCM uses this object to verify the configu-ration after a device resets and to deter-mine if a reconfiguration of the device isnecessary. Therefore the configurationtool has to write date and time of the con-figuration in this object.

To check the validity of the configurationdata of a device after a reset, the CMreads the “Verify Configuration” – object ofthe device and compares the values of thisobject (date and time of device configura-tion) with the expected values for date andtime, stored in the CM objects “Expected-ConfigurationDate” (1F26H) and “Expect-edConfigurationTime” (1F27H) by theConfiguration tool. If the expected valuesare zero or not identical with the values ofthe “Verify Configuration”- object, the CMstarts downloading the configuration datafrom the DCF of the device.

3. Configuration of Distributed Systems

Based on the concept of the object dic-tionary and a complete free choice of typeand structure of communication relation-ships between application objects, CANo-pen provides a very high degree of flexibil-ity with respect to device and system con-figuration.

On the other hand, this high flexibilitymakes configuration of a CANopen systema rather complex matter if this is not sup-ported by a configuration tool. This is es-pecially true, for the configuration of dis-tributed intelligent systems with more thanone interacting programmable device anda complex communication structure. A

more detailed discussion of this topic isgiven in [3].

3.1 The Configuration Process

The main steps for the configuration of aCANopen-based automation system are:

• Definition of the network configuration:Selection of the devices on the net-work, allocation of node-Ids and baud-rate.

• Configuration of the specific devicefunctionality. For programmable de-vices this includes the definition of therequired network variables.

• Set-up of the communication relation-ships between all application objectsshared across the network and of therequired service data channels be-tween devices.

Figure 5 illustrates the basic task of set-ting-up the communication relationshipsfor transmission of process data (applica-tion objects) between two intelligent de-vices. This process includes the followingsteps:

• Definition of the required input andoutput network variables according tothe application programs running onthe programmable devices.

• Mapping of the producer applicationobjects (input network variables and/orlocal process inputs) of both devicesinto appropriate Transmit PDOs(TxPDOs). Generally, several applica-tion objects can be mapped into oneTxPDO. Also the transmission mode(e.g. asynchronous, synchronous) ofthe TxPDO has to be selected.

• Mapping of the consumer applicationobjects (output network variables or lo-cal process outputs) of both devicesinto appropriate Receive PDOs(RxPDOs). Of course, there can bemore than just one consuming device.In that case any of the other consum-ing devices also need to be configured

• Allocation of appropriate CAN-Identifiers to each TxPDO and the cor-responding RxPDO

Figure 5: Mapping of network variables into PDOsand PDO-Linking

The described basic process of configur-ing the transmission of process datashows, that configuring a distributed intel-ligent CANopen system without a configu-ration tool is not very efficient. The nextsection will introduce an existing CANopenconfiguration tool.

3.2 System Configuration by means of aCANopen Configuration Tool

With the PC-based CANopen Configura-tionStudio offered by IXXAT Automation[7] a powerful configuration tool for theconfiguration of intelligent CANopen sys-tems is available. When the system iscombined with a programming system,e.g. for PLC programming, not only con-figuration but also programming of distrib-uted intelligent CANopen systems is pos-sible. Based on an efficient data basesystem, the consistent storage of Elec-

tronic Data Sheets, as well as further,project-specific information is ensured.

Via the tool’s Control Panel the basicadministration of several projects is pro-vided. Further functions of the ControlPanel are: Selection and control of thedifferent tools, structuring and definition ofnetworks, handling of Electronic DataSheets and Device Configuration Files,allocation of node-Ids to network devices,definition of the baud rate as well as utilityfunctions like Windows and file handlingoptions.

The following plug-ins are available:

• Object Dictionary BrowserWith this tool browsing of the CANopenobject dictionary of a device is possibleand object dictionary entries can be easilyedited.

• Device ConfiguratorThis tool specifically supports editing adevice’s communication and applicationparameters, PDO-mapping and PDO link-ing.

• Visual Object LinkerWhereas the usage of the Object Diction-ary Browser and the Device Configuratoris mainly of interest for someone familiarwith CANopen (like developers), the VisualObject Linker tool (Figure 6) very effi-ciently supports the configuration of com-munication relationships between processdata and/or network variables on the ap-plication level. Therefore this tool requiresalmost no knowledge of CANopen. Withthe Visual Linker it is only necessary tolink the producer application object (like aspecific Output Network Variable) to oneor more consuming application objects.Mapping of the application objects into aTxPDO, allocation of CAN identifiers toTransmit and Receive PDO as well as de-mapping on the consumer side is per-formed automatically by the Object Linker.Therefore, the CANopen communicationmechanism are completely hidden. TheObject Linker also supports the definitionof network variables and the export ofspecified variables to an integrated or ex-ternal programming system.

• Network Access InterfaceThis plug-in builds the interface to aCANopen network and provides functionsfor down- and uploading of configurationand program data, scanning of a network,verification of device configurations, net-work and program control as well as LayerSetting Services.

Figure 6: IXXAT CANopen ConfigurationStudio,Object Linker plug-In.

4. Implementation of ProgrammableCANopen Devices

Since “intelligent” functions in a distributedCANopen system are located mainly onprogrammable devices like PLCs or HMIdevices, these devices should principallybe able to perform the function of aCANopen Master as well as that of aCANopen Slave. Based on the CANopenMaster software package of IXXAT Auto-mation the implementation of a CANopencontroller device is considerably facilitated.In addition to the basic functions sup-ported by standard CANopen softwarepackages, the IXXAT CANopen Mastersoftware package (Figure 7) includes allthe additional functions necessary for thecontrol of distributed intelligent systems.

The included Network Manager provides aconfigurable, standardized system boot-upprocedure, the Configuration Manager theconfiguration functionality as defined inCiA DSP 302.

The CANopen Kernel comes with a uni-versal application programming interfacefor integration with the PLC run time sys-tem and the application program, respec-tively, consisting of a “Process Image” asthe interface for process data, as well as acommand and a diagnosis interface (Fig-ure 7).

Figure 7: Software architecture of the IXXATCANopen Master software package

The command interface actually consistsof two command buffers: One for localcommands and one for commands trans-mitted by means of SDOs. Via the localcommand buffer the application programcan control the different functions of theCANopen Master software package. Typi-cal commands of this type are, for exam-ple, requesting the storage of configurationdata, starting the boot-up process or re-questing information about the automati-cally configured Process Images.

Through the remote command buffercommands the reading and writing of theobject dictionary entries of the local andremote nodes is performed.Each command returns a confirmationvalue which indicates the successful ornon-successful execution of the commandin the corresponding confirmation buffer.

The diagnosis and error Interface servesto inform the application program aboutthe error statuses of the Master softwarepackage, the communication system andthe nodes. This interface also providesnode emergency messages and error sta-tistics as well as the nodes configurationstatus and many further status data.

Via the Process Images Input and Output,the application program exchanges proc-ess data with the CANopen kernel, whichis responsible of transferring the processdata between the process images and theremote nodes. The process images areimplemented in form of a global datastructure accessible by the PLC run timesystem and the Master software package.

5. Summary

With CANopen DSP 302 a versatileframework for the implementation of dis-tributed intelligent automation systemsbased on CANopen is available. This in-cludes sophisticated features like networkvariables, standardized system boot-up,automatic reconfiguration and programdownload and control. In addition, efficientsystem configuration and programmingtools are available in the market as well aspowerful software packages for the im-plementation of programmable CANopendevices. Therefore, due to the manybenefits of distributed intelligent systems,it is expected that CANopen-based auto-mation systems with distributed intelli-gence will become more and more popularin the near future.

References

[1] http://www.mauell.com

[2] CiA Draft Standard 301, CANopen –Communication Profile for Industrial Sy-stems, Version 4.01, 6/2000

[3] Etschberger, K.: Controller Area Net-work, Basics, Protocols, Chips and Appli-cations. IXXAT Press, 2001. ISBN3-00-007376-0

[4] CiA Draft Standard Proposal 302:Framework for Programmable CANopenDevices, Version 3.0, 6/2000. CAN-in-Automation

[5] CiA, Draft Standard Proposal 405:Interface and Device Profile for IEC61131-3 Programmable Devices. Version2.0, 2/2000

[6] Etschberger, K., Eberle, J.: CANopenbecoming intelligent with IEC 1131-3. CANin Automation. Proceedings of the 5th in-ternational CAN Conference. 11/98.

[7] http://www.ixxat.de

Prof. Dr.-Ing. K. EtschbergerIXXAT Automation GmbHLeibnizstr. 15D-88250 Weingartene-mail: etschberger@ixxat.dePhone: +49-0751-56146-0Fax: +49-0751-56146-29web: www.ixxat.de

Dipl.-Ing. Ch. SchlegelIXXAT Automation GmbHLeibnizstr. 15D-88250 Weingartene-mail: schlegel@ixxat.dePhone: +49-0751-56146-0Fax: +49-0751-56146-29web: www.ixxat.de