Simulation Software Engineer

Simulation Software Engineer

When to Use

• Choose discrete-event vs continuous-time (or hybrid) simulation architecture and time-stepping policy
• Build physics and kinematics models—rigid body, vehicle dynamics, simplified aerodynamics, constraints
• Model sensors and environments—noise, bias, latency, occlusion, weather, terrain, traffic, actors
• Design digital twins and scenario runners—parameterized worlds, replay, batch sweeps, regression suites
• Define SIL/HIL interfaces—stimulus injection, plant models, clock sync, I/O mapping, fault injection hooks (engineering, not security bench)
• Engineer real-time vs faster-than-real-time execution—scheduling, back-pressure, wall-clock coupling
• Implement deterministic replay—seed control, ordering, floating-point policy, record/playback contracts
• Run calibration and validation against logs, flight/field data, or bench measurements with explicit metrics
• Plan Monte Carlo and parameter sweeps—sampling design, coverage, aggregation, failure taxonomy
• Outline distributed simulation—federation concepts, time management, bandwidth/latency budgets (concept level)
• Integrate game-engine or middleware pipelines when simulation rigor (time, sensors, replay) is required

When NOT to Use

• Pure game development without simulation rigor (determinism, validation, SIL/HIL, sensor truth models) → game/graphics skills as appropriate
• Sensor fusion algorithms only—Kalman/graph optimization, track association, estimator tuning without building the sim stack → sensor-fusion-engineer
• Autonomy product stack—perception/planning product code, fleet ops, tactical autonomy delivery → tactical-ai-autonomy-developer
• Bare-metal MCU firmware, ISR/RTOS on chip, driver bring-up → embedded-real-time-software-engineer
• Industrial plant control applications—DCS/PLC scan cycles, OPC UA to historians, BPCS logic → control-software-developer
• Formal proof obligations—theorem proving, certified code, assurance case ownership → software-assurance-formal-methods-specialist
• HIL security testing—authorized bus fault injection, exploit benches, penetration on hardware rigs → hardware-in-the-loop-security-tester
• Service-level profiling, load tests, p99 on servers or browsers without simulation architecture → performance-engineer

Related skills

Core Workflows

1. Scope, paradigms, and success criteria

Define simulation purpose (V&V, training, design exploration, digital twin), fidelity tiers, and measurable acceptance metrics.

See `references/simulation_software_scope.md`.

2. Time bases, physics, and numerical stability

Select DE/CT/hybrid time management, integrators, stiffness handling, and coordinate frames.

See `references/modeling_time_and_physics.md`.

3. Sensors, environment, and scenarios

Model sensing pipelines, world state, actors, and scenario DSL/runner contracts.

See `references/sensors_environment_and_scenarios.md`.

4. Execution, real-time, and determinism

Schedule sim loops, real-time coupling, record/playback, seeds, and reproducibility policies.

See `references/execution_realtime_and_determinism.md`.

5. Validation, calibration, and metrics

Compare sim to measured data; tune parameters; report uncertainty and regression gates.

See `references/validation_calibration_and_metrics.md`.

6. SIL/HIL, twins, and integration

Map software-in-the-loop and hardware-in-the-loop boundaries, clocks, I/O, and twin synchronization.

See `references/integration_sil_hil_and_twins.md`.

Outputs

• Simulation architecture brief — paradigm (DE/CT/hybrid), time policy, modules, fidelity tiers, risks
• Model catalog — physics, sensors, environment, interfaces, units, assumptions, known gaps
• Scenario specification — parameters, initial conditions, termination, pass/fail metrics, seed policy
• Determinism and replay contract — what is logged, ordering rules, FP policy, version pins
• SIL/HIL interface sheet — signals, rates, latency, clock domains, fault injection points (engineering)
• Validation report — metrics vs ground truth, calibration parameters, residual analysis, regression suite
• Sweep/Monte Carlo plan — sampling design, coverage matrix, aggregation and failure taxonomy
• Distributed sim concept note — federation roles, time management, bandwidth budget (when applicable)

Principles

• Match fidelity to decision — coarse models for exploration; high fidelity only where metrics demand it
• Make time explicit — document clocks, step sizes, event ordering, and real-time coupling assumptions
• Separate truth, sensor, and estimator — ground truth in sim ≠ sensor output ≠ fusion output
• Invest in reproducibility — seeds, deterministic builds, pinned assets, replay contracts before scaling sweeps
• Validate against measurements — calibration is incomplete without stated metrics and holdout data
• Keep security and formal peers in lane — route HIL security and proof obligations to named skills
• Stay NDA-safe — generic patterns only; no contractor names, controlled data, or export-sensitive payloads

When to load references

Execution, real-time, and determinism

Table of contents

1. Purpose 2. Execution modes 3. Scheduling and back-pressure 4. Determinism dimensions 5. Record and replay 6. Floating-point policy 7. Regression and CI 8. Distributed simulation (concept) 9. Checklist

Purpose

Guide how simulation runs execute—real-time coupling, faster-than-real-time throughput, and reproducible record/replay for SIL, HIL, and Monte Carlo campaigns.

Execution modes

Document overrun policy: skip frame, catch up, or freeze sim while controller continues (dangerous—justify explicitly).

Scheduling and back-pressure

Single-process loop

while running:
  wait_until(next_tick)           # if real-time
  integrate_physics(dt)
  update_environment()
  generate_sensor_observations()
  publish_to_sut()                # SIL/HIL boundary
  collect_commands()
  apply_actuation()
  log_frame()

Multi-threaded pipelines

• Separate physics, rendering, sensor raycast, I/O threads with bounded queues.
• Define drop policy when queues fill (drop render vs drop sensor vs slow physics).
• Real-time HIL: prefer bounded latency over unbounded queues.

Determinism dimensions

Tolerance-based replay: when bit-identical replay is infeasible, define metric tolerances (pose RMSE, sensor checksum buckets) and still log seeds and versions.

Record and replay

Minimum replay header

• sim_version, scenario_id, params, seed_map
• Asset manifest hashes
• Integrator and physics engine settings
• FP/compiler flags profile name

Log contents (tiered)

Replay modes:

• Open-loop: feed recorded commands; compare outputs
• Closed-loop: re-run SUT with recorded exogenous disturbances only
• Hybrid: partial SIL with hardware replaced by recorded I/O

Floating-point policy

• Maintain a `deterministic` build profile (no fast-math, fixed reduction order where needed).
• Document known nondeterministic ops (parallel reductions on GPU) and isolate them.
• For cross-platform replay, prefer tolerance metrics over bitwise identity.

Regression and CI

Fail CI on silent metric drift—require explicit baseline bumps with rationale.

Distributed simulation (concept)

High-level only—detail belongs in program-specific designs:

• Roles: federate, orchestrator, physics owner, sensor service
• Time management: conservative vs optimistic synchronization
• Bandwidth: what state crosses the wire (poses vs full sensor blobs)
• Failure: partition handling, stale state, graceful degrade

Do not claim scalability numbers without measurement on target network.

Checklist

• [ ] Execution mode and overrun policy documented
• [ ] Thread/queue diagram if multi-threaded
• [ ] Seed map and tie-break rules defined
• [ ] Replay header schema versioned
• [ ] Deterministic build profile named in CI
• [ ] Baseline metrics and tolerances stored per scenario

Integration: SIL, HIL, and digital twins

Table of contents

1. Purpose 2. SIL vs HIL vs twin 3. Interface architecture 4. Clocks and synchronization 5. I/O mapping and protocols 6. Fault injection (engineering) 7. Digital twin patterns 8. Game-engine and middleware bridges 9. Security and safety boundaries 10. Handoffs 11. Checklist

Purpose

Guide integration of simulation with software and hardware under test—SIL/HIL boundaries, digital-twin synchronization, and middleware bridges—without owning security exploitation or formal assurance.

SIL vs HIL vs twin

MIL (model-in-the-loop): often means controls model only—clarify whether “MIL” here excludes sensor rendering; align vocabulary with controls peers (control-software-developer).

Interface architecture

+------------------+     observations      +------------------+
|  Sim world/plant | --------------------> |  SUT (SIL/HIL)   |
|  + sensor models |                       |  controllers/    |
+------------------+ <-------------------- |  perception stack|
        ^                  commands         +------------------+
        |                                            |
        +------------ optional twin ingest ----------+

Contract elements:

• Message types, rates, units, timestamps
• Semantic version of interface schema
• Error handling (stale data, NaN guards, safe defaults)

Clocks and synchronization

HIL overrun: define whether sim waits for hardware, freezes plant, or continues open-loop—misconfiguration causes false pass.

I/O mapping and protocols

Examples (generic):

• Analog/digital maps for actuator and sensor pins
• Ethernet/UDP CAN-FD bridges for automotive stacks
• Middleware (DDS, ROS-style, custom IPC) for robotics SIL

Document:

Prefer recorded I/O playback for bring-up before closed-loop HIL.

Fault injection (engineering)

Engineering faults (for robustness testing):

• Sensor bias ramps, dropout, latency spikes
• Actuator saturation, delay, stuck values
• Environment parameter shocks (wind gust, friction change)

Route security-focused bus manipulation and exploitation to hardware-in-the-loop-security-tester with authorized rules of engagement.

Digital twin patterns

Requirements:

• Identity mapping (asset ID, frame, time)
• Freshness SLAs and stale-state handling
• Versioned twin model matching field software baselines

Do not ingest non-public or export-controlled telemetry into shared repos—use sanitized synthetic or approved stores.

Game-engine and middleware bridges

When using game engines or visual pipelines:

• Pin physics substep, collision meshes, and rendering decoupling
• Export deterministic sensor topics even if visuals are nondeterministic
• Provide headless mode for CI

For Simulink-style or block-diagram tools:

• Export FMU/co-sim boundaries with clear step negotiation
• Document algebraic loops and solver settings in the twin manifest

Security and safety boundaries

• Do not instruct disabling interlocks or safety monitors in real systems from sim examples.
• Do not blend security attack scenarios with safety validation without explicit program separation.
• Formal claims require software-assurance-formal-methods-specialist—sim evidence alone is insufficient.

Handoffs

Checklist

• [ ] SIL/HIL boundary diagram and schema versioned
• [ ] Clock owner and overrun policy documented
• [ ] I/O map with rates and latency budgets complete
• [ ] Engineering fault catalog separated from security tests
• [ ] Twin freshness and model version policy defined
• [ ] NDA/export-safe data handling stated for live feeds

Modeling time and physics

Table of contents

1. Purpose 2. Time management 3. Integrators and stability 4. Coordinate frames 5. Kinematics and dynamics patterns 6. Contacts and constraints 7. Stochastic elements 8. Performance vs accuracy 9. Checklist

Purpose

Guide time-base selection and physics/kinematics modeling for simulation software—stable integration, consistent frames, and explicit assumptions suitable for SIL/HIL and validation.

Time management

Discrete-event (DE)

• Maintain an event queue ordered by simulation time; advance clock to next event.
• State updates occur on events (arrivals, failures, mode switches, message delivery).
• Use when dynamics are piecewise or dominated by protocol/logic timing.

Contracts to document:

• Event ordering tie-break rules (priority, entity ID) for determinism
• Relationship to any CT subsystems (interpolation between events)

Continuous-time (CT)

• Choose integrator and fixed vs variable step based on stiffness and real-time needs.
• Sub-step physics inside a macro frame when coupling to sensors or controllers at rate \(f_s\).

Hybrid coupling

• Scheduler owns time—either DE master with CT slaves, or CT master with DE interrupts.
• Define zero-crossing / guard conditions for mode switches (gear shift, contact engage).
• Avoid hidden aliasing—controller running at 100 Hz while physics integrates at 1 kHz without documented hold/interpolation.

Integrators and stability

Stability practices:

• Unit-test energy/momentum drift on conservative systems where applicable
• Document maximum stable step for real-time targets
• Separate physics step from control step with explicit upsampling/hold policy

Coordinate frames

• Define a frame tree: world (ENU/NED), body, sensor mounts, articulation joints.
• State rotation conventions (quaternion order, Euler sequence) in API docs.
• Propagate uncertainty at frame boundaries when calibrating extrinsics.

Common bugs: left vs right-handed frames, NED vs ENU in aerospace, IMU frame vs body frame.

Kinematics and dynamics patterns

Simulink-style workflows: block-diagram plants with algebraic loops resolved explicitly; document solver settings and algebraic variable initialization.

Contacts and constraints

• Prefer stable contact models (penalty with tuned damping, LCP-based) for repeatable regression.
• Document friction, restitution, and solver iterations; they affect determinism.
• For game engines, physics engine settings are part of the replay contract (solver iterations, CCD on/off).

Stochastic elements

• Drive randomness from named RNG streams per subsystem (environment, sensor, traffic).
• Never mix unseeded thread-local random in deterministic suites.
• Log stream IDs and seeds in replay headers.

Performance vs accuracy

Checklist

• [ ] Master clock and all sub-clocks documented
• [ ] Integrator choice justified for stiffness and real-time mode
• [ ] Frame tree diagram and conventions published
• [ ] Contact/solver settings pinned for regression
• [ ] RNG streams and seeds specified per stochastic module
• [ ] Units enforced (SI) at module boundaries

Sensors, environment, and scenarios

Table of contents

1. Purpose 2. Truth vs sensor vs consumer 3. Sensor modeling patterns 4. Environment modeling 5. Actors and traffic 6. Scenario runner design 7. Scenario DSL and parameters 8. Synthetic data and labels 9. Checklist

Purpose

Guide sensor pipelines, environment/world state, and scenario runners so simulations produce decision-grade outputs with explicit contracts for SIL, replay, and validation.

Truth vs sensor vs consumer

Rule: Never score perception against truth without documenting which sensor model was used; fusion teams need sensor-fusion-engineer for estimator design.

Sensor modeling patterns

Timing model (always specify):

• Capture time vs publish time vs host receive time
• Jitter distribution and worst-case latency for real-time SIL
• Frame drops and out-of-order delivery for robustness tests

Environment modeling

Keep collision geometry separate from visual meshes; document simplifications.

Actors and traffic

• Behavior layers: kinematic paths, rule-based, learned policies (black-box OK if versioned).
• Interaction: right-of-way, spawn/despawn rules, density controls.
• Determinism: seeded traffic flows for regression; separate streams from environment RNG.

For training sims (generic, NDA-safe), avoid identifying real locations or classified tactics—use abstract maps and nominal parameters.

Scenario runner design

Core responsibilities:

1. Load world + robot/platform + parameter set + seed 2. Initialize state and RNG streams 3. Step or run until termination conditions 4. Record agreed topics (truth, sensors, commands, metrics) 5. Score pass/fail and emit artifacts for CI

Runner API surface (conceptual):

run(scenario_id, params, seed) -> RunResult(metrics, logs, exit_reason)
replay(log_uri, options) -> RunResult
sweep(matrix) -> SweepReport

Scenario DSL and parameters

Version scenario packs with the sim binary and asset manifest (hash pins).

Synthetic data and labels

• Auto-label from truth for ML pipelines; document label delay if sensor-time labels differ.
• Publish calibration metadata (intrinsics/extrinsics) alongside synthetic sets.
• For domain randomization, track parameter ranges and coverage across sweeps.

Checklist

• [ ] Truth/sensor/consumer boundaries documented
• [ ] Per-sensor timing, noise, and failure modes specified
• [ ] Environment collision vs visual meshes aligned or gap listed
• [ ] Scenario schema versioned; seeds and tags required
• [ ] Recording format supports deterministic replay
• [ ] Handoff notes for fusion/autonomy peers on interfaces

Simulation software scope

Table of contents

1. Purpose 2. Terminology 3. In scope 4. Out of scope 5. Simulation paradigms 6. Domain patterns 7. Fidelity tiers 8. Roles and RACI 9. Handoffs

Purpose

Define simulation software engineering boundaries—designing and building executable models of systems, environments, and sensors for verification, training, exploration, and digital-twin operation.

This skill covers architecture, modeling, execution, validation, and integration patterns—not live product autonomy delivery, formal certification claims, or security-focused HIL exploitation.

Terminology

In scope

Out of scope

Simulation paradigms

Decision rule: Pick the coarsest paradigm that answers the decision; add fidelity only when metrics fail without it.

Domain patterns

Fidelity tiers

Document tier per subsystem and upgrade triggers (which metric failed at lower tier).

Roles and RACI

Handoffs

• To `sensor-fusion-engineer`: Provide sensor outputs, timestamps, and ground truth; receive estimator requirements and failure modes to model.
• To `tactical-ai-autonomy-developer`: Deliver sim APIs, scenario catalogs, and regression baselines; receive stack interfaces and release gates.
• To `embedded-real-time-software-engineer`: Align clock domains, I/O rates, and WCET assumptions for HIL targets.
• To `control-software-developer`: Exchange plant models and scan-cycle semantics when simulating industrial controllers.
• To `hardware-in-the-loop-security-tester`: Separate engineering HIL I/O maps from security test plans and authorized injection.
• To `software-assurance-formal-methods-specialist`: Provide model assumptions and environment contracts; do not claim proofs from sim alone.

Validation, calibration, and metrics

Table of contents

1. Purpose 2. V&V vocabulary 3. Validation workflow 4. Calibration workflow 5. Metric families 6. Monte Carlo and parameter sweeps 7. Uncertainty and sensitivity 8. Regression governance 9. Reporting template 10. Checklist

Purpose

Guide evidence that simulation is fit for purpose—comparing to measured data, tuning parameters responsibly, and structuring sweeps without over-claiming predictive power.

V&V vocabulary

Fit-for-purpose statement (required): “This model is adequate for \<decision\> when metric \<M\> is within \<threshold\> on dataset \<D\>.”

Validation workflow

1. Define use case — what decision the sim supports (controller gain, training coverage, HIL fault test) 2. Select fidelity tier per subsystem (see scope reference) 3. Choose datasets — holdout reserved; no tuning on test set 4. Define metrics — per domain (pose, velocity, range error, detection counts) 5. Run baseline — document sim version, seeds, assets 6. Compare and report — residuals, time alignment, failure cases 7. Gate — pass/fail thresholds for CI or release

Time alignment

• Synchronize logs with interpolation policy (linear, SLERP for attitudes)
• Account for sensor latency in sim vs truth in field logs
• Flag clock jumps and drop segments that invalidate comparison

Calibration workflow

Avoid: tuning until metrics look good on the same data used to fit (report train vs holdout).

Metric families

Publish units and frames with every metric table.

Monte Carlo and parameter sweeps

Design

Execution contract

• Fixed seed ladder for reproducibility (base_seed + run_index)
• Cap parallelism with isolated output dirs
• Aggregate with percentiles, not only means

Failure taxonomy

Classify failures: collision, timeout, controller_saturation, sensor_fault, numerical_instability—avoid undifferentiated “failed.”

Uncertainty and sensitivity

• Sensitivity: vary one parameter at a time or Sobol indices when budget allows
• Uncertainty: report output spread across Monte Carlo; separate epistemic (model gap) vs aleatory (noise)
• Do not present single-run results as reliability without distribution

Regression governance

When baselines move, require hypothesis (model fix vs intentional behavior change).

Reporting template

## Validation summary
- Use case:
- Sim version / scenario pack:
- Datasets (train/holdout):

## Results
| Metric | Threshold | Train | Holdout |
|--------|-----------|-------|---------|

## Residual analysis
- Largest errors (with timestamps):

## Calibration
- Parameters changed since last release:
- Identifiability / overfit notes:

## Limitations
- Known non-validated regimes:

Checklist

• [ ] Fit-for-purpose statement written
• [ ] Holdout dataset reserved before tuning
• [ ] Metrics include units, frames, time sync method
• [ ] Monte Carlo seeds and aggregation documented
• [ ] Failure taxonomy applied
• [ ] Limitations section lists known bad regimes