An equipment alarm notification system should not merely send a high volume of messages to mobile phones. It should detect an event, deliver the right context and deadline to a person who can act, and close the loop through acknowledgement (ACK), escalation, recovery and audit. Procurement teams must also distinguish an alarm—requiring an operator to respond to an equipment or process condition—from a non-alarm notification that assigns work or provides information to maintenance, management or logistics personnel.
This guide helps manufacturing sites in Thailand compare vendors, write an RFP, run a 30-day proof of concept (PoC), and define factory and site acceptance tests (FAT/SAT). It covers the full chain from event source to audit history, the proper role of phones and smartwatches, power and communications failures, multilingual shifts, vendor support and OT security. The 30-day duration and every sample time or quantity below are recommended examples, not external statistics or industry averages. Replace them with the plant’s approved baseline.
Separate operator alarms from non-alarm notifications first
The public summary of IEC 62682:2022 describes the primary function of an alarm system as notifying operators of abnormal process conditions or equipment malfunctions and supporting their response. Its scope includes alarms presented to operators through a control system. By contrast, the ISA public page describes ISA-TR18.2.8-2023 as guidance for non-alarm alerts, prompts and notices intended for people beyond the control-room operator, including maintenance staff, engineers and management. Keeping non-critical messages outside the alarm stream protects the integrity of operator alarming.
This is a difference in responsibility and consequence, not a naming preference.
| Class | Recipient | Expected action | Typical channels | Failure handling |
|---|---|---|---|---|
| Operator alarm | Person operating the process or equipment | Follow a defined response procedure and act on the abnormal condition | HMI, annunciator, light and sound | Follow control-system procedures; never depend only on a phone |
| Maintenance notification | On-call technician or equipment owner | Inspect, diagnose, repair or arrange parts | Phone, smartwatch, maintenance terminal | Provide an alternate contact and manual dispatch method |
| Management notification | Supervisor, manager or plant leadership | Decide, allocate support or approve a shutdown response | Phone, call, email, dashboard | Switch according to impact and urgency |
| Logistics notification | Warehouse, tugger or forklift team | Replenish material, move finished goods or collect containers | Mobile app, display or vehicle terminal | Fall back to radio, paper or timed rounds |
| Information notice | Quality, planning or management | Maintain awareness and perform later analysis | Dashboard or report | Keep it outside the urgent path |
Phones and smartwatches are useful secondary channels for delivering work to people. They do not replace a safety instrumented system (SIS), emergency stop, protective relay, machinery interlock, or local visual and audible indication. Batteries, notification permissions, operating-system power saving, dead zones and device restrictions can all interrupt delivery. An RFP should therefore state which notification classes use which channels and what takes over when a channel fails—not simply request “mobile notifications.”
Design an eight-stage event lifecycle
A point-to-point integration that sends a PLC signal directly to chat or email may deliver a message, but it does not close the operational loop. Treat these eight stages as one lifecycle:
- Event source: acquire state changes from PLC, DCS, SCADA, sensors, power monitoring, MES, quality, maintenance and logistics systems.
- Normalization: convert equipment ID, event code, source time, state, quality, location, operation and lot into a common model.
- Prioritization: classify the event based on safety, quality, lost production, propagation and available response time.
- Routing: select recipients and channels using site, equipment, shift, skill, language, roster and holiday rules.
- ACK: record who received and accepted the assignment, separating message-read from work acceptance.
- Escalation: move responsibility to the next role if nobody accepts or arrives within the approved time.
- Return and closure: record machine return-to-normal separately from completion of work, cause and corrective action.
- History and audit: retain the event states, deliveries, ACKs, changes, suppression and user operations in time order.
The public OPC UA Part 9: Alarms & Conditions v1.05.06 specification defines information models for Conditions, Alarms, acknowledgement, confirmation, severity, quality, comments, shelving, suppression and audit events. Even where OPC UA is not selected, those concepts form a useful completeness checklist. An upstream value of only “abnormal = 1” does not reveal whether the condition remains active, has returned to normal, has been accepted, or comes from a source with poor data quality.
Minimum fields for event sources and normalization
| Field | Example | Acceptance question |
|---|---|---|
| Unique identity | event_id, source_event_id | Does a retry avoid duplicate notification and counting? |
| Source time | UTC source time, displayed in ICT | Is it kept separate from gateway receipt time? |
| Source | plant, line, machine, PLC, tag | Can history still be traced after a master-data change? |
| State | active, returned, acknowledged, closed | Are return-to-normal and business closure separate? |
| Quality | good, uncertain, bad | Is a communications failure distinguished from machine failure? |
| Context | product, lot, operation, mode, shift | Can the system assess impact and required skill? |
| Message | common code plus localized text | Does one code prevent divergent translations? |
| Evidence | original value, threshold, rule version, user | Can the reason for notification be reproduced later? |
Source time matters. If queued events are forwarded after a link recovers and are sorted only by server receipt time, cause and effect may appear in reverse. FAT should test clock synchronization, UTC storage, ICT presentation and explicit time zones. It should also reproduce a restart in which PLCs, gateways and servers start in different orders, then verify retained-state refresh and deduplication.
Make factory alert notifications actionable through priority design
Three colors labelled high, medium and low do not tell a recipient what to do. Every alarm or notification needs an impact, required action, allowed response time, owner and fallback route. Operations, maintenance, safety and quality personnel should rationalize priorities rather than accepting the equipment supplier’s defaults.
Use these questions in order:
- Must an operator act on the equipment or process now to avoid a defined consequence? If yes, it is an alarm candidate.
- Is the signal merely a status for an automatic protection function that requires no operator action?
- Does it create a maintenance job or management decision? If yes, it is likely a non-alarm workflow.
- Could it affect safety, environment, quality, equipment or delivery, and over what time horizon?
- If one cause creates many signals, which one represents the cause and how will consequent events be grouped?
- Is the state normal during startup, shutdown, cleaning, changeover or maintenance mode?
The ISA public overview says ISA-TR18.2.3-2024 addresses meaningful, prioritized and actionable alarm design, HMI presentation, dynamic alarming and shelving. The objective is not an arbitrary reduction in message count. It is to prevent irrelevant alarms in a given operating state and to govern suppression or shelving with a reason, owner, expiry and return condition. A quiet system with indefinitely suppressed events may have lost monitoring capability.
Route by role, shift and skill—not a person’s name
Thailand factories often combine day and night shifts, employees and contractors, Thai operators and Japanese managers, and remote support from equipment suppliers. A rule tied to one individual or one group chat will break during leave or reassignment. Routing should combine the following conditions.
| Condition | Design example | Required fallback |
|---|---|---|
| Function | Maintenance, production, quality, warehouse, IT/OT | Delegate function when the roster is empty |
| Shift | A/B/C, day, night, holiday | Transfer open work during handover |
| Skill | PLC, robot, mechanical, electrical, refrigeration | Secondary specialist and vendor contact |
| Area | Site, building, line, restricted area | Person authorized to enter |
| Language | Thai, English, Japanese | Common event code with bilingual text |
| Urgency | Immediate, short-term, next shift, report | Phone, annunciator or email fallback |
| Device state | Online, unreachable, refused, low battery | Server-side delivery-failure detection |
When extending an andon call to a mobile phone, do not assign the same priority to line assistance and an equipment alarm. Material replenishment, quality support and supervisor calls belong in a work queue with accepted, started, arrived, completed and cancelled states. For a dedicated logistics workflow, see our forklift call and dispatch system guide.
Separate ACK, escalation, return-to-normal and closure
ACK does not mean “fixed.” At minimum, distinguish message seen, work accepted, technician arrived, equipment returned to normal, monitoring confirmed, and cause/action documented. If one person’s read receipt stops delivery to everyone, the work can remain unowned.
A practical state sequence is:
Raised → Notifying → Accepted → In progress → Equipment returned → Monitored → Closed
Branches may include false notification, duplicate merge, on hold, waiting for vendor, waiting for parts, recurrence and cancellation. For every transition, define the permitted role, required fields, timer and recipients. Automatically closing a work item when an equipment signal returns to normal hides intermittent recovery, missing root cause and repeated faults. Conversely, displaying the machine as stopped until a person closes paperwork is also inaccurate. Keep equipment state and workflow state in separate fields.
Escalation times must be based on time-to-consequence, travel time and roster capacity—not copied from a generic benchmark. A plant might set an illustrative rule of acceptance within two minutes, arrival within five and supervisor escalation after ten for its highest class. These are recommended examples, not an industry average. The PoC should measure actual distributions by machine and shift and replace them with approved values.
Acceptance conditions for phones and smartwatches
When comparing a smartphone andon notification or smartwatch equipment alert, do not approve the solution after a push-notification demonstration. FAT and SAT should verify that:
- lock screens do not reveal excessive confidential or personal data;
- messages include site, equipment, event, priority, source time, required action and ACK link;
- Thai combining marks, long equipment names, Japanese and English display correctly;
- the plant has decided whether watch-only acknowledgement is allowed and how accidental taps are prevented;
- operating-system grouping does not hide the highest-priority event;
- old notifications are distinguished from current state after a device returns from a dead zone;
- device loss, revocation, MDM, screen lock, application update and logout are manageable;
- shared devices can identify the active user and be handed over by shift where BYOD is prohibited;
- SMS, voice call or local indication can take over during a push-service outage.
“API accepted” is not the same as “shown to a user.” Record separate times for send request, external service acceptance, device delivery, user display and ACK. The support contract should state which point the supplier monitors and guarantees.
Design real-time factory notification for power and communications loss
A real-time factory notification requirement must not assume a permanent connection. A Thailand site can experience a local outage, voltage dip, carrier failover, Wi-Fi roaming, weak mobile coverage, cloud incident or planned network isolation. Local control that protects the process must remain independent from the notification service that distributes and analyzes events.
OPC UA Part 9 v1.05.06 publicly describes a Refresh mechanism for synchronizing current Conditions. This addresses active states that existed before a client subscribed and would otherwise remain unseen until a new transition occurred. It also models communications quality. An implementation should require that:
- PLC and control equipment continue control and protection when cloud or notification servers are unavailable.
- An edge gateway buffers uniquely identified events locally and replays them with original source time and order.
- The server receives idempotently, avoiding duplicate notification and counting.
- A reconnecting client refreshes the current active state.
- Equipment abnormality and communications-quality failure are separate; unknown data is never shown as normal.
- Recovery limits a flood while preserving unresolved, important conditions.
- Tests cover UPS duration, buffer capacity, replay throughput and clock synchronization limits.
Combining this boundary with our SCADA system selection RFP guide helps prevent a mobile notification layer from being mistaken for SCADA or local control.
Put OT security into the RFP
Because an alarm notification platform reads from PLC or SCADA and connects to cloud and mobile services, it crosses IT/OT boundaries. NIST SP 800-82 Rev. 3, published in September 2023, gives guidance on securing OT while addressing its performance, reliability and safety requirements. The January 2025 Secure by Demand guide from CISA and partners urges asset owners to include security in procurement and highlights issues such as weak authentication, known vulnerabilities, limited logging, insecure defaults and legacy protocols.
Include at least these requirements:
| Area | Requirement | Acceptance evidence |
|---|---|---|
| Architecture | Minimize permitted OT-to-upstream traffic; separately approve any write path | Data flow, firewall rules and port list |
| Identity | Named accounts, MFA, role-based rights and service-account control | Role matrix, disabling test and audit log |
| Cryptography | Protect data in transit, renew certificates and safeguard secrets | Configuration, expiry behavior and renewal procedure |
| Logging | Record login, configuration, ACK, suppression and rule changes | Time sync, tamper resistance and SIEM export |
| Vulnerability | SBOM, notification process, patch policy and support end date | Contract, contact path and update demonstration |
| Remote support | Avoid permanent access; require approval, time limit and recording | Session record or complete operation log |
| Recovery | Back up and restore configuration, rules and history | Agreed RTO/RPO and restoration test |
| Ownership | Control data sharing, termination return and standard export | Export demonstration and exit procedure |
Do not make “cloud” a blanket accept/reject decision. Classify information and processing by notification type. Control and safety decisions can stay local while a cloud service performs distribution or analysis. Also verify that the plant can change rosters and rules, retrieve logs and restore backups if the vendor is unavailable.
Essential RFP sections for a Thailand plant
The RFP should request evidence against factory scenarios, not only yes/no answers on a feature sheet.
1. Scope and ownership boundary
- State sites, lines, machines, event points, users, shifts and languages.
- Diagram responsibility boundaries for PLC/DCS/SCADA, gateway, server, mobile, MDM and networks.
- Define alarm, non-alarm notification, safety function, equipment protection and work order separately.
- Provide a RACI for production support, initial response, advanced diagnosis, site visit and manufacturer escalation.
2. Data and interfaces
- Describe OPC UA, MQTT, API, database or contact interfaces, read/write direction and update rate.
- Define IDs, time, quality, state transitions, replay, reversed order and deduplication.
- Require version control, approval, bulk upload and export for equipment and event masters.
- Measure the load on legacy PLC scans and OT networks.
3. Notification workflow
- Configure priority, routing, ACK, retry, delegation, escalation, return and closure.
- Provide a fallback if roster or HR/shift synchronization fails.
- Govern grouping, cause/consequence, suppression, shelving and maintenance mode during event bursts.
- Record false notification, cancellation, recurrence, shift handover and waiting status.
4. Thailand-site operations
- Provide Thai, English and Japanese UI, event dictionary, training and support contacts.
- Test UTC storage, ICT display, shift crossover, Thailand holidays and holiday rosters.
- Consider radio survey, hazardous-area devices, no-camera zones and shared terminals.
- Contract local service hours, night escalation, spares, site response and overseas manufacturer support.
5. Non-functional, security and exit requirements
- Define detection-to-delivery latency, peak event rate, retention and search time as well as availability.
- Cover patching, certificates, backups, disaster recovery, logs, vulnerabilities and end of support.
- Compare five-year TCO including licenses, devices, communications, operation, maintenance, changes and training.
- Require data return, configuration handover, account deletion and connection removal at exit.
A 30-day PoC plan—recommended example values
A 30-day PoC is meant to eliminate the riskiest assumptions using real data, not build the complete production system. The following is an illustrative recommendation and should be adapted to loss exposure, shifts, equipment and change approval.
| Period | Main work | Example exit condition |
|---|---|---|
| Days 1–5 | Observe work, inventory events, classify alarms and non-alarms | Owners, actions and priority agreed for 20 representative events |
| Days 6–10 | Connect one line, normalize, verify time, quality and replay | Event identity and original source time can be reproduced |
| Days 11–15 | Route by shift and skill; localize in three languages | Day, night and holiday tests pass |
| Days 16–20 | Configure ACK, escalation, return and history | State sequence and audit evidence are traceable |
| Days 21–25 | Test power loss, disconnect, burst and device loss | No safety impact and no missing or duplicate event after recovery |
| Days 26–30 | User evaluation, KPI, TCO and decision | Gaps, modification price, rollout plan and Go/No-Go approved |
One line, 20 representative events and 15 users are also recommended examples. Include frequent events, compound failures, bad communications quality, shift handover and an older PLC—not only easy normal cases. Verify that special PoC settings do not hide production pricing or security limitations.
FAT and SAT acceptance scenarios
FAT tests logic and load in a supplier environment. SAT tests real machines, networks, devices and shifts at the factory. “A message arrived” is not enough.
| ID | Scenario | Passing evidence |
|---|---|---|
| T01 | Replay the same event three times | One case is created; retries remain in history only |
| T02 | Return event arrives before active event | Source-time and ordering rules converge to correct state |
| T03 | Night-shift electrical technician is absent | Delegate receives it and supervisor escalation occurs on expiry |
| T04 | Event starts and returns while device is offline | Old messages and current state are explicit after reconnect |
| T05 | Large event burst in one minute | Grouping works without hiding an important condition |
| T06 | Notification server stops | PLC, SCADA and safety remain unaffected; fallback works |
| T07 | Components restart in reverse order after outage | State refresh completes without missing or duplicate messages |
| T08 | Fault recurs after ACK | New occurrence is visible and not buried in the old case |
| T09 | Threshold and routing rule are changed | Approval, version, old/new values and user are audited |
| T10 | Long Thai text is shown on a watch | Characters render and equipment, action and priority are understood |
| T11 | Vendor performs remote support | MFA, approval, time limit, recording and disconnect are verified |
| T12 | Contract exit is simulated | Configuration, history and attachments export in a usable format |
An illustrative latency criterion might be “95th percentile within five seconds from event source to notification-service acceptance.” This remains a recommended example. Define measurement points, time sync, population, peak load and whether external push delivery is included.
KPIs for sustainable alarm management
Do not treat the number of messages sent as value. Separate detection, delivery, human response, recovery, recurrence and data quality.
| KPI | Example definition | Control |
|---|---|---|
| Detection delay | Source time to normalized intake | Monitor clock error separately |
| Delivery delay | Normalized intake to channel acceptance | Keep separate from device display |
| ACK time | Case generation to work acceptance | Exclude automatic ACK and bulk read |
| Arrival time | Acceptance to confirmed site arrival | Standardize QR/NFC or other evidence |
| Recovery time | Active start to equipment return | Analyze waiting categories separately |
| Closure time | Return to approved cause/action | Remove slow paperwork that adds no value |
| Escalation rate | Expired cases divided by eligible cases | Check whether thresholds are realistic |
| Recurrence | Same fault within an approved period | Audit code quality and corrective action |
| Notification quality | False, duplicate, unknown recipient or unclear translation | Capture shop-floor feedback |
The ISA public overview of ISA-TR18.2.5-2022 describes ongoing monitoring, assessment and auditing using measures such as alarm rates, standing alarms and operator response time. Targets should come from the plant’s alarm philosophy and baseline, not a generic number. When moving from notification to prediction, our predictive maintenance case-study guide explains why a predictive score and an actual maintenance decision must remain distinguishable.
Common failures and remedies
Forwarding everything to chat
A single chat has no dependable roster, skill assignment, ACK ownership or audit. Keep event code, role routing and workflow state in the platform; treat chat as only one presentation channel.
Calling every message an alarm
If replenishment requests and daily notices make the same sound as equipment conditions, the operator’s required action is buried. Classify alarms and non-alarm notifications and assign separate owners and KPIs.
Closing automatically on a return signal
Temporary self-recovery can close the case without cause or action. Separate the equipment’s Returned state from the work item’s Closed state.
Treating mobile notification as a safety function
A device dependent on communications and battery does not replace SIS, interlocks or emergency stops. Perform risk reduction in control and safety design and use mobile only as a supplementary channel.
Testing only the happy path
The real risk appears during outage, disconnection, shift change, message flood and device loss. Make these mandatory PoC and SAT scenarios.
FAQ: equipment alarm notification systems
What is the best way to send factory alert notifications?
Use several methods according to urgency and recipient. Keep operator alarms on HMI and local visual/audible channels. Use phones, smartwatches, voice calls and email for maintenance or management workflows, with delivery-failure detection and a defined fallback.
Can smartwatch equipment alerts count as a safety measure?
Not by themselves. They can quickly contact an on-call technician but cannot replace SIS, machinery interlocks or emergency stops. Evaluate battery, coverage, wear compliance and accidental input, then use the watch as a secondary channel.
What matters when adding smartphone notifications to an andon?
Do not give assistance calls, machine faults, quality events and logistics requests the same priority. Track acceptance, start, arrival and completion, and retain local and manual paths.
How many seconds should a real-time factory notification take?
There is no universal answer. Work backward from the time in which a person can avoid the consequence. Define measurement points, percentile, peak load and time synchronization. Any seconds in this guide are examples, not industry statistics.
What should an alarm-management project establish first?
Establish the alarm philosophy, event dictionary, priority rationale, required action, owner and state transitions. Rationalizing representative events before tool deployment prevents the migration of nuisance messages.
Can the system work with an old PLC?
Sometimes. Compare discrete contacts, existing SCADA, an OPC server and an edge gateway. Document limitations in communication load, source time, quality and replay, then agree what the upstream system can and cannot compensate for.
Besides price, what differentiates vendors?
Compare the event model, abnormal-scenario recovery, access and audit, data portability, local Thailand support, end-of-support policy and five-year TCO. Ask each bidder to demonstrate the same factory scenario.
Conclusion: move from “delivered” to “closed”
The value of an equipment alarm notification system is not message volume or app appearance. It is whether the right person acts within an agreed time, the equipment returns, and cause and corrective action remain auditable. Separate alarms from non-alarm workflows and design the full path from source, normalization and priority through routing, ACK, escalation, recovery, closure and history. Phones and smartwatches can be effective supporting channels, but they are not substitutes for local control, safety instrumentation or interlocks.
TOMAS TECH can support an inventory of existing PLC/SCADA signals, notification classification, RFP development, a 30-day PoC and FAT/SAT design. You are welcome to contact us even if you are still defining responsibilities and acceptance conditions before selecting a product.
Primary references
- ISA, ISA-18 Series of Standards (public summaries of ISA-TR18.2.3-2024, ISA-TR18.2.5-2022 and ISA-TR18.2.8-2023)
- IEC, IEC 62682:2022 — Management of alarm systems for the process industries
- OPC Foundation, OPC UA Part 9: Alarms & Conditions v1.05.06 — Scope
- OPC Foundation, OPC UA Part 9: Alarms & Conditions v1.05.06 — Concepts
- NIST, SP 800-82 Rev. 3, Guide to Operational Technology Security (September 2023)
- CISA and partners, Secure by Demand: Priority Considerations for OT Owners and Operators (January 2025)
