Skip to main content
Contact Nelix Partner with Nelix
Sector

Industrial Infrastructure

Condition monitoring on plant that will outlive several generations of compute

Architecture specified · RTL in progress · no Nelix silicon yet

industrial infrastructure context

Heat, dust and vibration rule out fans and filters
Heat, dust and vibration rule out fans and filters
THE CHALLENGE

The data is at the machine and the decision has to be defensible

Condition monitoring on pumps, compressors, gearboxes and switchgear is only useful if it acts before failure, and the vibration and thermal signatures that carry the early warning are produced faster than a plant network will carry them. So the analysis belongs at the asset. That means placing a compute device inside the OT boundary, where a control-system owner will ask what it runs, what it can reach, and how either claim is verified.

The environment is hostile in ordinary ways: ambient temperatures in a motor control centre or a kiln house, conducted noise on the supply, continuous vibration, and dust ingress that rules out fans and filters. Equipment life is measured in decades, and anything adjacent to a safety-instrumented function has to behave predictably when supply is lost rather than restarting into an unknown state.

LIMITATIONS

Why current compute does not serve it

The constraints are structural: placement, power, connectivity and service life, not missing features on a datasheet.

  1. Industrial PCs are datacentre parts in a painted cabinet

    General-purpose edge hardware assumes clean supply and forced-air cooling. In a plant it derates, needs filters, and becomes another maintenance item on a rounds sheet.

  2. The OT boundary is enforced by network placement alone

    A monitoring device is trusted because of the VLAN it sits on, not because of anything it can prove about the firmware it is currently running.

  3. Model provenance is lost in the field

    A predictive maintenance model pushed through a jump host leaves no evidence of which version produced a given recommendation, which matters most when the recommendation was to keep running.

  4. Supply dips discard in-flight state

    Compute designed to be shut down cleanly loses partial analysis on a voltage dip, so the window around a disturbance is the data most likely to be missing.

FPGA development board
FPGA development board
APPROACH

Analysis at the asset that carries its own evidence

SecureGrid is specified to sit close to the machine, with measurement inputs, tamper detection and an optional inference datapath inside one trust domain anchored by TrustCore. A current or vibration signature and the conclusion drawn from it share the same chain of custody instead of meeting across a board-level bus.

InferEdge runs the analysis as a completion transaction under an energy contract, committing progress at safe boundaries so a supply disturbance leaves a resumable state. Each exported result is accompanied by an attestation bundle binding the result digest to device identity, firmware measurement and model version, which gives a reliability engineer not only the recommendation but the configuration that produced it.

No silicon exists yet. The architecture is specified, RTL is in progress, and FPGA validation comes before any claim about how the design behaves in a plant; the power and format figures are design targets.

Specified, not measured. RTL in progress; FPGA next; no Nelix silicon yet.

While running Runtime verification
Continuous runtime verification A conceptual die floorplan for continuous measurement. An always-on measurement engine occupies the left of the die, with a four-phase cycle beneath it: sample, hash, extend, compare. To its right a recessive band shows workload activity in three lanes of uneven task footprints. A sample bus runs under the band and a comb of taps drops from it into a digest chain of linked cells, one per epoch, which the light extends from left to right. One epoch is flagged and re-measured. Beneath the chain the measured history stacks downward in rows that fade as they age, and the chain has no entry from its left end, so the record can only be extended and never rewound. Fresh evidence leaves through a port on the right edge. Operating die · power on Measure engine Always on Sampler Hash macro Every epoch not only at boot Sample Hash Extend Compare Workload activity L0 L1 L2 Sample bus Rolling digest E0 E1 E2 E3 E4 E5 E6 No rewind Re-measure Measured history E6 E5 E4 E3 Fresh quote Measurement continues for as long as the device runs
  • Measured epoch
  • Flagged for re-measure
  • Light = the digest being extended
Boot-time proof goes stale, so measurement continues while the device works and the evidence an operator asks for is always current.
Measurement and evidence path · design intent
POSITION

Where Nelix sits in this system

A signal and the conclusion drawn from it share one chain of custody instead of meeting across a board-level bus.

Analysis carried out at the asset
Analysis carried out at the asset
PATHWAY

From the asset signal to a recommendation that can be reviewed

Sense, analyse, attest and admit — so a maintenance decision carries its own evidence.

  1. Sense

    Capture the signal at the asset, inside one trust domain

  2. Analyse

    Run inference as a completion transaction under contract

  3. Attest

    Bind result, firmware and model version together

  4. Admit

    Let the plant workflow accept only verified recommendations

CAPABILITIES

The mechanisms that address them

Technical mechanisms in the specification. None of these figures have been characterised in silicon.

  1. Measurement and inference in one trust domain

    Sensor input is measured and attested where it is captured, so the analysis inherits the provenance of the signal rather than trusting an unprotected bus.

  2. Model version bound to every result

    An exported recommendation names the firmware and model that produced it, so an unapproved or withdrawn model can be rejected before it reaches a work order.

  3. Defined behaviour under supply disturbance

    Brownout moves execution to a lower clock profile through contract renegotiation rather than into an undefined state next to a safety function.

  4. Checkpointed capture around an event

    Progress committed at safe boundaries means the data from a trip or a dip survives the event that caused it.

  5. Convection-cooled thermal target

    A sub-15 W design target for inference is intended to allow sealed, fanless enclosures in dusty, hot and high-vibration locations.

  6. Signed update over an unreliable link

    Firmware and model updates are verified against signed manifests and can be queued for equipment only reachable during a planned outage.

OUTCOMES

What changes if the architecture delivers

Operational consequences stated as design intent, not as measured field results.

  1. Maintenance decisions that can be reviewed

    When a recommendation carries provenance, a decision to intervene or to defer can be reconstructed during an incident review.

  2. A basis other than network position for allowing a device

    Equipment that can attest its own firmware state gives a control-system owner evidence to assess, not just a segmentation diagram.

  3. Fewer separately maintained boxes in a panel

    Consolidating metrology, tamper detection and inference reduces the number of independently powered and independently updated units in an enclosure.

  4. Compute matched to plant life

    Cryptographic agility and cryptographic retirement are specified for devices expected to remain in service as long as the machine they monitor.

PRODUCTS

Platform layers involved

The product family this sector is specified against. Each page states programme stage honestly.

What we need from this sector now

Partnership

We would rather specify against real plant conditions than a datasheet abstraction of them, which means talking to reliability and control engineers while the RTL is still being written.

Partner with Nelix Contact the team
  • Failure-mode and condition-monitoring data from operating plant
  • Requirements from control-system and reliability engineering teams
  • Pilot installations for FPGA-based validation in real environments
  • Review of attestation against functional-safety and audit practice
SOLUTIONS

Other sectors