Purpose and Acceptance Criteria #
Alarm and event design is usually the last functional layer validated on a warehouse automation project, yet it is often the first thing operators rely on when a conveyor stop, pallet jam, or WCS order timeout occurs. This article provides a commissioning and acceptance checklist for controls technicians, PLC programmers, WCS integrators, and maintenance leads who need to confirm that alarms and events are meaningful, correctly timestamped, and traceable from the field device to the WCS display and historian.
Acceptance is not simply confirming that a red banner appears on a screen. It require that alarm texts correlate to a physical condition, that the event sequence matches the actual electrical and mechanical sequence, and that maintenance staff can act on the message without guessing. The practice below is written for site teams using their own hardware and software environments. It does not replace OEM commissioning documentation, site-specific risk assessments, or factory acceptance tests supplied by equipment vendors.
Operating Context and Component Interactions #
A typical automated warehouse controls environment contains three interacting layers: the PLC layer, the WCS layer, and the network/interface layer between them. The PLC continuously scans inputs, executes machine logic, and writes diagnostics to its local tag base. The WCS orchestrates order routing, zone assignment, and equipment state machines by issuing commands and reading feedback. Alarms and events are the translation layer between these two worlds.
PLC States and Diagnostic Outputs #
The PLC is the source of truth for low-level conditions like motor overloads, photoeye blocked timeouts, positioner faults, and safety relay states. During commissioning, the PLC must be placed in a known state—generally Run or Remote with outputs disabled for dry tests—before any alarm acceptance testing begins. Many commissioning issues trace back to teams testing alarms while the PLC is in a maintenance state, which masks timestamps or prevents WCS communication from waking.
Ensure that alarm tags in the PLC follow a consistent state convention across all routines. For example, a TRUE signal might mean “fault active,” but another routine might invert the same condition. Acceptance checks must include reading the raw tag, the OPC-UA or EtherNet/IP mapping, and the WCS database point to confirm the state was not inverted somewhere in the chain.
WCS Orchestration and Event Flow #
The WCS does not usually read field devices directly. It subscribes to PLC tags or reads periodic scans through an interface engine. When the PLC writes an alarm bit or event occurrence, the WCS stamps the scan cycle time, enriches the raw tagname into a readable description, and stores it in an event table. The same event may trigger WCS orchestration actions, such as stopping downstream zones, sending a maintenance notification, or raising a service ticket.
During commissioning, confirm that the WCS’s handling of alarm severity does not conflict with its orchestration logic. A high-severity fault may cause the WCS to pause a whole route, while the PLC only stopped a single zone. Both behaviors are valid but must be documented and accepted by operations before sign-off.
Interface and Message Flow #
The interface layer is the least trusted but most critical link in the chain. A PLC tag change may update instantly in the PLC’s diagnostics buffer but take one second to reflect in WCS due to polling intervals, message queue delays, or network jitter. The acceptance checklist should record the nominal message latency, the maximum expected latency under burst conditions, and the behavior when a message is lost or duplicated.
Typical message flow is as follows:
- PLC detects condition and raises an internal diagnostic flag
- PLC writes the flag to a comms tag table
- Interface engine detects the change and converts the data to a WCS-compatible format
- WCS validates the point name and maps it to a configured alarm or event
- WCS logs the event, updates the equipment state, and sends an acknowledgement request to the PLC if the system is two-way capable
Pre-Commissioning Checks #
Before energizing any conveyor section or starting functional tests, spend a half day on static checks of the alarm and event configuration. These checks are low-cost but catch most of the issues that otherwise appear as phantom alarms or missing events during full-line testing.
- Tag inventory completeness: Compare the PLC tag list against the WCS alarm import spreadsheet. Every tag that will be used for diagnostics must have a unique identifier, a device name, and a warehouse location.
- Naming conventions: Confirm that all tags follow the site convention, such as EQ-A-BELT01-MOTOR-FLT or similar. Inconsistent naming leads to duplicate alarms and lost events.
- Alarm classes: Verify that each alarm is assigned to an appropriate class—process, equipment, safety, information—and that the WCS class configuration matches the PLC numeric codes.
- Description fields: Reject placeholder descriptions such as “Fault.” A valid description must include the equipment ID, the physical condition, and a suggested action.
- Suppression logic: Confirm the philosophy for nuisance alarms. Some alarms are expected during normal stops (e.g., no package present). Those should be suppressed at the PLC, not in the WCS display layer.
- Timestamp method: Decide whether the PLC or WCS timestamp carries authority. Mixed timestamping causes confusion during root cause analysis.
Functional Test Design #
Functional testing for alarms and events is fundamentally a cause-and-effect validation. You must be able to create the physical condition, observe the PLC state, and see the WCS event with the correct message and severity. Testing should progress from the smallest physical scope to the largest.
Begin with a single photoeye or limit switch. Break the beam manually and verify the PLC input change, the PLC alarm bit, the WCS display, and the event log. Then move to a component-level fault, such as a motor overload. If practical, simulate the overload by placing an ammeter in line or using the PLC input forcing procedure, but only when that is allowed by site policy. Never bypass safety devices under any circumstances. Site procedures, lockout requirements, OEM documentation, and competent engineering judgment take priority over any commissioning checklist.
Message Timing and Burst Scenarios #
Alarm acceptance should include burst testing. A conveyor section with multiple simultaneously jammed zones can generate dozens of events within one second. Confirm that the WCS event engine does not drop messages, reorder timestamps, or block operator displays during burst conditions.
To run a controlled burst test, place the conveyor into a safe state and manually trip multiple photoeyes in rapid succession. Record the number of events generated by PLC versus the number stored in the WCS database. A 100% match is the acceptance criterion. Any missing events require investigation of the interface queue buffer or the WCS message timeout setting.
Loss of Communication and Recovery #
Network loss between PLC and WCS is inevitable over a system’s lifetime. The acceptance checklist should verify how alarms and events behave during a disconnect and reconnection. Decide and document whether the WCS should clear stale alarms on PLC return, or whether a full resync must be triggered manually.
For Ethernet/IP or OPC-UA interfaces, simulate the loss by disabling the network port on the PLC side. Observe the WCS health monitor and ensure that the connection status changes to “not connected” and that a session-level event is raised. When the connection returns, confirm that the WCS receives the full current alarm snapshot, not just the deltas since the disconnect. This is a common gap that can leave stale alarms visible for hours.
Practical Diagnostic Table #
The following table includes commonly observed failures during alarm and event commissioning. Use it as a reference when investigating discrepancies between physical conditions, PLC states, and WCS displays.
| Observable Symptom | Probable Cause | Evidence to Collect | Typical Resolution Path |
|---|---|---|---|
| WCS shows alarm but no physical condition exists | Stale PLC tag retained in WCS after reconnection | Compare PLC current scan value with WCS database value at the same minute; note connection drop timestamps | Enable full snapshot read on reconnect; manually clear the stale event and retest |
| Two alarms with the same text appear from one device | Duplicate tag mapping or inconsistent naming convention | Export the WCS alarm mapping table and filter by the device ID; list all occurrences with source tag names | Remove the duplicate mapping; enforce unique tag names at PLC level |
| Event appears with a timestamp earlier than the PLC timestamp | Clock skew between PLC and WCS server | Log both timestamps for a known event; record server NTP status and the PLC uptime command output | Synchronize both devices to the same time source; establish the master clock authority |
| Alarm clears in WCS but PLC input is still active | Clearing logic triggered by WCS acknowledgment instead of actual machine state | Check the alarm acknowledgment logic in WCS scripts; verify the PLC reset request tag against the input state | Change the clear condition so that acknowledgment only silences, not clears |
| Single physical fault triggers dozens of related events | Cascading alarm design with no root-cause suppression | Log the sequence with a high-resolution event recorder; identify which event fired first in the PLC scan list | Add alarm suppression masks for secondary effects; designate one root-cause alarm per zone |
Use this table as a starting point for your own site-specific diagnostic log. Every warehouse has unique equipment, interface drivers, and operator expectations, so do not treat this as an exhaustive resolution manual.
Evidence Collection and Logging Practices #
Commissioning tests are worthless without recorded evidence. For every alarm or event test, store the following minimum set of records:
- Date and time of test
- Test case ID and description
- PLC program version and WCS build version
- Physical action taken to trigger the condition
- Observed PLC tag value before and after the test
- WCS event text, severity, and timestamp as displayed
- Name of the technician performing the test
- Screenshot or exported log of the result
Organize these records in a shared repository that is accessible to the maintenance team after go-live. A spreadsheet with filters and a documented folder structure is often more practical than a complex wiki. The goal is that a maintenance technician troubleshooting a night-time jam can look up the commissioning evidence and see exactly which fault was tested and how.
Pay particular attention to the PLC scan order. If a motor overload and a subsequent photoeye jam happen within the same PLC scan, the WCS may log them in the order they appear in the communication tag table, not the physical order. To avoid this, evidence should include a scan order listing or a timestamp with sub-second resolution from the PLC diagnostic buffer.
Common Interpretation Errors #
Even with correctly configured alarms, teams often misinterpret event data during commissioning and early operation. One common error is treating all WCS events as PLC alarms. The WCS may generate events such as “order timed out” or “carrier not assigned,” which are orchestration-level conditions, not machine faults. Operators should be trained to distinguish “I know what is broken” from “I know what did not happen,” as these require different response actions.
Another error is assuming that the first-event timestamp is always the root-cause event. In a high-speed sorter, a jam sensor may fire a few milliseconds after the servo drive faulted. The WCS screen displays the jam first because it arrives through a faster message path. The diagnostic investigation should always go back to the PLC scan log to identify the true first event.
A third error is accepting an alarm without validating the recovery behavior. A maintenance technician may acknowledge an alarm, but the WCS may still hold the zone in a faulted state. The acceptance test must include the complete lifecycle: raise alarm, acknowledge alarm, physically clear condition, release fault, resume operation. Some systems have separate reset and acknowledge steps, and failing to test all of them leaves hidden traps for the shift crew.
Maintenance Implications #
The quality of alarm and event design directly affects preventive and corrective maintenance workflows. When alarms are well-structured, maintenance teams can classify failures by device type, downtime duration, and recurrence rate. When alarms are poorly structured, the historian becomes a dump of noisy text that no one reads.
During acceptance, define the key maintenance indicators that the event log will support. These may include total downtime, alarms per equipment section, mean time to acknowledge, and the percentage of alarms that repeated within the same hour. The WCS should be able to export this data without custom SQL scripts written by an external consultant. If the export requires manual work, the commissioning team should raise that gap with the software integrator before sign-off.
Also consider the maintenance lifecycle of alarm mappings. When a PLC program changes are made post-commissioning—such as adding a new sensor or renaming a motor—the WCS mapping table must be updated in the same change window. Include a regeneration check in the change management procedure so that the WCS does not continue referencing old tag names. The acceptance checklist should state clearly who owns the mapping table after go-live and how version differences are tracked.
Decision Boundaries and Escalation #
Commissioning personnel must know their authority limits. The decision to accept an alarm sequence with a known delay is a business operational decision, not just a technical consideration. Document each deviation from the original specification, including the impact to operations and who approved the deviation. If a certain alarm cannot be simulated safely, the acceptance record must say so, and a temporary risk assessment is required before the system is placed into production.
Escalate to the controls governance group when:
- Alarm texts are ambiguous beyond simple typo fixes
- The same physical event maps to multiple WCS actions in a conflicting way
- PLC program changes are required during the commissioning window
- The interface protocol cannot deliver a required timestamp accuracy
Similarly, do not rely on operator observations alone to verify alarms. Operators are an invaluable source of real-world insight, but their interpretation of an alarm can be influenced by shift context and memory. Use recorded event evidence as the master reference and treat verbal reports as hypothesis-generating input, not proof of malfunction.
Key Takeaways #
- Alarm and event acceptance is a cross-layer activity involving PLC tag state, interface transport, WCS mapping, and display logic. Each layer must be verified independently and together.
- Pre-commissioning static checks of tag names, descriptions, severity classes, and suppression settings reduce the effort of later functional tests and prevent ambiguous operator messages.
- Functional testing must include single-event triggers, burst scenarios, loss-of-communication recovery, and full lifecycle sequences from raise to reset.
- Use a diagnostic evidence table to structure troubleshooting. Record observations at every layer and do not rely on a single timestamp source to identify root cause.
- One-piece event logs that include test case IDs, versions, and technician names enable later maintenance investigations and reduce repeat commissioning work.
- Do not treat WCS orchestration messages as machine-level alarms. Provide clear training for operators to distinguish equipment faults from operational routing issues.
- Post-commissioning changes to either PLC code or WCS mappings must follow change management that updates the central alarm mapping table version.
- Always follow site procedures, lockout requirements, OEM documentation, and competent engineering judgment, and never bypass safety devices to test warning or fault scenarios.
