Equipment runtime log capture is not complete when a dashboard starts drawing colored bars. If the same stoppage produces a different duration or reason when it is recalculated tomorrow, the log is not dependable evidence. A Thai factory needs to retain each state transition with time, quality, order, reason and revision context, then accept the solution through replay tests that include communication loss, clock skew, resend and manual correction.
Executive conclusion: accept replayable events, not saved values
A stoppage pie chart is not proof that stop analysis is correct. A defensible record must explain when the controller observed the transition, when the collector received it, whether the value was trustworthy, which event came first, who or what classified the reason, and which rule version was active.
This guide proposes seven minimum context fields: source timestamp, receive timestamp, quality/status, sequence, reason code, actor and rule version. This is a procurement design, not a claim that one standard mandates the exact schema. It gives the plant, integrator and software provider a common acceptance language.
The decisive tests are not performed only under a healthy connection. The buyer should interrupt communications, introduce clock anomalies, deliver events late or out of order, resend duplicates and make an authorized correction. When the stored input is replayed with the same rule version, the same stop intervals and reasons should be reproduced, or every difference should be explained by traceable evidence.
Why runtime evidence matters now in Thai manufacturing
In a publication context dated 27 August 2026, Thailand’s Office of Industrial Economics displays a preliminary July 2026 Manufacturing Production Index of 94.80, down 0.94% month on month and up 0.46% year on year. Those figures do not describe an individual factory. They provide current context for why management needs to explain production variation beyond a monthly total and trace it to operational events.
Thailand BOI’s first-half 2026 release reports 132 Smart and Sustainable Industry applications worth approximately THB 17.2 billion. These are applications, not realized investments, installed systems, savings or successful outcomes. In an active investment environment, contracts should define evidence and change control rather than treat the number of connected machines or dashboard screens as acceptance.
A broader production actual data collection design connects items, quantities, operations, lots and work results. This article narrows the lens to whether equipment-state transitions survive loss, duplication and correction without making stop analysis irreproducible. It is also distinct from a maintenance planning system, which schedules inspections and work orders; here, the concern is the evidentiary quality of the stops that may trigger those actions.
Five reasons value storage cannot reproduce stop-cause analysis
One timestamp is forced to represent different facts
The time at which a PLC or sensor observes a value is not necessarily the time at which a gateway or server receives it. Data buffered during an outage may arrive in a burst after recovery. Sorting only by receive time can move a stop to the recovery period. Trusting source time without qualification can hide a drifting or misconfigured device clock.
OPC UA Part 4 DataValue can carry source and server timestamps as well as Good, Uncertain or Bad status. A server timestamp relates to the server’s knowledge of the value; it is not automatically identical to the downstream analytics collector’s receive timestamp. The interface specification must name the clock and system boundary represented by every timestamp.
Current values overwrite state transitions
Polling a tag that currently says RUN can miss a STOP-to-RUN transition that happened between reads. Faster polling is not a universal cure: it changes load and traffic while ordering questions remain. The historical system of record should preserve the transition from previous state to new state with a stable identity and ordering context. A current-value table can serve live visualization, but it should not replace the immutable event history.
Communication quality is mistaken for equipment state
If a lost connection is filled as STOP, a network incident appears to be lost production. If the last RUN value is held indefinitely, a real stop may be hidden. State and quality must be separate dimensions: for example, state STOP, quality Uncertain, delayed receipt. A report can then exclude or flag uncertain periods without silently inventing equipment behavior.
A resend is counted as a new stoppage
MQTT Version 5.0 defines session state, QoS and message/session expiry mechanisms. Transport delivery behavior does not by itself guarantee that one business event is counted once. A sender may restart its sequence, the same event may arrive by two routes, or an application may re-inject a stored message. Business-level deduplication therefore needs explicit identity rules and acceptance tests.
A manual correction erases the original reasoning
Allowing the line team to change a reason to “material waiting” can improve data. Overwriting the automatic classification destroys the evidence needed to review the rule. The system should append the before and after values, actor, time, correction reason, approval and rule version. OPC UA Historical Access covers historical data and events as well as modifications and audit-related capabilities, but a particular implementation must still prove that it retains and exports the required history.
Minimum event schema for equipment runtime log capture
The following is a buyer-side minimum design, not a product-specific mandatory format. Names and data types can fit an existing MES, SCADA or data platform, but the meanings should remain intact.
| Field | Why retain it | What acceptance should prove |
|---|---|---|
| source timestamp | Time the source observed the transition | Time zone, resolution and behavior during clock faults |
| receive timestamp | Time the collection service received it | Ability to identify delay, outage and resend |
| quality/status | Trust state of the value | Non-Good data is not silently converted to zero or STOP |
| sequence | Evidence of order and gaps | Rules for restart, rollover and multiple paths |
| reason code | Managed classification of the stop | Taxonomy, unclassified state, hierarchy and retirement history |
| actor | Originator of creation, classification or correction | Device, rule, integration and person remain distinguishable |
| rule version | Logic applied to the event | Historical data can be replayed with the rule then in force |
An implementation may also include event ID, equipment ID, previous state, new state, ingest ID and a correction link. Adding columns is not enough. The data contract must define the meaning of nulls, gaps, duplicate identities and reversed clocks.
Define the state model before inferring convenient answers from logs
Disagreement often begins with state semantics rather than collection technology. RUN signal, motor current, cycle completion and good-part discharge can each produce a different definition of “running.” AUTO with no material, a running primary machine blocked downstream, setup, planned stop and quality hold should not be collapsed into one unexplained STOP.
Define a state machine for the equipment, line and process levels. Each transition needs entry and exit conditions, priority, persistence behavior and parent-child aggregation rules. A rule such as “a safety stop takes priority when multiple signals are true” belongs to the versioned classification logic.
ISA-95 provides models and terminology for exchange across enterprise and control domains, and the ISA page lists Part 1 as 2025. Naming the standard does not create interoperability. It can, however, help the parties identify which layer owns the raw event, which layer classifies a reason and where the system of record resides.
ISO 22400-1:2014 provides an overview, concepts and terminology for manufacturing-operations-management KPIs; ISO says the edition was reviewed and confirmed in 2025 and remains current. It does not define a plant’s stop-reason taxonomy or certify KPI accuracy. Every numerator, denominator and exclusion should be traceable to sample events.
Use source and receive timestamps for different questions
“We use NTP” is not a complete time design. RFC 5905 specifies NTPv4, but it does not promise a particular precision or failure behavior in a specific factory. Legacy controllers, standalone machines, gateways and virtual servers may use different clock sources.
An RFP should ask:
- Which clock is authoritative, through which path, and who monitors it?
- What time zone and resolution does each device retain?
- Who assigns time if a source provides no source timestamp?
- How does quality/status change when a clock jumps, reverses or becomes unsynchronized?
- At which service boundary is receive time stamped, and is it stable during reprocessing?
- How are local display time and storage time separated?
Use source time and sequence to reconstruct operational order. Use the difference from receive time to observe delivery health. Do not automatically turn delivery delay into equipment downtime; treat it as a separate collection-quality signal.
Accept communication loss, resend and reordering with replay tests
A healthy-connection demonstration hides the difficult behavior. The PoC and FAT should retain test inputs and provide a harness that can submit the same inputs again. The SAT should collect evidence under the real plant network, equipment and access-control conditions.
Communication loss
Interrupt the connection deliberately and observe what the edge buffer retains. After recovery, late events should return to the correct occurrence interval and remain identifiable as delayed receipts. If buffer capacity is exceeded, the system should emit gap evidence or an alarm rather than silently discard old data.
Duplicate resend
Resend an event with the same event ID or identity key. The stoppage count and duration must not increase. Deduplication should preserve an audit trail of what was considered duplicate and which record was selected. Two different payloads with one identity should be quarantined as a conflict, not blindly overwritten.
Out-of-order arrival
Submit a RUN that occurred after STOP but arrives first. Decide whether the engine waits before ordering, corrects an earlier interval after a late event, or recalculates a closed report. The low-latency live view and the completeness-oriented final report do not need one identical service target.
Clock skew
Move a source clock forward and backward. Confirm that sequence and receive time expose the anomaly. If the system corrects time automatically, retain the original timestamp, correction rule, actor and rule version. If correction is not defensible, mark the event Uncertain and route it for review.
Manual correction
Have an authorized user correct a stop reason. Retain the old value, new value, actor, approval and rule version. Do not confuse a replay using the historical rule with a reclassification using today’s rule.
Separate factory real-time monitoring from final reports
A shop-floor display values speed and may include provisional data. A daily meeting, customer explanation, costing decision or maintenance review needs a controlled report after late arrivals, corrections and unclassified stops have been closed. Treating both as one definitive number creates distrust when the morning display differs from the monthly report.
The screen should expose data freshness, quality, unsynchronized equipment, unclassified stops and closing status. In addition to color, show the received-through time, whether the figure is provisional or final, and whether recalculation is pending. Live values may update; the events and report versions underneath them should be immutable or append-only.
A report manifest can retain the period, applied rule version, reason-code version, exclusions, execution actor and output hash. A future rule change then does not prevent the factory from explaining the historical report under the conditions used at the time.
RFP questions that make competing proposals comparable
Comparing brands and protocols alone allows bidders to answer different questions. Ask what evidence will exist when failure modes occur.
| RFP question | Required answer/evidence | Inadequate answer |
|---|---|---|
| How is a transition uniquely identified? | Event ID, sequence, restart and duplicate rules | MQTT prevents duplicates |
| How are two times retained? | Source/receive definitions, clock sources, anomaly handling | Everything uses server time |
| What happens during an outage? | Buffer, overflow, resend and gap evidence | It sends automatically later |
| How is unknown quality handled? | Status mapping, quarantine, display and report exclusion | Error values are not stored |
| Who assigns a reason? | Automatic/manual actor, approval and version | The operator selects it |
| Can history be replayed? | Raw export, rule package, manifest and comparison | It is visible on a history screen |
| Can corrections be exported? | Before/after, actor, reason, approval and time | An administrator can edit it |
| How is access secured? | Privilege, logging, remote access, update and retirement | There is a firewall |
NIST SP 800-82 Revision 3 addresses OT security while considering performance, reliability and safety requirements. Log collection should not create unrestricted two-way access into control networks. Design zones, least privilege, monitoring and recovery according to risk. The January 2025 Secure by Demand joint guide also supports procurement questions around vendor logging. Ask for configurations, sample exports and test evidence rather than a generic compliance statement.
Make the PoC a destructive log test, not a screen evaluation
A PoC that ends when several machines connect and a dashboard moves evaluates only the healthy path. The equipment scope may be small, but the evidence loop should cover state semantics, time, quality, ordering, resend, correction and replay.
Prepare a golden input before the PoC. Use a simulator or safely captured anonymized events to define expected intervals and reasons alongside missing, duplicate and clock-anomaly cases. Compare vendor output mechanically with expected output. When a difference appears, require an event-level explanation instead of a visual judgment that the chart looks close.
The PoC deliverables should include a data dictionary, state-transition table, reason-code table, time policy, abnormal test inputs, expected and actual results, open differences and next-gate conditions. Promote this package into the RFP attachment so that production bids are comparable.
FAT: prove reproducibility before shipment
FAT may not reproduce every plant condition, but it can test deterministic processing and exception behavior in the supplier environment.
- The same input and rule version produce the same intervals and reasons.
- Input, configuration, software version, rule version, output and difference file are retained together.
- Duplicate, gap, reverse order, reversed clock, Bad/Uncertain and unknown reason inputs are injectable.
- Buffer overflow, service restart and reconnect behavior are recorded.
- Raw and corrected events can be exported separately.
- Unauthorized correction is rejected and the attempt is logged.
- Every simulated FAT condition maps to a named SAT retest.
FAT pass does not mean every site-specific function is complete. It means the system can ship without making SAT verification impossible. Record the owner, due condition and evidence format for each substitute condition.
SAT: prove the actual factory clocks, network and operating model
SAT should not end when the first live value appears. Use actual PLCs, gateways, network segments, servers, user privileges and shift handover to exercise factory-specific failure modes.
SAT evidence gate
- Trace every RFP requirement ID to a test case.
- Retest PoC/FAT substitutions under actual equipment conditions.
- Execute outage, resend, reordering, clock skew and manual correction.
- Reconcile raw log, processed event, live dashboard and final report through the same event ID.
- Confirm that replay with the same input and rule version produces the same result.
- Record every difference with cause, impact, owner, temporary control and retest condition.
- Accept only when plant operators can export logs and reproduce the evidence package themselves.
Attach the test case, input, system version, configuration, clock status, rule version, reason-code version, raw export, processed export, comparison, exception list and approver to the acceptance signature. Screenshots alone cannot be recalculated. Require machine-readable files and a manifest.
Apply the same discipline to major and micro-stop analysis
A long stop is visible, so one missing boundary can have a large effect on the total. Short stops are numerous and more sensitive to polling, debounce, minimum-duration rules and resend duplication. A duration ranking alone is not enough for either category.
For major-stop analysis, verify boundaries, planned/unplanned classification, parent-child impact and a second stop after recovery. For micro-stops, verify signal chatter, repeated causes, propagation between machines and missing reasons. Classification thresholds are plant rules, not universal external facts. Version the threshold and do not silently overwrite past results after it changes.
A Pareto chart shows recorded causes, but poor log quality can promote the easiest causes to capture. Display unclassified periods, Uncertain duration, late arrivals, sequence gaps and manual corrections beside downtime. Improvement meetings can then assign separate owners to equipment loss and measurement failure.
Govern changes and audit after go-live
Adding equipment, changing PLC logic, revising reason codes, upgrading the network or deploying software can change stop-analysis meaning. A change request should identify affected equipment and fields, rule version, backward compatibility, replay regression test and rollback.
Distinguish raw, normalized, classified, corrected and reported layers. If raw data will be deleted early to save capacity, the business owner should approve which future questions can no longer be answered. Backup is not the same as replay readiness: configuration, rules, reference data and execution environment must also be restorable.
Remote maintenance and vendor access should have time limits, approval, least privilege, action logs and expiry at contract end. Keep security logs and production events separate but linkable through controlled identifiers. If a time or configuration change affects the analysis, the plant must be able to explain who did what.
Make procurement, implementation and operation ownership explicit
| Role | Main responsibility | Gate evidence |
|---|---|---|
| Plant sponsor | Purpose, stop definition, accept/stop authority | Requirement approval, exceptions, signature |
| Production/maintenance | States, reasons, recovery and field validation | State/reason tables, shift test record |
| OT | PLC, clocks, network and edge | Connection map, sync state, outage test |
| IT/data | Storage, access, processing, replay and export | Schema, manifest, comparison |
| Quality/audit | Corrections, versions, traceability and retention | Audit trail, approval history, retention policy |
| Procurement | RFP, deliverables, commercial gates | Response matrix, payment link to open items |
| Integrator/vendor | Build, test, documents, training and correction | FAT/SAT evidence, as-built, training record |
An integrator cannot “produce the correct utilization” when the factory has not defined stop semantics or reason ownership. Conversely, the factory cannot verify replay if vendor logic is a black box. Link both parties’ deliverables and decision rights to acceptance evidence, not just a RACI chart.
Implementation roadmap: advance by evidence gates, not connection count
First, limit the process scope and agree on the state model and event schema. Second, build healthy and abnormal golden inputs and close replay differences in the PoC. Third, place evidence requirements in the RFP, prove deterministic behavior at FAT and actual conditions at SAT. Fourth, hand final-report control and change governance to operations.
Progress should not be measured only by connected equipment. Use completion conditions such as approved state definitions, executed abnormal cases, resolved differences, replayable exports and local staff able to produce the evidence. Do not expand simply because more tags are visible.
In a multilingual factory, interface descriptions can be localized while event ID, equipment ID and reason code remain language-neutral. Japanese headquarters, Thai operations and the integrator can then refer to the same stop without translating the identity of the evidence.
Summary: the value of stop analysis is the ability to reproduce and explain it
Equipment runtime log capture succeeds when each state transition retains source timestamp, receive timestamp, quality/status, sequence, reason code, actor and rule version. Put communication loss, clock skew, resend, reordering and manual correction into replay tests, and require the same inputs and rule version to reproduce the same stop intervals through PoC, FAT and SAT. Separate provisional monitoring from controlled reports and preserve historical decision context after changes. The log then becomes a shared foundation for improvement, maintenance and investment decisions—not merely a moving dashboard.
TOMAS TECH can help structure the event schema, RFP questionnaire, abnormal PoC cases and FAT/SAT replay package before a specific product is selected. If existing runtime reports disagree or a new IoT platform needs defensible acceptance criteria, you are welcome to contact us at the planning stage.
FAQ: accepting runtime log capture and stop analysis
What should equipment runtime log capture retain at minimum?
Link each state transition to source timestamp, receive timestamp, quality/status, sequence, reason code, actor and rule version. Event ID, equipment ID, previous/new state and correction links are also useful. The essential work is defining behavior when data is missing, duplicated or corrected.
How is production actual collection different from equipment runtime logs?
Production actual collection broadly covers quantities, operations, items and work results. Equipment logs focus on the underlying state transitions, time, quality and order. Link them through controlled identifiers rather than forcing every concept into one record.
Is source timestamp alone enough for stop-cause analysis?
No. It is crucial for occurrence time but can be affected by clock faults, and data may arrive late after an outage. Receive timestamp, sequence and quality/status distinguish an equipment event from a delivery problem.
Does MQTT QoS eliminate business duplicates?
Transport controls are valuable, but they are not equivalent to a rule that one business stop is counted once. Define application identity using event ID, source, sequence and payload, then test resend through replay.
What should a major-stop analysis acceptance test cover?
Test start and end boundaries, planned/unplanned classification, parent-child aggregation, intervals crossing an outage and recurrence after recovery. Trace the final report back to raw events through event IDs.
May a real-time factory screen differ from a monthly report?
Yes, if the difference is controlled and explainable as provisional versus final. Show freshness, quality and closing status on the screen. Retain the applied rules, reason-code version, exclusions and execution history with the report.
How do FAT and SAT replay tests differ?
FAT uses retained inputs to prove deterministic processing, exception handling and export in the supplier environment. SAT repeats the failure modes with actual PLCs, network, clocks, privileges and plant operation, closing every substitute FAT condition.
Does manual correction weaken auditability?
It does if it overwrites history. Keep the raw event and append before/after values, actor, reason, approval, time and rule version. The plant can then incorporate operational knowledge without losing the evidence trail.
Primary and official sources
- Thailand OIE, July 2026 MPI context — https://www.oie.go.th/view/1/Home/en-us
- Thailand BOI, 1H 2026 Smart and Sustainable Industry applications — https://www.boi.go.th/index.php?_module=news&from_page=press_releases2&language=en&page=press_releases_detail&topic_id=139075
- OPC UA Part 4, DataValue — https://reference.opcfoundation.org/specs/OPC-10000-4/7.11
- OPC UA Part 11, Historical Access — https://reference.opcfoundation.org/specs/OPC-10000-11
- ISA-95 Standard — https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard
- ISO 22400-1:2014 — https://www.iso.org/cms/%20render/live/en/sites/isoorg/contents/data/standard/05/68/56847.html
- NIST SP 800-82 Revision 3 — https://csrc.nist.gov/pubs/sp/800/82/r3/final
- MQTT Version 5.0 — https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html
- RFC 5905, NTPv4 — https://www.rfc-editor.org/info/rfc5905/
- Secure by Demand OT procurement guide — https://www.cisa.gov/sites/default/files/2025-01/joint-guide-secure-by-demand-priority-considerations-for-ot-owners-and-operators-508c.pdf
