| |||
Interfaces and Methods - Schemas - FDT Specification - Quicklinks - Abbreviations | |||
| Up to FDT Specification 2.1 FDT Overview 2.2 Where FDT Fits 2.3 General FDT Architecture and Components 2.4 Overview of Objects and Interfaces 2.4.1 The Device Type Manager (DTM) 2.4.2 The Block Type Manager (BTM) 2.4.3 The FDT Frame Application 2.5 Synchronization and Serialization Issues 2.6 Parameter interchange via XML 2.6.1 Examples of usage 2.7 Persistent Storage Story 2.7.1 Persistence Overview 2.7.2 Persistence Interfaces 2.8 Basic features of a session model 2.9 Basic Operation phases 2.9.1 Roles and Access Rights 2.9.2 Operation Phases 2.10 Abstract FDT Object Model 2.11 Fieldbus independent Integration 2.12 Scanning and DTM Assignment | 2.4.3 The FDT Frame ApplicationThe FDT Frame Application provides the complete functionality to manage data, to communicate with the device and to embed DTMs. So it depends on the environment and the tasks whether a Frame Application is an engineering tool, a standalone tool or a web page. A DTM must be independent of the environment it is running in. So all environment-specific tasks must be handled by the Frame Application. In most cases, engineering tools are based on Database Management Systems (RDBMS, OODBMS). Due to this, no DTM should implement transaction strategies. It depends on the data management of each Frame Application whether transactions are used or not. All aspects of data management are encapsulated within the Frame Application. It is not a matter of any DTM. The standard storage interfaces encapsulate the storage mechanism of the Frame Application. This can be a simple file system or in case of engineering tool the database provided by the DCS system manufacturer. The data a DTM stores via this interfaces are DTM-specific and are not available for other applications. It is up to the DTM which data it stores but each DTM has to guarantee that it can represent each stored device instance by loading these data
From a DTM point of view, all task-related interfaces for the interaction with Frame Application are available via the main interface IFdtContainer of the Frame Application. Which task-related interfaces are provided depends on the capability of the Frame Application. Each interface will be described in detail at its own chapter. In a complex plant environment, there are also complex communication networks for linking the process devices. No DTM should need any information about the topology of a system network. So it is up to the Frame Application to organize the routing for accessing a device. The Frame Application has to provide in each case a peer-to-peer connection (physical or logical). So its up to the Frame Application to manage the multi user access to a device. To represent its communication capabilities a Frame Application can implement FDT-Channel objects. The Frame Application’s channels represent the gateway from the FDT-specific to the Frame Application-specific communication. At least the interface IFdtCommunication must be implemented for a channel of a Frame Application. On the Frame Application’s side the communication channel can be a PC I/O board or engineering topology with processing units and proprietary bus systems. IFdtCommunication always provides the communication functionality for DTMs to access their fieldbus devices. All actions that belong to the physical fieldbus have to be done by using this interface. Each DTM can communicate with each FDT- communication channel provided that the FDT-Channel supports the appropriate communication protocol. The association of a DTM with a specific FDT-Channel is done by configuration. The topology information for configuration is stored in the Frame Application’s database via the IFdtTopology interface. A FDT- communication channel must be able to handle several connections to the same device and can be responsible for connections to different devices. The component guarantees that a link to a device is established as a peer-to-peer connection. The unique peer-to-peer connection is necessary for the asynchronous communication especially the management of the invoke IDs. Only for the peer-to-peer connection, the DTM has to guarantee that the used invoke IDs are unique for all of its communication processes (e.g. configuration and observation in parallel). In general one and the same DTM can communicate with devices of the same type attached to different fieldbus interfaces using the appropriate FDT- communication channels.
The general functionality of the FDT-Channels is encapsulated within a channel object and allows communicating with master and slave devices or following software components. An engineering tool for example may configure its fieldbus master by its own manufacturer specific means. | ||
© by M&M Software GmbH, parts of this website taken from FDT Interface Specification Version 1.2.1, © by FDT Group, AISBL. This website is published for support of M&M products as granted in license conditions, chapter 2.1. Last updated 2015-02-05 15:17 Email: FDT Technical Support Line. | |||