Applied Ontology in Manufacturing

The Integration Problem on the Factory Floor

A typical automotive assembly plant manages 5,000-10,000 active part numbers from hundreds of suppliers, runs continuous inline quality checks, and coordinates robotic cells, conveyor systems, and human workstations across multiple shifts. The software stack is just as complex: MES for production execution, SCADA for process control, ERP for planning and materials, PLM for product design, QMS for quality management, CMMS for maintenance. Six or more systems, each with its own data model, its own API, its own definition of basic concepts.

Each system holds a slice of reality. The MES knows what is running on the line right now. The PLM knows how the product was designed. The QMS knows what defects have been found. The CMMS knows when the last maintenance was performed. But none of them holds the complete causal chain: from a design change in the PLM, to a tooling adjustment on the line, to a quality deviation caught by an inline sensor, to a warranty claim filed eighteen months later.

The standard response to this fragmentation is integration middleware. Point-to-point APIs, ESBs, iPaaS platforms. These bridge syntax -- mapping Field A in the MES to Field B in the QMS. They do not bridge semantics. When the MES calls something an "operation" and the QMS calls it an "inspection point," the middleware maps the data without understanding that these are two views of the same physical activity on the same machine at the same time.

This is a modeling problem.

Why ISA-95 Is Not Enough

The manufacturing world is not without standards. ISA-95 (also known as IEC 62264) has been the de facto framework for manufacturing-enterprise integration since 2000. It defines a hierarchy -- Enterprise, Site, Area, Work Center, Work Unit -- and a set of models for production, quality, maintenance, and inventory. It is genuinely useful. If you are building a greenfield MES, ISA-95 gives you a solid starting structure.

But ISA-95 is an information model, not a formal ontology. It defines data structures and exchange formats. It does not define formal semantics. It tells you that a "Work Order" has a "quantity" field and references a "Material" -- but it does not express the axiom that a Work Order cannot be released if the specified Material has not been quality-approved for the target process, or that a Material substitution requires re-validation of the downstream QualityInspection parameters.

ISA-95 describes structure. Ontology describes meaning and rules. You need both. ISA-95 for interoperability with existing systems. Ontology for the reasoning that makes your digital twin actually intelligent.

Building on IOF and BFO

The Industrial Ontology Foundry (IOF) exists precisely to fill this gap. IOF is an open community building formal ontologies for manufacturing and industrial operations, grounded in BFO (Basic Formal Ontology) -- the same upper-level ontology used by over 350 ontology projects worldwide.

IOF gives you rigorously defined classes like ManufacturingProcess, MaterialArtifact, MaintenanceActivity, and QualitySpecification. These are not just labels. They carry formal definitions in OWL (Web Ontology Language), with axioms that constrain how they can be instantiated and related. A ManufacturingProcess is formally defined as a PlannedProcess (a BFO occurrent) that has a MaterialArtifact as input and a MaterialArtifact as output, where the output differs from the input in at least one quality (dimension, composition, surface finish, etc.).

This level of rigor sounds excessive until you realize it prevents the modeling errors that cause real operational failures. Without it, someone will model a quality inspection as a manufacturing process, or a maintenance task as a production operation, and the system will make incorrect inferences about resource allocation, scheduling, and cost attribution.

Modeling a Production Line: A Concrete Example

To make this concrete, consider how you would model a CNC machining cell that produces aluminum housings for electric motor assemblies.

The core entities:

• Machine: CNC-Lathe-07, with properties including spindle speed range, tool magazine capacity, current tool set, calibration status, and hours since last service.
• WorkOrder: WO-2025-4471, specifying the part number, quantity, required material grade, quality standard, and due date.
• Material: ALU-6061-T6, Lot 2025-B-0089, with properties including alloy composition, heat treatment status, dimensional certification, and shelf location.
• QualityInspection: QI-2025-12003, referencing the inspection plan, measurement parameters, tolerance bands, and the calibration record of the CMM (coordinate measuring machine) that will perform the measurement.
• Operator: The certified machine operator, with their qualification matrix (which machines, which processes, which material types).

The relations:

• WorkOrder isExecutedOn Machine
• WorkOrder consumes Material
• WorkOrder requiresQualification Operator
• QualityInspection validates WorkOrder
• Machine hasCurrentToolSet ToolConfiguration

The axioms -- and this is where ontology earns its keep:

• A WorkOrder cannot transition to "In Progress" unless the assigned Machine's calibration status is "Valid" and the current tool set matches the WorkOrder's required tool configuration.
• A Material lot cannot be consumed by a WorkOrder unless its QualityInspection status is "Released" for the specific process type.
• An Operator cannot execute a WorkOrder on a Machine unless their qualification matrix includes both the machine type and the material grade.
• A QualityInspection is invalid if the measuring instrument's calibration certificate expired before the inspection date.

The Wrong-Material Problem

Here is a scenario that happens in real factories more often than anyone wants to admit: the machine ran, but nobody loaded the right material.

The operator picks up a material lot from the staging area. The lot label says ALU-6061-T6. The work order calls for ALU-6061-T6. Looks correct. But this specific lot has a pending quality hold -- the composition certificate from the supplier showed a slightly elevated silicon content that needs metallurgical review. The hold is recorded in the QMS. The work order is in the MES. The lot location is in the WMS. No single system connects all three.

In a traditional setup, the operator runs the job. The parts pass inline inspection (dimensional checks are fine -- the composition issue does not affect dimensions). The parts ship to the customer. Months later, premature corrosion. Root cause analysis traces it back to the elevated silicon content in that lot. The result: warranty claims, a customer audit, and a containment exercise that shuts down the line.

With an ontology-driven system, the axiom "Material lot cannot be consumed unless QualityInspection status is Released for the specific process type" prevents the work order from starting. The operator gets a clear message: "Material ALU-6061-T6, Lot 2025-B-0089 has a quality hold (QI-2025-11847, pending metallurgical review). Cannot proceed." The system can suggest alternative lots that are released. The problem is caught before it becomes expensive.

From Reactive Alarms to Prediction

Traditional MES and SCADA systems operate reactively. The machine stops -- alarm. The temperature exceeds a threshold -- alarm. The operator missed a scan -- alarm. By the time you see the alarm, the problem has already occurred. You are in damage-control mode.

An ontology-driven system enables prediction because the formal relationships between entities create a reasoning framework. The system knows that Operation A depends on Machine B, which has a mean time between failures of 2,400 hours. Machine B has been running for 2,350 hours since its last service. The vibration sensor on the spindle bearing is showing a trend that matches the degradation pattern from the last three failure events.

Without ontology, these are three unrelated data points in three different systems. With ontology, they form a causal chain that triggers a proactive maintenance scheduling workflow -- before the failure occurs, before production is interrupted, before downstream orders are delayed.

Predictive Maintenance Done Right

Predictive maintenance has been a recurring promise in manufacturing for years, and the ML models themselves have gotten quite good. Where things tend to fall short is the operational context around the predictions.

Knowing that Machine B will probably fail in 50 hours is useful but insufficient. The question an operations manager actually needs answered is: What happens when Machine B goes down? Which work orders are affected? Can they be rerouted to Machine C? Does Machine C have the right tooling? Is there an operator qualified for Machine C on the current shift? What is the cost of rerouting versus the cost of emergency maintenance tonight?

Answering those questions requires traversing the ontology: from machine to work order to material to operator qualification to shift schedule to tool configuration to cost model. Most predictive maintenance tools focus on the prediction itself, which is the easier half. The harder half is connecting that prediction to the operational context that determines what to actually do about it.

The Dark Factory: Vision vs. Reality

The ultimate vision for ontology-driven manufacturing is the dark factory -- a production facility that operates with the lights off because no humans are on the floor. FANUC has run lights-out machining cells for over a decade. Tesla's Gigafactories push toward increasing levels of automation. Foxconn has publicly stated their goal of fully automated "lights-out" production lines.

Full-factory autonomy remains aspirational for complex, high-mix manufacturing. The dark factory works today for high-volume, low-variability processes -- injection molding, CNC machining of standard parts, semiconductor wafer fabrication. For job shops, custom manufacturing, and operations with high product variability, we are years away.

But the trajectory is clear, and the prerequisite is formal. A dark factory cannot call a supervisor when something ambiguous happens. Every decision must be formalized: what to produce, in what sequence, on which machines, using which materials, with what quality criteria, under what exception-handling policies, and with what escalation paths when the formalized rules are insufficient.

That is an ontology. Not a process flowchart. Not a decision table. Not a pile of if-then rules in a PLC program. A formal, executable model of the manufacturing domain that a runtime can interpret, reason about, and act on.

Full-factory autonomy is not around the corner. But the intermediate steps deliver concrete value on their own: fewer wrong-material incidents, less unplanned downtime, better demand-supply coordination, faster changeovers from formalized setup procedures. Each step is worth doing regardless of whether full lights-out operation ever becomes practical for a given facility.