154 IEEE TRANSACTIONS ON NUCLEAR SCIENCE,VOL 47,NO.2,APRIL 2000 A Universal System for Laboratory Data Acquisition and Controll Francisco J.A.Cardoso Departamento de Fisica,Universidade de Coimbra,3000 Coimbra,PORTUGAL Abstract In analogy with human organisations,monitoring is usually conceived and implemented as a hierarchical chain, A highly distributed system for laboratory test and experiment monitoring and control is presented.The with information filtering up the hierarchy and being SCADA (Supervisory Control And Data Acquisition) consolidated at each stage.Control actions follow the same approach,as typically found in the industrial environment. path,only in the opposite direction.This concept along with was followed to base this design,leading to a rigidly the strict rules which were used to define and articulate structured architecture which proved to be highly manageable modules,as referred to above,inspired the implementation as and robust.Ultimately,a powerful laboratory aid tool was the a typical industrial SCADA (Supervisory Control And Data result of a virtuous combination of a sound modularity Acquisition)system. concept with a communication mechanism based on the However,the major challenge here consisted of the CANopen high-level protocol serving a virtual manner in which experiment setting-up could be carried out, instrumentation strategy so as to keep the standard of software modularity compatible to the one more easily obtainable for hardware.Actually,this line of concern addresses the specific issue of how procedures I.INTRODUCTION can be remotely invoked throughout the different unit levels. Opposite to the typical needs placed by industrial thus involving both code allocation criteria and the automation,laboratory work involves stringent requirements communications media to be used.These considerations have regarding both functional flexibility and time management, led to fundamental design decisions,as follows: thus reflecting the potential diversity of variables involved in Executable code corresponding to the functional each and every experiment.In order to cope with this abilities of each module,according to its specific common difficulty and,still,keep costs at a reasonable level, nature,resides permanently in non-volatile memory a new system has been devised and used under common there located.Hence,there will be no need for any working conditions,in a number of applications fields downloading of executable code prior to initiating an throughout this Physics Department experimental run.Alternatively,on start-up of every Thus,the key issues to this design were: run,short message strings are passed down the Flexibility as the ability to extend the system both hierarchical chain,cach message unit consisting of a physically and functionally; command code and the respective parameters; Potential for parallelism,which is a key factor for A single communications mechanism was selected to system performance,especially in what its link the different units in a system,irrespective of consistency is concerned; time stringency and distances involved:CAN (Controller Area Network-ISO 11898)serial bus The communication mechanism required integrating The option for CAN was due to a number of the separate sub-units,without incurring important factors,such as reliability,real-time performance degradation due to large inter-module response,ease of use and low cost. communication load and probability of message loss These decisions implied the use of CANopen high-level or corruption. protocol,which proved to be a very suitable tool to support Modularity was,therefore,taken to a very high level.The the communication semantics required by what then became whole system was designed conceptually as a set of inter- a complete strategy of virtual instrumentation. communicating tasks,which are logically grouped into functional sub-systems that are mapped onto physical processor modules according to their processing II.THE SYSTEM ARCHITECTURE requirements.Each task executes in a private protected environment and implements a single abstraction for the rest Our major objective of a higher degree of versatility could of the system.Messages are used by modules to request only be achieved through a sound mixed functional-physical services from other modules.The message system provides modularity concept,whose efficiency derived from a duly an efficient mechanism for passing information between balanced hardware-software modularity criterion. processors and synchronising local processes,and encourages Thus,as depicted in figure 1,the overall system consists strong logical separation between tasks. of a number of fully autonomous units distributed over four different hierarchical levels,which are briefly described as iWork supported by both QI,Lda.and.Agencia de Inovacao,S.A. follows (from top to bottom): 0018-9499/00310.00@2000IEEE
154 IEEE TRANSACTIONS ON NUCLEAR SCIENCG, VOL. 41, NO. 2, mnIL 2000 A Universal System for Laboratory Data Acquisition and Controll Francisco J. A. Cardoso Departamento de Hsica, Universidade de Coimbra, 3000 Coimbra, PORTUGAL Abstract A highly distributed system for laboratory test and experimcnt monitoring and control is presented. The SCADA (Supervisoty Control And Data Acquisition) approach, as typically found in the industrial environment, was followed to base this design, leading to a rigidly structured architecture which proved to be highly manageable and robust. Ultimately, a powerful laboratory aid tool was the result of a virtuous combination of a sound modularity concept with a communication mechanism based on the CANopeii high-level protocol serving a virtual instrumentation strategy. I. INTRODUCTION Opposite to the typical needs placed by industrial automation, laboratory work involves stringent requirements regarding both functional flexibility and time management, thus reflecting the potential diversity of variables involved in each and every experiment, In order to cope with this common difficulty and, still, keep costs at a reasonable level, a new system has been devised and used under coininon working conditions, in a number of applications fields throughout this Physics Department. Thus, the key issues to this design were: Flexibility as the ability to extend the system both physically and functionally; Potential for parallclism, which is a key factor for system performance, especially in what its consistency is concerned; The communication mechanism required integrating the scparate sub-units, without incurring performance degradation due to large inter-module communication load and probability of message loss or cormption. Modularity was, therefore, taken to a very high level. The whole system was designed conceptually as a sct of intercommunicating tasks, which are logically groupcd into functional sub-systems that are mapped onto physical processor modules according to their processing requirements. Each task executes in a private protected environment and implements a siiigle abstraction for the rest of the system. Messages are used by modules to request sewices from other modules. The message system provides an efficient mechanisni for passing iiifomation betweell processors and synchronising local processes, and cncourages strong logical separation between tasks. . 'Work supported by both QI, Lda. and .AgBncia de InovapBo, SA. In analogy with human organisations, monitoring is usually conceived and implemcnted as a hierarchical chain, with information filtering up the hierarchy and being consolidated at cach stage. Control actions follow the same path, only in the opposite direction. This concept along with thc strict rules which were used to define and articulate modules, as referred to above, inspired the iniplcmentation as a typical industrial SCADA (Supervisory Control And Data Acquisition) system. However, the major challenge here consisted of the manlier in which experiment setting-up could be carried out, so as to keep the standard of software modularity compatible to the one more easily obtainable for hardware. Actually, this line of concern addresses the specific issue of how procedures can be remotely invoked throughout the different unit levels, thus involving both codc allocation criteria and the commuiiications media to bc used. These considerations have 1cd to fundamental design decisions, as follows: Executable code corresponding to the functional abilities of cach module, according to its spccific nature, resides permanently in non-volatile memory there located. Hence, there will be no need for any downloading of executable code prior to initiating an experimcntal run. Alternatively, on start-up of evety run, short message strings are passed down the hierarchical chain, cach message unit consisting of a command codc and the respective parameters; A single communications mechanism was selected to link the different units in a system, irrespective of time stringency and distances involved CAN (Controller Area Network - IS0 11898) serial bus. The option for CAN was due to a iiumber of important factors, such as reliability, real-time response, ease of use and low cost. These decisions implied the use of CANopen high-level protocol, which proved to be a very suitablc tool to support the communication semantics required by what thcn became a complete strategy of virtual instrumentation. 11. THE SYSTEM ARCIIITECTUKE Our major objective of a higher degree of versatility could only be achieved through a sound mixed functional-physical modularity concept, whose efficiency derived from a duly balanced hardware-software modularity criterion. Thus, as depicted in figure 1, the ovcrall system consists of a number of fully autoiioinous units distributed over four different hierarchical levels, which arc briefly described as follows (from top to bottom): 0018-9499/00510.00 0 2000 IEEE
155 the central management and processing unit, Another key factor for the success of this design was the responsible for data gathering,final validation, basic choice of fieldbus technology to support the different archival and interactive processing,as well as for communications needs throughout the system and, experiment programming and interactive follow-up; particularly,the option for CAN bus.In fact,having been integrating units.which consolidate and originally devised to support communications in automotive appropriately route the information produced at applications,CAN [is particularly suitable in cases like those lower level units under their respective this one,where the network hierarchy implied in the authority; architecture serves the purpose of distributed computing at data acquisition and control units,which digitise device level analogue input signals according to their frequencies Being specified at the two lowest levels of ISO/OSI,as and amplitude range,take notice of events as they detailed in [2]3],CAN supports up to 32 nodes on a twisted- occur,make control decisions and drive actuators; pair cable run of up to 1.9km,at speeds ranging from 20kb/s smart transducers and actuators,to be used whenever to IMb/s.Other major features of CAN are the outstanding variable locations are too far from the main capabilities of error detection,thus leading to increased equipment site. reliability,real-time response,simplicity and low cost. The key to this architecture is a basic cell structure comprising one unit of a certain level and a number of units of the immediate lower level,which adequately replicates so III.HARDWARE IMPLEMENTATION as to encompass all variables and devices in each and every Following the previous basic options,the selection of the application. Embedded communication for the most adequate technology constituted the next step forward. microcontroller-based units within a cell is carried out Having been,at first,based on the Siemens C167CR-16FM through a CAN serial bus,the top-level unit in each network microcontroller,this system is currently being re-designed to also acting as gateway to the respective higher level network accommodate the upcoming C167CS-32FM chip,especially of the same type.Thus,this dual-ported operation facilitates due to the fact that it has two internal CAN units. a multi-buffering scheme,which ensures constant-rate data In fact,the C167 chip is a powerful tool for the flow across the whole system and,therefore,predictable 1/0 development of embedded systems and,due to the fact that it time during both external access and data storage on disk,as is part of the Siemens C166 microcontroller family,a number required by real-time operation. of good quality software development tools are easily available on the market.This work,in particular,has been realised with recourse to a set of tools (assembler,C and C++ compilers,and debuggers)from TASKING [6].Some of its aE-L Process most notable features are: configuration High execution performance in general (machine and cycle of 100ns)and,especially,in branching supervision instructions processing.Also,context switching in response to interrupts is more rapidly carried out through increased flexibility in register bank handling; Extensive memory addressing capabilities:in a total Process amount of 16Mbyte addressable memory,it provides access to both on-chip 2kbyte of RAM and 256kbyte integrator of FLASH memory,the rest of the addressable space being available for external memory; Built-in multiple priority interrupt manager,featuring different dedicated interrupt control registers,which allow 'clean'prioritising of interrupt sources; The availability of 11I parallel I/O lines,which can be used for general purpose as much as for integrated peripherals 1/O,or alternatively,when the device is programmed as a microprocessor,as external buses; Internal timer units which,duly associated with Process special capture/reload registers,can be used for plain timing,pulse width measurement,event counting, etc. Figure 1:The overall system architecture
155 Another key factor for the succcss of this design was the basic choice of tieldbus technology to support thc differcnt communications needs throughout the system and, particularly, the option for CAN bus. In fact, having been originally devised to support communications in automotive applications, CAN [I] is particularly suitable in cases like this one, where the network hierarchy implied in the architecture serves the purpose of distributed computing at device level. Being specified at the two lowest levels of ISO/OSI, as detailed in [2][31, CAN supports up to 32 nodes on a twistedpair cable run of up to I.Okm, at speeds ranging from 20kb/s to IMb/s. Other major features of CAN are the outstanding capabilities of error detection, thus leading to increased reliability, real-time respoiisc, siinplicity iutd low cost. 111. HARDWARE IMPLEMENTATION Following the previous basic options, the selcction of the most adequate technology constituted the next step forward. Having been, at first, based on the Siemens C167CR-16FM microcontroller, this systcm is currently bcing re-dcsigned to accommodate the upcoming C167CS-32FM chip, especially due to the fact that it has two internal CAN units. In fact, the C167 chip is a powerful tool for the development of cmbedded systems and, due to the fact that it is part of the Siemens C166 microcontroller family, a number of good quality sortwarc development tools are easily available on the market. This work, in particular, has been realised with recourse to a set of tools (assembler, C and C+t compilers, and debuggers) from TASKING [6]. Some of its most notable features are: High execution perforinancc in general (machine cycle of 100ns) and, especially, in branching instructions processing. Also, context switching in response to interrupts is more rapidly carried out through increased flexibility in rcgister hank handling; Extensive memory addressing capabilities: in a total amount of l6Mbyte addressable memory, it provides access to both on-chip 2kbyte of RAM and 256kbyte of FLASH memoty, the rcsl of the addressable spacc being avdilable for external memory; Built-in multiple priority interrupt manager, featuring different dedicated interrupt control registers, which allow 'clean' prioritising of interrupt sources; The availability of I1 1 parallel I/O lines, which can be used for general purpose as much as for integrated peripherals 110, or alternatively, whcn the device is programmed as a microprocessor, as external buses; Internal timer units which, duly associated with spccial capture/reload registers, can be used for plain timing, pulse width measurement, event counting, etc. thc central management and processing unit, responsible for data gathering, final vnlidation, archival and interactive processing, as well as for experiment progranrtning and intcractive follow-up; integrating units, which consolidate and appropriately route the information produced at those lower lcvel units under their respective authority; data acquisition and control units, which digitise analogue input signals according to their frequcncies and amplitude range, take notice of events as they occur, make control decisions and drive actuators; smart transducers and actuators, to be used whenever variable locatioiis are too far from the main equipment site. The key to this architecture is a hasic cell structure comprising one unit of a certain level and a number of units of the immediate lowcr level, which adequately replicates so as to encompass all variables and devices in each and every application. Embeddcd cominunication for the microcontroller-based units within a cell is carried out through a CAN serial bus, the top- levcl unit in each network also acting as gateway to the respective higher level network of the same type. Thus, this dual-ported operation facilitates a multi-buffering scheme, which ensures constant-rate data flow across the whole system and, therefore, predictable I/O time during both external access and data storage on disk, as required by real-time operation configuration +- __~__ integrator Controller Figure 1: The overall system architecture
156 Therefore,the SAB-C167CS-32FM chip from Siemens in both data acquisition and control units and smart was selected to support all units involved in real-and limited- transducers and actuators,the motherboard can be time operation,i.e.,those placed at the three lower complemented by (i)a board with capabilities to hierarchical levels.Thus,on one hand,this device is able to handle 16 channels of either digital inputs and digital interface to sensors and actuators via the built-in 1/O ports, outputs,all of them with on-board protection,and(ii) which has led to an overall capability to handle 16 channels a board with capabilities to handle 16 analogue input of each analogue and digital inputs and outputs.On the other channels,with an option for 10-bit or 16-bit hand,it has two built-in CAN bus controllers,as required by resolution,at a maximum sampling rate of 100MS/s the specified architecture. (for a single channel use)and,also,16 analogue Physical modularity was achieved by sharing the basic output channcls with 8-bit resolution. The processor block amongst the three different module types motherboard consists of a 10cmx10cm other than the ccntral management unit.Thus,in physical (approximately 4"x4")card integrating the terms,each unit is made of a motherboard and the daughter- microcontroller,transceivers and interfacing (opto- cards appropriate to the respective functional level (figures 2 couplers)to the two CAN networks,drivers and and 3),as follows: receivers for one RS232E connection with two hardware protocol levels,and a local 5V regulator. in integrating units,the motherboard is complemented by (i)a board with a rcal-time clock Despite the fact that the processor chip is explored either as microcontroller or as microprocessor,this and up to 4 MB of static RAM made non-volatile motherboard is common to all units: with recourse to an on-board battery,and,optionally (ii)an auxiliary board containing the hardware all boards were made to fit in 3U-high Eurocard sub- required to drive a front panel for local human racks.In some application cases,units were housed interfacing; in standard Eurocard plug-in modules (30 height 21HP width,and 16cm depth). Memory Power IV.SOFTWARE IMPLEMENTATION Each of the C167 integrated CAN controllers is capable of Netork handling transmission and reception of frames according to CAN version 2.0B.It provides CAN functionality on 15 message objects,which are formatted as extended frames, with 29-bit identifiers.Thesc message objects work independently and therefore,can be handled with no mutual influence. Each of the message objects has a unique identifier and its own set of status and control bits.The Auxiliary controller provides storage and full control capabilities,then interfacing to the CPU proper via a small dual-ported Motherboard memory.Thus,CAN 'on its own',i.e.,only making use of low level protocol layers,makes an excellent ground for the Figure 2:Board interconnection in integrating units sort of modularity required at specification level.The use of CANopen took even further the potential for modularity. Digital Process In order to minimise the effort involved in system Interface integration,manufacturers of CAN-based equipment adopted the concept of device profiling,thus generally standardising the communication contents (both syntax and semantics) Powver which are to be transferred to each other.Thus,a CANopen profile family for a determined device type provides both Netwark descriptions on the actual devices'functionality and the communication mechanism to explore them,i.e.,consists of device profiles [4]and a communication profile [5].A device profile consists of thrce parts: Analogue One mandatory part,in which the standard device Interface type is defined and is,therefore,common to all members of the respective family: Motherboard One optional part for an extended device definition Figure 3:Board interconnection in DAQC units (naturally not offending the mandatory general specification);
156 Thereliore, the SAB-Cl67CS-32PM chip from Siemens was selected to support all units iuvolved in real- and limitedtime operation, i.e., those placed at the three lower hierarchical Icvels. Thus, on one hand, this device is able to intcrface to sensors and actuators via the built-in 110 ports, which has 1cd to an overall capability to handle 16 channels of each aiialogue aiid digital inputs and outputs. On the other hand, it has two built-in CAN bus controllers, as required by the specified architecture. Physical modularity was achieved by sharing thc basic processor block amougst the three different module typcs other than the central inanageincnt unit. Thus, iii physical tcrins, each unit is made of a mothcrboard and the daughtercards appropriate to the respective functional level (figures 2 aud 3), as follows: in integrating units, the motherboard is complemented by (i) a board with a rcal-timc clock and up to 4 MB of static RAM made nowvolatile with recourse to an on-board batteiy, and, optionally, (ii) an auxiliaiy board coutaining the hardware required to drive a fsont panel for local human interfacing; Power Nebork J Motherboard 7 L - - -7- - Y Figure 2:Board intcrconuection in integrating units -+ Nebwork Analogue Interface / 2 Figure 3:Board interconnection in DAQC units in both data acquisition and control units and smart transducers and actuators, the motherbboard can be complemeuted by (i) a board with ciipabilities to handle 16 channels of either digital inputs aiid digital outputs, all of them with on-board protection, aiid (ii) a board with capabilities to handle 16 analogue iuput channcls, with a11 option for lO-bit or 16-bit resolution, at r? maximum sampling rate of IOOMSis (for a single chaiinel use) and, also, 16 analogue output chaiincls with 8-bit resolution. The motherboard cousists of a lOcmxlOcm (approximately Px4”) card integrating the inicrocontrollcr, transccivers and interfacing (optocouplers) to the two CAN nctworks, drivers and receivers for oue RS232E connection with two hardware protocol levcls, and a local 5V regulator. Despite the fact that the processor chip is explored either as microcontroller or as microproccssor, this motherboard is common to all units; all boards were made to fit in 3U-high Eurocard subracks. In some application cases, units were housed in standard Eurocerd plug-in modules (3U height, 21HP width, and 16cm depth). IV. SOFTWARE IMPLEMENTATION Each of the C167 integrated CAN controllers is capable of handling traiismission and receptiou of frames according to CAN version 2.OU. It provides CAN functionality on 15 message objects, which are formattcd as extended frames, with 29-bit identifiers. Thcsc mcssage objects work iiidependently aiid thercfore, can be haudled with no mutual influencc. Each of the message objects has a unique identifier and its own sct of status and control bits. The controller provides storage and full control capabilities, then interfacing to the CPU proper via a small dual-ported memoly. Thus, CAN ‘on its own’, i.e., only making use of low lcvcl protocol layers, makes an excelleiit grouiid for the sort of modularity required at specification Icvcl. The use of CANopeii took even fuithcr the potential for modularity. In order to minimise thc effort involved in system integration, manufacturers of CAN-based equipment adoptcd thc conccpt of devicc profiling, thus generally standardising the communication contents (both syutax and semantics) which are to be transferred to each other. Thus, a CANopeii profile family for a determincd device type provides both descriptions on the actual devices’ functionality and the communicatiou mechanism to explore them, i.e., consists or dcvice profiles [4] aiid a communication profile [5]. A device profile consists of thrce parts: One mandatory part, in which the standard device type is defined and is, therefore, comnion to all members of the respective family; One optional part for an cxtended devicc definition (neturally not offcudiug thc iuaudatoty general specification);
157 One manufacturer specific functionality,where In the end,CANopen turned out to be the right tool to makers can give the specific features of the product. ensure the level of software modularity appropriate to meet the one more traditional and easily achievable with hardware. As a result of this,a complete virtual instrumentation This approach provides present flexibility and ensures strategy could be pursued,thus leading to a powerful room for future developments of device profiles. laboratory aid tool. The most important part of every CANopen device is the object dictionary,which is the collection of all the device V.CONCLUSION parameters listed in predefined manner and made accessible to the network,as shown in table 1.The object dictionary A generalised approach to the architecture of this system consists of a communication profile,which is common to all has been pursued,so as to maximise its potential versatility. devices in the family,and applications related data in one or despite the fact that,in principle,no absolute and definite more device profiles specifying device attributes.In this universal solution can be actually achieved;so far,however. manner,devices become uniquely and universally represented results obtained are strongly encouraging.Thus,modularity by an electronic data sheet (EDS)and a device configuration was extensively practised,encompassing both functional and file (DCF),both supplied by the vendor. physical criteria.Each modular unit is permanently In CANopen networks there are two standard programmed with the set of abilitics it has been devised for, communication mechanisms:through Process Data Objects which are then activated at the beginning of each (PDO),which are responsible for real-time data distribution, experimental run through a string of messages (not code), and through Service Data Objects (SDO),which are which are received from the respective master unit,By responsible for block transfers of configuration data.More following the line of the virtual instrumentation approach,the specifically,PDO mechanisms provide synchronisation original program is graphically entered at the central primitives for real-time data transfers between modules,with management and processing unit. a very light protocol overhead.Also,in a determined This approach lends itself to the most valuable feature in module,two SDO are used to allow other nodes to access the laboratory automation:flexibility,in terms of true rapid module's Object Dictionary,each of the SDO thus providing prototyping.Thus,experiment set-up,run supervision and a simplex channel. data handling capable of producing final information readily available to scientific workers in disparate fields of activity such as biophysics,hydraulics,seismology and nuclear Table 1:Object Dictionary Structure technology. Index (hex) Object REFERENCES 0000 Not used [1]CAN Specification 2.0,Robert Bosch GmbH,1991. 0001-001F Static Data Types [2]CAN Physical Layer for Industrial Applications,CiA 0020-003F Complex Data Types Draft Standard 102,CAN in Automation (CiA)e.V., Erlangen,1994. 0040-005F Manufacturer Specific Data Types [3]CAN Application Layer Specification,CiA Draft 0060-007 Device Profile Specific Static Data Types Standards 202 to 207,CAN in Automation (CiA)e.V., Erlangen,1996. 0080-009F Device Profile Spccific Complex Data Types [4]CANopen Device Profiles,CiA Draft Standards 401 to 00AO-OFFF Reserved for further use 406,CAN in Automation (CiA)c.V.,Erlangen,1996. 1000-1FFF Communication Profile Area [5]CANopen Communication Profile for Industrial Systems, CiA Draft Standard 301(Rev.3.0).CAN in Automation 2000-5FFF Manufacturer Specific Profile Area (CiA)e.V.,Erlangen,1996. 6000-9FFF Standard Device Profile Area [6]TASKING,Inc.,Dedham,MA 02026-4530.USA. A000-FFFF Reserved for further use In conclusion,CAN open provides standard network management and system services,such as synchronism, emergency messaging and system time provision.Also,the high level of (re)configuration ability especially recommends CANopen for the sctting-up and maintenance of complex systems
157 In the end, CANopen turned out to bc thc right tool to ensure the level of software modularity appropriate to meet tlie one more tiaditional and easily achiewble with hardware. As a result ol this, a complctc virtual instrumentation strategy could be pursued, thus leading to a powcrful laboratoiy aid tool. Index (Lex) Object noon Not used 0001-001F Static Data Types 0020-003F Complex Data Types One manufacturer specific functionality, where makers can give the specific features of the product. REFERENCES [I] CAN Specification 2.0, Robert Bosch GmbH,1991. [2] CAN Physical Layer for Industrial Applications, CiA Draft Standard 102, CAN in Automation (CiA) e.V., Erlanecn. 1994. This approach provides present flexibility and ensures roan for future developments of device profiles. lhe most important part of every CANopen device is the object dictionary, which is the collection of all the device parameters listed in predefined manner and made accessible to the network, as shown in table 1. The object dictionaiy consists of a communication profilc, which is common to all devices in the family, and applications related data in onc or more device profiles specifying device attributes. in this manner, dcvices become uniquely and universally representcd bv a11 electronic data sheet IEDS) and a dcvice confieuration 0040-005F 0060-007F 0080-009F OOAO-OFFF 1000-IFPP 2000-5PFF V. CONCLUSION A generalised approach to tlic architecture of this systein has been pursued, so as to maximise its potential versatility, despite the fact that, in principle, no absolute and dcfinite univcrsal solutioii can be actually acliievcd; so rar, however, results obtained are strongly encouraging. Thus, modularity was extensively practised, cncompassing both functional and ", [3] CAN Appliciition Layer Specification, CiA Draft Standards 202 to 207, CAN iii Automation (CA) e.V., Erlangen, 1996. [4] CANopen Device Profiles, CIA Draft Standards 401 to 406, CAN in Automatioil (CIA) c.V., Erlangen, 1996. [5] CANopen Comiiiunication Profile for Industrial Systems, CiA Draft Standard 301(Rev. 3.0), CAN in Automation (CIA) e.V., Erlangen, 1996. Manufacturcr Specific Data Types Dcvicc Profile Specific Static Data Types Device Profilc Specific Complex Data Typcs Reserved for further use Communication Profilc Area Manufaclurer Specific Profilc Arca 6000-9FFF Standard Devicc Profile Arca [6] TASKING, Inc., Dcdham, MA 02026-4530, USA. A000-FFFF Reserved for furthcr usc