OpenCyber Academy
Engineering · Chapter 43 · English
Course code: OCA-138Chapter 43: OCA-138-C043

Chapter 43 — Industry or public-service practice

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 43 published. Map, example, EX085.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["43.1 Purpose of practice"]
  N2["43.2 Placement agreement"]
  N3["43.3 Reflective practice log"]
  N4["43.4 Common placement work"]
  N5["43.6 Practical activity"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX085"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["43.1 Purpose of practice"]
  N2["43.2 Placement agreement"]
  N3["43.3 Reflective practice log"]
  N4["43.4 Common placement work"]
  N5["43.6 Practical activity"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX085"]
[Learning outcomes and connection]
    |
    v
[43.1 Purpose of practice]
    |
    v
[43.2 Placement agreement]
    |
    v
[43.3 Reflective practice log]
    |
    v
[43.4 Common placement work]
    |
    v
[43.6 Practical activity]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX085]

Learning outcomes and connection

After this chapter you can (1) plan and complete a supervised practice placement in an operator, vendor, integrator, regulator or public agency; (2) work within the placement's authorisation, confidentiality and safety rules; (3) keep a reflective practice log that links observed work to the course's methods; and (4) produce a placement report that is useful to the host and safe to share. It applies the whole course to real practice and prepares the capstone.

43.1 Purpose of practice

Practice exposes the constraints that textbooks smooth over: procurement cycles, staffing, legacy equipment, regulatory deadlines, union agreements, budgets, and the gap between procedure and practice. Engineers who have seen a control room at night design differently from those who have not.

The TMRP case in this book is synthetic; a placement is where you see how far a real utility's constraints differ from it. Notice how decisions are actually made, who owns operational risk and how long a simple change takes, because those observations will shape how you scope your capstone.

43.2 Placement agreement

Before starting, agree in writing: host supervisor and academic supervisor; scope of work; systems you may access and how; confidentiality and data handling; safety induction; what you may publish in your report; and how incidental findings are handled. You work under the host's authority and policies; your course gives you no authority to test or access anything.

The worked example's host approved the final report text before it left the organisation. Agreeing the publication rule in advance avoided any argument about what the report could include.

43.3 Reflective practice log

Keep a weekly log with four entries: observation (what you saw, without judgement), connection (which chapter's method it relates to), difference (where practice diverged from the method, and why it made sense locally), and question (what you would investigate). Reflection turns experience into transferable judgement. Do not record sensitive details in the log; record patterns.

In the worked example below, the student's observation about firmware versions follows exactly this pattern, and contains no device names. Weekly entries keep the habit.

43.4 Common placement work

Typical tasks for an engineering student: updating an asset inventory and reconciling it with network data (Chapter 22); drafting or reviewing a playbook (Chapter 37); supporting a risk assessment (Chapter 24); preparing a test procedure for a commissioning (Chapter 31); assessing advisories against the inventory (Chapter 12). Each produces a deliverable for the host and a sanitised learning artefact for the course.

The student in the worked example did the first task, reconciling an asset register with monitoring data. The student's deliverable to the host was a change to the work-order form.

43.5 Worked example: a sanitised placement report (synthetic)

A student placed with a (synthetic) regional electricity distributor writes a report section: "Observation: substation RTU firmware versions in the asset register differed from those observed in passive monitoring in 18% of a sample of 60 devices. Connection: Chapter 22's reconciliation of multiple inventory sources. Difference: the register is updated at annual maintenance visits, while firmware changes occur during unscheduled repairs; field staff had no simple way to report changes. Recommendation (accepted by host): add a firmware field to the repair work-order form and a quarterly reconciliation against monitoring data." No device names, addresses or locations appear; the host approved the text.

43.6 Practical activity

Draft a placement agreement for a hypothetical four-month placement at a water utility, covering all items in §43.2.

Use a water utility like LRWA as your mental model, but keep the agreement general enough for a real host to sign. Name both supervisors by role, list the systems you may see and how, and state plainly that you may not test or scan anything. Say how incidental findings are reported and who approves your report before it leaves the host. Add a safety induction date and the data you may take away, which should usually be none.

43.7 Common errors and limits

The worked example avoids each: its scope was agreed, its log recorded patterns rather than device details, and its recommendation took account of why the register lagged behind repairs. Its criticism of the register was framed around a process gap, not around the field staff, and the host accepted the recommendation because it fitted the way repairs were actually done.

Exercises — chapter 43

EX085 — Placement agreement. Objective: define placement boundaries. Inputs: §43.6. Steps: write the agreement. Expected evidence: one to two pages. Rubric: 3 = all §43.2 items, explicit prohibition on unscoped testing, incidental-finding route, publication approval; 2 = one missing; 1 = generic; 0 = none.

EX086 — Reflective entry. Objective: reflect usefully. Inputs: an observation: "operators kept a paper notebook of setpoint changes alongside the SCADA log". Steps: write a four-part log entry. Expected evidence: entry. Rubric: 3 = neutral observation, link to Chapters 13/37, local rationale (trust, outages, handover), investigative question; 2 = judgemental; 1 = observation only; 0 = none.

Chapter synthesis

Practice teaches the constraints that shape real designs. Work within a written agreement and the host's authority, log observations, connections, differences and questions without sensitive detail, and deliver value to the host in a form that is safe to share.

Worked answers

EX085. Assessed by rubric; the agreement must name supervisors, scope, access method, confidentiality, safety induction, publication approval, incidental-finding route and an explicit statement that the student will not test or explore systems outside the agreed tasks.

EX086. Observation: operators record setpoint changes in a paper notebook as well as in SCADA. Connection: Chapter 13 (provenance) and Chapter 37 (operations). Difference: practice duplicates the electronic log; locally rational because the notebook survives SCADA outages, supports shift handover and is trusted. Question: do the two records ever disagree, and could the notebook serve as an independent integrity check?