Are Microsoft technologies still best for process control systems?
Engineering and IT Insight: Process control architects and designers are questioning the 15-year wisdom that you cannot go wrong by picking the Microsoft environment for a process control system. See 6 critical requirements for process controls.
Use of Microsoft technologies is creating growing concerns among senior designers and senior architects in control system suppliers. Microsoft technology is widely used as the underlying basis for process control systems, such as supervisory control and data acquisition (SCADA), human machine interface (HMI), distributed control system (DCS) displays, historians, manufacturing execution systems (MES), and batch execution systems. Since 1998, when Microsoft Windows 98 was released, the Microsoft Windows platform has been the de facto standard for most control system suppliers. Below, see six critical requirements for process control systems.
While the hard real-time control systems, such as PLCs and embedded DCS controllers, have not moved to a Microsoft environment, almost all other parts of process control systems have moved to Microsoft Windows servers, MS-SQL databases, and Windows desktop operating systems. Most suppliers have followed the "every other release" strategy, skipping Microsoft Windows ME (2000), using Windows XP (2001), skipping Windows Vista (2007), using Windows 7 (2009), and many are now looking at skipping Windows 8.
For the past two decades consumer software has been the driving force in operating system and user interface in manufacturing systems. Control system suppliers have applied consumer technologies as they have become reliable enough for industrial applications. However, today is a different situation. This is a period of intense change in consumer products with tablets and smartphones replacing laptops, laptops replacing desktop systems, and new user interface models and services under continual change. Continual change is not what control systems need. Many control systems have lifetimes of 20 to 30 years. Some of the systems developed using the 1980-1990 VAX/VMS technology from Digital Equipment Corp. are only now being replaced. The concern among architects and designers is that the consumer software may not stabilize for many years and the cost of trying to apply the software to manufacturing is starting to exceed the benefits. The current consumer infrastructures are so complex that there are usually multiple security and safety updates per month. Many process control suppliers are spending more development budget on testing, validation, and distribution of patches than they are spending on new development. Additionally, no one expects this situation to get any better. In fact, it may get worse as infrastructure complexity continues to increase.
When major changes happen in the user interface, many manufacturing companies are looking at the cost to completely retrain their operations workforce to a system with at best a 5-year lifetime, with no measurable benefit over the existing system and a great opportunity for mistakes and errors that can stop production and risk plant safety. In particular, Microsoft Windows 8 provides the same interface on a 3-in. phone as on a 27-in. monitor, significantly reducing the usefulness of an HMI in high-information content tasks. Yet this is the situation control system vendors face when trying to keep up with the consumer changes.
Consumer oriented operating systems also always want to call home to the vendor and perform an auto update. This can occur even if auto update is turned off, because we all know consumers won't update critical patches if left on their own. However, this behavior is the opposite for manufacturing, which requires stability, safety, and validation of patches. There are too many examples of patches causing operational problems, or just being wrong, to allow systems to patch themselves without human intervention.
These issues are causing architects and designers to question the 15-year wisdom that you cannot go wrong by picking the Microsoft environment for your process control system.
6 critical process control needs
Process control vendors require:
- A system with a minimal attack surface, so that biweekly or monthly patches are not required
- A consistent programming interface that will not change every four to five years, requiring a complete rewrite of their software
- An environment that can be quickly and safely "locked down" to reduce the risk from hacking
- A system with limited network access, only through specific ports to reduce the risk of network based attacks
- Support for priority-based multi-tasking, preferably a real-time operating system (RTOS) that supports hard real-time requirements
- A robust ecosystem of utilities and tools to make development, installation, debugging, and maintenance as easy as it is on consumer systems.
The process automation market is estimated at about $130 billion, more than large enough to support a dedicated software infrastructure market. Maybe, if the grumbling by architects and designers reaches a tipping point, the process control market can force current suppliers, like Microsoft, Apple, and Google, to develop systems designed for process control, or the process control vendors may collectively move to Linux derived systems. Only time will tell, but watch for movement away from rapidly changing consumer technologies to more stable solutions that will still be valid 5, 10, 15, or even 20 years from today.
- Dennis Brandl is president of BR&L Consulting in Cary, N.C., www.brlconsulting.com. His firm focuses on manufacturing IT. Edited by Mark T. Hoske, content manager, CFE Media, Control Engineering and Plant Engineering, mhoske(at)cfemedia.com.
What's your view? Post your opinion below or join the related discussion in Control Engineering's LinkedIn Group.
This posted version contains more information than the print / digital edition issue of Control Engineering.
See other articles from Brandl related to this topic below.
See other Manufacturing IT articles.
|Search the online Automation Integrator Guide|
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.