Who Owns Your OT Architecture? Why Standards Are a Leadership Decision

Expanding a company’s manufacturing facilities involves extensive planning. Unfortunately, operational technology (OT) architecture and management are often overlooked as a necessary part of these expansions.

Without proper planning, each facility ends up with different OT architecture, unclear ownership of assets, and a logistical mess that is difficult to troubleshoot. Scalability suffers and internal plant expansions become a headache, as each plant will have different needs, quirks, and systems that must be individually addressed.

 

The Ownership Problem

One of the core problems with developing OT architecture is that the default option is to allow the vendor to dictate the standards. At first glance, it appears this is the easiest option; the vendor demonstrates how they view the facility and what they think works best. The plant engineers can default to this architecture and do not have to develop a deeper plan.

Ownership involves having control over the databases, brokers, and standards, as well as maintaining security, and assuming the responsibility to manage changes and updates. Furthermore, it means enforcing standards and determining who, how, and when vendors plug into these systems.

Here’s what often happens: An external vendor recommends a new OT architecture, so a small segment of the plant begins operating under a different strategy than the rest of the system. Over time, other machine segments are integrated, while supporting vendors change hands or go out of business, leaving many of these disparate segments without external support.

Even if the vendor remains in business, there are other hidden costs associated with allowing the vendor to choose the standards. The vendor still decides what works best for their product, not necessarily what is best for the particular facility. This can build inefficiency into the system from the beginning.

 

Building a Leadership Culture

Each new project should add to a shared, uniform foundation, rather than being treated as a silo with separate standards. Clear ownership is only the first step in performing this integration. Ownership must also mean leadership; leadership includes not just choosing a standard, but funding the project and enforcing the rules of the standard. Often, the failure point is not the standard itself but the fact that the standard was never enforced or never funded.

First, the leadership should consist of a cross-community slice of the stakeholders. Because true integration includes both OT and IT, as well as operations and engineering, these should be represented in the team. Change requests need input from all members to minimize integration friction during deployment. The team should also change how RFPs, contracts, and other documents with outside vendors are authored, to ensure that the standards are upheld.

Second, funding should be ongoing. Too often, standardization and integration projects fail because they are treated as a “one-and-done” expenditure, instead of a recurring expense. In reality, the effort required to maintain libraries, evaluate change requests, and ensure new modules are integrated properly requires time. It requires recognizing that standards are critical infrastructure, not a side project.

 

CESMII’s Three Smart Manufacturing Imperatives

To begin the process of standardization, one can start with Collaborative Ecosystems Smart Manufacturing Innovation Institute’s (CESMII’s) Three Smart Manufacturing Imperatives. By aligning strategies to these imperatives, owners do not need to develop everything from scratch.

Standards-Based Information Modeling

Standards-based information modeling ensures that all equipment, regardless of vendors, is represented by the same OPC UA information, templates, and Smart Manufacturing (SM) profiles. The standards should include the structure, attributes, relationships, and context for data.

Interoperability Platforms

Once standards-based information modeling is complete, shared context must be put into operation. Standard models are called up and populated with data from real devices, regardless of manufacturer. This is the step that connects data to actual hardware.

Open API

Accessing data is not the same as promoting interoperability between systems. Using an open API, such as CESMII’s Industrial Information Interoperability eXchange (i3X), provides not just data, but contextualized data to the consumers who need to see it. Data contextualization allows integration among systems without the need for heavy customization at each system.

 

Data Model Repository

There is an old saying, “a man with one watch knows the time, but a man with two watches can never be sure.” The same is true with data models. Ideally, a single source of truth should be used, not multiple copies across different devices, or different “truths” for different hardware vendors. From there, engineers, vendors, and hardware can access this centralized repository.

The data models themselves include the SM model, OPC UA NodeSet files, and reusable equipment models. Consider a chemical process that involves multiple pumps. Each of these pumps comes from different manufacturers, and pumps different types and quantities of liquid, but the basic function is still the same: pump liquid. They can use the same SM model, making it much simpler to pull relevant data when needed without having to consider vendor-, machine-, or site-specific nuances in system structure. Each pump may have highly customizable components, but the overall framework remains the same between pumps.

 

Operational Standards

Industrial standards already exist for many pieces of equipment. For example, ISA-95 provides the hierarchical structure for systems, from enterprise level down to machine level. Other commonly used standards include ISA-18.2, which handles safety alarms and systems, and ISA-101, which specifies human-machine interface (HMI) design for more effective use. Infrastructure integration includes communication protocols such as MQTT, Eclipse Sparkplug, NATS, and several others.

An added advantage of using operational standards is simplifying the onboarding process for new hires. Professionals who have worked in systems engineering or integration may already have experience with these standards. It also helps with internal transfers from one facility to another for the same reason; engineers can know what to expect when they arrive.

 

Extending the Supply Chain

As standardization is developed at the enterprise level, it can alter the supply chain into and out of each facility. Published data models can be provided to automation equipment suppliers and machine builders. Then, they know what to expect when they design equipment for a client. Instead of giving the client a particular machine and letting them worry about integrating it, they can make the whole system more attractive during the sales pitch. New equipment arrives already modeled with data that the plant can use.

It also helps with new plant design and knowledge transfer between plants. New plants can be brought online without having to develop a new hierarchy; standard templates, data formats, and protocols can be used. Failure modes at one plant can be quickly investigated at another plant.

 

Case Studies

Defining standards for the OT architecture has proven to be a worthwhile venture across many industries. One thing these studies have in common: manufacturing facilities pair with integration specialists. The manufacturing facility explains its systems and will ultimately maintain ownership of them, while the integrator helps make sense of and standardizes the system.

Conagra Foods (with Logical Systems, Inc.)

Conagra Foods manages 32 food processing facilities spread out over North America. Each plant had its own independently developed PLC systems. This led to inconsistent tags, hierarchy, and version drift between plants. Logical Systems, Inc. helped them develop templates, standardized tags, and a unified architecture using Ignition. Since this change, new plants can be brought online more quickly, uniformly, and efficiently.

 

A technician works in a control cabinet at a Conagra Foods facility. Image used courtesy of Inductive Automation.

 

BorgWarner PlantX (with Concept Reality)

BorgWarner worked with Concept Reality to build a connected-factory program that was designed around uniform standards. The pair established an ISA-95-style hierarchy, standard UDT patterns, visualization templates, and other tools that would ultimately streamline scalability. BorgWarner provided the business priorities, and Concept Reality supported the architecture.

Tessenderlo Group (with AT-Automation)

Tessenderlo Group, with the help of AT-Automation, developed a safe-loading application built around ISA-95 data structure, making it modular and easy to deploy. The new data structure standardized key components, such as load points, arms, and so on, so that it could be deployed across new sites without having to reinvent the logic.

 

The Bottom Line

Ultimately, standards are a leadership decision that is made early in the design process. Having clear ownership and making those standards decisions will make it possible to scale a process. Those who do not have a clear ownership structure or do not choose standards will find themselves constantly rebuilding with each change in production needs.

To learn more about how to manage OT architecture, please visit Inductive Automation and reach out to their technical staff.