The sustained success of the FDT technology in the process automation, and increasingly also in the factory automation, cannot be disputed by even the most adamant critics of this technology. However, some of the frequently mentioned, most critical problems cannot be ignored completely. They are the problematic distribution and installation of DTMs on many computers and the limitation on the Windows-platform for certain applications. These problems have been acknowledged and they can be solved at reasonable costs with today s technology, as the concept of the Remote FDT Server by shows. The FDT/DTM-standard eases the engineering and the parameterization of intelligent field devices. More than that, DTMs provide a wide range of diagnostic functions in the form of device-specific- and graphic user interfaces, which effectively support the jobs of the plant operator and the service technician. More efficient fault diagnosis from DTMs If the control system reports that a certain field device is faulty, the plant operator is able to analyze in detail the condition of this particular field device online and in dialogue with the respective DTMs. In the ideal case, the plant operator should be able to request for the matching graphic user interface of the DTM, which is responsible for the faulty device. This graphic user interface pops up on command on the control station s computer screen and enables a fast and targeted reaction to critical plant malfunctions. DTM Deployment, a dilemma? FDT, as it is today, reaches its limits when it is implemented in large-scale plants with many control stations in many different areas of the plant. Apart from the FDT-frame application, all DTMs used in the project must also be installed in all computers, which are supposed to show the user interfaces of these DTMs. This distribution of components to many computer systems, and especially their updating with the installation of software-updates, is time-consuming and error-prone. If, in the worst case, the user interface of the process control system does not run under a Windows Operating System, but under Linux, for example, the local installation on the control system of the SCADA-System would not be possible in the first place. Remote Desktop as solution The M&M Software has turned a dilemma into an opportunity and has, in cooperation with customers, developed an innovative solution with the Remote FDT Server. This Remote FDT Server integrates the graphic user interface of a DTM in the HMI of a SCADA-System without the need to install the device-specific DTM locally on the SCADA-System. Instead of the installation in all control stations, the necessary DTMs are all installed in one central PC-System, the Remote FDT Server. This server transmits the graphic user interfaces of the DTMs to the GUI of all control stations on request, using remote technologies. Page 1 of 10
Figure 1 - Caption: The Remote FDT Server integrates into an existing communication structure. Procedure in principle One control station requests to view a particular DTM in operation. A software component, which is integrated in the GUI of the control station, sends a message to the Remote FDT Server. This message contains an identification of the field device, that is requested to be viewed, the current username and other, optional parameters in connection with the request. Upon receiving the message, the Remote FDT Server starts a new user-session and shows the requested DTM in the assigned Operation Frame Instance (optionally already in the online mode). This operation frame has been optimized specially for this application and is in fact a simplified version of the FDT frame application, which is installed and executed on the Remote FDT Server. The operation frame exclusively provides the necessary and allowed FDTfunctions for the plant operation. Every user session has a unique instance of this application. Once the operation frame is successfully initialized, the content of its main window is displayed via Remote Desktop in a window on the control station. All entries, which the user makes in the control station window, are transmitted to the Operation Frame Interface on the Remote FDT Server. The user doesn t even realize that he operates an application on a different system. Page 2 of 10
The access authorization determines whether the control station user can only read, or also change the device parameters. Under no circumstances should a user be allowed to change the device topology of the FDT project. Preliminary segmentation of the plant It should be possible for several control stations to simultaneously access the Remote FDT Server, without creating conflicts when the same device is accessed by multiple control stations at the same time. The plant planner therefore divides the entire supervised plant into several independent sub-segments. The central Server-PC must be able to reach each one of these sub-segments via Ethernet. A separate FDT project is created for each sub-segment and contains the Bus-topology with all devices of the sub-segment. The FDT projects are typically created and managed by a fully functional FDT frame application, such as the fdtcontainer application. The FDT projects must be archived in a central place in the net, to which the Remote FDT Server has access. If changes need to be made on the structure of the FDT projects while the plant is in operation, the Remote Clients can temporarily and centrally block the accesses. Solution option VNC The Remote FDT Server is now available in two versions with different technical approaches. The VNC-Version uses the VNC-Technology (Virtual Network Computing) as basic technology for the Remote Desktops. VNC is based on an open standard for the desktop virtualization, which supports both physical computers and virtual machines (VM). This version implements each User session with its own virtual machine, which uses the Remote FDT Server as host. Vmware vsphere 4 or optionally the free Vmware ESXi are used as virtualization infrastructure. The built-in VNC Server, the Vmware Host, provides the desktop of each hosted VM via VNC in the form of an adjustable TCP/IP port. All VM on the Remote FDT Server are derived from the so-called cloning of a single basic VM. Necessary updates of DTMs are executed only on this basic VM and are then replicated through cloning to all VMs. Page 3 of 10
Clone Clone Clone Figure 2 :The DTM is installed only once and the VM is then cloned. A service named Operation Station Master, which is installed on the Remote FDT Server, manages and coordinates the access to existing VMs and prevents at the same time the parallel access to the same FDT sub-project by several control stations. The control stations communicate with this Operation Station Master via Web Services. Upon receiving a request message from a control station, the Operation Station Master reserves an available VM and makes sure that this VM downloads the requested DTM from the requested sub-project and shows it in the operation frame. The VNC-Port number is messaged to the control station. A VNC Client component on the control station then links up via this port with the VM-Interface and shows the contents in the Operation Frame. Additional watchdog-functions prevent that assigned VMs are permanently blocked, because VNC clients did not logout properly. Page 4 of 10
Figure 3: The solution version VNC on Vmware ESXi. Solution option RDP The RDP version is based on Microsoft s Remote Desktop Services under Windows Server 2008 R2, formerly known as Terminal Server. Here, the user sessions are directly displayed as Remote Desktop sessions in the Terminal Server. The Remote Desktops are transmitted to the control stations with RDP protocol. The cloning of virtual machines is not necessary. However, an additional Central Service coordinates the active Operation Frame Instances that are running in different Remote Desktop sessions, here as well. The control station must be equipped with an RDP Viewer, instead of a VNC Viewer. Page 5 of 10
Figure 4: The solution version RDP based on the Remote Desktop Services under Windows Server 2008 R2. VNC or RDP? The main advantage of the VNC version is that the DTMs can still be executed in a real 32 -Bit environment. Therefore, compatibility problems of the DTMs with the implemented operating system are very unlikely. The RDP version, on the other hand, runs on Windows Server 2008 R2; and this is a true 64-bit operating system. Some of the older DTMs can cause problems here. But then again, the licensing requirements are more clear-cut and transparent with the RDP version. Besides the necessary server-license, an RDS Client Access License is required for each control station. For the VNC version, on the other hand, additional Windows workstation licenses (either XP, Vista or Windows 7) are required per running VM. Since the introduction of Windows 7 with changed mechanisms for the Windows-activation, a few obstacles of a technical nature and in regard to licensing have emerged. Another advantage of RDP is the already built-in encoding of the messages. For VNC, this function must be created retrospectively. From the user point of view, however, both versions are functionally identical. Therefore, the choice between VNC or RDP depends largely on the preferences in regard to the virtualization technology of the respective IT personnel. The maximum number of parallel user sessions can be parameterized in both versions, but recommended as ceiling is the number of existing FDT sub-projects. In principle, the existing hardware (especially Main Memories) should be able to support the anticipated number of Page 6 of 10
parallel user sessions. The rule of thumb is ½ GB main memory per active user session. In case of resource-consuming DTMs, the required capacity can also go up to one GB and more. Integration in control systems Client components for a variety of operating systems are available both for VNC and RDP, often even as Open Source or Freeware. With these, the Remote FDT Server can seamlessly, visually integrate the user interfaces of DTMs into virtually every existing SCADA-HMI at reasonable costs. With the Operation Station Client, the Remote FDT Server offers a ready-to-use display component as standard solution for the client side. This system is easily integrated with a simple initialization process with transfer of additional command line parameters. In addition, the Remote FDT Server has a built-in Web-Server, which enables the access to DTMs via web browser. Each DTM has a unique URL for the direct call up. PC-based solutions are not the only client. Thanks to the implemented standard technologies VNC or RDP, mobile devices with an appropriate display size can also access the Remote FDT Server. Apple s ipad is a striking, but not (yet?) practical example. Figure 5: DTMs are no longer limited to Windows. As an example, the Apple ipad. Page 7 of 10
FDT 2.0 and FDI? The Remote FDT Server presently supports DTMs according to FDT 1.2 and 1.2.1. After the imminent passing of the new FDT 2.0 Standard and the subsequent adjustment of the operation frame, the support will soon be provided also for this FDT-standard. The direct support of FDI ultimately depends on the compatibility of FDI and FDT. No conclusive statements on this issue can be made as yet. But regardless of the outcome, a Remote Desktop-based concept can surely be developed for a future FDI server as well. Conclusion The described solution is certainly not the first concept that uses the Terminal Server or similar technologies to make FDT/DTM available as server-solution. But the Remote FDT Server is unique in terms of the special attention it pays to the details and requirements of the plant operation and because it is so easy to integrate in existing SCADA-Systems without built-in FDT support. The main benefits for the user are listed below in note form: The central and singular installation of DTMs saves time and costs. DTMs that are integrated in the SCADA-System allow the plant operator a more efficient troubleshooting and diagnosis The built-in Web-Server enables the mobile access for repair- and maintenance work also via the Internet (optional). Remote FDT Server makes FDT available for the first time as fully integrated solution also for plants that run under Linux and other operating systems. Technical Terms: (taken in part from Wikipedia) FDT DTM FDT (Field Device Tool) is a non-proprietary concept, which enables the parameterization of field devices from different manufacturers with only one programme A Device Type Manager (DTM) is a type of driver-component for a certain field device or a field device family. Is usually provided by the device manufacturer. The DTM incorporates all functions, the structure, the parameterization and the GUI, including an auxiliary system for a certain field device or, possibly, a device family. It is installed on the PC as Program, but can only be started from a Container, also called Frame Application. Page 8 of 10
VNC RDP FDT 2.0 FDI Virtual Network Computing, short VNC, is a software which can display the screen content of a remote computer (Server) on a local computer (client) and which in turn sends keyboard- and mouse-movements on the local computer to the remote computer. A person works on a remote computer without physically sitting in front of this computer. The Remote Desktop Protocol (RDP) is a network-protocol by Microsoft for the visualization and controlling of desktops on remote computers. It controls how the Terminal Services, or new Remote Desktop Services, are addressed and used under Microsoft Windows. Latest version of the FDT Standard. Is based on.net and WPF. Currently only available in the status Draft in Preparation. Future Device Integration (FDI). New approach for the device integration based on Engineering Device Descriptions (EDD). Currently only available as First Draft. Author: Klaus Hübschle Technical Director Page 9 of 10
Company Profile M&M M&M Software stands for innovation, competency and quality. In the almost 25 years in business, M&M has gained the reputation of being a reliable partner for many renowned customers worldwide. Our vast industry know-how is reflected in a wide range of innovative and unique software solutions that we have developed for and together with our customers in the factory- and process automation, maritime technology, mechanical engineering, building automation and energy technology. M&M is the competent service provider for all matters concerning software products in the industrial automation. Our range of services Lifecycle Management for Software Products comprises the services management & technology consulting, software development, QA services, IT operations & services and software maintenance & support. We focus on intelligent solutions for handling and monitoring (HMI), device integration, engineering systems and web applications. The company s headquarter is in St. Georgen in s Black Forest region. With our existing subsidiary in Suzhou near Shanghai/China which was established in 2005, we do not only serve the upcoming markets in Asia, but also offer offshore development services to our customers in Europe and America in proven M&M quality to significant price advantages. Your contact person for this press release: Petra Schulz Tel.: +49 7724 9415-50(?) Fax.: +49 7724 9415-23 press@mm-software.com Page 10 of 10