How to design a unified data model across MES modules

Anchor every module on the ISA-95 object models: equipment, physical assets, material (class, definition, lot) and personnel, with typed links between them and company-specific fields held as properties. Then map each source's signal names, units and identifiers once into shared fields, and describe machine data with an OPC UA information model so any module or tool reads it the same way.

Take a cooling water pump. A work order reaches that pump through its ISA-95 equipment key. What its discharge pressure reading means comes from an OPC UA companion specification. Keys assigned once let every module join to the same records.

Which entities should every module reference?

The object models and attributes exchanged between manufacturing operations management activities are standardized (see ISA-95, Part 4). The OPC UA common object model for ISA-95 (OPC 10030) names four primary types of information that systems must exchange: material and its properties, equipment as it pertains to the operations performed, the physical assets that make up the equipment, and personnel with their roles and qualifications. Those four are your reference entities.

Work orders and operations are activity records. They should not carry their own copies of equipment or material descriptions. They link to the equipment, material lot and personnel records by key.

Two distinctions matter for clean joins:

• Class versus instance. The resource models separate classes from instances. A pump class holds what is true of every pump of that kind; an instance is the one in your engine room. "Class" here means a classification, not a UML class.
• Material in three levels. Material class identifies materials regardless of source. Material definition identifies material from a specific vendor or source. Material lot identifies the actual material, its location and its quantity. A procurement record keys to the definition, and a consumption or failure record keys to the lot.

The core model holds a minimum set of industry-independent attributes. Industry-specific, application-specific and company-specific information goes in property objects attached to the entity, per the ISA property model described in OPC 10030. Resist adding columns to the core entity for one module's needs.

How do you normalize signal names, units and identifiers?

Each OEM names, scales and times its signals differently. Normalizing means reconciling those naming conventions, units and reporting intervals into one coherent model. Do the mapping once, at the source boundary, and never again per consumer.

A shared signal definition should carry five fields:

• Signal identifier. One stable ID for the quantity, such as main engine exhaust temperature on cylinder 3. Without it, two OEM tags for the same measurement look like two different things.
• Asset link. A reference to the equipment instance (and through it the class). This is what lets a reading join to a work order or a warranty term.
• Unit. The canonical unit, with the conversion applied at mapping time. Comparing a Celsius engine against a Fahrenheit one is a silent error otherwise.
• Reporting interval. How often the source emits the value. A one-second signal and a one-minute signal cannot be compared point for point without knowing this.
• Source name. The OEM's original tag, kept so the mapping is auditable and can be corrected in one place.

This is the translation work that normalizing OEM telemetry across manufacturers covers in more detail. Once it exists, a new dashboard or model reads the shared fields and never touches the OEM tags.

Which information-model standard should describe machine data?

Use OPC UA information models when the machine or its gateway exposes an OPC UA server. An OPC UA companion specification (OPC 40001-1, section 4.2.3.3) for a vertical market defines ObjectTypes, VariableTypes, DataTypes and ReferenceTypes for the concepts that market uses. The machine tools specification, OPC 40501-1, for example, aims at a common interface among machines of different technologies, manufacturers and model series. That is the same problem you have with a mixed fleet.

The rule flips when a source has no OPC UA server. Map its tags into the shared signal definition above and borrow the companion specification's concept names where they fit.

The MES-to-ERP interface is a separate job. Information exchange profiles for exchanges between level 4 and level 3, or between level 3 activities, are defined through a Part 8 method. A profile sets the verbs and nouns used for an implementation, so use Part 8 there rather than OPC UA types.

The decision rule for extending a model:

• Use a companion specification as is when it already describes the machine. Pick only the building blocks you need; the modelling best practices (section 10) note these specifications are not all-or-nothing.
• Reuse by composition, not subtyping. The same guidance recommends composition over subtyping when using another specification's concepts. Add the reused type as a component of your own object type, and instances can pick up new features without changing the model.
• Put local needs in properties. A company-specific field, such as a fleet-specific inspection code, belongs in a property on the entity. Create a new type only when the thing has its own identity and relationships.

How does one schema answer questions across maintenance, warranty, procurement and telemetry?

A cross-record query works when every record carries the same keys. A maintenance entry and the warranty record for the same component stay unconnected until someone builds the link. With a shared schema, that link is a typed relationship that already exists.

Here is one failed pump traced through those joins:

• The discharge pressure signal, keyed by its signal identifier, drifts. Its asset link points to the pump's equipment instance.
• That equipment instance key finds the work order for the seal replacement, and the work order's personnel link names who did the job.
• The work order's material lot key finds the replacement seal that went in. The lot points to its material definition, which names the vendor.
• The same material definition and equipment instance reach the vendor's warranty terms and any open claim.

Every step reuses a key assigned once, so no module needs its own copy of the pump. With those joins in place, one query against an asset can pull telemetry, maintenance history, warranty status and procurement cost together, instead of someone checking five systems by hand. Tracing a repeat failure through maintenance, procurement and personnel records is the same query shape.

SailPlan's schema sits on top of your MES, historian and maintenance software and leaves them in place. Our published work and deployments are in maritime, which is why the examples here come from engine rooms and fleets. The mapping is done once, and new models, agents and dashboards connect to the same schema rather than each needing its own connectors. Normalized telemetry also puts assets on one footing for comparison; where anomaly detection breaks across OEMs and which methods rank best show what that allows. More schema-design write-ups are on the Insights page.

Related resources

• How to Normalize OEM Telemetry Across Manufacturers
• Anomaly Detection Across Mixed OEM Equipment: Where It Breaks
• Anomaly Detection Across Mixed OEM Equipment: Methods Ranked
• Insights — SailPlan