ISO 15745-2:2003

INTERNATIONAL ISO
STANDARD 15745-2
First edition
2003-11-15
Industrial automation systems and
integration — Open systems application
integration framework —
Part 2:
Reference description for
ISO 11898-based control systems
Systèmes d'automatisation industrielle et intégration — Cadres
d'intégration d'application pour les systèmes ouverts —
Partie 2: Description de référence pour les systèmes de contrôle fondés
sur l'ISO 11898
Reference number
©
ISO 2003
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 2003
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 2003 — All rights reserved

Contents Page
Foreword .iv
Introduction.v
1 Scope.1
2 Normative references.1
3 Terms and definitions.2
4 Abbreviated terms.2
5 Technology specific elements and rules .3
5.1 Integration models and IAS interfaces.3
5.2 Profile templates.3
5.2.1 General.3
5.2.2 Contents and syntax.3
5.2.3 Header.3
5.3 Technology specific profiles.4
6 Device and communication network profiles for ISO 11898-based control systems .4
6.1 DeviceNet.4
6.1.1 Device profile.4
6.1.2 Communication network profile.6
6.2 CANopen.7
6.2.1 Device profile.7
6.2.2 Communication network profile.15
Annex A (normative) DeviceNet profile templates.17
A.1 General.17
A.2 Device profile template description.18
A.2.1 Device profile template description – XML based .18
A.2.2 Device profile template description – XML encapsulation of EDS files.35
A.3 Communication network profile template description.37
A.3.1 Communication network profile template description – XML based .37
A.3.2 Communication network profile template description – XML encapsulation of EDS files.51
A.4 Electronic Data Sheet (EDS).53
A.4.1 Common CIP EDS requirements.53
A.4.2 DeviceNet specific EDS requirements.85
Annex B (normative) CANopen profile templates.98
B.1 Device profile template description.98
B.1.1 General.98
B.1.2 Basics.98
B.1.3 DeviceManager object.100
B.1.4 Supplementary element descriptions.103
B.1.5 Device profile template XML schemas .105
B.2 Communication network profile template description.153
Bibliography.163

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.
The main task of technical committees is to prepare International Standards. 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.
ISO 15745-2 was prepared by Technical Committee ISO/TC 184, Industrial automation systems and integration,
Subcommittee SC 5, Architecture, communications and integration frameworks.
ISO 15745 consists of the following parts, under the general title Industrial automation systems and integration — Open
systems application integration framework:
— Part 1: Generic reference description
— Part 2: Reference description for ISO 11898-based control systems
— Part 3: Reference description for IEC 61158-based control systems
— Part 4: Reference description for Ethernet-based control systems
iv © ISO 2003 — All rights reserved

Introduction
The application integration framework (AIF) described in ISO 15745 defines elements and rules that facilitate:

 the systematic organization and representation of the application integration requirements using integration
models;
 the development of interface specifications in the form of application interoperability profiles (AIPs) that enable
both the selection of suitable resources and the documentation of the "as built" application.
ISO 15745-1 defines the generic elements and rules for describing integration models and AIPs, together with their
component profiles - process profiles, information exchange profiles, and resource profiles. The context of
ISO 15745 and a structural overview of the constituents of an AIP are given in Figure 1 of ISO 15745-1:2003.
This part of ISO 15745 extends the generic AIF described in ISO 15745-1 by defining the technology specific
elements and rules for describing both communication network profiles and the communication related aspects of
1 2
device profiles specific to ISO 11898-based control systems (DeviceNet , CANopen ).
In particular, this part of ISO 15745 describes technology specific profile templates for the device profile and the
communication network profile. Within an AIP, a device profile instance or a communication network profile
instance is part of the resource profile defined in ISO 15745-1. The device profile and the communication network
profile XML instance files are included in a resource profile XML instance using the ProfileHandle_DataType as
specified in ISO 15745-1:2003, 7.2.5.
AIFs specified using the elements and rules of ISO 15745-1 can be easily integrated with the component profiles
defined using the elements and rules specified in this part.

TM
1) DeviceNet is a trade name of Open DeviceNet Vendor Association, Inc. This information is given for the convenience of
users of ISO 15745 and does not constitute an endorsement by ISO of the trademark holder or any of its products. Compliance
TM TM
to this standard does not require use of the trade name DeviceNet . Use of the trade name DeviceNet requires permission of
the Open DeviceNet Vendor Association, Inc.
2) CANopen is a trade name used to describe EN 50325-4. This information is given for the convenience of users of ISO
15745 and does not constitute an endorsement by ISO of the trademark, or any related products. Compliance to this standard
does not require use of the trade name CANopen.
INTERNATIONAL STANDARD ISO 15745-2:2003(E)

Industrial automation systems and integration — Open systems
application integration framework —
Part 2:
Reference description for ISO 11898-based control systems
1 Scope
This part of ISO 15745 defines the technology specific elements and rules for describing both communication
network profiles and the communication related aspects of device profiles specific to ISO 11898-based control
systems.
NOTE Generic elements and rules for describing integration models and application interoperability profiles, together with
their component profiles (process profiles, information exchange profiles, and resource profiles) are specified in
ISO 15745-1.
This part of ISO 15745 is to be used in conjunction with ISO 15745-1 to describe an application integration
framework.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated references,
only the edition cited applies. For undated references, the latest edition of the referenced document (including any
amendments) applies.
ISO 639-1:2002, Codes for the representation of names of languages – Part 1: Alpha-2 code
ISO 639-2:1998, Codes for the representation of names of languages – Part 2: Alpha-3 code
ISO 3166-1:1997, Codes for the representation of names of countries and their subdivisions – Part 1: Country
codes
ISO/IEC 10646-1:2000, Information technology – Universal Multiple-Octet Coded Character Set (UCS) – Part 1:
Architecture and Basic Multilingual Plane
ISO 11898:1993, Road Vehicles – Interchange of digital information – Controller area network (CAN) for high-speed
communication
ISO 15745-1:2003, Industrial automation and systems integration – Open systems application integration
framework – Part 1 : Generic reference description
IEC 61158 (all parts), Digital data communications for measurement and control – Fieldbus for use in industrial
control systems
IEC 61784-1:2003, Digital data communications for measurement and control – Part 1: Profile sets for continuous
and discrete manufacturing relative to fieldbus use in industrial control systems
IEC 62026-3:2000, Low-voltage switchgear and controlgear – Controller-device interfaces (CDIs) – Part 3:
TM
DeviceNet
EN 50325-4 : 2002, Industrial communications subsystem based on ISO 11898 (CAN) for controller-device
interfaces – Part 4 : CANopen
IEEE Std 754-1985 (R1990), IEEE Standard for Binary Floating-Point Arithmetic
REC-xml-20001006, Extensible Markup Language (XML) 1.0 Second Edition – W3C Recommendation 6 October
REC-xmlschema-1-20010502, XML Schema Part 1: Structures – W3C Recommendation 02 May 2001
REC-xmlschema-2-20010502, XML Schema Part 2: Datatypes – W3C Recommendation 02 May 2001
RFC 1738:1994, Uniform Resource Locators (URL) – Internet Engineering Task Force (IETF), Request for
Comments (RFC)
RFC 1759:1995, Printer MIB – Internet Engineering Task Force (IETF), Request for Comments (RFC)
UML V1.4, OMG - Unified Modeling Language Specification (Version 1.4, September 2001)
3 Terms and definitions
NOTE The UML terminology and notation used in this document is described in Annex A of ISO 15745-1:2003.
For the purposes of this document, the terms and definitions given in ISO 15745-1 apply.
4 Abbreviated terms
AIF Application Integration Framework
AIP Application Interoperability Profile
CAN Controller Area Network
CIP™ Common Industrial Protocol
EDS Electronic Data Sheet
IAS Industrial Automation Systems
OSI Open System Interconnection
UML Unified Modelling Language (see UML V1.4)
XML eXtensible Markup Language (see REC-xml-20001006)

CIP™ is a trade name of ControlNet International, Ltd. and Open DeviceNet Vendor Association, Inc. This information is given
for the convenience of users of ISO 15745 and does not constitute an endorsement by ISO of the trademark holder or any of its
products. Compliance to this standard does not require use of the trade name CIP™. Use of the trade name CIP™ requires
permission of either ControlNet International, Ltd. or Open DeviceNet Vendor Association, Inc

2 © ISO 2003 – All rights reserved

5 Technology specific elements and rules
5.1 Integration models and IAS interfaces
The AIP developer shall develop the integration model using the rules described in ISO 15745-1, and shall ensure
that the ISO 11898-based device and communication network profiles (whether representing the interface
requirements or those derived from existing devices/communication networks) include the necessary IAS
interfaces. The IAS interfaces included in the profile shall be identified in the header section (see ISO 15745-
1:2003, 7.2.2).
NOTE IAS interfaces are described in ISO 15745-1:2003, Annex B.
5.2 Profile templates
5.2.1 General
The ISO 11898-based technology specific profile templates are derived from the generic profile templates specified
in ISO 15745-1:2003, clause 7.
5.2.2 Contents and syntax
ISO 15745 specifies profile templates that are XML schemas (REC-xmlschema-1-20010502 and REC-xmlschema-
2-20010502) and use a common general structure. The device and communication network profiles based on these
templates typically contain:
 information needed to identify the connected device;
 a description of device data that can be accessed via the network;
 a description of the communication capabilities supported by the device;
 additional vendor-specific information.
However, some ISO 11898-based technologies use specific legacy ASCII syntax. Hence, for backward
compatibility, template definitions of any technology ( Annex A to Annex B) include all or a relevant subset of the
following:
 communication network and device profile templates, as defined in ISO 15745-1;
 ISO 15745 template to encapsulate files with legacy ASCII syntax ("wrapper");
 legacy ASCII syntax.
5.2.3 Header
The profile template header defined in ISO 15745-1:2003, 7.2.2, is used for ISO 11898 technology specific profile
templates. Each technology uses one or more names to identify the technology or its particular component(s) (see
Table 1). The selected name shall be stored in the ProfileTechnology attribute in the header section.
Table 1 — ProfileTechnology names
ProfileTechnology name Technology
DeviceNet DeviceNet
CIP DeviceNet
EDS DeviceNet
CANopen CANopen
COFDCML CANopen
5.3 Technology specific profiles
The technology specific communication network profile structure and communication related aspects of device
profile structure based on ISO 11898-based technologies are described in clause 6. The technologies included are:
 DeviceNet (see 6.1);
 CANopen (see 6.2).
The related profile template definitions are specified in Annex A and Annex B.
6 Device and communication network profiles for ISO 11898-based control systems
6.1 DeviceNet
6.1.1 Device profile
6.1.1.1 General
Figure 1 shows the class structure of the DeviceNet device profile.
DeviceProfile
DeviceIdentity
ApplicationProcess
0.*
DeviceManager
0.1
Assembly
0.*
Parameter
DeviceFunction
1.* 0.*
ParameterGroup
0.*
Figure 1 — DeviceNet device profile class diagram
The available formats for DeviceNet device profiles are described in A.2.
The XML schema representing the DeviceNet device profile template is defined in A.2.1.3.3. The file name of this
XML schema shall be “CIP_Device_Profile.xsd”.
NOTE The DeviceNet device profile class diagram shown in Figure 1 defines the main classes. These classes are further
decomposed ; details are defined in Annex A.
4 © ISO 2003 – All rights reserved

The XML schema representing the encapsulation of a legacy DeviceNet EDS into the ISO 15745 device profile
template is defined in A.2.2.2. The file name of this XML schema shall be “EDS_Device_Profile_wrapper.xsd”. The
legacy EDS ASCII syntax itself is described in A.4.
6.1.1.2 Device identity
The DeviceIdentity class contains attributes which uniquely identify the device, and supports services which allow
the retrieval of this information from the device.
These attributes provide in particular:
 manufacturer's identification (name and identification code);
 device identification (device type, product name, revision, serial number);
 device classification;
 location of storage of additional information (e.g. icons).
6.1.1.3 Device manager
The DeviceManager class contains attributes and supports services used to monitor and configure the device.
These attributes provide in particular:
 revision of the DeviceNet identity object;
 information on device structure (for devices integrated in a modular system).
Services allow:
 device reset;
 retrieval of DeviceManager attributes.
6.1.1.4 Device function
The DeviceFunction class contains attributes and supports services which enable the management (e.g.
configuration) of a function of the device.
EXAMPLE  Examples of DeviceFunction objects are Overload, Presence Sensing, Analogue Input, and Discrete Output
objects.
NOTE The definition of specific DeviceFunction class is not defined in ISO 15745-2.
6.1.1.5 Application process
Figure 2 shows the class structure of the ApplicationProcess class.
ApplicationProcess
0.1
0.1 0.1
Assembly Parameter ParameterGroup
AssemblyClass ParameterClass Group
0.1 0.1 0.*
AssemblyInstance ParameterInstance
0.1 0.1
Assem Param
0.* 0.*
Figure 2 — DeviceNet ApplicationProcess class diagram
The Assembly class assembles several application process data items into a single block for optimisation of
communications. The Parameter class provides a standardized interface for accessing individual application
process data items. The ParameterGroup class specifies groups of related parameters for a specific purpose (e.g.
configuration, monitoring). The Assembly class and the Parameter class support attributes and services both at the
class and instance levels.
The Assem, Param and Group classes specify individual instances of the main classes.
NOTE The Assembly class and the Parameter class correspond to the DeviceNet Assembly object and Parameter objects.
The Assembly object is fully specified in IEC 61158-5:2003 and IEC 61158-6:2003 (Type 2).
6.1.2 Communication network profile
6.1.2.1 General
Figure 3 shows the class structure of the DeviceNet communication network profile.
CommNetworkProfile
1 1 0.1
ApplicationLayers TransportLayers NetworkManagement
0.1
NM-DeviceNetObject
0.1
ConnectionObject DNPhysicalLayer
0.1
1 NM-ConnectionObject
0.1
MessageRouter DNLinkLayer
0.1
NM-MessageRouter
0.1
DeviceNetObject
0.1
Ports
Figure 3 — DeviceNet communication network profile class diagram
6 © ISO 2003 – All rights reserved

The available formats for DeviceNet communication network profiles are described in A.3.
The XML schema representing the DeviceNet communication network profile template is defined in A.3.1.3. The file
name of this XML schema shall be “DNet_CommNet_Profile.xsd”.
The XML schema representing the encapsulation of a legacy DeviceNet EDS into the ISO 15745 communication
network profile template is defined in A.3.2.2. The file name of this XML schema shall be
“EDS_CommNet_Profile_wrapper.xsd”. The legacy EDS ASCII syntax itself is described in A.4.
6.1.2.2 Application layers
The DeviceNet ApplicationLayers class represents the combined profiles for the upper 3 OSI layers of the
DeviceNet communication network integration model.
It is further divided into several classes, as shown in Figure 3:
 ConnectionObject defines the properties associated with connections and connection management;
 MessageRouter defines the properties associated with internal message routing in the device.
NOTE The corresponding Connection object and Message Router object are fully specified in IEC 62026-3:2000.
6.1.2.3 Transport layers
The DeviceNet TransportLayers class represents the combined profiles for the lower 4 OSI layers of the DeviceNet
communication network integration model.
It is further divided into several classes, as shown in Figure 3:
 DNPhysicalLayer identifies the physical layer characteristics (e.g. connectors, baudrates, electrical
characteristics);
 DNLinkLayer and DeviceNetObject define the properties associated with data link layer configuration and
monitoring;
 Ports identifies the device ports which are able to route messages from one link to another link.
NOTE The corresponding DeviceNet object is fully specified in IEC 62026-3:2000.
6.1.2.4 Network management
The DeviceNet NetworkManagement class represents the network configuration and performance adjustment
capabilities of the DeviceNet communication network integration model.
It is further divided into several classes, as shown in Figure 3:
 NM-DeviceNetObject, NM-ConnectionObject and NM-MessageRouter define the properties associated with
class management of the corresponding objects.
6.2 CANopen
6.2.1 Device profile
6.2.1.1 General
Figure 4 shows the class structure of the CANopen device profile.
DeviceProfile
DeviceIdentity
0.*
ApplicationProcess
0.1
DeviceManager
0.*
DeviceFunction
Figure 4 — CANopen device profile class diagram
The required format for CANopen device profiles is described in B.1. The XML schema representing the CANopen
device profile template is defined in B.1.5.1. The file name of the XML schema shall be ‘COFDCML.xsd’.
NOTE 1 For better readability the CANopen DeviceProfile class diagram has been divided in five class diagrams.
NOTE 2 All these classes are mapped to the same XML schema defined in B.1.5.1.
NOTE 3 The CANopen device profile class diagrams shown in Figure 4 to Figure 10 define the main classes. Some classes
are further decomposed; details are defined in Annex B.
6.2.1.2 Device identity
The DeviceIdentity class is defined in Figure 5.
DeviceIdentity
vendorName
0.1
productID
0.1
vendorID
0.1
productText
0.1
vendorText
0.1
orderNumber
deviceFamily
0.*
version
0.1
capabilities
0.1
buildDate
0.1
productFamily
0.1
specificRevision
productName
0.1
instanceName
0.1
serialNumber
Figure 5 – DeviceIdentity class diagram
The DeviceIdentity class shall consist of the child classes shown in Figure 5 and specified in Table 2.
Table 2 - Decomposition of Device identity object class

Class Description Profile Type Instance
vendorName name of the manufacturer or vendor of the device X X X
vendorID X X
IEEE OUI (Organizationally Unique Identifier) (see [6])
vendorText can be used to provide further information on the X X X
vendor
deviceFamily the definition of this class is is not defined in this X X X
standard
8 © ISO 2003 – All rights reserved

Class Description Profile Type Instance
capabilities the definition of this class is not defined in this X X
standard
productFamily vendor specific product family (brand name) of the X X
device
productName vendor specific name of the product X X X
productID unique ID, identifying the device type, the format is at X X
the vendor's discretion
productText can be used to provide further information on the X X X
device
orderNumber vendor specific order number of the product X X
version vendor specific product version, the versionType X X
attribute allows the distinction of multiple versions
(i.e. Hardware, Firmware)
buildDate build date of the firmware of software constituting the X X
major functionality of the device
specificationRevision revision of the specification to which this device X X X
conforms
instanceName name of device instance  X
serialNumber serial number of device instance  X
NOTE The columns Profile, Type and Instance indicate whether a certain child class is suitable for usage
in a device profile, device type description or device instance description.
6.2.1.3 Device manager
6.2.1.3.1 General
Figure 6 shows the CANopen representation of the DeviceManager object.
DeviceManager
0.1
localDataDescriptionList
0.*
communicationEntitiy
1.*
localDataDescription
0.1
deviceStateTransitionDiagram
0.1
deviceStructure
0.*
processingEntity
0.1
slotList
0.1
channelList
1.*
slot
1.*
channel
0.1
indicatorList
0.1
MAUList
0.1
LEDList
1.*
MAU
1.*
LED
Figure 6 – DeviceManager class diagram
<< uses >>
6.2.1.3.2 localDataDescriptionList, localDataDescription
The localDataDescriptionList object shall be a collection of localDataDescription objects. A localDataDescription
object shall describe data objects that are used only within the device context.
6.2.1.3.3 deviceStructure
6.2.1.3.3.1 Overview
The deviceStructure object shall be a container of all physical objects of the device. Such an object can be a
channel (physical or logical I/O point), a MAU (Medium Attachment Unit), a slot for the connection of additional
modules (as part of the device) or a LED (light-emittig diode).
6.2.1.3.3.2 channelList, channel
A channelList shall be a collection of channel objects. Channel objects shall describe physical or logical I/O points
of a device.
6.2.1.3.3.3 MAUList, MAU
The MAUList shall be a collection of MAU objects. These objects shall describe the access points to network
medias.
6.2.1.3.3.4 slotList, slot
A slotList object shall be a collection of slot objects. A slot object shall contain a reference to an external CANopen
device profile exchange description.
NOTE Slots are used to describe modular devices or distinct combinations of devices.
6.2.1.3.3.5 indicatorList, LEDList, LED
A LEDList object shall be a collection of LED objects. A LED object shall describe a LED of a device.
NOTE The indicatorList class may be extended in future editions of ISO 15745-2.
6.2.1.3.4 communicationEntity
6.2.1.3.4.1 General
Figure 7 shows the definition of the communicationEntity class.
10 © ISO 2003 – All rights reserved

communicationEntity
cfgItemList
0.1
CANopenIdentity
0.1
CANopenDedicatedCfgItem
0.1
CANopenCommunicationFunctionList CANopenVendorID
0.1
CANopenProductCode
1.*
function
0.1
CANopenRevisionNumber
CANopenCommunicationParameterList
0.1
CANopenSerialNumber
1.*
0.1
parameters
CANopenManufacturerDeviceName
0.1
CANopenObjectAccessList
CANopenManufacturerHardwareVersion
1.*
CANopenObject
Figure 7 - communicationEntity class diagram
The communicationEntity shall describe an entity of a device, capable of communicating with entities of other
devices and shall contain a complete set of predefined configuration items and communication object descriptions.
There may be more than one communicationEntity in a device.
6.2.1.3.4.2 cfgItemList (configuration item list)
The cfgItemList shall consist of a CANopenDedicatedCfgItem object.
6.2.1.3.4.3 CANopenDedicatedCfgItem (CANopen dedicated configuration item)
A CANopenDedicatedCfgItem shall be a collection of configuration items.
NOTE The definition of additional configuration item classes is outside the scope of ISO 15745-2.
6.2.1.3.4.4 CANopenIdentity
The CANopenIdentity class consists of several object that are required to identify a device within a CANopen
network. This includes objects for a CANopenVendorID, CANopenProductCode, CANopenRevisionNumber, and
CANopenSerialNumber as well as CANopenManufacturerDeviceName, CANopenManufacturerHardwareVersion,
and CANopenManufacturerSoftwareVersion.
NOTE The corresponding identity object is specified in EN 50325-4.
6.2.1.3.4.5 CANopenCommunicationFunctionList, function
The CANopenCommunicationFunctionList shall be a collection of function objects. Each function object describes
a CANopen functionality from the CANopen communication area by use of the
CANopenCommunicationParameterList.
6.2.1.3.4.6 CANopenCommunicationParameterList, parameters
The CANopenCommunicationParameterList shall be a collection of parameter objects. Each parameter object
describes a parameter from the CANopen communication area.
<< uses >> << uses >>
6.2.1.3.4.7 CANopenObjectAccessList, CANopenObject
The CANopenObjectAccessList shall be a collection of CANopenObject objects. Each CANopenObject object
describes a parameter from the DeviceFunction view or from the CANopenCommunicationParameterList in respect
of the CANopen object dictionary.
NOTE The CANopenObjectAccessList is correponding to the CANopen object dictionary in EN 50325-4.
6.2.1.3.5 processingEntity
6.2.1.3.5.1 General
Figure 8 shows the definition of the processingEntity class.
processingEntity
0.1
cfgItemList
0.*
additionalItemList
1.*
dedicatedCfgItem
1.*
additionalItem
0.*
uncomittedCfgItem
0.1
internalConnectionPointList
0.1
logicalConnectionPointList
1.*
internalConnectionPoint
1.*
logicalConnectionPoint
0.1
logicalConnectionPointAssemblyList
1.*
logicalConnectionAssemblyPoint

Figure 8 - processingEntity class diagram
A processingEntity shall describe any device entity that is not a communication entity.
EXAMPLE A resource capable of executing programs.
6.2.1.3.5.2 additionalItemList, additionalItem
The additionalItemList shall be a collection of user defined additionalItem objects. An additionalItem object can be
used to describe device properties other than configuration properties or communication objects.
NOTE The definition of the additionalItemType of additional items is outside the scope of this International Standard.
EXAMPLE Device documentation.
6.2.1.3.5.3 logicalConnectionPointList, logicalConnectionPoint
The logicalConnectionPointList shall be a collection of logicalConnectionPoint objects. A logicalConnectionPoint
describes a connection.
NOTE It is assumed, that only connections between connection endpoints of the same type are used.
6.2.1.3.5.4 logicalConnectionPointAssemblyList, logicalConnectionPointAssembly
The logicalConnectionPointAssemblyList shall be a collection of logicalConnectionPointAssembly objects. A
logicalConnectionPointAssembly shall be a description of a group of logicalConnectionPoint objects.
12 © ISO 2003 – All rights reserved

<< provides >>
6.2.1.3.5.5 internalConnectionPointList, internalConnectionPoint
The internalConnectionPointList shall be a collection of internalConnectionPoint objects, which define internal
connections between multiple communicationEntity and/or resourceEntity objects in the same device.
6.2.1.3.5.6 cfgItemList (configuration item list)
The cfgItemList may consist of dedicatedCfgItem objects and uncomittedCfgItem objects.
6.2.1.3.5.7 dedicatedCfgItem (dedicated configuration item)
A dedicatedCfgItem shall be a configuration Item with a dedicatedCfgItemType. A dedicatedCfgItem shall be used
to specify the corresponding configuration properties.
6.2.1.3.5.8 uncommittedCfgItem (uncommitted configuration item)
An uncommittedCfgItem shall be a configuration item without a dedicatedCfgItemType attribute. An
uncommittedCfgItem shall be used to specify configuration properties that cannot be described by a
dedicatedCfgItem.
NOTE The definition of uncommitted configuration items is outside the scope of ISO 15745-2.
EXAMPLE A description of a DIP-Switch which changes the ID code of a device.
6.2.1.4 Device function
6.2.1.4.1 General
DeviceFunction
functionView
parameterList
1.*
parameter
0.1
functionList
1.*
function
0.1
inputList
0.1
outputList
Figure 9 - DeviceFunction class diagram
To allow multiple representations of the device function, an additional XML schema is used to describe the
DeviceFunction. The file name of this XML schema shall be “FDCMLISO15745DeviceFunction.xsd”. The
DeviceFunction XML schema is defined in Annex B.
NOTE The definition of additional XML schemas describing the DeviceFunction classes is outside the scope of
ISO 15745-2.
6.2.1.4.2 parameterList, parameter
The parameterList shall be a collection of parameter objects. A parameter object describes a device parameter
from a functional perspective. It is connected with a communication object in the communicationEntity.
6.2.1.4.3 functionList, function, inputsList, outputsList
The functionList shall be a collection of function objects. A function object shall consist of an inputList and an
outputList. These lists shall contain a list of references to parameter objects.
6.2.1.5 Application process
6.2.1.5.1 General
The ApplicationProcess object may be represented by one or more suitable XML schemas.
NOTE The definition of these XML schemas are not defined in ISO 15745-2.
6.2.1.5.2 textualDescription
The textualDescription object explains the function of a device in a human readable textual form.
14 © ISO 2003 – All rights reserved

6.2.2 Communication network profile
6.2.2.1 General
Figure 10 shows the class structure of the CANopen communication network profile.
CommNetworkProfile
TransportLayers
cfgItemList
CANopenDedicatedCfgCategory
CANopenBaudRate
CANopenGeneralCapabilities
0.1
CANopenDeviceCommissioning
ApplicationLayers
cfgItemList
CANopenDedicatedCfgCategory
CANopenDummyMappingDataTypes
CANopenGeneralCapabilities
0.1
CANopenDeviceCommissioning
NetworkManagement
cfgItemList
CANopenDedicatedCfgCategory
CANopenGeneralCapabilities
0.1
CANopenManagerlCapabilities
0.1
CANopenDeviceCommissioning
0.*
communicationProfile
Figure 10 - CANopen communication network profile class diagram
The XML schema representing the CANopen communication network profile is defined in Annex B. The file name
of the XML schema shall be “COCommNetworkProfile.xsd”.
6.2.2.2 communicationProfile
The communicationProfile shall state the usable communication profile identifiers. Communication profiles and their
identifiers are defined in IEC 61784-1:2003 clause 10.1. An AIP designer may specify additional communication
profiles, the identifiers for such new communication profiles shall be a three digit number between 680 and 699.
6.2.2.3 Transport layers
6.2.2.3.1 General
A TransportLayers object shall represent the combined profiles for the lower 4 OSI layers of the communication
network integration model. The TransportLayers object shall contain a cfgItemList object.
6.2.2.3.2 cfgItemList, CANopenDedicatedCfgCategory
The cfgItemList shall be a collection of configuration items related to the lower 4 OSI layers of the communication
network integration model. This includes a specific category dedicated to CANopn related configuration items, e.g.
Baudrates, general capabilities as well as device commissioning.
NOTE This CANopenDedicatedCfgCategory describes the supported services for data transimission (e.g. process data
objects and service data objects) as well as the supported baudrates as defined in EN 50325-4.
6.2.2.4 Application layers
6.2.2.4.1 General
An ApplicationLayers object shall represent the combined profiles for the upper 3 OSI layers of the communication
network integration model. The ApplicationLayers object shall contain a cfgItemList object.
6.2.2.4.2 cfgItemList, CANopenDedicatedCfgCategory
The cfgItemList shall be a collection of configuration items related to the upper 3 OSI layers of the communication
network integration model. This includes a specific category dedicated to CANopen related configuration items, e.g.
supported data types for dummy mapping, general capabilities as well as device commissioning.
6.2.2.5 Network management
6.2.2.5.1 General
A NetworkManagement object shall represent network management functionality. The NetworkManagement object
shall contain a cfgItemList object.
6.2.2.5.2 cfgItemList, CANopenDedicatedCfgCategory
The cfgItemList shall be a collection of configuration items related to the network management. This includes a
specific category dedicated to CANopen related configuration items, e.g. CANopen manager capabilities, general
capabilities as well as device commissioning.
NOTE This CANopenDedicatedCfgCategory specifies the supported network management services as specified in
EN 50325-4.
16 © ISO 2003 – All rights reserved

Annex A
(normative)
DeviceNet profile templates
A.1 General
The upper layers of the DeviceNet network are based on the Common Industrial Protocol (CIP). This protocol
models all communication and application entities as objects. CIP specific messaging requests services to be
performed on corresponding object instances (or their attributes). This scheme provides an explicit access to all
configuration, status, and runtime variables data in a node. At the same time, I/O connections allow direct
exchange with the I/O database, without intermediate processing. In both cases, all data references within a device
are specified using a CIP path, i.e. an octet string stream that defines the application object instance, attribute
and/or connection end-point.
Multiple options are available for remote configuration of devices with a CIP communication interface, including:
 device information saved in printed or electronic format;
 dedicated Parameter Objects, which provide a known public interface to individual configuration/parameter
data values, and may also embed additional configuration information such as descriptive text, data type, data
limits and default;
 dedicated Configuration Assembly, which allows bulk upload and download of configuration data by grouping
individual configuration/parameter data values;
 combinations of the above methods.
Configuration tools currently available for CIP-based devices use a specially formatted ASCII file, referred to as the
Electronic Data Sheet (EDS), which provides:
 information needed to identify the connected device;
 a description of device data that can be accessed via the network (e.g. configurable parameters);
 a description of the communication capabilities supported by the device (e.g. connections);
 additional vendor-specific information.
The EDS allows a configuration tool to automate the device configuration process. The EDS requirements provide
an open, consistent and compatible approach for performing device configuration in the CIP environment.
The EDS information is very similar to the information required in both communication network and device profiles,
hence the following subclauses specify format for:
 communication network and device profile templates, as defined in ISO 15745-1;
 encapsulation of legacy EDS files in the ISO 15745 templates (“wrappers”);
 the legacy Electronic Data Sheet, including common semantics information.
NOTE The DeviceNet EDS (Electronic Data Sheet) of a given device can be
...