Poka-yoke · A closer look
Give every check a clear purpose and boundary.
Understand prevention, detection, quality interlocks and safety functions, with operational records that explain what a check confirms and what happens next.
The practical question
How should error-proofing and interlocks be described in an OT view?
Name the function, the condition it evaluates, the work it covers and the meaning of its result. Make the responsible response easy to find. Keep quality and process checks distinguishable from safety functions, and do not use a shared indicator as evidence that their engineering responsibilities are interchangeable.
Two devices may both stop a cycle while serving very different purposes. A quality check, a sequencing condition and a protective function need clear descriptions of what they establish. That clarity helps people respond appropriately and keeps the operating record from claiming more than the function supports.
Separate prevention and detection
ASQ’s mistake-proofing guidance distinguishes approaches that prevent an error from those that detect it or make it apparent. For the operating record, state which outcome the method is intended to provide. A detected discrepancy and a prevented action should not be counted or explained as identical events.
Sources: [1]
Do not collapse safety into quality
HSE’s machinery guidance describes interlocked guards that prevent hazardous operation under specified access conditions. The assurance needed for such a protective function is different from the interpretation of an ordinary quality check. Changing the way either function is represented should preserve that distinction and the responsible engineering ownership.
Sources: [2]
Make the result specific enough to use
Consider a check intended to confirm component presence. Describe which component, at which stage and for which part or fixture. If the source provides only a general present state, show that limitation. Do not quietly extend the statement to identity, orientation or conformity.
Explain what happens when the check cannot produce a dependable result. Unavailable, not yet evaluated and evaluated with an exception are different states for a reviewer. Keep them readable so a person does not need to infer the meaning from colour alone.
An illustrative situation
When a shared indication creates confusion
Hypothetical example: an assembly station presents several conditions under one message, check failed. The incoming operator cannot tell whether the condition concerns component presence, sequence completion or access to the cell. The review identifies the source functions and the intended response for each.
The proposed improvement is a clearer explanation and route to the established response, with the competent owners reviewing any interface or engineering change. The history retains which condition occurred. A single total is no longer expected to answer several unrelated operating questions.
Keep the function and its record aligned
When an approved change alters the check, preserve the new definition and the period from which it applies. Review whether historical comparisons remain meaningful. A lower exception count may reflect a different function, different work or an unavailable source rather than a process improvement.
An initial discussion with VIEOX can focus on one confusing or difficult-to-review check. Bring the task description, existing indications and the people responsible for the function. We can explore how the available information can express the intended meaning clearly without changing the authority of the underlying control or protection.
Put the question to work
A practical checklist
- State whether the method prevents an error, detects it or verifies a condition.
- Name the work and requirement each result covers.
- Keep safety, quality and sequencing functions clearly distinguished.
- Show unavailable and not-yet-evaluated states separately from passing results.
- Preserve approved definition changes and review their effect on comparisons.
Questions, answered
Can the operating view act as the machine’s protective system?
The operating view should not be assumed to perform a protective function. Protection depends on the engineered system and its required assurance. Keep the display’s role clear: it helps people understand records and responsibilities within the established operating arrangements.
Should every failed check have the same response?
The appropriate response depends on the function, the work and the established procedure. Present that distinction in plain language and identify the responsible role. A consistent visual design can still explain different conditions and their different authorised responses.