Perfect Abstractions
  • Home
  • Contact
  • Blog
  • Home
  • Contact
  • Blog

A Software Framework for SCADA Applications

9/2/2014

6 Comments

 
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.
Picture
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.
6 Comments
Iain Mitchell
9/4/2014 12:29:48 am

You did mention communication with PLCs but going further, it would be nice if the SCADA - the high level interface - could communicate with the PLC at register level so that varieties of applications are not required to set up and deliver data. The SCADA should be able to sit right on top of the PLC and virtually read the inputs in the simplest systems and virtually control the outputs if that was required and interrogate the PLC control program as well. We, the users have a number of real world switches and values and there seems to be an extremely complex set of levels necessary to get these to appear as graphics

Reply
Nick Mudge
9/4/2014 07:07:57 am

Yes, thank you for this.

Reply
Dries Boone link
9/4/2014 10:04:42 pm

As a Sales Engineer for a process measurement systems company, filling the gap between PLC data and a scada system is a much heard functionality request. Therefor all signals measured by our system are available on OPC.

This means that all signals, coming from a variety of PLC types and interfaces are automatically available on OPC for SCADA systems.

Also we include a software that enables to construct a custom-made HMI interface.

Reply
Johan link
7/28/2015 08:06:57 pm

A few days ago, I came across this framework to build home-made SCADA: http://www.objectis-software.com/product/concept-hmi/.

Don't really get how it works but there are severals features.

Hope it helps :)

Reply
SCADA HMI Software link
6/20/2016 11:13:48 pm

Thanks for sharing it's really helpful.

Reply
SCADA HMI Software link
6/23/2016 03:27:18 am

SCADA HMI Software System designed specifically to improve efficiency and increase the value of manufacturing equipment.

Reply



Leave a Reply.

    Author

    Nick Mudge
    Ignition Software Consultant
    nick@perfectabstractions.com
    916.234.6521

    See our blogs here http://blog.perfectabstractions.com
    nickmudge.info.

    Links

    Nick Mudge's Weblog
    Computing Without Boundaries

    Archives

    March 2017
    November 2016
    September 2015
    August 2015
    January 2015
    September 2014
    August 2014
    July 2014

    Categories

    All
    Applets
    Chat
    Debugging
    Fonts
    Gateway Scripting
    Ignition
    Ignition 7.7
    Ignition Modules
    Ignition Scripting
    Ignition Templates
    Java
    Jython
    Kepware
    Linux
    Logging
    OPC
    OPC UA
    OPC-UA
    Python
    RSS
    SCADA
    Security
    Software Abstraction
    Support
    Testing
    Water
    Weather
    Weather Radar
    Windows

    RSS Feed

    Join My Mailing List

    • Get email updates about news, blog posts, articles, product offers and other items of interest.

    • subscribed: 0
    • I respect your privacy
    • Email Marketingby GetResponse
© Perfect Abstractions LLC