Published 22 October 2026 · 6 minute read
This is a story about our own software. It was found in our own testing, on a demonstration line, and it has been fixed and verified. We are publishing it because the same mistake can sit unnoticed in almost any plant that moves PLC data through an edge gateway, and because the way it was caught says something useful about release gates.
A recent test batch on a real PLC ran an ISA-88 recipe shaped like tablet granulation. One phase dosed a binder with a target of 2.5 kg and a tolerance of ±5 %, so anything from 2.375 kg to 2.625 kg was acceptable.
The batch record showed 2.3 kg. When QA opened the disposition, the release gate refused ACCEPT: the material was reconciled outside recipe tolerance. That is exactly what the gate is for.
The interesting part came next. The PLC's own final value for that dose was 2.500 kg. The dose was fine. The record was wrong.
Two design choices, each reasonable on its own, combined to lose the last part of the dose.
First, the edge gateway used a deadband. Like most edge software, it published analog values by exception: a floating-point value was sent only when it had changed by more than 0.2 since the last value sent. Report-by-exception with a deadband is standard practice. It keeps a temperature that wobbles by a hundredth of a degree from flooding the network.
Second, the MES recorded each dose once, when its phase completed. At phase completion it took the latest dose value it had received and wrote it into the batch record.
During dosing, the value climbed. The gateway sent it in steps. The last step it sent was 2.3 kg. The final 0.2 kg increase, from 2.3 to 2.5, was not more than 0.2, so it was never published. The phase completed, the MES read the last value it had, and 2.3 kg went into the record.
It was not a one-off. On a later batch, another material was recorded as 0.700 against the PLC's 0.833, for the same reason: the last change, 0.133, was under the deadband.
Deadband errors are hard to spot by eye. A trend of the dose shows a smooth climb and a flat line at the end. The flat line looks like the dose finished; in fact it is the last value that crossed the threshold. The PLC held the correct value all along. Only the comparison between the record and the controller exposed the gap, and only because the release gate checked reconciliation against tolerance.
The fix was to separate two kinds of value that had been treated the same:
The MES still records the controller's number at phase completion. The difference is that the number it has is now always the controller's final number.
We verified the change on the next batch on the real line and on a simulator. Every dose recorded in the batch record matched the PLC to the last digit.
None of this is specific to our software. If you move PLC data to an MES, historian or EBR through any gateway, the same failure is possible.
In data-integrity terms, the recorded 2.3 kg failed accurate and original: it was neither the true value nor the value captured at the source. It also shows why complete matters. Every individual message the gateway sent was correct. The record was wrong because one message was missing, and nothing in the data said so.
The PulseMQ edge gateway publishes recorded quantities on any exact change and keeps the deadband for other analog values. PulseMQ records dose actuals per phase and the final quantity and defects at completion from the PLC, under an ISA-88 recipe where the PLC is master. The QA release gate refuses ACCEPT while a material is reconciled outside recipe tolerance, and lists every other open reason at the same time. More on the protocol side in what is Sparkplug B, and on the full flow on the pharmaceutical and GMP overview.
Pilot it on one batch line. We connect to your PLC, map its phases and dose actuals to the record, and your own QA signs real dispositions on your own batches.
See the pharma pilotWhat is a deadband in an edge gateway?
A threshold for report-by-exception publishing: an analog value is sent only when it has changed by more than the deadband since the last value sent. It reduces network traffic for noisy signals such as temperatures.
Why can a deadband make a batch record wrong?
If the MES records a quantity at a single moment, such as phase completion, and the final change in that quantity is smaller than the deadband, the final value is never sent. The record then holds the last value that crossed the threshold, not the controller's final value.
How do you prevent it?
Publish recorded quantities, such as dose actuals and final counts, on any exact change, outside the deadband. Keep the deadband for monitoring values. Test it by running a dose whose last increment is smaller than the deadband and comparing the record with the PLC.