A Software Framework for SCADA Applications

So you want a SCADA software application.

You look around for existing solutions that would be a good fit. 

Search the web, ask your friends, ask other people.

You may not find a pre-built solution that meets your needs exactly. Maybe nothing you find meets your needs very well. It is kind of hard because there are an unlimited number of SCADA applications possible.

Perhaps what you need is a framework for building SCADA applications. A set of general tools and pre-built functionality that you can customize and use to create the applications that you need.

The rest of this article explores general tools and capabilities that would be useful in a SCADA framework. An ideal SCADA framework would have all the listed tools, functionality and support.

A checklist for evaluating SCADA frameworks is available at the end of this article.

Communication and Data

It would be useful for a SCADA framework to provide lots of ways to get and send data. The following functionality would be useful:

Ability to talk to devices and PLCs and/or use OPC-UA. This is needed for real-time monitoring and control of equipment.

A sub-framework for use by third-party developers to implement communication protocols that are not provided by the framework.

Built-in support for connecting to and using common SQL databases, such as MySQL, SQL Server, Oracle and PostreSQL. A sub-framework for implementing connections to other databases or kinds of databases.

A way to log time series data to a database for later graphing and analysis. This is a data historian.

A distributed data historian, which is a data historian with the ability to read and write data across multiple physical machines.

A way to forward data being collected from a remote location to another location or central server.

Ability to access and use SOAP Web Services provided by external applications. This enables SCADA applications to send information requests to external applications and receive responses.

Ability to create SOAP Web Services that can be accessed and used by external applications. This enables SCADA applications to receive information requests from external applications and send responses.

Ability to access and use HTTP-based REST APIs provided by external applications. This enables SCADA applications to send information requests to external applications and receive responses.

Ability to create HTTP-based REST APIs that can be accessed and used by external applications. This enables SCADA applications to receive information requests from external applications and send responses.

Full support for sending and receiving email, including attachments.

Ways for applications built using the SCADA framework to communicate with each other.

Analyze, Evaluate and Take Action Based on Data

It would be useful for a SCADA framework to provide ways to analyze, evaluate and take action based on data. This functionality can be used for process control - automatically adjusting, handling and running processes.

Support for a scripting or programming language would be useful for creating algorithms to analyze, evaluate and take action based on data.

Pre-built tools could be configured to receive data, process it and take action.

Architecture

A client-server architecture is the best architecture that I know of for a SCADA framework.

The SCADA framework has server software. Server software is configured to connect to databases, PLCs, devices and other sources of data. Client applications are developed and then stored on the server computer where the server software can access them. Users download client applications from the server. Client applications communicate with the server software to get data from databases, PLCs etc.

Client-Server Architecture

Changes made to client applications are uploaded to the server and the server software sends updates to all computers that have client applications installed. This allows client applications to be modified and updated easily over a computer network. This eliminates having to physically run around and manually update each computer that has a client application installed.

The SCADA framework should also allow server-side only programs or applications to be developed. It makes sense to perform some functionality and activities on the server and not in clients. Activities such as logging data from PLCs, time-based activities, emailing reports and other actions are best done on the server.

Functionality could exist for separating, organizing, monitoring and managing client and server applications that are created using the SCADA framework.

Ways could also exist for managing and enabling communication between multiple instances of the server software.

Support for redundancy. A client application could be configured so that if it lost its network connection to its server then it could automatically connect to a different server on a different network or connect to a server locally on the same machine as the client application.

An easy way to upgrade the SCADA framework is needed for when new versions of the software are released.

Ideally the SCADA framework and applications built with it could run on many devices and operating systems, including mobile devices.

A key part of a SCADA framework is making it extensible. It should provide a way for people to create new tools and functionality and add them to the SCADA framework.

Creating Applications

A SCADA framework could provide software libraries and/or a development environment and other tools for quickly creating and testing applications. Here are some tools and functionality that would be useful:

Pre-built GUI components or widgets for creating client applications. The idea is to save time by using pre-built functionality instead of developing GUI components from scratch. Such components would need to be very flexible so they could be customized and used in many ways.

More specifically it would be useful if pre-built GUI components and functionality existed for creating HMI screens, information dashboards and business process workflows. Here are some examples of pre-built, customizable components that could exist: text fields, labels, buttons, dropdown menus, documents, tables, charts, state indicators, date selectors, alarms, forms, reports. Many more could exist.

Support for creating, displaying and using PDF reports and reports in other document formats.

A scripting or programming language for creating new components, functionality, customizing components and connecting data between different parts of an application.

Ways to reuse functionality or code inside a single application and across multiple applications.

Example applications and/or template applications. It would save time and provide consistency to build applications off of existing example applications or empty template applications that use common strategies and common application structure.

Drawing tools.

Sets of images, art and icons that can be used in applications.

Ability to use images and drawings that have been created outside the SCADA framework.

Ability to run and test applications before deploying or making them live.

Debugging tools. Ways to log errors and other data that is used for debugging and understanding applications.

Ability to see past changes that have been made to applications and revert applications to earlier states. This is revision control.

Ways to make backups of applications and important configuration information.

Alarms

It would be very useful for a SCADA framework to provide built-in functionality and tools for creating and handling alarms in applications.

It would also be useful to have tools for notifying people about alarms through email, phone calls and SMS texts.

Security

SCADA applications need to be secure. A SCADA framework could provide a variety of security options for SCADA applications. Here could be some useful security capabilities:

Option for using TSL/SSL for encrypting data sent over computer networks.

Built-in functionality for user authentication and assigning permissions to users. Permissions for parts of client applications, permissions for accessing data, permissions for accessing parts of the server software and server applications.

Ability to tie into and use existing authentication and user account systems such as Active Directory.

Logging user actions to a database. General logging of anything important that occurs.

A way to be notified of security updates about the SCADA framework.

Code signing technology to verify that any upgrades, new tools or functionality added to the SCADA framework come from a correct source and have not been tampered with or corrupted.

Licensing

It would be useful if a SCADA framework provided the following licensing functionality and capability:

A way to purchase licenses for different parts and tools of the SCADA framework. This way people can purchase just what they need.

An easy way to view and manage licenses and install and uninstall them.

Licenses should be reasonably priced and arranged in such a way that as SCADA systems grow, the licensing scales with the systems and does not become too costly to become prohibitive.

Site or corporate licensing options could be useful.

Support

It would be useful for a community and/or company to be actively supporting a SCADA framework and improving it over time. Here are important ways it could be supported:

Good tech support options.

Good ways to learn about the SCADA framework.

Confidence that the SCADA framework will not be abandoned or given lower priority in the future.

Active development by a stable technical team. New features and improvements are added to the SCADA framework based on what people are asking for.

Continuous effort on the development team to find and fix bugs that are found and to generally improve the software, and help people who are using the software.

SCADA Framework Checklist

I compiled a list of all the items in this article and created a SCADA Framework Checklist document that can be used for evaluating SCADA frameworks. Download checklist here.

What am I Missing?

Now it is your turn. What am I missing that should be added to this list? What does an ideal SCADA framework consist of?

Thanks to Chris Powell, Jason Hamlin and Lionel MAZEYRAT from the Ignition Chat Group for input and suggestions for this article.