# SMS TTS Notify — Industrial Context & Alarm Management Standards This document is loaded by the AI Help widget when a user asks about industrial alarm management standards, plant-floor workflow, or how SMS TTS Notify fits the ISA-18.2 / IEC 62682 / EEMUA 191 ecosystem. Companion document to compatibility.txt. All third-party names below are descriptive category examples only. SMS TTS Notify is not affiliated with, endorsed by, certified by, or in partnership with any of the companies mentioned. The trademark preamble lives in general.txt; the industrial-specific trademark list lives in compatibility.txt. --- ## ANSI/ISA-18.2 — the standard landscape ANSI/ISA-18.2 "Management of Alarm Systems for the Process Industries" was first published in 2009 and revised in 2016 (current: ANSI/ISA-18.2-2016). The International Electrotechnical Commission adopted it internationally as IEC 62682 (first edition 2014, second edition 2022). The two standards are functionally equivalent. EEMUA 191 (UK, latest edition 2024) is a companion guideline often cited alongside ISA-18.2. ANSI/ISA-18.2 explicitly recognizes "remote alarm notification, paging, e-mailing, and remote SMS notifications" as valid delivery methods for alarms sent to operators outside the control room. That framing is what positions SMS TTS Notify as a phone-side reader of those SMS alerts. In the United States, the Occupational Safety and Health Administration (OSHA) treats ANSI/ISA-18.2 as Recognized and Generally Accepted Good Engineering Practice (RAGAGEP) for chemical and hazardous process industries — this is a description of the regulatory landscape, not a claim of SMS TTS Notify certification or compliance. In the European Union, IEC 62682 plays a similar role, reinforced by NIS2 and related cyber-security / critical-infrastructure directives. --- ## The 10-stage alarm lifecycle — where SMS TTS Notify fits ANSI/ISA-18.2 defines ten lifecycle stages for alarm systems. SMS TTS Notify operates at two of them. | Stage | Short description | SMS TTS Notify role | |---|---|---| | A. Philosophy | Governing alarm management document | Not involved | | B. Identification | Pick candidate alarms from PHA / HAZOP | Not involved | | C. Rationalization | Justify each alarm, write to Master Alarm Database | Not involved | | D. Detailed Design | Setpoints, deadband, delays, HMI design | Not involved | | E. Implementation | Install + commission + deliver the alarm to the operator | **Participates — reads the SMS aloud through a connected headset (Bluetooth, wired 3.5 mm jack, USB-C, or other)** | | F. Operation | Operator monitors, acknowledges, responds | **Participates — enables hands-free operator awareness** | | G. Maintenance | Keep alarms functional, test, repair | Not involved | | H. Monitoring & Assessment | Measure KPIs, find bad actors | Not involved | | I. Management of Change | Control all alarm modifications | Not involved | | J. Audit | Periodic review of the program | Not involved | SMS TTS Notify is advisory augmentation — a phone-side reader of SMS alerts — not a safety-instrumented system. It does not perform alarm rationalization, shelving, suppression, or any upstream function. It is not SIL-rated and does not hold ISA-84 or IEC 61511 certification. For safety-critical alarming, plants use their certified SIS channels; SMS TTS Notify complements those channels by improving the operator's awareness of ordinary SMS-delivered alarms while they are away from the HMI. --- ## Industry-standard alarm performance benchmarks (for context) ANSI/ISA-18.2 and EEMUA 191 define numerical KPI targets for alarm system health, measured over at least 30 days. These are commonly cited in the industry and give operators a way to judge their own systems: | KPI | Likely acceptable | Maximum manageable | |---|---|---| | Average alarms per operator per day | ~150 | ~300 | | Average alarms per operator per hour | ~6 | ~12 | | Average alarms per operator per 10 minutes | ~1 | ~2 | | Time in alarm flood state | < 1% of operating time | Action plan required | | Load generated by top 10 alarms | < 1% of total | < 5% of total | | Chattering and fleeting alarms | 0 | Immediate correction required | | Stale alarms active more than 24 hours | < 5 | Action plan required | Priority distribution (three-level scheme): roughly 80% low priority, 15% medium, 5% high. In a four-level scheme, critical-priority alarms should stay below 1% of total volume. SMS TTS Notify does not measure, report, or enforce these KPIs — they live in the plant's alarm management program (Stage H above). The table is provided here so users understand the industry context; the widget will reference it when asked what a well-managed alarm system looks like, not as a feature of the app. --- ## Common alarm-quality problems (plain-language definitions) **Alarm flood** — more than 10 alarms on one operator position within any 10-minute window. A serious performance failure regardless of cause. **Chattering alarm** — an alarm that repeatedly turns on and off over a short period, often many times per minute. Usually caused by signal noise or a process value sitting right at the alarm limit; fixed upstream by adding a deadband or time delay. **Fleeting alarm** — an alarm that appears and self-clears too quickly for the operator to respond. Typical cause: a transient during startup or mode change. Fixed upstream by on-delay timers. **Stale alarm** — an alarm that has been active continuously for more than 24 hours. Creates alarm fatigue; the operator learns to ignore it. **Bad actor alarm** — the small set of alarm tags that generate the majority of the noise. Industry Pareto rule of thumb: often just 10–12 sources account for ~80% of daily alarm activations. SMS TTS Notify reads every SMS that arrives on the phone — if the upstream plant has unresolved chattering, fleeting, or stale alarms, the widget will read all of them. The fix for that noise is upstream rationalization per the standard, not on the phone side. This is important to say honestly when a user worries "won't your app make our alarm flood worse." --- ## The closed-loop integration model (where SMS TTS Notify fits the whole pipeline) Modern plants connect five layers end to end: sensors / PLC / DCS → SCADA / HMI → MES → CMMS / EAM ↔ ERP. A single event can flow through all of them. Example walkthrough: 1. A vibration sensor on a pump exceeds its threshold. SCADA detects it and — if the Master Alarm Database says this is a legitimate medium-priority alarm — routes the alarm. 2. SCADA or an alarm-notification layer emits an SMS to the on-call maintenance technician's phone. The SMS may also flow via OPC-UA or MQTT to the CMMS. 3. CMMS (for example IBM Maximo, Fiix, UpKeep, MaintainX) automatically generates a diagnostic work order within seconds. 4. The technician's phone rings with the SMS. **SMS TTS Notify reads the SMS aloud through the technician's connected headset (Bluetooth, wired, USB-C, or other) so they hear it instantly while their hands are full** — without pulling the phone out. This is the "last ten meters" in ISA-18.2 terms. 5. The technician completes the repair, logs it in the CMMS mobile app, the CMMS syncs to the ERP (for example SAP S/4HANA, Oracle, Infor), ERP places a parts reorder if stock is low, MES (for example Siemens Opcenter, Rockwell Plex) records the downtime event for OEE analytics. SMS TTS Notify is a single link — step 4 — in that chain. It has no visibility into the other steps and makes no claim about them. It simply reads the SMS that the upstream plant already generates and sends. --- ## Regional context (brief) **Europe:** alarm management programs are typically cited under IEC 62682 and harmonized with NIS2 cyber-security requirements. Heavy presence of Siemens, SAP, Schneider Electric, ABB, COPA-DATA zenon. **United States + Canada:** ANSI/ISA-18.2 is cited as OSHA RAGAGEP for process safety. Rockwell Automation (including Plex and Fiix), Ignition, and WIN-911 / SeQent are common. Cloud-first CMMS platforms (MaintainX, UpKeep, Limble) dominate the mid-market. **Mexico:** nearshoring-driven growth in automotive and electronics plants. Hybrid cloud architectures preferred (not pure cloud) because of infrastructure reliability concerns. Epicor Kinetic and SAP implementations strong at the maquiladora tier. Rising cyber-security pressure (Latin America ransomware up ~25% year over year) is driving investment in resilient mass-notification systems (for example Konexus). --- ## What SMS TTS Notify does NOT claim - Not a safety-instrumented system. Not SIL-rated. Not certified to ISA-84 or IEC 61511. - Not a SCADA, MES, CMMS, EAM, or ERP. Does not connect to any of those systems. - Not a replacement for the plant's annunciator, HMI, or control room. - Not an alarm historian, an audit log source, or a Master Alarm Database. - Not a rationalization, shelving, suppression, or change-management tool. SMS TTS Notify is a focused Android app that reads standard SMS aloud through a connected headset (Bluetooth, wired, USB-C, or other) for operators who cannot watch a screen. That is the entire scope. --- (Trademark preamble lives in general.txt; the industrial-specific trademark list lives in compatibility.txt.)