4th IEEE International Workshop on Factory Communication Systems, Vasteras, Sweden, August 28-30,2002 “©2002 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.”
Development of Distributed Industrial Control Applications: The CORFU Framework K. Thramboulidis Electrical & Computer Engineering University of Patras 26500, Patras, GREECE
[email protected] manufacturing plants are forced to improve their ability to design competitive products and modify existing ones by adopting processes that yield in greater success in terms of quality, time and budget, which conform the project success triangle. To address the above trends, evolving standards, like IEC61499 [1] and IEC1804 [2], define the basic concepts and a methodology for the design of modular, re-usable, distributed industrial process measurement and control systems. They define, the function block construct as the main building block of IPMCS applications, in a way that it can be used to define robust, re-usable software components that constitute the distributed IPMCSs, in a format that is independent of implementation issues. They also define, a methodology to be used by system designers to construct distributed control systems. According to this methodology IPMCS applications are defined in terms of logically connected function blocks [3]. Complete control applications, can be built from network of function blocks, formed by interconnecting their inputs and outputs. Function blocks in the form of composite function blocks or subapplications are assigned into physical processing resources such as field devices, to form the control system [4]. Even though, the distribution of the IPMCS application is a simple task, as far as field devices are interconnected with the same field bus, things are going to become more complicated, when the application’s function blocks must be distributed among devices assigned to different field buses of the same or different type. Industry's solution to the problem of interconnecting different field buses is not very clear [5]. Softing's Profigate is an Ethernet-Profibus Gateway. It consists of a PROFIBUS connector, a CPU board and an Ethernet TCP/IP software interface. Siemens' SIMATIC OPC SERVER is another example. Two major reasons, though, put these solutions in question: first, the realtime transmission between two field buses cannot be guaranteed, due to the Ethernet backbone, and second,
Abstract Today’s control applications are either based on traditional distributed control systems or on programmable logic controllers. They are usually composed of monolithic applications that are almost impossible to integrate and even to expand. Even more, the many different types of commercial fieldbuses resulted in a wide diversity of devices and tools to support the development of Industrial Process Measurement and Control Systems (IPMCSs). The demand for integration, both during the development phase as well as during the operational phase is becoming more than evident. In this paper, we present CORFU, an OO framework to improve the engineering process of IPMCSs in terms of reliability, development time and degree of automation. The defined framework embodies an abstract design that is capable to provide solutions for the family of distributed IPMCSs.
1. Introduction Most of the existing Industrial Process Measurement and Control Systems (IPMCSs)1 have been based until now either on traditional distributed control systems or on programmable logic controllers. In both cases, the systems are composed of monolithic applications that are almost impossible to integrate and even to expand. Modularity, flexibility, extensibility, reusability and interoperability are dimensions slightingly addressed by many traditional proprietary engineering tools and products. Even more, most of the traditional products and tools are far away from the new challenging technologies of Software Engineering. The IPMCS software industry increasingly faces today, the challenge of creating complex custom-made distributed control systems within time and budget, while high competition forces prices down. To respond to market demands for innovative products, 1 For a list of abbreviations look at the end of the paper.
1
4th IEEE International Workshop on Factory Communication Systems, Vasteras, Sweden, August 28-30,2002 these gateways offer only PROFIBUS connections. Another commercial product that promises connectivity between independent field bus segments is the SST-XLink from SST Network gateways. Although this product seems promising, a great effort for configuration from user's part is required. It doesn't also offer the capability for remote configuring, diagnostics, monitoring, etc. A very promising approach is the one carried out by the IDA group [6]. This group wants to establish a vendor independent and open standard adopting as its communication platform the TCP/IP protocol with realtime capable communication. Its aim is to provide specifications and source code samples for equipment manufacturers. IDA’s Application Model depicts the structure and the basic elements of the control application and is based on the reference architecture defined in IEC 61499. However, it restrains the IEC model in some aspects and extends or modifies it in some other. For example it restrains the model by always combining each event with the associated data connections to the so-called IDA Connection and extends it by the provision of mechanisms to configure the topological structure of the networked devices [7]. In the context of this paper, we consider the development of distributed function block based IPMCS applications over heterogeneous field bus segments and we present a framework-based approach. Frameworks provide an important enabling technology for reusing both the architecture and the functionality of software components allowing the IPMCS engineer, to ignore all the complexities inherent in field devices and fieldbuses, and to concentrate on the actual problem to be solved [8]. The proposed, Common Object-oriented Real-time Framework for the Unified development of distributed IPMCS applications (CORFU), assists process and system engineers in the development and configuration of distributed IPMCSs. We adopted the Object-Oriented approach to exploit the many benefits of OT as they were encountered in our many projects where we applied it. The whole engineering process proposed by the IEC 61499 is adopted and improved in terms of reliability, development time and degree of automation. The rest of this paper is organized as follows. In section 2, we present the layout of the proposed CORFU framework, which address both the IPMCS engineering process, as well as the IPMCS operational phase. Section 3, describes our approach for the Virtual FieldBus (VFB), which is an IEC 61499 compliant fieldbus. The wrapping of a commercially available fieldbus is considered as a case study. In section 4, we briefly describe the functions to be performed by the IPCP Protocol, as well as its interface to processes that require its services. In section 5, we refer to our prototype implementation and finally, at the last section, we conclude the paper.
2. CORFU: A framework for the interconnection of heterogeneous fieldbus segments. As far as, the field devices are interconnected with the same fieldbus, the distribution of the IPMCS application modules is a simple task. Data and event connections are implemented through the specific’s fieldbus communication mechanisms and real time constraints are satisfied by the fieldbus nature. However, things are going to become more complicated, when the application’s functionality must be distributed among devices assigned to different fieldbuses of the same or different type. This is a common situation in industry, where a lot of proprietary fieldbuses have been installed in different time periods under different circumstances. If, for example, an enterprise wants to transfer data or events between two buildings, with each one having its own fieldbus, it has to interconnect the two heterogeneous fieldbuses. There is also a requirement, from the corporate level, to have, through the enterprise’s intranet, integrated monitor and control of industrial processes, which are assigned to different fieldbus segments. The obvious solution to the above problem is to use interworking units to interconnect each fieldbus segment with the enterprise intranet. Although this solution, address the requirements for the integrated monitoring in corporate level, it does not satisfy the requirement for real-time interconnection between fieldbus segments. To satisfy this requirement, we were guided to adopt the use of a backbone network for the real time interconnection of fieldbus segments, as is shown on figure 1. The selected communication subsystem must provide the quality of service required to meet the timing requirements. ATM is one of the successfully used technologies for the interconnection of fieldbuses [9][10]. However, to satisfy the key requirement of the simplicity of the communication system as well as the low cost of the equipment, Fast switched-Ethernet was also selected. One port of the switch is dedicated to connect the IPMCS to the enterprise internet/intranet where part of the system’s HMI is supposed to run.
Figure 1. Network topology for the CORFU Framework.
2
4th IEEE International Workshop on Factory Communication Systems, Vasteras, Sweden, August 28-30,2002 Our approach to use interworking units between each fieldbus and the backbone, leaves unchanged the already defined legacy applications on each fieldbus and requires only the extra effort for the interconnection of function blocks assigned to different fieldbus segments. This would result, in the least effort that the enterprise should spend over the configuration of the new system. On top of this network topology we have defined the layout of the CORFU framework for the development and operation of distributed IPMCS applications. Figure 2 presents a high level view of the communication infrastructure introduced by the CORFU framework. The Industrial Process-Control Protocol (IPCP) has been defined for the development, distribution and operation of function block based industrial process measurement and control applications. It allows the interaction between the main components required for the development and operation of IPMCs applications, i.e. the Engineering Support System (ESS), the Virtual Fieldbuses (VFB), and the SCADA clients. For the IPCP protocol to be defined, the following interactions must be considered in detail: • ESS to VFB • VFB to VFB • VFB to SCADA clients
Figure 2. Architecture of the CORFU Framework. As is shown in figure 3, the main components of the interworking unit that cover both the configuration and the operational phases of the system are: the VFB, the Industrial Process Control Protocol and the wrapper. The VFB module is used to abstract any commercial fieldbus, to the IEC 61499 level so as the interoperability in fieldbus level may be achieved. For the implementation of the VFB module, a wrapper layer is defined which undertakes the task of wrapping the specific fieldbus to the VFB. The architecture is complemented by the definition of the Industrial Process-Control Protocol that is implemented on top of TCP-UDP layers.
As a result the IPCP has commands, which provide: • a real-time path for the exchange of events and data between cooperating function block based filedbus segments, • a straightforward method for the ESS to support the distribution and configuration of the distributed industrial control system, • a standard way for the interaction with clients that implement the HMI of the system. To support the above requirements the functions of the IPCP have been organized into three classes: Class 1: the class supports ESS to VFB communication Class 2: the class supports VFB to VFB real-time communication Class 3: the class supports VFB to SCADA client interaction For the Interworking Unit (IU) to be able to interconnect the existing fieldbuses to the selected backbone, a modular and highly expandable architecture has been defined. This architecture should satisfy the need for the real-time interconnection among fieldbus segments as well as the need for the similes development of IPMCS applications over heterogeneous field buses. It should also favour the uniform access from the corporate level through the many commercially available OPCcompliant SCADA client systems.
Figure 3. Architecture of the CORFU Interworking Unit.
3. The Virtual FieldBus This part describes the functions to be performed by the VFB, the modules that constitute it, and its interface to programs that require its services. We consider the VFB from two points of view: the real-time point of view and the configuration management one. According 3
4th IEEE International Workshop on Factory Communication Systems, Vasteras, Sweden, August 28-30,2002 The Real-Time Entity is considered as an aggregation of Virtual Field Devices (VFDs). The VFD is the software representation of a real field device inside the VFB. A notation is required to represent the properties of a field device in a machine-readable format to be used by the ESS during the development phase of the distributed IPMCS. A device specification is also required during the IPMCS’s operation phase. There are several notations, known as Device Description Languages (DDLs) that already support the specification of field devices. Among the notations we discriminate HART DDL, Profibus device description, Foundation field bus DDL and Lonworks DDL [12]. However, there is no common model for the device specification and these notations result in incompatible device specifications. Even more, dynamic aspects of the field devices as well as System Management are not covered by any of the above notations. In the context of the CORFU framework we have considered the requirements for the field device model imposed both by the development of the FB-oriented ESSs and the demand for device interoperability during the fieldbus operation phase. In [11] we have defined, using the Unified Modelling Language (UML), a field device model, which facilitates the development and operation of open FB-oriented IPMCS applications.
to figure 4, which highlights the configuration management point of view, the VFB is composed of the following three modules: • The Real-Time Entity (RTE) • The Configuration Management Entity (CME) and • The SCADA server
Figure 4. The architecture of the Virtual Fieldbus regarding the configuration management point of view. The Configuration Management Entity is the entity that is responsible for the configuration management of the VFB. It provides the services required by the ESS for the configuration of IEC 61499 compliant filedbuses. In [11] we have considered the requirements for the field device model imposed by the development of the FBoriented ESSs. During this process the most of the services that the CME must provide were defined. An ESS should use these services, to directly assign to the system layer, the higher two layers of our 4-layer IPMCS architecture [4]. An appropriate system level editor allows the engineer to construct the system design and directly map it to the real-world level. Furthermore, the ESS must provide all the functionality required by the FB’s distribution and assignment process to the system layer building blocks and mainly to field devices. Actions of the ESS that have no meaning in the application design phase, but refer to the configuration of the underlying communication subsystem must be properly hidden inside the CME by encryption and encapsulation mechanisms. Except of the above services, a set of services are provided for the configuration of the SCADA Server which is responsible for the interaction with the modules that implement the HMI of the IPMCS.
Figure 5. Virtual Field Device of type 1. We discriminate between two kinds of VFDs: VFD type1 and VFD type2. Figure 5 shows the VFD of type 1 which is considered as a proxy of a real IEC compliant device. This type of VFD is an entity that contains only the proxies of the function blocks that interact with
4
4th IEEE International Workshop on Factory Communication Systems, Vasteras, Sweden, August 28-30,2002 captured by the WITH statements would be used by the ESS to properly initialise the ECTs. The other data structure used is the Data Connection Table (DCT). DCTs contain except from addressing, the required information that must accompany each data connection of the module’s function blocks that are considered as outputs and have as destinations, function blocks assigned to other VFBs. Such information includes the value, the time stamp, the status, etc. This information has of course to be in the IEC 61499 format. The architecture is complemented by the definition of a set of rules, which are defined to meet all functional and non-functional (performance, extensibility and faulttolerance) requirements of the communication mechanism.
function blocks located in other devices in the same or other field buses. The VFD of type 2 is more complicated since it acts as a wrapper of a non-IEC compliant real device. VFD contains all the function blocks allocated to the real device as well as the wrapper of them to the real device connection points, as is shown in figure 6.
Figure 6. Virtual Field Device of type 2. Figure 7 presents the VFD of an IEC compliant device that is interconnected to the CORFU framework. The two function blocks FB1 and FB2 are assigned through the ESS to the real field device. The CORFU framework automatically creates, in the virtual field device that is contained inside the corresponding VFB, the appropriate proxies of the function blocks that interact with other function blocks that are located in other devices. This process takes place during the downloading of function blocks to the real device. CME has the functionality of configuring the VFB for the exported and imported data and events for the RTE to support the required event and data connections. For the real time interconnection a different communication scheme is used. A daemon process and a set of data structures, as is shown in figure 3, are used for the implementation of the mechanism, which allows interactions among the specific fieldbus, the SCADA server and the IPCP. There is an Event Connections Table (ECT) that contains, for every output event exported by the VFB, the information required by the daemon module to respond to the communication requirements of this event. When a function block of the VFB produces an event that is used by another VFB, the RTE of the producer function block must send a request to the daemon module to handle this event. The daemon uses the information of the related ECT entry and forwards the event with the required data to the destination VFB. It is clear that there is a close relation to the WITH keyword of the function block notation. Actually the information
Figure 7. An IEC compliant field device connected to the CORFU framework. To better understand the functionality of the wrapper three possible scenarios for distributing two function blocks interconnected with event and associated data as shown in figure 8 were considered: • FB1 and FB2 are allocated to the same device • FB1 and FB2 are allocated to different devices of the same fieldbus
5
4th IEEE International Workshop on Factory Communication Systems, Vasteras, Sweden, August 28-30,2002 •
The specification of the behavior required by any IPCP implementation, both in its interactions with IPMCS process and in its interactions with other IPCPs should be given. The interface between an application process and the IPCP, i.e. the IPCP/user interface, should be illustrated in reasonable detail. This interface should consists of a set of calls much like the calls an operating system provides to an application process e.g. for manipulating files. For example, there are calls to OPEN or CLOSE a VFB, to properly configure the VFB by means of downloading function blocks, making connections between function blocks and defining imported and exported data and events, or to obtain the VFB’s STATUS. Although considerable freedom should be given to IPCP implementers, to design interfaces, which are appropriate to a particular operating system environment, a minimum functionality must be defined/required at the IPCP/user interface for any compliant implementation. It is also expected that the IPCP should asynchronously communicate with IPMCS application processes. The interface between IPCP and the lower level protocols such as TCP or UDP must be specified. The IPCP/TCP-UDP interface should provide calls to send and receive IPCP datagrams addressed to IPCP modules in hosts anywhere in the IPMCS. These calls should have parameters for passing the address, type of service, precedence, security, and other control information. A mechanism should be provided for the two levels to asynchronously pass information to each other. IPCP should be designed to work in a very general environment of interconnected networks where TCP/IP protocol stack is available. A list of the main commands for the class 1 and class 2 is given below.
FB1 and FB2 are allocated to different fieldbus segments
Figure 8. A simple function block diagram. Wrapping of profibus In our first prototype implementation we selected to interconnect a profibus segment with a Lonworks one [13]. In our first implementation of the Profibus wrapper we made use of the Softing’s Profibus Linux driver. To obtain interoperability in function block level, coding and decoding to IEC61499 data types was introduced. Input or output data of a DP slave of profibus might consist of more than one items and are represented in a Profibus specific format. Most of the times the representation is vendor specific and the engineer has to deal with them according to the directions of the device vendor. For example the module 6ES7, 332-5HD010AB0 4x12bit AO has 8 bytes of output data. Each set of 2 bytes represent an analogue value but only the 12 bits of the total 16 are used. Moreover the user can choose of three different ways to represent the number in those 12 bits. According to the virtual fieldbus in order to represent these DP analogue values we create 4 distinct items. These items have a unique ID and are of type ANALOG, which means that their data type is a 4-byte float. More factors have to be taken in care so the system finally will know where to find these DP outputs and how to deal with them. The details are not in the scope of this paper.
Class 1 main functions: APPEND_DEVICE.request/indication REMOVE_DEVICE.request/indication DOWNLOAD_FB.request/indication CONNECT_FB2IPT.request/indication CONNECT_FB2FB.request/indication EXPORT_FB_ITEM.request/indication IMPORT_FB_ITEM.request/indication
4. The Industrial Process Control Protocol The IPCP is intended to provide a reliable process-toprocess communication service in a multi-network IPMCS environment. IPCP specifies a protocol for the development and operation of distributed, function block oriented Industrial Process Measurement and Control applications. It should support both reliable stream-based transmitions, mainly for configuration management, and unreliable UDP, mainly to satisfy the real-time constraints. The IPCP interfaces on one side to IPMCS application processes and on the other side to lower level protocols such as TCP or UDP. T/TCP may also be used to obtain faster, more efficient and more reliable transactions.
All the above commands have the corresponding confirm/response primitive. Class 2 main functions: GET_DATA.request/indication GET_DATA.confirm/response GET_DATA_GROUP.request/indication GET_DATA_GROUP. confirm/response POST_DATA.request/indication POST_EVENT.request/indication 6
4th IEEE International Workshop on Factory Communication Systems, Vasteras, Sweden, August 28-30,2002 configuration an issue we must mention is the absence of networking for the RT-Linux. We only found one such implementation, the RTNET one, which only offers UDP functionality. However to support a reliable configuration, TCP functionality is required. We developed a reduced functionality TCP layer on top of the RTNET’s Internet Protocol. That was not an easy task mainly due to the absence of design documentation. “Understand C” was proved to be a very helpful tool for this task.
POST_EVENT_WITH.request/indication Instead of developing IPCP on top of UDP the use of a protocol that belongs to the context of the Data Distribution Services for Real Time Applications of the corresponding RFP of the OMG may be considered. Protocols of this category provide to the application developers a standard set of services across products from multiple vendors. These services are based on a publish-subscribe, rather than CORBA’s client-server model, and this model eliminates network programming. The NDDS real-time messaging middleware provided by the Real-Time Innovations contains an implementation of the Real-Time Publish Subscribe (RTPS) wire protocol. The RTPS protocol provides publish-subscribe services over the industry standard UDP that is provided with the Internet Protocol (IP) stack. Data are distributed based on named topics rather than IP addresses. IPCP can set deadlines for new topic issues, perform automatic hot-swap for redundant publishers, and control the data flow rate. The protocol is optimized to add minimal latency to the network communications overhead and lets the ESS to specify a minimum wait period and deadline on a subscription-by-subscription basis [13].
6. Conclusions Recent IEC standards propose the function block concept, to improve productivity in terms of re-use, reliability, flexibility and interoperability in the development of distributed IPMCS applications. We adopted this concept and considered the requirements for the development of such applications. We defined CORFU, a Common Object-oriented Real-time Framework for the Unified development of distributed IPMCS applications. This framework assists process and system engineers in the development, configuration and operation of distributed IPMCSs. We constructed the frameworks architecture having in mind issues such as modularity, expandability, robustness, and flexibility. We have found our architecture very helpful in the development process of our function block oriented Engineering Support System. It helped us to easily identify services for application management, such as function block creation, deletion, interconnection and activation. The importance of such services is expected to increase along with the demand for system agility. Although the function block concept attempts to address the interoperability issue, it still has a long way to go. Over and above, the Function block approach is procedural-like and it does not exploit the maximum benefits introduced by the Object Technology. New technologies in Software Engineering as well as modern CASE tools that assist in improving the efficiency of software development process must be considered for the development of distributed IPMCSs. We are currently working to the direction of expanding CORFU to support the use of the UML notation in the development process of IPMCS applications.
5. Our Prototype implementation To proceed with the implementation, we adopted RTLinux to be the RTOS of our interworking unit [14]. RTLinux is a “hard real-time” mini operating system that runs Linux as its lowest priority execution thread [15]. The Linux thread is made completely preemtible so that realtime threads and interrupt handlers are never delayed by non-real time operations. RT-Linux, in its last version, supports user-space real-time programming. Code running in user space, as compared to kernelspace, is more easier to debug, is less likely to crash or hang the system and is more convenient to communicate with other user-space tasks. However a constraint that must be taken into account is that RTLinux does nothing to help Linux be real-time. In our case study the interworking unit was equipped with a PROFIBUS master card and IBM's Turboways 25 Mbps ATM adapter and it was connected to an IBM's 8285 ATM switch. Drivers were available under Linux for all our hardware. However we had to port them to RTLinux. As PROFIBUS card we selected Softing's PROFIBOARD, that offers a dual port RAM as an interface mechanism to the processing unit. Since a binary for RT-Linux was not available from Softing we have undertake the project to port the driver to RTLinux. Fortunately Softing provided us with the driver’s source code and the necessary support to accomplish this task. For the case of fast switched-Ethernet we installed the Intel Express 410T Standalone Switch. For this
Acknowledgements I gratefully thank Chris Tranoris, George Doukas, Polizois Parthimos and Peter Manesis members of the development team, for their helpful discussions.
7
4th IEEE International Workshop on Factory Communication Systems, Vasteras, Sweden, August 28-30,2002 References
[12] Christian Diedrich, Peter Neumann, “Field Device Integration in DCS Engineering using a Device Model”, IEEE 1998. [13] Real-Time Publish-Subscribe (RTPS). Wire protocol specification, Protocol version 1.0, Document Version 1.15. Real-Time Innovations, Inc. 2001. [14] C. Tranoris, S. Aslanis, K. Thramboulidis, “Using RT_Linux for the interconnection of industrial fielsbuses” ASME international, First National Conference on Recent Advances in Mechanical Engineering, September 17-20, 2001 Patras, Greece. [15] Victor Yodaiken, “real-time Linux, A short position paper”, http://www.rtlinux.org
[1]
IEC Technical Committee TC65/WG6, “IEC61499 Industrial-Process Measurement and Control – Specification”, IEC Draft 2000. [2] IEC SUB COMMITTEE No. 65C: DIGITAL COMMUNICATIONS, WORKING GROUP 7: FUNCTION BLOCKS for PROCESS CONTROL , “IEC1804 General Requirements”, IEC Draft 1999. [3] R. Lewis, Modelling control systems using IEC 61499, IEE 2001. [4] K. Thramboulidis, C. Tranoris, “A Function Block Based Approach for the Development of Distributed IPMCS Applications”, 10th IEEE International Conference on Advanced Robotics (ICAR 2001), August 22-25, 2001, Budapest, Hungary. [5] K. Thramboulidis, C. Tranoris, “An Architecture for the Development of Function Block Oriented Engineering Support Systems”, IEEE International Conference on Computational Intelligence in Robotics and Automation, Canada August 2001. [6] IDA- the Inetrent of Automation Technology, White paper, v 1.0, IDA-Group, 2001. [7] IDA – Interface for Distributed Automation: Architecture Description and Specification, Revision 1.0, November 2001, IDA group. [8] Maarten Boasson, “The Artistry of Software Architecture”, IEEE Software, November 1995, vol. 12 No 6. [9] O. Kunert, “ Interconnecting fieldbuses through ATM”, IEEE International Workshop on Factory Communication Systems, 1997. [10] C.Cseh, M.Jansen, J.Jasperneite, “ATM networks for factory communication”, 7th IEEE International Conference on Emerging Technologies and Factory Automation, 1999. [11] K. Thramboulidis, A. Prayati, “Field Device Specification for the Development of Function Block Oriented Engineering Support Systems”, International Conference on Emerging Technologies and Factory Automation, French Riviera 2001.
APENDIX A ABREVIATIONS USED IN THE PAPER CME: Configuration Management Entity CORFU: Common Object-oriented Real-time Framework for the Unified development of distributed IPMCS applications. DCT: Data Connections Table DDL: Device Description Language ECT: Event Connections Table ESS: Engineering Support System FB: Function Block HMI: Human Machine Interaction IPCP: Industrial Process-Control Protocol IPMCS: Industrial Process Measurement and Control unit. IPT: Industrial Process Terminator IU: Inteworking Unit OO: Object Oriented OPC: OLE for Process Control. OT: Object Technology RTE: Real-Time Entity RTOS: Real Time Operating System SCADA: Supervisory Control And Data Acquisition UDP: User Datagram Protocol UML: Unified Modelling Language VFB:Virtual Field Bus VFD: Virtual Field Device
8
