1.1 Overview In network communications, as in many fields of engineering, it is a fact that “one size does not fit all.” Engineering design is about making the right set of trade-offs, and these trade-offs must balance conflicting requirements such as simplicity, generality, ease of use, richness of features, performance, memory size and usage, scalability, determinism, and robustness. These trade-offs must be made in light of the types of information flow (e.g. periodic, one-to-many, request-reply, events), and the constraints imposed by the application and execution platforms. The Type 15 fieldbus provides two major communication mechanisms that complement each others to satisfy communication requirements in the field of automation: the Client/Server and the Publish/Subscribe paradigms. They can be used concurrently on the same device. Type 15 Client/Server operates in a Client/Server relationship. Its application layer service definitions and protocol specifications are independent of the underlying layers, and have been implemented on a variety of stacks and communication media, including EIA/TIA-232, EIA/TIA-422, EIA/TIA-425, HDLC (ISO 13239), fiber, TCP/IP, Wireless LANs and Radios. Type 15 Publish/Subscribe operates in a Publish/Subscribe relationship. Its application layer service definitions and protocol specifications are independent of the underlying layers and can be configured to provide reliable behaviour and support determinism. The most common stack is UDP/IP. The fieldbus application layer (FAL) provides user programs with a means to access the fieldbus communication environment. In this respect, the FAL can be viewed as a “window between corresponding application programs.” This part of IEC 61158 provides common elements for basic time-critical and non-time-critical messaging communications between application programs in an automation environment and material specific to Type 15 fieldbus. The term “time-critical” is used to represent the presence of a time-window, within which one or more specified actions are required to be completed with some defined level of certainty. Failure to complete specified actions within the time window risks failure of the applications requesting the actions, with attendant risk to equipment, plant and possibly human life. This part of IEC 61158 define in an abstract way the externally visible service provided by the Type 15 fieldbus application layer in terms of a) an abstract model for defining application resources (objects) capable of being manipulated by users via the use of the FAL service, b) the primitive actions and events of the service; c) the parameters associated with each primitive action and event, and the form which they take; and d) the interrelationship between these actions and events, and their valid sequences. The purpose of this part of IEC 61158 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 part of IEC 61158 specifies the structure and services of the Type 15 IEC fieldbus Application Layer, in conformance with the OSI Basic Reference Model (ISO/IEC 7498) and the OSI Application Layer Structure (ISO/IEC 9545). FAL services and protocols are provided by FAL application-entities (AE) contained within 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 provide communication services that operate on a set of related application process object (APO) classes. One of the FAL ASEs is a management ASE that provides a common set of services for the management of the instances of FAL classes. Although these services specify, from the perspective of applications, how request and responses are issued and delivered, they do not include a specification of what the requesting and responding applications are to do with them. That is, the behavioral aspects of the applications are not specified; only a definition of what requests and responses they can send/receive is specified. This permits greater flexibility to the FAL users in standardizing such object behavior. In addition to these services, some supporting services are also defined in this standard to provide access to the FAL to control certain aspects of its operation. 1.2 Specifications The principal objective of this part of IEC 61158 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 secondary objective is to provide migration paths from previously-existing industrial communications protocols. It is this latter objective which gives rise to the diversity of services standardized as the various Types of IEC 61158, and the corresponding protocols standardized in subparts of IEC 61158-6. This specification may be used as the basis for formal Application Programming-Interfaces. Nevertheless, it is not a formal programming interface, and any such interface will need to address implementation issues not covered by this specification, including a) the sizes and octet ordering of various multi-octet service parameters, and b) the correlation of paired request and confirm, or indication and response, primitives. 1.3 Conformance This part of IEC 61158 does not specify individual implementations or products, nor do they constrain the implementations of application layer entities within industrial automation systems. There is no conformance of equipment to this application layer service definition standard. Instead, conformance is achieved through implementation of conforming application layer protocols that fulfill the Type 15 application layer services as defined in this part of IEC 61158. 1.4 Type overview In network communications, as in many fields of engineering, it is a fact that “one size does not fit all.” Engineering design is about making the right set of trade-offs, and these trade-offs must balance conflicting requirements such as simplicity, generality, ease of use, richness of features, performance, memory size and usage, scalability, determinism, and robustness. These trade-offs must be made in light of the types of information flow (e.g. periodic, one-to-many, request-reply, events), and the constraints imposed by the application and execution platforms. The Type 15 fieldbus provides two major communication mechanisms that complement each others to satisfy communication requirements in the field of automation: the Client/Server and the Publish/Subscribe paradigms. They can be used concurrently on the same device. Type 15 Client/Server operates in a Client/Server relationship. Its application layer service definitions and protocol specifications are independent of the underlying layers, and have been implemented on a variety of stacks and communication media, including EIA/TIA-232, EIA/TIA-422, EIA/TIA-425, HDLC (ISO 13239), fiber, TCP/IP, Wireless LANs and Radios. Type 15 Publish/Subscribe operates in a Publish/Subscribe relationship. Its application layer service definitions and protocol specifications are independent of the underlying layers and can be configured to provide reliable behavior and support determinism. The most common stack is UDP/IP.
