Drawing Clear Boundaries: Platform, Business & Control Systems in Cement Digitalization

In cement digitalization projects, unclear system responsibilities cause duplicate construction, data conflicts, and control boundary violations. This article provides a reference design method for assigning responsibilities among platform, business systems (ERP, MES, LIMS, EAM, EMS), and control systems (DCS).

System Boundaries Are Not Software Labels

A single asset like a fan exists across six systems simultaneously: ERP (financial asset), EAM (technical records), DCS (runtime parameters), EMS (energy attribution), data platform (unified ID), and AI services (health assessment). Each system owns a distinct perspective; none should own all. The fundamental unit of boundary definition is: which business object, which attributes, which actions, which lifecycle, and who bears final accountability.

Reference Architecture: Activities First, Systems Second

ISA-95/IEC 62264 models manufacturing operations across levels: field devices (L0-1), supervisory (L2), manufacturing operations management (L3 — MES, LIMS, EAM), and enterprise planning (L4 — ERP). The standard guides identifying business activities first, then assigning systems. A single product may span multiple levels; multiple systems may collaborate on one activity. Business responsibility, software deployment, and network zones (IEC 62443 zones & conduits) are related but distinct design concerns.

Four Dimensions of System Boundaries

Business Responsibility : Who owns correctness and completion? (e.g., who approves test results, who accepts maintenance)

Data Authority : Which system and state represent the official fact? (e.g., reviewed vs. raw instrument results)

Modification & Publishing : Which service accepts create, correct, approve, publish? Other systems may display but not modify.

Control Execution : Who can change physical processes, under what conditions, with what fallback? Distinct from read access.

System Responsibility Baseline Table

A starting matrix for eight system types, listing core responsibilities and responsibilities not to assume by default:

ERP : procurement, sales, finance, cost; not real-time control or full field interpretation

MES : production tasks, process records, output confirmation, execution coordination; not full financial accounting or low-level control

LIMS : sample, test, review, approve, publish results; not automatic production disposition or release decisions

EAM : technical assets, maintenance plans, work orders, repair history; not auto-confirm faults or auto-shutdown from alerts

EMS : energy metering, accounting, balance, efficiency; not default final source for all operating costs

DCS : process monitoring, control, engineering logic execution; not cross-system approvals or group data governance

Industrial Data Platform : object mapping, data governance, metrics, analytics; not arbitrary modification of source business records

AI/Optimization Services : prediction, detection, assessment, constrained calculation; not automatic business approval or control execution rights

Responsibilities can migrate but each must have a clear owner.

ERP vs MES: Plan, Execution, Accounting Separation

Cement production tasks involve: enterprise demand/plan, factory production schedule, actual execution, and final accounting records. These are linked but must not collapse into a single overwritable "output field." Example flow: ERP provides operating plan → MES converts to production tasks and records execution → field metering provides process basis → confirmed actuals feed accounting systems. Key questions: who publishes plan, who receives/confirms, who records execution, who confirms actuals, who owns accounting, how plan changes and actual corrections propagate. The "plan → estimated → confirmed → settled" quantity chain mirrors the group indicator "estimate → confirm → ratify" three-state model: values may differ but each has name, state, and owner. Do not force different business stages into one value for report consistency.

LIMS vs Quality Apps: Test Facts vs Quality Decisions

LIMS manages sample and test result lifecycle. Test results ≠ quality decisions. A result exceeding limits may trigger retest, investigation, inventory hold, or release judgment — handled by quality apps, MES, or designated modules. Three object types: Test Record (what, method, result, reviewer), Quality Event (deviation, linked production periods/materials), Disposition Decision (who approves action, execution outcome). If LIMS already covers these, fine, but platform reading results does not gain rights to modify, approve release, or adjust production.

EAM vs Equipment Intelligence: Diagnosis ≠ Maintenance Management

Intelligent apps detect vibration/temperature/current anomalies and provide evidence. EAM manages maintenance plans, work orders, spares, acceptance, history. Proper relationship: intelligence provides clues and evidence; maintenance process owns confirmation and disposition. Distinguish five states: observed anomaly, model diagnostic hypothesis, personnel-confirmed issue, scheduled repair task, post-repair confirmed root cause. These associate conditionally with responsible parties, not via direct field-level sync. Example: model suggests "possible bearing anomaly" ≠ formal "bearing damaged" fault record. Repair results feed back to analytics for model correction and performance evaluation.

EMS vs Data Platform: Energy Metrics Need Governance, Not Just Formulas

"Specific power consumption = power / output" seems calculable anywhere, but official metrics require: metering boundaries, instrument multipliers, statistical periods, output sources, revision status, audit process. Pitfalls: power is instantaneous, energy is cumulative; specific consumption must use interval differences of cumulative meter readings; multiplier errors or cumulative resets invalidate downstream analysis. Statistical boundaries must align with national standards (e.g., GB 16780) for compliance and benchmarking. If EMS owns official accounting, platform syncs confirmed results or reuses its calculation service. Platform real-time estimates must be labeled "real-time estimate," not share identity with confirmed results. Distinguish: raw metering data, online estimated metrics, confirmed energy statistics, financial cost allocations. They share base data but may use different boundaries and publish times. "One unified caliber ≠ one calculation result for all uses."

DCS vs Upper Apps: Readable Data ≠ Writable Control

Data platforms read process data, but read permission does not extend to control permission. Architecture must separately manage: process data read, operation suggestion generation, parameter change request, control command acceptance, field execution, execution feedback. Even with business approval, control side must verify current mode, object state, allowed ranges, interlock conditions — the "object confirmation → data validity → permission check → constraint check" gate. Business approval must not bypass field protection. NIST SP 800-82 Rev.3 emphasizes balancing performance, reliability, safety; control responsibility cannot be delegated to ordinary business apps. Specific protection functions belong to designated control/protection systems.

Platform Responsibilities: Three Categories

Common Technical Services : identity, authorization, configuration, interface management, messaging, audit, runtime monitoring

Industrial Common Services : unified object ID, tag mapping, metric definitions, data quality, model invocation, evidence query

Cross-System Collaboration : event correlation, business progress tracking, evidence aggregation, controlled interface invocation

Platform may have authoritative records (e.g., unified object mapping, model versions, platform analysis events) but must not become authoritative for all source business just by aggregating data. "Aggregation right ≠ modification right; analysis right ≠ approval right."

Authoritative Data Source Defined to Object, Attribute, State

"Equipment data from EAM" is too broad. Example: purchase price from ERP, technical specs from EAM, real-time state from control system, unified mapping from master data/platform. Practical definition: for a business scope, object class, attribute group, and state, a designated service publishes the official version. Record at minimum: object type & ID, authoritative attribute scope, owning plant/org, official publish state, business owner, publishing system/interface, version/effective time, correction process. This is System of Record / Golden Record in MDM. "Single authority" prevents multiple competing official modification entry points for the same fact in the same scope — not requiring all fields in one database.

Data Responsibility Matrix Eliminates Disputes

Example matrix with columns: Data Object, Authority Source Example, Formal Modification Path, Platform Usage. Rows include: confirmed production actuals (MES/production app → production correction & review → sync, analyze, associate metrics), reviewed lab results (LIMS → re-review, correction, republish → read version, associate production scope), maintenance work order status (EAM → work order business interface → show progress, receive status changes), confirmed energy accounting (EMS/accounting module → accounting revision → benchmark, aggregate, trace), current process measurements (designated instruments/control chain → platform does not rewrite raw facts → store original, add quality tags), object mapping relations (master data/semantic service → mapping review & version publish → provide cross-system links), model predictions (model service → generate new versioned result → show prediction & applicability conditions). Matrix requires business+technical confirmation. "Platform usage" must specify read-only replica, derived calculation, or controlled write request — not vague "bidirectional sync." Sync direction, trigger, frequency, allowed latency are part of interface contract determining which system has fresher data during failures.

Unified Entry ≠ Unified Modification

Users want a single workbench. Two implementations: (1) user acts in platform, platform calls authoritative system's business API, source system enforces permissions, state, rules; (2) platform modifies local copy, attempts write-back. For formal business records, (1) keeps responsibility clearer. Example: unified workbench submits maintenance request → EAM creates work order, returns ID. Still "one entry" but no duplicate work order business. Same authoritative service can have multiple clients; no need to force all users onto one page.

Corrections Return to Authoritative Process

If platform suspects a lab result error: submit issue → responsible role verifies → correct & republish in LIMS → platform receives revision → recalc affected results. Preserve: original record, correction reason, operator, reviewer, version, publish time — an audit trail answering "how did this value become current?" not just "what is the value?" For unit conversions, anomaly flags, analysis corrections, distinguish raw vs processed values. Do not disguise "adjusted for analysis" as "source system originally had this value." If authoritative system lacks correction API, establish controlled manual process or flag disputed data — do not let platform silently become a second fact source.

Cross-System States Need Managed Relationships, Not Field Sync

Same business flow, different systems maintain different object states. Example: platform anomaly event (pending confirm, confirmed, handling, pending verify, closed) vs EAM work order (pending approval, dispatched, executing, pending acceptance, completed). States correlate but not 1:1. Work order complete ≠ anomaly gone; anomaly temporarily gone ≠ maintenance performed. Design explicit association rules: EAM publishes "work order completed" → platform event enters "pending effect verification" → designated role checks runtime data → decides close. Do not bidirectionally sync a "closed" field. "Cross-system closure manages object relationships, not copying same state name."

Scenario 1: Quality Anomaly Cross-System Collaboration

LIMS publishes test fact (sample, method, result, review state, version)

Quality app/platform identifies event per approved rules, references test result (not copy-modify)

Platform associates production evidence: sample scope, production records, process data for relevant periods. Association range needs business confirmation — cannot just match result entry time to production time (sample taken morning, entered afternoon; industrial data must align sampling, testing, entry, material production timelines — multi-timeline alignment)

Quality/production roles decide disposition in designated flow (retest, investigate, etc.)

Authorized roles execute field actions via proper control process, not quality event directly controlling equipment

New test results, production records, disposition evidence verify effect; owner decides close

Throughout: test fact, quality judgment, disposition decision, control action each have distinct owners.

Scenario 2: Equipment Warning to Maintenance Loop

Monitoring/Model Service : generates anomaly alert, saves input time range, model version, evidence

Platform Event Service : deduplicates alerts, links equipment object, notifies designated personnel

Equipment Engineer : confirms need for inspection, adds field observation, diagnostic opinion

EAM : creates work order per approved request, manages personnel, spares, execution, acceptance records

Production Coordination : if shutdown needed, arranges per existing procedures

Control/Field Personnel : execute per approved flow; EAM work order does not grant shutdown permission directly

Platform/Model Team : receives repair conclusion, checks if anomaly cleared, evaluates alert effectiveness

Avoid three confusions: predicted fault ≠ confirmed fault; work order approved ≠ field conditions met; work order closed ≠ model diagnosis correct.

Three Levels of Cross-System Call Results

Request Received : target system accepted request, not yet processed

Business Accepted/Completed : passed rule checks, created record or changed business state

Physical Action Confirmed : if field execution involved, confirmed via control feedback

Example: platform submits work order creation, times out. Cannot assume failure and retry indefinitely — target may have succeeded, response lost. Use request ID, business correlation ID, status query to confirm. Every request carries an idempotency key — same business action submitted repeatedly processed once. Standard practice to prevent duplicate work orders, duplicate shipments. Similarly, control request network response ≠ actual execution feedback. Interface contract must define each state meaning and who handles subsequent query, retry, manual intervention.

Platform Behavior When Source System Unavailable

System responsibilities cover failure behavior. Example: EAM down. Platform shows synced history with update timestamp. New user requests saved as "pending submission." Must not show "work order created" or generate fake EAM work order ID. On recovery, submit per auth/idempotency rules, update status. For time-sensitive or state-volatile requests, re-validate — do not execute all backlog unconditionally. This "partial function available, critical transactions wait" is degraded mode (referencing prior RTO/RPO discussion). Each system's degraded mode must be pre-designed, not improvised. Likewise, when source data delayed, platform shows data freshness; do not wrap cached old state as current field state.

No MES/EAM/EMS? Platform Can Assume Business Role

If a factory lacks EAM, project can build lightweight maintenance app owning work order lifecycle. Must define for this module: business owner, object model, state rules, permissions, correction mechanism, interfaces, migration path. Deployment on platform does not excuse missing responsibilities. Future new system introduction requires planning: history migration, incomplete task handover, formal modification entry switch, old module retirement. "System count can be few, responsibilities cannot be omitted." One product can play multiple roles, but each role needs clear business boundaries.

Group Unification Should Not Remove Factory Responsibility

Group wants unified metrics, models, UX — not all field facts directly modified by group platform. Reasonable split: group defines common standards, interface specs, aggregation requirements; factory confirms field objects, metering relations, production actuals, business records. Consistent with group data foundation principle: group unifies rules, factory confirms facts, both maintain mappings. Example: group defines specific power consumption; factory confirms which meters map to which equipment. Disputes: group initiates audit/supervision, but correction enters process with responsible owner. Platform must retain: who published rule, who confirmed data, when result effective, which historical results affected. Only then group management rests on explainable, traceable factory facts.

Ten Architecture Review Questions

Every key business record: clear responsible system and role?

Same object, different attributes: authoritative source defined per attribute?

Can formal data be independently modified in multiple systems?

Can platform display distinguish source record, replica, derived result?

Corrections have version, reason, propagation mechanism?

Cross-system states have explicit transition and association rules?

On request timeout: can determine if succeeded, avoid duplicate execution?

Suggestion, approval, business write, control execution separated?

Source system down: platform degrades correctly, labels data state?

System replacement/responsibility shift: authority entry switch plan?

If several answers are "coordinate later," responsibility design incomplete.

Five Design Deliverables

System Responsibility Matrix : which business activities each system owns, which it does not

Authoritative Data Source Matrix : object, attribute, business state, responsible system, confirming role

Modification & Publishing Path Map : create, correct, review, publish, sync paths

Cross-System State & Interface Contract : request, response, event, idempotency, failure, compensation rules

Control Responsibility & Failure Boundary Checklist : who proposes, who approves, who executes, which system/role takes over on exception

Materials need not be lengthy but must ensure every key business action has clear ownership.

Conclusion: Good Collaboration Built on Clear Responsibility

Platform goal is not merging ERP, MES, LIMS, EAM, EMS, DCS into one monolith, but enabling collaboration within clear boundaries. Business systems maintain formal business records; control systems own engineered field execution responsibility; platform provides common capabilities, data association, cross-system collaboration. When platform itself assumes business, it follows same responsibility rules. Four principles: same fact → clear authoritative source; formal modification → responsible process; cross-system collaboration → clear contracts; change physical process → guard control boundary. Interfaces can unify, data can share, processes can connect. But responsibility must not become blurred.