Software Engineering Approach in the Design and Development of the ...

5 downloads 208 Views 755KB Size Report
May 13, 2008 - design and development of industrial automation systems based on software engineering principles including unified modeling language UML ...
Software Engineering Approach in the Design and Development of the Industrial Automation Systems Adnan Salihbegović ETF Sarajevo Zmaja od Bosne bb Sarajevo, Bosnia +38761143479

adnan.salihbegovic@ etf.unsa.ba

Zoran Cico

Vlatko Marinković

Elvedin Karavdić

ETF Sarajevo Zmaja od Bosne bb Sarajevo, Bosnia

Bosna-S Oil Service Company Ulica Nova 26 Sarajevo, Bosnia +38761235348

Bosna-S Oil Service Company

vlatko.marinkovic@ bosna-s.ba

elvedin.karavdic@ bosna-s.ba

+38761273093 [email protected]

ABSTRACT

Ulica Nova 26 Sarajevo, Bosnia +38762204563

General Terms

The objective of the paper is to present generalized approach in design and development of industrial automation systems based on software engineering principles including unified modeling language UML and concept of reusable software and COTS software modules. The said generalization is illustrated on the case example of the design and engineering of the software for one real life project that Faculty software engineering group has completed for local engineering firm. The said project involves monitoring and control system for the refinery oil terminal with truck loading and pipeline shipping of petroleum products. System architecture is based on PLC controllers and can be part of the any larger, network-based, SCADA/HMI system. In the first part of the paper, we present the overall hardware architecture for the system as well as its software structure described with variety of UML diagrams presenting underlying processing logic and communication and human interfaces between systems distributed parts. These formal representations of the system functional requirements are then used, in conjunction with the software tools, for configuring and programming of the controllers as well as designing and coding its interface modules and drivers and HMI interface screens and underlying functionalities. The modeling of both automatic control sequences (for truck loading applications) and programming units that enable operator input from HMI screens (for pipeline shipping) are presented to demonstrate the idea of reusable software approach, further applied in modeling of the user-designed building blocks for the control and monitoring of pumps and MOV’s (Motor Operated Valves). Furthermore, some of the real-time performance requirements on communication subsystem and protocols are first defined and tested in developed UML RTD diagrams and then implemented and tested in the target hardware and software integration in commissioning and start-up phase of the developed system.

Algorithms, Design, Reliability, Human Factors, Standardization

Keywords Software engineering, UML diagrams, SCADA/HMI, data server, fieldbuses, COTS software, OPC protocols, real-time systems, user interfaces

1. DESCRIPTION OF THE CONTROLLED SYSTEM Refinery terminal consists of 6 main processing areas: Truck-Loading Gantry, Pump Station A (6 loading pumps), Pump Station B (11 shipping pumps), Electrical Substation, Tank Farm, and Administrative Building with Control Room. Different products, like fuel oil, gas oil, premium, regular, kerosene, avgas and LPG are coming from the refinery, and are used for tank stocking, truck loading and pipeline shipping. PLC based SCADA/HMI system, is used for control and monitoring of all processes on the terminal, enabling automatic loading sequences and generation of the reports of loaded products to trucks, measurement of all process variables, indication and material balances of all incoming and outgoing products, tank inventories, automatic control of process variables (temperatures, pressures, densities, etc), alarm registration, acknowledgement and archiving, real time trending and trend history windows real-time data exchange with remotely installed RDBMS business database for invoice and other financial transactions with product buyers and many more. The truck-loading gantry consists of 11 loading arms, used to load gas oil, premium, regular, kerosene and heavy naphtha to trucks. The products are pumped to the loading gantry and trucks by six loading pumps in pump station A. Upstream of each loading arm, a PD flow meter, flow computer and a set/stop valve are installed, providing automatic loading sequence and precise measurement of loaded quantity [2]. RS-485 serial communication is used to connect all 11 flow computers with PLCs, enabling automatic starting of the loading pumps when request for loading from loading gantry is received, and also enabling the complete monitoring of the loading system, including on-demand and scheduled reports. Pump station B consists of 11 shipping pumps, which are used to transfer products through 2 pipelines. The white products pipeline is used to transfer gas oil, premium and LPG to the product-loading harbor for overseas tanker transportation, through a 40 km long

Categories and Subject Descriptors C.3 [Process control systems] D.1 [Programming techniques]: D.1.6 Logic programming, D.2 [Software Engineering] D.2.2 Modules and interfaces, State diagrams, User interfaces, Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that coies are not made or distributed for profit or commercial advantage and that copies bear this notice systems] and the full citation on the first page. To copy C.3 [Process control otherwise, or republish, to post on D.1.6 serversLogic or toprogramming, redistribute to lists, D.1 [Programming techniques]: ,requires prior specific permission and/or a fee. SEESE’08, May 13, 2008, Leipzig, Germany Copyright 2008 ACM 978-1-60558-076-0/08/05...$5.00.

15

pipeline. The Fuel oil pipeline is used to transfer heated fuel oil and gas oil to an electricity power plant through a 30 km pipeline. All incoming and outgoing quantities are custody metered by turbine flow meters and PLCs enable indication, totalization and reporting of all flow rates and quantities [2]. Furthermore, user defined control blocks enable automatic and manual control of all MOV’s (motor operated valves) and pumps, in loading and pumping sequences. All MOVs at the terminal are interconnected in the fieldbus network, enabling control and monitoring of actuators using just one twisted pair wire. The network is closed in a ring, making it dual redundant and providing additional reliability [18]. The tank farm consists of several product tanks, for premium and gas oil storage, and two LPG spheres. Radar level gauges are used to measure product levels, and a dedicated communication interface unit (CIU) is used to transfer the measurement data to the central SCADA/HMI system.

2. MONITORING AND CONTROL SYSTEM DESIGN A distributed PLC based SCADA/HMI system was built with the standard hardware components of Yokogawa Stardom system, a networked-based Control System (NCS) that is by its architecture and functional capabilities positioned between the lower-end PLC/SCADA systems and the higher-end DCS [1]. Based on these building blocks and integrating other components from different hardware manufacturers, owing to system’s open hardware and software structure, we arrived at the total system architecture depicted on the following figure No. 1

Figure No.1 Topology of the system redundant, providing additional reliability and availability to the system [1], [3]. Furthermore, there is an engineering station based on the large size LCD monitor and industial PC which runs VDS server software and is located at the console. Together with the maintenance station, there are in total four different operator screens in the control room that can be watched and used at the same time. All of the other PC-based, PDA or notebook based Operator stations are connected as thin clients either wirelessly in the field via IEEE 802.11 b/g WLAN, or through a VPN network over the Internet as thin clients. Additionaly, there is Internet

The control system is housed in two control cabinets, Cab1 in a control room and Cab2 in an electrical substation. There is one FCN controller in both of these cabinets and these controllers are interconnected using Ethernet communication through a fibre-optic cable. Console inside the control room includes an industrial PC which runs VDS (e.g. Data Server and HMI Server). There are also two Touch Screen Panel PCs mounted on the front side of the control cabinet. By using these panels, operators can monitor and control all system functions. Controller CPU’s, power supply units and communication ports are all selected to be dual

16

machine diagrams, timing diagrams, etc) [14]. Resource Configurator was used for hardware modules configuration and for the definition of every input and output signal from the field being directly connected to the system, and not using fieldbuses. After editing these data, all I/O tags were defined as global variables and were used during control logic development inside Logic Designer. In order for these process tags to be available in Data Server, Logic Designer’s tag database configuration, needs to be exported to Object Builder. After most of the tag database is up and running inside Data Server, development of the graphic operator screens can start, previously prepared and tested with adequate set of UML diagrams like communication diagrams, interaction diagrams, etc [13]. Regarding the graphical options available, every label, indicator or any other element and its attributes can be linked with tags from Data Server using the DataSource Dialog option. With Graphic Modify function , graphic objects can change their properties according to the values of the process tags in Data Server. Overall software architecture of the communication and control system can be described using deployment diagram, thus enabling to define software modules inside field controllers, necessary for overall system functioning. There are basically two modules of the control software: control logic, responsible for control sequence execution and interlock design for each pump and MOV and communication module, responsible for interface between control logic, field devices and operator workstation as a human-machine interface [11]. Deployment diagram is shown in the figure No. 2.

based VPN connection to business database in the company headquarters for business data processing [9].

3. CONTROL SYSTEM IMPLEMENTATION The main hardware components of the system are standalone controller FCJ (Field Control Junction) and FCN (Field Control Node) with expandable I/O modules. FCN is a rack mounted unit with I/O modules which also include communication modules for remote I/O, PLCs of other manufacturers, Modbus and Fieldbus. Both controllers use the same programming sofware which complies with IEC 61131 programming languages. Simple, web based operator panels can be created using JAVA-based tools [16]. Software tools available for the system from the hardware manufacturer include [1]: − Software programming tools in compliance with IEC61131 standard for programming of FCN/FCJ PLC controllers, with five application development languages. − Application Portfolios - user-defined programs that can be security protected for use in other projects to implement the idea of reusable application software modules. It is based on the use of layering such that function blocks can be created from other function blocks and be in turn used nested in other function blocks. Application Portfolios can be created from a set of function blocks to define a simple or complex control strategy, and can be re-used in other projects [19].



Embedded HMI web server with tomcat apache server and email function in the field controllers, providing autonomous functionality of the controller. No other HMI software is required, making them ideal for embedded and remote applications [5]. Other software modules include JRE and are running under renowned Wind River VxWorks real time operating system [6].

Software component for the implementation of HMI part of the system is the VDS (Versatile Data Server), which is a PC based application that combines a data server and a HMI Server to collect data from FCX’s (FCNs or FCJs), from PLCs of other manufacturers, I/O modules and DAQ stations and third party devices and provide information to the user via web-based operator displays. The data server and HMI Server connect to each other using OPC, and can be in the same or separate PCs. Third party applications can also access the data server using OPC protocols [7].

4. SOFTWARE DESIGN FOR THE CONTROL SYSTEM

Figure No.2 System software deployment diagram

Appplication software development and configuration is done based on system functional specifications and underlying hardware configuration. This development can be formalized and automated at the later stage of code generation and configuration applying tools like UML diagrams to describe system fuctions and algorithms that have to be implemented in software ( state

4.1 Control Logic and User Developed Control Blocks User developed control blocks, have been created as generic for control of pumps and MOV’s to enable reusing the same block multiple times, thus creating the modular structure of the control

17

logic system and speeding up application software design. In this way, the same logic block was used for control of all 59 MOV’s, the only difference being input and output tags connected to the block. The same user defined control block was created to control all 17 pumps in the Project. Software for the field controllers has been designed using IEC 61131-3 programming languages and Yokogawa proprietary libraries for communication development. Control logic for automatic product loading has been designed using Structured text programming language, favorable for definition of various conditions (if-then statements) and repeating sequences. On the other side, functional block diagrams were used for pump and MOV control logic development. Programming with Function block diagrams language enabled easy development of logic diagrams, using basic logic functions (and, or, not) and latch blocks necessary for keeping up the memory of the current control block state [12]. Previously, while defining the functionalities of these modules, they were specified using UML state machine diagrams, that were useful pictorial presentations while discussing these functions and functionalities between software engineering and process control team members [17].

Using this block and its associated faceplate, Operator can carry out automatic/manual and open/stop/close commands, while the control system development engineer can add required interlocks (manual disable, open disable, close disable). The control block accepts commands from both the HMI operator issued on the screen and programmatic commands from automatic sequences generated from state charts [10]. The initial operating mode of the MOV is automatic. If the user needs to operate the MOV, he first has to switch the MOV into manual operating mode. This can be done on the faceplate for every MOV. Faceplates are created as one graphical object block and the configuration for every specific MOV is done by linking adequate variables from the control blocks. The faceplate that enables the operator to control and monitor the MOV’s from HMI screens is shown on the figure No. 4 and next to it is the iconical view of the code generated functional block structure.

4.2 User Developed Block for MOV Control Basic functionality and internal state configuration of the generic block for MOV control can be represented using UML state diagrams [11]. There is one key condition that determines control block functionality. It is the local/remote selection. Only remote state of the control block allows control block execution and issuing commands to the field devices. Local state of the control block makes it idle and does not allow any command to be issued. Control block has two states that define control logic execution. Automatic state, which represents variety of interlock conditions for proper system functioning and command issuing. Another is the manual state, necessary for connection with HMI operator. This way, operator is allowed to issue commands from the operator screens. Both of the mentioned states includes alarm and interlock checkout logic structure, which verifies necessary conditions for command issuing and possible alarm state of the MOV. UML state diagram of the MOV control block is shown in the next figure No.3

Figure No. 4 MOV function block and graphical icon

4.3 User Developed Block for Pump Control This block also has automatic/manual and start/stop logic, for commands issued both from human operator (manual control), and programmatically by control sequence logic (automatic control) [2]. Regardless of the current operating mode, if the abnormal process state occurs, the operational mode immediately switches to automatic, and issues the command to stop the pump. The pumps in the Pump station A are programmed to work all the time in automatic mode, and can not be switched to manual mode by the remote operator. The control logic is implemented in such a way that the pump starts every time the loading request is received from the loading gantry and stops when the loading has finished. If more than one pump is present on the same product line, the starting of the second pump is implemented if the requests are received from multiple loading arms. Also, the automatic starting of the third (stand-by) pump is carried out, when one of the main pumps drops out of the service. For Pump station B, different control algorithms were implemented. The operator can start the pump manually, but only if the suction MOV of the pump is open, and the discharge MOV of the pump is closed. The faceplate of the block consists of the start/stop and automatic/manual indications and commands, and local/remote status indications.

Figure No. 3 MOV logic state diagram

18

State diagram of the pump control block depicted on the figure No. 5 is very similar to the state diagram of the MOV block. Only the remote control state allows block execution and command issuing and automatic and manual state makes the difference between automatic command issuing and the manual one, issued by the operator. Varieties of different conditions for proper pump functioning are included in alarm&interlock state checkout. It is customized and designed for specific use of the pump. At the end, when all alarm conditions and interlocks are fulfilled, start and stop command can be issued.

4.4 HMI Screen Example: Control Board For Overall System Monitoring The following figure No. 6 is presenting, in the way of process flow diagram, the overall plant of truck loading and pipeline shipping. Dynamic layer of the screen (e.g. indicating the status of the equipment, if it is ON or OFF or open/close) is used on the following components: - pumps (ON – green, OFF – red). If the pump is ON, there is additional animation showing the rotation of the pump rotor. - MOVs (MOV open is indicated with green color, and when closed the color of the MOV icon turns red) Furthermore, there is indication of the MOV moving from one final position to another (e.g. from open to close state or opposite). During this movement the icon of the MOV becomes gray and stays in that color, until MOV reaches final position when it turns into red (if closed) or green (if open). There is no possibility to issue the command from this screen, except of the selection of the zoom-in screens from which this can be done. Selection can be done either from the bottom part of the screen by clicking with mouse (or touching with the finger on touch screen monitors installed on the front door of the cabinet CAB 1 in control room) on one of the buttons.

Figure No. 5 Pump control state diagram

Figure No. 6 HMI screen for system overview

19

Alternatively, selection of the new screen can be done by clicking (or touching) an area on the screen that is showing the part of the process where Operator wants to zoom in (e.g. clicking/touching in the area showing tanks to go to screen “Tanks” or clicking/touching the area depicting spheres to go to “Spheres” screen , and so on).

5.2 OPC (OLE for Process Control) Communication The OPC Specification is an open-standard technical specification that defines a set of standard interfaces based upon Microsoft’s OLE/COM technology. The data acquired by the Data Server, are accessible from the outside programs via OPC interface to allow access according to a unified procedure via set of defined interfaces. At Stardom, HMI Server and other external applications can access the data in the Data Server via its OPC interface (Figure No. 8), implemented using OPC DA 2.0 Specification directives [7], [8]. Stardom provides only limited number of template reports, but we needed additional “on event” reports for loading computers to create loading bills. Since reporting engine in Stardom system failed to fulfill these needs, open interface standards and students creativity in software engineering subjects played the mayor role. Students as members of development team, developed OPC 2.0 DA Automation client component using MS Excel VBA. Since it is an Automation object, another COTS (Commercial Of The Shelf) was embedded in system, e.g. OPC DA 2.0 Automation Wrapper. Developed module is running in MS Excel and is connected to Data Server’s OPC Server through Automation Wrapper for data collection. Data Server is acquiring data on loading status, loaded amount, driver ID, time and date from each loading computer. Developed module is subscribed as OPC client and after value of loading status changes from 1 to 0 signifying the end of loading, module fills the report with adequate data in form of loading bill, archives the bill and than sends it to the printer.

Before implementation of the screens, and there are about 60 of these hierarchically organized, their content and interactions with operators were specified using use case and activity UML diagrams [10],[17].

5. COMMUNICATION INTERFACES AND PROTOCOLS The Data Server interrogates connected controllers at a user defined polling rate, which can be configured to be different for different process parameters. The controllers are usually set as passive type devices from higher level data processing point of view, so they just pass the requested data to the data servers. Some of them are set as active type devices, and can transmit data at an arbitrary timing [1],[4]. FCN does both, it makes response to a request from the Data Server, but also support unsolicited data transfer, which means it is set as hybrid type data source device , as depicted on the next Figure No. 7.

Figure No. 7 Operator station - controller communication diagram The Data Server consists of the data server engine, Control objects and the I/O objects. The data server engine exchanges data with the field device using the I/O object function, and executes various processing functions using control objects [20]. Careful tuning is needed, when connecting PLCs to VDS Data Server, in order to register virtual IP addresses of FCNs, set whether or not a dual redundant network will be used, and whether or not the time between the FCN and VDS should be synchronized (for time stamping of OPC data). The process data network can also be modeled as multilayer architecture which is providing system distribution throughout the plant or supporting geographically distributed systems [18].

Figure No. 8 OPC based communication diagram

5.1 Field Buses As seen on the overall system topology depicted on Figure No. 1, at the lowest level of HMI/SCADA system, apart from direct I/O field connections, there are three field bus subsystems: level gauging subsystem, MOV (Motor Operated Valve) subsystem, and truck-loading computer subsystem. The majority of I/O signals have been entered into the system directly through PLCs I/O modules (around 800) located in the control room and the power transformer substation (mostly due to the hazardous area limitations).

At HMI layer, HMI Server runs as message management software, acting as interface between HMI clients and Data Server. The HMI Clients and HMI Server interact using HTTP, to achieve accessibility within various networking configurations. This results in an increased friendliness with the existing network devices and equipment, such as firewalls. The HMI client is a standard Web browser that receives and displays data from HMI Server, which is the HMI client’s interface with Data Server. A special feature of the HMI client is

20

that it is a Thin Client, meaning that no additional software is required for it to carry out the above function, reducing the total cost of system implementation. The HMI Client displays a page upon same mechanism as the Internet, using HTTP. A Web browser issues the request to an HMI server (1) by specifying the address of the page to be displayed. The HMI server then returns the HTML of the requested page (2). Furthermore, the HMI server executes Java Servlet, and then returns the results to the applet executing in Web browser [16], as depicted on the next Figure No. 9.

6. INTEGRATION OF REAL-TIME PROCESS AND BUSINESS DATABASES The ID of the truck driver filling his truck is received from the card reader (see on the above figure No. 10) and is used by the load computer to check in its online database, whether the driver can be allowed to start the loading related to his company’s financial status and liquidity, as well as to issue after completion of the loading, the loading bill and register the loading quantities in the central billing and invoicing database located at the Company headquarter. These two: real-time process and business databases, are online interconnected and synchronized over the Internet using OPC protocol tunneling within VPN network using OPC to ODBC converter as COTS component readily available on software market [9]. The interplay between software and process control and management staff proved to be possible and successful when both players used common specification tools provided with UML database and entity relationship diagrams [10], and COTS components to implement this functionality.

Figure No. 9 Applet–servlet communication diagram

7. CONCLUSION

The overall architecture depicting all of communication layers is shown on the figure No.10

The paper describes and illustrates design process of an industrial application based on standard SCADA/HMI system, which has been significantly customized and extended through system open hardware and software architecture. The features of the used system like: modularity and extensibility and communication with the remote devices of various manufacturers and vendors are demonstrated, This is achieved by using Modbus, Ethernet, OPC or any type of field buses based on serial communication and myriad of protocols including tools for user specified communication and protocol driver. Additionally, the dual-redundancy architecture for the majority of the system components, and the modular software architecture with the standard and open real time operating system are also utilized throughout system design. Numbers of functions are incorporated with the software tools, especially the layering capabilities for software development in the Logic Designer. These possibilities are demonstrated through control logic development and userdefined blocks developed for an industrial application. Within the HMI interface, the modern approach of Java based web application with thin clients further extends the modularity and scalability features of the system. The described SCADA/HMI system integration approach, based on standard interfaces and protocols using COTS software modules and formal system functional description based on UML diagrams, together with avoidance of any proprietary traps, has proved to be the optimal solution for system integrators of realtime monitoring and control systems. This is especially true when these systems are extending their boundaries of real-time data acquisition and processing to a higher level of plant, corporate and enterprise management and data processing, integrating process control and business activities in total plant and enterprise wide systems. For this goal, formalization of specifications using UML diagrams was common ground of understanding and mutual collaboration between the software and process control engineers involved in system design.

Figure No. 10 Topology of system communication layers

21

8. REFERENCES

[12] Douglas, B. P. 1998 Real-time UML, Addison-Wesley, 1998

[1] Yokogawa, Stardom system documentation

[13] Jaragh. M, Saleh K.A 2000 Modeling communications protocols using the unified modeling language , Proceedings TENCON 2000, Volume 2, pages 271-275.

[2] API RP 554, Process Instrumentation and Control [3] API Recomended Practice 557, Guide To Advanced Control Systems

[14] Gomma, H. 2000 Designing concurrent, distributed, and real-time applications with UML, Addison Wesley , 2000

[4] IEEE Std 999-1992 Recomended Practice for master/remote supervisory control

[15] Jacobson I. 1992 Object-oriented software engineering, Addison Wesley, 1992

[5] Zoltan Laszlo 2005 Memory allocation in VxWorks 6.0 , White paper, Wind River Systems Inc, 2005

[16] Magee, J. and Kramer, J. 1999 Concurrency: State models & Java programs” , John Wiley and Sons, 1999

[6] Maarten Koning and Keith Wiles 2007 Device software optimization for concurrent and consecutive systems, White paper, Wind River Systems Inc, 2007

[17]

Rosenberg, D. and Scott, K. 1999 Use case driven object modeling with UML”, Addison Wesley, 1999

[18] Grygiel, G. Hensler, O. and Rehlich, K 1996 DESY, DOOCS: a Distributed Object Oriented Control System on PC’s and Workstations, 1996

[7] OPC – Data access automation interface standard , OPC Foundation publication, Ver. 2.20 , Feb 1999 [8] OPC – Data access custom interface standard , OPC Foundation publication, Ver. 3.00 , March 2003

[19] Crnkovic, I. Hofmeister, C. Reussner, R. 2006 Quality of Software Architectures, Second International Conference on Quality of Software Architectures, QoSA, Springer Berlin / Heidelberg, ISBN: ISBN-10: 3- 540- 48819-7, 2006

[9] Matrikon OPC Server for GDA – user manual , Matrikon publication , Vers. , December 2005 [10] Visual paradigm for UML Ver. 6.2 , Instruction manual

[20] Heinzelman, W., Murphy A, Carvalho H, Perillo M 2004 Middleware to Support Sensor Network Applications. IEEE Network Magazine 18 (2004)

[11] Jakob Axelsson 2001 Unified modeling of real-time control systems and their physical environments using UML Proceedings of the eighth annual IEEE International conference and workshop on the engineering of computer based systems ( ECBS’01).

22