Architecture

OEDI-SI compiles a wiring diagram into a HELICS runner config and executes it. This page follows that pipeline through the code in oedisi.componentframework.system_configuration.

The build pipeline¶

Wiring diagram¶

A WiringDiagram is the whole system: a list of Component instances and a list of Links. Each component has a name, a type (which definition to use), and parameters; each link connects a source/source_port to a target/target_port. Validators enforce unique component names and that every link references real ports.

Compiling to a runner config¶

generate_runner_config() turns a wiring diagram plus a dictionary of component types into a RunnerConfig:

1. initialize_federates() instantiates each component as a ComponentType, checks that linked ports are compatible, and asks each component to write its input_mapping.json (which upstream port feeds each input).

2. Each component becomes a Federate — a directory, a name, a hostname, and an exec command string.

3. A broker federate is appended: helics_broker -f <n> --loglevel=warning, where n is the federate count.

The result serializes to system_runner.json, the file HELICS actually runs.

Executing¶

helics run --path=system_runner.json launches the broker and every federate. Each federate connects to the broker, registers its publications and subscriptions, and advances through simulated time together. The oedisi run command wraps this; see the CLI reference.

Single-container vs. multi-container¶

The pipeline above is the single-container path: every federate runs as a local process. In the multi-container path, generate_runner_config is replaced by generated Docker/Kubernetes artifacts, and federates coordinate over a REST contract instead of local processes — but the wiring diagram and data types are identical.

Where the UI fits¶

The web app’s backend calls this same machinery: it converts a saved template to a WiringDiagram, calls generate_runner_config(), and runs helics run. See How OEDI-SI works for the end-to-end view.