Substandard Standards and Their Committees
- Industrial and Enterprise software standards are ubiquitous especially as it relates to connectivity and interoperability.
- The real opportunity today lies in innovation enablement through data insights- standards are not going to address this challenge.
- Why create a standard for a problem that has already been solved?
Early in my career, I worked for a start-up company called Soft Systems Engineering (SSE), which eventually was acquired by Wonderware (now Aveva/Schneider). SSE created a very innovative software application for developing and executing complex batch recipes for process manufacturing plants. Following the acquisition by Wonderware, this became the InBatch product which today is still going strong across manufacturing plants globally.
The product provided a very structured approach to defining batch process recipes. It also managed the execution of the batch process and provided detailed reports and analytics. As the product gained traction, the market began to emerge, along with new competitors. Not too long after that, something else emerged- a standards committee. It was called the ISA S88 committee, and its objective was to define a common structure for batch process management that everyone would follow, allowing for interoperability and all sorts of other great things.
I remember attending my first S88 meeting with the various industry experts that made up the committee. From my vantage point, SSE had already defined structures for complex batch recipes from which customers were adopting and deriving value. SSE offered up their model to the committee in that meeting, but they were not interested. Their preference was to alter the naming conventions on something that already existed, claim it as the committee’s own, and declare victory.
Another thing I learned from the experience - once a standard committee starts, it never ends.
The S88 committee eventually morphed into the S95 committee which expanded the S88 committee scope to include standards for integrating business logistics systems to manufacturing systems.
Fast forward to today: We now have the OPC Foundation and OPC Unified Architecture (OPC UA), MQTT, AMQP, and other various protocols, reference architectures, and associated committees. These standards provide a valuable service as we now have protocols and standards to enable anything to connect and interoperate with anything. You would think we had solved world hunger, yet companies still struggle to collaborate (internally and externally) and innovate.
Why? Perhaps we are at a point where automated connectivity and data collection is table stakes and the real challenge is generating actionable, scalable data insights to the right people at the right time. Is this a challenge for a standard committee to solve? Or perhaps, just like in the past, software platforms are emerging to accelerate innovation without the need for standards.
At TwinThread, we believe our industrial digital twin platform provides the foundation for driving operational continuous improvement and innovation across a manufacturing enterprise. This starts with data connectivity and contextualization. We connect to almost any data source and contextualize data automatically in a matter of minutes through a structured digital twin architecture. Analytics, alerts, notifications, anomaly models, predictive models, and workflows are easily configured based on the digital twin structure.
While we leverage existing protocols for connectivity, our digital twin structure was created in house, we did not derive it from a standard or a standard committee. Our digital twin architecture enables rapid generation of sustainable, scalable IIoT solutions for our growing customer base. Our digital twin platform serves as the foundation and engine powering very successful continuous innovation programs at some of the world's leading industrial companies.
TwinThread’s approach is also unique in that it enables the customer to leverage their domain expertise and create their own unique intellectual property using the platform. While we conform to available standards, we are not constrained by those standards, and neither are our customers.
We are happy to share our structure and approach and forgo the need for any new standards or committees.
Dive deeper into the ramifications of an incomplete IIoT platform in parts 1-3 of this series:
