PLC, SCADA and Historian Layers: Where Industrial Reporting Usually Fails
If report figures do not match from shift to shift, the problem is usually not the reporting tool but the data path from source signal to report.
The symptom on site
Shift reports do not agree, the same KPI shows different values on different screens, and maintenance cannot trace a figure back to the tag it came from.
Likely root cause
Reports were bolted on after the screens, piece by piece. The boundaries between PLC, SCADA and historian were never written down; retention, operator inputs and calculation logic sit where nobody owns them.
What to check
Where is the source signal for each KPI? Is tag naming consistent? Do historian retention and sampling match what the report needs? Where are operator inputs entered, and by whom? Is the calculation logic written down?
The wrong fix
Buying a new BI tool or reporting platform before the data path is clear. The same problem simply reappears on the new screens.
A better approach
Map the PLC → SCADA → historian → SQL/report chain; write down the naming standard, retention rules, operator input boundaries and acceptance tests for each report type.
Our view
We build reporting as a layer of the existing OT structure, not as a separate software project. Every report should be verifiable back to its source signal.
Seeing something similar? Let's look at your current setup together.
Share your current situation