A Modern Approach to CIP Device Descriptions
Rick Blair
Senior Principal System Architect
Schneider Electric
Presented at the ODVA
2015 Industry Conference & 17th Annual Meeting
October 13-15, 2015
Frisco, Texas, USA
Abstract
Since the early 1990’s, the Electronic Data Sheet (EDS) has been the method for describing CIP device
characteristics. While the interpretation of the EDS by software is not widespread, this need could grow
as ODVA and vendors embark upon evolving CIP based systems:
 Internet of Things (IoT);
 The explosion of web-based applications;
 Possible future ODVA developments.
Electronic interpretation of an EDS requires parsing. An open source EDS parser is not available from
ODVA. Every vendor desiring to write applications that interpret EDS files needs to develop their own
EDS parser. Extensions to the EDS specification may also be needed to support the above applications.
Interpreting the EDS file format requires specialized knowledge within a company that is typically not
needed in any other portion of that company’s work.
The time is right to explore an alternative to EDS. This paper will consider using the eXtensible Markup
Language (XML) for describing a CIP device. XML is well maintained by a standards body. XML is used
in many applications inside a company beyond work on ODVA or CIP topics. XML parsers exist in web
browsers and modern compiler libraries. XML includes schemas for validating the XML Device
Description (DD) file.
More than one method exists to convert from EDS to XML. This paper does not attempt to propose THE
only way this could be accomplished. In fact, changing to a new file format offers the opportunity to begin
with a clean slate and full knowledge of present and future needs to re-architect the existing structure.
Sample conversions from EDS to XML are provided for various sections, along with source code
examples to demonstrate the ease of extracting data from an XML DD file. The use of XML schemas to
assist in creating and validating XML DD files is also presented.
The paper will conclude with a comparison of the pros and cons associated with this migration along with
a recommendation to strongly adopt this proposed strategy.
Keywords
Device Description (DD), EDS, XML, Element, Tag, Attribute, schema.
2015 ODVA Industry Conference
1
©2015 ODVA, Inc.
Introduction
Many newcomers to the CIP environment have difficulty understanding the requirements of EDS files.
Tools, like EZ-EDS, attempt to simplify the creation and maintenance of EDS files. However, every time
specification enhancements revise the EDS chapters of the CIP specifications, maintenance of EZ-EDS is
required. This often lags the specification changes, making the tool unusable for the new enhancements
in the interim. XML provides a validation methodology (call schema) that could be updated at the same
time as the specifications, mitigating this lag.
Previous approaches based on XML were considered in the past, for example the Field Device
Configuration Markup Language (FDCML) [6] for INTERBUS and the ISO 15745 series [7] with a device
part and a communication part, including various network protocols like INTERBUS, DeviceNet,
ControlNet, Modbus, WorldFIP and EtherNet/IP to name a few. These initiatives took place when XML
was not well established and the XML tools were primitive or not available. The time was not right and the
initiatives did not get traction.
This paper presents an alternate approach for describing CIP devices based on XML. There are
numerous advantages for using XML to describe CIP devices and some advantages to continue with the
current EDS methodology which will be explored. Examples of XML code will be presented and compared
to current EDS formats. The use of XML schemas to assist in generating and validating the content of an
XML DD file is described. Code examples are also provided to demonstrate the ease of extracting data
from an XML DD file using web technologies.
The paper will end with a recommendation to move forward with a migration to XML along with supporting
arguments.
Introduction to XML
XML, which became a World Wide Web Consortium (W3C) Recommendation on February 10, 1998,
stands for eXtensible Markup Language. XML was designed to describe data, with a focus on what data
is, and not merely how to display data. XML is designed to be self-descriptive.
XML uses tags, elements, text and attributes to describe data. A tag is a case-sensitive string, with no
spaces, enclosed between a left angled bracket (<) and a right angled bracket (>). The tag <message>
and <Message> are considered to be different. There are no predefined tags in the XML specifications.
There are two types of tags, an opening or start tag, <tag> and a closing or end tag </tag>. Opening and
closing tag pairs are used to define elements. Elements can contain text, attributes and / or other
elements.
XML documents form a tree structure starting with a "root" element. The terms parent, child, and sibling
are used to describe the relationships between elements. Parent elements have children. Children on the
same level are called siblings. Every XML document must contain a root element. This element is the
parent of all other elements.
The following is an example of an XML document. XML documents can use various character encoding
formats. The first line of an XML document specifies, using the encoding keyword, what encoding format
is used for the document.
2015 ODVA Industry Conference
2
©2015 ODVA, Inc.
Figure 1 – Sample XML file
<?xml version="1.0" encoding="UTF-8"?>
<!-- This is a comment -->
<collection xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:noNamespaceSchemaLocation="Records.xsd">
<album type="Vinyl">
<title>Dark Side of the Moon</title>
<artist>Pink Floyd</artist>
<year>1971</year>
</album>
<album type="CD">
<title>Splinter</title>
<artist>The Offspring</artist>
<year>2003</year>
</album>
<album type="MP3">
<title>Turn Blue</title>
<artist>The Black Keys</artist>
<year>2014</year>
</album>
</collection>
The root element in the example above is <collection>. All <album> elements in the document are
contained within <collection>. The <album> element has three children: <title>,< artist> and <year>. In
the example above, <collection> and <album> have element contents, because they contain other
elements. <album> also has an attribute (type=" ") that signifies the type of the album in the collection.
<title>, <artist> and <year> have text content because they contain text.
As the name implies, XML Elements are Extensible. XML elements can be extended to carry more
information. Using the above example, additional elements could be added to the <album> element (e.g.
<purchaseDate> and <purchasePrice>) or an additional attribute, such as genre could be included. These
additions would not break software that extracts the current data. These new elements and attributes are
simply ignored. See [1] for a more detailed introduction to XML.
Introduction to XML Schema
The previous section defined the syntax of an XML document. An XML document that is syntactically
correct is called “well formed.” Because designers of XML documents are free to choose their own tags,
elements and attributes, as well as any valid values, there is a further need to validate an XML document
against the XML document designer’s criteria. XML schemas are used for this purpose. An XML schema
describes the structure of an XML document. An XML document validated against an XML schema is
considered both "Well Formed" and "Valid."
Just like XML documents, XML schemas are written in XML. There is no need to learn another language.
An XML editor can be used to edit schema files and an XML parser can parse schema files.
One of the greatest strength of XML schemas is the support for data types. This allows XML document
designers to describe document content, define restrictions on data and to provide validation criteria to
ensure correctness of data.
2015 ODVA Industry Conference
3
©2015 ODVA, Inc.
Figure 2 – Sample XML Schema Snippet
<xs:element name="album">
<xs:complexType>
<xs:sequence>
<xs:element name="title" type="xs:string"/>
<xs:element name="artist" type="xs:string"/>
<xs:element name="year">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minInclusive value="1948"/>
<xs:maxInclusive value="2015"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
<xs:attribute name="type" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="Vinyl"/>
<xs:enumeration value="CD"/>
<xs:enumeration value="MP3"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
The schema above is interpreted like this:
 <xs:element name="album"> defines the element called "album."
 <xs:complexType> indicates that the "album" element is a complex type.
 <xs:sequence> indicates that the complex element “album” contains other elements that must
appear in the defined sequence.
 <xs:element name="title" type="xs:string"> indicates that the element “title” is a string.
 <xs:element name="artist" type="xs:string"> indicates that the element “artist” is a string.
 <xs:element name="year"> starts the definition of the simple element “year” which is of type
integer and has legal values in the range of 1948 to 2015 inclusive.
 <xs:attribute name="type" use=”required”> begins the definition of a required attribute called
“type” for the “album” element. This attribute is of type string and can contain only the three
defined enumerations; “Vinyl,” “CD” or “MP3.”
The above example illustrates only a few of the many data validation techniques available using XML
schema. See [2] for a more detail introduction to XML schema.
Introduction to XML Document Object Model
The W3C defines a standard for accessing and manipulating XML. Called the XML Document Object
Model (DOM). every Element, Attribute and Text field in an XML document is considered a node. XML
DOM views an XML document as a tree-structure, called a node-tree. Most, if not all, modern compiler
libraries and all browsers have a built-in XML parser that can be used to read and manipulate XML. This
can be done by traversing the node-tree or by accessing nodes directly via their name. See [3] for more
information on XML DOM.
2015 ODVA Industry Conference
4
©2015 ODVA, Inc.
EDS File Organization
An EDS file contains an ASCII representation of a device’s parameter objects and some additional
information required to support object addressing. It is organized as a series of sections. Each section
begins with the section name enclosed in brackets (e.g. [File], [Device], etc.). Within each section are
entry keywords. Each entry keyword contains fields separated by commas. Each entry keyword definition
is terminated with a semicolon. The figure below illustrates the defined EDS file format [4].
Figure 3 - Basic Structure of an EDS File
[section name]$ Comment - extends to end of line
Entry1=value,value,value;
Entry2=
value,
value,
value;
$
$
$
$
$ Entire entry on one line
Entry3=
value, value,
value,
value;
Multiple line entry
Field1
Field2
Field3
$
$
$
$
Combination
Fields 1 and 2 on one line
Field3
Field4
Entry5 = 1,
{1,2,3};
$ Field 1 specifies the value 1
$ Field 2 specifies an array or
$ structure with three values
Entry6 = { 44, {22,33,11} };
$
$
$
$
Entry 6 specifies a single field.
The field contains two sets of data.
The first set is a single value 44.
The second set contains three values.
A similar approach can be used with XML as shown below. At this level, it would be hard to argue the
advantages or disadvantages of either format. One distinct difference is to note that in EDS files, the
names of fields can only be shown in comments, while in XML files, they are part of the document.
Hence, if the author of an EDS file chooses not to include comments, the readability of the data depends
upon the prior knowledge of the reader.
2015 ODVA Industry Conference
5
©2015 ODVA, Inc.
Figure 4 – Example, Basic Structure of an XML DD File
<?xml version="1.0" encoding="UTF-8"?>
<sectionName>
<!-- Entry all on one line -->
<entry1><field1>value</field1><field2>value</field2><field3>value</field3></entry1>
<!-- All elements (fields) on separate lines -->
<entry2>
<field1>value</field1>
<field2>value</field2>
<field3>value</field3>
</entry2>
<!-- Mixed format -->
<entry3>
<field1>value</field1> <field2>value</field2>
<field3>value</field3>
<field4>value</field4>
</entry3>
</sectionName>
File Description Section
The file description section begins with the keyword [File] and contains administrative information about
the EDS file. A configuration tool can read this information and display it to the user. A user can also
access this section by opening an EDS file with a text editor. The figure below is an example of a [File]
Description section within an EDS file.
Figure 5 – EDS File Description Section Example
[File]
DescText = "Smart Widget EDS File";
CreateDate = 04-03-1994;
$ created
CreateTime = 17:51:44;
ModDate = 04-06-1994;
$ last changed
ModTime = 22:07:30;
Revision = 2.1;
$ Revision of EDS
HomeURL = “http://www.odva.org/EDS/example.eds”;
[Device]
...
An example of how the File Description section could be represented using XML appears in the figure
below. Currently, the EDS definition does not contain any information on how to indicate what version of
the CIP specification the EDS is based upon. In the XML file example below, the schema on which the
XML file is based is specified in the attributes appearing in the <product> element. As the XML definitions
are extended, newer versions of the schemas can be created to describe the extensions. The schema
revision will dictate the version of the XML file definition.
2015 ODVA Industry Conference
6
©2015 ODVA, Inc.
Figure 6 – Sample File Description Section Using XML
<?xml version="1.0" encoding="UTF-8"?>
<product xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:noNamespaceSchemaLocation="CIP_DD_V03_18.xsd">
<file>
<description>Smart Widget XML File</description>
<creationDate>15-Aug-2015</creationDate>
<creationTime>10:56:22</creationTime>
<modificationDate>06-Oct-2015</modificationDate>
<modificationTime>17:11:49</modificationTime>
<DDRevision>1.00</DDRevision>
<homeURL>http://www.odva.org/DD/example.XML</homeURL>
</file>
</product>
Device Description Section
The device description section begins with the keyword [Device] and contains manufacturer’s information
about the device, including some of the same values in a device’s Identity Object. A sample device
description appears in the figure below.
Figure 7 – EDS Device Description Section Example
[File]
...
[Device]
VendCode = 65535;
VendName = "Widget-Works, Inc.";
ProdType = 43;
ProdTypeStr = “Generic Device”;
ProdCode = 42;
MajRev = 1;
$ Device Major Revision
MinRev = 1;
$ Device Minor Revision
ProdName = "Smart-Widget";
Catalog = “1499-DVG”;
Icon = “example.ico”;
...
2015 ODVA Industry Conference
7
©2015 ODVA, Inc.
Figure 8 below shows an example of an XML element for the description of a device.
Figure 8 – Sample Device Description Section Using XML
<?xml version="1.0" encoding="UTF-8"?>
<product xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:noNamespaceSchemaLocation="CIP_DD_V03_18.xsd">
<file></file>
<device>
<vendorName>Widget Works, Inc.</vendorName>
<vendorCode>65535</vendorCode>
<productName>Smart Widget</productName>
<productType>43</productType>
<productTypeString>Generic Device</ProductTypeString>
<productCode>42</productCode>
<majorRevision>1</majorRevision>
<minorRevision>1</minorRevision>
<catalog>1492-RAB</catalog>
<icon>example.ICO</icon>
</device>
</product>
The [File] and [Device] Description sections of an EDS file contain Entry keywords that have only one
field each. The above XML examples describing this same data used complex elements (<file> and
<device>) in place of the sections and text elements to describe the various Entry Keywords. The next
section will show how more complex EDS constructs could be rendered using XML.
Parameter Section
The parameters section of an EDS file can contain a variety of entry Keywords, each containing
numerous fields. As shown in Figure 9, comments are used extensively to document the meaning of
each field.
2015 ODVA Industry Conference
8
©2015 ODVA, Inc.
Figure 9 – EDS Parameter Section Example
[File]
...
[Params]
Param1 = 0,
6,"20 04 24 68 30 03", $ Link Path Size, Link Path
0x0002,
$ Descriptor
0xD1, 1,
$ BYTE Data Type, Data Size
"Idle Action",
$ Name
"",
$ Units
"",
$ Help string
,,0,
$ Min/Max/Default
,,,,
$ Scaling
,,,,;
Enum1 =
0, "Fault",
1, "Stop",
2, "Zero Data",
3, "Hold Last",
4, "Send Flt Cfg”;
Fixed1 =
1, 0,
$ The idle action is never stop
4, 1;
$ The fault configuration is always sent
Param2 =
$ not addressable from link
0, , , 0x0082, 0xC6, 1, "speed control", "", "", 3, 12,
Enum2 = 3, "stop", 8, "slow", 12, "fast";
ConstructedParam1=
“20 4e 24 01 30 09”,
$ Link Path
0x0000,
$ Descriptor
1,10,
$ SIGNED_ODOMETER, Data
"Total Energy",
$ Name
"kWh",
$ Units
{“TWh”,”GWh”,”MWh”,”kWh”,”Wh”}, $ Member Units
"Total energy in kWh",
$ Help string
{“This is Terawatt-Hours”,
“This is Gigawatt-Hours”,
“This is Megawatt-Hours”,
“This is Kilowatt-Hours”,
“This is Watt-Hours”},
$ Member Help
{-999,-999,-999,-999,-999},
$ Min
{999,999,999,999,999,999},
$ Max
{0,0,0,0,0}
$ Default
1,
$ 1 Type Specific Field
-3;
$ Decimal point location
3, ,,,,,,,,;
Size
follows
between Wh and kWh
In the above example, the Enum and Fixed keywords are actually disjoint from the associated Param
keyword. Only the value after the keyword connects them together. Figure 10 demonstrates one
methodology that could be used to represent the above parameter section. The enum and fixed
constructs are embedded in the associated parameter definition. Unlike EDS files, where every field
needs to be present, even if empty, XML documents only need to describe those elements and attributes
that differ from their default values. Several alternatives exist, and some are explored in later sections.
Many of the alternatives depend upon whether tools using the XML data have underlying knowledge of or
depend upon content from a device description file.
2015 ODVA Industry Conference
9
©2015 ODVA, Inc.
Figure 10 – Sample Parameters Section Using XML
<?xml version="1.0" encoding="UTF-8"?>
<product xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:noNamespaceSchemaLocation="CIP_DD_V03_18.xsd">
<parameters>
<parameter id="1">
<path>20 04 24 68 30 03</path>
<descriptor>
<getEnumStrSupported>1</getEnumStrSupported>
</descriptor>
<name>IO Action</name>
<data size="1" type="BYTE">
<default>0</default>
<enum bit="0">Fault</enum>
<enum bit="1" fixed="0">Stop</enum>
<enum bit="2">Zero Value</enum>
<enum bit="3">Hold Last Value</enum>
<enum bit="4" fixed="1">Send Flt Cfg</enum>
</data>
</parameter>
<parameter id="2">
<descriptor>
<getEnumStrSupported>1</getEnumStrSupported>
<disjointEnumsSupported>1</disjointEnumsSupported>
</descriptor>
<name>Speed Control</name>
<data size="1" type="USINT">
<default min="3" max="12">3</default>
<enum value="3">Slow</enum>
<enum value="8">Medium</enum>
<enum value="12">Fast</enum>
</data>
</parameter>
<parameter id="3" constructed="TRUE" members="5" size="10" units="kWh">
<path>20 4E 24 01 30 09</path>
<name>Total Energy</name>
<help>Total energy in kWh</help>
<data id="1" size="2" type="INT" units="TWh">
<default min="-999" max="999">0</default>
<help>This is Terawatt-Hours</help>
</data>
<data id="2" size="2" type="INT" units="GWh">
<default min="-999" max="999">0</default>
<help>This is Gigawatt-Hours</help>
</data>
<data id="3" size="2" type="INT" units="MWh">
<default min="-999" max="999">0</default>
<help>This is MegaWatt-Hours</help>
</data>
<data id="4" size="2" type="INT" units="kWh">
<default min="-999" max="999">0</default>
<help>This is kiloWatt-Hours</help>
</data>
<data id="5" size="2" type="INT" units="Wh">
<default min="-999" max="999">0</default>
<help>This is Watt-Hours</help>
</data>
2015 ODVA Industry Conference
10
©2015 ODVA, Inc.
<!-- Decimal point location between Wh and kWh -->
<typeSpecific id="1">-3</typeSpecific>
</parameter>
</parameters>
</product>
In the above example, the various bits of the <descriptor> element are represented by children elements
for each set bit. Bits that are not set are not present. The value of the Descriptor field of Param2 in the
EDS file is 0x0082. This could simply be replicated in the XML file using the following Element
description.
<descriptor>0x0082</descriptor>
Unfortunately, this provides no information to the reader or to a tool interpreting the DD file regarding the
meaning of the bits that are set. The following XML demonstrates a method by which each bit that is set
could be named.
Figure 11 – Sample <descriptor> Element Showing Only Set Bits
<descriptor>
<getEnumStrSupported>1</GetEnumStrSupported>
<disjointEnumsSupported>1</DisjointEnumsSupported>
</descriptor>
The above method is better than the first example for someone reading the XML document, but for a tool
that needs to display the values of all the bits in the field, there is still not enough information. Also, a tool
would only have element names as reference, not readable text. Additionally, translations to other
languages are not feasible using this method. One solution would be to hardcode the definitions in a tool,
but this requires tool maintenance if definitions are changed or augmented. Another approach would be to
encode the required definitions within the Device Description file. The following XML code demonstrates a
method that could be used to fully describe the Descriptor field within a Device Description file. Also,
translated strings can be defined for each bit by adding a language attribute to each bit element.
Figure 12 – <descriptor> Element With Full Translated Enumerations
<descriptor>
<value>0x0082</value>
<enum bit="0">Supports Parameter Instance</enum>
<enum bit="0" lang="FRE">Supporte l’instance de parametre</enum>
<enum bit="0" lang="GER">Unterstützt Parameterinstanz</enum>
<enum bit="1">Supports Full Attributes</enum>
<enum bit="1" lang="FRE">Supporte la totalite des attributes </enum>
<enum bit="1" lang="GER">Unterstützt alle Attribute</enum>
<enum bit="2">Non-volatile storage save command required</enum>
<enum bit="2" lang="FRE">Commande de sauvegarde de la memoire non volatile
necessaire </enum>
<enum bit="2" lang="GER">Erfordert Kommando zum nicht flüchtigen
Speichern</enum>
...
</descriptor>
The above approach, while quite readable for someone manually reading the file, would require much
redundant information within a Device Description file for an Element like Descriptor, since it appears in
every Parameter Element. A single definition of the enumerations could be defined and referenced by
each Descriptor Element. This would hamper manual readability but would provide a more concise
2015 ODVA Industry Conference
11
©2015 ODVA, Inc.
representation. This is just one of the tradeoffs that would need to be considered when creating an XML
DD file definition.
XML Device Description Schema
There are two main consumers of device description files. Humans read printed copies in order to assist
them in installing, configuring and troubleshooting devices. If, in the case of an EDS file there is a missing
semicolon, or in the case of an XML file there is an inconsistent opening and closing tag, a human will
simply overlook this insignificant inconsistency. Computers interpreting device description files are not so
tolerant. Device descriptions, whether EDS or XML, must be well formed for proper computer
consumption. Well formed means that the file is grammatically correct. However, being well formed is not
sufficient. For example, imagine a “version” field or element. The expected content should be in the form
of xx.yy where xx and yy represent numbers from 01 to 99. Now, imagine that in the DD file, its value is
set to “17.1234.” While this is syntactically correct for the file format, it is not correct for its intended value.
EZ-EDS is used to prevent this for EDS files. In the case of an XML DD file, XML Schema is used.
Not only can XML schema be used to assist in creating valid XML files, it can be used to make sure an
XML file is valid before attempting to interpret its contents. As software parsing of device description files
becomes more prevalent, it is imperative that these files can be checked for validity at runtime and
contain as much information as possible. This will enable lightweight tools to be developed with little or no
knowledge of CIP devices, relying mainly on device description files. Additionally, XML schema files can
contain default values, eliminating the need to build default values into a tool.
Another advantage of XML schemas is that an XML DD file can specify which schema file to use for
validation. Hence, it is evident to which version of the specification the XML DD file is compliant.
Figure 13 illustrates a simplified XML DD file showing an example of a <parameters> element. Two
<parameter> elements are shown. Note the simplified notation for an empty <descriptor/> element in the
second <parameter> element rather than the more verbose form of <descriptor></descriptor>.
2015 ODVA Industry Conference
12
©2015 ODVA, Inc.
Figure 13 – Simplified XML DD of <parameters> Element
<?xml version="1.0" encoding="UTF-8"?>
<product xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="CIP_DD_V03_18.xsd">
<parameters>
<parameter id="1">
<name>RPILimits</name>
<helpstring>This parameter defines the minimum, maximum and default RPI values
for this product.</helpstring>
<data>
<datasize>4</datasize>
<datatype>UDINT</datatype>
<dataunits>microseconds</dataunits>
<defaultvalue>10000</defaultvalue>
<minvalue>2000</minvalue>
<maxvalue>50000</maxvalue>
</data>
<descriptor>0</descriptor>
</parameter>
<parameter id="2">
<name>InputSize</name>
<helpstring>This parameter defines the input data size</helpstring>
<path>20 04 24 65 30 04</path>
<data>
<datasize>2</datasize>
<datatype>UINT</datatype>
<dataunits>bytes</dataunits>
<defaultvalue>0</defaultvalue>
<minvalue>0</minvalue>
<maxvalue>496</maxvalue>
</data>
<descriptor/>
</parameter>
</parameters>
</product>
Figure 14 below shows a sample schema file for the above XML DD file. It demonstrates some of the
constructs available to an XML designer to validate the contents of an XML file. It is not intended to be a
comprehensive validation of all legal constructs but only to serve as an introduction to the possibilities.
2015 ODVA Industry Conference
13
©2015 ODVA, Inc.
Figure 14 – XML DD Schema file for Simplified <parameters> Section
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:element name="product">
<xs:complexType>
<xs:sequence>
<xs:element ref="parameters"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="parameters">
<xs:complexType>
<xs:sequence>
<xs:element ref="parameter" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="parameter">
<xs:complexType>
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="helpstring" type="xs:string"/>
<xs:element name="path" minOccurs="0">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="(([0-9a-fA-F]{2} ){2})*([0-9a-fA-F]{2} [0-9a-fAF]{2})?"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element ref="data"/>
<xs:element name="descriptor" type="xs:unsignedShort" default="0"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type="xs:positiveInteger" use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="data">
<xs:complexType>
<xs:sequence>
<xs:element name="datasize" type="xs:positiveInteger"/>
<xs:element name="datatype">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="INT"/>
<xs:enumeration value="DINT"/>
<xs:enumeration value="UINT"/>
<xs:enumeration value="UDINT"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="dataunits" type="xs:string"/>
<xs:element name="defaultvalue" type="xs:string"/>
<xs:element name="minvalue" type="xs:string"/>
<xs:element name="maxvalue" type="xs:string"/>
</xs:sequence>
</xs:complexType>
2015 ODVA Industry Conference
14
©2015 ODVA, Inc.
</xs:element>
</xs:schema>
For the <path> element, the minOccurs attribute defines that this element can be missing in the XML DD
file. If present, it must follow the pattern specified by the following regular expression [5]:
<xs:pattern value="(([0-9a-fA-F]{2} ){2})*([0-9a-fA-F]{2} [0-9a-fA-F]{2})?"/>
The pattern specifies that the path must consist of 0 or more pairs of hexadecimal bytes (e.g. “aa bb” “aa
bb cc dd ee ff” etc.). Note that the regular expression allows for upper of lower case letters.
While the above regular expression can make sure that the path corresponds to a valid format, it does not
validate the correctness. In EZ EDS, the various elements of a path can be entered and it will create the
proper path. This technique could be built into the XML file construction to overcome the previous
example’s deficiency.
The <data> element is specified separately and referenced in the <parameter> element. In this way, its
definition could also be used in other elements (e.g. <assembly>).
The <datatype> element contains an enumeration. Although in the real world the list would be much
longer, it illustrates how element values can be restricted to a predefined set of values.
In the XSD file, the <descriptor> element has a defined default value of 0 and a minOccurs attribute of 0.
This allows the XML file to not define this element. When a tool discovers this element is either missing or
empty, its default value could be obtained from the referenced schema file. This is not possible for empty
fields in the current EDS solution where tools need to know default values.
The value of XML schema files is also apparent during the creation of XML DD files. Modern XML editors
are capable of using XML schema to assist the user in XML file creation. Some XML editors use XML
schema to create entire element structures populating the element with instances of every required child
element and attribute. Upon selection of an element in an XML document, an XML editor can also provide
a list of valid elements and attributes that a user can pick from to add to their document. For
enumerations, a list of values can be shown. Checks for values that do not conform to the schema are
also flagged. The prices (free to hundreds of dollars) and capabilities vary by XML editor tool.
Assume that the following element needs to be added to the sample XML DD file shown in Figure 13.
Figure 15 – Sample <parameter> Element to Add
<parameter id="3">
<name>OutputSize</name>
<helpstring>This parameter defines the output data size</helpstring>
<path>20 04 24 66 30 04</path>
<data>
<datasize>2</datasize>
<datatype>UINT</datatype>
<dataunits>bytes</dataunits>
<defaultvalue>0</defaultvalue>
<minvalue>0</minvalue>
<maxvalue>494</maxvalue>
</data>
</parameter>
The following figure shows a sample XML editor screenshot demonstrating how an XML schema is used
to assist the user in adding this element.
2015 ODVA Industry Conference
15
©2015 ODVA, Inc.
Figure 16 – Example Showing XML Editor Help with Schema
EDS DD file creation and validation benefit from the EZ EDS tool. Unfortunately, updates to this tool lag
behind revisions to ODVA CIP specifications, often by several revision cycles. The process for updating
an ODVA specification begins with a Specification Enhancement document, usually authored by a
Special Interest Group (SIG) and approved by the Technical Review Board (TRB). These approved
enhancements are incorporated into the specifications, reviewed one last time and finally published twice
per year. Using XML DD files, the schema files could be updated at the same time as a Specification
Enhancement, eliminating the lag between specification revisions and a validation availability. Since
schema documents are written in XML, it is possible for the team creating the enhancement to create the
schema. This is not the case for EZ EDS. Schema files for each revision of specifications could be placed
on the ODVA website.
XML Parsing Examples
This section will demonstrate some coding examples to extract data from a sample XML DD file. Two
different scenarios are considered. First, consider a tool that is rather ignorant of the various components
that comprise an XML DD file but simply wants to display information to a user. This could be a webbased or Human Machine Interface (HMI) type application. The second scenario is a tool that needs to
fully comprehend CIP, such as a Programmable Logic Controller (PLC) programming product.
Each example below is written in Javascript and run on a Raspberry Pi based web server. Using the XML
DD file shown in Figure 8, the following HTML file will read the various child elements of the <device>
element and display them to the user. The tag names, followed by an equals sign followed by the value
are presented on separate lines. By choosing descriptive tag names, the output is quite understandable
by a user. Figure 17 shows the code while Figure 18 provides the results.
In the sample code, the variable x contains a list of all child nodes of the root element. In the real world,
the code would be constructed to find the respective parent node of interest. The for-loop checks to see if
the child node is an element. This is needed because some browsers consider whitespace between
elements to also be nodes. The node name (element tag name) and its contents are written followed by a
2015 ODVA Industry Conference
16
©2015 ODVA, Inc.
line break. The XML parser built into the browser makes it possible for a developer to focus on the
required task and not on creating file-specific parsing code.
Figure 17 – JavaScript Example to Read <device> element Children
<html>
<head>
<script src="loadxmldoc.js">
</script>
</head>
<body>
<script>
var xmlDoc=loadXMLDoc("eds device section.xml");
// documentElement always represents the root node
var x=xmlDoc.documentElement.childNodes;
for (i=0;i<x.length;i++)
{
if (x[i].nodeType == 1) // Print only element nodes.
{
document.write(x[i].nodeName);
document.write("= ");
document.write(x[i].childNodes[0].nodeValue);
document.write("<br>");
}
}
</script>
</body>
</html>
Figure 18 – <device> Element Contents Generated by JavaScript Code
vendorCode= 65535
vendorName= Widget Works, Inc.
productType= 1.
productTypeString= Generic Device
productCode= 42
majorRevision= 1
minorRevision= 1
productName= Smart Widget
catalog= 1492-RAB
icon= Example.ICO
Another method to access data in an XML file is to use tag names. The sample JavaScript code in Figure
19 outputs the values of the <name> and <helpString> elements that are children of the <parameter>
elements. Because the tag names are already known, the element names are simply written to the output
in more human readable form. Figure 20 shows the output for a sample file containing six <parameter>
elements.
2015 ODVA Industry Conference
17
©2015 ODVA, Inc.
Figure 19 – JavaScript Code to Read Elements by Tag Name
<html>
<head>
<script src="loadxmldoc.js">
</script>
</head>
<body>
<script>
var xmlDoc=loadXMLDoc("NIP_Parameters.xml");
// Place all parameter elements in param
var param=xmlDoc.getElementsByTagName("parameter");
for (i=0;i<param.length;i++)
{
document.write("Element Name = ");
document.write(param[i].
getElementsByTagName("name")[0].childNodes[0].nodeValue);
document.write("<br>");
document.write("Element Help String = ");
document.write(param[i].
getElementsByTagName("helpstring")[0].childNodes[0].nodeValue);
document.write("<br>");
}
</script>
</body>
</html>
Figure 20 –Element Contents Generated by JavaScript Using Tag Name
Element Name = RPILimits
Element Help String = This parameter defines the minimum, maximum and default RPI
values for this product.
Element Name = InputSize
Element Help String = This parameter defines the input data size
Element Name = OutputSize
Element Help String = This parameter defines the output data size
Element Name = DiagnosticSize
Element Help String = This parameter defines the Diagnostic data size
Element Name = DiagnosticRPILimits
Element Help String = This parameter defines the minimum, maximum and default RPI
values for the diagnostic assembly in this product.
The two code samples above demonstrate the ease of extracting data from XML files using JavaScript.
This introduction only scratches the surface of the plethora of methods available for accessing data
stored in XML files. While not intended as a tutorial, several methods were shown. Library references
exist for many modern programming languages and platforms. These libraries allow programmers to
focus on data manipulation and not have to worry about complex parsing of file structures. With the ability
to dynamically verify and validate an XML file’s content prior to its use, less error handling code is
needed.
Synergies
Protocols like Automation Markup Language (AutomationML) [8] “is an XML schema based data format
and has been developed in order to support the data exchange in a heterogeneous engineering tools
2015 ODVA Industry Conference
18
©2015 ODVA, Inc.
landscape. The goal of AutomationML is to interconnect engineering tools in their different disciplines,
e.g. mechanical, plant engineering, electrical design, process engineering, process control engineering,
HMI development, PLC programming, robot programming, etc.” The XML DD file proposed in this paper
lowers the entry point to interconnect a CIP Automation Environment with AutomationML based tools.
Migration
In the current landscape, there exist thousands of EDS files. Since the use of EZ EDS is not a
requirement, erroneous EDS files exist. Furthermore, many keywords and fields are currently optional that
could become mandatory. Tools also exist that interpret these files.
In its most basic construct, migration would consist of converting existing EDS file to XML and enhancing
existing tools to recognize, in the short term, both formats, and in the long term, only the newer format. As
with all transitions, this cannot occur instantaneously, but would require several years to complete.
The migration details, however, are heavily dependent upon the choices made during the creation of an
XML based DD file.
Converting from EDS to XML is quite straightforward if the resulting XML file only represents the current
EDS structure. Unfortunately, this provides little benefit from the current solution. However, if the XML DD
file definition contains structural improvements, the conversion becomes more challenging. In either case,
a software tool could be created to perform the conversion. EZ EDS could be used as a starting point. It
already interprets EDS files an builds a user interface presentation. Replacing its output section to
generate XML could be investigated. Files containing errors could be flagged for manual correction. If
content that was considered optional is required, a conversion tool could provide a template, but would
not be able to create the required data. This would necessitate manual intervention.
Tools would also need to be enhanced to recognize the XML format. Again, if only a format conversion
were present, little or no changes would be needed to work with the data content. Only the gathering of
the data would change, Processing the information remains as present. With a more comprehensive
restructuring of the DD format, tools would need to change to process the restructured format. A tool
could further take advantage of the random access capability provided by XML files by processing only
the data pertinent to its operation.
Some devices store their EDS file in their nonvolatile memory using a specific instance of the File object.
In order to accommodate an alternative file format, changes would be needed to the File object
specification. This could be a simple as allowing either an EDS or XML file to exist in a specific instance
of the File object or the creation of a new instance. An XML DD file could also be larger than its EDS
counterpart, especially if optional material became mandatory. This could become problematic for older
devices with limited storage. Binary compression standards exist for XML files that could be considered.
Embarking upon a journey to switch from the current EDS format to an XML based DD format needs to
consider migration as it evaluates the choices to be made.
2015 ODVA Industry Conference
19
©2015 ODVA, Inc.
Summary
The following table summarizes a comparison between EDS and XML based DD files.
ASCII Format
Support for other formats (e.g.
Unicode)
Human readable
XML
Yes
Yes
EDS
Yes
No
Yes
Yes, with use of optional
comments
Yes, EZ EDS
Text editor (yes) EZ EDS (no)
Context driven generation tool
Yes 1
Platform independent editing
Yes
tools
Static validation
Yes
Yes, but out of date
Dynamic validation
Yes
No
File Format easily understood by Yes
No
recent grads
Parsing supported on multiple
Yes
No
platforms and languages
Extensible
Yes
Limited
Ability to determine spec version
Yes
No
compliance
Integration
Facilitates tools integration
1. Schema cannot replace some of the context editing constructs like path creation help in EZ EDS, on
the other hand, the goal should be to design the XML DD file such that context sensitive tools are not
necessary.
Conclusions
This paper provided a high-level introduction to XML and XML Schemas, followed by a demonstration of
how XML could be used to describe CIP devices instead of using EDS files. It further demonstrated how
easy it is to programmatically extract data from an XML based DD file. Change is always difficult to
embrace, and change for the sake of change would be unwarranted. Parsing of EDS files is present in
many existing tools. A change in device description file format would require existing tools utilizing EDS
files to change. This, coupled with the realization that defining a new XML-based Device Description file
construct along with its schema is not a trivial task, could warrant staying with the antiquated EDS file
format. However, there are many advantages of using XML to describe devices that cannot be ignored:
 XML parsing is built into many modern compilers and web browsers.
 XML is understood by most recent Computer Science graduates
 Schema could be updated at the same time as XML enhancements
 XML files can be dynamically verified and validated by tools prior to data extraction
 XML supports more than just ASCII
 XML is extensible
 XML can be made human readable without user comments
The EDS file format has served ODVA well. Unfortunately, it is not well suited for Web and IoT based
applications. As ODVA contemplates future initiatives and alliances, the question to ask is, “Will EDS help
propel ODVA into the future or should alternative Device Description methods be explored?” This paper
presented some compelling reasons to migrate to a new Device Description methodology along with a
few reasons to stay with the current solution. If nothing else, this paper has hopefully whetted ODVA’s
appetite to investigate this topic further and in more depth to form its own conclusions.
2015 ODVA Industry Conference
20
©2015 ODVA, Inc.
References
[1] XML Tutorial, W3C, http://www.w3schools.com/xml/default.asp
[2] XML Schema Tutorial, W3C, http://www.w3schools.com/schema/default.asp
[3] XML DOM Tutorial, W3C http://www.w3schools.com/dom/default.asp
[4] CIP specification, Volume 1, Chapter 7
[5] Regular Expression Quick Reference Brochure, Microsoft Corporation
[6] FDCML 2.0 Specification
[7] ISO 15745:2003 Industrial automation systems and integration - Open systems application integration
[8] IEC 62714 series, Engineering data exchange format for use in industrial automation systems
engineering – Automation Markup Language
******************************************************************************************************************************************************
The ideas, opinions, and recommendations expressed herein are intended to describe concepts of the author(s) for the possible use
of ODVA technologies and do not reflect the ideas, opinions, and recommendation of ODVA per se. Because ODVA technologies
may be applied in many diverse situations and in conjunction with products and systems from multiple vendors, the reader and
those responsible for specifying ODVA networks must determine for themselves the suitability and the suitability of ideas, opinions,
and recommendations expressed herein for intended use. Copyright ©2015 ODVA, Inc. All rights reserved. For permission to
reproduce excerpts of this material, with appropriate attribution to the author(s), please contact ODVA on: TEL +1 734-975-8840
FAX +1 734-922-0027 EMAIL [email protected] WEB www.odva.org. CIP, Common Industrial Protocol, CIP Energy, CIP Motion, CIP
Safety, CIP Sync, CompoNet, ControlNet, DeviceNet, and EtherNet/IP are trademarks of ODVA, Inc. All other trademarks are
property of their respective owners.
2015 ODVA Industry Conference
21
©2015 ODVA, Inc.