Short answer
Andon calls and downtime logs are timestamped records of when a line stopped, where, for how long and why. Joined to footage by time and station, they explain anomalies such as jams, shortages and operator calls for help, and give exception labels for evaluation. They hold no motion or force data and should not be used to score individual workers.
The buyer's problem
Anyone who has reviewed hours of factory video knows that the interesting moments are not the cycles. They are the pauses, the odd motions, the hand waved at a supervisor and the part that gets set aside. Without context, an annotator or a model sees a person stop and cannot tell whether it was a jam, a missing component, a quality hold or a break. The footage is ambiguous, and an evaluation built on ambiguous exceptions is weak.
Plants often keep a second record of the same hours: a log of calls for help, stoppages and downtime reasons. That record is made for operations, not for robotics, but it is exactly the kind of annotation video lacks. This page explains how to source it, what to expect in it and how to keep its use appropriate.
What the records are
- Andon events: a signal, from a button, cord or system, indicating that a station needs help or has a problem. A record typically has a time, a station and sometimes a category.
- Downtime logs: intervals in which a machine or line was not producing, with start, end, equipment and a reason code.
- Stoppage and exception reports: narrative or coded descriptions of what went wrong and how it was resolved.
- Shortage and quality holds: records of material or quality conditions that paused work.
- Changeover records: planned stoppages for switching products; see changeover procedures.
Whether a plant has these in a structured system or on paper is a supplier question. Some plants log from machine controllers, some from operator entry, and the two differ in precision. A machine-recorded stop can be precise in time but says little about cause; an operator-entered reason names the cause and may be entered later and from memory.
What the logs can support
| Use | How the log helps | Caveat |
|---|---|---|
| Exception labeling | Tags stoppages and calls in footage with a cause | Needs a reliable time join |
| Evaluation scenarios | Realistic exception types for a station | Reflects what the plant records |
| Rare-event sampling | Finds footage of uncommon situations | Reason codes can be coarse |
| Context for annotators | Explains why a pause happened | May be entered after the fact |
| Process understanding | Relates stoppages to steps and parts | Does not show how people responded in detail |
Quality systems usually depend on documented information and on evaluating performance. ISO 9001:2026 lists support, including documented information, operation, performance evaluation and improvement among its requirements, and is stated to be generic and applicable to any organization, with certification optional (ISO, 2026). That tells a buyer only that documentation is a normal part of quality management; it does not tell you that a particular plant keeps a particular log, or how.
Joining logs to footage
The practical difficulty is time. Footage clocks, controller clocks and the log system's timestamps often differ by seconds or more. Before purchase, ask for a small sample where an event is visible in video and present in the log, and measure the offset. For the wider problem of aligning production records with video, see MES records aligned to video, and for the footage side see process monitoring camera footage.
Stable keys help: station ID, line ID, shift, work order and, where available, unit serial. A log with only a plant-wide timestamp and a free-text reason is much harder to use than one tied to a station.
Illustrative log extract
# Illustrative only - synthetic values, not an available dataset
log: stoppage_events_v0
site: site_031 (synthetic)
fields:
event_id: evt_000412
station: station_S4
start_time: 2026-03-02T09:14:22 (site clock; offset to video measured separately)
end_time: 2026-03-02T09:17:05
source: operator_call | controller_stop | quality_hold
reason_code: part_shortage | jam | tool_fault | quality_hold | other
reason_text: free text, redacted for names and part numbers
resolution: restocked | cleared | adjusted | escalated
work_order: wo_5521 (pseudonymous)
links:
footage: camera_id and time range containing the event
error_record: optional reference to an error-proofing entry
removed: operator names, badge ids, customer names
excluded: motion data, force data, images unless separately attached
Quality and acceptance criteria
Ask for the code list first, then a sample. A usable log has a stable reason vocabulary, consistent station names, start and end times for each event and a way to tell planned from unplanned stops. Be wary of logs where most events fall into "other", where durations are rounded to the nearest hour or where edits to past entries are not tracked. If you intend to use the log for held-out evaluation scenarios, ask for events from separate periods, stations or lines so that the test cases do not share a source with training material, as discussed in error-proofing records.
Limits: what this data cannot support
Downtime and andon logs are records of exceptions, not demonstrations. They contain no images unless footage is attached, no hand or body motion and no forces. They cannot train a humanoid's control, and neither can footage, SOPs, quality records or recognition and pose labels alone; control needs robot or teleoperation data. They also describe only what the plant chose to record, so an unlogged near miss or micro-stop is absent. Reason codes capture the plant's categories, which may not match your taxonomy, and a stop attributed to one cause may have several.
Stops that end in a repair rather than a restart connect to rework and repair operations. A related caution concerns time-based study. A log of stoppages is not a time and motion study; for that, see time and motion study recordings.
Permissions and provenance, and an important separation
Logs often carry the names or IDs of operators who pressed a button, entered a code or cleared a fault. They may also show customer names in work orders and details of equipment problems the plant considers sensitive. Redaction or removing identifiers does not settle permissions: the plant may still own, or be restricted from sharing, the underlying records, and pseudonymous operator IDs can sometimes be traced back by the plant. Ask who can license the logs and what notice employees had that their entries might be used this way. This is not legal advice. See manufacturing data confidentiality.
Keep the purpose separate. Using stoppage logs to evaluate how a robot perceives and responds to line exceptions is a different activity from using them to monitor which individual operators call for help or lose time. A license, consent record and internal policy should say that the data is for the first and not the second, and buyers should avoid requesting operator-level fields they do not need.
Questions to ask suppliers
- Which systems produce the logs, and how much is machine-recorded versus operator-entered?
- What is the reason-code vocabulary, and how often has it changed?
- Do events carry station, line, shift and work-order keys?
- How far apart are the log clock and any video clock, and can the offset be measured?
- What share of events falls under "other" or has no reason?
- Are operator identifiers present, and can they be removed without losing the event's meaning?
- Can events be linked to footage or to error-proofing records?
- What period and how many stations or lines does the log cover?
Discuss your requirements
If your evaluation depends on realistic line exceptions, describe the stations, record types and permitted uses to SourceX. SourceX looks for US businesses that may hold suitable records, checks the data and the supplier's licensing permissions, and coordinates the license and delivery. It follows up about potential sources; a request does not guarantee a match. The humanoid training data guide and the manufacturing hub place these logs among the other supply routes; the catalog page on sensor and IoT data covers machine-generated streams.
Tell SourceX what your evaluation set needs to cover
Sources
- ISO 9001:2026 Quality management systems - Requirements — generic quality management requirements including documented information.