Software that keeps a site observing

01The edge runtime: the site's own operating layer

Every observing site runs software between its instruments and the world. The edge runtime reads each instrument, stamps the time, checks the value, stores it and forwards it with its context.

It also hosts local applications: quality checks, alarms, compression and, increasingly, models that interpret images or signals before anything leaves the site.

Telecom standards bodies have worked on the same idea for networks, standardising an open environment so that applications from different providers can run at the edge across multi-vendor platforms².

A field site asks for more than a data centre does. It runs on limited power, in heat and cold, often far from help, and it must restart cleanly after every outage without anyone on site.

The runtime is therefore built as a small set of supervised services, each restarted on failure, with a durable store underneath and nothing that depends on a distant service in order to start.

Good runtime design is mostly about what happens when things go wrong. A sensor that stops talking, a disk that fills or a clock that drifts should each produce a clear local state rather than a silent gap.

The same runtime should run on the small and the large: a single logger on a pole and a rack of computers at a busy port, with the same services and the same kind of records.

02Offline-first: store, decide, then forward

Offline-first means every record is written to local storage before any attempt to send it. The link is treated as a bonus that comes and goes, not as a condition for observing.

The internet community has studied this for networks that never have a stable end-to-end path. Delay-tolerant networking provides communication through environments with intermittent connectivity, long or variable delays and high error rates³.

Its bundle protocol forms a store, carry and forward overlay across the networks beneath it, which is the same pattern a field site follows with its own records³.

Local decisions matter as much as local storage. When a camera must raise an alarm or a gauge must trigger a warning, sending every frame to a distant cloud adds transfer time and a round trip.

The simulator shows the trade for one decision. Change the frame size, the uplink, the backhaul and the round trip, and compare the time to decide on site with the time through a cloud.

When the link returns, the site sends what it holds in order of importance and marks which values arrived late, so that users downstream can tell a delay from a gap.

03Fleet updates that cannot brick a site

Software in the field must change: to fix vulnerabilities, adjust configuration and add functions. A reliable and secure update mechanism is a basic requirement for connected devices, including those with very limited resources¹.

The IETF architecture for firmware updates separates the roles. A firmware server holds images, a manifest describes and protects each update, and a status tracker tells devices what is available and reports what they are running¹.

The manifest's information model sets out what a device needs to know before installing anything, including evidence that the update came from a trusted party and that no rollback to an older image is taking place⁴.

Repositories can be attacked too. The Update Framework is designed to keep update systems secure even against attackers who compromise the repository or signing keys⁵.

At a remote site the rollout itself needs care. Updates are staged from a mirror the operator controls, applied in a window the plan allows, checked after restart and rolled back automatically if the site stops reporting.

Fleets are updated in waves. A few sites take a release first, their health is watched, and only then does the rest of the fleet follow.

Configuration changes follow the same path as code. A new sampling rate or alarm threshold is described, signed and staged like any release, so the record shows when and why each site's behaviour changed.

04A secure supply chain, and signatures that last

An update is only as trustworthy as the process that built it. Few development life cycle models address software security in detail, so secure practices usually need to be added to each one⁶.

The Secure Software Development Framework is a core set of high-level practices that help producers reduce vulnerabilities in released software and address their root causes⁶.

Supply-chain levels add evidence about how each artefact was built, so that a site can check that the software it runs came from the expected source and process⁷.

Firmware below the operating system needs the same care. Platform firmware resiliency guidance describes how to protect it against unauthorised changes, detect changes that occur and recover rapidly and securely⁸.

Signatures in the field have long lives. A logger installed now may still be checking update signatures many years from now, so the signing scheme should be chosen with future attacks in mind.

ML-DSA, standardised in 2024, is a signature scheme believed to be secure even against an adversary with a large-scale quantum computer⁹.

Post-quantum keys and signatures are larger than classical ones. ML-KEM, a key-encapsulation mechanism published at the same time, joins ML-DSA in the simulator¹⁰.

Try a choice of key exchange and signature to see what it adds to a secure handshake, which matters on a thin satellite or radio link.

05Field apps for the people who keep sites running

Sites are installed, serviced and eventually removed by people. The apps they carry must work where the site works: on a hillside, in a vault or on a quay, often with no signal at all.

A field app is offline-first in the same way as the runtime. It downloads the work order, site plan and checklists before the visit, records everything locally, and synchronises when a link appears.

Commissioning is where the record of a site begins. The app captures photographs, serial numbers, mounting heights and test results, so that the site's description is evidence rather than memory.

The app also talks to the site directly. A technician standing at the rack can see the runtime's state, the clock, the queue and the last update, without depending on a distant service.

Every action in the app becomes part of the site's history. When a sensor is swapped or recalibrated, the change and the person who made it are recorded beside the data it affects.

Decommissioning uses the same app. The technician records what was removed, confirms that keys were wiped or returned, and exports the site's data before the last power is switched off.

06Observability: a site that reports on itself

An operator responsible for many remote sites cannot visit them to see how they are. Each site must describe its own health: power, temperature, storage, clock, links, software and every instrument.

OpenTelemetry is an open framework for generating, exporting and collecting traces, metrics and logs, and it is vendor and tool agnostic¹¹.

Telemetry should go only where the operator sends it, to collectors the operator has configured. A site should never phone home to a software maker unless the operator chooses that.

Health data is also evidence. A record of when the clock lost its reference or when the queue backed up explains later why some values carry lower quality.

Nexus Observatory Inc. designs site software around these principles, so that a site keeps observing on its own and reports honestly on its state.

The test of site software is simple. Years after installation, the site should still be measuring, still accepting signed updates and still able to explain every gap in its own record.