Engineering CI/CD

From Software CI/CD to Engineering CI/CD

Software CI/CD follows a well-understood pattern: code committed, build triggered, unit tests run, integration tests run, deployment staged, smoke tests pass, production deployed. Each stage gates the next. The pipeline is fast (minutes to hours), deterministic (same code produces same build), and transparent (every developer sees the pipeline status).

Engineering CI/CD follows the same principles but operates on different artifacts. The "code" is a model change — an updated parameter, a new component, a revised requirement, a modified interface. The "build" is a consistency check — do the model relationships still hold? The "tests" are parametric evaluations, simulations, and regression comparisons. The "deployment" is a dashboard update or a release decision.

The pipeline structure is analogous. The details are different. Understanding those details is the work of this lesson.

The Engineering Pipeline

An engineering pipeline processes a model change through a series of stages, each designed to catch a specific category of problem.

Stage 1: Consistency Checks

When a model element changes, the first question is: does the model still make sense? Consistency checks are the engineering equivalent of a compiler checking syntax. They verify that model relationships are intact — that every requirement is still allocated to at least one design element, that interface definitions on both sides of a connection still match, that parametric constraints are not violated by the new values.

These checks are fast (seconds to minutes) because they operate on model data, not on simulation results. They catch the most basic errors: a requirement left dangling after a design restructuring, a power budget exceeded by a component swap, an interface mismatch introduced by an update to one side of a connection without updating the other.

In an MBSE context, consistency checks run against the model's relationship graph. If a requirement is allocated to a function, and that function is realized by a component, a change to any element in that chain should trigger a check that the chain still holds. This is the digital thread being actively maintained, not just recorded.

Stage 2: Parametric Evaluation

With consistency confirmed, the pipeline evaluates derived quantities. Mass rollups, power budgets, thermal margins, cost estimates — any quantity computed from model parameters. These evaluations use the parametric relationships defined in the system model (or in connected analysis tools) to recompute values with the updated inputs.

Parametric evaluation catches problems that consistency checks miss: a component swap that passes all interface checks but pushes the total system mass over budget. A material change that satisfies the structural requirement but violates the thermal constraint. These are not syntax errors — they are engineering constraint violations that only surface when the numbers are run.

Stage 3: Targeted Simulation

Not every model change warrants a full simulation campaign. The pipeline should be smart about which simulations to trigger. A change to a structural parameter triggers structural simulations. A change to a thermal interface triggers thermal simulations. A change to a control algorithm triggers dynamics simulations. The mapping between model elements and simulation types is part of the pipeline configuration.

Targeted simulation is the most time-consuming stage — minutes to hours depending on fidelity. This is where the pipeline must balance thoroughness against speed. Low-fidelity screening simulations can run quickly and flag potential issues. High-fidelity confirmation simulations run on a longer cycle. The pipeline may use both: a fast screen as a gate, followed by a high-fidelity run queued for the next available compute window.

Stage 4: Regression Comparison

Simulation results in isolation tell you whether the current design meets requirements. Regression comparison tells you whether the current design is better or worse than the previous version. The pipeline compares key performance metrics against the established baseline: did thermal margin increase or decrease? Did structural safety factor change? Did weight go up or down?

Regression comparison is where automation provides its greatest leverage. In a manual workflow, comparing results across design iterations requires an analyst to locate the previous results, align the comparison basis, and compute the deltas. In an automated pipeline, the baseline is stored, the comparison is computed automatically, and deviations beyond a threshold are flagged.

Stage 5: Dashboard Update and Reporting

The pipeline's final stage publishes results to a dashboard visible to the engineering team. Key metrics, pass/fail status, regression trends, and flagged issues are presented in a format that supports decision-making without requiring anyone to dig through simulation output files.

The dashboard is not a luxury — it is the mechanism by which the pipeline's output becomes actionable. A pipeline that runs but whose results sit in a log file nobody reads has no value. The dashboard closes the loop: change made, pipeline ran, results visible, decision informed.

Triggers: What Starts the Pipeline

Model Change Trigger

The most common trigger. An engineer commits a change to the system model — a parameter update, a component addition, a requirement modification. The pipeline detects the change, classifies it (which subsystems are affected?), and initiates the appropriate stages. This is the engineering equivalent of a code commit triggering a CI build.

Scheduled Trigger

Some evaluations should run on a regular cadence regardless of whether the model changed. Nightly regression runs, weekly integration checks, monthly comprehensive evaluations. Scheduled triggers ensure that slow-building problems (performance trends, resource budget drift) are caught even when no single change triggers the pipeline.

Manual Trigger

Sometimes an engineer needs to run the pipeline on demand — to validate a proposed change before committing it, to rerun a failed stage after fixing an infrastructure issue, or to evaluate a what-if scenario. Manual triggers provide this flexibility while still using the same automated pipeline infrastructure.

Parallel vs. Sequential Stages

Not every stage depends on the output of the previous stage. Consistency checks and parametric evaluations can often run in parallel — they operate on different aspects of the model. Structural and thermal simulations can run concurrently if they are independent. The pipeline should exploit this parallelism to reduce end-to-end execution time.

Sequential dependencies exist where one stage's output is another stage's input. Simulation cannot start before consistency checks confirm the model is valid. Regression comparison cannot start before simulation completes. The pipeline must respect these dependencies while parallelizing everything else.

Modeling the pipeline as a directed acyclic graph (DAG) of stages — rather than a linear sequence — is the standard approach. Each node is a stage. Edges represent data dependencies. Stages with no unmet dependencies execute in parallel. This is exactly how software CI/CD systems (Jenkins, GitLab CI, GitHub Actions) model their pipelines, and the same tools can often be adapted for engineering use.

Decision Gates: Automated vs. Human

A decision gate is a point in the pipeline where a pass/fail decision determines whether to proceed. Two models exist:

Automated gates. The pipeline evaluates a quantitative criterion and proceeds or halts without human intervention. "If structural safety factor is above 1.5, proceed. If below, halt and notify." Automated gates are appropriate when the pass/fail criterion is unambiguous and the consequence of a false pass is manageable.

Human review gates. The pipeline pauses and presents results to a designated reviewer, who decides whether to proceed. "Thermal margin decreased by 8% — acceptable for this design iteration?" Human gates are appropriate when the criterion involves judgment, when the consequence of a wrong decision is severe, or when regulatory requirements mandate human oversight.

Most mature pipelines use a combination: automated gates for routine checks (consistency, budget compliance) and human gates for high-consequence decisions (design release, test readiness review). The pipeline's value is in automating the routine so that human attention is reserved for the decisions that genuinely require it.

Assessment