What if the values in your batch report are not exactly the same as the ones generated by the machine? In many pharmaceutical facilities, batch data is pulled from the PLC through standard connections into SCADA or other systems, where key parameters are recalculated externally. The assumption is that the results will match the machine’s own report. In practice, they diverge, creating a second, unvalidated source of truth that most facilities don’t flag as a data integrity risk until an auditor surfaces it.
Why this happens
Pharmaceutical machines generate three distinct data types: alarms and events, real-time measurements, and batch reports. Systems such as historians or SCADA handle the first two comfortably over OPC. But batch reports are often stored in proprietary formats, locked SQL databases, encrypted CSVs, vendor-specific binary files, that sit outside the OPC protocol layer entirely. Faced with this gap, engineering teams build a workaround: capture real-time OPC-UA tags during production and recalculate the batch results externally.
What this workaround introduces
The recalculation creates three specific risks. First, a sampling rate mismatch: PLCs execute control loops at 10 to 100ms, while OPC-UA typically polls at 500ms to 1 second. Recalculating from polled data means working with a fraction of the data points the PLC used, and for fast transients the results will diverge.
Second, calculation drift. The algorithms inside a PLC, floating-point precision, integration methods, rounding logic, are specific to that machine’s firmware. Replicating them externally requires reverse-engineering the PLC’s logic and maintaining exact parity over time. Small differences accumulate. During routine production, nobody notices. During an audit, an inspector comparing reported values against the machine’s own record will.
Third, a re-validation burden. The PLC’s batch report is validated as part of equipment qualification. An external recalculation path requires its own independent validation, the application, the transfer mechanism, the recalculation logic, the storage layer. Every PLC firmware update or algorithm change triggers re-verification. The cost compounds over the equipment’s lifecycle.
The alternative architecture
The alternative is not to recalculate at all. A dedicated process data management layer connects directly to each machine’s native interface, not just OPC, but the proprietary protocols where the validated batch report actually lives, and retrieves the report data as-is. No recalculation, no sampling rate compromise, no parallel validation chain. The PLC’s batch report remains the single source of truth from generation through to quality review.
The same connection path enables a second capability: delivering pre-validated production recipes directly to the PLC. Instead of manual recipe entry at the HMI before each run, the MES sends the production order through the data layer, which translates it into a machine-specific format. Recipes flow down, validated batch reports flow back up. No manual transcription at either end.
When this decision matters
Data architecture decisions carry the least friction during two windows: when a new line is being commissioned and the automation stack is still being specified, or when an existing line undergoes a significant retrofit. If your batch reports are being recalculated, resampled, or reconstructed anywhere between the machine and quality review, you have a data integrity gap, and the window to close it is smaller than it appears.
Download Whitepaper:
For more information, please contact us at sasa.sokolic@metronik.si.
