process automation, factory automation and similar monitoring and control applications; • integrated and consistent life-cycle data exchange within a control system including its fieldbu
Terms and definitions
3.1.1 actor coherent set of roles that users of use cases play when interacting with these use cases
Note 1 to entry: An actor has one role for each use case with which it communicates
3.1.2 address communication protocol specific access identifier
3.1.3 application software functional unit that is specific to the solution of a problem in industrial-process measurement and control
Note 1 to entry: An application may be distributed among resources, and may communicate with other applications
3.1.4 business object object representing specific behavior (e.g DTM, BTM and channel)
The term "business object" originates from the three-tier architecture design pattern, where it is a key component of the business layer.
BTM specialized DTM to manage and handle a block
Note 1 to entry: This note applies to the French language only
3.1.6 communication fieldbus protocol specific data transfer
Communication Channel access point for communication to field device
3.1.8 configuration system created by configuring the plant components and the topology
3.1.9 configure setting parameters at the instance data as well as the logical association of plant components to build up the plant topology (off-line)
Note 1 to entry: See also parameterize (3.1.38)
3.1.10 connection established data path for communication with a selected device
3.1.11 data set of parameter values
A data type is defined as a collection of data objects that adhere to a specific data structure, along with a set of allowable operations These data objects serve as operands during the execution of these operations.
DCS manufacturer system manufacturer manufacturer of the control system
Note 1 to entry: This note applies to the French language only
3.1.14 device independent physical entity of an automation system capable of performing specified functions in a particular context and delimited by its interfaces
[SOURCE: IEC 61499-1:2012, 3.29, modified – the note has been deleted]
3.1.15 field device networked independent physical entity of an automation system capable of performing specified functions in a particular context and delimited by its interfaces
3.1.16 device manufacturer manufacturer of fieldbus devices
3.1.17 device type device characterization based on abstract properties such as manufacturer, fieldbus protocol, device type identifier, device classification, version information or other information
The characterization scope can differ based on the properties defined for each set and is specific to the manufacturer of each DTM.
FDT objects that jointly are executed on different PCs in a network
The implementation of a distributed system is dependent on the vendor, as it may involve executing DTM and Presentation on separate PCs or running DTMs in a multi-user environment across different machines.
Note 2 to entry: This note applies to the French language only
3.1.19 documentation human readable information about a device instance
Note 1 to entry: This may be electronic information in a database
DTM software component containing device-specific application software
Note 1 to entry: The DTM is a generic class and means "Type Manager" The D is kept because the acronym is well-known in the market
Note 2 to entry: This note applies to the French language only
DTM device type software module for a particular device type within the DTM
Note 1 to entry: A DTM may contain one or more DTM device types
3.1.22 entity particular thing, such as a person, place, process, object, concept, association, or event [SOURCE: IEC 61499-1:2012, 3.31]
FDT model interface specification for objects and object behavior in a monitoring and control system
3.1.25 function specific purpose of an entity or its characteristic action
DTM which interprets device type or domain specific device descriptions and provides the FDT interfaces
Note 1 to entry: This note applies to the French language only
3.1.27 hardware physical equipment, as opposed to programs, procedures, rules and associated documentation
3.1.28 implementation development phase in which the hardware and software of a system become operational [SOURCE: IEC 61499-1:2012, 3.51]
3.1.29 instantiation creation of an instance of a specified type
3.1.30 interface shared boundary between two functional units, defined by functional characteristics, signal characteristics, or other characteristics as appropriate
Generic DTM which interprets device descriptions
3.1.32 mapping set of features or attributes having defined correspondence with the members of another set [SOURCE: IEC 61499-1:2012, 3.66]
3.1.33 multi-user environment environment which allows operation by more than one user
3.1.34 network all of the media, connectors, repeaters, routers, gateways and associated node communication elements by which a given set of communicating devices are interconnected
Note 1 to entry: In this document network is used to express that one or more interconnected fieldbus systems with different protocols can be applied
3.1.35 nested communication communication using a hierarchy of communication systems
3.1.36 operation well-defined action that, when applied to any permissible combination of known entities, produces a new entity
3.1.37 parameter variable that is given a constant value for a specified application and that may denote the application
3.1.38 parameterize setting parameters in a device or a block or an object
Note 1 to entry: See configure (3.1.9)
3.1.39 persistent data stored data that is preserved through shutdown/restart and maintenance activities
Process Channel representation of process value and its properties
3.1.41 service functional capability of a resource which can be modeled by a sequence of service primitives [SOURCE: IEC 61499-1:2012, 3.87]
3.1.42 session instance of user interactions within the FDT model
3.1.43 synchronization synchronization of data depending on the context where used
Note 1 to entry: For example, synchronization can occur between the DTM and the device or between several DTM instances having a reference to the same instance data
3.1.44 system set of interrelated elements considered in a defined context as a whole and separated from their environment
A system can consist of various elements, which may include both natural and artificial material objects, as well as cognitive processes and their outcomes, such as organizational structures, mathematical techniques, and programming languages.
The system is defined as being isolated from its environment and other external systems by an imaginary boundary, which effectively severs any connections between them and the system in question.
[SOURCE: IEC 60050-351:2013, 351-42-08, modified – some notes have been deleted]
3.1.45 transient data temporary data which have not been stored (while configuring or parameterizing)
3.1.46 type software element which specifies the common attributes shared by all instances of the type [SOURCE: IEC 61499-1:2012, 3.99]
3.1.47 variable software entity that may take different values, one at a time
Note 1 to entry: The values of a variable are usually restricted to a certain data type
Note 2 to entry: Variables are described as input variables, output variables, and internal variables
3.1.48 use case class specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system
Abbreviations
COM Component Object Model [IEC 62541-1]
CPF Communication profile family [IEC 61784-1]
DCS Distributed control system [IEC 62351-2]
IDL Interface definition language [ISO/IEC 24775]
OEM Original equipment manufacturer [IEC 62402]
OLE Object Linking and Embedding [IEC 61970-2]
OPC Open connectivity via open standards (originally: OLE for Process Control) [IEC 61970-2]
PLC Programmable logic controller [IEC 61131-1]
SCADA Supervisory, control and data acquisition [IEC 62443-1-1]
UML Unified modeling language [ISO/IEC 19501]
UUID Universal unique identifier [IEC 62755]
XML Extensible markup language [IEC 61970-2]
Conventions
The conventions for UML notation used in the IEC 62453 series are defined in Annex A
State of the art
In industrial automation, control systems integrate numerous binary and analog input/output signals through a communication network This network must accommodate various field devices from multiple manufacturers, either through direct connections or I/O multiplex units Many applications utilize over 100 distinct types of field devices, highlighting the complexity and diversity of the industrial landscape.
Each device features unique configuration and parameterization functions essential for its intended task When setting up a fieldbus coupler and bus communication, it is crucial to consider these device-specific properties and settings Additionally, the control system must be informed of the device's presence and capabilities Effective integration of device input and output signals, along with function block services, is vital for the successful planning of the control system.
The lack of a unified interface standard complicates the configuration process in control system projects due to the diverse range of device types and suppliers involved This necessitates the use of multiple tools, leading to increased time and effort To ensure consistency in data, documentation, and application configurations, extensive and expensive system testing is required.
Service and diagnostic tasks in control systems often fail to utilize the full functional capabilities of fieldbus devices Additionally, there is no assurance that tools designed for specific devices or modules can be integrated with other system software Generally, these device-specific tools are limited to direct connections with a particular fieldbus or a specific type of field device.
Figure 1 − Different tools and fieldbuses result in limited integration
Objectives of FDT
General features
Full integration of fieldbus devices or modules into automation systems requires a communication path from central engineering or operator terminals via the system and fieldbuses to the individual field devices
• central facilities for planning, diagnostics and service with direct access to all devices;
• integrated, consistent configuration and documentation of the automation system, its fieldbuses and devices;
• organization of common data for the automation system and the field devices;
• central data management and data security;
• simple, fast integration of different device and module types into the automation system
Integration of field devices into the engineering systems of automation technology can cover a small set of configuration, service and diagnostic functions as well as a large set of functions.
Device and module manufacturer benefits
FDT technology facilitates the integration of unique properties and features of various devices and modules, as illustrated in Figure 2 Manufacturers can incorporate planning and service tools as software components tailored to specific devices or modules within the engineering system This capability allows manufacturers to define configuration, service, and diagnostic functions, as well as customize the design of devices and modules in the automation system's engineering environment.
Standardizing software components significantly lowers manufacturing costs by enabling a single solution to manage configuration, service, and diagnostic functions across various automation systems This approach also removes the need for frequent, project-specific adaptations, which would otherwise require ongoing development and maintenance for multiple device and module types.
Device description Function blocks Device addresses Device parameters Device I/Os
Figure 2 – Full integration of all devices and modules into a homogeneous system
System manufacturer and integrator benefits
The control system manufacturer or integrator needs to implement the defined interfaces for integrating all fieldbus devices and modules just once, eliminating the need for manufacturer-specific or device-specific implementations and their ongoing maintenance.
Other applications
FDT is primarily intended for controlling device functionality and accessing data to configure control system components However, FDT interfaces can be utilized in various application contexts At the foundational level, they can retrieve raw data from devices and modules within SCADA, DCS, or PLC systems to configure the bus master Additionally, the Frame Application can initiate device-specific diagnostic applications through the DTM The architecture and design facilitate the development and integration of scalable DTMs, with functionality tailored to the device's capabilities.
FDT model
General
FDT facilitates the interaction between device-specific software components, fieldbus interface-specific software components and host systems (see Figure 3)
• The device-specific software components are called Device Type Managers (DTMs)
• The fieldbus interface-specific software components are called Communication Channels
• The host systems are called Frame Applications
Figure 3 – General architecture and components
A Frame Application serves as the runtime environment for Device Type Managers (DTMs), consisting of client applications that utilize DTMs, a database for the persistent storage of device data, and a communication channel to field devices These client applications are specialized, focusing on specific functions such as configuration, observation, channel assignment, and leveraging the services offered by the DTMs.
A Device Type Manager (DTM) contains software applications tailored to specific devices and definitions for various protocols This allows a Frame Application to manage any device type by seamlessly integrating the relevant DTMs, eliminating the necessity for specialized knowledge about the device or fieldbus.
Device and module-specific software components are essential for integrating products in automation systems For instance, DTM objects can represent standard measurement and control devices, with specialized DTMs available for various applications.
• software entities or function blocks that are movable and may be hosted by different modules in a network, also known as Block DTM (BTM) objects;
• modular equipment combinations, such as I/O stations with plug in boards to provide combinations of I/O and control functions also known as Module DTM objects
A Communication Channel serves as the gateway to fieldbus or point-to-point communication, offering services that are independent of the fieldbus interface Typically, protocol-specific services are aligned with the services provided by the channel These services facilitate data exchange between the Frame Application or a DTM and connected devices, enabling functions such as identification requests, device resets, and broadcasting.
FDT outlines the services and data exchanges required by each component, defining these services in a fieldbus-independent manner while allowing for the exchange of fieldbus-specific data The IEC 62453-3xy specifications detail the content and data format for manufacturer-independent fieldbuses, facilitating protocol profile integration within FDT Additionally, FDT permits manufacturers to create their own content and data formats tailored to specific fieldbuses or point-to-point communication.
The main features of the FDT concept are:
• Frame Application is the representation of the host tool where the DTMs are interacting with the control system, maintenance or engineering application;
• DTM is the main concept and can be applied for simple devices but also for modular devices, software components (function block);
Nested communication is essential for accommodating the needs of heterogeneous and hierarchical networks, where intelligent field devices are interconnected This serves as the foundation for various communication components outlined in the standard.
Graphical interfaces enable interactive access to the functionalities of intelligent field devices and their Device Type Managers (DTMs) This interaction is facilitated through presentation objects that represent these aspects effectively.
Frame Applications
Frame Applications serve as the runtime environment for the FDT system, featuring varied appearances based on their intended use, such as standalone configuration and engineering systems Despite these differences, all Frame Applications adhere to a set of general requirements.
• device and module-specific knowledge is not necessary;
• ability to manage all DTM instances and store instance data;
• ability to manage and create DTM communications and connections (including any necessary message routing);
• guarantee of system-wide consistent configuration;
• enables multi-user and server/client operation (optional);
• takes care of data versions and consistency
FDT is a specification to facilitate the interaction between device-specific objects (i.e presentation and DTM) and the Frame Application This is shown in Figure 4
A Frame Application serves as the runtime environment for device-specific objects, typically consisting of client applications that utilize Device Type Managers (DTMs), a database for the persistent storage of device data, and a communication link to field devices.
Client applications are single applications focusing on specific aspects such as configuration, observation, channel assignment, and using the functionality provided by the DTM as a server
The IEC 62453 series differentiates between the specification of interactions among objects, such as Frame Applications and Device Type Managers (DTMs), and the technology used for their implementation It focuses solely on defining the expected behavior of these objects for client applications that utilize them.
Device Type Manager
DTM objects are supplied by the device manufacturer together with the device The following properties are characteristic for the DTM:
• graphical user interfaces as defined by this specification;
• all rules of the device are known;
• all user dialogs are contained;
• user interface (multilingual including help system);
• parameter validity check (also depending on other device-specific parameters);
• automatic generation of dependent parameters;
• processing sequences are defined for complex calibration, and setup procedures where needed;
• reading and writing of parameters from/to the field device;
• diagnostic functions customized for the device;
• provision of the type-specific data for establishment of communication;
• provision of device/instance-specific data, for example to be used in function planning;
• device or instance specific documentation;
• no direct connection to any other device;
• no information on the engineering environment;
• support for one or more device types
Device manufacturers determine the number and range of functions for a Device Type Manager (DTM) based on the capabilities of the supported devices A DTM typically manages at least one field device but can also encompass device families, such as pressure transmitters, or an entire product range from a manufacturer Communication and data management are facilitated through the interfaces of the engineering tool or Communication DTMs, utilizing various bus systems within a control system.
DTMs can be categorized into Specific DTMs, which are tailored for individual devices or families, and Generic DTMs, which support devices based on a device profile or by incorporating a device description, such as a DD or FDI device package.
In the context of system planning and plant management, it is essential to integrate a DTM with the relevant engineering tool to ensure data consistency To prevent issues, it is advisable to avoid simultaneous access by standalone tools and the engineering tool to the same devices However, parallel standalone operation may be permissible in specific scenarios, such as during the transition from a standalone tool to a DTM.
A Device Type Manager (DTM) is integrated into engineering tools or applications that oversee device instances, facilitating communication and assisting with device-specific functions These applications are commonly known as 'Frame Applications'.
Communication Channel concept
The IEC 62453 series defines the FDT objects and interfaces that facilitate communication between Frame Applications and device-specific applications known as DTMs Frame Applications, which can include engineering tools, operator stations, or standalone tools, function as clients, while DTMs serve as servers in this interaction.
DTMs can be linked to either monolithic or distributed Frame Applications, utilizing various components from multiple manufacturers These Frame Applications are capable of managing and integrating several DTMs from one or more suppliers.
Figure 5 – General FDT client/server relationship
Frame Application Standalone Tool vendor #2
Frame Application Operater Station vendor #1
Server DTM Vendor A Server DTM Vendor B
DTMs consist of a server object and related objects, which together illustrate the device and block from the perspective of an external application The server object encapsulates the available functionalities of the device and block.
There are two different types of channels, the Communication Channel and the Process Channel
The Communication Channel object provides access to the fieldbus and is communication technology dependent
The Process Channel delivers essential information regarding the I/O values of a device or module, including access, units, range, and labels This data is crucial for client applications to accurately contextualize parameters for effective visualization.
The Device Type Manager (DTM) acts as a communication client, utilizing the Communication Channel for data transactions When a device is directly connected to a fieldbus, its FDT object hierarchy is represented accordingly The DTM communicates with the device through this Communication Channel In cases where the device is part of a communication hierarchy, it is represented in the software using appropriate FDT objects, with each fieldbus corresponding to a Communication Channel and gateways represented by specific DTM objects Notably, the device DTM is unaware of the underlying communication hierarchy, focusing instead on maintaining the device's functionality while the Communication Channel object facilitates external communication.
The DTM provides the Process Channel for semantic information about the I/O parameters (i.e DTMs are information servers) The DTM provides the semantic information to the application using the Process Channel
Figure 6 – Typical FDT channel architecture
SCADA/DCS using FDT Frame
Each Process Channel provides information to access and interpret about device-specific I/O values (e.g data types, ranges, alarms, etc) (see Figure 7)
I/O value-related parameters provide essential information for Frame Applications to integrate device I/O data Typically, Process Channels that convey these parameters serve as representations rather than actual data sources It is important to view these parameters as specifying the address of the data, rather than the data source itself.
Presentation object
The presentation object offers an optional graphical user interface for the DTM, BTM, and Communication Channel It can be seamlessly integrated into the Frame Application's GUI or function as a standalone executable outside of it.
5 Structure of the IEC 62453 series
Structure overview
In addition to this overview, the FDT interface specification has several parts as shown in Figure 8
IEC parameter 1 Channel parameter 2 parameter 3
Figure 8 – Structure of the IEC 62453 series
The FDT interface specification outlines the connections between device-specific objects, client applications within the Frame Application, and the FDT channel for communication functions These interfaces utilize services that facilitate the commands and information necessary for effective client-server interactions.
The IEC 62453 series is structured to separate the objects, client applications and channel service specifications from their mapping to any specific implementation technology
Separate parts of the IEC 62453 series are used as follows:
• concepts and details of objects and services are specified in Part 2;
• communication profile integration for different communication services is specified in Parts 3xy;
• object model integration profiles implementation technologies are specified in Parts 4x;
• communication implementation for common object model for different communication services is specified in Parts 5z-xy
The IEC 62453 series includes the following parts:
Part 2: Concepts and detailed description
Part 301: Communication profile integration – IEC 61784 CPF 1
Part 302: Communication profile integration – IEC 61784 CPF 2
Part 303-1: Communication profile integration – IEC 61784 CP 3/1 and CP 3/2
Part 303-2: Communication profile integration – IEC 61784 CP 3/4, CP 3/5 and CP 3/6 Part 306: Communication profile integration – IEC 61784 CPF 6
Part 309: Communication profile integration – IEC 61784 CPF 9
Part 315: Communication profile integration – IEC 61784 CPF 15
Part 41: Object model integration profile – Common object model
Part 2 Concepts and detailed detailed description
Part 4z Implementation Profile Part 5z-xy
Part 42: Object model integration profile – Common Language Infrastructure
Part 51-10: Communication implementation for common object model – IEC 61784 CPF 1 Part 51-20: Communication implementation for common object model – IEC 61784 CPF 2 Part 51-31: Communication implementation for common object model – IEC 61784 CP 3/1 and CP 3/2
Part 51-32: Communication implementation for common object model – IEC 61784 CP 3/4,
The article discusses the communication implementation for the Common Object Model as outlined in IEC 61784, specifically focusing on CPF 6, CPF 9, and CPF 15 Additionally, it addresses the communication implementation for the Common Language Infrastructure.
Part 52-20: Communication implementation for common language infrastructure –
Part 52-31: Communication implementation for common language infrastructure –
Part 52-32: Communication implementation for common language infrastructure –
IEC 61784 CP 3/4, CP 3/5 and CP 3/6
Part 52-90: Communication implementation for common language infrastructure –
Part 52-150: Communication implementation for common language infrastructure –
Part 61: Device Type Manager (DTM) Styleguide for common object model
Part 62: Field Device Tool (FDT) Styleguide for common language infrastructure
The remainder of Clause 5 describes the principle content of the parts.
Part 2 – Concepts and detailed description
Part 2 is the FDT interface specification It contains abstract specifications of all objects, their behavior, their interface services and interactions IEC 62453-2 is normative.
Parts 3xy – Communication profile integration
General
IEC 62453-3xy outlines the communication services necessary for an FDT application, which depend on the implementation of suitable profiles derived from relevant technologies The specific communication implementation profiles are detailed in the associated sections of IEC TR 62453-5xy.
The IEC 62453-3xy parts have normative content and at least one communication technology profile is required for a working implementation
NOTE The initial specification includes several communication technology profiles and additional profiles can be added in future editions of this Part of IEC 62453.
Communication profile integration – IEC 61784 CPF 1
IEC 62453-301 provides information for integrating FOUNDATION™ Fieldbus 1 technology into the FDT interface specification (IEC 62453-301).
Communication profile integration – IEC 61784 CPF 2
IEC 62453-302 provides information for integrating CIP™ 2 technology into the FDT interface specification (IEC 62453-302).
Communication profile integration – IEC 61784 CP 3/1 and 3/2
IEC 62453-303-1 provides information for integrating PROFIBUS 3 technology into the FDT interface specification (IEC 62453-303-1).
Communication profile integration – IEC 61784 CP 3/4, CP 3/5 and 3/6
IEC 62453-303-2 provides information for integrating PROFINET 3 technology into the FDT interface specification (IEC 62453-303-2).
Communication profile integration – IEC 61784 CPF 6
IEC 62453-306 provides information for integrating INTERBUS® 4 technology into the FDT interface specification (IEC 62453-306).
Communication profile integration – IEC 61784 CPF 9
IEC 62453-309 provides information for integrating HART® 5 technology into the FDT interface specification (IEC 62453-309).
Communication profile integration – IEC 61784 CPF 15
IEC 62453-315 provides information for integrating Modbus® 6 technology into the FDT interface specification (IEC 62453-315)
FOUNDATION™ Fieldbus is a trademark owned by the non-profit consortium Fieldbus Foundation This information is provided for user convenience regarding IEC 62453 and does not imply IEC's endorsement of the trademark or its products Compliance with the standard does not necessitate the use of the trademark, and permission from the trademark holder is required for its use.
2 CIP™ is a trademark owned by ODVA, Inc This information is provided for user convenience regarding IEC 62453 and does not imply IEC's endorsement of the trademark or its products Compliance with IEC 62453 does not necessitate the use of the trademark, and permission from the trademark holder is required for its use.
PROFIBUS and PROFINET are trademarks of the non-profit organization PROFIBUS Nutzerorganisation e.V (PNO) This information is provided for user convenience within IEC 62453 and does not imply IEC's endorsement of the trademark holder or its products Compliance with the standard does not necessitate the use of the trade name, which requires permission from the trademark holder.
INTERBUS is a trademark owned by Phoenix Contact GmbH & Co KG, with its usage regulated by the non-profit INTERBUS Club This information is provided for user convenience regarding IEC 62453 and does not imply IEC's endorsement of the trademark or its products Compliance with IEC standards does not necessitate the use of the INTERBUS trade name, which requires permission from the trademark holder for its use.
5 HART is the official trade name of the HART Communication Foundation, provided here for user convenience within IEC 62453 This mention does not imply IEC's endorsement of the trademark holder or its products Compliance with the standard does not necessitate the use of the trade name, which requires permission from the trademark holder.
Modbus, a trademark of Schneider Automation Inc., is registered in the United States and other countries This information is provided for user convenience regarding IEC 62453 and does not imply IEC's endorsement of the trademark holder or its products Compliance with IEC 62453 does not necessitate the use of the trade name, which requires permission from the trademark holder.
Parts 4z – Object model integration profiles
General
IEC 62453-2 outlines the requirements for object behavior and client/server functions in FDT applications To implement these features effectively, appropriate technology profiles are necessary The specifications for these object implementation profiles can be found in different sections of IEC TR 62453-4.
The IEC TR 62453-4z parts have informative content and explain the additions to IEC 62453-
2, which are necessary to implement FDT based on a specific technology Each Part 4z defines a specific technology, IEC TR 62453-41 specifies the implementation profile for a common object model technology.
Object model integration profile – Common object model (COM)
IEC TR 62453-41 contains all the details of the services provided by implementation technology dependent interfaces based on COM IEC TR 62453-41 is informative and therefore a TR.
Object model integration profile – Common language infrastructure (CLI)
IEC TR 62453-42 contains all the details of the services provided by implementation technology dependent interfaces based on CLI IEC TR 62453-42 is informative and therefore a TR.
Parts 51-xy/52-xy – Communication profile implementation
General
The IEC TR 62453-51-xy and IEC TR 62453-52-xy documents outline the implementation syntax for communication services in FDT applications These profiles are derived from the communication services detailed in the various sections of IEC 62453-3xy.
The IEC TR 62453-51-xy parts provide implementation syntax based on IEC 62453-41
The IEC TR 62453-52-xy parts provide implementation syntax based on IEC 62453-42
The IEC TR 62453-51-xy and IEC TR 62453-52-xy parts have informative content and at least one implementation of a communication technology profile is required for a working implementation
NOTE The specification includes several communication technology profiles and additional profiles can be added in future editions of IEC 62453-1.
Communication profile implementation – IEC 61784 CPF 1
IEC TR 62453-51-10 and IEC TR 62453-52-10 provide the syntax for integrating FOUNDATION™ Fieldbus technology into the FDT interface specification (IEC TR 62453-51-
10 for COM integration and IEC TR 62453-52-10 for CLI integration).
Communication profile implementation – IEC 61784 CPF 2
IEC TR 62453-51-20 and IEC TR 62453-52-20 provide the syntax for integrating CIP™ technology into the FDT interface specification (IEC TR 62453-51-20 for COM integration and IEC TR 62453-52-20 for CLI integration).
Communication profile implementation – IEC 61784 CP 3/1 and 3/2
IEC TR 62453-51-31 and IEC TR 62453-52-31 provide the syntax for integrating PROFIBUS technology into the FDT interface specification (IEC TR 62453-51-31 for COM integration and IEC TR 62453-52-31 for CLI integration).
Communication profile implementation – IEC 61784 CP 3/4, CP 3/5 and 3/6
IEC TR 62453-51-32 and IEC TR 62453-52-32 provide the syntax for integrating PROFINET technology into the FDT interface specification (IEC TR 62453-51-32 for COM integration and IEC TR 62453-52-32 for CLI integration).
Communication profile implementation – IEC 61784 CPF 6
IEC TR 62453-51-60 provides the syntax for integrating INTERBUS® technology into the FDT interface specification (IEC TR 62453-506 for COM integration)
NOTE The syntax for integrating INTERBUS® into CLI is not defined yet.
Communication profile implementation – IEC 61784 CPF 9
IEC TR 62453-51-90 and IEC TR 62453-52-90 provide the syntax for integrating HART® technology into the FDT interface specification (IEC TR 62453-51-90 for COM integration and IEC TR 62453-52-90 for CLI integration).
Communication profile implementation – IEC 61784 CPF 15
IEC TR 62453-51-150 and IEC TR 62453-52-150 provide the syntax for integrating Modbus® technology into the FDT interface specification (IEC TR 62453-51-150 for COM integration and IEC TR 62453-52-150 for CLI integration).
Parts 6z – DTM styleguides
General
Besides the technical specifications provided in IEC 62453-2 and IEC TR 62453-4z guidelines are provided that support a consistent look and feel of DTMs
The IEC TR 62453-6z series provides essential information on the enhancements to IEC 62453 required for a uniform appearance based on specific technologies Each part of the series focuses on a particular technology, with IEC TR 62453-61 outlining the style guide for the common object model technology, while IEC TR 62453-62 details the style guide for the common language infrastructure technology.
Device Type Manager (DTM) styleguide for common object model
IEC TR 62453-61 contains all the details of the GUI design bases on the COM implementation technology IEC TR 62453-61 is informative and a Technical Report.
Field Device Tool (FDT) styleguide for common language infrastructure
IEC TR 62453-62 contains all the details of the GUI design bases on the CLI implementation technology IEC TR 62453-62 is informative and a Technical Report
6 Relation of the IEC 62453 series to other standardization activities
Field devices and modules are essential components of industrial automation systems, designed to fulfill specific applications These systems are structured in multiple hierarchical levels, interconnected through communication systems, as depicted in Figure 9.
A communication system, such as a fieldbus, links field devices to higher-level controllers, which usually include programmable logic controllers (PLCs), distributed control systems (DCSs), or manufacturing execution systems (MESs) Engineering and commissioning tools, capable of accessing both field devices and controllers, are positioned at the controller level.
In extensive automation systems, the next tier is often linked through communication networks like Ethernet, incorporating sophisticated visualization systems (HMI), central engineering tools, and SCADA host systems Various clusters of field devices, whether equipped with controllers or not, can interconnect with each other or connect to higher-level systems via communication networks such as fieldbus.
Additional levels can enhance support for manufacturing execution systems (MES), enterprise resource planning (ERP), and other IT-based systems by enabling access to field devices either indirectly through LANs and controllers or directly via routers.
Figure 9 – Standards related to IEC 62453 in an automation hierarchy
Several standards govern the communication and integration of field devices within automation systems, as illustrated in Figure 9, which highlights the levels where the specified functions or elements are typically implemented.
Device profiles in terms of parameter lists, function blocks or objects are usually intended to be implemented in field devices (IEC 61915-1, IEC 61800-7 series, IEC 61804-2 and IEC TR
Industrial communication standards are defined by IEC 61158, IEC 61784-1, IEC 61784-2, and the IEC 62026 series The IEC 61131 series focuses on programming languages for controllers, while the ISO 15745 series, IEC 61804-3, IEC 61915-1, and IEC 61850 series provide description languages for field devices Additionally, elements from both the IEC 61131 and IEC 61499 series can be utilized in the design and programming of advanced functions for operation, commissioning, and maintenance stations.
The IEC 62453 series provides generic interfaces to various host applications needing to interact with field devices and their related control functions
Higher level applications such as MES and ERP are reflected in the IEC 62264 series
Table 1 gives a short summary of the above-mentioned standards:
Table 1 – Overview of related standards
The IEC 61131-3 standard outlines the textual programming languages Structured Text and Instruction List, alongside the graphical languages Ladder Diagram and Function Block Diagram These languages are designed to operate cohesively within a unified software model for Programmable Logic Controllers (PLCs), utilizing shared components like variables and tasks.
IEC 61158 IEC 61158 is a collection of multiple fieldbus and Ethernet based industrial communication specifications These communication systems represent the actual state of the art of industrial communication
IEC 61499 series Function blocks for industrial measurement and control systems General function block model using an event driven architecture
1/IEC 61784-2 IEC 61784-1/IEC 61784-2 describe communication profiles of certain fieldbuses based on the specifications of IEC 61158
The IEC 61800-7x series provides a standardized interface and profiles for power drive systems Specifically, IEC 61800-7-1 defines a generic interface for power drives, while IEC 61800-7-2 outlines various power drive profiles Additionally, IEC 61800-7-3 details the mapping of these profiles and interfaces to facilitate compatibility with network communication technologies, including IEC 61158.
IEC 61804-2 This standard specifies FB by using the device model which defines the components of an
IEC 61804-2 outlines the essential specifications for Function Blocks (FBs) used in measurement, actuation, and processing, emphasizing general rules that facilitate control while promoting innovation and specialization across various industrial sectors This standard enables the mapping of conceptual FB specifications to specific communication systems, supported by definitions from industrial groups.
IEC 61804-3 defines the Electronic Device Description Language (EDDL) technology, facilitating the integration of actual product details throughout the engineering life cycle EDDL bridges the gap between the conceptual function block specification of IEC 61804-2 and product implementation, serving as a generic language for detailing the properties of automation system components.
• device parameters and their dependencies;
• device functions, for example, simulation mode, calibration;
• graphical representations, for example, menus;
The IEC 61850 series, known as "Communication networks and systems for power utility automation," serves as the global standard for information models and exchange in substation automation This series has established itself as the foundational standard for modeling power systems information, facilitating communication between devices, and configuring systems throughout the electrical energy supply chain Substation information is structured using logical nodes, data objects, and data attributes.
IEC 61915-1 “Low-voltage switchgear and control gear – Device profiles for networked industrial devices –
Part 1: General rules for the development of device profiles“ defines a frame work for common representation of networked industrial devices including a profile template for documentation Main focus is drawn to the above-mentioned device classes This representation follows the principles given in the IEC TR 62390 “Common automation device – Profile guideline“; also refer to ISO 15745
The IEC 62026 series outlines the communication interfaces for low-voltage switchgear and control gear, facilitating connections with controllers such as programmable controllers and personal computers in industrial automation Specifically, IEC 62026-1 establishes the common requirements for these controller-device interfaces (CDIs), while the following parts detail various CDI technologies, adhering to a standardized document structure as defined in IEC 62026-1.
IEC TR 62390 offers guidance for creating device profiles for industrial field and control devices, regardless of their complexity This report emphasizes the functional aspects of devices and serves as a recommended guideline for standardization committees, fieldbus consortia, and product manufacturers in developing profiles for networked devices Additionally, some elements of this guideline may apply to standalone devices, aiming to establish a common and more generic approach for publishing device information and behavior.
IEC 62769 This international standard describes the concepts and overview of the Field Device Integration
(FDI) Field devices are represented by device packages which are based on EDDL (IEC 61804-3 and IEC 61804-4) and optional by programmed graphical user interface (compatible with
IEC 62453-42) The devices packages are integrated in a client-server-architecture The server provides an information model at the interface which optionally may use OPC UA (IEC 62541 series)
ISO 9506-1 Manufacturing Message Specification (MMS) MMS specifies structure for messages required to control and monitor intelligent electronic devices It is an OSI Reference model layer 7 specification
ISO 15745 series ”Industrial automation systems and integration – Open system application integration framework”
ISO 15745-1 outlines the fundamental elements and guidelines for creating integration models and application interoperability profiles, including process, information exchange, and resource profiles Additional sections detail technology-specific elements for communication network profiles and device profiles related to various fieldbus technologies This standard also introduces a device model supported by an XML schema, facilitating the generation of an XML device description file.
ISO/IEC 19501 “Information technology – Open Distributed Processing – Unified Modeling Language (UML)
Version 1.4.2” UML provides means for the specification of objects, their relations and behavior UML is frequently used in international standards
Architecture
The FDT functionality and the chosen architecture are described in an abstract way in IEC 62453-2 The description includes:
• their relation to each other (e.g aggregation or specialization);
• the description of services and service primitives of all FDT elements together with their mandatory and optional arguments The arguments are structured data types
Each implementation technology dependent detail of the services is described in IEC 62453-
41 This means that the syntax of the service primitives in detail as well as the interface definition for FDT is specified.
Dynamic behavior
The dynamic behavior of an FDT system is described in IEC 62453-2 using sequence diagrams to show the interactions using abstract message names
Device configuration tool and DCS
The details of these interactions are described in IEC 62453-41 using the syntax defined in the FDT IDL
The dynamic behavior and data management of a Device Type Manager (DTM) are outlined through state machines in IEC 62453-2 This standard provides an abstract view of DTM behavior, while IEC 62453-41 and IEC 62453-42 focus on the implementation specifics of states and transitions, utilizing service mapping syntax for the corresponding interface methods based on the relevant technology.
IEC 62453-41 and IEC 62453-42 each describe additional implementation specific dynamic behavior.
Structured data types
The service primitive arguments are structured data types They are described in IEC 62453-2 as abstract data types IEC 62453-41 describes them in terms of XML schemas IEC 62453-
42 describes them in terms of CLI data types.
Fieldbus communication
The Communication Profile Family (CPF) utilizes specific service primitives that are transmitted through the Communication Channel mechanism, as outlined in IEC 62453-2 The syntax for these Communication Channel service primitives is detailed in the implementation-dependent specifications found in IEC 62453-41 and IEC 62453-42.
IEC 62453-3xy outlines all CPF-specific services and service primitives, detailing their mandatory and optional arguments Additionally, IEC TR 62453-5z-xy provides the implementation-dependent schema required for transmitting the communication service primitives specified in the corresponding IEC 62453-3xy section.
General
Note contains information for people reading the UML diagram (or model) Notes provide additional context to help explain details that are not apparent in the diagram (see Figure A.1)
Class diagram
The class diagram is one of the UML specification methods The UML elements, which are used in the class diagrams of the IEC 62453 series are explained in the following
Class is a description of a set of objects that share the same attributes, operations, methods, relationships, and semantics (see Figure A.2)
An abstract class is a type of class that cannot be instantiated directly and serves primarily for specification purposes It is defined as abstract when it has no instances and is intended solely for inheritance In written form, abstract classes are typically denoted by an italicized class name.
Association is the semantic relationship (between two or more classifiers) that specifies connections among their instances (see Figure A.3)
Composition represents a symmetric relationship that defines how a whole and its parts are interconnected, where the removal of the whole leads to the elimination of its parts.
Composite Class Composition Part Class
Aggregation is a form of asymmetric association that specifies a whole-part relationship between the aggregate (whole) class and a subordinate (part) class (see Figure A.5)
Dependency is a form of association that specifies a dependency relationship between two classes An arrowhead can be used to indicate an asymmetric dependency (see Figure A.6)
Generalization refers to the taxonomic relationship between a broader element and a more specific one, ensuring consistency while providing additional information This concept is applicable to various elements, including classes, packages, and use cases, and is also utilized to describe inheritance.
Figure A.7 – Abstract class, generalization and interface
An interface is a mechanism that allows for the convenient packaging and reuse of method signatures and properties, serving as an abstract class without any underlying method implementations It acts as a promise to implement a standard set of methods and properties Both abstract and concrete classes can inherit from an interface, with concrete classes providing the actual implementation For example, a concrete class can implement multiple interfaces, such as Interface1 and Interface2, as illustrated in Figure A.7.
Multiplicity specification is represented as a text string containing a comma-separated sequence of integer intervals Each interval is formatted as lower-bound upper-bound, indicating a closed range of integers from the lower to the upper bound The lower and upper bounds are literal integer values, and the star character (*) can be used for the upper bound to signify an unlimited range.
Statechart diagram
A statechart diagram visually represents a state machine, utilizing specific symbols for states and pseudostates Transitions between these states are depicted by directed arcs, illustrating the connections within the state machine.
Figure A.9 – Elements of UML statechart diagrams
A state is shown as a rectangle with rounded corners Optionally, it may have an attached name tab
An initial state (pseudostate) is shown as a small solid filled circle
A final state is shown as a circle surrounding a small solid filled circle (a bull’s eye)
A composite (super) state is represented as a rectangle with rounded corners that encloses two small ellipses This state is formed from a collection of sub-states, which are interconnected by transitions.
Figure A.10 – Example of UML state chart diagram
Use case diagram
A use case diagram serves as a class diagram that outlines the necessary interactions with a system, featuring actors, use cases, and their relationships Figure A.11 illustrates the UML syntax employed in this standard.
Figure A.11 – UML use case syntax
An actor is shown as a person It can represent a human being or another external system interaction with the system which is specified
A use case defines a functional requirement by illustrating the interaction between an actor and the system Complex interactions can be derived from simpler ones, which is represented by the 'include' relationship.
An inheritance relation is represented by a dashed line with a triangle pointing to the parent, indicating the more general element In this standard, inheritance among actors signifies that one actor 'inherits' the permissions to execute specific use cases from another actor.
Sequence diagram
The sequence diagram is a diagram that depicts an interaction by focusing on the sequence of messages between objects on the lifelines (see Figure A.12)
Object instances are represented by a vertical line
A message is represented by an arrow In this standard, a full arrow is used to depict the general occurrence of a message independently of synchronous or asynchronous handling of the message
The sequence of messages is defined by the order of messages starting from the top of the diagram
Return information of the message
FDT technology utilizes component-based architecture, where software modules from various manufacturers are integrated into a cohesive system The responsibility for ensuring the compliance of these software modules lies with the suppliers of FDT-based software Meanwhile, system integrators and technology organizations must establish a robust integration framework along with testing programs or certification processes to facilitate the efficient and secure integration of the individual modules.
IEC 60050 (all parts), International Electrotechnical Vocabulary
NOTE See also the IEC Multilingual Dictionary – Electricity, Electronics and Telecommunications (available on CD-ROM and at http://www.electropedia.org/)
IEC 61131 (all parts), Programmable controllers
IEC 61131-3, Programmable controllers – Part 3: Programming languages
IEC 61158-1, Industrial communication networks – Fieldbus specifications – Part 1: Overview and guidance for the IEC 61158 and IEC 61784 series
IEC 61375-3-3, Electronic railway equipment – Train communication network (TCN) – Part 3-3: CANopen Consist Network (CCN)
IEC 61499 (all parts), Function blocks
IEC 61499-1, Function blocks – Part 1: Architecture
IEC 61784-1, Industrial communication networks – Profiles – Part 1: Fieldbus profiles
IEC 61784-2, Industrial communication networks – Profiles – Part 2: Additional fieldbus profiles for real-time networks based on ISO/IEC 8802-3
IEC 61784 (all parts), Industrial communication networks – Profiles
IEC 61800-7-1, Adjustable speed electrical power drive systems – Part 7-1: Generic interface and use of profiles for power drive systems – Interface definition
IEC 61800-7-2 (all parts), Adjustable speed electrical power drive systems – Part 7-2: Generic interface and use of profiles for power drive systems – Profile specifications
IEC 61800-7-3 (all parts), Adjustable speed electrical power drive systems – Part 7-3: Generic interface and use of profiles for power drive systems – Mapping of profiles to network technologies
IEC 61804-2, Function blocks (FB) for process control – Part 2: Specification of FB concept
IEC 61804-3, Function Blocks (FB) for process control and Electronic Device Description Language (EDDL) – Part 3: EDDL syntax and semantics
IEC 61804-4, Function blocks (FB) for process control and electronic device description language (EDDL) – Part 4: EDD interpretation
IEC 61850 (all parts), Communication networks and systems for power utility automation
IEC 61915-1, Low-voltage switchgear and controlgear – Device profiles for networked industrial devices – Part 1: General rules for the development of device profiles
IEC TS 61970-2, Energy management system application program interface (EMS-API) – Part 2: Glossary
IEC 62026 (all parts), Low-voltage switchgear and controlgear – Controller-device interfaces
IEC 62026-1, Low-voltage switchgear and controlgear – Controller-device interfaces (CDIs) – Part 1: General rules
IEC 62264 (all parts), Enterprise-control system integration
IEC TR 62390, Common automation device – Profile guideline
IEC 62402, Obsolescence management – Application guide
IEC TS 62443-1-1, Industrial communication networks – Network and system security – Part 1-1: Terminology, concepts and models
IEC 62453 (all parts), Field Device Tool (FDT) interface specification
IEC 62541 (all parts), OPC Unified Architecture
IEC TR 62541-1, OPC Unified Architecture – Part 1: Overview and Concepts
IEC 62755, Radiation protection instrumentation – Data format for radiation instruments used in the detection of illicit trafficking of radioactive materials
IEC 62769 (all parts), Field device integration (FDI)
IEC TR 80001-2-1, Application of risk management for IT-networks incorporating medical devices – Part 2-1: Step by step risk management of medical IT-networks – Pratical applications and examples
ISO/IEC 7498 (all parts), Information processing systems – Open Systems Interconnection –
ISO/IEC 19501:2005, Information technology – Open Distributed Processing – Unified
ISO/IEC 24775, Information technology – Storage management
ISO 2382 (all parts), Information technology – Vocabulary
ISO 9506-1, Industrial automation systems – Manufacturing Message Specification – Part 1: Service definition
ISO 15745 (all parts), Industrial automation systems and integration – Open systems application integration framework
ISO 15745-1, Industrial automation systems and integration – Open systems application integration framework – Part 1: Generic reference description