If the Frame Application has built-in communication capabilities, then it is able to provide Communication Channels see 4.2.4.3 which provide the services to access the fieldbus.. repres
Terms and definitions
For the purposes of this document, the terms and definitions given in IEC 62453-1 as well as the following apply
DTM instance in an FDT Project, which is classified by its relation to a Parent DTM
Note 1 to entry: Any DTM which uses FDT communication may be classified as Child DTM (i.e Device DTM, Gateway DTM, Module DTM and BTM)
FDT version implementation version defined by the related technology specific organization
Note 1 to entry: The FDT version is specified in IEC TR 62453-41 or in IEC TR 62453-42
3.1.3 monolithic DTM one single DTM that represents the complete device with all its modules
Note 1 to entry: There are also other concepts representing modules of a device in this specification, for example Module DTM and BTM
DTM instance in an FDT Project, which is classified by its relation to a Child DTM
Note 1 to entry: Any DTM which provides FDT communication may be classified as Parent DTM (e.g Communication DTM, Gateway DTM, Composite Device DTM)
Symbols and abbreviated terms
For the purposes of this document, the symbols and abbreviations given in IEC 62453-1 as well as the following apply
OODMS Object Oriented Database Management System
RDBMS Relational Database Management System
Conventions
Use of UML
The conventions for UML notation used in this document are defined in IEC 62453-1.
State availability statement
The state availability statement uses [_] and [X] for stating the availability of a service in a specific state The expressions have the following meaning:
[_] ‘’ service is not available in this state;
[X] ‘’ service is available in this state.
Data type names and references to data types
The conventions for naming and referencing data types are explained in Clause A.1
General
Clause 4 introduces the FDT model and covers topics which are specific to the requirements of field device integration.
Abstract FDT model
FDT model overview
The UML class diagram in Figure 2 provides an overview of the objects defined in FDT and their relationships to each other
DTM presentation DTM channels linked communication channels
Table 1 contains brief descriptions of all objects A more detailed description of objects and related services is provided in subsequent clauses 4.2.2 to 4.2.4
The FDT objects may be executed all on one platform or in a distributed system
Data exchange and object interaction rely on the data types outlined in Annex A The specific implementation of these data types is detailed in the IEC 62453-4z documents, which describe how they map to various implementation technologies.
Table 1 – Description of FDT objects
The Frame Application serves as a logical object that represents environments such as engineering systems or standalone tools, managing the lifecycle of DTM instances within the project.
A Frame Application may handle several projects
Project The Project belongs to the Frame Application
The Project is a logical object describing the management of device-instances It controls the lifetime and dataset of device-instances within a Frame Application
FDT does not define any services for the Project, since it is a pure Frame Application internal object
Host Channel A Host Channel belongs to the Frame Application
The Host Channel is a logical object representing a part of a function of a host system, such as DCS or PLC
It is required when additional information for the processing of device I/O data is needed, e.g if DTM or BTM data refers to more than one I/O value
For example one Octet often is used to group the state values of eight digital I/O points
In these applications, the Host Channel object provides an association between the contents of the channel data and individual process I/O points
To enable cyclic I/O data in a Frame Application, it is essential to establish an association between I/O function blocks and a device's process values The inputs and outputs of these I/O function blocks are denoted by Host Channels, while the process value is represented by a Channel This relationship between the Host Channel and the Channel is referred to as channel assignment.
FDT does not define any services for the Host Channel, since it is a pure Frame Application internal object
A Device Type Manager (DTM) is a software component that includes application software tailored for specific devices, encapsulating essential data, functions, and business rules Typically, a DTM is not an independent executable; it requires a Frame Application to serve as its runtime environment.
A Device Type Manager (DTM) is usually created by the device manufacturer and is included with the devices The functionality of a DTM varies based on its software design, determining whether it supports a specific device type, a range of different device types, or an entire family of device types.
Each device in a plant is represented by a DTM object, necessitating one or more DTM objects to manage various devices These DTMs are integrated into the system, allowing for dynamic expansion by adding new DTMs for additional devices.
A DTM may represent different types of devices, e.g field devices, communication devices or gateway devices (see 4.2.3)
Presentation Presentation objects (see 4.2.3.3) represent a (visual) user interface The Presentation object belongs to the DTM, to the BTM or to the Channel
Channel Channel object could behave in three ways: As a ‘Communication Channel’, a ‘Process
Channel’ and a combination of both (see 4.2.4)
All the associations shown in Figure 2 above are explained in Table 2 below
Table 2 – Description of associations between FDT objects
To enable cyclic I/O data access within a Frame Application, it is essential to establish an association between the I/O function blocks and the device's process values The I/O function blocks are represented by a Host Channel, while the process values are denoted by a channel The Frame Application (project) manages this critical association.
Informational services – DTM service: GetChannels – channel service: ReadChannelInformation Management services
– channel service: WriteChannelInformation Depending services
– proprietary DTM services for channel management channel presentation The instances of Presentation objects are associated with the instance of their DTM business object by this relationship
– all channel use cases with DTM specific GUI Services:
Informational services (see also 7.3) – channel service: GetChannelFuntions – channel service: GetGuiInformation Depending services
– frame service: OpenPresentationRequest – frame service: ClosePresentationRequest devices A project holds the list of DTM instances by the association devices
Releasing the project results in a release of all associated DTM instances A DTM instance cannot be part of more than one project
– system generation – system planning Services:
Informational services – frame service: GetChildNodes Management services
– services related to sub-topology management, see 7.6.2 – ValidateAddChild
– ChildAdded – ValidateRemoveChild – ChildRemoved – FA services related to topology management
DTM channels A DTM can have a list of channels, which are associated with DTM channels A channel is part of a DTM
Informational services – frame service: GetChannels Management services
– There are no services to manipulate this association The lifetime of channel instances is controlled by a DTM
DTM presentation The Presentation object instances are associated with their DTM instance by this relationship
– All DTM use cases with DTM specific GUI Services:
FA channels The Frame Application (project) may have a list of Communication Channels There are no services to manipulate this association
The FA organizes the Process Channels of DTMs to manage internal I/O for projects, illustrating the linked communication channels The topology of DTMs is represented through this association, where each DTM object acts as a child node of a channel, highlighting the connection between a device and its corresponding channel.
The Frame Application (project) is responsible for handling this association
– linked channels can be explored by GetParentNodes – SetLinkedCommunicationChannel
The ReleaseLinkedCommunicationChannel links Distributed Temperature Monitors (DTMs) within a topology of field devices In this structure, a channel object serves as the parent node for each device, illustrating the connection between the channel and the device.
The Frame Application (project) is responsible for handling this association
– linked DTMs can be explored by GetChildNodes – SetLinkedCommunicationChannel
– ReleaseLinkedCommunicationChannel opened presentations Open Presentation objects are linked by this association to projects
The Frame Application (project) is responsible for handling this association. projects A Frame Application can create and manage multiple projects, which are connected by the “projects” association
The Frame Application (project) is responsible for handling this association
Frame Application (FA)
Frame Applications seamlessly support various devices by integrating relevant Device Type Managers (DTMs) without requiring specialized knowledge of specific devices or fieldbuses They can offer diverse appearances and features based on their intended use, such as standalone configuration or integration within a Distributed Control System (DCS) Typically, these applications include client interfaces that concentrate on specific functions like configuration, monitoring, and I/O planning, leveraging the services provided by the DTMs.
The Frame Application is the runtime environment for the DTMs It provides the services described in 7.7 which may be used by the hosted DTMs
If the Frame Application includes built-in communication capabilities, it can offer Communication Channels that facilitate access to the fieldbus, allowing for comprehensive control over communication and enabling low-level functions like monitoring and filtering Conversely, Frame Applications lacking these capabilities rely on Communication DTMs The relationship between the Frame Application and the Communication Channel object is illustrated in Figure 3.
Fieldbus Interface Fieldbus represents represents
Figure 3 – Frame Application with integrated Communication Channel
The Frame Application's channel objects serve as the bridge between FDT-specific and Frame Application-specific communication On the Frame Application side, the Communication Channel can consist of a PC I/O board or an engineering topology that includes processing units and proprietary bus systems.
Device Type Manager (DTM)
The DTM Business Logic (DTM BL) integrates device-specific functions and protocol definitions, enabling a Frame Application to manage various devices seamlessly This integration allows for the handling of different devices without requiring specialized knowledge of the device or fieldbus.
The DTM BL offers the services outlined in section 7.2, as illustrated in Figure 4 For Frame Applications, all management and task-related interactions with device functionality are accessible through these services.
Figure 4 – Device Type Manager (DTM)
A DTM represents the device structure using the data type net:DtmDeviceInstanceTopology, which can be accessed through the GetActiveTypeInfo service The device structure is detailed by a list of net:Module, with each module containing various properties such as configuration data, Process Channels, and Communication Channels.
A DTM exposes a list of supported device types with the data type fdt:DtmDeviceTypes (see 4.8.1)
DTMs are essential measurement and control devices, including modules, gateways, and communication interfaces They vary primarily in the data, functions, and user interfaces they offer The categories of DTMs correspond to the physical entities they represent, serving as a general guideline for common types of physical devices, although they cannot encompass all existing devices.
A Communication DTM is a unique type of Device Type Manager (DTM) designed to manage application software for specific communication hardware It facilitates the configuration of essential settings, such as baud rate and start and stop bits, ensuring optimal communication performance.
A Communication DTM must offer Communication Channels that facilitate access to the fieldbus, as illustrated in Figure 5 The availability of these channels may vary based on the Communication DTM's configuration, and there may be instances where no channels are provided temporarily, such as during reconfiguration.
Fieldbus Interface Fieldbus represents represents
Communication Channels offered by a DTM have a significant advantage over those provided by a Frame Application, as they can be utilized by multiple Frame Applications This allows each Frame Application to enhance the variety of protocols accessible within the system Furthermore, both types of Communication Channels can coexist within a single Frame Application.
A Device DTM is a specific type of DTM that includes application software designed for typical field devices, such as pressure transmitters or valves This DTM facilitates essential functions for configuring and parameterizing the device.
If it is required to make the device’s I/O signals or process values accessible to the host system, then the Device DTM shall provide Process Channel objects (see 4.2.4.2)
A Gateway DTM is a special category of DTM containing the application software for a device that connects different fieldbus segments (see Figure 7)
A DTM serves as a hybrid of a Communication DTM and a Device DTM, offering Communication Channels for access to the linked fieldbus and Process Channels for the connected fieldbus This functionality is essential for making gateway I/O signals or process values available to the host system.
The relationship between the I/O signals from a gateway device and its communication interface is significant, as the gateway transmits I/O signals received from connected devices This connection is illustrated as a relationship between the Process Channels and the Communication Channel.
A Child DTM connects to the Gateway DTM through its Communication Channel, with the Frame Application managing the link between the DTMs The Device DTM utilizes the services of the Communication Channel to communicate with its device, a process referred to as "Nested Communication," which is elaborated in section 4.7.
Modular devices consist of various hardware modules and sub-modules that can be plugged into physical slots For instance, an I/O module can connect to a Remote I/O device Communication between the composite device and its modules typically occurs via a backplane bus, which is defined by the manufacturer and often relies on proprietary protocol specifications This structure can be illustrated through a hierarchy of Device Type Managers (DTMs).
The Composite Device DTM serves as the foundational element for the entire device representation, offering Communication Channels that depict the backplane bus Depending on its software design, the Composite Device DTM may feature a single channel to represent the entire backplane bus or multiple channels to illustrate the individual slots for module connections.
If a composite device offers process data, the Composite Device DTM must supply Process Channels Additionally, if the composite device relays process data generated by its device modules, the Process Channels from the Composite Device DTM can be derived from those provided by the Module DTMs.
A Module DTM is a special category of DTM containing the application software for a device hardware or software module (see Figure 9)
Devices can be categorized into modules and sub-modules, which include both hardware and software types Hardware modules are designed to fit into physical slots within the device, such as an I/O module that connects to a Remote I/O device This modular design allows for representation by multiple Device Type Managers (DTMs), as illustrated in Figure 9.
Channel object
There are three different types of channels, the Communication Channels, the Process Channels and combinations of them as shown in Figure 12
Communication Channel services Process Channel services
Input and output signals from devices are essential for the planning function of control systems When a device generates I/O signals, the corresponding Device Type Manager (DTM) must provide details about these signals This information is communicated through Process Channels.
A Process Channel facilitates the services outlined in section 7.5, which include access to I/O signal information such as addressing, signal type, and data type, but it does not provide the current value of the I/O signal.
The implementation of Process Channel and its respective services depends on the implementation technology and differs for IEC 62453-41 and IEC 62453-42
The I/O signal information from the Process Channel is specific to the protocol used, as outlined in the IEC 62453-3xy document, which details the integration of protocol profiles in FDT.
The configuration of a device influences the number and type of I/O signals, which in turn affects the number of Process Channels and the information provided Additionally, a Frame Application can communicate with the DTM by setting the appropriate parameters.
The ProtectedByChannelAssignment parameter, utilized through the WriteChannelData service, ensures that no further modifications are allowed once the channel is integrated into the control system's functional planning Consequently, the DTM will reject any changes associated with this channel.
A Communication Channel serves as the access point to a fieldbus and is reliant on specific communication technologies It can represent connections to a vendor-specific backplane bus, a point-to-point link, or logical communication with device blocks This channel may be facilitated by a Frame Application or a Device Type Manager (DTM).
A Communication Channel offers communication services that operate independently of the communication hardware and fieldbus protocol Typically, the services specific to the protocol are directly aligned with the services offered by the channel, and the interfaces provide various methods to facilitate this interaction.
– scan the fieldbus for available devices,
The services take base arguments which are extended for protocol-specific communication by IEC 62453-3xy specifications (see Figure 13)
FDT also allows manufacturers to define support for proprietary bus protocols, which are not part of the standard, for example for a manufacturer-specific fieldbus or point-to-point communication
The services provided by Communication Channels may be used by the Frame Application or by DTMs to exchange data with a connected device or to initiate a function (e.g identification
IEC request, device reset, broad-cast, etc.) The general communication concept is further described in 4.7
A Communication Channel must support multiple simultaneous connections if the communication protocol allows it, enabling various Device Type Managers (DTMs) to connect to different devices or multiple DTMs to connect to the same device Depending on the protocol, a single DTM may also establish several connections to one device The Communication Channel ensures that device links are established as peer-to-peer connections The services provided by the Communication Channel are outlined in section 7.6, with pure communication services defined in section 7.6.1, which establish the framework for interaction with connected devices The parameters for data exchange are specified in the IEC 62453-3xy documents that detail the protocol profile integration in FDT.
Vendor-specific protocols, such as backplane bus or point-to-point, may replace standard communication services with vendor-specific services This means that only DTMs from the same vendor can communicate with one another, necessitating the definition of a vendor-specific bus category For vendor-independent fieldbus protocols, an IEC 62453-3xy document must be provided to describe the protocol profile integration in FDT, ensuring the use of standard communication services.
4.2.4.4 Combined Process and Communication Channel
A combined Process and Communication Channel is integral to a Gateway DTM, representing the I/O signal associated with cyclic communication on the connected fieldbus This channel serves as the entry point to the linked fieldbus or point-to-point connection, as illustrated in Figure 14.
Figure 14 – Combined Process/Communication Channel
The channel must facilitate Process Channel services for the connected fieldbus and provide Communication Channel Services for accessing devices linked to that fieldbus or point-to-point connection.
Modularity
Different fieldbus protocols are using different device models FDT supports the following different approaches to describing the structure of the device:
Bus categories
A DTM reveals details about encapsulated protocol-specific definitions, with the GetTypeInformation service providing bus categories that serve as Universally Unique Identifiers for fieldbus protocols or point-to-point communications The FDT concept differentiates between supported and required bus categories.
• supported bus categories refer to the protocol-specific communication services provided by a DTM (corresponding Communication Channels) to access a fieldbus;
• required bus categories refer to the protocol-specific communication services required by a DTM to exchange data with its device.
Identification
DTM instance identification
An FDT Frame Application shall assign a unique identifier for each DTM instance This unique identifier is referred to as “System Tag” The System Tag is used by DTMs
– for navigation in the FDT topology
– for the management of Child DTMs in the FDT topology (e.g address setting)
The DtmSystemGuiLabel serves as a user-friendly identifier for a DTM instance and its corresponding DTM GUI It is essential for the Frame Application and the DTM to utilize the DtmSystemGuiLabel to accurately identify the dialogs and windows associated with the DTM instance.
For some communication protocols the DtmSystemGuiLabel may reflect an identifier of the device (e.g the device tag)
A DTM supports the HardwareInformation service (see 7.2.3.3) that enables to read device information online from the connected device (see Figure 15)
Figure 15 – Identification of connected devices
The service provides essential device type information, including the manufacturer, type, hardware, and embedded software version, along with instance-specific details such as fieldbus address, tag, and serial number This data is tailored to specific fieldbus protocols, similar to the output from the GetIdentificationInformation service The transformation of this protocol-specific information into a protocol-independent format, usable by the Frame Application without requiring fieldbus-specific knowledge, is outlined in the IEC 62453-3xy document, which details the protocol profile integration in FDT.
System and FDT topology
The Frame Application manages the system topology by organizing the routing necessary for device access within the plan, allowing the DTM to operate without needing to handle any information regarding the system topology.
System topology management is Frame Application specific Some Frame Applications may require user interactions; others may support automatic operations such as topology importing or fieldbus scanning (see 6.2)
A DTM provides essential information, such as the name, vendor, version of supported device types, and their identification properties, allowing the Frame Application and users to select the appropriate DTM for a device.
The Frame Application sets up and connects the Device Type Managers (DTMs) based on the system's topology, a process referred to as FDT topology As illustrated in Figure 16, this topology represents a straightforward system configuration featuring a single fieldbus and two connected devices.
Device 1 : Device DTM ôuseằ ôuseằ
Figure 16 – FDT topology for a simple system topology
A Communication Channel serves as the essential link between Device DTMs, facilitating access to the fieldbus, as illustrated in Figure 16.
The Frame Application establishes the connection between a Communication Channel and a DTM, but the final decision to link a DTM rests with the Communication Channel Prior to creating the link, the Frame Application must invoke the ValidateAddChild service The Communication Channel is required to verify that the DTM's bus categories align with its own supported categories; if they do not match, the linking will be denied Additionally, the Communication Channel may conduct further checks, such as ensuring the number of linked DTMs does not exceed a specified limit Detailed sequence diagrams in section 8.1 illustrate this process.
The Communication Channel and the associated DTM do not require the management of topology information However, the Frame Application facilitates the retrieval of topology information through the GetParentNodes (refer to section 7.7.3.5) and GetChildNodes services (refer to section 7.7.3.6).
The FDT topology management for a more complex system topology with gateways, modular devices and devices with blocks works exactly the same way
Device 2 : Device DTM Device 1 : Device DTM
Slot1 : Communication Channel Slot x : Communication Channel
Block 1 : BTM Block 2 : BTM Block 3 : BTM
Figure 17 – FDT topology for a complex system topology
Starting from the root, all DTMs are linked via Communication Channels according to the physical system topology
The root element DTM for a device, which can consist of multiple DTMs such as Modular Device and Device 1 DTMs, facilitates the automatic generation of the FDT sub-topology that reflects the entire device structure The Frame Application provides essential services, including CreateChild, DeleteChild, and MoveChild, allowing a DTM to modify the FDT topology effectively.
FDT Communication
General
In FDT, communication involves transmitting requests from the communication consumer to the provider, represented by a Communication Channel This process relies on asynchronous services for sending and receiving communication requests.
In order to submit communication requests the consumer of communication first has to establish a connection to a physical device This allows the management of active connections by the Communication Channel.
Handling of communication requests
The Communication Channel processes one or more transaction requests from the consumer, executing them in the order received Once completed, the results of these transactions are returned to the client of the Communication Channel.
The relationship between communication requests and responses can be managed through a specific ID, which is dependent on the implementation For instance, each transaction request is assigned a unique ID that is also included in the corresponding transaction response.
Handling of communication errors
The communication client shall evaluate each of the received transaction results in order to recognise possible communication errors
If a communication client encounters errors for its own requests, it must notify the user In cases of nested communication, Gateway DTMs should not alert the user about errors from requests initiated by a Child DTM, as the responsibility to inform the user lies with the Child DTM.
Handling of loss of connection
In the event of an irreparable loss of connection to a device, the Communication Channel will terminate the connection and issue an Abort notification to the relevant communication client, as outlined in section 7.6.1.5 The exact conditions that prompt the sending of the Abort notification, such as a lack of response from the device, will be specifically determined for each communication protocol.
If a Gateway DTM receives an Abort notification, then it shall send Abort notifications to all connected communication clients
The Abort notification's origin should not directly inform users about connection loss Instead, the communication client must update the user interface to reflect the connection status In cases where the client consists of multiple Device Type Managers (DTMs) with simultaneous open connections, it is essential to consolidate notifications and inform the user of the connection loss with a single message to avoid confusion.
Upon sending an Abort notification, the Communication Channel must cease sending any additional transaction responses to the communication client, which should disregard any transaction responses received after the Abort notification.
Point–to-point communication
The Frame Application has to provide in each case a peer-to-peer connection between a DTM and a device
The Frame Application is responsible for facilitating communication between a DTM and its device To establish this connection, it must invoke the SetLinkedCommunicationChannel service and subsequently enable communication by calling the EnabledCommunication service with a TRUE parameter.
In order to access the device, the DTM uses the Communication Channel services (see 7.6.1) as shown in Figure 18
Device 1 : Device DTM ôuseằ ôuseằ
Figure 18 – Point-to-point communication
To establish a communication link with the device, a DTM must invoke the Communication Channel service Connect (refer to section 7.6.1.2) Once the link is successfully established, the DTM can communicate with the device by calling the Transaction service (see section 7.6.1.6) For a detailed illustration of this sequence, please refer to the diagram in section 8.3.2.
DTMs must take into account the limited availability of fieldbus resources when establishing connections to devices Therefore, a DTM should only create the necessary connections, and any unused connections should be terminated once the online function is completed.
Nested communication
A Device Type Manager (DTM) can access physical devices without needing to understand the system topology, allowing it to communicate with devices across various fieldbus interfaces of the same protocol In cases where devices are linked to a sub-system, such as a channel of a Remote I/O, nested communication is utilized.
Device 1 : Device DTM ôuseằ ôuseằ
Slot1 : Communication Channel Slot x : Communication Channel
Block 1 : BTM Block 2 : BTM Block 3 : BTM
Communication Channel services ôuseằ ôuseằ
The Frame Application is responsible for managing the connection between Communication Channels and their corresponding Device Type Managers (DTMs), ensuring they can communicate effectively with their devices In point-to-point communication, DTMs utilize Communication Channel services to interact with devices without needing to understand the underlying nested communication For a detailed illustration of this process, refer to the diagram in section 8.3.3.
The communication in FDT follows the concept of nested communication:
• each Communication Channel wraps the communication message from the linked DTM below, without knowing the contents;
• the linked DTM below the Communication Channel does not have any knowledge about the system topology;
• the DTM shall support only communication protocols that are supported by the respective device:
– communication/routing through any system topology is possible without limitations.
DTM, DTM Device Type and Hardware Identification Information
DTM and DTM Device Type
A DTM offers two services for retrieving information about itself and the device types it supports, which is typically utilized by the Frame Application for library creation, DTM selection during FDT topology setup, or basic validations.
DTM Device Type 1 DTM Device
XYZ Type 1 2.091 1,22 provides provides describes describes describes
Figure 20 – DTM, DTM Device Type and Device Identification Information
A DTM is a software component that includes application software tailored for specific devices The GetTypeInformation service provides essential details about the software, including its name, version, vendor, FDT version, and a list of supported device types.
A DTM (Device Type Manager) can include one or more DTM Device Types, which represent specific device types within the DTM framework While the FDT (Field Device Tool) specification does not define the detailed design and implementation of these DTM Device Types, the service GetTypeInformation provides essential details about them, including their name, version, vendor, and supported protocols.
When a Frame Application integrates a DTM into the FDT topology, it selects a supported DTM Device Type, as outlined in service Initialize (7.2.4.1) The DTM retains this selection in its instance data for future reference when a similar DTM is initiated Additionally, the DTM provides details about the chosen DTM Device Type through the GetActiveTypeInfo service (7.2.3.4), which consistently returns the current DTM Device Type In the event of a DTM update, the new DTM will supply the updated Device Type information.
Supported hardware identification
The DTM Device Types service, specifically through the GetIdentificationInformation function, provides essential details about various physical device types, including the manufacturer, type, hardware, and embedded software version Additionally, the DTM can utilize wildcards for certain device identification elements, indicating that the DTM Device Type is applicable to all devices matching the wildcard criteria, such as using the asterisk ‘*’ to denote support for all hardware versions.
The GetIdentificationInformation service provides fieldbus-specific data as outlined in the IEC 62453-3xy document, which details protocol profile integration in FDT FDT facilitates the conversion of this information into a protocol-independent format, allowing Frame Applications to utilize it without requiring protocol-specific expertise This transformation is dependent on the implementation technology and is further defined in the IEC 62453-4z documents, which describe the mapping to specific implementation technologies.
Connected Hardware Identification
Furthermore a DTM supports service HardwareInformation (see 7.2.3.3) that enables to read device information online from the connected device (see Figure 21)
DTM Device Type 1 DTM Device
Address: 1 Tag: tag xy Serial No.: 123-456 describes
The service provides detailed information about the device type, including the manufacturer, type, hardware, and embedded software version, as well as instance-specific details like fieldbus address, tag, and serial number This data is tailored to the fieldbus and follows the specifications outlined in the IEC 62453-3xy document, which describes the protocol profile integration in FDT For further clarification, refer to the examples provided in sections 6.2.4 and 6.2.5.
DTM data persistence and synchronization
Basically, three kinds of DTM related data can be seen:
Instance-related data, known as "instance data," is specific to the Device Type Model (DTM) The DTM determines the type of data it will store, but it must ensure that it can accurately represent the stored device instance by loading this data.
• non-instance-related data Non-instance-related data belongs to a project or is global or DTM Device Type specific;
• bulk data DTM specific data, for example historical data, temporary data
A DTM (Device Type Manager) uses a specific format for all types of data, which is identified by a Universal Unique Identifier (UUID) that indicates how its instance data is saved Additionally, the DTM provides a list of compatible data formats it can load, with these format identifiers included in the DTM Device Type information returned by the GetTypeInformation method After a DTM software upgrade, a Frame Application can utilize these format identifiers to locate the appropriate DTM.
Two types of DTM data persistence mechanism are defined in FDT A DTM shall either use the Frame Application project storage or a private DTM storage (see Figure 22)
Figure 22 – FDT storage and synchronization mechanisms
The LoadInstanceData and SaveInstanceData services enable the DTM to manage instance-related data within the Frame Application project storage, ensuring data consistency for multi-user and multi-client access To maintain data integrity, the DTM should utilize the FA services related to DTM data synchronization to lock instance-related data before making alterations Additionally, the Frame Application must employ the DTM services related to data synchronization to inform the DTM of events, such as when data is locked by another DTM instance.
The GetPrivateDtmStorageInformation service provides direct access to private DTM storage, allowing the DTM to store instance-related, non-instance-related, and bulk data without relying on additional services from the Frame Application The DTM is responsible for ensuring data consistency during multi-user and multi-client access, while the Frame Application must establish a backup strategy for the private DTM storages.
A DTM must operate without side effects in the absence of private DTM storage, ensuring that the instance data managed by the SaveInstanceData and LoadInstanceData services remains unaffected.
The private DTM storage mechanism is implementation technology dependent and thus defined in the IEC 62453-4z documents defining mapping to specific technologies.
DTM device parameter access
A DTM supports services to read and write device parameters stored in the DTM instance data (see 7.2.8) and directly in the connected device (see 7.2.10)
The availability of device parameters in a DTM is contingent upon the specific device and fieldbus type Each parameter is assigned semantic information, as indicated by the SemanticId in Table A.4, enabling applications like Frame Application to understand the meaning and usage of individual parameters or data structures The definition of these identifiers is protocol-specific and outlined in the IEC 62453-3xy specifications, which detail the integration of protocol profiles in FDT.
DTM state machine
DTM states
The following diagram (Figure 23) defines the different states of a DTM configured communication allowed
The state machine consists of two states: ‘configured’ and ‘communication allowed’ Which DTM services are available in a certain state is defined in the service descriptions (see Clause 7)
State transitions in the Frame Application are initiated by invoking the appropriate DTM services A transition is successful when the service indicates success with fdt:serviceSucceeded = TRUE Conversely, if the service returns fdt:serviceSucceeded = FALSE, the DTM retains its current state The conditions that permit the DTM to reject state transitions are outlined in the service descriptions.
State Transition: Initial state – state ‘configured’
The service Initialize (see 7.2.4.1) shall be called to bring the DTM from its initial state into the state ‘configured’
State Transition: State ‘configured’ – state ‘communication allowed’
To transition the DTM from the 'configured' state to 'communication allowed', the EnableCommunication service must be invoked with a TRUE parameter This action requires that the Frame Application has previously notified the DTM of the communication infrastructure by utilizing the SetLinkedCommunicationChannel service.
In this state, the DTM can initiate a communication link to its device by utilizing the Connect service of its associated Communication Channel The sub-states within this state are detailed in the communication state machine.
State Transition: State ‘communication allowed’ – state ‘configured’
The service EnableCommunication (see 7.2.4.3) shall be called with FALSE to bring the DTM from the state ‘communication allowed’ into the state ‘configured’
State Transition: State ‘configured’ – final state
The service Terminate (see 7.2.4.6) shall be called to bring the DTM from state ‘configured’ into its final state
Table 3 shows an overview of these transitions
Table 3 – Transitions of DTM states
Start state End state Trigger Condition
RUE) Communication infrastructure available to DTM
Communication allowed Configured EnableCommunication(FA
This state machine describes the sub-states in the DTM state ‘communication allowed’ (see Figure 24) connecting disconnecting connected not connected
Figure 24 – Substates of communication allowed
Table 4 provides a description of the transitions of the DTM ‘communication allowed’ sub- states
Table 4 – Transitions of DTM ‘communication allowed’ sub states
Start state End state Trigger Condition Action
‘not connected‘ ‘connecting‘ Trigger of Online service of the DTM Connect Request
‘connecting‘ ‘not connected‘ Connection could not be established
‘connected‘ ‘not connected‘ Connection is terminated by communication
‘connected‘ ‘disconnecting‘ Online service of
DTM is finished Disconnect service
‘disconnecting‘ ‘connected‘ Connection could not be terminated
Basic operation phases
Roles and access rights
When a DTM is started by the Frame Application, the user role is passed to the DTM, which shall restrict the parameter access according to the role
Also the availability of functions and appearance of user interfaces may be adapted
• an observer will not get access to calibration functions;
• an observer shall not modify parameters
Operation phases
When a Frame Application requests available functions from the DTM, it transitions through the operation phase, enabling the DTM to adjust both the availability of functions and the user interface's appearance.
There are five operation phases:
– planning and configuring of a plant,
– no online access to the plant;
– installing the plant infrastructure and the devices,
– scanning the network to verify a planned network,
– downloading project data into the plant,
– programming, diagnosis of the devices,
– the plant is completely commissioned and running,
– very restricted access to configuration and parameterization data,
– scan to verify the network,
– reading process values and diagnosis information;
– this operation phase is used for service tool Frame Applications Scan to create a topology Scan to verify a network All service related operations Unrestricted access to the device;
– the application does not support the operation phases defined above,
– a DTM shall offer all functions if the Frame Application passes “not supported”
The following table (see Table 5) describes the usage of operation phases in different Frame Application types
System Frame Application Service tool Frame Application Other Frame Applications
During the commissioning phase, the DTM may grant the maintenance actor access to Online Parameterization for the entire parameter set However, in the runtime phase, this access may be restricted or limited to only certain parameters.
FDT version interoperability
Version interoperability overview
FDT is a component based concept, which is constantly enhanced to new improved versions
Control system environments generally operate for a duration of 10 to 15 years When hardware and software components within a control system need replacement, it can lead to a combination of components that are designed for various FDT versions.
This raises the question, how components based on different FDT versions can cooperate
Subclause 4.13 mainly deals with two topics concerning FDT version interoperability: a) Persistence
New versions of FDT components (Frame Applications and DTMs) shall be able to load instance data of older versions b) Component Interoperability
Different versions of FDT components must ensure proper interoperability within a single implementation technology Device Type Managers (DTMs) from newer FDT versions should function seamlessly in older Frame Applications and vice versa Communication is expected to operate effectively, even when there are discrepancies in the FDT versions of Device DTMs and Communication DTMs The specifics of interaction between these components are determined by the technology used, as outlined in the IEC 62453-4z documents.
A limiting condition for future FDT enhancements is to ensure maximum compatibility of different FDT versions This results in a maximum interoperability of FDT components originally designed for different FDT versions
Within IEC 62453-4z documents, version interoperability on two different levels is considered:
The FDT specification targets full compatibility of different versions of the standard Properly designed FDT components will achieve compatibility without extra implementations
Within IEC 62453-4z documents the FDT version is composed by a major, a minor, a release and a build number (e.g 1.2.0.3 where 1 is the major, 2 is the minor number, 0 the release and 3 the build number)
Compatibility is defined slightly differently with respect to the major number:
– compatibility between FDT components with the same FDT major version number is assured by the IEC 62453-4z specification;
Compatibility among FDT components with varying minor, release, and build version numbers can be ensured through additional code paths The FDT specification outlines the necessary information and mechanisms to facilitate full compatibility A minor or release number is incremented when new functionality is introduced, depending on its significance, while the build number is raised to address bug fixes within the specification or type library.
DTM and device versions
When introducing a new Device Type Manager (DTM) for a major version of FDT, it is advisable to utilize updated registration information If there are changes to the registration details of a DTM, the FDT IEC 62453-4z standard offers a method for upgrading to the latest version.
The latest DTM version in the device catalog can offer either the complete list or a selection of devices from the previous DTM version An FDT Frame Application will manage both DTM versions, treating them like any other DTMs that can handle the same field device as separate entities.
A DTM of a higher FDT version which does not use new registration information shall support at least all DTM Device Types that were supported by previous versions of this DTM.
Persistence
If the version of the Frame Application changes or if the version of the DTM changes, then persistence (loading of stored projects) may be a problem
A Frame Application must load and provide unchanged instance data to the DTM, even with version changes The DTM can also load old instance data, provided its registration information remains unchanged If the registration information of a DTM changes, the FDT specification outlines a technology-dependent mechanism for upgrading to the newer DTM as defined in IEC 62453-4z documents.
An existing old instance data of a DTM can be loaded into a new DTM object, which is responsible for converting the instance data appropriately.
A new DTM will indicate its compatibility with existing dataset instances and support all Device Types from the previous DTM When the Frame Application detects the new DTM, it can prompt the user with a message such as, "A new compatible DTM was installed Would you like to use the new version instead of the old one?" If the user agrees, the new DTM will be instantiated, replacing the old version and loading the previous instance data.
Nested communication
DTMs must communicate effectively due to their potential chaining within the FDT topology It is essential to consider the restrictions that arise from the involvement of DTMs supporting different FDT versions.
Information exchanged via communication services may contain version dependent parameters
A DTM must utilize communication service parameters that align with the FDT version of its parent component The version information for the parent component will be included in the service Connect response (refer to section 7.6.1.2) Consequently, a DTM should only employ communication parameters that are compatible with this specified FDT version.
A Communication Channel must maintain compatibility with older FDT minor versions when upgraded to a higher minor version, as some existing child components may not support the interfaces of the newer version.
Within nested communication the version number returned by a Gateway DTM depends on the functionality of its parent component
If the Gateway DTM is at a higher version number than the parent component then the Gateway DTM:
• shall return the same version as the parent and provide the functionality according to this version, or
• shall emulate the higher functionality if possible Then the Gateway DTM shall guarantee that all required functionality is provided by its parent
5 FDT session model and use cases
Session model overview
Clause 5 outlines the use cases taken into account during the development of the FDT Specification While a Frame Application may implement only a portion of these use cases, it is also possible for it to accommodate additional use cases that are not specified in Clause 5.
Figure 25 shows the main use cases
Operator Actor roles with the property UserFlag are only abstract actors They extend inherited actors with specific functions and access right.
The frame application may specify explicit access rights by inheriting any of the non abstract actor roles.
Figure 25 – Main use case diagram
The main use cases are specified in more detail in subclause 5.3, including textual descriptions and optionally some necessary scenarios.
Actors
The actor types in the above displayed use case diagram are structured in a hierarchical way
The "Maintenance" actor derives from the "Operator" actor, while the "Planning Engineer" actor utilizes the use cases of the "Maintenance" actor Additionally, both the "Administrator" and "OEM Service" actors can enhance the inherited actors with extra use cases Use cases inherited by a higher-level actor can be adapted to better align with their intended purpose.
Table 6 provides a brief description of the actors roles:
Brief description: This actor stands for a person that may only observe the current process
User level: FDTUserInformation.userLevel = observer
Access verification: The access as “Observer” actor may not have a password
Brief description: This actor stands for a person who has to observe and manage the current process The
“Operator” may therefore check the current status of the device, modify set values and check if the device is functioning well
The use cases for this actor role should enable the user to perform a complete diagnosis, watch the actual status and parameter set as well as the current process variables
User level: FDTUserInformation.userLevel = operator
Access verification: The access as “Operator” requires a password
Use cases: User Login, Online View, Audit Trail, Archive, Report Generation, Asset Management
Brief description: A “Maintenance” person should have the possibility to perform all necessary maintenance operations including device exchange, teaching, calibration, adjustment, etc
Users can download verified parameter sets, modify selected parameters both online and offline, and conduct device-specific operations Upon completing the processing, they have the option to upload the entire parameter set.
User level: FDTUserInformation.userLevel = maintenance
Access verification: The access as “Maintenance” actor requires a password
Use cases: Simulation, Online Operation, Repair, Offline Operation, Bulk Data Handling
User Login a , Online View a , Audit Trail a , Archive a , Report Generation a , Asset Management a
Brief description: The actor “Planning Engineer” stands for person like a plant engineer, a specialist (e.g according to VDI/VDE 2187) or any fully authorized person
This person has access to the complete set of functions of the Frame Application and can use DTM functions without any restrictions Only OEM-specific operations are locked
User level: FDTUserInformation.userLevel = planningEngineer
Access verification: The access as “Planning Engineer” actor requires a password
Use cases: DTM Instance Handling
Simulation a , Online Operation a , Repair a , Offline Operation a , Bulk Data Handling a , User Login a , Online View a , Audit Trail a , Archive a , Report Generation a , Asset Management a
Actor name: Administrator (abstract actor)
Brief description: The "Administrator" actor stands for a person that has to perform administrative operations within an engineering environment
The person is responsible for adding and removing of software components Inherits: Depends on the Frame Application
User flag b : FDTUserInformation.administrator = TRUE
Access verification: The access as "Administrator" actor requires a password
Use cases: Integration and all inherited use cases
Actor name: OEM Service (abstract actor)
Brief description: The actor "OEM Service" may perform the complete set of DTM specific functions
OEM specific operation may be accessible to an "OEM Service" actor, such as resetting of internal counters and exchanging firmware
The "OEM Service" has only inherited use cases, but the inherited use cases (especially the "Online Operation" use case) may have significant extensions
Inherits: Depends on the Frame Application
User flag b : FDTUserInformation.oemService = TRUE
Access verification: The access verification for an "OEM Service" shall have two security levels:
1 Frame Application password: enables access to the Frame Application functionality
A device-specific password is essential for accessing OEM operations on the device, with the responsibility for its verification resting with the DTM or the device itself.
Use cases: Inherited use cases only a Inherited use cases b “User Flags” may be combined with any “User Level”, to specify the inherited actor role of an “Administrator” or
Use cases
Use case overview
Subclause 5.3 describes all use cases of the use case diagram in tabular form To reduce information, all the attributes of the included use cases, which are identical to the related main use case, are not displayed.
Observation
Only the observation use cases can be executed by the actor “Observer” (see Figure 26) The
“Observer” stands for a person that has the lowest access level No use case is associated with this person.
Operation
The ‘Operation’ use cases are available for the actor “Operator” (see Figure 27)
Online View ôincludeằ ôincludeằ ôincludeằ
Table 7 provides a description of Operation use cases
Brief description: A person of specified actor type logs into the Frame Application If verification fails, the person may act as an “Observer” actor only
GUI: Part of the Frame Application
UserLevel Observer: Depends on the Frame Application
OEM Service: Accessible with extended functionality (see below)
Included use case: DTM-Specific Login
Brief description: Access to manufacturer specific information, e.g production codes, changes log
GUI: Part of the DTM
Device connection: Typically needs an established connection
UserFlag OEM Service: Accessible only for OEM Service
This use case provides a comprehensive set of operations for monitoring device parameters and status The Graphical User Interface (GUI) is integrated within the Device Management Tool (DTM), allowing users to access online views for multiple devices simultaneously Additionally, the online view feature includes a print function to facilitate documentation creation.
Device connection: Needs an established connection to one or more devices
(Adjust SetValue may influence device data) UserLevel Observer: No access
Included use case: Parameter Set Online View
Brief description: Enables the actor to load parameters from the device for viewing and documenting
Included use case: Adjust SetValue
Brief description: Enables the actor to adjust the SetValues of a device (e.g positioner, controllers)
Included use case: Online Status
Brief description: Use case for viewing and analyzing the current device status
Included use case: Online Trend
Brief description: Use case for generating and watching trends of dynamic online values
Included use case: Plausibility Check
Whenever device parameters or configuration data are modified, an automatic plausibility check is conducted The data cannot be written to the device until this plausibility check is successfully passed.
Brief description: Displays identification of device instance information, e.g address, TAG, Fieldbus-
The Rev., DD-Rev., and Firmware details are dependent on the protocol and may include device type-specific information Additional insights can be found in the documentation, along with a section for comments related to the device instance For more information, please refer to the Device Identification chapter in the protocol-specific FDT-JIG-Annex specifications (DTM applicationId: fdtIdentify).
Brief description: Use case to enable the actor viewing and deleting audit trail data
GUI: The component, which supports audit trail, has to provide an adequate GUI
Print: Printing for documentation purpose as a need for audit trails and therefore has to be supported Device connection: No connection necessary
Operator: Accessible for viewing only
Planning Eng.: View, export and delete
Included use case: DTM-Specific Audit Trail
Brief description: Every DTM might support an audit trail on its own
Included use case: FA-Specific Audit Trail
Brief description: The Frame Application may implement a system global audit trail using internal data and named DTM properties exported from the DTM via the audit trail services
The "Archive" use case focuses on accessing a Frame Application archive for effective viewing and data analysis It is essential for the component that facilitates archive functions to offer a user-friendly graphical user interface (GUI) Additionally, every archive component must include printing capabilities to enhance usability.
Operator: Accessible for viewing only
Planning Eng.: View, export and delete
Included use case: Historical Trend
Brief description: The archive operations may support visualization of historical data (for example trending)
Included use case: Historical Data Analysis
Brief description: Some Frame Applications and DTMs may support extended operations to analyze historical data
Brief description: The print function of a use case can normally be started from its GUI
Frame Applications can include a configurable documentation feature that allows users to generate reports These reports can be created by aggregating the outputs from multiple use cases or devices, providing a comprehensive view of the GUI.
For example a report could be generated containing "Online View", "Audit Trail" and
"Online Operation" printouts for one device or a report may be generated containing the configuration of a communication infrastructure element and its clients
Print: Frame Application in combination with one or more DTMs
Device Connection: Depends on the type of report
UserLevel, UserFlag: The printed information may depend on user level and user flags
Brief Description: Frame Application provides mechanism for asset management
GUI: The component, which supports asset management functions, has to provide an adequate GUI
(DTM applicationId: fdtAssetManagement) Print: Frame Application supporting this use case should support printing, too
Operator: Accessible for viewing only
Planning Eng.: View, export and delete
Maintenance
The maintenance use cases are available for the actor “Maintenance Engineer” (see Figure 28)
Upload Download ôincludeằ ôincludeằ ôincludeằ ôincludeằ
DTM Instance Upgrade and Replacement
Device-/Persistent Data Comparison ôincludeằ
Repair Simulation ôincludeằ ôincludeằ ôincludeằ
The Maintenance use cases are described in Table 8
Brief description: This use case simulates the behavior of a device
Therefore the actor is allowed to perform temporary changes within the device parameters, like forcing the device to set a fixed current analog output
Device connection: Shall have a connection established
Brief description: This use case includes all operations which do not require an established connection to a device
Only for up- and download a connection to a device may be temporarily established
GUI: DTM and Frame Application
Device connection: Depends on the included use case
Included use case: Plausibility Check
Whenever parameter values are modified, an automatic plausibility check is conducted Data cannot be saved to the database or written to the device until this check is successfully passed Depending on the rules or application environment, there may be two possible options available.
Inconsistent data may be stored following a warning display, and for safety reasons, data writing is prohibited after such a warning Additionally, users should note that the plausibility check may be more lenient for higher-level actors.
Included use case: Offline Parameterization
Brief description: The user may change parameter values The changes will only affect data in the
Frame Application database after stored as persistent data Data should be signed as transient data until they are stored GUI: DTM (applicationId: fdtOfflineParameterize)
Device connection: No connection necessary
Included use case: Persistent Data Comparison
Brief description: Allows the user to compare the offline parameter set with parameter sets of other instances, of device default or of project default parameter sets
The data sets may be editable and data may be transferred from one data set to the other
Print: May be supported by the DTM
Brief description: This use case stands for operations which shall be performed to repair or change a device
Example: A Frame Application supports a temporary removal of a device with automatically downloading parameterization when the device has been reinstalled UserLevel Observer: No access
OEM service: Accessible with extended functionality (see below)
Use case: DTM Instance Upgrade And Replacement
This use case involves the operations necessary to upgrade or replace a DTM when the new DTM differs from the previous version.
The data format of the new DTM can be either compatible (upgrade) or incompatible (replacement) to the data format of the previous DTM UserLevel Observer: No access
Brief description: This use case stands for operations which shall be performed to replace a DTM in the case of incompatible data set format
Brief description: This use case stands for operations which shall be performed to upgrade a DTM in the case of compatible data set format
Brief description: This use case includes all operations which are performed directly with the device
Device connection: Connected or disconnected
Planning Eng.: Fully accessible excluding OEM-specific parameter
OEM service: Accessible with extended functionality (see below)
Included use case: Online Functions
The "online functions" use case encompasses all procedures that facilitate direct communication with the device This includes both straightforward tasks, such as resetting, and more intricate processes that may involve multiple sections, like calibration or teaching in.
Included use case: Online Parameterization
This use case begins by reading all parameters from the device and displaying them in a user-friendly GUI Users can modify these parameters based on their access level, and any changes made are immediately applied to the device, provided the new settings are verified.
Included use case: Device-/Persistent Data Comparison
Brief description: This use case gives the user the possibility to compare persistent and device data
The user may edit data and copy between these two sources
Brief description: This use case invokes calibration procedures to adjust the input for e.g pressure transmitters or the current for the output
Included use case: Plausibility Check
Whenever device parameters or configuration data are modified, an automatic plausibility check is conducted The data cannot be written to the device until this plausibility check is successfully passed.
UserLevel, UserFlag: The plausibility check may be more tolerant for actors of higher level
Brief Description: Reads the whole parameter set from the device into the Frame Application database
An upload started by an "OEM Service" actor may upload additional OEM parameters
GUI: If the Frame Application supports up- and download for a group of devices, the
Frame Application may offer a GUI for a better control of the upload process
Device connection: Needs a temporary connection
Brief description: Same as for upload, but in the opposite direction
GUI: If the Frame Application supports up- and download for a group of devices, the
Frame Application may offer a GUI for a better control of the download process
Device connection: Needs a temporary connection
The article discusses how to retrieve a list of available devices from a channel object, which can be supplied by either a DTM or a Frame Application Additionally, it highlights that the Frame Application may provide a graphical user interface (GUI) for displaying the list of devices.
Device connection: Needs a temporary connection (The channel shall have online access)
Use case: Bulk Data Handling
This use case enables the simultaneous management of multiple instruments, allowing for actions such as uploading and downloading, adjusting parameters, and generating reports It effectively addresses bulk data processing at the system level.
Brief description: Reads the whole parameterization from the devices of the group into the Frame
Brief description: Same as for upload, but in the opposite direction
Planning
The planning use cases are available for the actor “Planning Engineer” (see Figure 29)
Export ôincludeằ ôincludeằ ôincludeằ ôincludeằ
System Planning ôincludeằ ôincludeằ ôincludeằ
List of Supported Devices ôincludeằ ôincludeằ ôincludeằ DTM Matching ôincludeằ
Table 9 provides a description of the planning use cases
Use case: DTM Instance Handling
Brief description: With this use case a "Planning Engineer" actor can handle (e.g instantiate, import, export, delete) a device instance in the Frame Application
GUI: Frame Application and DTM
Included use case: Create Instance
Brief description: In this use case a new device instance can be created and placed into the project
After creation of a new device instance, the device parameter set shall be instantiated This action is performed by the DTM
GUI: Frame Application and DTM (if it supports device default selection)
The parameter set can be established by importing data from a template database or by duplicating the parameter set from a previously instantiated and verified device.
Brief description: To copy data from one device instance to another, the device instance data can be exported
Included use case: Delete Instance
Brief description: Deletion of a device instance
Brief description: This use case enables the “Planning Engineer” actor to configure a complex device GUI: DTM (DTM applicationId: fdtConfiguration)
Device connection: Shall not have a connection established
Brief description: Use case to perform all necessary actions for the creation of topology based on the result of scan
GUI: Frame Application and DTM
Print: Frame Application and DTM
This article discusses how to retrieve a list of available devices using a service scan from a channel object, which can be supplied by either a DTM or a Frame Application Additionally, the Frame Application may provide a graphical user interface (GUI) to display the list of devices effectively.
Device connection: Needs a temporary connection (The channel shall have online access)
Included use case: Network Management
Brief description: Use case for network management purposes, e.g address setting as a function of a Communication-DTM
Included use case: DTM Matching
Brief description: Use case for finding a DTM that matches best the information retrieved in the Scan use case
Included use case: Create Instance
Brief description: In this use case a new device instance can be created and placed into the project
After creation of a new device instance, the device parameter set shall be instantiated This action is performed by the DTM
GUI: Frame Application and DTM (if it supports device default selection)
Brief description: Use case to perform all necessary actions for the editing of topology information
GUI: Frame Application and DTM
Print: Frame Application and DTM
Included use case: Network Management
Brief description: Use case for network management purposes, e.g address setting as a function of a communication-DTM
Included use case: Bus Master Configuration
Brief description: Use case for configuration of bus master DTMs
Included use case: Channel Assignment
Brief description: Use case for editing the FDT channel assignments
Use case: List of Supported Devices
Brief description: In this use case a list of all supported devices within a project can be viewed and edited
A “Planning Engineer” actor can select a device from this list to create a new device instance
An actor with the “Administrator” actor flag set has access to change this list
Planning Eng.: Accessible for viewing only
UserFlag Administrator: Accessible for editing
OEM service
The “OEM Service” uses cases may provide the “OEM Service” actor (see Figure 30) extended access to use cases of other actor roles.
Administration
The administration use cases are available to users that have additional Administrator permissions (see Figure 31)
List of Supported Devices ôincludeằ ôincludeằ ôincludeằ
Table 10 provides a description for the Administrator use cases
This use case allows the actor to install, uninstall, or update new Device Type Managers (DTMs), with installation and uninstallation processes not governed by the Frame Application Additionally, the Frame Application may facilitate the management of DTMs.
Device connection: Shall not have a connection established
Brief description: Installation of a new DTM
GUI: Responsibility of the DTM
Brief description: Deinstallation of a DTM
GUI: Responsibility of the DTM
Included use case: Update DTM
Brief description: Update/modification of a DTM installation
GUI: Responsibility of the DTM