CoSimu Platform

Coupled-run visualizationSeveral domain models converge under a coordination layer, exchange state as the experiment advances, and carry a controlled intervention from one domain into another. The scene requires WebGL; the same sequence is described below.

State exchange Injected disturbance Injection point Clock sweep

How a coupled experiment is assembled

Each element of the arrangement is an experimental design decision, and together they determine what the resulting evidence is able to support.

Assembling and running one coupled experiment On the left, four participating models, comprising a power system, a communication network, control logic and a physical process, each publish a declared interface of state variables, measurements, setpoints and operational constraints. A vertical divider marks the point at which those interfaces are bound into one configuration. To the right, the four models advance as horizontal lanes through an orchestration region; vertical dashed lines mark the negotiated points at which state crosses the interfaces. A controlled intervention is applied on the communication lane, and a highlighted path shows the response passing into control logic and then into the physical process, where the consequence is recorded along the experiment timeline. PARTICIPATING MODELS ORCHESTRATED RUN TIME COORDINATION · STATE EXCHANGE INTERFACE BINDING Power system continuous dynamics Communication network discrete packet events Control logic scan cycle Physical process coupled process dynamics controlled intervention control responds physical consequence DECLARED INTERFACES state variables · measurements setpoints · operational constraints t t+Δ t+2Δ t+3Δ t+4Δ Between exchange points each model advances on its own step; at each exchange point, state crosses the declared interfaces.
One coupled run, with the exchange interval and the number of participating models set by the configuration.
Model representation and declared interfaces
Each participating model computes on its own terms: a power-system solver, a communication model, control logic, a representation of the physical process. Taking part requires a declaration of what can be read from it and written to it: state variables, measurements, setpoints, and the operational constraints that bound valid behavior.
Orchestration and time coordination
A selected subset of models is bound into a single configuration, and the coordination method is chosen to suit their time representations. Between exchange points each model advances on its own step; at the exchange point, values cross the declared interfaces. Which models participate, how they connect and how their advance is coordinated are experimental choices recorded with the run.
Controlled intervention and propagation
A scenario drawn from the security-analysis libraries is applied at a defined point with stated timing and magnitude, so that the same intervention can be repeated in a later run. The control system responds, the physical process moves, and the movement reaches the models coupled to it. That is behavior which becomes visible only once the domains are coupled.
Experimental observation
The run records the propagation path, the physical constraints that shaped the response, and what could be observed from each monitoring position as the disturbance developed. That record is what allows two configurations to be compared, and it carries the assumptions under which the comparison holds.

Architecture of the CoSimu environment

Twin kernels provide reusable representations of physical processes; security-analysis libraries provide reusable experimental and analytical methods; orchestration composes compatible components and coordinates their interaction; and the resulting experiment is recorded together with the assumptions under which it holds.

Twin kernels

A twin kernel is a reusable computational representation of a physical process, published in a form that other components can interact with.

A kernel computes the process it represents. It declares the dynamics it integrates, the state it holds, the parameters that configure it, the interfaces through which it can be read and written, and the operational constraints that bound valid behavior. Those declarations are what allow a security methodology written elsewhere to address the process at all.

Kernels differ in internal implementation and in modeling fidelity. An electromagnetic-transient representation and a phasor-domain representation of the same network answer different questions, and a method that is meaningful against one may need re-expressing against the other. Declaring an interface makes that difference explicit, so an experiment can state which representation its conclusion rests on. Electrical power systems provide the initial application context for CoSimu, with the first twin kernel being developed for a power-system process. The broader architecture is intended to accommodate additional process-specific kernels for compatible cyber-physical domains, including industrial and water infrastructure, each kernel retaining the dynamics, interfaces, assumptions and validation requirements of the process it represents. Beyond the initial focus on cyber-physical security, the architecture is intended to support investigations of fault propagation, control-system behavior and operational performance in compatible physical processes.

Security-analysis libraries

The libraries hold the experimental and analytical methods an investigation applies to a process, expressed against declared interfaces, independently of any one simulator.

Their intended scope covers attack scenarios, fault conditions, operational disturbances, physics-informed detection, moving target defense, security-evaluation procedures and resilience analysis. Expressing a method against an interface allows it to address a further system whose dynamics are compatible, and allows two systems to be studied with the same analytical approach.

Portability applies to the methodology. A detector tuned to voltage dynamics carries assumptions about timescale, sensitivity and observability that a hydraulic process does not satisfy, so applying it elsewhere is a research task with its own adaptation and validation. The libraries are structured to make those assumptions visible at the point where a method is bound to a kernel.

Orchestration and model coupling

Orchestration assembles a set of compatible components into a single experiment and coordinates their interaction while it runs.

It selects the participating models, binds their interfaces, transfers state between them, coordinates how they advance relative to one another, and applies interventions at defined points. The coordination method depends on the models involved: continuous solvers, discrete-event models and scan-based control logic represent time differently, and the approach chosen for a configuration is recorded as part of the experimental design.

Compatible interfaces allow models to be composed, and the validity of the resulting experiment also depends on their timescales, state representations and modeling assumptions. Determining when a composition supports a particular conclusion is an active research question.

Contextualized experimental evidence

A completed experiment produces a record of system behavior under specified conditions, together with the assumptions on which it rests.

The record should support four kinds of question: how the intervention propagated across interfaces; which physical constraints shaped the response; what a defender positioned at a given point could have observed; and how the behavior changes when the configuration is altered. Comparison between configurations is the mechanism through which a defensive measure is evaluated.

Each answer holds for the models used, at the fidelity used, under the coupling chosen, for the intervention as specified. A complete trace supports causal investigation within the experiment, and carrying a result to a physical installation calls for validation against that installation. Stating those conditions alongside a result is part of the method.

Development status

CoSimu is being developed around three initial components: the twin-kernel specification, the interface model used by security-analysis methods, and the orchestration layer that composes participating models. The first twin kernel is being developed for an electrical power-system context.

Further process-specific kernels, a wider set of security-analysis libraries, and larger coupled configurations form the architectural direction of the work. The FAQ page sets out that direction in more detail.

[email protected] [email protected]
Research FAQs Contact