You're probably aware of the important role that supervisory control and data acquisition (SCADA) software plays in managing automation systems used by water or power utilities, national broadcasters or scientists. You’re also likely aware of the role custom coding plays when configuring these applications for users. However, you may be less aware of the ongoing price of each line of code that, if not carefully managed, can reduce performance, reliability, and longevity of critical SCADA systems.
Control Amplified talked with Chris Little, media relations director for Trihedral Engineering Limited, to find out how systems integrators and in-house developers can create advanced SCADA solutions that aren’t limited by rapidly aging code.
Transcript
Len Vermillion: Why is custom code standard practice when configuring most SCADA applications?
Chris Little: For many SCADA software platforms, it’s the primary mode of configuration. It's what holds together the combination of proprietary or third-party components that provide the standard SCADA functionality that operators and managers need. Basic things like trending reports, remote access and hot backup failover usually need some form of hand coding to work. To be fair, many integrators like doing it this way because they’re very good at it.
Len Vermillion: What are some of the hidden costs of this practice?
Chris Little: There are several, but they're all different variations on technical debt, which is the cost of future work that would be required when you choose a solution that’s easier in the short term. By writing custom code, you're creating work for yourself in the future. SCADA systems involve so much money, time and decision-making that, once you've got one in place, you don't want to turn the hourglass over and start again from scratch.
The more technical debt you incur by writing custom code, the more work you make for yourself going forward.
Len Vermillion: What’s the limitation of custom code, especially if everyone likes doing it?
Chris Little: For one, it ages badly. One of the keys to longevity for a SCADA system is the ability to regularly update the software, so you can take advantage of new features and security fixes. Many system integrators insist that, once a system is working, you should never upgrade it or the operating system it runs on. They're afraid to upgrade to a version with an important fix in it because they're afraid it will possibly break their custom code. This is why you get old, increasingly limited systems running on machines with unsupported and insecure operating systems. This can affect the scalability of your system, so it becomes a source of risk.
When an integrator needs to go back and service, troubleshoot or add to the application, it’s frustrating to look at someone else's code from 10 years ago, or even their own. People's best practices change. They get better and learn different ways of writing code. So, even if they've documented their code as they should, it can still be challenging to build reliably onto that base without breaking anything.
Len Vermillion: What’s the alternative?
Chris Little: Look at built-in features out of the box. If you have a system where every piece of core functionality is installed up front with one installer, and gets upgraded with every new version, you avoid this risk. You also reduce the configuration time for each application.
Len Vermillion: Does this make a big difference to the application's resilience?
Chris Little: Absolutely. Let's assume you have talented integrators, who have coded server failover dozens of times, and they're able to cut-and-paste the best version of that redundancy code each time they do a new system. It means the stability and security of the code they wrote has been tested, at most, a few dozen times, and was tested over however long those systems existed.
By making redundancy core to the SCADA product, the code not only goes through an extensive product development lifecycle, but also internal and personal testing. The way we do it with our VTScada software is, when there’s a new unreleased version, everyone in our company uses it because we want to find the things that go wrong before anyone else does. We have powerful automated tests that we pound on each version, and this goes on for weeks before we let anyone touch it.
Because they’re part of the core product, the standard features installed with VTScada are battle-hardened and have been running in the field for decades. Everybody gets to take advantage of what we've learned from every system. You can’t do that with custom code.
Len Vermillion: By which standard is VTScada's development measured?
Chris Little: A few years ago, VTScada’s development environment was certified as compliant with IEC's 62443-4-1, maturity level 2, “Security for industrial automation and control systems.” This is the standard that defines the secure development lifecycle requirements for products used in industrial automation and control systems.
Len Vermillion: To be clear, you're not saying all custom code is bad, right?
Chris Little: Correct, and that's a great point. Every application has something about it that’s unique, some challenge, some opportunity that’s different than every other system. A chance for an integrator to do something really special that will improve the quality of work for that user. This is where custom codes come in.
Len Vermillion: Why should integrators use a built-in approach?
Chris Little: You can do more in less time. There’s always pressure to get a lot of things done in a limited period of time. With VTScada's built-in features, most of these functions are built-in out of the box. You can set up two, three, four levels of server redundancy distributed across a wide area network (WAN) without writing any code.
Integrators can also support it more easily over time. VTScada has built a variety of ways to remotely support users without traveling to their sites. Many integrators can support it without having to travel 100 miles in the winter to open that client’s computer. They can do it by becoming a secure node on the Internet. They can pass VTScada ChangeSet files back and forth, which contain complete copies of the entire application, including built-in version control.
