How to coordinate sensor state machines sharing a single RS‑485 Modbus interface?

[Giulio Dalla Vecchia]

Hi everyone,

I’d like your advice on an architectural issue.

I have 40 “sensors” connected over an RS‑485 bus.
For each sensor I have an orthogonal state machine inside a dedicated AO (let’s call it SensorManager).
I also have a separate AO responsible for managing the RS‑485 serial interface.

The problem:
Each of the 40 sensor state machines may need to send a Modbus request, which means they would post an event to the AO that handles the serial line. However, I cannot allow all 40 sensors to request Modbus communication simultaneously. That would overwhelm the communication AO and break the event memory pool.

My question:

• How would you manage this situation so that multiple sensors requesting Modbus communication don’t overload the serial-handling AO?
• Should I implement some kind of request queue?
• A scheduler inside the serial AO?
• Token-based access?
• A round‑robin cycle?
• Or should the SensorManager AO itself coordinate all Modbus accesses?

I’m open to architectural suggestions or patterns you’ve used in similar multi‑sensor RS‑485 setups.

Thanks in advance!

[Quantum Leaps]

Hi Giulio,
First, let me clarify that if your sensors can permanently overwhelm your communication bandwidth (RS-485 in your case), no software design is going to fix it. Unfortunately, even QP cannot pull off such magic.

Now, your problem seems to me two-fold. First, you worry about event pools, meaning that you have a buffering problem. Second, you think about coordinating the sensor components, which is a coordination problem.

Regarding coordination, your SensorManager seems to be the ideal candidate. It might coordinate Sensors by posting permissions to send to the Sensor components. This could be done similarly as in the DPP application (especially the dpp_comp example), where the Table AO grants permissions to eat to the Philo components. Of course, this might require some additional states in the Sensor state machines.

Regarding the buffering, I would just leverage the existing event pools for posting communication events from the Sensors to the SerialManager. If you think about it, the event pools already provide an advanced, concurrency-safe buffering that you can't do any better yourself. If you can tolerate occasional data loss from the Sensors, you can use the best-effort, fault-tolerant allocation and posting of events. Please see:

• Q_NEW_X()
• QACTIVE_POST_X().

--MMS

[Giulio Dalla Vecchia]

Hi,
thank you so much for the detailed explanation!

I have to say, I really liked the “dining philosophers” analogy — I hadn’t even thought about applying the DPP pattern to my scenario, but it actually makes perfect sense here!

Definitely a clever way to coordinate access to the shared resource.

Thanks a lot for the insight and for pointing me in the right direction! 🙌

Giulio