GRIDARA

Technology

Additive control, at protocol level, on the systems you already run.

This page is written for a BMS engineer or a technically literate evaluator. It states what GridAra reads, what it writes, how it signals the market, and where the security and registration work currently stands.

Architecture

One orchestration layer, four levels.

Site inputs feed the IPEOS engine. IPEOS, the Intelligent Precinct Energy Operating System, drives orchestration across the seven-day cycle and presents role-specific views. Every protocol boundary is a standard interface, not a bespoke one.

data up · control down 04 · VIEWS Stakeholder views — one reconciled data model Facilities manager Building & portfolio manager Asset owner 03 · ORCHESTRATION Load moved in time, across the seven-day cycle Pre-cool in the solar window Coast through the evening peak Demand-response events Portfolio coordination 02 · IPEOS ENGINE The orchestration core Machine-learning price & load forecasting BACnet ↔ dispatch bridge Dispatch & optimisation engine OpenADR 2.0b → BMS gateway Verified energy reconciliation 01 · SITE INPUTS The systems already in the building BMS (BACnet/IP) Solar & battery (Modbus TCP) Market signals (AEMO) Interval metering (NEM12)
IPEOS runs as one layer over the building's own systems. Live data and verified results flow up; additive setpoint commands flow down through the OpenADR-to-BMS gateway, always inside limits agreed with your engineers. If the gateway stops, the BMS runs unchanged.

In detail

What connects, and how.

Integration method

BACnet/IP and Modbus TCP. Read-write access to zone temperatures, AHU supply air, chiller plant status and whole-building demand — using the points your BMS already exposes.

Non-invasive design

GridAra issues additive setpoint adjustments, not replacements of existing control logic. Your sequences, interlocks and safeties are untouched. If the gateway drops, the BMS runs as before.

Demand response signalling

OpenADR 2.0b is the standard GridAra uses to exchange demand response signals with the building and with programme operators.

Dispatch & optimisation

The engine evaluates live and forecast electricity prices and assigns the building's flexibility to its highest-value use each interval — energy cost avoidance, demand-charge reduction, or a demand response event. Forecasting uses machine-learning models trained on Australian market and weather data.

One model, three views

Every stakeholder reads the same reconciled data.

BMS, battery, metering and market data are reconciled once. Each stakeholder sees that single model shaped to the decision in front of them — so the numbers never disagree between the plant room and the boardroom.

One reconciled data model BMS · batteries · metering · market Facilities manager Battery state, thermal headroom HVAC zone setpoints Demand-response event log Building & portfolio manager Energy attribution: solar / battery / grid PPA rate vs retail Pre-cooling schedule, verified NABERS reporting Asset owner Portfolio performance across sites Energy cost and savings forecast Early-warning maintenance flags
One model, no conflicting numbers. The facilities manager works the plant, the building or portfolio manager runs operations and reporting, and the asset owner sees the cost and sustainability picture. All of it from the same reconciled source.

Beyond a single building

Precinct coordination.

The same dispatch and optimisation engine that manages one building can manage several on one site as a single system. When one building generates more solar than it can use, IPEOS can direct that surplus to another building on the same connection instead of exporting it. The decision is made every dispatch interval, alongside the battery and load decisions already described.

Three conditions have to be met. The buildings share a single grid connection point. There is common ownership, or an agreement that lets energy move between them. And metering is in place that can attribute energy use and generation to each building accurately, which is what makes internal settlement and reporting possible.

Where those conditions are not met, for example between buildings that are separately owned and separately connected, the arrangement becomes a private distribution network rather than an orchestration layer, with different capital and regulatory requirements. GridAra treats precinct coordination as an extension to pursue site by site, after the building-level deployment is running.

Security posture

Encrypted, bounded, and built to a national framework.

  • Encrypted communications between the on-site gateway, the building and GridAra's platform.
  • Bounded authority. The gateway can only read its defined point list and write offsets inside the agreed envelope.
  • Designed for the Australian Energy Sector Cyber Security Framework (AESCSF). Alignment work is in progress; certification is not yet complete.

Current status

Where the registration work stands.

GridAra's National Electricity Market participation, demand response service provider arrangements and AESCSF alignment are in progress. Anything not yet complete is described on this site as “built to” or “designed for” the relevant standard — not as an achieved status. Current detail is available on request.
Talk to our technical team