Instructor Guide | Teaching Operational Technologies

What This Guide Covers

This page is written for the faculty member who is about to teach — or is designing a section around — the Teaching Operational Technologies workshop (OT-101): a 12-lesson, 5-day faculty development course covering the history, technology, protocols, threats, governance, and operations of OT/ICS environments. It assumes you already have subject-matter footing and need to know how this particular site is put together so you can run it smoothly in a room full of instructors or students.

Work through it once before your first cohort, then keep the sidebar handy as a quick-reference during prep. The Pre-Class Link Audit section below is the single most important thing to check first — it will save you from discovering a broken link live in front of a class.

How the course home page and each lesson page are organized, and what every button and widget on them does
The generic anatomy of a lesson — content modules, activity, simulation, quiz — and how to facilitate each part
A realistic pacing plan across five days, including where the as-authored schedule runs long
How to introduce the Safeguards & Responsible Use policy and when to restate it
What the lab, simulator, and AI content-generation tools actually contain today, including where the label doesn't yet match the content

Pre-Class Link Audit

Do this first

⚠ Checked against the live site — some Faculty Resources and Dev Tools links are not yet wired up

Every link below was actually followed. A few cards on the course home page point to pages that don't exist yet, and two of the "Lab Activities" cards currently open different content than their description promises (they appear to be shared with the electronics/ELT-102 site). None of this breaks the 12 core lessons, which are complete and consistent — but you should know about it before a student clicks a dead link mid-class.

Solid Lessons 1–12 (lesson01.html–lesson12.html) — complete, consistent, and internally linked with correct prev/next navigation.
Missing Instructor Teaching Guide card → teaching-guide.html does not exist on the site yet. This page is designed to be saved under that exact filename to fill that gap — see the note in the FAQ.
Missing Safeguards & Responsible Use — "Read the full policy →" and the matching Faculty Resources card both point to safeguards.html, which does not exist. Until it's built, use the summary box on the course home page as the full policy text and read it aloud or project it for the acknowledgment step.
Missing Assessment & Rubric Bank card → assessments.html does not exist. For now, the per-lesson quiz embedded in each lesson's Review section is your assessment bank — see Assessment below.
Missing Graphics Generation and Content Generation cards link to gen-graphics.html and gen-content.html, which don't exist under those names. The working files are ot-gen-graphics.html and ot-gen-content.html — bookmark those directly, along with the unlinked bonus tools ot-gen-activities.html, ot-gen-casestudies.html, ot-gen-cheatsheets.html, and ot-gen-examples.html.
Content mismatch Hands-on Lab Exercises card (labs.html) describes Modbus, network-path, and syslog labs, but currently opens an Arduino sensor lab page (gas, flex, pressure, and temperature sensors, servo actuator) built for a different course. Preview it before assigning; it may still work as a supplementary hands-on activity, just not the one described.
Content mismatch OT Simulator Suite card (simulators.html) describes an ICS process, Modbus, syslog, NTP, and access-matrix simulator, but currently opens a solid-state electronics simulator library (op-amps, logic gates, flip-flops, a PLC simulator). The lesson-embedded simulations (air gap erosion, attack path, etc. — see Lesson Anatomy) are unaffected and are what you should rely on in class.
Solid Actuators & Mechanisms card (actuators-mechanisms.html) opens correctly and matches its description.

Practical takeaway Click every card on the course home page yourself, in the room you'll teach in, at least once before the workshop. It takes about ten minutes and it's the difference between a smooth session and improvising in front of a class.

Site Map & Navigation

The site has one hub page and a consistent template for every content page beneath it.

Course Home (index.html)

Opens with the dark header and course badge, then a hero panel with six colored "strand pills" showing how many lessons fall into each strand (Foundations, Protocols, Threats, Frameworks, Identity, Operations). Below that is the full Safeguards & Responsible Use summary — this is intentionally the first substantial thing on the page, not buried at the bottom, because it's meant to be read before anything else. Then a 12-lesson card grid organized by day, a Faculty Resources row (teaching guide, safeguards policy, assessment bank), a Lab Activities row, and a Content Development Tools row.

Every lesson page (lesson01.html–lesson12.html)

Same template throughout: a slim topbar with a "← Course Home" link and your institutional credit line; a dark header band with the lesson number, title, one-line tagline, and a meta row (difficulty, duration, objective count) plus the dark/light toggle and print button; a sticky section-nav strip of in-page tabs that highlights the section currently in view as a student scrolls; a two-column layout with the lesson content on the left and a sticky sidebar on the right; and a footer with the AI-assisted-draft disclosure.

Sidebar widgets, present on every lesson page
Widget	What it does	How to use it while teaching
On This Page	Jump-to-section table of contents	Point students here at the start of the lesson so they can see the shape of the session before you begin.
Objectives Progress	Checkbox list of the lesson's learning objectives with a live progress bar, saved in the browser via `localStorage`	Have students check items off as you finish each one — it's a built-in, zero-setup formative signal. Progress is per-device, not shared with you, so it's a self-check, not a gradebook.
Key Terms	A mini glossary of the lesson's vocabulary, each term linked back to where it's defined in the body	Use it as a two-minute pre-lesson vocabulary preview, or as a review tool before the quiz.
Lesson Navigation	Previous/next lesson links	Mostly useful for students working ahead or catching up asynchronously; in a live session you'll usually navigate from the course home page instead.

Header actions, both pages

The 🌙/☀️ toggle and 🖨 print button appear in both the course-home header and every lesson header — but see the FAQ for an important quirk: the theme choice does not carry over between the course home page and the lessons, because they're saved under two different keys.

Color-coded strands run through the whole site as a wayfinding device — each lesson card and its accent bar are tinted by strand, and the same colors appear in the progress strip on the course home page:

Foundations (L1–3) Protocols (L4–5) Threats (L6–7) Frameworks & Governance (L8–9) Identity (L10) Operations (L11) Capstone (L12)

Lesson Anatomy — How to Run One End to End

Lessons 1–11 share the same internal shape (Lesson 12, the capstone, swaps the activity/simulation/quiz block for a build-teach-critique structure — see the note at the end of this section). Here's the generic run-of-show and how to facilitate each part.

1. Lesson Overview

≈ 5 min

A short framing box at the top of the page states the objectives in plain language. Read these aloud or project them — this is also the list that populates the Objectives Progress checklist in the sidebar, so what you say here is literally what students will check off.

2. Content Modules (s1, s2, s3…)

≈ 2–2.5 hrs

The bulk of the lesson: numbered sections with body text, analogy boxes (amber-highlighted, for building intuition), worked examples (neutral gray, for concrete cases), comparison tables, and occasional timelines. Treat these as your lecture script, not slides to be read verbatim — the writing is dense enough to support cold-reading, but it lands better if you paraphrase and pause for questions between subsections rather than at the end of the whole block.

3. Activity

Individual, then pair-share≈ 15–25 min

An interactive matching, sorting, or scenario exercise embedded right in the page — dropdowns, buttons, or a short table students fill in, graded instantly with a "Check My Mapping"-style button and a per-row correct/incorrect indicator. Run it as designed: individual work first, then a pair-share to argue out disagreements before anyone hits Check. If you're short on time, the pair-share is the part to compress, not the individual attempt — that's where the thinking happens.

4. Simulation

≈ 10–15 min

A small, self-contained model — click a control, watch a meter or readout change, read the explanation that appears. These are deliberately labeled ⚠ Simulation only — no live equipment and are safe to demo live from your own machine while narrating out loud, or to hand students the room number/URL and have them click through in pairs. They work best as a discussion trigger — stop after each toggle and ask "why did that number move?" rather than letting students click through silently.

5. Review & Knowledge Check

≈ 15 min

A short auto-graded quiz with a "Grade My Quiz" button, per-item feedback, and a total score banner. Use it as an exit ticket: have everyone take it in the last ten minutes, then spend two minutes on whichever item the room got wrong most often — you won't know which one until you ask, since the grading is entirely client-side and nothing is reported back to you.

6. Further Reading

Take-home

A short curated list of external references. Good as an optional assignment before the next session, not as required pre-reading — the lesson itself doesn't assume students have read it.

Lesson 12 is different The capstone replaces the activity/simulation/quiz sequence with two extended blocks: a lecture on designing objectives, labs, rubrics, and feedback, followed by a hands-on lab where each participant builds, calibrates, teaches a segment of, and receives peer and instructor critique on their own teachable module. Budget it as a full working session, not a lecture day — plan for participants to be presenting to each other for a meaningful chunk of the four hours.

Pacing & Suggested Agenda

Every lesson page is labeled 4 contact hours, and the site groups all 12 lessons into 5 days. Do the math and the day boundaries aren't even: Day 1 and Day 5 carry three lessons apiece (12 hours), while Days 2–4 carry two apiece (8 hours) — 48 hours of authored content spread unevenly across a "5-day" course. Decide up front which of the three options below fits your calendar, rather than discovering the imbalance on Day 1 morning.

Three ways to fit this into a real schedule
Option	What it looks like	Best for
A. As-authored	Run Days 1 and 5 as long days (three 4-hour lessons, ~12 hrs with breaks) and Days 2–4 as standard days (two lessons, ~8 hrs).	Institutes where the first and last day are already expected to run long (opening logistics absorbed elsewhere, capstone presentations extending the last day anyway).
B. Six even days	Two lessons per day across six days (48 hrs ÷ 6 = 8 hrs/day), moving Lesson 3 to its own half-day slot or pairing it with Lesson 4.	Workshops that can add a day and want a uniform daily rhythm for participants commuting or juggling other duties.
C. Compressed five days	Trim each lesson to ~3.2 hrs by shortening the activity/simulation facilitation (see the compression notes in Lesson Anatomy) to fit 40 hrs over 5 standard days.	Grant-funded institutes locked to a Monday–Friday, 8-hour-a-day structure.

Day-by-day breakdown (as authored — click to expand):

Lesson 1 — From Isolated Plants to Converged Networks
Lesson 2 — IT/OT Security Principles
Lesson 3 — OT Technologies & Field Devices

Facilitation noteRead the Safeguards policy aloud before Lesson 1 begins and collect the acknowledgment form (see Safeguards) — this is the day it needs to happen.

Lesson 4 — IT Protocols Inside OT Networks
Lesson 5 — Industrial Communication Protocols

Facilitation noteThese two are the most technically dense lessons for anyone without a networking background. If your cohort skews non-technical, this is the day to slow down rather than Day 1.

Lesson 6 — The OT Threat Landscape
Lesson 7 — Vulnerabilities & Countermeasures

Facilitation noteLesson 6 leans on documented incidents as case studies — remind the room these are read for cause/impact/lesson-learned, not as attack procedure, consistent with the Safeguards policy's defensive-scope rule.

Lesson 8 — Frameworks for OT Security
Lesson 9 — Governance, Risk & Compliance for IT/OT

Facilitation noteThe heaviest lessons for a "why does this matter to me" pushback from technical participants. Anchor both in the compliance deadlines and audit evidence their own institutions already face.

Lesson 10 — Access Control & Identity Management in OT
Lesson 11 — Monitoring, Detection & OT Incident Response
Lesson 12 — Capstone: Build and Teach Your Own OT Module

Facilitation noteThe heaviest day and the one most likely to run over. If you're going to cut anything under time pressure, protect the capstone's teach-back block first — cut depth from Lesson 10 or 11 instead, since the capstone is the deliverable participants will actually take home.

Introducing Safeguards & Responsible Use

The course home page leads with an eight-point safeguards summary (safety outranks the exercise, simulation/isolated equipment only, air-gapped lab segments, defensive scope, incidents as case studies, protecting real-world data, faculty review of AI-generated content, and accessibility). Remember that the "Read the full policy →" link to safeguards.html is currently broken (see Pre-Class Link Audit), so the summary box on the course home page is the policy until that page is built.

When to cover it Before Lesson 1's activity, not before Lesson 1's lecture content — students should hear the "why" (OT controls physical processes) before the rules land. Restate the isolation and defensive-scope points specifically before the Day 3 threat-landscape case studies and again before the Day 5 capstone, since that's when students are producing content of their own that needs the same review standard applied to it.

Acknowledgment form The policy states every student signs an acceptable-use acknowledgment before the first hands-on lab. Since safeguards.html isn't live yet, print or project the summary box and collect a signature on paper or through your LMS before Lesson 1's activity begins — don't wait for the dedicated page.

Labs, Simulators & What They Actually Contain

Your most reliable hands-on material is embedded in each lesson — the Activity and Simulation blocks described in Lesson Anatomy. Treat the three standalone cards under "Lab Activities" on the course home page as a supplementary layer, and preview each one before you rely on it (details in the Pre-Class Link Audit above):

Hands-on Lab Exercises (labs.html) — currently Arduino sensor labs (gas, flex, pressure, temperature, servo), not the Modbus/network-path/syslog labs described. Usable as a physical-computing supplement if you have the hardware; not a substitute for the OT-specific labs the card promises.
OT Simulator Suite (simulators.html) — currently an electronics simulator library (op-amps, logic gates, flip-flops, a PLC simulator), not the bottle-filling ICS/Modbus/syslog/NTP/access-matrix suite described. The PLC simulator may still be worth a five-minute detour in Lesson 3 if you want to show field-device programming concretely.
Actuators & Mechanisms (actuators-mechanisms.html) — matches its description: valves, motors, drives, and cylinders, with failure-mode framing. Pairs well with Lesson 3's field-device tour.

Content Development Tools

These are for you, not your students — AI-assisted drafting tools for building or extending lesson material. The course home page links to gen-graphics.html and gen-content.html, which don't currently exist; use the working files directly instead:

ot-gen-graphics.html — Purdue model diagrams, network zone drawings, protocol stack illustrations, concept maps.
ot-gen-content.html — draft lesson text, quiz questions, and scenario descriptions.
ot-gen-activities.html, ot-gen-casestudies.html, ot-gen-cheatsheets.html, ot-gen-examples.html — additional generators not yet surfaced as cards on the course home page, but present and usable.

⚠ Faculty review required

Everything these tools produce is a first draft. Fact-check every generated diagram against a real reference before projecting it, and review every generated quiz item or scenario for technical accuracy before it reaches a student — this is one of the eight safeguards, not optional cleanup.

Common Misconceptions & Discussion Prompts

Most participants arrive with IT-security instincts that don't transfer cleanly to OT. These are the assumptions worth surfacing and correcting out loud, mapped to the lesson where the content directly addresses them.

Assumption: "OT security is just IT security applied to factories." Reality (Lesson 2): OT inverts the CIA triad — availability and safety usually outrank confidentiality, and a 20-year equipment lifecycle breaks the patch-and-replace cadence IT relies on.

Prompt: "What would you do differently if a system couldn't be rebooted for two years?"

Assumption: "An air gap means the network truly has no path to the outside." Reality (Lesson 1): Air gaps erode one reasonable-sounding business request at a time — a vendor's remote support link, a dashboard feed — until the "gap" is a policy, not a physical fact.

Prompt: "Which of your own institution's systems do you assume are isolated — and when did anyone last verify that?"

Assumption: "If it uses TCP/IP, standard IT tools and settings will work fine on it." Reality (Lesson 4): Static addressing and local time sources persist in OT for good reasons; DHCP and default NTP configured like an office LAN can break control-loop timing and device discovery.

Prompt: "Why might a plant engineer refuse a 'simple' DHCP rollout that IT considers routine?"

Assumption: "Legacy protocols without authentication are just outdated and need to be patched." Reality (Lesson 5): Protocols like Modbus and DNP3 were designed for trusted, isolated networks; the fix is architectural (segmentation, monitoring) more often than it is a patch, since many field devices can't be patched at all.

Prompt: "If you can't add authentication to the protocol, where else can you add it?"

Assumption: "Incident response means isolate the affected host first, ask questions later." Reality (Lesson 11): Isolating a host that's actively controlling a physical process may not be a choice the plant can accept — the containment decision has to weigh process safety, not just the security playbook.

Prompt: "What has to be true before you're allowed to pull the plug on a live control system?"

Assumption: "One compliance framework should cover this, the way one framework often covers IT." Reality (Lesson 8): IEC 62443, NIST SP 800-82/CSF, and ISO/IEC 27001 overlap but diverge in scope and vocabulary — course design means picking one spine deliberately, not teaching all four in parallel.

Prompt: "If you had to pick one framework as your course's backbone, which would you choose and why?"

Assessment, Today and Later

The course home page advertises a dedicated Assessment & Rubric Bank (assessments.html), which isn't built yet (see Pre-Class Link Audit). Until it exists, your assessment tools are:

Per-lesson quizzes — the auto-graded Review & Knowledge Check at the end of each lesson (Lessons 1–11), five questions each with explanatory feedback. Client-side only, so scores aren't reported to you; use them as a student self-check and exit-ticket discussion trigger, not a recorded grade, unless you screen-capture or otherwise collect the result yourself.
The capstone (Lesson 12) — the closest thing to a summative assessment on the site: each participant produces a teachable module with objectives, one hands-on simulation, an assessment with a rubric, and a written safeguards statement, then teaches a segment and takes peer and instructor critique. Build your own simple rubric for this (objectives clarity, simulation design, rubric quality, safeguards statement, delivery) until a shared one is published.

How to Teach With This Site