M \2009 03 04\~$blank pdf Industrial communication networks — Fieldbus specifications — Part 3 7 Data link layer service definition — Type 7 elements BS EN 61158 3 7 2008 raising standards worldwide™[.]
Overview
IEC 61158 outlines essential components for time-critical messaging communications in automation settings The term "time-critical" indicates a specific time-window during which certain actions must be completed reliably If these actions are not performed within the designated timeframe, it could jeopardize the applications involved, posing risks to equipment, facilities, and potentially human safety.
This standard outlines the externally visible service of the Type 7 fieldbus data-link layer by defining the primitive actions and events involved, detailing the parameters linked to each action and event, and describing their interrelationships and 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.
Specifications
This standard aims to define the features of conceptual data-link layer services designed for time-sensitive communications, enhancing the OSI Basic Reference Model to aid in the creation of data-link protocols for such applications Additionally, it seeks to offer pathways for transitioning from existing industrial communication protocols.
This specification serves as a foundational guideline for formal DL-Programming-Interfaces However, it is important to note that it does not constitute a formal programming interface Any developed interface must tackle implementation challenges not addressed in this specification, such as the sizes and octet ordering of multi-octet service parameters, as well as the correlation between paired request and confirm, or indication and response, primitives.
Conformance
This standard does not specify individual implementations or products, nor does it constrain the implementations of data-link entities within industrial automation systems
Equipment does not conform to the data-link layer service definition standard directly Instead, conformance is attained by implementing the relevant data-link protocol that meets the Type 7 data-link layer services outlined in this standard.
The referenced documents are essential for the application of this document For dated references, only the specified edition is applicable, while for undated references, the most recent edition, including any amendments, is relevant.
ISO/IEC 7498-1, Information technology – Open Systems Interconnection – Basic Reference
ISO/IEC 7498-3, Information technology – Open Systems Interconnection – Basic Reference
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.
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.2 confirm (primitive); requestor.deliver (primitive)
3.2.7 indication (primitive); acceptor.deliver (primitive)
3.2.9 request (primitive); requestor.submit (primitive)
3.2.11 response (primitive); acceptor.submit (primitive)
Data-link service terms and definitions
The acknowledgment response DLPDU is the information sent by the recipient of an acknowledged message to indicate whether the message was received correctly or if there are insufficient resources to store it This response is received by the DLE on the local link that originally sent the message requesting acknowledgment.
The basic cycle sequence of the bus-arbitrator involves scanning a set of DLCEP-identifiers for variables, requests, and cyclical application messages Additionally, it includes a designated window for aperiodic exchanges, a window for message services, and a window for synchronization.
3.3.3 basic transaction succession of DLPDUs related to a single DL-service instance
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
A DL-segment is a local link within a single DL-subnetwork that allows connected DLEs to communicate directly This direct communication occurs without the need for DL-relaying, provided that all participating DLEs are attentive to the DL-subnetwork during the communication attempts.
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
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
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
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
DLS-user-entity DLS-user-entity
DLSAP- addresses group DL- address
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
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
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
The end of message transaction indication DLPDU is a signal emitted by the source entity of a message to relinquish link access control to the bus-arbitrator after completing a message transaction.
A DL-subnetwork is defined as the largest collection of links connected by DL-relays that share a common DL-name (DL-address) space Within this subnetwork, any connected DL-entities can communicate with each other directly or through one or more intervening DL-relay entities.
NOTE An extended link may be composed of just a single link
3.3.16 frame denigrated synonym for DLPDU
A DL-address can indicate multiple DLSAPs within an extended link Additionally, a single DL-entity may be linked to several group DL-addresses associated with one DLSAP, or it may have one group DL-address connected to multiple DLSAPs.
3.3.18 identified variable (or simply "variable")
DLL system variable for which an associated DLCEP-identifier has been defined
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
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
The request response DLPDU refers to the information sent by the initiator when explicitly requesting a buffer transfer, which is associated with a specific request identifier DLPDU This information is then received by the bus-arbitrator.
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
The turnaround time refers to the interval between the reception or emission of the last MAC symbol of a Data Link Protocol Data Unit (DLPDU), indicated by a SILENCE signal from the Physical Layer (PhL), and the reception or emission of the first MAC symbol of the subsequent DLPDU, indicated by an ACTIVITY signal from the PhL, as measured at a specific 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.
Symbols and abbreviations
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
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)
3.4.5 DL- Data-link layer (as a prefix)
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.10 DLPCI DL-protocol-control-information
3.4.11 DLPDU DL-protocol-data-unit
3.4.13 DLME DL-management Entity (the local active instance of
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.20 Ph- Physical layer (as a prefix)
3.4.21 PhE Ph-entity (the local active instance of the physical layer)
3.4.23 Q_IDRQ1/2 Queue for the DL-identifiers requested, received by the BA at priority
3.4.24 Q_Msg_Aper Queue which contains messages to be emitted that are associated with aperiodic exchanges
3.4.25 Q_Msg_Cyc Queue which contains messages to be emitted that are associated 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)
3.4.28 RQ_Inhibit Indicator used to manage explicit requests for buffer transfers
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
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 presents a tabular format to outline the component parameters of DLS primitives It details the applicable parameters for each group of DLS primitives in tables throughout the document Each table features up to six columns, including the service parameter name and columns for the associated primitives and parameter-transfer directions utilized 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)
Each row of the tables contains a specific parameter, with corresponding codes under the relevant service primitive columns that indicate the parameter's usage type and direction.
M — parameter is mandatory for the primitive;
The parameter U is an optional user setting that may be included based on the dynamic needs of the DLS user If it is not specified, a default value will be utilized for this parameter.
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
The symbol "(=)" signifies that the parameter is semantically equivalent to the one immediately to its left in the service primitive table Additionally, the letter "b" indicates that a specific note pertains 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 illustrating the sequence of primitives consist of vertical lines that denote the user-DLL interface, arrowed lines that indicate the temporal sequence of primitives at the interface, and dotted lines that establish the relationships between the primitives In the absence of dotted lines, the action is considered local There are two distinct types of dotted lines utilized in these diagrams.
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
4 Data-link layer services and concepts
Field of application, object
This standard applies to a data-link layer appropriate for the exchange of data between transmitters, actuators, and programmable controllers within a manufacturing process
This standard outlines the DLL services, focusing on two key aspects: a) the services available at the conceptual interface between the DLE and DLS users, and b) the function 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.
General description of services
The article discusses two types of data transmission services: the first type facilitates connection-oriented buffer transfers between pre-established point-to-multipoint Data Link Connections (DLCs) on the same local link, while the second type manages acknowledged or unacknowledged connectionless message transfers between individual Data Link Service Access Points (DLSAPs), as well as unacknowledged message transfers from a single DLSAP to a group of DLSAPs over an extended link.
The standard term for data exchanged among DLS users is DLS-user-data (DLSDU) as defined by ISO/IEC 7498-1 To enhance clarity, the terms "buffer transfer" and "message transfer" are utilized to differentiate between the two types of communication services provided by this DLS: connection-oriented and connectionless, respectively.
There are also two types of buffer transfer services:
Cyclical buffer transfer involves the automatic triggering of data exchanges by the communications system, based on predefined variable names and periods established during system configuration to meet application requirements.
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:
Cyclical message transfers are automatically initiated by the communications system based on predefined resources and time periods, which are established during system configuration according to application requirements.
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
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 limited to local links, allowing for the identification of variables and exchanges independently of the producing and consuming DLEs During system configuration, all relationships among various DLS users are defined for buffer transfers Each DLCEP identifier uniquely characterizes a system variable, establishing a clear relationship between the variable's publisher and its subscribers.
Buffer transfers operate within the local broadcast medium, limited to the local link The DLCEP-identifier and the variable's value are accessible to all DLEs on this link This identifier enables each DLE to determine its role as either a publisher or a subscriber of the value linked to the specified variable.
Message transfers utilize the local broadcast medium and bridges to navigate the extended link During this transaction, two DLSAP addresses are specified to facilitate communication between the entities The first is a 24-bit destination DLSAP address, which encodes the link ID of the destination local link and the sub-address of the destination DLSAP or group of DLSAPs within that link The second is a 24-bit source DLSAP address, encoding the link ID of the source DLE's local link and the sub-address of the source DLSAP within that 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
Dynamic flow control for variable exchange is not needed, as the data volume from cyclical traffic remains constant This volume is determined by configuring the system to align with local link capacity.
Subscribers store only the last value received; a new exchange overrides the previous value
An acknowledgement mechanism regulates the flow of message transfers, while sequence numbering prevents message duplication A subscriber will only accept a message if it has the capacity to store it, ensuring that no message can overwrite a previously received one.
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
4.2.5 Overall description of medium allocation
The bus-arbitrator (BA) is a crucial element that regulates data publishers' access to the medium by emitting a DLPDU with a link-local DL-identifier, which can be either a DLSAP-address or a DLCEP-address It is essential that only one active bus-arbitrator exists on each local link at any given time.
Each transaction is categorized into one of three medium allocation classes: a) cyclical buffer transfers, message transfers, or service request polling; b) explicit requests for buffer transfers; and c) explicit requests for message transfers.
4.2.5.2 Cyclical buffer transfers, message transfers or service request polling
The bus-arbitrator executes transactions in a predetermined sequence, starting the next transaction only after the previous one is completed, following the guidelines established during system configuration.
The procedure for each type of transaction is as follows:
A buffer transfer transaction involves several key phases: first, the bus-arbitrator broadcasts a variable DLCEP-identifier DLPDU, followed by the sole publisher of the required information broadcasting a variable response DLPDU During this phase, subscribers retrieve the information from the local link Figure 2 illustrates the different phases of a buffer transfer transaction.
The term "publisher" refers to the designated DLE on the local link responsible for emitting the variable linked to the bus-arbitrator-emitted DLCEP-identifier DLPDU that immediately precedes it Conversely, a "subscriber" is any DLE configured to receive copies of the published variable and provide those copies 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
In a message transfer, a fundamental transaction involves several key phases: first, the bus-arbitrator broadcasts a message known as the DL-identifier DLPDU Next, the designated DLE responds by sending a message DLPDU If this message is directed to a specific DLSAP and requires an acknowledgment, the corresponding DLE associated with that DLSAP-address will send back an acknowledgment DLPDU.
Sequences of primitives
4.3.1 Constraints on services and primitives
There is no specific order in the execution of the different services
A request primitive allows the DLS-user to initiate a service, while a confirmation primitive is sent back to the DLS-user upon the service's completion Additionally, an indication primitive notifies the DLS-user of new DLS-User Data or the arrival of a new message.
The DL-services and their parameters are summarized in Table 1
Table 1 – Summary of DL-services and primitives for buffer transfers
DL-P UT request (in DLCEP-identifier,
DLS-user-data) Update Buffer
DL-P UT confirm (out Status) DL-G ET request (in DLCEP-identifier) Copy Buffer
DL-G ET confirm (out DLS-user data,
Status) DL-B UFFER -S ENT indication (out DLCEP-identifier) Buffer transfer
DL-S PEC -U PDATE request (in Specified DL-identifier,
List of DL-identifiers requested) DL-S PEC -U PDATE confirm (out Status)
DL-F REE -U PDATE request (in List of DL-identifiers requested,
Explicit request for buffer transfer
DL-F REE -U PDATE confirm (out Status)
NOTE The method by which a confirm primitive is correlated with its corresponding preceding request primitive is a local matter
The DL-services and their parameters are summarized in Table 2
Table 2 – Summary of DL-services and primitives for message exchanges
DL-M ESSAGE request (in Specified DL-identifier,
Destination DL(SAP)-Address, Source DLSAP-Address, DLS-user-data)
DL-M ESSAGE indication (out Destination DL(SAP)-Address,
Source DLSAP-Address DLS-user-data)
DL-M ESSAGE confirm (out Status)
Acknowledged message transfer DL-M ESSAGE -A CK request (in Specified DL-identifier,
Destination DLSAP-Address, Source DLSAP-Address, DLS-user-data)
(out Destination DLSAP-Address, Source DLSAP-Address, DLS-user-data)
DL-M ESSAGE -A CK confirm (out Status)
NOTE The method by which a confirm primitive is correlated with its corresponding preceding request primitive is a local matter.
Buffer writing
The DLS-user can utilize this service to transfer data to the local DLE for future buffer transfers, with the DLE acting as the publisher Key operations involved in this process include the DL-PUT request and the DL-PUT confirm.
The sequence of primitives in a successful buffer writing is shown in Figure 3:
Figure 3 – Primitives associated with the buffer writing service
4.4.3 Types of primitives and parameters
Table 3 indicates the types of primitives and parameters of writing a buffer
Table 3 – DL-Put primitives and parameters
DLCEP-identifier M DLS-user-data M
NOTE The method by which a confirm primitive is correlated with its corresponding preceding request primitive is a local matter
The DL-PUT request enables DLS-users to send variable values (DLS-user-data) to the DLE, which can then utilize this data for future buffer transfers at the designated DLCEP.
This parameter clearly identifies the variable within the local link, corresponding to a variable published by the DLE It may appear as either a local identifier or a link-local DLCEP address.
This parameter replaces the value previously stored in the buffer associated with the corresponding DLCEP-identifier The maximum amount of data which can be stored in a buffer is 128 octets
NOTE One expected application-service-entity, MPS (IEC 61158-5-7), uses DLS-user-data that is always two octets or more in length
A DL-PUT confirm primitive follows a DL-PUT request primitive and provides an account on the progress of the action requested
This parameter indicates the status of the writing operation, which can have several outcomes: a) success, meaning the operation was completed successfully; b) failure due to a semantic error in the request, such as an unknown DLCEP-identifier or exceeding the supported buffer size of 128 octets; c) failure caused by an invalid DLCEP-identifier, which may be invalidated by System Management; and d) failure resulting from issues accessing the buffer linked to the variable, indicating buffer availability problems.
This last status value indicates that the DLE is concurrently accessing the buffer and that the implementation does not support that concurrency.
Buffer reading
This service allows DLS-user data to be transferred from the DLE to the DLS-user Associated primitives are DL-GET request and DL-GET confirm
The sequence of primitives in a successful buffer reading is shown in Figure 4:
Figure 4 – Primitives associated with the buffer reading service
4.5.3 Types of primitives and parameters
Table 4 indicates the type of primitives and parameters of reading a buffer:
Table 4 – DL-Get primitives and parameters
NOTE The method by which a confirm primitive is correlated with its corresponding preceding request primitive is a local matter
DL-GET request allows the DLS-user to read the value of a variable received through the DLL
Use of the primitive does not erase the stored value, which can be reread by another similar DL-GET request primitive
This parameter clearly identifies the variable within the local link, corresponding to a variable subscribed by the DLE It may appear as either a local identifier or a link-local DLCEP address.
A DL-GET confirm primitive follows a DL-GET request primitive and provides an account on the progress of the requested action
This parameter indicates the status of the variable's value reading, with possible outcomes including: a) success, meaning the reading operation was completed successfully; b) failure due to an unknown DLCEP-identifier; c) failure caused by an invalid DLCEP-identifier, which may be invalidated by System Management; and d) failure resulting from issues accessing the buffer linked to the variable, indicating buffer availability problems.
This last status value indicates that the DLE is concurrently accessing the buffer and that the implementation does not support that concurrency
When the Status parameter indicates Success, this parameter reveals the last value stored in the buffer linked to the specific DLCEP-identifier The buffer can hold a maximum of 128 octets of data.
Buffer transfer
This service notifies the DLS-user of each time that a published variable is sent or received Associated primitives are DL-BUFFER-SENT indication and DL-BUFFER-RECEIVED indication
The sequence of primitives in a successful buffer transfer is shown in Figure 5:
DL-BUFFER-RECEIV ED Indication
Figure 5 – Primitives associated with the buffer transfer service
4.6.3 Types of primitives and parameters
Table 5 indicates the type of primitives and parameters for a buffer sent indication
Table 5 – DL-Buffer-Sent primitive and parameter
DL-B UFFER -S ENT Indication Parameter name input DLCEP-identifier M
A DL-BUFFER-SENT indication informs the DLS-user that the published variable associated with the specified DLCEP-identifier has just been emitted on the bus
NOTE The buffer associated with that DLCEP-identifier may have been written previously by the DLS-user using the DL-P UT request primitive
This parameter unambiguously designates the variable that has just been emitted on the bus It can take the form of a local identifier or of a link-local DLCEP-address
Table 6 indicates the type of primitives and parameters for a buffer received indication
Table 6 – DL-Buffer-Received primitive and parameter
DL-B UFFER -R ECEIVED Indication Parameter name input DLCEP-identifier M
The DL-BUFFER-RECEIVED indication notifies the DLS-user that a subscribed identified variable has been successfully received The variable's value is now accessible in the B_Dat_Cons buffer linked to the variable and can be retrieved using the DL-GET request primitive.
This parameter unambiguously designates the variable that has just been received by the subscribing DLE It can take the form of a local identifier or of a link-local DLCEP-address
The DLS-user can access the current value of the variable by reading the buffer associated with that DLCEP-identifier (DL-GET).
Explicit request for buffer transfer
This service enables an entity to explicitly request the broadcasting of multiple link-local DLCEP addresses, facilitating the exchange of associated variables.
The service offers two types of options: a) an explicit request for a buffer transfer, which is associated with a specified DLCEP-identifier at the time of the service request, known as a specified explicit request.
A DLS-user, who may be a publisher or subscriber of the requested variable(s), initiates this request The fulfillment occurs during the bus-arbitrator's regular or irregular scanning cycles, based on the configuration settings.
The associated primitives include the DL-SPEC-UPDATE request and the DL-SPEC-UPDATE confirm Additionally, when a service is requested, the explicit request for a buffer transfer is not tied to a DL-identifier, which is referred to as a free explicit request.
A DLS-user, who may be a publisher or subscriber, initiates the request for specific variable(s) This request is processed during the bus-arbitrator's aperiodic scanning cycle.
Associated primitives are DL-FREE-UPDATE request and DL-FREE-UPDATE confirm
NOTE A single DLCEP-identifier cannot be configured concurrently for both a specified explicit request and a free explicit request
With the free explicit request service, two levels of priority (urgent and normal) are possible
W ith the specified explicit request service only urgent priority is offered
When the bus-arbitrator receives an (specified or free) explicit request for a buffer transfer it initiates a transaction in conformance with the buffer transfer service described in 4.2.5.2.2
NOTE Two types of service are provided for explicit requests for buffer transfer because of the possible uses of this service
The explicit request service includes a feature that allows for the overriding of prior requests Each DLCEP-identifier designated for this service is equipped with a buffer for potential requests, which holds lists of DL-identifiers that have been explicitly requested for broadcasting.
A request associated with a given specified DL-identifier thus overrides any previous request using that DL-identifier
A specific request linked to a DLCEP identifier can be processed during the bus-arbitrator's regular or irregular scanning cycles There is a method to select between these two scanning types by specifying whether the request should go through the bus-arbitrator.
The explicit request service enables the fulfillment of a buffer transfer during the periodic scanning cycle of the bus arbitrator Additionally, the recovery service offered by the DLS user can be utilized, as outlined in the relevant documentation.
The free explicit request service has a mechanism for placing requests in a queue Two queues for requests are provided: one for urgent requests, and one for other requests
A DLCEP-identifier's attachment to one of these latter queues is dynamic
The DLCEP-identifier that carries the request is chosen by the DLE
The selected DLCEP-identifier is the one associated with the first DLPDU emitted on the medium after the service request, provided it was not previously configured to support the specified explicit request service.
The free explicit request service enables quick integration of a buffer transfer request into the bus-arbitrator's regular scanning process, as the request is conveyed through the initial response from the requesting DLE for a designated DLCEP-identifier.
In the protocol, a single request-response DLPDU is generated, regardless of multiple requests stored in the two queues, while the number of confirmation primitives corresponds to the number of requests Furthermore, there are additional restrictions on the implementation of this service.
1) a request response DLPDU is limited to a maximum of 64 DL-identifiers, and
All DL-identifiers included in a single free explicit request must be transmitted to the bus-arbitrator within the same DLPDU response; they cannot be divided between two separate DLPDUs.
4.7.2 Specified explicit request sequence of primitives
The sequence of primitives in a successful specified explicit update is shown in Figure 6:
Figure 6 – Primitives associated with the specified explicit request for a buffer transfer
4.7.3 Specified explicit request primitives and parameters
Table 7 indicates the types of primitives or parameters needed for a specified explicit update
Table 7 – DL-Spec-Update primitives and parameters
DL-S PEC -U PDATE Request Confirm
Specified DLCEP-identifier M List Of Requested DL-identifiers M
NOTE The method by which a confirm primitive is correlated with its corresponding preceding request primitive is a local matter
A DL-SPEC-UPDATE request enables the DLS-user to request the circulation of specific identified variables, while designating the DLCEP for transmitting the request to the bus-arbitrator This action overrides all prior requests associated with the same DLCEP.
The DLCEP-identifier specified in this parameter is responsible for carrying the buffer transfer request A DLS-user initiates a request when the corresponding variable response is emitted for the selected DLCEP-identifier It is essential that this identifier is part of the periodic section of the bus-arbitrator's scanning table and is configured for the DL-SPEC-UPDATE service, rather than the DL-FREE-UPDATE service.
If the DLCEP-identifier is properly configured, the request associated with the specified DLCEP-identifier is fulfilled as part of the bus-arbitrator's periodic scanning
4.7.3.4 List of requested DL-identifiers
This parameter specifies the list of DL-identifiers associated with the variables that the requester wants broadcast This list is destined for the bus-arbitrator; it contains a maximum of
ADL-SPEC-UPDATE confirm follows a DL-SPEC-UPDATE request and provides the DLS-user with the status of the requested exchange
The parameter signifies that the bus-arbitrator has acknowledged the request to broadcast one or more DL-identifiers and has transmitted the corresponding list However, this primitive does not ensure that the bus-arbitrator has successfully received the list, nor does it confirm that the requested associated variables have been exchanged.
Unacknowledged message transfer
The DLL offers DLS-users a connectionless unacknowledged message transfer service For aperiodic message transfers, it utilizes a buffer transfer service from the source DLE to request service opportunities from the bus-arbitrator In contrast, for cyclical message transfers, the bus-arbitrator circulates message DL-identifier DLPDUs within the periodic window.
Unacknowledged message services can operate in either point-to-point or multipoint configurations within an extended link In multipoint scenarios, messages are directed to a group distribution list (DL-address) recognized by one or more destination link entities (DLEs) When a transaction involves multiple local links, the message must traverse these links sequentially to reach its intended DLEs, creating an acyclic subgraph of the extended link Bridge DLEs, acting as DL-relays, facilitate the transfer of messages between successive links in this subgraph, ensuring the message is sent to the appropriate destination DLEs.
In unacknowledged message transfer services, the message initiator serves as the source Conversely, in cyclical message transfer, the bus-arbitrator periodically circulates the message DL-identifier, regardless of any requests from the source DLE.
The sequence of primitives in a successful unacknowledged message transfer is shown in Figure 8
Figure 8 – Primitives associated with the unacknowledged message transfer request service
4.8.3 Types of primitives and parameters
Table 9 indicates the types of primitives or parameters for an unacknowledged message transfer:
Table 9 – DL-Message primitives and parameters
DL-M ESSAGE Request Indication Confirm
Parameter name input input output
NOTE The method by which a confirm primitive is correlated with its corresponding preceding request primitive is a local matter
A DL-MESSAGE request allows a DLS-user to request the transmission of an unacknowledged message to the specified DL(SAP)-address
If the message transfer is cyclical, this parameter is a DL-identifier configured for cyclical message service This DL-identifier is linked to a queue for messages to be emitted
In cases of aperiodic message transfer, the parameter is set to NIL, allowing service requests to be directed to the queue designated for aperiodic messages.
This parameter specifies a DLSAP-address or group DL-address, identifying the DLSAP or group of DLSAPs which is the destination of the message
This parameter specifies the local DLSAP, associated with the DLS-user, which is to be the attributed source of the message
This parameter specifies the information which is being conveyed between the corresponding DLS-users
A DL-MESSAGE indication signals the arrival of an unacknowledged message to a DLS-user associated with the destination DL(SAP)-address
NOTE This parameter does not indicate whether the sender’s mode of transfer was aperiodic or cyclical
A DL-MESSAGE confirm provides the initiating DLS-user with a report on the transmission of an unacknowledged message
This parameter enables DLS users to assess the success or failure of the requested DLS The outcomes are as follows: a) success indicates that the message was sent, b) failure occurs when the message queue is full, with immediate confirmation, and c) failure also arises if the specified DL-identifier is unknown or not configured for the service, which also results in immediate confirmation.
Acknowledged message transfer
The DLL offers DLS-users a connectionless acknowledged message transfer service For aperiodic message transfers, it utilizes a buffer transfer service from the source DLE to request service opportunities from the bus-arbitrator In contrast, for cyclical message transfers, the bus-arbitrator circulates message DL-identifier DLPDUs within a periodic window.
Acknowledged message transfers occur point-to-point within the extended link, requiring sequential passage across multiple local links if the transaction involves more than one Each link facilitates an acknowledgment from the receiving DLE, which can be either a forwarding bridge or the intended destination DLE, back to the transmitting DLE, whether it is the original sender or a forwarding bridge This acknowledgment confirms the successful transmission and reception on that specific local link.
NOTE This standard does not further specify the role of the bridge DLE Requirements for bridges are specified in IEC 61158-4-7
In the recognized message transfer service, the request initiator serves as the message source Conversely, in the cyclical message transfer service, the message DL-identifier is regularly circulated by the bus-arbitrator, regardless of whether the source DLE has made any requests.
The sequence of primitives in a successful acknowledged message transfer is shown in Figure 9:
Figure 9 – Primitives associated with the acknowledged message transfer request service
4.9.3 Types of primitives and parameters
Table 10 indicates the types of primitives or parameters needed for an acknowledged message transfer
Table 10 – DL-Message-Ack primitives and parameters
DL-M ESSAGE -A CK Request Indication Confirm
Parameter name input input output
NOTE The method by which a confirm primitive is correlated with its corresponding preceding request primitive is a local matter See 1.2
ADL-MESSAGE-ACK request allows a DLS-user to request the transmission of an acknowledged message to the specified DLSAP-address
If the message transfer is cyclical, this parameter is a DL-identifier configured for cyclical message service This DL-identifier is linked to a queue for messages to be emitted
In cases of aperiodic message transfer, the parameter is set to NIL, allowing service requests to be directed to the queue designated for aperiodic message transfers.
This parameter specifies the DLSAP which is the destination of the message
This parameter specifies the local DLSAP, associated with the DLS-user, which is to be the attributed source of the message
This parameter specifies the information which is being conveyed between the corresponding DLS-users
A DL-MESSAGE-ACK indication signals the arrival of an acknowledged message to the DLS-user associated with the destination DLSAP-address
NOTE This parameter does not indicate whether the sender’s mode of transfer was aperiodic or cyclical
A DL-MESSAGE-ACK confirm provides the initiating DLS-user with a report on the transmission and initial reception of an acknowledged message
This parameter enables DLS users to assess the success or failure of the requested DLS It indicates: a) success, meaning the message was positively acknowledged by either the addressed DLE or an intermediate bridge; b) failure due to the destination DLE's queue for received messages being full; and c) failure because the queue for messages to be emitted is also full.
NOTE The confirmation is immediate in this case d) failure — the specified DL-identifier is unknown or not configured for this service,
NOTE The confirmation is immediate in this case e) failure — expiration of the acknowledgement DLPDU reception timer or faulty transmission
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 61158-2 (Ed.4.0), Industrial communication networks – Fieldbus specifications – Part 2: Physical layer specification and service definition
IEC 61158-4-7, Industrial communication networks – Fieldbus specifications – Part 4-7: Data- link layer protocol specification – Type 7 elements
IEC 61158-5-7, Industrial communication networks – Fieldbus specifications – Part 5-7: Application layer service definition – Type 7 elements
IEC 61158-6-7, Industrial communication networks – Fieldbus specifications – Part 6-7: Application layer protocol specification – Type 7 elements
IEC 61784-1 (Ed.2.0), Industrial communication networks – Profiles – Part 1: Fieldbus profiles