Topics In Demand
Notification
New

No notification found.

Blog
Avoid Repeating the Mistakes of Industry 3.0

July 26, 2019

749

0

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 mistakes of Industry 3.0 Mistakes%20of%20Industry%203.0.JPGmanagement, 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.

“Reprinted with permission, original blog was posted here”. You may also visit here for more such insights on the digital transformation of industry.

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 RPaira@arcweb.com

About the Author:

Mark Sen Gupta

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.


That the contents of third-party articles/blogs published here on the website, and the interpretation of all information in the article/blogs such as data, maps, numbers, opinions etc. displayed in the article/blogs and views or the opinions expressed within the content are solely of the author's; and do not reflect the opinions and beliefs of NASSCOM or its affiliates in any manner. NASSCOM does not take any liability w.r.t. content in any manner and will not be liable in any manner whatsoever for any kind of liability arising out of any act, error or omission. The contents of third-party article/blogs published, are provided solely as convenience; and the presence of these articles/blogs should not, under any circumstances, be considered as an endorsement of the contents by NASSCOM in any manner; and if you chose to access these articles/blogs , you do so at your own risk.


© Copyright nasscom. All Rights Reserved.