Chapter 44 — Engineering capstone I
Lesson map
Lesson 44 published. Map, example, EX087.
flowchart TD
N0["Learning outcomes and connection"]
N1["44.1 What a capstone is"]
N2["44.2 Scoping"]
N3["44.3 Planning"]
N4["44.4 Environment"]
N5["44.6 Practical activity"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX087"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["44.1 What a capstone is"]
N2["44.2 Scoping"]
N3["44.3 Planning"]
N4["44.4 Environment"]
N5["44.6 Practical activity"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX087"]
[Learning outcomes and connection]
|
v
[44.1 What a capstone is]
|
v
[44.2 Scoping]
|
v
[44.3 Planning]
|
v
[44.4 Environment]
|
v
[44.6 Practical activity]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX087]
Learning outcomes and connection
After this chapter you can (1) define a capstone project with a sponsor, scope, requirements and acceptance criteria; (2) plan it with a schedule, risk register and verification plan; (3) set up a reproducible engineering environment; and (4) pass a preliminary design review. The capstone integrates the course into one built and verified system and continues through Chapters 45–50.
44.1 What a capstone is
A capstone is a substantial engineering project in which the student designs, builds and verifies a system that meets real or realistic requirements under constraints. In this course the capstone must: address a critical-infrastructure security or resilience need; include a working artefact (software, configuration, testbed or prototype); include analysis (threat/failure, performance, reliability); and be verified against stated requirements. The capstone continues the TMRP case unless your supervisor approves another synthetic or authorised case.
The worked example below follows TMRP: restart-safe authenticated telemetry for the legacy RTUs at PS1 and PS2.
44.2 Scoping
A good capstone scope is narrow enough to finish and deep enough to require real engineering. Examples: an authenticated telemetry gateway with fault-injection verification; a residual-based detector with a validated simulation study; a recovery-orchestration tool with a measured restoration trial; a segmentation-verification tool with a policy model. Write a one-page scope: need, stakeholders, deliverables, out-of-scope items, constraints, and acceptance criteria.
The TMRP capstone scope in the worked example below fits on one page and leaves real RTU hardware and the carrier network out.
44.3 Planning
Plan with a work breakdown, schedule with milestones (preliminary design review, critical design review, verification complete, thesis draft, defense), risk register (technical, schedule, access, skills), and verification plan tracing requirements to tests. Keep a weekly log and update the risk register monthly.
For the TMRP capstone, the twelve-week schedule places the preliminary design review in the first weeks and the independent review before verification. Its risk register includes the chance that restart safety proves harder than expected, which, as the verification summary later shows, is what happened when the receiver accepted replays after a restart.
44.4 Environment
Set up version control, an issue tracker, a reproducible build (pinned dependencies or standard library only), automated tests, and a results directory where every result is stored with the commit, seeds and environment that produced it.
For the TMRP capstone, the gateway uses only the Python standard library, so there are no dependencies to pin, and every campaign result is stored with its seed and commit. That discipline is what lets the later dossier list a hash and version for each result.
44.5 Worked example: capstone scope (synthetic)
Title: Restart-safe authenticated telemetry for legacy RTUs. Need: N2/N3 of TMRP. Deliverables: gateway software (Python standard library), bench harness, fault-injection campaign, key-rotation procedure, thesis. Out of scope: real RTU hardware; carrier network. Constraints: 12 weeks; synthetic data. Acceptance: R1, R2 (including restarts), R7 verified on the bench; zero silent failures in a seeded campaign of 10,000 messages across seven fault classes; key rotation without loss of telemetry demonstrated.
Each acceptance criterion maps to a requirement or a demonstration, so the critical design review can check them one by one.
44.6 Practical activity
Write your capstone scope and plan, and hold a preliminary design review with your supervisor and one peer.
Base your scope on the one-page template: need, stakeholders, deliverables, items out of scope, constraints and acceptance criteria. Then prepare a short plan with milestones and a risk register. At the review, ask your supervisor and peer to challenge the acceptance criteria above all, because a criterion that cannot be tested will cause trouble at the critical design review. Record their findings and your responses.
44.7 Common errors and limits
- Scopes too broad ("secure the utility").
- No acceptance criteria.
- Verification planned last.
- Unreproducible environments.
The draft scope in EX087 shows the first two errors: securing water utilities with an AI system has no boundary and no acceptance criteria. The TMRP capstone scope avoids them by naming one gateway, three requirements and a measured campaign. Its verification plan was written with the scope, and its environment uses only the standard library with seeded runs, so every result can be reproduced. Its milestones are dated.
Exercises — chapter 44
EX087 — Scope critique. Objective: tighten a scope. Inputs: draft scope "Build an AI system to protect water utilities from cyber attacks". Steps: list four problems and rewrite the scope in one page. Expected evidence: critique and rewrite. Rubric: 3 = problems (unbounded, no requirements, no data, no acceptance) and a feasible, verifiable rewrite; 2 = rewrite vague; 1 = critique only; 0 = none.
EX088 — Risk register. Objective: plan for project risks. Inputs: §44.5. Steps: write five project risks with likelihood, impact, mitigation and trigger. Expected evidence: table. Rubric: 3 = realistic risks (scope creep, restart-safety design harder than expected, bench fidelity, time, supervisor availability) with concrete triggers; 2 = no triggers; 1 = generic; 0 = none.
Chapter synthesis
A capstone is a scoped, built and verified system. Define the need, deliverables, constraints and acceptance criteria; plan milestones, risks and verification from the start; and make the environment reproducible so that every result can be traced and re-run.
Continue studying — chapter 44 of 50
← Chapter 43 · Course chapter index · Chapter 45 →
Continue to the next authored lesson.