Mark has about 30 years of expertise in process control, SCADA, and Industrial IT applications. He began his career as a Process Control Engineer with Mobay Corporation (Bayer) in Baytown, TX working with instrumentation, PLCs, and DCSs. He later joined Honeywell as an Applications Engineer working with DCS and SCADA and later joined the sales group as a Systems Consultant for SCADA, batch, Foundation Fieldbus, and hybrid control products. At Plant Automation Services, he managed the alarm management products and wrote the initial specification for PlantState Suite.
In the 1960s, computerization was just beginning. Early minicomputers were used in the control of industrial processes since the beginning of the 1960s. The IBM 1800, for example, was an early computer that had input/output hardware to gather process signals in a plant for conversion from field contact levels (for digital points) and analog signals to the digital domain. The first industrial control computer system was built 1959 at the Texaco Port Arthur, Texas, refinery with an RW-300 manufactured by the Ramo-Wooldridge Company (who?). In these early days, there was no off-the-shelf solution a company could purchase and configure. Instead, companies did a lot of the work themselves, purchasing generic computing platforms and programming the functions and logic from a blank slate. Eventually, some companies partnered with analog control manufacturers to develop digital products, but some process companies developed their own. Monsanto eventually spun its process control division off, and The Dow Chemical Company finally gave up the Mod5.
The Mistakes of Industry 3.0
This happened with more than just control system platforms, but also with advance control applications. How many spreadsheet applications were created (and still are) to fill a need in alarm management, safety lifecycle management, loop tuning, process analytics, etc.? Many of these needs can now be addressed with commercial products, but we continue to see an adherence to home-grown solutions. This adherence is usually justified with one of two reasons: 1) it’s a competitive advantage, 2) the available products aren’t good enough. That might seem true at the start, but it rarely holds true for long.
What makes this a mistake? Product lifecycle and core purpose. Core purpose centers around the company’s purpose; what does the company do? What it makes, it needs to make well. All its resources need to be focused on that purpose. Creating software is not part of the core business of a manufacturer. There may be exceptions where a technology needs to be created internally, but manufacturers need to know when to relinquish it. With regards to product lifecycle, most manufacturers do not have the skillsets, nor the resources, to manage software lifecycles. What’s involved? Proper lifecycle management entails capturing user use cases, professional development staff to stay on top of operating system changes/patches and address cyber security issues, and proper product and development documentation and change management. Manufacturers don’t have these skillsets nor the processes in place. Worse yet, they’re hard to find and harder to keep; people move on and developers don’t care for the manufacturing space.
As manufacturers progress with the new technologies enabling digital transformation, they should be cognizant of the potential pitfalls of in-house creations. If the idea is that good, partner, patent and license it.
About ARC Advisory Group (www.arcweb.com): Founded in 1986, ARC Advisory Group is a Boston based leading technology research and advisory firm for industry and infrastructure.
For further information or to provide feedback on this article, please contact firstname.lastname@example.org
About the Author: