Machine Downtime Tracking: Run Signal First, Not MES

After a run-signal logger is installed, the shop has timestamped evidence of every stop instead of relying on memory. Start with one trustworthy machine-state signal, preserve communication loss as a separate state, and add reason capture only after the duration data is reliable.

Current, Load, and Elapsed Downtime

A motor, compressor, spindle, or pump draws current when energized. That current produces thermal load and can provide a practical indication that part of a machine is active. It does not prove that the machine is producing acceptable parts: a motor can run while the process is starved, blocked, warming up, idling, or being set up.

The number that matters is elapsed time between valid state transitions. For each stop:

downtime = restart timestamp - stop timestamp

This calculation requires a defined production state, a common time base, and retained transition records. A daily total must also distinguish stopped time from missing data. A blank interval caused by a failed connection is an unknown interval, not confirmed downtime.

Quantity	Decision or limit	Where to read it
Running state	Choose the signal that most closely represents production, not merely control power	PLC logic, electrical drawing, machine status output, or measured load trace
Stop and restart times	Record every accepted transition using one clock	Logger, PLC event record, SCADA historian, or database
Signal chatter	Filter only pulses proven to be non-production transitions	Trend the raw input before selecting a filter
Communication state	Classify loss of updates separately from stopped	Heartbeat, connection status, or last-update timestamp
Reason	Keep the operator list short enough to complete consistently	Tablet, HMI, workstation, or reviewed shift record

Symptoms and Likely Causes

Observed record	Likely cause	Diagnostic action
Logger shows running while no parts are produced	The selected current or status signal represents an energized subsystem rather than productive operation	Compare it with cycle completion, part detection, speed, or another process value
Many short run-stop transitions	Contact bounce, control-state chatter, intermittent power, or an unsuitable signal	Trend the unfiltered signal and correlate it with machine events before applying a time filter
Several machines dip or stop together	A shared power, network, server, or time-source event may be involved	Align timestamps across all machines and examine common infrastructure
A white gap appears in a plot	The logger lost power, communications, storage access, or its data source	Check the heartbeat and last valid sample; label the interval unknown
Long stops have no reason	Reason entry is inconvenient, delayed, or contains too many choices	Reduce the list, allow later review, and prefill causes that can be derived from controller events
Reported downtime emphasizes breakdowns	Memorable maintenance events overshadow routine setup and waiting losses	Rank recorded intervals by total duration and frequency rather than recollection

Collection Approaches Compared

Paper, spreadsheets, automatic signal logging, SCADA, controller-to-database messaging, dedicated products, and custom applications all solve different parts of the problem. The selection hinges on timestamp accuracy, operator effort, expansion needs, and who will maintain the system.

Approach	Automatic duration	Reason capture	Expansion path	Main constraint
Paper or whiteboard	No	Manual	Manual transcription	Missing and rounded timestamps
Spreadsheet	Only with an automatic data source	Usually manual	Possible reporting and imports	Editing discipline and version control
One-signal logger	Yes	Optional	Add sensors, speeds, counters, and reason entry	The signal may show energized time rather than production
Simple SCADA	Yes	HMI or workstation entry	Historian, alarms, trends, and multiple machines	Configuration and lifecycle ownership
PLC to database	Yes	Controller events plus operator input	Structured plant reporting	Database interfaces, retries, buffering, and security
MQTT to a broker such as Mosquitto	Yes	Added by the application	Text files, databases, and dashboards	Topic design, retained state, credentials, and store-and-forward behavior
Dedicated downtime or OEE product	Yes	Typically integrated, subject to selected product	Packaged displays and reporting	Subscription, hardware, installation, and contract terms
Custom single-board-computer application	Yes	Application dependent	Highly adaptable	Documentation, passwords, source ownership, and maintainer continuity

For the commercial offers evaluated in this case, pricing began around €150 per machine per month, plus hardware, with a three-month notice period. That figure is a purchasing input for those offers, not a universal OEE price. A basic one-signal implementation was considered achievable for a few hundred dollars, but the final cost follows the isolation hardware, enclosure, installation, communications, and reporting method selected.

A Vorne system is one dedicated-product route represented in the installation experience. Siemens controllers also provide a path for sending error events to a database through PLC library and query functions. Comparable event transfer is feasible on other controller platforms, including Rockwell systems, but the engineering method and effort depend on the available communications features.

Recommended Minimum Architecture

For a shop with a handful of machines and no MES, begin with automatic state duration rather than a full OEE deployment. Use one signal per machine, a timestamped event store, a connection heartbeat, and a simple daily report. This produces useful evidence without making operator reason entry a prerequisite for recording downtime.

The preferred signal order is:

1. A controller state that explicitly represents automatic production.
2. A cycle-complete or part-produced event when cycles are discrete.
3. A machine output documented as running or ready.
4. A measured electrical-load signal when controller access is unavailable.

A load signal is often the quickest retrofit, but validate what it means. This is heat, not logic: current proves that a load is drawing power, while production requires a separate process interpretation. If one signal cannot distinguish setup, idle, blocked, and productive running, retain the binary record and add classification signals later.

Store transitions rather than relying only on periodic plot images. A transition record needs the machine identity, previous state, new state, timestamp, data-quality status, and optional reason. Preserve raw samples temporarily during commissioning so signal filters can be checked against actual behavior.

Installation and Commissioning Procedure

1. Define the production boundary. Decide whether downtime begins when automatic operation stops, when part flow stops, or when a scheduled production period fails to produce. Write that definition beside the report.
2. Select one authoritative signal. Review controller logic, drawings, existing outputs, and observable loads. Reject signals that remain active through normal idle periods unless energized time is the intended metric.
3. Observe the raw behavior. Plot the candidate through running, planned stops, setup, faults, starvation, and restart. Note chatter and delays without assigning an arbitrary filter.
4. Create explicit states. At minimum, record running, stopped, and unknown. Add off-schedule or not-planned only if the production schedule is available and maintained.
5. Timestamp transitions. Use the same clock for every machine and server involved. Store the original event time when data is buffered rather than replacing it with the later database receipt time.
6. Add connection supervision. Record a heartbeat or last-update time. When updates disappear, open an unknown interval instead of extending the previous running or stopped state.
7. Pilot one machine. Compare recorded transitions with direct observation across normal production, setup, a controlled stop, and a communications interruption.
8. Add reason capture. Request a reason after the duration is already secured. Use a short cause list, permit supervisor correction, and retain an unclassified option rather than forcing an inaccurate answer.
9. Document ownership. Record signal sources, network paths, database schema, credentials custody, backups, source-code location, restore steps, and the person or company responsible for changes.

Reason Codes and Actionable Losses

Automatic timing answers when and how long. It rarely answers why without controller events, process context, or operator input. Separate the measurement layer from the reason layer so an ignored tablet prompt cannot erase the stop itself.

Start with categories that lead to different actions: breakdown, setup or changeover, waiting for material, waiting for an operator, quality hold, planned stop, and unclassified. Expand a category only when repeated events justify a more specific corrective path. A large taxonomy introduced before operators trust the system increases skipped or guessed entries.

Routine losses often matter more than memorable faults. A two-hour maintenance event attracts attention, while repeated setup time may accumulate to the same duration and remain accepted as normal. The setup loss is frequently more controllable through preparation, sequence changes, staffing, or production scheduling; the logger makes that comparison visible.

Once state timing works, add sensor values, speeds, fault events, and production counts where they help classify losses. Plot related values around points of interest instead of retaining every high-rate value indefinitely. Correlate simultaneous dips or spikes across machines before blaming an individual asset.

Verification, Reporting, and Lifecycle Control

Verify the recorder with known events rather than visual plausibility. Trigger a controlled stop and restart, record the observed times, and compare them with stored transitions. Disconnect the data path and confirm that the report displays unknown time rather than machine downtime. Repeat the check for a planned setup so the state and reason layers remain distinct.

Reconcile each reporting window:

observed time = running time + stopped time + unknown time

If a schedule is applied, reconcile scheduled production separately from off-schedule time. Report both total duration and event count: one long stop and many short stops can require different corrective work even when their totals match.

Storage and analysis become the limiting resources as signals are added. Retain transition events for long-term comparisons, select an appropriate retention period for detailed trends, and test restoration from backup. AI-assisted analysis can group patterns or prioritize intervals, but the recorded state, timestamp, and data-quality flag remain the event truth.

A custom application must survive the departure of its developer. Keep architecture notes, build instructions, source, passwords under company control, and a tested replacement procedure for every field device. An undocumented dashboard that cannot be changed or authenticated is an operating dependency, not merely a reporting tool.

Frequently Asked Questions