The Inspector Asks a Question You Cannot Answer

A state dairy inspector is standing in your processing room, clipboard in hand, watching the HTST pasteurizer run. The divert valve just actuated — product temperature dropped below 161.5 degrees F and the flow diverted back to the raw side. The system is working correctly.

The inspector turns to you and asks: "Can you show me the logic that controls the divert valve? What is the temperature setpoint? What is the time delay? How does the system handle a sensor failure?"

You look at the CompactLogix sitting in the panel. The PanelView is displaying the pasteurizer status screen. The program is running flawlessly — it has been running flawlessly for seven years. But the integrator who programmed it sold his company and moved to Florida. You have the L5X backup file on a USB drive somewhere, but nobody on your maintenance staff programs in Studio 5000.

You cannot answer the inspector's question.

This is not a hypothetical scenario. This happens at dairy plants, juice processors, and food manufacturing facilities across the country every time an inspector decides to look past the process and into the controls. And under FSMA, it is happening more often.

FSMA Changed the Documentation Game

The Food Safety Modernization Act (FSMA) shifted FDA's approach from reactive (responding to contamination events) to preventive (requiring documented controls that prevent contamination in the first place). The Preventive Controls for Human Food rule (21 CFR Part 117) requires food facilities to:

1. Conduct a hazard analysis
2. Implement preventive controls for identified hazards
3. Monitor those preventive controls
4. Document that monitoring is occurring and the controls are working

For a dairy plant running an HTST pasteurizer, the preventive control for pathogen destruction is thermal processing — specifically, the time-temperature relationship defined by the Pasteurized Milk Ordinance (PMO). The monitoring is the continuous temperature recording at the holding tube outlet. The documentation is... well, that is where it gets complicated.

The PMO requires a "recording thermometer" — a continuous chart recorder or electronic equivalent — that documents the temperature at the holding tube outlet throughout every processing run. Most modern HTST systems use an electronic recorder (an Anderson AJ-300, a Partlow Versa, or similar) that satisfies this requirement.

But the recording thermometer only tells you the temperature. It does not tell you what happens when the temperature drops below the legal minimum. That logic — the divert valve control, the timing pump interlock, the sensor failure response — lives in the PLC.

Under FSMA, your hazard analysis must identify what happens if a preventive control fails. If the pasteurizer temperature drops below 161 degrees F (for milk at 15 seconds), the system must divert. But how does it divert? What is the exact temperature comparison? Is there a time delay? What happens if the temperature sensor fails open (reads zero)? What happens if it fails high (reads full scale)?

The answers to all of these questions are in the ladder logic. And if you cannot produce that documentation on demand, you have a compliance gap.

The PMO Timing Law and How PLC Logic Implements It

The Pasteurized Milk Ordinance specifies minimum time-temperature combinations for pasteurization. For HTST processing of milk:

Temperature	Minimum Time
161 degrees F (72 degrees C)	15 seconds
191 degrees F (89 degrees C)	1.0 second
204 degrees F (96 degrees C)	0.05 seconds
212 degrees F (100 degrees C)	0.01 seconds

The standard HTST pasteurizer ensures compliance through three mechanisms:

1. Holding tube sizing: The holding tube is physically sized so that at maximum flow rate, the minimum residence time exceeds 15 seconds at 161 degrees F. This is a mechanical control — it does not depend on the PLC.

2. Flow control: A timing pump (positive displacement pump or magnetic flow meter with flow control valve) limits the maximum flow rate through the holding tube. The PLC typically monitors flow rate and alarms or diverts if flow exceeds the design maximum.

3. Divert valve: The flow diversion device (FDD) at the holding tube outlet diverts product back to the raw side when the temperature is below the legal minimum. The divert valve is the critical safety device — and its control logic is in the PLC.

In a properly designed HTST system, the divert valve control logic looks something like this in ladder:

RUNG: Temperature Check
  GRT  Holding_Tube_Temp  161.5  — Greater Than comparison
  OTE  Temp_Above_Setpoint       — Bit indicating temp is OK

RUNG: Divert Valve Control
  XIC  Temp_Above_Setpoint       — Temp must be above setpoint
  XIC  Flow_Within_Limits        — Flow must be within design limits
  XIC  System_In_Run             — System must be in pasteurize mode
  XIC  No_Sensor_Fault           — Temperature sensor must be healthy
  OTE  FDD_Forward_Flow          — Energize = forward flow (pasteurized)

The divert valve is typically a fail-safe design: de-energized = divert (raw side), energized = forward flow (pasteurized side). This means any failure — power loss, PLC fault, sensor failure, communication loss — results in diversion. The ladder logic must actively keep the valve in forward flow.

The 161.5 degree F setpoint (not 161.0) provides a 0.5 degree safety margin. This margin is typically set by the integrator during commissioning and documented in the original commissioning records — if those records exist.

CIP Sequences: Where Documentation and Reality Diverge

Every food processing facility has written Standard Operating Procedures (SOPs) for CIP cleaning. These SOPs specify wash steps, chemical concentrations, temperatures, flow rates, and contact times. The SOPs were probably written when the CIP system was installed, reviewed by a food safety consultant, and filed in a binder.

The problem is that the CIP PLC program has been modified since those SOPs were written. Somebody changed the caustic wash time from 20 minutes to 15 minutes because production needed the line back sooner. Somebody adjusted the rinse temperature because the hot water system could not keep up. Somebody added a step that the SOP does not mention.

The result: the SOP says one thing and the PLC does another. When an auditor reviews your CIP documentation, they are reading the SOP. When the CIP system actually runs, it is executing whatever is in the MicroLogix. If those do not match, you have a compliance gap — and you probably do not know about it because nobody has looked at the MicroLogix program in years.

A typical CIP sequence in ladder logic is implemented as a sequencer — a series of steps driven by a counter or a state machine integer. Each step has:

• Chemical valve states: Which valves are open (caustic supply, acid supply, rinse water)
• Temperature setpoint: Required solution temperature for the step
• Flow rate requirement: Minimum flow rate to ensure coverage
• Timer preset: How long the step runs
• Advance conditions: What must be true to move to the next step (temperature reached, conductivity confirmed, timer done)

Documenting this sequence from the ladder logic gives you the actual CIP procedure — not what the SOP says, but what the PLC actually does. Comparing the two frequently reveals discrepancies that have been silently accumulating for years.

Common discrepancies we see:

• Wash times shortened: Production pressure leads to shorter wash cycles. The SOP says 20-minute caustic wash; the PLC timer preset is 900 seconds (15 minutes).
• Temperature compromises: The SOP specifies 180 degrees F caustic wash; the PLC comparison is 170 degrees F because the boiler cannot maintain 180 degrees F during peak production.
• Missing steps: A pre-rinse step was added to the PLC to clear product residue before caustic, but the SOP has no pre-rinse step documented.
• Concentration verification: The SOP requires conductivity verification of chemical concentration; the PLC sequence advances on timer alone regardless of conductivity.

Each of these discrepancies is a potential finding during a food safety audit. And the fix is not changing the PLC — it is updating the SOPs to match what the PLC actually does (assuming the actual procedure is adequate), or changing the PLC to match the SOPs (if the actual procedure is inadequate).

Either way, you need the PLC documentation first.

The Integrator Knowledge Gap

The food processing industry has a structural problem: the controls knowledge for most facilities lives inside the head of one integrator.

A typical small dairy plant has one CompactLogix running the pasteurizer, one MicroLogix running the CIP, and maybe a PanelView or two for operator interface. These systems were installed by a local integrator — a one-person or three-person shop — who programmed the PLCs, built the panels, and commissioned the system.

That integrator knows the system intimately because they built it. They know why the divert valve delay is 0.8 seconds instead of 1.0 seconds (the valve actuator is fast). They know why the CIP rinse temperature is 170 degrees F instead of 180 degrees F (the boiler is undersized). They know which analog input channel reads which temperature transmitter and what the scaling is.

When that integrator retires, sells their business, or simply stops returning phone calls, that knowledge evaporates. The PLC programs are still running, but nobody can explain what they do or why they do it that way.

This is not unique to food processing — it happens across all industries with PLC-controlled equipment. But in food processing, the stakes are higher because regulatory compliance depends on understanding the control logic. An oil refinery with undocumented PLC programs has an operational risk. A dairy plant with undocumented PLC programs has a regulatory risk.

Building the Documentation Package

What a state inspector or FDA auditor actually wants to see for an HTST pasteurizer:

1. Process flow diagram showing the pasteurizer, holding tube, divert valve, and control points
2. I/O list mapping every sensor and actuator to its PLC address
3. Control narrative describing the pasteurization sequence in plain English
4. Divert logic documentation showing the exact conditions that cause diversion
5. Alarm list with setpoints and responses
6. CIP sequence documentation showing actual wash steps, times, temperatures, and chemicals
7. Sensor failure response documenting what happens when each sensor fails

Items 2-7 can be generated directly from the PLC program. The ladder logic contains all of this information — it just needs to be extracted, organized, and presented in a format that a non-programmer (an inspector, an auditor, a plant manager) can understand.

This is exactly the workflow that PLC forensics tools automate. Upload the L5X or RSS file, and the tool:

1. Parses every routine and rung in the program
2. Identifies the divert valve output and traces back every condition that affects it
3. Extracts temperature comparison values (your divert setpoint)
4. Identifies timer presets that affect hold time or delay
5. Maps every analog input to its tag description
6. Documents the CIP sequence step by step
7. Flags safety-critical rungs for review

The output is a documentation package that answers the inspector's questions before they are asked.

Sensor Failure Modes: The Question Nobody Asks Until It Matters

The most important safety logic in an HTST pasteurizer is not the normal operating sequence. It is the failure response.

What happens when the holding tube temperature sensor fails? There are three failure modes:

1. Fail low (reads zero or minimum scale): The PLC sees a temperature far below the divert setpoint and diverts. This is the safe failure mode — product goes back to the raw side. No food safety risk. Production stops.

2. Fail high (reads maximum scale): The PLC sees a temperature above the divert setpoint and continues forward flow. This is the dangerous failure mode — unpasteurized product could pass through the system. The PLC must detect this condition (rate of change check, comparison to backup sensor, or reasonableness check) and divert.

3. Fail in place (reads last known value): Some sensor failures cause the transmitter to hold its last output. The PLC sees a valid-looking temperature that is no longer updating. This is the most insidious failure mode because it looks normal.

A properly programmed HTST system has logic to detect all three failure modes. An improperly programmed one — or one where the failure detection was "going to be added later" and never was — may only catch failure mode 1.

The only way to know which failure modes your system handles is to read the ladder logic.

Practical Steps for Food Processors

If you are a food processing facility with PLC-controlled pasteurization or CIP systems, here is what to do today:

Step 1: Get a backup of every PLC program. If you do not have current backups, this is your top priority. Connect to each PLC and save the program file. For CompactLogix, this is an .ACD file that you export as .L5X. For MicroLogix, this is an .RSS file. For SLC-500, this is also .RSS.

Step 2: Document what you have. Upload each program file to a PLC analysis tool and generate the I/O map, alarm list, and control narrative. Compare the CIP sequence documentation to your written SOPs.

Step 3: Fix the discrepancies. If the PLC does not match the SOPs, either update the SOPs (if the PLC procedure is adequate) or update the PLC (if it is not). Document the changes.

Step 4: Establish a change management process. Going forward, any change to PLC logic must be documented. Save a new backup, update the documentation, and update the SOPs. This is a FSMA requirement under the Corrective Actions and Corrections provision.

Step 5: Test your failure responses. With the documentation in hand, verify that the PLC correctly handles sensor failures, power interruptions, and communication losses. If it does not, fix it and document the fix.

These five steps cost a fraction of what a full SCADA replacement costs, and they close the compliance gap that most food processors do not know they have.

Get Started

Upload your pasteurizer or CIP PLC program to Controls Foundry for free instant analysis. We will parse the ladder logic, extract the divert valve conditions, document the CIP sequence, and give you a compliance-ready documentation package.

No Studio 5000 license required. No integrator visit. Just upload the file and get answers.

Upload your PLC program to Controls Foundry