Chapter 46 — Engineering capstone II

Chapter 46 — Engineering capstone II

Lesson map

Lesson 46 published. Map, example, EX080.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["46.1 Finishing the build"]
  N2["46.2 Executing verification"]
  N3["46.3 Critical design review"]
  N4["46.5 Practical activity"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX080"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["46.1 Finishing the build"]
  N2["46.2 Executing verification"]
  N3["46.3 Critical design review"]
  N4["46.5 Practical activity"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX080"]

[Learning outcomes and connection]
    |
    v
[46.1 Finishing the build]
    |
    v
[46.2 Executing verification]
    |
    v
[46.3 Critical design review]
    |
    v
[46.5 Practical activity]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX080]

Learning outcomes and connection

After this chapter you can (1) complete implementation of the capstone artefact; (2) execute the full verification plan and record results; (3) close review findings; and (4) pass a critical design review with evidence. It continues Chapter 44 after the independent review and prepares the failure and recovery trial (Chapter 47).

46.1 Finishing the build

Freeze scope: new features now threaten verification. Close the review findings that require design changes first. Keep the main branch always passing its tests; tag the version that enters final verification.

For the TMRP capstone, scope was frozen after the independent review. F2's stale-station alarm was the design change made before the tagged version entered final verification; every later idea went to a list for future work. The restart fix came later, as a correction found by verification itself, which is the only kind of change allowed after a freeze. The main branch stayed green.

46.2 Executing verification

Run the full verification plan against the tagged version: unit, integration, property-based and fault-injection tests (Chapters 30 and 40). Record each result with version, seed and environment. For any failure: record, analyse, fix, re-run, record again. Do not overwrite earlier results; history is evidence.

For the TMRP capstone, the receiver's failure to reject replays after a restart was recorded, fixed by persisting the last counter per station, and re-tested, with both results kept. The tagged version was the one tested. Its seed was recorded.

46.3 Critical design review

At the critical design review the panel checks: requirements met with evidence; review findings closed or dispositioned; residual risks stated and owned; operations and maintenance prepared; and readiness for the trial. Bring the traceability matrix, verification results, finding log and assurance case.

For TMRP, the panel saw the verification summary below. It includes the restart failure and its fix, the stale-station alarm added after F2 and the key rotation demonstration. With F1 to F3 closed or dispositioned and R6 reported honestly, the panel could make an explicit readiness decision for the trial instead of an assumption.

46.4 Worked example: capstone verification summary (synthetic)

The restart failure was found by the extended fault model of EX080 — a direct return on the verification laboratory's investment.

46.5 Practical activity

Run your full verification plan and produce the summary table with links to raw results.

For each requirement, give the tests, the result and any fix, as in the TMRP summary. Keep the failed results with their dates and the fixes that followed, and link each line to the raw result files with their seeds and versions. If a test was not run, say so in the table rather than leaving it blank. The table should let a reviewer trace any claim to a file in one step.

46.6 Common errors and limits

• Adding features during verification.
• Overwriting failed results with later passes.
• Entering critical design review with open critical findings.

The TMRP capstone avoided these by freezing scope after review, keeping the restart failure in the record beside its later pass, and closing F1 to F3 before the critical design review. Failed results stayed in the record with the fixes that followed, so reviewers could see how each pass was earned. No feature was added during verification. Open findings were closed first.

Exercises — chapter 46

EX091 — Rotation design. Objective: design key rotation without loss. Inputs: §46.4. Steps: describe the rotation protocol step by step, including how the receiver knows which key to try, the overlap window, failure handling and revocation. Expected evidence: procedure. Rubric: 3 = key ID in authenticated header, receiver accepts both keys during window, counters continue, rollback if new key fails, old key revoked and destroyed; 2 = no key ID; 1 = "change the key"; 0 = none.

EX092 — Readiness decision. Objective: judge readiness. Inputs: all requirements pass except a minor finding on documentation and an open major finding that the stale-station alarm threshold (60 s) produces two false alarms a day during LTE congestion. Steps: recommend go / go with conditions / no-go for the trial, with reasoning. Expected evidence: recommendation. Rubric: 3 = go with conditions (threshold tuning study during trial, operators briefed), reasoning about consequence of false alarms vs missed loss of data; 2 = no conditions; 1 = unreasoned; 0 = none.

Chapter synthesis

Freeze scope, close findings, verify the tagged version completely and keep failure history as evidence. Enter the critical design review with traceability, results, findings and the assurance case, and leave it with an explicit readiness decision.

Continue studying — chapter 46 of 50

← Chapter 45 · Course chapter index · Chapter 47 →

Continue to the next authored lesson.