Simulink-style modeling and simulation plan
Proposed product features, not current capabilities. The request to add Simulink features is interpreted as a usable graphical model-based engineering environment, including execution and verification semantics. The core visual modeling workflow is part of the proposed v1, not an optional diagram viewer. The feature catalog sets overall priorities; this document specifies the model-runtime work in more detail.
Simulink provides a block-diagram modeling/simulation environment. Test harnesses and code generation also belong to separately documented MathWorks products, so the requested product direction spans more than a canvas. The Galata proposals below are an independently designed scope, not a claim of file, block, solver or numerical equivalence with the entire MathWorks ecosystem. Simulink, Simulink Test, Simulink Coder.
| ID | Capability to add | Proposed delivery boundary | Acceptance demonstration |
|---|---|---|---|
| S01 | Block canvas: search/palette, connect ports, select/group, undo/redo, copy/paste, align, keyboard navigation and hierarchy breadcrumbs | M2 / Must v1 | An engineer builds, saves, reopens and modifies the reference controller without editing YAML; undo restores semantic content exactly |
| S02 | Typed signal ports and model compiler: numeric/Boolean types, scalar/vector/matrix shapes, physical dimensions, coordinate frames, time domain and direct-feedthrough metadata | M1 contract, M2 compiler / Must v1 | Invalid units/shapes/frame/rate wiring is rejected at the originating blocks before numerical execution; explicit conversion blocks are inspectable |
| S03 | Core block library: constants, step/ramp/sine/table signals, sum/gain/product, matrix operations, comparators/switches, integrators, state-space systems, filtered PID, saturation, rate limits, delays, lookup tables, logging and scopes | M2 basic, M3 complete declared palette / Must v1 | Every block has an independent analytic/reference behavior test, invalid-input contract and documented supported types/rates |
| S04 | Reusable subsystems, named interfaces, parameter masks and referenced models with versioned library identity | M2–M3 / Must v1 | Two instances maintain independent states; a library update produces a reviewable semantic diff; missing or incompatible references fail clearly |
| S05 | Data dictionary, parameters with units/ranges, initial-state sets, model configurations and build-time variants | M2–M4 / Must v1 | Changing a parameter or variant creates a distinct model/run identity; parameter shadowing, unresolved names and incompatible variants are rejected |
| S06 | Continuous/discrete/multirate scheduling: sample-time propagation, explicit rate transitions, zero-order holds and clock inspection | M3 / Must v1 | Mixed-rate reference models have verified event order and outputs; undeclared cross-rate transfer is refused |
| S07 | Solver configuration: deterministic fixed-step continuous integration, discrete updates, state initialization, convergence studies and numeric event handling | M2 basic, M3 timing / Must v1 | Graph execution reproduces analytic systems and the equivalent CLI studies; halved steps show justified convergence; clock events occur at specified times |
| S08 | Algebraic-loop analysis with highlighted dependency cycles and direct-feedthrough explanations | M2 / Must v1 for detection | Unsupported algebraic loops fail before simulation; the editor never silently inserts a delay or changes the equations |
| S09 | Run/stop/pause/step, execution progress, complete-state checkpoints and controlled parameter tuning | M2 run controls, M4 checkpoint/tuning / Must v1 | Resume/replay restores continuous/discrete/actuator/controller/PRNG/event states; tuning events have exact simulation-time and revision records |
| S10 | Signal scopes, dashboard values, synchronized cursors, overlays, signal search, units, decimation and raw-data export | M2–M4 / Must v1 | Display decimation preserves relevant extrema and never replaces the underlying numerical records; plots link to run and block identities |
| S11 | Aircraft blockset: environment, rigid body, aerodynamic tables, propulsion, actuators, sensors, disturbances and sampled controllers | M3 / Must v1 for accepted fixed-wing scope | A reusable closed-loop aircraft model reproduces accepted reference scenarios and propagates validity/evidence to its outputs |
| S12 | Operating points, named linearization/loop-break points, subsystem transfer extraction and linked control-analysis views | M3 / Must v1 | Signal sign, units, sample time and retained states are explicit; graph linearization matches independent analytic references and retains chart/conditioning diagnostics |
| S13 | Model checks/advisor: unconnected required ports, invalid initialization, units, sample times, hidden domain violations, unsupported blocks and numerical evidence gaps | M2 basic, M4 acceptance checks / Must v1 | Each finding names a block or setting and a correction; passing syntax checks cannot appear as model validation or requirement acceptance |
| S14 | Test manager and isolated harnesses, scenario signals, numeric/temporal assertions, baseline/equivalence tests and requirement links | M4 / Must v1 | The same harness runs from desktop and CI; tolerances and reference origins are versioned; failures link to time/signals/blocks |
| S15 | Model differencing/review: semantic and graphical diffs, parameter/library/solver changes, run comparison and review annotations | M4 / Must v1 | Layout-only edits do not change numerical identity; semantic edits invalidate affected caches and require renewed evidence |
| S16 | Stateflow-style finite-state logic: states, guarded transitions, entry/exit actions and timers; later hierarchy, parallel regions and state coverage | Next, separate semantics gate | Transition priority, simultaneous events, reset and timer behavior have conformance tests; chatter/zero-time loops terminate diagnostically |
| S17 | Simulink interoperability: data/state-space exchange first; supported model-subset translation and FMI co-simulation later | M3 data exchange; Next model translation | An import report lists every supported, transformed and rejected construct; approved fixtures pass behavioral comparison with the original licensed environment |
| S18 | Restricted C/C++ controller generation, model-to-code traceability, desktop SIL, target PIL/HIL and deployment packaging | Next, separate code-generation program | Generated supported controllers match model behavior on independent harnesses; unsupported constructs fail generation; target acceptance is separate from desktop equivalence |
| S19 | Adaptive/stiff/implicit solvers and supported algebraic-loop solutions | Research before commitment | Stiffness, event location, convergence and failure cases pass independently established benchmarks; any determinism-policy change has an ADR |
| S20 | Fixed-point design, automatic scaling, accelerator backends, physical multiphysics networks, HDL/GPU targets and automatic formal test generation | Later product families | A funded user case, reviewed semantics and independent validation justify each separate addition |
The model compiler is a first-class subsystem. The present pipeline is a DAG of engineering operations. A signal-flow graph can contain feedback and dynamical state; it needs a different representation and compilation stage. Preserve that distinction:
- Parse the versioned model, parameters, library references and declared configurations.
- Resolve stable block/port IDs and model instances; preserve source hierarchy for traceability.
- Propagate/check types, dimensions, units, coordinate frames, sample times and initialization rules.
- Identify continuous states, discrete states, direct-feedthrough dependencies and strongly connected algebraic components.
- Reject unsupported equations/rates/blocks with specific diagnostics; build an explicit execution schedule for accepted models.
- Lower accepted blocks into an IR that calls the numerical kernels; record compiler/runtime/IR version and all solver settings.
- Execute the same compiled model from the desktop, CLI, harness runner and campaign worker; publish typed artifacts with the same evidence contract.
The block model format is canonical and diffable; canvas coordinates and presentation settings are stored separately from numerical identity. The architecture decision must specify how library updates, schema migrations, cached IR, parameter overrides and imported blocks affect identity. Generated IR is a rebuildable artifact, not the only copy of an engineer's model.
Timing semantics must be written before blocks are multiplied. The first supported hybrid profile uses an explicit base tick and validated commensurate discrete periods/offsets, with continuous substeps aligned to sample/event boundaries. Evaluate combinational outputs from a documented snapshot, then commit discrete state updates in a deterministic phase; define output/update ordering explicitly for every supported block. A discrete controller must not update at each RK substage. Noise generators draw on their declared clocks with independent recorded seeds, not according to incidental evaluator call count. Rate-transition blocks declare hold/interpolation and initial values. Unsupported clocks are rejected, not silently rounded. The discovery spike must compare multirate, zero-order-hold and simultaneous-event fixtures against an independent implementation. Sample-time concepts.
Every block declares whether outputs depend on current inputs and how state is initialized/reset. Pure direct-feedthrough cycles require an algebraic solution; graphical feedback through an integrator or unit delay has different semantics. V1 detects unsupported algebraic loops and explains them. A later solver may accept a declared equation class only with residual, convergence and failure checks. Adding a hidden delay to make a loop executable would change the engineering model and is forbidden. Simulink's own documented algebraic-loop handling involves numerical solution, underscoring why this is runtime work rather than drawing functionality. Algebraic-loop concepts.
The initial library has an explicit supported profile. Start with floating-point real signals, Boolean logic, named vector/bus interfaces, continuous linear/aircraft state and discrete controller state. Integer conversion and arithmetic require an overflow policy. Complex signals, variable-size arrays, arbitrary user scripting, recursive models, implicit physical networks and unrestricted native extensions need separate contracts. Each library entry exposes ports, parameter units/ranges, direct feedthrough, state, sample behavior, validity, provenance and independent verification evidence. A model that uses one unsupported block is rejected as a whole until the user makes a reviewed substitution.
Interactive tuning must remain replayable. Ordinary editing creates a new configuration for the next run. Live tuning is enabled only for parameters whose runtime semantics are declared, applied at a defined tick, and recorded as events. Structural edits require recompilation. Pausing is a presentation/control action; it must not change simulation time or numerical results. Checkpoints contain all state and runtime identity and are incompatible across unapproved model/runtime changes. Stopped, cancelled, crashed and complete runs remain distinguishable. A test harness should reproduce the same event history without UI interaction.
Interoperability has three different meanings. Data exchange exports/imports matrices, trajectories, parameters and operating points with explicit units and rates. Behavioral co-simulation exchanges signals with another simulator under a declared master clock and coupling scheme. Native model translation maps supported block semantics and must inventory losses. FMI defines Model Exchange, Co-Simulation and Scheduled Execution interfaces; choosing one does not establish numerical equivalence or solve the master algorithm. FMI specification.
Use documented APIs on an appropriately licensed MATLAB/Simulink installation to explore extracting a supported model subset; test selected versions and report unhandled scripts, callbacks, custom blocks, library links, data dictionaries, variants and state-machine constructs. The standalone Galata application should not require MATLAB for its native workflow. A translated diagram is accepted only after structural and behavioral comparison; visual similarity is insufficient. Avoid promising universal SLX compatibility or silently dropping unsupported constructs.
Code generation is a later, bounded compiler product. First target an explicitly supported sampled-controller subset, with defined numeric types, static state layout, initialization/reset and one-step semantics. Plant simulation and arbitrary third-party blocks are not implicitly eligible. Retain block-to-IR-to-code mapping, compiler flags, generated-source hashes and test results. Validate host software-in-the-loop equivalence first, then processor-specific behavior, timing/resource budgets and hardware interfaces under a named target contract. Code generation support does not establish flight-code approval. MathWorks documents C/C++ generation and test workflows separately, which is a useful reference for the separation of responsibilities. Coder documentation.
Implementation sequence. Establish S02/S06 semantics and independent fixtures during M1. Deliver S01/S03/S07/S08 with one continuous closed-loop model at M2. Add S04/S05/S06/S11/S12 with sampled aircraft-control studies at M3. Complete S09/S10/S13/S14/S15 and campaign integration at M4. M5 accepts the installed workflow and evidence. S16–S20 have their own discovery decisions, estimates and acceptance gates; they do not delay defining a complete, bounded first product.
The proposed executable-model architecture turns this capability plan into dependency boundaries, typed IR, solver and clock phases, artifact identity, replay contracts and a migration sequence. It is a design for review, not a claim that the graph runtime exists.