Technology & trust
Built to control real equipment, not just chart it
DYDON Energy AI OS is an operating system in the practical sense: it talks to hardware from many vendors, holds one model of every site, decides what each asset should do next and sends the command. This page explains how, without the parts we keep confidential.
What the platform does
Every capability below is in production use across the product lines. Each one is described in the present tense because it exists today.
- Multi-vendor integration
- Chargers, batteries, inverters, meters and building loads from different vendors are brought onto one platform through open protocols and, where needed, vendor APIs. Vendor quirks are handled in the integration layer, not in the products.
- Real-time data
- Telemetry from every site flows into one data model with one set of definitions, so a battery in Taiwan and a charger in Australia are described the same way.
- Forecasting
- Load, generation, tariffs and market signals are forecast per site and per portfolio, and refreshed as new data arrives.
- Optimisation
- The AI optimisation engine plans dispatch across all assets at once against cost, demand limits, equipment constraints and market opportunities.
- Control
- Plans become commands. The edge agent executes them on site and reports back, closing the loop between decision and equipment.
- Market services
- Aggregation, bidding, event dispatch and settlement for demand response and frequency programmes run on the same platform as control.
- Anomaly detection and self-healing
- The platform watches for equipment and communication faults, retries and reroutes where it safely can, and raises what it cannot fix.
One model of every site
The value of coordinating assets comes from describing them consistently. The data platform is what lets one forecast and one optimisation serve six asset classes.
- Unified asset model
- Every device is represented with the same schema regardless of vendor: capabilities, constraints, state and history.
- Time-series at scale
- High-frequency telemetry is stored and queried efficiently enough for both real-time control and long-range analysis.
- APIs for partners
- Partners and customers reach the same data and controls through documented APIs, which is how white-label products and fleet systems integrate.
- Reporting
- Energy, cost and emissions reporting is derived from the control data itself rather than assembled separately.
Designed for equipment that must not be misused
The platform controls physical assets, so security is treated as a control problem as much as an IT problem. We publish the principles; implementation details are shared with customers under agreement.
- Cloud-native on AWS
- The platform runs as microservices on AWS with infrastructure managed as code, so environments are reproducible and isolated.
- Least-privilege access control and verification
- No service or site is trusted by network location. Every call is authenticated and authorised.
- Device identity
- Each edge agent and connected device carries its own identity and credentials, so a compromised device cannot impersonate another.
- Least privilege for control
- Commands that change how equipment behaves are scoped, logged and constrained by the site's safety envelope at the edge.
The site keeps running when the cloud does not
Energy equipment cannot depend on an always-on connection. Reliability is designed around that assumption.
- Edge autonomy
- The edge agent holds the current plan locally and keeps executing it inside the safety envelope if connectivity is lost.
- Safe defaults
- If a plan expires or a command is rejected, assets fall back to a safe configured state rather than the last instruction.
- Fault isolation
- A failure in one site, service or vendor integration does not spread to the others.
- Operational visibility
- Site reliability engineering monitors the platform and sites continuously, with alerting on both software and equipment health.
Common questions
Which vendors do you support?
Any equipment that speaks OCPP, OCPI, OpenADR, CSIP-Aus, Modbus, MQTT or SunSpec, plus vendors we have integrated through their APIs. Ask us about a specific model and we will tell you.
Does DYDON need its own hardware on site?
The edge agent runs on a small industrial gateway or on hardware the site already has, depending on the equipment. It does not require DYDON-branded chargers, batteries or inverters.
Where is our data stored?
In AWS regions appropriate to the market. Data residency requirements are agreed per customer.
Can we integrate DYDON into our own software?
Yes. The same APIs that power the white-label products and fleet integrations are available to customers and partners.
What happens to control if DYDON's cloud is unavailable?
Sites continue on their last plan inside the safety envelope, then fall back to a safe configured state if the plan expires. Nothing on site depends on the cloud to stay safe.
Ask the engineers
If you want to go deeper on integration, protocols or security than this page does, a technical call with the team is the fastest route.