Hub-and-node architecture for industrial sensing

Short answer

A hub-and-node architecture splits a sensing system into one central hub, which records, time-stamps and presents data, and several nodes, each dedicated to one sensing function such as vibration, sound, vision or depth. We build one node per function because each physical quantity needs its own front end, short analogue paths and independent failure handling, and because functions can then be added or upgraded one at a time.

Key takeaways

In a hub-and-node architecture, each node digitises one kind of signal close to the sensor, and the hub handles recording, time-stamping and the operator view, and is designed to host models.
Keeping analogue paths short and digitising at the node protects small signals, such as accelerometer outputs, from noise picked up along long cables.
Each physical quantity needs a different front end: an 18-bit converter at 200 kSPS for vibration is a different design from a camera interface.
Separate nodes contain failures: a faulty sensor affects one node's stream, not the whole system.
The main cost is that every node has its own clock, so offsets have to be measured and recorded rather than assumed away.

The hub-and-node architecture is the structural decision behind all of our sensing hardware. Instead of building one box with every sensor wired into it, we build a central hub and a family of nodes, one per sensing function. This article explains why, what we gain and what it costs.

It is written for engineers who are designing or buying multimodal sensing systems and want to understand the reasoning, not just the product list.

What a hub-and-node architecture is

A hub-and-node architecture is a system layout in which a central unit (the hub) coordinates several peripheral units (the nodes). In our case:

A node is dedicated to one sensing function. It contains the sensor, the analogue front end where needed, the converter and enough processing to package and send the data.
The hub receives data from its own sensors and from the nodes, time-stamps every stream, records it and presents it to operators over the local network.

The idea is not new. ISO 13374-1 gives general guidelines for software specifications covering the data processing, communication and presentation of machine condition monitoring and diagnostic information. A hub-and-node design maps those functions onto hardware.

Why one node per function

Keep analogue paths short

Small analogue signals do not travel well. An accelerometer output a few metres away from its converter picks up interference from drives, motors and switching power supplies along the way. Digitising at the node, right next to the sensor, means only digital data travels the long distance to the hub.

Match each front end to its physics

Each modality needs a different acquisition chain, and compromises show up in the data. Our Vibration Node pairs an ADI ADXL1002 MEMS accelerometer (+/-50 g, 3 dB bandwidth up to 11 kHz) with an LTC6373 programmable-gain instrumentation amplifier, whose gain can be set in steps from 0.25 to 16, and an ADAQ4003 18-bit converter module, which we run at 200 kSPS on a single channel. The Acoustic Node uses a Microtech Gefell MK 301 E measurement capsule with a 2 to 100 kHz capture band, production-proven from 2 to 20 kHz. A camera node, by contrast, needs a sensor interface, exposure control and image buffering. Putting all of this on one board means designing for the worst case of every function at once.

Contain failures

When a node fails, it fails alone. A broken accelerometer cable or a dirty camera window affects one stream, and because our sensors report their signal health and dropouts, a dead channel is flagged on that node instead of bringing the system down. Our article on why single-sensor monitoring misses faults explains why one channel on its own can mislead.

Add and upgrade one function at a time

Machines and questions change. A customer may start with vision and thermal, then add vibration a year later when a bearing problem appears. With one node per function, that is an extra node, not a new system. It also means a better sensor for one function, for example a different camera sensor built to order, does not require redesigning the rest.

Place each sensor where its physics is

A microphone belongs a short distance from the noise source, an accelerometer on the bearing housing, a camera where it has line of sight and a depth sensor above the fill level. Separate nodes can each go where they measure best, rather than where a single enclosure happens to fit.

What the hub does

The hub is where data from all nodes comes together. On our Edge AI Hub, which runs on a RUBIK Pi 3 with a Qualcomm QCS6490, its jobs are:

Time-stamping. Every stream is time-stamped on the hub, and each node's clock offset is measured continuously and written into every record, with its uncertainty.
Recording. Data is stored on NVMe with a versioned manifest, per-segment SHA-256 hashes, an append-only journal and tiered retention.
Models (designed to host). Custom models are trained by our engineers on customer data; on-device inference as ONNX on the CPU was first proven on our Vibration Node, and NPU deployment is coming soon.
Presentation. An operator dashboard on the hub shows live status, previews, alerts, events and a vibration view over the local network.
Export. Recordings export to NWB, MKV/HEVC, JSONL and CSV.

The hub also carries its own sensors. The Multi-Camera configuration has three global-shutter cameras, a radiometric thermal core and a USB microphone on board, because those functions share a mounting position often enough to justify it.

Trade-offs we accept

No architecture is free. These are the costs of one node per function, and how we deal with them.

More clocks. Every node has its own oscillator. Rather than pretend otherwise, we measure each node's offset continuously and write it into every record with its uncertainty, so analysis can account for it. A hardware sync timer is in development with LarsLabs. The general problem is described in our article on time-stamping multimodal sensor data.
More devices to install. Several small nodes mean more mounting points and more cables or radio links than one box. For many machines, that is offset by placing each sensor where it measures best.
Wired versus wireless. The Vibration Node is available wired or over Wi-Fi. Wired links are more predictable; Wi-Fi saves cabling on moving or hard-to-reach equipment. The choice is made per installation.
Link bandwidth. As an illustrative calculation, one vibration channel at 200 kSPS and 18 bits per sample amounts to 3.6 Mbit/s before packing overhead, or 6.4 Mbit/s if each sample travels in a 32-bit word, which a wired link or a decent Wi-Fi connection carries comfortably. Raw video from a global-shutter camera is orders of magnitude more, which is one reason why cameras connect over wired camera interfaces rather than streaming raw frames over radio.
Power. Each node needs power, either from the cable or locally. For places without either, we build special sensors, such as the energy-autonomous VCD4.3 for freight wagons.

Monolithic versus hub-and-node: a comparison

Aspect	Monolithic sensing box	Hub-and-node architecture
Analogue cable length	Often long, from sensor to central box	Short, digitised at the node
Front-end design	One compromise board for all sensors	Front end matched to each physical quantity
Failure impact	One fault can affect the whole box	Contained to one node
Adding a function	Often requires a new box	Add a node
Sensor placement	Limited by enclosure position	Each sensor where its physics is
Clocks	Fewer clocks, but long signal paths	A clock in every node, offsets measured and recorded
Installation effort	One enclosure	Several smaller devices

The comparison is not one-sided. For a single camera on a fixed station, a compact, self-contained device is perfectly sensible, which is why our hub carries cameras itself. The hub-and-node approach pays off as soon as several physically different measurements are needed at different points on a machine.

How NeuroControls applies the architecture

The current node family follows the one-function rule:

Vision Node with an OmniVision OV9281 global-shutter sensor (Available); other sensors such as the Sony IMX900 are built to order.
Vibration Node with ADXL1002, LTC6373 and ADAQ4003 at 18 bits and 200 kSPS, wired or Wi-Fi (Available).
Acoustic Node with a Microtech Gefell MK 301 E measurement capsule and a 2 to 100 kHz capture band, production-proven from 2 to 20 kHz; available as a standalone logger and built to order as a hub node.
Depth Node with an ST VL53L9CX direct time-of-flight sensor (Available).
Event Node with an event camera chosen per order (Built to order).
Wireless Node based on an Espressif ESP32-S3 with an IMU (Built to order).

More detail is on our architecture page, the Edge AI Hub page and the page on cognitive sensors. For what the hub's QCS6490 can do, see our article on edge AI hardware for sensing.

Frequently asked questions

What is a hub-and-node architecture in industrial sensing?

It is a layout in which a central hub coordinates several sensor nodes. Each node handles one sensing function, such as vibration, sound, vision or depth, and digitises its signal close to the sensor. The hub time-stamps and records all streams and presents them to operators. The approach maps the data processing, communication and presentation functions covered by ISO 13374-1 onto hardware.

Why digitise sensor signals at the node instead of at a central unit?

Small analogue signals pick up interference from motors, drives and power electronics when they travel along long cables. Digitising next to the sensor means only digital data travels the long distance, which protects signal quality. It also allows each node to have a front end, gain stage and converter designed for its specific physical quantity rather than a compromise for all.

Is a hub-and-node system harder to install than a single sensing box?

It involves more devices, so there are more mounting points and connections. In return, each sensor can be placed where it measures best, such as an accelerometer on the bearing housing and a camera with line of sight to the process. For a single fixed camera, a self-contained device is simpler; for several modalities spread over a machine, separate nodes are usually the better fit.

How are node clocks handled in a hub-and-node architecture?

Each node has its own oscillator, so its clock has an offset to the hub that changes over time. In our system, every stream is time-stamped on the hub, and each node's clock offset is measured continuously and written into every record, with its uncertainty. That lets analysis account for offsets rather than assume they are zero.

Can nodes connect wirelessly?

Some can. Our Vibration Node is available wired or over Wi-Fi, and a Wireless Node based on the ESP32-S3 with an IMU is built to order. Wired connections are more predictable, while wireless links save cabling on moving or hard-to-reach equipment. The choice depends on the machine, the data rate and the installation.

Why we build one node per function: the hub-and-node architecture