AI in the Ammonia Refrigeration Control System: Four Places It Earns Its Keep

Every ammonia refrigeration facility already has more data than anyone looks at. The PLC scans every pressure, temperature, level, and motor status several times a second. The historian, if there is one, has been quietly storing that data for years. The PLC program itself is a complete, executable description of how the plant is supposed to behave, including every interlock and permissive that keeps it safe. The PSM binder on the shelf describes what the plant is supposed to be.

The problem has never been a shortage of information. The problem is that all of it is locked behind tools that require a specialist: a historian query language, a PLC programming environment, a P&ID set that only the refrigeration contractor can read fluently, and a compliance program that lives in the head of one person who has been at the plant for twenty years.

This is the gap AI closes in an ammonia control system. Not by taking control of anything, but by making the information the plant already has answerable. This post covers four places where that pays off: the historian, the PLC program, the system as a whole, and the compliance record. It also covers the boundaries that have to hold for any of it to belong in a machinery room.

Start With What AI Should Not Do

Before the value, the limits. An ammonia refrigeration system is a covered process under OSHA PSM, and the PLC is the safety-relevant control layer. Nothing described in this post writes to the PLC, changes a setpoint, or takes a control action. The AI layer reads. It reads the historian, it reads exported program files, it reads the documentation, and it answers questions.

That read-only boundary is the same one NH3Edge has always held for its edge computer, which connects to the PLC data table over EtherNet/IP or Modbus without any ability to command the control system. AI does not change that architecture. It sits on top of it.

The second limit is grounding. An AI assistant in this setting is only useful if every answer can be traced to a specific tag, time range, program rung, or document. A confident answer with no source is worse than no answer, because someone will act on it. The examples below all assume the answer comes with its evidence attached.

1. An Interface to the Historian

A process historian is the single most underused asset at most ammonia facilities. The data is there. Getting it out requires knowing tag names, building a trend, picking the right time window, and exporting to a spreadsheet to do any real analysis. So in practice, the historian gets opened after an incident and rarely otherwise.

AI changes the interface, not the data. Instead of building a query, the refrigeration lead asks:

• "What was the high-pressure receiver level and discharge pressure in the ten minutes before the high discharge alarm on Tuesday night?"
• "How many times did compressor 3 start in the last 30 days, and how long did each run last?"
• "Show me every time suction pressure on the low-temp system rose above 5 psig for more than five minutes this summer."
• "Did the condenser fans on cell 2 run at all during the 2:00 AM to 4:00 AM window last night?"

Under the hood, the AI translates the question into the actual historian query, runs it against the real data, and presents the result with the tags and time range it used. The number is not generated by the model. It is retrieved from the historian. The model's job is translation and explanation.

This matters for ammonia specifically because the questions that matter are almost always about relationships across time. A rising receiver level plus falling low-pressure receiver level plus increasing condensing pressure is a signature, and it tells a story about where the charge is going. Continuous inventory monitoring already produces that signature every scan cycle. Being able to ask "when did the inventory distribution last look like this, and what was happening?" turns years of stored data into an operating memory the plant can actually consult.

The practical payoff is troubleshooting speed. A nuisance trip that takes an afternoon to investigate with trend screens takes a few questions. And the person asking does not have to be the one person who knows the historian.

2. Asking the PLC Program What It Does

This is the capability most operators do not know is possible, and it is the one with the largest safety value.

The PLC program is the ground truth for how the plant behaves. It is also, at most facilities, a document nobody at the plant can read. It was written by a contractor, modified by a second contractor, patched during a compressor replacement, and never fully documented. The interlock that trips the king valve on a low-level condition is in there somewhere, along with every permissive that has to be true before a compressor will start.

Modern PLC programs export to structured text formats. Allen-Bradley Logix projects export to L5X. Siemens TIA Portal projects export their blocks. An AI that has read the exported program can answer questions like:

• "What conditions cause the king solenoid to close?"
• "What has to be true before compressor 2 is allowed to start?"
• "Where is the tag HPR_LEVEL_HI written, and what uses it?"
• "Is there any path where the engine room ammonia detector alarm does not trigger the exhaust fans?"
• "What changed between the program backup from March and the one from July?"

That last question deserves attention. Management of Change under 29 CFR 1910.119(l) applies to changes in process technology and equipment, and control logic is process technology. Most facilities have no practical way to know whether the program running today matches the one that was in place when the last PHA was done. Comparing two exported program files and explaining the functional differences in plain language is a task AI does well, and it is a task that almost never gets done manually.

The safety connection is direct. Process Safety Information under 1910.119(d)(3) requires documentation of safety systems, including interlocks, detection, and suppression. The PLC program is the actual implementation of those interlocks. Being able to interrogate it, rather than trusting a narrative description written years ago, closes a real gap between the PSI binder and the plant.

The boundary here is the same as everywhere else: the AI reads exported program files. It does not go online with the processor and it does not edit logic. A question about the program is answered from a file, with the routine and rung cited, and a human verifies it in the programming software before anyone acts on it.

3. Understanding the System as a Whole

The historian tells you what happened. The program tells you what the logic will do. The P&ID tells you how the equipment is connected. Operating procedures tell you what the operators are supposed to do. At most plants, no single person holds all four in their head, and the person closest to it is the one whose retirement everyone is quietly worried about.

An AI assistant with access to all four sources can answer questions about function rather than just data:

• "Walk me through what happens during a hot gas defrost on the spiral freezer evaporators, from the first output to the return to normal."
• "Why does suction pressure on the intermediate system rise every night around 3:00 AM?"
• "If the low-pressure receiver level transmitter fails high, what does the control system do, and what does the operator see?"
• "Which vessels are protected by which relief valves, and where do they discharge?"

The first example is training. New operators learn the plant faster when they can ask it questions. The second is analysis, and the answer probably lives in a combination of the defrost schedule in the program and the historian trend. The third is a what-if scenario, which is exactly the kind of question a PHA team works through, and having it answerable from the actual logic rather than from memory makes the PHA better. The fourth is Process Safety Information, and it is the kind of question an OSHA inspector asks.

There is a second, quieter benefit. Operating procedures under 1910.119(f) are supposed to describe normal operation, startup, shutdown, and emergency operation. At many plants the written procedure and the actual sequence in the PLC have drifted apart. Asking the AI to compare the written startup procedure with the startup sequence in the program surfaces those discrepancies. Each one is either a procedure that needs updating or a program change that never went through MOC. Either way, it is a finding you would rather make yourself than have an inspector make.

4. Compliance

Everything above feeds compliance, but there is a specific set of PSM obligations where the value is concrete because they are evidence problems, not engineering problems.

Mechanical integrity records. Element 8 under 1910.119(j) requires documented inspection and testing of process equipment, and IIAR Bulletin 110 and IIAR 6 define what that looks like for ammonia systems. Safety system tests, low-level cutout tests, and high-pressure cutout tests all leave a signature in the historian. An AI that can answer "show me the last time the low-level cutout on the LPR actually tripped, and confirm the compressors stopped" is producing MI evidence from data that already exists.

Compliance audits. Element 13 under 1910.119(o) requires a compliance audit at least every three years. Audit preparation is largely a document assembly exercise: pull the records that show each element is implemented. Asking for "every alarm event on the ammonia detectors in the last three years, with the response time to acknowledgment" or "every oil drain event logged since the last audit" is a query the AI can run and cite. The auditor still evaluates the evidence. The AI just finds it.

Incident investigation. Element 11 under 1910.119(m) requires investigation of incidents that resulted in or could reasonably have resulted in a catastrophic release. The first hour of any investigation is reconstructing the sequence of events. A historian query in plain language, cross-referenced with the program logic that explains why the system responded as it did, compresses that hour considerably and produces a timeline with sources.

PHA revalidation. The five-year revalidation under 1910.119(e)(6) is supposed to account for changes since the last PHA. Program diffs, alarm frequency changes, and operating envelope drift over five years are all things the historian and program exports can show. That makes the revalidation about actual plant history rather than the team's recollection of it.

Two cautions belong here. First, the AI does not determine compliance. A person with the authority and the qualifications makes that call and signs it. The AI assembles evidence and explains it. Second, the AI's own answers should be logged. If a question about interlock behavior informed a PHA decision, the question, the answer, and the sources it cited should be part of the record. That audit trail is what makes the tool defensible.

What This Requires From the Architecture

None of this works without three things already in place.

A historian that actually captures the data. The AI can only query what was stored. Facilities that log a handful of tags at one-minute intervals will get thin answers. Continuous, scan-rate logging of all process points is the foundation, and it is what the NH3Edge edge computer is built to do, with local buffering so the record has no gaps during connectivity loss.

Exported program files kept current. A program backup from commissioning is not enough. Every change should produce a new export, tied to its MOC record, so the AI is reading the program that is actually running.

A read-only path, with the data staying where it belongs. Process data and control logic are sensitive. They should stay in the facility's own tenant, the AI layer should have no write path to the OT network, and the ISA/IEC 62443 zone boundary between the control network and everything else should hold exactly as it did before AI was involved.

Where This Is Headed

The honest summary is that AI does not give an ammonia refrigeration facility any information it did not already have. What it gives is access. The historian becomes something an operator can talk to. The PLC program becomes something the PSM coordinator can ask questions of. The system's behavior becomes something a new operator can learn by asking. And the compliance record becomes something that can be assembled from evidence rather than reconstructed from memory.

For facilities near or above the 10,000-pound threshold, that access is not a convenience. It is the difference between a PSM program that describes the plant and one that can prove it.

---

Interested in what AI-assisted monitoring and compliance could look like for your ammonia facility? Contact NH3Edge or request a demo.