Using gRPC for (local) inter-process communication
Using a full-featured RPC framework for IPC seems like overkill when the processes run on the same machine. However, if your project anyway exposes RPCs for public APIs or would benefit from a schema-based serialisation layer it makes sense to use only one tool that combines these—also for IPC.
Each bright box corresponds to a software process running on the DAQ server. The middle row are those processes that directly talk to the camera hardware via Ethernet using their hardware-specific protocols. Each of these control & monitoring processes expose a small set of functions that other processes may call to change or monitor the state. The two processes in the lower row are somewhat special: they do not connect to any hardware, but rather act as independent connectors between subsystems to run control loops. “Thermal” monitors the subsystem temperatures and adjusts cooling and ventilation parameters to stabilise the camera; “PDP-Readout-Connector” monitors pixel health, deactivates the trigger contribution of tripped or broken pixels and reactivates the trigger contribution of recovered pixels.This way the corresponding logic resides in a single, well-scoped subsystem and the Readout and PDP subsystems do not need to know anything about each other.
The “State Supervisor” orchestrates these subsystems and exposes an abstraction of the camera functionality via an RPC interface—essentially as a small set of states to hide the details of the hardware subsystems. The State Supervisor acts as the sole entry point for external control & monitoring; only a camera expert may control the subsystems individually in engineering mode.
