Computer Standards & Interfaces 31 (2009) 504–514
Contents lists available at ScienceDirect
Computer Standards & Interfaces
j ourna l homepage: www.e lsev ie r.com/ locate /cs i
Developing and implementing an open and non-proprietary device description forFOUNDATION fieldbus based on software standards
Rodrigo Palucci Pantoni ⁎, Dennis BrandãoSchool Engineer of São Carlos — University of São Paulo, Brazil
⁎ Corresponding author.E-mail address: [email protected] (R.P
1 Royalty: Payment made to the holder of a produtrademark, and so on, or to the author of a book, for thetheir property. Plural: royalties.
0920-5489/$ – see front matter © 2008 Elsevier B.V. Adoi:10.1016/j.csi.2008.06.008
a b s t r a c t
a r t i c l e i n f oArticle history:
Support for interoperability Received 7 November 2007Received in revised form 9 May 2008Accepted 28 June 2008Available online 11 July 2008Keywords:Non-proprietary technologyOpen technologyElectronic Device DescriptionXMLFieldbus automation systems
and interchangeability of software components which are part of a fieldbusautomation system relies on the definition of open architectures, most of them involving proprietarytechnologies. Concurrently, standard, open and non-proprietary technologies, such as XML, SOAP, WebServices and the like, have greatly evolved and been diffused in the computing area. This article presents aFOUNDATION fieldbus™ device description technology named Open-EDD, based on XML and other relatedtechnologies (XLST, DOM using Xerces implementation, OO, XML Schema), proposing an open and non-proprietary alternative to the EDD (Electronic Device Description). This initial proposal includes definingOpen-EDDML as the programming language of the technology in the FOUNDATION fieldbus™ protocol,implementing a compiler and a parser, and finally, integrating and testing the new technology using fielddevices and a commercial fieldbus configurator. This study attests that this new technology is feasible andcan be applied to other configurators or HMI applications used in fieldbus automation systems.
© 2008 Elsevier B.V. All rights reserved.
1. Introduction
The interoperability concept is the ability of a system (or a softwarecomponent) or a product to work with other systems or productswithout special effort on the part of the customer [1]. Another linkedconcept is of interchangeability, which defines the capacity ofexchanging a system or product without losing any functionality [2].
Interoperability and interchangeability are defined in the elabora-tion and construction phases of the software or device project,following an open standard related to project architecture.
Open software can be defined as a software with an architecturespecially designed to foresee the integration with other software ortechnologies. It is, however, a non-functional requirement of thesoftware project [3].
Another aspect involved is the concept of open standards. Suchconcept is related to the true possibility of a system to be freelyimplemented, without legal or commercial restrictions; for example, ifroyalties1 are to be paid to use, implement or commercialize thesoftware, then the software is not open (which means it is not free).Property rights are not strictly tied to the cost, but to the rights to theobject (in this case, the technology) in a more extensive way. Inpractical terms, what characterizes a technology as proprietary ornon-proprietary is the license agreement bonded to the technology by
. Pantoni).ct patent, production process,right to use or commercialize
ll rights reserved.
the holder of the intellectual property rights. The technology is eitherin public domain, and in this case it is inherently non-proprietary, or itis owned by a person or a legal entity and in this case the holder hasthe rights to the technology. In this second case, the holder has a legalpremise to associate a license agreement to his/her propriety. Suchlicense can be restrictive, whichmeans the user has access to a smallersubset of rights than the owner rights. Restrictive licenses arediscriminative because they impose different rights of use to differentusers, for example limiting who, how, when or where the technologycan be used. On the other hand, if the license is non-restrictive, equalrights of use are assured, and that is where the term “free” comesfrom, consolidating the term “Free Software”, for example [4]. How-ever, there are cases that licenses of free software are restrictive, butnot discriminating. The term “open” is also used as in “Open Source”.
In this article, the term “open” is related to the softwarearchitecture which is designed to foresee the integration, while theterm “non-proprietary” is related to the license-free usage, regardingthe respective license agreement.
Electronic Device Description (EDD) technology describes devicecharacteristics to the configurator or any other fieldbus HMIapplication. This technology is a common language adopted todescribe different devices from different manufacturers. Nowadays,this technology is applied to FOUNDATION fieldbus™ (FF), HART andPROFIBUS devices [5].
The open and non-proprietary device description technologyproposed in this article, named Open-EDD, is distinguished from thecurrent and typically proprietary device description technologies. TheOpen-EDD is based on open and non-proprietary standard technol-ogies already spread for personal computers but adapted to the
505R.P. Pantoni, D. Brandão / Computer Standards & Interfaces 31 (2009) 504–514
industrial area, being naturally extended to automation systems. Inthis study, the open and non-proprietary base technology is XML(eXtensible Markup Language), which is world-wide known forintegrating Internet applications.
This technology is the open and non-proprietary technologicalternative to the current EDD, defined and controlled by the FieldbusFoundation™ for the FOUNDATION fieldbus™ protocol.
The motivation to develop the Open-EDD is presented in the nextsection; Section 3 is intended to give a brief revision of the relatedwork found in the literature regarding device description; Section 4describes the EDD technology and other device descriptions used infieldbus plants; Section 5 details the software configurator thatvalidates the proposed technology; Section 6 describes the methodol-ogy to create the Open-EDD and its characteristics; Section 7 presentsthe results and the last section outlines the conclusions.
2. Motivation and goal
The EDD technology for FF consist of a standard languagenormalized by IEC 61804-2 [6] EDDL (Electronic Device DescriptionLanguage), a compiler for EDDL and an interpreter, named DDS(Device Description Services).
The compiler translates the source code of the description createdusing the EDDL, and generates a special, codified and compacted binaryfile. The interpreter extracts all originally coded information from thebinaryfile and, therefore,mustbe integrated to the FF configuratororHMIapplication, so that they canproperly access the information in the binaryfiles and enable the interaction between the system and the devices.
Although theEDDL is an IEC61804-2 [6] standard, the compiler and theinterpreter are proprietary [7]. Such elements are exclusively man-aged, distributed and commercialized by the FOUNDATION fieldbus™.
The EDD can now be considered a mature technology, whichaccumulated resources and functionalities during over 12 years oftechnical revisions. However, in the case of FF and HART protocols, it isnecessary to purchase toolkits related to the compiler and theinterpreter to use this technology, and this fact can potentiallyexclude universities and research centers from the developmentprocess due to higher costs of development. It is then believed that analternative to the EDD based on free technologies can contribute to theprotocol technological development, for example, developing functionblocks, simulators and applications for automation systems.
The proposed Open-EDD also helps the device developer as well asthe HMI or configurator developer. For device developers, the EDDcurrently uses the EDDL, with a similar syntax to the C programminglanguage, and requires training and time to acquire the knowledgedue to its particularities. For HMI or configurator developers, DDSintegration is also arduous because it is implemented in low-level Clanguage (the framework supplied for FOUNDATION fieldbus wasdelevoped in C language).
Creating the Open-EDD involves defining a new language namedOpen-EDDML (Open Electronic Device DescriptionMarkup Language),modeling, designing and implementing a compiler and a parser(similar to the EDD interpreter).
The Open-EDDML language, in this initial version, embodiesinformation only related to the structure of the identification EDDand the lists of blocks and parameters from the FF device.
The integration to a fieldbus configurator and the operational testsusing FF devices for process control validate this technology.
3. Related work
This section is intended to give a brief revision of the related workfound in the literature related to the studies for device descriptionformats.
Methodologies to integrate EDDL and FDT/DTM technologies forFF and PROFIBUS devices have been studied in this decade [8–10].
The disadvantage of those methodologies is that FDT/DTM is basedon COM (Component Object Model) [11] proprietary technology,developed by Microsoft and supported only onWindows operationalsystems. Thus, the resulting technology cannot be consideredinteroperable with all automation systems. Furthermore, FDT/DTMis relatively difficult to develop and does not support datapersistence [10]. On the other hand, EDDL supports data persistence[6].
On the analysis presented in [11], it is presented a device descriptionformat for CANOpen devices based on XML. In this research the authorpresents the developed model and exposes the benefits of using XMLtechnology.
In the fieldbus literature related to FF, HART and PROFIBUSprotocols device description, a similar work to the proposedtechnology Open-EDD is described in [12], in which the authorsanalyzed analytically the possibility of mapping EDD FF data to XML,i.e., without an implementation and validation of the purpose. Thatpurpose do not foresee real complex device variable types like Re-cords that contains Enumerated and BitEnumerated information,which is difficult to be handled.
To create a XML-based language, it is necessary to describe a setof rules that defines the XML markups or elements. There are twopossibilities to define the language: DTD (Document Type Definition)or a XML Schema. Since it would be necessary to describe complextypes obtained from the device variables, this study adopted asolution using XML Schema, which is also suitable to naturally mapelements in the UML notation. The DTD, evaluated for the samepurpose by [12], was not adopted in this study because DTD does notsupport complex types and does not have intuitive association to theUML notation.
Besides the use of XML Schema for validation, this paper differsfrom the purpose presented in [12] through the following aspects: inthis work an implementation and validation of technology iseffectively performed; it was developed a UML modelling with EDDconstructions to keep compatibility with the current EDDL standard;the proposed technology is implemented with open softwarestandards; the usage of inheriting of XML characteristics to generatea graphical interface from the XML technology through XSLtechnology; the integration of the proposed technology in a fieldbusconfigurator currently available in the market; and finally, after testswith existing devices, the validation of the methodology.
4. Electronic device description
The configurator interacts with the devices to configure them, toconfigure thefieldbus networks andprogram the control strategy logic. Todo so, some information about the characteristics of the device is required,such as the name and type of the variables, functions, inputs and outputs,etc.
For FF, the description of the device characteristics is available forthe configurator through the EDD technology. The configurator hasan EDD bank available with the software installation, one EDDfor each device, which includes all devices supported by theconfigurator.
Besides describing a device, the main role of the EDD is enablingthe interoperability among devices from different manufacturers viacommon standards and interfaces.
The EDD is also known by the name of its previous version, the DD(Device Description). Due to this fact, in this study the abbreviationsDD and EDD express the same technology but intend to indicate thedifference between versions.
As for fieldbus devices [7], asserts that device interoperability isonly assured when the following two requirements are fulfilled: first,there is a standard logical structure for the application layer (seventhlayer) of the ISO/OSI reference model, and second, the ElectronicDevice Description (EDD).
Fig. 1. FF user layer.
506 R.P. Pantoni, D. Brandão / Computer Standards & Interfaces 31 (2009) 504–514
One of the first publications of DD occurred in Germany, when theDD was presented as the eighth layer of the ISO/OSI reference model[13]. Currently, such technology is not considered as an additionallayer to the ISO/OSI reference model.
In the FF protocol architecture, the EDD (or DD) is located on theso-called user layer because it describes information concerning thefunction blocks to a higher level in the system architecture, forexample, where the configurator is installed. Fig. 1 shows the FF layermodel and indicates the location of the user layer above the seventhlayer of the ISO/OSI reference model.
Other technologies of description were created to assuresystem interoperability to other fieldbuses in the plant floor:PROFIBUS introduced GSD (General Slave Data); PROFINET intro-duced GSDML (General Station Description Markup Language) andINTERBUS introduced FDCML (Field Device Configuration MarkupLanguage).
PROFIBUS configurator systems which follow the IEC 61784-1:2003 CP3/1 and CP3/2 use a specific multiplatform ASCII formatfile called GSD file. This file contains information to execute networkcontrol. According to [14], the information would include: deviceidentification, description of the device information which can beaccessed through the network (for example, configurable parameters),description of communication capabilities (for example, transmissionrate) and additional manufacturer information.
For PROFINET, GSDML is the technology which provides interoper-ability among devices. GSDML is considered an evolution of the GSDtechnology because both technologies have the same objective;however, while the GSD description is created in ASCII format,GSDML is based on the XML technology. The description, therefore,can be created in anyXML editor, provided that the description is basedon a XML Schema defined by GSDML specification [15]. According to[16], PROFINET was developed to support distributed inputs andoutputs even among other fieldbuses such as INTERBUS. This supportfor distributed inputs and outputs led to the development of a morepowerful device description, the GSDML.
FDCML is the description technology used by INTERBUS, which issimilar to the GSDML technology because it is based on the XMLtechnology, both were elaborated using the same common devicemodel, according to ISO 15745 [17]. The independence of the commu-nication protocol and the extensibility provided by the XML technologyenable the description of devices from other similar protocols, such as
PROFINET. The extensibility permits the inclusion of any networkelement from any communication protocol. According to [18], there arePROFINET and Sercos devices which have been already described usingFDCML, besides the INTERBUS devices.
The technologies mentioned above (GSD, GSDML and FDCML),differently from EDD, were created essentially to describe data forcontrol communication services, i.e., cyclic services of the respectiveprotocols, allowing interoperability among them.
Besides EDD, the protocols FF, HART and PROFIBUS also use analternative and recent technology considered as a complement to theEDD [19] named FDT/DTM (Field Device Tool/Device Type Manager).Similar to the EDD, the FDT/DTM technology also provides deviceinteroperability, except for the information directly related to thecontrol, but for parameterization, configuration download, generatingconfiguration screens which include menus, configuration/calibrationmethods and dialog boxes, creating control strategies (in the case ofFF), etc. Such information is used on acyclic services (parameteriza-tion, configuration download, configuration upload, etc). This is thereason why PROFIBUS devices, for example, use two types ofdescription technology simultaneously (EDD or FDT/DTM and GSD,for example).
The FDT/DTM technology was initially developed by a group ofsystem suppliers who were joined to create an open architecture forfield devices, as occurred with EDD developed with EDDL. Suchtechnology is built on software components based on Microsoft COM(Component Object Model) technology, in accordance with thecommunication interfaces defined by the specifications from theGerman group ZVEI (German Electrical and Electronic ManufacturersAssociation) [20].
In the FF protocol, the configurator can use the EDD information intwo situations: to gather the information about the characteristics ofthe devices in the offline configuration mode and to communicate tothe devices in onlinemodewhen the configuration is executed in real-time.
It is only possible to edit the configuration in offline mode usingdevice description technologies, because it is necessary to accesscharacteristics of field devices without communicating or exchangingdata between the configurator and the devices. This feature allows theengineering phase to begin before the plant startup, even in a locationapart from the industrial area, where the process control will actuallyoccur.
Fig. 2. Syscon software architecture.
Fig. 3. Control strategy created in offline mode.
507R.P. Pantoni, D. Brandão / Computer Standards & Interfaces 31 (2009) 504–514
The EDD information will also be used in the online configurationmode, and in this case the role of the DDs is to represent a set ofdrivers. Editing the configuration in online mode involves: sending areading or writing command to block parameters in the devices,creating instances of function blocks in the devices, downloading acontrol strategy, etc.
In onlinemode, the configurator requires the access to the network,and therefore to the field devices, from the OPC server component (OLEfor Process Control). On the other hand, theOPC server needs the devicedescriptions to access or configure the devices; in this phase, the OPCserver requires the information about the referred devices from the DDserver and executes the requested procedures.
Fig. 2 shows the architecture designed for the Syscon configuratorthat accesses the FF devices and networks. It is used in its architecturethe DD version 4 [21].
The DD bank is stored in the hard disk of the host station, withseveral directories, each representing a device type supported. Insideeach directory, for each device version, there is one proprietary, binaryDD file (ffo filename extension), one file with the list of symbols fromthe binary file (sym filename extension) and one CF file (CapabilityFile, cff filename extension). In this configurator architecture, the set ofdirectories is named Device Support.
The CF description technology quoted above is also used for FF H1devices, but with a different objective from the EDD, which is todescribe the physical capabilities of the referred device, such as themaximum memory available [22].
5. Fieldbus configurator
To better understand this study, it is necessary to detail thesoftware configurator used to test and validate the Open-EDD, namedSyscon [23], pointing out the role of the EDD in the plant startup andoperation process. The configurator executes the following proceduresto commit and configure the distributed control system of theindustrial process plant: control strategy offline configuration, net-work topology definition, offline configuration of function block'sparameters, configuration download and online configuration offunction block's parameters.
The control strategy is configured in offline mode using diagramsthat graphically represent the function blocks [24,25] (Fig. 3).
The topology is built adding the FF fieldbuses, then configuring thecontrol cycle for each fieldbus, adding field devices and finally creatingblock instances for the devices. Fig. 4 shows the configurator windowafter creating a FF topology.
The configuration of field devices in offline mode, that is, theconfiguration performed before establishing the connection betweenthe software and the field devices, alters the parameter values of thefunction blocks available for each device.
Fig. 4. Network topology.
508 R.P. Pantoni, D. Brandão / Computer Standards & Interfaces 31 (2009) 504–514
The online configuration consists of editing values of functionblock parameters while operating the plant. Fig. 5 shows the onlineparameter characterization window.
Fig. 5. Online characte
To the parameter values configuration (online and offline mode) ofthe function blocks, the EDD provides the following informationrelated to the parameters [21], as shown in Table 1.
rization window.
Fig. 6. Open-EDD componet and Xerces parser.
509R.P. Pantoni, D. Brandão / Computer Standards & Interfaces 31 (2009) 504–514
6. Methodology for creating the Open-EDD
6.1. Definition language — Open-EDDML
Similar to the EDDL – the programming language that defines theEDD – a XML-based language is proposed to develop the Open-EDD.This language is called Open-EDDML.
XML is a meta-language, that is, a language used to defineother languages. To create a XML-based language, it is necessaryto describe a set of rules that defines the XML markups or elements[26]. The language can be built for problem domains, applicationsor information collections. There are two possibilities to definethe language: DTD (Document Type Definition) or a XML Schema[27,28].
A more complete and legible graphical representation of the XMLSchema including the structure and the relationship of XML elementsis shown in Fig. 6, using UML notation.
6.2. Compiler and parser
Similar to the compiler (tokenizer) and the interpreter (DDS) fromthe EDD technology, a single software component was developed tocompile and interpret data from the Open-EDD.
This component (Fig. 6) was implemented in Borland C++ 5.02using the UML (Unified Modeling Language) modeling tool RationalRose 98. A free open source library named Xerces [29] was includedin the component to execute basic XML writing and interpretingservices.
DOM (Document Object Model) API [30], implemented inXerces, was used to manipulate XML data in this work. Thistechnology was chosen because it is a W3C standard, providesthe support to validate the XML format through XML Schema(comparing to EDD, it acts as the compiler — tokenizer), andrepresents the XML elements as objects at a higher level ofinformation abstraction and encapsulation [28]. This last men-tioned characteristic is not found in the SAX technology, forexample [31].
Data compilation or validation is inherent to the Xerces C++ parser.When a device is created in Syscon, an Open-EDD file should be readonce, and a validation is requested in real-time, that is, while theprocess is being executed.
Table 1Parameters information from EDD
Information Description Possible values
Handling Indicates if the parameter is forreading, writing or both. It isconfigured to allow editing thevariable value.
Read, Write, Read/Write
Class Defines the parameter class. Itcreates a reference for customdiagrams according to class orfunctionality, or even for creatinglinks between blocks.
Input, Output, Contained,Dynamic, Diagnostic, Service,Operate, Alarm, Tune, Local
Type Defines the type of theparameter, indicates the dataformat that will be displayed onscreen or sent to the device viareading and writing commands.
Ascii, BitString, BitEnumerated,BooleanT, DateAndTime, Double,Duration, Enumerated, Euc, Float,Index, Integer, OctetString,PackedAscii, Password, Time,Time_Value, Unsigned,VisibleString
Metatype Defines the metatype. Array, Variable, RecordBitEnumeration Define the list of elements for bit-
enumerations.Specific to each parameter.
Enumeration Define the list of elements forenumerations.
Specific to each parameter.
Object-oriented modeling was used to develop the component.The development of complex and high-level systems is bettermanaged and modeled using object-oriented (OO) technology andUML [32,33].
Two UML class diagrams were created to model the XML Schemastructure in the Open-EDD component. In the first UML diagramdeveloped, the base class XMLElement was defined with basicfunctionalities, such as reading, writing, data and format validation,provided by Xerces. For each Open-EDDML element or markup, a classthat inherits the functionalities of the base class is defined. Since theelement ParameterXMLElem has the same functionalities as theelementMemberXMLElem, but with additional services, it is inheritedfrom the element MemberXMLElem.
The second UML class diagram created intends to represent theassociations between classes that describe Open-EDDML elements inthe same manner of XML Schema elements from Open-EDD, asindicated in Fig. 7.
The methodology to integrate the Open-EDD component to thefieldbus configurator was executed replacing the DDS proprietaryinterpreter with the parser developed. Therefore, the configurator andthe DD server must have been modified to interact with the parser, asindicated in Fig. 8.
In the Open-EDD bank, ffo and sym files (generated by theproprietary compiler) were replaced with a single XML file (Open-EDD) in every device directory in the Device Support.
A disadvantage of Open-EDD is that the files may have a larger sizein the hard disk depending on the number of information included(the size is between 10 kB and 2 MB). EDD files are not as large asOpen-EDD files because they are binary (compacted) files, whileOpen-EDD is a XML file.
Another related problem is the performance required toquery data from the Open-EDD files. To avoid large processingtimes for reading a file each time a data query is requested inthe configurator, a mechanism was created to optimize thereading performance. When a configurator needs to access datafrom a specific device type (related to an Open-EDD file), allinformation about it (an entire XML tree structure — DOM) isloaded into static objects. Then, when the configurator needs toaccess data from a device type which has already been loaded,this query is done instantaneously because the information is inthe cache memory. The user will have to wait a few seconds toload the XML structure only in the first Open-EDD file readingand later on all operations related to this file (the same devicetype) will be executed instantaneously, not needing the XML fileto be loaded again.
Fig. 7. Diagram of associations between Open-EDDML elements in UML notation.
510 R.P. Pantoni, D. Brandão / Computer Standards & Interfaces 31 (2009) 504–514
6.3. Test procedures
During the tests of the Open-EDD, the following procedures wereexecuted:
- Open-EDD files were created based on current FF DDs for theFF certified devices DFI302, TT302 and FY302, using the freeXML editor available in the Netbeans development environ-ment [34];
- The files created were integrated in the Open-EDD bank;- The devices were created in the configuration file;- The Resource and Transducer blocks of all devices were createdusing the configurator, as well as the Analog Input (AI) andPID block of the TT302, and the Analog Output (AO) of theFY302;
- The AI-PID-AO control strategy was created as indicated in Fig. 3;- Function blocks were parameterized in offline mode;- The configuration was downloaded to the devices;- Online parameter values were read and written to the fielddevices.
6.4. User-friendly graphical interface for Open-EDD data
The methodology to create a mechanism to automatically generatea user-friendly graphical interface using Open-EDD was executedimplementing the logic in XSLT (eXtensible Stylesheet LanguageTransformation) language to generate the interface in HTML. This logicis described in the file “OpenEDD.xsl”, which is associated to anyOpen-EDD file to represent the information in a user-friendly formatfor visualization purposes. In addition to the “OpenEDD.xsl”, a
Fig. 8. Modified Syscon architecture.
511R.P. Pantoni, D. Brandão / Computer Standards & Interfaces 31 (2009) 504–514
cascading style sheet named “OpenEDD.css” was created to store theHTML style of the document, defining font size and type, colors,underlined or italicized texts, and so on.
7. Results
To develop device descriptions, Open-EDDML is simpler: whilea considerable learning curve/time is required to develop devicesusing EDDL, Open-EDDML has a tree standard structure for devel-opment. At first sight, the development may seemmore complicatedbecause of excessive syntax details. However, the implementa-tion becomes very simple when using a XML specialized tool. Suchtools build and validate the syntax and format based on the XMLSchema during the implementation of Open-EDD files thus facilitat-ing the development for the device developer. Table 2 comparesthe same code described in EDDL and in Open-EDDML for a hy-pothetical device description which contains one block with twoparameters.
The algorithm that invokes parser functions in the configuratorwasimplemented (Open-EDD component) in a high-level language so thatthe Open-EDDML elements are represented by objects. Fig. 9 shows apart of the algorithm implemented in C++ to obtain the describedOpen-EDDML items (or information).
Fig.10 shows the viewwhich can be generated from any Open-EDDfile, resulting from the mechanism that automatically generates astandard user-friendly graphical interface using XSLT.
8. Conclusions
The Open-EDD technology is intended to be easier to be handledthan the EDD. Such easiness is noted by device developers that useXML support tools, as well as HMI application developers, because theparser/compiler integration to the applications occurs in a high-levellanguage (using objects), as opposite to the DDS from the EDD, thatuses C functions.
The proposal of a flexible, non-proprietary technological al-ternative based on a meta-language such as the Open-EDD canincorporate all the EDD resources plus eliminate the need ofpurchasing development toolkits. In accordance with the open
systems motivation, this study presents the Open-EDD as an al-ternative to the EDD. In this sense, the Open-EDD standard viability isclear and the negative impact caused by a technological migration canbe considered low, once the old proprietary format still would besupported.
If considered, otherwise, as a replacement of EDD, the adoptionimpact of the Open-EDD should be evaluated based on the fact the twotechnologies are not compatible (EDD technology is proprietary due toits encrypted format). On the other hand, the Open-EDD brings thebenefits of open software tools. A solution to this issue could be aconverter tool that uses proprietary DDS interpreter to convert EDDto Open-EDD, granting total compatibility with device descriptiontechnologies.
Using XML as the base of the proposed technology enabledthe implementation of a mechanism to automatically generatethe Open-EDD interface in HTML format. The great benefit ofthis mechanism is to generate a standard view from any Open-EDD file from any device, creating a standard graphical inter-face. This aspect is important especially for automation systemswith devices from different manufacturers because the userwould interact with a common look and feel in any system,from any manufacturer. Nowadays, the graphical interface forEDD is developed by the manufacturers of HMI tools and doesnot have standardized or uniform look and feel. The Open-EDDXSL file, which generates the graphical interface automati-cally provides uniformity for device information visualizationand save developing time for HMI tools. Additionally, the HTMLformat allows the integration with other technologies as AJAX,which can be used for implementing a dynamic behavior overconditional constructions, which shall be considered for theOpen-EDD extensibility.
Due to the extensibility provided by the XML technology, Open-EDD can be extended to support device descriptions from otherprotocols, since there is a similarity of information, as in the HART andPROFIBUS protocols, for example.
This study was validated by a commercial software configuratorwhich attests that this technique is feasible and can be applied toother configurators or HMI applications used in fieldbus automationsystems.
Table 2A comparison between EDDL and Open-EDDML
512 R.P. Pantoni, D. Brandão / Computer Standards & Interfaces 31 (2009) 504–514
Due to the size that Open-EDD files can reach, the evolution of thistechnology requires the use of an efficient, on the fly, compacting/uncompacting method, for instance as proposed in [35].
Fig. 9. C++ code for read
Another functional requirement is the implementation of condi-tional constructions used to describe the calibration methods andmenu visualization methods, among other EDD structures or
ing Open-EDDML.
Fig. 10. HTML data in user-friendly format.
513R.P. Pantoni, D. Brandão / Computer Standards & Interfaces 31 (2009) 504–514
constructions. A possible solution is based on the XSL technology, asproposed by [36], considering open technology philosophy, notrequiring the use of vendor specific parsers.
Acknowledgment
The authors gratefully acknowledge the academic support andresearch structure of the Engineering School of São Carlos —
University of São Paulo. The authors also acknowledge the importanttechnical contributions from Smar International Corporation.
References
[1] P. Miller, Interoperability what is it and why should I want it? Oct. 12, 2006,bhttp://www.ariadne.ac.uk/issue24/interoperabilityN. Accessed in.
[2] O.S. Donaires, FF DD×FDT/DTM: Sources, Characteristics and Tendencies. Controle& Instrumentação, São Paulo, v.99, 2004, pp. 40–46.
[3] Pantoni, R.P. Developing and implementing an open and non-proprietary devicedescription for FOUNDATION fieldbus™ devices based on XML. M.Sc. Dissertation—
Eng. School of São Carlos, University of São Paulo, São Carlos; 2006.[4] F.J. Monaco, Non-proprietary knowledge management, Aug. 11; 2006 bhttp://
www.icmc.usp.br/~monacoN. Accessed in.[5] M. Zielinsky, Digital fieldbus installations use EDDL for simplicity with advanced,
full functionality, Computing & Control Engineering Journal v.15 (n.6) (2005)24–31 London.
[6] International Electrotechnical Commission. 61804-2. Function blocks (FB) forprocess control — Part 2: Specification of FB concept and Electronic DeviceDescription Language (EDDL); 2005.
[7] L. Yong, Y. Hai-Bin, W. Tian-Ran, Y. Zhi-Jia, Fieldbus interoperation technologies,IEEE International Congress on Intelligent Control and Automation, 2004,Hangzhou P.R.China. Proceedings…, IEEE, New York, 2004, pp. 3620–3623.
[8] R. Simon, M. Riedl, C. Diedrich, Integration of field devices using field device tool(FDT) on the basis of electronic device descriptions (EDD), IEEE InternationalSymposium on Industrial Electronics, 2003, Pusan. Proceedings…, v.1, IEEE, NewYork, 2003, pp. 189–194.
[9] W. Kastner, F. Kastner-Masilko, EDDL inside FDT/DTM, IEEE International Work-shop on Factory Communication Systems, 2004, Vienna. Proceedings…, IEEE, NewYork, 2004, pp. 365–368.
[10] Microsoft — Component Object Model. bhttp://www.microsoft.com/com/default.mspxN. Accessed in May. 7; 2008.
[11] M. Wollschlaeger, CANopen device descriptions using general purpose modelinglanguages, International CAN Conference, 6., 1999, Turin. Proceedings…, IEEE, NewYork, 1999, pp. 03–06–03-13.
[12] Z. Wang, H. Yu, H. Wang, A. Xu, Y. Zhou, The research of XML-based extensibledevice description for FF, Annual Conference of IEEE Industrial Electronic Society,Busan. Proceedings…, IEEE, New York, 2004, pp. 2600–2603.
[13] W. Borst, Kommunikation auf der instrumentierungsebene, Elektronik, v.40,n.18,Munchem, 1991, pp. 72–80.
[14] Profibus International, Specification for PROFIBUS, Device Description and DeviceIntegration, v.1, GSD, Germany, 2005.
[15] Profibus International, GSDML Specification for Profinet IO. Germany, v.1, 2005.[16] J. Kasemann, Profinet basics, Oct.10, 2005 bwww.interclub.com/Profinet Basics.pdfN.
Accessed in.[17] International Organization for Standardization, ISO 15745-1, Industrial automation
systems and integration – Open systems application integration framework – Part 1:Generic reference description, Geneva, Switzerland, 2003.
[18] Heines, B. [email]. [email protected] Received in Oct. 27, 2005.[19] W. Kastner, F. Kastner-Masilko, EDDL inside FDT/DTM, IEEE International Work-
shop on Factory Communication Systems, 2004, Vienna. Proceedings…, IEEE, NewYork, 2004, pp. 365–368.
[20] FDT Group. bwww.fdt-jig.orgN. Accessed in May 20, 2006.[21] Fieldbus Foundation, FF-900-1.5: Foundation specification device description,
part 1. Austin, 1999.[22] Fieldbus Foundation, FF-103-1.7: Foundation specification common file format,
part 1. Austin, 1999.[23] Smar Equipamentos Industriais. bhttp://www.smar.comN. Accessed in Oct. 28,
2005.[24] Fieldbus Foundation, FF-800-1.4: Foundation specification system architecture.
Austin, 1999.[25] Fieldbus Foundation, FF-890-1.3: Foundation specification function block applica-
tion process, part 1. Austin, 1999.[26] G. Thiruvathukal, XML and computational science, Computing in Science and
Engineering, v.6, n.1, 2004, pp. 74–80.[27] XML Schema. bhttp://www.w3.org/XML/SchemaN. Accessed in May 10, 2006.[28] P. Walmsley, Definitive XML Schema, Prentice Hall PTR, Upper Sandle River, 2002,
pp. 03–14.[29] Apache Software Foundation, Oct. 29, 2005 bhttp://xml.apache.org/xerces-c/N.
Accessed in.[30] XML DOM, Mar. 23, 2007 bhttp://www.w3.org/DOM/N. Accessed in.[31] School of Computing and IT, Mar. 22, 2007 bhttp://www.scit.wlv.ac.uk/~jphb/
cp2101/week4/XML_Parsing.htmlN. Accessed in.[32] G. Booch, Object-oriented Analysis and Design with Applications, 2nd.ed.
Benjamin/Cummings, California, 1994.[33] G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide,
Addison-Wesley, Reading Mass, 1999.[34] Netbeans, Feb. 15, 2006 bhttp://www.netbeans.orgN. Accessed in.[35] Abstract Syntax Notation One, Oct. 23, 2007 bhttp://asn1.elibel.tm.fr/xml/N.
Accessed in.[36] M.A.O. Pagnano, R.P. Pantoni. bhttp://freepatentsonline.com/20040230899.htmlN.
Accessed in Mar. 23, 2007.
Dennis Brandão — He received his Ph.D. degree inmechanical engineering at the University of São Paulo in2005. He now teaches “Industrial Automation” at theDepartment of Electrical Engineering of the same uni-versity. His research activities are mainly in the area of
514 R.P. Pantoni, D. Brandão / Computer Standards & Interfaces 31 (2009) 504–514
Rodrigo Palucci Pantoni — R&D Systems Analyst, receivedthe Computer Science degree in 2000 and subsequentlyreceived the M.S. in 2006 at the University of São Paulo(USP). He's attending the Ph.D course, in the sameuniversity, as part of his job at the Smar R&D department
in the area of software development for automationcontrol and fieldbuses. He joined Smar in 2000, workingin the Smar R&D department where he conducts researchand development of host systems, including a FieldbusFoundation Asset Management and a Configurator system.fieldbus technology and application, with a particularinterest for distributed systems and continuous processcontrol.
