Manufacturing Ontology Modeling: End-to-End Digitization from Production Line to Product

“

Series: S4 Ontology Modeling · Article 16 | Level: Intermediate | Reading Time: 18 min

#TL;DR

Manufacturing Ontology revolves around the "Material, Process, Product" triad — BOM (Bill of Materials), process routes, equipment status, and quality inspection form the core model. coomia-dip unifies them as an ObjectType network, breaking down data silos between MES, ERP, and SCADA.
Equipment Ontology combined with real-time Metrics enables predictive maintenance — each machine is an ObjectType instance with vibration, temperature, and current sensor data as Metric properties. Derived properties auto-compute health scores, and Actions auto-trigger maintenance work orders.
Quality traceability chains through RelationType enable "one-click trace-back" — from a defective product, trace through relationships to batch, process step, equipment, operator, and raw material lot number in seconds, replacing hours of manual investigation.

#1. Manufacturing Data Challenges

#1.1 Typical Data Silos

Code

Manufacturing enterprise system landscape:

┌─────────────────────────────────────────────────┐
│  ERP (SAP/Oracle)                                │
│  ├── Material master data                        │
│  ├── BOM lists                                   │
│  ├── Purchase orders                             │
│  └── Cost accounting                             │
├─────────────────────────────────────────────────┤
│  MES (Manufacturing Execution System)            │
│  ├── Work order management                       │
│  ├── Process routes                              │
│  ├── WIP tracking                                │
│  └── Operator records                            │
├─────────────────────────────────────────────────┤
│  SCADA / IoT Platform                            │
│  ├── Equipment status monitoring                 │
│  ├── Sensor data                                 │
│  ├── Energy consumption                          │
│  └── Environmental data                          │
├─────────────────────────────────────────────────┤
│  QMS (Quality Management System)                 │
│  ├── Inspection standards                        │
│  ├── Inspection records                          │
│  ├── Non-conformance handling                    │
│  └── SPC (Statistical Process Control)           │
├─────────────────────────────────────────────────┤
│  WMS (Warehouse Management System)               │
│  ├── Inventory management                        │
│  ├── Receipt/shipment records                    │
│  └── Location management                         │
└─────────────────────────────────────────────────┘

Problems:
├── 5 systems, 5 data models, 5 APIs
├── "Which raw material batch was used for this product?" → cross ERP+MES+WMS
├── "Is there correlation between equipment faults and defect rates?" → cross SCADA+QMS
├── "How much did production line downtime cost?" → cross MES+ERP
└── Every analysis requires custom IT reports

#2. Core ObjectType Design

#2.1 Materials and BOM

Code

ObjectType: Material
  properties:
    materialId: STRING (PK)
    materialName: STRING
    materialType: ENUM [RAW, SEMI_FINISHED, FINISHED, PACKAGING]
    unit: STRING
    specification: STRING
    safetyStock: INT
    leadTimeDays: INT
    cost: DECIMAL
    supplier: RELATION → Supplier
  metrics:
    currentStock: METRIC(gauge, source=wms_db)
    monthlyConsumption: METRIC(counter, source=erp_db)
    avgPurchasePrice: METRIC(gauge, source=erp_db)
  derivedProperties:
    stockCoverageDays: currentStock / (monthlyConsumption / 30)
    isLowStock: currentStock < safetyStock

ObjectType: BOM (Bill of Materials)
  properties:
    bomId: STRING (PK)
    productMaterial: RELATION → Material
    version: STRING
    status: ENUM [DRAFT, ACTIVE, OBSOLETE]
    effectiveDate: DATE
    components: RELATION[] → BOMItem

ObjectType: BOMItem
  properties:
    itemId: STRING (PK)
    parentBom: RELATION → BOM
    componentMaterial: RELATION → Material
    quantity: DECIMAL
    unit: STRING
    substitutes: RELATION[] → Material
    scrapRate: DECIMAL
  derivedProperties:
    effectiveQuantity: quantity * (1 + scrapRate)
    componentCost: componentMaterial.cost * effectiveQuantity

BOM hierarchy:
  Finished Product A
  ├── Semi-finished B (x2)
  │   ├── Raw Material D (x3)
  │   └── Raw Material E (x1)
  ├── Raw Material C (x5)
  └── Packaging F (x1)

Via coomia-dip relation traversal:
  GET /api/v1/objects/BOM/bom-001/expand?depth=3
  → Auto-expands all BOM component levels

#2.2 Process Routes and Steps

Code

ObjectType: ProcessRoute
  properties:
    routeId: STRING (PK)
    product: RELATION → Material
    version: STRING
    status: ENUM [DRAFT, ACTIVE, OBSOLETE]
    steps: RELATION[] → ProcessStep

ObjectType: ProcessStep
  properties:
    stepId: STRING (PK)
    route: RELATION → ProcessRoute
    stepNumber: INT
    stepName: STRING
    workCenter: RELATION → WorkCenter
    standardTimeMinutes: DECIMAL
    setupTimeMinutes: DECIMAL
    requiredSkills: STRING[]
    qualityCheckpoints: RELATION[] → QualityCheckpoint
  derivedProperties:
    totalTimeMinutes: standardTimeMinutes + setupTimeMinutes

ObjectType: WorkCenter
  properties:
    workCenterId: STRING (PK)
    name: STRING
    workshopId: RELATION → Workshop
    equipment: RELATION[] → Equipment
    capacity: INT
    operatingHours: STRING
  metrics:
    utilization: METRIC(gauge, source=mes_db)
    oee: METRIC(gauge, source=computed)
  derivedProperties:
    availableCapacity: capacity * (1 - utilization / 100)

#2.3 Equipment and Sensors

Code

ObjectType: Equipment
  properties:
    equipmentId: STRING (PK)
    equipmentName: STRING
    equipmentType: ENUM [CNC, INJECTION, ASSEMBLY, PACKAGING, TESTING]
    manufacturer: STRING
    model: STRING
    serialNumber: STRING
    installDate: DATE
    lastMaintenanceDate: DATE
    workCenter: RELATION → WorkCenter
    maintenanceSchedule: RELATION → MaintenanceSchedule
  metrics:
    vibration: METRIC(gauge, source=iot_mqtt, unit="mm/s")
    temperature: METRIC(gauge, source=iot_mqtt, unit="C")
    current: METRIC(gauge, source=iot_mqtt, unit="A")
    spindleSpeed: METRIC(gauge, source=iot_mqtt, unit="RPM")
    powerConsumption: METRIC(counter, source=iot_mqtt, unit="kWh")
    runningHours: METRIC(counter, source=iot_mqtt, unit="h")
    cycleCount: METRIC(counter, source=iot_mqtt)
    errorCount: METRIC(counter, source=iot_mqtt)
  derivedProperties:
    healthScore: DERIVED
      expression: |
        100
        - (IF(metric("vibration","avg","5m") > 8.0, 25, 0))
        - (IF(metric("temperature","avg","5m") > 85, 25, 0))
        - (IF(metric("current","avg","5m") > ratedCurrent * 1.2, 25, 0))
        - (IF(metric("errorCount","sum","1h") > 5, 25, 0))
    status: DERIVED
      expression: |
        CASE
          WHEN healthScore >= 80 THEN "HEALTHY"
          WHEN healthScore >= 50 THEN "WARNING"
          WHEN healthScore >= 20 THEN "DEGRADED"
          ELSE "CRITICAL"
        END
    daysSinceLastMaintenance: TODAY() - lastMaintenanceDate
    predictedFailureDays: DERIVED
      expression: |
        # Based on health score decay trend prediction
        LINEAR_REGRESSION(
          metric("healthScore", "avg", "1d"),
          window="30d",
          predictTo=20  # Predict days until health drops to 20
        )

Equipment Action:
  ActionType: CreateMaintenanceOrder
    trigger: healthScore < 50 OR daysSinceLastMaintenance > 90
    parameters:
      equipmentId: REQUIRED
      maintenanceType: ENUM [PREVENTIVE, CORRECTIVE, PREDICTIVE]
      priority: ENUM [LOW, NORMAL, HIGH, URGENT]
      assignedTechnician: RELATION → Employee

#3. Production Execution Model

#3.1 Work Orders and WIP

Code

ObjectType: ProductionOrder
  properties:
    orderId: STRING (PK)
    product: RELATION → Material
    bom: RELATION → BOM
    processRoute: RELATION → ProcessRoute
    plannedQuantity: INT
    actualQuantity: INT
    plannedStartDate: TIMESTAMP
    plannedEndDate: TIMESTAMP
    actualStartDate: TIMESTAMP
    actualEndDate: TIMESTAMP
    status: ENUM [PLANNED, RELEASED, IN_PROGRESS, COMPLETED, CANCELLED]
    priority: ENUM [LOW, NORMAL, HIGH, URGENT]
  metrics:
    completionRate: METRIC(gauge, source=mes_db)
    defectRate: METRIC(gauge, source=qms_db)
    cycleTime: METRIC(gauge, source=mes_db, unit="min")
  derivedProperties:
    yieldRate: actualQuantity / plannedQuantity * 100
    onTimeStatus: CASE
      WHEN actualEndDate <= plannedEndDate THEN "ON_TIME"
      WHEN actualEndDate IS NULL AND NOW() > plannedEndDate THEN "OVERDUE"
      ELSE "IN_PROGRESS"
    END
    estimatedCompletionTime: DERIVED
      expression: |
        actualStartDate + (cycleTime * plannedQuantity / 60)

ObjectType: WIP (Work In Progress)
  properties:
    wipId: STRING (PK)
    productionOrder: RELATION → ProductionOrder
    material: RELATION → Material
    currentStep: RELATION → ProcessStep
    currentWorkCenter: RELATION → WorkCenter
    quantity: INT
    lotNumber: STRING
    startTime: TIMESTAMP
    status: ENUM [WAITING, IN_PROCESS, QC_PENDING, COMPLETED, REJECTED]
  derivedProperties:
    waitingTime: NOW() - startTime (when status == WAITING)
    isBottleneck: waitingTime > currentStep.standardTimeMinutes * 2

#3.2 Quality Management

Code

ObjectType: QualityInspection
  properties:
    inspectionId: STRING (PK)
    wip: RELATION → WIP
    processStep: RELATION → ProcessStep
    inspector: RELATION → Employee
    inspectionType: ENUM [INCOMING, IN_PROCESS, FINAL, SAMPLING]
    inspectionTime: TIMESTAMP
    result: ENUM [PASS, FAIL, CONDITIONAL]
    measurements: JSON
    defects: RELATION[] → DefectRecord

ObjectType: DefectRecord
  properties:
    defectId: STRING (PK)
    inspection: RELATION → QualityInspection
    defectType: ENUM [DIMENSIONAL, SURFACE, FUNCTIONAL, COSMETIC]
    defectCode: STRING
    severity: ENUM [MINOR, MAJOR, CRITICAL]
    description: STRING
    rootCause: STRING
    correctiveAction: STRING
    photos: STRING[]

Quality traceability chain (via relation traversal):

  Defective Product
  │
  ├── QualityInspection (which inspection found it?)
  │   ├── inspector (who inspected?)
  │   └── processStep (which step?)
  │       └── workCenter → equipment (which machine?)
  │
  ├── WIP (which work-in-progress?)
  │   ├── productionOrder (which work order?)
  │   └── lotNumber (which batch?)
  │
  ├── BOM → BOMItem → Material (which raw materials?)
  │   └── supplier (which supplier?)
  │       └── incomingInspection (did incoming QC pass?)
  │
  └── Equipment (what was the equipment's status at the time?)
      └── metrics.vibration / temperature at inspectionTime

One API call for full traceability:
  POST /api/v1/objects/DefectRecord/def-001/trace
  {
    "direction": "UPSTREAM",
    "depth": 5,
    "includeMetrics": true,
    "metricsTimeWindow": "inspectionTime +/- 1h"
  }

#4. Supply Chain Model

#4.1 Suppliers and Procurement

Code

ObjectType: Supplier
  properties:
    supplierId: STRING (PK)
    name: STRING
    category: ENUM [STRATEGIC, PREFERRED, APPROVED, PROBATION]
    materials: RELATION[] → Material
    certifications: STRING[]
    leadTimeDays: INT
    paymentTerms: STRING
  metrics:
    onTimeDeliveryRate: METRIC(gauge, source=erp_db)
    qualityRejectRate: METRIC(gauge, source=qms_db)
    avgLeadTime: METRIC(gauge, source=erp_db)
  derivedProperties:
    supplierScore: DERIVED
      expression: |
        onTimeDeliveryRate * 0.4 +
        (100 - qualityRejectRate) * 0.3 +
        (1 - avgLeadTime / expectedLeadTime) * 100 * 0.3
    riskLevel: CASE
      WHEN supplierScore >= 80 THEN "LOW"
      WHEN supplierScore >= 60 THEN "MEDIUM"
      ELSE "HIGH"
    END

#4.2 Inventory Management

Code

ObjectType: InventoryLot
  properties:
    lotId: STRING (PK)
    material: RELATION → Material
    quantity: DECIMAL
    warehouse: RELATION → Warehouse
    location: STRING
    receivedDate: DATE
    expiryDate: DATE
    supplier: RELATION → Supplier
    purchaseOrder: RELATION → PurchaseOrder
    qualityStatus: ENUM [PENDING_QC, APPROVED, REJECTED, QUARANTINE]
  derivedProperties:
    daysToExpiry: expiryDate - TODAY()
    isExpiringSoon: daysToExpiry < 30 AND daysToExpiry > 0
    isExpired: daysToExpiry <= 0
    fifoOrder: receivedDate  # First-in-first-out ordering

#5. Production Dashboard and KPIs

#5.1 Workshop-Level Dashboard

Code

ObjectType: Workshop
  properties:
    workshopId: STRING (PK)
    name: STRING
    workCenters: RELATION[] → WorkCenter
    shiftSchedule: JSON
  derivedProperties (aggregating child metrics):
    totalOEE: AVG(WorkCenter.oee)
    activeOrders: COUNT(ProductionOrder WHERE status == "IN_PROGRESS")
    todayOutput: SUM(ProductionOrder.actualQuantity WHERE actualEndDate == TODAY())
    defectRate: AVG(ProductionOrder.defectRate)
    equipmentHealthAvg: AVG(Equipment.healthScore)
    criticalEquipmentCount: COUNT(Equipment WHERE status == "CRITICAL")

Workshop dashboard data model:
┌─────────────────────────────────────────────────────┐
│  Workshop: Stamping Workshop                         │
│                                                      │
│  OEE: 78.5%    Active Orders: 12    Output: 4,523   │
│  Defect: 1.2%  Equip Health: 85.3   Warnings: 2     │
│                                                      │
│  Work Orders:                                        │
│  [PO-001: In Progress 67%] [PO-002: In Progress 34%]│
│  [PO-003: Waiting Material] [PO-004: Planned]        │
│                                                      │
│  Equipment Status:                                   │
│  CNC-01: OK 92  CNC-02: OK 88  CNC-03: WARN 45     │
│  CNC-04: OK 91  CNC-05: OK 87  CNC-06: OK 95       │
│                                                      │
│  Quality Trend:                                      │
│  [Last 7 days defect rate trend chart]               │
└─────────────────────────────────────────────────────┘

All data from Ontology unified queries,
no need to fetch separately from MES + SCADA + QMS.

#6. Predictive Maintenance Model

#6.1 Maintenance Strategy Comparison

Code

Three maintenance strategies implemented via Ontology:

Strategy 1: Time-Based Maintenance
  trigger: daysSinceLastMaintenance >= maintenanceInterval
  Drawback: May over-maintain or under-maintain

Strategy 2: Condition-Based Maintenance
  trigger: healthScore < 50
  Improvement: Based on actual condition, reduces unnecessary maintenance

Strategy 3: Predictive Maintenance
  trigger: predictedFailureDays < 14
  Optimal: Predict and schedule before failure occurs

coomia-dip predictive maintenance flow:
  1. Equipment sensor data → Metric properties (real-time collection)
  2. healthScore derived property (recomputed every minute)
  3. predictedFailureDays derived property (based on trend analysis)
  4. Alert rule: predictedFailureDays < 14
  5. Action: CreateMaintenanceOrder (auto-create work order)
  6. Maintenance complete → lastMaintenanceDate updates → healthScore recomputes

Closed-loop automation, no manual equipment monitoring needed.

#7. Energy Management Model

Code

ObjectType: EnergyMeter
  properties:
    meterId: STRING (PK)
    meterType: ENUM [ELECTRICITY, GAS, WATER, STEAM, COMPRESSED_AIR]
    equipment: RELATION → Equipment (optional)
    workCenter: RELATION → WorkCenter (optional)
    workshop: RELATION → Workshop (optional)
  metrics:
    consumption: METRIC(counter, source=iot_mqtt)
    instantPower: METRIC(gauge, source=iot_mqtt)
    peakDemand: METRIC(gauge, source=iot_mqtt)
  derivedProperties:
    dailyConsumption: metric("consumption", "sum", "1d")
    monthlyConsumption: metric("consumption", "sum", "30d")
    costEstimate: monthlyConsumption * unitPrice
    consumptionPerUnit: monthlyConsumption / workshop.todayOutput

Energy analysis hierarchy:
  Factory → Workshop → Work Center → Equipment
  Each level auto-aggregates child energy consumption
  Auto-calculates Energy Per Unit produced

#8. Relationship Network Overview

Code

Core relationship network for manufacturing Ontology:

Supplier ──supplies──→ Material
Material ──usedIn──→ BOMItem ──partOf──→ BOM
BOM ──definesProductionOf──→ Material (finished)
ProcessRoute ──routeFor──→ Material (finished)
ProcessStep ──partOf──→ ProcessRoute
ProcessStep ──performedAt──→ WorkCenter
WorkCenter ──contains──→ Equipment
WorkCenter ──locatedIn──→ Workshop
ProductionOrder ──produces──→ Material
ProductionOrder ──usesBom──→ BOM
ProductionOrder ──followsRoute──→ ProcessRoute
WIP ──belongsTo──→ ProductionOrder
WIP ──atStep──→ ProcessStep
QualityInspection ──inspects──→ WIP
DefectRecord ──foundIn──→ QualityInspection
InventoryLot ──stores──→ Material
InventoryLot ──from──→ Supplier
Equipment ──monitors──→ EnergyMeter

Total relation types: 18
Total ObjectTypes: 15

#9. Practical Example: Injection Molding Workshop

#9.1 Scenario Description

Code

Injection molding workshop Ontology modeling:

Workshop overview:
├── 20 injection molding machines (various tonnages)
├── Annual output 5 million pieces
├── 3-shift operation
├── Primarily produces automotive interior parts

Problems to solve:
├── Machine health monitoring (reduce unplanned downtime)
├── Mold life management (predict replacement timing)
├── Injection parameter and quality correlation analysis
├── Energy optimization (reduce per-unit energy consumption)
└── Complete quality traceability chain

#9.2 Core Model

Code

ObjectType: InjectionMachine
  properties:
    machineId, machineName, tonnage, manufacturer
    mold: RELATION → Mold (currently installed mold)
  metrics:
    clampingForce, injectionPressure, injectionSpeed
    barrelTemperature, moldTemperature
    cycleTime, cushionLength
    shotWeight, partWeight
    powerConsumption

ObjectType: Mold
  properties:
    moldId, moldName, cavityCount, material
    maxShotCount, currentShotCount
    lastMaintenanceDate
  derivedProperties:
    remainingLife: (maxShotCount - currentShotCount) / maxShotCount * 100
    estimatedRemainingDays: remainingLife / avgDailyShotCount

ObjectType: InjectionParameter (injection recipe)
  properties:
    parameterId, product, mold, machine
    injectionPressure, holdingPressure, backPressure
    injectionSpeed, screwSpeed
    barrelTemp1, barrelTemp2, barrelTemp3, nozzleTemp
    coolingTime, cycleTime

Correlation analysis example:
  When defect rate increases, auto-correlate:
  1. Whether injection parameters deviate from standard recipe
  2. Whether mold remaining life is too low
  3. Machine health score
  4. Whether raw material batch changed
  → Auto-generate root cause analysis report

#10. Alignment with Industry 4.0

Code

coomia-dip manufacturing Ontology aligned with Industry 4.0:

┌──────────────────┬────────────────────────────────┐
│ Industry 4.0     │ coomia-dip Implementation       │
├──────────────────┼────────────────────────────────┤
│ Digital Twin     │ Equipment ObjectType + RT Metrics│
│ Smart Factory    │ Workshop/Line ObjectType hierarchy│
│ Predictive Maint │ Derived property + trend + Action│
│ Quality 4.0      │ Traceability chain + correlation │
│ Mass Customization│ BOM versioning + route variants │
│ Supply Chain 4.0 │ Supplier ObjectType + risk score │
│ Energy Management│ Energy meter ObjectType + agg   │
│ Traceability     │ Batch → Step → Equipment chain  │
└──────────────────┴────────────────────────────────┘

Core value:
  Traditional: 5 systems each managing their own silo
  coomia-dip: Unified Ontology model, all data interconnected
  One query answers complex cross-system questions

#Key Takeaways

Manufacturing Ontology's core is the "Material-Process-Product" triad — BOM defines "what to use," process routes define "how to make," and production orders connect them. coomia-dip models this precisely with ObjectTypes and RelationTypes.
Equipment Ontology + real-time Metrics = Digital Twin foundation — each machine's sensor data flows in as Metric properties in real-time, healthScore derived property auto-recomputes every minute, and predictedFailureDays enables predictive maintenance.
Quality traceability chain is the quintessential relationship network application — from a defective product, trace upstream through batch, process step, equipment, operator, and raw material in one API call, replacing hours of manual investigation.
Multi-layer aggregation delivers equipment-to-factory visibility — equipment-level metrics aggregate to work center, work center to workshop, workshop to factory, each level with auto-computed OEE, output, and defect rate.
Action mechanism enables closed-loop automation — equipment health drops, auto-create maintenance order; inventory below safety stock, auto-trigger procurement; quality anomaly, auto-stop line and notify — from "seeing problems" to "auto-handling."

#Next Article

The next article S4-17 Financial Risk Ontology Modeling discusses how to express the financial domain's complex relationship networks using the Ontology model — customers, accounts, transactions, products, and risk events — how derived properties compute risk metrics in real-time, and how relation traversal discovers hidden correlations.

#ontology #manufacturing #industry-4.0 #digital-twin #predictive-maintenance #quality-traceability #bom #mes #oee