Functionality Considerations in Custom SCADA Development Tools

Transcription

1 Functionality Considerations in Custom SCADA Development Tools Timothy P. Creegan STRACT Supervisory control and data acquisition (SCADA) software is used to control and monitor processes throughout industry. The licensing cost of software and the bundling of potentially superfluous functionality into commercial SCADA software could lead organizations to develop their own custom SCADA development tools for internal use. It is important to understand the functionality criteria unique to each organization. A method for determining the critical functionality factors for SCADA software is presented, along with an example study of an organization s SCADA software base. Keywords SCADA, COTS, Software Functionality, Software Quality 1. INTRODUCTION 1.1 Basics of SCADA Supervisory control and data acquisition (SCADA) software is used in manufacturing and utility industries for control and monitoring of industrial equipment, processes, and production data. A typical SCADA system consists of one or more personal computers, a software application developed with the SCADA vendor s development tools, and one or more remote devices called remote terminal units (s), which could include programmable logic controllers (PLCs), utility meters, smart process transmitters, or others. Features of the software applications typically include: graphical visualization tools for depicting and controlling equipment and processes to an operator, also called human-machine-interface (HMI) drivers for PC PLC communications, trending and archiving of process data, synchronous and asynchronous scripting features for basic programming tasks, recipe management for automatic machine setup from preset parameter recipes and so on. Data in a SCADA system are exchanged between the software running on the personal computer and the s in the field. Each individual piece of data addressed in the system, including process variables, internal calculation results, displayed values, etc. is designated as a tag. Tags are analogous to variables in other programming languages, and provide a means for measuring the size of a SCADA application; applications can range from a size of fewer than 100 tags for very small standalone systems to tens or hundreds of thousands of tags for a system controlling a complex system such as an oil refinery. There is some confusion about the term SCADA and other similar terms including Process Control System and Human Machine Interface. At one time SCADA systems were primarily known for utility monitoring, and field devices were typically far-flung meters accessible only by modem or radio communications. At that time the term SCADA implied remote communication with an, while Process Control System implied local communication such as within the same physical building. Today however there is less of a distinction between local and remote control as digital communication (e.g. Ethernet) has become prevalent, and SCADA no longer connotes distance between supervisory computer and controlled device. Human Machine Interface (HMI) is another term often used interchangeably with SCADA, but HMI systems strictly speaking do not incorporate control or data acquisition, only display of system data and acceptance of human input to the system. Commercial-off-the shelf (COTS) SCADA development software packages can be divided into two families: proprietary and open. A proprietary SCADA development package is intended to be used with a specific application type and/or hardware type. Open SCADA development packages are intended to be usable for a wide variety of application and hardware combinations. [1] 1.2 Main Functional Points of SCADA There are several functionalities associated with typical SCADA systems. These are described below in detail. Input/output: This is the ability to accept and transmit data between the supervisory computer(s) and s. This is done by supplying the necessary network layers between hardware (physical connection to the devices) and application (required drivers to transfer data between the supervisory software and hardware). Open SCADA systems must supply functionality for a variety of hardware types; proprietary SCADA systems must supply functionality for a single hardware type or family. Alarming: This is the ability to create logic to interpret conditions as problems requiring automated or human intervention. Alarming can consist of notification only or of actuating some solution to the problem. Trending: This is the ability to graphically depict variables as a function of time, typically in a value vs. time line plot. Trending can be real-time (depicting data up to the present and continuously self-updating) or historical (depicting data from a user-selected time window). Reports: This is the ability to automatically generate reports based on collected data, either locally for viewing by the operator or archived for access through another application such as a Web browser. SC1-T1-1

2 Display: This is the ability to display data to the user, often in a graphical format. Components of the display may be animated or vary their appearance dynamically depending on real-world conditions (such as the liquid level of a tank being depicted as a tank icon partially colored with a fraction equal to the tank level). 1.3 Development Schemes Finished SCADA applications as deployed for end users are developed by either automation contractors or developers at the end user location. These applications are developed using tools provided by COTS SCADA vendors. The developers purchase the SCADA development tools from the vendors, and then also purchase individual run-time licenses for each application deployed. Application run-time licenses are typically sold on a scale proportional to the size of the application; thus a license for an application requiring 10,000 tags is likely to be more costly than a license for an application requiring 100 tags. In addition, maintenance fees on a per-application basis are usually required to ensure technical support, version updates, etc. In summary the cost of using COTS software can be quite high, especially as the number of applications in an enterprise increases. 1.4 Other Development Considerations The functionality provided with COTS SCADA development software is typically provided as is, with needed functionality bundled with superfluous functionality, where needed and superfluous depend on the individual organization. Functionality that is needed but not provided by a COTS SCADA development package must be built or purchased elsewhere and integrated with the original software. These concerns about COTS software are not unique to SCADA software; [2] describes these problems and others, including risk if the vendor drops the product or support for the product, and quality shortcomings with the vendor software. Also [3] observes that although custom software is often unattractive because of long development costs, some lessons learned though empirical findings include: the cost to maintain COTS software equals or exceeds that of developing custom software, and software engineers must spend significant time and effort up front to analyze the impact of version updates (even when the decision is made not to incorporate the updates). 2. THE CUSTOM SOFTWARE OPTION 2.1 Justification As an alternative to the standard COTS SCADA development approach, custom SCADA development tools created by the end user could be considered. Custom software in this milieu is not unprecedented; [4] describe the design and realization of a component-based application framework to develop Manufacturing Execution Systems (MES), where MES software occupies a niche between SCADA software and enterpriseresource-planning (ERP) software. Custom SCADA development tools are obviously not appropriate for every organization given the sheer size of the engineering task associated therewith. However for large enterprises with substantial internal software development resources, or for enterprises willing to purchase external software developing capability, custom SCADA development tools may be a feasible and even preferable alternative to COTS development tools. Some reasons why custom software could be preferable include: 1. The overall long-term cost may be lower if the enterprise has a large number of SCADA applications that would require licensing if developed with COTS packages. 2. The organization has control over version upgrades to the software. 3. The organization has a better understanding of the software construction. 4. The organization has control over the quality of the SCADA development package and can choose which aspects of quality should be emphasized. It is the last point, that of being able to choose which areas of quality to emphasize, that is examined in the rest of this paper. 2.2 Quality Considerations The decision to implement a custom SCADA development package implies that sufficient attention must be paid to quality considerations. As described in ISO [5], this includes internal quality (the totality of characteristics of the software product from an internal view), external quality (the totality of characteristics of the software product from an internal view), and quality in use (the user s view of the quality of the software product when it is used in a specific environment and a specific context of use). Furthermore, the model for internal and external quality can be divided into the broad categories of functionality, reliability, usability, efficiency, maintainability, and portability. 2.3 Functionality Considerations While all of these categories should be considered, the scope of this paper is limited to the category of functionality. Functionality is further divided into five subcategories: suitability, accuracy, interoperability, security, and functionality compliance. These subcategories are explained below, as they would pertain to custom SCADA development software. Suitability is described in ISO as the capability of the software product to provide an appropriate set of functions for specified tasks and user objectives. The set of functions necessary for SCADA development software would include the key components described above, including input/output, trending, alarming, etc. Accuracy is described in ISO as the capability of the software product to provide the right or agreed results or effects with the needed degree of precision. Accuracy with regards to SCADA systems could include numeric or temporal precision. Numeric precision would be the ability to provide data with the required number of significant figures, within the required tolerance of real-world values, etc. Temporal precision would be the ability to read, write, or process data within an allowable amount of time. Accuracy requirements will vary by industry or application; a SCADA system for manufacturing inexpensive products will probably have different accuracy requirements from one controlling a nuclear power plant. Interoperability is described in ISO as the capability of the software product to interact with one or more specified systems. There are two main aspects of interoperability that should be SC1-T1-2

3 considered with respect to SCADA systems. First is interoperability with regards to computer operating systems such as Microsoft Windows (and its various versions), Unix, Linux, etc. Second is interoperability with regards to various types and whether the SCADA software can interact with various standardized (Ethernet, Profibus, etc.) or proprietary plant communications networks. Security is described in ISO as the capability of the software product to protect information and data so that unauthorized persons or systems cannot read or modify them and authorized persons or systems are not denied access to them. Typically the security features provided by SCADA software involve password protected user accounts where functionality such as maintenance screens can be limited. Other security functionality may be present in the SCADA system but may be supplied by the underlying operating system. Functionality compliance is described in ISO as the capability of the software product to adhere to standards, conventions or regulations in laws and similar prescriptions relating to functionality. Although SCADA software may be used to fulfill government regulations (such as monitoring and recording of pollutant emissions) there are no known government regulations regarding functionality of SCADA systems. Each category and aspect of quality of functionality will have a different level of importance for different organizations. It is critical for an organization to understand which functionality aspects will be required for custom SCADA development, first to decide whether to take on the commitment to produce the required artifacts, and second to ensure success for this project. If an organization already has an established SCADA application base, then that base could be mined for indication of critical functionalities to that organization. A study to determine the critical functionalities of a particular organization is described below. 3. METHODOLOGY OF STUDY A study of an organization s existing SCADA base was conducted to determine what functionality aspects were being used and consequently should be considered if the organization decides to create custom SCADA development software. The organization s existing SCADA base consisted of 25 applications, ranging from the smallest application of 230 tags to the largest of 2651 tags. These applications were developed using a single vendor s COTS SCADA development package. Eighteen of the applications were developed internally by the organization; seven of the applications were developed externally and delivered as part of turnkey projects. These applications are representative of the organization s entire breadth of processes. A list of 13 functionality aspects was considered. These aspects are common functionalities typically bundled with COTS SCADA development software. This list was derived from the literature as well as from the features offered by the specific vendor. The first 9 functionality aspects (input/output, alarming, trending, animated graphics, recipe management, database access, reporting, statistical process control [SPC] and password protection) were considered separately for each particular application. The last 4 functionality aspects (flexibility across all operating systems, flexibility across Microsoft Windows operating systems, flexibility between manufacturers, flexibility between communications networks), which were all aspects of interoperability, were considered across the entire SCADA base, since interoperability is not meaningful when applied to a single application. For each application and each functionality aspect, a Boolean test Table 1: Functionality Decision Criteria Functionality Aspect ISO Subcategory Decision criteria Input/Output Suitability Does the application exchange data with an? Alarming Suitability Are any tags in the application configured for automatic alarming? Trending Suitability Are there any real-time or historical trending displays included in the Animated Graphics Suitability Is the appearance of any graphics programmed to vary depending on real-world conditions? Recipe Management Suitability Is the recipe manager utility provided by the vendor used to save or load tag values? Database Read/Write Access Suitability Are data read from or written to an external database? Reporting Suitability Are human-readable reports automatically generated by the SPC Suitability Is the SPC utility provided by the vendor used to analyze data? Password Protection Security Are there multiple password-protected user accounts configured in the Operating System (all) Interoperability Does the existing SCADA base include applications running on more than one vendor s operating system? Operating System (MS Windows) Interoperability Does the existing SCADA base include applications running on more than one Microsoft Windows version? Interoperability Does the existing SCADA base include applications communicating with more than one type of? Network Interoperability Does the existing SCADA base include applications incorporating more than one communications network? SC1-T1-3

4 of present or not present was applied. The decision criteria for each functionality aspect are listed above in Table RESULTS OF STUDY 4.1 Definitions Before discussing the results, several terms should be defined. They are: N T : the total number of applications examined N(x): the total number of applications that incorporate functionality x Tags(n): the total number of tags in application n Tags(total): the total number of tags in all applications = NT n= 1 tags( n) Tags(x): the total number of tags in all applications that incorporate functionality x 4.2 Suitability and Security For each aspect x of suitability and security functionality, two ratios were calculated. First, an absolute ratio of N(x)/N T was calculated to show the pervasiveness of a particular functionality in the organization s application base. Second, a tag-weighted ratio of tags(x)/tags(total) was calculated to analyze whether functionality requirements were skewed by very small or very large applications. Results are shown in Table 2 below. Table 2: Suitability and Security Results Functionality Aspect Absolute Ratio Tag Ratio Input/Output Alarming Trending Animated Graphics Recipe Management Database Read/Write Access Reporting SPC 0.04 Password Protection Interoperability For each aspect x of interoperability functionality, the entire application base was considered, and an absolute ratio and tag ratio was calculated for each possible condition. The conditions and ratios for each are listed below in Table 3. The absolute and tag ratios for all conditions should add to 1.00; some do not due to rounding errors. Functionality Aspect Operating System (all) Operating System (MS Windows) (cont.) (cont.) Network Table 3: Interoperability Results Microsoft Windows * / 1.00/ 1.00 Windows NT/ 0.12/ 0.07 ** 5/03/ FlexLogix/ PLC-5/ 0.08/ 0.06 RS-232/ 0.04 Other OS/ 0.00/ 0.00 Windows 2000/ 0.72/ /04/ 0.36/ 0.34 CompactLogix/ DataHighway+/ 0.44/ Windows XP/ 0.16/ /05/ ControlLogix/ 0.12/ 0.17 Ethernet/ 0.52/ DISCUSSION OF RESULTS The results indicate which aspects of functionality in SCADA software are important to this organization. We can draw the following conclusions from the results presented. 1. There does not appear to be any skew as a result of large or small applications. In each functionality case the absolute and tag ratios are quite close, and in no case is there a difference of more than 13%. 2. Automated reporting, integrated SPC, and interoperability between Microsoft and non- Microsoft operating systems are not important to this organization. 3. Several functionality aspects are definitely important to this organization, including: input/output, alarming, trending, animated graphics, password protection, flexibility, and network flexibility. 4. Some functionality aspects appear to be moderately important to this organization, including: recipe management, database access, * Microsoft, Windows, Windows NT, Windows 2000, and Windows XP are registered trademarks or trademarks of Microsoft Corporation. ** stands for Allen-Bradley. Allen-Bradley, 5/03, 5/04, 5/05, FlexLogix, CompactLogix, ControlLogix, PLC-5, and DataHighway+ are trademarks of Rockwell Automation, Inc. SC1-T1-4

5 and operating system flexibility among Windows operating systems. An organization must decide on a strategy for incorporating the results of such a survey into its functionality requirements for custom SCADA development software. Strategies might include: omission of superfluous functionality from the software inclusion of critical functionality in the core of the software inclusion of moderately important functionality in the core of the software, or use of third-party software for these features as needed Although the results show what functionality is required of custom SCADA development software for a particular organization, it is not comprehensive. There are several reasons why additional functionality may be required in custom software particular to an organization even if it is unused in the existing SCADA base. One case is that there may be functionality that is not offered by the organization s COTS SCADA package. This functionality could be generic and applicable to many organizations or specific to a particular organization. A generic functionality might be interaction with common enterprise-resource-planning (ERP) software, a functionality typically not found in COTS SCADA software (because it is accomplished by other software packages). A specific functionality might be predictive modeling software for an organization s process or equipment, incorporating company-specific algorithms to improve performance. If functionalities like these are required in existing processes, then they are likely provided by software external to the SCADA package, and should be considered when deciding the scope of a custom SCADA development system. A second case is that there may be functionality that is offered by the organization s COTS SCADA package, but the functionality exhibits defects in usability, reliability, maintainability, or other quality aspects. A trending graph may be a useful functionality in a SCADA package, yet if the implementation of the trending functionality in practice is difficult to configure, offers poor choices for display options, or frequently causes the system to crash, it is unlikely to be used. However, a mitigating factor in this case is the fact that organizations are free to choose among COTS SCADA packages from many vendors, and it would seem unlikely that organizations would willingly choose a package exhibiting serious defects in the very aspects critical to their applications. A third case is that the existing SCADA application base for an organization is not representative of that organization s future needs. This could happen if the organization diversifies into other types of processes, or because there are existing processes in certain areas of the company that are still using technologies older than SCADA. To be effective as a study tool, an existing SCADA application base should of course be a good representation of present and future needs. Major planned changes or additions to the organization s existing process or equipment portfolio should be considered in addition to the results of an application base study. 6. CONCLUSIONS AND FUTURE WORK The conclusions of this paper are as follows: 1. Custom SCADA development software manufactured by organizations for their own use may be a viable alternative to COTS SCADA development packages. 2. The quality requirements of custom SCADA development software should be considered when deciding whether this alternative should be pursued. The ISO quality model is one tool that can be used to define the quality requirements. 3. The construction of functionality requirements for custom SCADA development software can use an existing SCADA application base to determine critical functionality considerations. A survey of suitability, security, and interoperability functionality in an existing application base, such as the one presented here, can be used to enumerate the importance of including various functionality aspects in a custom development package. One area of future work that should be considered is expanding the approach of studying an existing SCADA application base to other aspects of quality, such as reliability, usability, and maintainability. A survey-based approach such as was presented in this paper may not be appropriate for these other aspects of quality. 7. REFERENCES [1] Bailey, D., and Wright, E. Practical SCADA for Industry. Elsevier Press, Oxford, England, [2] Voas, J. COTS Software: The Economical Choice? IEEE Software, 15, 2 (March 1998), [3] Reifer, D., Basili, V., Boehm, B., and Clark, B. Eight Lessons Learned during COTS Based Systems Maintenance. IEEE Software, 20, 5 (September 2003), [4] Furicht, R., Prahofer, H., Hofinger, T., and Altmann, J. A Component-Based Application Framework for Manufacturing Execution Systems in C# and.net. In Proceedings of the 40 th International Conference on Technology of Object-Oriented Languages and Systems (Sydney, Australia, 2002). Australian Computer Society, Inc., Darlinghurst, Australia, 2002, [5] ISO/IEC Software Engineering-Product Quality-Part 1: Quality Model. International Organisation for Standardization, Geneva, Switzerland, SC1-T1-5