Building a factory model with ISA-95

A factory has no shortage of data. The difficult part is knowing what the data describes and how it relates to everything else.

A tag called Line1.Power might be obvious to the engineer who created it. It is less obvious to a scheduling system trying to calculate the energy cost of a production order, or to someone comparing the same machine across five sites.

To answer those questions, one needs a model of the factory. ISA-95 is a good place to start.

What ISA-95 gives you

ISA-95, also published internationally as IEC 62264, is a set of standards for integrating manufacturing control systems with business systems. It defines common terminology, system boundaries, activities, and information models.

The familiar ISA-95 levels are:

• Level 0: the physical production process.
• Level 1: sensing and manipulating the process.
• Level 2: monitoring and supervisory control.
• Level 3: manufacturing operations management.
• Level 4: business planning and logistics.

The standard mainly concerns the boundary between manufacturing operations at Level 3 and business systems at Level 4. This is where operations requests, schedules, resource requirements, and performance results have to move between systems without everyone inventing a different meaning for them.

The levels are useful, but they are not the main reason I use ISA-95 when building a factory model. The value is the vocabulary underneath them: equipment, materials, personnel, segments, requests, schedules, and performance.

ISA-95 gives us a shared language. It does not give us a PostgreSQL schema that should be copied table for table.

Start with the questions

It is tempting to begin by modeling the entire standard. This will produce a large and impressive schema before it produces anything useful.

I prefer starting with the questions the model needs to answer:

• Where is this machine in the factory?
• What material or utility flows through it?
• Which measurement belongs to which machine or flow?
• What process is supposed to happen here?
• Which production order was running at 10:30?
• How much electricity did that order use?
• Which input lots ended up in this finished product?
• Why did the line miss its target?

These questions quickly expose the concepts and relationships that are actually required. They also provide tests for the model. If the schema contains 40 tables but still cannot answer which machine consumed the most steam last Tuesday, the model is not finished.

A factory is more than one graph

I use “factory graph” as a description of the relationships, not as a requirement to use a graph database. A relational database handles most of this well.

The important part is recognizing that a factory contains several overlapping graphs:

They are related, but they are not interchangeable.

The equipment hierarchy

The equipment hierarchy describes containment:

Enterprise
└── Site
    └── Area
        └── Work Center
            └── Work Unit

This is the backbone of the model. A self-referencing equipment table is usually enough to represent it:

CREATE TYPE equipment_level AS ENUM (
    'Enterprise',
    'Site',
    'Area',
    'WorkCenter',
    'WorkUnit'
);

CREATE TABLE equipment (
    id                  BIGSERIAL PRIMARY KEY,
    ref_id              VARCHAR(64) UNIQUE NOT NULL,
    name                VARCHAR(255) NOT NULL,
    level               equipment_level NOT NULL,
    parent_equipment_id BIGINT REFERENCES equipment(id)
);

The application or additional database constraints should prevent cycles and invalid parent-child level combinations.

The hierarchy lets one aggregate measurements and production results from a machine to a line, area, site, or enterprise. It also gives every other object a stable location in the factory.

Do not confuse a logical equipment position with the physical asset currently installed there. “Filler 1” may be a permanent position in the process while the motor, meter, or complete machine occupying it changes over time. If replacement history matters, model physical assets separately and assign them to equipment with start and end timestamps.

The physical topology

Containment does not describe flow.

A boiler may sit in a utilities area while supplying steam to three production lines in another area. A buffer may receive material from two machines and feed a third. None of this can be inferred from the equipment hierarchy.

Represent those relationships explicitly:

CREATE TABLE flow_connection (
    id                BIGSERIAL PRIMARY KEY,
    ref_id            VARCHAR(64) UNIQUE NOT NULL,
    from_equipment_id BIGINT NOT NULL REFERENCES equipment(id),
    to_equipment_id   BIGINT NOT NULL REFERENCES equipment(id),
    material_id       VARCHAR(64) REFERENCES material(id),
    CHECK (from_equipment_id <> to_equipment_id)
);

This graph answers questions about material, energy, water, steam, compressed air, waste, and emissions. It should not also be forced to represent process sequence. A pipe between two machines and the rule that operation B follows operation A are different facts, even when they happen to point in the same direction.

Process intent

ISA-95 uses segments to describe reusable work and its resource requirements. In a production example, a segment can require:

• an equipment class or specific machine
• input and output materials
• personnel or a personnel class
• parameters such as temperature, pressure, speed, or target cycle time

A workflow or route connects segments in the required order. This is what should happen, independent of a specific order or Tuesday's production result.

Keeping process intent separate from physical topology makes the model much more useful. The same process step may run on one of four equivalent machines. The route stays the same while the equipment assignment changes.

Operations and production execution

The 2026 edition of IEC 62264-2 uses generalized operations models rather than separate production-only schedule and performance models. This allows the same structure to describe production, maintenance, quality, and inventory work. I focus on production here, but the separation is the same:

Demand → Schedule → Dispatched work → Performance

For production, a request might say: make 5,000 units of product X by Friday. A schedule assigns time and resources. Dispatch turns scheduled work into executable job orders. Performance records actual start and end times, quantities produced, quality results, and the resources used.

This separation is necessary for plan-versus-actual reporting. If a schedule row is continuously edited until it resembles reality, the original plan is lost. Keep versions of the plan and record actual performance separately.

It also provides the data required for OEE: planned production time, runtime, ideal cycle time or rate, total count, and good count.

Materials and genealogy

A material definition and a material lot are not the same thing.

“Steel grade X” is master data. “Lot S-2026-0814” is a particular quantity of that steel received or produced at a particular time. Recipes and process segments normally refer to material definitions. Traceability refers to lots.

Once execution results are linked to consumed and produced lots, genealogy becomes another directed graph:

Input lot A ─┐
             ├── Production run ── Output lot C
Input lot B ─┘

This supports recalls, quality investigations, and product-level cost or emission attribution. It is useful, but not every first version of a factory model needs it. Add lot genealogy when there is a real traceability question to answer.

Measurements

A measurement point defines the meaning of a signal. A reading carries the observed value and timestamp, normally with a quality or status indicator.

The point should identify:

• what is measured
• the unit of measure
• whether it belongs to equipment or a flow connection
• the material or utility, where relevant
• whether it is physical or calculated
• which sensor or calculation provided it during a given time range

This distinction keeps the logical point stable when a meter is replaced. Historical readings remain attached to “Steam flow into Line 2” even though the physical device has changed.

I would normally keep this metadata in the relational model and store high-volume readings in a time-series database. At 1 Hz, 10,000 tags generate 864 million readings per day. The factory model should provide context for those readings without forcing every reading through the same transactional database used for equipment, recipes, and schedules.

Units and time are part of the model

Units should not be stored as inconsistent free text across sensor and material tables. For gas volumes, m³ identifies the unit of volume but does not state the temperature and pressure conditions. A value expressed in Nm³ has been normalized to defined reference conditions. Those conditions must also be recorded.

A unit dictionary should include a stable code, symbol, quantity kind, quantity dimension, and, where valid, a deterministic conversion to a canonical unit. Every measured or calculated quantity should reference a defined unit. Cost and emission factors must also state their unit explicitly.

Time validity matters for the same reason. Electricity tariffs change. Emission factors change. Assets are replaced. A sensor is remapped. A machine moves to another line.

If the model overwrites these relationships, historical calculations can silently change. Store valid_from and valid_to for any fact whose value or assignment can change over time.

Build it in layers

The first useful version does not need the whole standard. I would build it in three layers.

Layer 1: structure and measurements

Start with:

• equipment and its hierarchy
• material and utility definitions
• physical flow connections
• measurement points and units

This is enough to browse the factory, map sensor data, and answer basic consumption questions by equipment, line, or site.

Layer 2: process and execution

Add:

• segment definitions and workflows
• equipment, material, and personnel requirements
• operations requests and schedules
• dispatched work or job orders
• performance results

Now the model can connect what should happen to what did happen. Scheduling, OEE, throughput, and resource attribution become possible.

Layer 3: traceability and optimization

Add these only where required:

• material lots and genealogy
• personnel capabilities
• asset assignment history
• time-valid cost and emission factors
• storage capacity and compatibility
• changeover costs and scheduling constraints

This is where a factory model becomes valuable for optimization, product costing, emissions accounting, and traceability. It is also where complexity increases quickly. Each extension should still be justified by a question or workflow.

Common mistakes

Putting everything in one node and edge table

A generic graph looks flexible at first. Eventually every query depends on a growing list of node types, edge types, and JSON properties. Database constraints become difficult and invalid relationships become easy.

Use explicit tables for concepts with different rules. An equipment hierarchy, process dependency, material genealogy edge, and steam connection can all be traversed as graphs without pretending they are the same relationship.

Copying ISA-95 literally

ISA-95 is a conceptual standard designed to work across industries and systems. Your implementation serves a particular product and set of factories.

Keep the standard's semantics, but use names your team understands. Document the mapping. Do not add tables merely because an object exists somewhere in the standard.

Mixing definitions, plans, and actuals

A recipe is not a production order. A production order is not a schedule. A schedule is not a production result.

Combining them makes the first demo faster and every later analysis harder. Keep intent, plan, dispatch, and actual performance separate.

Ignoring identity

The same machine will have different IDs in ERP, MES, SCADA, maintenance, and the historian. Pick a stable internal identity and keep aliases per source system. Avoid making a display name or one vendor's identifier the primary key for the whole factory.

Modeling before asking

The most dangerous version of a factory model is one that is technically elegant but operationally irrelevant.

Start with five to ten questions from engineers, planners, operators, and managers. Build the smallest model that answers them. Add the next concept when the next question requires it.

The model is the integration layer

ISA-95 was created to make integration between manufacturing and business systems less ambiguous. That remains the useful idea.

A factory model should allow a production request from ERP, a machine state from a PLC, a meter reading from a historian, and a finished quantity from MES to refer to the same operational context.

The final schema will differ between a steel mill, a battery plant, and a food factory. The underlying questions are similar: where did this happen, what was supposed to happen, what actually happened, what went in, what came out, and what did it cost?

ISA-95 gives us a solid language for answering those questions. The work is choosing how much of that language the factory actually needs.

If building software for factories sounds interesting, take a look at the open roles at Juna AI.