We try to keep networks as small (node count) as possible, because CPU demand increases as the cube of # nodes.
Break the vehicle’s fluid systems into separate networks.
On the other hand, we can’t arbitrarily split fluid systems anywhere we want, because network-network interfaces can be unstable
Tightly-coupled interfaces are unstable.
User preference also comes into play
Documentation & vehicle subsystem diagrams imply a certain organization, and they’ll typically prefer the models to match
So there is a trade between small networks, stable interfaces, user expectations
Coupling & Stability
Separate fluid networks are interfaced together so they can flow between them.
The separate networks are in themselves stable because they’re solved as simultaneous systems
this is the main reason why we use simultaneous system solvers: for stability
But the 2 separate networks are not solved together as one system. Instead they handshake pressure & flow information between them across a data interface with lag. This introduces instability.
“Tightly-coupled”: System A has a large effect on B and vice-versa.
Relatively high flow rates between relatively small volumes:
volume (m3) / flow rate (m3/s) = (s), so you can think of the interface as having a time constant that relates to how fast the two networks equalize. Higher volume or lower flow rate increases the time and thus stability.
Example: a hatch between two cabin volumes. Hatches have large flow area and thus the cabin volumes are always at almost the exact same pressure. Any big pressure change to volume A causes a large flow and B instantly follows.
Tightly-coupled = BAD.
“Loosely-coupled”: System A has a small effect on B or vice-versa.
Low flow rates between two big volumes, or between one big & one small volume
Example: O2 supply valve to the cabin. O2 flows at a relatively slow rate and so causes small changes in cabin pressure
Loosely-coupled = GOOD.
Vehicle breakdown examples
ATCS:
All separate coolant loops as separate networks
Gas supply systems to gas-pressurized accumulators, if they’re simple and belong to a single loop, can be included in that loop’s network
Complicated gas supply systems that pressurize multiple loops should be a separate network
Loop-to-loop leaks should not be a consideration for combining two loops into one drawing — use external interfaces for that
never split a liquid loop into separate networks
ECLSS:
ARS/THC ventilation loops typically in same network as cabin because splitting across loops is a no-no
Combined cabins of multiple docked vehicles:
Small passive vehicles (crew transport to ISS) usually owned by one big “master” network (ISS stack), smaller networks slaved to the master via shadow links
Multiple active vehicles that can’t be slaved/shadowed require special interfaces similar to external supply/demand but with extra logic to enforce stability. TS-21’s ISS US segment <→ RST is an example
PCS typically separate network(s) from cabin. If O2 & N2 are separate w/ no x-over, they should be separate networks
waste water busses & storage systems typically separate
Regen systems typically in separate networks because they deal with low flow rates & loosely-coupled interfaces
Prop:
Fuel & Oxid sides typically together in one network because rocket links need to mix them in the combustion chamber
Ullage pressurization can be a separate network if its complicated but with a loosely-coupled interface in the tank supply