Manufacturing data hubs are gaining traction in the industry as a new solution for unifying, standardizing, and orchestrating plant and operational data. But what is a manufacturing data hub? And how do you identify one?
Attempts at constructing the optimally useful, efficient and scalable architecture for manufacturing data have been ongoing for three decades. As computing power, cloud technologies and software engineering patterns have evolved, the offerings have gotten closer to optimal while at the same time flooding the market with confusing terms and buzzwords related to Industry 4.0.
What global manufacturing needs is a system that allows them to be innovative with implementing modern technology while also improving their bottom line through operational improvements. This can only be done with a Manufacturing Data Hub (MDH).
What Is an MDH?
Drastically oversimplified, an MDH is a platform that collects all manufacturing data into a centralized system of record, based on a standard schema, to give the end user simplified access to all the data and events that make up their processes.
To do this, 6 non-negotiable aspects or criteria must be met for a platform to call itself a Manufacturing Data Hub:
- It must have an operationally focused, event-driven architecture (EDA).
- It must collect data and events using open protocols and persist them and their derivatives in a low-latency, real-time data store.
- It must contain a mechanism for standards-based modeling and configuration that enforces a widely available standard definition of manufacturing.
- It must allow the end user’s custom business logic to extend the standard model using low-code or no-code tools.
- It must have a single access point, subscribable API, based on an open standard, that federates every entity and relationship contained in the model, including those from external systems in the supply chain.
- It must be infinitely scalable, natively highly available and function with zero downtime.
The 6 Criteria of an MDH
Feature #1: Operationally-focused EDA
Defining an architecture to collect and contextualize data is pointless if it isn’t solving a problem. Problems in manufacturing are defined in terms of events. Use cases are solved by evaluating and responding to events. Improvements are often defined in terms of events that either happened or were prevented from happening.
The data is mostly irrelevant on its own. The events produced by the data are everything. Therefore, the architecture of an MDH must be event-driven, not data-driven.
Feature #2: Low-latency / Real-time
It does little good to find out about an event if it’s too late to take the necessary action for the betterment of a process.
The underlying data structures and technologies must be able to deliver the events and their payloads to the users and applications in real-time with the absolute minimum latency. This is exponentially more important when using the MDH to feed AI and ML models.
Feature #3: Standards-based modeling
Standards in manufacturing exist because thousands of brilliant people felt that it was prudent to spend millions of collective hours defining the commonality of what a manufacturing process is.
That work and those standards do not fade from relevance because of advances and changes in technology. Indeed, those standards become more relevant. They define a common language for an enterprise and decrease the speed of iterative implementation, sometimes by orders of magnitude.
An MDH must deal in ISA-95 standards-based schema.
Feature #4: Simplification of custom business logic
Standard models define things, processes and relationships. What they do not define is how an individual enterprise will choose to implement those things and processes or how the other systems in the enterprise will interact with the model.
Implementing business processes using verbose custom code is the bane of systems integration and the root of failure in manufacturing data systems and applications.
An MDH allows for business logic to be extended using low-code or no–code tools.
Feature #5: No data silos
Developing applications that solve manufacturing problems takes much longer than it should, given improvements in technology and software engineering processes.
The solution is that all data and events in the system are available from one endpoint, using an open protocol to query a self-defining and discoverable API that does not define query payloads. Query development must take minutes, not weeks or months so that global manufacturing can get about the business of iterative innovation.
Feature #6: Cloud Native / Secure / On-Premise
For an MDH to be useful, it needs to be available all the time, with no exceptions, because it is the beating heart of the enterprise.
It needs to be capable of being rolled out in a rapid deployment fashion as a part of an enterprise continuous integration and deployment (CI/CD) program. It needs to scale to meet demand. It needs to provide granular security to the event level and encrypt data both at rest and in transit.
In other words, it needs all of the capabilities provided by cloud-native technologies; however, it needs to provide those without forcing end users to push their data and events into a public cloud.
Conclusion: These 6 Criteria Are Non-Negotiable
If any one or combination of these criteria isn’t present in a data platform calling itself a “manufacturing data hub,” then the platform is not a true manufacturing data hub. A true MDH allows global manufacturers to tame the massive amounts of data their operation creates. Through that data, they can innovate and improve the bottom line through operational improvements.
