Whether you can’t find a pre-built SCADA package that suits your needs or you simply want to build it yourself to ensure future customizability, the build-your-own SCADA path is still an option today. But the checklist of to-do items has certainly grown a lot longer with the need for interoperability, real-time readouts, and remote access.
Nick Mudge, a software consultant at Perfect Abstractions and certified Inductive Automation SCADA integrator, says that the first steps in the process of building your own SCADA involve establishing the communications and data framework for the system.
According to Mudge, the following functionality should be viewed as extremely useful for your self-built SCADA system, if not required:
* Ability to talk to devices and PLCs and/or useOPC-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 logtime seriesdata to a database for later graphing and analysis—essentially, 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 useSOAP Web Servicesprovided 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 useHTTP-based REST (representational state transfer) APIs (application programming interfaces)provided by external applications.This enables SCADA applications to send information requests to external applications and receive responses.
* Full support for sending and receiving email, including attachments.
* Ways for applications built using the SCADA framework to communicate with each other.
Of course, you’ll also need a way to analyze, evaluate and take action based on the SCADA data. Mudge notes that “support for a scripting or programming language would be useful for creating algorithms to analyze, evaluate, and react to data.Pre-built tools could be configured to receive data, process it and take action.”
See, I told you the list for creating SCADA software is quite long with all the modern SCADA requirements. But we’re just getting started.
Architecture
Mudge contends that the best architecture for a SCADA framework is a client-server architecture.
“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,” he says. “Users download client applications from the server. Client applications communicate with the server software to get data from databases, PLCs, etc.”
Mudge goes on to explain that 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 easily modified and updated over a computer network. It also 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,” he says. “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.”
He also stresses 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.”
Also, don’t forget that there should be an easy way to upgrade the SCADA framework 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,” he says. “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
Once you have your framework established, it’s time to create applications. Here are some tools and functionality Mudge says are useful:
* Use pre-built GUI components or widgets for creating client applications.Mudge suggests to save time by using pre-built functionality instead of developing GUI components from scratch.“More specifically it would be useful if pre-built GUI components and functionality existed for creatingHMIscreens, informationdashboardsandbusiness process workflows,” he says. Examples of pre-built, customizable components include: text fields, labels, buttons, dropdown menus, documents, tables, charts, state indicators, date selectors, alarms, forms, reports.
* 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 applicationsthat 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 datathat is used for debugging and understanding applications.
* Revision control—the ability to see past changes that have been made to applications and revert applications to earlier states.
* Ways to make backups of applications and important configuration information.
Security
SCADA applications, like any other industrial control system application, need to be secure. Mudge recommends the following security capabilities for a DIY SCADA system:
* Option for usingTSL/SSLfor 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 signingtechnology 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.
Even more details about DIY SCADA, addressing all that’s covered above as well as licensing, alarms, and support issues are covered in a checklist developed by Mudge that can be accessed here.
As cool as DIY SCADA could be, I have to admit that this is a pretty daunting list. Personally, I would just buy an existing SCADA system. However, I know the DIY itch is one that just has to be scratched at times. And if DIY SCADA is in your ballpark, this a good place to start.
