SCADA reports: define the data first

A report shows a shift quantity that differs from the machine counter. Before changing the chart, check the data definition: when a part is counted, whether rejects are separate and what happens when the recipe changes. Reliable reporting starts with agreed events and period boundaries. Connecting tags to a dashboard does not resolve different meanings of the data.

Process values and reported results

A control value and a shift-accounting value may serve different purposes. Current speed helps observe a machine, while a production result needs a definition of which parts were counted and when. Record each item's name, source, unit and intended use before building the view. Establish who will make decisions from the report: operators, maintenance or production planning.

Define the event that increments each counter and its reset rules. Separate total production, good parts and rejects. For several connected machines, identify the source of the line result. Adding counters from successive stations may count one product repeatedly. If quantity comes from the difference between counter readings, detect resets, device restarts and possible rollover rather than interpreting a falling value as negative production.

Timestamps and data quality

Identify whether a timestamp comes from the device, the collection system or archive insertion. Those moments can differ, particularly after communication returns. For multiple sources, check clock synchronisation and the time zone. Shift boundaries and daylight-saving handling belong in the reporting rules, rather than depending on the computer used to open an export.

Keep data quality or status alongside the value when the source provides it. A stale reading and a missing sample are not zero production. Reports should identify periods without reliable data and explain how they affect the result. Carrying forward the last value may help a live display, but its use in a total, average or operating-duration calculation needs separate consideration.

Choose the right aggregation

Decide whether a result is an event count, counter difference, measurement average or time spent in a state. These operations are not interchangeable. An average speed from occasional samples does not automatically reconstruct the number of parts produced. For brief events, check whether collection captures them at all. Distinguish the reading interval, archive interval and period used for later summaries.

Define which shift receives an event at a period boundary. For batches, establish opening, closing and product identification. A recipe alone may not provide traceability when several batches use the same settings. Agree the required identification level with the report's users. One counter and a timestamp do not justify a claim that the complete history of each product is available.

Stops, alarms and reasons

Machine not running does not distinguish a fault, missing material, changeover and a planned break. Some categories come from PLC states; others require operator input. Define precedence when several reasons apply. Without that rule, reports can allocate the same time to different categories even though they use the same signals.

Keep alarms, informational events and stop-duration accounting distinct. An alarm may occur while production continues, and a planned stop may generate no alarm. Retain category start, end and source where needed. If a manual correction affects the report, make its reason identifiable. Users can then explain a changed result rather than searching for a hidden error in the chart.

Exports, retention and verification

Include units, reporting period, time zone and understandable column names in an export. For CSV, agree separators and numeric formatting so that opening the file in a spreadsheet does not change its meaning. Define how long detailed records and summaries are retained. Retention depends on operational needs, capacity and maintenance cost, not an assumption that every sample will remain available indefinitely.

Before expanding reporting, compare one short period with machine history. Include a counter reset, product change, shift boundary and connection loss. Explain discrepancies before adding more charts. For HMI and SCADA work, agree the data definitions and verification method first. Bring a sample report, available tag descriptions and the questions that the result needs to answer.