4 2 PDF

IEC 61158-4-2
Edition 1.0 2007-12
INTERNATIONAL
STANDARD
--`,,```,,,,````-`-`,,`,,`,`,,`---
Industrial communication networks – Fieldbus specifications –
Part 4-2: Data-link layer protocol specification – Type 2 elements
IEC 61158-4-2:2007(E)
Copyright International Electrotechnical Commission

Provided by IHS under license with IEC
No reproduction or networking permitted without license from IHS Not for Resale
THIS PUBLICATION IS COPYRIGHT PROTECTED
Copyright © 2007 IEC, Geneva, Switzerland
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 IEC or IEC's member National Committee in the country of the requester.
If you have any questions about IEC copyright or have an enquiry about obtaining additional rights to this publication,
please contact the address below or your local IEC member National Committee for further information.
IEC Central Office

3, rue de Varembé
CH-1211 Geneva 20
Switzerland
Email: [email protected]
Web: www.iec.ch
About the IEC

The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.
About IEC publications

The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.
Catalogue of IEC publications: www.iec.ch/searchpub
The IEC on-line Catalogue enables you to search by a variety of criteria (reference number, text, technical committee,…).
It also gives information on projects, withdrawn and replaced publications.
IEC Just Published: www.iec.ch/online_news/justpub
Stay up to date on all new IEC publications. Just Published details twice a month all new publications released. Available
on-line and also by email.
Electropedia: www.electropedia.org
The world's leading online dictionary of electronic and electrical terms containing more than 20 000 terms and definitions
in English and French, with equivalent terms in additional languages. Also known as the International Electrotechnical
Vocabulary online.
Customer Service Centre: www.iec.ch/webstore/custserv
If you wish to give us your feedback on this publication or need further assistance, please visit the Customer Service
Centre FAQ or contact us:
Email: [email protected]
Tel.: +41 22 919 02 11
Fax: +41 22 919 03 00
--`,,```,,,,````-`-`,,`,,`,`,,`---

IEC 61158-4-2
Edition 1.0 2007-12
INTERNATIONAL
STANDARD
Industrial communication networks – Fieldbus specifications –

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION PRICE CODE
XK
ICS 35.100.20; 25.040.40 ISBN 2-8318-9428-X
--`,,```,,,,````-`-`,,`,,`,`,,`---

–2– 61158-4-2 © IEC:2007(E)
CONTENTS
FOREWORD...........................................................................................................................7
INTRODUCTION.....................................................................................................................9
1 Scope ............................................................................................................................. 10
1.1 General ................................................................................................................. 10
1.2 Specifications ........................................................................................................ 10
1.3 Procedures............................................................................................................ 10
1.4 Applicability ........................................................................................................... 11
1.5 Conformance......................................................................................................... 11
2 Normative references ..................................................................................................... 11
3 Terms, definitions, symbols and abbreviations................................................................ 12
3.1 Reference model terms and definitions .................................................................. 12
3.2 Service convention terms and definitions............................................................... 14
3.3 Common terms and definitions .............................................................................. 15
3.4 Additional Type 2 definitions.................................................................................. 16
3.5 Type 2 symbols and abbreviations......................................................................... 23
4 Overview of the DL-protocol ........................................................................................... 24
4.1 General ................................................................................................................. 24
4.2 Services provided by the DL .................................................................................. 26
4.3 Structure and definition of DL-addresses ............................................................... 27
4.4 Services assumed from the PhL ............................................................................ 29
4.5 Functional classes................................................................................................. 31
5 General structure and encoding of PhIDUs and DLPDUs and related elements of
procedure ....................................................................................................................... 32
5.1 Overview ............................................................................................................... 32
5.2 Media access procedure........................................................................................ 32
5.3 DLPDU structure and encoding ............................................................................. 35
5.4 Lpacket components ............................................................................................. 39
5.5 DLPDU procedures ............................................................................................... 41
--`,,```,,,,````-`-`,,`,,`,`,,`---
5.6 Summary of DLL support services and objects ...................................................... 42
6 Specific DLPDU structure, encoding and procedures ...................................................... 44
6.1 Modeling language ................................................................................................ 44
6.2 DLS user services ................................................................................................. 46
6.3 Generic tag Lpacket .............................................................................................. 52
6.4 Moderator Lpacket ................................................................................................ 53
6.5 Time distribution Lpacket ...................................................................................... 54
6.6 UCMM Lpacket ...................................................................................................... 57
6.7 Keeper UCMM Lpacket.......................................................................................... 57
6.8 TUI Lpacket........................................................................................................... 58
6.9 Link parameters Lpacket and tMinus Lpacket ........................................................ 59
6.10 I’m-alive Lpacket ................................................................................................... 60
6.11 Ping Lpackets........................................................................................................ 62
6.12 WAMI Lpacket ....................................................................................................... 64
6.13 Debug Lpacket ...................................................................................................... 64
6.14 IP Lpacket ............................................................................................................. 65
6.15 Ethernet Lpacket ................................................................................................... 65
7 Objects for station management ..................................................................................... 65

61158-4-2 © IEC:2007(E) –3–
7.1 General ................................................................................................................. 65

7.2 ControlNet object .................................................................................................. 66
7.3 Keeper object ........................................................................................................ 76
7.4 Scheduling object .................................................................................................. 98
7.5 TCP/IP Interface object ....................................................................................... 109
7.6 Ethernet link object.............................................................................................. 118
7.7 DeviceNet object ................................................................................................. 124
7.8 Connection configuration object (CCO)................................................................ 132
8 Other DLE elements of procedure................................................................................. 152
8.1 Network attachment monitor (NAM) ..................................................................... 152
8.2 Calculating link parameters ................................................................................. 159
9 Detailed specification of DL components ...................................................................... 167
9.1 General ............................................................................................................... 167
9.2 Access control machine (ACM) ............................................................................ 167
9.3 TxLLC ................................................................................................................. 184
9.4 RxLLC ................................................................................................................. 188
--`,,```,,,,````-`-`,,`,,`,`,,`---
9.5 Transmit machine (TxM) ...................................................................................... 191

9.6 Receive machine (RxM) ...................................................................................... 194
9.7 Serializer ............................................................................................................. 200
9.8 Deserializer ......................................................................................................... 201
9.9 DLL management ................................................................................................ 202
Annex A (normative) Indicators and switches ...................................................................... 205
A.1 Purpose .............................................................................................................. 205
A.2 Indicators ............................................................................................................ 205
A.3 Switches ............................................................................................................. 216
Bibliography........................................................................................................................ 218
INDEX ................................................................................................................................ 219
Figure 1 – Relationships of DLSAPs, DLSAP-addresses and group DL-addresses ................ 15

Figure 2 – Data-link layer internal architecture ...................................................................... 25
Figure 3 – Basic structure of a MAC ID address .................................................................... 27
Figure 4 – Basic structure of a generic tag address .............................................................. 27
Figure 5 – Basic structure of a fixed tag address .................................................................. 28
Figure 6 – M_symbols and Manchester encoding at 5 MHz (informative) .............................. 29
Figure 7 – NUT structure ...................................................................................................... 33
Figure 8 – Media access during scheduled time .................................................................... 33
Figure 9 – Media access during unscheduled time ................................................................ 34
Figure 10 – DLPDU format .................................................................................................... 35
Figure 11 – Aborting a DLPDU during transmission .............................................................. 39
Figure 12 – Lpacket format ................................................................................................... 39
Figure 13 – Generic tag Lpacket format ................................................................................ 40
Figure 14 – Fixed tag Lpacket format .................................................................................... 41
Figure 15 – Goodness parameter of TimeDist_Lpacket ......................................................... 55
Figure 16 – Example I’m alive processing algorithm .............................................................. 62
Figure 17 – Keeper CRC algorithm ....................................................................................... 82
Figure 18 – Keeper object power-up state diagram ............................................................... 94

–4– 61158-4-2 © IEC:2007(E)
Figure 19 – Keeper object operating state diagram ............................................................... 95

Figure 20 – Synchronized network change processing .......................................................... 98
Figure 21 – State transition diagram for TCP/IP Interface object ......................................... 118
Figure 22 – Connection configuration object edit flowchart.................................................. 152
Figure 23 – NAM state machine .......................................................................................... 153
Figure A.1 – Non redundant network status indicator labeling ............................................. 209
Figure A.2 – Redundant network status indicator labeling ................................................... 210
Table 1 – Data-link layer components ................................................................................... 24

Table 2 – MAC ID addresses allocation ................................................................................ 27
Table 3 – Fixed tag service definitions .................................................................................. 28
Table 4 – Data encoding rules .............................................................................................. 29
Table 5 – M Data symbols .................................................................................................... 30
Table 6 – Truth table for ph_status_indication....................................................................... 31
Table 7 – FCS length, polynomials and constants ................................................................. 37
Table 8 – DLL support services and objects .......................................................................... 43
Table 9 – Elementary data types ........................................................................................... 46
Table 10 – DLL events .......................................................................................................... 51
Table 11 – Time distribution priority ...................................................................................... 56
Table 12 – Format of the TUI Lpacket ................................................................................... 58
Table 13 – ControlNet object class attributes ........................................................................ 67
Table 14 – ControlNet object instance attributes ................................................................... 67
Table 15 – TUI status flag bits .............................................................................................. 71
Table 16 – Channel state bits ............................................................................................... 72
Table 17 – ControlNet object common services..................................................................... 74
Table 18 – ControlNet object class specific services ............................................................. 75
Table 19 – Keeper object revision history ............................................................................. 77
Table 20 – Keeper object class attributes ............................................................................. 77
Table 21 – Keeper object instance attributes ........................................................................ 77
Table 22 – Keeper operating state definitions ....................................................................... 80
Table 23 – Port status flag bit definitions .............................................................................. 80
Table 24 – TUI status flag bits .............................................................................................. 81
Table 25 – Keeper attributes ................................................................................................. 84
Table 26 – Memory requirements (in octets) for the Keeper attributes................................... 84
Table 27 – Keeper object common services .......................................................................... 85
Table 28 – Keeper object class specific services .................................................................. 86
Table 29 – Service error codes ............................................................................................. 87
Table 30 – Wire order format of the TUI Lpacket ................................................................... 91
Table 31 – Service error codes ............................................................................................. 92
Table 32 – Keeper object operating states ............................................................................ 92
--`,,```,,,,````-`-`,,`,,`,`,,`---
Table 33 – Keeper object state event matrix ......................................................................... 96

Table 34 – Scheduling object class attributes ....................................................................... 99
Table 35 – Scheduling object instance attributes ................................................................ 100

61158-4-2 © IEC:2007(E) –5–
Table 36 – Scheduling object common services .................................................................. 100

Table 37 – Status error descriptions for Create ................................................................... 101
Table 38 – Status error descriptions for Delete and Kick_Timer .......................................... 102
Table 39 – Scheduling object class specific services .......................................................... 102
Table 40 – Status error descriptions for Read ..................................................................... 104
Table 41 – Status error descriptions for Conditional_Write .................................................. 105
Table 42 – Status error descriptions for Forced_Write ........................................................ 105
Table 43 – Status error descriptions for Change_Start ........................................................ 106
Table 44 – Status error descriptions for Break_Connections ............................................... 106
Table 45 – Status error descriptions for Change_Complete................................................. 107
Table 46 – Status error descriptions for Restart_Connections ............................................. 108
Table 47 – TCP/IP Interface object class attributes ............................................................. 109
Table 48 – TCP/IP Interface object instance attributes ........................................................ 110
Table 49 – Status bits ......................................................................................................... 112
Table 50 – Configuration capability bits .............................................................................. 112
Table 51 – Configuration control bits................................................................................... 113
Table 52 – Example path .................................................................................................... 113
Table 53 – Interface configuration components ................................................................... 114
Table 54 – Alloc control values ........................................................................................... 115
Table 55 – TCP/IP Interface object common services ......................................................... 116
Table 56 – Get_Attribute_All reply format ........................................................................... 117
Table 57 – Ethernet link object revision history ................................................................... 118
Table 58 – Ethernet link object class attributes ................................................................... 119
Table 59 – Ethernet link object instance attributes .............................................................. 119
Table 60 – Interface flags bits ............................................................................................. 121
Table 61 – Control bits........................................................................................................ 123
Table 62 – Ethernet Link object common services............................................................... 123
Table 63 – Ethernet Link object class specific services ....................................................... 124
Table 64 – DeviceNet object revision history....................................................................... 124
Table 65 – DeviceNet object class attributes....................................................................... 125
Table 66 – DeviceNet object instance attributes.................................................................. 125
Table 67 – Bit rate attribute values ..................................................................................... 127
Table 68 – BOI attribute values........................................................................................... 128
Table 69 – Diagnostic counters bit description .................................................................... 129
Table 70 – DeviceNet object common services ................................................................... 130
Table 71 – Reset service parameter ................................................................................... 130
Table 72 – Reset service parameter values ........................................................................ 131
Table 73 – DeviceNet object class specific services............................................................ 131
--`,,```,,,,````-`-`,,`,,`,`,,`---
Table 74 – Connection configuration object revision history ................................................ 132

Table 75 – Connection configuration object class attributes ................................................ 132
Table 76 – Format number values ....................................................................................... 134
Table 77 – Connection configuration object instance attributes ........................................... 135
Table 78 – Originator connection status values ................................................................... 137

–6– 61158-4-2 © IEC:2007(E)
Table 79 – Target connection status values ........................................................................ 138

Table 80 – Connection flags ............................................................................................... 138
Table 81 – I/O mapping formats .......................................................................................... 140
Table 82 – Connection configuration object common services............................................. 141
Table 83 – Get_Attribute_All error codes ............................................................................ 141
Table 84 – Get_Attribute_All response ................................................................................ 142
Table 85 – Set_Attribute_All error codes............................................................................. 143
Table 86 – Set_Attribute_All request................................................................................... 144
Table 87 – Create request parameters ................................................................................ 145
Table 88 – Create error codes ............................................................................................ 146
Table 89 – Delete error codes ............................................................................................. 146
Table 90 – Restore error codes........................................................................................... 146
Table 91 – Connection configuration object class specific services ..................................... 147
Table 92 – Kick_Timer error codes ..................................................................................... 147
Table 93 – Open_Connection error codes ........................................................................... 148
Table 94 – Close_Connection error codes .......................................................................... 148
Table 95 – Stop_Connection error codes ............................................................................ 148
Table 96 – Change_Start error codes ................................................................................. 149
Table 97 – Get_Status service parameter ........................................................................... 149
Table 98 – Get_Status service response ............................................................................. 149
--`,,```,,,,````-`-`,,`,,`,`,,`---
Table 99 – Get_Status service error codes ......................................................................... 150

Table 100 – Change_Complete service parameter .............................................................. 150
Table 101 – Change_Complete service error codes ............................................................ 150
Table 102 – Audit_Changes service parameter ................................................................... 151
Table 103 – Audit_Changes service error codes ................................................................. 151
Table 104 – NAM states...................................................................................................... 153
Table 105 – Default link parameters.................................................................................... 154
Table 106 – PhL timing characteristics................................................................................ 160
Table A.1 – Module status indicator .................................................................................... 206
Table A.2 – Network status indicators ................................................................................. 207
Table A.3 – Network status indicator ................................................................................... 211
Table A.4 – Network status indicator ................................................................................... 213
Table A.5 – Combined module/network status indicator ...................................................... 214
Table A.6 – I/O status indicator ........................................................................................... 215
Table A.7 – Bit rate switch encoding ................................................................................... 217

61158-4-2 © IEC:2007(E) –7–
INTERNATIONAL ELECTROTECHNICAL COMMISSION

____________
INDUSTRIAL COMMUNICATION NETWORKS –

FIELDBUS SPECIFICATIONS –
--`,,```,,,,````-`-`,,`,,`,`,,`---
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with an IEC Publication.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
NOTE Use of some of the associated protocol types is restricted by their intellectual-property-right holders. In all
cases, the commitment to limited release of intellectual-property-rights made by the holders of those rights permits
a particular data-link layer protocol type to be used with physical layer and application layer protocols in Type
combinations as specified explicitly in the IEC 61784 series. Use of the various protocol types in other
combinations may require permission from their respective intellectual-property-right holders.
IEC draws attention to the fact that it is claimed that compliance with this standard may involve the use of patents
as follows, where the [xx] notation indicates the holder of the patent right:
Type 2 and possibly other types:
US 5,400,331 [RA] Communication network interface with screeners for incoming messages
US 5,471,461 [RA] Digital communication network with a moderator station election process
US 5,491,531 [RA] Media access controller with a shared class message delivery capability
US 5,493,571 [RA] Apparatus and method for digital communications with improved delimiter
detection
US 5,537,549 [RA] Communication network with time coordinated station activity by time slot and
periodic interval number
US 5,553,095 [RA] Method and apparatus for exchanging different classes of data during different
time Intervals
IEC takes no position concerning the evidence, validity and scope of these patent rights.

–8– 61158-4-2 © IEC:2007(E)
The holders of these patent rights have assured IEC that they are willing to negotiate licences under reasonable
and non-discriminatory terms and conditions with applicants throughout the world. In this respect, the statement of
the holders of these patent rights are registered with IEC. Information may be obtained from
[RA]: Rockwell Automation, Inc.
1201 S. Second Street
Milwaukee, WI 53204
USA
Attention: Intellectual Property Dept.
Attention is drawn to the possibility that some of the elements of this standard may be the subject of patent rights
other than those identified above. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 61158-4-2 has been prepared by subcommittee 65C: Industrial
networks, of IEC technical committee 65: Industrial-process measurement, control and
automation.
This first edition and its companion parts of the IEC 61158-4 subseries cancel and replace
IEC 61158-4:2003. This edition of this part constitutes a minor revision. This part and its
companion Type 2 parts also cancel and replace IEC PAS 62413, published in 2005.
This edition of IEC 61158-4 includes the following significant changes from the previous
edition:
a) deletion of the former Type 6 fieldbus, and the placeholder for a Type 5 fieldbus data link
layer, for lack of market relevance;
b) addition of new types of fieldbuses;
c) division of this part into multiple parts numbered -4-1, -4-2, …, -4-19.
The text of this standard is based on the following documents:
FDIS Report on voting

65C/474/FDIS 65C/485/RVD
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
This publication has been drafted in accordance with ISO/IEC Directives, Part 2.
The committee has decided that the contents of this publication will remain unchanged until
the maintenance result date indicated on the IEC web site under http://webstore.iec.ch in the
data related to the specific publication. At this date, the publication will be:
--`,,```,,,,````-`-`,,`,,`,`,,`---
• reconfirmed;
• withdrawn;
• replaced by a revised edition, or
• amended.
NOTE The revision of this standard will be synchronized with the other parts of the IEC 61158 series.
The list of all the parts of the IEC 61158 series, under the general title Industrial
communication networks – Fieldbus specifications, can be found on the IEC web site.

61158-4-2 © IEC:2007(E) –9–
INTRODUCTION
This part of IEC 61158 is one of a series produced to facilitate the interconnection of
automation system components. It is related to other standards in the set as defined by the
“three-layer” fieldbus reference model described in IEC/TR 61158-1.
The data-link protocol provides the data-link service by making use of the services available
from the physical layer. The primary aim of this standard is to provide a set of rules for
communication expressed in terms of the procedures to be carried out by peer data-link
entities (DLEs) at the time of communication. These rules for communication are intended to
provide a sound basis for development in order to serve a variety of purposes:
a) as a guide for implementors and designers;

b) for use in the testing and procurement of equipment;
c) as part of an agreement for the admittance of systems into the open systems environment;
d) as a refinement to the understanding of time-critical communications within OSI.
This standard is concerned, in particular, with the communication and interworking of sensors,
effectors and other automation devices. By using this standard together with other standards
positioned within the OSI or fieldbus reference models, otherwise incompatible systems may
work together in any combination.
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 10 – 61158-4-2 © IEC:2007(E)
INDUSTRIAL COMMUNICATION NETWORKS –

FIELDBUS SPECIFICATIONS –
1 Scope
1.1 General
The data-link layer provides basic time-critical messaging communications between devices in
an automation environment.
This protocol provides communication opportunities to all participating data-link entities,

sequentially and in a cyclic synchronous manner. Foreground scheduled access is available
for time-critical activities together with background unscheduled access for less critical
activities.
Deterministic and synchronized transfers can be provided at cyclic intervals up to 1 ms and

device separations of 25 km. This performance is adjustable dynamically and on-line by re-
configuring the parameters of the local link whilst normal operation continues. By similar
means, DL connections and new devices may be added or removed during normal operation.
This protocol provides means to maintain clock synchronization across an extended link with
a precision better than 10 μs.
This protocol optimizes each access opportunity by concatenating multiple DLSDUs and
associated DLPCI into a single DLPDU, thereby improving data transfer efficiency for data-
link entities that actively source multiple streams of data.
The maximum system size is an unlimited number of links of 99 nodes, each with 255 DLSAP-
addresses. Each link has a maximum of 2 24 related peer and publisher DLCEPs.
1.2 Specifications
--`,,```,,,,````-`-`,,`,,`,`,,`---
This standard specifies
a) procedures for the timely transfer of data and control information from one data-link user
entity to a peer user entity, and among the data-link entities forming the distributed data-
link service provider;
b) the structure of the fieldbus DLPDUs used for the transfer of data and control information
by the protocol of this standard, and their representation as physical interface data units.
1.3 Procedures
The procedures are defined in terms of
a) the interactions between peer DL-entities (DLEs) through the exchange of fieldbus
DLPDUs;
b) the interactions between a DL-service (DLS) provider and a DLS-user in the same system
through the exchange of DLS primitives;
c) the interactions between a DLS-provider and a Ph-service provider in the same system
through the exchange of Ph-service primitives.

61158-4-2 © IEC:2007(E) – 11 –
1.4 Applicability
These procedures are applicable to instances of communication between systems which

support time-critical communications services within the data-link layer of the OSI or fieldbus
reference models, and which require the ability to interconnect in an open systems
interconnection environment.
Profiles provide a simple multi-attribute means of summarizing an implementation’s

capabilities, and thus its applicability to various time-critical communications needs.
1.5 Conformance
This standard also specifies conformance requirements for systems implementing these
procedures. This standard does not contain tests to demonstrate compliance with such
requirements.
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.
IEC 61131-3, Programmable controllers – Part 3: Programming languages

--`,,```,,,,````-`-`,,`,,`,`,,`---
IEC 61158-2 (Ed.4.0), Industrial communication networks – Fieldbus specifications – Part 2:

Physical layer specification and service definition
IEC 61158-3-2, Industrial communication networks – Fieldbus specifications – Part 3-2: Data-
link layer service definition – Type 2 elements
IEC 61158-5-2, Industrial communication networks – Fieldbus specifications – Part 5-2:

Application layer service definition – Type 2 elements
IEC 61158-6-2, Industrial communication networks – Fieldbus specifications – Part 6-2:

Application layer protocol specification – Type 2 elements
IEC 61784-3-2, Industrial communication networks – Profiles – Part 3-2: Functional safety
fieldbuses – Additional specifications for CPF 2
IEC 62026-3 1, Low-voltage switchgear and controlgear – Controller-device interfaces (CDIs) –

Part 3: DeviceNet
ISO/IEC 3309, Information technology – Telecommunications and information exchange

between systems – High-level data link control (HDLC) procedures – Frame structure
ISO/IEC 7498-1, Information technology – Open Systems Interconnection – Basic Reference

Model: The Basic Model
ISO/IEC 7498-3, Information technology – Open Systems Interconnection – Basic Reference

Model: Naming and addressing
ISO/IEC 8802-3, Information technology – Telecommunications and information exchange

between systems – Local and metropolitan area networks – Specific requirements – Part 3:
Carrier sense multiple access with collision detection (CSMA/CD) access method and
physical layer specifications
1 To be published.

– 12 – 61158-4-2 © IEC:2007(E)
ISO/IEC 10731, Information technology – Open Systems Interconnection – Basic Reference

Model – Conventions for the definition of OSI services
ISO 11898:1993 2, Road vehicles – Interchange of digital information – Controller area

network (CAN) for high-speed communication
3 Terms, definitions, symbols and abbreviations
For the purposes of this document, the following terms, definitions, symbols and abbreviations
apply.
3.1 Reference model terms and definitions
This standard is based in part on the concepts developed in ISO/IEC 7498-1 and ISO/IEC
--`,,```,,,,````-`-`,,`,,`,`,,`---
7498-3, and makes use of the following terms defined therein.
3.1.1 called-DL-address [ISO/IEC 7498-3]
3.1.2 calling-DL-address [ISO/IEC 7498-3]
3.1.3 centralized multi-end-point-connection [ISO/IEC 7498-1]
3.1.4 correspondent (N)-entities [ISO/IEC 7498-1]

correspondent DL-entities (N=2)
correspondent Ph-entities (N=1)
3.1.5 demultiplexing [ISO/IEC 7498-1]
3.1.6 DL-address [ISO/IEC 7498-3]
3.1.7 DL-address-mapping [ISO/IEC 7498-1]
3.1.8 DL-connection [ISO/IEC 7498-1]
3.1.9 DL-connection-end-point [ISO/IEC 7498-1]
3.1.10 DL-connection-end-point-identifier [ISO/IEC 7498-1]
3.1.11 DL-connection-mode transmission [ISO/IEC 7498-1]
3.1.12 DL-connectionless-mode transmission [ISO/IEC 7498-1]
3.1.13 DL-data-sink [ISO/IEC 7498-1]
3.1.14 DL-data-source [ISO/IEC 7498-1]
3.1.15 DL-duplex-transmission [ISO/IEC 7498-1]
3.1.16 DL-facility [ISO/IEC 7498-1]
3.1.17 DL-local-view [ISO/IEC 7498-3]
3.1.18 DL-name [ISO/IEC 7498-3]
3.1.19 DL-protocol [ISO/IEC 7498-1]
3.1.20 DL-protocol-connection-identifier [ISO/IEC 7498-1]
3.1.21 DL-protocol-control-information [ISO/IEC 7498-1]
2 A newer edition of this standard has been published, but only the cited edition applies.

61158-4-2 © IEC:2007(E) – 13 –
3.1.22 DL-protocol-data-unit [ISO/IEC 7498-1]
3.1.23 DL-protocol-version-identifier [ISO/IEC 7498-1]
3.1.24 DL-relay [ISO/IEC 7498-1]
3.1.25 DL-service-connection-identifier [ISO/IEC 7498-1]
3.1.26 DL-service-data-unit [ISO/IEC 7498-1]
3.1.27 DL-simplex-transmission [ISO/IEC 7498-1]
3.1.28 DL-subsystem [ISO/IEC 7498-1]
3.1.29 DL-user-data [ISO/IEC 7498-1]
--`,,```,,,,````-`-`,,`,,`,`,,`---
3.1.30 flow control [ISO/IEC 7498-1]
3.1.31 layer-management [ISO/IEC 7498-1]
3.1.32 multiplexing [ISO/IEC 7498-3]
3.1.33 naming-(addressing)-authority [ISO/IEC 7498-3]
3.1.34 naming-(addressing)-domain [ISO/IEC 7498-3]
3.1.35 naming-(addressing)-subdomain [ISO/IEC 7498-3]
3.1.36 (N)-entity [ISO/IEC 7498-1]

DL-entity
Ph-entity
3.1.37 (N)-interface-data-unit [ISO/IEC 7498-1]

DL-service-data-unit (N=2)
Ph-interface-data-unit (N=1)
3.1.38 (N)-layer [ISO/IEC 7498-1]

DL-layer (N=2)
Ph-layer (N=1)
3.1.39 (N)-service [ISO/IEC 7498-1]

DL-service (N=2)
Ph-service (N=1)
3.1.40 (N)-service-access-point [ISO/IEC 7498-1]

DL-service-access-point (N=2)
Ph-service-access-point (N=1)
3.1.41 (N)-service-access-point-address [ISO/IEC 7498-1]

DL-service-access-point-address (N=2)
Ph-service-access-point-address (N=1)
3.1.42 peer-entities [ISO/IEC 7498-1]
3.1.43 Ph-interface-control-information [ISO/IEC 7498-1]
3.1.44 Ph-interface-data [ISO/IEC 7498-1]
3.1.45 primitive name [ISO/IEC 7498-3]
3.1.46 reassembling [ISO/IEC 7498-1]
3.1.47 recombining [ISO/IEC 7498-1]

– 14 – 61158-4-2 © IEC:2007(E)
3.1.48 reset [ISO/IEC 7498-1]
3.1.49 responding-DL-address [ISO/IEC 7498-3]
3.1.50 routing [ISO/IEC 7498-1]
3.1.51 segmenting [ISO/IEC 7498-1]
3.1.52 sequencing [ISO/IEC 7498-1]
3.1.53 splitting [ISO/IEC 7498-1]
3.1.54 synonymous name [ISO/IEC 7498-3]
3.1.55 systems-management [ISO/IEC 7498-1]
3.2 Service convention terms and definitions
This standard also makes use of the following terms defined in ISO/IEC 10731 as they apply
to the data-link layer:
3.2.1 acceptor
3.2.2 asymmetrical service
3.2.3 confirm (primitive);

requestor.deliver (primitive)
3.2.4 deliver (primitive)
3.2.5 DL-confirmed-facility
3.2.6 DL-facility
3.2.7 DL-local-view
3.2.8 DL-mandatory-facility
3.2.9 DL-non-confirmed-facility
3.2.10 DL-provider-initiated-facility
3.2.11 DL-provider-optional-facility
3.2.12 DL-service-primitive;
primitive
3.2.13 DL-service-provider
3.2.14 DL-service-user
3.2.15 DL-user-optional-facility
3.2.16 indication (primitive)

acceptor.deliver (primitive)
3.2.17 multi-peer
3.2.18 request (primitive);

requestor.submit (primitive)
3.2.19 requestor
3.2.20 response (primitive);

acceptor.submit (primitive)
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 15 –
3.2.21 submit (primitive)
3.2.22 symmetrical service
3.3 Common terms and definitions

NOTE Many definitions are common to more than one protocol Type; they are not necessarily used by all protocol
Types.
3.3.1
DL-segment, link, local link
single DL-subnetwork in which any of the connected DLEs may communicate directly, without
any intervening DL-relaying, whenever all of those DLEs that are participating in an instance
of communication are simultaneously attentive to the DL-subnetwork during the period(s) of
attempted communication
DLS-user-entity DLS-user-entity
DLS-users
DLSAP DLSAP DLSAP
DLSAP-
DLSAP- address group DL- DLSAP-
addresses address address
DL-layer DL-entity
--`,,```,,,,````-`-`,,`,,`,`,,`---
PhSA P PhSA P
Ph-layer
NOTE 1 DLSAPs and PhSAPs are depicted as ovals spanning the boundary between two adjacent layers.
NOTE 2 DL-addresses are depicted as designating small gaps (points of access) in the DLL portion of a DLSAP.
NOTE 3 A single DL-entity may have multiple DLSAP-addresses and group DL-addresses associated with a
single DLSAP.
Figure 1 – Relationships of DLSAPs, DLSAP-addresses and group DL-addresses
3.3.2
DLSAP
distinctive point at which DL-services are provided by a single DL-entity to a single higher-
layer entity.
NOTE This definition, derived from ISO/IEC 7498-1, is repeated here to facilitate understanding of the critical
distinction between DLSAPs and their DL-addresses. (See Figure 1.)
3.3.3
DL(SAP)-address
either an individual DLSAP-address, designating a single DLSAP of a single DLS-user, or a
group DL-address potentially designating multiple DLSAPs, each of a single DLS-user.
NOTE This terminology is chosen because ISO/IEC 7498-3 does not permit the use of the term DLSAP-address to
designate more than a single DLSAP at a single DLS-user

– 16 – 61158-4-2 © IEC:2007(E)
3.3.4
(individual) DLSAP-address
DL-address that designates only one DLSAP within the extended link
NOTE A single DL-entity may have multiple DLSAP-addresses associated with a single DLSAP.
3.3.5
extended link
DL-subnetwork, consisting of the maximal set of links interconnected by DL-relays, sharing a
single DL-name (DL-address) space, in which any of the connected DL-entities may
communicate, one with another, either directly or with the assistance of one or more of those
intervening DL-relay entities
NOTE An extended link may be composed of just a single link.
3.3.6
frame
denigrated synonym for DLPDU
3.3.7
--`,,```,,,,````-`-`,,`,,`,`,,`---
group DL-address
DL-address that potentially designates more than one DLSAP within the extended link. A
single DL-entity may have multiple group DL-addresses associated with a single DLSAP. A
single DL-entity also may have a single group DL-address associated with more than one
DLSAP
3.3.8
node
single DL-entity as it appears on one local link
3.3.9
receiving DLS-user
DL-service user that acts as a recipient of DL-user-data
NOTE A DL-service user can be concurrently both a sending and receiving DLS-user.
3.3.10
sending DLS-user
DL-service user that acts as a source of DL-user-data
3.4 Additional Type 2 definitions
3.4.1
actual packet interval (API)
measure of how frequently a specific connection produces its Lpacket data
3.4.2
allocate
take a resource from a common area and assign that resource for the exclusive use of a
specific entity
3.4.3
application
function or data structure for which data is consumed or produced
3.4.4
application objects
multiple object classes that manage and provide the run time exchange of messages across
the network and within the device

61158-4-2 © IEC:2007(E) – 17 –
3.4.5
attribute
description of an externally visible characteristic or feature of an object
NOTE The attributes of an object contain information about variable portions of an object. Typically, they provide
status information or govern the operation of an object. Attributes may also affect the behavior of an object.
Attributes are divided into class attributes and instance attributes.
3.4.6
behavior
indication of how the object responds to particular events. Its description includes the
relationship between attribute values and services
3.4.7
bit
unit of information consisting of a 1 or a 0. This is the smallest data unit that can be
transmitted
3.4.8
blanking or blanking time
length of time required after transmitting before the node is allowed to receive
3.4.9
client
1) An object which uses the services of another (server) object to perform a task
2) An initiator of a message to which a server reacts
3.4.10
communication objects
components that manage and provide run time exchange of messages across the network
such as the ControlNet object, the Unconnected Message Manager (UCMM)
--`,,```,,,,````-`-`,,`,,`,`,,`---
3.4.11
connection
logical binding between two application objects within the same or different devices
3.4.12
connection ID (CID)
identifier assigned to a transmission, associated with a particular connection between
producers and consumers, that identifies a specific piece of application information
NOTE Within the data link this is a generic tag.
3.4.13
cyclic redundancy check (CRC)
residual value computed from an array of data and used as a representative signature for the
array
3.4.14
cyclic
term used to describe events which repeat in a regular and repetitive manner
3.4.15
deafness
situation where the node can not hear the moderator DLPDU but can hear other link traffic
3.4.16
device
physical hardware connection to the link

– 18 – 61158-4-2 © IEC:2007(E)
NOTE A device may contain more than one node.
3.4.17
DLPDU
data-link protocol data unit
NOTE A DLPDU consists of a source MAC ID, zero or more Lpackets and an FCS as transmitted or received by
an associated PhE.
3.4.18
end delimiter
unique set of M_symbols that identifies the end of a DLPDU
3.4.19
error
discrepancy between a computed, observed or measured value or condition and the specified
or theoretically correct value or condition
3.4.20
extended link
links connected by DL-routers (sometimes called a local area network)
3.4.21
FCS error
error that occurs when the computed frame check sequence value after reception of all the
octets in a DLPDU does not match the expected residual
3.4.22
fixed tag
two octet identifier (tag) which identifies a specific service to be performed by either
a) that receiving node on the local link which has a specified MAC ID, or
b) all receiving nodes on the local link
NOTE Identification of the target node(s) is included in the two octet tag
3.4.23
frame
denigrated synonym for DLPDU
3.4.24
generic tag
three octet identifier (tag) which identifies a specific piece of application information
3.4.25
guardband
time slot allocated for the transmission of the moderator DLPDU
3.4.26
implicit token
mechanism that governs the right to transmit
NOTE No actual token message is transmitted on the medium. Each node keeps track of the MAC ID of the node
that it believes currently holds the right to transmit. The right to transmit is passed from node to node by keeping a
record of the node that last transmitted. A slot time is used to allow a missing node to be skipped in the rotation
3.4.27
implicit token register
register that contains the MAC ID of the node that holds the right to transmit
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 19 –
3.4.28
instance
actual physical occurrence of an object within a class, identifying one of many objects within
the same object class
EXAMPLE California is an instance of the object class state.
NOTE The terms object, instance, and object instance are used to refer to a specific instance.
3.4.29
instance attribute
attribute that is unique to an object instance and not shared by the object class
3.4.30
instantiated
object that has been created in a device
3.4.31
Keeper
object responsible for distributing link configuration data to all nodes on the link
3.4.32
link
collection of nodes with unique MAC IDs, attached to Ph-segments connected by Ph-
repeaters
3.4.33
little endian
model of memory organization which stores the least significant octet at the lowest address,
and of transmission organization which transfers the least significant octet first on the medium
--`,,```,,,,````-`-`,,`,,`,`,,`---
3.4.34
Lpacket
well-defined sub-portion of a DLPDU consisting of
a) size and control information
b) a fixed tag or a generic tag, and
c) DLS-user data or, when the tag has DL-significance, DL-data
3.4.35
M_symbol(s)
symbols that represent the data bits and related information encoded and transmitted by the
PhL
3.4.36
maximum scheduled node
node with highest MAC ID that can use scheduled time on a link
3.4.37
maximum unscheduled node
node with highest MAC ID that can use unscheduled time on a link
3.4.38
Message Router
object within a node that distributes messaging requests to the appropriate application objects
3.4.39
moderator
node with the lowest MAC ID that is responsible for transmitting the moderator DLPDU

– 20 – 61158-4-2 © IEC:2007(E)
3.4.40
moderator DLPDU
DLPDU transmitted by the node with the lowest MAC ID for the purpose of synchronizing the
nodes and distributing the link configuration parameters
3.4.41
multipoint connection
connection from one node to many
NOTE Multipoint connections allow messages from a single producer (publisher) to be received by many
consumer (subscriber) nodes.
3.4.42
network
series of nodes connected by some type of communication medium. The connection paths
between any pair of nodes can include repeaters, routers and gateways
3.4.43
network access monitor (NAM)
component within a node that manages communication with a temporary node connected to
the nodes local NAP
3.4.44
network access port (NAP)
PhL variant that allows a temporary node to be connected to the link by connection to the
NAP of a permanent node
3.4.45
network address or node address
node’s address on the link (also called MAC ID)
3.4.46
network status indicators
indicators on a node indicating the status of the Physical and Data Link Layers
3.4.47
network update time (NUT)
repetitive time interval in which data can be sent on the link
3.4.48
node
logical connection to a local link, requiring a single MAC ID
NOTE A single physical device may appear as many nodes on the same local link. For the purposes of this
protocol, each node is considered to be a separate DLE.
3.4.49
non-concurrence
situation where a transmission is received from an unexpected MAC ID, which appears to
violate the time based access protocol
NOTE This may occur when a connection is made between two working links that are not synchronized with each
other but who have the same configuration information
3.4.50
non-data symbol
PhL symbol which violates the requirements of Manchester biphase L encoding
3.4.51
object
abstract representation of a particular component within a device
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 21 –
NOTE An object can be

1) an abstract representation of a computer’s capabilities. Objects can be composed of any or all of the
following components:
a) data (information which changes with time);
b) configuration (parameters for behavior);
c) methods (things that can be done using data and configuration).
2) a collection of related data (in the form of variables) and methods (procedures) for operating on that data
that have clearly defined interface and behavior.
3.4.52
object specific service
service defined by a particular object class to perform a required function which is not
performed by a common service
NOTE An object specific service is unique to the object class which defines it.
3.4.53
originator
client responsible for establishing a connection path to the target
3.4.54
permanent node
node whose connection to the network does not utilize the network access port (NAP) PhL
variant
NOTE This node may optionally support a NAP PhL variant to allow temporary nodes to connect to the network
3.4.55
produce
act of sending data to be received by a consumer
3.4.56
producer
node that is responsible for sending data
3.4.57
redundant media
system using more than one medium to help prevent communication failures
3.4.58
requested packet interval (RPI)
measure of how frequently the originating application requires the transmission of Lpackets or
data packets from the target application
3.4.59
rogue
node that has received a moderator DLPDU that disagrees with the link configuration currently
used by this node
--`,,```,,,,````-`-`,,`,,`,`,,`---
3.4.60
scheduled
data transfers that occur in a deterministic and repeatable manner on predefined NUTs
3.4.61
server
object which provides services to another (client) object

– 22 – 61158-4-2 © IEC:2007(E)
3.4.62
service
operation or function than an object and/or object class performs upon request from another
object and/or object class
NOTE A set of common services is defined and provisions for the definition of object-specific services are
provided. Object-specific services are those which are defined by a particular object class to perform a required
function which is not performed by a common service.
3.4.63
slot time
maximum time required for detecting an expected transmission
NOTE Each node waits a slot time for each missing node during the implied token pass
3.4.64
start delimiter
unique set of M_symbols that identifies the beginning of a DLPDU
3.4.65
supernode
DLE with a MAC ID of zero
NOTE This DLE DL-address is reserved for special DLL functions
3.4.66
table unique identifier (TUI)
unique reference code used by ControlNet and Keeper objects to reference a consistent set of
link configuration attribute
3.4.67
tag
shorthand name for a specific piece of application information, two or three octets in length
3.4.68
target
end-node to which a connection is established
3.4.69
temporary node
same as transient node
3.4.70
--`,,```,,,,````-`-`,,`,,`,`,,`---
tMinus
number of NUTs before a new set of link configuration parameters are to be used
3.4.71
tone
instant of time which marks the boundary between two NUTs
3.4.72
tool
executable software program which interacts with the user to perform some function
EXAMPLE Link scheduling software (LSS).
3.4.73
transaction id
field within a UCMM header that matches a response with the associated request, which a
server echoes in the response message

61158-4-2 © IEC:2007(E) – 23 –
3.4.74
transient node
node that is only intended to be connected to the network on a temporary basis using the NAP
PhL medium connected to the NAP of a permanent node
3.4.75
Unconnected Message Manager (UCMM)
component within a node that transmits and receives unconnected explicit messages and
sends them directly to the Message Router object
3.4.76
unconnected service
messaging service which does not rely on the set up of a connection between devices before
allowing information exchanges
3.4.77
unscheduled
data transfers that use the remaining allocated time in the NUT after the scheduled transfers
have been completed
3.5 Type 2 symbols and abbreviations

ACM Access control machine
CA Clock accuracy
CAN Controller area network [ISO 11898:1993]
COP Connection originator password
IP Internet Protocol
LED Light emitting diode.
LSS Link scheduling software
MAC ID MAC address of a node
NAM Network attachment monitor
NAP Network access port
ND Non-data symbol
NUT Network update time
PT Programming terminal (a temporary network connection)
Rcv Receive
RPI Requested Lpacket interval
Rx Receive
RxLLC Receive logical link control
RxM Receive machine
SEM State event matrix
SMAX MAC ID of the maximum scheduled node
STD State transition diagram, used to describe object behavior
TCP Terminal Control Protocol
TUI Table unique identifier
Tx Transmit
TxLLC Transmit logical link control
--`,,```,,,,````-`-`,,`,,`,`,,`---
TxM Transmit machine

UCCM Unconnected Message Manager
UMAX MAC ID of maximum unscheduled node
USR Unscheduled start register

– 24 – 61158-4-2 © IEC:2007(E)
4 Overview of the DL-protocol
4.1 General
4.1.1 DLL architecture
The Type 2 DLL is modeled as an integrated Access Control Machine (ACM), with scheduling
support functions, designed for reliable and efficient support of higher-level connection-mode
and connectionless data transfer services. Interoperating with these higher level functions are
DLL management functions.
PhL framing and delimiters are managed by DLL functions for serializing and deserializing
M_symbol requests and indications.
Within the Data Link Layer, the Access Control Machine (ACM) has the primary responsibility
for detecting and recovering from network disruptions. The major objectives of the ACM are
— to make sure that the local node detects and fully utilizes its assigned access slots in the
schedule;
— to make sure that the local node does not interfere with the transmissions of other nodes,
especially the moderator node;
— to start the next NUT (see 4.1.2) on schedule, whether the moderator DLPDU is heard or
not;
— if the local node is the moderator, to transmit each moderator DLPDU strictly on schedule.
The Data Link Layer is comprised of the components listed in Table 1 :
Table 1 – Data-link layer components
--`,,```,,,,````-`-`,,`,,`,`,,`---
Components Description
Access Control Machine (ACM) receives and transmits control DLPDUs and header information, and
determines the timing and duration of transmissions.
Transmit LLC (TxLLC) buffers DLSDUs received from Station Management and the DLS-user, and
determines which should be transmitted next.
Receive LLC (RxLLC) performs the task of quarantining received link units until they are validated
by a good FCS.
Transmit Machine (TxM) receives requests to send DLPDU headers and trailers, and Lpackets from
the ACM, and breaks them down into octet symbol requests that are sent to
the Serializer.
Receive Machine (RxM) assembles received Lpackets from octet symbols received from the
Deserializer, and submits them to the RxLLC.
Serializer receives octet symbols, encodes and serializes them, and sends them as
M_symbols to the PhL. It is also responsible for generating the FCS.
Deserializer receives M_symbols from the PhL, converts M_symbols into octets and sends
them to the receive machine. It is also responsible for checking the FCS.
DLL Management Interface holds the Station Management variables that belong to the DLL, and helps
manage synchronized changes of the link parameters.
The internal arrangement of these components, and their interfaces, are shown in Figure 2.
The arrowheads illustrate the primary direction of flow of data and control.

61158-4-2 © IEC:2007(E) – 25 –
Application Layer
TxLLC RxLLC
DLL Access Control

Station Management Machine
Manage-
ment
TxM RxM
Framer Framer
Octet Octet
Serialiser Deserialiser
Physical Layer and Medium
Figure 2 – Data-link layer internal architecture
4.1.2 Access control machine (ACM) and scheduling support functions
The ACM functions schedule all communication from one DLE to another. The timing of this
communication are regulated at two levels,
1) to provide an accurate time based distribution of scheduled opportunities for designated

communications in accord with, and with a pre-established schedule for, the local link and
any extended network of links.
2) to provide a democratic distribution of unscheduled opportunities for arbitrary
communications, generally in a cyclic but asynchronous manner.
Accurate schedule timing as provided by 1) is very important to support many control and data
collection tasks in the applications domain of this protocol. The schedule is based on a fixed,
repetitive time cycle called network update time (NUT). The NUT is maintained in close
synchronism among all nodes participating in the DLL and used to provide two types of
--`,,```,,,,````-`-`,,`,,`,`,,`---
access opportunity;
1) One opportunity for each active station to transfer one scheduled DLPDU containing
multiple scheduled DLSDUs.
NOTE 1 Only DLSDUs with scheduled as their QoS parameter may be included in a scheduled DLPDU.
NOTE 2 DLSDUs with scheduled as their QoS parameter are usually connection mode transfers with generic
as their tag parameter.
2) One opportunity for at least one active station to send one background (unscheduled)
DLPDU containing multiple DLSDUs of any QoS type. If time is available within a NUT,
one background MAC opportunity is offered to each other active station in order of their
MAC ID address. The station MAC ID for the first background opportunity in each NUT, is
incremented ( +1 modulo the set of background addresses) for each successive NUT to
democratically share the available time among active stations.

– 26 – 61158-4-2 © IEC:2007(E)
Support procedures are included for automatic transfer to backup scheduling services and to
manage the use of redundant Ph media.
4.1.3 Connection-mode, connectionless-mode data transfer and DL service
The connection mode, connectionless mode and DL services provide the necessary
functionality for
— managing DL provider interactions with the DL user by converting request and response
primitives into necessary DLE operations and generating indications and confirm
primitives where appropriate,
— determination of the DL address and control information to be added to each DLSDU,
— local confirmation of status for each outgoing DLSDU,
— DLPDU formation by concatenation of multiple DL user DLSDUs for efficient transfer as
single PhPDUs, subject to DLPDU size limitations, QoS parameters and the type of
--`,,```,,,,````-`-`,,`,,`,`,,`---
access opportunity.
4.2 Services provided by the DL
4.2.1 Overview
The DLL provides connectionless data transfer services and connection-mode data transfer
services for limited-size DLSDUs, an internally synchronized time service, scheduling services
to control the time allocation of the underlying shared PhL service, a DL(SAP)-address and
queue management service, and a packing/unpacking service that combines multiple DLSDUs
into a single data transfer DLPDU for efficient use of each access opportunity.
4.2.2 QoS
4.2.2.1 Definition
The QoS parameter specifies priority options for DLSDUs and access opportunities. The
available values are as follows:
4.2.2.2 DLL scheduled priority
The scheduled priority QoS provides accurate time based cyclic and acyclic sending of
DLSDUs. The execution timing for this fieldbusscheduled service can be accurate and
repeatable to better than 1 ms. Scheduled priority is normally used with connected mode
services.
NOTE The master Keeper is responsible for regular publication of a unique table identifier (TUI) which ensures all
nodes have a reference for the current set of link operating parameters. This TUI publication uses a fixed tag and
is sent with QoS priority set to scheduled.
4.2.2.3 DLL high priority (unscheduled)
The high priority QoS provides acyclic sending of DLSDUs with a bounded upper time for the
sending delay. Data on this priority is sent only when all scheduled data has been sent and a
non-scheduled sending opportunity is available.
4.2.2.4 DLL low priority (unscheduled)
The low priority QoS provides for sending of DLSDUs only on an as-available basis. Data on
this priority is sent only when all other data priorities have been sent and a non-scheduled
sending opportunity is available.
NOTE High and Low priority are used only in a local sense to set the order of servicing among locally submitted,
unscheduled DLS-user-data.

61158-4-2 © IEC:2007(E) – 27 –
4.3 Structure and definition of DL-addresses
4.3.1 General
DL-addresses are used as MAC ID addresses (Link node designators), Fixed tag addresses
(DLSAP-addresses and group DL-addresses), and Generic tag addresses (DLCEP-
addresses).
This subclause defines the form and structure of DL-addresses and includes specific
definitions for some standard DL-addresses.
All addresses are formed of octets. Each octet shall be transferred to the Ph layer low-bit first
and multiple octets shall be transferred low-order octet first (little endian format).
Three types of DL addresses are used.
4.3.2 MAC ID address
MAC ID addresses identify physical nodes on the local link as shown in Figure 3.
Permitted values are within the range 0–99, values from 100–254 are reserved.
MAC ID
1 octet
Figure 3 – Basic structure of a MAC ID address
Table 2 specifies the use of MAC ID addresses.
Table 2 – MAC ID addresses allocation
MAC ID Meaning and purpose
0x0 temporary address used for maintenance

SMAX current maximum address value for Scheduled access
opportunities. SMAX =< UMAX
UMAX current maximum address value for Unscheduled access
opportunities SMAX. =< UMAX =< 0x63
0x64 to 0xFE reserved
0xFF broadcast address to all MAC ID nodes on this link
4.3.3 Generic tag address
Generic tag addresses types identify all data transfers for connected mode services. The
available capacity in the DLL is 3 octets, see Figure 4.
Generic tag
3 octets
Figure 4 – Basic structure of a generic tag address

NOTE 1 Generic tags are used to send connected DLSDUs and may be associated with any of the available QoS
priorities (Scheduled, High, Low).
NOTE 2 Negotiation and management of generic tags and connected mode services are the responsibility of the
DL user.
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 28 – 61158-4-2 © IEC:2007(E)
4.3.4 Fixed tag address
Fixed tag addresses types identify DLSAPs within a designated station MAC ID. They are
used with all data transfers for connectionless mode services.
NOTE Fixed tags are used to send connectionless DLSDUs and are usually associated with unscheduled QoS
priorities (High, Low). Typical uses of fixed tags are for station management and to establish connections.
Each fixed tag address shall consist of two octets as shown in Figure 5.
Fixed tag service Destination MAC ID
1 octet 1 octet
Figure 5 – Basic structure of a fixed tag address
The first octet shall specify the service access point in the destination node as specified in
Table 3. The second octet shall be the address of the destination node. The destination
address shall be either a MAC ID or 0xFF, which indicates the broadcast address to all MAC
IDs on the local link.
Table 3 – Fixed tag service definitions
Fixed tag service Meaning

0x00 moderator
0x01 - 0x08 vendor specific
0x09 ping request
0x0A – 0x14 vendor specific
0x15 tMinus
0x16 - 0x28 vendor specific
0x29 ping reply
0x2A - 0x3F vendor specific
--`,,```,,,,````-`-`,,`,,`,`,,`---
0x40 - 0x6F reserved
0x70 – 0x7F vendor-specific
0x80 I’m alive
0x81 link parameters
0x82 reserved
0x83 UCMM
0x84 TUI
0x85 IP (reserved for Internet Protocol)
0x86 WAMI
0x87 reserved
0x88 Keeper UCMM
0x89 Ethernet (used for address
resolution protocol)
0x8A - 0x8B reserved
0x8C Time distribution
0x8D – 0x8F reserved for time distribution
0x90 debug
0x91 - 0xCF reserved
0xD0 - 0xEF group addresses
0xF0 - 0xFF vendor specific
Fixed tags in the range 0xD0 to 0xEF shall be reserved to permit group screening of
connection identifiers.

61158-4-2 © IEC:2007(E) – 29 –
4.4 Services assumed from the PhL
4.4.1 General requirements
The following subclauses include requirements for interface to a Type 2 PhL that are not
required for other Types.
— Transmit Machine.
— Receive Machine.
— Serializer.
— Deserializer.
This is necessary because the Ph-Interface Data Units (PhIDUs) that Type 2 passes across
the DLL–PhL interface are individual serial data and non-data symbols, designated on the
DLE side as M_Symbols (see Table 4), whereas PhIDUs for other Types are not
conceptualized in this way. As a consequence, a Type 2 Data Link Layer requires a Type 2
PhL.
4.4.2 Data encoding rules
The M_Symbols transferred at the DLL to PhL interface are of four types designated 0, 1, +, -.
They will be encoded inside the PhL into appropriate Ph_Symbols as shown in Table 4. The
M_0 and M_1 will be encoded into Ph_Symbols that represent Manchester biphase L data
encoding rules. The M_ND symbols are non-data symbols to allow for the creation of unique
data patterns used for start and end delimiters. The example of signal voltage waveform as it
might be applied to an electrically-conductive medium is shown in an idealized form in
Figure 6 to provide an example of the data encoding rules shown in Table 4.
Table 4 – Data encoding rules
Data bits (common name) M_Symbol representation Ph_Symbol encoding Manchester encoded
--`,,```,,,,````-`-`,,`,,`,`,,`---
data “zero” M_0 or {0} {L,H} 0

data “one” M_1 or {1} {H,L} 1
“non_data+” M_ND+ or {+} {H,H} no data
“non_data–” M_ND– or {–} {L,L} no data
+V
Transmitter
Off
-V
One
bit
time
(200 ns)
MAC_Symbols 1 1 0 0 +
Manchester
biphase L Time
encoding
P hy _Symbols H L H L L H L H L L H H
Figure 6 – M_symbols and Manchester encoding at 5 MHz (informative)

– 30 – 61158-4-2 © IEC:2007(E)
4.4.3 DLL to PhL interface
4.4.3.1 General
The DLL to PhL interface need not be exposed in the implementation of any PhL variant. This
interface may be internal to the node. If conformance to the DLL to PhL interface is claimed, it
shall conform to the requirements of this clause.
4.4.3.2 Ph_lock_indication
ph_ lock_indication shall provide an indication of either data lock or Ph_Symbol synchronization
by the PhL. Valid states for ph_ lock_indication shall be true and false. ph_ lock_indication shall
be true whenever valid Ph_Symbols are present at the PhL interface and the PhL to DLL
interface timing of M_Symbols conforms to the PhL requirements. It shall be false between
frames (when no Ph_Symbols are present on the medium) or whenever data synchronization
is lost or the timing fails to conform to the PhL requirements. ph_ lock_indication shall be true
prior to the beginning of the start delimiter.
4.4.3.3 Ph_frame_indication
ph_ frame_indication shall provide an indication of a valid data frame from the PhL. Valid states
for ph_ frame_indication shall be true and false. ph_ frame_indication shall be true upon
ph_ lock_indication = true and reception of the first valid start delimiter. ph_ frame_indication shall
be false at reception of next M_ND symbol (following the start delimiter) or ph_ lock_indication
= false.
NOTE This signal provides octet synchronization to the DLL.
4.4.3.4 Ph_carrier_indication
ph_ carrier_indication shall represent the presence of a signal carrier on the medium. The
ph_ carrier_indication shall be true if internal PhL identification of signal carrier has been true
during any of the last 4 M_symbol times and it shall be false otherwise.
4.4.3.5 Ph_data_indication
ph_ data_indication shall represent the M_Symbols that are decoded from the PhL internal
representations such as those shown in Table 4. Valid M_symbols shall be M_0 {0}, M_1 {1},
M_ND+ {+}, and M_ND– {-} as shown in Table 5.
Table 5 – M Data symbols
Data bits (common name) M_Symbol representation
data “zero” M_0 or {0}

data “one” M_1 or {1}
“non_data+” M_ND+ or {+}
“non_data–” M_ND– or {–}
The ph_ data_indication shall represent the M_Symbols as decoded within the PhL whenever
ph_ lock_indication is true.
4.4.3.6 Ph_status_indication
ph_ status_indication shall represent the delimiter status of the frame which was received from
the PhL as shown in Table 6. Valid symbols shall be Normal, Abort, and Invalid.
ph_ status_indication shall indicate Normal after reception of a frame (ph_ frame_indication = true)
composed of a start delimiter, valid data (no M_ND symbols) and an end delimiter.
ph_ status_indication shall indicate Abort after reception of a frame (ph_ frame_indication = true)
composed of a start delimiter, valid data, and a second start delimiter. ph_ status_indication
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 31 –
shall indicate Invalid after reception of a frame (ph_ frame_indication = true) composed of a
start delimiter and the detection of any M_ND symbol which was not part of a start or end
delimiter.
Table 6 – Truth table for ph_ status_indication
Start delimiters in End delimiter Any non-delimiter

Ph_status_indication Ph_frame_indication
a single frame detection Manchester violations
Normal true 1 true false

Abort true 2 don’t care false
Invalid true 1 don’t care true
4.4.3.7 Ph_data_request
--`,,```,,,,````-`-`,,`,,`,`,,`---
ph_data_request shall present the M_Symbols to be transmitted. Valid symbols shall be M_0,
M_1, M_ND+ or M_ND– as shown in Table 5. ph_ data_request shall indicate M_0 when no
data is to be transmitted (and ph_ frame_request = false).
4.4.3.8 Ph_frame_request
ph_ frame_request shall be true when ph_ data_request presents M_Symbols to be encoded into
the appropriate Ph_Symbols by the PhL, and shall be false when no valid M_Symbols are to
be transferred to the PhL.
4.5 Functional classes
Implementations of this protocol fall into two broad classes:
— connection originators (sometimes called Scanners);

— connection responders or connection targets (sometimes called Adaptors).
Devices with connection origination capability will include functions such as Scheduling
object, support for external Configuration Tools and usually a Keeper object.
Connection responders are typically simpler devices which do not need the full set of
capabilities.
This specification does not mandate particular groupings of functions for classes of
implementation devices.
NOTE Grouping of services and functions into implementation classes may be done by separate specifications for
profiles.

– 32 – 61158-4-2 © IEC:2007(E)
5 General structure and encoding of PhIDUs and DLPDUs and

related elements of procedure
5.1 Overview
The DLL and its procedures are those necessary to provide the services offered to DLS user
by using the services available from the PhL. The main services of this protocol are
a) provision of timely access opportunities to support scheduled data-transfer DL-services on

one link and on an extended multi-link network;
b) the packing of multiple DLS-user transfers into a single PhL transfer unit (DLPDU) to
efficiently use each transfer opportunity;
c) the efficient distribution of DLS-user data from a publishing DLS-user to a set of
subscribing DLS-users;
d) the provision of a synchronized sense of internal time among the DLEs and available to
the DLS-users of the extended link;
e) the standardized availability of local DL-address, buffer and queue management
capabilities.
5.2 Media access procedure
The primary task of the Data Link Layer is to determine, in co-operation with other Data Link
Layers on the same link, the granting of permission to transmit on the medium. At its upper
interface, the DLL provides services to receive and deliver service data units for the DLS user
and Station Management.
The DLL protocol is based on a fixed, repetitive time cycle called a network update time
(NUT). The NUT is maintained in close synchronism among all nodes on the link. A node is
not permitted access to transmit on the medium if its NUT does not agree with the NUT
currently being used on a link wide basis. Different links may have different NUT duration.
Each node contains its own timer synchronized to the NUT for the local link. Media access is
determined by local sub-division of the NUT into access slots. Access to the medium is in
sequential order based on the MAC ID of the node. Specific behaviors have been
incorporated into the access protocol allowing a node which temporarily assumes a MAC ID of
zero to perform link maintenance. The MAC ID numbers of all nodes on a link are unique. Any
DLL detecting the presence of a duplicate MAC ID shall immediately stop transmitting.
An implicit token passing mechanism is used to grant access to the medium. Each node
monitors the source MAC ID of each DLPDU received. At the end of a DLPDU, each DLL sets
an “implicit token register” to the received source MAC ID + 1. If the implicit token register is
equal to the local MAC ID, then the node shall transmit one DLPDU containing one or more
Lpackets with data or a null DLPDU. In all other cases, the node watches for either a new
DLPDU from the node identified by the “implicit token register” or a time-out value if the
identified node fails to transmit. In each case, the “implicit token” is automatically advanced to
the next MAC ID. All nodes have the same value in their “implicit token register” preventing
collisions on the medium.
--`,,```,,,,````-`-`,,`,,`,`,,`---
The time-out period (called the “slot time”) is based on the amount of time required for
— the current node to hear the end of the transmission from the previous node;
— the current node to begin transmitting;
— the next node to hear the beginning of the transmission from the current node.
The slot time is adjusted to compensate for the total length of the medium since the
propagation delay of the medium effects the first and last item on the previous list.
NOTE The calculation of slot time is specified in 8.2.

61158-4-2 © IEC:2007(E) – 33 –
Each NUT is divided into three major parts: scheduled, unscheduled, and guardband as
shown in Figure 7. This sequence is repeated in every NUT. The implicit token passing
mechanism is used to grant access to the medium during both the unscheduled and
scheduled intervals.
Scheduled
Network Update Time (NUT) Guardband
Unscheduled
Figure 7 – NUT structure
During the scheduled part of the NUT, each node, starting with node 0 and ending with node
SMAX, gets a chance to transmit time-critical (scheduled) data. SMAX is the MAC ID of the
highest numbered node that has access to the medium during the scheduled part of the NUT.
Every node between 0 and SMAX has only one opportunity to send one DLPDU of scheduled
data in each NUT. The opportunity to access the medium during the scheduled time is the
same for each node in every NUT. This allows data that is transmitted during the scheduled
portion of the NUT to be sent in a predictable and deterministic manner. Figure 8 shows how
the permission to transmit is granted during the scheduled time. The DLS-user regulates the
amount of data that each node may transmit during this scheduled token pass.
Tim e SCHEDULED
UNSCHEDULED
GUARDBAND
0 0 0
1 1 1
2 2
3 3 3
--`,,```,,,,````-`-`,,`,,`,`,,`---
n n n
n = SMAX
maximum scheduled
each node is allowed to transmit Example: network address
exactly once during scheduled time node #3 waits one slot time
(implied token) because node #2 was This boundary moves from NUT to NUT
missing depending on the utilization
nodes wait one slot time for each missing of scheduled time
node (MAC ID) from 0 to SMAX
Figure 8 – Media access during scheduled time
During the unscheduled part of the NUT, each node from 0 to UMAX shares the opportunity to
transmit one DLPDU of non-time critical data in a round robin fashion, until the allocated NUT
duration is exhausted. UMAX is the MAC ID of the highest numbered node that has access to

– 34 – 61158-4-2 © IEC:2007(E)
the medium during the unscheduled part of the NUT. The round robin method of access
opportunity enables every node between 0 and UMAX to have zero, one or many
opportunities to send unscheduled data depending on how much of the NUT remains after the
completion of the scheduled time. Variations in scheduled traffic means the opportunity to
access the medium during the unscheduled time may be different for each node in every NUT.
Figure 9 shows how the permission to transmit is granted during the unscheduled time. The
MAC ID of the node that goes first in the unscheduled part of the NUT is incremented by 1 for
each NUT. The unscheduled token begins at the MAC ID specified in the unscheduled start
register (USR) of the previous moderator DLPDU. The USR increments by one modulo
(UMAX+1) each NUT. If the USR reaches UMAX before the guardband, it returns to zero and
the token pass continues.
Tim e
0
1
2
7
8 8
9 9 9
10 10
11 11
12 UMAX
maximum unscheduled
MAC ID
--`,,```,,,,````-`-`,,`,,`,`,,`---
permission to transmit is passed each node gets several or no
on a round-robin basis MAC ID from start of previous opportunities to transmit,
interval plus one gets first based on available NUT time
opportunity to transmit and other unscheduled traffic
nodes wait one slot time for each one MAC frame in interval
missing node (MAC ID) from 0 to UMAX
plus one
Figure 9 – Media access during unscheduled time
When the guardband is reached, all nodes stop transmitting. A node is not allowed to start a
transmission unless it can be completed before the beginning of the guardband. During the
guardband, the node with the lowest MAC ID (called the “moderator”) transmits a
maintenance message (called the “moderator DLPDU”) that accomplishes two things:
— it keeps the NUT timers of all nodes synchronized;

— it publishes critical link parameters enabling all members of the local DLL group to share a
common version of important DLL values such as NUT, slot time, SMAX, UMAX, etc.
The moderator transmits the moderator DLPDU, which re-synchronizes all nodes and restarts
the NUT. Following the receipt of a valid moderator DLPDU, each node compares its internal
values with those transmitted in the moderator DLPDU. A node using link parameters that
disagree with the moderator disables itself. If the moderator DLPDU is not heard for 2
consecutive NUTs, the node with the lowest MAC ID assumes the moderator role, and begins
transmitting the moderator DLPDU in the guardband of the third NUT. A moderator node that
notices another node on-line and transmitting with a MAC ID lower than its own immediately
cancels its moderator role.
Typical situations that may cause disruption of the DLL access protocol include
— induced noise on the link;

— poor cable or termination quality;

61158-4-2 © IEC:2007(E) – 35 –
— physically connecting two links together while the network is operating.
One common consequence of such disruption is that nodes may be caused to disagree as to
which node should be transmitting; this is called a network “non-concurrence”. Another
potential problem occurs when the nodes do not agree to the same link configuration
parameters. A node that disagrees with the link parameters as transmitted by the moderator is
called a “rogue” and immediately stops transmitting. The DLL access protocol is designed to
recover a rogue node and bring it back on-line.
5.3 DLPDU structure and encoding
5.3.1 General
DLPDUs are the DLPDUs passed to the Ph layer for sending on the Ph medium. The DLPDUs
are formed by the transmit logical link control (TxLLC) protocol in two stages:
— DLSDUs are formed into Link-units (Lpackets);

— Multiple Lpackets are packed into one DLPDU subject to constraints set by the QoS
required, the type of access opportunity available and limits on DLPDU overall length.
5.3.2 DLPDU components
The general DLPDU structure is shown in Figure 10 and managed by the DLL support units
TxFramer, RxFramer, Octet Serializer and Octet Deserializer as shown in Figure 2.
The components of the DLPDU shall be transmitted in the following order: preamble, start
delimiter, source MAC ID, zero or more Lpackets, FCS and end delimiter.
Mframe
START SOURCE END

PREAMBLE Lpackets FCS
DELIMITER MAC ID DELIMITER
(16 bits) (8 bits) (8 bits) 0 to 510 octets (16 bits) (8 bits)
Lpacket Lpacket ••• Lpacket
Figure 10 – DLPDU format
5.3.3 Preamble
The preamble shall be composed of 16 consecutive {1} M_Symbols.
5.3.4 Start and end delimiters

--`,,```,,,,````-`-`,,`,,`,`,,`---
The start delimiter shall consist of these M_Symbols, {+, 0, –, +, –, 1, 0, 1}, transmitted from
left to right.
The end delimiter shall consist of these M_Symbols, {1, 0, 0, 1, +, –, +, –}, transmitted from
left to right.
The use of non-data M_Symbols shall be reserved for the start and end delimiters.

– 36 – 61158-4-2 © IEC:2007(E)
5.3.5 DLPDU octets and ordering
The source MAC ID, Lpackets, and FCS shall be composed of octets. An octet shall be
composed of exactly eight M_Symbols each of which shall be either {0} or {1}. An octet shall
be transferred to the PhL low bit first. Multiple octet fields shall be transmitted low order octet
first (little endian format).
5.3.6 Source MAC ID
The source MAC ID address shall be a single octet as specified in 4.3.2. A node may also
temporarily assume a MAC ID of zero to perform link maintenance.
--`,,```,,,,````-`-`,,`,,`,`,,`---
5.3.7 Lpackets field
Zero or more Lpackets shall be concatenated into a single DLPDU subject to the constraint
that the maximum number of octets which compose all Lpackets in a DLPDU shall be 510.
An additional constraint is that DLPDUs sent during a scheduled access opportunity shall only
contain Lpackets with a QoS parameter of scheduled.
5.3.8 Frame check sequence (FCS)
5.3.8.1 Frame check sequence requirements
The FCS shall be a modified CCITT checksum using the 16 bit polynomial:
G(X) = X 16 + X 12 + X 5 + 1. A two octet FCS shall be included in each DLPDU.
The formal concepts for its generation and checking on reception are described in 5.3.8.2.
The generation and checking of the FCS are further specified in 9.7 and 9.8.
5.3.8.2 Frame check sequence formal concepts
5.3.8.2.1 Frame check sequence field
Within this subclause, any reference to bit K of an octet is a reference to the bit whose weight
in a one-octet unsigned integer is 2 K .
NOTE This is sometimes referred to as “little endian” bit numbering.
For this standard, as in other International Standards (for example, ISO/IEC 3309,
ISO/IEC 8802 and ISO/IEC 9314-2), DLPDU-level error detection is provided by calculating
and appending a multi-bit frame check sequence (FCS) to the other DLPDU fields during
transmission to form a "systematic code word" 3 of length n consisting of k DLPDU message
bits followed by n - k (equal to 16) redundant bits, and by calculating during reception that
the message and concatenated FCS form a legal (n,k) code word. The mechanism for this
checking is as follows, where the generic form of the generator polynomial for this FCS
construction is specified in equation (4) and the polynomial for the receiver’s expected
residue is specified in equation (9). The specific polynomials for this standard are specified in
Table 7.
3 W. W. Peterson and E. J. Weldon, Jr., Error Correcting Codes (2nd edition), MIT Press, Cambridge, 1972.

61158-4-2 © IEC:2007(E) – 37 –
Table 7 – FCS length, polynomials and constants
Item Value
n-k 16
G(X) X 16 + X 12 + X 5 + 1 (notes 1, 2)
R(X) X 12 + X 11 + X 10 + X 8 + X 3 + X 2 + X + 1 (notes 2, 3)
NOTE 1 Code words D(X) constructed from this G(X) polynomial have Hamming distance 4 for lengths ≤ 4 095
octets, and all errors of odd weight are detected.
NOTE 2 These are the same polynomials and method as specified in ISO/IEC 3309 (HDLC).
NOTE 3 The remainder R(x) should be 0001 1101 0000 1111 (X 15 to X 0 , respectively) in the absence of errors.
5.3.8.2.2 At the sending DLE
The original message (that is, the DLPDU without an FCS), the FCS, and the composite
message code word (the concatenated DLPDU and FCS) shall be regarded as vectors M(X),
F(X), and D(X), of dimension k, n - k, and n, respectively, in an extension field over GF(2). If
the message bits are m 1 … m k and the FCS bits are f n-k-1 … f 0 , where
m1 … m8 form the first octet sent,
m 8N-7 … m 8N form the Nth octet sent,
f7 … f0 form the last octet sent, and
m1 is sent by the first PhL symbol(s) of the message and f 0 is sent by the
last PhL symbol(s) of the message (not counting PhL framing
information),
NOTE 1 This “as transmitted” ordering is critical to the error detection properties of the FCS.
then the message vector M(X) shall be regarded to be

M(X) = m 1 X k-1 + m 2 X k-2 + … + m k-1 X 1 + m k (1)
and the FCS vector F(X) shall be regarded to be

F(X) = f n-k-1 X n-k-1 + … + f 0 ( 2)
= f 15 X 15 + … + f 0
The composite vector D(X), for the complete DLPDU, shall be constructed as the
concatenation of the message and FCS vectors
D(X) = M(X) X n-k + F(X) (3)
= m 1 X n-1 + m 2 X n-2 + … + m k X n-k + f n-k-1 X n-k-1 + … + f 0
= m 1 X n-1 + m 2 X n-2 + … + m k X 16 + f 15 X 15 + … + f 0 (for the case of k = 15)
The DLPDU presented to the PhL shall consist of an octet sequence in the specified order.
The redundant check bits f n-k-1 … f 0 of the FCS shall be the coefficients of the remainder
F(X), after division by G(X), of L(X) (X k + 1) + M(X) X n-k
where G(X) is the degree n-k generator polynomial for the code words
G(X) = X n-k + g n-k-1 X n-k-1 + … + 1 (4)
and L(X) is the maximal weight (all ones) polynomial of degree n-k-1
L(X) = (X n-k + 1) / (X + 1) = X n-k-1 + X n-k-2 + … + X + 1 (5)
= X 15 + X 14 + X 13 + X 12 + … + X 2 + X + 1 (for the case of k = 15)
That is,
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 38 – 61158-4-2 © IEC:2007(E)
F(X) = L(X) (X k + 1) + M(X) X n-k (modulo G(X)) (6)

NOTE 2 The L(X) terms are included in the computation to detect initial or terminal message truncation or
extension by adding a length-dependent factor to the FCS.
NOTE 3 As a typical implementation when n-k = 16, the initial remainder of the division is preset to all ones. The
transmitted message bit stream is multiplied by X n-k and divided (modulo 2) by the generator polynomial G(X),
specified in equation (7). The ones complement of the resulting remainder is transmitted as the (n-k)-bit FCS, with
the coefficient of X n-k-1 transmitted first.
The equation for D(X) does not apply to the Type 8 protocol because that protocol sends the
message and check bits in separate DLPDUs. The equation for F(X) as just given does not
apply to the Type 8 protocol because that protocol does not complement the check bits before
transmission. The equation corresponding to F(X) for the Type 8 protocol is
F Type 8 (X) = L(X) X k + M(X) X n-k (modulo G(X)) (7)
NOTE 4 As a typical implementation for the Type 8 protocol, the initial remainder of the division is preset to all
ones. The transmitted message bit stream is multiplied by X n-k and divided (modulo 2) by the generator polynomial
G(X), specified in equation (7). The resulting remainder without ones complementation is transmitted as the (n-k)-
bit FCS, with the coefficient of X 0 transmitted first.
--`,,```,,,,````-`-`,,`,,`,`,,`---
5.3.8.2.3 At the receiving DLE
NOTE 1 This subclause does not apply to the Type 8 protocol.
The octet sequence indicated by the PhE shall be concatenated into the received DLPDU and
FCS, and regarded as a vector V(X) of dimension u
V(X) = v 1 X u-1 + v2 X u-2 + … + vu-1 X + vu (8)
NOTE 2 Because of errors u can be different than n , the dimension of the transmitted code vector.
A remainder R(X) shall be computed for V(X), the received DLPDU and FCS, by a method
similar to that used by the sending DLE (see 5.3.8.2.2) in computing F(X)
R(X) = L(X) X u + V(X) X n-k (modulo G(X)) (9)
= r n-k-1 X n-k-1 + … + r 0
Define E(X) to be the error code vector of the additive (modulo-2) differences between the
transmitted code vector D(X) and the received vector V(X) resulting from errors encountered
(in the PhS provider and in bridges) between sending and receiving DLEs.
E(X) = D(X) + V(X) (10)
If no error has occurred, so that E(X) = 0, then R(X) will equal a non-zero constant remainder
polynomial
R ok (X) = L(X) X n-k (modulo G(X)) (11)
whose value is independent of D(X). Unfortunately R(X) will also equal R ok (X) in those cases
where E(X) is an exact non-zero multiple of G(X), in which case there are “undetectable”
errors. In all other cases, R(X) will not equal R ok (X); such DLPDUs are erroneous and shall
be discarded without further analysis.
NOTE 3 As a typical implementation, the initial remainder of the division is preset to all ones. The received bit
stream is multiplied by X n-k and divided (modulo 2) by the generator polynomial G(X), specified in equation (8).
5.3.9 Null DLPDU
A DLPDU with an empty Lpacket field, called a null DLPDU, shall be sent by a node to
indicate that it has no data to send at the QoS allowed by the access opportunity.
5.3.10 Abort DLPDU
To abort a partially transmitted DLPDU, the Data Link Layer shall transmit the following
sequence:

61158-4-2 © IEC:2007(E) – 39 –
— one 0xFF octet;

— start delimiter;
— end delimiter.
start source start end

preamble data 0xFF
delimiter MAC ID delimiter delimiter
2 start delimiters not separated by an end delimiter identify

this as an aborted Mframe.
Figure 11 – Aborting a DLPDU during transmission

NOTE 1 Some implementations of this specification may build the DLPDU as it is being transmitted. If a higher
layer has provided only a partial DLPDU to the Data Link Layer, and the DLL has begun transmission of the DLPDU
assuming that the rest will be provided shortly, a transmit underflow occurs if the rest of the DLPDU is not provided
to the DLL soon enough to complete the transmission.
NOTE 2 Although the DLL assembles the entire DLPDU including delimiters, the PhL performs start and end
delimiter detection. The PhL identifies a transmit abort as a DLPDU which includes two start delimiters which are
not separated by an end delimiter, as shown in Figure 11.
NOTE 3 The 0xFF octet is inserted before the start delimiter / end delimiter pair to avoid violating PhL constraints
governing consecutive physical symbol relationships on the media.
5.4 Lpacket components
5.4.1 General Lpacket structure
The Lpacket (or link unit) is the PDU which is used to carry DLSDUs between peer DLS users.
The components of the Lpacket shall be transmitted in the following order: size, control, tag,
and link data as shown in Figure 12.
Lpacket
(1 octet) (1 octet) (2 or more octets) (0 - 506 octets)
size control tag link data
Figure 12 – Lpacket format
5.4.2 Size
The size field shall specify the number of octet pairs (from 3 to 255) contained in an individual
Lpacket. The number of octet pairs shall include the size, control, tag, and link data fields
counted in accordance with the following rules:
— combined, the size and control shall count as a single octet pair;
— the number of octet pairs from the tag and link data fields shall be counted separately and
odd octet counts shall be rounded up;
— although the counting of octet pairs is done independently, the format of an Lpacket as
placed into a DLPDU shall not include the extra octets caused by the round up.
NOTE For example, an Lpacket with a 3 octet tag (2 octet pairs) and a 9 octet link data (5 octet pairs) has a size
field of 1+2+5 = 8 octet pairs; however the Lpacket occupies 2+3+9 = 14 octets in the DLPDU.
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 40 – 61158-4-2 © IEC:2007(E)
5.4.3 Control
5.4.3.1 Bit 0 and Bit 4 (type of Lpacket)
The bits of the control field shall be numbered 0 to 7, where bit 0 shall be the least significant
bit of the control field. Bit 0 shall indicate the type of Lpacket.
— When set (bit 0 = 1), the Lpacket shall be a fixed tag Lpacket (see 4.3.4).
— When clear (bit 0 = 0), the Lpacket shall be a generic tag Lpacket (see 4.3.3).
Bit 4 of the control field shall be the inverse of bit 0. If bit 0 is clear, then bit 4 shall be set. If
bit 0 is set, then bit 4 shall be clear.
5.4.3.2 Bit 1 (odd tag size)
Bit 1 of the control field shall indicate whether the tag field contains an even or odd number of
octets. When clear (bit 1 = 0), this bit shall indicate that the tag contains an even number of
octets. When set (bit 1 = 1), it shall indicate that the tag contains an odd number of octets.
5.4.3.3 Bit 2 (odd link data size)
--`,,```,,,,````-`-`,,`,,`,`,,`---
Bit 2 of the control field shall indicate whether the link data contains an even or odd number of
octets. When clear (bit 2 = 0), this bit shall indicate that the link data contains an even
number of octets. When set (bit 2 = 1), it shall indicate that the link data contains an odd
number of octets.
5.4.3.4 Bits 3, 5, 6 and 7 (reserved bits)
Bits 3, 5, 6 and 7 of the control field are reserved and shall be zero.
5.4.4 Generic tag Lpackets
Generic link-units are formed from the DLS-generic-tag and DLS-user-data provided by the
DLS user with the addition of size and control field information for generic tags as shown in
Figure 13. The 3 octet generic tag address (see 4.3.3) shall identify the connected mode
information carried in the link data field
Lpacket
(1 octet) (1 octet) (3 octets) (0 - 504 octets
size control generic tag address link data
Figure 13 – Generic tag Lpacket format
The minimum length generic tag Lpacket shall be 5 octets (minimum link data size of
0 octets). The maximum size of link data shall be 504 octets.
NOTE Generic Lpackets are usually connection mode transfers with the QoS value of scheduled or low.
5.4.5 Fixed tag Lpackets
Fixed tag link-units are formed from the DLS-fixed-tag and DLS-user-data provided by the
DLS user with the addition of size and control field information for fixed tags as shown in
Figure 14. The 2 octet fixed tag address (see 4.3.4) shall identify the service access point in
the the destination node and the address of the destination node.

61158-4-2 © IEC:2007(E) – 41 –
Lpacket
(1 octet) (1 octet) (2 octets) (3 - 506 octets)
--`,,```,,,,````-`-`,,`,,`,`,,`---
size control fix ed tag address link data
service destination
fix ed tag MAC ID
Figure 14 – Fixed tag Lpacket format
The minimum length fixed tag Lpacket shall be 7 octets (minimum link data size of 3 octets).
The maximum size of link data shall be 506 octets.
NOTE Fixed Lpackets are always connectionless mode transfers. They are not usually sent with the QoS
parameter value scheduled.
5.5 DLPDU procedures
5.5.1 General
The transmission protocol combines one or more Lpackets into single DLPDUs for sending
according to the available transmission opportunity. The DLPDU components are passed to
the Ph layer by the transmit machine framer (TxM) and Serializer (see 9.3).
A node shall always send one DLPDU at each valid access opportunity for it to transmit, and
no DLPDU shall include Lpackets with a lesser QoS parameter than the QoS value applicable
to the access opportunity.
If a node has no Lpackets available at or better than the QoS of the access opportunity, then
a Null DLPDU shall be sent.
If for internal reasons a node begins a DLPDU and is unable to complete it, the abort
sequence shall be sent, transmission shall stop for that access opportunity and the local DLS
user shall be notified.
NOTE Null DLPDUs and abort DLPDUs provide an efficiency improvement as they notify other nodes that use of
the transmission slot has ended and enable the next node to begin transmission without waiting for slot time out.
Each Lpacket in the queue awaiting transfer has an associated local identifier. At completion
of the transfer to the PhL, or an aborted transfer, the local identifier is returned to the local
DLS user with a status confirmation of OK or T XA BORT .
The DLS user has additional local services to identify unsent Lpackets and request they are
flushed from the queue, this action results in the confirmation status of FLUSHED being
returned with the local identifier for Lpackets that have been flushed.
5.5.2 Sending scheduled DLPDUs
Scheduled DLPDUs are normally used for transfer of connected mode operation using
Generic Lpackets. They are formed by concatenating multiple Lpackets (subject to a limit of
510 octets), prepending Ph-control information and source station MAC ID, and appending a
defined frame check sequence and further Ph-control information.
Lpackets are packed into a Scheduled DLPDU in FIFO order as received from the DLS user,
until the queue is empty of packets with Scheduled QoS or the next such Lpacket size
exceeds the remaining space.
– 42 – 61158-4-2 © IEC:2007(E)
5.5.3 Sending unscheduled DLPDUs
Unscheduled DLPDUs may contain both Generic Lpackets and Fixed Lpackets. They are
formed by concatenating multiple Lpackets (subject to a limit of 510 octets), prepending Ph-
control information and source station MAC ID, and appending a defined frame check
sequence and further Ph-control information.
Lpackets are packed into an unscheduled DLPDU in QoS priority order (Scheduled, High and
Low priorities respectively). Within each QoS, the FIFO order of queuing by the DLS user is
followed, until the queue is empty or the next such Lpacket size exceeds the remaining space.
5.5.4 Receiving DLPDUs
5.5.4.1 Unpacking
Received DLPDUs are assembled from the incoming Ph stream of symbols and unpacked by
the Octet Deserializer, Receive Machine Framer (RxM) and Receive Logical Link Control
(RxLLC) functions in two stages
— a frame check sequence is computed over the stream of received octets, (excluding Ph
delimiters) and checked for the proper residual value, if this is correct, then
— each Lpacket contained in the DLPDU is examined to extract its tag. Each extracted tag is
then compared with the contents of a local tag filter to determine if the associated Lpacket
is of interest to the receiving station. Lpackets whose tags match the tag filter are then
processed further and passed to the DL user, DL management or used inside the DLL.
Indications passed to the DL user or DL management include Lpacket size, Lpacket tag
and Lpacket data. In addition for fixed tag Lpackets, the source ID is also indicated.
5.5.4.2 Tag filtering
Each local DLS provider maintains a list of tags used to identify Lpackets of interest to its DL
user or its internal DL management functions. The DL user may access and change this list to
specify
--`,,```,,,,````-`-`,,`,,`,`,,`---
— generic tags of interest
— fixed tags of interest
NOTE A generic tag specifies the Lpackets for a single connection-mode object. A fixed tag specifies all
connectionless-mode messages in a particular class, for example Time distribution .
5.6 Summary of DLL support services and objects
The operation and coordination of participating DLL providers is governed by variables and
attributes held in DL management objects or provided by the DL user services listed in
Table 8. Access to these items is via defined fixed tag addresses, DL user services or
unspecified local services. Details are given in the listed clauses.

61158-4-2 © IEC:2007(E) – 43 –
Table 8 – DLL support services and objects
DLL item Description Location
DLS user services see IEC

61158-3-2
connected mode a local service for requesting, indicating and confirming generic tag see 6.2.2
transfer service (connected mode) data transfer by Lpackets
connectionless a local service for requesting, indicating and confirming generic tag see 6.2.2
mode transfer (connected mode) data transfer by Lpackets
service
queue maintenance a local service for flushing unsent Lpacket messages from the internal DL see 6.2.3
service service queue
tag filter service a local service for the DLS user to inform its local DL provider which see 6.2.4
Lpacket tags and tag types are to be accepted and processed by the DLL
or passed to the DL user
link synchronization a local service for informing the local DLS user of the current NUT number see 6.2.5
service to maintain schedule pointers
synchronized a local service for loading and changing local lists of current and pending see 6.2.6
parameter change DL configuration data and in conjunction with the tMinus-start-countdown
service and tMinus- service and moderator DLPDU, to manage an accurately timed change
start-countdown over to new DL link configurations
event reports local services to report various events for use by management see 6.2.7
service
bad FCS service see 6.2.8
current moderator see 6.2.9
power-up and on- see 6.2.10
line
enable moderator see 6.2.11
listen only see 6.2.12
Generic tag service an Lpacket service for connected mode communication see 6.3
Fixed tag services a range of Lpacket service addresses for various connectionless mode see 5.4.5
communication
moderator an Lpacket broadcast in every NUT for managing time precision and timing see 6.4
for change of link parameters
time distribution an Lpacket for publishing time values and offsets used in coordinating the see 6.5
service same time sense in all stations
UCMM an Lpacket service to transfer DLSDUs from a DLS user to the see 6.6
Unconnected Message Manager in a peer DLS-user
Keeper UCMM an Lpacket service to transfer DLSDUs from a DLS user to the Keeper see 6.7
objects in other nodes
TUI an Lpacket broadcast to all stations assisting their synchronization to the see 6.8
current link configuration
link parameters an Lpacket service for publishing pending link parameters in advance of a see 6.9
synchronized change of link operating conditions
tMinus an Lpacket service to start a count down leading to a change of link see 6.9
parameters and return the result.
I’m alive an Lpacket broadcast by new and reset devices to assist their entry into an see 6.10
operating system
ping request and an Lpacket service soliciting identification responses from all other active see 6.11
reply devices on the link
--`,,```,,,,````-`-`,,`,,`,`,,`---
WAMI an Lpacket allowing temporary devices to identify a local device MAC ID see 6.12
when they are plugged into its network access port
debug an Lpacket service to trace object state transitions see 6.13

– 44 – 61158-4-2 © IEC:2007(E)
DLL item Description Location

Objects
ControlNet object holds and distributes station management data classes and instances for see 7.2
Ph and DL layers, also collects diagnostic information for use by other
DLS-user entities
Keeper object accessed via the Keeper UCMM, or general UCMM fixed tag, to provide a see 7.3
range of support services for link operation, schedules and connections
holds link data and attributes for all devices on a link
keeps copies of all connection originator data for connection originating
devices in a network
negotiates with other Keeper objects on a link to agree on master Keeper
and backup Keeper roles
when master Keeper distributes link attributes to all nodes and keeps
backup Keepers synchronized
regularly issues TUI Lpacket to ensure all stations are synchronized to the
current links configuration
manages the network resource semaphore enabling orderly modification of
link attribute data
Scheduling object provides services to external link scheduling software in support of see 7.4
read/write for connection and schedule information from involved devices
stores the current schedule details and connection password in the Keeper
TCP/IP Interface provides the mechanism to configure the TCP/IP interface of a device see 7.5
object
Ethernet Link object maintains link-specific counters and status information for a physical see 7.6
Ethernet ISO/IEC 8802-3 port
DeviceNet object holds and distributes station management data classes and instances for see 7.7
Ph and DL layers, also collects diagnostic information for use by other
DLS-user entities
Connection provides an interface to create, configure and control connections in a see 7.8
Configuration object device
--`,,```,,,,````-`-`,,`,,`,`,,`---
6 Specific DLPDU structure, encoding and procedures
6.1 Modeling language
6.1.1 State machine description
Some of the components of the Data Link Layer are specified using a state machine
description language. The action statement is expressed in C++. Other components do not
require a state machine description and are specified using only C++.
A state machine is described using the following syntax, where * indicates repetition of one or
more of the preceding component, and {} indicates an optional component:
state-machine :=
<header-statements>
state*
state :=
“state:” <state-name>
transition*
transition :=
“event:” <event-expression>
{“condition:” <condition-expression>}
“destination:” <state-name>
{“action:” <action-statements>}
State-names are legal C++ identifiers, event-expressions and condition-expressions are C++
expressions, and header-statements and action-statements are lists of C++ statements.

61158-4-2 © IEC:2007(E) – 45 –
Header-statements include
— #include and #define;

— variable and interface declarations;
— subroutine definitions.
An event-expression indicates the specified event when the value of the expression is TRUE.
An event is required to trigger a transition. A condition-expression qualifies a transition. A
qualified transition occurs when its event occurs if the condition is true at the time of the
event. In general, event-expressions are FALSE upon entry into a state. There are a few
cases where an event-expression may be true upon entry to a state. In these cases, the
transition takes place immediately.
Action statements are executed when the transition is triggered.
All the event triggers and conditions of the current state are evaluated continuously and
concurrently until a given transition is enabled. All expressions and statements execute
instantaneously. The following model illustrates the precedence of the various parts of a
transition:
if(the event has occurred && the condition is true)
{
do the actions;
go to the destination;
}
Implementations may use other code or syntax, however the implementation performance
shall be equivalent to that specified except for internal execution timing and local variables
6.1.2 Use of DLL- prefix
The primitives and parameters described in IEC 61158-3-2 use the following prefixes:
DL- for data link

DLS- for DL-link service
DLMS- for DL-management service.
Within this Type 2: Data Link Protocol Specification, the generic prefix DLL- is used as
equivalent to the appropriate service description prefix.
6.1.3 Data types
The data types used in the data link variables, parameters, state machines and example code
are specified in IEC 61158-5-2.
The specification of data types corresponds to the notation of IEC 61131-3. A list of the
elementary data types, their corresponding description and some of their valid values is
shown in Table 9. Additional detail is specified in IEC 61158-6-2.
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 46 – 61158-4-2 © IEC:2007(E)
Table 9 – Elementary data types
Range
Keyword Description
Minimum Maximum
BOOL Boolean
SINT Short Integer -128 127
INT Integer -32 768 32 767
DINT Double Integer -2 31 2 31 -1
LINT Long Integer -2 63 2 63 -1
USINT Unsigned Short Integer 0 255
UINT Unsigned Integer 0 65 535
UDINT Unsigned Double Integer 0 2 32 -1
ULINT Unsigned Long Integer 0 2 64 -1
REAL Floating point
LREAL Long float
ITIME Duration (short)
TIME Duration
FTIME Duration (high resolution)
LTIME Duration (long)
DATE Date only
TIME_OF_DAY or TOD Time of day
DATE_AND_TIME or DT Date and time of day
STRING character string (1 octet per character)
STRING2 character string (2 octet per character)
STRINGN character string (N octets per character)
SHORT_STRING character string (1 octet per character,
1 octet length indicator)
SWORD bit string - 8 bits
WORD bit string - 16-bits
DWORD bit string - 32-bits
LWORD bit string - 64-bits
6.2 DLS user services
6.2.1 General
The DLL user services provided to the DLS user have the following interfaces used for the
specified purposes. The related service definitions and time sequence diagrams are given in
IEC 61158-3-2.
6.2.2 Connected mode and connectionless mode transfer service
6.2.2.1 Service encoding
The request and confirmation services used to queue the sending of Lpackets by the DLL
shall be of the following forms.
a) Connection mode transfers use Generic tag request and confirmation.
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 47 –
DLL_xmit_generic_request( DLL_xmit_generic_confirm(
IDENTIFIER id, IDENTIFIER id,
USINT Lpacket[], TXSTATUS status );
UINT Lpacket_size,
PRIORITY priority,
USINT gentag[3] );
b) Connectionless mode transfers use Fixed tag request and confirmation.
DLL_xmit_fixed_request( DLL_xmit_fixed_confirm(
USINT Lpacket[], TXSTATUS status );
UINT Lpacket_size,
PRIORITY priority,
USINT service,
USINT destID );
c) Connection mode transfers use Generic tag indication.
DLL_recv_generic_indication(
USINT Lpacket[]
UINT Lpacket_size,
USINT gentag[3] );
d) Connectionless mode transfers use Fixed tag indication.
DLL_recv_fixed_indication(
USINT Lpacket[],
UINT Lpacket_size,
USINT service,
USINT sourceID );
6.2.2.2 Procedures for request and confirmation
The Lpacket parameter shall contain the DLSDU as an ordered sequence of octets. The
Lpacket_size parameter shall specify the number of octets contained in the Lpacket
array. The QoS priority shall specify onto which internal queue the request shall be placed
and shall be one of LOW, HIGH or SCHEDULED. Only Lpackets on the SCHEDULED queue may
be sent during the scheduled portion of the NUT. The unscheduled portion of the NUT shall
be used to transmit Lpackets from the HIGH and LOW QoS priority queues, and may be used
to transmit Lpackets from the SCHEDULED queue. The queues shall be prioritized such that,
during an unscheduled transmit opportunity, the SCHEDULED queue is emptied first, then the
HIGH QoS priority queue is emptied second, and finally the LOW QoS priority queue is emptied
last.
The IDENTIFIER, id, shall correlate a confirmation with a corresponding request. The
status parameter shall return the status of the attempted transmit and shall be one of OK,
T X A BORT or FLUSHED .
The DLL_xmit_fixed_request service queues an Lpacket with a two octet fixed tag for
transmit. The service parameter shall specify the first octet of the fixed tag Lpacket. The
destID parameter shall specify the second octet, which shall determine the MAC ID of the
destination node.
The remaining parameter, gentag, of the DLL_xmit_generic_request service shall

specify on which generic tag to transmit the Lpacket.
NOTE 1 The use of one or more queues for different priorities is an internal implementation choice.
NOTE 2 Assembly of the related Lpacket structure and the procedure for its sending on the link are described in
their respective clauses (see 5.3 and 5.4).
6.2.2.3 Procedures for indication

--`,,```,,,,````-`-`,,`,,`,`,,`---
These indications shall signal the delivery of an Lpacket with a good FCS. Only fixed tag
Lpackets which have had their service enabled by a successful call to
DLL_enable_fixed_request shall cause a DLL_recv_fixed_indication. Only generic
tag Lpackets which have had their generic tag enabled by a successful call to
DLL_enable_generic_request shall cause a DLL_recv_generic_indication.

– 48 – 61158-4-2 © IEC:2007(E)
The array of octets, Lpacket, shall contain the DLSDU as an ordered sequence of octets.
The integer, Lpacket_size, shall specify the number of octets contained in the Lpacket
array.
6.2.3 Queue maintenance service
Once queued, an Lpacket shall remain in a transmit queue until it is transmitted or de-queued.
The request and confirmation services used to de-queue an Lpacket, before it is transmitted,
shall be of the form:
DLL_flush-requests-by-QoS_request( PRIORITY priority );
DLL_flush-requests-by-QoS_confirm( PRIORITY priority );
DLL_flush_single_request( PRIORITY priority, IDENTIFIER id );
DLL_flush-requests-by-QoS_request shall cancel all pending transmits at the specified

QoS priority. Each pending transmit shall immediately terminate with a confirmation
containing the FLUSHED status. DLL_flush_single_request shall cancel a specific
Lpacket identified by the id used to transmit the Lpacket. This service need not have a
corresponding confirmation since the confirmation of the queued Lpacket shall serve this
purpose.
6.2.4 Tag filter service
By default, the Data Link Layer shall only process the moderator Lpacket (fixed tag 0x00), and
all other Lpackets shall be discarded. Other protocol layers may enable or disable reception
of specific Lpackets using the following services;
DLL_enable_generic_request( DLL_enable_generic_confirm(
USINT gentag[3] ); BOOL result );
DLL_disable_generic_request( DLL_disable_generic_confirm(
USINT gentag[3] ); BOOL result );
DLL_enable_fixed_request( DLL_enable_fixed_confirm(
USINT service ); BOOL result );
DLL_disable_fixed_request( DLL_disable_fixed_confirm(
USINT service ); BOOL result );
parameter, result, shall return TRUE if the request was successful and FALSE if
unsuccessful. The gentag parameter shall specify which generic tag to route to the higher
layer that enabled the tag; likewise, the service parameter shall specify which fixed tag to
route to the higher layer that enabled the tag.
NOTE The DLL_enable_generic_request service can return an unsuccessful result if the implementation of
the Data Link Layer is unable to filter any more generic tags.
6.2.5 Link synchronization service
The indication that a new network update time (NUT) has begun shall be of the form:
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 49 –
DLL_tone_indication( USINT cycle );

6.2.5.2 Procedures for indication
The parameter cycle shall return the interval counter from the moderator DLPDU just
received.
NOTE If a moderator DLPDU is expected but does not arrive, the local node simulates the reception of the
moderator DLPDU based on an internal timer of the ACM.
6.2.6 Synchronized parameter change service
All nodes on a link shall maintain two copies of link parameters: current and pending. The
current copy of link parameters shall be used for the on going operation of the Data Link
Layer. The pending copy shall be maintained to allow a synchronized change of link
parameters. The local DLL user services that read and write these link parameters shall be of
the form:
DLL_set_pending_request( DLL_set_pending_confirm(
DLL_config_data params ); BOOL result );
DLL_set_current_request( DLL_set_current_confirm(
DLL_config_data params ); BOOL result );
DLL_get_pending_request( DLL_get_pending_confirm(
IDENTIFIER id ); IDENTIFIER id,
DLL_config_data params );
DLL_get_current_request( DLL_get_current_confirm(
IDENTIFIER id ); IDENTIFIER id,
DLL_config_data params );
The DLL_config_data shall contain the link parameters and be of the form:
class DLL_config_data
{
public:
USINT myaddr; // the MAC ID of this node
UINT NUT_length; // the length of the NUT in 10 μs increments
USINT smax; // highest MAC ID allowed to transmit scheduled
USINT umax; // highest MAC ID allowed to transmit unscheduled
USINT slotTime; // time allowed for line turnaround in 1 μs increments
time to disable RX after DLPDU in 1,6 μs increments
--`,,```,,,,````-`-`,,`,,`,`,,`---
USINT blanking; //
USINT gb_start; // 10 μs intervals from start of guardband to tone
USINT gb_center; // 10 μs intervals from start of moderator to tone
USINT modulus; // modulus of the interval counter
USINT gb_prestart; // transmit cut-off, 10 μs intervals before tone
}; // may not transmit passed this limit
The local DLL user services which request and confirm the start of a tMinus countdown shall
be of the form:
DLL-tMinus-start-countdown-request( DLL-tMinus-start-countdown-confirm(
USINT start_count ); BOOL result );
NOTE The tMinus fixed tag service (see 6.9) is used by the master Keeper to request all stations on the link to
initiate a changeover countdown. This is the local DLL user procedure to request and confirm local participation.
At the correct expiry of the tMinus countdown, each participating station passes a local
indication to its ControlNet object requesting a change from current link parameters to
pending link parameters.
DLL_tminus_zero_indication( );

– 50 – 61158-4-2 © IEC:2007(E)
6.2.6.2 Procedures for request, confirmation and indication
result shall return TRUE if the request was successful and FALSE if unsuccessful.
The moderator Lpacket contains a field, called tMinus, that shall be used to synchronize the
update of the current link parameters. The DLL-tMinus-start-countdown-request shall
cause a node to participate in a tMinus countdown, and, if the node is the moderator, shall
initialize the tMinus field of the moderator Lpacket. The moderator node shall decrement this
field before transmitting each moderator until the field equals zero. When the tMinus field
transitions from 1 to 0, the DLL in each node participating in the countdown shall locally
generate a DLL_tminus_zero_indication and copy its pending link parameters into its
current copy. If the tMinus field transitions to 0 from any value except 1, the countdown shall
be aborted and no DLL_tminus_zero_indication shall be generated.
6.2.7 Event reports service
The indication used to alert the Station Management entity of various events internal to the
Data Link Layer shall be of the form:
DLL_event_indication(
DLL_event event,
USINT mac_id /*[optional]*/ );
The DLL_event, event, shall be one of the events enumerated in Table 10. The mac_id
parameter shall be used in the case of (event = DLL_EV_badFrame); it shall indicate the
source MAC ID of the node that transmitted the bad DLPDU.
NOTE Since the DLPDU was damaged, the source MAC ID may not be correct.
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 51 –
Table 10 – DLL events
DLL events Description
DLL_EV_rxGoodFrame A good DLPDU was received. This shall include DLPDUs that contain no data
(null DLPDUs), but shall exclude moderators
DLL_EV_txGoodFrame A good DLPDU was transmitted. This shall include DLPDUs that contain no
--`,,```,,,,````-`-`,,`,,`,`,,`---
data (null DLPDUs), but shall exclude moderators
DLL_EV_badFrame A damaged DLPDU was received. The optional parameter, which is the
apparent source MAC ID of the offending node, shall also be reported
DLL_EV_errA A bad DLPDU was received on channel A of the physical medium, or a good
DLPDU was received on channel B and ph_frame_indication from channel
A stayed false
DLL_EV_errB A bad DLPDU was received on channel B of the physical medium, or a good
DLPDU was received on channel A and ph_frame_indication from channel
B stayed false
DLL_EV_txAbort A transmit DLPDU was terminated with an abort sequence
DLL_EV_NUT_overrun NUT is not large enough to accommodate all the scheduled traffic
DLL_EV_dribble Scheduled Lpackets could not be sent during scheduled time
DLL_EV_nonconcurrence An event was detected that indicates that this node is out of step with the
access control protocol
DLL_EV_rxAbort A DLPDU was received that was terminated with an abort sequence
DLL_EV_lonely Have not heard a DLPDU from another node on the link for 8 NUTs
DLL_EV_dupNode Another node on the link is using this node’s MAC ID
DLL_EV_noisePulse ph_lock_indication went true then false before ph_frame_indication
went true, but ph_lock_indication was not true long enough to indicate a
possibly damaged DLPDU
DLL_EV_collision ph_frame_indication was true when this node was about to transmit
DLL_EV_invalidModAddress A moderator was received from a node that does not have the lowest MAC ID
on the link
DLL_EV_rogue A moderator DLPDU was received that does not match the link configuration
information at this node
DLL_EV_deafness Cannot hear the moderator DLPDU even though other link traffic is present
DLL_EV_supernode A moderator was received from MAC ID 0
6.2.8 Bad FCS service
The indication used to alert the Station Management entity that a received DLPDU had an
invalid FCS shall be of the form:
DLL_badFCS_indication( CHANNEL channel );
The channel parameter shall indicate which PhL entity provided the DLPDU which was in
error. This parameter shall be one of CHA or CHB, corresponding to PhL channel A and PhL
channel B, respectively. This indication shall be provided, at most, once per error DLPDU per
channel.
6.2.9 Current moderator service
The indication used to inform the Station Management entity which node is currently the
moderator shall be of the form:
DLL_currentMod_indication( USINT macID );
The macID parameter shall indicate the MAC ID of the node that last transmitted a valid
moderator DLPDU.

– 52 – 61158-4-2 © IEC:2007(E)
6.2.10 Power up and online services
The request and confirmation which places the Data Link Layer on-line shall be of the form:
DLL_online_request( BOOL online ); DLL_online_confirm( BOOL online );
The indication that specifies that the Data Link Layer has completed its initialization shall be
of the form:
DLL_powerup_indication( void );
At power-up, the DLL shall wait until the online parameter equals TRUE. The DLL shall then
begin the process of going on-line. When the online parameter is FALSE, the DLL shall go
off-line at the end of the current NUT. When off-line the DLL shall not transmit, and shall
ignore any link activity.
6.2.11 Enable moderator service
The request and confirmation services that enable and disable the ability of a node to assume
the moderator role shall be of the form:
DLL_enable_moderator_request( BOOL enable );
DLL_enable_moderator_confirm( BOOL enable );
When the enable parameter is TRUE, the DLL shall enable the transmission of moderator
DLPDUs. When the enable parameter is FALSE, transmission of moderator DLPDUs shall be
disabled.
NOTE This request is used by station management entities to allow a new node to non-disruptively join a working
link. The moderator switch over protocol does not tolerate the node with the lowest MAC ID suppressing moderator
DLPDUs for an extended period. The Network Attachment Monitor (NAM) re-enables moderator transmission
whenever another device is detected on the link.
6.2.12 Listen only service
The request and confirmation services that allows a device to receive, but disables the ability
of a device to transmit, shall be of the form:
DLL_listen_only_request( BOOL enable );
DLL_listen_only_confirm( BOOL enable );
6.2.12.2 Procedures for request, confirmation and indication
When the enable parameter is TRUE, the Data Link Layer shall participate in the access
--`,,```,,,,````-`-`,,`,,`,`,,`---
protocol and transmit DLPDUs. When the enable parameter is FALSE, transmission of
DLPDUs shall be disabled; however, the ability of the node to receive DLPDUs shall not be
impaired.
6.3 Generic tag Lpacket
6.3.1 General
The generic tag Lpacket is used for transferring connection data. The connection ID or
Generic Tag is a unique identifier for previously negotiated resources and parameters at its

61158-4-2 © IEC:2007(E) – 53 –
source, destination(s) and any intermediate transit points. Only the generic Tag is necessary
to identify the message data.
6.3.2 Structure of the generic-tag Lpacket
The size and control fields shall follow the Generic Tag format. The address shall be the DLS-
generic-tag provided by the local DL-generic-request service. The link data field shall contain
the DLS-user-data provided by the DL-generic-request.
6.3.3 Sending and receiving the generic-tag Lpacket
The sending station shall send the Lpacket at the QoS priority specified by the DL-generic-
request.
The status of each generic tag Lpacket transmission is confirmed to the DL user by returning
the DLS-user-id (an internal handle or identifier) and the DLS Txstatus with one of the
following values.
a) “OK” — message successfully sent;

b) “T XA BORT ” — sending process failed;
c) “ FLUSHED ” — message has been removed from the pending queue before sending.
NOTE 1 Txstatus is a local variable so the coding is not specified.
NOTE 2 The FLUSHED status is only used in response to a deletion requested by the Queue maintenance service
NOTE 3 The parameter value OK is not an indication that the message has been received
All receiving stations whose local Tag Filter service contains an address matching the
received Lpacket address, shall pass each correctly received data unit to its local DL user,
together with the data unit size and the address (the generic tag for the connection).
6.4 Moderator Lpacket
6.4.1 General
The moderator MAC Lpacket is used for DLL management, access timing and
synchronization, it is sent as a moderator DLPDU containing only one Lpacket, the moderator
Lpacket.
6.4.2 Structure of the moderator Lpacket
The size and control fields shall follow the fixed tag format. The address shall be formed from
the moderator fixed tag and 0xFF the broadcast address for all MAC IC nodes on this link.
The link data field shall contain the following in the listed order.
class moderatorLpacket : public fixedLpacket
{
public:
UINT NUT_length; // the length of the NUT in 10 μs increments
USINT slotTime; // 1 μs increments allowed for line turnaround
USINT blanking; // 1,6 μs increments to disable RX after DLPDU
USINT usr; // unscheduled start register
USINT interval_count; // current NUT number (0 to modulus)
USINT tMinus; // countdown to synchronized link parameter change
USINT reserved; //
};
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 54 – 61158-4-2 © IEC:2007(E)
6.4.3 Sending and receiving the moderator Lpacket
The moderator DLPDU containing the moderator Lpacket shall be transmitted once per NUT
by the node with the lowest MAC ID. It shall be sent in the guardband, a fixed part of every
NUT reserved for the moderator DLPDU.
To support DLL management actions, the sender and receivers of the moderator DLPDU shall
use the contents of the moderator link data field as follows.
The NUT_length shall specify the duration of the current NUT. NUT_length shall be a 16 bit
integer representing the number of 10 μs ticks and shall be in the range 50 (500 μs) to 10 000
(100 ms). The beginning of the NUT shall be called the tone. At the tone, a counter that
decrements every 10 μs shall be loaded with the NUT_length.
NOTE 1 Subclause 8.2 further constrains the value of NUT_length.
To guarantee that the link is quiet during moderator transmission, all nodes shall cease
transmitting when their internal counter reaches the value of gb_prestart. All nodes may
then assume that the link is quiet between gb_start and gb_center. When the moderator
node's counter reaches the value of gb_center, it shall begin transmitting a DLPDU
containing only the moderator Lpacket. The moderator Lpacket shall be completely
transmitted at least 30 μs before the decrementing counter would have expired.
NOTE 2 Subclause 8.2 calculates the values of gb_prestart, gb_start, and gb_center to guarantee these
constraints. Factors that affect the calculation of these values include clock accuracy, missing nodes, and
propagation delay between nodes. In all cases, gb_prestart > gb_start > gb_center > 7.
The highest MAC ID transmitting during the scheduled portion of the NUT shall be smax. It
shall be in the range 0 to 254. umax shall determine the highest MAC ID that transmits during
the unscheduled portion of the NUT. It shall be in the range smax to 254. The unscheduled
start register, usr, shall select which node transmits first in the unscheduled portion of the
NUT. The usr shall increment each NUT. This counter shall be updated modulo (umax + 1).
A node shall listen to the PhL directly after it finishes transmitting. blanking shall determine
the amount of time to suspend listening and shall be in 1,6 μs ticks.
The moderator node shall increment an 8 bit counter, called interval_count, once per
NUT. This counter shall be updated modulo (modulus + 1). Since the guardband is at the end
of the NUT, the value of interval_count shall correspond to the NUT that just completed.
NOTE 3 Subclause 8.2 and the specifications of the ControlNet object further constrain the value of smax, umax,
blanking and modulus.
The tMinus field shall maintain a countdown until all nodes adopt new link parameters (see
6.9). The slotTime field shall determine the time to wait for a missing node and shall be in
1,0 μs ticks. An additional 1,0 μs shall be added to the value of the slotTime. The
slotTime field shall be in the range 8 to 254; the other values shall be reserved. The
reserved octet shall be set to zero.
6.5 Time distribution Lpacket
6.5.1 General
The moderator DLPDU provides a common reference marker that is synchronized between all
nodes on the network. By distributing and processing time stamps relative to the reference
--`,,```,,,,````-`-`,,`,,`,`,,`---
instead of to the time distribution message, implementations are simplified whilst accuracy is
improved by several orders of magnitude. Phase and frequency synchronization is inherent in
this DL-protocol to a very high level of accuracy. The accuracy of time synchronization using
the time distribution format defined in this subclause is implementation dependent, however it
can be better than 10 μs.

61158-4-2 © IEC:2007(E) – 55 –
6.5.2 Structure of the time distribution Lpacket
6.5.2.1 Packet format
the time distribution fixed tag and 0xFF the broadcast address. The link data field shall
contain the following in the listed order:
class TimeDist_Lpacket : public fixedLpacket
{
public:
USINT revision; // revision of time distribution format
USINT leap; // leap second offset
UINT goodness; // time relay control field
DINT gse; // global squared error relative to ultimate master
LINT dctz; // distribution channel time zero
LINT ts_ref; // time stamp of previous reference pulse
LINT ts_tx; // time stamp of this message's transmission
};
6.5.2.2 Revision
The revision parameter shall be set to zero. This parameter shall represent the revision of the
time distribution format.
6.5.2.3 Leap
The leap parameter shall specify the Universal Coordinated Time (UTC) leap seconds. This
number, when added to the system time, shall give actual UTC time. This number can
increment or decrement by one twice a year on the solstices, as dictated by the US Naval
Observatory, to maintain synchronism between terrestrial and astronomical time. If zero, then
the number of leap seconds is unknown.
NOTE The leap parameter should not be used in any control situations, but may be needed in some time relays to
distribution channels that are based on UTC rather than Global Positioning Satellite (GPS) time.
6.5.2.4 Goodness
6.5.2.4.1 Parameter structure
--`,,```,,,,````-`-`,,`,,`,`,,`---
The goodness parameter shall be partitioned as shown in Figure 15.
stratum reserved equal zero priority

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Figure 15 – Goodness parameter of TimeDist_Lpacket
6.5.2.4.2 Stratum
The most significant field, called stratum, shall specify the number of time relays between this
message, and a source of absolute time. A value of 0 shall signify an exact reference, and the
value shall be incremented for every intermediate time relay. If the priority field is set to zero
(lock not achieved), or the number of intermediate time relays exceeds 15, the goodness
parameter shall be set to 15. Bits 3 through 11 shall be reserved and set to zero.
NOTE A time relay is a link-to-link router which distributes time synchronization messages on its links based on
the time synchronization messages received on its other links.
6.5.2.4.3 Source quality
The priority field shall indicate the quality of the time message as shown in Table 11.

– 56 – 61158-4-2 © IEC:2007(E)
Table 11 – Time distribution priority
Value Meaning
7 Absolute system time. Acting as master

6 Absolute system time. Acting as dependent
5 Human set system time. Acting as master
4 Human set system time. Acting as dependent
3 Lock established to node on distribution channel other
than this one
2 Lock established to node on this channel. System time
unknown
1 (invalid)
0 Not synchronized with any other node
6.5.2.5 gse
The gse parameter shall indicate the cumulative rms stability squared. This parameter shall
approximate the node’s worst case stability relative to the rest of the system. The units of this
parameter shall be (0,1 μs) 2 . When the rms stability is unknown or not yet determined, it shall
be 0xFFFFFFFF.
6.5.2.6 LINT time parameters
In each of the LINT time parameters, the most significant bit shall be zero – only 63 bits shall
be used. The units of these parameters shall be 0,1 μs.
6.5.2.7 dctz
The dctz parameter shall indicate the system time offset from the distribution channel’s
arbitrary time zero, established when the networks are synchronized.
6.5.2.8 ts_ref
The ts_ref parameter shall indicate the time stamp of the last tone following a moderator
DLPDU which had its interval_count equal to zero. The value of zero shall indicate that this
value is not known. System time zero shall be defined as that used for the Global Positioning
Satellites: 12:00 midnight, Jan 6, 1980 GMT.
6.5.2.9 ts_tx
The ts_tx parameter shall indicate the time stamp at the transmission of this message. The
value of zero shall indicate that this value is not known. System time zero shall be defined as
that used for the Global Positioning Satellites: 12:00 midnight, Jan 6, 1980 GMT. This
parameter shall be set to zero.
NOTE This protocol does not use GPS time, it only uses the time zero point for GPS. So the 1999 roll over of
GPS had no relevance for system time.
6.5.3 Sending and receiving the time distribution Lpacket
The current master Keeper for the link is responsible to sent the time distribution Lpacket at
intervals and QoS values configured by the DL user to match its application requirements.
--`,,```,,,,````-`-`,,`,,`,`,,`---
All nodes are responsible to receive the time distribution Lpacket.

61158-4-2 © IEC:2007(E) – 57 –
6.6 UCMM Lpacket
6.6.1 General
The Unconnected Message Manager (UCMM) is a DLS-user entity providing an unconnected

request/response message service for at least one outstanding message. It uses the DLL
transmit service and the UCMM Lpacket for its messages.
6.6.2 Structure of the UCMM Lpacket
the UCMM fixed tag and destination MAC ID provided by the DLL transmit service. The link
data field shall contain the DLS user data provided by the DLL transmit service.
6.6.3 Sending and receiving the UCMM Lpacket
The UCMM Lpacket shall be sent at the QoS priority specified by the DLL data transfer
service.
The status of each UCMM transmission is confirmed to the DL user by returning the DLS-
user-id (an internal handle or identifier) and the DLS Txstatus with one of the following values.

b) “T XA BORT ” — sending process failed;
The receiving station whose MAC ID matches that in the address, shall pass each correctly
received data unit to its local DL user, together with the data unit size, the Lpacket service
type and its source ID obtained from the DLPDU which conveyed the Lpacket.
6.7 Keeper UCMM Lpacket
6.7.1 General
Devices that implement the Keeper object shall also support sending and receiving of Keeper
UCMM Lpackets. Only the master Keeper shall send the Keeper UCMM Lpacket.
NOTE Using a specific address for Keeper objects reduces the decoding activity required by devices which do not
include a Keeper object.
6.7.2 Structure of the Keeper UCMM Lpacket
the Keeper UCMM fixed tag and 0xFF the broadcast address. The link data field shall contain
the user data provided by the Keeper object.
6.7.3 Sending and receiving the Keeper UCMM Lpacket
The Keeper UCMM Lpacket shall only be sent by a station with its Keeper object in the master
state. It shall be requested at the QoS priority specified by the invoking Keeper object.
The status of each Keeper UCMM transmission is confirmed to the DL user by returning the
DLS-user-id (an internal handle or identifier) and the DLS Txstatus with one of the following
values.

b) “T XA BORT ” — sending process failed; --`,,```,,,,````-`-`,,`,,`,`,,`---

– 58 – 61158-4-2 © IEC:2007(E)
The receiving station whose MAC ID matches that in the address, shall pass each correctly
received data unit to its local DL user, together with the data unit size, the Lpacket service
type and its source ID obtained from the DLPDU which conveyed the Lpacket.
NOTE 4 As this is an unconnected message, the source MAC ID is required to enable a response as appropriate.
6.8 TUI Lpacket
6.8.1 General
A Table Unique Identifier (TUI) is used by all ControlNet objects to reference a consistent set
of link configuration attributes. Two separate sets of attributes are held, each with their own
TUI, one for current operation and one for pending operation. Changes from TUI data in the
current link configuration to the TUI data in the pending link configuration shall occur at the
completion of a synchronized parameter change.
The TUI Lpacket is published as a scheduled Lpacket by the master Keeper to enable all
attached devices to verify they have current configuration and schedule data.
6.8.2 Structure of the TUI Lpacket
the TUI fixed tag and 0xFF the broadcast address. The link data field shall contain the listed
items shown in Table 12.
Table 12 – Format of the TUI Lpacket
Name Data type Description of parameter Semantics of values
Size USINT Size of the Lpacket in words 0x0D

Control USINT Link layer Lpacket control octet 0x01 (Fixed tag
Lpacket)
Fixed_Tag USINT Fixed tag value 0x84 (TUI Lpacket)
Destination_Mac_Id USINT Who receives the Lpacket 0xFF (Broadcast)
Unique_Id UDINT CRC of the Keeper’s current Least significant octet
attributes first
Status_Flag UINT TUI flag values See the Keeper object
TUI attribute for details
Keeper_Mac_Id USINT MAC ID of the Keeper See the Keeper object
broadcasting the TUI TUI attribute for details
Reserved USINT Reserved for data alignment
Net_Resource_Vendor_Id UINT Vendor ID of object holding Net
Resource for exclusive use
Net_Resource_Serial_Number UDINT Serial number of object holding Net
Net_Resource_Class UDINT Class number of object holding Net
Net_Resource_Instance UDINT Instance number of object holding
Net Resource for exclusive use
When generating the transmitted TUI Lpacket, any reserved fields shall use the values as
specified in the corresponding reserved fields of Keeper object attribute 0x0101. During the
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 59 –
configuration process, the programming tool shall set any reserved fields in attribute 0x0101,
to zero.
6.8.3 Sending and receiving the TUI Lpacket
The requested QoS priority shall be scheduled.
When the Keeper object is in the MASTER _ VERIFY , FAULTED _ MASTER _ VERIFY , MASTER ,
FAULTED _ MASTER , NET _ CHANGE _ MASTER or NET _ CHANGE _ FAULTED _ MASTER operating state, it
shall attempt to transmit a Table Unique Identifier (TUI) Lpacket as scheduled data once
every 4 NUTs (on NUT numbers 0, 4, 8, 12, 16 …). All Keeper devices shall reserve 26 octets
of scheduled link transmit time once every 4 NUTs for transmitting this Lpacket. (If sent
unscheduled, it shall be the highest QoS priority unscheduled information.)
Reception of TUI Lpackets shall be enabled at power up by the ControlNet object in each
device. Received TUI Lpackets shall be passed to the local ControlNet object.
6.9 Link parameters Lpacket and tMinus Lpacket
6.9.1 General
To synchronize the changing of local link parameters, Station Management shall enable the
reception of two fixed tag Lpackets: 0x15 (tMinus) and 0x81 (link parameters) via the
DLL_enable_fixed_request service of the DLL.
All nodes on a link shall maintain two copies of link parameters: current and pending. The
current copy of link parameters shall be used for the on going operation of the Data Link
Layer. The pending copy shall be maintained to allow a synchronized change of link
parameters. The change synchronization is supported by the tMinus service.
6.9.2 Structure of link parameters and tMinus Lpackets
the fixed tag for the service and 0xFF the broadcast address. The link data field for the
appropriate Lpacket shall contain the following contents in the listed order.
a) Contents of the Link parameters Lpacket data field:

class LinkParm_Lpacket : public fixedLpacket
{
public:
UINT NUT_length; // the length of the NUT in 10 μs increments;
USINT slotTime; // time allowed for line turnaround in 1 μs increments
USINT blanking; // time to disable RX after DLPDU in 1,6 μs increments
UINT zero; // reserved
UDINT unique_id; // 32 bit CRC calculated from Keeper configuration table
UINT status_flag; // 16 bit status table set by the Keeper
UINT reserved[8]; // all zeros
};
NOTE The format of the instance attributes 0x80 and 0x81 of the ControlNet object are exactly the same as
the link data of a fixed tag 0x81 Lpacket.
b) Contents of the tMinus Lpacket data field:

class tMinus_Lpacket : public fixedLpacket
--`,,```,,,,````-`-`,,`,,`,`,,`---
{
public:
USINT start_count;
USINT reserved[3];
};

– 60 – 61158-4-2 © IEC:2007(E)
where start count is a number of NUTs to be counted before the transition and shall not be
less than 8 and the reserved field shall contain zeros.
6.9.3 Sending and receiving the tMinus and Link parameters Lpackets
The Link parameters and tMinus Lpackets are issued by the master Keeper when a change is
required to the link parameters. They shall be requested at the QoS priority specified by the
invoking Keeper object.
Upon the reception of a LinkParm_Lpacket, each node shall load the pending copy of its
link parameters using their local DLL_set_pending_request service. The pending
parameters shall be loaded within 3 unscheduled transmit opportunities or within 1 s,
whichever is greater. The pending link parameter attribute of the ControlNet object shall also
be updated with the pending copy of the link parameters.
Upon reception of a tMinus_Lpacket, the node shall initiate a synchronized parameter

change using the DLL-tMinus-start-countdown-request service passing the
start_count parameter. The ControlNet object shall copy its pending link parameter
attribute to its current link parameter attribute when the DLL_tminus_zero_indication
signals the completion of the synchronized parameter change.
NOTE The DLL copies its own pending link parameters to its current copy at the completion of the tMinus
countdown and no DLL_tminus_zero_indication is signaled at the completion of the countdown unless the
completion is preceded by a DLL-tMinus-start-countdown-request..
The moderator Lpacket contains a field, called tMinus, that shall be used to synchronize the
update of the current link parameters. The DLL-tMinus-start-countdown-request shall
cause a node to participate in a tMinus countdown, and, if the node is the moderator, shall
initialize the tMinus field of the moderator Lpacket. The moderator node shall decrement this
field before transmitting each moderator until the field equals zero. When the tMinus field
transitions from 1 to 0, the DLL in each node participating in the countdown shall locally
generate a DLL_tminus_zero_indication to its ControlNet object which shall copy its
pending link parameters into its current copy. If the tMinus field transitions to 0 from any
value except 1, the countdown shall be aborted and no DLL_tminus_zero_indication
shall be generated.
6.10 I’m-alive Lpacket
6.10.1 General
This service allows all nodes on a link to recognize that another node has just been reset or --`,,```,,,,````-`-`,,`,,`,`,,`---
power cycled.
6.10.2 Structure or the I’m-alive Lpacket
the I’m alive fixed tag and 0xFF the broadcast address. The link data field shall contain the
following in the listed order.
class Im_Alive_Lpacket : public fixedLpacket
{
public:
USINT Lpacket_variant;
USINT sourceID;
USINT reserved[6];
};
The Lpacket_variant and reserved fields shall be set to zero. The sourceID field shall
be set to MAC ID of the node which transmits the Lpacket.
6.10.3 Sending and receiving I’m Alive
The QoS priority shall be specified by the invoking DL user.

61158-4-2 © IEC:2007(E) – 61 –
When a node is first brought on-line before starting full operations, the network attachment
monitor (NAM) in the new node shall broadcast at least 3 Im_Alive_Lpackets, subject to
the rules for I’m Alive the state processing.
Receiving stations shall notify their management services.

NOTE Among the clients of these broadcasts are the higher layer connection mangers of every other node on the
link.. The entities will abort any transaction records associated with the newly activated MAC ID and cancel any
connections which had passed through the newly activated MAC ID. Since connection IDs (generic tags) are
allocated dynamically, this ensures that connection ID’s issued by the old device at the MAC ID are not improperly
reused.
6.10.4 I’m alive state processing
A node shall only transmit one Im_Alive_Lpacket per NUT. To minimize the processing
requirements in each node, a node which is broadcasting its three Im_Alive_Lpackets
shall not count as a valid transmission any Im_Alive_Lpacket that is preceded in the NUT
by more than seven other such Lpackets. These Lpackets shall be transmitted in the
unscheduled portion of the NUT (QoS priority of either LOW or HIGH).
NOTE Because the timing of when nodes power up or reset relative to each other cannot be controlled, there is
the possibility of an I’m alive Lpacket broadcast storm if a large number of nodes enter the I’m alive state at the
same time. To minimize processing requirements, a transmission smearing and back off algorithm is recommended
to monitor and control the intensity of any broadcast storm activity. Such an algorithm would spread the I’m alive
Lpackets out over longer and longer periods of time, should a large number of nodes power up concurrently. If a
small number of nodes power up together, the algorithm should allow them to exit the I’m alive state quickly since
there cannot be a broadcast storm. An example of one such algorithm is shown in Figure 16.
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 62 – 61158-4-2 © IEC:2007(E)
Initialization Psync
Tx_Count == 0
Heard = 0
State = Calm != 0
Tx_Count = 4 Heard Exit
>2 <=2 >8

Backoff =
4 if umax <= 16 State = Breezy State = Stormy
8 if umax <= 32
16 if umax > 32
Heard = 0
Tx_nut = MAC_ID % Backoff

Current_Nut =
Nut # from ASIC % Backoff != 0
Exit == 0
State
Calm Breezy Stormy
Tx_Count = min(Tx_Count++,4)
Backoff 1 64 Backoff
>1 < 64
Backoff /= 2 Backoff *= 2
Tx_Nut = MAC_ID % Backoff Tx_Nut = MAC_ID % Backoff
State = Calm
Tx_Count == 1
I'm Alive packet received
!= 1
Current_Nut = Tx_Nut Tx stream empty

Tx_Count == 0
No Yes No Yes
!= 0
Tx stream empty & Tx_Count = 0
Heard++ State != Stormy
No Yes
Notify Transports
Exit
Exit Tx I'm Alive packet
Notify UCMM
Tx_Count - -
Exit Exit
Figure 16 – Example I’m alive processing algorithm
6.11 Ping Lpackets
6.11.1 General
The ping service allows station management to initiate a ping request and receive a ping
response from each active station, or one addressed station attached to the DLS provider.
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 63 –
All stations contain the ping service and at power-up the enable-fixed-request service is used
by the DLS user to activate reception and response to ping requests within the local DLS
provider.
6.11.2 Structure of the ping Lpackets
The size and control fields shall follow the fixed tag format.
a) When sending a ping request, the address shall be formed from the ping request fixed tag
and an address specified by the DL user. The specified address may be a single MAC ID
or 0xFF the broadcast address.
The link data field shall contain the following in the listed order.
class Ping_request : public fixedLpacket
{
public:
USINT client_ID;
USINT reserved[3];
};
where client_ID is the MAC ID of the request originator, and the reserved field shall
contain zeros.
b) When sending a ping reply, the address shall be formed from the ping reply fixed tag and
the client_ID address from the corresponding ping request indication, (used here as
destination for the reply).
The link data field shall contain the following in the listed order;
class Ping_reply : public fixedLpacket
{
public:
USINT server_ID;
USINT vendor_specific[4];
USINT reserved[3];
};
where the server_ID field shall contain the MAC ID of the node responding to the request,
the vendor_specific field may contain any data and the reserved field shall contain zeros.
The DLL_xmit_fixed_request(id, Lpacket, sizeof(Ping_reply), HIGH, 0x29,

client_ID) service shall be used to send the reply to the MAC ID specified in the
client_ID field of the received Ping_request Lpacket.
NOTE A typical use for the vendor_specific field is for debugging or diagnostic information.
6.11.3 Sending and receiving the ping Lpackets
The QoS priority for a ping request shall be specified by the invoking DL user. The QoS
priority for a ping response shall be High.
Sending of ping-request Lpackets may be initiated by local management in any station.
At power up, the DLL_enable_fixed_request(id, 0x09) internal service of the Data

Link Layer shall be invoked to enable the reception of fixed tag ping requests.
--`,,```,,,,````-`-`,,`,,`,`,,`---
Upon receipt of a ping-request, each receiving station assembles a ping reply fixed tag
Lpacket and sends it to the requesting station.
Upon receipt of a ping response, the requesting node passes the indication to local
management.

– 64 – 61158-4-2 © IEC:2007(E)
6.12 WAMI Lpacket
6.12.1 General
A “Where Am I?” (WAMI) server shall be present in all permanent nodes which have a
Network Access Port (NAP). The server shall not be present on transient nodes.
NOTE The WAMI (where am I) server allows a transient node (a node which connects to the network via the
network access port or NAP) to determine the MAC ID of the node to which it is attached. This is a convenient way
for software in a transient device to establish communication with the local permanent node.
6.12.2 Structure of the WAMI Lpacket
the WAMI fixed tag and 0xFF the broadcast address for all MAC IC nodes on this link. The
link data field shall contain the following in the listed order.
class WAMI_Lpacket : public fixedLpacket
{
public:
USINT requestID;
USINT responseID;
USINT reserved[6];
};
In a request WAMI, the requestID shall contain the MAC ID of the transient node that is
--`,,```,,,,````-`-`,,`,,`,`,,`---
sending the Lpacket. The other fields shall contain zeros. To convert a request into a
response, the server shall copy its own MAC ID into the responseID field and reply. The
QoS priority is Low.
NOTE 1 After WAMI fixed tag reception is enabled by the DLL_enable_fixed_request(id, 0x86) service of
the DLL, fixed tags are received by the DLL_recv_fixed_indication service..
NOTE 2 The Network Attachment Monitor (see 8.1) describes procedures to ensure the transient MAC ID does
not duplicate an existing link MAC ID.
6.12.3 Sending and receiving the WAMI Lpacket
The QoS priority shall be Low.
The WAMI server is only implemented in devices having a NAP, these devices shall repeat all
messages from the main link to the NAP and all messages from the NAP to the main link.
Additionally these devices shall include means of detecting messages received via their NAP,
and they shall only respond to Lpackets which match each of the following criteria:
— WAMI fixed tag 0x86;

— destination broadcast (0xFF);
— received via the device local NAP.
Lpackets that match these criteria shall be called request WAMI Lpackets. For all such
Lpackets, the server shall generate a response WAMI that is addressed to the MAC ID which
sent the request WAMI. The WAMI server shall discard all other WAMI fixed tag 0x86
Lpackets.
6.13 Debug Lpacket
This service may be used to transmit the state of an object building a trace of object state
transitions on the wire.
the debug fixed tag and destination MAC ID provided by the DLL transmit service. The link
data field shall contain the following in the listed order.

61158-4-2 © IEC:2007(E) – 65 –
class Debug_Lpacket : public fixedLpacket

{
public:
UINT object_class;
UINT data1;
UINT data2;
};
The value of object_class shall be the class code (see IEC 61158-6-2) of the object
transmitting its state. The meaning of the data1 and data2 fields shall be defined in the
object definition. Devices shall not generate more than one fixed tag debug Lpacket per 10 s
on average so as not to interfere with other unscheduled transmissions.
6.14 IP Lpacket
This service (fixed tag 0x85) is used to send raw IP frames. The maximum IP frame size that
can be sent in an Lpacket is 506 octets. Broadcast are sent with destination 0xFF. IP frames
between two nodes shall have the correct fixed tag destination MAC ID. An address resolution
protocol shall be used to determine the MAC ID associated with a particular IP address.
6.15 Ethernet Lpacket
This service (fixed tag 0x89) is used to send Ethernet frames other than IP frames. This
includes but is not limited to Ethernet Address Resolution Protocol (ARP) frames. This allows
simple implementation of IP and an Ethernet style address resolution protocol on Type 2
physical layer since an existing TCP/IP/Ethernet stack can be used with minor packet
changes.
The lowest octet of the Ethernet physical address is used to represent the Type 2 MAC ID
(Ethernet physical addresses are sent highest octet first). A Type 2 broadcast (MAC ID 0xFF)
shall be expanded to an Ethernet broadcast address (FF FF FF FF FF FF).
On start up a TCP/IP stack that includes Ethernet ARP shall know the physical address of the
local node. This is reported as “00 00 00 00 00 <MACID>”.
The low octet of an Ethernet frame’s “destination address” is used as the Type 2 fixed tag
destination. The low octet of an Ethernet frame’s “source address” will be the same as the
local node’s MAC ID (reported to the TCP/IP stack at startup) and is sent as the DLPDU
source MAC ID. The Ethernet “frame type” (08 06 for ARP) make up the first two octets of the
data portion of the Lpacket and up to 504 octets are available for the data portion of the
Ethernet frame (ARP request/reply uses 28 octets).
Because the Ethernet “frame type” is included in the Lpacket, other types of Ethernet frames
such as RARP can be sent using this Ethernet fixed tag service as well.
7 Objects for station management
7.1 General
This protocol specification is quite flexible. It can provide deterministic and synchronized I/O
transfer at cyclic intervals up to 1 ms and node separations up to 25 km. This performance is
adjustable on-line by configuring the link parameters. These parameters, which govern the
access to the link, can be tuned as required to match different applications.
Station Management allows these parameters to be changed on-line, as the network is

working, it also allows the link to continue functioning while connections to new nodes are
added and removed.
The functions of Station Management allow
— access to variables and events within each of the Layers;

--`,,```,,,,````-`-`,,`,,`,`,,`---

– 66 – 61158-4-2 © IEC:2007(E)
— a common user interface;

— coordinating the change of link parameters;
— non-disruptively adding nodes to the link;
— tuning of link parameters;
— clock synchronization between nodes.
The access to variables and events within each of the Layers is accomplished by defining
object interfaces for these parameters.
The ControlNet object provides a consistent interface to the Physical and Data Link Layers.
The Keeper object holds the link attributes for all devices on a link and shall be responsible
for distributing those attributes to those devices in an orderly fashion. It also holds (for link
scheduling software) a copy of the connection originator data for all connection originator
devices using a network. If there are multiple Keeper objects on a link, they perform
negotiations to determine which Keeper is the master Keeper and which Keeper(s) perform
backup Keeper responsibilities. The master Keeper is the Keeper actively distributing link
parameters and attributes to the nodes on the network. A backup Keeper is one that monitors
Keeper related network activity and can transition into the role of master Keeper should the
master Keeper fail to perform.
The Keeper object also contains support for obtaining, holding, and releasing the Network
Resource, a network semaphore that is used to eliminate conflicts when modifying the
attribute data held by the Keeper object(s) on a link.
The Scheduling object shall exist in connection originator (CO) devices. The Scheduling
object shall be used by link scheduling software (LSS) to
— read scheduled connection information;

— write schedule information;
— provide the CO with a signature (software key) which shall be used to authenticate the CO
device’s access to a specific link.
The TCP/IP Interface object provides the mechanism to configure the TCP/IP interface of a
device.
The Ethernet Link object maintains link-specific counters and status information for a physical
Ethernet ISO/IEC 8802-3 port.
The DeviceNet object provides a consistent interface to the Physical and Data Link Layers.
The Connection Configuration object provides an interface to create, configure and control
connections in a device.
7.2 ControlNet object
7.2.1 Overview
The ControlNet object shall provide a consistent Station Management interface to the Physical
and Data Link Layers. This object shall make diagnostic information from these layers
available to client applications. Each node shall support one ControlNet object per link.
7.2.2 Class attributes
The ControlNet object shall support the class attributes as specified in Table 13.
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 67 –
Table 13 – ControlNet object class attributes
Attribute Need in Access Data Description of

Name Semantics of values
ID implementation rule type attribute
0x01 Required Get Revision UINT Revision of this First revision, value = 1
object
0x02 Required Get Max. UDINT Maximum instance Value determined by
instance number node specifics
7.2.3 Instance attributes
7.2.3.1 General
The ControlNet object shall support the instance attributes as specified in Table 14.
Table 14 – ControlNet object instance attributes
Attribute Need in Access Description of Semantics

Name Data type
ID implementation rule attribute of values
0x80 Optional Get Pending_Link_Config STRUCT pending link see 6.9.2

of 34 configuration
octets parameters
Link_Config STRUCT pending link
of 12 parameters
octets
NUT_length UINT DLL NUT_length in 10 μs ticks
smax USINT DLL smax 0 to 99
umax USINT DLL umax 1 to 99
slotTime USINT DLL slotTime in 1μs ticks
blanking USINT DLL blanking in 1,6 μs
ticks
gb_start USINT DLL gb_start in 10 μs ticks
gb_center USINT DLL gb_center in 10 μs ticks
reserved UINT reserved
modulus USINT DLL modulus 127 required
--`,,```,,,,````-`-`,,`,,`,`,,`---
gb_prestart USINT DLL gb_prestart in 10 μs ticks
TUI STRUCT Keeper TUI see 7.2.3.3
of
22 octets
unique_ID UDINT Keeper CRC see 7.2.3.4
status_flag UINT TUI flag see 7.2.3.5
reserved USINT [16] reserved
0x81 Required Get current_link_config STRUCT current link same as
of configuration attribute 0x80
34 octets parameters see 6.9.2
0x82 Required Get/ diagnostic_counters STRUCT diagnostic counters see 7.2.3.7
Get_and of
_Clear 42 octets
buffer_errors UINT buffer event counter see 7.2.3.8
error_log SWORD[8] bad DLPDU log see 7.2.3.9
event_counters STRUCT diagnostic counters see 7.2.3.10
of 32
octets

– 68 – 61158-4-2 © IEC:2007(E)

Name Data type
good_frames_ SWORD[3] good DLPDUs

transmitted transmitted (LSB
first)
good_frames_ SWORD[3] good DLPDUs
received received (LSB first)
selected_channel_ USINT framing errors
frame_errors detected on active
receive channel
channel_A_ USINT framing errors
frame_errors detected on channel
A
channel_B_ USINT framing errors
frame_errors detected on channel
B
aborted_frames_ USINT DLPDUs aborted
transmitted during transmission
(transmit underflows)
highwaters USINT LLC transmit
underflow and LLC
receive overflow
NUT_overloads USINT no unscheduled time
in NUT (all time used
for scheduled
transmissions)
slot_overloads USINT more scheduled data
queued for one NUT
than allowed by
sched_max_frame
parameter
blockages USINT single Lpacket size
exceeds
sched_max_
frame parameter
non_concurrence USINT two or more nodes
could not agree
whose turn it is to
transmit
aborted_frames_ USINT incomplete DLPDUs
received received
lonely_counter USINT number of times
nothing heard on
network for 8 or
more NUTs
duplicate_node USINT DLPDU received
from node with local
node’s MAC ID
noise_hits USINT noise detected that
locked the modem rx
PLL
collisions USINT Rx data heard just as
we were going to
transmit
mod_MAC_ID USINT MAC ID of the
current moderator
node
non_lowman_mods USINT Moderator DLPDUs
heard from non
lowman nodes
rogue_count USINT rogue events
detected
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 69 –

Name Data type
unheard_moderator USINT DLPDUs being heard

but no moderators
being heard
vendor_specific USINT vendor specific
reserved SWORD[4] reserved
vendor_specific USINT vendor specific
vendor_specific USINT vendor specific .
reserved SWORD reserved

0x83 Required Get station_status STRUCT of station status see 7.2.3.11
6 octets
smac_ver USINT MAC implementation
vendor_specific SWORD[4] vendor specific
channel_state SWORD channel state LEDs, see 7.2.3.12
redundancy warning,
--`,,```,,,,````-`-`,,`,,`,`,,`---
and active channel

bits
0x84 Get required, Get/Set MAC_ID STRUCT MAC ID switch and
Set-(One Time of 4 octets current settings
Only) Optional
MAC_ID_current USINT current MAC ID Range 0 to
99. See
7.2.3.13 .
MAC_ID_switches USINT MAC ID switch 0 to 99, 0xFF.
settings See 7.2.3.14
MAC_ID_changed BOOL MAC ID switches see 7.2.3.15
changed since reset
Reserved USINT reserved
0x85 Optional Get/Set Sched_max_frame STRUCT of scheduled data limit
2 octets
Sched_max_frame USINT scheduled maximum in octet pairs.
DLPDU See 7.2.3.16
Reserved USINT reserved
0x86 Required Get error_log STRUCT driver firmware see 7.2.3.17
of buffer error counts
10 octets and troublesome
node list
buffer_errors UINT buffer event
counter
error_log SWORD[8] bad DLPDU log .
0x87 Optional Get / extended_diagnostic STRUCT additional diagnostic

Get_and _ counters of 264 counters
_Clear octets
unsched_transmitted UDINT number of
unscheduled
Lpackets transmitted
sched_highwater UDINT Max. number of
shared/unscheduled
Lpackets in transmit
queue
sched_data 128 schedule information
STRUCTS
of 2 octets
(256 octets)

– 70 – 61158-4-2 © IEC:2007(E)

Name Data type
words_in_use USINT number of scheduled

words in use by this
node this NUT
Lpkt_in_use USINT number of scheduled
Lpackets in use by
this node this NUT
0x88 Optional Get Active_node_table ARRAY of one bit for each MAC see 7.2.3.18
32 octets ID
1 = node present
0 = node missing
0x89 Optional Get New_node_table ARRAY of one bit for each MAC see 7.2.3.19
32 octets ID
1 = node has joined
link recently
0 = node has not
joined link recently
where
LSB = least significant byte/octet.
7.2.3.2 pending_link_config
The values within the attribute allow the pending link parameters to be read. This attribute
shall change based on the Station Management function called synchronized parameter
change, and shall not be set via the services of the ControlNet object.
7.2.3.3 Keeper TUI
The ControlNet object shall maintain separate copies of the TUI sub–attribute for
pending_link_config and current_link_config attributes. Changes to the TUI data in the
pending_link_config attribute shall occur at the reception of a fixed tag 0x81. Changes to the
TUI data in the current_link_config attribute shall occur at the completion of the synchronized
parameter change.
7.2.3.4 unique_ID
The unique_ID field shall consist of a 32 bit CRC value calculated from the contents of the
network configuration table maintained by the Keeper. This value shall be copied from the
fixed tag 0x81 Lpacket.
7.2.3.5 status_flag
The status_flag field of the TUI sub–attribute shall consist of a 16 bit value. Unused bits shall
be reserved and set to zero.
As shown in Table 15, the Keeper State bit (bit 4) shall indicate whether this node has ever
heard a TUI from a master Keeper. The ControlNet object shall clear this bit at initialization.
Since all TUI Lpackets sent by the master Keeper have this bit set, the ControlNet object
need not manipulate this bit.
--`,,```,,,,````-`-`,,`,,`,`,,`---
Reception of TUI Lpackets shall be enabled at power up using the

DLL_enable_fixed_request(id, 0x84) service. The status field of the TUI Lpackets
shall be checked. If bit3 = 0, bit4 = 1, and bit5 = 1, then the TUI Lpacket shall be copied into
attribute 0x81 and TUI reception shall be disabled using the
DLL_disable_fixed_request(id, 0x84). Bits 0 and 1 of the TUI status field shall be
used to override the default network redundancy settings for the node. They shall indicate if
the network is being operated single channel or redundant channel mode. Only network
redundancy information from TUI Lpackets with both the Keeper State and Keeper configured
bits set, shall be used.

61158-4-2 © IEC:2007(E) – 71 –
Table 15 – TUI status flag bits
Bit Meaning
0-1 Network Redundancy

Bit 1 = 0, bit 0 = 0; Illegal combination
Bit 1 = 0, bit 0 = 1; Channel B only
Bit 1 = 1, bit 0 = 0; Channel A only
Bit 1 = 1, bit 0 = 1; Redundant
2 Holding Network Resource bit
0 = Network Resource not being held
1 = Network Resource being held for the object identified
in the TUI
3 Network change in progress bit
0 = No network change in progress
1 = Network change in progress
4 Keeper State bit
0 = TUI transmitted by Keeper not in MASTER state
1 = TUI transmitted by Keeper in MASTER state
--`,,```,,,,````-`-`,,`,,`,`,,`---
5 Keeper configured bit

0 = No master Keeper heard since joining link
1 = Heard master Keeper since joining link
6 - 15 reserved ( set to 0 )
7.2.3.6 current_link_config
The values within the current_link_config attribute correspond to the link parameters currently
used. The format of this attribute shall be identical to that of the pending_link_config attribute.
7.2.3.7 diagnostic_counters
The diagnostic_counters attribute shall maintain counts of events in the Physical and Data
Link Layers.
NOTE The diagnostic_counters attribute may be read without effecting their values by using one of the
Get_Attribute service requests. The information may be read and the values set to zero by using the
Get_and_Clear service request. See 7.2.5.
The event information maintained by the firmware shall also be gettable (but not clearable) via
the error_log attribute. This is done for efficiency. The information maintained by the firmware
shall be immediately and directly accessible.
7.2.3.8 buffer_errors
The value of the buffer_errors sub–attribute shall increment on every receive overflow event
and transmit underflow event. If an implementation never overflows or underflows,
buffer_errors shall be zero.
7.2.3.9 error_log
If DLL_event_indication returns a value of DLL_EV_badFrame, the error_log sub-

attribute records the last eight such indications. The mac_id parameter of this indication shall
be recorded. The order of MAC IDs shall be most recent error first to oldest error last. Values
of zero represent unused positions in the error log.
7.2.3.10 event_counters
The event_counters sub-attribute shall contain counts of link events. The counter shall
rollover when their values exceed their limits.

– 72 – 61158-4-2 © IEC:2007(E)
7.2.3.11 station_status
This attribute shall be only gettable.
7.2.3.12 channel_state
The channel_state octet shall represent the current state of the network status indicators, if
implemented. The bits of the channel_state octet are described in Table 16.
NOTE The network status indicators are described in Annex A.
Table 16 – Channel state bits
Bits Description
0,1,2 Channel A LED State

0 = Off
1 = Solid green
2 = Flashing green-off
3 = Flashing red-off
4 = Flashing red-green
5 = Railroad red-off
6 = Railroad red-green
7 = Solid red
3,4,5 Channel B LED State
Indications same as channel A LED.
6 Redundancy Warning – When warning, the non–active channel in a
redundant configuration is unusable by the controller.
0 = normal (no warning)
1 = warning
7 Active Channel – Indicates which of two channels the receiver is
currently listening to.
0 = Channel B
1 = Channel A
7.2.3.13 MAC_ID_current
The MAC_ID_current value shall be accessible using the Get_Attribute services. Setting shall
be required on devices without address switches. Only the first set, of the MAC_ID_current
value, after a ControlNet object reset shall be accepted. Setting shall be optional on devices
with address switches.
The range of allowable values for MAC IDs shall be 1 to 99.
7.2.3.14 MAC_ID_switches
The MAC_ID_switches value shall be gettable and not settable on all devices. The returned
value shall be 0xFF for auto-address nodes and nodes without address switches.
7.2.3.15 MAC_ID_changed
The MAC_ID_changed value shall be cleared when the device is reset and set whenever the
device detects that the address switches have been changed. Once set, it stays set until the
device is reset, even if the address switches are returned to their original settings. The
frequency at which the address switches are checked shall be device dependent.
When a change in the network address switches is detected, this flag shall be set and a minor
error shall be reported to the host.
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 73 –
7.2.3.16 sched_max_frame
The sched_max_frame attribute shall be used to limit the maximum size of the node’s
scheduled transmissions. A value of 0 shall indicate that a node shall not transmit during the
scheduled portion of the NUT.
7.2.3.17 error_log
The instance attribute 0x86 shall be a copy of the error_log sub-attribute contained in
instance attribute 0x82.
NOTE The information in this attribute is a copy of the information found in the diagnostic_counters attribute. This
copy is only gettable. The values in this attribute may be cleared only by using the Get_and_Clear service request
on the diagnostic_counters attribute. See 7.2.5 for more details.
This copy of the error_log shall only be accessible via the Get_Attribute services. This
attribute shall only be cleared when the master copy in 0x82 is cleared.
7.2.3.18 Active node table (instance attribute = 0x88)
Instance attribute 0x88 of the ControlNet object shall consist of an array of 256 bits, one per
MAC ID. The least significant bit shall correspond to MAC ID = 0; the most significant bit shall
correspond to MAC ID = 255. The bit for a specific MAC ID shall be set (1) for a node within
1 s of a node transmitting on the link. The bit shall be cleared (0) within 20 s of the node
leaving the link. A node shall be considered to have left the link if it misses three consecutive
transmit opportunities.
7.2.3.19 New node table (instance attribute = 0x89)
Instance attribute 0x89 of the ControlNet object shall consist of an array of 256 bits, one per
MAC ID. The least significant bit shall correspond to MAC ID = 0; the most significant bit shall
correspond to MAC ID = 255. The bit for a specific MAC ID shall be set (1) for a node within
1 s of a node transmitting on the link. The bit shall be cleared (0) between 10 s and 20 s after
the node has joined the link.
7.2.4 Common services
7.2.4.1 General
The ControlNet object shall support the common services as specified in Table 17.
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 74 – 61158-4-2 © IEC:2007(E)
Table 17 – ControlNet object common services
Need in
Service implementation Service name Description of service
code
Class Instance
0x05 N/A Required Reset Return ControlNet object to power up state

0x10 N/A Conditio Set_Attribute_Single Set network or node specific configuration
nal information
--`,,```,,,,````-`-`,,`,,`,`,,`---
0x0E Required Required Get_Attribute_Single Get network or node specific configuration
information
0x01 N/A Optional Get_Attribute_All Get network and node specific configuration
information
0x02 N/A Optional Set_Attribute_All Set network and node specific configuration
information
0x03 N/A Optional Get_Attribute_List Get network and/or node specific configuration
information
0x04 N/A Optional Set_Attribute_List Set network and/or node specific configuration
information
7.2.4.2 Reset service
The Reset service shall reinitialize the Network Attachment Monitor (NAM) causing it to
monitor the link activity and then attempt to join the link. MAC ID switches shall not be re-
evaluated due to the reset.
The ControlNet object need not respond to a Reset request before actually performing the
reset operation.
7.2.4.3 Set_Attribute_Single
If any attribute has been implemented as settable, the Set_Attribute_Single service shall be
required.
7.2.4.4 Get_Attribute_All response
The object/service specific reply data portion for a successful Get_Attribute response is
shown in the Instance Attributes for the ControlNet object table. The size of this response is
dependent on the attribute instance(s) being accessed.
Because of the large size of the Get_Attribute_All response, devices with limited resources
need not support this service.
The data portion of a Get_Attribute_All service request shall contain the following attributes in
the following order:
0x81 - current_net_config
0x82 - diagnostic_counters
0x83 - station_status
0x84 - MAC_ID
0x86 - error_log
7.2.5 Class specific services
7.2.5.1 General
The ControlNet object shall support the class specific services as specified in Table 18.

61158-4-2 © IEC:2007(E) – 75 –
Table 18 – ControlNet object class specific services
Service Need in implementation

Service name Description of service
code Class Instance
0x4C N/A Required Get_and_Clear Get then clear the diagnostic counters
0x4D N/A Required Enter_Listen_Only Force the node to enter and stay in listen only
mode until reset
0x4E N/A Required Where_am_I Determine the MAC ID of the device this node is
(See 7.2.5.4) attached via the NAP
0x4F N/A Conditional Auto_Address Required in all auto-address nodes. Select a new
MAC ID using the auto address sequence of the
NAM
7.2.5.2 Get_and_Clear service
This class specific service shall be evoke an identical response to the Get_Attribute_Single
service; however, after the response Lpacket is built, the value of the attribute shall be set to
zero. Only instance attributes 0x82 and 0x87 shall support this service.
7.2.5.3 Enter_Listen_Only service
The Enter_Listen_Only service shall cause this object to send a

DLL_listen_only_request(FALSE) to the DLL associated with this instance of the
ControlNet object. This service need not generate a response since the node may stop
transmitting before the response is sent.
NOTE 1 The node should remain in the listen-only state until a reset request is sent to either the ControlNet or
Identity object.
NOTE 2 The Enter_Listen_Only service is intended to be used for diagnostic purposes to force nodes to drop off
the link until they are specifically requested to rejoin. This allows a node to effectively be removed from the link
without having to physically disconnect the network cable.
7.2.5.4 Where_am_I service
All transient nodes shall implement the Where_am_I service. This service shall determine the
MAC ID of the node to which the transient node is connected via its network access port
(NAP). The service may be implemented by using the WAMI server functionality of the Station
Management entity.
NOTE A transient node may use this service to identify the MAC ID of the node into whose NAP it is plugged.
The Where_am_I response shall be a single USINT containing the MAC ID of the permanent
node to which the transient node is connected. If the ControlNet object is unable to complete
the WAMI query, it shall return a MAC ID of 255.
7.2.5.5 Auto_Address service
For nodes that support automatically selecting a MAC ID, this service shall reinitialize the
NAM causing it to monitor the link activity and then attempt to join the link possibly with a new
--`,,```,,,,````-`-`,,`,,`,`,,`---
MAC ID. Nodes that do not support automatically selecting a MAC ID shall not implement this
service.
The Auto_Address service need not respond prior searching for a new MAC_ID.
7.2.6 Behavior
7.2.6.1 Effect of DLL_tminus_zero_indication
Upon receipt of this indication, the object shall copy the contents of instance attribute 0x80
(pending_link_config) into instance attribute 0x81 (current_link_config). An internal copy of

– 76 – 61158-4-2 © IEC:2007(E)
instance attribute 0x80 shall be kept even if the implementation has not made it accessible via
one of the Get_Attribute services.
7.2.6.2 Duplicate node
If a DLL_event_indicaton(DLL_EV_dupNode) is received from the Data Link Layer, the

ControlNet object shall force the DLL into a listen-only state. The ControlNet object shall latch
this state until a reset service is received. A reset to the Identity object shall also end the
listen only state.
7.2.6.3 Redundancy
The network redundancy setting for a node shall be initially set at start up to the best
capability of the device. (Channel A only for single channel devices, both channels for
network redundant devices). The power up redundancy setting shall be reflected in the TUI
contained in the instance attribute 0x82.
The network redundancy setting for a node shall be updated to the current network
redundancy setting by the Keeper in one of two ways:
— The node receives a TUI Lpacket from the wire with the master Keeper and configured
Keeper bits set and the net change in progress bit reset in the Status_Flags word;
— The node receives a fixed tag 0x81 Lpacket.
In either case, the received TUI data shall be copied into attribute 0x80.
If a single channel node joins a redundant link, it shall behave as if it were a redundant node
with a faulty channel.
7.2.7 Module status indicator
The module status indicator, if implemented, shall provide the following status indications:
a) solid green when connections are active in the on line state;

b) flashing green/off in the check for moderator listen only state;
c) flashing green/off when rogue conditions are detected;
d) flashing red/off for a recoverable error;
e) flashing red/off when in the D UP _ LISTEN _ ONLY state;
f) solid red for a irrecoverable error.
7.3 Keeper object
7.3.1 Overview
The Keeper object shall hold the link attributes for all devices on a link and shall be
responsible for distributing those attributes to those devices in an orderly fashion. It also
holds (for link scheduling software) a copy of the connection originator data for all connection
originator devices using a network. If there are multiple Keeper objects on a link, they perform
negotiations to determine which Keeper is the master Keeper and which Keeper(s) perform
backup Keeper responsibilities. The master Keeper is the Keeper actively distributing
attributes to the nodes on the network. A backup Keeper is one that monitors Keeper related
network activity and can transition into the role of master Keeper should the master Keeper
fail to perform.
The Keeper object also contains support for obtaining, holding, and releasing the Network
Resource, a network semaphore that is used to eliminate conflicts when modifying the
attribute data held by the Keeper object(s) on a link.
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 77 –
7.3.2 Revision history
The revision history of the Keeper object is described in Table 19.
Table 19 – Keeper object revision history
Class
Description of changes
revision
01 Initial Release
02 Release for IEC 61158 series
The Keeper object shall support the class attributes as specified in Table 20.
Table 20 – Keeper object class attributes
Need in Access Description Semantics of

Number Name Data type
implementation rule of attribute values
0x1 Required Get Revision UINT Revision of this 2 (revision 2)

object (See Note 2)
NOTE 1 Revision 1 Keeper devices are restricted to only operate at MAC ID = 1. These devices perform the
functions of the Keeper as described in this specification as long as no other Keeper is present on the
Network. At any other MAC ID, these devices containing revision 1 Keepers perform as if no Keeper objects
were present.
NOTE 2 Revision 2 Keepers devices operate at any legal MAC ID value. These devices perform the functions of
the Keeper as described in this specification in the presence of any other Revision 2 Keepers on the Network.
7.3.4.1 General
The Keeper object shall support the instance attributes as specified in Table 21. Only one
instance of the Keeper object is allowed. That instance shall be sensitive to the port on which
requests are received. This is especially important in the case of a router device where one
Keeper instance receives requests from two links.
Table 21 – Keeper object instance attributes

--`,,```,,,,````-`-`,,`,,`,`,,`---
Attribute Need in Access Description Semantics of

Name Data type
ID implementation rule of attribute values
0x00 Required Get status STRUCT Keeper object status
of 2 octets
state USINT current Keeper
operating state
reserved USINT reserved for data
alignment
0x01 Required Get/Set port_status STRUCT port status for node 1
through of 10 through node 99
0x63 octets
port_status UINT port status
ID STRUCT node type
of 8 octets identification
vendor UINT vendor code
type UINT product type
code UINT product code
major USINT major revision
minor USINT minor revision

– 78 – 61158-4-2 © IEC:2007(E)

Name Data type
0x64 – Reserved Reserved for
0xFE future expansion
0xFF Required Get/Set net_config STRUCT of current network
12 octets parameters
NUT UINT Network Update Time In 10 μs ticks
smax USINT Scheduled max node 0 to 99
ID
umax USINT Unscheduled max 0 to 99
node ID
Slot_Time USINT Slot Time In 1 μs ticks
Blank_Time USINT Blanking Time In octets
Gb_Start USINT Guard Band Start In 10 μs ticks
Gb_Center USINT Guard Band Center In 10 μs ticks
Reserved UINT Reserved for Data
Alignment
Int_Cnt mod USINT Interval Count 127
Modulus (Macrocycle
length)
Gb_Prestart USINT Guard Band Prestart In 10 μs ticks
0x100 Required Get/Set name UINT [33] current name of this 32 unicode
link characters and a
unicode NULL
0x101 Required Get/Set RT_TUI STRUCT of Table Unique
22 octets Identifier
--`,,```,,,,````-`-`,,`,,`,`,,`---
unique_ID UDINT attribute CRC
status_flag UINT TUI flag bits See 7.2.3.3
reserved USINT [16] reserved to allow
common format with
attribute 0x102
0x102 Required Get Link_TUI STRUCT Table Unique
of 22 Identifier
octets (current link only)
unique_ID UDINT attribute CRC
status_flag UINT TUI flag bits See 7.2.3.3
Keeper_MAC_ID USINT MAC ID of node Any legal MAC
broadcasting the TUI ID
reserved USINT reserved for data
alignment
Net_Resource_ UINT Vendor ID of object
Vendor_Id holding Net Resource
Net_Resource_ UDINT Serial number of
Serial_Number object holding Net
Resource
Net_Resource_ UDINT Class of object
Class holding Net Resource
Net_Resource_ UDINT Instance of object
Instance holding Net Resource
0x103 Required Get/Set Cable_Config STRUCT Current cable
of up to configuration
100 octets
Id USINT Id value Always 0xFF
Num_Elements USINT Number of cable Range 1 to 24
configuration
elements in network
configuration

61158-4-2 © IEC:2007(E) – 79 –

Name Data type
Propagation_time UINT Number of 100 ns
ticks
Physical element Phy
element
[24]
Phy_element STRUCT
of 4 octets
Vendor_id UINT Vendor code
Product_code USINT Product code
How_many USINT
0x104 Required Get/Set CO_summary STRUCT General information
of 204 about the co_data
octets attribute
data_size UINT Size of co_data In words
attribute
connection_info_ USINT Used by
revision programming
tool
0 = Format 1
1 = Format 2
2 - 255 reserved
tool_keeper_ USINT Highest level co_data Level supported
revision parse rule supported is ≤ Keeper
object revision
0 = Format 1
1 - 255 reserved
See 7.3.6.7
0ffsets UINT[100] Array of word offsets In words
into the co_data 0xFFFF = no
attribute, by MAC ID data for this
MAC ID
node 0 based
index
0x105 Required Get/Set CO_data STRUCT connection originator Tool Keeper
fragment of up to information Revision Format
14 988 1
octets
Branch STRUCT Information relative to
of variable all routers or
size connection originators
on this link
num_devices UINT number of devices on
--`,,```,,,,````-`-`,,`,,`,`,,`---
this link
device STRUCT details of this device
of variable
size
type USINT types of device 1 = router
2 = connection
originator
Path_Size USINT size of path to node In 16 bit words
Path ARRAY of path to device
UINT
CO_data STRUCT Details of CO data Present only for
of variable CO devices
size (type = 2)

– 80 – 61158-4-2 © IEC:2007(E)

Name Data type
COP UDINT CO password, as
provided to the CO at
the end of a
scheduling session
(see 7.4.5.8)
Size UINT Size of Connection In 16 bit words
data
Connection STRUCT Connection data Connection Info
of variable Revision in the
size format specified
by connection_
info_revision of
attribute 0x104
One per
connection for
this CO device.
See 7.3.4.7
7.3.4.2 Operating state definitions
The values for the Keeper operating state shall be as defined in Table 22.
Table 22 – Keeper operating state definitions
Value Description
0 Power up - Not on line

1 Power up - TUI wait
2 Power up - TUI poll
3 Backup
--`,,```,,,,````-`-`,,`,,`,`,,`---
4 Master verify
5 Master
6 Faulted Backup
7 Faulted Master verify
8 Faulted Master
9 Net Change - Backup
10 Net Change - Master
11 Net Change - Faulted Backup
12 Net Change - Faulted Master
7.3.4.3 Port status flag bit definitions
The values for the Port status flag shall be as defined in Table 23.
Table 23 – Port status flag bit definitions
Bit Meaning
0 Node accepts scheduled connections bit

0 = Node does not accept scheduled connections
1 = Node accepts scheduled connections
1 – 15 reserved ( set to 0 )

61158-4-2 © IEC:2007(E) – 81 –
7.3.4.4 status_flag
The Keeper configured bit cleared in the TUI status word shall identify a Keeper with an
invalid configuration or cleared memory.
Referring to Table 24, the status_flag field of the TUI sub–attribute shall consist of a 16 bit
value. Unused flag bits shall be reserved and set to 0.
The holding network resource bit shall only be used by the Keeper object.
The Master Keeper bit shall indicate whether or not this node has ever heard from a master
Keeper. The ControlNet object shall clear this bit at initialization. All TUIs sent by the master
Keeper shall have this bit set. If a TUI Lpacket is received with the Master Keeper bit not set,
the Lpacket shall be retained as a received TUI, but the redundancy information shall not be
used.
The redundancy bits shall be used to override the default redundancy settings for the node.
They shall indicate if the link is being operated in the single channel mode or redundant. The
redundancy information shall not be used if a TUI Lpacket is received with the Master Keeper
bit clear.
The net change in progress bit shall indicate that a synchronized network change sequence is
in progress and that new nodes shall delay going on-line until the change sequence is
completed and the bit is cleared. This bit shall be cleared in the case of a network resource
timeout situation or if the network resource is released.
Table 24 – TUI status flag bits
Used in:
Bit Meaning RT_TUI Network_TUI ControlNet
object TUI
0-1 Network Redundancy

Bit 1 = 0, bit 0 = 0; Illegal combination
Bit 1 = 0, bit 0 = 1; Channel B only X X X
Bit 1 = 1, bit 0 = 0; Channel A only
Bit 1 = 1, bit 0 = 1; Redundant
2 Holding Network Resource bit
0 = Network Resource not being held
1 = Network Resource being held for the object X
identified in the TUI
3 Network change in progress bit
0 = No network change in progress X X X
1 = Network change in progress
4 Keeper State bit
0 = TUI transmitted by Keeper not in MASTER X X
state
1 = TUI transmitted by Keeper in MASTER
state.
5 Keeper configured bit
0 = Keeper attributes not configured (RT_TUI) X X X
1 = Keeper attributes configured (RT_TUI)
6 - 15 reserved ( set to 0 )
7.3.4.5 unique_ID
The unique_ID field of the TUI attribute shall consist of a 32-bit value calculated from the
contents of the Keeper attribute table (excluding the TUI attribute) by the software
configuration tool. The following attributes shall be used, in the given order to calculate the
TUI unique_ID:
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 82 – 61158-4-2 © IEC:2007(E)
0x1 through 0x63 (port parameters for nodes 1 through 99)

0xFF (link parameters
0x100 (link name);
0x101 (RT TUI) redundancy bits only;
0x103 (cable configuration);
0x105 (CO device password data only);
The TUI unique identifier shall be calculated as follows:
— the TUI unique identifier shall be initialized to 0;

— the data for attributes 0x1 through 0x63, attribute 0xFF, attribute 0x100, redundancy
setting (attribute 0x0101 RT_TUI status flag bits 0–1), 0x103 and each CO password (in
address order) shall be run through the CRC polynomial.
The polynomial used to calculate the CRC shall be

G(X) = X 32 + X 26 + X 23 + X 22 + X 16 + X 12 + X 11 + X 10 + X 8 + X 7 + X 5 + X 4 + X 2 + 1
as shown in Figure 17.
UDINT CRC( // (r) the updated CRC
unsigned long CRC, // (i) the CRC to start with
SWORD* buffer, // (i) pointer to buffer of SWORD / octets
WORD size) // (i) the number of octets in the buffer
# define KEEPER_CRC_POLY 0xEDB88320L
WORD octetIndex;
WORD bitIndex;
SWORD oneOctet;
// loop through the octets passed, including them in the CRC
for (octetIndex=0; octetIndex < size; octetIndex++)
{
oneOctet = buffer[octetIndex];
// loop through the bits passed, including them in the CRC
for (bitIndex = 0; bitIndex < 8; bitIndex++)
{
if ((oneOctet & 0x1) ^ (CRC & 0x1))
{
CRC = (CRC >> 1) ^ KEEPER_CRC_POLY;
} else {
CRC = (CRC >> 1);
}
oneOctet >>= 1;
}
}
// return the new CRC
return(CRC);
}
Figure 17 – Keeper CRC algorithm
7.3.4.6 Keeper MAC_ID
The Keeper_MAC_ID should be the MAC ID of the current master Keeper that is broadcasting
the TUI. If no TUI has been received in the last 12 NUTS, a value of 0xFF shall be returned.
7.3.4.7 Connection
Various formats exist for connection data. Each format is described below. The entire
collection of connection data entries shall be an integral number of words.
Format 1 does not specify the size of the path; therefore, its path[ ] shall be one of two forms:
— class segment, instance segment, then two connection point segments; or

— an ANSI extended symbol segment.
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 83 –
// Format 1
USINT O2T_Size // in 16 bit words
UINT O2T_Rpi // in 1 ms ticks from 2 to 32 767
USINT T2O_Size // in 16 bit words
UINT T2O_RPI // bit 15 = connection point, 0 = point to point, 1 = multipoint
// bit 14 = API in ms from 2 to 32 767
USINT O2T_Nui_Api // The highest bit set indicates the API;
// bit 7 = 128*NUT, bit 6 = 64*NUT, etc.
// Remaining bits indicate the O2T_NUI. If API = 1, NUI = 0
USINT T_Node // Range 1 – 99
USINT T2O_Nui_Api // The highest bit set indicates the API;
// bit 7 = 128*NUT, bit 6 = 64*NUT, etc.
// Remaining bits indicate the O2T_NUI. If API = 1, NUI = 0
--`,,```,,,,````-`-`,,`,,`,`,,`---
UINT path[] // forward open connection path from this
// Format 2
UINT O2T_net_params // copied from forward open
UINT T2O_net_params // copied from forward open
UINT O2T_RPI // RPI in floating point format
UINT T2O_RPI // RPI in floating point format
USINT O2T_schedule // from schedule segment in forward open
USINT MAC_ID
USINT T2O_schedule // from schedule segment in forward open
USINT path_size // in 16-bit words
UINT path[] // forward open connection path from this
UDINT convert_to_10us_ticks (UINT RPI)

{
return (RPI <= 0x4000) ? RPI :
(RPI <= 0xE000) ? (RPI & 0x1FFF) + 0x2000 << (RPI>>13) - 1 :
: (RPI & 0x0FFF) + 0x1000 << (RPI>>12 & 1) + 7;
}
UINT convert_to_Keeper_format (UDINT ticks)
{
if (ticks < 0x00004000) return RPI; // 0 - 16383 by 1
if (ticks < 0x00008000) return RPI>>1 & 0x1FFF | 0x4000; // 16384 - 32766 by 2
if (ticks < 0x00040000) return RPI>>4 & 0x1FFF | 0xA000; // 131072 - 262128 by 16
if (ticks < 0x00080000) return RPI>>5 & 0x1FFF | 0xC000; // 262144 - 524256 by 32
if (ticks < 0x00100000) return RPI>>7 & 0x0FFF | 0xD000; // 524288 - 1048448 by 128
if (ticks < 0x00200000) return RPI>>8 & 0x0FFF | 0xE000; // 1048576 - 2096896 by 256
return 0xFFFF;
)
7.3.4.8 Attribute data
A Keeper maintains the link and node configuration information for its link in an attribute data
structure. The Keeper shall keep two copies of the attribute structure: pending copy in RAM
and a current copy in non-volatile memory. When new attributes are set in the Keeper, they
shall be set in the pending RAM copy. The RAM copy shall be written to the currently active
copy in non-volatile storage only upon receipt of a special request to do so.
The attributes shall use the following rules for getting and setting:
— Set service requests set the pending copy in RAM;

— Get service requests get the current copy in non-volatile storage.
Keeper shall maintain the collection of attributes specified in Table 25:

– 84 – 61158-4-2 © IEC:2007(E)
Table 25 – Keeper attributes
Attribute number Keeper attributes
0x01 - 0x63 (port parameters for nodes 1 through 99)

0xFF (link parameters)
0x100 (link name)
0x101 (Keeper TUI)
0x103 (cable configuration)
0x104 (node offset information into CO data)
--`,,```,,,,````-`-`,,`,,`,`,,`---
0x105 (CO path and password information)
All Keeper attribute definitions assume a maximum of 99 nodes on the link. The Keeper object
shall have memory to store the CO_summary and CO_data attributes.
Memory requirements (in octets) for the Keeper attributes are as specified in Table 26.
Table 26 – Memory requirements (in octets) for the Keeper attributes
Octets Keeper attributes
2 Keeper status
990 Port parameters (99 nodes at 10 octets each)
12 link parameters
66 link name
22 TUI
100 Cable configuration
204 CO summary
14 988 CO data (7 494 words)
16 384 Total (Exactly 16K octets)
The sequence of events required to properly and safely update the Keeper attributes shall be
as follows:
a) obtain the Network Resource;

b) issue a Change_Start service request to the Keeper;
c) issue the appropriate Set_Attribute service request(s) to update the pending copy of the
Keeper attributes;
d) issue a Change_Complete service request to the Keeper. Doing this shall initiate a
synchronized parameter change;
e) release the Network Resource.
The Keeper common services shall all operate with an internal time out to prevent a hardware
error condition from indefinitely stalling operations. The actual time out values shall be device
dependent.
The Keeper object shall support the common services as specified in Table 27.

61158-4-2 © IEC:2007(E) – 85 –
Table 27 – Keeper object common services
Need in
code
Class Instance
0x03 N/A Required Get_Attribute_List Get network and node specific

configuration information
0x04 N/A Required Set_Attribute_List Set network and node specific
0x0E Required Required Get_Attribute_Single Get network and node specific
0x10 N/A Required Set_Attribute_Single Set network and node specific
--`,,```,,,,````-`-`,,`,,`,`,,`---
The Keeper object is capable of receiving these service requests via fixed tags 83 and 88.
When received via fixed tag 83, the request is processed and responded to as required
independent of Keeper state. When received on fixed tag 88, the Keeper will only respond to
the request if it is in the Master, Net Change Master, Faulted Master or Net Change Faulted
Master states. Keeper nodes in other states shall not respond to the request.
7.3.6.1 General
Any device that has implemented the Keeper object shall also implement the Keeper UCMM.
The Keeper object shall support the following class specific as specified in Table 28.

– 86 – 61158-4-2 © IEC:2007(E)
Table 28 – Keeper object class specific services
Need in
Service implementation Service name Description of service Parameter(s)
code
Class Instance
0x4B N/A Required Obtain_ Attempt to obtain the UINT vendor ID
Network_Resource Network Resource for this UDINT serial number
(ONR) link. UDINT class
If successful, hold for 60 s UDINT instance
0x4C N/A Required Hold_ Continue to hold the UINT vendor ID

Network_Resource previously obtained Network UDINT serial number
(HNR) Resource for this link for UDINT class
60 s UDINT instance
--`,,```,,,,````-`-`,,`,,`,`,,`---
0x4D N/A Required Release_ Release the Network UINT vendor ID

Network_Resource Resource for this link UDINT serial number
(RNR) UDINT class
UDINT instance
0x4E N/A Required Change_Start Copy current attributes in <none>
(CS) non-volatile storage to
pending attributes in RAM.
Enter the appropriate net
change operating state
0x4F N/A Required Change_Complete Copy pending attribute data 16 bit number of “sets”
(CC) in RAM to current data in performed since
non-volatile storage. Change_Start
Restart normal Keeper
operation.
Initiate synchronized
network change if net
attributes changed.
If number of sets does not
match, do change_abort
processing
0x50 N/A Required Change_Abort Discard changes made to <none>
(CA) the pending attribute data,
release the network
resource and return to
normal Keeper operation
0x51 N/A Required Get_Signature Get signature value for a Request: path size (octet)
(GS) specific connection (size is in words) path
originator (CO password) Response: 32 bit cop
0x52 N/A Required Get_Attribute_ Get a portion of an attribute UINT size; //words
Fragment specifically designed to be UINT offset; //offset
(GAF) fragmented, that is too large
to fit in a single Lpacket.
For use only on the co_data
attribute
0x53 N/A Required Set_Attribute_ Set a portion of an attribute UINT size; //words
Fragment specifically designed to be UINT offset; //offset
(SAF) fragmented, that is too large UINT data [ ]
to fit in a single Lpacket.
For use only on the
CO_data attribute
The error codes for these services shall be as specified in Table 29, where the service codes
are the abbreviations for the service names specified in Table 28.

61158-4-2 © IEC:2007(E) – 87 –
Table 29 – Service error codes
Error code use by service

Error code Meaning
ONR HNR RNR CS CC CA GS GAF SAF
0x02 resource_unavailable_err X X X X
0x03 invalid_parameter_err X X X X
0x04 path_segment_err X X X
0x05 path_dest_unknown_err X X X X X X X X X
0x08 unimplemented_service_err X X X X X X X X X
0x09 invalid_attr_err X X
0x0C wrong_object_state_err X X X
0x0D already_exists_err X X
0x0F no_permission_err X X
0x11 reply_too_large_err X
0x13 not_enough_data_err X X X X X X X
0x14 undefined_attr_err X
0x15 too_much_data_err X X
0x16 nonexistant_object_err X X X X X X X X X
0x26 invalid_path_size_err X X X X X X X X X
7.3.6.2 Network resource
The Network Resource (NR) shall be a link semaphore that is used to eliminate conflicts when
modifying attribute information in Keeper objects.
In operation, the NR shall appear as a status flag bit and other data fields in the TUI Lpacket
that shall be repetitively broadcast by the master Keeper.
--`,,```,,,,````-`-`,,`,,`,`,,`---
A device that wishes to update the Keeper attribute information first shall submit a request to
the master Keeper to obtain the NR on its behalf (via an Obtain_Network_Resource service).
This request shall be broadcast since the identity of the master Keeper is not generally
known. Once obtained, the device shall periodically ask (every 15 s) the master Keeper to
continue holding the NR via a Hold_Network_Resource service request. The master Keeper
shall maintain a 60 s timer that is started when the NR is initially obtained, and retriggered
when a subsequent Hold_Network_Resource request from the same node is received. If the
timer ever times out, the master Keeper shall automatically release the NR.
A backup Keeper shall respond to the Network Resource service requests as follows. When
an Obtain_Network_Resource service request is received, it shall start a 60 s timer that shall
be retriggered when a Hold_Network_Resource service request is received. The timer shall
also be started when a Keeper powers up on an existing network and senses that the network
resource is currently being held. The timer shall be stopped when a
Release_Network_Resource service is received or the timer expires.
When a backup Keeper becomes the master Keeper, it shall use the data from the most
recently received TUI Lpacket to hand off the holding of the NR from the old master Keeper.
In both master and backup Keepers, the 60 s timer shall be used to determine if the node
requesting the NR has failed or has been prematurely removed from the network. When a
Keeper’s 60 s NR timer expires, the Keeper shall
a) abort any attribute changes in progress;

– 88 – 61158-4-2 © IEC:2007(E)
b) reset the net change in progress TUI status bit;

c) exit the net change operating state;
d) return to normal operation.
Since the NR can be held over a fairly long period if the user is performing substantial edits,
the NR shall be cleanly handed off to the new master Keeper if the master Keeper changes.
This handoff shall be invisible to the node that the master Keeper is holding the NR for. Since
all information regarding the NR is contained in the TUI Lpacket being broadcast by the
master Keeper, and since backup Keepers are receiving the broadcast TUI and are using the
broadcast TUI for determining if and when they should take over as master Keeper, the
backup Keepers shall have all the information needed to cleanly transition holding the NR
when the appropriate backup Keeper takes over as master Keeper.
Faulted backup and master Keeper shall process Network Resource requests in the same
way as non-faulted backup and master Keeper.
When the network resource is not being held, the related fields in the network TUI Lpackets
shall be zeroed:
— NR VENDOR_ID;
— NR SERIAL_NUMBER;
— NR CLASS;
— NR_INSTANCE.
7.3.6.3 Obtain_Network_Resource service
The Obtain_Network_Resource service request shall cause the master Keeper to hold the
Network Resource for 60 s for itself or another node, if it is not already being held. The time
period that the Network Resource is held may be extended indefinitely through use of the
Hold_Network_Resource service request.
If the Network Resource is already being held for any node, an error status shall be returned.
The Obtain_Network_Resource service shall return the error codes as defined in Table 29, as
designated in column ONR for this service.
7.3.6.4 Hold_Network_Resource service
The Hold_Network_Resource service request shall cause the master Keeper to continue
holding the Network Resource for the next 60 s if the node requesting the hold is the same
node for which the master Keeper is currently holding the Network Resource.
If the Network Resource is being held for another node or is not being held, an error status
shall be returned.
The Hold_Network_Resource service shall return the error codes as defined in Table 29, as
designated in column HNR for this service.
7.3.6.5 Release_Network_Resource service
The Release_Network_Resource service request shall cause the master Keeper to stop
holding the Network Resource if the node requesting the release is the same node for which
the master Keeper is currently holding the Network Resource. If a network change is in
process and the network resource is released, the network change will be aborted.
Whether the Network Resource is being held for another node or is not being held, an error
status shall be returned.
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 89 –
The Release_Network_Resource service shall return the error codes as described in

Table 29, as designated in column RNR for this service.
7.3.6.6 Change_Start service
The Change_Start service request shall cause the Keeper object to:
a) copy the current copy of the attributes in non-volatile storage into the pending copy in
RAM;
b) clear the count of Set_Attribute service requests (including set single, list and fragment)
received by the ControlNet object;
c) put the Keeper object into the appropriate net_change operating state.
This service request shall only be processed if the Network Resource is being held by the
master Keeper as indicated by the net_resource bit in the broadcast TUI Lpacket.
The Change_Start service shall return the error codes as defined in Table 29, as designated
in column CS for this service.
7.3.6.7 Change_Complete service
The Change_Complete service request shall cause the Keeper object to:
a) copy its pending copy of the attributes from RAM to the current copy of the attributes in
non-volatile storage;
b) perform a synchronized network change;
c) verify tool_keeper_revision in attribute 105 is ≤ Keeper object revision (if not true, mark
attribute table invalid);
d) exit whatever network change operating state it is in;
e) return to normal Keeper operation.
If the Keeper object is not in one of the net change operating states, the Change_Complete
service request shall be ignored and an incorrect state error response shall be generated.
If the number of Set_Attribute service requests (including: Set_Attribute_Single,

Set_Attribute_List and Set_Attribute_Fragment) received by the Keeper object since the
Change_Start service request does not match the number in the Change_complete
parameter, a Change_Abort shall be executed instead and an error response shall be
generated.
The reply to this service shall be returned after at least one TUI is broadcast with the
net_change_in_progress bit cleared. A synchronized change shall take place prior to the TUI
transmission with the bit reset.
The Change_Complete service shall return the error codes as defined in Table 29, as
designated in column CC for this service.
7.3.6.8 Change_Abort service
The Change_Abort service shall cause the Keeper object to
a) discard changes made to the pending attribute data;

b) release the network resource;
c) return to normal Keeper operation.
The reply to this service shall be returned after at least one TUI is broadcast with the
net_change_in_progress bit and holding_network_resource bit cleared.
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 90 – 61158-4-2 © IEC:2007(E)
The Change_Abort service shall return the error codes as defined in Table 29, as designated
in column CA for this service.
7.3.6.9 Get_Signature service
The Get_Signature service shall cause the master Keeper to look up the CO password values
for a connection originator in the CO_data attribute. The path to the device shall be given as
the attribute in the request. This path shall be parsed and used to search the tree structure of
the CO_data one branch at a time, to locate the appropriate COP (CO password) value, which
is returned as a parameter in the response.
The path shall be parsed one branch at a time since the path entries in the CO_data attribute
only specify the portion of the path between one branch and the next, not the entire path to
that branch.
The Get_Signature service shall return the error codes as specified in Table 29, as
designated in column GS for this service.
7.3.6.10 Get_Attribute_Fragment service/response
The Get_Attribute_Fragment service shall collect and return some portion of the CO_data
attribute data managed by the Keeper object. Any part of this attribute may be read. The
CO_data attribute shall be the only Keeper attribute which responds to fragment services.
Accessing other attributes shall cause an error to be returned.
NOTE When getting attribute data, the current attribute data from non-volatile storage, not the pending copy of
the attribute should be returned.
The Get_Attribute_Fragment service shall return the error codes as defined in Table 29, as
designated in column GAF for this service.
7.3.6.11 Set_Attribute_Fragment service
The Set_Attribute_Fragment service shall be used to set any portion of the CO_data attribute
managed by the Keeper object. Only the CO_data attribute shall be accessed via this service.
Accessing other attributes shall cause an error to be returned.
The Set_Attribute_Fragment service shall be processed only when the Keeper object is in one
of the net change operating states. The Keeper object shall return an invalid mode error if it is
not in one of the net change operating states when a Set_Attribute_Fragment service request
is received.
Setting attribute data, shall set the pending copy of the attribute, not the current copy in non-
volatile storage. The pending attributes shall be copied to the current attributes in non-volatile
storage upon reception of a class specific Change_Complete service request.
The Keeper object shall not perform attribute value checking during any set operation.
The Set_Attribute_Fragment service shall return the error codes as defined in Table 29, as
designated in column SAF for this service.
7.3.6.12 Table unique identifier (broadcast), fixed tag 0x84
When the Keeper object is in the master verify, faulted_master_verify, master,

faulted_master, net change master or net_change_faulted_master operating state, it shall
attempt to transmit a special Table Unique Identifier (TUI) Lpacket as scheduled data once
every 4 NUTs (that is, on NUT numbers 0, 4, 8, 12, 16 …). All Keeper devices shall reserve
26 octets of scheduled link transmit time once every 4 NUTs for transmitting this Lpacket. If
sent unscheduled, it shall be the highest QoS priority unscheduled information.
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 91 –
When generating the transmitted TUI Lpacket, any reserved fields shall use the values as
specified in the corresponding reserved fields of attribute 0x0101. The programming tool shall
set any reserved fields in attribute 0x0101, to zero.
The format of the TUI Lpacket link data shall be as defined in Table 30.
Table 30 – Wire order format of the TUI Lpacket
Name Data type Description of parameter Semantics of values
Size USINT Size of the Lpacket in words. 0x0D

Control USINT Link layer Lpacket control octet. 0x01 (Fixed tag
Lpacket)
Fixed_Tag USINT Fixed tag value. 0x84 (TUI Lpacket)
Destination_Mac_Id USINT Who receives the Lpacket. 0xFF (Broadcast)
Unique_Id UDINT CRC of the Keeper’s current Least significant octet
attributes. first.
Status_Flag UINT TUI flag values. See the TUI attribute
for details.
Keeper_Mac_Id USINT MAC ID of the Keeper broadcasting See the TUI attribute
the TUI. for details.
Reserved USINT Reserved for data alignment
Net_Resource_Vendor_Id UINT Vendor ID of object holding Net
Net_Resource_Serial_Number UDINT Serial number of object holding Net
Net_Resource_Class UDINT Class number of object holding Net
Net_Resource_Instance UDINT Instance number of object holding
Net Resource for exclusive use
7.3.7 Service error codes
Table 31 lists possible error codes and the most likely condition under which the code would
be returned.
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 92 – 61158-4-2 © IEC:2007(E)
Table 31 – Service error codes
Error
Meaning Return condition
code
0x02 resource_unavailable_err The requested network resource is not available
0x03 invalid_parameter_err An invalid parameter was provided to the service
0x04 path_segment_err Whenever an path over and above the attribute number is specified
0x05 path_dest_unknown_err Object instance does not exist
0x08 unimplemented_service_err Whenever the service is not supported for an attribute
0x09 invalid_attr_err Whenever an attribute is specified which is not supported in this object
0x0C wrong_object_state_err The object is in a state which does not allow the service to be performed
0x0D already_exists_err The service has already been obtained by the requesting node
0x0E not_settable_err Attribute is not settable
0x0F no_permission_err Node requesting this service does not currently own the resource
0x11 reply_too_large_err Not enough room in the response buffer to reply
0x13 not_enough_data_err Whenever the request does not contain enough data
0x14 undefined_attr_err Attempts to access an undefined attribute
0x15 too_much_data_err More data has been encountered than expected for this service request
0x16 nonexistant_object_err Keeper object not available
0x26 invalid_path_size_err Whenever an invalid path segment for this service is specified
7.3.8 Behavior
The numeric indication of Keeper state shall be as defined in Table 32.
Table 32 – Keeper object operating states
State Description
0,1,2 The Keeper object is either waiting for the node to come on-line or is determining if it
– Power up is a legitimate Keeper for this link
3 The Keeper object has determined that it is a legitimate Keeper for this link but
– Backup either has determined it is a backup Keeper or has not yet determined if it is the
master Keeper for this link
4 The Keeper object has determined that it is a legitimate Keeper for this link but has
– Master Verify not heard another active Keeper on the link or has received a good TUI from a
matching Keeper at a higher node number or has heard a TUI from a faulted Keeper.
It starts broadcasting the TUI Lpacket but does not process synchronized parameter
changes or respond to requests of the master Keeper
5 The Keeper object has determined that it is a legitimate Keeper for this link and that
– Master it is the master Keeper for this link. It broadcasts the TUI Lpacket, processes
synchronized link changes when required to change link parameters and shall
respond to requests of the master Keeper
6 The Keeper object has determined that it is not a legitimate Keeper for this link, and
– Faulted Backup is not the Keeper if there are only faulted Keepers on the link
7 The Keeper object is faulted but has not heard another active Keeper on the network
– Faulted Master Verify for 12 NUT times. It starts broadcasting the TUI Lpacket but does not process
synchronized link changes or respond to requests of the master Keeper
8 The Keeper object is faulted and has assumed faulted master Keeper duties. There
– Faulted Master are no unfaulted Keeper’s on the network. It broadcasts the TUI Lpacket, processes
synchronized link changes when required to change network parameters and shall
respond to requests of the master Keeper
9,10,11,12 The Keeper is having its attributes updated. There is a Net Change substate for the
– Net Change backup, master, fault and faulted master states previously discussed. The separate
substates are needed so the Keeper object can exit the Net Change state properly
when updates complete normally and when updates are aborted. The pending
attributes may be set only when the Keeper is in a Net Change state. Nodes in the
net change master and net change faulted master shall respond to requests of the
master Keeper. Nodes in the net change backup or net change faulted backup states
shall not respond to requests of the master Keeper
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 93 –
7.3.9 Miscellaneous notes
Keepers shall maintain parameters only for nodes on the same link.
Each Keeper shall be capable of distributing link parameters to all nodes on that link. The
master Keeper shall be the Keeper with the lowest MAC ID of all the legitimate Keepers on
the link. A faulted master Keeper on a link may or may not be the lowest MAC ID.
The Keeper shall be responsible for configuring those devices that appear in its attributes.
The master Keeper shall be the only Keeper that issues responses to service requests via
fixed tag 0x88 that are broadcast to all Keeper objects on a net.
All legitimate Keeper objects on a link shall have identical copies of the network attributes for
all devices on the link. Keepers that do not agree with the master Keeper shall stay in the
faulted backup state until they agree (agree means their TUI unique_id parameters are
identical).
Only one programming terminal may modify Keeper attributes at a time. The programming
terminal shall acquire the Network Resource prior to starting the Keeper modification and
shall retain possession of the Network Resource during the entire modification procedure. If a
programming terminal makes a change to a Keeper, it shall update all of the other Keepers on
the link as well by broadcasting the Change_Start, Set_Attribute, and Change_Stop service
requests.
The Keeper shall check the “tool Keeper revision” in attribute 0x0104 for a valid attribute
table. If the Keeper is unable to understand that revision, the Keeper shall clear bit 5 in any
TUI transmissions so that other more capable Keepers can assume the master Keeper
responsibilities. Keeper revisions 0 and 1 shall be identical to revision 2.
The “connection info revision” value is independent on the Keeper revision, and shall only be
utilized by programming tools.
The Keeper may, for network diagnostic purposes, broadcast to all nodes a debug fixed tag
(0x90) Lpacket with three words of data. The first word identifies that the Keeper object is
sending the diagnostic. The second word is the current “Keeper state” and the third word is
the next “Keeper state”.
--`,,```,,,,````-`-`,,`,,`,`,,`---
7.3.10 Keeper power up sequence
7.3.10.1 General
The Keeper power up sequence shall allow the Keeper object to begin operations under a
variety of conditions, from a normal configured network power on state to one where many
network devices are new and unconfigured.
The Keeper object power up sequence shall not begin until the NAM has brought the Keeper
node on-line. The Keeper power up shall determine if this particular Keeper device is a
legitimate Keeper for the local link and to bring the Keeper object into either the backup or
faulted backup operating state.
If this device is a legitimate Keeper for the link, the Keeper object shall determine if it is the
master Keeper or a backup Keeper for the link. If this device is not a legitimate Keeper for the
link, the Keeper object enters a fault state. An unconfigured Keeper shall enter the fault state
at power up.
The 12*NUT timer shall be retriggered whenever a TUI Lpacket is received that indicates the
NR is being held. This shall indicate that the Keeper attributes are being updated.

– 94 – 61158-4-2 © IEC:2007(E)
The Keeper object’s power up sequence is illustrated in Figure 18.
NAM is attached
Keeper has valid
Attributes and
Net parameters
do not match those in the Keeper attribute table valid in
attributes Complete non-volatile storage
-OR- -AND-
Keeper has invalid attributes Net parameters are default parameters
in non-volatile storage or the Network is quiet
Start Keeper object
power up
No response
from any Net parameters Set reminder to
polled node match those in the initiate synchronized
after 1 pass attributes network change
in master state
Rx TUI
match
Rx TUI NR not held
Faulted mismatch
12*NUT timer Backup
Backup
Rx TUI match
NR held
Timeout
Rx TUI match
NR held
Poll for TUI

Rx TUI mismatch unique_id Rx TUI match
-OR- NR not held
TUI unique_id mismatch from polled -OR-
node configured by a Master Keeper TUI unique_id match
from polled node
-OR-
all responses from the polled
nodes indicate that no nodes
responded as being configured by
a master keeper
Figure 18 – Keeper object power-up state diagram
7.3.10.2 Poll for TUI unique_id
The Poll for TUI unique_id state in Figure 18 shall require the following operation be
performed by the Keeper object:
a) Issue a UCMM request to the addressed node’s ControlNet object to read the object’s
current configuration parameters. Should the request fail, proceed on to the next MAC ID
until UMAX is reached. Multiple concurrent requests may be permitted to reduce the poll
time.
b) Each MAC ID in the range 1 through UMAX (excluding the MAC ID of the Keeper node)
may be polled singly or concurrently with a Get_Attribute_Single request on the
current_link_config attribute of the ControlNet object of the node. This attribute contains a
copy of the current TUI attribute for the node. Concurrent access to multiple nodes at one
instant will serve to accelerate the polling process.
c) If no response is heard from any polled node and UMAX has been reached, the poll is
aborted and the Keeper object shall transition to the “Start Keeper object power up state”,
since at least one other node on a non-default network is present but unable to respond.
This will allow the power up poll process to repeat until a node is capable of responding.
d) If a response is received from a polled node and the “Keeper State” bit in the returned TUI
status_flag was set, the polled node was configured by a Keeper in the “Master” operating
state. Compare the TUI unique_id value returned by the polled node to the one in this
Keeper’s attribute table. If it matches, the poll is aborted and the Keeper object shall
transition to the “backup” operating state. If it mismatches, the poll is aborted and the
Keeper object shall transition to the “faulted backup” operating state.
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 95 –
e) If a response is received from a polled node and the “Keeper State” bit in the returned TUI
status_flag was not set, the polled node was not configured by a Keeper in the “Master”
operating state. In this case, the information is discarded and the poll continued. If all
nodes respond in this way, indicating that none of them were configured by a Keeper in
the “Master” operating state, the poll is terminated and the Keeper shall transition to the
“backup” operating state since in this situation, all nodes are either new or have lost their
stored configuration.
--`,,```,,,,````-`-`,,`,,`,`,,`---
7.3.10.3 Operating states
The Keeper object operating states shall be defined as in Figure 19, Table 33, and the
following sections.
All States
NAM leaves attached state
Wait for NAM

Power up
NAM enters attached state

Power Up Complete Power Up Complete
Goto Faulted Backup Goto Backup
Power Up
Change_Abort –or- Change_Abort –or-
Change complete –or- Change complete –or-
No TUI 12 NUTs –or- No TUI 12 NUTs –or-
NR timer expires Rx TUI good match NR timer expires
Net Change Net Change
Faulted Backup Faulted Backup Backup Backup
Change_Start Change_Start
Rx TUI good mismatch –or-
Attribute table unconfigured
No Rx TUI for 12 NUTs –OR-
Rx TUI good higher match –OR-
No Rx TUI for 12 NUTs Rx TUI faulted
Faulted
Master Verify Master Verify
Rx TUI good lower
Rx TUI good –or-
Rx TUI faulted lower
12 NUTs in 12 NUTs in
Faulted Master Master Verify
Verify Attribute table configured
Rx TUI good –or- and successful net change
Rx TUI faulted lower Rx TUI good lower
completed
Faulted Master Master
Attribute table unconfigured

Change_Complete –OR-
Change_Start
Change_Abort –OR- Change_Start
NR timer expires
Change_Abort -OR-
NR timer expires -OR-
Change_Complete
Net Change Net Change
Faulted Master Master
Figure 19 – Keeper object operating state diagram

– 96 – 61158-4-2 © IEC:2007(E)
Table 33 – Keeper object state event matrix

Event State
Power Backup Master Master Faulted Faulted Faulted Net Net Net Net
Up Verify Backup Master Master Change Change Change Change
Verify (Back-up) (Master) (Faulted (Faulted
Backup) Master)
Rx TUI from a good Goto Goto

node Faulted Faulted
Backup Backup
Rx TUI from a good Goto

lower node Backup

higher node Master
(match) verify

node (mismatch) Faulted
Backup

node (match) Backup
Rx TUI from a Goto

faulted node Master
Verify
Rx TUI from a Goto

faulted lower node Faulted
Backup
No TUI Rx for Goto Goto Abort Abort

12*NUT Master Faulted change. change.
Verify Master Goto Goto
Verify Backup Faulted
Backup
12 Nut times Goto Goto

elapse Master Faulted
Master
Change_Start Goto Goto Goto Goto

Net Net Net Net
Change Change Change Change
Backup Master Faulted Faulted
Backup Master
Change_Complete Goto Goto Goto Goto

Backup Master Backup Master
verify
Change_Abort Do Do Do Do
Change Change Change Change
Abort. Abort. Abort. Abort
Goto Goto Goto Goto
Backup Master
60 s Network Abort Abort Abort Abort

Resource timer change. change. change. change.
expires Goto Goto Goto Goto
--`,,```,,,,````-`-`,,`,,`,`,,`---
Backup Master
NAM leaves Goto wait for NAM powerup

attached state
Power up complete Goto

to Backup Backup
Power up complete Goto

to Faulted Backup Faulted
Backup
NOTE Blank cells indicate that this event cannot occur, or if it does occur, no action shall be taken by the Keeper
object.

61158-4-2 © IEC:2007(E) – 97 –
7.3.10.4 Network resource
Access to changing Keepers shall be controlled through the use of the Network Resource.
Only one device can acquire the Network Resource for exclusive access at a time.
The Network Resource shall be held by the master Keeper for the node performing the
attribute updates. If the master Keeper does not hear from the node performing the update at
least once every 60 s, the master Keeper shall automatically release the Network Resource,
abort the change in progress, and return to normal operation.
7.3.10.5 Faulted Keeper
Any Keeper whose TUI unique_id attribute does not match that of the broadcast TUI from a
Keeper shall enter a fault state unless a net change operation is in progress.
7.3.10.6 MAC ID chooses master Keeper
The Keeper node MAC ID included in the TUI message shall be used by the Keeper to
determine which Keeper on a link is the master Keeper.
7.3.10.7 Master verify
The Keeper shall wait for 12*NUT after the first TUI broadcast begins before assuming master
Keeper status. This shall be sufficient time for a Keeper with a lower MAC ID to become
master Keeper. Other Keepers become backup Keepers.
7.3.10.8 Rogue
If the node containing the Keeper rogues during a synchronized network change sequence,
the “Net Change in Progress” bit shall be cleared and control shall be returned back to the
start of the synchronized network change processing immediately after the NAM brings the
node back on-line. The normal Keeper object power-up sequence shall be bypassed.
7.3.10.9 Synchronized network change processing algorithm
Although the moderator is used by the link to distribute operating parameters, it shall be the
responsibility of the Keeper object to initiate changes to the link parameters.
All link parameter changes shall be accomplished through the use of a synchronized network
change algorithm. This shall provide a means for all nodes on the network to change their
current link parameters in unison without disrupting network operation.
The algorithm for the synchronized network change operation shall be as defined in Figure 20.
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 98 – 61158-4-2 © IEC:2007(E)
Synchronized network change
Rogue detected
Note 3 Set "Net Change in Progress"
bit in broadcast TUI.
Note 1
Rogue detected
Using the UCMM datagram
Note 3 broadcast a set_single of
pending_net_config
attributes 3 times in
different NUTs
Rogue detected
Note 3 Broadcast global t-minus with
count yielding 500 msec. or 25
NUTs, whichever is greater.
Timeout
Note 2
Clear "Net Change in Wait for t-minus completion

Progress" bit in Rogue detected or 5 second timeout
broadcast TUI and
Rejoin network via Note 3
the NAM.
T-minus completed
Clear "Net Change in Progress"

bit in broadcast TUI
Done
NOTE 1 Broadcasting a TUI with the net change in progress bit set forces nodes that are just powering up to hold
off from going on-line until after the network change completes and the net change in progress bit in the broadcast
TUI is cleared. This reduces the chances of a rogue event occurring.
NOTE 2 The tMinus delay count provides noise immunity and insures that all nodes will hear at least one
moderator with the new tMinus count. It also allows nodes a reasonable amount of time to process the Set_Single
packets with new network attributes. The delay count is determined by taking the maximum of 25 or the result of
dividing 500 ms by the current nut time in ms.
NOTE 3 The rogue condition will occur only if the moderator node and at least one other node did not receive one
of the three broadcast set network attribute service request packets. This would only occur if there was a serious
noise event (lasting at least 3 NUTs in duration).
Figure 20 – Synchronized network change processing
7.4 Scheduling object
7.4.1 Overview
The Scheduling object shall exist in connection originator (CO) devices. The Scheduling
object shall be used by link scheduling software (LSS) to
a) read scheduled connection information;

b) write schedule information;
c) provide the CO with a password (software key) which shall be used to authenticate the CO
device’s access to a specific link.
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 99 –
A LSS session with the Scheduling object schedules a particular link. If a CO device has
connections on multiple links, multiple LSS sessions shall be needed to schedule all the
connections. The results of the scheduling session shall be saved by the CO device (including
the CO password computed by the LSS).
Since the LSS may be integrated with the programming software (PS) for a CO device, the
Scheduling object shall provide commands which support integrated or a separate PS.
Specifically, when the LSS writes Scheduling data to the Scheduling object, it may write
conditionally or it may force the write. A conditional write of Scheduling data shall be used if
the PS and LSS were not integrated and the Scheduling object shall only use the provided
Scheduling data if a separate PS has not changed the connection information during the LSS
session. A forced write may be used with an integrated LSS/PS if the integrated tool can
guarantee that no other PS has changed connection information since it was last read during
the current Scheduling session.
All communication to the Scheduling object shall use the Unconnected Message Manager
(UCMM) fixed service, or an active Generic tag connection service to the Message Router
object.
The Scheduling object shall support the class attributes as specified in Table 34. The
Get_Attribute_All service shall return the class level attributes in numerical order, smallest to
largest.
Table 34 – Scheduling object class attributes
Attribute Need in Access

Name Data type Description of attribute
ID implementation rule
0x01 Required Get Revision UINT First revision, value = 1

0x02 Required Get MaxInstance UDINT maximum number of Scheduling objects
s supported
0x03 Required Get NumInstanc UDINT number of instantiated Scheduling
es objects
The Scheduling object shall support the instance attributes as specified in Table 35. The
Get_Attribute_All service shall return the attribute level attributes in numerical order, smallest
to largest.
– 100 – 61158-4-2 © IEC:2007(E)
Table 35 – Scheduling object instance attributes
Attribute Need in Access

Name Data type Description of attribute
ID implementation rule
0x01 Required Get/Set Route STRUCT of route from CO to the link being
variable scheduled
size
NumSegments UINT number of segments in path
Segments ARRAY of array of segments
UINT
0x02 Required Get/Set TimeOut UDINT watchdog time-out μs
(default = 60 s)
0x03 Optional Get/Set Controller UINT bit 0 (run/program)
State = 0, may be programmed
= 1, currently controlling I/O
bit 1 (remote/local)
= 0, bit 0 shall not be changed
remotely
= 1, bit 0 may be changed remotely
bit 2-15 reserved and shall be zero
7.4.4.1 General
In addition to the services described in this subclause, the Scheduling object shall support the
standard Get_Attribute_All service addressed to the class instance (instance zero). A specific
Scheduling object implementation may optionally support other standard attribute services.
The Scheduling object shall support the common services as specified in Table 36.
Table 36 – Scheduling object common services
Need in
code
Class Instance
0x01 Required Optional Get_Attribute_All Returns a predefined listing of

this objects attributes Modifies
all settable attributes
0x02 N/A Optional Set_Attribute_All Modifies all settable attributes
0x03 Optional Optional Get_Attribute_List Returns the contents of a list of
specified attributes
0x04 N/A Optional Set_Attribute_List Modifies a list of settable
attributes
0x08 Required Optional Create Used to instantiate a Scheduling
object
0x09 N/A Required Delete Used to conclude a LSS
Scheduling session
0x0E Optional Optional Get_Attribute_Single Returns the contents of the
specified attribute
0x10 N/A Optional Set_Attribute_Single Modifies a single attribute
An implementation may support setting the route instance-level attribute, but if it does, the
--`,,```,,,,````-`-`,,`,,`,`,,`---
internal behavior shall be indistinguishable from a delete service followed by a create service
containing the new route.

61158-4-2 © IEC:2007(E) – 101 –
7.4.4.2 Create
The create service shall be used to instantiate a Scheduling object on the CO. Within the
create message, the client (LSS) shall include a route pointing from the CO to the link to be
scheduled. The route to the link shall consist of port segments and shall not contain network
segments. The Scheduling object shall reply with an instance number to which all further
communication shall be addressed for this Scheduling session, and with the currently stored
CO password and path.
The new instance shall delete itself if communications to its client are severed.
Communications to an instance shall be monitored via a watchdog timer whose time-out value
(default = 60 s) can be set via one of the optional set attribute services. The watchdog timer
for an instance shall be reset when it receives any message. If the timer expires, the instance
shall be deleted aborting all pending changes. The time-out value shall be a 32-bit integer
with units of µs.
If the create service is addressed to the class level (instance zero), the instance number of
the newly created instance shall be chosen automatically by the Scheduling object. For debug
purposes, the Scheduling object may optionally allow the create service to be addressed to a
specific instance number.
The Scheduling object shall support at least one instance. If the Scheduling object allows
more than one instance to exist, it shall ensure the integrity of all its instances. The value of
instance attribute 0x01 shall be provided with the create service.
class Scheduling_Create_Request : public MR_Request
{
UINT number_of_attributes; // set to 1
InstanceAttribute1 attribute1;
}
class Scheduling_Create_Response : public MR_Response
{
UDINT instance_number;
UDINT cop; // Connection Originator Password (COP)
UINT path_size; // in words, range 0 to 255
UINT path[]; // array of port segments from the scheduled link
// to the connection originator
// no key segments, no network segments
// include the MAC ID of the link hop
};
The response shall include one of the status codes shown in Table 37.
Table 37 – Status error descriptions for Create
General Extended
Error description
status status
0x02 0x0001 Insufficient resource — maximum number of Scheduling object

instances already exist
0x0002 Insufficient resource — not enough memory on CO device
0x04 N/A Path syntax error
0x08 N/A Unimplemented service (since non-zero instances are optional)
0x10 N/A Cannot open another instance due to internal conflicts
0x13 N/A Insufficient request data — request was too short or truncated
0x0D N/A Object already exists (when non-zero instance specified)
0x1C N/A Attribute list shortage — required attribute was missing
0xDO N/A No scheduled connections on this link
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 102 – 61158-4-2 © IEC:2007(E)
7.4.4.3 Delete
The delete service shall be used to conclude a LSS Scheduling session. It deallocates all
resources for a specified instance of the Scheduling object. Any pending changes which have
not yet been committed shall be lost. Connections which have been broken by commands
earlier in the LSS session shall not necessarily be restored. The delete service shall not be
supported at the class level. The response of this service shall be as specified in Table 38.
Table 38 – Status error descriptions for Delete and Kick_Timer
General Extended
Error description
status status
0x00 N/A Success

0x05 N/A Instance undefined
0x08 N/A Unimplemented service (if directed to instance 0)
7.4.5.1 General
The Scheduling object shall support the following class specific services as specified in
Table 39.
Table 39 – Scheduling object class specific services
Need in
code
Class Instance
0x4B N/A Required Kick_Timer Reset the watchdog timer within

the Scheduling object
0x4C N/A Required Read Read information about the
scheduled connections
0x4D N/A Required Conditional_Write Write the schedule information
back to the CO device
0x4E N/A Optional Forced Write Write the schedule information
back to the CO device
0x4F N/A Required Change Start Iinitiate a Scheduling data
change
0x50 N/A Required Break Connections Break all affected connections
after new Scheduling data
--`,,```,,,,````-`-`,,`,,`,`,,`---
0x51 N/A Required Change Complete Indicate that all scheduled

connections have been broken
0x52 Required N/A Restart Connections Break all connections which use
a specific link
7.4.5.2 Kick_Timer
The kick_timer service shall reset the watchdog timer within an instance of the Scheduling
object without otherwise affecting the state of the Scheduling object. The LSS shall issue a
command at a rate of four per time-out period. For example, the LSS shall issue a service
request every 15 s if the time-out value is set to the default 60 s. All other Scheduling object
services, directed to this Scheduling instance, shall also reset the watchdog timer so the kick
timer service need only be used if the client (LSS) wants to keep a Scheduling object instance
alive but has nothing to say.

61158-4-2 © IEC:2007(E) – 103 –
The watchdog timer for an instance shall be reset when it receives any message; however, it shall
not start its countdown until the corresponding response is sent. This shall be to allow for a single
task implementation. The response of this service shall be as specified in Table 38.
7.4.5.3 Read
The read service shall be used by the LSS to read information about the scheduled
connections that the CO device desires to create on a specific link. The connection
information shall come from an application object within the CO device.
A read service request shall contain a required UDINT parameter that specifies which
connection index on which to start the read. The Scheduling object shall reply to a read
service with as much connection information as can be fit into a reply Lpacket. The
connection indexes within an Lpacket shall be ordered from smallest to largest (gaps shall be
allowed). The extended status field within the reply shall indicate whether connections with
higher indexes exist in the CO device. A client (LSS) shall continue to submit read requests
with higher starting indexes until it reads all the connection information for the chosen link. An
extended status of 0 shall indicate that more connections exist in the device. An extended
status of 1 shall indicate that all connections have been read.
The reply shall consist of a UINT indicating the number of connections described in this
response followed by a series of entries each describing a connection that meets the
connection request criteria (the route to the link). Each entry shall have a unique Scheduling
data index that is chosen by and shall primarily be used by the CO. The last one of these can
--`,,```,,,,````-`-`,,`,,`,`,,`---
be incremented by the LSS to continue the request if it is too long for a reply.
Other parameters provided in the connection entry shall describe the connection sizes,
connection types (multi-cast/point to point) and connection update rates (RPIs). The
connection entry route information shall consist of the route from the link to the target module
for the connection including the connection points within the target module. Port information
need not actually be used by the LSS.
This route shall also contain the current values assigned for the connection in the network
segments. The network segments shall contain both API (Lpacket interval) and starting NUT
information.
class Scheduling_Read_Request : public MR_Request
{
UDINT first_connection_index;
}
class Scheduling_Read_Response : public MR_Response

{
UINT number_of_connections;
Scheduling_Connection_Description desc[];
}
class Scheduling_Connection_Description
{
UDINT connection_index;
UINT O2T_parameters;
UINT T2O_parameters;
UDINT O2T_RPI;
UDINT T2O_RPI;
UINT path[]; // array of path segments
// first segment is always O=>T schedule segment
// second is always port segment onto the link
// third is always T=>O schedule segment
// remaining path including logical segments
// and other port segments if multihop connection
};
The scheduling tool, LSS, shall use the logical segments of the target path to determine
whether more than one connection request actually uses one multipoint producer. The rule for
all objects except the Assembly object shall be that a match of class, instance, T⇒O
connection point, and any finer granularity (for example attribute or member) constitutes a
unique producer and it shall be scheduled once for both connections. Since the Assembly

– 104 – 61158-4-2 © IEC:2007(E)
object equates instance and connection point, a match on connection path instance shall not
determine whether the producer is unique.
For example, these two connection paths specify the same producer (instance 0x88 of the
Assembly object):
"20 04 24 03 2C 99 2C 88";
"20 04 24 AA 2C 77 2C 88".
These two connection paths specify different producers since the logical class segment do not match:
"20 77 24 03 2C 99 2C 88";
"20 77 24 AA 2C 99 2C 88".
The status response of this service shall be as specified in Table 40.
Table 40 – Status error descriptions for Read
General Extended
Error description
status status
0x00 N/A Success

7.4.5.4 Conditional_Write
Conditional_Write service shall be used by the LSS to write the schedule information back to
the CO device. Receipt of this message shall indicate that specific indexes of the connection
information are being rescheduled by the LSS. A CO device may start breaking the current
connections associated with the connection indexes, or it may wait until the receipt of a
subsequent break connections service request.
If the new schedule provided by the LSS exactly matches the current schedule for a given
connection, the CO device may ignore that part of the write request. A Scheduling object
implementation may reply with an out of resource error if it receives updates for more
connections than it has been queried about (via read requests). An implementation may also
check for duplicate write requests; thereby, allowing retries — more write requests than read
requests. The connection indexes may not be in order.
The difference between the conditional write service and the forced write service shall be that,
for the conditional case, the CO device shall be required to verify the freshness of the
connection information it previously sent to the LSS. If the data is not fresh, the CO device
shall not use the Scheduling data for that connection index. In the forced case, the CO device
need not check. “Fresh” connection information shall mean that nothing has changed the
connection information since it was sent to the LSS via a read command.
The request shall be an array of connection schedules.

class Scheduling_Write_Request : public MR_Request
{
UINT number_of_connection_schedules;
struct {
UDINT connection_index;
USINT O2T_schedule;
USINT T2O_schedule;
} schedules[];
};
--`,,```,,,,````-`-`

61158-4-2 © IEC:2007(E) – 105 –
The response status of this service shall be as specified in Table 41.
Table 41 – Status error descriptions for Conditional_Write
General Extended
Error description
status status
0x00 N/A Success

0x03 N/A Invalid value — bad index contained in request
0x0C N/A Wrong state (change start not received)
0x10 N/A Device state conflict (device cannot break connection)
0x15 N/A Instance is unable to receive any more write requests
7.4.5.5 Forced_Write
Forced_Write service shall be similar to the conditional write service except that the LSS shall
guarantee that it has provided valid connection information. The request parameters shall be
the same as for the Conditional_Write service. The response status of this service shall be as
specified in Table 42.
Table 42 – Status error descriptions for Forced_Write
General Extended
Error description
status status
0x00 N/A Success

0x0C N/A Wrong state (change start not received)
0x10 N/A Device state conflict (device cannot break connection)
0x15 N/A Instance is unable to receive any more write requests
7.4.5.6 Change_Start
The Change_Start service shall be used to initiate a Scheduling data change in the controller.
The controller shall allocate enough memory for the new data and for the CO password and
path. The conditional write or forced write service shall be then used to write the data to
the controller.
The CO password shall be used when a controller first is powered up and begins to remake
scheduled connections. The CO shall ensure the path associated with the CO password (see
Create response or Change_Complete request) matches the path from the network to the CO
device. If the path matches the CO shall ensure this CO password matches the one stored in
the Keeper object of the link prior to making any scheduled connections on that link.
The Change_Start request shall have only one parameter. The parameter shall be a UINT in
the range 0 to 255 that specifies the size of the CO password and path to be provided in the
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 106 – 61158-4-2 © IEC:2007(E)
Change_Complete service. Implementations may use this to allocate a receive buffer for the
CO password and path.
Table 43 – Status error descriptions for Change_Start
General Extended
Error description
status status
0x00 N/A Success

0x02 0x0002 Insufficient resource — not enough memory on CO device
0x10 N/A Device state conflict (for example, device cannot allocate
sufficient memory)
7.4.5.7 Break_Connections
Break_Connections service shall be used after the new Scheduling data has been written to
--`,,```,,,,````-`-`,,`,,`,`,,`---
the controller to break all the affected connections. The service shall reply only after all the
connections have been broken. If any connections are in the process of being connected, they
shall also be closed before replying to this service.
The Scheduling object break connections service shall break all connections that were
specified in the Scheduling data write services. An LSS may always write Scheduling data for
all connections (causing all connections over the link to be broken) but another LSS may be
optimized to minimize the number of connections that get broken.
When the Scheduling object break connections service is received, in addition to breaking the
changed connections, the CO shall NULL out (zero out) the currently active scheduled data
values for the connections it breaks to prevent connections from being re-established until the
Scheduling data change complete service is received. If the change complete service is never
received (due to loss of communications with LSS) these connections shall not be able to be
opened until they are rescheduled. The response of this service shall be as specified in
Table 44.
Table 44 – Status error descriptions for Break_Connections
General Extended
Error description
status status
0x00 N/A Success

0x0C N/A Object state conflict
0x10 N/A Device state conflict (device cannot break connections)

61158-4-2 © IEC:2007(E) – 107 –
7.4.5.8 Change_Complete
Change_Complete service shall be used to indicate that all scheduled connections have been
broken and it is permitted to start making the new scheduled connections. The request
contains the new CO password and path to be used for the link that has been scheduled. The
CO shall ensure the path associated with the CO password (see Create response or
Change_Complete request) matches the path from the network to the CO device. If the path
matches the CO shall ensure this CO password matches the one stored in the Keeper object
of the link prior to making any scheduled connections on that link.
class Scheduling_Change_Complete_Request : public MR_Request
{
UDINT cop; // Connection Originator Password (COP)
UINT path[]; // array of port segments from the scheduled link
// to the connection originator
// no key segments, no network segments
// include the MAC ID of the link hop
};
NOTE The reverse path included in this request allows the LSS to detect changes in the network position of the
scheduled CO during later scheduling sessions.
Table 45 – Status error descriptions for Change_Complete
General Extended
Error description
status status
0x00 N/A Success

0x03 N/A Invalid value (new CO password and path is not formatted
correctly)
0x10 N/A Device state conflict
0x0C N/A Wrong state
7.4.5.9 Restart_Connections
The Restart_Connections service may only be sent to the class instance of the Scheduling
object (instance zero). It shall be used to break all connections which use a specific link. After
all the connections have been broken, the CO device shall attempt to re-establish them. The
request parameter for this service shall be structured as is instance attribute 0x01. The
response status of this service shall be as specified in Table 46.
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 108 – 61158-4-2 © IEC:2007(E)
Table 46 – Status error descriptions for Restart_Connections
General Extended
Error description
status status
0x00 N/A Success

0x08 N/A Unimplemented service (if addressed to a non-zero instance)
0x10 N/A Device state conflict (cannot break connections)
0xDO N/A No scheduled connections on this link
7.4.6 Typical scheduling session
A typical scheduling session shall use these services:
a) create;
b) read;
c) write;
d) change_start;
e) break_connections;
f) conditional_write;
g) forced_write;
h) change_complete.
The following steps describe the usage of services in a typical Scheduling session:
1) The LSS shall begin by sending a create message to instance zero of the Scheduling
object. Contained in this message shall be a path from the CO to the link. This path shall
determine which connections are of interest to the LSS.
2) The Scheduling object shall create an instance of itself to service this LSS and reply with
the instance number to which all future communications in this session shall be sent.
3) The newly created instance shall reset a 60 s timer upon receipt of any message. If this
timer ever expires, the instance shall delete itself aborting any change in progress. In
normal operation, the LSS shall be required to send a command to the Scheduling object
at least once every 15 s allowing a few dropped messages without unnecessarily deleting
an instance.
4) The LSS may optionally send read commands to the newly created instance to transfer
--`,,```,,,,````-`-`,,`,,`,`,,`---
the connection information from the CO device. The transmitted connection information
shall contain indexes which are used to uniquely identify the connections internally within
the CO device.
5) The LSS shall reflect back these indexes on subsequent write commands so that the CO
may determine for which connections the write applies. The issuing of read commands
shall be optional since the connection information can be obtained for the LSS by other
means. For example, in an integrated LSS/PS, the PS shall provide this information to the
LSS.
6) Once the connection information is acquired from each CO desiring scheduled data on the
link, the LSS shall calculate a tentative schedule.
7) The LSS then shall issue the following sequence of commands to each of the CO devices:
change start, one or more writes, and break connections. This sequence can be done
in parallel to each of the CO devices. The type of write command (forced or conditional)
shall depend on how the connection information was obtained. If the LSS has
independently ensured that the connection information is valid, it may use the forced
write command; otherwise, it shall use a conditional write command. The LSS can know

61158-4-2 © IEC:2007(E) – 109 –
that the connection information is valid by obtaining the edit resource for the CO before
the connection information.
8) Upon receipt of a conditional write command, the Scheduling object shall check that the
parameters of the connection have not changed since they were last read. If the
connection has been changed, the Scheduling object shall not use the Scheduling
information for the index whose connection parameters have changed. The Scheduling
object within the CO can do this through any means it chooses.
9) The Scheduling object shall be absolved of responsibility to check the validity of forced
writes. This responsibility shall be assumed by the LSS.
10) Once the break connection commands to each of the CO devices has completed
successfully, the LSS shall issue a change complete to each of the CO devices indicating
that the schedule transmitted earlier via writes is now valid. The change complete
command shall include the new CO password and path.
11) The session shall end by deleting the instance of the Scheduling object.
7.5 TCP/IP Interface object
7.5.1 Overview
The TCP/IP Interface object provides the mechanism to configure the TCP/IP interface of a
device.
NOTE 1 Examples of configurable items include the device’s IP Address, Network Mask, and Gateway Address.
The physical port associated with the TCP/IP Interface object shall be any port supporting the
TCP/IP protocol.
NOTE 2 For example, a TCP/IP Interface object may be associated any of the following : an Ethernet
ISO/IEC 8802-3 port, an ATM port, a serial port running SLIP, a serial port running PPP.
The TCP/IP Interface object provides an attribute that identifies the link-specific object for the
associated physical port. The link-specific object is generally expected to provide link-specific
counters as well as any link-specific configuration attributes.
Each device shall support exactly one instance of the TCP/IP Interface object for each
TCP/IP-capable port on the device. A request to access instance 1 of the TCP/IP Interface
object shall always refer to the instance associated with the port over which the request was
received.
The TCP/IP Interface object shall support the class attributes as specified in Table 47.
Table 47 – TCP/IP Interface object class attributes

0x01 Optional Get Revision UINT revision of this object first revision, value = 1
7.5.3.1 General
The TCP/IP Interface object shall support the instance attributes as specified in Table 48.
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 110 – 61158-4-2 © IEC:2007(E)
Table 48 – TCP/IP Interface object instance attributes
Attribute Need in Access Description of Semantics of

Name Data type
ID implementation rule attribute values
0x01 Required Get Status DWORD Interface status See 7.5.3.2

0x02 Required Get Configuration DWORD Interface capability Bit map of capability
capability flags flags. See 7.5.3.3
0x03 Required Get/Set Configuration DWORD Interface control Bit map of control
control flags flags. See 7.5.3.4
0x04 Required Get Physical link STRUCT Path to physical See 7.5.3.5
object of variable link object
size
Path size UINT Size of path Number of UINTs in
Path
Path ARRAY of Logical segments Class Segment and
UINT identifying the Instance Segment.
physical link object Maximum length is 6
UINTs (if 32 bit
logical segments are
used)
0x05 Required Get/Set Interface STRUCT TCP/IP network See 7.5.3.6
configuration of variable interface
size configuration
IP address UDINT Device’s IP Value of 0 indicates
address. no IP address has
been configured.
Otherwise, the IP
address shall be set
to a valid class A, B,
or C address and
shall not be set to
the loopback
address (127.0.0.1)
Network mask UDINT Device’s network Value of 0 indicates
mask no network mask
address has been
configured
Gateway UDINT gateway address Value of 0 indicates
address no IP address has
been configured.
Otherwise, the IP
address shall be set
to a valid class A, B,
or C address and
shall not be set to
the loopback
address (127.0.0.1)
Name server UDINT Primary name Value of 0 indicates
server no name server
address has been
configured. Other-
wise, the name
server address shall
be set to a valid
class A, B, or C
address
Name server 2 UDINT Secondary name Value of 0 indicates
server no secondary name
server address has
been configured.
Otherwise, the name
server address shall
be set to a valid
class A, B, or C
address
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 111 –

Name Data type
Domain name STRING Default domain ASCII characters.
name Maximum length is
48 characters. Shall
be padded to an
even number of
characters (pad not
included in length).
A length of 0 shall
indicate no Domain
Name is configured
0x06 Required Get Host name STRING Host name ASCII characters.
Maximum length is
Set is 64 characters. Shall
optional be padded to an
(see even number of
7.5.3.7) characters (pad not
included in length). A
length of 0 shall
indicate no Host
Name is configured.
See 7.5.3.7
0x07 Conditional a Safety network OCTET[6] See IEC 61784-3-2
number
0x08 Conditional b Get TTL value USINT TTL value for Time-to-live value for
CP 2/2 multicast IP multicast packets.
Set is packets Default value is 1,
condi- minimum is 1,
tional c maximum is 255. See
7.5.3.8
0x09 Conditional b Get Mcast config STRUCT IP multicast See 7.5.3.9
of 8 octets address
Set is configuration
condi-
tional c
Alloc control USINT Multicast address Determines whether
allocation control multicast addresses
word. Determines are generated via
how addresses are algorithm or are
allocated explicitly set. See
7.5.3.9 for details
Reserved USINT Reserved for Shall be 0
future use
Num mcast UINT Number of IP The number of IP
multicast multicast addresses
addresses to allocated, starting at
allocate for CP 2/2 “Mcast start addr”.
Maximum value is
device specific,
however shall not
exceed the number
--`,,```,,,,````-`-`,,`,,`,`,,`---
of CP 2/2 multicast
connections
supported by the
device
Mcast start addr UDINT Starting multicast IP multicast address
address from (Class D). A block of
which to begin “Num mcast”
allocation addresses is
allocated starting
with this address
a This attribute is required for CPF 2 safety devices. Non-safety devices shall not implement this attribute.
b If either “TTL value” or “Mcast config” is implemented, both shall be implemented.
c If either “TTL value” or “Mcast config” is implemented as settable, both shall be implemented as settable.

– 112 – 61158-4-2 © IEC:2007(E)
7.5.3.2 Status
The status attribute is a bitmap that indicates the status of the TCP/IP network interface, as
specified in Table 49. Refer to the state diagram in Figure 21 for a description of object states
as they relate to the status attribute.
Table 49 – Status bits
Bit(s) Name Definition
0-3 Interface configuration status Indicates the status of the interface configuration attribute.
0 = The interface configuration attribute has not been configured
1 = The interface configuration attribute contains valid configuration
obtained from BOOTP, DHCP or non-volatile storage
2 = The interface configuration attribute contains valid configuration,
obtained from hardware settings (e.g. pushwheel, thumbwheel,…)
3-15 = Reserved for future use
4 Mcast pending Indicates a pending configuration change in the TTL value and/or
Mcast config attributes. This bit shall be set when either the TTL value
or Mcast config attribute is set, and shall be cleared the next time the
device starts
5-31 Reserved Reserved for future use and shall be set to zero
7.5.3.3 Configuration capability
The configuration capability attribute is a bitmap that indicates the device’s support for
optional network configuration capability. Possible configuration capability items are listed in
Table 50. Devices are not required to support any one particular item, however they shall
support at least one method of obtaining an initial IP address.
Table 50 – Configuration capability bits
Bit Name Definition
0 BOOTP client 1 (TRUE) shall indicate the device is capable of obtaining

its network configuration via BOOTP
1 DNS client 1 (TRUE) shall indicate the device is capable of resolving
host names by querying a DNS server
2 DHCP client 1 (TRUE) shall indicate the device is capable of obtaining
its network configuration via DHCP
3 DHCP-DNS update 1 (TRUE) shall indicate the device is capable of sending
its host name in the DHCP request as documented in
Internet draft <draft-ietf-dhc-fqdn-option-12.txt>
4 Configuration settable 1 (TRUE) shall indicate the interface configuration
attribute is settable. Some devices, for example a PC or
workstation, may not allow the interface configuration to
be set via the TCP/IP Interface object
5-31 Reserved Reserved for future use and shall be set to zero
7.5.3.4 Configuration control
The configuration control attribute is a bitmap used to control network configuration options,
as specified in Table 51.
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 113 –
Table 51 – Configuration control bits
Bit Name Definition

0–3 Startup Configuration Determines how the device 0 = The device shall use the
shall obtain its initial network configuration previously
configuration at start up stored (for example, in non-volatile
memory or via hardware switches,
etc)
1 = The device shall obtain its
network configuration via BOOTP.
2 = The device shall obtain its
network configuration via DHCP
upon start-up
3-15 = Reserved for future use
4 DNS Enable If 1 (TRUE), the device shall resolve host names by querying a
DNS server
5–31 Reserved Reserved for future use and shall be set to zero
Devices are not required to support any of the particular values of the Startup Configuration
bits, however a device shall support at least one method of obtaining an initial TCP/IP
interface configuration. For example, some low-end devices may choose to obtain network
interface configuration via BOOTP or DHCP only. Other devices may wish to only allow initial
configuration over a serial (or other) port, then store the configuration in non-volatile memory.
The use of BOOTP and/or DHCP may not be appropriate for some devices. DHCP in
particular supports dynamically allocated IP addresses, which could result in a device getting
a different IP address each time it powers up. This behavior is not appropriate for devices that
need to have static IP addresses.
Out of the box, a device may wish to obtain its initial configuration via some method other
than BOOTP or DHCP. For example, the device may wish to obtain its initial configuration
over an attached serial port, or via another communications port compatible with the
corresponding Type 2 Application Layer protocol (assuming the device has another
communications port). In this case, the device shall have its startup configuration bits set to 0,
and its interface configuration attribute fields to all 0s. The device shall then wait to be
configured over another communications port.
Once a device is up and running, when the value of the startup configuration bits is 0, a request to
set the interface configuration attribute shall cause the device to store the contents of the
Iinterface configuration attribute in non-volatile storage if supported by the device. The startup
configuration bits shall not be set to 0 unless the interface configuration attribute has previously
been set. Otherwise the device could be rendered unable to communicate on the network.
7.5.3.5 Physical link object
This attribute identifies the object associated with the underlying physical port. There are two
components to the attribute : a path size (in UINTs) and a path. The path shall contain a class
segment and an instance segment that identify the physical port object. The maximum path
size is 6 (assuming a 32 bit logical segment for each of the class and instance). An example
path is shown in Table 52.
Table 52 – Example path

--`,,```,,,,````-`-`,,`,,`,`,,`---
Path Meaning
[20][f6][24][01] [20] = 8 bit class segment type;

[f6] = Ethernet Link object class;
[24] = 8 bit instance segment type;
[01] = instance 1

– 114 – 61158-4-2 © IEC:2007(E)
The physical link object itself typically maintains link-specific counters as well as any link-
specific configuration attributes. The most likely physical link object is the Ethernet Link object
(see 7.6).
7.5.3.6 Interface configuration
This attribute contains the configuration parameters required to operate as a TCP/IP node. In
order to prevent incomplete or incompatible configuration, the parameters making up the
interface configuration attribute cannot be set individually. To modify the Interface
configuration attribute, the user should first get the interface configuration attribute, change
the desired parameters, then set the attribute.
The TCP/IP Interface object shall apply the new configuration upon completion of the Set
service. If the value of the startup configuration bits (configuration control attribute) is 0, the
new configuration shall be stored in non-volatile memory. The device shall not reply to the set
service until the values are safely stored to non-volatile storage.
If initial configuration is to be obtained via BOOTP or DHCP, the interface configuration

attribute components shall be all zeros until the BOOTP or DHCP reply is received. Upon
receipt of the BOOTP or DHCP reply, the interface configuration attribute shall show the
configuration obtained via BOOTP/DHCP.
Devices are not required to support the Set service. Some implementations, for example
those running on a PC or a Workstation, need not support setting the network interface
configuration via the TCP/IP Interface object.
Components of the interface configuration attributes are described in Table 53.
Table 53 – Interface configuration components
Name Meaning
IP address The device’s IP address

Network mask The device’s network mask. The network mask is used when the IP
network has been partitioned into subnets. The network mask is used to
determine whether an IP address is located on another subnet
Gateway address The IP address of the device’s default gateway. When a destination IP
address is on a different subnet, packets are forwarded to the default
gateway for routing to the destination subnet
Name server The IP address of the primary name server. The name server is used to
resolve host names. For example, that might be contained in a
fieldbusconnection path
Name server 2 The IP address of the secondary name server. The secondary name
server is used when the primary name server is not available, or is
unable to resolve a host name
Domain name The default domain name. The default domain name is used when
resolving host names that are not fully qualified. For example, if the
default domain name is “network.org”, and the device needs to resolve
a host name of “plc”, then the device will attempt to resolve the host
name as “plc.network.org”
7.5.3.7 Host name
The Host Name attribute contains the device’s host name. The host name attribute is used
when the device supports the DHCP-DNS Update capability and has been configured to use
DHCP upon start up. The mechanism allows the DHCP client to transmit its host name to the
DHCP server. The DHCP server then updates the DNS records on behalf of the client.
--`,,```,,,,````-`-`,,`,,`,`,,`---
NOTE The DHCP-DNS Update mechanism is specified in Internet draft <draft-ietf-dhc-fqdn-option-12.txt>.

61158-4-2 © IEC:2007(E) – 115 –
The host name attribute does not need to be set for the device to operate normally. The value
of the Host Name attribute, if it is configured, shall be used for the value of the FQDN option
in the DHCP request. If the Host Name attribute has not been configured then the device shall
not include the FQDN option in the DHCP request.
For devices that do not support the DHCP-DNS capability, or are not configured to use DHCP,
then the host name may be used for informational purposes.
The set access is optional when the interface configuration attribute is not settable. Some
devices (e.g. a PC or workstation), may not allow the interface configuration or host name
attributes to be set via the TCP/IP Interface object. If the set is not implemented, an “Attribute
not settable” (0x0E) error shall be returned in response to a “Set_Attribute_Single” request.
7.5.3.8 TTL value
TTL value is the value the device shall use for the IP header Time-to-live field when sending
CP 2/2 packets via IP multicast. By default, TTL Value shall be 1. The maximum value for TTL
is 255. Unicast packets shall use the TTL as configured for the TCP/IP stack, and not the TTL
value configured in this attribute.
When set, the TTL Value attribute shall be saved in non-volatile memory, and shall take affect
the next time the device starts. Setting the TTL value attribute shall also cause the Mcast
pending bit in the Interface status attribute to be set, indicating that there is pending
configuration. When a new TTL value is pending, Get_Attribute_Single or Get_Attribute_All
requests shall return the pending value. The Mcast pending bit shall be cleared the next time
the device starts.
NOTE Users should exercise caution when setting the TTL value greater than 1, to prevent unwanted multicast
traffic from propagating through the network. IEC 61158-6-2 includes a discussion on user considerations when
using multicast.
7.5.3.9 Mcast config
The Mcast config attribute contains the configuration of the device’s IP multicast addresses to
be used for CP 2/2 multicast packets. There are three elements to the Mcast config structure:
Alloc control, Num mcast, and Mcast start addr.
• Alloc control determines how the device shall allocate IP multicast addresses (e.g.,
--`,,```,,,,````-`-`,,`,,`,`,,`---
whether by algorithm, whether they are explicitly set,…). Table 54 shows the details for
alloc control.
Table 54 – Alloc control values
Value Definition
0 Multicast addresses shall be generated using the default allocation algorithm specified
in IEC 61158-6-2. When this value is specified on a Set_Attribute_Single or
Set_Attribute_All, the values of Num mcast and Mcast start addr in the Set_Attribute
request shall be 0
1 Multicast addresses shall be allocated according to the values specified in Num mcast
and Mcast start addr
2 Reserved
• Num mcast is the number of IP multicast addresses allocated. The maximum number of
multicast addresses is device specific, but shall not exceed the number of CP 2/2
multicast connections supported by the device.
• Mcast start addr is the starting multicast address from which Num mcast addresses are
allocated.
When set, the Mcast config attribute shall be saved in non-volatile memory, and shall take
affect the next time the device starts. Setting the Mcast config attribute shall also cause the

– 116 – 61158-4-2 © IEC:2007(E)
Mcast pending bit in the Interface status attribute to be set, indicating that there is pending
configuration. When a new Mcast Config value is pending, Get_Attribute_Single or
Get_Attribute_All requests shall return the pending value. The Mcast pending bit shall be
cleared the next time the device starts.
When the multicast addresses are generated using the default algorithm, Num mcast and
Mcast start addr shall report the values generated by the algorithm.
7.5.4.1 General
The TCP/IP Interface object shall support the common services as specified in Table 55.
Table 55 – TCP/IP Interface object common services
Need in
code
Class Instance
0x01 Optional Optional Get_Attribute_All Returns a predefined listing of this objects

attributes (see the Get_Attribute_All response
definition in 7.5.4.2)
0x02 N/A Optional Set_Attribute_All Modifies all settable attributes
0x0E Conditio Required Get_Attribute_Single Returns the contents of the specified attribute
nal a
0x10 N/A Required Set_Attribute_Single Modifies a single attribute
a The Get_Attribute_Single service shall be implemented for Class if any class attributes are implemented.
For class attributes, since there is only one class attribute, class attribute #1 shall be
returned.
For instance attributes, attributes shall be returned in numerical order up to the last
implemented attribute. The Get_Attribute_All reply shall be as specified in Table 56.
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 117 –
Table 56 – Get_Attribute_All reply format
Attribute ID Size (octets) Contents
1 4 Status
2 4 Configuration capability
3 4 Configuration control
4 2 Physical link object, path size
Variable, 12 octets max Physical link object, path (if path size is non-zero)
5 4 IP address
4 Network mask
4 Gateway address
4 Name server
4 Secondary name server
2 Domain name length
Variable, equal to domain name length Domain name
1 Pad octet only if Domain Name Length is odd
6 2 Host name length
variable, equal to host name length Host name
1 Pad octet only if Host Name Length is odd
7 6 See IEC 61784-3-2.
Not present if attribute 7 is not implemented. Shall
be 0 when additional attributes greater than
attribute ID 7 are included
8 1 TTL value.
9 8 Mcast config.
The lengths of the physical link object path, domain name, and host name are not known
before issuing the Get_Attribute_All service request. Implementers shall be prepared to
accept a response containing the maximum sizes of the physical link object path (6 UINTs),
the domain name (48 USINTs), and host name (64 USINTs).
7.5.4.3 Set_Attribute_All request
The instance Set_Attribute_All request shall contain the configuration control attribute,
followed by the interface configuration attribute.
7.5.5 Behavior
The behavior of the TCP/IP Interface object shall be as illustrated in the State Transition
Diagram shown in Figure 21.
Note that the act of obtaining an initial executable image via BOOTP/TFTP shall not be
considered within the scope of the TCP/IP Interface object behavior. Devices are free to
implement such behavior, however it shall be considered to have occurred in the “Non-
existent” state.
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 118 – 61158-4-2 © IEC:2007(E)
Non-existent
Powerup/Reset
Status attribute set to 0

Obtaining Initial
Configuration BOOTP/DHCP
Disabled AND Stored
Config is Valid
BOOTP/DHCP Disabled BOOTP OR
AND Stored Config Invalid DHCP Enabled
Waiting for
Configuration
Set_Attributes BOOTP/DHCP
Request Received Response Received
Applying
Configuration
Configuration
Applied
Set_Attributes
Request Received
TCP/IP Network Status attribute set to 1
Interface Configured
Figure 21 – State transition diagram for TCP/IP Interface object
7.6 Ethernet link object
7.6.1 Overview
The Ethernet Link object maintains link-specific counters and status information for a physical
Ethernet ISO/IEC 8802-3 port. Each device shall support exactly one instance of the Ethernet
Link object for each Ethernet port on the module. A request to access instance 1 of the
Ethernet Link object shall always refer to the instance associated with the port over which the
request was received.
The revision history of the Ethernet Link object is described in Table 57.
Table 57 – Ethernet link object revision history
Class
revision
01 Initial Release
02 Release for IEC 61158.
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 119 –
The Ethernet Link object shall support the class attributes as specified in Table 58.
Table 58 – Ethernet link object class attributes

0x01 Required Get revision UINT revision of this object current value for this
attribute = 2
0x02 to These class attributes are optional and are described in IEC 61158-5-2
0x07
An error reading the class revision attribute implies this is a revision 1 only implementation.
7.6.4.1 General
The Ethernet Link object shall support the instance attributes as specified in Table 59.
Table 59 – Ethernet link object instance attributes

Name Data type
0x01 Required Get Interface speed UDINT Interface speed Speed in Mbit/s
currently in use (e.g. 0, 10, 100,
1 000). See 7.6.4.2
0x02 Required Get Interface flags DWORD Interface status Bit map of interface
flags flags. See 7.6.4.3
0x03 Required Get Physical USINT[6] MAC layer address See 7.6.4.4
address
0x04 Conditional a Get Interface STRUCT See 7.6.4.5
counters of 44
octets
In Octets UDINT Octets received on
the interface
In Ucast UDINT Unicast packets
Packets received on the
interface
In NUcast UDINT Non-unicast
Packets packets received
on the interface
In Discards UDINT Inbound packets
received on the
interface but
discarded
In Errors UDINT Inbound packets
that contain errors
(does not include In
Discards)
In Unknown UDINT Inbound packets
Protos with unknown
protocol
Out Octets UDINT Octets sent on the
interface
Out Ucast UDINT Unicast packets
Packets sent on the
interface
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 120 – 61158-4-2 © IEC:2007(E)

Name Data type
Out NUcast UDINT Non-unicast packets
Packets sent on the interface
Out Discards UDINT Outbound packets
discarded
Out Errors UDINT Outbound packets
that contain errors
0x05 Optional Get Media counters STRUCT of Media-specific See 7.6.4.6
48 octets counters
Alignment UDINT frames received
errors that are not an
integral number of
octets in length
FCS errors UDINT DLPDUs received
that do not pass
the FCS check
Single collisions UDINT Successfully trans-
mitted DLPDUs which
experienced exactly
one collision
Multiple UDINT Successfully trans-
collisions mitted DLPDUs
which experienced
more than one
collision
SQE test errors UDINT Number of times SQE
test error message is
generated
Deferred UDINT DLPDUs for which
transmissions first transmission
attempt is delayed
because the
medium is busy
Late collisions UDINT Number of times a
collision is detected
later than 512 bit-
times into the
transmission of a
packet
Excessive UDINT DLPDUs for which
collisions transmission fails
due to excessive
collisions
MAC transmit UDINT DLPDUs for which
errors transmission fails
due to an internal
MAC sublayer
transmit error
Carrier sense UDINT Times that the
errors carrier sense
condition was lost
or never asserted
when attempting to
transmit a frame
Frame too long UDINT DLPDUs received
that exceed the
maximum permitted
DLPDU size
MAC receive UDINT DLPDUs for which
errors reception on an
interface fails due
to an internal MAC
sublayer receive
error
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 121 –

Name Data type
0x06 Optional Get/Set Interface control STRUCT Configuration for See 7.6.4.7
of 4 octets physical interface
Control bits WORD Interface control
bits
Forced interface UINT Speed at which the Speed in Mbit/s
speed interface shall be (e.g. 10, 100, 1 000)
forced to operate
a The interface counters attribute is required if the media counters attribute is implemented.
7.6.4.2 Interface speed
The interface speed attribute shall indicate the speed at which the interface is currently
running (e.g. 10 Mbit/s, 100 Mbit/s, 1 Gbit/s, or other speeds). A value of 0 shall be used to
indicate that the speed of the interface is indeterminate.
The scale of the attribute is in Mbit/s, so if the interface is running at 100 Mbit/s then the value
of the interface speed attribute shall be 100. The interface speed is intended to represent the
available link transmit time; the attribute shall not be doubled if the interface is running in full-
duplex mode.
7.6.4.3 Interface flags
The interface flags attribute contains status and configuration information about the physical
interface as specified in Table 60.
Table 60 – Interface flags bits
Bit Name Definition
0 Link status Indicates whether or not the port is connected to an active

network :
- 0 indicates an inactive link
- 1 indicates an active link
The determination of link status is implementation specific.
In some cases devices can tell whether the link is active
via hardware/driver support. In other cases, the device
may only be able to tell whether the link is active by the
presence of incoming packets
1 Half/Full duplex Indicates the duplex mode currently in use:
- 0 indicates the port is running half duplex
- 1 indicates full duplex
If the Link status flag is 0, then the value of the Half/Full
duplex flag is indeterminate.
2-4 Negotiation status Indicates the status of link auto-negotiation:
0 = Auto-negotiation in progress
1 = Auto-negotiation and speed detection failed. Using
default values for speed and duplex. Default values are
product-dependent; recommended defaults are 10Mbit/s
and half duplex
2 = Auto negotiation failed but detected speed. Duplex
--`,,```,,,,````-`-`,,`,,`,`,,`---
was defaulted. Default value is product-dependent;

recommended default is half duplex
3 = Successfully negotiated speed and duplex
4 = Auto-negotiation not attempted. Forced speed and
duplex
5 Manual setting 0 indicates the interface can activate changes to link
requires reset parameters (auto-negotiate, duplex mode, interface
speed) automatically
1 indicates the device requires a Reset service be issued
to its Identity object in order for the changes to take effect

– 122 – 61158-4-2 © IEC:2007(E)
Bit Name Definition
6 Local hardware fault 0 indicates the interface detects no local hardware fault
1 indicates a local hardware fault is detected
The meaning of this is product-specific. Examples are an
AUI/MII interface detects no transceiver attached or a
radio modem detects no antennae attached. In contrast to
the soft, possible self-correcting nature of the Link Status
being inactive, this is assumed a hard-fault requiring user
intervention
7-31 Reserved Reserved and shall be set to zero
7.6.4.4 Physical address
The physical address attribute contains the interface’s MAC layer address. The physical
address is an array of octets. The recommended display format is "XX-XX-XX-XX-XX-XX",
starting with the first octet. The physical address is not a settable attribute : the Ethernet
address shall be assigned by the manufacturer, and shall be unique per ISO/IEC 8802-3
requirements.
7.6.4.5 Interface counters
The interface counters attribute contains counters relevant to the receipt of packets on the
interface. These counters shall be as defined in RFC 1213 “MIB-II Management Information
Base”. The interface counters is a conditional attribute; it shall be implemented if the media
counters attribute is implemented.
7.6.4.6 Media counters
The media counters attribute contains counters specific to Ethernet media. These counters
shall be as defined by RFC 1643, “Definitions of Managed Objects for Ethernet-Like Interface
Types”. If this attribute is implemented the interface counters attribute shall also be
implemented.
7.6.4.7 Interface control
7.6.4.7.1 Overview
The interface control attribute is a structure consisting of control bits and forced interface
speed and shall be as specified in the following subclauses.
7.6.4.7.2 Control bits
The control bits attribute is specified in Table 61.

--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 123 –
Table 61 – Control bits
Bit Name Definition
0 Auto-negotiate 0 indicates ISO/IEC 8802-3 link auto-negotiation is disabled

1 indicates auto-negotiation is enabled
If auto-negotiation is disabled, then the device shall use the
settings indicated by the forced duplex mode and forced
interface speed bits
1 Forced duplex mode If the Auto-negotiate bit is 0, the forced duplex mode bit
indicates whether the interface shall operate in full or half
duplex mode.
0 indicates the interface duplex should be half duplex
1 indicates the interface duplex should be full duplex
Interfaces not supporting the requested duplex shall return an
error code 0x09 (Invalid Attribute Value). If auto-negotiation is
enabled, attempting to set the forced duplex mode bits shall
result in an error code 0x0C (Object State Conflict)
2-15 Reserved Shall be set to zero
7.6.4.7.3 Forced interface speed
If the auto-negotiate bit is 0, the forced interface speed bits indicate the speed at which the
interface shall operate. Speed is specified in Mbit/s (e.g. for 10 Mbit/s Ethernet, the interface
speed shall be 10). Interfaces not supporting the requested speed should return an error code
0x09 (Invalid Attribute Value).
If auto-negotiation is enabled, attempting to set the Forced Interface Speed shall result in an
--`,,```,,,,````-`-`,,`,,`,`,,`---
error code 0x0C (Object State Conflict).
7.6.5.1 General
The Ethernet Link object shall support the common services as specified in Table 62.
Table 62 – Ethernet Link object common services
Need in
code
Class Instance
0x01 Optional Optional Get_Attribute_All Returns a predefined listing of this objects

attributes (see the Get_Attribute_All response
definition in 7.6.5.2)
0x0E Conditional Required Get_Attribute_Single Returns the contents of the specified attribute
0x10 N/A Conditional Set_Attribute_Single Modifies a single attribute
The Get_Attribute_Single shall be implemented for the class attribute if the class attribute is
implemented.
The Set_Attribute_Single service shall be implemented if the interface control attribute is

implemented.
For class attributes, since there is only one possible attribute, the Get_Attribute_All response
is the same as the Get_Attribute_Single response. If no class attributes are implemented,
then no data is returned in the data portion of the reply.

– 124 – 61158-4-2 © IEC:2007(E)
For instance attributes, attributes shall be returned in numerical order, up to the last
implemented attribute. All zeros shall be returned for the interface counters and media
counters attributes if they are not implemented but the interface control attribute is
implemented.
7.6.6.1 General
The Ethernet Link object shall support the class specific services as specified in Table 63.
Table 63 – Ethernet Link object class specific services
Need in
code
Class Instance
--`,,```,,,,````-`-`,,`,,`,`,,`---
0x4C N/A Conditional Get_and_Clear Gets then clears the specified attribute (interface
counters or media counters)
The Get_and_Clear service shall only be implemented if the interface counters and media
counters attributes are implemented.
7.6.6.2 Get_and_Clear service
The Get_and_Clear service is a class specific service. It is only supported for the interface
counters and media counters attributes. The Get_and_Clear response shall be the same as
the Get_Attribute_Single response for the specified attribute. After the response is built, the
value of the attribute shall be set to zero.
7.7 DeviceNet object
7.7.1 Overview
The DeviceNet object shall provide a consistent Station Management interface to the Physical
and Data Link Layers. This object shall make diagnostic information from these layers
available to client applications. Each node shall support one DeviceNet object per link.
The revision history of the DeviceNet object is described in Table 64.
Table 64 – DeviceNet object revision history
Class
revision
01 Initial Release
02 Release for IEC 61158 series
The DeviceNet object shall support the class attributes as specified in Table 65.

61158-4-2 © IEC:2007(E) – 125 –
Table 65 – DeviceNet object class attributes

0x01 Required Get Revision UINT revision of this object 2 (revision 2)
7.7.4.1 General
The DeviceNet object shall support the instance attributes as specified in Table 66.
Table 66 – DeviceNet object instance attributes

Name Data type
0x01 Optional Get/Set MAC ID USINT node address see 7.7.4.2

0x02 Optional Get/Set Bit Rate USINT bit rate see 7.7.4.3
0x03 Optional Get/Set BOI BOOL bus-off interrupt see 7.7.4.4
0x04 Optional Get/Set Bus-Off Counter USINT number of times CAN see 7.7.4.5
went to the bus-off
state
0x05 Optional Get Allocation STRUCT see 7.7.4.6
Information of 2 octets
Allocation choice SWORD see 7.7.4.6.2
Master’s MAC ID USINT MAC ID of master see 7.7.4.6.3
(from allocate)
0x06 Conditional a Get MAC ID switch BOOL The node address 0 = no
changed switch(es) have Change
changed since last
power–up/reset 1 = change
since last
reset or
power–up
0x07 Conditional b Get Bit rate switch BOOL The bit rate 0 = no
changed switch(es) have Change
changed since last
power–up/reset 1 = change
since last
reset or
power–up
0x08 Conditional a Get MAC ID switch value USINT Actual value of node 0 to 99
address switch(es)
0x09 Conditional b Get Bit rate switch value USINT Actual value of bit 0 to 9
rate switch(es)
0x0A Optional c Get/Set Quick Connect BOOL Enable/Disable of 0 = disable
Quick Connect (default)
feature
1 = enable
0x0B Conditional d Safety Network SWORD[6] See
Number IEC 61784-3-
2
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 126 – 61158-4-2 © IEC:2007(E)

Name Data type
0x0C Optional Get Diagnostic counters STRUCT List of ISO 11898 See 7.7.4.7
of 34 diagnostic counters
octets
Diagnostic counters WORD Indicates which
descriptor diagnostic counters
are supported
Arbitration loss count UINT See ISO 11898 Range =
0 – 65 535
Overload count UINT See ISO 11898
Default = 0
Bit error count UINT See ISO 11898
Stuff error count UINT See ISO 11898
Ack error count UINT See ISO 11898
Form error count UINT See ISO 11898
--`,,```,,,,````-`-`,,`,,`,`,,`---
CRC error count UINT See ISO 11898
Rx message loss UINT ISO 11898
count subsystem has
detected a lost
receive message
Warning error count UINT See ISO 11898
Rx error counter UINT Receive error Range =
counter (see 0 – 256
ISO 11898)
Tx error counter UINT Transmit error Range =
counter (see 0 – 256
ISO 11898)
UINT[5] Reserved Default = 0
a These attributes are required if the MAC ID switch can be set to a different value than the device is currently
on-line at.
b These attributes are required if the bit rate switch can be set to a different value than the device is currently
on-line at.
c This attribute shall be stored in non-volatile memory.
d This attribute is required for CPF 2 safety devices. Non-safety devices shall not implement this attribute.
7.7.4.2 MAC ID
This attribute contains the MAC ID of this device. The range of values is 0 to 63 decimal.
A device that uses a switch to set the MAC ID shall return an Error Response, with General
Error Code 0x0E (Attribute not settable), in response to a Set_Attribute_Single request when
the switch setting is 0 to 63 and the MAC ID switch is enabled by other settings. When the
MAC ID switch setting is greater than 63 (disabled) or the MAC ID switch is disabled by other
settings, the device may support the setting of the MAC ID attribute by the
Set_Attribute_Single service request. The device shall provide visual indication (e.g. via
physical switch, LED) that the MAC ID switch has been overridden. A minor recoverable fault
shall be declared when the MAC ID switch is enabled and indicates a valid MAC ID, but does
not match the current on-line address of the device. During power up or reset, a device should
go to the Communications Faulted state if it has a MAC ID switch set to an invalid setting and
does not support the setting of the MAC ID attribute.
The MAC ID attribute is considered non-volatile in that once configured the attribute shall be
remembered after a power cycle or device reset. The “out-of-box” configuration shall default
to a MAC ID value of 63. The following MAC ID determination scenarii apply only to devices
that use non-volatile memory to store the MAC ID of the device.

61158-4-2 © IEC:2007(E) – 127 –
1. When the MAC ID switch is valid and enabled, the switch value is loaded into non-volatile
memory when the device powers up or is reset, and prior to attempt to go on-line. The
MAC ID switch value is not loaded into non-volatile memory at any other time.
2. Devices shall attempt to go on-line with the MAC ID value stored in non-volatile memory
or, if in the “out-of-box” configuration, with a MAC ID value of 63.
3. When a Set_Attribute_Single request with a valid MAC ID is received by a device with the
MAC ID switch disabled, the non-volatile MAC ID shall be loaded with the new MAC ID.
4. When a Set_Attribute_Single request with a valid MAC ID is received by a device with the
MAC ID switch enabled, the non-volatile MAC ID shall not change and an Error Response
with General Error Code 0x0E (Attribute not settable) shall be returned.
The modification of the MAC ID requires a device to delete all Connection objects and
re-execute the Network Access State Machine defined in IEC 62026-3.
7.7.4.3 Bit Rate
The Bit Rate attribute indicates the selected bit rate. Values are specified in Table 67.
Table 67 – Bit rate attribute values
Value Meaning
00 125 kbit/s
01 250 kbit/s
02 500 kbit/s
A device that uses a switch to set the bit rate shall return an Error Response, with General
Error Code 0x0E (Attribute not settable), in response to a Set_Attribute_Single request when
the bit rate switch is set to a valid value and not disabled by other settings. When the bit rate
switch is not set to a valid value (disabled) and/or the bit rate switch is disabled by other
settings, the device may support the setting of the Bit Rate attribute by the
Set_Attribute_Single service request. The device shall provide visual indication (via physical
switch, LED, etc.) that the bit rate switch has been overridden. A minor recoverable fault shall
be declared when the bit rate switch is enabled and indicates a valid bit rate, but does not
match the current on-line bit rate of the device. During power up or reset, a device should go
to the Communication Fault state if it has a bit rate switch set to an invalid setting and does
not support the setting of the Bit Rate attribute.
The Bit Rate attribute is considered non-volatile in that once configured the attribute shall be
remembered after a power cycle or device reset. The “out-of-box” configuration shall default
such that the device is able to go online at 125 kbit/s. The following bit rate determination
scenarii apply only to devices that use non-volatile memory to store the bit rate of the device.
1. When the bit rate switch is valid and enabled, the switch value is loaded into non-volatile
memory when the device powers up or is reset, and prior to attempting to go online. The
bit rate switch value is not loaded into non-volatile memory at any other time.
2. Devices shall attempt to go on-line with the bit rate value stored in non-volatile memory or,
if in the “out-of-box” configuration, able to go online at 125 kbit/s.
3. When a Set_Attribute_Single request with a valid bit rate is received by a device with the
bit rate switch disabled, the non-volatile Bit Rate shall be loaded with the new bit rate.
4. When a Set_Attribute_Single request with a valid bit rate is received by a device with the
bit rate switch enabled, the non-volatile Bit Rate shall not change, and an Error Response
with General Error Code 0x0E (Attribute not settable) shall be returned.
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 128 – 61158-4-2 © IEC:2007(E)
The modification of the Bit Rate will not take effect until the device is either physically reset
(such as cycle of power or a reset switch) or reset by sending the Reset Service to the
Identity object. During this time the Bit Rate attribute value will not match the actual network
bit rate.
7.7.4.4 BOI (Bus–off interrupt)
The BOI attribute consists of one bit that defines how a CAN device processes the bus–off
interrupt. The BOI attribute is bit position 0 within an octet for the Get_Attribute_Single/
Set_Attribute_Single services. The rest of the bits in the octet shall be zeros.
Table 68 – BOI attribute values
Value Meaning
--`,,```,,,,````-`-`,,`,,`,`,,`---
00 Hold the CAN chip in its bus-off (reset) state upon

detection of a bus-off indication
01 If possible, fully reset the CAN chip and continue
communicating upon detection of a bus-off indication
When the BOI attribute is FALSE (set to zero) and an ISO 11898 CAN chip bus-off event is
detected, the following steps are taken:
• the CAN chip is held in its reset/bus-off state;

• the device enters the Communications Faulted state (see IEC 62026-3).
When the BOI attribute is TRUE (set to one) and a CAN chip bus-off event is detected, it may
be possible to return the CAN chip to its normal operating mode and continue communicating
based on the Network Access State Machine presented in IEC 62026-3.
If the BOI attribute is set to one the device shall insure that it does not perpetually reset and
continue to produce corrupted packets on the bus. Failing to do so will allow the device to
disrupt all communications on the bus.
Connections are not necessarily effected when a bus-off event is detected and the device is
able to continue communicating. Previously established connections can remain existing or
they can be deleted (soft reset). Either way, the Duplicate MAC ID detection algorithm shall
be performed again per the Network Access State Machine.
As indicated in Table 66, support of the BOI attribute is optional. If it is not supported, a
device shall implement the behavior indicated by attribute value zero (0) in Table 68.
7.7.4.5 Bus–off counter
The Bus–off Counter counts the number of times the CAN chip went to the bus–off state
(counts number of bus–off interrupts). The counter has values of 0 to 255 decimal.
The Bus–off Counter is initialized to zero at power–up or device initialization.
The Bus–off Counter stops counting when it reaches maximum count. The counter does not
roll over. The Counter stays at maximum count until a Set_Attribute_Single is performed.
The DeviceNet object resets the Bus–off Counter to zero (0) whenever it receives a
Set_Attribute_Single request specifying the Bus-Off Counter attribute. The
Set_Attribute_Single data is not used and can be any value. The transmission of a
Set_Attribute_Single request to the Bus–off Counter is all that’s required to reset the counter.

61158-4-2 © IEC:2007(E) – 129 –
7.7.4.6 Allocation information
7.7.4.6.1 Overview
The Allocation Information attribute is pertinent to the Predefined Master/Slave Connection

Set. Its support is required if the Predefined Master/Slave Connection Set is supported. It
indicates whether or not the Predefined Master/Slave Connection Set defined in IEC 62026-3
has been allocated. If it has been allocated, then, this attribute indicates the device that has
performed the allocation and the Connection(s) that are currently allocated.
This attribute is modified when a successful response associated with an

Allocate_Master/Slave_Connection_Set service (defined later in this section) is generated.
This attribute is not modifiable by the Set_Attribute_Single Service. An Error Response whose
General Error Code Field is set to 0x0E (Attribute not settable) is returned if a
Set_Attribute_Single request specifies this attribute.
The Allocation Information attribute consists of the Allocation choice and the Master’s MAC
ID.
7.7.4.6.2 Allocation choice
The Allocation choice indicates which of the Predefined Master/Slave Connections are active
(in the Configuring, or Established state). Its format is specified in IEC 62026-3.
The Allocation choice is initialized to 00 at device power–up or reset.
7.7.4.6.3 Master’s MAC ID
The Master’s MAC ID contains the MAC ID of the device that has allocated the Predefined
Master/Slave Connection Set via the Allocate_Master/Slave_Connection_Set service. This
contains the Allocator’s MAC ID field copied from the Allocate_Master/Slave_Connection_Set
request.
The range of values is 0 to 63 and 255 decimal. A value in the range 0–63 indicates that the
Predefined Master/Slave Connection Set is currently allocated and denotes the MAC ID of the
device that performed the allocation. The value 255 means the Predefined Master/Slave
Connection set has not been allocated.
The Master’s MAC ID attribute is initialized to 255 (0xFF) at device power–up/reset.
7.7.4.7 Diagnostic counters
This attribute reports the counts of various types of network errors. The first field, diagnostic
counters descriptor, identifies which counters are supported by the device. Each bit indicates
if a designated counter is supported. If set, the counter is supported. Table 69 specifies the
diagnostic counter bit assignement.
Table 69 – Diagnostic counters bit description
Bit Counter Clearable
0 Arbitration loss Yes

1 Overload error Yes
2 Bit error Yes
3 Stuff error Yes
4 Ack error Yes
5 Form error Yes
6 CRC error Yes
--`,,```,,,,````-`-`,,`,,`

– 130 – 61158-4-2 © IEC:2007(E)
Bit Counter Clearable
7 Rx message loss Yes

8 Warning error Yes
9 Rx error No
10 Tx error No
11 – 15 Reserved (shall be 0) N/A
The remaining fields provide counter values for each supported counter. The counters are
advanced by one fore each occurrence of the error, except for the Rx and Tx error counters
(fields 10 and 11) which are incremented and decremented by the CAN peripheral based on
the ISO 11898 standard, and do not roll over.
All counters are cleared to zero when the device enters the Sending Duplicate MAC ID Check
Request Message (see the Link Access State Transition Diagram in IEC 62026-3).
7.7.5.1 General
The DeviceNet object shall support the common services as specified in Table 70.
Table 70 – DeviceNet object common services

--`,,```,,,,````-`-`,,`,,`,`,,`---
Need in
code
Class Instance
0x05 N/A Conditional a Reset Used to reset this instance of the DeviceNet
object
0x10 N/A Optional Set_Attribute_Single Set network or node specific configuration
information
0x0E Optional Optional Get_Attribute_Single Get network or node specific configuration
information
a This service is required when this DeviceNet object instance is addressable through some other CPF 2
access mechanism other than the subnet interface controlled by this DeviceNet object instance.
7.7.5.2 Reset
When the DeviceNet object receives a Reset request, it
• determines if it can provide the type of reset requested;

• responds to the request;
• performs the type of reset requested.
The Reset common service has the object–specific parameter specified in Table 71.
Table 71 – Reset service parameter
Name Type Description of request Semantics of values

parameters
Type USINT Type of reset See Table 72

61158-4-2 © IEC:2007(E) – 131 –
The parameter Type for the Reset common service has the enumeration specifications shown
in Table 72.
Table 72 – Reset service parameter values
Value Type of reset
0 Emulate as closely as possible cycling power on the network link that the DeviceNet object instance
represents. This value is the default if this parameter is omitted
1 Return as closely as possible to the out-of-box configuration, then emulate cycling power on the
network link as closely as possible
2 Excepting the MAC ID and bit rate, return as closely as possible to the out-of-box configuration, then
emulate cycling power on the network link as closely as possible. The MAC ID and bit rate is not
changed by this reset
3 – 99 Reserved
100– 199 Vendor specific reset behavior
200 – 255 Reserved
--`,,```,,,,````-`-`,,`,,`,`,,`---
7.7.6.1 General
The DeviceNet object shall support the class specific services as specified in Table 73.
Table 73 – DeviceNet object class specific services
Service Need in
code implementation
0x4B Optional Allocate_Master/Slave_ Requests the use of the Predefined Master/Slave

Connection_Set Connection Set
0x4C Conditional a Release_Master/Slave_ Indicates that the specified connections within
Connection_Set the Predefined Master/Slave Connection Set are
no longer desired. These connections shall be
released (deleted)
0x4D Conditional b Clear_Diagnostics Clears the diagnostic counters that are reported
in attribute 12
a The Release_Master/Slave_Connection_Set service is required if the

Allocate_Master/Slave_Connection_Set service is implemented in the device.
b This service shall be supported if any clearable counters are implemented in the Diagnostic counters
attribute.
7.7.6.2 Allocate_Master/Slave_Connection_Set,
Release_Master/Slave_Connection_Set
These services are used to allocate and deallocate the Predefined Master/Slave Connection
Set described in IEC 62026-3.
A device that behaves as the client across the Predefined Master/Slave Connection Set is
referred to as a master. A device that behaves as the server across the Predefined
Master/Slave Connection Set is referred to as a slave. Within the bounds of the service
descriptions to follow, a master and/or slave is viewed as a functional unit within a
communicating device.
A device that wants to function as another’s master shall first allocate the Predefined
Master/Slave Connection Set within the slave. Only one master can have the Predefined
Master/Slave Connection Set allocated at any given time. The entire Connection Set is

– 132 – 61158-4-2 © IEC:2007(E)
allocated and the master uses a select subset of the connections from the set (i.e. Bit Strobe
only, or Poll only). When a master wants to “give–up” its slave it releases all connections,
causing the slave to “deallocate” the Predefined Master/Slave Connection Set.
7.7.6.3 Clear_Diagnostics
This service clears (to zero) the clearable counters within attribute 12 (diagnostic counters).
The counters that are clearable are indicated in Table 69.
7.8 Connection configuration object (CCO)
7.8.1 Overview
This object defines an interface used to create, configure and control connections in a device.
This specification does not define or constrain the operation of the device’s connection
management state machine. The class attributes used by this object are shown in Table 75.
The revision history of the Connection Configuration object is described in Table 74.
Table 74 – Connection configuration object revision history
Class
revision
01 Initial definition
02 Intermediate definition
03 Release for IEC 61158
7.8.3.1 General
The Connection Configuration object shall support the class attributes as specified in Table 75.
Table 75 – Connection configuration object class attributes
Need in NV
Attri- Access Description of Semantics of
implemen Name Data type
bute ID rule attribute values
tation
0x01 Required Get NV Revision UINT Revision of this object Third revision,
value = 3 (see
7.8.2)
0x02 Required Get NV Max instance UDINT Maximum instance Value determined
number by node specifics
0x03 Required Get NV Num instance UDINT Number of connections
currently instantiated
0x04 This class attribute is optional and is described in IEC 61158-5-2
0x05 Conditional e Get NV Optional STRUCT List of optional services A list of service
service list of utilized in an object codes specifying the
variable class implementation optional services
size implemented in the
device for this class
Number UINT Number of services in The number of
services the optional service list service codes in
the list
Optional ARRAY of List of optional service The optional
services UINT codes service codes
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 133 –
Need in NV
Attri- Access Description of Semantics of
implemen Name Data type
bute ID rule attribute values
tation
0x06 These class attributes are optional and are described in IEC 61158-5-2
0x07
0x08 Required Get NV Format number UDINT See 7.8.3.2
0x09 Required Get/Set NV Edit signature UDINT See 7.8.3.3
0x0A – Reserved
0x20
0x21 Optional Get/ NV Scanner Mode BOOL The originator to target 0 = idle mode
Set a,b packets for connections
1 = run mode
originated by this device
shall reflect the state of
this attribute
0x22 Optional Get V Scanner WORD Bit 0, set to Scanner Bits 0 – 10
capabilities c Mode (attribute 0x21)
= 0, No
supported d
= 1, Yes
Bit 1, set to Scanner
Mode (attribute 0x21)
currently supported
Bit 2, Instances may
currently be created in
Run mode
currently be changed in
Run mode
currently be deleted in
Run mode
Bit 5, Instance may
currently be created in
Idle mode
currently be changed in
Idle mode
currently be deleted in
Idle mode
Bit 8,
Open_Connection/Close
_Connection services
supported
Bit 9, Stop_Connection
service supported
Bit 10, Get_Member
service to read image
tables supported
Bits 11-15 – reserved
and shall be zero
a A set to attribute 0x21 shall return a device state conflict (0x10) error if changing the Scanner Mode is not permitted
when the set attribute command is received.
b The value of attribute 0x21may be different than the value last set to attribute 0x21 if another mechanism (like a key
switch) changed the scanner’s mode.
c If the device in which this object is implemented has some sort of mechanism for changing connections, the state of
these bits shall be changed to reflect the present state of the device
d Bit 0 indicates if the Scanner Mode attribute has the ability to ever be set using a set attribute service.
e Required if object supports any optional services. Optional if object does not support any optional services.
--`,,```,,,,````-`-`,,`,

– 134 – 61158-4-2 © IEC:2007(E)
7.8.3.2 Format number
This number determines the format of instance attribute 0x09. This format value shall be
specified in the format_number field of each instance attribute 0x09. Meaning of the format
values is specified in Table 76.
Table 76 – Format number values
Value Meaning
0 Single O->T/T->O tables, 16-bit words, 0-based offsets

1 Multiple O->T/T->O tables, 16-bit words, 0-based offsets
2 – 99 Reserved
100 – 199 Vendor Specfic
200 – … All other values are reserved
7.8.3.3 Edit signature
Created and used by configuration software to detect modification to the instance attribute
values. For CP 2/1 this value is initially 0 and is incremented each time a change complete
operation is performed. For all other CPF 2 networks this value is initially 0 and is set to a 32
bit CRC each time a change complete operation is performed (the polynomial is
x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+x^0), the CRC
seed value shall be 0. The CRC is calculated on the set all attribute data stream for each
connection instance (lowest to highest) plus class attribute 0x01, class attribute 0x02, class
attribute 0x03 and class attribute 0x08.
7.8.4.1 General
The Connection Configuration object shall support the instance attributes as specified in
Table 77.
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 135 –
Table 77 – Connection configuration object instance attributes
Attribute Need in Access NV Description of Semantics of

Name Data type
ID implem rule attribute values
0x01 Required Get V Connection status STRUCT Connection See 7.8.4.2

of 4 status
octets
Gen_status USINT General status
Reserved USINT Reservied Shall be zero
Ext_status UINT Extended
status
0x02 Required Get/Set NV Connection flags WORD Connection See 7.8.4.3
flags
0x03 Required Get/Set NV Target device ID STRUCT See 7.8.4.4
of 8
octets
Vendor_id UINT Vendor ID
Product_type UINT Device type
Product_code UINT Product code
Major_rev USINT Major revision
Minor_rev USINT Minor revision
0x04 Conditional Get/Set NV CS data indix number UDINT See 7.8.4.5
0x05 Required Get/Set NV Net connection STRUCT See 7.8.4.6
parameters of 14
octets
Conn_timeout USINT Connection
Timeout
Multiplier
Xport_class_and_trig SWORD Transport Class
and Trigger
Rpi_OT UDINT Originator to
Target
Requested
Packet Interval
Net_OT UINT Originator to
Target network
connection
parameters
Rpi_TO UDINT Target to
Originator
Requested
Packet Interval
Net_TO UINT Target to
Originator
network
connection
parameters
0x06 Required Get/Set NV Connection path STRUCT See 7.8.4.7
of
variable
size
Open_path_size USINT Open
connection path
size
Reserved USINT Reserved
Open connection Padded Connection path
path EPATH
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 136 – 61158-4-2 © IEC:2007(E)

Name Data type
0x07 Required Get NV Config #1 data STRUCT See 7.8.4.8
of
variable
size
Config_data_size UINT Length of
config_data in
octets
Config_data ARRAY of Config #1 data
octets
0x08 Required Get/Set NV Connection Name STRUCT See 7.8.4.9
of
variable
size
name_size USINT Number of
characters in
the connection
name.
Reserved USINT Reserved Shall be zero
connection_name STRING2 User-assigned
--`,,```,,,,````-`-`,,`,,`,`,,`---
connection
name encoded
in UNICODE
0x09 Required Get/Set NV I/O mapping STRUCT See 7.8.4.10
of
variable
size
format_number UINT This number The format value
determines the shall match the
format of this value of class
attribute attribute 0x08
mapping_data_ UINT Size, in octets,
size of the
mapping_data
field that follows
mapping_data ARRAY of I/O mapping
octets information
associated with
this instance
0x0A Required Get/Set NV Config #2 data STRUCT See 7.8.4.11
of
variable
size
Config_data_size UINT Length of
config_data in
octets
Config_data ARRAY of Config #2 data
octets
0x0B Required Get/Set NV Proxy device ID STRUCT See 7.8.4.12
of 8
octets
Vendor_id UINT Vendor ID
Product_type UINT Device type
Product_code UINT Product code
Major_rev USINT Major revision
Minor_rev USINT Monor revision

61158-4-2 © IEC:2007(E) – 137 –

Name Data type
0x0C Conditional a Get/Set NV Connection disable BOOL Indicates if this 0 – This instance
instance of the of the
Connection Connection
Configuration Configuration
object is object is
disabled enabled.
1 – This instance
of the
Connection
Configuration
object is
disabled.
--`,,```,,,,````-`-`,,`,,`,`,,`---
When an Open
service is
received this
value shall be
set to 0. When a
Close or Stop
service is
received this
value shall be
set to 1
0x0D Conditional b Safety Parameters See IEC 61784-3-2
0x0E Conditional b Safety Connection

Parameter CRC
0x0F Conditional b Safety Configuration
Instance
0x10 Conditional b Safety ID Allocation
0x11 Conditional b Safety Target

Connection Serial
Number
a Attribute 0x0C shall be supported if conditional services Open_Connection (0x4C) and Close_Connection
(0x4D) are supported. Attribute 0x0C shall not be supported if conditional services Open_Connection (0x4C)
and Close_Connection (0x4D) are not supported.
b These attributes are not allowed if the device is not a safety device. If the device is a safety device, see
IEC 61784-3-2.
7.8.4.2 Connection status
The values for the originator connection status are defined in Table 78.
Table 78 – Originator connection status values
General Extended status Error Description

Status
0x00 N/A Connection is open

0x01 0x0000 or greater See Connection Manager service request error codes,
IEC 61158-6-2
0x02 – 0x26 0x0000 or greater See General Status codes, IEC 61158-6-2
0xD0 0x0001 Connection is closed or stopped (via the Close or
Stop services)
0x0002 Connection open is pending
0x0003 Connection close is pending
The values of the target connection status are defined in Table 79.

– 138 – 61158-4-2 © IEC:2007(E)
Table 79 – Target connection status values

Status
0x00 0x0000 Connection is open

0x01 0x0001 or greater The number of connection to this target
0xD0 0X0001 Connection is closed or stopped (via the Close or
Stop services)
7.8.4.3 Connection flags
The bit patterns for the connection flags are defined Table 80.
Table 80 – Connection flags
Bit Meaning
0 Connection
0 = Originator
1 = Target
1–3 O->T Real time transfer format
000 – Use 32-bit Run/Program header to indicate idle mode
001 – Use zero data length packet to indicate idle mode
--`,,```,,,,````-`-`,,`,,`,`,,`---
010 – None. Connection is pure data and is modeless
011 – Heartbeat
100 – Reserved
101 – Safety (see IEC 61784-3-2)
100 thru 111 – reserved for future use
4-6 T->O Real time transfer format
000 – Use 32-bit Run/Program header to indicate idle mode
001 – Use zero data length packet to indicate idle mode
010 – None. Connection is pure data and is modeless
011 – Heartbeat
100 – Reserved
101 – Safety (see IEC 61784-3-2)
100 thru 111 – reserved for future use
7 - 15 Reserved
7.8.4.4 Target device ID
This attribute is the identity of the target device for this connection instance. This identity
information is not used for verifying (keying) the online target device, it is used by a
configuration tool to locate the correct electronic data sheet for the connection configuration
described in this CCO instance. For Target instances this attribute shall be the identity of the
device containing this CCO object.
7.8.4.5 CS data index number
The CS Data Index Number attribute is required for a device on CP 2/1; otherwise this
attribute shall not be implemented.

61158-4-2 © IEC:2007(E) – 139 –
The CS Data Index Number is a value set by the configuration software. This is the
connection_index value returned from the Scheduling object read service (see 7.4.4 for a the
definition of the Scheduling object services). This attribute is ignored for target instances.
7.8.4.6 Net connection parameters
7.8.4.6.1 conn_timeout
The conn_timeout is the value used for the connection timeout multiplier field defined in
IEC 61158-6-2 (Forward_Open request). conn_timeout is ignored for target instances.
7.8.4.6.2 xport_class_and_trig
The xport_class_and_trig is the value used for the Transport Type/Trigger field defined in
IEC 61158-6-2 (Forward_Open request). xport_class and_trig is ignored for target instances.
7.8.4.6.3 rpi_OT
The rpi_OT is the value used for the O_to_T RPI field defined in IEC 61158-6-2
(Forward_Open request). rpi_OT is ignored for target instances.
7.8.4.6.4 net_OT
The net_OT is the value used for the O_to_T Network Connection Parameters field in
IEC 61158-6-2 (Forward_Open request). Only the size field is used for target instances.
7.8.4.6.5 rpi_TO
The rpi_TO is the value used for the T_to_O RPI field defined in IEC 61158-6-2
(Forward_Open request). rpi_TO is ignored for target instances.
7.8.4.6.6 net_TO
The net_TO is the value used for the T_to_O Network Connection Parameters field in
IEC 61158-6-2 (Forward_Open request). Only the size field is used for target instances.
7.8.4.7 Connection path
7.8.4.7.1 open_path_size
The open_path_size is the value used for the Connection_Path_size field in IEC 61158-6-2
(Forward_Open request). For target instances the open_path_size is used for matching the
open_path_size received in a forward open.
7.8.4.7.2 open connection path
The open_connection_path is the value used for the Connection_Path field in IEC 61158-6-2
(Forward_Open request). For target instances the open_connection_path is used for matching
the open_connection_path received in a forward open.
7.8.4.8 Config #1 data
This does not apply to target instances. The data specified in attributes 0x07 and 0x0A are
concatenated (in that order) into a single data segment, then appended to the connection path
in attribute 0x06 to form the complete path sent in the Forward_Open service of the
Connection Manager object.
All the configuration data may be placed in attribute 7 or all the configuration data may be
placed in attribute 0x0A or the configuration data may be split between attributes 0x07 and
0x0A. When a connection is a proxied connection the convention that shall be followed is that
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 140 – 61158-4-2 © IEC:2007(E)
any configuration data intended for the proxying device is placed in attribute 0x07 and any
configuration data intended for the proxied device is placed in attribute 0x0A. Config #1 data
is ignored for target instances.
7.8.4.9 Connection name
This Connection Name field allows a user to name each connection instance. The connection
name has no meaning to the Connection Configuration object.
7.8.4.10 I/O mapping
The I/O mapping attribute contains I/O mapping data. The I/O mapping data specifies image
table locations where target to originator data is placed and where originator to target data is
obtained.
Table 81 describes the structure of the mapping_data field of the I/O mapping attribute for
each of the format numbers.
Table 81 – I/O mapping formats
Format Mapping_data_size Name Data Type Description

Number (in octets)
Single I/O tables STRUCT of 16 bit words, 0 based 16 bit word offsets
4 octets
0 4 O->T offset UINT Offset into O->T image table
T->O offset UINT Offset into T->O image table
Multiple I/O tables STRUCT of Table selection, 16 bit words, 0 based 16
8 octets bit word offsets
O->T table UINT O->T image table selection
1 8 O->T offset UINT Offset into O->T image table
--`,,```,,,,````-`-`,,`,,`,`,,`---
T->O table UINT T->O image table selection

T->O offset UINT Offset into T->O image table
7.8.4.11 Config #2 data
This note does not apply to target instances. The data specified in attributes 0x07 and 0x0A
are concatenated (in that order) into a single data segment, then appended to the connection
path in attribute 0x06 to form the complete path sent in the Forward_Open service of the
Connection Manager object. All the configuration data may be placed in attribute 0x07 or all
the configuration data may be placed in attribute 0x0A or the configuration data may be split
between attributes 0x07 and 0x0A. When a connection is a proxied connection the convention
that shall be followed is that any configuration data intended for the proxying device is placed
in attribute 0x07 and any configuration data intended for the proxied device is placed in
attribute 0x0A. Config #2 data is ignored for target instances.
7.8.4.12 Proxy Device ID
This attribute is the identity of the device proxying for the target device for this connection
instance. This identity information is not used for verifying (keying) the online target device, it
is used by a configuration tool to locate the correct electronic data sheet for the connection
configuration described in this CCO instance. For Target instances and Connections that are
not proxied this attribute shall be ignored.

61158-4-2 © IEC:2007(E) – 141 –
7.8.5.1 General
The Connection Configuration object shall support the common services as specified in
Table 82.
Table 82 – Connection configuration object common services
Need in
code
Class Instance
0x01 Required Required Get_Attribute_All Gets all attributes of the

specified instance
0x02 Optional Required Set_Attribute_All Sets all attributes of the
specified instance
0x08 Required N/A Creat Creates a new connection
instance
0x09 Required Required Delete Deletes an existing connection
instance
0x0E Optional Required Get_Attribute_Single Returns the contents of the
specified attribute
0x10 Required Optional Set_Attribute_Single Modifies an attribute value
0x15 Required Required Restore Restore current connection
attributes
7.8.5.2 Get_Attribute_All
--`,,```,,,,````-`-`,,`,,`,`,,`---
This service shall read all attributes associated with an existing instance and shall support the
error codes shown in Table 83.
Table 83 – Get_Attribute_All error codes

Status
0x04 None Path syntax error

0x05 None Instance undefined
0x08 None Unimplemented service
The structure of the Get_Attribute_All response is shown in Table 84.

– 142 – 61158-4-2 © IEC:2007(E)
Table 84 – Get_Attribute_All response
Name Data Type Description
Connection STRUCT of 4 Connection status information. When the connection is not open,
status octets this attribute contains an error code indicating the reason
USINT General status
USINT Pad
UINT Extended status
Connection WORD Connection flags
flags
Target device id STRUCT of 8 Target device identification
octets
UINT Vendor ID
UINT Product type
UINT Product code
USINT Major revision
USINT Minor revision
--`,,```,,,,````-`-`,,`,,`,`,,`---
CS data index UDINT Scheduling object read data connection_index number. The default
number value used when this attribute is not supported shall be
0xFFFFFFFF
Net connection STRUCT of 14 Network connection parameters for both originator-to-target and
parameters octets target-to-originator directions
USINT Connection time-out multiplier
SWORD Transport class and trigger
UDINT Originator-to-target RPI
UINT Originator-to-target network connection parameters
UDINT Target-to-originator RPI
UINT Target-to-originator network connection parameters
Connection path STRUCT of Connection path
variable size
USINT Size of connection path, in 16-bit words, used in the Connection
Manager Forward_Open service request
USINT Reserved. Shall be zero
ARRAY of Connection path. The open connection path size is the length of
UINT this array
Config #1 data STRUCT of Config #1 data. This data is sent to devices via the Connection
variable size Manager Forward_Open service request
UINT Configuration data length in octets
ARRAY of Configuration data padded to an even number of octets
USINT
Config #2 data STRUCT of Config #2 data. This data is sent to devices via the Connection
variable size Manager Forward_Open service request
UINT Configuration data length in octets
ARRAY of Module configuration data padded to even number of octets
USINT
Connection STRUCT of Connection name
name variable size
USINT Number of characters in connection name
USINT Pad
STRING2 Connection name encoded in UNICODE

61158-4-2 © IEC:2007(E) – 143 –

I/O mapping STRUCT of I/O mapping
variable size
UINT Format number
UINT Attribute size in octets
ARRAY of Attribute data padded to an even number of octets
USINT
Proxy device id STRUCT of 8 Proxy device identification
octets
UINT Vendor ID
UINT Product type
UINT Product code
Safety
parameters
Connection
parameter CRC STRUCT of See IEC 61784-3-2.
55 octets
These 55 octets are included in the Get_Attribute_All response
Safety
only if either the O=>T or T=>O real time transfer format in the
configuration
Connection Flags Attribute (attribute 2) indicates the format is
instance
Safety
Safety id
allocation flag
Safety target
connection
serial number
Connection BOOL Bit 0, value of connection disable attribute (attribute 12) if

disable supported. 0, if connection disable attribute is not supported
7.8.5.3 Set_Attribute_All
This service shall read all attributes associated with an existing instance and shall support the
Table 85 – Set_Attribute_All error codes

Status

0x0C None Wrong object state
The structure of the Set_Attribute_All request is shown in Table 86.

--`,,```,,,,````-`-`,,`,,`,`,,`---

– 144 – 61158-4-2 © IEC:2007(E)
Table 86 – Set_Attribute_All request
Connection flags WORD Connection flags

Target device id STRUCT Target device identification
of 8 octets
UINT Vendor ID
UINT Product type
UINT Product code
Cs data index UDINT Scheduling object read data connection_index number. The default
number value used when this attribute is not supported shall be 0xFFFFFFFF
Net connection STRUCT Network connection parameters for both O⇒T and T⇒O directions.
parameters of 14
octets
--`,,```,,,,````-`-`,,`,,`,`,,`---
USINT Connection time-out multiplier
SWORD Transport class and trigger
UDINT O⇒T RPI
UINT O⇒T network connection parameters
UDINT T⇒O RPI
UINT T⇒O network connection parameters
Connection path STRUCT Connection path
of variable
size
USINT Size of connection path, in 16-bit words, used in the Connection
Manager Forward_Open service request
USINT Reserved. Shall be zero.
ARRAY of Connection path. The open connection path size is the length of this
UINT array
Config #1 data STRUCT Config #1 data. This data is sent to devices via the Connection
of variable Manager Forward_Open service request
size
UINT Module configuration data length in octets.
USINT
Config #2 data STRUCT Config #2 data. This data is sent to devices via the Connection
of variable Manager Forward_Open service request
size
UINT Module configuration data length in octets
USINT
Connection name STRUCT Connection name
of variable
size
USINT Number of characters in connection name
USINT Pad.
STRING2 Connection name encoded in UNICODE.
I/O mapping STRUCT I/O mapping
of variable
size
UINT Format number.
UINT Attribute size in octets

61158-4-2 © IEC:2007(E) – 145 –
ARRAY of Attribute data padded to an even number of octets

USINT
Proxy device id STRUCT Proxy Device identification.
of 8 octets
UINT Vendor Id
UINT Product type
UINT Product code
Safety
parameters
STRUCT See IEC 61784-3-2.
Safety of 49
configuration octets These 49 octets are included in the Set_Attribute_All service data only
instance if either the O=>T or T=>O real time transfer format in the Connection
Flags Attribute (attribute 2) indicates the format is Safety
Safety id
allocation flag
Connection BOOL Bit 0, value of connection disable attribute (attribute 12)
disable
7.8.5.4 Create
This service creates a new instance of a Connection Configuration object. Initial attribute
values may also be specified with this service. The created instance number is assigned by
the class and returned to the requestor. Table 87 defines the request parameters for this
service.
Table 87 – Create request parameters
Parameter Data Type Description
Connection flags WORD Connection flags

NumConnParams UINT Number of attribute/value pairs that
follow
ConnParams ARRAY of List of Attribute number/value pairs
STRUCT of variable size
UINT Attribute number
Object/class attribute specific Attribute value
STRUCT
--`,,```,,,,````-`-`,,`,,`,`,,`---
This service shall read all attributes associated with an existing instance and shall support

– 146 – 61158-4-2 © IEC:2007(E)
Table 88 – Create error codes
General Extended Error Description

Status status
0x02 0x0001 Insufficient resource — maximum number of instances

already exist
0x0002 Insufficient resource — not enough memory on device
0x03 None Invalid parameter error (when attribute count is invalid)
0x0E None Attempt to set a read-only attribute
0x13 None Insufficient request data — request was too short or
truncated
0x1C None Attribute list shortage — required attribute was missing
7.8.5.5 Delete
This service deletes existing connection instances. If addressed to the class-level, all
connection instances are deleted. If addressed to the instance-level, only the addressed
instance is deleted. This service shall support the error codes shown in Table 89.
Table 89 – Delete error codes

Status

0X08 None Unimplemented service
7.8.5.6 Restore
This service shall discard modifications to instances that have not yet been committed by the
Change_Complete service. If the Restore service is addressed to the class (instance 0), then
pending modifications for all instances shall be discarded and the edit session shall be ended.
If addressed to a specific instance, only modifications for that instance shall be discarded and
the edit session shall not be ended.
This service shall support the error codes shown in Table 90.
Table 90 – Restore error codes

Status

--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 147 –
7.8.6.1 General
The Connection Configuration object shall support the class specific services as specified in
Table 91.
Table 91 – Connection configuration object class specific services
--`,,```,,,,````-`-`,,`,,`,`,,`---
Service Need in implementation
code Class Instance
0x4B Required N/A Kick_Timer Kicks Edit Watchdog Timer

0x4C Conditional * Conditional * Open_Connection Opens connections
0x4D Conditional * Conditional * Close_Connection Closes connections
0x4E Conditional * Conditional * Stop_Connection Stops connections
0x4F Required N/A Change_Start Manages session editing

0x50 Required N/A Get_Status Get status for multiple
connections
0x51 Required N/A Change_Complete Completes session editing
0x52 Required N/A Audit_Changes Audits pending changes
* The Open_Connection and Close_Connection services shall either both be supported or

neither the Open_Connection or Close_Connection services shall be supported. The
Stop_Connection service may only be supported if the Open_Connection service is supported
7.8.6.2 Kick_Timer
This service shall reinitialize the edit watchdog timer. Upon successful execution of the
Change_Start service, the edit watchdog timer shall be started with a period of 60 s. This
timer is used to recover from the loss of a configuration client between the Change_Start and
Change_Complete/Restore operations. Receipt of any service request shall reset the edit
watchdog timer. Clients may request this service to reset the timer without otherwise affecting
the state of the Connection Configuration object. If the edit watchdog timer expires, all
pending modifications shall be discarded and the edit session shall be ended.
Table 92 – Kick_Timer error codes

Status

7.8.6.3 Open_Connection
The Open_Connection service shall cause the connection associated with an instance of the
Connection Configuration object to open. If the Open_Connection service is addressed to the
class (instance 0), then all connection instances shall be opened. If addressed to a specific
instance, then only that connection instance shall be opened.

– 148 – 61158-4-2 © IEC:2007(E)
Table 93 – Open_Connection error codes

Status

7.8.6.4 Close_Connection
The Close_Connection service shall cause the connection associated with an instance of the
Connection Configuration object to close. If the Close_Connection service is addressed to the
class (instance 0), then all connection instances shall be closed. If addressed to the instance
level, then only the specified instance shall be closed. The Close_Connection service shall
initiate a “graceful” connection shutdown, that is, a Forward_Close request shall be sent to
the connection target. Once a connection has been closed by this service it shall remain
closed until an Open_Connection service is issued.
Table 94 – Close_Connection error codes

Status

0x08 None Uninplemented service
7.8.6.5 Stop_Connection
The Stop_Connection service shall cause the connection associated with an instance of the
Connection Configuration object to stop producing data immediately without sending an
Forward_Close request to the connection target. If the Stop_Connection service is addressed
to the class (instance 0), then all connection instances shall be stopped. If addressed to the
instance level, then the specified instance shall be stopped. Once a connection has been
stopped, it remains stopped until a subsequent Open_Connection service request is issued.
Table 95 – Stop_Connection error codes

Status
--`,,```,,,,````-`-`,,`,,`,`,,`---

7.8.6.6 Change_Start
This service shall
a) signal the beginning of an edit session;

b) synchronize the current and pending attributes;

61158-4-2 © IEC:2007(E) – 149 –
c) place all connections in the "changeable" state;

d) start the edit watchdog timer.
Change_Start shall be requested prior to performing any services that modify the attributes of
a connection. This service shall only be addressed to the class-level (instance 0). If a
Change_Start service is received while an edit session is active, an Object State Conflict
error (0x0C) shall be returned.
Table 96 – Change_Start error codes
--`,,```,,,,````-`-`,,`,,`,`,,`---
Status

0x10 None Device state conflict
7.8.6.7 Get_Status
The Get_Status service shall retrieve the status attribute (attribute 1) for multiple connections
via a single transaction. This service shall be supported at the class-level (instance 0) only.
Given a starting instance number, the Get_Status service shall return instance/status pairs
until either the response buffer is full or the status of all connections has been returned.
The request parameter are defined in Table 97.
Table 97 – Get_Status service parameter
Starting Instance UDINT Starting instance number
The response parameters are defined for this service in Table 98.
Table 98 – Get_Status service response
Done Indicator UINT 0 = More status to be retrieved

1 = All connection status information
has been retrieved.
All other values reserved.
NumStatusEntries UINT Number of instance/status pairs that
follow
StatusEntries ARRAY of List of instance/status pairs
STRUCT of 8
octets
UDINT General status
USINT General status
USINT Reserved, shall be 0
UINT Extended status

– 150 – 61158-4-2 © IEC:2007(E)
Table 99 – Get_Status service error codes

Status
0x03 None Invalid parameter error (when attribute count is

invalid)
7.8.6.8 Change_Complete
This service shall signal the completion of an edit session. Pending attributes for all modified
connection instances shall be applied. This service shall take a parameter indicating the type
of change being performed; either full or incremental. If an incremental edit is specified, then
only the connections that have been modified shall be broken and re-established. If a full edit
is specified, then all connections shall be broken and all supporting resources shall be freed
and reallocated before attempting to re-establish the connections. The Change_Complete
service shall be supported at the class-level (instance 0) only.
If optional instance attribute 12 is supported and the value of instance attribute 12 is FALSE
or if optional instance attribute 12 is not supported an attempt to open the connection shall be
made. If optional instance attribute 12 is supported and the value of instance attribute 12 is
TRUE, no attempt shall be made to open the connection.
The request parameter is defined in Table 100.
Table 100 – Change_Complete service parameter
Change type UINT 0 = Full

1 = Incremental
All other values reserved.
Table 101 – Change_Complete service error codes

Status
0x02 None Resource unavailable. Indicates that there is not

enough memory on the host device to support the
specified configuration
7.8.6.9 Audit_Changes
This service shall verify whether or not there is enough memory on the host device to support
a proposed configuration. Like the Change_Complete service, this service shall take a
parameter indicating the type of change being performed; either full or incremental. The
Audit_Changes service shall be supported at the class-level (instance 0) only. This service
allows a configuration client to determine if all pending changes will be successful before
actually committing the changes with the Change_Complete service.
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 151 –
The request parameter is defined in Table 102.
Table 102 – Audit_Changes service parameter
Change type UINT 0 = Full

1 = Incremental
All other values reserved
Table 103 – Audit_Changes service error codes

Status
0x02 None Resource unavailable. Indicates that there is not

enough memory on the host device to support the
specified configuration
7.8.7 Behavior
Figure 22 summarizes the process of creating, editing, and deleting connections.
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 152 – 61158-4-2 © IEC:2007(E)
Start
Modifications Current and pending attributes are
synchronized. All connections placed in
the “changeable” state and the edit
Request watchdog timer is started.
Change
Start The Kick Timer service should be
Service requested if the interval between requests
will exceed sixty seconds.
Create New Edit Delete

Connection Existing Existing
? Connection Connection
No No No
? ?
Yes Yes Yes
Request Request Request Delete

Create Service SetAttrSingle/ Service
SetAttrAll
Service
--`,,```,,,,````-`-`,,`,,`,`,,`---
No Pending attribute changes
Done
are discarded, creates and
Editing?
deletes are rolled back.
Checks to see if there
The edit watchdog timer
is enough memory to
is stopped.
support the proposed Yes
configuration.
Request Audit Request

Accept
Changes Restore
Yes Edits? No
Service Service
Pending attribute changes

are applied, creates and
deletes are committed.
Request Change The edit watchdog timer
Audits
Complete is stopped.
Pass?
No Yes Service
End
Figure 22 – Connection configuration object edit flowchart
8 Other DLE elements of procedure
8.1 Network attachment monitor (NAM)
8.1.1 General
The network attachment monitor (NAM) shall control the DLL to allow new nodes to non-
disruptively join a working link.
The NAM controls attaching the DLL to an existing link without causing disruption to
transmissions on that link. It accomplishes this by monitoring and controlling the DLL via the
Station Management and the normal send/receive interfaces to the DLL as summarized in
Table 104 and Figure 23.

61158-4-2 © IEC:2007(E) – 153 –
Table 104 – NAM states
State Actions
Check for 1) auto-address nodes shall find an address before entering (see 8.1.3)
Cable
2) use default parameters (see 8.1.2)
3) transmit DLPDUs, but no moderators
4) if receive rogue moderator, go to “Check for Moderator”
5) if receive any good DLPDU, transmit one more DLPDU, then go to “Wait to Rogue”
Wait to 1) use default parameters (see 8.1.2)
Rogue
2) transmit no DLPDUs
3) if hear rogue moderator, go to “Check for Moderator”
4) if hear no rogue moderator for 400 – 600 ms, go to “I’m Alive”
Check for 1) transmit no DLPDUs
Moderator
2) if hear 9 identical valid moderators in successive NUTs, go to “I’m Alive” using the
parameters in those moderators
3) if have not heard a moderator for 1,0 s – 3,0 s, go to “Check for Cable”
4) if receive moderator with invalid link parameters, stay in this state, but change network
status indicator to invalid link configuration (flashing red / green)
I’m Alive 1) auto-address nodes shall find an address before entering (see 8.1.3)
2) transmit DLPDUs, including moderators if this node has the lowest MAC ID
3) transmit three fixed tag 0x80 Lpackets
4) after sending them go to “Attached”
Attached 1) normal network operation
2) transmit DLPDUs, including moderators if this node has the lowest MAC ID
4) if no other nodes on link for 8 NUTs, go to “Check for Cable”
power on
Check for Cable

ro
gu
ei
no nt
m er
od up
er t
ato
rf
ou
n d
Waiting to rogue interupt Check for

Rogue fou
nd Moderator
tor
d era
mo
no ro
gue fo
lonely
rupt
r 500
e inte
interrup
t
rup
ms
e
rogu
int
ue
t
rog
I’m alive sent

I’m alive Attached
Figure 23 – NAM state machine
8.1.2 Default parameters
The default link parameters for a node shall be as shown in Table 105:
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 154 – 61158-4-2 © IEC:2007(E)
Table 105 – Default link parameters
Parameter Data type Value
NUT_length UINT 100 ms (10 000 intervals of 10 μs each)

smax USINT 0
umax USINT 99
slotTime USINT 254 (255 μs)
blanking USINT 6 (octet times)
gb_start USINT 610 μs (61 intervals of 10 μs each)
gb_center USINT 450 μs (45 intervals of 10 μs each)
modulus USINT 127
gb_prestart USINT 920 μs (92 intervals of 10 μs each)
8.1.3 Auto-addressing
Some nodes may have no pre-assigned MAC ID. These nodes, known as auto-address
nodes, shall search for an unused MAC ID by observing the link. The auto-address node shall
not transmit until a free MAC ID is found.
NOTE Typically, auto-address nodes are transient nodes such as hand-held terminals.
8.1.4 Valid MAC IDs
--`,,```,,,,````-`-`,,`,,`,`,,`---
On a link with default configuration parameters, an auto-address node shall search in the
range 92 through 99. On a link with any other configuration parameters, an auto-address node
shall search in the range SMAX+1 through UMAX. A free MAC ID shall be declared found if at
least three sequential unscheduled transmit opportunities for that MAC ID have passed
without receiving any DLPDUs from that MAC ID.
NOTE The ControlNet object provides an interface to determine the MAC ID which has been chosen.
8.1.5 State machine description
The following state machine description shall define the behavior of the network attachment
monitor:
// Network Attachment Monitor state machine description
//
// This state machine monitors and controls the DLL to make sure that it goes on-line
// in a fashion that does not disrupt a running network.
//
//
// Lpacket constants: masks for ctl octet
//
#define FIXEDSCREEN 1
#define TAGPAD 2
#define DATAPAD 4
#define OCTETWORD 8
//
// moderator Lpacket constants
//
#define MODERATOR_SIZE 9 // moderator Lpacket size octet
#define MODERATOR_CTL 1 // moderator Lpacket control octet
#define MODERATOR_TAG 0 // moderator Lpacket tag octet
//
// Lpacket class
//
class Lpacket
{
public:
USINT size; // return the size octet

USINT ctl; // return the control octet

61158-4-2 © IEC:2007(E) – 155 –
// return the value of the tag pad bit

int tag_pad(void)
{
return (ctl&TAGPAD) >>1;
}
// return the value of the data pad bit
int data_pad(void)
{
return (ctl&DATAPAD) >>2;
}
// return the number of octets in the Lpacket
int wire_size(void)
{
return size*2 - tag_pad() - data_pad();
}
// get the next octet to be transmitted
USINT get_next_octet(void);
// is this Lpacket aborted?

BOOL abort(void);
};
class fixedLpacket : public Lpacket

{
public:
USINT tag;
USINT dest;
};

{
public:
UINT NUT_length;
USINT smax;
USINT umax;
USINT slotTime;
USINT blanking;
USINT gb_start;
USINT gb_center;
USINT usr;
USINT interval_count;
USINT modulus;
USINT tMinus;
USINT gb_prestart;
USINT spare;
BOOL isValid(void);
// this checks for umax<myaddr, and similar parameter
// error that would prevent a node from successfully
// joining a network
BOOL operator==(moderatorLpacket &);

// the equality test for moderator Lpackets excludes
// the interval count, and usr, but includes the
// tMinus counter
};
//
// interface to station management
//
BOOL SM_powerup; // input indication: powerup has occurred
void SM_LEDS(LED_STATE); // set the LEDS to a specified pattern
#define LED_bad_network_parameters // flashes the network status indicator
{
public:
BOOL listen_only;
USINT myaddr;
UINT NUT_length;
USINT smax;
USINT umax;
USINT slotTime;
USINT blanking;
USINT gb_start;
USINT gb_center;
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 156 – 61158-4-2 © IEC:2007(E)
USINT modulus;
USINT gb_prestart;
};
//
// interface to DLL
//
void DLL_xmit_fixed_request(char *comment);
void DLL_xmit_fixed_confirm(void);
void DLL_recv_fixed_indication();
//
// These timer objects are as used internally to the ACM of the DLL.
//
// various behaviors for timers
enum {ONCE_UP, ONCE_DOWN, REPEAT_UP, REPEAT_DOWN} timer_mode;
class timer
{
public:
float count; // number of ticks left
float preset; // initialize ticks, or cycle length
BOOL expire; // latched flag when timer expires
timer_mode mode;
// constructor: defines mode
timer(timer_mode m)
{
mode = m;
}
void restart(void)
{
if(mode == REPEAT_DOWN
|| mode == ONCE_DOWN) // if counting down, start with preset
{
count = preset;
}
else
{
count = 0; // else start from zero
}
// start counting
}
void start(float interval) // start counting down from interval towards zero
{
mode = ONCE_DOWN;
preset = interval; // set interval
restart(); // start counting
}
void begin_counting(void) // start counting up from zero
{
mode = ONCE_UP;
restart();
}
--`,,```,,,,````-`-`,,`,,`,`,,`---
bool expired(void) // returns true if the timer has expired; clears flag
{
BOOL tmp;
tmp = expire;
expire = 0;
return tmp;
}
};
//
// time conversion factors
//
#define usec
#define msec *1000
#define sec *1000000
class timer timer(ONCE_DOWN); // general purpose timer

int counter; // general purpose counter

61158-4-2 © IEC:2007(E) – 157 –
moderatorLpacket new_mod; // buffer for getting new moderator Lpackets

moderatorLpacket old_mod; // buffer for saving moderator Lpackets
DLL_config_data default_config; // DLL config parameters for default mode

DLL_config_data DLL_config; // scratch DLL config buffer
// Wait for powerup.

// Bring the DLL on-line.
// It is assumed that the node's MAC ID is known before this machine is allowed to
power-up.
// If this node is auto-addressed, a free MAC ID shall be determined
// before enabling this machine.
state: powerup0
event: SM_powerup
destination: checkForCable0
action:
DLL_set_current_request(default_config); // set default parameters
state: checkForCable0
event: DLL_set_current_confirm() // default parameters were set
action:
DLL_enable_moderator_request(FALSE); // disable moderators
DLL_online_request(TRUE); // send DLL on-line
event: DLL_online_confirm() // DLL is now on-line, but can't moderate
// rogue -> checkForModerator
event: DLL_SM_report(rogue)
destination: checkForModerator0
action:
DLL_listen_only_request(TRUE); // send DLL to listen only
DLL_enable_fixed_request(MODERATOR_TAG); // enable reception of moderators
event: DLL_recv_fixed_indication
|| DLL_recv_gen_indication // any Lpacket received
destination: waitForRogue
action:
wait until transmit once more;
DLL_enable_moderator_request(FALSE); // re-enable moderators
timer.start(500 msec);
state: waitForRogue
action:
event: timer.expired()
destination: alive0
action:
DLL_listen_only_request(FALSE); // send DLL to listen only
DLL_xmit_fixed_request("send an I'm alive message");
//
// in the "alive" states, the DLL is on-line
// three "I'm alive" message are sent
// if lonely is detected, do nothing
//
state: alive0
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 158 – 61158-4-2 © IEC:2007(E)

action:
// first message sent, send the second
event: DLL_xmit_fixed_confirm();
destination: alive1
action:
state: alive1
action:
// second message sent, send the third

destination: alive2
action:
state: alive2
action:
// third message send, consider attachment to be complete

destination: attached
//
// the DLL is on-line and fully functional
//
state: attached
action:
event: DLL_SM_report(lonely)
destination: checkForCable
action:
DLL_enable_moderator_request(FALSE); // disable moderators
//
// a rogue event was detected
// the DLL instantly disables itself (it goes to its rogue state)
//
state: checkForModerator0
event: DLL_enable_fixed_confirm(); // receive moderators enabled

action:
counter = 0; // init moderator counter
old_mod = NULL;
timer.start(3 sec);
// timeout
event: timer.expired
action:
DLL_set_current_request(default_params); // set default parameters
// ignore irrelevant received DLPDUs

event: DLL_recv_fixed_indication(new_mod) // got a moderator Lpacket
condition: received Lpacket is not mod
|| received Lpacket is not TUI
|| TUI.net_change == false
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 159 –
// received a TUI indicating a net change in progress -- reset counter

condition: received Lpacket is TUI
&& TUI.net_change == TRUE // the new moderator is different
action:
counter = 0;
// received a moderator that would not permit this node

// to operate normally (for example, - myaddr>umax)
// reset counter and flash bad_net_parameter indicator
condition: !isValid(new_mod) // the new moderator is no good for us
action:
SM_LEDS(LED_bad_network_parameters); // flash the indicator
old_mod = new_mod;
counter = 0;
// received moderator that doesn't match the last one -- reset counter
condition: received Lpacket is mod
&& new_mod != old_mod // the new moderator is different
action:
old_mod = new_mod;
counter = 0;
// received moderator that matches, but not the ninth match -- just increment the
counter
&& isValid(new_mod)
&& new_mod==old_mod
&& counter<8
action:
counter++;
// have received 9 successive identical moderators
// adopt these parameters and proceed to go back on-line
&& isValid(new_mod)
&& new_mod==old_mod
&& counter==8
action:
DLL_online_request(FALSE); // send DLL off-line
//
// second step to going back on-line
//
event: DLL_online_confirm() // now off-line
destination: check ForModerator3
action:
copy parameters from new_mod to DLL_config; // get net configuration from
moderator
DLL_set_current_request(DLL_config); // adopt those parameters
//
// third step to going back on-line
//
event: DLL_set_current_confirm() // have now adopted new parameters
destination: alive0
action:
DLL_listen_only_request(FALSE); // send DLL to listen only
8.2 Calculating link parameters
8.2.1 Link parameters

--`,,```,,,,````-`-`,,`,,`,`,,`---
This subclause describes the requirements governing the selection of values for the following
configuration variables:
— NUT_length;
— gb_prestart;

– 160 – 61158-4-2 © IEC:2007(E)
— gb_start;
— gb_center;
— slotTime;
— blanking.
NOTE The definitions of the link parameters include NUT_length, gb_center, gb_prestart, gb_start,
blanking, and slotTime.
8.2.2 Conditions affecting link parameters
Parameter value selection shall allow for worst case conditions of these factors:
— signal propagation time between nodes;

— the timing reference accuracy at various nodes;
— moderator changes resulting in a change in the cable distance or signal propagation time
between moderator and non-moderator nodes.
NOTE 1 A typical moderator change occurs as follows: At some random time the previous moderator is
disconnected from the cable, loses power, or stops transmitting moderators for some other reason. Two NUTs
(sometimes three) pass during which no moderator DLPDUs are transmitted. The new moderator transmits its first
moderator DLPDU in the guardband of the third NUT since it last received a valid moderator DLPDU.
NOTE 2 In the event that the previous moderator was lost near the time that the moderator DLPDU was being
transmitted it may be possible that the new moderator received the last moderator DLPDU from the previous
moderator, while other nodes may not have received the last moderator DLPDU. It is therefore required that nodes
tolerate an interval of 4 NUTs between reception of valid moderator DLPDUs.
8.2.3 Moderator change
In the requirements which follow, the term “moderator change” shall be interpreted by a non-
moderator node as:
— reception of a valid moderator DLPDU from the original moderator node

— a time interval of up to 4 NUTs during which no valid moderator DLPDUs are received
— reception of a valid moderator DLPDU from a second moderator node
8.2.4 NUT timing
8.2.4.1 Tone
A network update time (NUT) for a node shall begin at a point in time called the tone, and
shall end at the next tone.
NOTE The times specified in this subclause assume a perfectly accurate clock. Any permitted inaccuracy is
explicitly included in the requirements. Sources of inaccuracy may include firmware delay, hardware delay, and
local crystal inaccuracy. Since some of the time range requirements do not explicitly specify the clock accuracy
tolerance, implementations should provide that internal timers are set such that the requirements are met.
8.2.4.2 Clock accuracy
The timing specifications for PhL Signalling to support the tone and NUT precision shall be as
defined in Table 106.
Table 106 – PhL timing characteristics
Specification Limits / characteristics Comments
Data Rate 5 Mbit/s ± CA also called M_Symbol rate, data “zero” or “one”
Bit Time 200 ns ± CA also called M_Symbol time, data “zero” or “one”
PhL symbol time 100 ns ± CA also called Phy_Symbol time, see data encoding rules
Clock Accuracy (CA) ± 150 parts/million including temperature, long term, and short term
maximum stability
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 161 –
8.2.4.3 Restriction on NUT_length
The maximum value of NUT_length shall be 10 000 (100 ms). The minimum value
NUT_length shall ensure that each NUT allows a maximum length unscheduled Lpacket to
be sent after the scheduled Lpackets have been sent.
NOTE For example, with no scheduled connections, the minimum value of NUT_length is about 1 ms.
8.2.4.4 Moderator node timing
The moderator node shall begin a new NUT at (NUT_length × 10 μs) ± CA after the previous
tone. The reception of a valid or invalid DLPDU shall not affect the timing of the transmission
of the moderator DLPDU by the moderator node.
The moderator node shall begin transmission of the moderator DLPDU at (NUT_length –
gb_center) × 10 μs ± CA after the tone.
8.2.4.5 Non-moderator node timing
A non-moderator node shall begin a new NUT at (gb_center × 10 - 40 ± 2) μs after the last
M_Symbol of the end delimiter of any valid received moderator DLPDU. A non-moderator
node shall begin a new NUT at (NUT_length × 10) μs ± CA after the previous tone if a valid
moderator DLPDU is not received in the current NUT.
Every non-moderator node shall receive and process any valid moderator DLPDU which
begins between (tone + 20) μs and (tone + (NUT_length × 10 - 30) μs ± CA).
8.2.4.6 Post-tone silence
No DLPDUs shall be transmitted between the tone and 20 μs after the tone.
8.2.4.7 Pre-tone silence
No DLPDU shall be transmitted, except the moderator DLPDU, that does not terminate before
((NUT_length - gb_prestart) × 10 + 11,2) μs ± CA after the tone.
The value of gb_prestart shall provide that the blanking time after the last non-moderator
DLPDU transmitted by any node and received by any other node expires before the start of the
guardband in the receiving node. This condition shall also be met during a moderator change.
8.2.4.8 Guardband start
The guardband shall start at (NUT_length - gb_start) × 10 μs ± CA after the tone.
The value of gb_start shall provide that any node shall observe the start of the moderator
DLPDU no earlier than ((NUT_length - gb_start) × 10 + 20) μs ± CA after the previous
tone in that node. This condition shall be met during a moderator change.
8.2.4.9 Guardband center
The value of gb_center shall provide that any node shall observe the end of the moderator
DLPDU no later than (NUT_length × 10 - 40) μs ± CA after the tone. This condition shall
also be met during a moderator change.
8.2.4.10 Useable time

--`,,```,,,,````-`-`,,`,,`,`,,`---
Every node shall receive and process any valid DLPDU that begins between (tone + 20 μs) and (tone
+ (NUT_length - gb_start) × 10 μs ± CA), except that reception of a valid or invalid DLPDU shall
not affect the timing of the transmission of the moderator DLPDU by the moderator node.

– 162 – 61158-4-2 © IEC:2007(E)
8.2.5 Slot timing
8.2.5.1 Slot time
In the following description, the slots shall be numbered sequentially. The value of slotTime
shall provide that a DLPDU transmitted in slot N is received in slot N at all other nodes
assuming worst case conditions of
— crystal drift;
— signal propagation delay between nodes;
— MAC ID assignment;
but excluding noise events.
8.2.5.2 First slot
Scheduled slot 0 shall begin at 20 μs after the tone.
8.2.5.3 Missing node
If no DLPDU is sent or received during slot N-1, slot N shall begin at slotTime × 1 μs ± CA
after the beginning of slot N-1.
8.2.5.4 Restarting the slot timer
If a DLPDU is sent or received during slot N-1, slot N shall begin no later than 6,0 μs after the
last M_Symbol of the end delimiter of the DLPDU. If a damaged DLPDU, with
ph_status_indication not equal to Normal, is received during slot N-1, slot N shall begin
no later than 6,0 μs after ph_lock_indication goes FALSE.
8.2.5.5 Node turn around time
If both node N-1 and node N transmit in their respective slots, node N shall begin transmitting
between 11,2 μs and 12,8 μs after the last M_Symbol of the end delimiter of the DLPDU
transmitted by node N-1.
8.2.5.6 Beginning transmission after missed node
If node N-1 does not transmit in its slot, and node N is enabled to transmit in its slot, node N
shall begin transmitting no earlier than the start of slot N, and no later than 6,8 μs after the
start of slot N.
NOTE The major factor to consider here is crystal drift. In the worst case, where there are two nodes attached to
the network at MAC IDs 0 and 99, SMAX=98, UMAX=99, and USR=1, there can be a silence of 196 slot times
between the scheduled DLPDU transmitted by node 0 and the unscheduled DLPDU transmitted by node 99. If node
99 has a fast crystal and node 0 has a slow crystal, or vice versa, the value of slotTime should be adequate to
guarantee that, when node 99 transmits, node 0 agrees that the current slot is 99.
8.2.6 Blanking
The value of blanking shall be 6.
8.2.7 Example implementation (informative)
The requirements in 8.2.4, 8.2.5 and 8.2.6 are met (not optimally) in the following example
program which calculates the link parameters:
#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>
#define roundup(x,y) (((x) - 1L) / (y) + 1L) /* Round up integer division */
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 163 –
#define F_TURN 16060L /* ns for firmware turnaround and detect */

#define B_TURN 5720L /* ns extra turnaround with large blanking value */
#define NULLFRAME 7L /* octets for length of a null Lpacket transmission */
#define DELAY 4110L /* ns per 1000 meters cable delay */
#define RPT_DLY 815L /* ns per repeater delay */
#define PPMT 1500L /* Max crystal error in tenths of PPM = +/- 150,0 ppm */
#define MODBEFORE 2 /* min moderator overhead before Lpacket (housekeeping)*/
#define MODRECOV 3 /* worst case min moderator overhead after any Lpacket */
#define MODTIME 5 /* ticks for the moderator plus error recovery if bad */
#define MINUNSCHED 850 /* minimum unscheduled time */
int main(int argc, char **argv)

{
/* Default values for command line input parameters. These are
* arbitrarily chosen for our typical convenient network sizes.
*/
int dest = 0xff;
int board = -1; /* If -1 use driver, else use XT version TX */
int redund = 3; /* Unspecified. Later code defaults to 3 */
long NUT_time = 10000L;
int length = 1000;
int smax = 7;
int umax = -1;
int repeater = 0;
int blank = 6;
int maxfrm = 255;
int intmod = 256;
int terse = 0;
int listenonly = 0;
int noleds = 0;
/* Other derived variables. */
int gap;
long drift;
long prop;
long turn;
long bslot;
long slot;
long picodev;
int center;
int start;
int prestart;
long unscheduled;
long nuttenth;
int nuthigh;
int nutlow;
char txhead[7];
char *a;
/* Parse arglist */
argc--;
argv++;
if(argc==0)
{
argc=1;
argv[0]="-h";
} --`,,```,,,,````-`-`,,`,,`,`,,`---
while(argc && (a=&argv[0][0],*a++=='-'))

{
while(*a)switch(*a++)
{
case 'x' :
board = atoi(a);
if ((board < 0) || (board > 3))
{
printf("%%ERROR -- 0 <= board number <= 3.\n");
return(1);
}
goto nextarg;
case 'l':
listenonly = 128;
break;
case 'n':
noleds = 64;
break;
case 'b':
redund = 1;
break;
case 'a':
redund = 2;
break;
case 'r':
redund = 3;

– 164 – 61158-4-2 © IEC:2007(E)
break;
case 't':
terse = 1;
break;
case 'h' :
default:
printf("Compute and print a net config Lpacket.\n\n");
printf("NETCONF [-abdhlnrt] [-x<board>] [0x<dest>]”
” [<NUT time> [<length> [<smax>\n");
printf(" [<umax> [<repeaters> [<blanking> [<maxframe> “
”[<int modulus>]]]]]]]]\n");
return(1);
}
nextarg: argc--;
argv++;
}
/* Check for network address option */

if (argc && argv[0][0] == '0' && argv[0][1] == 'x')
{
sscanf (argv[0],"%i",&dest);
if ((dest < 0) || (dest > 255))
{
printf("%%ERROR -- 0x00 <= destination address <= 0xff.\n");
return(1);
}
argc--;
argv++;
}
/* Parse remaining arguments.

*/
switch (argc)
{
case 8: intmod = atoi(argv[7]);
case 7: maxfrm = atoi(argv[6]);
case 6: blank = atoi(argv[5]);
case 5: repeater = atoi(argv[4]);
case 4: umax = atoi(argv[3]);
case 3: smax = atoi(argv[2]);
case 2: length = atoi(argv[1]);
case 1: NUT_time = atol(argv[0]);
}
/* check the validity of all the arguments */

if ((intmod < 1) || (intmod > 256))
{
printf("%%ERROR -- 1 <= interval count modulus <= 256.\n");
return(1);
}
if ((maxfrm < 0) || (maxfrm > 255))
{
printf("%%ERROR -- 0 <= max scheduled frame <= 255.\n");
return(1);
}
if ((blank < 0) || (blank > 255))
{
printf("%%ERROR -- 0 <= blanking <= 255.\n");
return(1);
}
if (repeater < 0)
{
printf("%%ERROR -- number repeaters >= 0.\n");
return(1);
}
if ((smax < 0) || (smax > 254))
{
printf("%%ERROR -- 0 <= max scheduled addr <= 254.\n");
return(1);
}
if (length < 0)
{
printf("%%ERROR -- cable length >= 0.\n");
return(1);
}
if ((NUT_time < 350L) || (NUT_time > 100000L))
{
printf("%%ERROR -- 350 <= nut time <= 100,000.\n");
return(1);
}
if (umax == -1) umax = smax;
if ((umax < smax) || (umax > 254))
{
printf("%%ERROR -- smax <= umax <= 254.\n");
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 165 –
return(1);
}
if (NUT_time%10!=0)
{
printf("%%ERROR -- NUT length is specified in 10 μs intervals.\n");
return(1);
}
/* Gap is the number of slot times that can pass in the normal
protocol between transmissions.
When smax<umax,then the maximum silence equals smax + umax – 1.
The maximum silence occurs on the network with smax<umax when
the first node is at 0, the only other is at umax with the USR==1.
To illustrate a transmit sequence example when smax<umax,

set smax=4 and umax=5, USR==1, with two nodes at 0 and 5.
Slot times -> ssssuuuu -> (smax + umax – 1)
--`,,```,,,,````-`-`,,`,,`,`,,`---
01234123450
When smax=umax, then the maximum silence equals smax + umax – 2.
The maximum silence occurs on the network with smax = umax when
the first node is at 0, the only other is at 1 with the USR===2.
To illustrate a transmit sequence example when smax=umax,
set smax=umax=5, USR==2, with two nodes at 0 and 1.
Slot times -> ssssuuuu -> (smax + umax – 2)
012345234501
Units: slot times

*/
gap = (smax < umax) : smax + umax - 1 : smax + umax - 2;
if (gap < 0) gap = 0;
/* the drift is a correction factor needed to compensate for

the amount of time that the fastest and slowest nodes drift
apart during the longest silence due to crystal inaccuracy.
Actual drift factor = (1-(2*gap+1)(ppm)) / (1-ppm^2)
however, ppm^2 is so small it may be ignored.
Units: unitless factor scaled by micro/pico
*/
drift = roundup(10000000L - (long)(2*gap+1) * PPMT , 10L);
/* Prop is the time the signal takes to travel down the cable and
work its way through all the repeaters and modems. It assumed
on even a cable system that has no repeater boxes, that two
two repeater exist to allow nodes connected via the NAP.
Units: ps
*/
prop = (long)(length)*DELAY + (long)(repeater+2)*RPT_DLY*1000L;
/* turn is:
- the amount of time it takes for the DLL to respond to a

transmission, that is, - the time from the end of the end delimiter
to the start of the preamble
plus
- the time is takes another DLL to detect that the first *has*
responded, that is, - the time from the start of the preamble to the
end of the start delimiter.
Units: ns
*/
/* turnaround could be */
turn = (long)(blank)*1600L + B_TURN; /* <-- blanking constrained */
if (turn < F_TURN) turn = F_TURN; /* <-- or firmware constrained */
/* bslot is the ideal slot time - which is usually defined as

2 props + turnaround + detect (note that in this case, the
detect time and the turn time are combined)
Units: ps
*/
bslot = 2*prop + (turn*1000L);
/* slot is the ideal slot time adjusted to account for variances in
crystal frequency.
Units: µs

– 166 – 61158-4-2 © IEC:2007(E)
*/
slot = roundup(bslot , drift);
if ((slot < 1L) || (slot > 256L))
{
printf("%%ERROR -- Slot time is large, reduce network complexity. \n");
return(1);
}
/* Calculate guardband parameters (round up to a multiple of a 10 µs tick clock).*/
/* calc nut time - units: 10 usec ticks */

nuttenth = roundup(NUT_time,10L);
/* picodev is the amount the clocks of the slowest and fastest
node drifts apart during four NUTs
Units: ps
*/
picodev = nuttenth * PPMT * 8L;
/* center is the time before the next tone that the moderator
begins transmitting the moderator DLPDU. This includes adjustments
for clock drift during up to 4 NUTs, plus a moderator switchover
from a near to a far node.
Unit: 10 usec ticks
*/
center = MODTIME + MODRECOV +
(int)roundup(picodev + 2*prop , 10000000L);
/* start is the time before the next tone that the guardband starts.
Unit: 10 usec ticks
*/
start = center + MODBEFORE +
(int)roundup(picodev , 10000000L);
/* prestart is the time before the next tone beyond which nodes may not
transmit. Due to clock skew and other factors a transmission which
is sent such that it ends just at prestart may actually be received
by another node such that the transmission ends just as the guardband
starts. The prestart margin is required in order to ensure that
transmissions from slow nodes do not cross over into the guardbands
of faster nodes.
Unit: 10 usec ticks
*/
prestart = (int)roundup((nuttenth*PPMT*2L) + ((NULLFRAME+blank)*1600000L)
+ bslot , 10000000L) + start;
/* Determine if nut parameters is practical and print warnings.
* Initial calculations are conservative due to roundup of several
* parameters. Usage of fixround helps correct it.
*/
/* calc the max length of unscheduled time assuming that all
scheduled nodes are silent.
Units: µs
*/
unscheduled = NUT_time - max(roundup(NULLFRAME*1600000L+prop+turn*1000L,
1000000000L),slot)*(long)(smax+1)
- (long)(prestart)*10L;
if (unscheduled < MINUNSCHED)
printf("%%WARNING -- Not enough scheduled time available. Increase nut
time.\n");
/* Print statistics and the transmit command.
*/
nutlow = nuttenth & 0xff;
--`,,```,,,,````-`-`,,`,,`,`,,`---
nuthigh = (nuttenth >> 8) & 0xff;

if(!terse)
{
long deviation = roundup(picodev , 1000000L);
printf("slot = %ld usec, max unscheduled time = %ld usec\n",
slot,unscheduled);
printf("dev = %ld usec, prestart = %d ticks, start = %d ticks, center = %d
ticks\n",
deviation,prestart,start,center);
}
if (board == -1) sprintf(txhead,"tx");
else sprintf(txhead,"txt /%d",board);
printf( "%s m a 17 %02x %02x %02x %02x %02x %02x %02x “
”%02x %02x %02x %02x %02x %02x 00 00 00\n",
txhead,dest,nutlow,nuthigh,smax,umax,(int)slot-1,blank,
start,center,(listenonly|noleds|redund),maxfrm,intmod-1,prestart);
return(0);
}

61158-4-2 © IEC:2007(E) – 167 –
9 Detailed specification of DL components
9.1 General
This clause specifies each main functional component of the DL internal architecture as
shown in Figure 2 using the modeling language of 6.1.
9.2 Access control machine (ACM)
The Access Control Machine (ACM) shall control the sequencing of transmissions by this
node.
// ACM State Machine Description
/////////////////////////////////////////////////////////////////////////////
// constant and type definitions
//
// generic type and constant definitions
//
typedef enum {FALSE=0, TRUE=1} BOOL;
//
// protocol constants
//
#define LOWCOUNTINIT 2 // NUTs as lowman before switchover to moderator
#define MODERATOR_LENGTH 40 // length of the moderator DLPDU in usec
#define TXDUPCHECKS 3 // moderators that have to be heard before transmit at
powerup
#define TXNOMOD 5 // number of missed moderators before disabling transmit
#define DEAFNESS 5 // number of missed moderators before adjusting phase
#define DEAFADJUST 5 // 10 usec ticks to slip NUT if deafness is detected
#define LONELYINIT 8 // NUTs that are tolerated without hearing anything
// before becoming lonely (should be longer than DEAFNESS
// to ensure time for deaf recovery)
/////////////////////////////////////////////////////////////////////////////
// Lpacket definition
//
// Lpacket constants: masks for control octet
//
#define TAGPAD 2
#define DATAPAD 4
//
// moderator Lpacket constants
//
#define MODERATOR_SIZE 9 // moderator Lpacket size octet (in 16 bit words)
#define MODERATOR_CTL 1 // moderator Lpacket ctl octet (fixed tag)
#define MODERATOR_TAG 0 // moderator Lpacket service octet
//
// Lpacket class
//
class Lpacket
{
public:
USINT size; // the size octet
USINT ctl; // the ctl octet
int tag_pad(void)
{
}
int data_pad(void)
{
}
// return the size of the Lpacket (in octets)
int wire_size(void)
{
}
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 168 – 61158-4-2 © IEC:2007(E)

BOOL abort(void);
};
//
// fixed tag Lpacket (two octet tag)
//
class fixedLpacket : public Lpacket
{
public:
USINT service;
USINT dest;
};
//
// moderator fixed tag Lpacket
//
{
public:
UINT NUT_length;
USINT smax;
USINT umax;
USINT slotTime;
USINT blanking;
USINT gb_start;
USINT gb_center;
USINT usr;
USINT modulus;
USINT tMinus;
USINT gb_prestart;
USINT spare;
};
/////////////////////////////////////////////////////////////////////////////
//
// internal VARIABLES
//
// unless otherwise specified, all variables are initialized to zero at powerup
int tmp;
USINT interval_count; // counts how many NUTs have passed (0 – modulus)
USINT itr; // implicit token register - tracks which MAC should xmit
USINT usr; // unscheduled start register -- first unscheduled token
USINT tMinus; // countdown to synchronized change
USINT lowcount; // how many times have I been lowman?
USINT modcount; // counts moderators (or missed moderators) depends on netState
USINT modcountinit; // how many NUTs to check for dupnode
USINT nqlowman; // optimistic lowman detector
USINT qlowman; // pessimistic lowman detector
USINT lonely; // how many NUTs have I been lonely
--`,,```,,,,````-`-`,,`,,`,`,,`---
USINT deafcount; // number of times moderator apparently occurred during deaf

period
BOOL in_guardband; // TRUE during the guardband
BOOL dupflag; // edge detector for dupnode
BOOL scheduled; // scheduled/unscheduled part of the NUT
UINT octetsleft; // octets / octets left before end of current transmitted DLPDU
USINT macSrce; // source MAC ID for the current DLPDU
USINT currentMod; // the current moderator
moderatorLpacket moderator; // buffer for moderator Lpackets
enum { OFFLINE,
WATCH,
DUPCHECK,
NOTMOD,
MOD,
ROGUE,
DUPNODE
} netState; // connection state
/////////////////////////////////////////////////////////////////////////////
// timer definition
//
// various behaviors for timers
typedef enum {ONCE_UP, ONCE_DOWN, REPEAT_UP, REPEAT_DOWN} timer_mode;
class timer
{
public:
float count; // number of ticks left
float preset; // init ticks, or cycle length

61158-4-2 © IEC:2007(E) – 169 –
BOOL expire; // latched flag when timer expires

timer_mode mode;
// constructor: defines mode

timer(timer_mode m)
{
mode = m;
}
void restart(void)
{
// if counting down, start with preset
if(mode == REPEAT_DOWN || mode == ONCE_DOWN)
{
count = preset;
}
else
{
count = 0; // else start from zero
}
// start counting (implementation not specified)
}
void start(float interval) // start counting down from interval towards zero
{
mode = ONCE_DOWN;
preset = interval; // set interval
restart(); // start counting
}
void begin_counting(void) // start counting up from zero

{
mode = ONCE_UP;
restart();
}
bool expired(void) // returns true if the timer has expired; clears flag
{
BOOL tmp;
tmp = expire;
expire = 0;
return tmp;
}
};
//
// time conversion factors
//
#define usec
#define msec *1000
#define sec *1000000
//
// define the timers used by the ACM
//
class timer gen_timer(ONCE_DOWN); // general purpose, in several places
class timer slot_timer(REPEAT_DOWN); // used for response time-out between messages
class timer watch_timer(ONCE_DOWN); // used for watch time state
class timer NUT_timer(REPEAT_DOWN); // this generates the NUT timing
class timer holdoff_timer(ONCE_DOWN); // holds off transmit for a timer after
transmit or receive
/////////////////////////////////////////////////////////////////////////////
//
// interface to PhL
//
BOOL ph_lock_indication; // optimistic DLPDU detect (clock recovery is tracking)
--`,,```,,,,````-`-`,,`,,`,`,,`---
BOOL ph_frame_indication; // pessimistic DLPDU detect (Manchester valid since the SD)
/////////////////////////////////////////////////////////////////////////////
//
// interface to Deserializer
//
BOOL RX_dataReady; // an octet of a DLPDU is available
USINT RX_rxData; // octet most recently received from DLPDU (source MAC ID)
BOOL RX_endMAC; // the end delimiter has been detected
BOOL RX_FCSOK; // FCS on last DLPDU was OK
BOOL RX_abort; // abort received on last DLPDU

– 170 – 61158-4-2 © IEC:2007(E)
/////////////////////////////////////////////////////////////////////////////
//
// interface to RxM
//
BOOL RX_receivedLpacket; // an Lpacket has been received
moderatorLpacket RX_Lpacket; // the Lpacket most recently received
/////////////////////////////////////////////////////////////////////////////
//
// interface to transmitter (TxM)
//
void TX_sendHeader(USINT myaddr); // send preamble, SD, source MAC ID
void TX_sendLpacket(Lpacket &lp); // send an Lpacket
void TX_sendTrailer(void); // send FCS, ED
BOOL TX_headerComplete; // header has been sent
BOOL TX_LpacketComplete; // Lpacket has been sent
BOOL TX_trailerComplete; // trailer has been sent
BOOL TX_abort; // DLPDU was aborted
/////////////////////////////////////////////////////////////////////////////
//
// interface to LLC
//
Lpacket LLC_Lpacket; // shared variable between LLC and ACM containing the
Lpacket
BOOL LLC_pickLpacket (BOOL scheduled,
UINT octetsLeft);// tell LLC to pick an Lpacket for transmission
LLC_LpacketSent(void); // tell LLC that the Lpacket was sent
/////////////////////////////////////////////////////////////////////////////
//
//
//
// various events that can be reported to SM
//
typedef enum
{
DLL_EV_rxGoodFrame,
DLL_EV_txGoodFrame,
DLL_EV_badFrame,
DLL_EV_errA,
DLL_EV_errB,
DLL_EV_txAbort,
DLL_EV_NUT_overrun,
DLL_EV_dribble,
DLL_EV_nonconcurrence,
DLL_EV_rxAbort,
DLL_EV_lonely,
DLL_EV_dupNode,
DLL_EV_noisePulse,
DLL_EV_collision,
DLL_EV_invalidModAddress,
DLL_EV_rogue,
DLL_EV_deafness,
DLL_EV_supernode,
}event;
extern void DLL_event(event ev, int opt=0); // report an event
extern void DLL_currentMod_indication(USINT macID);
extern void DLL_tminus_zero_indication(void);
extern void DLL_online_confirm(BOOL en);
extern void DLL_listen_only_confirm(BOOL en);
extern void DLL_tone_indication(USINT NUT_count);
{
public:
USINT myaddr;
UINT NUT_length;
USINT smax;
USINT umax;
USINT slotTime;
USINT blanking;
USINT gb_start;
USINT gb_center;
USINT modulus;
USINT gb_prestart;
};
--`,,```,,,,````-`-`,,`,,`,`,

61158-4-2 © IEC:2007(E) – 171 –
// interface to DLL management interface

extern DLL_config_data DLL_SM_pending;
extern DLL_config_data DLL_SM_current;
extern BOOL SM_powerup;
extern BOOL SM_mod_enable; // state of mod_enable
extern BOOL SM_online; // state of on-line/off-line
extern BOOL SM_online_req; // pending state of on-line/off-line
extern BOOL SM_listen_only; // listen only state
extern BOOL SM_listen_only_req; // pending listen only state
/////////////////////////////////////////////////////////////////////////////
//
// subroutines
//
//
// take care of common processing for network parameter changes
//
void handle_net_change(void)
{
if(SM_listen_only != SM_listen_only_req) // handle completion of listen_only
change
{
SM_listen_only = SM_listen_only_req;
DLL_listen_only_confirm(SM_listen_only);
}
if(tMinus==1) // handle completion of synchronized change
{
tMinus = 0;
DLL_tminus_zero_indication();
}
}
//
// maintenance work done whenever the moderator is received
//
void processModerator(moderatorLpacket &moderator)
{
//
// copy data from the moderator
// which cannot cause a rogue condition
//
interval_count = moderator.interval_count;
usr = moderator.usr;
tMinus = moderator.tMinus;
lowcount = LOWCOUNTINIT; // re-initialize lowman counter

// resynchronize the NUT timer to the moderator
NUT_timer.count = DLL_SM_current.gb_center - MODERATOR_LENGTH/10;
if(netState == MOD) // if this node is moderator
{ // and a moderator was received!
netState = NOTMOD; // drop moderatorship
modcount = 0; // init count of missing moderators
DLL_event(DLL_EV_nonconcurrence); // indicate non-concurrence
}
else
{
if(!in_guardband) // unexpected moderator
{
DLL_event(DLL_EV_nonconcurrence); // indicate non-concurrence
}
if(netState == WATCH) // got moderator, there is a network

{
netState = DUPCHECK; // go check for dupnodes
modcount = modcountinit; // this is how many NUTs to check
}
else if(netState == DUPCHECK) // if checking for duplicate MAC IDs
{
if(SM_listen_only == FALSE) // unless this node is required to
{ // remain in this state
modcount--; // decrement NUT counter
if(modcount == 0) // when done
{
netState = NOTMOD; // it's OK to go transmit
}
}
}
else if(netState == ROGUE) // a rogue that sees a good moderator
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 172 – 61158-4-2 © IEC:2007(E)
{
netState = DUPCHECK; // can exit rogue state
modcount = modcountinit;
}
else
{
modcount = 0; // else just reset mod counter
}
}
}
//
// recovery after a time-out while waiting for moderator
//
void missed_moderator(void)
{
if(netState == NOTMOD) // if supposed to be on-line and hearing moderators
{
modcount++; // count consecutive missing moderator
if(modcount >= TXNOMOD) // if exceeded limit
{
netState = DUPCHECK; // change to a quietly waiting mode
modcount = 1; // init mods required before return on-line
}
if(SM_listen_only == FALSE // if allowed to transmit
&& SM_mod_enable == TRUE // and allowed to be moderator
&& DLL_SM_current.myaddr <= nqlowman) // and apparently the lowman
{
lowcount--; // count consecutive NUTs as lowman
if(lowcount == 0) // if this is the second time
{
netState = MOD; // then activate the moderator on third NUT
}
}
else
{
lowcount = LOWCOUNTINIT; // otherwise, re-initialize lowman counter
}
}
}
//
// housekeeping actions at the end of each NUT
//
void housekeeping(void)
{
if(netState == WATCH) // in watch state
{
lonely = LONELYINIT; // hold the lonely counter reset
if(watch_timer.count == 0) // if timed out (no moderators)
{ // change to on-line -- try to build a link
if (SM_listen_only == FALSE // if allowed to transmit
&& SM_mod_enable == TRUE // and allowed to moderate
&& nqlowman == DLL_SM_current.myaddr) // and lowman
{
netState = MOD; // activate moderator state
}
else
{
netState = DUPCHECK; // else wait for another node to moderate
modcount = modcountinit;
}
}
}
--`,,```,,,,````-`-`,,`,,`,`,,`---
else if (qlowman == 255 // no good FCS received in the last NUT

&& DLL_SM_current.myaddr != 0 // local node is not supernode
&& netState != WATCH) // not already in the watch state
{
lonely--;
if(lonely == 0 || netState == ROGUE || netState == DUPNODE)
{
DLL_event(DLL_EV_lonely);
if(netState == ROGUE)
{
watch_timer.start(0,75 sec);
}
else
{
}
netState = WATCH;
}

61158-4-2 © IEC:2007(E) – 173 –
}
else
{
lonely = LONELYINIT;
}
if(deafcount >= DEAFNESS)
{
deafcount = 0;
DLL_event(DLL_EV_deafness);
NUT_timer.count += DEAFADJUST;
}
// this counter determines how many NUTS a node should
// check the link before deciding that it is not
// a dupnode. if 0<myaddr<=SMAX a node is guaranteed to
// an access each NUT, so the check time is low. On the
// other hand, if smax<myaddr<=umax, a node might have to wait
// a long time for its access slot come up, so use a long
// time. If a DUPCHECKing unscheduled only node ever sees its slot
// go by, it sets modcount to a lower number immediately.
// nodes between SMAX and UMAX aren't guaranteed to get a slot every NUT
// if not an unscheduled only node, use a low number else use a huge number
if (DLL_SM_current.myaddr > DLL_SM_current.smax)
modcountinit = TXDUPCHECKS;
else
modcountinit = 255;
// update the interval count once per NUT

interval_count = (interval_count + 1) % DLL_SM_current.modulus;
// update the usr once per NUT
usr = (usr + 1) % (DLL_SM_current.umax + 1);
}
/////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////////////
//
// The ACM State Machine
//
state: powerup
event: SM_powerup
destination: offline
//
// be idle until told to go on-line
//
state: offline
// normal case
event: SM_online == TRUE
condition: ph_frame_indication == FALSE
destination: rxMod0
action:
in_guardband = TRUE; // start up at the beginning of a guardband
if(DLL_SM_current.myaddr == 0) // either local node is supernode
{
netState = MOD;
SM_listen_only = FALSE;
}
else // or not a supernode
{
netState = WATCH;
}
scheduled = FALSE;
in_guardband = TRUE;
DLL_online_confirm(SM_online);
// exception: there was an Lpacket on the wire at transition to on-line

event: SM_online == TRUE
condition: ph_frame_indication == TRUE
destination: badMod // treat it as an error inside the guardband
action:
DLL_event(DLL_EV_badFrame,macSrce);
if(DLL_SM_current.myaddr == 0)
{
netState = MOD;
SM_listen_only = FALSE;
}
else
{
netState = WATCH;
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 174 – 61158-4-2 © IEC:2007(E)
}
//
// wait for either energy on the wire or a slot time-out
//
state: waitFrame
event: ph_lock_indication == TRUE
destination: frEst1
action: gen_timer.begin_counting();
event: slot_timer.expired()
destination: gap
action: gen_timer.start(0,6 usec);
//
// wait for frame start, or noise
//
state: frEst1
event: ph_frame_indication == TRUE
destination: rxFrame
event: ph_lock_indication == FALSE // short energy burst == noise blip
destination: waitFrame
action: DLL_event(DLL_EV_noisePulse); // ignore it
event: gen_timer.count >= 8,0 usec
destination: frEst2
//
// continue waiting
//
state: frEst2
event: ph_lock_indication == FALSE // longer burst treat as a damaged DLPDU
destination: endFrame
action:
gen_timer.start(5,2 usec);
event: gen_timer.count >= 11,2 usec // energy this long with no data start
destination: endFrame // treat as bad DLPDU, no start delimiter
action:
//
// wait here for there to be no detectable energy on the wire (no clock lock)
//
state: endFrame
event: ph_lock_indication == FALSE

destination: gap
action:
slot_timer.restart();
//
// simulate first half of node turnaround time with this timing gap
//
state: gap
event: ph_frame_indication == TRUE // DLPDU start overrides all
event: gen_timer.expired() // process the rest of
destination: nextSlot
action:
gen_timer.start(6,1 usec); // start second half of turnaround
--`,,```,,,,````-`-`,,`,,`,`,,`---
if(scheduled) // do implicit token rotation, scheduled

{
itr++;
if(itr>DLL_SM_current.smax) // after SMAX,
{ // change from scheduled to unscheduled
itr=usr;
scheduled = FALSE;
}
}
else // implicit token rotation, unscheduled
{

61158-4-2 © IEC:2007(E) – 175 –
itr = (itr + 1) % (DLL_SM_current.umax + 1);

}
//
// decide what comes next
//
state: nextSlot
event: ph_frame_indication == TRUE // detect a DLPDU start at all times
// time for the guardband
event: gen_timer.expired()
condition: NUT_timer.count < DLL_SM_current.gb_prestart
destination: guardBand
action:
// scheduled time not completed -- log the error and proceed
if(scheduled == TRUE)
{
DLL_event(DLL_EV_NUT_overrun);
scheduled = FALSE;
}
// not this node's slot, keep counting.
// Note that the slot timer auto repeats to maintain regular slot intervals
condition: NUT_timer.count >= DLL_SM_current.gb_prestart
&& itr != DLL_SM_current.myaddr
// this node's slot, but not allowed to talk
&& itr == DLL_SM_current.myaddr
&& !(netState == MOD || netState == NOTMOD)
action: modcount = min(modcount, TXDUPCHECKS); // optimize dupcheck
// this node's slot, and allowed to talk
&& itr == DLL_SM_current.myaddr
&& (netState==MOD || netState==NOTMOD)
destination: waitForHold
//
// a DLPDU has started, this deals with the data
//
state: rxFrame
// prematurely lost the DLPDU event
event: ph_frame_indication == FALSE
action:
// start hold timer after line is quiet

holdoff_timer.start((DLL_SM_current.blanking+1) * 1,6 usec);
// duplicate node condition

event: RX_dataReady
condition: RX_rxData == DLL_SM_current.myaddr
destination: dupNode
action:
--`,,```,,,,````-`-`,,`,,`,`,,`---
macSrce = RX_rxData;
nqlowman = min(nqlowman,macSrce);
// record the source MAC ID
event: RX_dataReady
condition: RX_rxData != DLL_SM_current.myaddr
destination: nextLpacket
action:
//
// start here to parse each new Lpacket
// the RxM delivers one complete Lpacket at a time
//
state: nextLpacket
// received an out-of-sequence moderator -- attempt resync
event: RX_receivedLpacket
condition: RX_Lpacket.service == MODERATOR_TAG
destination: rxMod3 // unexpected moderator

– 176 – 61158-4-2 © IEC:2007(E)
// ignore most other received Lpackets

condition: RX_Lpacket.service != MODERATOR_TAG
destination: nextLpacket
// lost the DLPDU in the middle
action:
// the DLPDU was aborted
event: RX_abort
action:
DLL_event(DLL_EV_rxAbort);
// if bad FCS, or DLPDU extended into the guardband, treat as bad DLPDU
event: RX_endMAC
condition: NUT_timer.count <= DLL_SM_current.gb_start || !RX_FCSOK
action:
// good DLPDU, and not guardband time
// use the source ID
event: RX_endMAC
condition: NUT_timer.count > DLL_SM_current.gb_start && RX_FCSOK
action:
qlowman = min(qlowman, macSrce);
DLL_event(DLL_EV_rxGoodFrame);
if(itr != macSrce) DLL_event(DLL_EV_nonconcurrence);
itr = macSrce;
//
// deal with a duplicate node indication, local MAC ID already in by another node
//
state: dupNode
// bad DLPDU so ignore indication
action:
// bad DLPDU so ignore indication
event: RX_endMAC
condition: !RX_FCSOK
action:
// good DLPDU so accept the duplicate indication

event: RX_endMAC
condition: RX_FCSOK
action:
netState = DUPNODE;
if (!dupflag)
{
dupflag == TRUE;
DLL_event(DLL_EV_dupNode);
}
//
// Hold off transmission until blanking + 1 octet has expired
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 177 –
// since the last transmit or receive. It is possible that the

// hold timer expires before the gen_timer, dealing with turnaround time.
//
state: waitForHold
// time to transmit, but line has activity, treat it as a collision, and back off.
event: holdoff_timer.expired()
condition: ph_lock_indication == TRUE
action:
DLL_event(DLL_EV_collision);
// no problem, start transmission
event: holdoff_timer.expired()
condition: ph_lock_indication == FALSE
destination: sendHeader
action:
// calculate time remaining in this NUT
tmp = (unsigned)(NUT_timer.count-DLL_SM_current.gb_prestart);
octetsleft = min(255, (tmp<<1) + tmp + (tmp>>3)) * 2;
TX_sendHeader(DLL_SM_current.myaddr);
//
// when header has been sent, start first Lpacket
//
state: sendHeader
// TxLLC has something, send a new Lpacket
event: TX_headerComplete
condition: LLC_pickLpacket(scheduled, octetsleft) == TRUE
destination: sendNextLpacket
action:
TX_sendLpacket(LLC_Lpacket);
octetsleft = octetsleft - LLC_Lpacket.wire_size();
// nothing to send that fits in the time left, close the DLPDU
condition: LLC_pickLpacket(scheduled,octetsleft) == FALSE
destination: sendTrailer
action:
TX_sendTrailer();
if(scheduled // if unable to send all scheduled Lpackets
&& LLC_pickLpacket(scheduled,octetsleft) == TRUE)
{
DLL_event(DLL_EV_dribble);
}
//
// send subsequent Lpackets
//
state: sendNextLpacket
// TxLLC has something, send a new Lpacket
event: TX_LpacketComplete
condition: LLC_pickLpacket(scheduled,octetsleft) == TRUE
destination: sendNextLpacket
action:
TX_sendLpacket(LLC_Lpacket);
octetsleft = octetsleft - LLC_Lpacket.wire_size();
// nothing to send that fits in the time left, close the DLPDU
condition: LLC_pickLpacket(scheduled,octetsleft) == FALSE
destination: sendTrailer
action:
TX_sendTrailer();
//
// complete DLPDU termination
//
state: sendTrailer
event: TX_trailerComplete
action:
if(TX_abort == TRUE)DLL_event(DLL_EV_txAbort);
else DLL_event(DLL_EV_txGoodFrame);
//
// almost guardband start time, wait for guardband start then check lots of things
//
state: guardBand
event: ph_frame_indication == TRUE // received DLPDU takes precedence

destination: rxFrame // deal with it
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 178 – 61158-4-2 © IEC:2007(E)
// net change not in progress, this node is not moderator

event: NUT_timer.count <= DLL_SM_current.gb_start // guardband start time NOW
condition: tMinus == 0
&& SM_listen_only == SM_listen_only_req
&& netState != MOD
destination: rxMod0
// net change not in progress, this node is moderator AND can remain moderator
event: NUT_timer.count <= DLL_SM_current.gb_start
&& netState == MOD
&& SM_mod_enable == TRUE
&& min(DLL_SM_current.myaddr, qlowman) == DLL_SM_current.myaddr
destination: txMod0
// net change not in progress, this node is moderator, but cannot remain moderator
&& netState == MOD
&& (SM_mod_enable == FALSE
|| min(DLL_SM_current.myaddr, qlowman) != DLL_SM_current.myaddr)
destination: rxMod0
action:
netState = NOTMOD;
modcount = 0;
lowcount = LOWCOUNTINIT;
// net change in progress, this node is not moderator

condition: tMinus > 1 && SM_listen_only == SM_listen_only_req && netState != MOD
destination: rxMod0
action:
tMinus = tMinus - 1;
// net change in progress, this node is moderator, and can remain moderator
condition: tMinus > 1
&& netState == MOD
&& min(DLL_SM_current.myaddr, qlowman) == DLL_SM_current.myaddr
destination: txMod0
action:
// net change in progress, this node is moderator, but cannot remain moderator
condition: tMinus > 1
&& netState == MOD
|| min(DLL_SM_current.myaddr, qlowman) != DLL_SM_current.myaddr)
destination: rxMod0
action:
netState = NOTMOD;
modcount = 0;
// net change complete, this node becomes supernode
condition: tMinus == 1 && DLL_SM_pending.myaddr == 0
destination: txMod0
action:
handle_net_change();
netState = MOD;
SM_listen_only = FALSE; // override listen_only
// net change complete, but shall stop transmitting for a time
condition: ( tMinus == 1
&& DLL_SM_pending.myaddr != 0
&& DLL_SM_pending.myaddr != DLL_SM_current.myaddr
|| SM_listen_only != SM_listen_only_req
&& SM_listen_only)
destination: rxMod0
action:
netState = WATCH; // go to WATCH state
// net change complete, this node is not moderator, no significant changes
&& DLL_SM_pending.myaddr == DLL_SM_current.myaddr
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 179 –
||
SM_listen_only != SM_listen_only_req
&& !SM_listen_only)
&& netState != MOD
destination: rxMod0
action:
// net change complete, this node is moderator, no major changes, and can remain
moderator
&& !SM_listen_only)
&& netState == MOD
&& min(DLL_SM_pending.myaddr, qlowman) == DLL_SM_pending.myaddr
destination: txMod0
action:
// net change complete, this node is moderator, no major changes, but can’t stay
moderator
&& !SM_listen_only)
&& netState == MOD
|| min(DLL_SM_pending.myaddr, qlowman) != DLL_SM_pending.myaddr)
destination: rxMod0
action:
netState = NOTMOD;
modcount = 0;
//
// wait for moderator start
//
state: rxMod0
// got it
destination: rxMod1
// timed out waiting for moderator
event: NUT_timer.count <= 20 usec
destination: waitTone
action:
missed_moderator();
housekeeping();
//
// receive the moderator
//
state: rxMod1
// bad moderator
destination: badMod
action:
// get MAC source ID
event: RX_dataReady == TRUE
destination: rxMod2
action:
//
// continue receiving moderator
//
state: rxMod2
// bad DLPDU
destination: badMod
action:
// bad moderator DLPDU if it's null
event: RX_endMAC
destination: badMod --`,,```,,,,````-`-`,,`,,`,`,,`---

– 180 – 61158-4-2 © IEC:2007(E)
action:
// got an Lpacket, save the Lpacket for later, and go check the rest of the DLPDU
destination: rxMod3
//
// handle the end of a moderator DLPDU
//
state: rxMod3
// bad DLPDU
destination: badMod
action:
// bad DLPDU
event: RX_abort
destination: badMod
action:
DLL_event(DLL_EV_rxAbort);
// bad DLPDU if another Lpacket is in the moderator DLPDU

destination: badMod
action:
// bad DLPDU
event: RX_endMAC
destination: badMod
action:
// dupnode!
event: RX_endMAC
condition: RX_FCSOK && macSrce == DLL_SM_current.myaddr
action:
netState = DUPNODE;
if(!dupflag)
{
dupflag = TRUE;
DLL_event(DLL_EV_dupNode);
}
// good DLPDU, but bad header
event: RX_endMAC
condition: RX_FCSOK
&& macSrce != DLL_SM_current.myaddr
&& ( RX_Lpacket.size != MODERATOR_SIZE
|| RX_Lpacket.ctl != MODERATOR_CTL
|| RX_Lpacket.service != MODERATOR_TAG
|| RX_Lpacket.dest != 0xFF)
destination: badMod
// moderator, but from an incorrect address (not lowman)
event: RX_endMAC
condition: RX_FCSOK
&& RX_Lpacket.size == MODERATOR_SIZE
&& RX_Lpacket.ctl == MODERATOR_CTL
&& RX_Lpacket.service == MODERATOR_TAG
&& RX_Lpacket.dest == 0xFF
&& macSrce > qlowman
action:
DLL_event(DLL_EV_invalidModAddress);
// this is a moderator from a supernode,

// or this node is at 0xFF so that all others look like a supernode
// adopt all the parameters from the moderator
event: RX_endMAC
condition: RX_FCSOK
&& macSrce <= qlowman --`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 181 –
&& (macSrce == 0 || DLL_SM_current.myaddr == 0xFF)

action:
if (macSrce == 0 && currentMod != 0) DLL_event(DLL_EV_supernode);
currentMod = macSrce;
DLL_currentMod_indication(currentMod);
DLL_SM_current.NUT_length = moderator.NUT_length;
DLL_SM_current.gb_prestart = moderator.gb_prestart;
DLL_SM_current.gb_start = moderator.gb_start;
DLL_SM_current.gb_center = moderator.gb_center;
DLL_SM_current.modulus = moderator.modulus;
DLL_SM_current.blanking = moderator.blanking;
DLL_SM_current.slotTime = moderator.slotTime;
DLL_SM_current.smax = moderator.smax;
DLL_SM_current.umax = moderator.umax;
processModerator(moderator);
housekeeping();
// good moderator received, everything matches local copy
// resynchronize and continue
event: RX_endMAC
condition: RX_FCSOK
&& macSrce <= qlowman
&& !(macSrce == 0 || DLL_SM_current.myaddr == 0xFF)
&& moderator.NUT_length == DLL_SM_current.NUT_length
&& moderator.gb_prestart == DLL_SM_current.gb_prestart
&& moderator.gb_start == DLL_SM_current.gb_start
&& moderator.gb_center == DLL_SM_current.gb_center
&& moderator.modulus == DLL_SM_current.modulus
&& moderator.blanking == DLL_SM_current.blanking
&& moderator.slotTime == DLL_SM_current.slotTime
&& moderator.smax == DLL_SM_current.smax
&& moderator.umax == DLL_SM_current.umax
action:
processModerator(moderator);
housekeeping();
// The moderator doesn't match, so this node is a rogue.
// Since in the guardband, go to rxmod for recovery
event: RX_endMAC
condition: RX_FCSOK
&& !( moderator.NUT_length == DLL_SM_current.NUT_length
&& moderator.umax == DLL_SM_current.umax)
&& in_guardband == TRUE
destination: rxMod0
action:
netState = ROGUE;
DLL_event(DLL_EV_rogue);
// The moderator doesn't match, so this node is a rogue.
// Since currently not in the guardband, go to endframe for recovery.
event: RX_endMAC
condition: RX_FCSOK
&& !( moderator.NUT_length == DLL_SM_current.NUT_length
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 182 – 61158-4-2 © IEC:2007(E)

&& moderator.umax == DLL_SM_current.umax)
&& in_guardband == FALSE
action:
netState = ROGUE;
DLL_event(DLL_EV_rogue);
//
// come here to handle a bad moderator DLPDU
// wait for link to become quiet, or until tone generation is due
//
state: badMod
// This state is reached when this node identifies a moderator DLPDU,
// but the DLPDU is subsequently reported bad so the state transfers
// back to endFrame if this node is not in the guardband.
event: TRUE
condition: in_guardband == FALSE
action:
// the guardband should be ended NOW
event: NUT_timer.count <= 30 usec
action:
missed_moderator();
housekeeping();
// else wait until the link is quiet
event: ph_lock_indication == FALSE
destination: rxMod0
//
// send the moderator, wait for guardband center
//
state: txMod0
event: NUT_timer.count <= DLL_SM_current.gb_center
destination: txMod1
action:
TX_sendHeader(DLL_SM_current.myaddr); // send header
//
// send more
//
state: txMod1
destination: txMod2
action:
moderator.size = MODERATOR_SIZE;
moderator.ctl = MODERATOR_CTL;
moderator.service = MODERATOR_TAG;
moderator.dest = 0xff;
moderator.NUT_length = DLL_SM_current.NUT_length;
moderator.smax = DLL_SM_current.smax;
moderator.umax = DLL_SM_current.umax;
moderator.slotTime = DLL_SM_current.slotTime;
moderator.blanking = DLL_SM_current.blanking;
moderator.gb_start = DLL_SM_current.gb_start;
moderator.gb_center = DLL_SM_current.gb_center;
moderator.usr = usr;
moderator.interval_count = interval_count;
moderator.modulus = DLL_SM_current.modulus;
moderator.tMinus = tMinus;
moderator.gb_prestart = DLL_SM_current.gb_prestart;
moderator.spare = 0;
TX_sendLpacket(moderator); // send the Lpacket
//
// finish up
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 183 –
//
state: txMod2
destination: txMod3
action:
TX_sendTrailer();
//
// at completion, transferring to waiting for tone
//
state: txMod3
event: TX_trailerComplete
action:
currentMod = DLL_SM_current.myaddr;
housekeeping();
//
// wait for tone
//
state: waitTone
// end of this NUT, and transferring to off-line
event: NUT_timer.count == 0
condition: SM_online == FALSE
destination: offline
action:
DLL_tone_indication(interval_count);
// end of this NUT, start of another

event: NUT_timer.count == 0
condition: SM_online_req == TRUE
destination: waitSlotZero
action:
DLL_tone_indication(interval_count);
NUT_timer.restart();
scheduled = TRUE;
in_guardband = FALSE;
// housekeeping
// If this node detects line activity, but not moderators, attempt to recover.
// Maybe problem is that the local node is performing housekeeping (and is
// therefore deaf) during the time the moderator DLPDU is transmitted.
if ((netState != MOD || netState != NOTMOD)
&& qlowman != 255
&& ph_frame_indication == TRUE)
{
deafcount++;
}
else
{
deafcount = 0;
}
gen_timer.start(20 usec); // start timer for start of scheduled time
//
// wait for start of scheduled
//
state: waitSlotZero
// start a new scheduled token pass

destination: gap
action:
itr = -1;
if (DLL_SM_current.myaddr == 0) // supernode doesn't try to detect lowman
{
nqlowman = 0;
qlowman = 0;
}
else // else initialize the detector
{
nqlowman = 255;
qlowman = 255;
}
slot_timer.restart();
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 184 – 61158-4-2 © IEC:2007(E)
9.3 TxLLC
The TxLLC (transmit LLC) shall receive and buffer Lpackets from the upper layers. It shall
pick the next Lpacket to be transmitted based on
— the order in which Lpackets were queued;

— attributes of the Lpacket;
— information provided by the Access Control Machine (ACM).
The TxLLC shall present the selection Lpacket to the ACM for transmission.
--`,,```,,,,````-`-`,,`,,`,`,,`---
// DLL TX LLC State Machine Description
// This state machine accepts transmit requests from the DLS-user,

// queues and prioritizes them, and submits one Lpacket at a time
// to the ACM based on parameters received from the ACM.
/////////////////////////////////////////////////////////////////////////////
//
// type and constant definitions
//
typedef void *IDENTIFIER;
typedef enum { M_0,
M_1,
M_ND_plus,
M_ND_minus } M_SYMBOL;
// These are the three transmit priorities.
// hard assignments are so that the priority can be
// used as an index into an array of FIFOs
// note that HIGH and LOW are unscheduled
typedef enum { SCHEDULED=0,

HIGH=1,
LOW=2} PRIORITY;
typedef enum { OK,
TXABORT,
FLUSHED } TXSTATUS; // describes the result of a transmit request.
//
// Lpacket class
//
class Lpacket
{
public:
// return the size octet of the current Lpacket
USINT size;
// return the ctl octet of the current Lpacket
USINT ctl;

#define TAGPAD 2
#define DATAPAD 4
int tag_pad(void)
{
}

int data_pad(void)
{
}

int wire_size(void)
{
}
// store next octet to the Lpacket

void put_octet(USINT data);
// get an octet from the Lpacket

61158-4-2 © IEC:2007(E) – 185 –
USINT &operator[](int index);

Lpacket(void *p) // constructor
{
}
Lpacket(int size) // constructor
{
}
};
//
// superclass of Lpacket that defines an Lpacket to be transmitted
//
class txLpacket : public Lpacket
{
public:
IDENTIFIER id;
BOOL fixed;
// constructors
txLpacket(void *p) : Lpacket(p)
{
}
txLpacket(int size) : Lpacket(size) // size is size of PDU buffer
{ // (Lpacket plus pads, in octets)
}
};
/////////////////////////////////////////////////////////////////////////////
//
// interface to DLS-user
//
void DLL_xmit_fixed_request(
IDENTIFIER id,
USINT Lpacket[],
UINT size,
PRIORITY priority,
USINT service,
USINT destID);
extern void DLL_xmit_fixed_confirm (IDENTIFIER id, TXSTATUS status);
void DLL_xmit_generic_request(
IDENTIFIER id,
USINT Lpacket[],
UINT size,
PRIORITY priority,
USINT tag[3]);
extern void DLL_xmit_generic_confirm (IDENTIFIER id, TXSTATUS status);
void DLL_flush-requests-by-QoS_request (PRIORITY priority);
extern void DLL_flush-requests-by-QoS_confirm (PRIORITY priority);
DLL_flush_single_request( PRIORITY priority, IDENTIFIER xmit_id );
/////////////////////////////////////////////////////////////////////////////
//
// interface to ACM
//
txLpacket *pickLpacket(BOOL scheduled, int octetsLeft);// pick an Lpacket to send next
void LpacketSent(TXSTATUS status); // the Lpacket was sent
/////////////////////////////////////////////////////////////////////////////
//
//
void SM_powerup(void); // input indication: powerup has occurred
/////////////////////////////////////////////////////////////////////////////
//
// a class to represent message FIFOs
//
class FIFO
--`,,```,,,,````-`-`,,`,,`,`,,`---
{
public:
void put(txLpacket lp); // add an Lpacket to the FIFO
txLpacket &get(void); // remove an Lpacket from the FIFO
txLpacket &peek(void); // look at the first Lpacket in the FIFO

– 186 – 61158-4-2 © IEC:2007(E)
void flush(void); // delete all Lpackets in the FIFO

void flush1(IDENTIFIER id); // delete one Lpacket in the FIFO, given it's ID
BOOL has_data(); // true if the FIFO is not empty
};
FIFO fifo[3]; // at least three priority levels shall be provided
/////////////////////////////////////////////////////////////////////////////
//
// TxLLC implementation
//
//
// powerup initialization
//
void SM_powerup(void)
--`,,```,,,,````-`-`,,`,,`,`,,`---
{
fifo[SCHEDULED].flush();
fifo[HIGH].flush();
fifo[LOW].flush();
}
//
// flush a particular FIFO
//
void DLL_flush-requests-by-QoS_request (PRIORITY priority)
{
fifo[priority].flush();
DLL_flush-requests-by-QoS_confirm(priority);
}
//
// flush a particular Lpacket
//
void DLL_flush_single_request (PRIORITY priority, IDENTIFIER id)
{
fifo[priority].flush1(id);
}
//
// requests from DLS-user to submit Lpackets for transmission
//
void DLL_xmit_fixed_request(
IDENTIFIER id,
USINT Lpacket[],
UINT size,
PRIORITY priority,
USINT service,
USINT destID)
{
int tmp;
tmp = size + 4 + (size&1); // size of DLSdu plus 4 octet fixed Lpacket header
// plus optional data pad
txLpacket &lp(new txLpacket(tmp)); // create a new Lpacket buffer
// build the PDU (Lpacket)
lp[0] = tmp/2; // size, in words
lp[1] = 0x01 | ((size&1)<<2); // ctl octet, plus data pad bit, if needed
lp[2] = service; // fixed tag service
lp[3] = destID; // destination MAC ID
memcpy(&lp[4], Lpacket, size); // copy the rest of the data
// there may be a pad octet sent after the DLSdu
lp.id = id; // store the user's id (for the confirmation)
lp.fixed = TRUE; // store type of Lpacket (fixed)
fifo[priority].put(lp); // queue the Lpacket
}
void DLL_xmit_generic_request(
IDENTIFIER id,
USINT Lpacket[],
UINT size,
PRIORITY priority,
USINT tag[3])
{
int tmp;
int pad;
tmp = size + 6 + (size&1); // octet size of DLSdu plus 6 octet GEN Lpacket header
// plus data pad
pad = 0;
txLpacket &lp(new txLpacket(tmp)); // create a new Lpacket buffer
// build the PDU (Lpacket)

lp[0] = tmp/2; // size, in words

61158-4-2 © IEC:2007(E) – 187 –
lp[1] = 0x12 | ((size&1)<<2); // control octet,

// plus maybe a data pad bit,
lp[2] = 0; // tag pad octet (affects memory image of Lpacket)

lp[3] = tag[0]; // generic tag
memcpy(&lp[6], Lpacket, size); // copy the rest of the data
// there may be pad octet after the DLSdu
lp.id = id; // store the user's identifier (for the confirm)
lp.fixed = FALSE; // store type of Lpacket (generic)
fifo[priority].put(lp); // queue the new Lpacket
}
static txLpacket *picked = 0; // remember which Lpacket was picked

//
// called by ACM to pick the next Lpacket to be sent out
//
txLpacket *pickLpacket(BOOL scheduled, int octetsLeft)
{
int wordsleft = (octetsLeft+1)/2; // wordsleft is rounded up, accepting that in
some
// cases this results in an Lpacket not being sent
if(scheduled) // if scheduled, only look at scheduled FIFO
{
// if there is anything in the FIFO and it fits in the time left
if(fifo[SCHEDULED].has_data()
&& fifo[SCHEDULED].peek().size <= wordsleft)
{
picked = &fifo[SCHEDULED].get(); // then pick it to be sent
}
else picked = 0; // no Lpacket available
}
else // if unscheduled -- look at all FIFOs in order
{
// if there is anything in the FIFO and it fits in the time left
if(fifo[SCHEDULED].has_data()
&& fifo[SCHEDULED].peek().size <= wordsleft)
{
picked = &fifo[SCHEDULED].get(); // then pick it to be sent
}
else if(fifo[HIGH].has_data() // ditto for HIGH
&& fifo[HIGH].peek().size <= wordsleft)
{
picked = &fifo[HIGH].get();
}
else if(fifo[LOW].has_data() // ditto for LOW
&& fifo[LOW].peek().size <= wordsleft)
{
picked = &fifo[LOW].get();
}
else picked = 0; // no Lpacket available
}
return picked;
}
//
// confirmation from the ACM that the picked Lpacket was sent (or possibly aborted)
//
void LpacketSent(TXSTATUS status)
{
if(picked->fixed) // if the Lpacket was fixed
--`,,```,,,,````-`-`,,`,,`,`,,`---
{
DLL_xmit_fixed_confirm (picked->id, status); // generate a fixed confirm
}
else // else
{
DLL_xmit_generic_confirm (picked->id, status);// generate a generic confirm
}
delete picked; // delete temp data
picked = 0;
}

– 188 – 61158-4-2 © IEC:2007(E)
9.4 RxLLC
The RxLLC (receive LLC) shall buffer Lpackets from the Receive Machine (RxM) as they are
assembled. When the RxM indicates that a good DLPDU has concluded, all buffered Lpackets
shall be presented to the upper layers in the order received. If the RxM indicates a bad
DLPDU has concluded, all buffered Lpackets shall be discarded.
// DLL RX LLC State Machine Description
// This state machine gets Lpackets from the RxM,

// and DLPDU status from the deserializer.
// It handles quarantining, and passes quarantined
// Lpackets up to the DLS-user
/////////////////////////////////////////////////////////////////////////////
//
//
//
// Lpacket class
//
class Lpacket
{
public:
// the size octet of the current Lpacket
USINT size;
// the ctl octet of the current Lpacket

USINT ctl;
#define TAGPAD 2
--`,,```,,,,````-`-`,,`,,`,`,,`---
#define DATAPAD 4

int tag_pad(void)
{
}
int data_pad(void)
{
}
int wire_size(void)
{
}

USINT &operator[](int index);
// init for a new Lpacket

void init(void);
Lpacket(void *p) {} // constructor
};
class rxLpacket : public Lpacket

{
public:
USINT source; // the MAC ID of the node that sent this Lpacket
int memory_size; // size of the Lpacket in memory
BOOL fixed; // true if fixed , false if generic
rxLpacket(void *p) : Lpacket(p) {}
};

61158-4-2 © IEC:2007(E) – 189 –
/////////////////////////////////////////////////////////////////////////////
//
// a class to represent message FIFOs
//
class FIFO
{
public:
void put(rxLpacket lp); // add an Lpacket to the fifo
rxLpacket &get(void); // remove an Lpacket from the fifo
void flush(void); // delete all Lpackets in the FIFO
BOOL has_data(); // true if the fifo is not empty
};
/////////////////////////////////////////////////////////////////////////////
//
// a class to represent generic tags
//
class gen_tag
{
--`,,```,,,,````-`-`,,`,,`,`,,`---
USINT data[3];
public:
// constructor
gen_tag(USINT first, USINT second, USINT third)
{
data[0] = first;
data[1] = second;
data[2] = third;
}
USINT &operator[](int index)
{
return data[index];
}
};
/////////////////////////////////////////////////////////////////////////////
//
// internal variables
//
FIFO fifo;
/////////////////////////////////////////////////////////////////////////////
//
// interface to PhL
//
BOOL ph_lock_indication; // optimistic DLPDU detect (clock recovery is tracking)
BOOL ph_frame_indication; // pessimistic DLPDU detect (Manchester valid since the SD)
/////////////////////////////////////////////////////////////////////////////
//
//
extern BOOL RX_endMAC; // the end delimiter has been detected
extern BOOL RX_FCSOK; // FCS on last DLPDU was OK
extern BOOL RX_abort; // abort received on last DLPDU
/////////////////////////////////////////////////////////////////////////////
//
// interface to RxM
//
BOOL RX_receivedLpacket; // indication: an Lpacket has been received
rxLpacket RX_Lpacket(0); // data: the Lpacket most recently received
/////////////////////////////////////////////////////////////////////////////
//
// Interface to DLS-user
//
DLL_recv_fixed_indication (
USINT Lpacket[],
UINT size,
USINT service,
USINT sourceID);
DLL_recv_generic_indication (
USINT Lpacket[],
UINT size,
gen_tag tag);

– 190 – 61158-4-2 © IEC:2007(E)
/////////////////////////////////////////////////////////////////////////////
//
//
BOOL SM_powerup; // input indication: powerup has occurred
/////////////////////////////////////////////////////////////////////////////
//
// RxLLC states
//
// wait for powerup
state: powerup
event: SM_powerup
destination: idle
action:
--`,,```,,,,````-`-`,,`,,`,`,,`---
fifo.flush();
// wait for a DLPDU to start

state: idle
destination: getLpacket
state: getLpacket
// stuff a new Lpacket into FIFO
event: RX_receivedLpacket // wait for a new Lpacket to be assembled
destination: getLpacket
action:
fifo.put(RX_Lpacket); // stuff the Lpacket into the FIFO
// if FCS is good, give all Lpackets to next layer up

event: RX_endMAC
condition: RX_FCSOK
destination: idle
action:
rxLpacket &lp(0);
while(fifo.has_data())
{
lp = fifo.get();
if(lp.fixed)
{
DLL_recv_fixed_indication(
&lp[4], // rip off 4 octets of header to leave DLSdu
lp.memory_size-4,
lp[2], // send service octet
lp.source); // send source MAC ID
}
else
{
DLL_recv_generic_indication(
&lp[6], // rip off 6 octets of header to leave DLSdu
lp.memory_size-6,
gen_tag(lp[3],lp[4],lp[5])); // send a three octet tag
}
}
// if DLPDU is damaged, flush all the Lpackets in the FIFO

event: RX_endMAC
destination: idle
action:
fifo.flush(); // discard all Lpackets

61158-4-2 © IEC:2007(E) – 191 –
9.5 Transmit machine (TxM)
The transmit machine (TxM) shall receive commands and data from the Access Control
Machine to transmit the components of a DLPDU. It shall transmit a DLPDU by passing data
octets and commands to the Serializer.
// DLL TxM State Machine Description
// This state machine gets commands and Lpackets from the ACM to
// build and transmit a DLPDU. It uses the services of the
// Serializer to do this.
/////////////////////////////////////////////////////////////////////////////
//
//

/////////////////////////////////////////////////////////////////////////////
//
//
//
#define TAGPAD 2
#define DATAPAD 4
//
// Lpacket class
//
class Lpacket
{
public:
USINT size;
USINT ctl;

int tag_pad(void)
{
}
int data_pad(void)
{
}

int wire_size(void)
{
}


BOOL abort(void);
};
/////////////////////////////////////////////////////////////////////////////
//
//
int counter;
/////////////////////////////////////////////////////////////////////////////
//
// interface from ACM and TxLLC
//
BOOL TX_sendHeader; // command: send preamble, SD, source MAC ID
USINT myaddr; // input: the source MAC ID
BOOL TX_headerComplete; // reply: header has been sent
BOOL TX_sendLpacket; // command: send an Lpacket
class Lpacket lp; // input: the Lpacket to be sent
BOOL TX_LpacketComplete; // reply: Lpacket has been sent
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 192 – 61158-4-2 © IEC:2007(E)
BOOL TX_sendTrailer; // command: send FCS, ED

BOOL TX_done; // reply: DLPDU is complete
BOOL TX_abort; // status: DLPDU was aborted
/////////////////////////////////////////////////////////////////////////////
//
// interface to Serializer
//
void SER_txRequest(BOOL state); // command: turn transmitter on and off
void SER_sendData(USINT data); // command: send a Manchester coded data octet
void SER_sendSD(void); // command: send a start delimiter
void SER_sendED(void); // command: send an end delimiter
void SER_clearFCS(void); // command: clear the FCS accumulator
void SER_sendFCS(void); // command: send the FCS
BOOL SER_operationComplete; // reply: current operation is completed
/////////////////////////////////////////////////////////////////////////////
//
//
BOOL SM_powerup; // event indication
/////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////////////
//
// TxM states
//
// wait for powerup
//
state: powerup
event: SM_powerup
destination: idle
//
// wait for a DLPDU to send
//
state: idle
// when commanded by ACM to start a DLPDU, send the first preamble
event: TX_sendHeader
destination: pre0
action:
TX_done = FALSE;
TX_headerComplete = FALSE;
TX_abort = FALSE;
SER_txRequest(TRUE); // turn on transmitter
SER_sendData(0xff); // send first preamble octet
//
// send second preamble octet
//
state: pre0
event: SER_operationComplete
destination: pre1
action:
SER_sendData(0xff); // send second preamble octet
//
// send start delimiter
//
state: pre1
destination: sd
action:
SER_sendSD(); // send source MAC ID
//
// send MAC ID
//
state: sd
destination: finishHeader
action:
SER_clearFCS();
SER_sendData(myaddr);
//
// wait for header complete
//
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 193 –
state: finishHeader
destination: nextLP
action:
TX_headerComplete = TRUE;
//
// wait for a command to either send an Lpacket or to terminate the DLPDU
//
state: nextLP
// start a new Lpacket, grab the size octet

event: TX_sendLpacket
destination: sendCtl
action:
counter = lp.wire_size() - 1; // note size zero is not a permitted value
SER_sendData(lp.get_next_octet());
TX_LpacketComplete = FALSE;
// terminate DLPDU: send the FCS
event: TX_sendTrailer
destination: sendFCS
action:
SER_sendFCS();
state: sendCtl
// sent the CTL octet, ignoring tag pad if present
destination: sendData
action:
counter = counter - 1;
if(lp.tag_pad()) // if tag pad
{
lp.get_next_octet(); // discard next octet
}
//
// send the rest of the data in an Lpacket
//
state: sendData
// if aborted, send an abort sequence: SD followed immediately by ED
condition: lp.abort()
destination: abort1
action:
SER_sendData(0xff); // required before the Start Delimiter to avoid
// violating run length requirement of phy layer
// if more data, send the next octet
condition: !lp.abort() && counter > 0
destination: sendData
action:
counter = counter - 1;
// when done, wait for the next command

condition: !lp.abort() && counter <= 0
destination: nextLP
action:
if(lp.data_pad()) // if data pad
{
lp.get_next_octet(); // discard next octet
}
TX_LpacketComplete = TRUE; // signal that Lpacket is done
//
// send the ED
//
state: sendFCS
destination: sendED
action:
SER_sendED();
//
// wait for ED complete, then shut down and wait for next DLPDU
//
state: sendED
destination: idle --`,,```,,,,````-`-`,,`,,`,`,,`---

– 194 – 61158-4-2 © IEC:2007(E)
action:
SER_txRequest(FALSE); // turn off transmitter
TX_done = TRUE; // signal that DLPDU is done
//
// sent an FF before the abort, when it's done send an Start Delimiter
//
state: abort1
destination: abort2
action:
SER_sendSD();
//
// send second part of the abort (End Delimiter)
//
state: abort2
destination: abort3
action:
SER_sendED();
//
// wait for abort complete, then shut down and wait for next DLPDU
//
state: abort3
destination: idle
action:
SER_txRequest(FALSE); // turn off transmitter
TX_abort = TRUE; // assert error flag
TX_LpacketComplete = TRUE; // signal that Lpacket is done
TX_done = TRUE; // signal that DLPDU is done
9.6 Receive machine (RxM)
The receive machine (RxM) shall receive framing information and data octets from the
Deserializer. It shall decode Lpackets from the received octet stream for presentation to the
ACM and the RxLLC. It shall accept generic and fixed Lpackets for which the corresponding
tag filter is enabled, and discard Lpackets that are not enabled.
// DLL RxM State Machine Description
// This state machine gets octet symbols from the Deserializer and uses
// them to build Lpackets, which are then sent to the RxLLC.
/////////////////////////////////////////////////////////////////////////////
//
//

/////////////////////////////////////////////////////////////////////////////
//
//
//
#define TAGPAD 2
#define DATAPAD 4
//
// Lpacket class
//
class Lpacket
{
public:
// the size octet of the current Lpacket
USINT size;
// the ctl octet of the current Lpacket
USINT ctl;
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 195 –
int tag_pad(void)
{
}
int data_pad(void)
{
}
--`,,```,,,,````-`-`,,`,,`,`,,`---
int wire_size(void)
{
}
// get an octet from the Lpacket
USINT operator[](int index);
// init for a new Lpacket
void init(void);
};
class rxLpacket : public Lpacket

{
public:
USINT source; // the MAC ID of the node that sent this Lpacket
int memory_size; // size of the Lpacket in memory
BOOL fixed; // true if fixed , false if generic
};
/////////////////////////////////////////////////////////////////////////////
//
// a class to represent generic tags
//
class gen_tag
{
USINT data[3];
public:
// constructor
gen_tag(USINT first, USINT second, USINT third)
{
data[0] = first;
data[1] = second;
data[2] = third;
}
USINT operator[](int index)
{
return data[index];
}
};
/////////////////////////////////////////////////////////////////////////////
//
// the interface to the tag filter lookup tables -- the implementation is unspecified
//
class gen_screener
{
public:
BOOL enable(gen_tag tag); // set tag, requires tag, TRUE=success/FALSE=failure
BOOL disable(gen_tag tag); // clear tag, requires tag, TRUE=success/FALSE=failure
BOOL lookup(gen_tag tag); // lookup tag, requires tag, TRUE=enabled/FALSE=disabled
void init(void); // powerup init & clear
};
class fixed_screener
{
public:
BOOL enable(USINT service); // set tag, requires tag, TRUE=success/FALSE=failure
BOOL disable(USINT service); // clear tag, requires tag, TRUE=success/FALSE=failure
BOOL lookup(USINT service); // lookup tag, requires tag,
TRUE=enabled/FALSE=disabled
void init(void); // powerup init & clear
};
/////////////////////////////////////////////////////////////////////////////
//

– 196 – 61158-4-2 © IEC:2007(E)
//
// the tag filtering tables
class gen_screener gen;
class fixed_screener fixed;
// MAC ID of source of DLPDU
USINT source;
// an octet counter
int counter;
// temps for generic screener tag octets

USINT gen0;
USINT gen1;
/////////////////////////////////////////////////////////////////////////////
//
// interface to PhL
//
extern BOOL ph_lock_indication; // optimistic DLPDU detect (clock recovery is
tracking)
extern BOOL ph_frame_indication; // pessimistic DLPDU detect (Manchester valid since
the SD)
/////////////////////////////////////////////////////////////////////////////
//
//
extern BOOL RX_dataReady; // an octet of a DLPDU is available
extern USINT RX_rxData; // octet most recently received from DLPDU (source
MAC ID)
extern BOOL RX_endMAC; // the end delimiter has been detected
extern BOOL RX_FCSOK; // FCS on last DLPDU was OK
extern BOOL RX_abort; // abort received on last DLPDU
/////////////////////////////////////////////////////////////////////////////
//
{
public:
USINT myaddr;
UINT NUT_length;
USINT smax;
USINT umax;
USINT slotTime;
USINT blanking;
USINT gb_start;
USINT gb_center;
USINT modulus;
USINT gb_prestart;
};
extern DLL_config_data SM_current; // the DLL config variables -- need my MAC ID
extern BOOL SM_powerup; // input indication: powerup has occurred
/////////////////////////////////////////////////////////////////////////////
--`,,```,,,,````-`-`,,`,,`,`,,`---
//
// interface to RxM
//
// received data interface

BOOL RX_receivedLpacket; // an Lpacket has been received
rxLpacket RX_Lpacket; // the Lpacket most recently received
// interface to manage tag filters

extern enable_generic_confirm (IDENTIFIER id, BOOL result);
extern disable_generic_confirm (IDENTIFIER id, BOOL result);
extern enable_fixed_confirm (IDENTIFIER id, BOOL result);
extern disable_fixed_confirm (IDENTIFIER id, BOOL result);
void DLL_enable_generic_request (IDENTIFIER id, gen_tag tag)

{
enable_generic_confirm (id, gen.enable(tag));
}
void DLL_disable_generic_request (IDENTIFIER id, gen_tag tag)

61158-4-2 © IEC:2007(E) – 197 –
{
disable_generic_confirm (id, gen.disable(tag));
}
void DLL_enable_fixed_request (IDENTIFIER id, USINT service)
{
enable_fixed_confirm (id, fixed.enable(service));
}
void DLL_disable_fixed_request (IDENTIFIER id, USINT service)

{
disable_fixed_confirm (id, fixed.disable(service));
}
/////////////////////////////////////////////////////////////////////////////
//
// RxM states
//
//
// wait for powerup
//
state: powerup
event: SM_powerup
destination: idle
action:
RX_receivedLpacket = FALSE;
//
// wait for a DLPDU to start
//
state: idle

destination: getID
state: getID
// if DLPDU is terminated, wait for next DLPDU
destination: idle
// get the source MAC ID and save it for all the Lpackets in the DLPDU
destination: getSize
--`,,```,,,,````-`-`,,`,,`,`,,`---
action:
source = RX_rxData; // save the source MAC ID for subsequent Lpackets
state: getSize
destination: idle
// get the size octet and init a new Lpacket
destination: getCtl
action:
RX_receivedLpacket = FALSE; // re-initialize the interface
RX_Lpacket.init();
RX_Lpacket.source = source; // save the source in the new Lpacket
RX_Lpacket.put_octet(RX_rxData); // store the size octet
state: getCtl
destination: idle
// get the CTL octet for a fixed Lpacket
event: RX_dataReady == TRUE && (RX_rxData & 0xFB) == 0x01 // fixed tag
destination: getFixed0
action:
RX_Lpacket.put_octet(RX_rxData); // store the ctl octet
counter = RX_Lpacket.wire_size() - 2; // init the octet counter
// get the CTL octet for a generic Lpacket

event: RX_dataReady == TRUE && (RX_rxData & 0xFB) == 0x12 // generic tag
destination: getGen0
action:
RX_Lpacket.put_octet(RX_rxData); // store the ctl octet
RX_Lpacket.put_octet(0); // store the pad octet

– 198 – 61158-4-2 © IEC:2007(E)
// get the CTL octet for a generic Lpacket

&& (RX_rxData & 0xFB) != 0x01
&& (RX_rxData & 0xFB) != 0x12
destination: ignoreRest
action:
//
// handle service octet of fixed Lpacket
//
state: getFixed0
destination: idle
// handle case if tag is enabled
&& fixed.lookup(RX_rxData)
destination: getFixed1
action:
RX_Lpacket.put_octet(RX_rxData); // put the next data octet into the Lpacket
counter--; // count it
// handle case if tag is disabled
&& !fixed.lookup(RX_rxData)
action:
//
// handle dest octet of fixed Lpacket
//
state: getFixed1
destination: idle
// handle case if addressed to me or broadcast
&& (RX_rxData == SM_current.myaddr || RX_rxData == 0xFF)
destination: getRest
action:
RX_Lpacket.fixed = TRUE;
// handle case if not addressed to me

&& RX_rxData != SM_current.myaddr
&& RX_rxData != 0xFF
action:
//
// handle first tag octet of generic Lpacket
--`,,```,,,,````-`-`,,`,,`,`,,`---
//
state: getGen0
destination: idle
// save the next octet
action:
RX_Lpacket.put_octet(gen0=RX_rxData); // save and put the next octet into
Lpacket
//
// handle second tag octet of generic Lpacket
//
state: getGen1
destination: idle
// save the next octet


61158-4-2 © IEC:2007(E) – 199 –
action:
RX_Lpacket.put_octet(gen1=RX_rxData); // save and put next data octet into
Lpacket
//
// handle third octet of generic Lpacket
//
state: getGen2
destination: idle
// handle case if local node is interested in this generic Lpacket
&& gen.lookup(gen_tag(gen0, gen1, RX_rxData))
action:
RX_Lpacket.fixed = FALSE;
// handle case if not interested in this generic Lpacket

&& !gen.lookup(gen_tag(gen0,gen1,RX_rxData))
action:
state: getRest
destination: idle
// get data octets except the last
condition: counter > 1
action:
// get the last data octet; handle data pad, indicate arrived Lpacket; wait for
next Lpacket
condition: counter == 1
action:
RX_Lpacket.put_octet(RX_rxData); // get the last octet
if(RX_Lpacket.data_pad()) // if a data pad is requested,
{
RX_Lpacket.put_octet(0); // insert a zero
}
// remove pad octets from data count
RX_Lpacket.memory_size -= RX_Lpacket.size*2;
RX_receivedLpacket = TRUE; // notify that that an Lpacket has arrived
state: ignoreRest
destination: idle
// get data octets except the last
condition: counter > 1
action:
// handle the last data octet; wait for next Lpacket

condition: counter == 1
– 200 – 61158-4-2 © IEC:2007(E)
9.7 Serializer
For each command from the TxM, the Serializer shall produce the appropriate M_symbol
stream, which shall be output to the medium via the PhL.
// DLL octet Serializer
// This state machine gets commands to transmit octet symbols from the TxM.
// It decomposes the octet symbols into M_symbols, and
// uses the services of the PHY layer to send these on the medium.
// This specifies the correct order of transmission of the various octet symbols.
// The FCS algorithm is the same as that used by HDLC
/////////////////////////////////////////////////////////////////////////////
//
// data types
//
typedef enum {FALSE, TRUE} BOOL;
/////////////////////////////////////////////////////////////////////////////
//
// interface to TxM
//
// requests (TxM to SER)
void SER_txRequest(BOOL state); // command: turn transmitter on and off
void SER_sendData(USINT data); // command: send a Manchester coded data octet
void SER_sendSD(void); // command: send a start delimiter
void SER_sendED(void); // command: send an end delimiter
void SER_clearFCS(void); // command: clear the FCS accumulator
void SER_sendFCS(void); // command: send the FCS
// indications (SER to TxM)
extern void SER_operationComplete(void); // notify the TxM that an operation is
complete
/////////////////////////////////////////////////////////////////////////////
//
// interface to the PHY layer
//
typedef enum {M_0, M_1, M_ND_plus, M_ND_minus} M_SYMBOL;
BOOL ph_frame_request; // transmit enable/disable
M_SYMBOL ph_data_request; // data to be sent
/////////////////////////////////////////////////////////////////////////////
//
//
--`,,```,,,,````-`-`,,`,,`,`,,`---
static unsigned int accum; // the FCS accumulator, 16 bits, sign is irrelevant
// as long as zeros shift in from the right
/////////////////////////////////////////////////////////////////////////////
//
// internal subroutines
//
// add one octet to the FCS accumulator

// this is just one possible implementation of the HDLC FCS
static void FCS_octet(unsigned int d)

{
accum ^= d & 0xff;
for(int i=0;i<8;i++)
{
accum = (accum>>1) ^ (0x8408 * (accum&1)); // use FCS-CCITT polynomial
}
}
/////////////////////////////////////////////////////////////////////////////
//
// Serializer implementation
//
// requests (TxM to SER)

61158-4-2 © IEC:2007(E) – 201 –
// enable transmitter
void SER_txRequest(BOOL state)
{
ph_frame_request = state;
}
// add a data octet to the FCS and send it
void SER_sendData(USINT data)
{
FCS_octet(data);
// transmit data bits 0 through 7
ph_data_request = (data & 0x01) ? M_1 : M_0;
SER_operationComplete(); // tell TxM that operation is complete
}
// send a start delimiter

void SER_sendSD(void)
{
ph_data_request = M_ND_plus;
ph_data_request = M_0;
ph_data_request = M_ND_minus;
}
// send an end delimiter

void SER_sendED(void)
{
}
// initialize the FCS accumulator

void SER_clearFCS(void)
{
accum = 0xffff; // init the accumulator to all ones
}
// send the FCS

void SER_sendFCS(void)
{
int tmp;
tmp = accum ^ 0xffff; // invert the FCS before sending;

SER_sendData(tmp); // do not calculate FCS while sending itself
SER_sendData(tmp>>8);
--`,,```,,,,````-`-`,,`,,`,`,,`---

}
9.8 Deserializer
9.8.1 Octet construction
The Deserializer shall accept M_symbols from ph_data_indication. M_symbols at the

start of a frame shall be ignored until the ph_frame_indication line transitions from false
to true. This transition shall start on the first data octet – the source MAC ID. The Deserializer
shall then group subsequent sets of eight MAC data symbols into octets. As each subsequent
data octet is ready, the Deserializer shall transition the RX_dataReady line from false to true.

– 202 – 61158-4-2 © IEC:2007(E)
9.8.2 FCS checking
A modified CCITT Cyclic Redundancy Check shall be performed on the transferred data to
verify the frame check sequence (FCS).
The formal concepts for the FCS generator and checker are described in 5.3.8.2.
The method used for cheking shall be the same as specified for HDLC (ISO/IEC 3309), with
the exception that start and end delimiters shall be substituted for flags, and Manchester
encoding shall be substituted for bit-stuffing. The FCS checker shall implement the polynomial
X 16 + X 12 + X 5 + 1, and shall result in a two octets frame check sequence (FCS).
NOTE The last two data octets in the DLPDU (FCS octets) are calculated by the transmitting node so that, in the
absence of errors, the remainder in the receiving node is always 0xF0B8 (see 5.3.8.2).
The receive FCS process shall begin by pre-setting the FCS checker to 0xFFFF when the
ph_frame_indication line transitions from false to true. All subsequent data bits on the
ph_data_indication line, excluding the end delimiter, shall be applied to the FCS checker.
At end of receiving a DLPDU, the remainder (FCS) shall be compared to 0xF0B8.
9.8.3 End of DLPDU processing
Data octet processing shall proceed until ph_frame_indication transitions from true to
false. This transition can happen mid-octet, but no action shall be taken until the start of the
next octet. This time shall mark the end of reception for this frame.
The ph_status_indication received after ph_frame_indication transitions from true

to false shall determine which of the following actions to take:
— if Normal – set RX_FCSOK to true if (FCS remainder == 0xF0B8); otherwise, set to false;
— if Abort – set Rx_abort to true; set Rx_FCSOK to false;
— if Invalid – set Rx_abort to false; set Rx_FCSOK to false.
9.9 DLL management
DLL Management shall buffer the station management variables that are required for the DLL
to operate. It shall manage synchronized changes on these variables via interfaces to Station
Management and the ACM.
--`,,```,,,,````-`-`,,`,,`,`,,`---
// DLL Station Management Interface Description

// This component holds the station management variables that are
// subject to synchronized change.
/////////////////////////////////////////////////////////////////////////////
//
// type and constant definitions
//
typedef void *IDENTIFIER; // The data type of the identifier is unspecified.
// config data definition

{
public:
USINT myaddr;
UINT NUT_length;
USINT smax;
USINT umax;
USINT slotTime;
USINT blanking;
USINT gb_start;
USINT gb_center;

61158-4-2 © IEC:2007(E) – 203 –
USINT modulus;
USINT gb_prestart;
};
/////////////////////////////////////////////////////////////////////////////
//
//
void DLL-tMinus-start-countdown-request (IDENTIFIER id, USINT start_count);
extern void DLL-tMinus-start-countdown-confirm (IDENTIFIER id, BOOL result);
void DLL_set_pending_request (IDENTIFIER id, DLL_config_data params);

extern void DLL_set_pending_confirm (IDENTIFIER id, BOOL result);
void DLL_get_pending_request (IDENTIFIER id);
extern void DLL_get_pending_confirm (IDENTIFIER id , DLL_config_data params);
void DLL_set_current_request (IDENTIFIER id, DLL_config_data params);

extern void DLL_set_current_confirm (IDENTIFIER id, BOOL result);
void DLL_get_current_request (IDENTIFIER id);
extern void DLL_get_current_confirm (IDENTIFIER id , DLL_config_data params);
/////////////////////////////////////////////////////////////////////////////
//
// interface to ACM
//
extern void DLL_tminus_zero_indication (); // ACM calls this when tMinus==0 occurs
DLL_config_data DLL_SM_pending; // the ACM needs to see both current and pending
DLL_config_data DLL_SM_current;
extern ACM_tMinus; // poke the ACM's tMinus counter to get
// a synchronized change started. The ACM
// continually writes over this every time the
// moderator is received, unless it is the moderator
void SM_supernode(void); // if this node saw a moderator sent by a supernode,
// any pending SM update shall be cancelled
/////////////////////////////////////////////////////////////////////////////
//
//
BOOL pending_changed = FALSE;
/////////////////////////////////////////////////////////////////////////////
//
// write the pending copy of DLL_config
void DLL_set_pending_request (IDENTIFIER id, DLL_config_data params)
{
DLL_SM_pending = params; // save the params in the pending buffer
pending_changed = TRUE;
DLL_set_pending_confirm (id, TRUE);
}
// write the current copy of DLL_config

// ONLY USED WHEN OFFLINE
void DLL_set_current_request (IDENTIFIER id, DLL_config_data params)
{
DLL_SM_current = params; // save the params in the pending buffer
DLL_set_current_confirm (id, TRUE);
}
// read the pending copy of DLL_config

void DLL_get_pending_request (IDENTIFIER id)
{
if(pending_changed == TRUE) // if pending has been updated
{
// return the contents of the pending buffer
DLL_get_pending_confirm (id , DLL_SM_pending);
}
else // if pending buffer is invalid
{
// return the contents of the current buffer
DLL_get_current_confirm (id , DLL_SM_current);
}
}
//
// read the current copy of DLL_config
//
void DLL_get_current_request (IDENTIFIER id)
{
// return the contents of the current buffer
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 204 – 61158-4-2 © IEC:2007(E)
DLL_get_current_confirm (id , DLL_SM_current);

}
//
// called by the ACM when a tMinus countdown has completed
//
void DLL_tminus_zero_indication(void)
{
if(pending_changed)
{
DLL_SM_current = DLL_SM_pending;
pending_changed = FALSE;
}
}
//
// start a synchronized change sequence
//
void DLL-tMinus-start-countdown-request (IDENTIFIER id, USINT start_count)
{
ACM_tMinus = start_count; // the ACM polls this variable
DLL-tMinus-start-countdown-confirm (id, TRUE);
}
//
// cancel pending change if a supernode has been seen
//
void SM_supernode(void)
{
pending_changed = FALSE;
}
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 205 –
Annex A
(normative)
Indicators and switches
A.1 Purpose
A common approach to status indicators and switch behavior is recommended to provide a

consistent human user interface for all devices conforming to this standard. These indicators,
typically LEDs, assist maintenance and diagnosis of problems with the Media, Physical and
Data Link Layers.
NOTE Throughout this annex the term “network” is used to refer to that portion of the Ph-subnetwork and
DL-subnetwork that is connected to the device making the observation.
A.2 Indicators
A.2.1 General indicator requirements
CPF 2 profiles have different levels of requirements for support of status indicators. However,
if a device does support status indicators, they shall follow the specifications described in this
annex for the selected CP.
NOTE 1 Indicators help maintenance personnel to quickly identify a faulty unit or media (e.g. red indicators are
typically used to indicate a fault condition). For this reason, it is strongly recommended to implement these
indicators in any device for which no practical constraint prevents it.
Two types of status indicators may be provided:
— one module status indicator;

— one or several network status indicators.
NOTE 2 These may be sometimes combined.
Additional indicators may be present; however, the naming and symbol conventions of the
standard indicators shall not be employed for other indicators.
Safety devices have additional requirements, see IEC 61784-3-2.
A.2.2 Common indicator requirements
--`,,```,,,,````-`-`,,`,,`,`,,`---
A.2.2.1 Applicability of common requirements
The common indicator requirement shall only apply to indicators for which requirements are
specified in this standard.
A.2.2.2 Visibility of indicators
Indicators shall be visible without removing covers or parts from the equipment. Indicators
shall be easily seen in normal lighting. Any related labels and icons shall be visible whether or
not the indicator is illuminated.
A.2.2.3 Indicator flash rate
Unless otherwise indicated, a two state indicator shall have a flash rate of (1,0 ± 0,1) Hz. The
indicator shall have a duty cycle of (50 ± 5)%.
NOTE The indicator is in the first state (on) for approximately 0,5 s and in the second state (off) for approximately
0,5 s.

– 206 – 61158-4-2 © IEC:2007(E)
A.2.2.4 Module status indicator
A.2.2.4.1 Description
This single bicolor (green/red) indicator shall provide status of the entire device. It shall
indicate whether or not the device is powered, configured, and operating properly.
NOTE A device with more than one communication port would have only one module status indicator.
A.2.2.4.2 States
The module status indicator states shall be as specified in Table A.1. The indicator states
reflect the device states specified in the Identity object (see IEC 61158-5-2).
Table A.1 – Module status indicator
Indicator state Device state Cause
Steady off No power There is no power applied to the device.

Steady green Operational The device is operating in a normal condition.
Flashing green Standby The device needs commissioning due to configuration
missing, incomplete or incorrect.
Flashing red Recoverable fault The device has detected a recoverable major fault (see
NOTE 1).
Steady red Unrecoverable fault The device has an unrecoverable major fault; may need
replacing.
Flashing red / green Device self testing The device is executing its power up self tests.
NOTE 1 Indicator flash rates are given in A.2.2.3.

NOTE 2 An incorrect or inconsistent configuration would be considered a recoverable fault.
Any indicator colors/states not defined in Table A.1 are reserved and shall not be used.
A.2.3 Fieldbus specific indicator requirements (1)
A.2.3.1 General requirements (1)
Two categories of status indicators shall be provided for each CP 2/1 device:

— two network status indicators.
A.2.3.2 Indicators at power up
During power up, the indicators shall turn on to a fault or reset state. All indicators shall
remain on (illuminated) for at least 1 s. After completion of power up, the indicator shall return
to a normal operational state.
Behavior of the module status indicator shall be as specified in A.2.2.4.
The module status indicator shall be labeled with one of the following:
“MS”;
“OK”;
--`,,```,,,,````-`-`,,`,

61158-4-2 © IEC:2007(E) – 207 –
“status”;
“mod status”;
“module status”.
A.2.3.4 Network status indicators
The indication of network status shall require two bicolor (red/green) indicators. If the device
has redundant PhLs (channels), each of the indicators shall be associated with one of the
channels. If the device does not support channel redundancy, one of the indicators shall be
associated with the single channel; however, two indicators shall still be required.
NOTE These indicators signify a number of conditions within the PhL; and when viewed together, they can reflect
the state of the Data Link Layer.
The network status indicators do not usually reflect any errors received on the NAP; however,
nodes which have only a NAP (no other PhL variants) may use the network status indicators
to represent the status of the NAP. If this optional behavior is implemented, the state of both
the indicators shall reflect the state of NAP communication, instead of the A and B channels.
A.2.3.4.2 States
A.2.3.4.2.1 Definitions
The following definitions shall be used to describe the indicator behavior:
steady – indicator shall be illuminated continuously;

alternating – both indicators, viewed together, shall alternate between two defined states,
and the two indicators shall always be in opposite states, out of phase;
flashing – each indicator, viewed independently, shall alternate between two states, and if
the indicators are flashing, they shall flash together, in phase.
A.2.3.4.2.2 Priority
The different states of the network status indicators shall follow a strict priority scheme. If
more than one condition exists, the network status indicators shall display the state with the
highest priority as specified in Table A.2.
Table A.2 – Network status indicators
Priority Indicator state How to view Cause
highest (1) both steady off viewed together reset or no power

2 both steady red failed link interface
3 alternating red / green self test
4 alternating red / off bad node configuration (such as duplicate MAC ID)
5 steady off viewed channel disabled or channel not supported
independently
6 flashing red / green invalid link configuration
7 flashing red / off link fault or no DLPDUs received
8 flashing green / off temporary channel error, or listen-only
lowest (9) steady green normal operation
A.2.3.4.2.3 Steady green
During normal operation, when DLPDUs are being received without detected errors, the
network status indicator for any enabled channel shall be steady green.
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 208 – 61158-4-2 © IEC:2007(E)
A.2.3.4.2.4 Steady red
If the link interface has faulted, both indicators shall be steady red.
A.2.3.4.2.5 Steady off
If one of the PhL entities is disabled, the indicator for the disabled channel shall be off. A
channel can be disabled either because the device has only a single PhL or because it has
two PhLs but exists on a non-redundant link. Only deactivating the entire network interface
shall cause both indicators to be extinguished (off).
A.2.3.4.2.6 Flashing green / off
A flashing green / off pattern shall signify a temporary channel error. The two channels shall
be treated independently with respect to these errors. An error on channel A shall be
indicated by any of three events:
Ph_status_indication from channel A does not equal Normal;
DLL_badFCS_indication(CHA) is asserted;
DLL_event_indication(DLL_EV_errA) is asserted.
Likewise, an error on channel B shall be indicated by any of three events:
Ph_status_indication from channel B does not equal Normal;
DLL_badFCS_indication(CHB) is asserted;
DLL_event_indication(DLL_EV_errB) is asserted.
If more than one error occurs in a single DLPDU, only one channel error shall be declared.
There shall be at most one error event per DLPDU per channel. Each PhL shall have an
independent Ph_status_indication. The Data Link Layer shall report errors on at least
the channel selected for presentation to higher levels. The DLL may also report errors on the
other channel.
The flashing green state shall be entered whenever a channel error is detected. The flashing
green state shall transition to the steady green state if no errors are detected for 4 s ± 1 s on
a given channel.
--`,,```,,,,````-`-`,,`,,`,`,,`---
When the Data Link Layer is in a listen-only state, the indicator for any enabled channels shall
flash green.
NOTE The ControlNet object can be used to force the Data Link Layer to enter the listen-only state.
A.2.3.4.2.7 Flashing red / off
A flashing red / off pattern shall signify a severe link error. If the Ph_frame_indication
from one of channels remains false for a 1,0 s ± 0,1 s period, the respective indicator shall
assume the flashing red state for the next 1,0 s ± 0,1 s period.
For devices with redundant channels enabled, if the error rate for one of the channels
exceeds that of the other channel by more than one error per N DLPDUs received, then the
channel with the higher rate shall flash red. N shall be in the range 10 6 through 2×10 6 . The
interval used to measure channel error rate shall be 5×10 6 DLPDUs.

61158-4-2 © IEC:2007(E) – 209 –
A.2.3.4.2.8 Flashing red / green
A flashing red / green pattern shall signify a bad link configuration. The network status
indicators shall enter the flashing red / green state if the network attachment monitor (NAM)
indicates that the node has been asked to use invalid or unsupported link parameters.
To optionally indicate a receive queue overflow or a transmit queue underflow, the network
status indicators shall enter the flashing red / green state. The network status indicators shall
remain in this state at least 3 s even if the overflow condition has cleared.
A.2.3.4.2.9 Alternating red / off
An alternating red / off pattern shall signify an invalid node configuration. This state shall be
entered if the DLL_event_indication has either of the following values:
DLL_EV_dupNode;
DLL_EV_rogue.
This state shall be left immediately when the error condition clears.
A.2.3.4.2.10 Alternating red / green
An alternating red / green pattern shall signify that the Data Link Layer is in a self-test mode.
The network status indicators shall remain in this state for at least 3 s even if the self-test has
completed.
A.2.3.4.3 Labeling
The network status indicators shall be labeled using the symbols drawn in Figure A.1 and
Figure A.2. The first channel shall be labeled with the outline of a channel icon. The second
channel shall be labeled with a filled in channel icon. The first and second channels may be
labeled with an uppercase A and B, respectively.
Devices supporting non-redundant media
Both status indicators

- LED A is labelled with outline of icon and letter A.
- LED B is unlabelled.
one media connector:

labelled with icon and letter A
Figure A.1 – Non redundant network status indicator labeling

--`,,```,,,,````-`-`,,`,,`,`,,`---

– 210 – 61158-4-2 © IEC:2007(E)
Devices supporting redundant media
Both status indicators

- LED A is labelled with outline of icon and letter A
- LED B is labelled with a solid icon and letter B
A B
two media connectors :

- one labelled with outline of icon and letter A
A
- one labelled with a solid icon and letter B
Figure A.2 – Redundant network status indicator labeling

--`,,```,,,,````-`-`,,`,,`,`,,`---
CP 2/2 does not require a device to have indicators.
Two types of status indicators may be provided:

— one or several network status indicators.
NOTE 1 The fieldbus supporting consortia (see <www.odva.org>) defines an Industrial Performance Level that
requires a device to support both the module status and network status indicators as specified in this standard.
NOTE 2 A device with more than one communication port would have only one module status indicator, but more
than one network status indicator (one per port).
NOTE 3 Devices are encouraged to have an indicator that displays the state of link (e.g. link status, tx/rx,
collision) following generally accepted industry practices (as used in devices such as switches).
An indicator test shall be performed at power-up. To allow a visual inspection, the following
sequence shall be performed:
— first indicator green, all other indicators off;

— first indicator on green for approximately 0,25 s;
— first indicator on red for approximately 0,25 s;
— first indicator on green;
— second indicator (if present) on green for approximately 0,25 s;
— second indicator (if present) on red for approximately 0,25 s;
— second indicator (if present) off.
If other indicators are present, each indicator shall be tested in sequence as prescribed by the
second indicator above. If a Module Status indicator is present, it shall be the first indicator in
the sequence, followed by any Network Status indicator present. After completion of this
power up test, the indicator(s) shall turn to a normal operational state.

61158-4-2 © IEC:2007(E) – 211 –
The module status indicator shall be labeled with one of the following:
“MS”;
“Mod”;
“Mod status”;
“Module status”.
A.2.4.4 Network status indicators
The indication of network status shall require a single bicolor (red/green) indicator that
represents the state of a single communication port.
NOTE A device with more than one communication port would have one network status indicator per port.
A.2.4.4.2 States
The network status indicator states shall be as specified in Table A.3.
Table A.3 – Network status indicator
Indicator state Summary Cause
Steady off Not powered, If the device does not have an IP address (or is powered
no IP address off), the network status indicator shall be steady off
Flashing green No connections If the device has no established connections, but has
obtained an IP address, the network status indicator shall be
flashing green
Steady green Connected If the device has at least one established connection (even
to the Message Router), the network status indicator shall
be steady green
Flashing red Connection timeout If one or more of the connections in which this device is the
target has timed out, the network status indicator shall be
flashing red. This shall be left only if all timed out
connections are reestablished or if the device is reset
Steady red Duplicate IP If the device has detected that its IP address is already in
use, the network status indicator shall be steady red
Flashing green / red Self-test While the device is performing its power up testing, the
network status indicator shall be flashing green / red
A.2.4.4.3 Labeling
The network status indicator shall be labeled with one of the following:
“NS”;
“Net”;
“Net Status”;
“Network Status”.
CP 2/3 does not require a device to have indicators.
If a device supports indicators, then it is recommended to provide:

--`,,```,,,,````-`-`,,`,,`,`,,`---

– 212 – 61158-4-2 © IEC:2007(E)
— one status indicators;
or a combined module/network status indicator.
A device may also support I/O status indicators.
If there is a conflict between turning an indicator on red versus green, the indicator shall be
turned on red.
A.2.5.2.1 Module and network status indicators at power up
— network status indicator off;

— module status indicator on green for approximately 0,25 s;
— module status indicator on red for approximately 0,25 s;
— module status indicator on green;
— network status indicator on green for approximately 0,25 s;
— network status indicator on red for approximately 0,25 s;
— network status indicator off.
If a device has other indicators each indicator should be tested in sequence.
A.2.5.2.2 Combined module/network status indicators at power up
— combined module/network status indicator on green for approximately 0,25 s;

--`,,```,,,,````-`-`,,`,,`,`,,`---
— combined module/network status indicator on red for approximately 0,25 s;

— combined module/network status indicator off.
If a device has other indicators each indicator should be tested in sequence.
The module status indicator should be labeled with one of the following:
“MS”;
“Module status”.
A.2.5.4 Network status indicator
This bicolor (green/red) indicator provides the status of the communication link.

61158-4-2 © IEC:2007(E) – 213 –
A.2.5.4.2 States
The network status indicator states shall be as specified in Table A.4. See the Link Access
State Transition Diagram in IEC 62026-3 to compare the network status indcator to the
Network Access State machine.
Table A.4 – Network status indicator
Steady off Not powered/ Device is not on–line.

not on–line
– The device has not completed the Dup_MAC_ID test yet.
– The device may not be powered, look at module status
indicator.
– No network power present
Flashing green a On–line, not Device is on–line but has no connections in the established
connected state.
– The device has passed the Dup_MAC_ID test, is on–line,
but has no established connections to other nodes.
– For a Group 2 Only device it means that this device is not
allocated to a master.
– For a UCMM capable device it means that the device has
no established connections
Steady green Link OK, on–line, The device is on–line and has connections in the
connected established state.
– For a Group 2 Only device it means that the device is
allocated to a Master.
one or more established connections
Flashing red a Connection time–out One or more I/O Connections are in the Timed–Out state
Steady red Critical link failure Failed communication device. The device has detected an
error that has rendered it incapable of communicating on the
network (duplicate MAC ID, or Bus–off)
Flashing Communication A specific Communication Faulted device. The device has
red / green b faulted and received detected a Network Access error and is in the
an Identify Comm Communication Faulted state. The device has subsequently
Fault request - long received and accepted an Identify Communication Faulted
protocol request - long protocol message
a Indicator flash rates are given in A.2.2.3.
b Indicator flash rates are given in IEC 62026-3.

--`,,```,,,,````-`-`,,`,,`,`,,`---
A.2.5.4.3 Labeling
The network status indicator should be labeled with one of the following:
“NS”;
“Network Status”.

– 214 – 61158-4-2 © IEC:2007(E)
A.2.5.5 Combined module/network status indicator
This bicolor (green/red) indicator provides limited device and communication status. The
combined module/network status indicator indicates whether or not the device has power and
is operating properly.
A.2.5.5.2 States
The combined module/network status indicator states shall be as specified in Table A.5. See
the Link Access State Transition Diagram in IEC 62026-3 to compare the combined
module/network status indicator to the Network Access State machine.
Table A.5 – Combined module/network status indicator
Steady off Device not powered/ Device is not on–line.

not on–line
– The device has not completed the Dup_MAC_ID test yet.
– The device may not be powered
Steady green Device operational The device is operating in a normal condition and the device
and on–line, is on–line with connections in the established state.
connected
– For a Group 2 Only device it means that the device is
allocated to a Master.
one or more established connections
Flashing green a Device operational The device is operating in a normal condition and the device
and on–line, not is on–line with no connections in the established state.
connected
or – The device has passed the Dup_MAC_ID test, is on–line,
Device on–line and but has no established connections to other nodes.
device needs – For a Group 2 Only device it means that this device is not
commissioning allocated to a master.
no established connections.
– Configuration missing, incomplete or incorrect
Flashing red a Minor Fault and/or Any one or more of the following conditions.
connection time–out
and/or no network – Recoverable fault.
power – One or more I/O connections are in the Timed–Out state.
– No network power present
Steady red Critical fault or critical The device has an unrecoverable fault; may need replacing.
link failure
Failed communication device. The device has detected an
error that has rendered it incapable of communicating on the
network (duplicate MAC ID, or Bus–off)
Flashing Communication A specific Communication Faulted device. The device has
red / green b faulted and received detected a Network Access error and is in the
an identify comm fault Communication Faulted state. The device has subsequently
--`,,```,,,,````-`-`,,`,,`,`,,`---
request - long received and accepted an Identify Communication Faulted

protocol request - long protocol message
a Indicator flash rates are given in A.2.2.3.
b Indicator flash rates are given in IEC 62026-3.

61158-4-2 © IEC:2007(E) – 215 –
A combined module/network status indicator shall not be used for safety devices.
A.2.5.5.3 Labeling
The combined module/network status indicator should be labeled with one of the following:
“MNS”;
“Mod/Net Status”;
“Module/Network Status”.
A.2.5.6 I/O status indicator
This bicolor (green/red) indicator provides information concerning the states of inputs and/or
outputs.
The intent of the I/O Status indicator is to inform the user whether this device has outputs
under control and whether any outputs or inputs are active (e.g. outputs active, inputs
producing) or faulted. The indicator is intended to reflect the mode/state of the inputs and
outputs, not necessarily the on/off condition of the I/O points themselves.
A.2.5.6.2 States
The specific definition of the I/O status indicator colors and states reside in the individual
definitions of the corresponding application objects that specify the use of this indicator.
Table A.6 provide guidelines governing the use of the I/O status indicator.
Table A.6 – I/O status indicator
Steady off Output(s) inactive All outputs are inactive.

Input(s) inactive All inputs are inactive
Steady green Output(s) active One or more outputs are active and under control, and no
Input(s) active outputs are “faulted”.
One or more inputs are active and producing data, and no
inputs are “faulted”
Flashing green Output(s) idle One or more outputs are idle and no outputs are active nor
“faulted”
Flashing red Output(s) faulted One or more outputs are “faulted”, maybe in the fault state.
Inputs(s) faulted One or more inputs are “faulted”, maybe in the fault state
Steady red Output(s) forced off One or more outputs are forced off (may be an
Input unrecoverable unrecoverable Fault).
fault One or more inputs has an unrecoverable faul
NOTE Indicator flash rates are given in A.2.2.3.
A.2.5.6.3 Labeling
The I/O status indicator should be labeled with one of the following:
“IO”;
“I/O”;
“I/O status”.
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 216 – 61158-4-2 © IEC:2007(E)
A.3 Switches
A.3.1 Common switch requirements
A.3.1.1 General
All switches shall behave in the same way for the same function. For example, all network
address switches for devices shall behave in the same way.
If a device has switches, then it is recommended that the device provides the means by which
the switch setting can be determined remotely using messaging services.
A.3.1.2 Software override of switches
If a user accessible switch (e.g. MAC ID or bit rate switch) can be overwritten by software,
then an indicator shall be present that indicates whether or not it has been overwritten.
If an attribute is configurable with a switch and it cannot be overwritten with software, then the
device shall respond with the error “Attribute not settable” to a service which attempts to set
the attribute.
A.3.1.3 Times that switches are valid
Switches shall comply with either of the following rules:
— the switch shall be live at all times;

— the switch shall be live only at power turn on (PTO).
A.3.2 Fieldbus specific switch requirements (1)
A.3.2.1 Network address switches
A.3.2.1.1 Appearance
If the MAC ID is able to be set using switches, they shall be indicated in decimal format. This
may be accomplished by using a rotary, thumbwheel, pushwheel, or other type of switch. The
most significant digit shall be to the left or to the top of the least significant digit.
A.3.2.1.2 When to read switch
Network address switches shall only be read at power turn on (PTO). If the network address
switches are changed after power turn on, a minor fault shall be detected and the module
status indicator shall indicate a non-critical fault (flashing red). The MAC ID of the node used
by the Data Link Layer shall remain at the value read during PTO. The current setting of the
network address switches shall be stored in the ControlNet object so that another node may
remotely diagnose the non-critical fault.
A.3.2.1.3 Labeling
The network address switches shall be labeled with one of the following:
“NA”;
“address”;
“net address”.
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 217 –
There are no switch requirements for CP 2/2.
A.3.4.1 Network address switches
If DIP switches are used to set the MAC ID they shall be in binary format. If rotary,
thumbwheel or pushwheel switches are used, then decimal format is required. The most
significant digit shall always be to the left or to the top of the device when the user is trying to
configure the switches.
A.3.4.1.2 Labeling
The network address switches shall be labeled with one of the following:
“NA”;
“Node Address”.
A.3.4.2 Bit rate switches
If switches are used to set the CP 2/3 bit rate they shall be encoded as specified in Table A.7.
Table A.7 – Bit rate switch encoding
Bit rate Switch setting
125 kbit/s 0
250 kbit/s 1
500 kbit/s 2
A.3.4.2.2 Labeling
The bit rate switches shall be labeled with one of the following:
“DR”;
“Data Rate”.
--`,,```,,,,````-`-`,,`,,`,`,,`---

– 218 – 61158-4-2 © IEC:2007(E)
Bibliography
IEC/TR 61158-1 (Ed.2.0), Industrial communication networks – Fieldbus specifications – Part

1: Overview and guidance for the IEC 61158 and IEC 61784 series
IEC 61784-1 (Ed.2.0), Industrial communication networks – Profiles – Part 1: Fieldbus profiles
IEC 61784-2, Industrial communication networks – Profiles – Part 2: Additional fieldbus

profiles for real-time networks based on ISO/IEC 8802-3
ISO/IEC 8802 (all parts), Information technology – Telecommunications and information

exchange between systems – Local and metropolitan area networks
ISO/IEC 9314-2, Information processing systems – Fibre Distributed Data Interface (FDDI) –
Part 2: Token Ring Media Access Control (MAC)
ANSI X3.66, Advanced data communication control procedures (ADCCP)
ANSI X3.159, Information Systems – Programming Language C
ANSI X3J16 / ISO WG21 committee draft working paper for a C++ standard
Internet Engineering Task Force (IETF), Request for Comments (RFC):
RFC 791, Internet Protocol

(available at <http://www.ietf.org/rfc/rfc0791.txt>)
RFC 793, Transmission Control Protocol

RFC 1213, Management Information Base for Network Management of TCP/IP-based

internets : MIB-I (available at <http://www.ietf.org/rfc/rfc1213.txt>)
RFC 1643, Definitions of Managed Objects for the Ethernet-like Interface Types
th
IETF <draft-ietf-dhc-fqdn-option-12.txt>: February 24 , 2006,The DHCP Client FQDN
Option (available at <http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-12.txt>)
ODVA: THE CIP NETWORKS LIBRARY – Volume 1: Common Industrial Protocol (CIPTM) –
Edition 3.1, November 2006, available at <http://www.odva.org>
ODVA: THE CIP NETWORKS LIBRARY – Volume 2: EtherNet/IPTM Adaptation of CIP –

ODVA: THE CIP NETWORKS LIBRARY – Volume 3: DeviceNetTM Adaptation of CIP –

ControlNet International: THE CIP NETWORKS LIBRARY – Volume 4: ControlNetTM

Adaptation of CIP – Edition 1.1, December 2005, available at <http://www.controlnet.org>
--`,,```,,,,````-`-`,,`,,`,`,,`---

61158-4-2 © IEC:2007(E) – 219 –
INDEX
Addressing
service access points
single (DLSAP-address), 16
single or group of (DL(SAP)-address), 15
DL(SAP)-address. See Addressing, service access points, single or group
DLSAP, 15
DLSAP-address. See Addressing, service access points, single
Link
extended, 16
local, 15
Type 2
DLPDU, 18
fixed tag, 18
generic tag, 18
guardband, 18
moderator, 19, 20
______________
--`,,```,,,,````-`-`,,`,,`,`,,`---

--`,,```,,,,````-`-`,,`,,`,`,,`---

--`,,```,,,,````-`-`,,`,,`,`,,`---

--`,,```,,,,````-`-`,,`,,`,`,,`---
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
3, rue de Varembé
P.O. Box 131
CH-1211 Geneva 20
Switzerland
Tel: + 41 22 919 02 11
Fax: + 41 22 919 03 00
[email protected]
www.iec.ch


4 2 PDF

Uploaded by

Document Informationclick to expand document information

Document Informationclick to expand document information

Copyright:

Available Formats

4 2 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

4 2 PDF

Uploaded by

Copyright:

Available Formats

IEC 61158-4-2

Edition 1.0 2007-12

Copyright International Electrotechnical Commission

IEC Central Office

About the IEC

About IEC publications

Copyright International Electrotechnical Commission

Industrial communication networks – Fieldbus specifications –

Copyright International Electrotechnical Commission

Copyright International Electrotechnical Commission

7.1 General ................................................................................................................. 65

9.5 Transmit machine (TxM) ...................................................................................... 191

Figure 1 – Relationships of DLSAPs, DLSAP-addresses and group DL-addresses ................ 15

Copyright International Electrotechnical Commission

Figure 19 – Keeper object operating state diagram ............................................................... 95

Table 1 – Data-link layer components ................................................................................... 24

Table 33 – Keeper object state event matrix ......................................................................... 96

Copyright International Electrotechnical Commission

Table 36 – Scheduling object common services .................................................................. 100

Table 74 – Connection configuration object revision history ................................................ 132

Copyright International Electrotechnical Commission

Table 79 – Target connection status values ........................................................................ 138

Table 99 – Get_Status service error codes ......................................................................... 150

Copyright International Electrotechnical Commission

INTERNATIONAL ELECTROTECHNICAL COMMISSION

INDUSTRIAL COMMUNICATION NETWORKS –

Part 4-2: Data-link layer protocol specification – Type 2 elements

Copyright International Electrotechnical Commission

FDIS Report on voting

Copyright International Electrotechnical Commission

a) as a guide for implementors and designers;

Copyright International Electrotechnical Commission

INDUSTRIAL COMMUNICATION NETWORKS –

Part 4-2: Data-link layer protocol specification – Type 2 elements

This protocol provides communication opportunities to all participating data-link entities,

Deterministic and synchronized transfers can be provided at cyclic intervals up to 1 ms and

This standard specifies

The procedures are defined in terms of

Copyright International Electrotechnical Commission

These procedures are applicable to instances of communication between systems which

Profiles provide a simple multi-attribute means of summarizing an implementation’s

IEC 61131-3, Programmable controllers – Part 3: Programming languages

IEC 61158-2 (Ed.4.0), Industrial communication networks – Fieldbus specifications – Part 2:

IEC 61158-5-2, Industrial communication networks – Fieldbus specifications – Part 5-2:

IEC 61158-6-2, Industrial communication networks – Fieldbus specifications – Part 6-2:

IEC 62026-3 1, Low-voltage switchgear and controlgear – Controller-device interfaces (CDIs) –

ISO/IEC 3309, Information technology – Telecommunications and information exchange

ISO/IEC 7498-1, Information technology – Open Systems Interconnection – Basic Reference

ISO/IEC 7498-3, Information technology – Open Systems Interconnection – Basic Reference

ISO/IEC 8802-3, Information technology – Telecommunications and information exchange

Copyright International Electrotechnical Commission

ISO/IEC 10731, Information technology – Open Systems Interconnection – Basic Reference

ISO 11898:1993 2, Road vehicles – Interchange of digital information – Controller area

3 Terms, definitions, symbols and abbreviations

3.1 Reference model terms and definitions

3.1.1 called-DL-address [ISO/IEC 7498-3]

3.1.2 calling-DL-address [ISO/IEC 7498-3]