← Back to Resources

Why “Just Unify It” Needs To Be Adopted as the Mantra for Industrial Transformation

Why “Just Unify It” Needs To Be Adopted as the Mantra for Industrial Transformation

Industrial transformation, or IX, according to LNS Research, represents a new chapter in the ongoing Industrial Revolution started several hundred years ago. This new era is enabled by extraordinary technology advances commensurate with those of the first, second, and third industrial revolutions.

Very futuristic, almost Star Trek sounding, right? But the reality is, we’re already there. And in order to not be left behind, we need to rethink our approach to data management, analysis and aligning data across many domains. In other words: Unification.      

Let’s look at some broad, ‘vendor agnostic’ descriptions of IX to put it into context.    

From a manufacturing perspective, LNS writes:

“Most manufacturers already have, or should have a range of CI teams and programs in place.  They include but are not limited to Lean, Total Quality Management (TQM), and Six Sigma.  Fundamentally CI is about doing the same thing better.

IX, on the other hand, is about disrupting longstanding best practices, value drivers, and competitive advantages with emerging digital technologies and process change.  IX means doing new or different things, not the same thing better.  One of the core goals with IX is to redefine processes, work, and technology while finding digital solutions to empower that change.

LNS Research

Wikipedia says this next evolution of the Industrial Revolution “marks the beginning of the imagination age.”[ii] Conceding the “imagination age” to more creative folks, we will focus on “automation and data exchange.”

The sheer amount of data required to enable the increasing connectivity and smart automation at the heart of IX is conceptually infinite, which is why we need next-level ways of managing and strategic methods for thinking about that data.

What IX Means for Us

Industrial Transformation is all about increasing operational efficiencies based on four key themes:

1.    Interconnection

2.    Information transparency

3.    Technical assistance

4.    Decentralized decisions

And there are lots of trends that we’re seeing and anticipating. Let’s look specifically at two trends that we’re intimately involved with: Smart Factory and Predictive Maintenance.

Let's start to get practical with all this.  Our CTO wrote an article on ontological data which is a deeper dive on these points. For today, let's recap:

  • Ontological data provides the structure or shape of a contextual model.
  • It defines the kind of data and relationships that exist in the context, but not the context itself.
  • The ontology doesn’t have any specific information, they have placeholders for the different pieces of information in the context model.

Sean uses the example of a pump, vibration data and their connections to illustrate the difference between context data and ontology data models.

He explains: “The data consumer doesn’t have to know anything about which specific vibration tag represents the specific pump and the specific plant, but that for any pump at any plant, you will have a Voltage sensor whose data is stored in a PI Data Archive.”

It can provide you a way to quickly find the answers to questions, such as:

  • “Show me all pumps without a functional location?”
  • “Which pumps do not have a `main shaft vibration sensor’?”

These queries may sound trivial, but the wise and savvy OT veteran will tell you that the answer to these depends on who is asking the question and the context in which they are asking the question.

  • Is it being posed from the centralized plant operations control center?
  • Does the scope encompass all pumps across 8 sites and 3 countries?

If the answer is yes to both, the answers to the queries about the pumps are no longer trivial! In fact, they may be hugely consequential.

Ontological models provide a template to build against and allow us to think at a much higher level when formulating a strategy to answer a question without having to sort through all the context data.

But in order for this type of scale to be possible, we need to unify the data.

Once we have unified the data from various OT and IT systems, and built models and pipelines that can be reused and recycled, and we’re doing this at scale, we realize several benefits. It feeds analytics faster, reducing the cost and time to generate insights. Now, both SMEs at the plant and shared services colleagues operating out of a CoE or enterprise office model, can access the data they need to collaborate from anywhere. This dynamic, in turn, enables rapid and accurate insights, derived from high quality data, to create safer, efficient, and more profitable operations.

Moving Beyond Data in the Cloud

is driving change and innovation in Layer 4 of the Purdue Industrial Model,[iii] and it could be viewed as making the case for a Layer 5 that is centrally and remotely managed.

Purdue Industrial Model,[iii]

There are excellent ISVs doing a terrific job of helping companies move their OT data to the cloud – for example  sensor data, maintenance data, and much more. We partner with many of these ISVs and work closely with them to deliver on these customer initiatives. Making data available from the cloud closes some of the gaps with monitoring or predicting remotely from a centralized control and ops center. It is a step in the right direction, but is incomplete depending on the use case and problem that needs to be solved.

Moving data from Layer 2/Layer 3 as in the Purdue model – from historians/enterprise historians to the cloud can be accomplished reliably. This allows you to monitor data trends, examine changes in data relative to itself and manage alarms. This is observability 1.0 and can drive a lot of value.

However, comparing data from different equipment of the same type for a specific property is not that easy. To compare them, you have to:

  1. Be confident that you are in fact comparing two pieces of equipment of the same type. As explained in the post on metadata, contextual models change over time. If the data is no longer accurate, your comparison is not reliable.
  2. Be sure that you are comparing the same sensor data across these equipment instances. This again is data that drifts over time since each plant operator has the freedom to make changes to their equipment and sensors for good reasons.
  3. Normalize the metrics across the values being compared. For instance, not realizing that you are comparing amps to mA could lead to the wrong conclusion.

This doesn’t scale. You don’t want more point-2-point connections, no matter how easy it is to create. It just creates more mess. We need a better approach.

One that looks more like:

This is why we’re evangelizing the mantra of “Just Unify It.” Element Unify provides the technology to solve these critical problems for industrial companies and is driving the convergence of OT and IT by helping create 360 degree views of companies’ operating assets. It’s a data-product-developer platform that helps unlock human potential with the tools to create reusable data products, which allows companies to do more with its data.

Until Next Time…

We’ve covered a lot of ground! We reviewed our understanding of ontology, context models, and metadata. In the next post, we will make our case for why it is past time for Industrials to embrace the Data-as-a-Product mentality. An example of this building data twins as a precursor to fully blown Digital Twins. We’ll explore the fact that without data twins that is actively feeding digital twins, the use cases for digital twin become limited.

In the following posts, we will explore the differences between scaling Data Management vs. embracing Data as a Product approach. The latter is a significantly more powerful way to unlock access to data broadly within the enterprise.

Want to Learn More?

Register to view a live demo of Unify or sign up for a free trial to use the software for 30 days. You can also sign up for a free trial or purchase a Personal License from the AWS Marketplace.

Questions? Please contact us.

[i] LNS Research https://blog.lnsresearch.com/ix
[ii] Courtesy of Wikipedia
[iii] Formally the Purdue Enterprise Reference Architecture (PERA), is a structural model for industrial control system (ICS) security, concerning physical processes, sensors, supervisory controls, operations, and logistics.