Minor Stop Reduction: 30-Day Monitoring PoC in Thailand

When a Thailand factory begins a minor stop reduction initiative, setting a target such as “reduce stop count by X%” too early can lead the team in the wrong direction. Interruptions lasting seconds or tens of seconds may include sensor waits, part realignment, upstream starvation, downstream blockage, quality holds, changeovers, normal cycle completion, or missing communications data. The useful starting point is not a guessed count. It is an event record that can be reconstructed with the same boundaries. This guide connects minor-stop monitoring, equipment runtime monitoring, reason-code governance, a 30-day proof of concept (PoC), RFP requirements, and FAT/SAT acceptance.

Executive answer: separate event detection from reason classification

An effective minor-stop program keeps two layers distinct:

1. Fact layer: when the state changed, how long it remained, and what the counts and alarms showed before and after.
2. Interpretation layer: why the interruption was classified, who confirmed it, and which governed reason code was used.

More precise automatic detection only creates false precision if normal waiting or a communications gap is assigned to an equipment cause. Conversely, a manually entered reason is incomplete when the actual start and end window cannot be reproduced. Preserve raw state changes first, then retain the automatically proposed reason and the human-confirmed reason as separate fields.

This article does not prescribe one universal number of seconds for a “minor stop.” A ten-second interruption has a different meaning on a three-second-cycle process and a ninety-second-cycle process. The site should own the duration-band policy, base it on process behavior and improvement purpose, and retain its change history. ISO 22400-1 provides an industry-neutral framework and terminology for manufacturing-operations-management KPIs; selecting one threshold does not automatically make an OEE result compliant with that framework.

Why short interruptions are missed—and disputed after aggregation

Operators correctly prioritize recovery

During a short interruption, the operator’s correct priority is safe recovery. Requiring a person to open a terminal and navigate a deep reason tree for every event leads to delayed entries, batch entry, and unanswered prompts. Treat this as an interaction-design problem, not an individual failing. Provide a short confirmation window after the event, show only a few context-relevant choices near the machine, and allow supervisor review.

A PLC state alone lacks production context

A controller may know run, stop, and alarm states but may not know whether material waiting was planned, whether downstream quality imposed a hold, or whether the line was changing products. The OPC UA for Machine Tools material on time-based KPIs derives durations from states and combined states while recognizing that external context may not be available to the controller. Equipment state therefore needs to be joined with job, product, operating mode, adjacent-machine state, and quality context.

“Stop count” changes when system boundaries differ

If a stop signal returns for 0.5 seconds and drops again, is that one event or two? If the monitored asset stops three seconds after its upstream machine, should both be counted as causes? If the network disappears for twelve seconds, was the machine stopped? Without reconstruction rules, the PLC screen, monitoring system, and shift report will disagree. Agree on event-boundary rules first; counts are an output of those rules.

Define minor stops with a band policy, not a single magic threshold

Thresholds should be a site-owned policy, not an immutable vendor value. An initial design can use several duration bands. The numbers below are configuration examples only and must be tested against normal cycle time, signal quality, and actual recovery behavior.

For an asset with a normal forty-second cycle, a short state transition at cycle completion must not be counted as downtime. On a high-speed conveyor, two seconds may affect several units. On a semi-manual process, a fifteen-second wait may be part of standard work. A lower threshold is not automatically more advanced. The useful setting separates normal and abnormal behavior consistently and can be explained by the operating team.

The policy should identify the covered assets and modes, effective date, approver, and comparison method as well as the numeric bands. When a threshold changes, do not compare the old and new counts without qualification. Keep raw data that can be reprocessed under the previous rule or show the rule version on the dashboard.

The minimum event model to preserve before aggregating equipment monitoring data

The OPC UA for Machinery Monitoring building block provides entry points for status, health, process, and consumption information and references machinery state and operation mode. Whether the implementation uses OPC UA or another protocol, a minor-stop dataset should preserve the following evidence first.

For the broader collection foundation, see equipment runtime log capture in Thailand. This article narrows the scope to reconstructing short events and confirming reasons. Connect the results to the factory OEE improvement guide without allowing a minor-stop band to replace the site’s complete OEE time model.

Clock quality matters as much as a reason code

If PLC, edge computer, SCADA, and server clocks differ, the apparent order of an upstream and downstream stop may reverse. Alongside collection time, retain the source timestamp where feasible, clock-synchronization condition, and receive delay. FAT/SAT should intentionally remove synchronization and verify that the system warns users and can exclude “unhealthy clock” intervals from causal analysis.

Do not discard raw events and retain only daily totals

Threshold and merge rules will change during improvement. If only daily event count and downtime remain, historical data cannot be reprocessed. At least through the PoC, link state transitions, rule version, and classification result so that identical input reproduces an identical event list.

Separate detection output from classification output

The detection engine decides when an event occurred. Classification decides why. Keep these fields distinct:

• auto_reason: reason proposed by a rule or model;
• auto_confidence: confidence or supporting basis;
• confirmed_reason: reason confirmed by an operator or supervisor;
• confirmed_by / confirmed_at: accountable person and timestamp;
• comment: exception explanation or improvement note; and
• reason_code_version: the governed taxonomy version.

Do not overwrite and erase the automatic reason when a person corrects it. Retaining both creates useful evidence—for example, “classified automatically as sensor failure, confirmed as part orientation.” If the confirmation window expires, keep the event as unconfirmed rather than forcing a cause.

Make operator confirmation brief

Show event start, end, duration, adjacent states, and a small set of suggested reasons. Consider avoiding a preselected automatic answer that can be confirmed without attention. Reserve free text for exceptions, establish a correction period, and enable supervisor review.

Start with a compact, change-controlled reason hierarchy

A hundred codes at launch produces inconsistent entry. In a PoC, begin with two or three hierarchy levels and only a few choices at one time on the operator screen.

For each added, merged, or retired code, record the request, affected assets, effective date, mapping to the prior code, and approver. If “other” rises, review its notes and decide whether to add a code or reorder the interface. Prohibiting unknown merely encourages users to select the nearest wrong answer.

Rules for overlap, oscillation, communications gaps, and propagation

When comparing equipment monitoring systems, assess reconstruction behavior before dashboard appearance.

1. Overlapping interruptions

If several alarms occur during one stopped interval, do not add the same equipment downtime repeatedly. Link multiple evidence records to one parent event. Root-cause classification and alarm volume are different metrics.

2. Rapid stop/restart oscillation

Preserve the raw signal, then optionally merge transitions that occur within an approved merge gap. Users must be able to audit event count before and after merging. Investigate input quality so that software is not merely hiding physical contact bounce.

3. Network gaps

Do not declare a disconnected interval to be either running or stopped. If the last value is held on screen, mark its quality bad or unknown. Use edge store-and-forward to recover history after reconnection and suppress duplicates using stable event IDs. If recovery is impossible, classify the interval as data-quality failure.

4. Planned downtime and normal waiting

Identify breaks, changeovers, cleaning, planned maintenance, and quality approval waits with the applicable calendar and operating mode. Still capture actual start and end times so actual duration can be compared with plan.

5. Starvation, blockage, and line propagation

When the target asset stops for lack of material, link it to the first upstream event as a root event. Apply the same logic to downstream blockage. If the same propagated loss is summed at every machine, the line total inflates. Display “machine-view interruption” separately from “line root-cause loss.”

Transparent worked example: measure stop seconds and classification quality

The following is an illustrative fictional example, not an industry benchmark, customer result, or promised outcome. Assume a monitored machine with a forty-second normal cycle, a 480-minute shift, a thirty-minute planned break, and a twenty-minute planned changeover.

Planned production time is 480 - 30 - 20 = 430 minutes, or 25,800 seconds. Automatic detection returns 172 candidates. After applying agreed rules for normal cycle boundaries, duplicates, planned waiting, and communications gaps, 126 events remain for confirmation.

If another downtime class contributes 38.0 minutes, illustrative operating time is 430 - 22.2 - 38.0 = 369.8 minutes. With planned production time as the denominator, availability in this example is 369.8 ÷ 430 = 86.0%. This is a teaching calculation; the real KPI must use the site’s time model, exclusions, and documented relationship to ISO 22400 or other chosen framework.

By confirmed reason, assume sensor contact bounce accounts for 34 events/204 seconds, part alignment for 28/392 seconds, downstream blockage for 22/440 seconds, and all other reasons for 42/296 seconds. The totals reconcile to 126 events and 1,332 seconds. If the first two reason groups could each have their duration cut in half, the candidate reduction would be (204 + 392) ÷ 2 = 298 seconds = about 4.97 minutes per shift. Minor-stop time would become 22.2 - 4.97 = about 17.23 minutes; holding all other conditions constant, operating time would be about 374.77 minutes and availability 374.77 ÷ 430 = about 87.16%.

Under the strong assumptions of two shifts per day, twenty-two operating days per month, identical recurrence, and fully sustained improvement, the time conversion is 4.97 × 2 × 22 = about 218.7 minutes, or about 3.6 hours per month. This is not a payback commitment. Verify repeatability, quality impact, added labor, maintenance cost, and whether the asset is truly a bottleneck before converting time into money.

The lesson is not to make 172 raw candidates the KPI. The team can compare periods only when it can explain the 126 reconstructed events along with merge rules, exclusions, confirmation rate, unknown rate, and data-quality rate.

A 30-day PoC: prove event reproducibility on two or three assets

Before plant-wide rollout, select one bottleneck process and two or three contributing assets. The PoC should not promise a dramatic productivity gain. It should prove that events are reproducible, operators can confirm reasons without unreasonable burden, and signed evidence can support improvement decisions.

During shadow collection, do not use the screen for personnel evaluation or an official KPI. Doing so while false events remain destroys trust. Once a week, manufacturing, maintenance, quality, and IT/OT owners should review unknown and unconfirmed events and version any rule changes.

Quantify PoC acceptance criteria for the actual project

The following are acceptance topics; numeric targets must be selected from the asset and baseline study.

• Replaying an approved test interval yields the same event list.
• Start/end, duration, state, product, and count agree with raw evidence.
• The system explains gaps, recovery, and duplicate suppression after disconnect.
• Clock-health faults are visible and separable from healthy data.
• Automatic and confirmed reasons, corrections, and identities remain auditable.
• Unauthorized users cannot change thresholds or the reason taxonomy.
• Operator confirmation time and unconfirmed rate can be measured.
• A third party can recompute the aggregation from CSV/API output.
• The team can execute rollback and restore the previous configuration.

If an acceptance criterion says “99% detection,” also define how ground truth is created, which modes and intervals form the denominator, and how timing tolerance is scored. A percentage without those definitions is not a complete acceptance test.

What to require in an equipment monitoring RFP

Ask bidders to respond to the same scope, not merely list licenses and screens.

1. Connection scope: PLCs, protocols, scan interval, edge architecture, added hardware.
2. Event replay: ability to recreate the same event from supplied raw input.
3. Time: synchronization source, offset monitoring, timezone, loss-of-sync behavior.
4. Disconnect recovery: store-and-forward capacity, resend order, gap display, deduplication.
5. Classification governance: reason version, approval, effective date, automatic/confirmed retention.
6. Audit trail: who changed a threshold, reason, or event and when.
7. Permissions: separation of operator, supervisor, maintenance, and administrator roles.
8. Export: CSV/API access to source events including time and quality.
9. Performance: display/collection latency, peak event load, retention.
10. Support: backup, restore, update, rollback, and remote-support conditions.

A lower-cost option is not inherently inferior; the problem is comparing unequal scopes. Separate PoC services, onsite work, PLC tag preparation, network changes, training, cloud fees, maintenance, and future-asset pricing. Do not generalize cost before inspecting the factory.

FAT/SAT: accept evidence, not a dashboard demonstration

At FAT, use simulated events and saved raw data to test threshold boundaries, overlap, oscillation, disconnect, clock offset, permissions, audit, export, and restore. At SAT, test real equipment, the production network and clocks, actual jobs, upstream/downstream propagation, and operator interaction.

Each acceptance record should identify test ID, date/time, asset, software/configuration/reason-code versions, input, expected and actual outcome, disposition, open issue, and approver. Receive machine-readable event output and a configuration backup, not screenshots alone.

OT security: monitoring should not casually create a control path

NIST SP 800-82 Rev. 3 addresses OT security while recognizing performance, reliability, and safety requirements. Do not add a convenient write path from a monitoring server to PLCs without a separate design decision. Prefer read-only collection where feasible. If writing is necessary, specify the permitted tags and purpose, authorization, change procedure, and failure behavior.

Document OT zones and flows, firewall rules, accounts, secret storage, start/approval/end of remote sessions, activity logging, patch approach, backup, and rollback. Cloud versus on-premises alone does not decide security; diagram what data moves, from where to where, and under whose authority. Give temporary PoC accounts and firewall exceptions an expiry date.

What the weekly improvement meeting should review

Review data and operational health alongside event count and duration:

• raw candidates, reconstructed events, exclusions, and exclusion reasons;
• minor-stop seconds by band, product, and mode;
• confirmed, unconfirmed, unknown, and correction rates;
• bad source-quality time, unhealthy-clock time, and unrecoverable gaps;
• propagation time and linked root events;
• Pareto of confirmed reasons and week-over-week movement; and
• countermeasure date, asset, rule version, and persistence of outcome.

Reducing count alone can be achieved by increasing the merge gap. Show downtime seconds, good output, quality holds, safety outcomes, and operator effort, and separate periods before and after a rule change. Use the major line-stoppage root-cause guide for long events and the equipment alarm notification guide for immediate alerts; neither should be duplicated inside a minor-stop cluster article.

Thailand investment context and the BOI caveat

Thailand BOI’s published Smart and Sustainable Industry measure describes, for eligible improvement investments, a minimum investment of THB 1 million and a three-year corporate-income-tax exemption capped at 50% of qualifying investment, or 100% where the stated domestic automation-industry linkage condition of at least 30% is met. Eligibility depends on the specific activity, timing, investment content, and how the linkage condition is assessed. A monitoring PoC is not automatically eligible. Confirm current conditions with BOI or a qualified adviser.

A BOI/OSOS update for the first half of 2026 reports 132 Smart and Sustainable Industry applications worth approximately THB 17.2 billion. This is market context showing that improvement investments are being proposed in Thailand; it is not evidence of ROI for any particular minor-stop project. Build the decision from plant evidence and signed acceptance criteria, without assuming an incentive.

Implementation decision checklist

Data boundary

• [ ] Select the bottleneck process and two or three target assets.
• [ ] Define normal cycle, planned waiting, and stop-candidate states.
• [ ] Define time source, source quality, and communications-gap treatment.
• [ ] Retain both raw states and reconstructed events.

Shop-floor operation

• [ ] Begin with a compact taxonomy including unknown and data-quality failure.
• [ ] Design an operator confirmation window and supervisor correction.
• [ ] Include a shadow period with no personnel or official KPI use.
• [ ] Name the weekly reviewers and change approver.

Procurement and acceptance

• [ ] Put PoC scope, exit criteria, and stop conditions in the RFP.
• [ ] Compare event replay, recovery, deduplication, audit, roles, and API.
• [ ] Inject abnormal conditions at FAT/SAT and retain machine-readable evidence.
• [ ] Verify read-only boundary, remote access, logs, backup, and rollback.

Frequently asked questions

Where should a minor stop reduction program begin?

Choose two or three assets in a bottleneck process and define normal-cycle, planned-wait, and stop-candidate states. Before scaling, run a thirty-day PoC including roughly ten days of shadow collection and prove that the same raw input reproduces the same event list.

What threshold should minor stop monitoring use?

There is no universal answer. Create provisional bands from normal cycle time, signal noise, recovery behavior, and production impact, then tune them against raw evidence. Version the threshold, scope, effective date, and approver.

How should equipment monitoring system costs be compared?

Compare the same scope: licenses, PLC tag preparation, edge hardware, network, PoC, onsite service, training, cloud, maintenance, and additional assets. Confirm whether event replay, disconnect recovery, audit, API, and rollback are included. Do not apply a generic price without a site study.

How does this improve equipment availability and OEE?

Place confirmed minor-stop seconds correctly in the site’s time model and agree whether they are availability loss or another category. Avoid overlap with performance and quality loss and prevent a threshold change from appearing as a real OEE improvement. One threshold does not automatically establish ISO alignment.

What if operators do not enter reasons?

Do not force the nearest incorrect answer. Reduce the number of choices, provide a short confirmation window, preserve “unconfirmed,” and use weekly review to improve the interface and taxonomy where nonresponse is concentrated.

Must a monitoring PoC write to the control PLC?

Prefer a read-only architecture when monitoring can work without writes. If a write is unavoidable, separately engineer permitted tags, authorization, change control, failure behavior, and the safety boundary, then verify them in FAT/SAT.

Conclusion: a reducible minor stop begins as an explainable event

Minor stop reduction should not begin with a stop-count target. It begins by linking a site-owned duration policy, reproducible start/end, machine and production context, clock/source quality, separate automatic and confirmed reasons, and a change-controlled taxonomy. Use a thirty-day PoC on two or three assets to verify shadow collection, weekly review, event replay, disconnect recovery, audit, permissions, and FAT/SAT evidence before authorizing plant-wide rollout.

Even if the stop definition, PLC tags, reason hierarchy, and PoC acceptance sheet are not yet consolidated, TOMAS TECH can support monitoring requirements, data integration, a thirty-day PoC, and RFP/FAT/SAT design. To discuss the current assets and available data without assuming a packaged minor-stop product, use the TOMAS TECH contact page.

References

• ISO 22400-1:2014 (confirmed in 2025)
• OPC UA for Machinery — Monitoring
• OPC UA for Machine Tools — Production-running overview
• OPC UA for Machine Tools — Time-based KPIs
• NIST SP 800-82 Rev. 3
• Thailand BOI — Smart and Sustainable Industry
• BOI/OSOS — 1H 2026 investment update