There are countless reasons why a machine might fail to start, but there is only one reason why it stopped

Posted by on

 


Root Cause Analysis and State Management in Motor Circuits: A PackML Perspective

In the world of industrial automation, there is a fundamental truth regarding machine states: There are countless reasons why a machine might fail to start, but there is only one reason why it stopped.

I used to spend hours on technical support calls troubleshooting field issues. When things got heated, I would often paraphrase Tolstoy’s famous opening to Anna Karenina: "Normal machines are all alike; every dysfunctional machine is dysfunctional in its own way." That usually gets the point across immediately.

The Problem: The "Silent" Downtime

Most field engineers have faced these exact scenarios:

  • The machine stops, but the HMI provides no clear indication of why.

  • The operator attempts a Reset, but the sequence fails to initialize, leaving everyone guessing.

The root cause is rarely a mechanical failure; it is an architectural oversight in the PLC logic. If a physical button or HMI object doesn't provide a state feedback marker before execution—or if a "Start" command fails without a descriptive interlock message—the User Experience (UX) suffers.

From a safety and reliability perspective, a machine stops to enter a state that is safer than its running state. Failing to communicate the specific transition trigger via the UI is a major design flaw.

Beyond Simple Logic: The Need for State Machines

If we ignore the diagnostics mentioned above, a single line of code (or a simple rung of Ladder Logic) is technically "sufficient" to start and stop a motor safely. Whether written in LD, ST, or any other IEC 61131-3 language, the functional outcome is the same.

However, professional engineering requires more than just making a motor turn. It requires managing the contradiction between "functional code" and "diagnostic clarity." In my experience, the most robust solution for this is a structured State Machine, specifically PackML (Packaging Machine Language).

How PackML/OPC UA Handles "StopReason"

The PackML/OPC UA specification is explicit: StopReason is the first event captured during a downtime incident. Once this event is latched, the state transitions away from Execute, and the StopReason is locked to prevent it from being overwritten by secondary faults.

While PackML manages the "Categorization of State," the PLC program must handle the "First-Out Logic" (First-Hit Detection). When these two work in tandem on an HMI, the system becomes truly user-friendly. Without this, the HMI simply displays a "Shotgun Blast" of alarms, leaving the operator to guess which one was the root cause.

1. The Architecture: StopReason vs. Alarms

In the OPC UA PackML Companion Specification, StopReason is located under the PackMLAdminObjectType. It is defined as:

A structure used for "Stop Reason Events." It is similar to an Alarm but specifically represents the primary cause captured during an Abort, Hold, Suspend, or Stop event.

This architecture distinguishes between Alarms (which can exist in multiples simultaneously) and the StopReason (which identifies the specific catalyst for the current downtime).

2. Capture Timing: The Transition Trigger

According to the PackML definition, StopReason is not updated haphazardly. It is latched specifically when a transition occurs from a "running" state to a "stopping" state. The standard highlights four specific event types:

  • Abort

  • Hold

  • Suspend

  • Stop

By latching the reason at the exact moment the equipment exits the Execute state, we ensure that the root cause is preserved before it is buried by a cascade of secondary "Emergency Stop" or "Loss of Power" alarms.

3. The Data Structure

The StopReason is not a simple integer; it is a Data Structure comprising multiple sub-variables designed to describe the initial stoppage event in full context—ensuring that the "First-Out" is not just captured, but understood.