01
Connect
Platform · in development
Connect the automation, electrical and energy systems already on site through edge gateways and open interfaces.
ONE.OS · Platform under development
The software layer between building and energy systems.
ONE.OS is being built to connect existing infrastructure and give its data a consistent structure. The planned platform would provide a base for future monitoring, automation and energy optimisation across systems.
Why ONE.OS exists
The missing part is often between the systems.
A BMS can coordinate many building functions. It still has to coexist with energy platforms, vendor clouds, gateways and specialist controllers. ONE.OS is intended to provide a common layer across those boundaries while the underlying systems keep their role.
- 01Existing BMS and controllers
- 02Energy platforms and meters
- 03Vendor clouds and local gateways
- 04Repeated custom integration
Architecture
Physical systems below. Useful applications above.
The planned architecture uses ONE.Edge for local OT connectivity and ONE.OS to structure and share data. Critical building operation would not have to depend on a cloud connection.
01Existing physical systems
KNX
BACnet
Modbus
HVAC
Meters
EV
PV
Battery
ONE.Edge
Connect · collect · normalise · buffer
ONE.OS
Common data · semantic context · orchestration
04Operations and applications
Operations
Energy
Analytics
Automation
AI · direction
Open APIs
Edge-capable
Appropriate local operation stays close to the physical systems.
Vendor-agnostic
Existing and future systems connect through protocol-aware adapters.
Extensible
Contextual data can serve operations, analytics and third-party software.
ONE.Edge
Keep appropriate operation close to the building.
ONE.Edge is planned as the local part of the ONE.OS architecture. Its intended role is to connect OT systems, normalise and buffer telemetry, and communicate with ONE.OS. Appropriate local functions could continue when the cloud is unavailable. ONE.Edge is not a standalone product.
- 01Local OT connectivity
- 02Telemetry normalisation
- 03Data buffering
- 04Resilient local operation
- 05Secure cloud communication
A shared building model
A register number is not yet useful information.
Applications should not need a list of vendor-specific point addresses. The planned semantic model links each signal to the site, space, asset, meter or energy flow it describes.
Platform direction
Raw technical point
Modbus register 23316 · device 34Contextual meaning
Active power · main electrical meter
From signals to decisions
Connection is where the work starts.
Raw data is not enough. The platform has to give each signal meaning before it can support reliable control or optimisation.
01Existing systems, connected
02
Normalise
Platform · in development
Connect different protocols and normalise vendor-specific data into a consistent technical model.
03
Understand
Platform direction
Give each signal a place and a purpose: site, room, asset, meter or energy flow.
04
Automate
Platform direction
Coordinate actions across systems while each controller keeps doing its own job.
05
Optimise
Platform direction
Improve performance over time using the operating limits and priorities of each site.
Platform scope
One layer for building and energy data.
Each capability carries a maturity label, so planned work is not confused with available functionality.
- Platform direction
Building automation
Bring HVAC, room control, lighting, schedules, occupancy, alarms and meters into a common operational context.
- Platform direction
Energy coordination
Relate grid demand, PV, batteries, EV charging, heat pumps, flexible loads and tariffs to building operation.
- Platform · in development
Open interfaces
Make contextual building data available to applications and third-party software through practical open interfaces.
- Platform · in development
Edge resilience
Keep appropriate local functionality close to physical systems and separate OT from IT or cloud networks where required.
Cross-system use cases
Use cases that cross system boundaries.
Each use case needs information from more than one controller, protocol or vendor platform.
- Platform · in development
Connect existing infrastructure
Bring legacy and modern systems into one architecture without unnecessary rip-and-replace.
- Platform direction
Build a contextual asset model
Relate technical points to sites, spaces, equipment, meters and energy flows.
- Platform direction
Monitor operational performance
See building behaviour, energy demand, alarms and equipment state in one operational context.
- Platform direction
Automate across systems
Coordinate occupancy, schedules, comfort, electrical limits and equipment state across vertical domains.
- Platform direction
Optimise energy flows
Coordinate grid demand, PV, batteries, EV charging, HVAC and flexible loads instead of optimising them separately.
- Platform · in development
Open building data to applications
Expose contextual data through practical interfaces for operations and third-party software.
Protocol-aware, not protocol-led
Use the protocol. Keep your options open.
ONE.OS is being designed for both legacy and modern infrastructure. BACnet, Modbus, KNX, MQTT and APIs would connect systems to the platform without defining its full scope.
- 01BACnet
- 02Modbus TCP / RTU
- 03KNX
- 04MQTT
- 05REST APIs
Platform direction
AI needs building data it can trust.
Connection, context and reliable control come first. With that foundation, future assistants could investigate unusual consumption, spot conflicting operation and help schedule flexible loads.
- 01Why did this site’s energy consumption increase yesterday?
- 02Which rooms are heating while unoccupied?
- 03Optimise EV charging without exceeding contracted power.
ONE.OS
Need a common layer between systems?
We can map what is installed, what the project needs and where the integration layer belongs.
Platform scope and maturity are assessed per use case.