srvo

Design it so you can scale by adding boxes: modular process systems

Modular process system design: split gas, water and thermal equipment into supply, process, exhaust and control units so capacity grows by adding modules.

October 20, 2026 · srvo engineeringdraft — not published

Build process equipment (anything that moves, mixes, heats, cools or vents a fluid) as one integrated assembly, and it works until you need twice the throughput, a second test bed, or a change to one stage. Then the integrated design scales by redesign.

The alternative is to split the system into units with standard interfaces, so capacity grows by adding units. The process industry’s standards point the same way: ISA describes its ISA-88 batch-control standards as helping organizations “implement modular designs that scale with production needs”. Here is how the idea played out on two systems we built.

An industrial gas router

A food-grade R&D facility needed to store, distribute, mix, analyze and dispose of industrial gases safely. We split the system into hot-swappable modules: a Control Hub plus Supply, Refrigeration and Exhaust units.

  • The Supply Unit compresses four industrial gases into custom mains plumbing that feeds ten refrigerated mixing chambers.
  • Firmware-defined barostats regulate gauge pressure in the mains and partial pressures in each chamber.
  • Embedded controllers in the chambers stream video and sensor data over Ethernet, MQTT and CAN to a Node-RED application server.
  • A central Exhaust Unit with two holding tanks vents the mains and chambers to the building exterior.
  • Safety algorithms detect leaks in real time while actuating more than 50 valves across the system.

Throughput scales by installing additional Supply, Refrigeration and Exhaust units.

A desalination test bed

A desalination R&D program needed to compare two technologies on equal terms. A Supply Unit distributes hot water, chilled water and saltwater through plumbing mains to a pair of test beds on shared HVAC infrastructure: heat-pump vacuum distillation, with mechanical vapor recompression as the control group. A Control Unit logs data to a Node-RED application server. An Exhaust Unit with vacuum pumps and accumulator tanks generates vacuum and collects brine and condensate for analysis and closed-loop recycling.

Shared utilities are what make the comparison fair. Both test beds draw from the same supply and dump to the same exhaust, so a difference in the result points at the technology rather than the plumbing.

The pattern

ModuleIts jobIts interfaces
SupplyStore, condition and distribute inputsMains plumbing, power, a data link to control
ProcessDo the work: mix, separate, testMains in, exhaust out, sensors and actuators on the bus
ExhaustRemove, hold and dispose of outputs safelyExhaust mains, the building interface
ControlOwn state, safety logic, logging and the dashboardEvery module’s data link

Five rules we follow

  1. Split by function, not by part. Supply, process, exhaust and control change for different reasons and at different rates. Keep them in different boxes.
  2. Define interfaces before internals. Fix the plumbing connections, power and message formats first; then each unit can be designed, built and replaced on its own. MQTT, an OASIS-standard, lightweight publish/subscribe protocol, suits this well, because a new unit can publish and subscribe without the others changing.
  3. Keep one control plane. On the gas router, a web dashboard exposes every API endpoint, parameter, data stream, event log and safety alert, plus tuning, automations and access control. One place to see the whole system is what makes adding a module routine instead of risky.
  4. Make safety a system property. Real-time leak detection across every valve, and a dedicated exhaust unit, are system-level functions. Don’t leave each module to reinvent them.
  5. Make modules describe themselves. NAMUR and ZVEI specify the Module Type Package, a vendor-neutral description of a module’s automation functions that lets a plant integrate the module with little effort and generate its operator screens automatically. Even if you never adopt it, give every module a machine-readable list of its signals, services and safety states.

Spend the analysis where it scales

Modularity is not free. It costs connectors, enclosures and some duplicated hardware. It pays back when you put the engineering effort where the money is. On the desalinator, third-party, peer-reviewed analytical models sized the heat-exchanger capacities, and third-party Simulink models set the specifications for high-cost components, reducing costs. Size the expensive module carefully once, and every copy you add inherits that decision.

What to do this week

  1. Draw your system as boxes and pipes, and circle every connection that crosses a box boundary. Those circles are your interfaces.
  2. Write the message list for each box: what it publishes, what it subscribes to, and what its safe state is.
  3. Ask what doubling throughput would take. If the answer is a redesign, change the architecture until the answer is “another unit”.

If you want a second pair of eyes on a process system architecture, send us a brief.

Ask an engineer