M \2009 03 04\~$blank pdf Industrial communication networks — Fieldbus specifications — Part 5 17 Application layer service definition — Type 17 elements BS EN 61158 5 17 2008 raising standards worldw[.]
Overview
The Fieldbus Application Layer (FAL) serves as a crucial interface for user programs to interact with the fieldbus communication environment, effectively acting as a "window" that connects corresponding application programs.
This standard outlines essential components for both time-critical and non-time-critical messaging communications between application programs in an automation environment, specifically related to Type 17 fieldbus "Time-critical" refers to a defined time-window during which specific actions must be completed with a certain level of certainty Failing to execute these actions within the designated time frame can jeopardize the applications involved, posing risks to equipment, plant operations, and potentially human safety.
This standard outlines the externally visible services offered by various Types of the fieldbus Application Layer It includes an abstract model for defining application resources (objects) that users can manipulate through the FAL service Additionally, it details the primitive actions and events of the service, the parameters linked to each action and event, and their respective formats Furthermore, it describes the interrelationships between these actions and events, as well as the valid sequences in which they occur.
The purpose of this standard is to define the services provided to
1) the FAL user at the boundary between the user and the Application Layer of the Fieldbus Reference Model, and
2) Systems Management at the boundary between the Application Layer and Systems Management of the Fieldbus Reference Model
This standard outlines the structure and services of the IEC fieldbus Application Layer, ensuring alignment with the OSI Basic Reference Model (ISO/IEC 7498) and the OSI Application Layer Structure (ISO/IEC 9545).
FAL services and protocols are delivered through FAL application-entities (AE) within application processes Each FAL AE consists of object-oriented Application Service Elements (ASEs) and a Layer Management Entity (LME) that oversees the AE The ASEs facilitate communication services based on related application process object (APO) classes Among these ASEs is a management ASE that offers a unified set of services for managing instances of FAL classes.
The services outlined focus on the issuance and delivery of requests and responses without detailing the behavioral aspects of the applications involved This approach allows FAL users greater flexibility in standardizing object behavior Additionally, the standard includes supporting services that enable access to the FAL for controlling specific operational aspects.
Specifications
The main goal of this standard is to define the features of conceptual application layer services that are appropriate for time-sensitive communications, thereby enhancing the OSI Basic Reference Model to aid in the creation of application layer protocols designed for such critical communication needs.
A key goal is to establish migration pathways from existing industrial communication protocols, which leads to the variety of services standardized under the different types of IEC 61158.
This specification serves as a foundation for formal Application Programming Interfaces (APIs), but it is important to note that it does not constitute a formal programming interface Any API developed from this specification must address implementation challenges that are not included, 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 do they constrain the implementations of application layer entities within industrial automation systems
Equipment does not conform directly to the application layer service definition standard Instead, conformance is attained by implementing application layer protocols that meet the requirements of Type 17 application layer services as outlined in this standard.
The referenced documents are essential for applying this document For dated references, only the specified edition is applicable, while for undated references, the most recent edition, including any amendments, is relevant.
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
ISO/IEC 7498 (all parts), Information technology – Open Systems Interconnection – Basic Reference Model
ISO/IEC 9545, Information technology – Open Systems Interconnection – Application Layer structure
ISO/IEC 10731, Information technology – Open Systems Interconnection – Basic Reference Model – Conventions for the definition of OSI services
For the purposes of this document, the following terms and definitions apply.
Terms and definitions
For the purposes of this document, the following terms as defined in ISO/IEC 7498-1 apply: a) application entity b) application protocol data unit c) application service element
3.1.2 ISO/IEC 10731 terms a) (N)-connection b) (N)-entity c) (N)-layer d) (N)-service e) (N)-service-access-point
3.1.3.1 application function or data structure for which data is consumed or produced
3.1.3.2 application process part of a distributed application on a network, which is located on one device and unambiguously addressed
3.1.3.3 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.1.3.4 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.1.3.5 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 They can also influence the object's behavior Attributes are categorized into two types: class attributes and instance attributes.
3.1.3.6 behaviour indication of how an object responds to particular eventss
3.1.3.7 bridge intermediate equipment that connects two or more segments using a data-link layer relay function
3.1.3.8 channel single physical or logical link of an input or output application object of a server to the process
3.1.3.9 class a set of objects, all of which represent the same kind of system component
A class serves as a template 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.1.3.10 client a) object which uses the services of another (server) object to perform a task b) initiator of a message to which a server reacts
3.1.3.11 connection logical binding between application objects that may be within the same or different devices
NOTE 1 Connections may be either point-to-point or multipoint
Interconnection in RT-Auto ASEs refers to the logical link between sinks and sources of attributes and services across various custom interfaces This concept is divided into two categories: data interconnection and event interconnection Data interconnection pertains to the logical link and data flow between the sink and source of automation data items, while event interconnection involves the logical link and data flow between the sink (method) and source (event) of operational services.
3.1.3.12 connection point buffer which is represented as a subinstance of an Assembly object
3.1.3.13 conveyance path unidirectional flow of APDUs across an application relationship
AR used directly by the FAL User
NOTE On Dedicated ARs, only the FAL Header and the user data are transferred
3.1.3.15 device physical hardware connected to the link
NOTE A device may contain more than one node
3.1.3.16 domain part of the RTE network consisting of one or two subnetwork(s)
NOTE Two subnetworks are required to compose a dual-redundant RTE network, and each end node in the domain is connected to both of the subnetworks
The domain master station is responsible for diagnosing routes to all other domains, distributing network time to nodes within the domain, acquiring absolute time from the network time master, and notifying the status of the domain.
3.1.3.18 domain number numeric identifier which indicates a domain
3.1.3.19 end node producing or consuming node
3.1.3.20 endpoint one of the communicating entities involved in a connection
3.1.3.21 error discrepancy between a computed, observed or measured value or condition and the specified or theoretically correct value or condition
3.1.3.22 external bridge bridge to which neither internal bridges nor RTE stations are connected directly
3.1.3.23 event an instance of a change of conditions
3.1.3.24 group a) a general term for a collection of objects Specific uses: b) when describing an address, an address that identifies more than one entity
An interface is defined as a shared boundary between two functional units, characterized by their functional and signal attributes It encompasses a collection of FAL class attributes and services, providing a specific perspective on the FAL class.
3.1.3.26 interface port physical connection point of an end node, which has an independent DL-address
3.1.3.27 internal bridge bridge to which no routers, external bridges or nodes non-compliant with this specification are connected directly
3.1.3.28 invocation act of using a service or other resource of an application process
Each invocation functions as an independent thread of control defined by its context The invocation 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 remains incomplete.
A junction bridge is defined as a bridge that connects at least one router, external bridge, or node that does not comply with the specified standards, along with at least one internal bridge or RTE station.
3.1.3.30 link physical communication channel between two nodes
a synonym for an operational service which is provided by the server ASE and invoked by a client
3.1.3.32 network a set of nodes connected by some type of communication medium, including any intervening repeaters, bridges, routers and lower-layer gateways
3.1.3.33 network time master station which distributes network time to domain masters
3.1.3.34 node single DL-entity as it appears on one local link
3.1.3.35 non-redundant interface node node whch has a single interface port
3.1.3.36 non-redundant station station that consists of a single end node
NOTE “non-redundant station” is synonymous with “end node”
An object is an abstract representation of a specific component within a device, encompassing a collection of related data, represented as variables, and methods, which are procedures for manipulating that data It features a clearly defined interface and behavior.
3.1.3.38 originator client responsible for establishing a connection path to the target
3.1.3.39 path logical communication channel between two nodes, which consists of one or two link(s)
3.1.3.40 peer role of an AR endpoint in which it is capable of acting as both client and server
3.1.3.41 producer node that is responsible for sending data
3.1.3.42 provider source of a data connection
3.1.3.43 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 the number of subscribers and it may publish its APDUs using a dedicated AR
3.1.3.44 redundant interface node node with two interface ports one of which is connected to a primary network, while the other is connected to a secondary network
3.1.3.45 redundant station station that consists of a pair of end nodes
NOTE Each end node of a redundant station has the same station number, but has a different DL-address
3.1.3.46 resource a processing or information capability of a subsystem
RTE station station compliant with this specification
3.1.3.48 route logical communication channel between two communication end nodes
3.1.3.49 router intermediate equipment that connects two or more subnetworks using a network layer relay function
3.1.3.50 segment communication channel that connects two nodes directly without intervening bridges
3.1.3.51 server a) role of an AREP in which it returns a confirmed service response APDU to the client that initiated the request b) object which provides services to another (client) object
3.1.3.52 service operation or function than an object and/or object class performs upon request from another object and/or object class
3.1.3.53 station end node or a pair of end nodes that perform a specific application function
3.1.3.54 station number numeric identifier which indicates a RTE station
3.1.3.55 subnetwork part of a network that does not contain any routers A subnetwork consists of end nodes, bridges and segments
NOTE Every end node included in a subnetwork has the same IP network address
3.1.3.56 subscriber role of an AREP in which it receives APDUs produced by a publisher
Abbreviations and symbols
APDU Application protocol data unit
AREP Application relationship end ooint
DL- data-link layer (as a prefix)
DLSAP DL-service-access-point
FIFO First-in first-out (queuing method)
ISO International Organization for Standardization
MSU-AR Multipoint network-scheduled unconfirmed publisher/subscriber AREP
MTU-AR Multipoint user-triggered unconfirmed publisher/subscriber AREP
PSU-AR Point-to-point network-scheduled unconfirmed client/server AREP
PTC-AR Point-to-point user-triggered confirmed client/server AREP
PTU-AR Point-to-point user-triggered unconfirmed client/server AREP
Conventions
The FAL consists of a collection of object-oriented ASEs, with each ASE detailed in its own subclause Each specification includes two key components: the class specification and the service specification.
The class specification outlines the characteristics of the class, which can be accessed through instances using the Object Management ASE services detailed in Clause 5 of this standard Additionally, the service specification describes the services offered by the ASE.
Class definitions are described using templates Each template consists of a list of attributes for the class The general form of the template is 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 this standard.
The "CLASS ID:" is a unique number that identifies a specific class within the FAL ASE, ensuring clear identification when qualified by the FAL ASE's identity A "NULL" value signifies that the class cannot be instantiated Class IDs ranging from 1 to 255 are reserved for standardized classes to ensure compatibility with existing national standards, while IDs from 256 to 2048 are designated for user-defined classes.
The "PARENT CLASS:" entry indicates the name of the parent class associated with the specified class All attributes from the parent class are inherited by the defined class, eliminating the need to redefine them in the class template.
The parent class "TOP" serves as the foundational definition for all subsequent classes, establishing a standard from which they are derived Its use is specifically designated for classes defined by this standard.
The "ATTRIBUTES" label signifies that the subsequent entries are defined attributes for the class Each entry includes a line number, an indicator for mandatory (m), optional (o), conditional (c), or selector (s) status, an attribute type label, a name or conditional expression, and optionally, a list of enumerated values along with a default value Objects are typically identified by a numeric identifier, an object name, or both, with key attributes defined in the class templates The line number indicates the sequence and nesting level, with nesting denoted by periods, which is used to specify structured attribute fields, attributes conditional on constraints, and selection fields of choice type attributes Attributes can be mandatory or optional based on the truth of the constraint, with some optional attributes not requiring constraint statements.
The "SERVICES" label identifies the services associated with a class, where an (m) denotes a mandatory service, an (o) indicates an optional service, and a (c) signifies a conditional service If all services for a class are optional, at least one must be selected when defining an instance of that class The "OpsService" label refers to operational services, while "MgtService" pertains to management services Additionally, the line number indicates the sequence and nesting level, with each level marked by a period, allowing for the specification of services that are conditional on a constraint statement.
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 are used to represent service user/service provider interactions (ISO/IEC
10731) They convey parameters which indicate information available in the user/provider interaction
It is important to refer to Note 1 under section 3.3.3.3, which discusses the exclusion of service parameters that are relevant to protocol specifications, programming interface specifications, or implementation specifications, but are not applicable to an abstract service definition.
This standard employs a tabular format to outline the component parameters of service primitives It details the parameters relevant to each group of service primitives in various tables throughout the document Each table may contain up to six columns, including the name of the service parameter, along with columns for the associated primitives and the parameter-transfer directions utilized by the service.
2) the request primitive’s input parameters;
3) the request primitive’s output parameters;
NOTE 2 This is a seldom-used capability Unless otherwise specified, request primitive parameters are input parameters
4) the indication primitive’s output parameters;
5) the response primitive’s input parameters; and
6) the confirm primitive’s output parameters
NOTE 3 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 single parameter or its component, with corresponding service primitive columns that utilize a code to indicate the parameter's usage type for the specified primitive.
M parameter is mandatory for the primitive
U parameter is a User option, and may or may not be provided depending on dynamic usage of the service 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 service 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 parameter immediately to its left in the service primitive table Additionally, it 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
The procedures are defined in terms of
• the interactions between application entities through the exchange of fieldbus Application Protocol Data Units, and
• the interactions between an application layer service provider and an application layer service user in the same system through the invocation of application layer service primitives
These procedures are applicable to instances of communication between systems which support time-constrained communications services within the fieldbus Application Layer
The IEC 61158-5 series of standards outlines abstract services that are not intended as protocol, implementation, or programming interface specifications Consequently, there are limitations on how service procedures can be defined within these standards Variations in protocol aspects among different specifications or implementations of the same abstract services are not suitable for inclusion in these definitions, except at a level of abstraction that is universally applicable.
Service providers should specify the methods for pairing request and reply PDUs in an IEC 61158-6 protocol specification standard, rather than in an IEC 61158-5 abstract service definition standard Additionally, local implementation methods for pairing request and confirmation primitives, or indication and response primitives, are suitable for implementation or programming interface specifications, but not for abstract service or protocol standards, unless they maintain a common level of abstraction across all implementations It is essential that the abstract definition does not over-specify the concrete realizations of the standard.
For detailed insights into the conceptual service procedures related to the implementation of a protocol that fulfills the services outlined in the IEC 61158-5 abstract service definitions, refer to IEC/TR 61158-1 (Ed.2.0), section 9.6.
General
This Fieldbus Application Layer (FAL) provides communication services to time-critical and non-time-critical applications in fieldbus devices
The common concepts and templates used to describe the application layer service in this standard are detailed in IEC/TR 61158-1, Clause 9.
FAL ASEs
The FAL ASEs were defined using a modular and object-oriented approach, offering a collection of services tailored for a specific object class or a related group of classes.
The Application Relationship ASE is designed to facilitate remote access to the AP by defining and establishing communication relationships with other APs It also offers services to other ASEs, enabling them to convey their service requests and responses effectively.
Each FAL ASE specifies a collection of services, APDUs, and procedures relevant to its represented classes To cater to specific application requirements, only a portion of these ASE services may be utilized, and profiles can be employed to delineate these subsets.
APDUs are sent and received between FAL ASEs that support the same services Figure 1 shows the FAL ASEs from the perspective of communication
FAL AP APO ASE Service Primitives
Conveyance of APDUs by the AR ASE
Common FAL service parameters
Many services have the following parameters Instead of defining them for each service, the following common definitions are provided:
This parameter carries the parameters of the service invocation
The parameter provides essential information for the local identification of the Application Relationship Endpoint (AREP) used to deliver the service It may utilize a key attribute of the AREP to define the application relationship Additionally, when an AREP operates across multiple contexts at once, the parameter is enhanced to specify both the context and the AREP.
This selection type parameter indicates that the service request was successful
This selection type parameter indicates that the request failed
This parameter provides error information for service errors It is returned in confirmed service response(-) primitives
Variable ASE
In a fieldbus environment, application processes manage data that remote applications can read and write The variable ASE outlines the network-visible attributes of this application data and offers a range of services for reading, writing, and reporting their values.
The variable ASE can facilitate two distinct access models when the right types of application relationships are in place: the client/server model and the publisher/subscriber model In the client/server model, a client application sends read or write requests to a server application, which responds based on those requests The server remains inactive until stimulated by client requests on the network, generating no responses in the absence of such requests.
The publisher/subscriber model distinguishes itself by allowing data producers to publish their information onto a network Subscribers interested in accessing this data connect to the application that facilitates the publishing process and actively listen for incoming data transmissions This model is supported by two approaches: the "pull" model and another unspecified method.
In the "pull" model, subscribers initiate a request for the publisher to release a sequence of variable data The publisher then periodically distributes this data through multicasting, based on the remote requests received The schedule for publishing is managed solely by the publisher.
In the "push" model, the publisher is responsible for distributing a sequence of variable data based on requests from local FAL users This distribution occurs through multicasting, tailored to meet local demands, while the publisher also manages the publishing schedule independently.
This key attribute identifies an instance of this object class
This attribute is the numeric identifier of the data type
This optional attribute is the length of the data in octets
The value of this optional attribute indicates whether the data value of the Variable Object can be read via the fieldbus
The value of this optional attribute indicates whether the data value of the Variable Object can be updated via the fieldbus
This key attribute identifies an instance of this object class
This attribute specifies the number of variables in the list
This attribute identifies the variables by the key attributes that are contained in the list
This subclause contains the definition of services that are unique to this ASE The services defined for this ASE are:
This confirmed service may be used to read the value of a variable object or a variable list object It is not used with the publisher/subscriber model
The service parameters for each primitive are shown in Table 1
Parameter name Req Ind Rsp Cnf
The correlation between a confirm primitive and its corresponding preceding request primitive is determined locally Similarly, the relationship between a response primitive and its preceding indication primitive is also a local matter Refer to section 1.2 for more details.
This parameter specifies a variable object or a variable list object to be read by the key attribute
This parameter defines the value assigned to each variable For variable lists, it indicates the concatenated values of the variables in the order they appear.
NOTE If any of the variables in a variable list could not be read, the service fails
This confirmed service is used to write the value of a variable object or a variable list object It is not used with the publisher/subscriber model
The service parameters for each primitive are shown in Table 2
Parameter name Req Ind Rsp Cnf
The correlation between a confirm primitive and its corresponding preceding request primitive is determined locally Similarly, the relationship between a response primitive and its preceding indication primitive is also a local matter For further details, refer to section 1.2.
This parameter specifies a variable object or a variable list object to be written by the key attribute
This parameter defines the value to be written For individual variables, it indicates the specific value of that variable In the case of variable lists, this parameter outlines the concatenated values of each variable in the order they appear within the list.
NOTE If any variable in a variable list object cannot be updated, none of the variables in the variable list object will be updated and the write will fail
This optional service allows for the reporting of values for variable objects or variable list objects and can be utilized within the publisher/subscriber push model.
The service parameters for each primitive are shown in Table 3
Table 3 – Information report service parameters
This parameter specifies a variable object or a variable list object to be reported by the key attribute
This parameter defines the value to be reported, indicating the specific value for individual variables In the case of variable lists, it details the concatenated values of each variable in the order they appear within the list.
NOTE If any of the variables in a variable list could not be read, the service fails.
Event ASE
Event objects are used to define messages reporting event occurrences Event messages contain information that identifies and describes event occurrences
Notifiers play a crucial role in gathering event messages from event objects and distributing them through a single call to the FAL event notification service The quantity of event messages that can be submitted in one service invocation is constrained by the maximum APDU size that the AR can handle.
If an application process fails to receive one or more event notifications, a notification recovery service is provided to request the notifier to retransmit the notifications
In this model, application processes handle the functions related to event objects and event list objects, while the FAL offers tailored communication services The application process identifies events, constructs event messages, and aggregates them Subsequently, it utilizes the FAL event notification service to distribute the aggregated event messages.
3 (o) Attribute: Last Notification Sequence Number
This key attribute identifies an instance of this object class
This attribute identifies the AREP configured to convey event notifications This AREP is also used for reporting the event notifications generated by an event recovery request
The conditional attribute specifies the last sequence number used It is incremented for each event notification service invocation
This optional attribute identifies the events that are configured
This subclause contains the definition of services that are unique to this ASE The services defined for this ASE are:
This unconfirmed service is used by the notifier of an FAL AP to notify other APs that one or more events have occurred
The service parameters for each primitive are shown in Table 4
Table 4 – Event notification service parameters
NotifierID M M (=) Sequence Number U U (=) Notification Time U U (=) List of Event Messages M M (=) Event Key Attribute M M (=) Event Data type C C (=) Event Detection Time U U (=) Event Data U U (=)
This parameter identifies the notifier issuing the event notification
This optional parameter is the sequence number for the event notification It may be used for notification recovery purposes
This optional parameter is the time of the event notification
This parameter defines the list of event messages to be reported, which can include messages from multiple event objects Each message's content is determined by its corresponding event object and must align with the specifications of the notifier object.
This parameter identifies each of the specific events being acknowledged by this service
The conditional parameter specifies the data type for each event data parameter and is only applicable when the event data parameter is included If the event data parameter exists, the conditional parameter must also be present.
This optional parameter indicates the time of event detection and is included only if it is defined for the specific event object and supported by the designated notifier.
This optional parameter allows for the inclusion of user data in an event message, alongside the information used to identify the event occurrence It is included only if it is defined for the specific event object and supported by the notifier in use.
This unconfirmed service is used to request that a specified number of retained event notifications be returned Notifications are returned using the event notification service
The service parameters for each primitive are shown in Table 5
Table 5 – Event notification recovery service parameters
This parameter identifies the notifier to which this service is directed
This optional parameter specifies the sequence number of the event notification to be re-sent
If not present, the last notification sent is being requested.
Load region ASE
A load region is an unstructured memory area designed for uploading (reading) or downloading (writing) data The term "unstructured" indicates that this memory is simply an ordered sequence of octets, with no additional structure evident.
A load region can signify an unnamed volatile memory area, like dynamic computer memory, or a named non-volatile memory object, such as a file The data within a load region is known as a load image, which may include programs or data The load process facilitates the transfer of a load image to or from a load region, enabling application processes to initiate the downloading or uploading of specific load regions.
FAL ASE: LOAD REGION ASE
This attribute specifies the maximum size of the load region in octets
This attribute is a locally significant address of the load region
This optional attribute specifies the name of the load image contained in the load region
5.3.3 Load region ASE service specification
This subclause contains the definitions of services that are unique to this ASE The services defined for this ASE are:
This verified service facilitates the downloading of a load image through its request and indication primitives, while the response and confirmation primitives communicate the success or failure of the download process.
The service parameters for each primitive are shown in Table 6
Parameter name Req Ind Rsp Cnf
The correlation between a confirm primitive and its corresponding preceding request primitive is determined locally Similarly, the method for correlating a response primitive with its preceding indication primitive is also a local matter Refer to section 1.2 for more details.
This parameter specifies the load region into which the image is to be downloaded
This parameter specifies the data to be downloaded
This confirmed service facilitates the uploading of a load image, utilizing request and indication primitives to initiate the upload The response and confirmation primitives communicate the load image of the specified region and the outcome of the loading process.
The service parameters for each primitive are shown in Table 7
Parameter name Req Ind Rsp Cnf
The correlation between a confirm primitive and its preceding request primitive is determined locally, as is the correlation between a response primitive and its preceding indication primitive For further details, refer to section 1.2.
This parameter specifies the load region from which the image is to be uploaded
This parameter specifies the data uploaded.
Function invocation ASE
The function invocation class models the state-oriented function invocation It may be used to model software processes or user functions the operation of which may be controlled
FAL ASE: FUNCTION INVOCATION ASE
This key attribute consists of a station identifier and a function identifier
This attribute indicates the current state of the function invocation An enumerated set of values has been defined
UNRUNNABLE This state indicates that the function invocation is not executing and can not be executed
IDLE This state indicates that the function invocation is not executing, but is capable of being executed
RUNNING This state indicates that the function invocation is executing
STOPPED This state indicates that the execution of a function invocation has been suspended
5.4.3 Function invocation ASE service specification
This subclause contains the definition of services that are unique to this ASE The services defined for this ASE are:
This confirmed service is used to start a function invocation from the initial condition
The service parameters for each primitive are shown in Table 8
Parameter name Req Ind Rsp Cnf
The correlation between a confirm primitive and its preceding request primitive is determined locally, as is the correlation between a response primitive and its preceding indication primitive For further details, refer to section 1.2.
This parameter specifies one of the key attributes of the function invocation object
This confirmed service is used to stop a function invocation retaining its context so that it may be resumed
The service parameters for each primitive are shown in Table 9
Parameter name Req Ind Rsp Cnf
The correlation between a confirm primitive and its preceding request primitive is determined locally, as is the correlation between a response primitive and its preceding indication primitive For further details, refer to section 1.2.
This parameter specifies one of the key attributes of the function invocation object
This confirmed service is used to request to start a function invocation from the suspended condition
The service parameters for this service are shown in Table 10
Parameter name Req Ind Rsp Cnf
The correlation between a confirm primitive and its corresponding preceding request primitive is determined locally Similarly, the relationship between a response primitive and its preceding indication primitive is also a local matter Refer to section 1.2 for more details.
This parameter specifies one of the key attributes of the function invocation object.
Time ASE
The Time ASE defines a clock synchronization method for aligning time across network stations, enabling the addition of time values to alert information and ensuring messages are sequenced in chronological order.
A clock synchronization system comprises one or more time masters and multiple time slaves, with synchronization facilitated by the communication system The application is responsible for the adjustment and management of the clocks.
The network should have at least one network time master, which may be one of the domain time masters selected automatically or may be a fixed station
The network time master serves as the primary clock for the network, which can either be its own local clock or synchronized with an external clock source.
The domain time master of each domain obtains network time from the network time master and it distributes the network time value to stations in the domain
This attribute specifies the role of the Time ASE with values defined as follows:
NETWORK TIME MASTER A network unique end node which responds to time requests from domain masters
DOMAIN TIME MASTER A domain unique end node which distributes time information within the domain
TIME SLAVE An end node subscribes time information distributed by the domain master
This attribute indicates the stratum level of the local clock
This attribute indicates the maximum interval between successive time messages
This attribute indicates the precision level of the local clock
This subclause contains the definitions of services that are unique to this ASE The services defined for this ASE are:
To obtain the network time value distributed from the network, utilize this local service If Time ASE serves as the network time master, it will return the local time value of the master clock.
The service parameters for each primitive are shown in Table 11
Table 11 – Get network time service parameters
NOTE The method by which a confirm primitive is correlated with its corresponding preceding request primitive is a local matter See 1.2
This parameter is the value of the network time
This parameter indicates the states of time synchronization The possible states are;
• Synchronized to the domain time master
• Synchronized to the network time master as the domain time master
• Synchronized to an external time source as a network time master
This confirmed service should be used to set the value of network time to the time master
This service is available under conditions where the network time master is not synchronized to an external time source
The service parameters for each primitive are shown in Table 12
Table 12 – Set network time service parameters
Parameter name Req Ind Rsp Cnf
The correlation between a confirm primitive and its preceding request primitive, as well as the correlation between a response primitive and its preceding indication primitive, is determined locally For further details, refer to section 1.2.
This parameter is the value of the network time to be set
This local service should be used to recognize tick timing synchronized to the network time
The tick interval is configurable
The service parameters for each primitive are shown in Table 13
Table 13 – Tick notification service parameters
This parameter indicates tick timing
NOTE This service may be implemented by means of a hard-wired interruption.
Network management ASE
End nodes can feature dual network interfaces, known as network interface A and network interface B, to ensure network redundancy Network interface A is designated for the primary network connection, while network interface B connects to the secondary network.
Each Network Management ASE generates two diagnostic message APDUs and transmits them simultaneously to network interfaces A and B It receives pairs of APDUs from other end nodes involved in network redundancy, which helps in selecting the appropriate network interface for sending additional APDUs This process also assesses the reachability of the destination node before sending an APDU.
This information is preserved in the network status table
1 (m) Attribute: Number of Network Interfaces
4 (m) Attribute: List of Network Interface Status
3 (m) OpsService: Network Status Change Report
4 (m) OpsService: Station Status Change Report
This attribute specifies the number of network interfaces on this end node An end node may have one or two network interfaces
This attribute specifies the time interval between successive invocations of the diagnostic messages in milliseconds
This attribute specifies the time interval used to remove silent end nodes from the List of Network Interface Status
5.6.2.2.4 List of network interface status
The path status attribute reflects the condition of the connection to a remote station, indicating the success of Diagnostic Messages received by the Network Management ASE This bi-directional status reveals whether messages are successfully transmitted at both ends of the path or if either end is experiencing a fault.
5.6.3 Network management ASE service specification
This subclause contains the definition of the services that is unique to this ASE
The services defined for this ASE are
This local service is used to obtain the status of the network
The service parameters for each primitive are shown in Table 14
Table 14 – Get network status service parameters
NOTE The method by which a confirm primitive is correlated with its corresponding preceding request primitive is a local matter See 1.2
This parameter indicates consistency of the primary and secondary networks Possible values are
This local service is used to obtain the status of the specified station
The service parameters for each primitive are shown in Table 15
Table 15 – Get station status service parameters
NOTE The method by which a confirm primitive is correlated with its corresponding preceding request primitive is a local matter See 1.2
This parameter indicates the station for which the status is requested, and consists of a domain number and a station number
This parameter indicates the status of the station specified by the station identifier, and includes the following information a) existence
FALSE the station does not exist b) redundancy
SINGLE the station is not redundant
DUAL-REDUNDANT the station is redundant c) AREP of the end node which is on service
This parameter indicates the status of route for the station, and includes the following information a) status of the route on the primary network
UNREACHABLE b) status of the route on the secondary network
5.6.3.4 Network status change report service
This local service is used to inform of changes in network status
The service parameters for each primitive are shown in Table 16
Table 16 – Network status change report service parameters
This parameter indicates consistency of the primary and secondary networks, and has the following possible values:
5.6.3.5 Station status change report service
This local service is used to inform of changes in the station status
The service parameters for each primitive are shown in Table 17
Table 17 – Station status change report service parameters
This parameter indicates the station of which the status has changed
This parameter indicates the status of the end node specified in/by the request primitive and includes the following information: a) existence
FALSE the station does not exist b) redundancy
SINGLE the station is not redundant
DUAL-REDUNDANT the station is redundant c) AREP of the end node which is on service
This parameter indicates the status of the route for the station, and includes the following information: a) status of the route on the primary network
UNREACHABLE b) status of the route on the secondary network
Application relationship ASE
In a distributed system, application processes communicate with each other by exchanging Application Layer messages across well-defined Application Layer communication channels
These communication channels are modelled in the Fieldbus Application Layer as application relationships (ARs)
ARs facilitate communication between applications by adhering to specific characteristics essential for time-sensitive systems Various combinations of these characteristics result in the classification of different types of ARs The attributes of AR endpoint classes formally define the characteristics of ARs.
ARs communicate FAL service requests and responses, which are submitted to the AR ASE for transfer by an FAL Application Service Element (ASE) that corresponds to the class of the accessed APO This concept is visually represented in Figure 2.
The transfer of APDUs is influenced by the type of AR, which may direct them to one or multiple destination application processes Additionally, specific characteristics of the AR dictate the method of APDU transfer, as detailed in the following sections.
Figure 2 – The AR ASE conveys APDUs between APs
Each Access Point (AP) in an Augmented Reality (AR) system includes an endpoint These endpoints are specifically defined within the Application Environment (AE) of the AP The definition of an endpoint, when integrated with other definitions, plays a crucial role in the overall functionality of the AR system.
AR ASE FAL APO ASE
FAL AP APO Service Primitives
AR Confirmed Send Service Primitives
AR UnconfirmedSend Service Primitives other endpoints, defines an AR To ensure communication compatibility among or between endpoints, each endpoint definition contains a set of compatibility-related characteristics
These characteristics need to be configured appropriately for each endpoint for the AR to operate properly
Endpoint definitions include a set of characteristics that outline the operation of the AR These characteristics, along with those that specify compatibility, establish the endpoint's context The AR ASE utilizes this context to manage the endpoint's operation and the transmission of APDUs The following section will detail the characteristics that make up the endpoint context.
The role of an AREP defines the acceptable actions of an AP within the AREP framework An AREP can function as a client, server, peer (acting as both client and/or server), publisher, or subscriber.
Table 18 and Table 19 summarize the characteristics and combinations of each of the AREP roles
Table 18 – Conveyance of service primitives by AREP role
Client Server Peer Publisher Subscriber
Table 19 – Valid combinations of AREP roles involved in an AR
Client Server Peer Publisher Subscriber
Dedicated AR endpoints deliver services directly to the FAL User, functioning similarly to non-dedicated endpoints However, the APDUs they transmit include only the AR control field, lacking any service-specific protocol control information.
FAL Users set up for dedicated ARs manage and transfer their data independently, without relying on other FAL ASEs The specific format and content of the user data transmitted via dedicated ARs are determined solely by the configuration settings.
The cardinality of an Application Resource (AR) indicates the number of remote application processes involved from the perspective of a client or publisher endpoint, and it is not defined from the viewpoint of a server or subscriber.
From the perspective of a client or peer endpoint, ARs function on a one-to-one basis, as clients cannot send requests to multiple servers simultaneously and await their responses.
From a publisher endpoint perspective, cardinality signifies support for multiple subscribers These one-to-many application relationships facilitate communication between a single application and a group of applications, commonly known as multi-party and multicast interactions.
In one-to-many Augmented Reality (AR) systems, the publisher endpoint uses a group identifier to recognize remote endpoints, allowing for a more efficient management of subscribers This approach enables users to join or leave AR sessions without affecting the publisher's context, as their individual identities remain unknown While the publisher application may track participant involvement, this information does not interfere with the overall functionality of the AR experience.
The conveyance model defines how APDUs are sent between endpoints of an AR Three characteristics are used to define these transfers:
AR ASEs facilitate the transfer of information between augmented reality (AR) endpoints through designated conveyance paths These paths serve as one-way communication channels, enabling endpoints to effectively manage input and output data.
Endpoints in the application process can be configured with one or two conveyance paths Unidirectional endpoints are set up for either sending or receiving data, while bi-directional endpoints are equipped for both functions.
Unidirectional ARs can only transmit service requests, while bi-directional ARs are required for sending service responses This means that unidirectional ARs facilitate the transfer of unconfirmed services in a single direction, whereas bi-directional ARs allow for the transfer of both unconfirmed and confirmed services, which can be initiated by one or both endpoints.
Trigger policy indicates when APDUs are transmitted over the network by the data-link layer
The first type is referred to as user-triggered User-triggered AREPs submit FAL APDUs to the data-link layer for transmission at the earliest opportunity