A production actual data collection system for a Thai factory is not complete merely because it reads a PLC and displays a number. It must prevent double posting after retransmission, distinguish late operator entry from real-time events, stop unapproved inspection results from reaching ERP, and retain every correction. This guide turns record integrity and confirmation responsibility into practical RFP, PoC, FAT and SAT requirements.
A production actual data collection system must prove more than visibility
A machine signal can be shown on a dashboard quickly. That does not make it a production actual. A rising completion bit may mean one good unit, an empty cycle, a cavity count greater than one, a trial run or an item still awaiting inspection. If a connection recovers and sends the same message again, counting arrivals will inflate output.
A record used for planning, inventory, costing or delivery commitments must answer:
- What happened, at which site, line, asset, operation, order, item and lot?
- When did it happen, arrive and become confirmed?
- Which source record and transformation-rule version produced it?
- Will the same event be counted once when it is resent?
- Is it provisional, confirmed, posted or cancelled?
- Who corrected it, why, and what were the before-and-after values?
Process-progress visibility is a consumer of this foundation. If the foundation is weak, operators keep a parallel paper or spreadsheet truth and treat the system as an estimate. Therefore, specify event identity, state transition, deduplication and correction before choosing charts.
Model manufacturing actual collection as five states
Do not make every incoming value “posted.” Separate five states:
- Raw — the acquired PLC value, sensor sample, scan or operator input.
- Event — a business interpretation such as operation start, one completion or inspection failure.
- Provisional — the event enriched with order, item, lot, operator and unit, but not yet accepted.
- Confirmed — an authorized person or approved rule accepts it as the production record.
- Posted — the target ERP/inventory/cost process has returned a reconciled result.
Keep raw evidence so that corrected mapping logic can be replayed. At the same time, agree retention, capacity, access and privacy; “keep everything forever” is not a design. A confirmed record should not be overwritten. Add cancellation and correction events so the original value and reason remain auditable. If an ERP posting already exists, correction must include ERP reversal or reposting, not just a changed MES screen.
Separate raw signals from business events
A PLC bit, register or counter describes control state. A production event describes business meaning. The mapping layer must address pulse duration, debounce, PLC restart, multi-cavity output, trials, dry cycles, quality status and counter reset or rollover.
Attach an event-definition table to the RFP. For every event type, specify source, trigger, debounce, quantity rule, work-order mapping, quality state, event-ID rule, exception behavior and owner. “OPC UA connectivity is supported” does not answer these questions.
OPC UA PubSub can distribute cyclic data and event data, and it decouples publishers from subscribers. It is a useful transport and information mechanism, but business confirmation remains an application contract. Evaluate connectivity and production-record validity as separate criteria.
Divide responsibility across PLC, operator, inspection and scanning
PLC: capture objective occurrence
PLCs are suitable for cycle boundaries, equipment state, counters and alarms. They may not know the valid work order, defect reason or final quality status. Avoid loading every business master into control logic. Let the PLC issue a source event and let edge/MES join it to a time-valid work-order assignment. A failed join should enter an exception queue, not disappear. Later correction must retain the original event ID and timestamp.
Operator input: add meaning and exceptions
Setup complete, downtime reason, rework reason and disposal reason often require human input. Prefer controlled reason codes and context-dependent choices to uncontrolled free text. Use stable codes as master keys, with Thai, English and Japanese labels for display.
Record selection time separately from transmission time. An offline terminal must queue inputs durably and expose local-saved, sent, received and confirmed states. Shared accounts undermine correction accountability; use named identity or an approved team procedure with clear separation of duties.
Inspection: do not overwrite production quantity
One design records completion provisionally and then allocates it to good, reject, hold and rework after inspection. Another uses inspection pass as the good-output event. Either can be valid. The error is to overwrite all quantities in one counter.
Define consistency rules between completed, inspected, accepted, rejected, held and reworked quantities. Specify sampling, retest version, quality approval and downstream correction. If inventory or a quality lot is already posted, the correction workflow must reach that system too.
Barcode: identify the object, then validate it
A barcode can identify an order, item, lot, serial, container or operator, but a readable code is not automatically valid. Check routing sequence, expiry, prior use, duplication, item match and equipment eligibility. Give every scan its own event ID. A time-based debounce alone cannot distinguish an accidental double scan from two legitimate operations.
Set the MES–ERP boundary by confirmation ownership
ISA-95 provides a vocabulary for physical processes, sensing and control, manufacturing operations management and enterprise functions. It does not force every plant into one product topology. Define the boundary by the system of record and the authority to confirm each data class.
| Data | Typical owner | Collection-system responsibility |
|---|---|---|
| Item, routing, order | ERP or approved production master | Consume version and validity; do not create an uncontrolled parallel master |
| Equipment, tags, edge mapping | OT/MES | Version source configuration and transformation rules |
| Raw/event/provisional | Edge/MES | Preserve identity, state and exception evidence |
| Confirmed execution | MES/production management | Apply role and approval rules |
| Inventory/accounting posting | ERP | Return target document ID and status |
SAP’s Production Order Confirmation API is one example: its confirmation model includes start/end times, yield, scrap, rework, variance reason and final-confirmation type. This is not a universal ERP standard, but it shows why a production actual is more than a quantity.
Decide whether ERP posting starts at confirmation, supervisor approval or shift close. On ERP timeout, do not mark the event posted merely because the request left MES. Keep a posting request ID, target response ID and result code, and transition only after reconciliation.
Use our four criteria for comparing MES options to evaluate product fit, and the Thailand factory system-development outsourcing RFP guide when custom integration or software is included.
Keep event_time, received_at and confirmed_at separately
One timestamp cannot explain disconnection, late entry or approval delay. Store at least:
- event_time — when the physical or human event occurred;
- received_at — when edge, broker or MES recorded receipt;
- confirmed_at — when the business accepted it as an official actual.
GS1 EPCIS similarly distinguishes real-world eventTime from repository recordTime. Even without EPCIS, this distinction is valuable. Store timezone offset, clock source and clock status, especially across Thailand, Japan and Vietnam.
If a device clock drifts, event_time may appear later than received_at. Define permitted clock skew, synchronization, loss-of-sync flag and correction rules. Retain the original timestamp and add a corrected timestamp with a reason. For dashboards, declare which time drives each chart: event time for shop-floor occurrence, received time for pipeline latency, and confirmation time for closing. Mixing them creates a “real-time” chart that changes unexpectedly after close.
Handle retransmission, duplicates and reordering with business identity
MQTT 5.0 QoS 1 is at-least-once and can deliver duplicates. The DUP flag does not identify an application message. QoS 2 strengthens transport delivery, but it does not automatically prevent a duplicate database transaction or ERP posting after an application retry.
Assign a durable source_event_id, such as site-line-PLC boot ID-sequence or a UUID. Enforce it as a unique key. Same ID and same payload is a recorded duplicate with no second count. Same ID with different payload is a serious exception, not an overwrite.
Apply idempotency at every boundary:
- Device to edge: deduplicate by source event ID.
- Edge to MES: preserve event ID and transmission attempt.
- MES state: use expected state/version to prevent double confirmation.
- MES to ERP: reuse a stable posting request ID after timeout.
- ERP response: store and reconcile the target document ID.
Events may arrive out of sequence. Completion can arrive before start; inspection can arrive before production completion. Define a reordering window, prerequisite-state hold, timeout and exception queue. Database arrival order is not production order.
Design offline recovery as an operational procedure
A Thai plant can lose factory LAN, Wi-Fi, site VPN, cloud access, power or an edge runtime. “Works offline” must state where data is retained, for how long, in what priority, and what happens when storage fills.
AWS IoT Greengrass Stream Manager is one official implementation example that supports intermittent connectivity, persistence, retention and export priority. Regardless of product, require:
- a durable queue that survives edge restart;
- append-only journal with sequence, checksum and source event ID;
- separate priority for production events and diagnostic data;
- monitoring of buffer usage, oldest unsent event and dead-letter count;
- controlled backlog drain that does not starve current events;
- safe behavior for full disk, corruption, clock loss and expired certificates;
- encryption, keys, access and maintenance controls for local data.
During disconnection, the operator UI should distinguish locally saved from received and confirmed. After recovery, reconcile gaps, duplicates and ERP posting counts; “all messages sent” is not enough.
Put an event data contract in the RFP
Add a sample event schema, not only screen and asset lists.
| Group | Required fields |
|---|---|
| Identity | source_event_id, site, line, equipment, event_type, schema_version |
| Context | work_order, operation, item, lot/serial, shift, operator/role |
| Value | quantity, unit, quality_state, reason_code, raw reference |
| Time | event_time, timezone, received_at, confirmed_at, clock status |
| State | raw, event, provisional, confirmed, posted, cancelled, state version |
| Audit | creator, confirmer, changer, reason, before/after, rule version |
| Delivery | sequence, attempt, checksum, posting request ID, target response ID |
Require version-compatibility rules. What happens when a field is added, made mandatory or deployed gradually? Separate PLC tag mapping from the canonical event schema so control changes do not cascade through every consumer.
Security requirements should name device identity, certificate rotation, least privilege, routes and ports, remote maintenance, log access, restore test, vulnerability response and deprovisioning—not merely “use encryption.” Show one-way OT-to-IT flows and any approved return path for orders.
Use a 30/60/90-day PoC to prove record integrity
This is a recommended decision framework, not an industry-mandated duration.
Day 30: freeze definitions
Choose one operation and agree event definitions, IDs, clocks, state transitions, exceptions and owners. Collect samples for normal production, setup, trial, rework, hold, PLC restart and work-order change. Approve a manual truth set before demonstrating the system.
Day 60: create failure evidence
Inject network loss, edge restart, duplicate event, out-of-order arrival, ERP timeout, clock skew and master mismatch. A test might use 10,000 events, a two-hour outage, three retransmissions and ±5-minute skew, but these are examples—not universal thresholds. Replace them with plant peak, buffer and SLA values.
Measure collection completeness, duplicate posting, unreconciled records, confirmation lead time, exception effort, recovery time and audit gaps. Examine maximum and failure cases, not only averages.
Day 90: accept operations
Operators must process Thai-language exceptions; supervisors must confirm; IT/OT must trace an alert; and ERP users must reverse and repost. Receive operating procedures, access matrix, backup/restore evidence, certificate-renewal procedure, support escalation and known limitations. Decide scale, revise or stop.
Make FAT/SAT cover normal, failure and recovery
FAT should prove schema, deduplication, state, authorization, audit and interface behavior in the supplier environment. SAT must repeat the evidence with actual PLCs, network, shifts, operators and ERP/MES.
Cover normal events; counter resets and date/shift/lot boundaries; LAN, broker, database, edge and ERP failure; lost acknowledgements and conflicting duplicates; time drift and timezone; unauthorized confirmation and overwrite; backlog drain and dead-letter replay; peak load and full disk.
Each case needs precondition, input, expected event/state, evidence, actual result, tester, date and defect ID. A screenshot marked “pass” is insufficient. Acceptance evidence should trace the same event ID across raw storage, MES state and ERP document.
Compare TCO including exceptions and change
Use a common cost equation:
Monthly TCO = licenses + edge/connectivity + cloud/database + support + exception labor + amortized change + training/audit
Do not invent benchmark prices or benefit rates. Ask every supplier to price the same assumptions: one added machine, ten tags, a new event type, an ERP-field change, night support, Thai-language support, spare edge hardware, certificate rotation, OS patching and restore tests.
High automatic collection with many unmatched orders or clock errors can increase work. Track unresolved exception count and age, manual-correction ratio, recurrence and root-cause distribution, not automation percentage alone.
Common mistakes and corrections
- Treating a PLC counter as good output: separate raw completion from quality-confirmed quantity.
- Keeping arrival time only: keep event, receive and confirmation times.
- Assuming MQTT QoS solves business duplication: add event identity and idempotency.
- Testing an outage with ping only: test buffer, replay, order, gaps and ERP reconciliation.
- Overwriting confirmed records: add cancellation and correction events.
- Making both MES and ERP masters: assign ownership per field and state.
- Ending PoC at one-machine demo: inject failures and test multilingual operations.
- Omitting exception labor from TCO: include support, renewal, patch and recovery.
FAQ: Production actuals and progress visibility
What is a production actual data collection system?
It turns PLC, operator, inspection and scan records into order- and operation-linked actuals, then controls provisional entry, confirmation, ERP posting and correction. Event identity, state, authorization and audit distinguish it from a data logger.
Can PLC collection automate all manufacturing actuals?
PLC data is strong for objective cycles and status, but reason, rework, hold and order exceptions need operator or higher-level context. Combine the sources through explicit confirmation rules.
Why separate event time and confirmation time?
Disconnection, late entry and approval mean the times differ. Without both, progress, shift close and audit cannot be explained.
Is deduplication needed for a progress dashboard?
Yes. A retransmission can push progress over 100% and distort completion forecasts.
Does MQTT QoS 2 guarantee exactly-once ERP posting?
No. It addresses transport delivery. Database commits, service retries and ERP posting still need application event IDs and idempotent processing.
How are PoC, FAT and SAT different?
PoC proves the event definition and method in a narrow scope. FAT proves function and failure evidence at the supplier. SAT repeats this with the real factory environment and users.
Is it worth revisiting actual-data collection when an MES already exists?
Yes. Without changing the current MES screens, it may be possible to strengthen edge and event contracts, IDs, timestamps, exception handling and ERP reconciliation. Start by classifying gaps, duplicates, late entries and corrections in current logs, then modify only the necessary parts.
Conclusion: a correct actual is a record with an explainable path
The purpose is not to collect everything automatically. It is to connect raw signal, business event, provisional actual, confirmation and ERP posting with a durable ID, then explain the quantity after outage, retransmission or correction. Put ownership, three timestamps, audit and recovery reconciliation into both RFP and acceptance testing.
TOMAS TECH can help a Thai factory define one operation’s event contract, PLC/operator/inspection boundaries, RFP, 30/60/90-day PoC and FAT/SAT evidence. You can discuss requirements before selecting a product through our contact page.
