What Good Factory Data Architecture Looks Like

Good factory data architecture does not begin with a data lake. It begins with operating responsibility.

The architecture must define where information comes from, which system owns it, how it gains manufacturing context, who can act on it and how the result is preserved.

Without these decisions, factories can build impressive data estates that remain difficult to use during a shift, deviation or breakdown.

The architecture problem in manufacturing

Factory information comes from different levels and serves different purposes.

PLC and control systems need reliable, time sensitive operation. Historians preserve high frequency process values. MES manages production execution. ERP manages enterprise transactions. Quality and maintenance systems hold specialised records. Operators and supervisors create information through workflows and observations.

A good architecture should connect these systems without pretending they are interchangeable.

It should also avoid two extremes:

• Forcing every process into one replacement platform
• Leaving every system isolated and expecting people to connect the meaning manually

A seven layer factory data architecture

Layer 1: Physical and operational sources

This layer includes machines, sensors, PLCs, DCS, meters, cameras, operator observations, paper processes and local applications.

The key design question is which sources are relevant to the operating decision.

Collecting every available tag may increase cost without improving action.

Layer 2: Edge connectivity and secure acquisition

The edge layer connects operational technology to the digital environment.

It may handle protocol translation, buffering, local processing and secure outbound communication. The design must respect OT network boundaries and avoid introducing uncontrolled write access.

In the Df-OS architecture, X-Konnect and the Hectos edge gateway support machine and telemetry connectivity.

Layer 3: Source system integration

ERP, MES, QMS, CMMS, SCADA, historians and databases continue to perform their specialised roles.

The architecture defines:

• Which system is the source of record
• Which data is exchanged
• How identifiers are matched
• How timing and quality are handled
• What happens when a source is unavailable

Integration should be governed by use case, not by the ambition to move every record everywhere.

Layer 4: Event and context model

This is where values become manufacturing events.

The architecture connects data to:

• Plant, area, line and asset
• Product, batch and order
• Shift, role and operator
• Material and supplier lot
• Process step and SOP
• Event type, severity and status

This layer is often missing. It is also where a large share of decision value is created.

Layer 5: Workflow and operating execution

Data should connect to the work it is meant to influence.

This layer manages:

• Trigger
• Owner
• Response time
• Approval
• Escalation
• Evidence
• Closure

Df-OS operates at this layer by digitising factory workflows and connecting events to action.

Layer 6: Factory Metadata & Memory

This layer preserves the connected history of conditions, actions and outcomes.

It allows the factory to compare events, reuse RCA and CAPA, understand repeated failures and provide context to Vish AI.

The memory should be searchable, traceable and governed. It should not become a second uncontrolled copy of every source system.

Layer 7: Visibility and decision intelligence

The final layer serves people, dashboards, Control Towers, analytical models and Vish AI.

It should provide the right level of information for each role. An operator needs a clear next action. A plant manager needs exceptions and ownership. A CIO needs architecture, performance and governance. A model needs consistent context and boundaries.

The principles behind the layers

Preserve source ownership

ERP should not lose its role because a Control Tower needs order context. A historian should not become the workflow engine because it stores signals.

Clear ownership reduces conflict and duplication.

Separate control from insight

Machine control requires strict reliability and safety. Analytical recommendations and workflow actions have different timing and risk profiles.

The architecture should define where each type of action is permitted.

Add context close to the event

The best time to capture product, shift, process and response context is when the event occurs.

Reconstructing the relationship later is possible, but more difficult and less reliable.

Design for brownfield conditions

The architecture should support mixed protocols, intermittent connectivity, manual input and phased integration.

Build security into the flow

Network separation, outbound telemetry, identity, access control, encryption, audit and data ownership should be defined as architecture, not added after deployment.

A simple event flow

Consider a machine stop.

• The PLC produces the stop state.
• The edge layer acquires the signal securely.
• X-Konnect maps the signal to the asset and event type.
• ERP or MES provides product and work order context.
• Df-OS creates a downtime workflow and assigns ownership.
• The technician records diagnosis and action.
• The outcome becomes part of Factory Metadata & Memory.
• The Factory Control Tower updates the plant view.
• Vish AI can compare the event with similar history.

This is architecture translated into operating value.

Data architecture and the Autonomous Factory

Autonomous operations require a reliable chain from sensing to action.

The architecture must support:

• Trusted input
• Current context
• Approved decision logic
• Permissioned action
• Outcome verification
• Escalation and override

A weak layer anywhere in the chain limits autonomy.

This is why the path to the Autonomous Factory begins with architecture discipline, not only with model selection.

Questions for an architecture review

• Which systems own product, asset, workflow and decision records?
• Can events be linked across those identifiers?
• How is OT connectivity secured?
• Which context is created at the event?
• Can a signal trigger a workflow?
• Can the result of the workflow be linked back to the event?
• Is Factory Metadata & Memory searchable and governed?
• Which decisions can be recommended, guided or automated?
• How will the design scale across plants?

The Df-OS role

Df-OS is not intended to replace every layer.

It provides the factory operating layer that connects workflows, systems and decisions. X-Konnect provides machine and edge context. Vish AI uses Factory Metadata & Memory to support explanation and guided action.

This architecture respects existing ERP, MES, PLC, SCADA and historian investments while creating the connected operating environment they do not provide alone.

Final perspective

Good factory data architecture is not defined by the number of platforms or the size of the repository.

It is defined by whether the plant can move reliably from signal to context, from context to action and from action to learning.