Real-time data core: one live data model, measured

Why the edge needs one shared data model

A solar-plus-storage site gateway or an industrial controller is several programs at once. One polls inverters, meters and battery systems over a fieldbus. One runs the control loop that turns a site limit into power setpoints. Others serve the commissioning web page, record faults, log history and forward telemetry upstream. In a common design, each of these keeps its own copy of the site's state and passes messages to the others, so the same battery state of charge can live in several places, refreshed at different rates.

That arrangement fails in predictable ways. The dashboard shows one value while the controller acts on another, a new device type means touching every program, and timing bugs appear only when copies drift apart under load.

ByteHive's edge runtime takes the opposite approach. There is one live, typed data model, and every service on the device reads and writes it. A value polled from a meter is the same value the control loop uses, the web page shows and the logger records, from the moment it changes.

Typed variables and device instances

The data model is made of named variables, each with a declared type. Because the type is part of the definition, every consumer agrees on what a value is: a 16-bit register, a 64-bit energy counter, a floating-point setpoint or a line of status text. Nothing has to be re-parsed differently in each service.

That is nine types in total. Strings up to 8 KB let non-numeric but operationally important information travel in the same model, with no side channel.

Device instances

Energy sites are repetitive: a row of identical inverters, several battery strings, multiple meters. ByteHive models this with device instances. A device type is described once and instantiated as many times as the site requires, and every instance's values live in the same data model as everything else. Control logic can address one unit, or aggregate across all of them.

The model starts with room for 32,768 variables and grows as needed, so the size of a future site is not a decision baked into the firmware in advance.

Change-driven push instead of polling

The usual way for one program to track another's data is to poll it, which forces a trade-off with no good answer. Poll fast and you spend CPU re-reading values that have not changed, on a small gateway that is also running a web server and an encrypted cloud link. Poll slowly and every reaction waits, on average, half a poll interval before it even sees the change.

In ByteHive, a service subscribes to the variables it cares about and is pushed a notification only when a value actually changes. Writing the same value again wakes no one. Two consequences matter in practice:

• Reaction time is decoupled from a polling schedule. Logic responds when its input changes, not at its next scheduled look.
• Unchanged values wake no one. When nothing changes, subscribers sleep. The runtime's event-driven state machines make zero CPU wake-ups while idle, which leaves headroom for everything else the gateway does.

To be precise about where polling remains: field devices that speak a polled protocol such as Modbus are still polled, at rates configured per block of registers (for example 500 ms for fast-moving power values and 3 s for slow ones). From that boundary inward, services that subscribe receive changes by push instead of re-reading values.

Batch writes

Real control actions rarely involve a single value. A device poll returns a block of registers; commissioning a unit or applying a group of limits touches several variables at once. Batch writes let a service write a group of values together instead of as a series of individual writes.

Measured behaviour on ARM64 gateway hardware

The figures below were measured on a Cortex-A76-class ARM64 gateway, the hardware class targeted by the production appliance image, running the ByteHive edge runtime. They describe that hardware, not every board and workload.

8.4 µs

Variable read, measured on a Cortex-A76-class ARM64 gateway

0.6 µs

Read from a cached subscription, same hardware

63 µs

Median state-machine reaction to a value change (129 µs maximum observed), same hardware

19 µs

Cost of one PID control step, same hardware

How to read these numbers

• They are measurements, not bounds. 129 µs is the largest reaction observed in testing: a measured maximum, not a promised limit. The runtime runs on Linux, and heavy unrelated load on the same device can lengthen latencies.
• They cover the device's software, not the whole loop. At a real site the dominant delays are usually physical: polling intervals, inverter ramp rates and the response of power electronics. ByteHive's job is to make sure the software in the middle is not the bottleneck.
• Protection belongs in hardware. ByteHive is built for site-level supervisory control and setpoint management. Fast protection functions such as overcurrent trips and emergency stops should stay in device firmware and hardwired interlocks, as on any well-designed energy system.

Control logic on top of the data model

Because every value lives in one model, control logic needs no plumbing of its own. A built-in scripting engine and an event-driven state-machine engine read and write the model directly, so site behaviour such as limits, operating modes and control loops can be expressed without writing or compiling C.

Scripts that react to change or run on a tick

• On-change scripts run when an input they depend on changes. They suit limits, derived values and alarms.
• Tick scripts run on a fixed interval. They suit control loops, ramping and time-of-day logic.
• Fleet aggregates (SUM, AVG, MIN and MAX across every online device) let logic compute total site battery power or the lowest state of charge across all strings without listing each unit. The result follows the set of devices that are actually online.
• Built-in control functions cover PID with anti-windup, low-pass filters for noisy measurements, and time-of-day logic.

State machines

Operating modes such as standby, charging, discharging, fault and maintenance are clearer as a state machine than as nested conditions. ByteHive's event-driven state machines support up to 32 states, react to value changes (63 µs median on the hardware above) and make zero CPU wake-ups while idle.

Checked before it runs, swapped without a rebuild

• Scripts are fully checked before anything runs. A script with a syntax error is rejected up front and changes nothing on the device. A syntax error cannot leave the logic half-loaded.
• Behaviour changes by swapping a script. There is no firmware rebuild and no recompile, and no new image to qualify for a logic adjustment.

Teams who prefer to draw logic can use ByteHive Studio (developer preview), whose visual canvas and state-machine designer generate readable logic the runtime executes directly.

Persistence, logging, faults and recovery

Remote sites bring power cuts, unreliable links and nobody on hand to reboot things. ByteHive builds the answers into the runtime instead of leaving each application to reinvent them.

• Persistence. Persistent values such as setpoints, limits and configuration are restored at boot, so they survive a power cycle instead of reverting to defaults.
• Data logger. A built-in logger keeps a rolling five-minute window at 1 Hz, with optional CSV export to USB. That is enough to see what happened in the minutes before a fault, even with no network connection.
• Faults and events. Faults carry a severity and can be acknowledged, persistent faults are supported, and events are written to daily logs. The fault state people see is the same one the controller acts on.
• Self-healing watchdog. If a core service fails, the watchdog restarts the stack about five seconds later, without a site visit.
• Hot reconfiguration. Device polling and on-board I/O can be reconfigured without restarting the runtime.

The watchdog is a recovery mechanism, not a replacement for safe defaults. Field devices under ByteHive control should be configured to fall back to a safe state if their supervisory controller goes quiet for a few seconds.

Reliability engineering

Every other service depends on the data core, so it gets dedicated reliability testing.

8.47 billion

Operations in a soak test of the real-time data core, with zero failures

• Long soak testing. The real-time data core was run through 8.47 billion operations in a soak test, with zero failures. Long runs surface rare faults that short tests seldom reach.
• Mutation testing. The test suite is itself tested: faults are deliberately introduced into the code to confirm the tests catch them.
• Sanitizer builds. The core is also built and exercised with runtime error-detection instrumentation, which exposes memory and undefined-behaviour errors that ordinary test runs can pass over.

Testing reduces risk; it does not eliminate it. That is why the operational safeguards above, together with cryptographically signed A/B updates that roll back automatically when a health check fails (shipping in the Cortex-A76-class production appliance image), exist alongside the test programme rather than instead of it.

Open interfaces

A data model that only its vendor can reach is a lock-in mechanism. ByteHive exposes the same live model through documented interfaces, so the application layer you build on top stays yours.

• JSON web API. 32 documented endpoints covering variables, devices, commissioning, faults, history and users, with Admin, User and Viewer roles. Your data is reachable from day one; no custom API has to be written to get it out.
• C SDK. Two shared libraries with about 56 public functions, for native services that read, write and subscribe to the data model directly.
• Command-line tools. For bring-up and live debugging on a running device, without writing code.
• Modbus TCP server. Existing SCADA and energy management systems can read the values you choose to map, over a protocol they already speak.

The developer documentation publishes measured behaviour and documented limits, so integrators do not have to discover them in the field.

Roadmap

The following is in development or planned and is not part of the current release.

• MQTT. MQTT connectivity, so values in the data model can be exchanged with broker-based plant and enterprise systems alongside the existing web API, C SDK and Modbus TCP interfaces.

Summary

ByteHive's real-time data core gives every service on an edge device one live, typed view of the site. Nine data types and device instances describe real equipment; change-driven notifications let services react to changes instead of polling each other, so logic reacts when inputs change and idle sites stay idle; batch writes let a service update a group of values together.

On a Cortex-A76-class ARM64 gateway, reads take 8.4 µs (0.6 µs from a cached subscription), state machines react to a change in 63 µs median (129 µs maximum observed), and a PID step costs 19 µs. These are measurements, not bounds, and they leave ample headroom against the physical timescales of energy equipment.

Control logic runs on the model and is checked before it runs and swapped without a firmware rebuild. Persistence, logging, faults and a self-healing watchdog are built in, the real-time data core has passed an 8.47 billion-operation soak test with zero failures, and the data model is reachable through a documented web API, a C SDK and command-line tools.