A SCADA system controls and monitors a facility, displaying real-time variables and actionable data so operators can make informed decisions and execute commands in a controlled manner.

Every action taken on a system element — whether manually by an operator or automatically by the controller — must generate a log entry recording the date, time, operator identity, and changes made. That log builds a historical record that can be reviewed at any time and used to produce analysis or audit reports.

Storing a record in a database is straightforward on its own. But it takes thoughtful software architecture to make that data functional across system components and deliver a solution that is modern, useful, and user-friendly.

Storage Constraints in Typical SCADA Controllers

SCADA systems commonly run on small electronic controllers housed inside a panel or enclosure, with just enough memory for the application code and a limited number of log entries. This trade-off makes sense for consumer-grade electronics, where manufacturers strip out components to reduce unit costs. Higher-end or industrial-grade models, however, do offer expanded storage or add-on memory cards.

SCADA controller with onboard storage capacity for logs and notifications.

It is technically possible to run a controller with enough memory to store notifications, logs, and reports — all exportable to a spreadsheet. But is that approach sufficient, or even realistic, in a modern context?

A modern SCADA must support long-term storage of relevant data about control actions and the components that make up the system — actuators and sensors alike — and that data must be consumable or exportable in multiple formats.

Using Historical Data for Analysis and Auditing

With historical sensor data — temperature readings, energy consumption in kWh — engineers can study how an HVAC system behaves over specific time periods, detect faults, and audit performance using charts or structured spreadsheets.

When significant changes occur in the system, the operator must be informed even if they cannot observe the event in real time. The mechanism for this is an alarm or notification that requires explicit acknowledgment before it clears or stops alerting.

An "Emergency shutdown of the main pumping system" alarm, for example, is high-priority. Depending on its severity level, the SCADA should trigger a visual alert, an audible alarm, an email, or an SMS — ensuring the operator is aware of the emergency. The alarm message must then be marked as read or acknowledged to confirm the operator received it.

Processing Power and Report Generation

Processing capacity is a critical factor when generating reports. Producing a meaningful, modern report means computing historical data and transforming it into a consumable format.

Generating an alarm or notification report filtered by subsystem or operator is just as computationally demanding as generating an energy consumption report for a specific office zone. Both require processing capacity that meets current expectations — no one should have to wait an unreasonable amount of time to generate or view results.

Reports and alarms view in a modern SCADA system.

A capable reporting layer is not easy to achieve, because it demands more processing power and storage than most commercial control hardware typically provides — and scaling up those capabilities raises costs significantly. Building a custom reporting system is the ideal path for many projects, but custom development tailored to specific requirements is often prohibitively expensive.

There is also a shortage of flexible solutions that can communicate with any brand or protocol and produce standardized reports.

Compliance, Certification, and the Case for a Dedicated Reporting Layer

Certifications such as LEED require storing operational data over extended periods, with the ability to query and audit it at any time. That makes a robust reporting system a compliance necessity, not just a convenience — covering alarms, notifications, consumption data, configuration changes, and more.

At Innotica, we developed Pegasus Report to address exactly this gap. It is the ideal complement for a SCADA with limited memory, constrained processing power, or requirements for deep flexibility and granular detail. Pegasus Report operates in parallel with the existing control infrastructure, non-invasively — avoiding electrical interference and promoting subsystem decentralization. Because it introduces no changes to the control layer, each subsystem becomes more robust.

Oscar Calcaterra — ocalcaterra@innotica.net