1. Course overview

Model-based engineering has become the default way to develop complex systems in automotive, aerospace, energy, and industrial automation. A controller is no longer specified only by prose and drawings; it is specified by Simulink models, Stateflow charts, calibration data sets, and the toolchain configuration that turns them into executable code. When a safety case, a type approval, or an internal design review depends on simulation results, two questions become unavoidable: which exact model produced this result, and can we prove it has not changed since? This course addresses both questions under a single discipline: model configuration control (keeping every model, data set, and tool setting under versioned, auditable control) and simulation evidence provenance (recording, in a verifiable way, the chain of artifacts and actions that produced a simulation result).

Why the Two Disciplines Belong Together

Configuration control without provenance produces well-versioned models but no defensible link to results. Provenance without configuration control produces traceable records pointing at artifacts nobody can reconstruct. The two are complementary halves of one property: reproducibility. A simulation result is reproducible when an independent engineer, given only the recorded evidence package, can rebuild the same executable model and obtain the same outputs within a stated tolerance.

Consider a concrete failure mode seen in practice. A team runs a MIL (model-in-the-loop) test of an automatic emergency braking function and records a passing result: minimum time-to-collision of 1.42 s against a 1.20 s requirement. Six months later, during a functional safety assessment, the assessor asks for the evidence. The test report references aeb_controller.slx — but the file has been edited eleven times since. The report does not record the model version, the parameter file, the solver settings, or the MATLAB release. The result is technically true but evidentially worthless: it cannot be attributed to any reconstructable configuration. This course teaches the practices that prevent exactly this outcome.

Core Concepts and Vocabulary

The course uses a small, precise vocabulary throughout. The table below defines the terms that recur in every later chapter; treat it as the reference glossary for the whole course.

Two distinctions matter from the start. First, version control is not configuration control: a Git repository stores history, but configuration control additionally requires that a baseline be immutable, complete (no CI missing), and approved. Second, logging is not provenance: a log line saying "test passed" carries no attribution; a provenance record must bind the result to hashes of every input that influenced it.

The Technical Context: Where Models and Evidence Live

In a typical toolchain, a Simulink model references a data dictionary, which resolves to calibration files; a build step generates C code; a test harness drives the model or the generated code with scenario inputs; and a report generator captures results. Every one of these stages introduces configuration that can silently change behavior: solver type and step size, compiler version, optimization flags, library block versions, and the order in which data dictionary entries override workspace variables. Provenance must therefore span the whole chain, not just the model file.

The diagram below shows this chain as a signal-and-artifact flow: the left column is the configuration side (what defines behavior), the right column is the evidence side (what records it), and the arrows show which configuration items must be captured by which provenance element.

What the Course Covers — and What It Does Not

The course is organized into five progressive parts. Part I (Chapters 1–6) establishes foundations: configuration item identification, baseline construction, versioning strategy for binary model formats, and the data dictionary as a controlled artifact. Part II (Chapters 7–13) covers provenance mechanics: run manifests, content hashing, tool and environment capture, and the design of evidence bundles. Part III (Chapters 14–20) addresses reproducibility engineering: deterministic simulation settings, tolerance definition, re-run automation, and drift detection between baselines. Part IV (Chapters 21–26) applies the discipline to review and assessment workflows, including audit trails, change impact analysis, and evidence sufficiency criteria. Part V (Chapters 27–30) covers tooling integration — repository hooks, CI pipelines, artifact repositories — and a capstone exercise.

The course deliberately excludes model quality itself (whether the model is correct), test design methodology, and organizational process maturity models. Those are adjacent disciplines. Here, the question is always: given a result, can we establish exactly what produced it, and can we rebuild it?

A First Worked Example: From Ad-Hoc Test to Evidence Bundle

To make the scope concrete, consider a minimal but complete example that later chapters will expand. Suppose an engineer tests a cruise-control model and must hand the result to a reviewer. The ad-hoc version of this task produces a spreadsheet row: test name, date, "pass". The disciplined version produces the following, which is the target output of this course.

# run_manifest.yaml (illustrative example — values are hypothetical)
run_id: CC-MIL-0042
executed_at: 2025-03-11T09:14:22Z
executed_by: j.doe
baseline:
  tag: cc-baseline-2025.03
  manifest_sha256: 9f2c...e71a
configuration_items:
  - name: cruise_controller.slx
    sha256: 4b81...c0d3
  - name: cc_data_dictionary.sldd
    sha256: a7e0...19f5
  - name: cc_calibration_v3.mat
    sha256: 2d6f...88b1
  - name: test_harness_cc.slx
    sha256: e5c2...7a40
toolchain:
  matlab_release: R2024b
  solver: ode45
  fixed_step: 0.01
  compiler: gcc 13.2.0
result:
  metric: steady_state_error_kmh
  value: 0.31
  criterion: "<= 0.50"
  verdict: PASS
reproduction:
  command: "matlab -batch \"run_cc_test('CC-MIL-0042')\""
  tolerance: "0.01 absolute on steady_state_error_kmh"

Three properties of this record are worth noting, because they define the standard the course teaches. It is attributable — every input is bound by hash, so a later edit to any file is detectable. It is reconstructable — the toolchain block and reproduction command are sufficient to rebuild the environment. And it is judgeable — the criterion and tolerance are stated numerically, so a reviewer can decide whether the verdict is defensible without re-deriving the test intent.

Common Failure Patterns This Course Prevents

Experience across automotive and aerospace programs shows a recurring set of failure patterns. Floating references: reports cite file names rather than versions, so the cited artifact no longer exists in the tested form. Incomplete capture: the model is hashed but the calibration file is not, and the calibration was changed between runs. Environment drift: results differ after a tool upgrade because the solver default changed, and no record of the original solver setting exists. Non-deterministic tests: a test passes intermittently because random seeds or parallel execution order were never fixed, making the "pass" verdict unreproducible. Evidence sprawl: results, logs, and configuration live in different systems with no binding identifier, so assembling a review package takes days and introduces transcription errors.

Each of these maps to a specific practice taught later: immutable baselines, complete configuration indexes, toolchain capture, determinism controls, and the evidence bundle as a single reviewable unit. The remainder of the course builds these practices in dependency order, starting with the identification of configuration items — because nothing else works until you know precisely which artifacts influence behavior.