IEC 61158-3-7:2007

IEC 61158-3-7
Edition 1.0 2007-12
INTERNATIONAL
STANDARD
Industrial communication networks – Fieldbus specifications –
Part 3-7: Data-link layer service definition – Type 7 elements

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: inmail@iec.ch
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: csc@iec.ch
Tel.: +41 22 919 02 11
Fax: +41 22 919 03 00
IEC 61158-3-7
Edition 1.0 2007-12
INTERNATIONAL
STANDARD
Industrial communication networks – Fieldbus specifications –
Part 3-7: Data-link layer service definition – Type 7 elements

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
PRICE CODE
V
ICS 35.100.20; 25.040.40 ISBN 2-8318-9413-1

– 2 – 61158-3-7 © IEC:2007(E)
CONTENTS
FOREWORD.4
INTRODUCTION.6
1 Scope.7
1.1 Overview .7
1.2 Specifications .7
1.3 Conformance.7
2 Normative references.8
3 Terms, definitions, symbols, abbreviations and conventions .8
3.1 Reference model terms and definitions .8
3.2 Service convention terms and definitions .9
3.3 Data-link service terms and definitions.9
3.4 Symbols and abbreviations .13
3.5 Common conventions .14
4 Data-link layer services and concepts .16
4.1 Field of application, object .16
4.2 General description of services .16
4.3 Sequences of primitives.21
4.4 Buffer writing .22
4.5 Buffer reading.24
4.6 Buffer transfer .25
4.7 Explicit request for buffer transfer .26
4.8 Unacknowledged message transfer.30
4.9 Acknowledged message transfer.32
Bibliography .35

Figure 1 – Relationships of DLSAPs, DLSAP-addresses and group DL-addresses .11
Figure 2 – General description of medium allocation.20
Figure 3 – Primitives associated with the buffer writing service .23
Figure 4 – Primitives associated with the buffer reading service.24
Figure 5 – Primitives associated with the buffer transfer service .25
Figure 6 – Primitives associated with the specified explicit request for a buffer transfer.28
Figure 7 – Primitives associated with the free explicit request for a buffer transfer .29
Figure 8 – Primitives associated with the unacknowledged message transfer request
service .31
Figure 9 – Primitives associated with the acknowledged message transfer request
service .33

Table 1 – Summary of DL-services and primitives for buffer transfers .22
Table 2 – Summary of DL-services and primitives for message exchanges .22
Table 3 – DL-Put primitives and parameters .23
Table 4 – DL-Get primitives and parameters.24
Table 5 – DL-Buffer-Sent primitive and parameter .26
Table 6 – DL-Buffer-Received primitive and parameter .26
Table 7 – DL-Spec-Update primitives and parameters .28
Table 8 – DL-Free-Update primitives and parameters .30

61158-3-7 © IEC:2007(E) – 3 –
Table 9 – DL-Message primitives and parameters .31
Table 10 – DL-Message-Ack primitives and parameters.33

– 4 – 61158-3-7 © IEC:2007(E)
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
INDUSTRIAL COMMUNICATION NETWORKS –
FIELDBUS SPECIFICATIONS –
Part 3-7: Data-link layer service definition – Type 7 elements

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.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
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 of their respective intellectual-property-right holders.
International Standard IEC 61158-3-7 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-3 subseries cancel and replace
IEC 61158-3:2003. This edition of this part constitutes an editorial revision.
This edition includes the following significant changes with respect to 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 3-1, 3-2, …, 3-19.

61158-3-7 © IEC:2007(E) – 5 –
The text of this standard is based on the following documents:
FDIS Report on voting
65C/473/FDIS 65C/484/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.

– 6 – 61158-3-7 © IEC:2007(E)
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.
Throughout the set of fieldbus standards, the term “service” refers to the abstract capability
provided by one layer of the OSI Basic Reference Model to the layer immediately above. Thus,
the data-link layer service defined in this standard is a conceptual architectural service,
independent of administrative and implementation divisions.

61158-3-7 © IEC:2007(E) – 7 –
INDUSTRIAL COMMUNICATION NETWORKS –
FIELDBUS SPECIFICATIONS –
Part 3-7: Data-link layer service definition – Type 7 elements

1 Scope
1.1 Overview
This part of IEC 61158 provides common elements for basic time-critical messaging
communications between devices in an automation environment. The term “time-critical” is
used to represent the presence of a time-window, within which one or more specified actions
are required to be completed with some defined level of certainty. Failure to complete specified
actions within the time window risks failure of the applications requesting the actions, with
attendant risk to equipment, plant and possibly human life.
This standard defines in an abstract way the externally visible service provided by the Type 7
fieldbus data-link layer in terms of
a) the primitive actions and events of the service;
b) the parameters associated with each primitive action and event, and the form which they
take; and
c) the interrelationship between these actions and events, and their valid sequences.
The purpose of this standard is to define the services provided to
• the Type 7 fieldbus application layer at the boundary between the application and data-link
layers of the fieldbus reference model, and
• systems management at the boundary between the data-link layer and systems
management of the fieldbus reference model.
1.2 Specifications
The principal objective of this standard is to specify the characteristics of conceptual data-link
layer services suitable for time-critical communications, and thus supplement the OSI Basic
Reference Model in guiding the development of data-link protocols for time-critical
communications. A secondary objective is to provide migration paths from previously-existing
industrial communications protocols.
This specification may be used as the basis for formal DL-Programming-Interfaces.
Nevertheless, it is not a formal programming interface, and any such interface will need to
address implementation issues not covered by this specification, including
a) the sizes and octet ordering of various multi-octet service parameters, and
b) the correlation of paired request and confirm, or indication and response, primitives.
1.3 Conformance
This standard does not specify individual implementations or products, nor does it constrain the
implementations of data-link entities within industrial automation systems.
There is no conformance of equipment to this data-link layer service definition standard.
Instead, conformance is achieved through implementation of the corresponding data-link
protocol that fulfills the Type 7 data-link layer services defined in this standard.

– 8 – 61158-3-7 © IEC:2007(E)
2 Normative references
The following referenced documents are indispensable for the application of this document. For
dated references, only the edition cited applies. For undated references, the latest edition of
the referenced document (including any amendments) applies.
ISO/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 10731, Information technology – Open Systems Interconnection – Basic Reference
Model – Conventions for the definition of OSI services
3 Terms, definitions, symbols, abbreviations and conventions
For the purposes of this document, the following terms, definitions, symbols, abbreviations and
conventions 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 DL-address [7498-3]
3.1.2 DL-connection [7498-1]
3.1.3 DL-connection-end-point [7498-1]
3.1.4 DL-connection-end-point-identifier [7498-1]
3.1.5 correspondent (N)-entities [7498-1]
correspondent DL-entities  (N=2)
correspondent Ph-entities  (N=1)
3.1.6 (N)-entity [7498-1]
DL-entity  (N=2)
Ph-entity  (N=1)
[7498-1]
3.1.7 flow control
[7498-1]
3.1.8 (N)-layer
DL-layer  (N=2)
Ph-layer  (N=1)
3.1.9 DL-name [7498-3]
3.1.10 peer-entities [7498-1]
3.1.11 primitive name [7498-3]
3.1.12 DL-protocol [7498-1]
3.1.13 DL-protocol-connection-identifier [7498-1]
3.1.14 DL-protocol-data-unit [7498-1]

61158-3-7 © IEC:2007(E) – 9 –
3.1.15 DL-relay [7498-1]
3.1.16 (N)-service [7498-1]
DL-service  (N=2)
Ph-service  (N=1)
3.1.17 (N)-service-access-point [7498-1]
DL-service-access-point  (N=2)
Ph-service-access-point  (N=1)
[7498-1]
3.1.18 DL-service-data-unit
[7498-1]
3.1.19 DLS-user-data
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 confirm (primitive);
requestor.deliver (primitive)
3.2.3 deliver (primitive)
3.2.4 DL-service-primitive;
primitive
3.2.5 DL-service-provider
3.2.6 DL-service-user
3.2.7 indication (primitive);
acceptor.deliver (primitive)
3.2.8 multi-peer
3.2.9 request (primitive);
requestor.submit (primitive)
3.2.10 requestor
3.2.11 response (primitive);
acceptor.submit (primitive)
3.2.12 submit (primitive)
3.3 Data-link service terms and definitions
3.3.1
acknowledgement response DLPDU
information that the recipient of an acknowledged message emits in order to signal either the
proper reception of the message or the lack of available resources to store the message,
received by the DLE on the local link that emitted the message which requested the
acknowledgement
– 10 – 61158-3-7 © IEC:2007(E)
3.3.2
basic cycle
sequence of scanning by the bus-arbitrator of
a) a set of DLCEP-identifiers for variables, requests, and cyclical application messages;
b) plus a window provided for aperiodic exchanges;
c) plus a window provided for message services;
d) plus a window provided for synchronization
3.3.3
basic transaction
succession of DLPDUs related to a single DL-service instance
3.3.4
bus-arbitrator (BA)
DLE that controls each data producer's right to access the medium
NOTE  At any given instant one and only one bus-arbitrator is active in each DL-segment of a DL-subnetwork.
3.3.5
control field
portion of an emitted or received DLPDU that gives the nature of the data exchanged and the
type of exchange
3.3.6
destination address
three octets specifying the DL-segment of the DLE to whom the message is sent, and the
destination DLSAP’s sub-address within the local link
3.3.7
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
3.3.8
DL-segment, local link
set of devices that respect the DL-protocol and that are interconnected through a PhL. Only
one bus-arbitrator is active on a single DL-segment
3.3.9
DLCEP-identifier
two octets specifying a link-local DLCEP-identifier associated with a system variable. A
DLCEP-identifier uniquely designates a single DL-accessible variable within the local link
3.3.10
DLCEP-identifier DLPDU
information that a bus-arbitrator emits to allocate the local link to a data publisher for the
purpose of exchanging a variable
3.3.11
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.

61158-3-7 © IEC:2007(E) – 11 –
DLS-user-entity
DLS-user-entity
DLS-users
DLSAP DLSAP DLSAP
DLSAP-
address DLSAP-
DLSAP-
group DL-
address
addresses
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.12
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.
3.3.13
(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.14
end of message transaction indication DLPDU
information that the source entity of a message emits in order to return link access control to
the bus-arbitrator at the end of a message transaction
3.3.15
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.

– 12 – 61158-3-7 © IEC:2007(E)
3.3.16
frame
denigrated synonym for DLPDU
3.3.17
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.18
identified variable (or simply "variable")
DLL system variable for which an associated DLCEP-identifier has been defined
3.3.19
invalid DLCEP-identifier
DLCEP-identifier not recognized locally
3.3.20
macrocycle
set of basic cycles needed for all cyclical DLCEP-identifiers to be scanned
3.3.21
message DLPDU identifier
information that a bus-arbitrator emits to allocate the medium to a source DLE for a message
transfer
3.3.22
message response DLPDU
information that a data publisher emits in response to a message identifier DLPDU. This
information is received and retained by the desired destination entity or entities
3.3.23
node
single DL-entity as it appears on one local link
3.3.24
periodic scanning of variables
action by the bus-arbitrator that guarantees the cyclical exchange of variables
NOTE  This is the basic principle of the Type 7 DL-service and protocol.
3.3.25
published identified variable
variable that corresponds to a DLCEP-identifier for which the DLE emits data
3.3.26
receiving DLS-user
DL-service user that acts as a recipient of DLS-user-data
NOTE  A DL-service user can be concurrently both a sending and receiving DLS-user.
3.3.27
request DLPDU identifier
the information that a bus-arbitrator emits to allocate the medium to the initiator of an explicit
request for a buffer transfer
61158-3-7 © IEC:2007(E) – 13 –
3.3.28
request response DLPDU
the information that the initiator of an explicit request for a buffer transfer emits in response to
a request identifier DLPDU. This information is received by the bus-arbitrator
3.3.29
sending DLS-user
DL-service user that acts as a source of DLS-user-data
3.3.30
source address
three octets specifying the local link-id of the entity sending the message, and the source
DLSAP’s sub-address within the local link
3.3.31
subscribed identified variable
variable that corresponds to a DLCEP-identifier for which the DLE receives data
3.3.32
triggered message scanning
function of a bus-arbitrator that makes it possible to transfer messages
3.3.33
triggered periodic scanning of messages
function of a bus-arbitrator that makes it possible to request triggered message exchanges
cyclically
3.3.34
triggered periodic scanning of variables
function of a bus-arbitrator that makes it possible to request triggered variable transfers
cyclically
3.3.35
triggered scanning of variables
function of a bus-arbitrator that makes possible the non-cyclical exchange of variables
3.3.36
turnaround time
time interval between reception or emission of the last MAC symbol of a DLPDU, signaled by a
SILENCE indication from the PhL, and the reception or emission of the first MAC symbol of the
subsequent DLPDU, signaled by an ACTIVITY indication from the PhL, both as measured in a
given station
3.3.37
variable response DLPDU
information that a data producer emits in response to a DLCEP-identifier DLPDU, which also
alerts data consumers to the relevance of the immediately time-proximate DLPDU.
3.4 Symbols and abbreviations
3.4.1 BA Bus-arbitrator
3.4.2 B_Dat_Cons Buffer which contains the value of the subscribed data
3.4.3 B_Dat_Prod Buffer which contains the value of the published data

– 14 – 61158-3-7 © IEC:2007(E)
3.4.4 B_Req1/2 Buffer containing the list of DL-identifiers that are the object of a
specified explicit request for a transfer at the priority 1 (urgent) or 2
(normal)
Data-link layer (as a prefix)
3.4.5 DL-
3.4.6 DLC DL-connection
3.4.7 DLCEP DL-connection-end-point
3.4.8 DLE DL-entity (the local active instance of the data-link layer)
3.4.9 DLL DL-layer
3.4.10 DLPCI DL-protocol-control-information
3.4.11 DLPDU DL-protocol-data-unit
3.4.12 DLM DL-management
3.4.13 DLME DL-management Entity (the local active instance of
DL-management)
3.4.14 DLMS DL-management Service
3.4.15 DLS DL-service
3.4.16 DLSAP DL-service-access-point
3.4.17 DLSDU DL-service-data-unit
3.4.18 FIFO First-in first-out (queuing method)
3.4.19 OSI Open systems interconnection
3.4.20 Ph- Physical layer (as a prefix)
Ph-entity (the local active instance of the physical layer)
3.4.21 PhE
Ph-layer
3.4.22 PhL
Queue for the DL-identifiers requested, received by the BA at priority
3.4.23 Q_IDRQ1/2
1 (urgent) or 2 (normal)
Queue which contains messages to be emitted that are associated
3.4.24 Q_Msg_Aper
with aperiodic exchanges
Queue which contains messages to be emitted that are associated
3.4.25 Q_Msg_Cyc
with cyclical exchanges
3.4.26 Q_Req1/2 Queue containing the list of DL-identifiers that are the object of a
free explicit request for a transfer at the priority 1 (urgent) or 2
(normal)
Quality of service
3.4.27 QoS
Indicator used to manage explicit requests for buffer transfers
3.4.28 RQ_Inhibit
3.5 Common conventions
This standard uses the descriptive conventions given in ISO/IEC 10731.
The service model, service primitives, and time-sequence diagrams used are entirely abstract
descriptions; they do not represent a specification for implementation.

61158-3-7 © IEC:2007(E) – 15 –
Service primitives, used to represent service user/service provider interactions (see ISO/IEC
10731), convey parameters that indicate information available in the user/provider interaction.
This standard uses a tabular format to describe the component parameters of the DLS
primitives. The parameters that apply to each group of DLS primitives are set out in tables
throughout the remainder of this standard. Each table consists of up to six columns, containing
the name of the service parameter, and a column each for those primitives and parameter-
transfer directions used by the DLS:
⎯ the request primitive’s input parameters;
⎯ the request primitive’s output parameters;
⎯ the indication primitive’s output parameters;
⎯ the response primitive’s input parameters; and
⎯ the confirm primitive’s output parameters.
NOTE  The request, indication, response and confirm primitives are also known as requestor.submit,
acceptor.deliver, acceptor.submit, and requestor.deliver primitives, respectively (see ISO/IEC 10731).
One parameter (or part of it) is listed in each row of each table. Under the appropriate service
primitive columns, a code is used to specify the type of usage of the parameter on the primitive
and parameter direction specified in the column:
M — parameter is mandatory for the primitive;
U — parameter is a User option, and may or may not be provided depending on
the dynamic usage of the DLS-user. When not provided, a default value for
the parameter is assumed;
C — parameter is conditional upon other parameters or upon the environment of
the DLS-user;
(blank) — parameter is never present.
Some entries are further qualified by items in brackets. These may be
a) a parameter-specific constraint
(=) indicates that the parameter is semantically equivalent to the parameter in the
service primitive to its immediate left in the table.
b) an indication that some note applies to the entry
(n) indicates that the following note n contains additional information pertaining to the
parameter and its use.
In any particular interface, not all parameters need be explicitly stated. Some may be implicitly
associated with the DLSAP at which the primitive is issued.
The diagrams used to describe the sequence of primitives are composed of:
a) vertical lines, representing the user-DLL interface;
b) lines with arrows representing the time sequence of the primitives at the interface;
c) dotted lines, defining the relationships between the primitives. When no dotted lines exist,
the action is local. Two types of dotted lines are used:
1) long, crossing the service provider area to reach the remote user, defining a direct
action on the remote entity;
2) short, beginning or ending at the middle of the service provider area. This defines an
action to or from the bus-arbitrator.

– 16 – 61158-3-7 © IEC:2007(E)
4 Data-link layer services and concepts
4.1 Field of application, object
4.1.1 Field of application
This standard applies to a data-link layer appropriate for the exchange of data between
transmitters, actuators, and programmable controllers within a manufacturing process.
4.1.2 Object
This standard specifies the DLL services. The object is to define:
a) the services provided at the conceptual interface between the DLE and the DLS-users, and
b) the role of the bus-arbitrator.
The standard is based on services provided by the physical layer (IEC 61158-2) to the
conceptual interface between the physical and data-link layers.
4.2 General description of services
4.2.1 General
Two types of data transmission services are provided:
a) the first handles connection-oriented buffer transfers between pre-established point-to-
multipoint DLCs on the same local link;
b) the second handles acknowledged or unacknowledged connectionless message transfers
between single DLSAPs, or unacknowledged message transfers from a single DLSAP to a
group of DLSAPs on the extended link.
NOTE  The standard term for data exchanged between DLS-users is DLS-user-data, or DLSDU [ISO/IEC 7498-1].
For purposes of clarity, the expressions "buffer transfer" and "message transfer" are used to distinguish between
the two types of communications services, connection-oriented and connectionless, respectively, that are offered by
this DLS,
There are also two types of buffer transfer services:
1)- cyclical buffer transfer. Variable names and periods are defined when the system is
configured, and are based on application needs. Cyclical exchanges are automatically
triggered by the communications system without the user requesting them,
2) explicit request for buffer transfer. Upon user request the value(s) of one or more
variables are circulated.
The message transfer service also has two forms:
3) cyclical messages transfer. Resources and periods are defined when the system is
configured and are based on application needs. Cyclical transfers are automatically
triggered by the communications system without the user requesting them,
4) aperiodic message transfer. Upon user request one or more messages are circulated.
4.2.2 Addressing
The DL-addressing model for a system includes two different types of addressing: one for
buffer transfer services and the other for message transfer services.
For buffer transfers: each variable in the system is associated with a DLCEP-identifier that
characterizes it within the system in a unique manner.
Entities participating in a buffer transfer are not identified explicitly. Rather, they are identified
indirectly as subscriber(s) or publisher of the identified variable.

61158-3-7 © IEC:2007(E) – 17 –
Each variable has only one publisher.
For message transfer: one or more DLSAP-addresses are defined within each DLE. These
DLSAP-addresses give access to a message transfer service.
Each DLSAP-address identifies an access point to a message service linked to a DLS-user
entity.
Variable addressing is restricted to the local link. The addressing mechanism makes it possible
to identify variables and exchanges independent of the producing and consuming DLEs. For
buffer transfers all relationships between the various DLS-users are known and defined when
the system is configured. Each DLCEP-identifier characterizes a single system variable and
thus establishes a relationship between the unique publisher of the variable and the
subscriber(s) of the variable.
Buffer transfers use the local broadcast medium and are restricted to the local link: the
DLCEP-identifier and the value of a variable are made available to all DLEs on the local link.
The DLCEP-identifier associated with the variable allows each DLE to recognize whether or not
it is the publisher or a subscriber of the value associated with the identified variable.
Message transfers use the local broadcast medium, and bridges to traverse the extended link.
During the message transaction two DLSAP-addresses are indicated in order to establish
contact between the communicating entities.
a) A 24-bit destination DL(SAP)-address that encodes the link-id of the destination local link
and the sub-address of the destination DLSAP or group of DLSAPs within that local link.
b) A 24-bit source DLSAP-address that encodes the link-id of the source DLE’s local link and
the sub-address of the source DLSAP within that local link.
Each DLSAP-address specifies a DLS-user of the message service (for both emission and
reception). This DL-address is unique within the extended link.
4.2.3 Flow control
Dynamic flow control for the exchange of variables is unnecessary. The volume of data
exchanged as a result of cyclical traffic is constant, and is defined upon configuration of the
system in a manner compatible with local link capacity.
Subscribers store only the last value received; a new exchange overrides the previous value.
An acknowledgement mechanism makes it possible to control message transfer flows. In
addition, sequence numbering of messages avoids message duplication. A subscriber accepts
a message only if that subscriber can store the message. In no case can a message overwrite
a previously received message.
4.2.4 Detection of DLPDU duplication/loss
Detection mechanisms apply to errors resulting from communications problems or out-of-
service DLEs.
DLPDU loss is accounted for in the finite state machines that describe the DL-protocol.
Duplication of a DLPDU can only occur with message transfers. The sequence numbering
mechanism makes it possible to detect message duplication and avoid delivery of duplicate
messages.
– 18 – 61158-3-7 © IEC:2007(E)
4.2.5 Overall description of medium allocation
4.2.5.1 General
An element known as the bus-arbitrator (BA) controls the right of each data publisher to
access the medium. It does this by emitting a DLPDU containing a link-local DL-identifier —
either a DLSAP-address or a DLCEP-address. At any given instant there should be only one
active bus-arbitrator on each local link.
Each transaction belongs to one of the three medium allocation classes defined below:
a) cyclical buffer transfers, message transfers or service request polling,
b) explicit request for buffer transfer,
c) explicit request for message transfer.
4.2.5.2 Cyclical buffer transfers, message transfers or service request polling
4.2.5.2.1 General
The bus-arbitrator initiates transactions in a configured order. When one transaction has been
completed the bus-arbitrator begins the following transaction according to guidelines defined
when the system is configured.
The procedure for each type of transaction is as follows:
4.2.5.2.2 Buffer transfer
For a buffer transfer, a basic transaction consists of the following phases.
a) The bus-arbitrator broadcasts a variable DLCEP-identifier DLPDU.
b) The sole publisher of the information required then broadcasts a variable response DLPDU.
During this phase subscribers take the information from the local link. Figure 2 shows the
various phases of a buffer transfer transaction.
NOTE  The term "publisher" designates the sole DLE connected to the local link that is configured as having the
responsibility of emitting the variable associated with the bus-arbitrator-emitted DLCEP-identifier DLPDU
immediately preceding on the local link. The term “subscriber” refers to any DLE which is configured to receive
copies of a published variable and make those copies available to an associated DLS-user.
During a buffer transfer the publisher can, using specific features of the response DLPDU,
transmit to the BA an explicit request for additional buffer transfers or message transfers.
4.2.5.2.3 Message transfer
For a message transfer, a basic transaction consists of the following phases.
a) The bus-arbitrator broadcasts a message DL-identifier DLPDU.
b) The addressed DLE sends a message DLPDU.
c) If the message DLPDU is addressed to a single DLSAP and requests an acknowledgement,
the DLE associated with that DLSAP-address sends an acknowledgement DLPDU.
Steps b) and c) may be repeated a limited number of times if an expected acknowledgment
DLPDU is not received error-free.
d) The originally-addressed DLE concludes the message exchange sequence by transmitting
an end-of-transaction DLPDU to the bus-arbitrator.
4.2.5.2.4 Service request polling
For a service request poll, a basic transaction consists of the following phases.
a) The bus-arbitrator broadcasts a request DL-identifier DLPDU.

61158-3-7 © IEC:2007(E) – 19 –
b) The initiator of the request replies with a request response DLPDU.
c) At a subsequent time of the bus-arbitrator’s choosing, one or more requested transactions
identical in form to the cyclical buffer transfer transaction follow.
4.2.5.3 Explicit request for buffer transfer
The bus-arbitrator services an explicit request for buffer transfer according to guidelines
4.2.5.2.2.
defined when the system is configured. The procedure employed is that of
4.2.5.4 Explicit request for message transfer
The bus-arbitrator services an explicit request for message transfer according to guidelines
defined when the system is configured. The procedure employed is that of 4.2.5.2.3.
4.2.5.5 Bus arbitrator basic principles
The time interval separating the reception or emission of the end of one DLPDU and the
emission or reception of the following DLPDU is known as the station's turn-around time,
whether the station's function be that of a publisher or subscriber, message originator or
receiver/acknowledger, or bus-arbitrator.
A more detailed definition of turn-around time, and the impact of turn-around time on
DL-timers, is given in the corresponding portion of IEC 61158-4-7.
The role of the bus-arbitrator is to "give the floor" to each variable publisher or message
originator, taking into account the services required according to the three medium allocation
classes just defined.
The bus-arbitrator thus has three types of functions.
a) Periodic triggering of buffer transfers, message transfers and request polling.
b) Triggered scanning of buffer transfers.
c) Triggered initiation of message transfers.
In addition, the bus-arbitrator can provide
d) a synchronization function in order to guarantee the constant length of scanning cycles.
Each of these four functions is provided in a specific window: a periodic window, an aperiodic
variable window, an aperiodic message window, and a synchronization window, respectively.
These four windows constitute a basic scanning cycle.

– 20 – 61158-3-7 © IEC:2007(E)
Phase 1: The Bus Arbitrator broadcasts a DLCEP-address

D : Device    A : (Bus) Arbitrator
D D D D
D D D A D
Phase 2: Recognition of this DLCEP-address:

— by the DLE which is the publisher for the DLC:
— by all other DLEs which subscribe to the DLC:

D D D D D
D D A D
Phase 3: The publishing DLE broadcasts the DLS-user-data from a local buffer

D
D D D A D D D
D
Phase 4: The subscribing DLEs receive the DLS-user-data into local buffers

D
D D D A D D D D
Figure 2 – General description of medium allocation
The medium access technique, shown in Figure 2, has the following characteristics:
1) broadcasting of identified variables;
2)- maximal efficiency in cyclical buffer transfers;
3 system Management can set parameters for medium sh
...