Ethernet POWERLINKXML Device Description
EPSG DS 311 V1.2.1

EPSG Draft Standard 311

Ethernet POWERLINKXML Device Description

Version 1.2.1©

B&R(B&R Industrial Automation GmbH)
2023

EPSG DS 311 V1.2.1-2-

B&R Industrial Automation GmbH

POWERLINK-Office
B&R Straße 15142 Eggelsberg
Austria

powerlink.office@br-automation.com
www.br-automation.com/en/technologies/powerlink/

The EPSG Draft Standard 311 “Ethernet Powerlink XML Device Description” has been provided by
Ethernet POWERLINK Standardisation Group (hereinafter referred to as “EPSG”). As a consequenceof the EPSG being dissolved from March 31st, 2023, B&R Industrial Automation GmbH will – as theformal successor of EPSG regarding the rights and content – make the Ethernet Powerlink XML
Device Description available as open source on it’s own website subject to the conditions mentioned
in the disclaimer under clause Pre. 1 of this document. B&R Industrial Automation GmbH especiallydisclaims liability for any personal injury, property or other damage, of any nature whatsoever, whether
special, indirect, consequential, or compensatory, directly or indirectly resulting from the publication,use of, or reliance upon this, or any other EPSG Standard document.

EPSG DS 311 V1.2.1-3-Disclaimer
Use of this EPSG Standard is wholly voluntary. The EPSG disclaims liability for any personal injury,
property or other damage, of any nature whatsoever, whether special, indirect, consequential, orcompensatory, directly or indirectly resulting from the publication, use of, or reliance upon this, or any
other EPSG Standard document.
The EPSG does not warrant or represent the accuracy or content of the material contained herein,and expressly disclaims any express or implied warranty, including any implied warranty ofmerchantability or fitness for a specific purpose, or that the use of the material contained herein is freefrom patent infringement. EPSG Standards documents are supplied “AS IS”.
The existence of an EPSG Standard does not imply that there are no other ways to produce, test,
measure, purchase, market, or provide other goods and services related to the scope of the EPSG
Standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued issubject to change brought about through developments in the state of the art and comments received
from users of the standard. Users are cautioned to check to determine that they have the latest editionof any EPSG Standard.
In publishing and making this document available, the EPSG is not suggesting or rendering
professional or other services for, or on behalf of, any person or entity. Nor is the EPSG undertaking toperform any duty owed by any other person or entity to another. Any person utilizing this, and anyother EPSG Standards document, should rely upon the advice of a competent professional indetermining the exercise of reasonable care in any given circumstances.
Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as
they relate to specific applications. When the need for interpretations is brought to the attention of the
EPSG, the group will initiate action to prepare appropriate responses. Since EPSG Standards
represent a consensus of concerned interests, it is important to ensure that any interpretation has also
received the concurrence of a balance of interests. For this reason, the EPSG and its members are
not able to provide an instant response to interpretation requests except in those cases where thematter has previously received formal consideration.
Comments for revision of EPSG Standards are welcome from any interested party, regardless ofmembership affiliation with the EPSG. Suggestions for changes in documents should be in the form ofa proposed change of text, together with appropriate supporting comments. Comments on standards
and requests for interpretations should be sent to the address given on the page before.

EPSG DS 311 V1.2.1-4-

Patent noticeAttention is called to the possibility that implementation of this standard may require use of subject
matter covered by patent rights. By publication of this standard, no position is taken with respect to theexistence or validity of any patent rights in connection therewith. B&R shall not be responsible for
identifying patents for which a license may be required by an EPSG standard or for conducting
inquiries into the legal validity or scope of those patents that are brought to its attention.

EPSG DS 311 V1.2.1-5-

History
Vers.
0.0.1
0.0.2
0.0.3

Date
2006.03.20
2006.04.13
2006.05.09

Author(s)F.Matejka
F.Matejka
F.Matejka

B&R
B&R
B&R

Description
Document started
First public release of the document
Corrected typos. Removed access types rwr and rww(these are not supported by EPL).

0.0.4

2006.06.02

F.Matejka

B&R

Corrected typos. Added descriptions in table “Attributesof element dynamicChannel”. Feedback of Mr. Gedenk.

0.0.5

2006.06.13

F.Matejka

B&R

Editorial changes. Feedback of Ms. Böttger.

0.0.6

2006.06.13

F.Matejka

B&R

Included changes from the CiA WD 311 CANopen XML
specification Version 0.4. Main change is the additional
text resource file. Two appendices added. Referenced
new schema version 0.8.

0.0.7

2006.07.24

F.Matejka

B&R

Corrected 2 typos in Tab. 54 and 55.

0.0.8

2006.11.16

F.Matejka

B&R

Added cover pages. Changed status from white paper
to draft standard proposal (approved by TWG ready for
2 month commenting period). File name changed toreflect document status.

0.0.9

2007.03.01

F.Matejka

B&R

Changes as agreed at TWG Meeting 28.02.2007.
Considered changes of CiA document from V0.4 toV0.5.2.
Included the schema files in the document (like in theCiA document).

0.0.102007.03.26

F.Matejka

B&R

Synchronized with CiA DS 311 Version 1.0 (minor
editorial changes).

1.0.0

2007.10.25

F.Matejka

B&R

Changed status to draft standard. Changed contact
address.

1.0.1

2012.09.18

S. Kirchmayer

B&R

Modular IOs

1.0.2

2013.08.20

S. Kirchmayer

B&R

Changes from TWG meeting in 3/13

1.0.2

2014.04.15

S. Kirchmayer

B&R

Status changed to DSP, new office address

1.1.0

2015.12.04

S. Kirchmayer,
B. Avramov,
C. Ruecker

B&R

Schema listings deleted,

Version was not distributed.

Object firmwareList subindex 0 ro
bitOffset added
References updated
connectorList addedclassificationList added

1.1.1

2016-06-22

S. Kirchmayer,
B. Avramov,
C. Ruecker

B&R

Modular device profiles added
modulManagement added

1.2.0

2016-09-15

S. Kirchmayer

B&R

Status changed to DS

1.2.1

2023-06-02

S. Kirchmayer

B&R© B&R due to dissolution of EPSGEPSG DS 311 V1.2.1-6-

Content
Disclaimer

3

Patent notice4

History

5

Content

6

1

Introduction

10

2

Scope

11

3

References

124

Notational conventions13

5

Abbreviations

14

6

POWERLINK profiles

15

6.1
Device profile
6.1.1
General6.1.2
Device identity
6.1.3
Device manager
6.1.4
Device function
6.1.5
Application process

15
15
15
16
16
16

6.2
Communication network profile
6.2.1
General
6.2.2
Application layers
6.2.3
Transport layers
6.2.4
Network management

17
17
17
17
17

POWERLINK profile templates

18

7

7.1

Overview

18

7.2
General rules
7.2.1
Using unique IDs
7.2.2
Language support
7.2.2.1 General
7.2.2.2 Element g_labels
7.2.2.3 Language identifier
7.2.2.4 Attribute lang
7.2.2.5 Attribute supportedLanguages
7.2.2.6 URIs

18
18
18
18
18
20
20
20
20

7.3

20

ProfileHeader

7.4
Device profile template description
7.4.1
ProfileBody_Device_Powerlink
7.4.2
ProfileBody_Device_Powerlink_Modular_Head
7.4.3
ProfileBody_Device_Powerlink _Modular_Child
7.4.4
DeviceIdentity
7.4.4.1 General
7.4.4.2 vendorName
7.4.4.3 vendorID
7.4.4.4 vendorText

21
21
22
22
23
23
23
23
23

EPSG DS 311 V1.2.1-7-

7.4.4.5 deviceFamily
7.4.4.6 productFamily
7.4.4.7 productName
7.4.4.8 productID
7.4.4.9 productText
7.4.4.10
orderNumber
7.4.4.11
version
7.4.4.12
buildDate
7.4.4.13
specificationRevision
7.4.4.14
instanceName
7.4.5
DeviceManager
7.4.5.1 General
7.4.5.2 indicatorList / LEDList
7.4.5.2.1 General
7.4.5.2.2 LED
7.4.5.2.3 combinedState
7.4.5.3 moduleManagement (modular device only)
7.4.5.3.1 General
7.4.5.3.2 interfaceList
7.4.5.3.2.1 General
7.4.5.3.2.2 interface
7.4.5.3.3 moduleInterface
7.4.6
DeviceFunction
7.4.6.1 General
7.4.6.2 capabilities
7.4.6.2.1 General
7.4.6.2.2 characteristicsList
7.4.6.2.2.1 General
7.4.6.2.2.2 characteristic
7.4.6.2.2.3 characteristicName
7.4.6.2.2.4 characteristicContent
7.4.6.2.2.5 standardComplianceList
7.4.6.3 picturesList
7.4.6.4 dictionaryList
7.4.6.5 connectorList
7.4.6.6 firmwareList
7.4.6.7 classificationList
7.4.7
ApplicationProcess
7.4.7.1 General
7.4.7.2 dataTypeList
7.4.7.2.1 General
7.4.7.2.2 Common elements
7.4.7.2.2.1 Group g_simple
7.4.7.2.3 array
7.4.7.2.3.1 General
7.4.7.2.3.2 subrange
7.4.7.2.4 struct7.4.7.2.4.1 General
7.4.7.2.4.2 varDeclaration
7.4.7.2.5 enum
7.4.7.2.5.1 General
7.4.7.2.5.2 enumValue
7.4.7.2.6 derived
7.4.7.2.6.1 General
7.4.7.2.6.2 count
7.4.7.3 functionTypeList
7.4.7.4 functionType
7.4.7.4.1 General
7.4.7.4.2 versionInfo

23
23
23
23
23
24
24
24
24
24
24
24
24
24
25
25
26
26
26
26
26
28
29
29
30
30
30
30
30
30
30
30
30
31
31
33
33
34
34
34
34
35
35
35
35
36
36
36
36
37
37
37
38
38
38
38
39
39
40

EPSG DS 311 V1.2.1-8-

7.4.7.4.3 interfaceList
7.4.7.4.3.1 General
7.4.7.4.3.2 varDeclaration
7.4.7.4.3.3 dataTypeIDRef
7.4.7.5 functionInstanceList
7.4.7.5.1 General
7.4.7.5.2 functionInstance
7.4.7.5.3 connection
7.4.7.6 templateList
7.4.7.7 parameterList
7.4.7.7.1 General
7.4.7.7.2 parameter
7.4.7.7.2.1 General
7.4.7.7.2.2 conditionalSupport
7.4.7.7.2.3 denotation
7.4.7.7.2.4 actualValue
7.4.7.7.2.5 defaultValue
7.4.7.7.2.6 substituteValue
7.4.7.7.2.7 allowedValues
7.4.7.7.2.8 unit
7.4.7.7.2.9 variableRef
7.4.7.7.2.10 instanceIDRef
7.4.7.7.2.11 variableIDRef
7.4.7.7.2.12 memberRef
7.4.7.7.2.13 property
7.4.7.8 parameterGroupList
7.4.7.8.1 General
7.4.7.8.2 parameterGroup
7.4.7.8.3 parameterRef
7.5
Communication network profile template description
7.5.1
ProfileBody_CommunicationNetwork_Powerlink
7.5.2
ProfileBody_CommunicationNetwork_Powerlink_Modular_Head
7.5.3
ProfileBody_CommunicationNetwork_Powerlink_Modular_Child
7.5.4
ApplicationLayers
7.5.4.1 General
7.5.4.2 identity
7.5.4.3 DataTypeList
7.5.4.4 ObjectList
7.5.4.4.1 Object
7.5.4.4.1.1 SubObject
7.5.4.5 dynamicChannels
7.5.4.5.1 dynamicChannel
7.5.4.6 moduleManagement (modular device only)
7.5.4.6.1 General
7.5.4.6.2 interfaceList / interface
7.5.4.6.2.1 General
7.5.4.6.2.2 rangeList / range
7.5.5
TransportLayers
7.5.6
NetworkManagement
7.5.6.1 Features
7.5.6.1.1 Feature Names
7.5.6.1.2 Feature Data Types
7.5.6.2 deviceCommissioning
7.5.6.3 Diagnostic
7.5.6.3.1 ErrorList
7.5.6.3.1.1 Error
7.5.6.3.2 StaticErrorBitField

40
40
40
41
41
41
41
42
42
43
43
44
44
45
46
46
46
46
46
47
47
47
48
48
48
48
48
49
50
52
52
52
52
53
53
53
54
55
56
58
60
60
61
61
61
61
61
63
63
64
64
64
64
65
65
65
66

EPSG DS 311 V1.2.1-9-

8File naming convention

68

9

Tool behaviour

69

App. 1

Value syntax (normative)

70

App. 2XML file content convention (normative)

71

App. 3XML file naming syntax (normative)

72

App. 4

Text resource

73

App. 5

Child identification (normative)

74

App. 6

Child firmware update (normative)

75

App. 7

ParameterGroup and parameterRef bitOffset attribute usage

76

EPSG DS 311 V1.2.1

1

-10-

Introduction

This specification defines the device description and device configuration file format for EPSG DS 301,
Ethernet POWERLINK Communication Profile Specification [7].
The format is based on the corresponding CANopen specification, "CiA DS 311 CANopen device
description Version 1.0". Therefore many parts of the CANopen specification are mirrored in thisdocument.
Alongside this document XML schema files are provided. The schema version 0.15 is described within
this document.
The XML schema files are:•Powerlink_Main.xsd•
CommonElements.xsd•
CommonElements_Modular.xsd•
ISO15745ProfileContainer.xsdProfileBody_Device_Powerlink.xsd•
ProfileBody_CommunicationNetwork_Powerlink.xsd•
ProfileBody_Device_Powerlink_Modular_Head.xsd•
ProfileBody_Device_Powerlink_Modular_Child.xsd•
ProfileBody_CommunicationNetwork_Powerlink.xsd•
ProfileBody_CommunicationNetwork_Powerlink_Modular_Head.xsd•
ProfileBody_CommunicationNetwork_Powerlink_Modular_Child.xsd•
TextResource.xsd

EPSG DS 311 V1.2.1

2

-11-

Scope

This specification defines the elements and rules for describing device profiles and communication
network profiles for devices used in POWERLINK systems. The content of this specification complies
with the definitions and provisions of ISO 15745-1:2005/Amd1.
NOTE Part 1 of ISO 15745 specifies generic elements and rules for describing integration models
and application interoperability profiles, together with their component profiles. The formal description
is based on XML technology.

EPSG DS 311 V1.2.1

3

-12-

References[1] ISO 15745-1:2003, Industrial automation systems and integration – Open systems application
integration framework – Part 1: Generic reference description[2] ISO 15745-1:2003/Amd1:2007, Industrial automation systems and integration – Open systems
application integration framework – Part 1: Generic reference description (proposed Amendment 1)[3] ISO 639-2, Codes for the representation of names of languages – Part 2: Alpha-3 code[4] ISO 3166-1, Codes for the representation of names of countries and their subdivisions – Part 1:
Country codes[5] IEC 61131-3, Programmable controllers – Part 3: Programming languages[6] ISO 1000, SI units and recommendations for the use of their multiples and of certain other units[7] EPSG Draft Standard 301 (EPSG DS 301), Ethernet POWERLINK, Communication Profile
Specification[8] EPSG Draft Standard 302-F (EPSG DS 302-F), Ethernet POWERLINK, Part F: Modular Device

EPSG DS 311 V1.2.1

4

-13-

Notational conventions

Figure 1 explains the notational conventions used in all those figures within this document, which
illustrate the structure of XML schema partitions. The notation is the one used by a specific XML tool.
The figure shows the hierarchical arrangement of sequences or choices of elements. All these items
can be characterized as mandatory, optional, or having a given multiplicity - see the different
examples in the figure.
Elements without sub-structure may have textual content (icon showing lines - example: Element11)
Elements can be declared local inside parent elements (no arrow shown), or they can be declared
global, which means that they can be referenced (arrow shown) from one to many places in the
structure (example: Element1 is referenced from inside the ROOT element and from inside Element2).

Fig. 1.

Notational ConventionsEPSG DS 311 V1.2.1

5
HMI
ISO
LED
OSI
URI
XML

-14-

Abbreviations
Human Machine Interface
International Organization for Standardization
Light Emitting Diode
Open Systems Interconnection
Uniform Resource Identifier
Extensible Markup Language

EPSG DS 311 V1.2.1

-15-

6

POWERLINK profiles

6.1

Device profile

6.1.1

GeneralFig. 2 shows the element structure of a POWERLINK device profile.

Fig. 2.

device profile element

NOTE 1 The additional ExternalProfileHandle element shown in Fig. 2 enables external non-XML
data to be referenced.
NOTE 2 The ProfileIdentification, ProfileRevision, and ProfileLocation attributes of theProfileHandle_DataType refer to the external non-XML data file. This can be used by legacy systems
that are in the process of migrating to XML.

6.1.2

Device identity

The DeviceIdentity element contains attributes that are independent of the network and of the process,and which uniquely identify the device (for further information see 7.4.4).
Fig. 3 shows the structure of the DeviceIdentity element.

Fig. 3.

DeviceIdentity element

EPSG DS 311 V1.2.1

6.1.3

-16-

Device manager

The DeviceManager element contains attributes and supports services that enable the monitoring of
the device.
Fig. 4 shows the structure of the DeviceManager element

Fig. 4.

6.1.4

DeviceManager element

Device function

The DeviceFunction element describes the intrinsic function of a device in terms of its technology. It
contains network independent descriptions/definitions of the technological device functionality (forfurther information see 7.4.6).
Fig. 5 shows the structure of the DeviceFunction element.

Fig. 5.

6.1.5

DeviceFunction element

Application process

The ApplicationProcess element represents the set of services and parameters, which constitute thebehaviour and the interfaces of the device in terms of the application, independent of the device
technology and the underlying communication networks and communication protocols (see 7.4.6.5).
Fig. 6 shows the structure of the ApplicationProcess element.

EPSG DS 311 V1.2.1

Fig. 6.

-17-

ApplicationProcess element

6.2

Communication network profile

6.2.1

GeneralFig. 7 shows the element structure of the communication network profile.

Fig. 7.

Communication network profile element

NOTE: The additional ExternalProfileHandle element shown in Fig. 7 enables external non-XML data
to be referenced. The ProfileIdentification, ProfileRevision, and ProfileLocation attributes of theProfileHandle_DataType refer to the external non-XML data file. This can be used by legacy systems
that are in the process of migrating to XML.

6.2.2

Application layers

The ApplicationLayers element represents POWERLINK application layer, e.g. gives detailed
information about a devices object dictionary (for further information see 7.5.4).

6.2.3

Transport layers

The TransportLayers element is present for compatibility to the CANopen XML device description. For
POWERLINK this element is empty.

6.2.4

Network management

The NetworkManagement element is used to store specific device features and diagnostic capabilities(for further information see 7.5.6).

EPSG DS 311 V1.2.1

-18-

7

POWERLINK profile templates

7.1

Overview

POWERLINK is a hard real time communication system based on the Standard IEEE 802.3.
The POWERLINK technology uses the concept of the multi-profile container specified in ISO 15745
1:2005/Amd.1 for XML profile files. Therefore, POWERLINK profile templates are based on thealternate ISO15745ProfileContainer master profile template specified in amendment 1 of ISO 15745 1.
Fig. 8 shows the structure of a POWERLINK XML profile. Two types of ProfileBody are defined for
POWERLINK profiles:•
ProfileBody_Device_Powerlink and•ProfileBody_CommunicationNetwork_Powerlink.
Two types of ProfileBody are defined for POWERLINK modular head node profiles:•
ProfileBody_Device_Powerlink_Modular_Head and•ProfileBody_CommunicationNetwork_Powerlink_Modular_Head.
Two types of ProfileBody are defined for POWERLINK modular child node profiles:•
ProfileBody_Device_Powerlink_Modular_Child and•ProfileBody_CommunicationNetwork_Powerlink_Modular_Child.

Fig. 8.

Master profile template

The ProfileTechnology name according to ISO 15745-1 is POWERLINK.

7.2

General rules

7.2.1

Using unique IDs

An element can have the attribute uniqueID of type xsd:ID. The unique identifier therefore is forced to
be unique in the whole XML file. An element that references the unique identifier contains a named
attribute of type xsd:IDREF.

7.2.2

Language support

7.2.2.1

General

Device profiles complying with the XML schema described here need a support of different languages,
since tools are then able to use names out of the XML file in order to display them in their userinterface. Communication parameters for example may be presented in the user interface of a tool.
The language support is implemented via the label group g_labels. Each name of an element, which
would possibly be displayed and is therefore language dependent, is provided inside the schema as ag_labels element. Optionally, a URI may be added as an attribute to the label element.
EXAMPLE (for a given parameter name)•German: Baud-Rate•
English: Baud rate•
French: Vitesse de transmission

7.2.2.2

Element g_labels

The group g_labels supports the introduction of a label (name) and a description in the context of theparent element (see Fig. 9).

EPSG DS 311 V1.2.1

Fig. 9.

-19-

Group g_labels

Every element, which needs a name or a description, shall select one or more suitable of the four
elements to perform this task: the label, the description, the labelRef and the descriptionRef element.
1)
The label element allows storage of the identifying name and the descriptive text inside the XML
file itself. The label element has the attributes given in Tab. 1. The element may appear n times,
once for each language. For identifying the language, the lang attribute is used.
AttributelangTab. 1
2)

Data typexsd:language

Userequired

Description
Language used for the name

Attributes of element label

The description element allows storage of textual descriptions inside the XML file itself. The
element may appear several times, once for each language.

Attribute
lang
URI
Tab. 2

Data typexsd:language
xsd:anyURI

Userequired
optional

Description
Language used for the description
Optional link to further descriptive information

Attributes of element label

3)

The labelRef element allows storage of a reference to an external text resource file. (see App.
4).
The labelRef element provides a pointer via its attributes dictID and textID to a text entry in a separate
text source file. These text source files are referenced in the dictionary sub-elements of theDeviceFunction element.
The labelRef element also may appear n times, to allow references to several dictionary entries, whichcontain links to files in different languages. The respective language is defined in the lang attribute ofthe dictionary element.
The labelRef element contains the attributes given in Tab. 3.
Attribute
dictID

Data typexsd:stringUserequiredtextID

xsd:string

required

Tab. 3
4)

Description
References a single dictionary element insidethe dictionaryList element; the dictionary
element contains a link to the external text
resource file
References a character sequence (xsd:string)inside the external text resource file by patternmatching

Attributes of element labelRef

The descriptionRef element allows storage of reference descriptive texts inside an external text
resource file. The definitions from the labelRef element shall apply for the descriptionRef
element.

EPSG DS 311 V1.2.1

7.2.2.3-20-

Language identifier

For the multi-language support each label gets an attribute with the content of the language code. The
language code corresponds to the content of the label element.
In order to verify which languages are supported in the XML file, the attribute supportedLanguages in
the ProfileBody element lists the supported languages.

7.2.2.4

Attribute lang

The language identifier lang consists of a combination of a language code (as defined in ISO 639-2)
plus an optional dash character plus an optional country code (as defined in ISO 3166-1). Lang is an
attribute of the label element and the description element.
Some of the values for lang are given in Table 4.
Language
English (United States)
German (Standard)
French (Standard)
Spanish (Standard)
Italian (Standard)
Portuguese (Brazil)
Tab. 47.2.2.5

value of lang
en-us
de
fr
es
it
pt-br

Values of attribute lang

Attribute supportedLanguages

The supportedLanguages attribute of the ProfileBody element identifies supported languages andconsists of a list of language codes plus optional country codes.
EXAMPLEsupportedLanguages=”en-us de fr es”

7.2.2.6

URIs

A general mechanism allows of describing a URI in the context of a label element. The URI is
implemented via an optional attribute URI.
EXAMPLEThis is used in the context of a vendor label, parameter label, or services label.

7.3

ProfileHeader

To facilitate the identification of a profile, the profile header of the device profile as well as thecommunication network profile shall comply with the model shown in Fig. 10, which is directly inheritedfrom ISO 15745-1.

EPSG DS 311 V1.2.1

Fig. 10.

-21-

ProfileHeader element

The ProfileHeader element is composed of the following elements:•
the ProfileIdentification element identifies the current profile,•the ProfileRevision element identifies the current profile revision,•
the ProfileName element contains a descriptive English name of the current profile. In case that
more than one ProfileBody element are present within a device profile, it is suggested that thevalue of the ProfileName element should be the concatenation of the values of the
productName elements inside the respective DeviceIdentity elements,•
the ProfileSource element identifies the validator of the current profile,•the ProfileClassID element identifies the class of the current profile according to ISO 15745-1,•
the ISO15745Reference element states the ISO 15745 part, edition and technology, to which
the description conforms.

7.4

Device profile template description

7.4.1

ProfileBody_Device_Powerlink

For the device profile the ProfileBody contains the DeviceIdentity, the DeviceManager, theDeviceFunction and the ApplicationProcess elements shown in Fig. 2.
The ProfileBody element contains the description•of a single device (e.g. a proximity sensor or an electromechanical limit switch), or of a more
complex one (e.g. a circuit breaker with up to 2500 parameters, more than 100 functions),•
or of a part of a device also called "module" in the PLC world (e.g. part of an I/O controller or ofan electrical protection unit).
The ProfileBody element contains the attributes given in Table 5.

EPSG DS 311 V1.2.1-22-

AttributeformatName
formatVersion
fileName
fileCreator
fileCreationDate

Data typexsd:string
xsd:string
xsd:string
xsd:string
xsd:date

Use
fixed
fixed
required
required
required

Description
Format identifier
Format version identifier
Name of the file with extension without path
Person creating the file
Date of file creation

fileCreationTime

xsd:time

optional

Time of file creation

fileModifiedBy

xsd:string

optional

Person modifying the file

fileModificationDate

xsd:date

optional

Date of last file change

fileModificationTime

xsd:time

optional

Time of last file change

fileVersion

xsd:string

required

Vendor specific version of the file

supportedLanguages

xsd:NMTOKENS

optional

List of supported languages

deviceClass

xsd:NMTOKEN

optional

Classification of the device profile; valid values:
compact (the profile is complete and unique fora product or product family)
configurable (open configurable product thatneeds an external configurator to create theprofile of one instance)

specificationVersion

xsd:string

default

Describes the specification version of the device
profile template. Default: 1.0.4

Tab. 5

7.4.2

Attributes of element ProfileBody

ProfileBody_Device_Powerlink_Modular_Head

For the device profile the ProfileBody contains the DeviceIdentity, the DeviceManager, theDeviceFunction and the ApplicationProcess elements shown in Fig. 2. The DeviceFunction element is
extended with the moduleManagement for supporting the modular head device functionality. If adevice implements a modular head node this profile template shall be used.
The ProfileBody_Device_Powerlink_Modular_Head element contains the attributes given in Tab. 5
and Tab. 6.
Attribute
specificationVersion
Tab. 6

7.4.3

Data typexsd:stringUserequired

Description
Describes the specification version of thedevice profile template. Fixed: 1.0.4

Additional attribute of ProfileBody_Device_Powerlink_Modular_Head

ProfileBody_Device_Powerlink _Modular_ChildFor the device profile the ProfileBody contains the DeviceIdentity, the DeviceManager, theDeviceFunction and the ApplicationProcess elements shown in Fig. 2. The DeviceFunction element is
extended with the moduleManagement for supporting the modular child device functionality. If adevice implements a modular child node this profile template shall be used.
The ProfileBody_Device_Powerlink_Modular_Head element contains the attributes given in Tab. 5
and Tab. 7.
Attribute
specificationVersion
Tab. 7

Data typexsd:stringUserequired

Description
Describes the specification version of thedevice profile template. Fixed: 1.0.4

Additional attribute of ProfileBody_Device_Powerlink_Modular_ChildEPSG DS 311 V1.2.1

-23-

7.4.4

DeviceIdentity

7.4.4.1

GeneralThe DeviceIdentity element (see Fig. 3) contains elements, which are independent of the network andof the process. It describes the identity of a single device or of a group of devices.
Tab. 8 specifies the attribute readOnly, which is attached to the vendorName, vendorID, vendorText,
deviceFamily, productFamily, productName, productID, productText, orderNumber, version,
specificationRevision and instanceName elements.
Attribute
readOnlyTab. 87.4.4.2

Data typexsd:booleanUsedefault

Description
Indicates whether the value is read-only for auser. (default: true)

Attribute of element vendorName

vendorName

The vendorName element identifies the name or the brand name of the vendor of the device.

7.4.4.3

vendorID

The vendorID element identifies the vendor. This information has to be filled in when the productdescribed is recognized and validated by a consortium.
NOTE Consortia specific product families and vendor identifiers are linked.

7.4.4.4

vendorText

The vendorText element allows the vendor to provide additional company information, like address or
hotline number. The g_labels group offers the possibility to include a vendor URI inside thevendorText element.

7.4.4.5

deviceFamily

The deviceFamily element states the family of the device.
EXAMPLE
Examples for device families are:•Variable Speed Drive•
Circuit Breaker•
Pressure Sensor

7.4.4.6

productFamily

The productFamily element states a vendor specific affiliation of the device type to a certain set ofdevices inside a family. The list of valid productFamily values is system, tool or consortia specific.
NOTE Consortia specific device families and vendor identifiers are linked.

7.4.4.7

productName

The productName element states a vendor specific designation or name of the device type.

7.4.4.8

productID

The productID element states a vendor specific unique identification for the device type described.

7.4.4.9

productText

The productText element allows the vendor to provide a short textual description of the device type.

EPSG DS 311 V1.2.1

7.4.4.10-24-

orderNumber

The orderNumber element is used to store the single order number of a given device or the set ofdifferent order numbers of the products of a device family, depending upon whether the device profile
describes a product or a device family.

7.4.4.11

versionThe version element is used to store different types of version information. Multiple version elements
are possible.
The version element has the attributes given in Tab. 9.
Attribute
versionType

Data typexsd:NMTOKEN

Use
required

Description
Type of version:
SW – Software
FW – Firmware
HW – Hardware

readOnly

xsd:boolean

default

Indicates whether the value is read-only for auser. (default: true)

Tab. 9Attributes of element version

7.4.4.12

buildDate

The buildDate element specifies the build date of the software unit.

7.4.4.13

specificationRevision

The specificationRevision element contains the revision of the specification, to which this device
conforms.

7.4.4.14

instanceName

This element contains the instance name of the device. The default value of the attribute readOnly is
set to false.

7.4.5

DeviceManager

7.4.5.1

GeneralThe DeviceManager element defines the list of indicators provided by the device type, if any.

7.4.5.2

indicatorList / LEDList

7.4.5.2.1

GeneralFig. 11 specifies the number and type of indicators, which are provided by a device type.

Fig. 11.

indicatorList / LEDListEPSG DS 311 V1.2.1

-25-

LED

7.4.5.2.2

The LED element describes the features of a single LED of the device type. A detailed featuredescription may be provided through the g_labels group.
Further properties of the LED are represented as attributes of the LED element given in Tab. 10.
Attribute
LEDcolors

Data typexsd:stringUserequired

LEDtype

xsd:string

optional

Tab. 10Attributes of element LED

Description
Colours of the LED; valid values are monocolorand bicolor
Rough classification of the supervised item orfunctionality; valid values are IO, device andcommunication

In addition to the descriptive parts introduced above, the LED element contains one to many LEDstateelements, which define the device states signalled by the LED and the visual behaviour used forsignalling the states.
The visual behaviour used for signalling the state is encoded as attribute values of the LEDstateelement, as given in Tab. 11. Additionally a unique ID is allocated for the LED state.
AttributeuniqueID

Data typexsd:ID

Use
requiredstate

xsd:string

required

LEDcolor

xsd:string

required

flashingPeriod

xsd:unsignedInt

optional

impulsWidth

xsd:unsignedByte

default

numberOfImpulses

xsd:unsignedByte

default

Tab. 11

7.4.5.2.3

Description
Unique ID for the LED state; may be referenced
from an LEDstateRef element
State of the LED; possible attribute values:on, off, flashing
Colours of the LED; valid values: green, red,amber
If state is flashing: flashing period of the LED in
milliseconds
Width of the flashing impulse given in percent(%) of the flashing period; if the attribute
impulsWidth is missing; the default value is 50(%)
Number of impulses in case that more than one
flashing impulse is inside one flashing period; if
the attribute is present, the attribute
impulsWidth shall be present also; if theattribute numberOfImpulses is missing, thedefault value is 1.

Attributes of element LEDstate

combinedStateThe combinedState element allows the indication of device states which are signalled by more than
one LED.
The description of the combined state is provided through the g_labels group.
The LED states participating in the signalling of the combined state are referenced by means of atleast two LEDstateRef sub-elements of the combinedState element.
The reference to a LEDstate element is encoded as the attribute value of the single attribute of the
LEDstateRef element (see Tab. 12).
AttributestateIDRef
Tab. 12

Data typexsd:IDREF

Userequired

Attribute of element LEDstateRef

Description
Unique ID of the referenced LEDstate element

EPSG DS 311 V1.2.1-26-

moduleManagement (modular device only)

7.4.5.3

This element is only supported in the abstract profile types which include the modular device support
ProfileBody_Device_Powerlink_Modular_Head and ProfileBody_Device_Powerlink_Modular_Child.

General7.4.5.3.1

The moduleManagement element, if present, contains either a moduleInterfaceList element and an
optional moduleInterface element or a single moduleInterface element as shown in Fig. 12 and Fig.
13.

Fig. 12.

moduleManagement element of a modular head device

Fig. 13.

moduleManagement element of a modular child device

The interfaceList element (see 7.4.5.3.2) shall be present if the device implements the root of amodular device. If the modular head device implements a module also the moduleInterface may bepresent.
The single moduleInterface element (see 7.4.5.3.3) shall be present if the device implements a single
module and may be present if the device is a head node and a module simultaneously.

7.4.5.3.2

interfaceList

7.4.5.3.2.1

GeneralThe interfaceList element, if present, contains a sequence of one to many interface elements.

7.4.5.3.2.2

interface

7.4.5.3.2.2.1

GeneralThe mandatory interface element (see Fig. 14) is used to indicate the properties of one interface
provided by a modular device. These properties include a file path (see 7.4.5.3.2.2.2) to the XML
device description files defining the modules to be connected to the modular device and may be theactual connected modules (see 7.4.5.3.2.2.4).

EPSG DS 311 V1.2.1-27-

The interface element may contain the element group g_labels with one or more sub elements andcontains the attributes defined in Tab. 13.

Fig. 14.

interface element (modular head node)

AttributeuniqueID

Data typexsd:ID

Use
required

Description
Unique ID of the interface.

type

xsd:NCName

required

Module type supported by the interface.

maxModules

xsd:positiveInteger

requiredunusedSlots
multipleModules

xsd:boolean
xsd:boolean

requireddefault

moduleAddressing

xsd:NMTOKEN

required

identList

xsd:hexBinary

optional

firmwareList

xsd:hexBinary

optional

Maximum number of modules to beconnected to the interface.
Defines whether empty slots are allowed.
Defines if multiple modules of the same typeare allowed. Default: true
Defines the addressing scheme for the node:• manual – The user shall provide anaddress for the module manually.
• position – Modules shall receive anaddress which is equal with theposition on the bus.
Index of the object (four hex digits) where
identification data of child devices is stored.
See App. 5 for details.
Index of the object (four hex digits) where
firmware data of child devices is stored. See
App. 6 for details.

Tab. 13

Attributes of element interface

7.4.5.3.2.2.2

fileList / File

The mandatory fileList element contains a sequence of one to many file elements.
The mandatory file element contains a file path referenced by the URI attribute (see Tab. 14) to search
for additional XML device description files containing definitions of the modules.
Attribute
URI

Data typexsd:anyURI

Userequired

Description
File path to XML device description file. (seeNOTE)

NOTE The file path may contain wildcard characters. The wildcard character “?” would be recognized
as a single character. The wildcard character “*” would be recognized as one to many characters.
Tab. 14

Attributes of element fileEPSG DS 311 V1.2.1

7.4.5.3.2.2.3-28-

moduleTypeList / moduleType

The moduleTypeList element contains a sequence of one to many moduleType elements. It is
mandatory for a moduleInterface element and optional for an interface element.
A Type element contains a reference to the module type of a module allowed to be connected to themodular device and a unique id to be referenced from a connector element. The according module
type is defined in the additional XML device description files referenced by the fileList element (see7.4.5.3.2.2.2). The module type is defined by the type attribute (see Tab. 15).
AttributeuniqueID

Data typexsd:ID

Use
required

Description
Unique id of the module type to bereferenced by a connector attributeinterfaceIDRef.

type

xsd:NCName

required

Reference to an allowed module type.

Tab. 15

Attributes of element moduleType

7.4.5.3.2.2.4

connectedModuleList / connectedModule

The optional connectedModuleList element contains a sequence of one to many connectedModule
elements. The connectedModuleList element is used for configured modular devices.
The mandatory connectedModule element contains the childIDRef attribute that is a reference to aconnected module. The attributes of the connectedModule element are defined in Tab. 16.
AttributechildIDRef

Data typexsd:stringUserequired

Description
Reference to the child id of a connected
module.

position

xsd:positiveInteger

requiredDefines the position of the module on theinterface.

address

xsd:positiveInteger

optional

Defines the address of the module on theinterface. Default: position

Tab. 16

Attributes of element connectedModule

7.4.5.3.3

moduleInterface

The moduleInterface element is used to indicate the properties of one module interface provided by amodular child device. These properties may include a file path (see 7.4.5.3.2.2.2) to the XML device
description files defining the modules to be connected to the modular device and the module types(see 7.4.5.3.2.2.3) of the modules to be connected to the modular device,

Fig. 15.

moduleInterface element (modular child device)

The single moduleInterface element shall contain the attributes given in Tab. 17.

EPSG DS 311 V1.2.1-29-

AttributechildID

Data typexsd:stringUserequired

type
moduleAddressing

xsd:NCName
xsd:NMTOKEN

required
required

Description
Unique ID of the module. (see NOTE)Type of the module.
Defines if the module addressing on thebus:• manual – Module address shallbe assigned manually by theuser. Requires modular headinterface attributemoduleAddressing to be manual.
• position – Module address shallbe assigned according to theposition of the module. Modular
head interface attributemoduleAddressing may only be
manual or position.
• next – Module address shall beassigned to the next address
after its preceding module
address. Requires modular headinterface attributemoduleAddressing to be manual.
minPosition
xsd:positiveInteger
default
Minimum allowed position of the moduleon the interface bus. Default: 1.
maxPosition
xsd:positiveInteger
optional
Maximum allowed position of the moduleon the interface bus. Defaults to themaxModules attribute in the headinterface.
minAddress
xsd:positiveInteger
default
Minimum allowed address of the moduleon the interface bus. Default: 1.
maxAddress
xsd:positiveInteger
optional
Maximum allowed address of the moduleon the interface bus. Defaults to themaxModules attribute in the headinterface.
maxCount
xsd:nonNegativeInteger optional
Maximum number of multiples of thismodule to be connected to the modular
device. The value 0 shall indicate nolimitation.
NOTE To guarantee uniqueness this ID consists of the 8 hexadecimal characters of the vendor-ID anda manufacturer specific part.
Tab. 17

Attributes of element moduleInterface

7.4.6

DeviceFunction

7.4.6.1

GeneralThe DeviceFunction element defines the catalogue view of the device, presented as a set ofcapabilities listing both device characteristics and compliance with various standards.
The sub-elements of the DeviceFunction element shown in Fig. 5 are detailed in the following
subclauses.

EPSG DS 311 V1.2.1

7.4.6.2

capabilities

7.4.6.2.1

General-30-

The optional capabilities element describes all functionalities, their characteristics, and the importantparameters of the device, that need to be known by tools which use the device profile to selectproducts with the same or similar properties.
The capabilities element describes device features in a purely textual form. It contains a sequence of
one to many characteristicsList elements and an optional standardComplianceList element.

7.4.6.2.2

characteristicsList

7.4.6.2.2.1

GeneralThe characteristicsList element is a collection of characteristics. The element shall contain at least one
characteristic sub-element. The characteristics inside a list may be associated with a category, which
can be expressed as textual content of the g_labels sub-element of the optional category sub-elementof the characteristicsList element.

7.4.6.2.2.2

characteristic

The characteristic element describes a single characteristic of a device. It contains a mandatory
characteristicName element and one to many characteristicContent elements.

7.4.6.2.2.3

characteristicName

The mandatory characteristicName element denotes a major technical characteristic of the device.
The vocabulary used in the device data sheet is recommended for the names of characteristics.
EXAMPLES"Maximum operational voltage", "Overload protection", "Electrical durability".

7.4.6.2.2.4

characteristicContent

This mandatory element contains a value for the characteristic. Multiple values may be expressed byusing multiple characteristicContent elements.
EXAMPLEAn example of a single value for "Maximum operational voltage" is 680V.

7.4.6.2.2.5

standardComplianceList

The standardComplianceList element is a collection of compliantWith elements. The element itself is
optional; if it exists, it shall contain at least one compliantWith sub-element.
The compliantWith sub-element has attributes, which state the compliance of the device with aninternational or company internal standard. The content of type g_labels of this element may containremarks concerning that standard.
The name or number of the standard is provided through the required name attribute of thecompliantWith element. The second, default valued range attribute of the compliantWith element
defines the range of applicability of the standard as given in Tab. 18.
Attribute
name
range
Tab. 18

7.4.6.3

Data typexsd:string
xsd:NMTOKEN

Use
requireddefault

Description
Name or number of the standard
The two possible enumerated values of theattribute are international (default) or internal

Attributes of element compliantWith

picturesList

The picturesList element offers the possibility to link pictures to the device profile. It contains one tomany picture sub-elements, whose caption is provided via a g_labels sub-element.
Tab. 19 defines attributes of the picture sub-element: an optional number of the picture, and the
mandatory link to an external resource containing the graphical information.

EPSG DS 311 V1.2.1-31-

Attribute
URI
type

Data typexsd:anyURI
xsd:NMTOKEN

Use
requireddefault

numberxsd:unsignedInt

optional

Tab. 19

7.4.6.4

Description
Link to the external resource
Defines the type of the given picture.
• frontPicture – Is used to display thedevice in a configuration tool. Only one
front picture shall be defined.
• icon – Defines an icon for the device ina configuration tool. Only one icon shallbe defined.
• additional – Additional pictures linked
to the device.
• none – default.
Number of the picture

Attributes of element picture

dictionaryList

The optional dictionaryList element offers the possibility to include links to external text resource files
to the device profile. It contains one to many dictionary elements, where each one contains one filesub-element.
A mandatory lang attribute of type xsd:language defines the language used in the file which is linked
to the dictionary element (see Tab. 20). A mandatory dictID attribute of type xsd:string holds theunique identification of the dictionary which is referenced from the attribute dictID of a labelRef
element as given in Tab. 3.
Attributelang

Data typexsd:language

Userequired

dictID

xsd:string

required

Tab. 20

Description
Language used for the file belonging to adictionary
Identification of the dictionary

Attributes of element dictionary

A file sub-element contains a single mandatory attribute given in Following Table.
Attribute
URI
Tab. 217.4.6.5

Data typexsd:anyURI

Userequired

Description
Link to the respective file

Attribute of element fileconnectorList

The optional connectorList element offers the possibility to describe the devices connectors. It
contains one to many connector elements. The content of type g_labels of this element may containremarks concerning the connector.

EPSG DS 311 V1.2.1-32-

Attribute
id
posX

Data typexsd:string
xsd:nonNegativeInteger

Use
required
optional

posY

xsd:nonNegativeInteger

optional

connectorTypexsd:string

default

interfaceIDRef

xsd:string

optional

positioning

xsd:NMTOKEN

default

Tab. 22

Attributes of element connector

Description
Defines the id for the connector
Defines the X-axis number of pixel for theconnector placement relative to the given
device picture counted from the left upper
corner.
Defines the Y-axis number of pixel for theconnector placement relative to the given
device picture counted from the left upper
corner.
Defines the fieldbus supported by theconnector. Default is “POWERLINK”. Either
connectorType or interfaceRef have to bepresent. The attribute is required formodular devices.
The connector may reference an interface
or a module type given in the module
management. This can be used to define
the fieldbus supported by the connector.
This attribute is required for modular childdevices.
The positioning defines the docking point
for devices or submodules. If positioning isremote the connector position is ignore.
• remote – default. Devices areconnected with a cable connection.
• localAbove – Devices areconnected directly above thedevice.
• localBelow – Devices areconnected directly below thedevice.
• localLeft – Devices are connected
directly on the left side of thedevice.
• localRight – Devices areconnected directly on the right sideof the device.

EPSG DS 311 V1.2.1

Fig. 16.

-33-

connectorList

firmwareList

7.4.6.6

The optional firmwareList element offers the possibility to describe firmware files for the device
revisions. It contains one to many firmware elements. The content of type g_labels of this element
may contain remarks concerning the firmware.
Attribute
URI
deviceRevisionNumber

Data typexsd:anyURI
xsd:nonNegativeInteger

Use
required
requiredbuildDatexsd:dateTime

optional

Tab. 23

Attributes of element firmware

Fig. 17.

firmwareList

Description
Link to the external firmware file.
Defines the device revision for which
the firmware is designed.
Creation date of the firmware.

classificationList

7.4.6.7

The optional classificationList element offers the possibility to classify the devices capabilities. It
contains one to many classification elements.
Data typexsd:NMTOKEN

Tab. 24

Use
required

Element classification

Description
Classification definition• Controller• Industrial PC• Operator Interface• IO• Drive• Motor• Encoder• Vision System• Sensor• Temperature• Counter• Safe• Analog• Digital• Input• OutputEPSG DS 311 V1.2.1

-34-

7.4.7

ApplicationProcess

7.4.7.1

GeneralThe ApplicationProcess element represents the set of services and parameters, which constitute thebehaviour, and the interfaces of the device in terms of the application, independent of the device
technology and the underlying communication networks and communication protocols.
The sub-elements of the ApplicationProcess element in Fig. 6 provide a generic approach for thedescription of arbitrary, flat or hierarchically structured functions of a device.
Functions are modelled as function types, which are instantiated within the device or - if hierarchicalstructures are needed - inside function types. The interface variables of these function instances,which may be of simple or complex data type, are associated with the parameters of the device bybuilding a reference from the parameter to the respective interface variable of the function instance, inflat as well as in hierarchical structures.
The ApplicationProcess element contains up to six lists of items (see Fig. 6):•
two optional lists which define data types and function types;•
one optional list which defines the function instances on device level (possibly including
connections between instances);•
one optional list which defines templates for sub-elements of device parameters or for subelements of allowed device parameter values;•
one required list which defines the device parameters and•one optional list which defines parameter groups (combinations of parameters for specificpurposes).
The elements inside these lists are described in the following sub clauses.

7.4.7.2

dataTypeList

7.4.7.2.1

GeneralThe optional dataTypeList element is present if complex data types like arrays or data structures areneeded inside variable declarations or parameter specifications of the device profile.
If present, the dataTypeList element shown in Fig. 18 contains a sequence of one to many elements
out of the choice of:•an array element,•a struct element,•
an enum element or•a derived element.

EPSG DS 311 V1.2.1

Fig. 18.

-35-

dataTypeList

7.4.7.2.2

Common elements

7.4.7.2.2.1

Group g_simple

The group g_simple contains a choice of elements, whose names represent the names of all simple
data types allowed in the definition of variables or parameters inside a device profile. The simple datatypes conform to the elementary data types defined in IEC 61131-3; the data types BITSTRING and
CHAR (=STRING[1]) are added.
These elements are introduced inside a group to allow their placement directly as a sub-element of thearray element (or of the varDeclaration element, or other elements).

7.4.7.2.3

array

7.4.7.2.3.1

GeneralThe array element serves to describe an array data type, which may be referenced from an interface
variable of a function type, from another array type definition, from a component variable inside thedefinition of a structured data type, or from a parameter specification.
The array element may contain the element group g_labels with one or more subelements. The arrayelement contains at least one subrange element and either an element describing a simple data typeout of the group g_simple, or an element dataTypeIDRef, which references one of the definedcomplex data types within the dataTypeList element.

EPSG DS 311 V1.2.1-36-

For multi-dimensional arrays, several subrange elements will be present. In this case, the first
subrange element in the sequence defines the subrange for the leftmost array index, and the last
subrange element in the sequence defines the subrange for the rightmost array index.
The array element contains the attributes given in Tab. 25.
Attribute
nameuniqueID

Data typexsd:string
xsd:ID

Tab. 25

Attributes of element array

7.4.7.2.3.2

Use
required
required

Description
Data type name of the array type
Unique ID of the array typesubrange

The subrange element defines the lower and the upper limit of an array index for one dimension of thearray. This element has no sub-elements. The limit values of type xsd:long are contained in the two
attributes of the subrange element given in Tab. 26.
Attribute
lowerLimit
upperLimit

Data typexsd:positiveInteger
xsd:positiveInteger

Tab. 26

Attributes of element subRange

7.4.7.2.4

struct7.4.7.2.4.1

GeneralUse
required
required

Description
Lower limit of the subrange
Upper limit of the subrange

The struct element serves to describe a structured data type, which may be referenced from aninterface variable of a function type, from an array type definition, from a component variable insidethe definition of another structured data type, or from a parameter specification.
The struct element may contain the element group g_labels with one or more subelements. The struct
element contains a sequence of one to many varDeclaration elements, which define the componentsof the structured data type.
The struct element shall contain the attributes given in Tab. 27.
Attribute
nameuniqueID

Data typexsd:string
xsd:ID

Tab. 27

Attributes of element struct7.4.7.2.4.2

Use
required
required

Description
Data type name of the structured data type
Unique ID of the structured data type

varDeclaration

In the context of the definition of a structured data type, the varDeclaration element describes a single
component variable (member) of the structure.
In the context of the definition of the interface of a function, the varDeclaration element describes asingle interface variable of the function type.
The varDeclaration element may contain the element group g_labels with one or more subelements.
The data type of the component variable or interface variable is either defined by an element
describing a simple data type out of the group g_simple, or by an element dataTypeIDRef, whichreferences one of the defined complex data types within the dataTypeList element.
All further properties of the variable are contained in the attributes of the varDeclaration element, asgiven in Tab. 28.

EPSG DS 311 V1.2.1

Attributename

Description
Name of the interface variable or structurecomponent
uniqueID
xsd:IDrequired
Unique ID of the interface variable or structurecomponent (see NOTE 1)
size
xsd:positiveInteger default
Number of elements, if the interface variable or
structure component is of type anonymous
ARRAY, BITSTRING, STRING or WSTRING(see NOTE 2) Default: 1.
initialValue
xsd:string
optional
Initial value of the interface variable or structurecomponent (see NOTE 3)
NOTE 1 When creating the unique ID for a variable, it is essential that the ID is unique over all
created IDs inside the XML source file. To allow equal names for component variables of different data
structures and equal names for interface variables of function types, the ID of a variable should
generally concatenate the type name of the structured data type or the function type with the variable
name, to guarantee uniqueness.
NOTE 2 Anonymous types define the size of an array, bitstring or string directly in the variabledeclaration, and not through the reference to a named complex data type. In the case of an array, thedata type of the variable gives the type of a single array element. In the case of a bitstring, the single
array element is a single bit. In the case of a string, the single array element is a single-byte resp.
double-byte character.
NOTE 3 If present, this attribute defines the initial (default) value of the interface variable of thefunction type. It is overwritten by a given default value of a parameter associated with the interface
variable of the function instance.
Tab. 28

Data typexsd:string

-37-

Use
required

Attributes of element varDeclaration

7.4.7.2.5

enum

7.4.7.2.5.1

GeneralThe enum element serves to describe an enumerated data type, which may be referenced from aninterface variable of a function type, from an array type definition, from a component variable insidethe definition of a structured data type, or from a parameter specification.
According to Fig. 18, it contains a sequence. The sequence may contain the element group g_labelswith one or more subelements, and one to many enumValue elements, which define the enumeration
constants of the enumerated data type. The data type of the enumeration constants is optionallydefined by an element describing a simple data type out of the group g_simple.
The enum element contains the attributes given in Tab. 29.
Attribute
nameuniqueID
size
Tab. 29

Data typexsd:string
xsd:ID
xsd:positiveInteger

Use
required
requireddefault

Description
Type name of the enumerated data type
Unique ID of the enumerated data type
Optional number of enumerated values of theenumerated data type. Default: 1.

Attributes of element enum

7.4.7.2.5.2

enumValue

The enumValue element defines the name(s) and optionally a numerical value of a single enumeration
constant. The name(s) are specified through the g_labels group, whereas the value is contained in the
single value attribute of the enumValue element, as given in Tab. 30.
Attribute
valueTab. 30

Data typexsd:stringUse
optional

Attribute of element enumValue

Description
Optional attribute: fixed numerical value for theenumeration constant, represented as a stringof characters

EPSG DS 311 V1.2.1

7.4.7.2.6

derived7.4.7.2.6.1

General-38-

The derived element serves to derive a new data type from a given base type.
The derived element may contain the element group g_labels with one or more subelements and an
optional count element and either an element describing a simple data type out of the group g_simple,
or an element dataTypeIDRef, which references one of the defined complex data types within the
dataTypeList element.
If the count element is missing, the derived type definition just introduces a new type name for therespective base type. If the count element is present, it defines the number of units of the respective
base type used to build the derived type (e.g. base type BITSTRING, count = 4 defines a derived typeof size 4 bit).
The derived element contains the attributes given in Tab. 31.
Attribute
nameuniqueID
description
Tab. 31

Data typexsd:string
xsd:ID
xsd:stringUserequired
required
optional

Description
Data type name of the derived type
Unique ID of the derived type
Description of the derived type

Attributes of element derived

7.4.7.2.6.2

count

The count element defines the number of used units of the base type of the derived type. Multilingualnames and/or descriptions for the count element are provided through the group g_labels.
The count is described by:•
its attributes,•
the mandatory sub-element defaultValue and a possibly empty set of sub-elements g_labels
and allowedValues.
The number of units is expressed as the value of the defaultValue attribute of the count element. The
allowedValue attribute defines the range of values for the default value.
The count element shall contain the attributes given in Tab. 32.
AttributeuniqueID
accessTab. 32

7.4.7.3

Data typexsd:ID
xsd:NMTOKEN

Use
requireddefault

Description
Unique ID of the countDefines which operations are valid for the count:- const - read access only; value is not changing- read - read access only (default value)- write - write access only
- readWrite - both read and write access- noAccess - access denied

Attributes of element countfunctionTypeList

If the optional ApplicationProcess element is present in the device profile, it may contain an optional
functionTypeList element shown in Fig. 19.

EPSG DS 311 V1.2.1

Fig. 19.

-39-

functionTypeList

The functionTypeList represents a sequence of one to many functionType elements.
Each of the functionType elements represents the type description of a device function, which isreferenced from at least one instance of that function type inside a functionInstanceList element.
References from more than one instance of the same function type are also possible.
The description of a function type contains all those objects and data which are common for all
instances of a given function type.
EXAMPLE 1
Examples are the variable - or function parameter - objects that constitute the interface of the function(type respectively instance).
EXAMPLE 2
Other examples are instances contained within the body of a function in a hierarchically structured
functional description. These instances, which are located within a functionInstanceList element inside
the function type, reference other function types in the list of function types.

7.4.7.4

functionType

7.4.7.4.1

GeneralThe functionType element may contain the element group g_labels with one or more subelements andcontains one to many versionInfo elements, a mandatory interfaceList element and an optional
functionInstanceList element. The functionInstanceList element is only present within a functionTypeelement, if the function is hierarchically structured.
The versionInfo element and the interfaceList element are described in the following subclauses.
Additionally, the functionType element shall contain the attributes given in Tab. 33.
Attribute
nameuniqueIDpackageTab. 33

Data typexsd:string
xsd:ID
xsd:stringUserequired
required
optional

Attributes of element functionType

Description
Type name of the function type
Unique ID of the function type
Optional textual association of the function typewith a "package" or similar classification
scheme - the usage of this attribute is left to the
profile validator

EPSG DS 311 V1.2.1-40-

versionInfo

7.4.7.4.2

The mandatory versionInfo element within the functionType element provides information on theversioning history of a function type (concerning the definition of the interface).
To keep track of the versioning history, the versionInfo element may be entered multiple times. The
multiple entries shall be arranged within the functionType element in the following sequence:a)the first entry represents the most recent version,b)
the second entry represents the immediately preceding version,c)
the last entry represents the first released version.
This element will be provided once at the creation of the description of the function type. New
elements will only be added, if modifications of a function type are introduced, which lead to a modified
version of the device profile.
The versionInfo element may contain one element group g_labels with one or more subelements.
The versionInfo element shall contain the attributes given in Tab. 34.
Attributeorganization

Data typexsd:stringUserequired

versionxsd:string

requiredauthorxsd:string

requireddate

xsd:daterequired

Tab. 34

Description
Name of the organisation maintaining thefunction type
Version identification in the versioning history;suggested format: "xx.yy" (xx,yy = 0..255)
Name of the person maintaining the function
type
Date of this version

Attributes of element versionInfo

7.4.7.4.3

interfaceList

7.4.7.4.3.1

GeneralThe mandatory interfaceList element within the functionType element provides the definition of theinterface of the function type. Elements of the interface are:•the input variables, and/or•
the output variables, and/or•
the configuration variablesof the function type.
Consequently the interfaceList element contains a sequence of three elements, where each element
represents lists of one to many variable declarations encoded as varDeclaration elements:•
one optional element inputVars,•
one optional element outputVars, and•one optional element configVars.
Neither the interfaceList nor the inputVars, outputVars or configVars elements have any attributes.

7.4.7.4.3.2

varDeclaration

In the context of the definition of a structured data type, the varDeclaration element describes a single
component variable (member) of the structure.
In the context of the definition of the interface of a function type, the varDeclaration element describes
a single interface variable of the function type.
The data type of the component variable or interface variable is either defined by an element
describing a simple data type out of the group g_simple, or by an element dataTypeIDRef, whichreferences one of the defined complex data types within the dataTypeList element.
7.4.7.2.2.1 describes the group g_simple and 7.4.7.4.3.3 describes the dataTypeIDRef element.
All further properties of the variable are contained in the attributes of the varDeclaration element, asgiven in Tab. 35.

EPSG DS 311 V1.2.1-41-

Attribute
nameData typexsd:stringUserequireduniqueID

xsd:IDrequiredsize

xsd:string

optional

initialValue

xsd:string

optional

Tab. 35

Description
Name of the interface variable or structurecomponent
Unique ID of the interface variable or structurecomponent
Number of elements, if the interface variable or
structure component is of type anonymous
ARRAY, BITSTRING, STRING or WSTRING
Initial value of the interface variable or structurecomponent

Attributes of element varDeclaration

7.4.7.4.3.3

dataTypeIDRef

The dataTypeIDRef element serves to reference a complex data type inside the dataTypeList element(see 7.4.7.2), either from an interface variable of a function type, or from an array type definition, orfrom a component variable inside the definition of a structured data type.
The reference of type xsd:IDREF is provided as an attribute of the dataTypeIDRef element, as given in
Tab. 36.
AttributeuniqueIDRef
Tab. 36

Data typexsd:IDREF

Userequired

Description
Unique ID of the referenced data type

Attribute of element dataTypeIDRef

7.4.7.5

functionInstanceList

7.4.7.5.1

GeneralThe optional functionInstanceList element, if present, contains a sequence of one to many
functionInstance elements and zero to many connection elements.
At the application process level, the functionInstance elements represent the accessible application
functions of the device type, independent of the network type or protocol. The connection elements
represent connections - if any - between specific output and input variables of those function
instances.
The functionInstanceList element also appears as an optional sub-element of the functionTypeelement. Like at the application process level, the functionInstanceList element in that case contains asequence of one to many functionInstance elements and zero to many connection elements.
The functionInstanceList element is only present within a functionType element, if a function ishierarchically structured. In this case the functionInstance elements represent the internal functions
contained in the function type, and the connection elements the optional internal connections. These
functions and their optional connections would be instantiated together with the instantiation of thecontaining function type.
The functionInstanceList element does not have any attributes.

7.4.7.5.2

functionInstance

The mandatory functionInstance element may contain the element group g_labels with one or moresubelements.
The functionInstance element shall contain the attributes given in Tab. 37.

EPSG DS 311 V1.2.1-42-

Attribute
Data type
Use
Description
name
xsd:string
requiredName of the function instanceuniqueID
xsd:IDrequired
Unique ID of the function instance (see NOTE)
typeIDRef
xsd:IDREF
required
Unique ID of the referenced function type
NOTE When creating the unique ID for a function instance, it is essential that the ID is unique over all
created IDs inside the XML source file. To allow equal names for function instances inside different
function types, the ID of a function instance should generally concatenate the name of the containing
function type with the instance name, to guarantee uniqueness.
Tab. 37

7.4.7.5.3

Attributes of element functionInstanceconnection

The optional connection element defines a connection between an output variable of a function
instance and an input variable of another function instance. Inside function types, the connection may
also be drawn between an input variable of the function type and an input variable of a contained
function instance, or between an output variable of a contained function instance and an output
variable of the function type. The connection element may appear zero to many times.
The connection element contains the attributes given in Tab. 38.
Attributesourcedestination
description
Tab. 38

Data typexsd:string
xsd:string
xsd:stringUserequired
required
optional

Description
Starting point of connection
Endpoint of connection
Optional textual description of the connection

Attributes of element connection

EXAMPLEThe values of the source and the destination attributes may be used to encode the starting point andthe endpoint of a connection using the syntax <function_instance_name>'.'<variable_name>; example
for the value of a source attribute: 'PowerMeasures.Frequency'. Connections to interface variables ofa function type use the names of the interface variables only.

7.4.7.6

templateList

The various sub-elements of the optional templateList element are referenced from within parameter
elements or allowedValues elements, which use sets of sub-elements with the same attribute values
in their descriptions. Intense usage of the template constructs may largely reduce the size of device
profile XML files.
The templateList element, if present, contains a sequence of zero to many parameterTemplateelements and/or zero to many allowedValuesTemplate elements, as shown in Fig. 20.

EPSG DS 311 V1.2.1

Fig. 20.

-43-

templateList

The sub-elements of the parameterTemplate element are a subset of the sub-elements of theparameter element, as specified in 7.4.7.7.2, such that the descriptions of these sub-elements in the
subclauses of 7.4.7.7.2 hold.
The parameterTemplate element shall contain the same attributes as the parameter element, as given
in Tab. 40.
The sub-elements of the allowedValuesTemplate element are the same as the sub-elements of theallowedValues element, as specified in 7.4.7.7.2.7, such that the descriptions of these sub-elements inthe subclauses of 7.4.7.7.2.7 also hold.
The single attribute of the allowedValuesTemplate element is given in Tab. 39.
AttributeuniqueID
Tab. 39

Data typexsd:ID

Use
required

Description
Unique ID of the template. Shall only bereferenced by a Parameter element.

Attribute of element allowedValuesTemplate

If a parameter element or an allowedValues element referencing a template contains the same subelement as the referenced template element, the value of the sub-element of the parameter element
or of the allowedValues element overrides the value provided by the template.

7.4.7.7

parameterList

7.4.7.7.1

GeneralIf the optional ApplicationProcess element is present in the device profile, it contains a mandatory
parameterList element shown in Fig. 21, which represents a sequence of one to many parameter
elements.

EPSG DS 311 V1.2.1

Fig. 21.

-44-

parameterList

Each of the parameter elements represents a parameter of the device profile. Multilingual names
and/or descriptions for the parameters are provided through the group g_labels.
The parameter is described by:•its name(s) and description(s) (element g_labels),•
its attributes,•
a choice of three possible references:•a reference to a simple data type (element g_simple - see NOTE 1),•
a reference to a complex data type (element dataTypeIDRef - see NOTE 1),•
or a reference to one (or more) interface variable(s) of one (or more) function instance(s)(element variableRef - see NOTE 1 and NOTE 2),•
and a possibly empty set of sub-elements (conditionalSupport, denotation, actualValue,defaultValue, substituteValue, allowedValues, unit and property).
NOTE 1 All parameter elements of a given device profile shall either use references to data types
only, or references to interface variables only.
NOTE 2 References to multiple variables are a special case: specific parameters may reference an
output variable of one function instance and an input variable of another function instance at the sametime. In this case the data types of the two variables shall be the same. The XML parser cannot checkthe equality of data types, this can only be checked by a supporting tool.

7.4.7.7.2

parameter

7.4.7.7.2.1

GeneralThe parameter element shall contain the attributes given in Tab. 40.
NOTE The same attributes are also valid for the parameterTemplate element, as specified in 7.4.7.6.

EPSG DS 311 V1.2.1

AttributeuniqueID
accessData typexsd:ID
xsd:NMTOKEN

-45-

Use
required
optional

Description
Unique ID of the parameter
Defines which tool operations are valid for theparameter:•accessList

xsd:NMTOKENS

optional

supportxsd:NMTOKEN

optional

const - read access only; the value is
not changing• read - read access only write - write
access only
• readWrite - both read and write access• readWriteInput – both read and write
access, but represents process inputdata• readWriteOutput – both read and write
access, but represents process output
data• noAccess - access denied
Defines a list of additionally allowed operations
on the parameter: the valid values are the same
as for the attribute access, but the parser will
not check the usage of the correct values.
Defines whether or not the parameter has to be
implemented in the device; valid values:•

mandatory - parameter implementationis required•

optional - parameter implementation ispossible but not required•

persistent

xsd:boolean

default

offsetxsd:string

optional

multiplierxsd:string

optional

templateIDRef

xsd:IDREF

optional

Tab. 40

conditional - parameter implementationis required if one or more other optionalparameter(s) is (are) implemented;
these parameters are specified using
the sub-element conditionalSupport
Defines the behaviour after power failure; valid
values are false (default) and true
Offset which is added to an actual value to forma scaled value: EngineeringValue =(ParameterValue + offset) * multiplier; if notpresent, offset = 0 is assumed
Scaling factor by which an actual value ismultiplied to form a scaled value:
EngineeringValue = (ParameterValue + offset) *multiplier; if not present, multiplier = 1 isassumedUnique reference to a parameterTemplateelement

Attributes of element parameter

7.4.7.7.2.2

conditionalSupport

One or more conditionalSupport elements are present only if the value of the support attribute of theparameter element is conditional. Each element refers to a single optional parameter. If at least one ofthose optional parameters is implemented, the conditional parameter has also to be implemented.
The element conditionalSupport shall contain the single attribute given in Tab. 41.

EPSG DS 311 V1.2.1

AttributeparamIDRef
Tab. 41

Data typexsd:IDREF

-46-

Use
required

Description
Unique ID of the referenced optional parameter

Attribute of element conditionalSupport

7.4.7.7.2.3

denotation

The denotation element serves to hold application-specific, multilingual names of the parameter. The
names are provided through the mandatory g_labels sub-element. It is also possible to add
multilingual descriptive information. The element denotation does not have any attributes.

7.4.7.7.2.4

actualValue

The actualValue element serves to hold the actual value of the parameter. An optional g_labels subelement may provide multilingual descriptive information for this value. The value itself is provided in
the value attribute of the element actualValue. An offset and multiplier may also be provided.
The attributes of the element actualValue shall be as given in Tab. 42.
Attribute
value
offsetData typexsd:string
xsd:stringUserequired
optional

multiplierxsd:string

optional

Tab. 42

Description
Actual value
Offset which is added to an actual value to forma scaled value: EngineeringValue = (value +offset) * multiplier; if not present, the respective
value of the parameter element shall be used
Scaling factor by which an actual value ismultiplied to form a scaled value:
EngineeringValue = (value + offset) * multiplier;
if not present, the respective value of theparameter element shall be used

Attributes of element actualValue

7.4.7.7.2.5

defaultValue

The defaultValue element serves to hold the default value of the parameter. This value overwrites thedefault value, if any, of the interface variable of the function type associated with the parameter.
An optional g_labels sub-element may provide multilingual names and/or descriptive information forthis value. The value itself is provided by the value attribute of the element defaultValue. An offset andmultiplier may also be provided.
The attributes of the element defaultValue shall be as given in Tab. 42.

7.4.7.7.2.6

substituteValue

The substituteValue element defines a specific value of the parameter that is provided to the device
application in certain device operating states (e.g. on device fault).
An optional g_labels sub-element may provide multilingual names and/or descriptive information forthis value. The value itself is provided by the value attribute of the element substituteValue. An offset
and multiplier may also be provided.
The attributes of the element substituteValue shall be as given in Tab. 42.

7.4.7.7.2.7

allowedValues

The allowedValues element defines a list of supported values and/or a single range or several rangesof supported values for the parameter (see Fig. 21).
The list of supported values is represented by zero to many value sub-elements of the allowedValues
element, whereas the ranges are represented by zero to many range sub-elements of theallowedValues element.
The value sub-element holds a single allowed value of the parameter. An optional g_labels subelement may provide multilingual names and/or descriptive information for this value. The value itself
is provided by the value attribute of the element value. An offset and multiplier may also be provided.
The attributes of the element value shall be as given in Tab. 42.

EPSG DS 311 V1.2.1-47-

The range sub-element contains two required sub-elements, namely the element minValue and theelement maxValue, which define the limits of that range of allowed values. The optional step subelement may be used to define equidistant intermediate values inside a range. The minValue,
maxValue and step elements have the same structure and attributes as the value sub-element of theallowedValues element. Therefore the description of the value sub-element and Tab. 42 are also valid
for these sub-elements.

7.4.7.7.2.8

unit

The unit element defines the engineering unit of a parameter (e.g. time, temperature, pressure, flow,
acceleration, current, energy), as specified in ISO 1000. An optional g_labels sub-element may
provide multilingual names and/or descriptive information for the engineering unit.
The attributes of the element unit shall be as given in Tab. 43.
Attributemultiplier

Data typexsd:stringUserequired

unitURI

xsd:anyURI

optional

Tab. 43

Attributes of element unit

7.4.7.7.2.9

Description
Multiplier for engineering units of analog
parameters
Link to the respective unit definition in a filecontaining all engineering units (time,
temperature, pressure, flow, acceleration,
current, energy…), as standardized by ISO
1000

variableRef

The variableRef element builds a reference to an interface variable of a function instance, or, if thevariable is an array or a structure, possibly a reference to a member of the variable (array element or
structure component).
In a hierarchically structured ApplicationProcess element, function instances can be located inside
function instances of other function types. Therefore stepping through the tree can only access a
specific instance in the functional tree, i.e. the specific instance shall be addressed through aconcatenation of instance names. To map this concatenation and allow the referencing of a member,the variableRef element contains:•a sequence of one to many instanceIDRef elements, followed by•a single mandatory variableIDRef element, and•an optional memberRef element.
The variableRef element has the attribute given in Tab. 44.
Attribute
position

Data typexsd:unsignedByte

Description
Defines the sequence of multiple mapped data
items into a single parameter object; position=1
means starting the mapping at the lowest bit
position; the number of bits is defined by thedata type of the data item; subsequent data
items are packed without gaps; default value: 1(see NOTE)
NOTE Attribute can be omitted for a single mapped data item.
Tab. 44

Attribute of element variableRef

7.4.7.7.2.10

Usedefault

instanceIDRef

The instanceIDRef element serves to reference a function instance inside a functionInstanceList
element, which may reside either on the level of the ApplicationProcess element or on the level of afunctionType element.
The reference of type xsd:IDREF is provided as an attribute of the instanceIDRef element, as given in
Tab. 45.

EPSG DS 311 V1.2.1

AttributeuniqueIDRef
Tab. 45

Data typexsd:IDREF

-48-

Use
required

Description
Unique ID of the referenced function instance

Attribute of element instanceIDRef

7.4.7.7.2.11

variableIDRef

The variableIDRef element serves to reference an interface variable of a function type inside thefunctionTypeList element.
In a given variableRef element the instance of that function type is defined by the functionInstanceelement referenced by the instanceIDRef element, which is just preceding the variableIDRef element.
The reference of type xsd:IDREF is provided as an attribute of the variableIDRef element, as given in
Tab. 46.
AttributeuniqueIDRef
Tab. 46

Data typexsd:IDREF

Userequired

Description
Unique ID of the referenced interface variable ofa function type

Attribute of element variableIDRef

7.4.7.7.2.12

memberRef

The optional memberRef element either references the respective component of an interface variableof structured data type (attribute uniqueIDRef is used), or the respective array element of an interface
variable of array data type (attribute index is used). One of these two attributes shall be present if thememberRef element is present.
The memberRef element shall contain the attributes given in Tab. 47.
AttributeuniqueIDRef

Data typexsd:IDREF

Use
optional

index

xsd:long

optional

Tab. 47

Description
Unique ID of the referenced component of astructured data typeIndex of the referenced array element

Attributes of element memberRef

7.4.7.7.2.13

property

The property element is introduced as a generic element to allow the inclusion of values for additional
specific properties into the description of a parameter.
The property element shall contain the attributes given in Tab. 48.
Attribute
name
value
Tab. 48

Data typexsd:string
xsd:stringUserequired
required

Description
Name of the property
Value of the property

Attributes of element property

7.4.7.8

parameterGroupList

7.4.7.8.1

GeneralThe optional parameterGroupList element, if present, contains a sequence of one to many
parameterGroup elements, as shown in Fig. 22. Multilingual names and/or descriptions for theparameter groups are provided through the group g_labels.

EPSG DS 311 V1.2.1

Fig. 22.

7.4.7.8.2-49-

parameterGroupList

parameterGroup

Each of the parameterGroup elements combines a set of parameters out of the parameterList element
to build a group of parameters which serve a specific purpose, e.g. to prepare HMI views. This
purpose is indicated by the value of the kindOfAccess attribute of the parameterGroup element. It is
possible to define a hierarchy of parameter groups.
The respective parameters in the set are referenced through the corresponding number ofparameterRef elements.
The parameterGroup element contains the attributes given in Tab. 49.

EPSG DS 311 V1.2.1-50-

AttributeuniqueID

Data typexsd:ID

Use
requiredkindOfAccessxsd:string

optional

configParameter

xsd:boolean

default

groupLevelVisible

xsd:boolean

default

conditionalUniqueIDRef

xsd:IDREF

optional

conditionalValue

xsd:string

optional

bitOffset

xsd:nonNegativeInteger

default

Tab. 49

7.4.7.8.3

Description
Unique ID of theparameter group.
Classifies theparameters of theparameter group.
An engineering
tool shallconsider thegroup asconfiguration
parameters if therespective visible
attribute is true.
Default: false.
An engineering
tool shall not
display a newhierarchy level forthis group.
Default: false.
Referenced
parameter forconditional
processing of thisgroup.
Value forcomparison withreferenced
parameter. If thereferenced
parameter does
not have thegiven value, thegroup shall beignored by anengineering tool.
Only relevant if
directly or
indirectly
referenced by an
Object elementfromcommunication
network profile.
Value for the bit
offset defined
position in theparent element.
Default: 0

Attributes of element parameterGroupparameterRef

The parameterRef element serves to reference a parameter element inside the parameterList elementof the ApplicationProcess element.

EPSG DS 311 V1.2.1-51-

The reference of type xsd:IDREF is provided as an attribute of the parameterRef element, as given in
Tab. 50.
AttributeuniqueIDRef
actualValue

Data typexsd:IDREF
xsd:stringUserequired
optional

visiblexsd:boolean

default

lockedxsd:boolean

default

bitOffset

xsd:nonNegativeInteger

default

Tab. 50

Attribute of element parameterRef

Description
Unique ID of the referenced parameter
Actual value of parameterRef. Can be used
to control further conditional groups.
Defines the visibility of the parameter in anengineering tool. Default: false
Disable user input in an engineering tool .
Default: false
Only relevant if indirectly referenced by an
Object element from communication
network profile.
Value for the bit offset defined position inparent parameterGroup element. If bitOffset
is implemented, the parent parameterGroupalso shall implement bitOffset. Default: 0

EPSG DS 311 V1.2.1

-52-

7.5

Communication network profile templatedescription

7.5.1

ProfileBody_CommunicationNetwork_Powerlink

This part of the device profile template defines the POWERLINK communication interface.
The ProfileBody_CommunicationNetwork_POWERLINK element contains the ApplicationLayers, theTransportLayers and the NetworkManagement sub-elements shown in Fig. 7. It has the attributes
given in Tab. 51.
AttributeformatName
formatVersion
fileName
fileCreator
fileCreationDate
fileCreationTime
fileModifiedBy
fileModificationDate
fileModificationTime
fileVersion
supportedLanguages
specificationVersion
Tab. 51

7.5.2

Data typexsd:string
xsd:string
xsd:string
xsd:string
xsd:date
xsd:time
xsd:string
xsd:date
xsd:time
xsd:string
xsd:NMTOKENS
xsd:string

Use
fixed
fixed
required
required
required
optional
optional
optional
optional
required
optional
default

Description
Format identifier
Format version identifier
Name of the file with extension without path
Person creating the file
Date of file creation
Time of file creation
Person modifying the file
Date of last file changeTime of last file change
Vendor specific version of the file
List of supported languages
Describes the specification version of thedevice profile template. Default: 1.0.4

Attributes of element ProfileBody

ProfileBody_CommunicationNetwork_Powerlink_Modular_Head

This part of the device profile template defines the POWERLINK communication interface for a
modular head node. If a device implements a modular head node this profile template shall be used.
The ProfileBody_CommunicationNetwork_Powerlink_Modular_Head element contains the
ApplicationLayers, the TransportLayers and the NetworkManagement sub-elements shown in Fig. 7. It
has the attributes given in Tab. 51 and Tab. 52. Additionally it includes a moduleManagement elementin the ApplicationLayers element to support the modular head node device functionality.
Attribute
specificationVersion
Tab. 52

7.5.3

Data typexsd:stringUserequired

Description
Describes the specification version of thedevice profile template. Fixed: 1.0.4

Additional attribute of ProfileBody_CommunicationNetwork_Powerlink_Modular_Head

ProfileBody_CommunicationNetwork_Powerlink_Modular_Child

This part of the device profile template defines the POWERLINK communication interface for a
modular child node. If a device implements a modular child node this profile template shall be used.
The ProfileBody_CommunicationNetwork_Powerlink_Modular_Child element contains the
ApplicationLayers, the TransportLayers and the NetworkManagement sub-elements shown in Fig. 7. It
has the attributes given in Tab. 51 and Tab. 53. Additionally it includes a moduleManagement elementin the ApplicationLayers element to support the modular child node device functionality.

EPSG DS 311 V1.2.1

Attribute
specificationVersion
Tab. 53-53-

Data typexsd:stringUserequired

Description
Describes the specification version of thedevice profile template. Fixed: 1.0.4

Additional attribute of ProfileBody_CommunicationNetwork_Powerlink_Modular_Child

7.5.4

ApplicationLayers

7.5.4.1

GeneralFig. 23 shows the structure of the ApplicationLayers element.

Fig. 23.

POWERLINK ApplicationLayers element

The ApplicationLayers element has the attributes given in following Table.
AttributeconformanceClass

Description
Conformance class of the device type(see NOTE)
communicationEntityType xsd:NMTOKENS
default
Shall not be used. Provided forcompatibility to CANopen. default: slave
NOTE Using that attribute it is possible to classify the device according to the supported services of
the communication protocol.
Tab. 54

7.5.4.2

Data typexsd:stringUse
optional

Attributes of element ApplicationLayers

identity

Since different communication profiles may require different identity information, an optional local
identity sub-element may be used within an ApplicationLayers element. This identity element may
contain a subset of the sub–elements of the DeviceIdentity element, shown in Fig. 24. All sub–element
descriptions given there also apply for the sub-elements of this identity element.

Fig. 24.

identity element with sub-elements

EPSG DS 311 V1.2.1

7.5.4.3-54-

DataTypeList

Data types in ObjectList are given in hexadecimal number (defined in the POWERLINK Specification).
The element DataTypeList stores a hex to data type relation to ease tool implementation. Modular
child devices may not implement the DataTypeList element. The following Figure shows the element
DataTypeList and its sub elements (not all data types shown)

Fig. 25.

DataTypeList element

For each data type DataTypeList contains a sub element defType. The defType element contains theattributes given in following Table.
Attribute
dataType

Data typexsd:hexBinaryUserequired

Tab. 55

Attributes of element defType

Description
Gives the hexadecimal code for the specified
data type (codes are defined in the
POWERLINK specification). This code is thenused in the dataType attributes of the elements
Object and SubObject.

Therefore a device description file may contain the following fragment, with multiple defType subelements:<DataTypeList><defType dataType="hexadecimal number"><data type/></defType></DataTypeList>

Thereby one defType sub-element for each hexadecimal number of Tab. 56is mandatory.

EPSG DS 311 V1.2.1-55-

Hexadecimal representation

Data type

0001
0002
0003
0004
0005
0006
0007
0008
0009
0010
0011
0012
0013
0014
0015
000A
000B
000C
000D
000F
0016
0018
0019
001A
001B
0401
0402
0403

BooleanInteger8
Integer16
Integer32
Unsigned8
Unsigned16
Unsigned32
Real32Visible_String
Integer24
Real64Integer40
Integer48
Integer56
Integer64
Octet_String
Unicode_String
Time_of_Day
Time_Diff
DomainUnsigned24
Unsigned40
Unsigned48
Unsigned56
Unsigned64
MAC_ADDRESSIP_ADDRESSNETTIME

Tab. 56

7.5.4.4

Hexadecimal representation of the data types

ObjectList

Following figure shows the structure of the ObjectList element. The element contains one to many
Object elements.

Fig. 26.

ObjectList element

The ObjectList element contains the attributes given in following Table.
Attribute
mandatoryObjects
optionalObjects
manufacturerObjects
Tab. 57

Data typexsd:unsignedInt
xsd:unsignedInt
xsd:unsignedInt

Use
optional
optional
optional

Attributes of element ObjectList

Description
Number of mandatory objects in the dictionary
Number of optional objects in the dictionary
Number of manufacturer-defined objects inthe dictionaryEPSG DS 311 V1.2.1-56-

If these attributes are used the objects given in ObjectList shall appear in order: all mandatory objects
first followed by optional objects and ended with the manufacturer objects.

7.5.4.4.1

Object

The element contains zero to many SubObject elements. The Object element and the SubObject
element map the functional part of the POWERLINK device profile to the POWERLINK communication
network profile.
The Object element contains the attributes given in following Table.

EPSG DS 311 V1.2.1-57-

Attribute
index

Data typexsd:hexBinary

nameobjectType
dataType

xsd:string
xsd:unsignedByte
xsd:hexBinary

Use
Required(optionalfor
modulardevice)required
required
optional

lowLimit
highLimit
accessTypexsd:string
xsd:string
xsd:NMTOKEN

optional
optional
optional

Description
Index of the object (four hex digits). A modular
device may define an index offset with this
attribute. This offset must not be higher than the
sortStep of the referenced range in the head
node.
Name of the object
POWERLINK object type
POWERLINK data type (four hex digits). Seeelement DataTypeList.
Low limit of the parameter value
High limit of the parameter value
Access type of the object; valid values:•

const – read only access; the value is
not changing•

ro – read only access•

wo – write only access•rw – both read and write accessdefaultValue
actualValue

xsd:string
xsd:string

optional
optional

Default value of the object
Actual value of the object. Tools store
calculated values or user input in this attribute.
Usually device description files (.xdd) do notcontain this attribute, it is added by a tool after
initial loading of a .xdd file. If the attributeactualValue is used the file has to be stored asa .xdc (XML device configuration file).
However it might be necessary1 to add theattribute already in the .xdd to define preset
values of objects, which shall be part of the.xdc, even without user input.

denotation

xsd:string

optional

Application specific name of the object. Used bytools for application specific object naming (e.g.
pressure, velocity). If the attribute denotation isused the file has to be stored as a .xdc (XMLdevice configuration file).

PDOmapping

xsd:NMTOKEN

optional

PDO mapping of the object; valid values:•no – not mappable•••

objFlags

xsd:hexBinary

optional

default – mapped by default
optional – optionally mapped
TPDO – may be mapped into TPDO
only
• RPDO – may be mapped into RPDO
only
Controls the behaviour of tools (four hex digits)• bit 0: 0 – write on download allowed
1 – write on download not allowed• bit 1: 0 – read on upload allowed
1 – read on upload not allowed

1 NOTE: By this it is possible to preselect a certain value, if the value is not equal to the default value.

E.g. selection of a specific temperature sensor

EPSG DS 311 V1.2.1-58-• bit 2: 0 – change of value takes effectimmediately
1 – change of value takes effectafter reset• bit 3 to 31: reserved (0)NOTE 1 Bit 0 and bit 1 shall prevent
unintended read or write access by generic
tools in case a parameter implements a specificfunction. A read or write in such cases may
trigger a specific function in the POWERLINK
device.

uniqueIDRef

xsd:IDREF

optional

subNumber
rangeSelector(modular device
only)

xsd:unsignedByte
xsd:string

optional
required(optionalfor
modularhead
device)Tab. 58

NOTE 2 Bit 2 gives information whether thechange of an object value is immediately
recognized by a device (and leads to a different
behaviour) or is deferred to the next reset of thedevice.
Unique ID of an appropriate element in theapplication process part referenced from thisobject; if the attribute is present and isreferencing a parameter, the attributes
dataType, lowLimit, highLimit, accessType, anddefaultValue may be defined by the referenced
element in the application process part.
Number of sub-objects of the object
Reference the index range to be used according
to the range element in the head node.

Attributes of element Object

7.5.4.4.1.1

SubObject

The SubObject element has an empty content and contains the attributes given in following Table.

EPSG DS 311 V1.2.1-59-

Attribute
subIndex
nameobjectType
dataType

Data typexsd:hexBinary
xsd:string
xsd:unsignedByte
xsd:hexBinaryUserequired
required
required
optional

lowLimit
highLimit
accessTypexsd:string
xsd:string
xsd:NMTOKEN

optional
optional
optional

Description
Subindex of the sub-object (two hex digits)
Name of the sub-object
POWERLINK object type
POWERLINK data type (four hex digits). Seeelement DataTypeList.
Low limit of the parameter value
High limit of the parameter value
Access type of the sub-object; valid values:•

const – read only access; the value is
not changing•

ro – read only access•

wo – write only access•rw – both read and write accessdefaultValue
actualValue

xsd:string
xsd:string

optional
optional

Default value of the sub-object
Actual value of the sub-object. Tools store
calculated values or user input in this attribute.
Usually device description files (.xdd) do notcontain this attribute, it is added by a tool after
initial loading of a .xdd file. If the attributeactualValue is used the file has to be stored asa .xdc (XML device configuration file).
However it might be necessary2 to add theattribute already in the .xdd to define preset
values of objects, which shall be part of the.xdc, even without user input.

denotation

xsd:string

optional

Application specific name of the sub-object.
Used by tools for application specific object
naming (e.g. pressure, velocity). If the attributedenotation is used the file has to be stored as a
.xdc (XML device configuration file).

PDOmapping

xsd:NMTOKEN

optional

PDO mapping of the sub-object; valid values:•no – not mappable•••

objFlags

xsd:hexBinary

optional

default – mapped by default
optional – optionally mapped
TPDO – may be mapped into TPDO
only
• RPDO – may be mapped into RPDO
only
Controls the behaviour of tools (four hex digits)• bit 0: 0 – write on download allowed
1 – write on download not allowed• bit 1: 0 – read on upload allowed
1 – read on upload not allowed• bit 2: 0 – change of value takes effectimmediately
1 – change of value takes effectafter reset

2 NOTE: By this it is possible to preselect a certain value, if the value is not equal to the default value.

E.g. selection of a specific temperature sensor

EPSG DS 311 V1.2.1

-60-

•

bit 3 to 31: reserved (0)NOTE 1 Bit 0 and bit 1 shall prevent
unintended read or write access by generic
tools in case a parameter implements a specificfunction. A read or write in such cases may
trigger a specific function in the POWERLINK
device.

uniqueIDRef

Tab. 59

xsd:IDREF

optional

NOTE 2 Bit 2 gives information whether thechange of an object value is immediately
recognized by a device (and leads to a different
behaviour) or is deferred to the next reset of thedevice.
Unique ID of an appropriate element in theapplication process part referenced from thisobject; if the attribute is present and isreferencing a parameter, the attributes
dataType, lowLimit, highLimit, accessType, anddefaultValue may be defined by the referenced
element in the application process part

Attributes of element SubObject

dynamicChannels

7.5.4.5

The optional dynamicChannels element contains one to many dynamicChannel elements.

dynamicChannel

7.5.4.5.1

The dynamicChannel element is used to mark available channels that can be used to create a link
between the data to be communicated in the POWERLINK network and the application program
running on the device.
The dynamicChannel element contains the attributes given in following Table.
Attribute
dataType

Data typexsd:hexBinaryUserequired

Description
POWERLINK data type (two hex digits)

accessType

xsd:NMTOKEN

requiredAccess type of the object; valid values:

startIndex

xsd:hexBinary

requiredendIndex

xsd:hexBinary

requiredmaxNumber

xsd:unsignedInt

requiredaddressOffset

xsd:hexBinary

required

bitAlignment

xsd:unsignedByte

optional

Tab. 60

Attributes of element dynamicChannel•

readOnly•

writeOnly• readWriteOutput
The index of the first object dictionary usedby the process image.
The index of the last object dictionary usedby the process image.
The maximum number of objects, which canbe allocated in this segment.
The content is the offset of the segment
inside the process image.
The content defines the bit alignment used.
Most often this will be 1 (bit alignment), 8(byte alignment), 16 (word alignment), or 32(double word alignment).

EPSG DS 311 V1.2.1-61-

moduleManagement (modular device only)

7.5.4.6

This element is only supported in the abstract profile type which includes the modular device support
for modular head devices ProfileBody_CommunicationNetwork_Powerlink_Modular_Head.

General7.5.4.6.1

The moduleManagement element, contains the interfaceList element. The structure of themoduleManagement element is given in Fig. 27.

Fig. 27.

moduleManagement element of a modular head node

7.5.4.6.2

interfaceList / interface

7.5.4.6.2.1

GeneralThe optional interfaceList element, if present, contains a sequence of one to many interface elements.
The mandatory interface element is used to indicate the properties of one interface provided by amodular device. These properties include the range of the indices to be used. The interface element
contains the attributes defined in Tab. 61.
AttributeuniqueIDRef

Tab. 61

Data typexsd:IDREF

Userequired

Description
Reference to the unique ID of the sameinterface definition as part of the device
profile part.

Attributes of element interface

7.5.4.6.2.2

rangeList / range

The mandatory rangeList element contains a sequence of one to many range elements.
The mandatory range element is used to define a range of indices to be used when creating new
objects based on the connected modules to a modular device. The range element contains theattributes defined in Tab. 62.

EPSG DS 311 V1.2.1-62-

Attribute
nameData typexsd:stringUserequired

Description
Name of the range.

baseIndex

xsd:hexBinary

requiredmaxIndex

xsd:hexBinary

optional

maxSubIndex

xsd:hexBinary

required

sortMode

xsd: NMTOKEN

required

sortNumber

xsd: NMTOKEN

required

sortStep

xsd:positiveInteger

default

PDOmapping

xsd:NMTOKEN

optional

First index to be used within therange.
Last index to be used within therange. If sortMode is subindex
and no subindex overflow isallowed, this attribute may beomitted as it is equal to thebaseIndex.
Last subindex to be used within
the range, if sortMode is set tosubindex.
Sort mode according to either a
new index or a new subindex iscreated for any new object orsubobject; valid values:• index• subindex
The rule how a new index or
subindex is created; valid
values:• continuous – a newindex or subindex iscreated continuously formodule objects.
• address –A new index
or subindex is createddepending on theaddress of the module.
A new index is
calculated baseIndex
plus address minus 1.
Step width for the next module.
Default: 1.
PDO mapping of the objects andsub-objects; valid values:•no – not mappable•default – mapped bydefault
optional – optionallymappedTPDO – may bemapped into TPDO only
RPDO – may bemapped into RPDO only•••
Tab. 62

Attributes of element range

Examples for the usage of sortNumber and sortStep are given in Fig. 28.

EPSG DS 311 V1.2.1-63-

DeviceDeviceRange: 2000h-20FFh
sortNumber = continuous

Range: 2000h-20FFh
sortNumber = address
sortStep = 0x10

3 Child-XDDs

3 Child-XDDs

Object A

Index 2000h

Object B
Object C

Index 2001hIndex 2002hObject D

Index 2003hFig. 28.

Object A
index = 0000h

Index 2000h

Object B
index = 0000h
Object C
index = 0005h

Index 2010hObject D
index = 0001h

Index 2021h

Index 2015h

Examples for index generation with sortNumber and sortStep

The resulting object index of the module configured for a given device consists of the baseIndex +sortStep (result of index generation as described in Fig. 28) + the index of the modules object.

7.5.5

TransportLayers

The TransportLayer element is empty, it is present for compatibility with the CANopen device
description.

7.5.6

NetworkManagement

The following figure shows the structure of the NetworkManagement element. This element is optional
for modular child devices but mandatory for any other POWERLINK device.

Fig. 29.

NetworkManagement element

Device information not covered by mandatory objects are stored in subelements of
NetworkManagement, these are:•Features
Are called device description entries in the POWERLINK Specification. See the POWERLINKSpecification for a comprehensive list. The features are further grouped in general, MN and CN
features.

EPSG DS 311 V1.2.1

•

•

-64-

device commissioning
Used by tools to store additional commissioning information (in device configuration files - .xdc
only)
Diagnostic
Description of diagnostic data (errors) reported from the device

7.5.6.1

Features

Every feature is assigned to GeneralFeatures, MNFeatures or CNFeatures according to its availability
in a MN, CN or both. The GeneralFeatures sub element is mandatory whereas MNFeatures and
CNFeatures are optional. In a device description for a CN the element CNFeatures has to be present,
vice versa for MNFeatures. It is also possible that MNFeatures and CNFeatures are present (fordevices which support MN and CN mode of operation).
The elements GeneralFeatures, MNFeatures or CNFeatures have an empty content.
Every feature is described as an attribute of GeneralFeatures, MNFeatures or CNFeatures. The data
type of a feature is derived from the data type defined in the POWERLINK Specification.
For a list and description of all POWERLINK Features please refer to the device description entries in
the POWERLINK Specification.

7.5.6.1.1

Feature Names

Every feature defined in the POWERLINK specification (there called device description entry) has aname starting with "D_" and ending with a data type designator (e.g. "_U32"). The device description
feature name strips these information and additionally all underlines ("_") are deleted.
Example:"D_SDO_MaxParallelConnections_U32" gives the feature name "SDOMaxParallelConnections".

7.5.6.1.2

Feature Data Types

Every device description entry in the POWERLINK Specification has an assigned data type. These areconverted to XML data types as follows:
POWERLINKBOOLEANINTEGER8
INTEGER16
INTEGER32
UNSIGNED8UNSIGNED16
UNSIGNED32
REAL32
VISIBLE_STRING
OCTET_STRINGUNICODE_STRING
REAL64
Tab. 63

7.5.6.2

XML
xsd:boolean
xsd:byte
xsd:short
xsd:int
xsd:unsignedByte
xsd:unsignedShortxsd:unsignedInt
xsd:float
xsd:string
xsd:string
xsd:string
xsd:double

POWERLINK/XML data types

deviceCommissioning

The deviceCommissioning element is optional and has an empty content.
A .XDD contains no deviceCommissioning element, it is used by a tool to store configuration specificdata in a .XDC file.

EPSG DS 311 V1.2.1-65-

The deviceCommissioning element contains the attributes given in Tab. 64.
Attribute
networkName

Data typexsd:stringUserequirednodeID
nodeName
nodeType

xsd:unsignedByte
xsd:string
xsd:NMTOKENS

required
required
required

usedNetworkInterface

xsd:unsignedByte

default

Tab. 64

Description
The name of the network segment to which
the device is connected.
The unique ID (node number) of the device.
The name of the device.
The allowed values are "CN", "MN", andpossible for future extensions.
For multi interface devices, index of usedinterface (see Object 1030h) default = 0

Attributes of element deviceCommissioning

Diagnostic

7.5.6.3

The optional element Diagnostic contains the optional elements ErrorList and StaticErrorBitField. No
attributes are defined.
The element Diagnostic is used to provide tools with presentational detail for the informationtransported in the StatusResponse frame (see the POWERLINK specification for details).

Fig. 30.

Element Diagnostic

ErrorList

7.5.6.3.1

The element ErrorList is optional. It is further decomposed as shown in following figure.

Fig. 31.

Element ErrorList

The element ErrorList contains no attributes. One to many Error elements may be defined inside theErrorList element.

7.5.6.3.1.1

Error

An Error element defines an error which may be signalled by the device. A device description filespecifies only the Errors which are device or manufacturer specific. Errors which are already definedin the POWERLINK Specification are not presented in the device description file.
The element Error has the following attributes:
Attribute
name
value

Data typexsd:string
xsd:string

Tab. 65

Attributes of element Error

Userequired
required

Description
A short name for the error.
The error code as signalled from the device.

EPSG DS 311 V1.2.1-66-

The element Error may contain an optional g_labels element for multilingual descriptions of the error.
It may also contain any number of optional addInfo elements.
The element addInfo is used to describe the content of the 64 Bits of additional information which may
be sent from device in addition to the error code. If there is no addInfo element no additional
information is provided for this error, therefore a tool shall not display the addition information (which issent but has unspecified content).
The additional information may be organized in bit groups, a group containing 1 to 32 consecutive bits.
Each of these groups is described by an addInfo element.
The element addInfo has the following attributes:
Attribute
bitOffset

Data typexsd:unsignedByte

Use
requiredlen

xsd:unsignedByte

requiredname

xsd:string

required

Tab. 66

Description
This is the bit starting an additional information
bit group.
The 64 Bits of additional information are
numbered from 0 (LSB) to 31 (MSB). Refer tothe POWERLINK specification for further
information.
The number of consecutive bits in the additional
information bit group.
The short name for the additional information bitgroup.

Attributes of element addInfo

The element addInfo may contain an optional g_labels element for multilingual descriptions of theadditional information bit group. It may also contain any number of optional value elements.
The element value is provided to enumerate certain values of an additional information bit group.
Tools may use this information to show a text instead of plain numbers. Values which have no text
assigned to, are treated as unsigned numbers.
The element value has the following attributes:
Attribute
value
name

Data typexsd:string
xsd:string

Tab. 67

Attributes of element valueUse
required
required

Description
The value (unsigned number).
The short name assigned to value.

The element addInfo may contain an optional g_labels element for assignment of multilingual texts tonumbers.

7.5.6.3.2

StaticErrorBitField

This element is used to describe the 64 static error bits inside the StatusResponse frame (see the
POWERLINK V2 specification for details). Bits which are already defined in the POWERLINKSpecification are not presented in the device description file.

Fig. 32.

Element StaticErrorBitField

The element StaticErrorBitField contains 1 to 64 ErrorBit elements.
The ErrorBit element describes one bit.
The element ErrorBit has the following attributes:

EPSG DS 311 V1.2.1

Attribute
nameoffsetTab. 68

Data typexsd:string
xsd:nonNegativeInteger
<=63

-67-

Use
required
required

Description
The short name.
Bit number (starting at 0) in the static error
bit field.

Attributes of element ErrorBit

The element ErrorBit may contain an optional g_labels element for assignment of multilingual texts toerror bits.

EPSG DS 311 V1.2.1

8

-68-

File naming convention

The file naming convention defined in this chapter shall apply to the following XML files•
the profile definition file•the device description file and•the device configuration file
The profile definition file is an XML representation of a POWERLINK framework, POWERLINK device
profile or POWERLINK application profile. The extension shall be “XPD”.
The device description file is an XML file describing the device type of a POWERLINK device. The
name of the file shall contain the vendor-ID of the POWERLINK device in the form of 8 hexadecimal
digits. The extension shall be “XDD”.
The information in the XDD file is used as a blueprint for instantiation of devices in an actual network
configuration. An XDD file contains the device default value but no device commissioning values andusually no actual values.
The device configuration file is an XML file describing a configured POWERLINK device. The
extension shall be “XDC”.
All information from the XDD file plus actual values and/or device commissioning values can be stored
in an XDC file. i.e. An XDC file stores the information for a specific instantiation of a device in a
specific network environment.
See App. 3 for details on file naming syntax.

EPSG DS 311 V1.2.1

9

-69-

Tool behaviour

All the information needed to configure a POWERLINK network is contained in the device description
files. Especially 2 areas inside the file are important.
1. The ObjectList contains all objects the device supports. This includes the mandatory objects
as defined in the POWERLINK specification. The objects default value (as stored in theattribute defaultValue) has to be considered for network and device configuration purposes. It
is not necessary to have an online connection to the device for configuration, the whole
configuration process can be done offline using the default values.
2. Device features (see elements GeneralFeatures, MNFeatures, CNFeatures) represent
information which is partly not contained in the device's object dictionary.

EPSG DS 311 V1.2.1-70-

App. 1 Value syntax (normative)
The values given are formatted as xsd:string in terms of XML. Values representing other datatypes than string values, e.g. numerical values, shall be given in accordance to the definition of IEC
61131-3.
NOTE The definition of hexadecimal values is different to the definition of IEC 61131-3. The definitionis according to ANSI C.
boolean_value
unsigned
integer_value
hexadecimal_value
exponent
real_value
hex_digit
hex_letter
digit::= 'true' | 'false':= digit { digit }::= [ '+' | '–' ] unsigned::= '0' 'x' { hex_digit }::= { 'E' | 'e' } integer_value::= integer_value '.' unsigned [ exponent ]::= digit | hex_letter::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'A' | 'B' | 'C' | 'D' | 'E' | 'F'::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'

EPSG DS 311 V1.2.1-71-

App. 2 XML file content convention (normative)
The XML file content shall be encoded in UTF8.

EPSG DS 311 V1.2.1-72-

App. 3 XML file naming syntax (normative)
The syntax defined in this annex applies to the following XML files•
the profile definition file (XPD),•
the device description file (XDD), and•the device configuration file (XDC).
No other characters than the following named characters are allowed in the XML file. The file nameshall not be case sensitive.
The XML file name of the text resource file shall be built using the same rules as defined for the XML
file name of the POWERLINK device description.
filename_XPD
filename_XDD
filename_XDC
filename_textresource
prefixpostfix
vendor_id
characterletterlowercase_letter
uppercase_letter
hex_digit
digit
hex_letter::= character { character | ‘_‘ | ‘-‘ } ‘.‘ (‘XPD‘ | ‘xpd‘ )::= [ prefix ] vendor_id [ postfix ] ‘.‘ (‘XDD‘ | ‘xdd‘ )::= character { character | "_" } "." ( "XDC" | "xdc" )::= [ prefix ] vendor_id [ postfix ] "." character { character }::= character { character | ‘-’} ’_’::= ‘_‘ {character | ‘-’} character::= 8 * hex_digit::= letter | digit::= lowercase_letter | uppercase_letter::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' | 'j' | 'k' | 'l' | 'm'| 'n' | 'o' | 'p' | 'q' | 'r' | 's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' |'z'::= 'A' | 'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' | 'K' | 'L'| 'M'| 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' | 'T' | 'U' | 'V' | 'W'| 'X' | 'Y' | 'Z'::= digit | hex_letter::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'A' | 'B' | 'C' | 'D' | 'E' | 'F'

EPSG DS 311 V1.2.1-73-

App. 4 Text resource
A text resource file contains exactly one textResource element. The textResource element has a lang
attribute, which designates the language of all text entries within the text resource file.
Following figure shows the structure of the textResource element.

Fig. 33.

Element textResource

The element textResource has the following attributes:
AttributelangTab. 69

Data typexsd:language

Userequired

Description
Language of all text entries within the text
resource file.

Attributes of element textResource

The element textEntry contains the text data as content.
The element textEntry has the following attributes:
Attribute
textID
Tab. 70

Data typexsd:stringUserequired

Attributes of element textEntry

Description
Text identifier of the text entryEPSG DS 311 V1.2.1-74-

App. 5 Child identification (normative)
Object identList3: NMT_ChildIdentData_ADOM
NMT_ChildIdentData_ADOM holds identification data for child devices. It allows the access to
identification data of up to 254 child devices. If the interface supports more than 254 child devices thelist will continue with sub-index 1 of the index following identList.
Index
Name
Data Type•identList
NMT_ChildIdentData_ADOM
DOMAIN

ARRAY

CategoryO

AccessPDO MappingroNoCategory
AccessPDO Mapping

O
ro
No

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value•

Object Type00h
NumberOfEntries
01h .. FEh
01h

Sub-Index 01h .. FEh: ChildIdent
Sub-Index
Name-Value Range
Default Value

01h .. FEh
ChildIdent-DOMAIN-

ChildIdent sub-indices provide access to the identification data of child devices.
Each sub-index in the array corresponds to the child device with the module number equal to
the sub-index.
•

Value Interpretation
VendorId_U32

ProductCode_U32

RevisionNo_U32

SerialNo_U32

ApplSwDate_U32

ApplSwTime_U32…

Tab. 71 ChildIdent value interpretation
ChildIdent is composed of at least 24 octets. The vendor may define more (vendor specific)
data after this. However the size of the domain shall not exceed 128 bytes.
NOTE: This is to avoid problems with clients which cannot handle very large domains.
VendorId_U32, ProductCode_U32_RevisionNo_U32 and SerialNo_U32 are equivalent to theobjects 1018h (NMT_IdentityObject_REC). ApplSwDate_32 and ApplSwTime_U32 areequivalent to 1F52h (PDL_LocVerApplSw_REC). For definitions and details see EPSG DS 301[7].

3 identList represents the value given by the attribute identList.

EPSG DS 311 V1.2.1-75-

App. 6 Child firmware update (normative)
Object firmwareList4: PDL_DownloadChildProgData_ADOM
PDL_DownloadChildProgData_ADOM holds downloaded programs for child devices. It allows theaccess to up to 254 programs. If the interface supports more than 254 child devices the list willcontinue with sub-index 1 of the index following firmwareList.
Index
Name
Data Type
•

ARRAY
O

Sub-Index 00h: NumberOfEntries
Sub-Index
Name
Value Range
Default Value•

firmwareList
Object TypePDL_DownloadChildProgData_ADOM
DOMAIN
Category

00h
NumberOfEntries
01h .. FEh
01hAccessPDO MappingroNoCategory
AccessPDO Mapping

O
cond
No

Sub-Index 01h .. FEh: ChildProgram
Sub-Index
Name-Value Range
Default Value

01h .. FEh
ChildProgram-DOMAIN-

ChildProgram sub-indices provide access to the firmware of child devices.
If the device supports reading of the program the access shall be rw otherwise wo.
Each sub-index in the array corresponds to the child device with the module number equal to
the sub-index.

4 firmwareList represents the value given by the attribute firmwareList.

EPSG DS 311 V1.2.1

App. 7-76-

ParameterGroup and parameterRef
bitOffset attribute usage

The following XDD example code implements the bitOffset attribute of the parameterGroup element
and parameterRef element to configure the actual value of an Object element. It shows a hierarchy ofparameterGroup and parameterRef elements used to set a number of specific bits in a 8 byte sized
object entry.
The dataType and accessType of the referenced parameterGroup with uniqueID “UID_PG1” is also
valid for all nested parameterRef and parameterGroup elements.
…
<parameter uniqueID="UID_Index21xx_Sub64_RegNumber" access="readWrite"><label lang="en">register Number</label><label lang="de">Registernummer</label><UINT/><defaultValue value="1"/></parameter>…
<parameter uniqueID="UID_Index21xx_MOD_CfgEntry_Size1"
templateIDRef="UID_PT_Index21xx_MOD_CfgEntry_Size"><label lang="en">size of MOD_CfgEntry_U64 data</label><label lang="de">Größe der MOD_CfgEntry_U64-Daten</label><USINT/><defaultValue value="1"/></parameter>….
<parameter uniqueID="UID_Index21xx_MOD_CfgEntry_Type2"
templateIDRef="UID_PT_Index21xx_MOD_CfgEntry_Type"><label lang="en">type of MOD_CfgEntry_U64</label><label lang="de">Typ des MOD_CfgEntry_U64</label><dataTypeIDRef uniqueIDRef="UID_DT_Nibble"/><defaultValue value="2"/></parameter>…
<dataTypeList><struct name="Nibble" uniqueID="UID_DT_Nibble"><varDeclaration name="VarNibble" uniqueID="UID_VarNibble" size="4"><label lang="de">4 Bit</label><label lang="en">4 bit</label><BITSTRING/></varDeclaration></struct></dataTypeList>…
<parameterGroup uniqueID="UID_PG1"><label lang="en">Group desc</label><parameterRef uniqueIDRef="UID_Index21xx_Sub64_RegNumber" bitOffset="0"/><parameterGroup uniqueID="UID_internal_group" bitOffset="16"><label lang="en">Group desc</label><parameterRef uniqueIDRef="UID_Index21xx_MOD_CfgEntry_Size1"/></parameterGroup><parameterRef uniqueIDRef="UID_Index21xx_MOD_CfgEntry_Type2" bitOffset="24"/></parameterGroup>…
…
<ObjectList><Object index="2100" name=”Object1" objectType="9"><SubObject subIndex="01" name="SubObj1" objectType="7" dataType="0001B"
accessType="rw" uniqueIDRef="UID_PG1"/></Object></ObjectList>…

Fig. 34.

Example XDD fragment

According to this sample XDD fragment, the actual 8 byte value of the object with index 0x2100,
subindex 0x01 is set to “0x0000000002010001”.