Mobile agent condition monitoring: notes from the European Conference on Edge AI 2025

On 20 October 2025 I presented "Mobile agent condition monitoring" at the European Conference on EDGE AI Technologies and Applications (EEAI 2025) in Naples. This post is a written version of the idea behind the talk: what mobile agent condition monitoring means, why we think it suits assets that move and have no power, and where it is still open engineering work. It is not a report of results. Those belong in papers and project deliverables, not in a blog.

Where the talk sat in the programme

EEAI 2025 ran from 20 to 22 October 2025 at the Hotel San Francesco al Monte, above the city. Our talk closed session C01, "Multi-Agent Solutions at the Edge", on the Monday afternoon in the Antico Refettorio, chaired by Fabian Chersi (CEA-List) and Holger Schmidt (Infineon Technologies).

The session was a good fit because it was not really about one technology. The other talks covered UAV-based radar and camera fusion for terrain analysis (imec), a complementary AI pipeline for PCBA defect detection (Deeepsensing), agentic edge AI for a collaborative smart warehouse (VERSES and partners) and spiking neural networks for agile drone control (University of Bologna). What they had in common was a question we also ask: how do you split work between many small, constrained devices so that each one only does what it is good at?

The conference is closely tied to the European EdgeAI project, funded through the Key Digital Technologies Joint Undertaking and coordinated by SINTEF, in which we led the VCD4.3 freight-wagon demonstrator. Many of the problems in the talk come straight from that work.

What is mobile agent condition monitoring?

A mobile agent, in the classic distributed-systems sense, is software that is "not bound to the system on which it begins execution", as the Communications of the ACM article Seven good reasons for mobile agents puts it. It carries its code and state, moves to where the data is and does its work there. Two of the reasons given in that article are directly relevant to sensing: reduced network load, because large data sets are processed where they are stored, and asynchronous, autonomous execution, because the agent keeps working when the link to its origin is gone.

Mobile agent condition monitoring applies the same thinking to machines and vehicles. The agent is the evaluation logic on a small sensor attached to the asset. It runs locally, decides locally and builds up a condition record that belongs to that asset. The infrastructure only collects what the agent has already concluded.

In a conventional set-up the direction is reversed. A wired or wireless sensor streams raw signal to a gateway or server, and the decision is made there. That works well on a fixed machine with power and a network socket next to it. It works badly on a freight wagon that spends weeks away from any infrastructure.

Why moving, unpowered assets need a different architecture

Think about what a battery-powered wireless vibration sensor actually spends its energy on. Sampling the accelerometer is cheap. The expensive parts are running a processor long enough to compute spectra or run a neural network, and powering a radio to send the result. The abstract of our talk lists exactly these as the cost and power limits of battery-powered IoT sensors in edge AI.

On a wagon, three facts make this worse:

• There is no supply voltage on most freight wagons, so every joule comes from a battery or from harvesting.
• There is often no network, so a radio either fails to connect or has to retry, both of which cost energy.
• Most of the time nothing interesting happens; the useful information is concentrated in short events such as a wheel flat striking the rail or a bearing passing through a load change.

If you accept those facts, the design follows. The sensor should sleep, wake only when something happens, decide what it saw with as little computation as possible and store a small verdict. Communication should cost the sensor nothing, which is where passive read-out comes in.

The building blocks we described

The talk abstract describes "Condition Tags" built around these ideas, demonstrated on vibration monitoring. In plain terms, the chain looks like this:

1. Threshold wake-up. An analogue or very low-power comparator watches the vibration signal. Only when a threshold is crossed is a small ARM core woken.
2. Lightweight evaluation. The core avoids power-hungry steps such as a full FFT and large neural networks. It uses time-series analysis and a feature-based engine instead: peak values, crest factor, impact counts, envelope-like measures that can be computed sample by sample.
3. Neuromorphic classification. A pattern-matching classifier sorts the feature vector into known classes. Neuromorphic approaches suit this because they compare against stored patterns with very little arithmetic. We cover the principle in our post on neuromorphic computing for condition monitoring.
4. Condition record. The result is appended to a compact record on the tag. The abstract describes linking this record to a digital product passport, so the asset's condition history stays with the asset.
5. Passive read-out. The abstract describes passive communication, written there as VHF: the tag does not transmit on its own, it is read when it passes a reader. In the VCD4.3 demonstrator this is a passive UHF RFID link. We go into the physics of passive read-out for sensors without radio or batteries separately.

The important point is not any single block. It is that each block removes a reason for the sensor to be large, powered or connected.

Mobile agents compared with streaming sensors

The table also shows the price. A mobile agent throws most of the raw signal away. That is acceptable only if you trust the on-board evaluation, which means the models have to be developed and validated on rich data collected elsewhere, typically on a fully instrumented test set-up. Our approach to that validation work is in a separate post on avoiding shortcut learning in industrial models.

What stays hard

Several questions came up in our own preparation, and none of them is solved by an architecture diagram.

Threshold choice. A wake-up threshold that is too low wakes the core for every rail joint; too high and slow-developing faults never trigger it. In practice the threshold itself becomes a model parameter that has to be tuned per asset type and operating condition.

Model updates. An agent that lives on a wagon for years will see conditions its model never saw. Passive read-out is good for collecting records and much less suited to pushing new models. Any update scheme has to fit inside a very small energy and memory budget.

Trust in the verdict. When only a verdict leaves the sensor, the sensor must also report on its own health, otherwise a loose mounting or a damaged sensing element turns into a false fault record. ISO 17359, the general guideline for setting up condition monitoring programmes, is a good reference for that discipline. Recording each sensor's own signal health is the idea behind what we call cognitive sensors, and we describe the general practice in self-monitoring sensors.

Data ownership. A condition record that travels with the asset raises the question of who may read it: owner, operator, maintainer or wagon keeper. For connected products in the EU, the Data Act now frames part of that answer, which we discuss in who owns your machine data.

How this connects to our work

The talk drew on our demonstrator in the EdgeAI project, the VCD4.3 sensor: an energy-autonomous freight-wagon sensor powered by the vibration it monitors, read out over passive RFID, which grades wheel flats and bearing faults on board. The VCD4.3 runs a time-domain classifier on a standard STM32 microcontroller, which the EdgeAI project blog describes as neuromorphic because it is inspired by how biological neural systems process sensory information; it runs without any specialised neuromorphic hardware, and it writes its result into an RFID tag that is read out passively. Developed as demonstrator VCD4.3 in the EU EdgeAI project, the sensor is now built to order as one of our special sensors. The details are on our special sensors page and the rail industry page.

For fixed machines with power and a network, the same principle of processing data at the source appears in a different form: hubs and nodes that record and time-stamp every stream at the machine and compute signal statistics on the node. If you want to discuss either case, our events and talks page lists where we present next, and you can always contact us directly.