Chapter 35 — Design studio II
Lesson map
Lesson 35 published. Map, example, EX069.
flowchart TD
N0["Learning outcomes and connection"]
N1["35.1 From concept to detailed design"]
N2["35.2 Assurance arguments"]
N3["35.3 Studio II brief synthetic"]
N4["35.5 Practical activity"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX069"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["35.1 From concept to detailed design"]
N2["35.2 Assurance arguments"]
N3["35.3 Studio II brief synthetic"]
N4["35.5 Practical activity"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX069"]
[Learning outcomes and connection]
|
v
[35.1 From concept to detailed design]
|
v
[35.2 Assurance arguments]
|
v
[35.3 Studio II brief synthetic]
|
v
[35.5 Practical activity]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX069]
Learning outcomes and connection
After this chapter you can (1) carry a design from concept to detailed design with quantitative justification; (2) integrate reliability, safety, security, performance and cost analyses into one argument; (3) build a structured assurance argument linking claims to evidence; and (4) defend detailed design decisions under review. It integrates Chapters 26–34 and prepares Chapters 36–40.
35.1 From concept to detailed design
Studio I selected a concept. Studio II details it: specific components, configurations, interfaces, procedures and verification. Every number from earlier chapters returns: hold-up times (Chapters 1, 6), battery sizing (Chapter 3), base rates (Chapter 7), latency (Chapter 11), fault tree (Chapter 23), detection metrics (Chapter 29), availability (Chapter 32), queueing (Chapter 36 preview). A detailed design is coherent when these numbers are consistent with each other and with the requirements.
For TMRP, the battery sizing, the 72 hours of local automatic operation, the hospital's four-hour buffer and the recovery time must all tell the same story; EX069 shows what happens when one of them does not.
35.2 Assurance arguments
An assurance case is a structured argument that a system meets a claim, supported by evidence. It has a top claim ("TMRP keeps the hospital supplied under credible scenarios including remote command forgery"), sub-claims (each requirement met; residual risks acceptable), arguments (why the sub-claims support the claim), and evidence (test results, analyses, reviews). Toulmin's model of argument — claim, data, warrant, backing, qualifier, rebuttal (Toulmin, 1958/2003) — is a useful lens: what evidence supports the claim, why it is relevant, and what would defeat it. Explicit defeaters ("unless the SCADA centre is compromised") keep the argument honest.
35.3 Studio II brief (synthetic)
Produce the detailed design for TMRP phase 1 (PS2, PS3, PS4 and Hollin Hill): component list with security features; zone and conduit allowlists; key management procedure; local manual and failover procedures; alarm rationalisation for new security alarms; verification plan; and an assurance case for the top claim with at least four sub-claims and identified defeaters.
The brief covers the four assets that matter most to St Brenna's: PS2 as the proven pilot, PS3 and Hollin Hill as the reservoir path, and PS4 as the direct feed. The remaining stations and the Fenwick works follow in later phases, so the assurance case for phase 1 must say clearly that it does not cover them yet.
35.4 Worked example: one branch of the assurance case (synthetic)
Sub-claim C2: forged remote commands cannot cause loss of hospital supply. Argument: commands require a valid per-station MAC (R1) and fresh counter (R2); even accepted commands cannot drive the process beyond local bounds (R3); loss of both supply paths additionally requires the hospital tank to fail (fault tree). Evidence: T1, T2 passed (bench and site acceptance at PS2); T3 passed on v2; Lab 9 conditioning analysis; independent review of key management. Defeaters: (D1) SCADA servers compromised — commands are authentic; mitigated by local bounds and two-person approval for bulk changes, residual accepted by the operations director; (D2) per-station key extracted from a stolen RTU — confined to one station, detection by tamper alarm, rotation procedure. Qualifier: claim holds for scenarios in the risk register v1.2; not for physical attack on both pump stations.
35.5 Practical activity
Write the full assurance case for the Studio II brief and present it to a panel that is instructed to find defeaters.
Give the panel the brief, your component list and the assurance case, and ask them to find what would defeat each sub-claim. Record every defeater they find, whether you already listed it or not, and write a response: evidence that addresses it, a design change, or an explicit acceptance with an owner. Defeaters such as a compromised SCADA centre or a stolen RTU key are expected; the panel's job is to find ones you missed, such as misuse of local manual mode.
35.6 Common errors and limits
- Inconsistent numbers across analyses.
- Assurance cases with claims and no evidence, or evidence with no argument.
- Defeaters omitted to make the case look stronger.
- Detailed design that changes requirements silently.
EX069 is an example of the first error inside TMRP itself: R6 asks for eight hours, but the recovery trial measured twelve. A case that claimed R6 while citing the trial would be inconsistent, so the case records R6 as not met and explains why the hospital claim can still hold through local automatic operation.
Exercises — chapter 35
EX069 — Consistency check. Objective: find inconsistencies across analyses. Inputs: PS4 battery hold-up 24 h (R5); hospital buffer 4 h; R6 restore remote operation in 8 h; Chapter 47's trial shows 12 h. Steps: identify which claims conflict and what the conflict means for the assurance case. Expected evidence: analysis. Rubric: 3 = identifies that R6 is not met (12 > 8), that supply does not depend on remote operation (local automatic) so hospital claim can still hold, and that the case must record R6 as failed with plan; 2 = partial; 1 = misses R6; 0 = none.
EX070 — Find a defeater. Objective: challenge an argument. Inputs: sub-claim C2 in §35.4. Steps: propose two further defeaters not listed and the evidence or design change that would address each. Expected evidence: two defeaters with responses. Rubric: 3 = credible defeaters (e.g., local manual mode misuse by insider; gateway firmware update path compromised; counter persistence failure) with specific responses; 2 = one weak; 1 = restates listed ones; 0 = none.
Chapter synthesis
Detailed design makes every earlier number meet. An assurance case connects the top claim to evidence through explicit arguments, with qualifiers and defeaters stated openly. Consistency across analyses and honesty about defeaters are what make a detailed design defensible.
Continue studying — chapter 35 of 50
← Chapter 34 · Course chapter index · Chapter 36 →
Continue to the next authored lesson.