Chapter 16 — Systems engineering

Lesson map

Lesson 16 published. Map, example, EX046.

flowchart TD
  N0["Learning outcomes"]
  N1["16.1 System of systems"]
  N2["16.2 Interface agreements"]
  N3["16.3 Traceability"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX046"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["16.1 System of systems"]
  N2["16.2 Interface agreements"]
  N3["16.3 Traceability"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX046"]

[Learning outcomes]
    |
    v
[16.1 System of systems]
    |
    v
[16.2 Interface agreements]
    |
    v
[16.3 Traceability]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX046]

Learning outcomes

You will (1) view the token platform as a system of systems; (2) manage interfaces; (3) trace requirements across components.

16.1 System of systems

Brightwater's platform is more than contracts: meters, a data gateway, the off-chain database, the ledger with validators, contracts, a member web app, paper statements and support staff. Jonas draws a context diagram showing each component and its interfaces. Systems engineering teaches that failures often occur at interfaces, where assumptions differ, such as the gateway assuming meter timestamps are in UTC while meters report local time. Seeing the whole system helps him find such mismatches early. He reviews the diagram with each component owner.

16.2 Interface agreements

For each interface Jonas writes an agreement: data format, units, timing, error handling and who owns it. The meter-to-gateway agreement states readings in watt-hours with UTC timestamps and signed by the device. The gateway-to-contract agreement states that minting requests are batched hourly and must not exceed the capacity bound. Written agreements turn implicit assumptions into checked rules, and they give reviewers something concrete to verify at each boundary. Each agreement is signed by both owners and stored with the architecture records, and any change requires the agreement to be updated before code changes are merged.

16.3 Traceability

Jonas builds a traceability matrix linking each requirement to the components that implement it and the tests that verify it. For example, the requirement that no more credits are minted than generation allows traces to the gateway's bound check, the contract's per-hour cap and a monitoring alert, each with a test. When a requirement changes, the matrix shows what else must change. Traceability is how engineers show that a system does what was intended, not just that each part works alone.

Worked example

A context diagram exposes a UTC versus local-time mismatch; interface agreements and a traceability matrix link the minting cap to three components and tests.

Synthetic case. Components and requirements are synthetic.

Errors and limits

Testing components separately without checking interfaces misses mismatched assumptions.

Exercises

• EX046 — Interface failure. What interface mismatch was found?
  Show marking criteria

  Rubric: 3 = UTC versus local timestamps;; 2 = time zones;; 1 = vague;; 0 = none.
• EX047 — Agreement content. Name two items in an interface agreement.
  Show marking criteria

  Rubric: 3 = format and units;; 2 = timing, owner;; 1 = colour;; 0 = none.
• EX048 — Minting trace. Which components implement the minting cap?
  Show marking criteria

  Rubric: 3 = gateway check, contract cap, monitoring alert;; 2 = three;; 1 = one;; 0 = none.

Synthesis

Context diagrams, interface agreements and traceability manage complexity across a token platform.

Continue studying — chapter 16 of 50

← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →