Remote control of energy assets

When you need control, not just monitoring

Most energy monitoring projects start the same way: "we want to see what the site is doing." Within a few weeks of operation a second question almost always shows up: "and can we change something from this dashboard too?" That is the moment monitoring becomes remote control of assets.

Concrete scenarios where remote control is unavoidable:

• Setting PCS active-power setpoint — the BESS operator reacts to an aggregator signal or to spot electricity price and has to shift the storage mode (charge / discharge / hold) immediately.
• Dispatch curtailment — the distributor or internal dispatch demands PV output limits. A manual intervention on site is neither acceptable in response time nor in auditability.
• Fault reset — after the root cause is cleared, the operator needs to remotely acknowledge the fault and bring the asset back online without a truck roll.
• Protection setting changes — seasonal adjustment of current or voltage thresholds on a REF615, with full traceability of who, when and why.

Architecture of cloud-based control

Controlling an asset from a cloud platform looks nothing like reading telemetry. Writing to a Modbus register changes physical state, and that carries different requirements on security, latency and auditability. ECC handles control this way:

1. The operator sends a command from the web app. The app checks their permission (RBAC: role operator or admin) and validates the command against the device's register map (that this register is writable, that the value is within the allowed range).
2. The validated command is sent as a direct method through Azure IoT Hub to the edge module. Direct methods time out — if the edge does not respond within 30 seconds the command is rejected and the operator sees it immediately.
3. The edge module writes over Modbus (function codes FC6 / FC16) and returns the device's actual response. Nothing is "fire and forget"; every command carries a confirmed or rejected result.
4. The full chain — who, when, what value, which device, what result — is written to an audit log table with a hash chain. Auditors can verify the chain cryptographically at any time.

Safety of remote writes

Remote control of an energy asset is one of the most sensitive functions of the platform under NIS2 and ISA/IEC 62443. Specific safeguards we ship with:

• Rate limiting per user and per device — a token bucket prevents accidental double-clicks and targeted attempts to flood a device.
• Explicit write allowlist in the register map — only registers marked writable: true can be changed. Protection functions and configuration are typically read-only.
• Two-person integrity for critical changes (roadmap) — protection threshold changes require a second admin-role confirmation.
• Audit chain with hash linking — each row in audit_log contains a SHA-256 hash of the previous row. Tampering with the log is detectable immediately; an hourly job verifies the chain automatically.
• Session invalidation via lastLogout — revoking access is instant, not delayed until JWT expiry.

When cloud control does not make sense

Honestly: not everything belongs in the cloud. Protection functions (fast trip, distance protection, undervoltage blocking) always stay in the local relay or PLC with millisecond response times. The cloud is the dispatch layer — slower decisions that can be made in seconds and need one shared view across the fleet. The interface between local protection logic and the cloud dispatch layer is the typical scope of an integration project we deliver.

Related to integration services

Remote control is not a standalone product — it is the output of a well-executed integration. If you have a specific project where you need to combine visualization, dispatch and safe remote writes, start on the energy systems integration page. It covers the service scope and the technology stacks we work with.