Edge-to-cloud architecture & security: the site decides, the cloud observes

The edge-first principle

An energy site is a physical system with physical consequences. Inverters, battery systems and generators act on commands quickly, and dispatch decisions depend on readings taken moments earlier. The wide-area link that connects a site to the cloud is the least dependable part of that chain: cellular coverage fades, site networks get reconfigured, upstream services have outages. ByteHive is designed around that reality.

The rule is simple: the cloud observes, the site decides. Control logic (scripts, state machines, PID loops, device setpoints) runs on the edge runtime at the site. The cloud receives telemetry, presents it to the people responsible for the fleet, and delivers software that the site owner approves. It is not part of any control loop, so a dropped link or a cloud-side incident does not stop the site's control logic.

One boundary is fixed by design: safety-critical commands are never cloud-writable. They can only be issued at the site.

Why this matters on an energy site

• Availability. The site's behaviour does not depend on a wide-area link it cannot control.
• Latency. Decisions are made where the measurements are, without a round trip to a data centre.
• Accountability. The party responsible for a site's safety keeps authority over what can change it.
• Exposure. The most consequential commands cannot be written from the cloud.

The trade-off is real: today, an operator cannot adjust a site's setpoints or control logic from the fleet portal. Setpoints and control logic are changed at the site; software delivered from the cloud installs only after the site owner approves it. The Roadmap describes what is planned in this area.

Telemetry you can trust

Warranty claims, performance reviews and capacity planning are only as good as the data underneath them. Edge telemetry tends to fail quietly: readings are lost when a link drops, or duplicated when a sender retries. Both produce numbers that look plausible and are wrong.

7 days

default store-and-forward window at the edge while the cloud link is down; configurable

Every zoom

history views in the fleet portal keep minimum and maximum, so short spikes stay visible

Per variable

reporting: every interval, periodically, or only on change

Delivered at least once, counted once

Telemetry is delivered at least once: a reading is not given up on because a single transmission failed. Retries inevitably create duplicates, so the cloud de-duplicates what it receives. Together, these mean retries do not inflate the record, and missing data is flagged rather than hidden.

Gaps are detected, not papered over

When data is missing, ByteHive detects the gap instead of smoothing over it. Missing intervals are identified as missing rather than being mistaken for idle time.

Store-and-forward: 7 days by default, configurable

When the link drops, the edge keeps recording and holds the telemetry, forwarding it when connectivity returns. The window is 7 days by default and is configurable, within the storage allocated on the gateway. A weekend outage at a remote site, a modem that needs a technician visit, or a firewall change that blocks outbound traffic becomes a delay in the history rather than a hole in it. The window is still finite; size it for your sites, and plan to resolve connectivity problems within it.

Per-variable reporting modes

Not every value deserves the same treatment. Each variable can be reported every interval, periodically, or on change. Fast-moving power and state-of-charge readings can go every interval; slowly changing values such as configuration or operating mode can be sent only when they change. On metered cellular links, where every byte costs money, the integrator chooses the trade-off between fidelity and bandwidth variable by variable instead of accepting one global rate.

The fleet portal

The fleet portal is built around the questions an operations team asks every day. Each view maps to one of them.

Why minimum and maximum are preserved

On a long view, each pixel stands for many hours of readings. If those hours are simply averaged, a brief power spike or a sharp state-of-charge dip disappears from the chart. ByteHive preserves the minimum and maximum at every zoom level, so spikes stay visible however far you zoom out. In practice that means you can zoom out to find an event, then zoom in to examine it, without needing to know in advance when it happened.

Long-term history lets you compare a site's recent behaviour with earlier periods, which is usually the first question asked when a site's yield or battery behaviour looks unusual.

Growing the fleet: new device types and new gateways

New device types need no cloud schema change

Energy sites are heterogeneous. Inverters, batteries and meters come from many manufacturers, and integrators add new models all the time. On platforms whose cloud data model is tied to specific device types, supporting a new one can mean a cloud release: a schema change, a migration, and coordination between edge and cloud teams.

In ByteHive, new device types need no cloud schema change. On the edge, devices are described by register maps, which are configuration rather than code, and commissioned from the web UI. Integrating a new device model is therefore a site-side task that needs no cloud release.

Claim a gateway with an email link

Claiming starts on the gateway itself. From its own web interface, the installer requests a claim and completes it through a link sent by email.

Signed A/B updates

Updating devices in the field is the riskiest routine operation a fleet performs. A failed update on a server is an inconvenience; on a gateway at a remote site it can mean a truck roll. Each property of ByteHive's update system addresses a specific, familiar failure.

Bring your own signing keys

Companies that build on ByteHive own their application layer, and the update system follows the same principle: customers generate their own update-signing key-ring, so the authority to release software for their product rests with them.

Validated on hardware

The full update path (signing, installation to the inactive slot, health-gated commit and rollback) has been validated end-to-end on hardware using the Cortex-A76 reference image. That is the target on which signed A/B updates ship today. On Cortex-A53 class hardware, ByteHive ships today as a binary package.

Device identity and the cloud link

Each unit generates its own key during factory provisioning, and the private key never leaves the unit. The unit and the cloud authenticate each other with mutual TLS.

• Per-unit identity. Every unit has its own key, so a credential taken from one unit cannot be used to impersonate another.
• The private key stays on the unit. It is generated there and never exported, so no copy of it exists outside the device.
• Attributable data. The cloud knows exactly which unit is reporting, so telemetry and events are tied to a specific device.
• Authentic endpoint. The unit verifies that it is talking to the genuine service, not an impersonator on the network path.

Security at the site

The local web interface is what installers, technicians and operators use at the site, and it deserves the same protection as the cloud link.

• HTTPS with TLS 1.2/1.3. Credentials and commands are not sent in clear text across the site network.
• Salted, iterated password hashing. Stored passwords resist offline guessing if storage is ever copied off a unit.
• Login lockout. Repeated failed attempts trigger a lockout instead of being allowed indefinitely.
• Forced change of the default admin password. The default administrator must set a new password at first login, so a unit does not stay on its factory password once someone has signed in.
• Roles: Admin, User and Viewer. People get the access their job requires, and visibility can be granted without the ability to change the site.
• Device-bound, encrypted Wi-Fi credentials. Network credentials are stored encrypted and bound to the unit that holds them.

How we check our own work

The web API has been through an internal white-box security review, conducted with full access to the source. The issues it identified were remediated and re-tested. This was an internal review, and we describe it as one.

Release builds fail on any high or critical dependency advisory, so a dependency with a known high or critical advisory cannot reach a release unnoticed.

Targets and delivery

Release builds are reproducible and published with SHA-256 checksums, and ARM64 binaries are load-verified in continuous integration. Reproducibility means a release can be rebuilt from source and checked against its SHA-256 checksums.

Roadmap

Everything in this section is in development or planned. None of it is part of the shipping product today.

Cloud

• Fully configurable ByteHive Cloud. Views, history and retention set to each deployment’s needs.
• Remote setpoints, gated by the site. The site keeps the final say over whether remote changes are accepted. The edge-first principle does not change, and safety-critical commands remain outside the cloud's reach.
• Alarm notifications so that faults reach the right people without anyone watching the portal.
• Team and organisation management for fleets operated by several people or companies.

Security

• Hardware-rooted boot integrity with a read-only root filesystem, extending the chain of trust from update installation to every boot.

Hardware

• An additional industrial-grade ARM64 processor target.
• Full appliance image and signed A/B updates on Cortex-A53 class hardware, bringing it to parity with the Cortex-A76 target.

Summary

ByteHive splits responsibility between the edge and the cloud along the line that energy sites need: authority stays where the equipment and its risks are, and visibility goes to the people who run the fleet.

• Edge-first control. The cloud observes and the site decides. Safety-critical commands are never cloud-writable.
• Reliable telemetry. At-least-once delivery with de-duplication and gap detection, store-and-forward at the edge (7 days by default, configurable), and reporting modes chosen per variable.
• A fleet portal for real questions. Live KPIs, power flow, inventory, faults and events, and history with spikes preserved at every zoom.
• Low-friction growth. New device types need no cloud schema change, and gateways are claimed with an email link from their own interface.
• Safe updates. On the Cortex-A76 appliance image: signed, product-bound A/B updates with a health-gated commit, automatic rollback, owner approval and your own signing keys.
• Security stated plainly. Per-device keys that never leave the unit, mutual TLS, a hardened local interface, an internal review and a dependency-advisory build gate.

Where something is not yet shipping, it is listed in the Roadmap and nowhere else.