AutomationEngineeringFeaturesIndustry 4.0Opinion

Is SCADA the right tech for the future?

The truism “Jack of all trades, master of none” applies across many disciplines, and industrial software is no exception. The industrial Internet of Things (IIoT) has expanded the function of many pieces of software. But are SCADA systems biting off more than they can chew? Here, Sean Robinson, UK service leader at industrial software specialist Novotek UK and Ireland, discusses the issues that come with both approaches and suggests where a balance should be struck.

Data-driven industrial sites have settled into three distinct groups regarding data manipulation and handling. The first have fully embraced wireless interconnectivity and cloud-computing, and therefore handle all their data with analytics and other web-based databasing tools. 

The second have adhered to the ‘if it isn’t broken, don’t fix it’ adage, and have taken their SCADA system and expanded its functions. Their SCADA systems handle it all, from process logic to web reporting and even historian functions.

The third group fit somewhere in between. These businesses have retained the SCADA systems they have relied on for decades, but they have also applied piecemeal upgrades, such as cloud-computing, where possible and applicable.

Of these three approaches, each has its own distinct advantages and disadvantages.

Internet problems equal manufacturing problems

The first approach seems very attractive at first glance. Exporting data wirelessly to data-farms curtails many of the restrictions associated with industrial data collection. 

Adding new equipment, or even entire sites, into these flexible cloud-based systems is as easy as hooking up a WiFi signal and aiming the data at the correct server with no extra equipment or wiring required. These setups also make remote monitoring possible for engineers anywhere around the world, vastly streamlining troubleshooting and support. However, it’s when exceptions occur that problems rear their heads. 

By funnelling every bit and byte through the internet, you’re entirely at the mercy of your service provider. In the entirely likely event that internet connection is lost then any data-driven process must stop. 

If dropped connections are planned for in advance, then process equipment can be made to return to safe configurations with local backup logic, but for particularly data-intensive processes, such as CAD laser cutting controls or machine-vision systems, even a half-second blip can wreak havoc.

So, while this approach may be cost-effective, highly flexible and offer unmatched access, you’re effectively taking your process control and handing it off to anonymous middlemen, who may have zero knowledge or understanding of your specific process needs.

SCADA as a one-man band?

At the other end of the scale, other industries have kept their SCADA systems online, and have built on and enhanced them to expand their remit far beyond typical SCADA features.

This patchwork approach is again quite attractive and leans into the strengths of software/firmware ecosystems in that they can easily be patched and updated. Seeing as all the data moves through the SCADA anyway, appending historian, web-monitoring, genealogy tracking and other data-driven features seems perfectly logical.

It’s not all plain sailing, however. Over years of incremental upgrades, SCADA systems can easily turn into the software equivalent of Frankenstein’s monster, with a tacked-on historian section here, a SQL log function co-opted from elsewhere there, and so on. 

When SCADA systems are built up in this way, they become almost impossible to troubleshoot or source support for as every company operating this way will naturally develop its own unique setup. This puts a lot of responsibility on individual software engineers who understand the subtleties of a certain system, meaning in the event those engineers are unavailable, if they’re ill or have retired for instance, nobody else knows where to start when troubleshooting a problem. 

In the worst instances, modern software may have to work alongside completely obsolete, decades-old systems. A chain is only as strong as its weakest link, so this approach severely limits operational efficiency while software old enough to drink catches up.

Lastly, with so many interlinked and interdependent systems all working and communicating back and forth under the same hood, an exception in one area can quickly turn into a complete system failure. An error in one area of the software can quickly be distributed around, causing exceptions to fly, variables to overflow and logging data to be garbled.

If it looks like a SCADA…

As you may be able to guess, the third approach described above is the one to take. Namely maintaining an up to date SCADA system and bringing in discretised additional software when required.

The key to making this work is making data interoperable between systems. This is achieved through GE’s model-based development (MBD), of which Novotek is the sole supplier across the UK and Ireland. Here, common data formats are standardised across sites and systems. Doing so completely dodges the problems of the methods described above while retaining the advantages.

When the SCADA system, historian and other functions all operate using the same signed variables, each function can be kept in its own environment and simply called through software when needed. 

This keeps the software as lean and efficient as possible, but with none of the compromises to operational flexibility normally associated with discretised software because any additional functions can be easily added thanks to the shared data formats. It also means that if one area encounters a problem, the other software is unaffected.

MBD standardised variables mean that software operates where it is specifically designed for. By keeping SCADA functions within the SCADA, historian functions within the historian, and so on, and ensuring that data can be passed freely between systems, you can achieve the best of both worlds.

This article originally appears in the January/February issue of Industrial News.