How OEDI-SI works

OEDI-SI turns a wiring diagram — a set of components and the links between their ports — into a running HELICS co-simulation. Understanding four concepts is enough to use everything else in these docs.

Core concepts¶

Component

A self-contained simulator or algorithm (a feeder, state estimator, recorder, …). Each component declares its interface in a component_definition.json file: its configuration (static_inputs) and the typed ports it subscribes to (dynamic_inputs) and publishes (dynamic_outputs).

Wiring diagram

The whole system: a list of component instances plus links that connect one component’s output port to another’s input port. In code this is the WiringDiagram model in oedisi.componentframework.system_configuration.

Runner config

The compiled artifact (system_runner.json) that HELICS actually executes. OEDI-SI produces it from a wiring diagram with generate_runner_config().

Broker

The HELICS process that coordinates time and message passing between all federates.

From UI to simulation¶

The web app is a friendly front-end over exactly this pipeline. A saved template (Vue Flow nodes + edges) is converted to a wiring diagram, compiled to a runner config, and launched with helics run.

The run lifecycle¶

Where each piece lives¶

Ready to see it in action? Start with the quickstart or the UI tour. Want the internals? Jump to Architecture.