Your Siemens PLC Passed Acceptance Testing. Here's Why It Still Failed in Production.

It Passed the Test. Then the Line Stopped.

Two months after a factory acceptance test, a packaging line went down. Siemens S7-1500, fully commissioned, all diagnostics green in TIA Portal. No fault codes. The process values just drifted—slowly, then all at once.

The customer's first assumption: defective hardware. They swapped the CPU. Then an I/O module. The drift didn't go away.

It wasn't a hardware problem. It was a verification problem. And the acceptance test—the one everyone signed—had checked almost nothing that mattered.

I'm a quality and brand compliance manager at an industrial automation integrator. I review every commissioning package before it goes to a customer—roughly 200+ packages annually. In 2024, I rejected 18% of first deliveries. Most of those rejections were not hardware failures. They were verification failures. The system worked on the day we tested it. It just didn't work the way we tested it.

What the Test Actually Checked

Most buyers focus on whether the PLC powers up and the diagnostics are green. They completely miss communication determinism, analog accuracy, and session behavior under load.

The question everyone asks is: "Does it power on?" The question they should ask is: "Does it hold timing when the network hiccups at 3 a.m. on a Sunday?"

Buyers treat the acceptance protocol like a spark plug cross-reference chart—match the model number, check the datasheet, sign the sheet. That works for spark plugs. It doesn't work for PLC systems.

Here's what the standard protocol misses—and what I now flag in every review.

The OPC UA Gap Nobody Validates

Every acceptance test I've reviewed checks that the OPC UA server is reachable. Browse the tags, confirm the endpoint, move on.

Reachable is not reliable.

According to Siemens' TIA Portal documentation (support.industry.siemens.com, accessed January 2025), the S7-1500 OPC UA server includes a session monitor in TIA Portal—but session recovery behavior after a network interruption is not validated by default diagnostics. The system log will show a session fault. It won't tell you what happened to the data flow between the fault and the recovery.

Did the vendor test it? Depends on what "test" means. If it means "the tag was readable during the demo," they tested it. If it means "the session renewed cleanly under a simulated 30-second network drop while the historian was subscribed," they didn't—and you can guess which scenario actually occurs in the field.

Why does this matter? Because OPC UA subscription behavior isn't just an IT concern. If the subscription drops during a shift change and the historian loses five minutes of data, you've lost traceability. If the subscription drops during a recipe download, the PLC may hold the last good value—or it may not. That depends on how the client handles retries. And that depends on whether anyone tested it.

Omdia's Q3 2024 industrial automation tracker puts Siemens' global PLC market share at roughly 32% by revenue. Verify the current figure—it moves quarterly. But the number matters for a reason: with that footprint, a configuration error in an OPC UA server isn't a rare edge case. It's common enough to have a name. Most people just don't look for it.

"The RTD Reads 25°C. Ship It."

I watched a technician verify a PT100 input by connecting an RTD simulator, setting it to 25°C, and confirming the HMI displayed 25°C. He signed the sheet. Done.

Here's the thing: 25°C is the easy point. The module is designed to read it accurately. The interesting behavior happens at 80°C, at -10°C, and over 200 meters of cable.

If you want to know how to check an RTD using a multimeter—and actually verify the input, not just the display—you disconnect the RTD, measure its resistance at the probe, and cross-reference against the RTD table. For a PT100, 100Ω at 0°C, 138.5Ω at 100°C. Then you compare that measured value to what the module reports. The difference is your error. If you don't have a calibrated source, at least check three points: ambient, hot, and cold. One point is not a test. It's a glance.

Siemens specifies the AI 8xRTD module at ±0.1% of the measured range at 25°C. That's a spec. The question is whether your module's actual reading at 80°C is verified against a calibrated source. The TIA Portal analog value processing documentation (accessed December 2024) notes that line resistance compensation must be enabled for 3-wire and 4-wire RTDs to achieve the specified accuracy. If that checkbox is off, your readings walk—and no one notices until the product is out the door.

Put another way: the PLC was fine. Our process wasn't.

Small Orders Don't Get a Pass

This is the part that makes me angry.

A large system integrator buys 50 S7-1200 units. Full 48-hour load test. Checked and re-checked.

A small factory buys three S7-1200 units for a central AC control panel upgrade on a rooftop unit. The vendor's acceptance protocol was two pages. Two. I've seen purchase agreements with longer attachments.

My team and I found two problems in that package. First, the analog inputs were tested with a simulator that only generated a 4mA signal—one point on a 4-20mA loop. Second, the OPC UA server certificate on one unit was issued to "TestServer.local"—a throwaway cert that would expire in 49 days. Not a functional issue today. A production outage in seven weeks.

Same verification hole. Smaller invoice. No one caught it because the protocol was written for a system the customer didn't buy.

I'm not saying small integrators are careless. I'm saying the economics push toward abbreviated testing. Forty hours of verification on a $200,000 project is easy to absorb. On a $6,000 project, it's a line item the customer questions. So it gets shortened. Then it gets skipped.

The argument against full testing on small orders is cost. The argument for it is downtime. Downtime doesn't care about your project size. A single-shift operation losing a day of production loses a week of output. That math is worse than any acceptance protocol I've ever written.

What It Cost

It took me three years and about 150 acceptance protocols to understand that passing a test doesn't mean the system is good. It means nothing catastrophic broke during the test window.

Year one: an OPC UA session fault went undetected through acceptance and triggered on every shift change. The historian lost data for roughly three weeks. If I remember correctly, the rework cost was around $11,000 in manual record reconstruction. I might be misremembering the exact figure—don't quote me on the dollar amount—but the traceability gap was real and documented.

Year two: a PT100 input ran with line resistance compensation disabled. Baked goods came out overcooked for six weeks before anyone traced it. The customer didn't complain. The quality team did. I want to say 1,200 units were scrapped, but I'd have to pull the report to confirm.

Neither of these was a hardware failure. Both were verification failures. They cost more than the verification would have.

What I Do Instead

Not a 48-hour load test. But not two pages either.

Run the OPC UA server for two hours with at least one client session open. Confirm session renewal, check the keep-alive interval, and log the results. Siemens' OPC UA server is reliable. The configuration that surrounds it—often—isn't.

Test analog inputs at three points. Use a calibrated source if you have one. If you don't, use an RTD simulator and cross-check with a multimeter at the probe. Verify line resistance compensation is enabled. Record actual values, not just "pass."

Check time synchronization if the system uses time-based logic. Two devices on the same PLC can drift. It's a small issue until it isn't.

And for small orders: ask for the real protocol. If your vendor says "this scope doesn't include full verification," treat that as a scope conversation, not a quality standard. I've turned down orders where the price excluded basic signal verification. Not because I'm difficult. Because that's not a quality guarantee—it's a delivery receipt.

The Question to Ask

The customer with the packaging line didn't need a better PLC. He needed a better question at acceptance.

Don't ask your integrator: "Does it work?"

Ask: "How do you verify that it still works next month?"

Not ideal, that conversation. But workable. And far cheaper than the one you'll have when the line stops.