Industrial communication networks – Fieldbus specifications – Part 5-21: Application layer service definition – Type 21 elements Réseaux de communication industriels – Spécifications de
Overview
The Fieldbus Application Layer (FAL) provides user programs with a means to access the fieldbus communication environment In this respect, the FAL can be considered a window between corresponding application programs
This standard outlines essential components for both time-critical and non-time-critical messaging communications between application programs in automation environments, specifically addressing the Type 21 protocol "Time-critical" refers to a defined time-window in which certain actions must be completed with a specified level of certainty Failing to execute these actions within the designated time frame can jeopardize the applications involved, posing risks to equipment, facilities, and potentially human safety.
This standard outlines the externally visible service provided by the FAL, including an abstract model for application resources that users can manipulate, the primitive actions and events of the service, the parameters associated with each action and event, and the interrelationships and valid sequences of these actions and events.
This standard aims to outline the services offered to FAL-users at the interface between the user and the application layer of the fieldbus Reference Model, as well as to systems management at the junction of the application layer and systems management within the same model.
This standard describes the structure and services of the IEC FAL, in conformance with the
OSI Basic Reference Model (ISO/IEC 7498) and the OSI Application layer Structure
FAL services and protocols are provided by FAL application entities (AEs) contained in the application processes The FAL AE is composed of a set of object-oriented Application
Service Elements (ASEs) and a Layer Management Entity (LME) that manages the AE The
ASEs deliver communication services based on a series of interconnected application process object (APO) classes Among these, the management ASE within the FAL category offers a unified set of services for managing instances of FAL classes.
The services outlined specify the issuance and delivery of requests and responses from an application perspective, but do not dictate the actions of the requesting and responding applications This means that while the services define the types of requests and responses that can be sent or received, they do not constrain the functionality of the applications themselves, allowing FAL-users greater flexibility in standardizing object behavior Additionally, the standard includes supporting services that facilitate access to the FAL for controlling various operational aspects.
Specifications
The principal objective of this standard is to specify the characteristics of conceptual application layer services suitable for time-critical communications, and thus supplement the
OSI Basic Reference Model in guiding the development of application layer protocols for time- critical communications
A key goal is to establish migration paths from existing industrial communication protocols, leading to a variety of standardized services under IEC 61158 and its associated protocols outlined in IEC 61158-6.
This standard may be used as the basis for formal application programming interfaces
While this standard provides guidelines, it does not serve as a formal programming interface Any formal interface must tackle implementation challenges that are not addressed here, such as the sizes and octet ordering of multi-octet service parameters, as well as the correlation of paired primitives for requests and confirmations or indications and responses.
Conformance
This standard does not specify individual implementations or products, nor does it constrain the implementations of application layer entities in industrial automation systems
There is no conformance of equipment to this application layer service definition standard
Instead, conformance is achieved through the implementation of conforming application layer protocols that fulfill any given type of application layer services as defined in this standard
The essential documents required for this application are specified herein For references with dates, only the cited edition is applicable, while for undated references, the most recent edition, including any amendments, is considered valid.
IEC 60559, Binary floating-point arithmetic for microprocessor systems
IEC 61158-2:2010 1 , Industrial communication networks – Fieldbus specifications – Part 2:
Physical layer specification and service definition
IEC 61158-3-21:2010 1 , Industrial communication networks – Fieldbus specifications –
Part 3-21: Data-link layer service definition – Type 21 elements
IEC 61158-4-21:2010 1 , Industrial communication networks – Fieldbus specifications –
Part 4-21: Data-link layer protocol specification – Type 21 elements
IEC 61158-6-21:2010 1 , Industrial communication networks – Fieldbus specifications –
Part 6-21: Application layer protocol specification – Type 21 elements
ISO/IEC 7498-1, Information technology – Open Systems Interconnection – Basic Reference
ISO/IEC 7498-3, Information technology – Open Systems Interconnection – Basic Reference
ISO/IEC 8822, Information technology – Open Systems Interconnection – Presentation service definition
ISO/IEC 9545, Information technology – Open Systems Interconnection – Application layer structure
ISO/IEC 10731:1994, Information technology – Open Systems Interconnection – Basic
Reference Model – Conventions for the definition of OSI services
3 Terms, definitions, symbols, abbreviations, and conventions
Terms and definitions from other ISO/IEC standards
3.1.1 ISO/IEC 7498-1 terms a) application entity b) application process c) application protocol data unit d) application service element e) application entity invocation f) application process invocation g) application transaction h) real open system i) transfer syntax
3.1.2 ISO/IEC 8822 terms a) abstract syntax b) presentation context
3.1.3 ISO/IEC 9545 terms a) application-association b) application-context c) application context name d) application-entity-invocation e) application-entity-type f) application-process-invocation g) application-process-type h) application-service-element i) application control service element
Fieldbus data link layer terms
This document references key terms defined in IEC 61158-3-21:2010 and IEC 61158-4-21:2010, including DL-Time, DL-Scheduling-policy, DLCEP, DLC, DL-connection-oriented mode, DLPDU, DLSDU, DLSAP, link, ISO/IEC 8802-3:2000 MAC address, and DL-entity identifier.
Fieldbus application layer specific definitions
3.3.1 application function or data structure for which data are consumed or produced
3.3.2 application objects multiple object classes that manage and provide a runtime exchange of messages across the network and within the network device
3.3.3 application process part of a distributed application on a network, which is located on one device and addressed unambiguously
3.3.4 application process identifier distinguishes multiple application processes used in a device
3.3.5 application process object component of an application process that is identifiable and accessible through an FAL application relationship
Application process object definitions consist of attribute values specific to their class and can be accessed remotely through the FAL Object Management ASE These services enable users to load, update, read, create, and delete application objects and their definitions dynamically.
3.3.6 application process object class class of application process objects defined in terms of the set of their network-accessible attributes and services
3.3.7 application relationship cooperative association between two or more application-entity-invocations for the purpose of exchange of information and coordination of their joint operation
NOTE This relationship is activated either by the exchange of application-protocol-data-units or as a result of preconfiguration activities
3.3.8 application relationship application service element application-service-element that provides the exclusive means for establishing and terminating all application relationships
3.3.9 application relationship endpoint context and behavior of an application relationship as seen and maintained by one of the application processes involved in the application relationship
NOTE Each application process involved in the application relationship maintains its own application relationship endpoint
3.3.10 attribute description of an externally visible characteristic or feature of an object
Attributes of an object hold crucial information regarding its variable aspects, often providing status updates or controlling its operations Additionally, these attributes can influence the object's behavior.
Attributes are divided into class attributes and instance attributes
3.3.11 behavior indication of how an object responds to particular events
3.3.12 channel single physical or logical link of an input or output application object of a server to the process
3.3.13 class set of objects, all of which represent the same type of system component
A class serves as a blueprint for creating objects, defining their variables and methods While all objects within a class share the same structure and behavior, they typically hold distinct data in their attributes.
3.3.14 class attributes attribute shared by all objects within the same class
3.3.15 class code unique identifier assigned to each object class
3.3.16 class-specific service service defined by a particular object class to perform a required function that is not performed by a common service
NOTE A class-specific object is unique to the object class that defines it
3.3.17 client a) object that uses the services of another (server) object to perform a task b) initiator of a message to which a server reacts
3.3.18 consume act of receiving data from a producer
3.3.19 consumer node or sink that receives data from a producer
3.3.20 consuming application application that consumes data
3.3.21 conveyance path unidirectional flow of APDUs across an application relationship
3.3.22 cyclic repetitive in a regular manner
3.3.23 data consistency means for coherent transmission and access of the input- or output-data object between and within client and server
3.3.24 device physical hardware connected to the link
NOTE A device may contain more than one node
3.3.25 device profile a collection of device-dependent information and functionality providing consistency between similar devices of the same device type
3.3.26 diagnostic information all data available at the server for maintenance purposes
3.3.27 end node producing or consuming node
3.3.28 endpoint one of the communicating entities involved in a connection
3.3.29 error discrepancy between a computed, observed, or measured value or condition and the specified or theoretically correct value or condition
3.3.30 error class general grouping for related error definitions and corresponding error codes
3.3.31 error code identification of a specific type of error within an error class
3.3.32 event instance of a change of conditions
FIFO variable variable object class composed of a set of homogeneously typed elements, where the first written element is the first element that can be read
NOTE In a fieldbus system, only one complete element can be transferred as a result of one service invocation
3.3.34 frame simplified synonym for data link protocol data unit (DLPDU)
3.3.35 group a) (General): a general term for a collection of objects b) (Addressing): when describing an address, an address that identifies more than one entity
3.3.36 invocation act of using a service or other resource of an application process
Each invocation represents an independent thread of control defined by its context, and it ceases to exist once the service is completed or the resource is released An outstanding service invocation refers to a service that has been initiated but not yet completed To uniquely identify and differentiate between outstanding service invocations, an Invoke ID can be utilized.
3.3.37 index address of an object within an application process
3.3.38 instance actual physical occurrence of an object within a class that identifies one of many objects in the same object class
EXAMPLE California is an instance of the object class US-state
NOTE The terms object, instance, and object instance are used to refer to a specific instance
3.3.39 instance attributes attribute that is unique to an object instance and not shared by the object class
3.3.40 instantiated object that has been created in a device
3.3.41 logical device specific FAL class that abstracts a software component or a firmware component as an autonomous self-contained facility of an automation device
3.3.42 manufacturer ID identification of each product manufacturer by a unique number
3.3.43 management information network-accessible information that supports management of the operation of the fieldbus system, including the application layer
NOTE Managing includes functions, such as controlling, monitoring, and diagnosis
3.3.44 network set of nodes connected by some type of communication medium, including any intervening repeaters, bridges, routers, and lower-layer gateways
An object is an abstract representation of a specific component within a device, encompassing a collection of related data represented as variables It also includes methods, or procedures, for manipulating that data, all of which are characterized by a clearly defined interface and behavior.
3.3.46 object dictionary collection of definitions, communication-specific attributes and parameters, and application- dependent data
3.3.47 object-specific service service unique to the object class that defines it
3.3.48 physical device automation or other network device
3.3.49 point-to-point connection connection that exists between exactly two application objects
AR endpoint placed in an established state during configuration of the AEs that control its endpoints
3.3.51 process data object(s) that are already pre-processed and transferred cyclically for the purpose of information or further processing
3.3.52 produce act of sending data to be received by a consumer
3.3.53 producer node that is responsible for sending data
3.3.54 property general term for descriptive information about an object
3.3.55 provider source of a data connection
3.3.56 publisher role of an AR endpoint that transmits APDUs onto the fieldbus for consumption by one or more subscribers
NOTE A publisher may not be aware of the identity or number of subscribers
The role of an AR endpoint in the publishing manager involves issuing one or more confirmed service request application protocol data units (APDUs) to a publisher, specifically to request the publication of a designated object.
Two types of publishing managers are defined by this standard, pull publishing managers and push publishing managers, each of which is defined separately
3.3.58 push publisher type of publisher that publishes an object in an unconfirmed service request APDU
3.3.59 push publishing manager type of publishing manager that requests that a specified object be published using an unconfirmed service
3.3.60 push subscriber type of subscriber that recognizes received unconfirmed service request APDUs as published object data
The application relationship endpoint (AREP) serves as a server by returning a confirmed service response APDU to the client that initiated the request It acts as an object that provides essential services to another object, referred to as the client.
3.3.62 service operation or function than an object and/or object class performs upon request from another object and/or object class
3.3.63 station host of one AP, identified by a unique data link connection endpoint (DLCEP)-address
3.3.64 subscriber role of an AREP in which it receives APDUs produced by a publisher
Abbreviations and symbols
ALME Application Layer Management Entity
APDU Application Protocol Data Unit
AREP Application Relationship End Point
ASCII American Standard Code for Information Interchange
DL- (as a prefix) Data Link -
DLCEP Data Link Connection End Point
DLSAP Data Link Service Access Point
DLSDU DL-service-data-unit
Conventions
The FAL consists of a collection of object-oriented Application Service Elements (ASEs), with each ASE detailed in its own subclause Each ASE specification includes two key components: the class specification and the service specification.
The class specification outlines the characteristics of the class, while access to these attributes is limited to specific instances mentioned in this document Additionally, the service specification details the services offered by the ASE.
This standard uses the descriptive conventions given in ISO/IEC 10731
Class definitions are described using templates Each template consists of a list of attributes for the class The general form of the template is as shown below:
PARENT CLASS: Parent class name
(1) The FAL ASE: entry is the name of the FAL ASE that provides the services for the class being specified
The CLASS: entry denotes the name of the specified class, with all objects created from this template being instances of that class This class can be defined either by the standard itself or by a user adhering to the standard.
(3) The CLASS ID: entry is a number that identifies the class being specified This number is not used for Type 21 elements
(4) The PARENT CLASS: entry is the name of the parent class for the class being specified
In object-oriented programming, all attributes established in the parent class are automatically inherited by the child class, eliminating the need to redefine them in the child class's template.
NOTE The parent-class TOP indicates that the class being defined is an initial class definition The parent class
TOP is used as a starting point from which all other classes are defined The use of TOP is reserved for classes defined by this standard
The ATTRIBUTES label signifies that the subsequent entries pertain to attributes defined for the class Each attribute entry includes a line number, an indicator for its status (mandatory, optional, conditional, or selector), an attribute type label, a name or conditional expression, and an optional list of enumerated values Additionally, a default value for the attribute may be specified in the following column Typically, objects are identified by a numeric identifier, an object name, or a combination of both.
In class templates, key attributes are defined under a primary key attribute, with the line number indicating the sequence and nesting level, marked by periods Nesting serves to specify structured attribute fields, conditional attributes based on constraint statements, and selection fields for choice type attributes Attributes can be mandatory or optional, depending on the truth of the constraint, although not all optional attributes necessitate constraint statements.
The SERVICES label identifies the services defined for the class, where an (m) in column 2 signifies a mandatory service, an (o) denotes an optional service, and a (c) indicates a conditional service.
When defining a class with all optional services, at least one service must be selected upon instance creation The label "OpsService" refers to an operational service, while "MgtService" indicates a management service The line number indicates the sequence and nesting level, with each level marked by a period This nesting structure is utilized to specify services that are conditional based on a constraint statement.
The service model, service primitives, and time-sequence diagrams used are entirely abstract descriptions; they do not represent a specification for implementation
Service primitives represent the interactions between service users and providers, as defined by ISO/IEC 10731 They communicate parameters that reflect the information exchanged during these interactions It is important to note that not all parameters need to be explicitly stated in a given interface.
This standard defines the ASE service using a tabular format that outlines the component parameters of service primitives Each group of service primitives is detailed in tables, which include up to five columns: parameter name, request primitive, indication primitive, response primitive, and confirmation primitive.
Each row of the tables contains a single parameter or component, with a code under the relevant service primitive columns indicating the usage type of that parameter for the specified primitive.
M The parameter is mandatory for the primitive
The parameter is an optional user setting that may be included based on the dynamic usage of the service If it is not specified, a default value will be applied.
C The parameter is conditional upon other parameters or upon the environment of the service user
— (blank) The parameter is never present
S The parameter is a selected item
Some entries are further qualified by items in parentheses These may be: a) a parameter-specific constraint:
The symbol "(=)" signifies that the parameter is semantically equivalent to the parameter immediately to its left in the service primitive table, while also indicating 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
The service procedures are characterized by two key interactions: first, the communication between application entities via the exchange of fieldbus Application Protocol Data Units (APDUs); and second, the interaction between an application layer service provider and a service user within the same system through the invocation of application layer service primitives.
These procedures are applicable to instances of communication between systems that support time-constrained communications services within the fieldbus application layer
Common concepts
The fieldbus is designed for use in factories and process plants, facilitating the connection of primary automation devices such as sensors, actuators, and programmable logic controllers with control and monitoring equipment in control rooms.
Primary automation devices operate at the foundational level of the industrial automation hierarchy, executing a specific range of functions within a defined time frame Key functions of these devices include diagnostics, data validation, and the management of multiple inputs and outputs.
Primary automation devices, known as field devices, are situated near process fluids, fabricated parts, machines, operators, and the surrounding environment This strategic placement positions the fieldbus at the foundational levels of the computer integrated manufacturing (CIM) architecture.
Fieldbus systems offer several advantages, including reduced wiring requirements, enhanced data exchange capabilities, improved distribution of control between primary automation devices and control room equipment, and the ability to meet time-critical constraints.
This subclause outlines the basics of the FAL, with comprehensive details on each FAL ASE available in the overview section of the respective communication model specifications.
4.1.2.1 Relationship to the application layer of the OSI Basic Reference Model
The FAL functions are organized based on OSI layering principles, but its architectural relationship with the lower layers differs significantly Firstly, the FAL consolidates OSI functions along with extensions to address time-critical requirements, utilizing the OSI application layer structure standard (ISO/IEC 9545) as a foundation for its specification Secondly, the FAL directly leverages the services of the underlying layer, which can be the DLL or any intermediate layer, and may also provide functions typically associated with the OSI middle layers to ensure proper mapping onto the underlying layer.
OSI middle layers OSI application layer
OSI physical layer OSI data link layer OSI AP
(possibly non-existent) Fieldbus application layer
Fieldbus physical layer Fieldbus data link layer Fieldbus user layer
Figure 1 – Relationship to the OSI Basic Reference Model
4.1.2.2 Relationships to other fieldbus entities
The FAL architectural relationships illustrated in Figure 2 have been designed to support the interoperability needs of time-critical systems distributed in the fieldbus environment
In this environment, the FAL provides communications services to time-critical and non-time- critical applications located in fieldbus devices
The FAL directly utilizes the DLL to transmit its application layer protocol data units, employing a combination of data transfer services and supporting services to manage the operational functions of the DLL.
Figure 2 – Architectural positioning of the fieldbus application layer
4.1.2.2.2 Use of the fieldbus data link layer
The FAL provides network access to fieldbus APs It interfaces directly to the fieldbus DLL for transfer of its APDUs
The DLL provides various types of service to the FAL for transfer of data between data link endpoints (e.g., DLSAPs and DLCEPs)
Fieldbus applications appear to the network as application processes (APs) APs are the components of a distributed system that may be individually identified and addressed
Each Access Point (AP) is equipped with a Forwarding and Access Layer (FAL AE) that facilitates network connectivity This AE enables communication between APs, serving as a crucial interface for visibility into the AP's operations.
Access points (APs) consist of distinct components that are recognizable throughout the network, referred to as application process objects (APOs) These components can be identified by various key attributes and are situated at the address of the application process that encompasses them.
Access to APOs is facilitated by application service elements (ASEs) that are specific to each APO and included in the FAL These ASEs are tailored to support user applications, function blocks, and management tasks.
The FAL services can be used to support various management operations, including management of fieldbus systems, applications, and the fieldbus network
4.1.2.2.5 Access to FAL layer management entities
One LME may be present in each FAL entity on the network fieldbus application layer management entities (FALMEs) provide access to the FAL for system management purposes
The system management information base (SMIB) encompasses the data available to the system manager, with each FALME contributing to the FAL segment of the SMIB However, the implementation details of the SMIB are not covered within the scope of this standard.
The structure of the FAL is a refinement of the OSI application layer structure (ISO/IEC 9545)
As a result, the organization of this subclause is similar to that of ISO/IEC 9545 Certain concepts presented here have been refined from ISO/IEC 9545 for the fieldbus environment
The FAL distinguishes itself from other layers of the OSI Basic Reference Model in two key ways: first, while the OSI model specifies a single type of application layer communications channel for connecting application processes (APs), the FAL introduces multiple types of application relationships (AR) to facilitate communication between APs Second, the FAL utilizes the Data Link Layer (DLL) instead of the OSI presentation layer for the transfer of Application Protocol Data Units (APDUs).
The FAL protocol lacks an explicit presentation context and cannot be used simultaneously with other application layer protocols between the same data link service access points.
Time-critical real open systems are modeled through the interactions of time-critical application processes (APs) The Framework for Application Layer (FAL) enables these APs to exchange commands and data effectively.
Effective cooperation among Application Processes (APs) necessitates the sharing of adequate information for coordinated interaction and processing activities These activities can be confined to a single fieldbus segment or extend across multiple segments The modular architecture of the FAL has been specifically designed to meet the messaging needs of these applications.
Cooperation between APs also sometimes requires that they share a common sense of time
Type specific concepts
The industrial automation and process control system includes essential automation devices such as sensors, actuators, local display devices, annunciators, programmable logic controllers, single loop controllers, and standalone field controls, all integrated with control and monitoring equipment.
Data transfer between these devices is performed by peer-to-peer or multicast communication
Figure 12 demonstrates the interaction between Type 21 FAL and the DLL, highlighting its capability to support both cyclic and acyclic data transfers for application processes Additionally, Type 21 can operate concurrently with TCP/IP or UDP communication, although the use of other standard communication protocols is not covered by this standard.
Figure 12 – Interaction between FAL and DLL
Type 21 supports the publisher-subscriber communication model for cyclic data sharing
Figure 13 illustrates this model The publisher periodically multicasts preconfigured data, and subscribers receive the data This cyclic data sharing is the most widely used model in industrial applications
Figure 13 – Publisher-subscriber communication model
Type 21 supports the client-server communication model for event-triggered data transfer
Figure 14 depicts a model where the client requests data based on internal or external events, and the server responds with the necessary information This setup is applicable for both event-triggered and user-triggered application processes.
By Internal Events for example
By Data Acquisition Module node
Figure 14 – Client-server communication model
4.2.1 Node, AP, and object dictionary
Each node hosts exactly one AP All APOs for this AP are collected in the object dictionary
(OD) Figure 15 illustrates the object model
The overall structure of the OD is as described in Table 2
Table 2 – Overall structure of the OD
Data type area Definition of data types
Communication profile area Contains communication-specific parameters for the Type 21 network These entries are common to all devices
Manufacturer-specific area Definition of manufacturer-specific variables
Device profile area Definition of the variables defined in a device profile (outside the scope of this document) Reserved area Reserved for future use
The FAL ASEs of a Type 21 application and their interrelationships are described in Figure 16
Conveyance of APDUs by the AR ASE
AR ASE service primitives APO ASEs
Figure 16 – ASEs of a Type 21 application