Device Management

Device Management is the control plane for every connected device the enterprise operates: sensors, controllers, gateways, telematics units, handheld terminals and embedded endpoints across vehicles, shop floors and field sites. It owns the full hardware lifecycle, from the moment a device is registered and provisioned, through configuration, firmware maintenance and health monitoring, to eventual retirement, and it does so at fleet scale across tens of thousands of endpoints.

Within Nashua 360 it is the hardware edge of the suite: the layer that keeps physical devices addressable, current, healthy and secure, and that streams their telemetry into the operational modules that act on it. Where other modules reason about vehicles, machines and assets as business objects, Device Management reasons about the silicon underneath them, the firmware they run and the network they speak over.

What the module does

Device Management maintains a single authoritative registry of every connected device, keyed on an immutable hardware identity and enriched with model, firmware version, network address, physical location, ownership and operational status. From that registry it runs the four disciplines that keep an estate of endpoints in service. Provisioning brings a device onto the platform with its credentials, certificates and baseline configuration applied before it reports for duty. Configuration management holds the desired settings for each device and continuously reconciles them against what the device actually reports, correcting drift without a site visit. Firmware and software maintenance curates versioned update packages, each with its changelog, dependencies, signature and validated rollback path, and delivers them over the air. Health monitoring ingests heartbeats, telemetry and error reports, so that a device falling silent, overheating or reporting faults is surfaced immediately rather than discovered on failure.

Around these disciplines the module provides grouping and tagging so devices can be addressed collectively by type, location, customer, firmware baseline or arbitrary label; staged over-the-air rollout with percentage-based and cohort targeting; and a full audit trail of every command, configuration change and update applied to every device. It is built to operate connected devices at scale, unattended, with human intervention reserved for the exceptions the platform raises.

The domain and data model

At the centre sits the device: a physical endpoint with a permanent hardware identity that persists no matter how many times its firmware, configuration or owner changes. Everything else in the domain hangs off that identity. A device carries a known model and generation, which determines what firmware it can run and what it can be asked to do, and it carries a live state: where it is, when it last spoke, what version it runs and whether it is healthy, degraded or unreachable.

The second organising idea is the update package. A package is a specific, versioned build of firmware or software, signed for authenticity, described by its changelog and constrained by the models and versions it is valid to install onto. Packages relate to devices through deployments, and a deployment records not a single event but the controlled journey of a package across a population: which devices are targeted, in what order and proportion, how each one fared and, crucially, the safe version to fall back to if a batch misbehaves.

The third idea is the device group, a dynamic or curated set that lets the enterprise reason about thousands of endpoints as a handful of meaningful cohorts, whether by customer, by site, by hardware type or by the firmware baseline they share. The final layer is the continuous stream of telemetry and health signals each device emits, the heartbeats, readings and error reports that give the registry its living, moment-to-moment picture rather than a static inventory. Together these concepts turn a scattered population of hardware into a coherent, queryable, governable estate.

The principal workflows

The onboarding workflow takes a device from its factory state to full production membership. It is registered against its hardware identity, matched to its model, issued credentials and certificates, assigned to the groups its role and location dictate, and given its baseline configuration, all before it is trusted to carry live traffic. From that point the day-to-day workflow is monitoring and reconciliation: the platform watches heartbeats and telemetry, compares reported configuration against desired configuration, and either corrects drift automatically or raises it for attention.

The most consequential workflow is over-the-air deployment. An operator selects an update package, chooses a target population by group or query, and defines a rollout profile: a small canary cohort first, then widening percentage bands, with health gates between stages. The platform advances the rollout only while the newly updated devices stay healthy, pauses or halts automatically if error rates rise, and executes the validated rollback for any device or batch that fails to come up cleanly. Alongside this sit the remote operations workflow, issuing configuration changes, reboots and diagnostic commands to a device or a whole group, and the retirement workflow, which decommissions a device, revokes its credentials and preserves its history for audit.

Register andprovisionConfigure andmonitorStage OTArolloutVerify orroll back
The lifecycle every connected device follows through the module, from onboarding to controlled over-the-air change.

Functional depth that matters

The depth of a device platform shows in how carefully it treats change and failure. Every update package is cryptographically signed and its signature verified on the device before installation, so an endpoint will only ever run authentic, authorised firmware. Deployments are staged by design: canary cohorts absorb risk first, health gates between bands require positive confirmation before the rollout widens, and any regression triggers an automatic pause. Because every package declares the version that preceded it, rollback is deterministic rather than best-effort, and a device that fails to boot or fails its post-update health check is returned to its last known-good state without manual recovery.

Configuration is managed as desired state, not as fire-and-forget commands: the platform holds what each device should look like and continuously reconciles reality against it, so a device that drifts, resets or is replaced converges back to policy on its own. Security runs throughout, with per-device credentials and certificates, encrypted transport, credential rotation and revocation, and a complete, tamper-evident audit trail of every command and change. Health monitoring applies configurable thresholds to heartbeat cadence, telemetry ranges and error frequency, distinguishing a device that is merely quiet from one that is genuinely failing, and it captures the diagnostic context needed to triage a fault rather than only signalling that one occurred.

How it fits the Nashua 360 suite

Device Management is the hardware substrate the rest of the suite stands on, and its telemetry is a first-class input to the operational modules. It feeds vehicle telematics directly into Fleet Management, so location, engine data, driver behaviour and utilisation reported by on-board units become the fleet's live operational picture, and so a firmware issue on a telematics unit is understood as a fleet data-quality issue rather than a mystery gap. It streams shop-floor device data into Manufacturing, keeping the controllers, scanners and terminals on the production line registered, current and monitored. It carries SCADA and IoT readings into Equipment and OEE, where the same signals that Device Management uses to judge a sensor's health become the raw material for availability, performance and quality calculations.

Beyond the operational feeds, the module registers devices as governed assets in Asset Management, so a physical endpoint has both a lifecycle in the field and a financial and maintenance record. Access to devices, groups and deployment actions is governed by the suite-wide permission model, so who may push firmware to which population is an authorisation decision, not a convention. The result is that hardware is not a blind spot at the edge of the enterprise but a fully modelled, fully governed part of the same operational graph as vehicles, machines and assets.

How AI Workers operate inside it

AI Workers are first-class operators inside Device Management, not a bolt-on assistant. Any authorised person can query the estate conversationally, asking which devices at a given site are running an outdated firmware baseline, which units have missed heartbeats in the last hour, or how a rollout is progressing, and receive a grounded answer drawn from the live registry. Workers also execute actions within their permitted scope: staging a deployment to a canary cohort, applying a configuration change to a group, or issuing a reboot to an unresponsive device, each carried out through the same governed pathways and audit trail as a human operator.

Their standing value is vigilance. Workers watch telemetry and deployment health continuously, detecting anomalies such as a temperature trend drifting out of range, a cohort whose error rate climbs mid-rollout, or a device silently diverging from its desired configuration, and they raise exceptions with the context needed to act. They extract and normalise the structured data buried in device error reports and diagnostic logs, turning noisy signals into clear findings, and they provide decision support before consequential change, summarising an update package's changelog, dependencies and blast radius so an operator approves with full sight of the risk. Where policy requires it, a Worker sits as a review or approval node in a deployment workflow, holding a wide firmware rollout at a health gate until its checks pass or escalating it to a human when they do not.