EN 50325-3:2001

SLOVENSKI STANDARD
01-junij-2002
Industrial communications subsystem based on ISO 11898 (CAN) for controller-
device interfaces - Part 3: Smart Distributed System (SDS)
Industrial communications subsystem based on ISO 11898 (CAN) for controller-device
interfaces -- Part 3: Smart Distributed System (SDS)
Ta slovenski standard je istoveten z: EN 50325-3:2001
ICS:
35.240.50 Uporabniške rešitve IT v IT applications in industry
industriji
43.040.15 $YWRPRELOVNDLQIRUPDWLND Car informatics. On board
9JUDMHQLUDþXQDOQLãNLVLVWHPL computer systems
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD EN 50325-3
NORME EUROPÉENNE
EUROPÄISCHE NORM April 2001
ICS 43.180
English version
Industrial communications subsystem based on ISO 11898 (CAN)
for controller-device interfaces
Part 3: Smart Distributed System (SDS)
This European Standard was approved by CENELEC on 2000-04-01. CENELEC members are bound to
comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration.
Up-to-date lists and bibliographical references concerning such national standards may be obtained on
application to the Central Secretariat or to any CENELEC member.
This European Standard exists only in English. A version in any other language made by translation
under the responsibility of a CENELEC member into its own language and notified to the Central
Secretariat has the same status as the official version.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Czech Republic,
Denmark, Finland, France, Germany, Greece, Iceland, Ireland, Italy, Luxembourg, Netherlands, Norway,
Portugal, Spain, Sweden, Switzerland and United Kingdom.
CENELEC
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
Central Secretariat: rue de Stassart 35, B - 1050 Brussels
© 2001 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC members.
Ref. No. EN 50325-3:2001 E
Foreword
This European Standard was prepared by the Technical Committee CENELEC TC 65CX, Fieldbus.
The text of the draft was submitted to the Unique Acceptance Procedure and was approved by
CENELEC as EN 50325-3 on 2000-04-01.
The following dates were fixed:
– latest date by which the EN has to be implemented
at national level by publication of an identical
national standard or by endorsement (dop) 2001-10-01
– latest date by which the national standards conflicting
with the EN have to be withdrawn (dow) 2003-04-01
EN 50325 is divided into three parts:
Part 1 General requirements
Part 2 DeviceNet
Part 3 Smart Distributed System (SDS)
The specifications for DeviceNet and SDS are based on ISO 11898 Controller area network (CAN) for
high-speed communication, a broadcast-oriented communications protocol. However, ISO 11898 specifies
only part of a complete communication system, and additional specifications are needed for other layers to
ensure precise data exchange functionality and support of inter-operating devices. The DeviceNet and
SDS specifications build on ISO 11898 to describe a complete industrial communication system.

- 3 - EN 50325-3:2001
Contents
Introduction. 5
General information on licensing . 6
1 Scope. 7
2 Normative references . 7
3 Definitions, abbreviations and symbols . 8
3.1 Definitions. 8
3.1.1 Application Layer .8
3.1.2 Application Layer Protocol (ALP).8
3.1.3 Application Layer Protocol Data Unit (APDU) .8
3.1.4 Application Layer Service.8
3.1.5 Autobaud.8
3.1.6 Change Of State (COS) .8
3.1.7 Change Of Value (COV) .8
3.1.8 Confirm .8
3.1.9 Data Link Layer Protocol Data Unit (DLPDU) .8
3.1.10 Embedded Object .8
3.1.11 Embedded Object Identifier.9
3.1.12 Indication.9
3.1.13 Logical Device .9
3.1.14 Network .9
3.1.15 Object Model .9
3.1.16 Physical Component.9
3.1.17 Physical Layer Interface PLI.9
3.1.18 Primitive .9
3.2 Abbreviations. 9
3.3 Symbols. 10
3.3.1 (+) .10
3.3.2 (-) .10
3.3.3 (=) .10
4 Relationship with the OSI Reference Model . 10
5 Characteristics. 10
5.1 SDS Network. 10
5.1.1 Network .10
5.1.2 Modelling.11
5.1.3 Hierarchy.12
5.2 SDS Application Layer Services. 13
5.2.1 Service conventions.13
5.2.2 Read service.16
5.2.3 Write service.16
5.2.4 Event service.17
5.2.5 Action service .18
5.2.6 Change Of State ON (COS ON) service.18
5.2.7 Change Of State OFF (COS OFF) service.19
5.2.8 Write State ON (WRITE ON) service.19
5.2.9 Write State OFF (WRITE OFF) service.19
5.3 SDS Application Layer Protocol. 20
5.3.1 Application Protocol Data Unit (APDU).20
5.3.2 APDU Forms .21
5.3.3 Error Codes .28
5.3.4 Data types .29
5.4 SDS APDUs embedded in CAN frames. 33
5.5 Example Short Form APDUs. 36
5.6 Example Long Form APDUs. 37
6 Product information . 37
6.1 Instructions for installation, operation and maintenance. 37

6.2 Marking . 37
7 Normal service, transport and mounting conditions. 37
7.1 Normal service conditions . 37
7.1.1 General .37
7.1.2 Ambient air temperature .38
7.1.3 Altitude.38
7.1.4 Humidity.38
7.1.5 Pollution degree.38
7.1.6 Sealed connectors .38
7.2 Conditions during transport and storage. 38
7.3 Mounting . 38
8 Constructional and performance requirements. 38
8.1 SDS Physical Layer Interface (PLI) . 38
8.1.1 SDS power PLI .38
8.1.2 Transceivers.39
8.1.3 Transceiver specifications.39
8.1.4 Indicating means .41
8.2 SDS Network. 41
8.2.1 Topology .41
8.2.2 SDS power distribution .42
8.2.3 Auxiliary power ground connection.43
8.3 Electromagnetic Compatibility (EMC) . 43
8.3.1 General requirements for electromagnetic compatibility tests.43
8.3.2 General test conditions for electromagnetic compatibility tests.43
8.3.3 Immunity requirements.44
8.3.4 Emission requirements .46
9 SDS Communication channel type tests. 46
9.1 General . 46
9.2 Product Model . 46
9.3 Object Model test . 47
9.3.1 General .47
9.3.2 Attributes.47
9.3.3 Actions .48
9.3.4 Events .48
9.3.5 Short form services COS ON and COS OFF.48
9.3.6 Short form services WRITE ON and WRITE OFF .49
9.4 Physical Layer Test . 49
9.4.1 Transceiver functional test .49
9.4.2 Transceiver Input Resistance.49
9.4.3 Transceiver input levels .49
9.4.4 Transceiver output levels .50
9.4.5 SDS power .51
9.5 Application Layer Test.53
9.5.1 ALP Services .53
9.5.2 Logical Device functions .57
9.5.3 Network functions .58
9.6 System test . 59
9.6.1 System test set-up.59
9.6.2 Non-participative system testing .59
9.6.3 Participative system testing.59
9.6.4 Other basic system testing.60
9.7 Electromagnetic Compatibility Test . 60
9.7.1 General .60
9.7.2 Fast transient/burst immunity.60

- 5 - EN 50325-3:2001
Introduction
The Smart Distributed System (SDS) is intended for use in, but is not limited to, industrial automation
applications. These applications may include devices such as limit switches, proximity sensors,
electro-pneumatic valves, relays, motor starters, operator interface panels, analogue inputs, analogue
outputs, and controllers.
SDS provides for the connection of intelligent devices such as sensors, actuators and other
components to one or more controllers. SDS functionality may be integrated directly into the devices
or be in modules allowing the connection of conventional components to the network.
The SDS network consists of one or more controllers connected to up to 126 Logical Devices. In
addition to the process data, SDS allows for the transmission of parameters and diagnostic data. The
data exchange may be either event driven, cyclical, multicast or polled. A maximum of 6 bytes of
data may be transmitted without fragmentation.
Topology is typically a single trunk with short branches using a cable comprising two shielded, twisted
pairs with a common earth wire all within a single jacket.
Data is transmitted at rates of 125 kbit/s, 250 kbit/s, 500 kbit/s and 1Mbit/s with maximum system
trunk lengths of 457 m, 182 m, 91 m and 22 m respectively.
Detailed information on the performance is contained in clause 5.
Figure 1 shows an example of an SDS Network.
Physical
Component
Sensor Solenoid
Motor
Controller
Termination
Resistor is
included in the
controller.
Branch
Controller
Tee
Termination
Trunk
Resistor
Figure 1 - Example of an SDS Network

General information on licensing
CENELEC calls attention to the fact that patent rights are linked to EN 50325-3 (Part 3: Smart
Distributed System). The patent holder, Honeywell Inc., has assured to CENELEC that it is willing to
grant a licence under these patents on reasonable and non discriminatory terms and conditions to
anyone wishing to obtain such a license, applying the rules of CEN/CENELEC Memorandum 8.
Honeywell’s undertakings (policy letter on licensing, the license offer and the form of license) in this
respect are on file with CENELEC and available for inspection by all interested parties at the
CENELEC Central Secretariat.
The license details may be obtained from:
The Director
(Industrial Marketing and Applied Technology Sensing and Controls Europe)
Honeywell Control Systems Ltd.
Newhouse Industrial Estate,
Motherwell,
Lanarkshire
Scotland ML1 5SB
GB
- 7 - EN 50325-3:2001
1 Scope
This Part of EN 50325 specifies the following particular requirements for Smart Distributed System
(SDS).
− Requirements for interfaces between control devices and switching elements,
− Normal service conditions for devices,
− Constructional and performance requirements,
− Tests to verify conformance to requirements.
2 Normative references
This Part of EN 50325 incorporates by dated or undated reference, provisions from other publications.
These normative references are cited at the appropriate places in the text and the publications are
listed hereafter. For dated references, subsequent amendments to or revisions of any of these
publications apply to this Part only when incorporated in it by amendment or revision. For undated
references the latest edition of the publication referred to applies.
EN 55011 1998 Industrial, scientific and medical (ISM) radio-frequency equipment –
Radio disturbance characteristics, limits and methods of
measurement
(CISPR 11:1997, mod.)
EN 60947-1 1999 Low-voltage switchgear and controlgear
Part 1: General rules
(IEC 60947-1:1999, mod.)
EN 61000-4-2 1995 Electromagnetic compatibility (EMC)
Part 4-2: Testing and measurement techniques - Electrostatic
discharge immunity test (IEC 61000-4-2:1995)
EN 61000-4-3 1996 Electromagnetic compatibility (EMC)
Part 4-3: Testing and measurement techniques - Radiated,
radio-frequency, electromagnetic field immunity test
(IEC 61000-4-3:1995, mod.)
EN 61000-4-4 1995 Electromagnetic compatibility (EMC)
Part 4-4: Testing and measurement techniques - Electrical fast
transient/burst immunity test (IEC 61000-4-4:1995)
EN 61000-4-5 1995 Electromagnetic compatibility (EMC)
Part 4-5: Testing and measurement techniques - Surge immunity test
(IEC 61000-4-5:1995)
EN 61000-4-6 1996 Electromagnetic compatibility (EMC)
Part 4-6: Testing and measurement techniques - Immunity to
conducted disturbances, induced by radio-frequency fields
(IEC 61000-4-6:1996)
EN 61131-3 1993 Programmable controllers - Part 3: Programming languages
(IEC 61131-3:1993)
ISO/IEC 7498-1 1994 Information technology - Open Systems Interconnection
Part 1: Basic Reference Model: The Basic Model
ISO TR 8509 1987 Information Processing Systems, Open Systems Interconnection,
Service Conventions
ISO 11898 1993 Road vehicles - Interchange of digital information - Controller area
network (CAN) for high-speed communication

3 Definitions, abbreviations and symbols
3.1 Definitions
For the purposes of this Part, the following specific terms and definitions apply.
3.1.1 Application Layer
The seventh layer of the ISO/OSI Reference Model. (see ISO/IEC 7498-1).
3.1.2 Application Layer Protocol (ALP)
The rules governing the structure and timing of Application Layer Protocol Data Units that are used to
achieve the services provided by the application layer.
3.1.3 Application Layer Protocol Data Unit (APDU)
The unit of data transfer exchanged between application layers. It is encapsulated within a Data Link
Layer Protocol Data Unit (DLPDU) when transmitted from one component to another.
3.1.4 Application Layer Service
A service provided to the Service User of the application layer. The service may be provided by
means of a specified function call.
3.1.5 Autobaud
A network process for determining the network communication baud rate.
3.1.6 Change Of State (COS)
A report that a binary device has changed state.
3.1.7 Change Of Value (COV)
A report that a device input value has changed by a predetermined amount.
3.1.8 Confirm
A representation of an interaction in which a Service Provider indicates, at a particular service access
point, completion of some procedure previously invoked, at that service access point, by an
interaction represented by a request Primitive. The Confirm is an Application Layer Primitive service.
A Confirm notifies the Service User of the presence of the response. (ISO TR 8509)
3.1.9 Data Link Layer Protocol Data Unit (DLPDU)
A protocol data unit at the data link layer.
3.1.10 Embedded Object
A network-addressable entity within a Logical Device. The Embedded Object may be e.g. an
embedded interface, an embedded device, an embedded function or an embedded function block.

- 9 - EN 50325-3:2001
3.1.11 Embedded Object Identifier
A 5 bit Application Protocol Data Unit field that holds a number used to differentiate between up to 32
Embedded Objects in a Logical Device.
3.1.12 Indication
A representation of an interaction in which an Application Layer Protocol Service Provider indicates
that a procedure has been invoked by the Application Layer Protocol Service User at the peer service
access point. The Indication is an Application Layer Primitive service. The Indication notifies the
Service User of the presence of a request from another device or controller. (ISO TR 8509)
3.1.13 Logical Device
A separate addressable entity within a Physical Component. A Logical Device is connected to the
communications channel via its logical address.
3.1.14 Network
All the physical media, connectors, associated communication elements and a given set of
communicating devices interconnected for the purpose of communication.
3.1.15 Object Model
A description of behaviour and structure that comprises a set of attributes, a set of actions and a set
of events.
3.1.16 Physical Component
A single or modular physical package, including hardware and software and containing one or more
Logical Devices, that is connected to the Network.
3.1.17 Physical Layer Interface PLI
The interface between the Physical Component and the communications media.
3.1.18 Primitive
An implementation-independent representation of an interaction between a Service User and a
Service Provider. Primitive services exist at the Application Layer level. The Primitives are: Request,
Response, Indication and Confirm. (ISO TR 8509)
3.2 Abbreviations
3.2.1 CAN Controller Area Network
3.2.2 EOID Embedded Object Identifier
3.2.3 FI Fragmentation Indicator
3.2.4 R/R Request/Response
3.2.5 RTR Remote Transmission Request
3.2.6 EUT Equipment under Test

3.3 Symbols
3.3.1 (+)
A qualifying suffix used with Result parameter service descriptions. As a Result qualifier, it refers to a
successful result in Service Convention diagrams.
3.3.2 (-)
A qualifying suffix used with Result parameter service descriptions. As a Result qualifier, it refers to
an unsuccessful result in Service Convention diagrams.
3.3.3 (=)
A qualifying prefix used with Indication and Confirm Primitive service descriptions in Service
Convention diagrams. It means that the Primitive is the same as one occurring at a previous level.
4 Relationship with the OSI Reference Model
The SDS protocol is based on a three-layer architecture.
NOTE 1  These layers constitute a collapsed form of the OSI (Open Systems Interconnection) seven layer
architecture, mapping onto the physical, data link, and application layers of the OSI Reference Model
(ISO/IEC 7498-1).
The Application Layer uses the services provided by the V2.0A CAN Specification data link layer of
ISO 11898.
NOTE 2  Figure 2 compares the architecture of the SDS Protocol Model with the OSI Reference Model.
SDS Protocol Model Corresponding ISO Layers
APPLICATION LAYER APPLICATION LAYER
| PRESENTATION LAYER
| SESSION LAYER
| TRANSPORT LAYER
| NETWORK LAYER
CAN DATA LINK LAYER DATA LINK LAYER
SDS PHYSICAL LAYER PHYSICAL LAYER
Figure 2 - SDS protocol architecture compared with the OSI Reference Model
5 Characteristics
5.1 SDS Network
5.1.1 Network
An SDS Network consists of Physical Components which include input devices, output devices, PLC
interfaces, PC interfaces and interfaces to other Networks, etc. Physical Components are modelled
as collections of Logical Devices that communicate over a physical medium. Figure 3 shows a
logical representation of an SDS Network.

- 11 - EN 50325-3:2001
Physical Component Physical Component Physical Component
Logical Device Logical Device Logical Device Logical Device
Embedded
Device
Embedded
Device
Embedded
Device
Embedded
Embedded Embedded
Embedded
Device
Function Function
Interface
Block
SDS Address SDS Address
SDS Address
SDS Address
CAN CAN
CAN
SDS Trunk Cable
Physical Component Physical Component
Physical Component
Logical Device Logical Device Logical Device
Logical Device
Embedded
Device
Embedded
Device
Embedded
Device
Embedded Embedded Embedded
Embedded
Device
Function Function
Interface
Block
SDS Address SDS Address
SDS Address
SDS Address
CAN CAN
CAN
SDS Bus Cable
Figure 3 - Logical representation of an SDS Network
5.1.2 Modelling
5.1.2.1 Component Model
Component models represent SDS network visible structure and behaviour of a node. The primary
purpose of modelling is to improve the interoperability and interchangeability of SDS components.
The basic SDS component model structure is shown in graphical form in Figure 4. An SDS Physical
Component contains at least one Logical Device and provides the connection to the Network. A
Logical Device contains at least one and up to 32 SDS Embedded Objects (see 3.1.10). A Physical
Component may have several Logical Devices with different SDS Logical Addresses on the Network.

A PHYSICAL COMPONENT CONTAINS
1 TO 126 LOGICAL DEVICES.
A LOGICAL DEVICE CONTAINS
THE ACTUAL COMPONENT PHYSICAL COMPONENT
1 TO 32 EMBEDDED OBJECTS
OF THE FOLLOWING TYPES:
LOGICAL DEVICE
THE ADDRESSABLE DEVICE
� I/O DEVICES
� FUNCTIONS EN 61131-3
EMBEDDED OBJECT 31
� FUNCTION BLOCKS
� INTERFACES
EMBEDDED OBJECT 30
EACH SDS OBJECT MODEL INCLUDES:
EMBEDDED OBJECT 1
EVENTS:
EVENTS:
ACTIONS:
ATTRIBUTES:
EMBEDDED OBJECT 0 Diagnostic Event
End Of Timer
SUB-ADDRESSABLE OBJECTS
EVENTS: Change Of State
ACTIONS:
ACTIONS:
Change Of Value
ATTRIBUTES:
NOOP
...............
Change Address
Clear ALL errors
ATTRIBUTES:
Self Test
Device Type
........
Catalog Listing
Vendor Number
Software Release Number
CAN
Date Code
Device Name
Tag Name
Serial Number
..............
SDS TRUNK
Figure 4 - Graphical representation of Component Model
An SDS Component Model shall include three types of elements: attributes, actions and events.
These elements describe the behaviour of an SDS Embedded Object.
5.1.2.2 Attributes
Attributes are containers for the network visible data. Therefore a device network variables shall
include the collection of attributes defined by each of its Embedded Objects (figure 4). Each attribute
shall have a primitive tag which identifies an associated data type (see 5.3.4) along with data size
and/or length specifications. Attributes may be read-only, read-write, or read-write with password
protection.
5.1.2.3  Actions
Actions are SDS Embedded Object services which shall be invoked via an action request message
which may include data. A device services an action in a manner similar to a subroutine call in a
software program. The action response message may also include data.
5.1.2.4 Events
Events are SDS Embedded Object reports. A device shall issue an event as soon as the trigger
condition described in the SDS Object Model is true. An event message may include data.
5.1.3 Hierarchy
NOTE  SDS defines a mechanism to organize and manage models. These models are separated into major
categories and arranged hierarchically.

- 13 - EN 50325-3:2001
Figure 5 shows the overview of the standard SDS hierarchy. The SDS Minimum Model specifies a
minimum set of features that every device shall support. These features shall be inherited by other
models such as I/O Devices, Interface Devices, etc., each of which shall also specify its own set of
attributes, actions and events. These may in turn be inherited by other models which add another set
of features. A particular model shall support the features of all the models it inherits.
SDS
Minimum
Model
1.0
2.0 3.0
4.0
SDS
I/O
EN 61131-3
SDS
Function
Device
Function Interface
Block
Figure 5 - SDS example of Models in hierarchical form
The topmost level of the hierarchy defines the structure and minimum behaviour of the Physical
Component and Logical Device in the SDS Model. Every SDS product shall include this top level.
Each lower level of the hierarchy defines additional SDS attributes, actions and events for SDS
Embedded Objects at that level. SDS Embedded Objects at each level of the hierarchy shall inherit
all of the features from all previous levels. A Logical Device may contain up to 32 Embedded Objects
in any combination.
5.2 SDS Application Layer Services
5.2.1 Service conventions
The Application Layer shall provide the services listed in Table 1.
Table 1 - SDS Application Layer Services
Service Function
Read Allows the ALP service user to read the value of a device attribute.
Write Allows the ALP service user to modify the value of a device attribute.
Event Allows an ALP service user to report an event.
Action Allows an ALP service user to command a device to execute an action.
Change Of State–ON Specialized event service that reports a Change Of State to the ON
condition of a binary Device Model
Change Of State–OFF Specialized event service that reports a Change Of State to the OFF
condition of a binary Device Model
Write State–ON Specialized write service that writes an ON state to a binary output device
Write State–OFF Specialized write service that writes an OFF state to a binary output device

The SDS Service Model uses four primitive functions to provide the Application Layer Services at the
CAN Data Link Layer level: Request, Response, Indication and Confirm. The Primitives are shown in
Figure 6 for the standard service and in Figure 7 for a fragmented service.
Initiating Device Responding Device
Service User
Response
Request
Confirm
Indication
Application Layer 2
Confirm
CAN Data Link Layer
Physical Layer
Response APDU
Request APDU
Figure 6 - Representation of the service Primitives (without fragmentation)
The following description corresponds to the service sequence shown in Figure 6. For example, when
a sender invokes an application layer “Read” service, the following sequence of events occurs.
a) A Request Primitive presented to the Application Layer causes the generation of an Application
Layer Protocol Data Unit by the initiating device.
b) The receipt of the Application Layer Protocol Data Unit by the responding device causes an
Indication of the received message for the Service User at the responding device.
c) The Service User at the responding device presents a Response Primitive to the Application
Layer that causes the generation of an Application Layer Protocol Data Unit.
d) The receipt of this APDU response by the initiating device causes a Confirm Primitive to be
delivered to the Service User at the initiating device.

- 15 - EN 50325-3:2001
Initiating Device
Responding Device
Service User
Request
Response
Confirm
Indication
Confirm
4 Application Layer
CAN Data Link Layer
Physical Layer
Response APDU
Request APDU (nth fragment)
Request APDU (2nd fragment)
Request APDU (1st fragment)
Figure 7 - Representation of the service Primitives with fragmentation
The Fragmented Service is used for information that exceeds the maximum data length of a single
Application Layer Protocol Data Unit. The following sequence of events occurs.
a) A Request Primitive presented to the Application Layer causes the generation of the individual
fragmented APDUs by the initiating device.
b) The receipt of the last APDU fragment by the responding device causes an Indication of the
received message for the Service User at the responding device.
c) Following receipt of the Indication Primitive, the Service User at the responding device invokes
the Response Primitive on the Application Layer, which causes the generation of a Response
ADPU.
d) The receipt of this Response APDU by the initiating device causes a Confirm Primitive to be
delivered to the Service User at the initiating device.

5.2.2 Read service
This service shall be used to read an attribute value of an Embedded Object. For example, it could be
used to read the present value of a sensor. Table 2 describes the parameters defined for the read
service.
Table 2 - Parameters defined for read service
Parameter Request Indication Response Confirm
Logical Address—
Mandatory (=) Request received Mandatory
EOID
Attribute ID Mandatory (=) Request received Mandatory
Result (+) Conditional
Attribute ID Mandatory
(=) Response received
Attribute Value Mandatory (=) Response received
Result (–) Conditional
Attribute ID Mandatory (=) Response received
Error Code Mandatory
(=) Response received
The functions of the parameters are as follows:
a) Logical Address identifies the device from which the attribute data is to be read. This is
mandatory in both the Request and the Response.
b) EOID (Embedded Object ID) specifies which of the Embedded Objects is to be read. This is
mandatory in both the Request and the Response.
c) Attribute ID specifies the attribute to be read. The value of the attribute ID is defined in the
Object Model of the Embedded Object. This is mandatory in both Request and Response.
d) Result (+) The Result (+) parameter is returned if the read was successful. It returns the attribute
ID and the value that was read.
e) Result (–) The Result (–) parameter is returned if the read fails. It returns the attribute ID and
provides an error code specifying why the read request failed.
5.2.3 Write service
Shall be used to modify an attribute of an Embedded Object. For example, this service could be used
to set an actuator output to ON or OFF. Table 3 describes the parameters defined for this service.
Table 3 - Parameters defined for write service
Parameter Request Indication Response Confirm
Logical Address—EOID Mandatory (=) Request received Mandatory (=) Response received
Attribute ID Mandatory (=) Request received Mandatory (=) Response received
Attribute Value Mandatory (=) Request received
Result (+) Conditional a
Attribute ID Mandatory (=) Response received
Result (–) Conditional a
Attribute ID Mandatory (=) Response received
Error Code Mandatory (=) Response received

- 17 - EN 50325-3:2001
The functions of the parameters are as follows:
a) Logical Address identifies the device to which the attribute data is to be written. This is
mandatory in both the Request and the Response.
b) EOID (Embedded Object ID) specifies which of the Embedded Objects is to be written.
c) Attribute ID specifies the attribute to be written. The value of the ID is defined in the Object
Model of the Embedded Object.
d) Attribute Value is the value to which the attribute is to be set.
e) Result (+) The Result (+) parameter returned with the attribute ID if the write was successful.
f) Result (–) The Result (–) parameter is returned if the write failed. It returns the attribute ID and
provides an error code specifying why the write request failed.
5.2.4 Event service
Shall be used to report the occurrence of events specified for an Embedded Object. For example, a
Logical Device might report a self-test failure. Table 4 describes the parameters defined for this
service.
Table 4 - Parameters defined for event service
Parameter Request Indication Response Confirm
Logical Address—EOID Mandatory (=) Request received Mandatory (=) Response received
Event ID Mandatory (=) Request received Mandatory (=) Response received
Event Parameters Conditional (=) Request received
Result (+) Conditional
Event ID Mandatory (=) Response received
Result (–) Conditional c
Event ID Mandatory (=) Response received
Error Code Mandatory (=) Response received
The functions of the parameters are as follows:
a) Logical Address identifies the device in which the event occurred.
b) EOID (Embedded Object ID) specifies which of the Embedded Objects is transmitting.
c) Event ID specifies the event that occurred. The value of the event ID is specified in the Object
Model of the sending Embedded Object.
d) Event Parameters The event parameters are conditional on the type of event. They are defined
in the Object Model specifications.
e) Result (+) The Result (+) parameter is returned with the event ID if the event was successful.
f) Result (–) The Result (–) parameter is returned if the event failed. It returns the event ID and
provides an error code specifying why the event failed.

5.2.5 Action service
Shall be used to execute the actions specified for an Embedded Object. For example, the action
service may be used to initiate a self-test. Table 5 describes the parameters defined for this service.
Table 5 - Parameters defined for action service
Parameter Request Indication Response Confirm
Logical Address—EOID Mandatory (=) Request received Mandatory (=) Response received
Action ID Mandatory (=) Request received Mandatory (=) Response received
Action Parameters Conditional (=) Request received
Result (+) Conditional a
Action ID Mandatory (=) Response received
Action Results Conditional (=) Response received
Result (–) Conditional a
Action ID Mandatory (=) Response received
Error Code Mandatory (=) Response received
The functions of the parameters are as follows:
a) Logical Address identifies the device to which the action request is to be sent. This is mandatory
in both the Request and the Response.
b) EOID (Embedded Object ID) specifies which of the Embedded Objects is to perform the action.
c) Action ID specifies the action to be performed. The value of the action ID is specified in the
Object Model.
d) Action Parameters are dependent on the type of action. They are defined in the Object Model.
e) Result (+) The Result (+) parameter is returned with the action ID and action parameters.
f) Result (–) The Result (–) parameter is returned if the action request failed. It returns the action ID
and provides an error code specifying why the action request failed.
5.2.6 Change Of State ON (COS ON) service
Shall be used by a Logical Device to report the occurrence of a change of its state to ON. This event
service shall be used by a device which contains only a single binary Embedded Object (e.g., a single
binary input). Table 6 describes the parameters defined for this service.
Table 6 - Parame
...