The Operational Challenge
The process industries are struggling under the weight of ever-increasing data volumes as more equipment and processes are instrumented and sensors are installed. Add to that the plethora of legacy, non-integrated, and siloed software applications, and the weight of technical debt becomes overwhelming. All of this is occurring under pressure to transform the operating model and utilize AI effectively.
One answer has been to re-architect the operational data infrastructure and how data is managed enterprise-wide, utilizing the following concepts:
- Universal Namespace (UNS) – the real-time, normalized, single source of truth for operational data
- Data fabric – the enterprise-wide architecture that enables unified data access
- Data operations – the operating model for building and maintaining data pipelines
- Data hub – the metadata and context layer of a modern data ecosystem
- Data mesh – a socio-technical operating model for organizing people and responsibilities around data
In doing so, the industry is moving away from the process historian as the indispensable center of the universe for operating data (i.e., time series and events), recognizing the need to integrate additional data types to enable superior decision-making in pursuit of Operational Excellence (OE) – defined by the Operational Excellence Consortium as, “a systematic, company-wide approach to management in which every function acts as one integrated system to execute mission, strategy, goals, and objectives”—and to accommodate new AI-based applications and agents.
Why Current Approaches Fall Short
The traditional IT approach to integration has been to use Application Programming Interfaces (APIs) to move data between applications. There are two problems with this approach.
- While the data is moved via the API, the context around the data does not move with it.
- The existing context in the control system and the historian, as typified by the ISA 95 hierarchical equipment taxonomy (e.g., enterprise, site, area, unit, etc.), does not align well with other operational systems (e.g., Enterprise Resource Planning, Asset Performance Management, Laboratory Information Management System, Process Safety Management, etc.), which contain their own unique data types, embedded business logic, constraints, and data relationships.
Make no mistake: these are valuable components of the Enterprise Architecture, but they are not, in and of themselves, the integration layer. So, something more than a taxonomy is needed, something more than a syntactic API, because the predefined handoffs between ISA 95’s pyramid layers constrain the system's flexibility. And that’s where an ontology comes in, highlighting the functional gap between syntactic and semantic interoperability. Think of it this way: in data science, a taxonomy is a simple hierarchy that classifies data, while an ontology is a complex network that maps the relationships between data points.
- Syntactic interoperability (the handshake): systems agree on a format (JSON, XML, or CSV). System A can send a file to System B, and System B can "read" the fields in the file.
- Semantic interoperability (the conversation): systems agree on the meaning of the data. System B recognizes that the pump mentioned by System A is the same physical asset in its own database and understands the safety implications of its failure.
Now, the ISA 95 standard has evolved and handles far more complexity than in its early days, but given how technology has progressed, it wasn’t really designed to solve today’s contextualization problem. Given the new data management concepts mentioned above, the layers appear to be flattening, but in reality, they have become multidimensional.
The challenge is how to build contextual relationships across these multiple dimensions. This is done through an equipment asset ontology instead of a hierarchical equipment taxonomy.
What Can an Ontology Do That a Taxonomy Cannot?
An Equipment Asset Ontology is a standardized data model organizing physical assets, attributes, states, and lifecycles. It’s not just a database. It’s a standardized language that disparate systems can use to share data consistently. Meanwhile, a taxonomy can only give you a hierarchy, a file tree, but it cannot describe relationships between levels or relationships to attributes from other systems.