Unified Object Model for Industrial Data: Group-Factory-Line-Equipment-Tag Framework

Unified Model Must First Answer: Who Owns the Data?

In different systems, the same object may have different names. For example, a raw meal mill may be called "RM1" in the DCS, "Raw Meal Vertical Mill 01" in the equipment system, and grouped under "Raw Meal Preparation Line 1" in the energy system. These names are not necessarily wrong, but without a mapping relationship, systems cannot confirm they refer to the same object. The first task of a unified model is to establish a common identity for business objects so that every piece of operational data, maintenance record, quality result, and energy indicator can be linked to a definitive object.

First clarify "who is who", then discuss "how data is used".

What the Five Layers Represent

"Group-Factory-Production Line-Equipment-Tag" serves as a main line for enterprise data organization:

Group

Defines common management scope, object classification, and indicator rules.

Factory

Represents a specific production site, carrying on-site equipment, production activities, and business records.

Production Line

Represents a production unit organized by a certain process, e.g., clinker production line or cement grinding line.

Equipment

Represents assets or functional objects performing specific functions, e.g., rotary kiln, vertical mill, fan, elevator.

Tag

Represents data entry points related to the object, e.g., temperature, pressure, power, running status, setpoint.

These five layers help users locate step by step: which group, which factory, which line, which equipment, which data point.

Note: The first four layers are "objects"; the fifth layer "tag" is strictly an attribute attached to an object . This division aligns with GB/T 20720.1 (equivalent to IEC 62264-1, ISA-95) equipment hierarchy: Enterprise, Site, Area, Work Center, Work Unit. Group corresponds to Enterprise, Factory to Site, Production Line to Area or Work Center, Equipment to Work Unit. The standard does not fix the number of layers; enterprises can add or remove as needed.

Visualizing the Basic Structure

Real factories often add a "Process" layer to express production flow. For example, under a clinker production line:

Raw Meal Preparation Process

No.1 Raw Meal Vertical Mill: mill differential pressure, main motor power, outlet gas temperature

Burning Process

No.1 Rotary Kiln: kiln speed, main drive current

Clinker Cooling Process

No.1 Grate Cooler: conveyor status, zone air pressures

Whether to add process, equipment group, or component layers depends on management needs. What is unified is object meaning and association rules , not requiring all factories to have identical layers.

Build Objects First, Then Connect Data

A common approach is to ingest all tags into a platform first, then guess their ownership from names. This risks carrying historical naming issues into the new system. A more robust sequence:

Clarify organizational and production boundaries → Establish equipment and functional objects → Verify tags → Map source systems

Leverage existing documents: factory and line lists, process flow diagrams, equipment ledgers, electrical and instrumentation records, control system point tables, energy metering lists, maintenance system asset lists. Discrepancies require field verification. The model should describe the actual operating factory , not simply copy an old ledger.

This is not invented from scratch. Process industries have mature standards: ISO 15926 defines a common data model and reference data library (RDL) for plant lifecycle data; ISO 14224 specifies collection and exchange formats for equipment reliability, availability, and maintenance data. Their shared philosophy matches this article — first unify semantics of objects and attributes, then discuss data exchange between systems .

Why Unified Coding Cannot Rely on Names Alone

Names are for human reading; unique identifiers are for stable system association. For instance, "No.1 Fan" may exist on multiple lines; if equipment is renamed, historical records must not be lost. Therefore each object needs a stable internal identifier and should retain:

Standard name

Field name

Historical names

Parent object

Source system codes

Codes should not embed all information. If factory, line, location, and equipment name are hard-coded, any equipment move or org change triggers mass re-coding. Practical principle:

Identifiers stay stable, names can change, ownership relationships are traceable.

Implementation: use stable surrogate keys (e.g., system-generated UUID or Snowflake ID). For cross-enterprise, cross-system identification, connect to the Industrial Internet Identification System, e.g., GB/T 31866 (Ecode), GB/T 36461 (OID).

How to Map the Same Equipment Across Systems

Create a cross-system mapping table. For example, No.1 Raw Meal Vertical Mill has one internal ID in the unified model, linked to:

Asset number in equipment management system

Equipment name in DCS

Metering object in energy system

Statistical unit in production system

Equipment code in maintenance work orders

This establishes a common query entry without immediately modifying all source systems. However, mappings are not always one-to-one. An energy metering object may cover multiple equipment; a maintenance work order may involve multiple components. Must distinguish:

Identity correspondence vs Statistical scope inclusion .

Mixing them causes double-counting or omissions in aggregation.

Why Separate Equipment and Functional Location?

Assume a fan is replaced. From a production function view, the "Kiln Tail Exhaust Fan" position still exists. From an asset view, the old fan is retired, the new fan has a new serial number, commissioning date, and maintenance history. Keeping only one object mixes records of two physical assets. Therefore separate:

Functional Location: what task is performed here. Physical Equipment: which asset currently performs the task.

When equipment is replaced, retain the functional location, update the asset installation relationship, and record the effective time. This enables continuous process analysis while separately tracking life and failures of different equipment.

This distinction has international standard backing. IEC 81346 splits technical object designations into three independent aspects: Function (=), Location (+), Product (-) — Function answers "what task here", Location answers "where installed", Product answers "which specific unit". The "functional location" here corresponds to the Function aspect , "physical equipment" to the Product aspect . Power industry coding systems KKS and RDS-PP are built on this thinking.

Where Should Shared Equipment Belong?

Cement plants often have shared facilities: air compressor station, circulating water system, main substation, common conveying system, shared raw material yard, shared packing and shipping facilities. Forcing them under a single production line to satisfy the five-layer structure causes other lines to lose visibility and unclear energy allocation. Better approach: place shared facilities under a factory-level common system, then establish "serves which lines" relationships. Define allocation rules separately when cost or energy sharing is needed.

Physical ownership, service relationship, and cost allocation are three different things.

What Else Is Needed When Tags Are Hung Under Equipment?

At minimum specify:

Original tag and source system

Standard parameter name

Measured object and location

Unit

Measured value, setpoint, or calculated value

Timestamp meaning

Data validity rules

Enable/disable timestamps

Business tags and source tags can be managed separately. E.g., "No.1 Raw Meal Mill Outlet Gas Temperature" is a business tag; a specific tag in the DCS is its current data source. After DCS upgrade or tag change, just update the mapping and retain history to maintain query continuity. But if measurement location or actual meaning changes, cannot treat as same tag based on name similarity alone.

Often overlooked detail: "Zero" has multiple meanings. At least distinguish four states: ① Not configured (instrument not installed); ② Acquisition fault (communication loss, sensor failure, data invalid); ③ Disabled or shutdown ; ④ True zero (flow meter actually reads zero). Industrial data standards (e.g., OPC UA) require: when quality code is "Bad", value should be null, not 0. Treating "fault zero" as "true zero" in averages and energy calculations systematically lowers results . Therefore tags must record quality code (Good/Uncertain/Bad) and timestamp source (source timestamp or server timestamp).

Is a Single Tree Enough?

Tree structures answer "where does it belong". But industrial analysis also needs:

Where does material come from and go to?

Which fan supplies air to which system?

Which power meter covers which equipment?

Which tags participate in KPI calculation?

Which sample corresponds to which production segment?

These relationships often cross tree levels. Example: cooler hot air serves both rotary kiln and calciner, cannot be expressed by a single parent-child link. Solution:

One ownership hierarchy plus multiple explicit business relationships.

Each relationship must have a name, direction, and meaning; avoid vague "associated" linking everything. This "hierarchy + relationships" structure is the foundation for industrial knowledge graphs and ontology modeling.

Where Should KPIs Be Attached?

Tags record raw or processed data; KPIs express business calculation results. Examples:

Fan power → equipment tag

Raw meal system daily electricity consumption → process statistical KPI

Specific energy consumption per ton clinker → production KPI under specific boundary

Factory gross profit → management KPI

They can link to different levels, but each KPI must define:

Calculation formula · Data sources · Statistical period · Inclusion scope · Exception handling rules

Cannot assume tree structure means "all numbers can be summed upward". Power, temperature, run rate, specific energy consumption have different aggregation methods.

Aggregation methods fall into three categories. ① Additive (electricity, output, coal consumption): can sum level by level, sum of factories equals group total. ② Ratio or intensity (specific energy consumption, run rate, unit cost): cannot average sub-values; must recalculate as "total ÷ total". ③ Instantaneous (power, temperature, pressure): should use time-weighted average or integrate samples, not simple arithmetic mean. The group specific energy consumption mentioned earlier is a typical ratio type — should equal Group total electricity ÷ Group total output , not arithmetic average of factory specific consumptions. "Average of averages" is the most common trap for such KPIs.

Will Unified Templates Erase Factory Differences?

Unified model must balance commonality and variation. Create base templates for similar objects. E.g., "Raw Meal Vertical Mill" template defines basic attributes and common parameter types like differential pressure, power, outlet temperature. But different equipment structures, drive modes, and instrument configurations vary, so templates should allow:

Optional fields

Factory extensions

Explicit missing items

Different measurement schemes

If a certain instrument is not installed, mark as "Not configured", not zero. Goal of unified model: make differences explainable , not make all factories look identical.

Why Does the Model Need Versions and Effective Times?

Factories continuously change: line revamps, equipment relocation, meter scope adjustments, instrument replacements, partial facility decommissioning, KPI formula updates. If model only stores current state, historical queries may be wrong. Example: a power meter adds coverage of a new equipment this month; cannot use new scope to explain last year's electricity. Therefore key relationships and rules must record effective time, optionally end time. When querying historical data, use the then-valid equipment ownership, tag mappings, and KPI definitions.

Current model describes now, historical versions explain the past.

This is the "temporal" concept in data management: each object and relationship has both valid time (when the relationship held in reality) and transaction time (when system recorded it). Recording both separately enables traceability.

How to Verify the Model Is Actually Usable?

Don't just check if the catalog is complete. Validate with real questions:

Query one equipment: Can you simultaneously find operation trends, maintenance work orders, and equipment documentation?

Calculate one KPI: Can you trace back to raw tags, statistical boundary, and formula?

Compare two factories: Can you explain which conditions are consistent and which differences need adjustment?

Review one failure: Can you reconstruct the installed equipment, valid tags, and operating status at that time?

Change one tag: Can queries remain continuous while preserving source change history?

These questions test whether the model truly connects business and data.

Who Maintains This Model?

Unified model cannot be left only to platform implementers. Typically requires joint responsibility:

Group defines basic classification and KPI rules

Factory confirms actual objects and field relationships

Equipment personnel maintain asset and installation info

Automation personnel maintain tags and signal mappings

Production, quality, energy personnel confirm business meanings

IT personnel ensure model publishing, interfaces, version control

Each object type should have a clear owner. More importantly, embed model updates into existing workflows: equipment modification acceptance, instrument replacement, metering scope adjustment should all trigger model review. Otherwise model quickly diverges from field.

These responsibilities can be incorporated into enterprise data governance framework. China's Data Management Capability Maturity Assessment Model (DCMM, current GB/T 36073—2025, effective 2026-07-01, replacing 2018 version) divides data management into eight capability domains: Data Strategy, Data Governance, Data Architecture, Data Application, Data Security, Data Quality, Data Standards, Data Lifecycle. Unified object model primarily falls into Data Standards, Data Architecture, Data Governance, and Data Quality . Core objects like equipment and materials are typically managed as Master Data with a single designated data steward.

Suggested Phased Implementation

Phase 1: Pick One Scenario

E.g., focus on energy analysis for one clinker line, clarify needed objects and data.

Phase 2: Establish Base Hierarchy

Organize factories, lines, processes, equipment, and key tags into a verifiable list.

Phase 3: Connect Source Mappings

Link control, equipment, energy, production systems; verify same object identified correctly.

Phase 4: Complete KPIs and Relationships

Define statistical boundaries, calculation formulas, material/energy relationships.

Phase 5: Validate with Business Questions

Check if query, calculation, explanation, and traceability work — not just display.

Phase 6: Scale and Sustain

Reuse mature templates while preserving each factory's real differences. Don't wait for group-wide modeling to finish; stabilize model in one scope to serve business, then expand gradually.

Final Summary

Building a "Group-Factory-Production Line-Equipment-Tag" unified model is about creating a shared understanding of production objects across the enterprise. Six things to do well:

Unique identity, clear names Clear ownership, reasonable shared relationships Complete tag meaning, traceable sources Unified KPI definitions, correct aggregation methods Changes retain history, queries respect time Business people confirm, responsible people maintain

With this foundation, scattered system data can be organized around the same equipment, same line, and same problem. For AI, it provides a clear path:

First find the right object, then get the right data, finally analyze with the right caliber.

The value of the unified model lies in enabling the whole group to talk about the same factory using the same verifiable business language.