Articles
13 minutes
Copy Link
ISA-95 vs. Industrial Ontologies: Hierarchy, Semantics, and When Manufacturers Need Both
TL;DR
ISA-95 defines enterprise and control boundaries and provides information models. Industrial ontologies add extensible relationships across site-specific data. They answer different questions rather than compete.
Use ISA-95 alone when its boundaries and information models cover the exchange. Use an ontology alone for a contained analysis that does not need an enterprise to control boundary. Use both when decisions depend on shared system roles and site specific relationships.
The order, lot, and temperature example shows how time bound relationships connect ERP, MES, PLC, and SCADA records.
The implementation sequence covers record ownership, relationship governance, validation, and the handoff to operational decisions.
What ISA-95 actually defines
ISA-95 defines five levels of manufacturing activity and the information exchanged between them. In the OPC Foundation’s ISA-95 Common Object Model, Level 0 represents the physical process. Level 1 covers sensing and actuation, while Level 2 covers monitoring and control, often through PLCs. Level 3 covers manufacturing operations management, including MES, while Level 4 covers enterprise functions commonly served by ERP. SCADA can serve different supervisory contexts, so its level depends on the function it performs.
ISA-95 also provides information models for the objects exchanged across those boundaries. Its four primary information models cover material, equipment, physical assets, and personnel. The distinction between equipment and physical assets shows why the model is more than a hierarchy. A temperature transmitter tagged TT-101 can retain its functional equipment identity when a technician replaces the physical sensor with one bearing a different serial number. Material lots identify actual quantities of material, while personnel information can describe qualifications needed for an operation.
ISA-95 supports property-based modeling, with classes, instances, and properties that describe specific objects. Those definitions give architects a shared starting point, but they do not specify every relationship at a particular plant. An architect still needs to establish, for example, which sensor reading belongs to a production order and when that association remains valid after a sensor replacement.
What an industrial ontology adds on top
An industrial ontology can use ISA-95 concepts as a starting point and define additional relationships for your plant and use case. ISA-95 already models equipment, material, physical assets, and personnel through properties and relationships. An ontology can add governed definitions for which sensor measures a particular vessel and which operation used that vessel at a given time.
Consider a temperature tag in SCADA and a serial-numbered transmitter in maintenance records. ISA-95 distinguishes an equipment role from the physical asset occupying it. A site ontology can connect the tag to the vessel it measures and record when a replacement transmitter took over. It can also define the readings’ units, source, and period of validity. Those details let an analyst attribute an older reading to the transmitter installed when SCADA captured it.
The OPC Foundation’s ISA-95 companion specification provides an OPC UA representation of selected ISA-95 concepts. OPC UA exposes selected ISA-95 objects as typed nodes with hierarchical and nonhierarchical references. Your ontology can build on those relationships without requiring RDF or OWL. Existing interfaces still move the data, while ISA-95 continues to define the enterprise and control boundaries.
Where each one fits across PLC, SCADA, MES, and ERP
A production order for 500 units shows how the two models work together across ERP, MES, PLC, and SCADA. ERP holds the order and its planned quantity at ISA-95 Level 4. At Level 3, MES records which operation ran against the order, which material lot it consumed, and which machine performed the work. ISA-95 defines the boundary between business planning and manufacturing operations, along with information models for objects such as material lots and equipment. The OPC Foundation’s ISA-95 model describes those activity levels and object relationships.
On the floor, a PLC reads temperature tag TT-101 and tracks whether the machine is running or stopped. Those sensing and control activities generally sit at Levels 1 and 2. SCADA may display the tag and machine state, but its ISA-95 placement depends on what it does. Supervisory control fits Level 2, while some operations functions fit Level 3. For a closer distinction between MES and ERP responsibilities, see Humble’s system role comparison.
An industrial ontology can define the relationships needed to interpret that temperature reading for the order. It can specify that TT-101 measures a particular machine, that the machine executed an MES operation, and that the operation consumed a named lot for the ERP order. The reading needs a unit, timestamp, and source. The relationships used to attribute it to equipment and an operation need valid time periods. Without those details, a tag value cannot reliably describe what happened to that lot during that operation. A downstream decision layer can then use the contextualized record to assess an operational choice, while the PLC, SCADA, MES, and ERP retain their existing responsibilities.
An illustrative join shows the required links. erp_order=PO-500 → mes_operation=OP-17 → material_lot=LOT-42. The operation used equipment=MX-3, and TT-101 measured MX-3 from 2026-09-01T08:00Z to 2026-09-30T17:00Z, according to the approved equipment registry. To attribute a PLC reading of 78.4 °C at 2026-09-22T10:15Z to LOT-42, confirm that the MES execution interval includes that timestamp and that the measurement link was valid then. The identifiers, values, and dates are illustrative. In a production model, record the source and effective dates of each relationship.
When you need hierarchy alone, ontology alone, or both
Use ISA-95 when you need a shared enterprise and control boundary with defined manufacturing information models. Add an industrial ontology when the use case depends on relationships that those models do not specify for your sites. ISA-95 already defines objects and properties for equipment, material, physical assets, and personnel. Using ISA-95 alone therefore means more than adopting a tree of system levels. The OPC Foundation’s ISA-95 model documents that scope.
Decision dimension | ISA-95 | Industrial ontology |
|---|---|---|
Scope boundary | Defines manufacturing activities and information exchanged across enterprise and operations systems | Models meaning across the sources selected for a use case |
Extensibility | Provides standard objects that you can extend | Adds governed entities and relationships specific to a site or use case |
Cross-site semantics | Supplies common reference concepts | Resolves local names and relationships across plants |
Integration effort | Requires mapping source records to standard concepts | Requires identity matching, relationship rules, and ongoing governance |
Tooling maturity | Has an established standard and companion models | Depends on the chosen model, tools, and governance practices |
When two plants use different identifiers for equivalent equipment roles, ISA-95 provides a common equipment concept. An ontology can map each local identifier to that concept and record which measurements apply during a given period.
Scenario | Choice | Reason |
|---|---|---|
One site needs a defined MES to ERP information exchange | Hierarchy alone | Standard boundaries and objects may cover the required exchange |
A local historian analysis needs relationships among tags | Ontology alone | The analysis may not cross an enterprise and control boundary |
A multi-plant rollout must compare equivalent assets | Both | Shared ISA-95 concepts need mappings to each plant’s identifiers |
Root cause analysis joins machine state, material lots, and orders | Both | System boundaries and governed relationships serve different parts of the query |
Analytics or AI consumes records across operations and business systems | Both | Consumers need defined source roles and consistent entity meaning |
An ontology alone can suit a contained analytical question, but it does not establish which system owns an order or execution record. Conversely, an ISA-95 exchange may suffice until a question requires relationships among records that the reference model cannot determine for your specific equipment, sites, and data sources.
Failure modes of using only one
ISA-95 gives you equipment and physical asset models, but its reference model cannot supply every relationship specific to your plant. The OPC Foundation’s ISA-95 object model distinguishes equipment roles from physical assets. In this example, TT-101 identifies a functional measurement position, while a serial number identifies the installed transmitter. If you map TT-101 directly into MES and maintenance records without tracking that distinction, a replacement transmitter can inherit readings or service history that belong to the previous unit. Each direct mapping then needs its own correction.
A site ontology also needs explicit rules for record ownership and system boundaries. You can define a relationship between a sensor reading, a material lot, and a production order, but the model still needs to identify which system owns each record and what each relationship means. If sites define those links differently, you cannot reliably compare their data. The architect must still specify when a PLC signal, an MES execution record, or an ERP order is authoritative for a particular decision.
A practical implementation sequence
Define the operational question before choosing a model. For example, you may need to identify which production orders used material lots while a machine ran outside its temperature limit. Specify the decision that answer will support and the time window it requires. Those requirements determine which records and relationships need modeling.
Map the system boundaries and record owners. Use ISA-95’s activity levels and information models to place the PLC measurement, SCADA observation, MES execution record, and ERP order in context. Record which application owns each value and where information crosses a boundary. SCADA’s role depends on the installation, so do not assign it a level solely by product name. For a closer look at those application roles, see the MOM, MES, and ERP comparison.
Connect records through governed relationships. Model how the sensor tag relates to a machine, how the machine relates to an operation, and how the operation relates to a material lot and production order. Include measurement units, timestamps, and the source of each relationship. ISA-95 supplies useful starting objects, while the ontology expresses the site-specific links the question needs.
Assign ownership for semantic changes. Name who approves a new equipment relationship, resolves conflicting identifiers, and updates the model after a sensor replacement. Keep the functional tag separate from the physical sensor so a hardware swap does not rewrite the history of what the tag measured.
Validate the join against recorded events. Trace a known order through the MES operation and material lot records to the machine state and PLC measurement. Check that timestamps overlap, units match, and the linked sensor was valid during the run. Investigate missing or ambiguous matches rather than silently filling them.
Hand off contextualized evidence for a decision. Once the records and relationships pass validation, a downstream decision layer can consume the order, lot, machine, and measurement context. The layer can then evaluate an operational action without becoming the owner of the source records or the semantic model.
Where Humble fits in this architecture
Humble sits downstream of the systems that collect, exchange, and contextualize manufacturing data. ISA-95 helps you define where production information crosses functional boundaries. An industrial ontology can then connect a machine state to the affected order, material lot, and equipment record. Humble sits at the decision layer and can use contextualized records to support scheduling and investigation of operational causes. The source systems remain responsible for their records.
A normalized machine-state value tells you what a source reported. To decide whether to change a schedule, you also need to know which order the machine was running, which constraints apply, and whether the record is current. Humble supports that decision. It does not build the ontology or replace PLC, SCADA, MES, ERP, or the infrastructure connecting them.
For more detail on system boundaries, consult Humble’s ISA-95 integration guide. Its manufacturing ontology software comparison addresses platform selection.
See If Humble Fits Your Floor
If you have a specific operational decision and know which records it requires, take Humble’s fit test to assess whether its decision layer suits your existing systems.
Book a Call with Humble
If you can identify the records behind a scheduling or root cause question, book a call with Humble to discuss how a decision layer could use them. Bring the decision and the available records.
Get the Humble Newsletter
For more on manufacturing operations and decision intelligence, subscribe to the Humble newsletter.
FAQ
Does ISA-95 include a data model?
Yes. ISA-95 defines information models for material, equipment, physical assets, and personnel, including properties and relationships. Those models provide a common starting point, but they do not describe every relationship specific to your plant.
Can an industrial ontology replace ISA-95?
An ontology can model site specific concepts and may represent system boundaries, but it does not itself supply ISA-95’s standardized activity and information models. Use ISA-95 when those shared definitions are required, and add ontology relationships where the use case needs them.
How does OPC UA relate to ISA-95 and industrial ontologies?
An OPC UA companion specification exposes a subset of ISA-95 objects and relationships as typed nodes and references. OPC UA provides a way to represent and exchange that information, while your semantic model determines which additional relationships your use case needs.
Does a small single-site manufacturer need an ontology?
Not necessarily. If stable identifiers and a few maintained mappings answer your operational questions, a separate ontology may add work without much benefit. Consider one when recurring questions require you to reconcile the meaning of data across systems.
How should architects use ISA-95 and industrial ontologies together?
Use ISA-95 to define shared functional boundaries and information objects. Add ontology relationships when a decision requires site specific connections among records that the reference model does not determine.
The use case should determine how much semantic modeling you add. When records carry consistent identities, relationships, and provenance across systems, downstream decision tools can evaluate operational choices in context rather than reconcile conflicting records each time.