Articles
16 minutes
Copy Link
Industrial Edge Computing and Industrial Ontologies: Turning Factory Signals Into Decision-Ready Data
TL;DR
Industrial edge computing handles protocol translation, buffering, filtering, and local processing near factory equipment.
Industrial ontologies connect normalized signals to asset identities, operating states, relationships, and business meaning.
An industrial data fabric can deliver clean, timestamped signals, but operational decisions also require context about equipment, orders, constraints, and current conditions.
Humble Operations consumes contextualized factory data and produces auditable decisions. It complements edge infrastructure, data platforms, and MES software rather than replacing them.
This reference architecture applies standards-based reasoning and clear category boundaries. It does not represent a single vendor’s marketing model.
What industrial edge computing actually means
Industrial edge computing places compute and storage within the plant network, near ISA 95 Levels 1 through 3, when an application cannot depend on continuous communication with enterprise or cloud services. PLCs and distributed control systems operate at Levels 1 and 2, while plant operations systems generally occupy Level 3. Edge gateways often sit near the boundary between control and manufacturing operations networks.
Five processing categories commonly belong at the edge.
Protocol translation converts device specific communications into formats that plant and enterprise applications can consume.
Buffering and store and forward preserve readings during network interruptions, then transmit them when connectivity returns.
Filtering and aggregation reduce unnecessary data movement by calculating useful events, counts, or time windows locally.
Deterministic control remains in PLCs, safety controllers, and other control equipment that can meet strict timing requirements. A general purpose gateway should not assume these duties.
Local inference runs a trained model near the equipment when latency, bandwidth, or continued operation during WAN loss requires local execution.
Workloads belong above the edge when they need cross plant history, enterprise records, or centralized analysis more than immediate local response. An edge node might detect an abnormal vibration pattern, for example, while a central platform compares that event with maintenance history and asset relationships across several plants.
Architects should use ISA 95 to define functional boundaries, OPC Foundation documentation to specify OPC UA communication and information models, and NIST SP 800 82 to assess industrial control system security. Those sources provide separate guidance for architecture, interoperability, and security, so no single model settles every deployment decision.
Why normalized signals cannot support decisions on their own
A normalized signal records a value in a consistent format, but it rarely explains what the value means operationally. A tag such as Zone3.Temp = 92.4°C may include a timestamp and unit. The tag still may not identify the physical sensor, the equipment it monitors, or the production state when the reading occurred. It also lacks the applicable recipe limit and work order context.
An industrial data fabric connects industrial data sources with storage, analytics, and applications. It provides shared services for collecting, transporting, governing, and accessing data across plant and enterprise systems. Protocol translation and schema normalization can make signals consistent across equipment vendors. Those functions do not automatically encode asset relationships, operating states, or business meaning. The guide to integrating shop floor data without replacing ERP or MES explains the underlying connection patterns.
A unified namespace serves a narrower purpose. It gives systems a shared naming and publication structure for operational data, often through an event based messaging pattern. The namespace helps producers and consumers find the same signals without building separate connections for every application. An industrial data fabric can include a unified namespace, but it may also provide connectors, storage, governance, and access controls beyond that shared structure.
A decision requires contextualized facts rather than isolated values. Before an application can decide whether to adjust an oven, it must know which oven zone produced the reading and which product was running. The application also needs the valid temperature range for that recipe, the duration of the deviation, and the actions it may execute. A contextual layer can then express the reading as a fact such as “Oven 2, Zone 3 exceeded the active recipe limit for four minutes during work order 481.” Decision software can evaluate that fact against operating rules and constraints.
How industrial ontologies add asset and operational context
An industrial ontology formally defines the entities in an industrial domain, their properties, and the relationships among them. It can represent a packaging line as a collection of machines, assign each sensor to a specific machine, and connect that machine to the product and operation it currently supports. The ontology can also define valid equipment states and the conditions that move an asset between those states.
A semantic model applies those definitions to actual factory data. The ontology supplies the shared concepts, while the semantic model maps tags, database records, and events to those concepts. A flat normalized schema may standardize tag names, timestamps, units, and data types. It usually cannot express that two differently named tags measure the same type of condition on equivalent assets at separate plants.
Contextualization converts a signal into a fact that software can evaluate. Consider a normalized record showing that tag TT104 reported 92 degrees Celsius at a specific time. A semantic model can identify TT104 as the outlet temperature sensor on Pasteurizer 2 and associate the reading with the active production state. An ontology can then define how that asset, state, and measurement relate. A decision layer can evaluate the resulting fact against operating constraints rather than treating 92 as an isolated number.
Asset hierarchies support queries across sites and equipment classes. Typed relationships let software follow connections between sensors, machines, operations, and production records. State and behavior definitions distinguish normal operation from startup, cleaning, maintenance, or a fault. Those structures give applications enough meaning to compare equivalent conditions and explain which evidence informed a recommendation.
Architects should consult primary specifications before selecting an implementation pattern. OPC UA information models define typed industrial information for exchange between systems. The Asset Administration Shell describes digital representations of industrial assets through structured submodels. W3C RDF and OWL provide general methods for expressing entities, relationships, vocabularies, and machine readable logic. These approaches can complement one another, but each addresses a different part of semantic interoperability.
Industrial edge computing vs. industrial data fabric vs. ontologies vs. MES vs. decision layers
Industrial edge computing processes machine data near equipment. An industrial ontology adds asset and operational context, while an MES manages plant execution within the ISA-95 operations boundary.
Layer | Primary function | Where it runs | Data consumed and produced | What it cannot do alone |
|---|---|---|---|---|
Industrial edge computing | Collects signals and performs local translation, buffering, filtering, aggregation, or inference | Near machines or within the plant network | Consumes controller tags and device events. Produces normalized signals and event streams | It cannot determine the business meaning of a signal or choose an operational response |
Industrial data fabric | Moves and governs data across plant and enterprise sources | Across plant, data center, and cloud infrastructure | Consumes normalized streams, historian records, and business data. Produces accessible, governed datasets | It cannot infer asset relationships, operating states, or decision logic |
Industrial ontology | Defines assets, relationships, states, constraints, and shared operational meaning | In a central or federated semantic service | Consumes identifiers, schemas, and operational records. Produces contextualized facts | It cannot collect machine signals or manage production execution |
MES or MOM | Coordinates and records production operations within the ISA-95 plant operations boundary | Primarily at the plant level | Consumes orders, routes, material records, and machine events. Produces execution status, genealogy, and production records | It cannot replace machine control or supply every cross plant decision |
Decision layer | Evaluates contextualized facts against constraints and objectives | At the plant, in the cloud, or across both | Consumes operational facts and business priorities. Produces recommendations, workflows, or approved writebacks | It cannot compensate for missing context or unreliable source data |
A unified namespace provides a shared structure for publishing data. An industrial data fabric adds broader delivery, governance, and access functions. Individual products may cover several rows, but architects still need to assign each responsibility explicitly.
Where Palantir Foundry's ontology model fits — and its limits for plant-floor decisions
Palantir Foundry illustrates how an enterprise ontology can support operational decisions above factory systems. A secondary strategic analysis says Foundry maps data from ERP systems, sensors, CRM platforms, and spreadsheets to business objects such as products, facilities, and supply chains. Relationships between those objects give applications more context than normalized tables or timestamped tags provide.
The same analysis describes a closed loop model in which applications write decisions back into the ontology. Conceptually, Foundry therefore spans semantic modeling and operational applications. An application could evaluate a facility, its orders, and its supply constraints as related objects rather than querying each source independently.
Foundry does not replace the plant floor stack in this architecture. Edge infrastructure still translates protocols, buffers signals, and supports local operation. MES software still manages production execution and records shop floor activity. Foundry can consume data from those layers and provide enterprise context above them.
The available source is a third party Scribd upload rather than Palantir technical documentation. It does not verify Foundry action type mechanics, manufacturing edge deployment, multi plant architecture, or interfaces for executing decisions in control and MES systems. Architects should therefore treat Foundry as an example of the ontology and application pattern, not as a documented benchmark for plant floor control or execution.
A sample multi-plant reference architecture
A multi plant architecture should preserve local plant operation while giving central applications a consistent view of assets, production states, and constraints. The following logical flow traces one machine signal through each layer.
Per site control and edge layer
A PLC records a motor temperature, and SCADA presents the operating state to plant personnel. An edge service reads the signal, adds a timestamp and source identifier, filters unusable readings, and buffers data when an upstream connection fails. Local control remains with the PLC or other plant control system.
Central industrial data fabric
The edge service publishes the normalized signal to a shared data fabric. The fabric transports and stores the reading under a consistent data contract. A data fabric can expose the same signal to historians, analytics tools, and plant applications, but the normalized value still lacks enough operational context for a production decision.
Central ontology and semantic layer
The ontology links the motor to its machine, production line, plant, product route, and maintenance state. It can also define that the temperature reading belongs to a specific operating mode and threshold policy. The signal now represents a fact about a known asset in a known operational state.
Per plant MES layer
Each plant MES contributes local production context such as the active work order, operation status, material consumption, and recorded completion. The MES remains the plant level system of record for execution. The architecture does not require every plant to use the same MES if the ontology maps local identifiers into shared concepts.
Cross plant decision layer
A decision layer combines contextualized equipment data with MES facts and relevant ERP constraints. For example, it can assess whether a machine condition threatens an order and evaluate production on another qualified line. Approved actions should return through governed MES, ERP, or plant workflows rather than bypassing those systems to write directly to a PLC.
This reference flow describes logical responsibilities, not a prescribed network topology. Any production design needs authoritative IEC 62443 and Purdue Model sourcing before specifying security zones, conduits, trust boundaries, or remote access paths. Requirements for site autonomy during WAN loss also need explicit design validation, including which local services continue operating and how buffered events reconcile after connectivity returns.
Implementation sequence: from signal collection to decision execution
Collect trustworthy signals at the edge. Connect PLCs, sensors, and other plant systems while preserving timestamps, engineering units, quality codes, and source identifiers. Edge components should buffer data during network interruptions and forward it after connectivity returns. PLCs and safety systems should retain deterministic control.
Normalize signals into a stable representation. Translate source protocols and tag formats into consistent names, units, timestamps, and data types. An industrial data fabric can then route and store these normalized signals without requiring every consuming application to understand each machine protocol.
Add operational context through an ontology. Map normalized tags to specific assets, lines, products, work orders, and operating states. The ontology should also represent relationships such as which machine belongs to a line and which order was active when an event occurred. Versioned mappings help you trace how a decision used the available context.
Connect records from MES and ERP systems. MES records can supply production events, while ERP records can supply demand and order information. Shared identifiers allow the contextualized signal to reference the correct production record. Reconcile identifier conflicts before adding automated decisions.
Introduce the decision layer in advisory mode. Start with a bounded use case and define acceptance criteria before the system recommends actions. Compare recommendations with actual outcomes and retain the evidence, constraints, and model version behind each recommendation.
Add controlled execution after validation. Approved decisions can flow into operator workflows or connected business systems according to explicit permissions. Feedback about execution and outcomes should return to the decision layer so you can evaluate performance and revise rules. The guide to implementing AI production scheduling without replacing ERP or MES applies this controlled rollout pattern to a specific decision-layer use case.
A limited pilot should prove the full sequence on one line or plant before you expand it. Reusable asset definitions and interface contracts can then support additional sites without copying every local tag structure.
Common sequencing mistakes break these dependencies. A decision layer cannot compensate for unidentified assets or inconsistent units. Central aggregation also fails when site components cannot tolerate network loss. Automating execution before validating recommendations adds operational risk and weakens auditability. Each mistake points to a failure in a specific architectural layer.
Common failure modes in edge-to-decision architectures
One gateway carries the whole site. A gateway failure then interrupts collection, translation, and upstream delivery at once. The edge layer should provide redundant paths where continuity matters, plus local buffering that preserves records during an outage.
The industrial data fabric collects values without meaning. Clean tags and timestamps cannot identify which asset produced a value or which operating state applied. A semantic layer should connect signals to asset identities, relationships, units, and production context.
The ontology drifts away from plant configuration. Renamed equipment, changed routing, and new products can leave semantic relationships stale. Ontology governance should assign ownership and update context when source systems change.
The MES becomes the universal integration layer. An MES can manage production execution while still depending on other layers for edge connectivity and shared asset meaning. Pushing every integration and analytical model into the MES creates tight coupling and makes later changes harder.
The decision layer consumes raw or loosely normalized tags. A recommendation engine cannot reliably interpret a temperature value without equipment state, production context, and applicable constraints. The decision layer should consume contextualized facts and return decisions with the supporting evidence.
No layer exposes data quality or delivery failures. Missing intervals, stale context, and delayed events can then appear valid to downstream applications. Each layer should report freshness, lineage, and processing status so you can locate the failure before acting on incomplete information.
Where Humble Operations fits as the decision layer
Humble Operations occupies the decision layer above existing manufacturing systems. It consumes contextualized, ontology backed data and combines those facts with operating constraints and captured shop floor knowledge. Humble then recommends what to do next and records the reasoning behind each recommendation, including the supporting evidence and relevant constraints.
Humble applies decision intelligence to operational problems such as production scheduling and root cause analysis. For scheduling, you can describe constraints in natural language. Humble generates optimization logic and revises that logic when materials, capacity, or priorities change. Auditable reasoning lets planners review why the software recommended a specific sequence before acting.
Humble is not an MES, edge platform, data fabric, or ontology platform. Your ERP or MES remains the system of record, while edge infrastructure continues collecting and processing machine signals. The comparison of manufacturing operations management, MES, and ERP explains how those systems divide responsibility. The industrial data fabric and ontology provide the context Humble needs to connect a factory signal with a specific asset, order, operating state, or constraint.
Book a Call with Humble to Map Your Decision Layer
Bring your current architecture and one priority use case to a call with Humble. The discussion can identify which contextualized data Humble would consume, where recommendations would enter existing workflows, and which systems would retain control.
See If Humble Fits Your Factory's Data Stack
Use the Humble fit test to assess whether the decision layer suits your current systems and operating problem. The assessment offers an early evaluation path before a detailed architecture discussion.
Vendor evaluation questions for edge, data fabric, ontology, and decision-layer buys
Edge platform Which functions continue when the plant loses its WAN connection?
Edge platform How does the platform buffer records, preserve timestamps, and forward data after connectivity returns?
Edge platform Which control functions remain with PLCs or other dedicated control systems?
Edge platform How do you deploy updates, detect configuration drift, and restore failed gateways across plants?
Edge platform Which protocols require custom connectors, and who maintains those connectors?
Industrial data fabric How does the fabric preserve source identity, units, quality codes, and event time during normalization?
Industrial data fabric How does a schema change affect existing consumers and historical records?
Industrial data fabric Can applications retrieve historical and current values through the same governed interface?
Industrial data fabric Which component owns retries, duplicate handling, access control, and data lineage?
Industrial data fabric Can you replace a broker, historian, or cloud service without rebuilding every integration?
Ontology layer How does the ontology represent assets, production relationships, operating states, and business terms?
Ontology layer Who approves model changes, and how are those changes versioned across plants?
Ontology layer How does the model map inconsistent tags and asset names to shared concepts?
Ontology layer Can users trace a contextualized fact back to its original signal and transformation?
Ontology layer How does the vendor prevent plant specific exceptions from breaking the shared model?
Decision layer Which decisions can the product recommend, approve, or execute?
Decision layer What evidence, constraints, and model versions appear in the audit record?
Decision layer How does the product respond when required context is missing, stale, or contradictory?
Decision layer Which actions write back to MES or ERP, and which remain advisory?
Decision layer How can an operator override, reverse, or suspend an automated action?
Decision layer Who retains execution authority when the decision layer or an upstream service becomes unavailable?
Subscribe to the Humble Newsletter
Get the Humble newsletter for practical guidance on manufacturing architecture, decision intelligence, and factory data systems.
Frequently asked questions
What is industrial edge computing? Industrial edge computing processes factory data close to machines and control systems. Edge software commonly handles protocol translation, local filtering, buffering during network interruptions, and workloads that cannot depend on a cloud connection.
How does industrial edge computing differ from an industrial data fabric? Industrial edge computing collects and processes signals near their source. An industrial data fabric moves governed data across plant and enterprise systems, giving applications a consistent way to access information from multiple sources.
What is the difference between an industrial ontology and a semantic model? A semantic model defines the meaning and structure of industrial data. An industrial ontology adds formal relationships and rules, such as which line contains a machine, which product ran during a fault, and which operating states permit a maintenance action.
How does an industrial ontology differ from an MES data model? An MES data model primarily supports production execution records such as orders, operations, materials, and completions. An ontology can connect those records with assets, sensor signals, constraints, operator actions, and relationships that span MES, ERP, historian, and maintenance systems.
Why are normalized factory signals not decision ready? Normalization can convert a tag into a consistent timestamp, unit, and value, but the resulting signal may still lack operational meaning. A temperature reading becomes decision ready only when software can identify the asset, production state, applicable limit, affected order, and permitted response.
Does Humble Operations replace an MES or ERP? Humble Operations serves as a decision layer above existing MES and ERP systems of record. Humble consumes operational context to support scheduling, root cause analysis, and documented recommendations with reasoning tied to evidence and constraints.
The takeaway for architects building this stack
Evaluate every new tool by how clearly it consumes and returns operational context across its interfaces. A product should preserve asset identity, operating state, and the evidence behind each transformation rather than forcing another layer to reconstruct them.
Clear boundaries matter more than choosing one vendor for the entire stack. A decision layer such as Humble can recommend actions only when the underlying data represents the right equipment, conditions, and constraints. When a vendor cannot explain what context its product requires, preserves, and passes onward, the architecture contains a dependency that you cannot reliably test or govern.