When system-designers design a solution, they care about the complete solution.

In automation, that would be the whole machine.
The design tool would hold the model of the whole machine, and all its modules.
The design tool would need to model the interfaces to other external systems.

Only then you can do simulation of the system and verify its functionality.

If we consider the carrier board the "system", then only systems  small enough to be driven by all interfaces fitting on one
carrier board would be designed and programmed. this is near to useless.,

Design software like https://www.br-automation.com/en/products/software/automation-studio/  models the whole machine.

I think so must we.


This means that we can have several carrier boards carrying interface boards, and those carrier boards need to communicate to each other.

Those communication channels between two carrier board will very likely be attached to a Cruvi connector on each carrier board. Those 
carrier2carrier connections might vary in speed and latency, as the media used might vary. But we should think about this usecase. Especially about time and clock syncing.

One main point of Cruvi should be "easy of use" for building systems.

If we want to build big systems, then multiclocking becomes an issue.