control-edge/cppmodel

Generate or extend a CI pipeline - GitHub Actions, GitLab CI, Bitbucket Pipelines, or Gitea Actions - that builds a CppModel project and runs its simulations/tests, asking which provider, platform(s), and compiler(s) (among those CppModel actually publishes a prebuilt SDK for) to target. Use when asked to set up, add, or fix CI for a project using the CppModel libraries.

Offer and apply a coding standard - MISRA C or MISRA C++, or another one the customer names - when writing or changing controller (production/embedded) code, using the customer's own licensed copy of the rules rather than general knowledge, and remembering the choice per project. Use whenever controller code is written or modified - decoupling a component (cppmodel:decouple-component), fixing or re-tuning a controller found failing in simulation (cppmodel:simulation-testing, cppmodel:verification, cppmodel:experiment-reconcile), or writing new control logic - and when asked about MISRA compliance of controller code. Not for simulation-only code (plant models, simulation harnesses).

Decouple a vendor-coupled controller component (one that calls a vendor BSW/RTOS/HAL API directly) so it can run in isolation under CppModel, without the real hardware, RTOS, or vendor SDK. Use when a customer wants to add simulation coverage for existing embedded controller code that isn't simulate-able yet.

Write or update a concise Markdown document describing a CppModel plant model and the controller it exercises - signal interface, plant behaviour as per-cycle update laws (TeX math), parameters and timing, the controller's states and transitions, the closed loop, the simplifications made and why, and how it is validated. Starts as a draft from the user's own initial description before any code exists, stays untouched while the solution changes, and is reshaped to match the code once the plant and controller are settled. Use when asked to document a plant model, a controller, or a simulation, at the start of cppmodel:plant-model or cppmodel:decouple-component (to collect the initial description), and when a solution is settled or a refinement is promoted.

Design a field data-collection plan for a real machine - an experiment tailored to that machine and concentrated on the behaviour the plant model is least sure of, where every run carries the trace the current model predicts. The predictions come from a "planned" CppModel simulation kept apart from the production simulations until the plan proves realistic or the customer adopts it. Shows the AI's understanding of the machine and model, with predicted graphs, in a widget for the user to confirm or correct before anyone drives the machine. Use when a customer asks for a new simulation or plant model of a real machine, wants to tune or optimize a controller toward a goal on the real machine, reports that the simulation and the machine disagree, or wants to think through the process of collecting logs and converging the model.

Reconcile field logs from a real machine with the experiment plan that produced them - find each planned run in the unannotated logs, infer what the operator actually did against what was asked (skipped, partial, different setpoints, extra manoeuvres), re-simulate what was actually done, and compare predicted vs actual on the same graphs, run by run, against the plan's tolerances. Then turn the gap into a minimal plant-model refinement on the planned path and test it against the same logs. Use when logs come back from a field session run with a cppmodel:experiment-design plan, when asked how the machine compared to the model's prediction, or when asked to refine a plant model from field data.

Decide whether a new plant model or a brand-new simulation file should be written in C or C++, using any stored project preference first, otherwise detecting the project's existing convention or asking. Use from cppmodel:plant-model or cppmodel:simulation-testing right before scaffolding a new file - not for editing/debugging an existing one, whose language is already fixed by its file extension, and not for cppmodel:decouple-component.

Run a CppModel simulation many times over a range of parameter values and/or alternative input profiles (a parameter sweep, sensitivity study, or scenario matrix), without editing or rebuilding the simulation - each run's inputs/parameters are passed to the binary with --inputs (SDK 0.10.0+) or posted through the cppmodel MCP server's set_inputs right before it executes, and the whole batch is verified afterwards from the execution records in one get_binary_runs call. Designs the sweep with the user, runs it, and reports which combinations pass or fail, where the pass/fail boundary lies, and the metrics the user cares about. Use when asked to sweep, vary, or tune a parameter, test robustness across input scenarios, find the limit at which a simulation starts failing, or compare several input profiles.

Build a minimal plant model (the simulated physical mechanism) for a new CppModel simulation, and scaffold a starter simulation file wiring it to the controller under test. Use when a customer needs to simulate a new physical mechanism (actuator, motor, sensor pair) that has no model yet.

Set up a machine to build CppModel projects from scratch - detects the OS, architecture, C library, installed C/C++ compilers/toolchains and build tools, compares them against the SDK builds download.cppmodel.com actually publishes (one per OS and architecture), then lets the user pick an installed supported compiler, install one, or (for an unsupported OS/arch/compiler) draft a request to support@cedge.se listing what is available for their OS. Finishes by installing the missing packages and the matching CppModel SDK and verifying a build. Use when asked to install, set up, or prepare a CppModel development environment, or when asked which compiler to use with CppModel.

Run a CppModel simulation with specific inputs (time series read by CppModel_getInput* / inputs["..."]) and parameters (constants read by CppModel_getParameter* / parameters["..."]) without editing or rebuilding it: passed to the binary with --inputs <file> (SDK 0.10.0+), or posted through the cppmodel MCP server's set_inputs right before a run with older SDKs. Finds the exact names the simulation reads, builds and validates the input document, runs the simulation with it (exploring locally first if useful), and confirms from the execution record that the values were really applied. Use when asked to run a simulation with given inputs/parameters or a named scenario, to try "what if <parameter> = X", or to see which inputs and parameters a simulation reads. For many runs over a range of values, use cppmodel:parameter-sweep instead.

Write, extend, or debug a CppModel-based simulation test, in C (the SDK's CModel.h API - CppModel_* functions and its CMODEL_CYCLIC/CMODEL_SIMULATE macros - directly or via a project's own helpers) or C++ (cppmodel::Simulation from cppmodel.hpp, CppModelBase::Simulation in older code, directly or via a project's own wrapper class). Use when asked to add test coverage to a CppModel simulation, when a simulation test fails and the reason isn't obvious from stdout, or when tightening timing-based assertions against real execution data.

Query CppModel Workspace API results - list simulations, fetch the latest results for one, list its execution history, or compare executions with each other. Every simulation run is submitted to the workspace, and its execution history is how runs are compared. Use when asked about CppModel simulation results, executions, how a run compares with an earlier one, or the Workspace API, in a project that uses the CppModel libraries.

Download and install the latest CppModel libraries into the project's dependencies folder, detecting the right platform build, diffing the public headers against what's already there to catch interface changes (RunCyclic's signature especially), migrating the build files when moving from an SDK before 0.8 (per-compiler static libraries) to 0.8+ (one shared library, find_package(cppmodel)), fixing unambiguous call-site breakage and asking about anything unclear, then rebuilding to verify before offering to sync the version pinned in CI/docs. Use when asked to update, upgrade, or refresh the CppModel dependencies/libraries to the latest version.

Turn a controller's requirements into CppModel verification rules (Always, Response, Settle, Mode, Oscillation, Wear, Rate, Energy, Percent) and requirement coverage (VerifyRequirement / CppModel_verifyRequirement) in a simulation, prove each rule can fail, read the rules' outcomes and margins from the recorded execution, and report which requirements are covered, by which simulation and rule, and whether they passed. Use when asked to verify a controller against requirements or a spec, add pass/fail criteria for timing, ranges, interlocks, mode sequences, settling or oscillation, trace tests to requirement IDs, report requirement coverage, or explain why a verification rule failed. Needs SDK 0.11.0+.