ISO 15745-4:2003/Amd 2:2007

INTERNATIONAL ISO
STANDARD 15745-4
First edition
2003-11-15
AMENDMENT 2
2007-02-01
Industrial automation systems and
integration — Open systems application
integration framework —
Part 4:
Reference description for Ethernet-based
control systems
AMENDMENT 2: Profiles for Modbus TCP,
EtherCAT and ETHERNET Powerlink
Systèmes d'automatisation industrielle et intégration — Cadres
d'intégration d'application pour les systèmes ouverts —
Partie 4: Description de référence pour les systèmes de contrôle fondés
sur Ethernet
AMENDEMENT 2: Profils pour Modbus TCP, EtherCAT et ETHERNET
Powerlink
Reference number
ISO 15745-4:2003/Amd.2:2007(E)
©
ISO 2007
ISO 15745-4:2003/Amd.2:2007(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2007
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2007 – All rights reserved

ISO 15745-4:2003/Amd.2:2007(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
Draft International Standards adopted by the technical committees are circulated to the member bodies
for voting. Publication as an International Standard requires approval by at least 75 % of the member bodies
casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
Amendment 2 to ISO 15745-4:2003 was prepared by Technical Committee ISO/TC 184, Industrial automation
systems and integration, Subcommittee SC 5, Architecture, communications and integration frameworks.
1) 2)
Amendment 2 to ISO 15745-4:2003 specifies profiles for Modbus TCP , EtherCAT , and ETHERNET
3)
Powerlink , and, as such, adds to the number of technology-specific elements and rules in ISO 15745-4 for
describing both communication network profiles and communication-related aspects of device profiles, thus
further extending the Application Integration Framework in ISO 15745-1.

1) Modbus® and Modbus TCP™ are the registered trademarks of Schneider Automation Inc. This information is given
for the convenience of users of ISO15745 and does not constitute an endorsement by ISO of the trademark holder or any
of its products. Compliance to ISO15745 does not require use of the trade name Modbus TCP or Modbus. Use of the
trademark Modbus TCP or Modbus requires permission of the trade name holder.
2) EtherCAT™ is the registered trademark of Beckhoff, Verl. This information is given for the convenience of users of
ISO15745 and does not constitute an endorsement by ISO/IEC of the trademark holder or any of its products. Compliance
to ISO15745 does not require use of the trade name EtherCAT™. Use of the trademark EtherCAT requires permission of
the trade name holder.
3) ETHERNET Powerlink™ is the registered trademark of ETHERNET Powerlink Standardization Group. This
information is given for the convenience of users of ISO15745 and does not constitute an endorsement by ISO/IEC of the
trademark holder or any of its products. Compliance to ISO15745 does not require use of the trade name ETHERNET
Powerlink™. Use of the trademark ETHERNET Powerlink requires permission of the trade name holder.
ISO 15745-4:2003/Amd.2:2007(E)

Industrial automation systems and integration — Open systems
application integration framework —
Part 4:
Reference description for Ethernet-based control systems
AMENDMENT 2: Profiles for Modbus TCP, EtherCAT and
ETHERNET Powerlink
Page 1, Clause 2
Add the following normative references:
"ISO 1000, SI units and recommendations for the use of their multiples and of certain other units
ISO 3166-1, Codes for the representation of names of countries and their subdivisions — Part 1: Country
codes
IEC/PAS 62030, Digital data communications for measurement and control - Fieldbus for use in industrial
control systems - Section 1: MODBUS® Application Protocol Specification V1.1a - Section 2: Real-Time
Publish-Subscribe (RTPS) Wire Protocol Specification Version 1.0
IEC/PAS 62407, Real-time Ethernet control automation technology (EtherCATTM)
IEC/PAS 62408, Real-time Ethernet Powerlink (EPL)
RFC 1157 SNMP, Simple Network Management Protocol (SNMP) Management Frameworks"
Page 2, Clause 4
Add the following abbreviated terms:
"DDXML Device Description eXtensible Markup Language
EPL ETHERNET Powerlink
FMMU Fieldbus Memory Management Unit
MIB Management Information Base
SNMP     Simple Network Management Protocol (RFC 1157)"
Page 4, Table 1
Add a row with the entries "DDXML" under the "ProfileTechnology name" column and "Modbus TCP" under
the "Technology" column.
ISO 15745-4:2003/Amd.2:2007(E)
Add a row with the entries "EtherCAT" under the "ProfileTechnology name" column and "EtherCAT" under the
"Technology" column.
Add a row with the entries "EPL" under the "ProfileTechnology name" column and "ETHERNET Powerlink"
under the "Technology" column.
Page 4, Subclause 5.3
Add the following items to the list in the first paragraph:
"— Modbus TCP (see 6.5)
— EtherCAT (see 6.6)
— ETHERNET Powerlink (see 6.7)".
Page 18
Insert the following new subclauses 6.5, 6.6 and 6.7 after subclause 6.4 inserted from Amendment 1 to
ISO 15745-4:2003, and before Annex A.
6.5 Modbus TCP
6.5.1 Device profile
6.5.1.1 General
Figure 20 shows the class structure of a Modbus TCP device profile.
DeviceProfile
0.1
DeviceIdentity
0.1
DeviceManager
1.*
DeviceFunction
0.*
ApplicationProcess
Figure 20 — Modbus TCP device profile class diagram
NOTE  The Modbus TCP device profile class diagram shown in Figure 20 defines the main classes. These classes are
further decomposed and detailed in Annex E.
The XML schemas representing the Modbus TCP device profile template are defined in E.4.6. The template is
based on two parts:
⎯ the DDXML profile header defined in E.3, and
⎯ the DDXML device profile defined in E.4.
6.5.1.2 Device identity
The DeviceIdentity class contains attributes that are independent of the network, of the process and uniquely
identify the device.
2 © ISO 2007 – All rights reserved

ISO 15745-4:2003/Amd.2:2007(E)
Figure 21 shows the structure of the Modbus TCP DeviceIdentity class.
DeviceIdentity
vendorName
0.1
vendorID
0.1
vendorText
0.1
deviceFamily
0.1
productFamily
productName
0.1
productID
0.1
productText
0.*
orderNumber
0.*
version
0.1
buildDate
0.1
specificationRevision
0.1
instanceName
Figure 21 — Modbus TCP DeviceIdentity class diagram
Further details are given in E.4.2.
6.5.1.3 Device manager
The DeviceManager class contains attributes and supports services that enable the monitoring of the device.
Communication specific configuration data and mapping information is defined in the communication network
specific part structured according to the schema specified in E.5.
Figure 22 shows the structure of the Modbus TCP DeviceManager class.
DeviceManager
0.1
indicatorList
0.1
LEDList
Figure 22 — Modbus TCP DeviceManager class diagram
ISO 15745-4:2003/Amd.2:2007(E)
Further details are given in E.4.3.
6.5.1.4 Device function
The DeviceFunction class describes the intrinsic function of a device in terms of its technology. It contains
network independent descriptions/definitions of the technological device functionality.
Figure 23 shows the structure of the Modbus TCP DeviceFunction class.
DeviceFunction
0.1
0.1
0.1
capabilities picturesList dictionaryList
0.1 0.1
0.1 1.*
standardComplianceList characteristicsList picture dictionary
1.*
0.1
1.* 1.*
file
compliantWith characteristic category
1.*
characteristicContent
characteristicName
g_labels
Figure 23 — Modbus TCP DeviceFunction class diagram
Further details are given in E.4.4.
6.5.1.5 Application process
The ApplicationProcess class represents the set of services and parameters, which constitute the behaviour,
and the interfaces of the device in terms of the application, independent of the device technology and the
underlying communication networks and communication protocols.
Figure 24 shows the structure of the Modbus TCP ApplicationProcess class.
4 © ISO 2007 – All rights reserved

ISO 15745-4:2003/Amd.2:2007(E)
ApplicationProcess
0.1
dataTypeList
functionTypeList
functionInstanceList
parameterList
0.1
parameterGroupList
Figure 24 — Modbus TCP ApplicationProcess class diagram
Further details are given in E.4.5.
6.5.2 Communication network profile
6.5.2.1 General
Figure 25 shows the class structure of the Modbus TCP communication network profile. These classes are
further decomposed and detailed in Annex E.
CommNetworkProfile
0.1 1
NetworkManagement TransportLayers ApplicationLayers

Figure 25 — Modbus TCP communication network profile class diagram
The XML schemas representing the Modbus TCP communication network profile template are defined in
E.5.5. Like for the device profile, the template is also based on two parts:
⎯ the DDXML profile header defined in E.3, and
⎯ the DDXML communication network profile defined in E.5.
6.5.2.2 Application layers
The Modbus TCP ApplicationLayers class represents the combined profiles for the upper 3 OSI layers of the
Modbus TCP communication network integration model.
Further details are given in E.5.2.
6.5.2.3 Transport layers
The Modbus TCP TransportLayers class represents the combined profiles for the lower 4 OSI layers of the
Modbus TCP communication network integration model.
Further details are given in E.5.3.
ISO 15745-4:2003/Amd.2:2007(E)
6.5.2.4 Network management
The Modbus TCP NetworkManagement class represents the network configuration and performance
adjustment capabilities of the Modbus TCP communication network integration model.
Further details are given in E.5.4.

6.6 EtherCAT
6.6.1 Device profile
6.6.1.1 General
Figure 26 shows the class structure of an EtherCAT device profile.
DeviceProfile
0.1
DeviceIdentity
0.1
DeviceManager
1.*
DeviceFunction
0.*
ApplicationProcess
Figure 26 — EtherCAT device profile class diagram
NOTE  The EtherCAT device profile class diagram shown in Figure 26 defines the main classes. These classes are
further decomposed and detailed in Annex F.
The XML schema representing the EtherCAT device profile template is defined in F.4.6. The template is
based on two parts:
⎯ the EtherCAT profile header defined in F.3, and
⎯ the EtherCAT device profile defined in F.4.
6.6.1.2 Device identity
The DeviceIdentity class contains attributes that are independent of the network, of the process and uniquely
identify the device.
Figure 27 shows the structure of the EtherCAT DeviceIdentity class.
6 © ISO 2007 – All rights reserved

ISO 15745-4:2003/Amd.2:2007(E)
DeviceIdentity
vendorName
0.1
vendorID
0.1
vendorText
0.1
deviceFamily
0.1
productFamily
productName
0.1
productID
0.1
productText
0.*
orderNumber
0.*
version
0.1
buildDate
0.1
specificationRevision
0.1
instanceName
Figure 27 — EtherCAT DeviceIdentity class diagram
Further details are given in F.4.2.
6.6.1.3 Device manager
The DeviceManager class contains attributes and supports services that enable the monitoring of the device.
Communication specific configuration data and mapping information is defined in the communication network
specific part structured according to the schema specified in F.5.
Figure 28 shows the structure of the EtherCAT DeviceManager class.
DeviceManager
0.1
indicatorList
0.1
LEDList
Figure 28 — EtherCAT DeviceManager class diagram
Further details are given in F.4.3.
ISO 15745-4:2003/Amd.2:2007(E)
6.6.1.4 Device function
The DeviceFunction class describes the intrinsic function of a device in terms of its technology. It contains
network independent descriptions/definitions of the technological device functionality.
Figure 29 shows the structure of the EtherCAT DeviceFunction class.
DeviceFunction
capabilities
1.*
characteristicsList
0.1
category
1.*
characteristic
characteristicName
1.*
characteristicContent
0.1
standardComplianceList
1.*
compliantWith
0.1
picturesList
1.*
picture
0.1 1
dictionaryList
g_labels
1.*
dictionary
1.*
file
Figure 29 — EtherCAT DeviceFunction class diagram
Further details are given in F.4.4.
6.6.1.5 Application process
The ApplicationProcess class represents the set of services and parameters, which constitute the behaviour,
and the interfaces of the device in terms of the application, independent of the device technology and the
underlying communication networks and communication protocols.
Figure 30 shows the structure of the EtherCAT ApplicationProcess class.
8 © ISO 2007 – All rights reserved

ISO 15745-4:2003/Amd.2:2007(E)
ApplicationProcess
0.1
dataTypeList
functionTypeList
functionInstanceList
parameterList
0.1
parameterGroupList
Figure 30 — EtherCAT ApplicationProcess class diagram

Further details are given in F.4.5.
6.6.2 Communication network profile
6.6.2.1 General
Figure 31 shows the class structure of the EtherCAT communication network profile. These classes are
further decomposed and detailed in Annex F.
ISO 15745-4:2003/Amd.2:2007(E)
CommNetworkProfile
ApplicationLayers
CANopenObjectList
CANopenObject
1.65535
CANopenSubObject
0.255
identity
0.1
vendorID
0.1
deviceFamily
0.1
productID
0.1
version
0.1
buildDate
0.1
specificationRevision
0.1
dummyUsage
0.1
dummy
1.*
dynamicChannels
dynamicChannel
1.*
g_simple
TransportLayers
0.1
NetworkManagement
generalFeatures
deviceCommissioning
0.1
Figure 31 — EtherCAT communication network profile class diagram

The XML schema representing the EtherCAT communication network profile is defined in F.5.5.
6.6.2.2 Application layers
The EtherCAT ApplicationLayers class represents the combined profiles for the upper 3 OSI layers of the
EtherCAT communication network integration model.
Further details are given in F.5.2.
6.6.2.3 Transport layers
The EtherCAT TransportLayers class represents the combined profiles for the lower 4 OSI layers of the
EtherCAT communication network integration model.
Further details are given in F.5.3.
10 © ISO 2007 – All rights reserved

ISO 15745-4:2003/Amd.2:2007(E)
6.6.2.4 Network management
The EtherCAT NetworkManagement class represents the network configuration and performance adjustment
capabilities of the EtherCAT communication network integration model.
Further details are given in F.5.4.

6.7 ETHERNET Powerlink
6.7.1 Device profile
6.7.1.1 General
Figure 32 shows the class structure of an ETHERNET Powerlink device profile.
DeviceProfile
0.1
DeviceIdentity
0.1
DeviceManager
1.*
DeviceFunction
0.*
ApplicationProcess
Figure 32 — ETHERNET Powerlink device profile class diagram
NOTE  The ETHERNET Powerlink device profile class diagram shown in Figure 32 defines the main classes. These
classes are further decomposed and detailed in Annex G.
The XML schema representing the ETHERNET Powerlink device profile template is defined in G.4.6. The
template is based on two parts:
⎯ the EPL profile header defined in G.3, and
⎯ the EPL device profile defined in G.4.
6.7.1.2 Device identity
The DeviceIdentity class contains attributes that are independent of the network, of the process and uniquely
identify the device.
Figure 33 shows the structure of the ETHERNET Powerlink DeviceIdentity class.

ISO 15745-4:2003/Amd.2:2007(E)
DeviceIdentity
vendorName
0.1
vendorID
0.1
vendorText
0.1
deviceFamily
0.1
productFamily
productName
0.1
productID
0.1
productText
0.*
orderNumber
0.*
version
0.1
buildDate
0.1
specificationRevision
0.1
instanceName
Figure 33 — ETHERNET Powerlink DeviceIdentity class diagram
Further details are given in G.4.2.
6.7.1.3 Device manager
The DeviceManager class contains attributes and supports services that enable the monitoring of the device.
Communication specific configuration data and mapping information is defined in the communication network
specific part structured according to the schema specified in G.5.
Figure 34 shows the structure of the ETHERNET Powerlink DeviceManager class.
DeviceManager
0.1
indicatorList
0.1
LEDList
Figure 34 — ETHERNET Powerlink DeviceManager class diagram
Further details are given in G.4.3.
12 © ISO 2007 – All rights reserved

ISO 15745-4:2003/Amd.2:2007(E)
6.7.1.4 Device function
The DeviceFunction class describes the intrinsic function of a device in terms of its technology. It contains
network independent descriptions/definitions of the technological device functionality.
Figure 35 shows the structure of the ETHERNET Powerlink DeviceFunction class.
DeviceFunction
capabilities
1.*
characteristicsList
0.1
category
1.*
characteristic
characteristicName
1.*
characteristicContent
0.1
standardComplianceList
1.*
compliantWith
0.1
picturesList
1.*
picture
0.1 1
dictionaryList
g_labels
1.*
dictionary
1.*
file
Figure 35 — ETHERNET Powerlink DeviceFunction class diagram
Further details are given in G.4.4.
6.7.1.5 Application process
The ApplicationProcess class represents the set of services and parameters, which constitute the behaviour,
and the interfaces of the device in terms of the application, independent of the device technology and the
underlying communication networks and communication protocols.
Figure 36 shows the structure of the ETHERNET Powerlink ApplicationProcess class.
ISO 15745-4:2003/Amd.2:2007(E)
ApplicationProcess
0.1
dataTypeList
functionTypeList
functionInstanceList
parameterList
0.1
parameterGroupList
Figure 36 — ETHERNET Powerlink ApplicationProcess class diagram
Further details are given in G.4.5.
6.7.2 Communication network profile
6.7.2.1 General
Figure 37 shows the class structure of the ETHERNET Powerlink communication network profile. These
classes are further decomposed and detailed in Annex G.
14 © ISO 2007 – All rights reserved

ISO 15745-4:2003/Amd.2:2007(E)
CommNetworkProfile
ApplicationLayers
CANopenObjectList
CANopenObject
1.65535
CANopenSubObject
0.255
identity
0.1
vendorID
0.1
deviceFamily
0.1
productID
0.1
version
0.1
buildDate
0.1
specificationRevision
0.1
dummyUsage
0.1
dummy
1.*
dynamicChannels
dynamicChannel
1.*
g_simple
TransportLayers
0.1
NetworkManagement
PowerlinkGeneralFeatures
PowerlinkMNFeatures
0.1
PowerlinkCNFeatures
0.1
deviceCommissioning
0.1
Figure 37 — ETHERNET Powerlink communication network profile class diagram

The XML schema representing the ETHERNET Powerlink communication network profile is defined in G.5.5.
6.7.2.2 Application layers
The ETHERNET Powerlink ApplicationLayers class represents the combined profiles for the upper 3 OSI
layers of the ETHERNET Powerlink communication network integration model.
Further details are given in G.5.2.
6.7.2.3 Transport layers
The ETHERNET Powerlink TransportLayers class represents the combined profiles for the lower 4 OSI layers
of the ETHERNET Powerlink communication network integration model.
ISO 15745-4:2003/Amd.2:2007(E)
Further details are given in G.5.3.
6.7.2.4 Network management
The ETHERNET Powerlink NetworkManagement class represents the network configuration and performance
adjustment capabilities of the ETHERNET Powerlink communication network integration model.
Further details are given in G.5.4.

16 © ISO 2007 – All rights reserved

ISO 15745-4:2003/Amd.2:2007(E)
Page 125
Insert the following new Annex E, Annex F and Annex G after Annex D inserted from Amendment 1 to
ISO 15745-4:2003, and before the Bibliography.
Annex E
(normative)
Modbus TCP profile templates
E.1 Overview
Modbus TCP is an Ethernet based communication system specified in IEC/PAS 62030.
Modbus TCP uses the concept of the multi-profile container specified in Amendment 1
to ISO 15745-4:2003 for XML profile files. Therefore, Modbus TCP profile templates are based
6)
on the alternate ISO15745ProfileContainer template specified in amendment 1 of ISO 15745-1.
Figure E.1 shows the structure of a Modbus TCP XML profile.
ISO15745ProfileContainer
1.*
ISO15745Profile
a
ProfileHeader
ProfileBody
Two types of ProfileBody are used:
ProfileBody_Device_ModbusTCP or ProfileBody_CommunicationNetwork_ModbusTCP
a
Figure E.1 — Modbus TCP profile template
The ProfileTechnology name is DDXML (Device Description eXtensible Markup Language).
E.2 General rules
E.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.
Unique identifiers may be generated in two ways. One possibility is to build a string out of the element name
and an up-counting number. A second way may be the concatenation of strings of parent elements. Both
methods guarantee the uniqueness of the string.
ISO 15745-4:2003/Amd.2:2007(E)
E.2.2 Language support
E.2.2.1 General
Device profiles complying with the XML schema described in this annex 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 user interface.
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 a g_labels
element. Optionally, a URI may be added as an attribute to the label element.
EXAMPLE
For a given parameter name:
⎯ German: Baudrate
⎯ English: Baud rate
⎯ French: Vitesse de transmission
E.2.2.2 Element g_labels
The group g_labels supports the introduction of a label (name) and a description in the context of the parent
element (see Figure E.2).
g_labels
{XOR}
{XOR} {XOR}
label labelRef
description
Figure E.2 — Group g_labels
Every element, which needs a name or a description, shall select one and only one of the three elements to
perform this task: the label, the description and the labelRef 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 Table E.1.
Table E.1 — Attributes of element label
Attribute Data type Use Description
lang xsd:language required Language used for the name or the description
URI xsd:anyURI optional Optional link to further descriptive information
The element may appear n times, once for each language. For identifying the language, the lang
attribute is used.
18 © ISO 2007 – All rights reserved

ISO 15745-4:2003/Amd.2:2007(E)
2) The description element allows storage of textual descriptions inside the XML file itself. The element
may appear several times, once for each language. The description element has the same attributes
as the label element.
3) The labelRef element allows storage of reference descriptive texts inside an external text resource
file.
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 the
DeviceFunction element. Text source files may be any files containing character sequences and
other information, for example figures.
The labelRef element also may appear n times, to allow references to several dictionary entries,
which contain links to files in different languages. The respective language is defined in the lang
attribute of the dictionary element.
The labelRef element contains the attributes given in Table E.2.
Table E.2 — Attributes of element labelRef
Attribute Data type Use Description
dictID xsd:IDREF required References a single dictionary element inside the
dictionaryList element; the dictionary element
contains a link to the external text source file
textID xsd:string optional References a character sequence inside the
external text source file by pattern matching

E.2.2.3 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.
E.2.2.4 Attribute lang
The language identifier lang consists of a combination of a language code (as defined in ISO 639-1) plus an
optional dash character plus an optional country code (as defined in ISO 3166-1). The attribute lang is an
attribute of the label element.
Some of the values for lang are given in Table E.3.
ISO 15745-4:2003/Amd.2:2007(E)
Table E.3 — Values of attribute lang
Language value of lang
English (United States) en-us
German (Standard) de
French (Standard) fr
Spanish (Standard) es
Italian (Standard) It
Portuguese (Brazil) pt-br
E.2.2.5 SupportedLanguages attribute
The supportedLanguages attribute identifies supported languages and consists of a list of language codes
plus optional country codes.
EXAMPLE
supportedLanguages=”en-us de fr es”
E.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.
EXAMPLE: This is used in the context of a vendor label, parameter label, or services label.
E.3 ProfileHeader description
To facilitate the identification of a profile, the profile header of the device profile as well as the communication
network profile shall comply with the model shown in Figure E.3, which is directly inherited from ISO 15745-1.
ProfileHeader
ProfileIdentification ProfileDate
1 0.1
ProfileRevision AdditionalInformation
1 0.1
ProfileName ISO15745Reference
ProfileSource IASInterfaceType
1 0.*
ProfileClassID
Figure E.3 — Profile header class diagram
The ProfileHeader element is composed of the following elements:
⎯ the ProfileIdentification element identifies the current profile,
⎯ the ProfileRevision element identifies the current profile revision,
20 © ISO 2007 – All rights reserved

ISO 15745-4:2003/Amd.2:2007(E)
⎯ 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 the value 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.
E.4 Device profile template description
E.4.1 ProfileBody_Device_ModbusTCP
This part defines the Modbus TCP device profile.
The ProfileBody_Device_ModbusTCP contains the DeviceIdentity, the DeviceManager, the DeviceFunction
and the ApplicationProcess elements shown in Figure 20.
The ProfileBody element contains the description of
⎯ a single device (for example a proximity sensor or an electromechanical limit switch), or of a more
complex one (for example a circuit breaker with up to 2500 parameters, more than 100 functions), or
⎯ a part of a device also called "module" in the PLC world (for example a part of an I/O controller or an
electrical protection unit).
The ProfileBody element contains the attributes given in Table E.4.
Table E.4 — Attributes of element ProfileBody
Attribute Data type Use Description
formatName xsd:string fixed Format identifier
formatVersion xsd:string fixed Format version identifier
fileName xsd:string required Name of the file with extension without path
fileCreator xsd:string required Person creating the file
fileCreationDate xsd:date required 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

ISO 15745-4:2003/Amd.2:2007(E)
E.4.2 DeviceIdentity
E.4.2.1 General
The DeviceIdentity class (see Figure 21) contains elements, which are independent of the network and of the
process. It describes the identity of a single device or of a group of devices.
Table E.5 specifies the attribute readOnly, which is attached to the vendorName, vendorID, vendorText,
deviceFamily, productFamily, productName, productID, productText, orderNumber, version,
specificationRevision, and instanceName elements.
Table E.5 — Attribute of element vendorName
Attribute Data type Use Description
readOnly xsd:boolean default Indicates whether the value is read-only for a user:
false, true (default)
E.4.2.2 Element vendorName
The vendorName element identifies the name or the brand name of the vendor of the device.
E.4.2.3 Element vendorID
The vendorID element identifies the vendor. This information has to be filled in when the product described is
recognized and validated by a consortium.
NOTE  Consortia specific product families and vendor identifiers are linked.
E.4.2.4 Element 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 the vendorText element.
E.4.2.5 Element deviceFamily
The deviceFamily element states the family of the device.
EXAMPLE
Examples for device families are:
⎯ Variable speed drive
⎯ Circuit breaker
⎯ Pressure sensor
E.4.2.6 Element productFamily
The productFamily element states a vendor specific affiliation of the device type to a certain set of devices
inside a family. The list of valid productFamily values is system, tool or consortia specific.
NOTE  Consortia specific product families and vendor identifiers are linked.
22 © ISO 2007 – All rights reserved

ISO 15745-4:2003/Amd.2:2007(E)
E.4.2.7 Element productName
The productName element states a vendor specific designation or name of the device type.
E.4.2.8 Element productID
The productID element states a vendor specific unique identification for the device type described.
E.4.2.9 Element productText
The productText element allows the vendor to provide a short textual description of the device type.
E.4.2.10 Element orderNumber
The orderNumber element is used to store the single order number of a given product or the set of different
order numbers of the products of a product family, depending upon whether the device profile describes a
product or a product family.
E.4.2.11 Element version
The version element is used to store different types of version information. Multiple version elements are
possible.
The version element has the attributes given in Table E.6.
Table E.6 — Attributes of element version
Attribute Data type Use Description
versionType xsd:NMTOKEN required Type of version:
— SW – Software
— FW – Firmware
— HW – Hardware
readOnly xsd:boolean default Indicates whether the value is read-only for a user:
false, true (default)
E.4.2.12 Element buildDate
The buildDate element specifies the build date of the software unit.
E.4.2.13 Element specificationRevision
The specificationRevision element contains the revision of the specification, to which this device conforms.
E.4.2.14 Element instanceName
This element contains the instance name of the device.

ISO 15745-4:2003/Amd.2:2007(E)
E.4.3 DeviceManager
E.4.3.1 General
The DeviceManager element defines the list of indicators provided by the device type, if any.
E.4.3.2 Elements indicatorList / LEDList
E.4.3.2.1 General
Figure E.4 specifies the number and type of indicators, which are provided by a device type.
indicatorList
0.1
LEDList
0.* 1.*
combinedState LED
1.* 1.*
LEDstateRef LEDState
1 1 1
g_labels
Figure E.4 — indicatorList / LEDList
E.4.3.2.2 LED
The LED element describes the features of a single LED of the device type. A detailed feature description may
be provided through the g_labels group.
Further properties of the LED are represented as attributes of the LED element given in Table E.7.
Table E.7 — Attributes of element LED
Attribute Data type Use Description
LEDcolors xsd:string required Colours of the LED; valid values are monocolor and
bicolor
LEDtype xsd:string optional Rough classification of the supervised item or
functionality; valid values are IO, device and
communication
In addition to the descriptive parts introduced above, the LED element contains one to many LEDstate
elements, which define the device states signalled by the LED and the visual behaviour used for signalling the
states.
The visual behaviour used for signalling the state is encoded as attribute values of the LEDstate element, as
given in Table E.8. Additionally a unique ID is allocated for the LED state.
24 © ISO 2007 – All rights reserved

ISO 15745-4:2003/Amd.2:2007(E)
Table E.8 — Attributes of element LEDstate
Attribute Data type Use Description
uniqueID xsd:ID required Unique ID for the LED state; may be referenced
from an LEDstateRef element
state xsd:string required State of the LED; possible attribute values:
On, off, flashing
LEDcolor xsd:string required Colour of the LED state; valid values: green, amber,
red
flashingPeriod xsd:unsignedInt optional If state is flashing: flashing period of the LED in
milliseconds
impulsWidth xsd:unsignedByte default Width of the flashing impulse given in percent (%)
of the flashing period; if the attribute impulsWidth is
missing, the default value is 50 (%)
numberOfImpulses xsd:unsignedByte default 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 the attribute numberOfImpulses is
missing, the default value is 1

E.4.3.2.3 Element combinedState
The combinedState element allows the indication of device states which are signaled 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 at least 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 Table E.9).
Table E.9 — Attributes of element LEDstateRef
Attribute Data type Use Description
stateIDRef xsd:IDREF required Unique ID of the referenced LEDstate element

E.4.4 DeviceFunction
E.4.4.1 General
The DeviceFunction element shown in Figure 23 defines the catalogue view of the device, presented as a set
of capabilities listing both device characteristics and compliance with various standards.
E.4.4.2 Element capabilities
E.4.4.2.1 General
The mandatory capabilities element describes all functionalities, their characteristics, and the important
parameters of the device, that need to be known by tools which use the device profile to select products 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.
ISO 15745-4:2003/Amd.2:2007(E)
E.4.4.2.2 Element characteristicsList
E.4.4.2.2.1 General
The 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-element of the
characteristicsList element.
E.4.4.2.2.2 Element characteristic
The characteristic element describes a single characteristic of a device. It contains a mandatory
characteristicName element and one to many characteristicContent elements.
E.4.4.2.2.3 Element characteristicName
The mandatory characteristicName element denotes a major technical characteristic of the device. The
vocabulary used in the product data sheet is recommended for the names of characteristics.
EXAMPLE
"Maximum operational voltage", "Overload protection", "Electrical durability".
E.4.4.2.2.4 Element characteristicContent
This mandatory element contains a value for the characteristic. Multiple values may be expressed by using
multiple characteristicContent elements.
EXAMPLE
An example of a single value for "Maximum operational voltage" is 680V.
E.4.4.2.3 Element 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 an international
or company internal standard. The content of type g_labels of this element may contain remarks concerning
that standard.
The name or number of the standard is provided through the required name attribute of the compliantWith
element. The second, default valued range attribute of the compliantWith element defines the range of
applicability of the standard as given in Table E.10.
Table E.10 — Attributes of element compliantWith
Attribute Data type Use Description
name xsd:string required Name or number of the standard
range xsd:NMTOKEN default The two possible enumerated values of the attribute
are international (default) or internal

E.4.4.3 Element picturesList
The picturesList element offers the possibility to link pictures to the device profile. It contains one to many
picture sub-elements, whose caption is provided via a g_labels sub-element.
26 © ISO 2007 – All rights reserved

ISO 15745-4:2003/Amd.2:2007(E)
Table E.11 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.
Table E.11 — Attributes of element picture
Attribute Data type Use Description
URI xsd:anyURI required Link to the external resource
number xsd:unsignedInt optional Number of the picture

E.4.4.4 Element dictionaryList
The optional dictionaryList element offers the possibility to include links to external text source files to the
device profile. It contains one to many dictionary elements, where each one contains one to many file sub-
elements. Several files are necessary if different file formats are needed within a dictionary.
A mandatory lang attribute of type xsd:language defines the language used in the files which are linked to the
dictionary element (see Table E.12). A mandatory uniqueID attribute of type xsd:ID holds the unique
identification of the dictionary entry which is referenced from the attribute dictID of a labelRef element as given
in Table E.2.
Table E.12 — Attributes of element dictionary
Attribute Data type Use Description
lang xsd:language required Language used for files belonging to a dictionary
entry
uniqueID xsd:ID required Unique ID of the dictionary entry

A file sub-element contains a single mandatory attribute given in Table E.13.
Table E.13 — Attributes of element file
Attribute Data type Use Description
URI xsd:anyURI required Link to the respective file

E.4.5 ApplicationProcess
E.4.5.1 General
The ApplicationProcess element represents the set of services and parameters which constitute the behavior
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 Figure 24 provide a generic approach for the
description of arbitrary, flat or hierarchically structured functions of a device.
Functions are modeled as function types, which are instantiated within the device or - if hierarchical structures
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 by building a reference from the
parameter to the respective interface variable of the function instance, in flat as well as in hierarchical
structures.
...