references/control_software_scope.md
# Control software scope
## Table of contents
1. [Purpose](#purpose)
2. [Terminology](#terminology)
3. [In scope](#in-scope)
4. [Out of scope](#out-of-scope)
5. [Safety and operational constraints](#safety-and-operational-constraints)
6. [Roles and RACI](#roles-and-raci)
7. [Handoffs](#handoffs)
## Purpose
Define **industrial control application software** boundaries—the logic and integration layers that execute control strategies, exchange process data, and drive HMI/SCADA behavior above field devices.
This skill covers **design, implementation patterns, integration, and deploy planning**—not live plant operation, OT security program ownership, or safety certification.
## Terminology
| Term | Meaning |
|---|---|
| BPCS | Basic process control system—regulatory and sequence control (non-SIS) |
| SIS | Safety instrumented system—separate from BPCS; highest change caution |
| DCS | Distributed control system—integrated controllers and engineering environment |
| PLC | Programmable logic controller—often ladder/ST/function blocks |
| RTU | Remote terminal unit—telemetry and control at remote sites |
| Soft-PLC | PC-based control runtime emulating PLC semantics (IEC 61131 environments) |
| Scan cycle | Periodic execution of control tasks and I/O refresh |
| Historian | Time-series archive of process values and metadata |
| SOE | Sequence of events—timestamped alarm/event ordering |
| MIL / SIL | Model-in-the-loop / software-in-the-loop simulation (high level here) |
## In scope
| Area | Examples |
|---|---|
| Control logic | PID, cascade, ratio, interlocks, sequences, state machines, mode management |
| Integration | OPC UA, Modbus, DNP3, MQTT/AMQP, protocol gateways, quality and timestamps |
| Architecture | Controller partitioning, redundancy, tag model, download areas |
| Data pipelines | Historian sampling, alarm routing, event correlation |
| HMI/SCADA logic | Server scripts, calculations, command validation, faceplate rules |
| Determinism | Scan rate, task order, I/O sync, overrun handling |
| Simulation | MIL/SIL interfaces, stub I/O, regression scenarios (not cert) |
| Deployment | Versioning, staging, rollback, FAT/SAT software hooks |
## Out of scope
| Topic | Route to |
|---|---|
| OT network segmentation, IEC 62443 program, passive monitoring | `scada-ics-cyber-security-specialist` |
| MCU ISR/RTOS, bare-metal drivers, chip WCET | `embedded-real-time-software-engineer` |
| HIL security bench, bus fault injection for security | `hardware-in-the-loop-security-tester` |
| Enterprise web/API backends | `senior-software-engineer` |
| Criticality tiering without control implementation | `mission-critical` |
| HRO culture and organizational prevention metrics | `zero-tolerance-for-failure` |
| SIL/LOPA and formal safety case | Site process safety / engineering |
| Graphics-only HMI design | UX/design skills as appropriate |
| Live CSIRT on OT networks | `incident-responder` + OT security peers |
## Safety and operational constraints
**Never instruct** the agent or operator to:
- Download logic to running production controllers without operations and change-control approval
- Modify SIS logic or bypass interlocks without documented process-safety authorization
- Change setpoints or outputs on live equipment from software examples without site runbooks
- Disable alarms, historians, or audit trails to “fix” performance without risk acceptance
**Prefer instead:**
- Staged controllers, simulation, and maintenance windows per site procedures
- Document tag impacts, rollback packages, and verification checklists before field deploy
- Explicit separation between BPCS application changes and SIS changes
## Roles and RACI
| Activity | Control software dev | Operations | OT security | Process safety | Vendor OEM |
|---|---|---|---|---|---|
| Application logic design | A | C | I | C | C |
| Protocol/integration design | A | I | C | I | C |
| Production download approval | C | A | I | C | C |
| OT hardening and monitoring | I | I | A | I | C |
| SIS logic changes | C | C | I | A | C |
| MIL/SIL test execution | A | C | I | C | C |
## Handoffs
| To skill | When |
|---|---|
| `scada-ics-cyber-security-specialist` | New remote access paths, OPC/MQTT exposure, zone impacts, monitoring use cases |
| `embedded-real-time-software-engineer` | Custom I/O modules, firmware on embedded targets running control runtime |
| `hardware-in-the-loop-security-tester` | Security validation on benches with real controllers and buses |
| `mission-critical` | Tiering, RTO/RPO, redundancy requirements spanning IT/OT |
| `zero-tolerance-for-failure` | Verification gates, pre-mortem, defect-escape prevention for control releases |
references/dcs_plc_rtu_architecture.md
# DCS, PLC, and RTU architecture
## Table of contents
1. [Platform classes](#platform-classes)
2. [Logic partitioning](#logic-partitioning)
3. [Redundancy and failover](#redundancy-and-failover)
4. [Engineering workflow](#engineering-workflow)
5. [RTU and remote sites](#rtu-and-remote-sites)
6. [Soft-PLC and PC control](#soft-plc-and-pc-control)
## Platform classes
| Class | Strengths | Typical application layer |
|---|---|---|
| DCS | Integrated IO, advanced control libraries, uniform HMI | Continuous process, complex regulatory control |
| PLC | Rugged, discrete/batch, vendor ecosystems | Machines, utilities, distributed skids |
| RTU | Telemetry-focused, comms-efficient remote sites | Pipelines, wells, substations (with DNP3) |
| Soft-PLC / PC | Flexibility, IT-like tooling | Hybrid lines, retrofit, analytics-adjacent control |
## Logic partitioning
| Rule | Rationale |
|---|---|
| One clear owner per interlock | Avoid split logic across controllers without documented interface |
| Minimize cross-controller writes in fast loops | Latency and fault modes multiply |
| Group by unit/area | Align downloads with operations outages |
| Isolate experimental logic | Staging CPU or simulation partition before merge |
Document **interface tags** between controllers: direction, rate, fail-safe values, and timeout behavior.
## Redundancy and failover
- Clarify **1oo2**, hot-standby, or vendor-specific redundancy for CPUs and networks
- Define **bump-less transfer** expectations for outputs and integrators
- Plan **I/O redundancy** vs **controller redundancy** separately
- Test failover with **loaded comms** and maintenance activities—not idle benches only
## Engineering workflow
| Artifact | Content |
|---|---|
| Tag dictionary | Name, engineering units, limits, alarm classes, access level |
| Logic modules | Areas, programs, routines; version and author metadata |
| Download package | Target controller, checksum, prerequisites, rollback image |
| Simulation hook | MIL/SIL mapping of tags to model I/O |
Enforce **check-in/out** or vendor equivalent; align with site change management.
## RTU and remote sites
- Prefer **exception-based reporting** for WAN links; define offline store-and-forward
- Separate **monitoring** from **control** paths where security architecture requires
- Document **latency-sensitive** controls that must not run across high-latency links
- Plan battery/ power fail behavior for comms equipment affecting control visibility
## Soft-PLC and PC control
- Match **IEC 61131** language choices to maintainer skills (LD/FBD/ST/SFC)
- Define runtime **startup order**: comms before outputs enabled, safe defaults on boot
- Coordinate with `embedded-real-time-software-engineer` when custom I/O or kernel drivers are in scope
- Avoid mixing IT patch cadence with OT validation windows without explicit risk acceptance
references/deployment_testing_and_safety.md
# Deployment, testing, and safety coordination
## Table of contents
1. [Test pyramid for control software](#test-pyramid-for-control-software)
2. [MIL and SIL (high level)](#mil-and-sil-high-level)
3. [FAT and SAT hooks](#fat-and-sat-hooks)
4. [Versioned OT deployment](#versioned-ot-deployment)
5. [Rollback and verification](#rollback-and-verification)
6. [Safety and security coordination](#safety-and-security-coordination)
## Test pyramid for control software
| Layer | Focus |
|---|---|
| Unit/module | Function blocks, sequences, state machines with injected I/O |
| Integration | Protocol mappings, gateway transforms, historian collectors |
| System | Controller + HMI server + comms on staging hardware |
| Regression | Golden traces for loops after logic changes |
| Field | FAT/SAT checklists—operations-led with engineering support |
Prefer **automated regression** where vendor tooling allows; export traces for diff on logic changes.
## MIL and SIL (high level)
| Type | Intent | This skill provides |
|---|---|---|
| MIL | Plant/model simulated; control logic connected to model I/O | Interface spec, tag mapping, scenario list |
| SIL | Controller/runtime tested against simulated or recorded I/O | Staging configs, test harness hooks |
**Does not** certify SIL levels or replace process-safety engineering. Document assumptions and gaps explicitly.
## FAT and SAT hooks
- Deliver **test cases** tied to tag scenarios: modes, trips, comms loss, manual override
- Provide **expected traces** (trend snapshots) for critical sequences
- Include **alarm verification** matrix: trigger, priority, shelving behavior
- Stage **protocol load tests** before connecting enterprise consumers
## Versioned OT deployment
| Artifact | Versioning practice |
|---|---|
| Controller logic | Vendor project version + git export where possible |
| HMI server scripts | Semantic version aligned with logic package |
| Protocol maps | Separate version id; checksum in deploy manifest |
| Certificates | Track expiry in deploy prerequisites |
Deployment steps (generic):
1. Freeze package in staging; run regression and MIL/SIL suites
2. Operations change ticket and outage window
3. Backup running config; deploy to standby first if redundant
4. Verify I/O feedback, alarms, historian, and critical sequences
5. Promote to active; monitor overrun and comms health
6. Archive manifest and sign-offs
## Rollback and verification
- Keep **last-known-good** images per controller area
- Define **rollback triggers**: failed sequence test, unexpected alarms, comms storm
- Verify rollback on **staging** periodically—not only during emergencies
- Post-deploy: capture **24–72h** monitoring checklist for integrator windup and alarm rationalization
## Safety and security coordination
| Topic | Control software role | Peer |
|---|---|---|
| SIS separation | Never merge; document interfaces only | Process safety |
| Unsafe downloads | Stop; require operations approval | Operations |
| New exposure (OPC/MQTT/cloud) | Document data flows and write paths | `scada-ics-cyber-security-specialist` |
| Bench security tests | Provide builds and mappings | `hardware-in-the-loop-security-tester` |
| Criticality / DR expectations | State dependencies and RTO needs | `mission-critical` |
| Release discipline / HRO gates | Checklists, independent verification | `zero-tolerance-for-failure` |
**Never** recommend live-plant security testing (scanning, fuzzing, exploit validation) as part of application deploy—route to OT security with safety gates.
references/historians_alarms_and_hmi_logic.md
# Historians, alarms, and HMI logic
## Table of contents
1. [Historian pipelines](#historian-pipelines)
2. [Alarm philosophy](#alarm-philosophy)
3. [Events and SOE](#events-and-soe)
4. [HMI and SCADA server logic](#hmi-and-scada-server-logic)
5. [Operator workflow](#operator-workflow)
6. [Performance and flooding](#performance-and-flooding)
## Historian pipelines
| Element | Guidance |
|---|---|
| Sampling | Align to control relevance—not every tag at fastest rate |
| Compression | Deadband and swing-door policies per tag class |
| Metadata | Units, limits, instrument type, asset hierarchy for analytics |
| Retention | Hot/warm/cold tiers; legal/operations retention separately |
| Ingress | Buffer at collector; handle back-pressure from slow archives |
Document **timestamp source** (controller vs server vs gateway) for forensic alignment.
## Alarm philosophy
| Item | Practice |
|---|---|
| Priority model | Consistent P1–P4 (or site standard) mapped to response time |
| Alarm vs alert | Alarms require operator action; alerts are informational |
| Shelving / suppression | Time-bound, attributed, auditable; avoid permanent suppression |
| Chattering | Debounce, hysteresis, or deadband at source—not only in HMI |
| Standing alarms | Regular rationalization reviews with operations |
## Events and SOE
- Capture **sequence of events** with millisecond resolution where process requires
- Correlate SOE with historian trends for post-trip analysis
- Define **flood handling** during plant upsets—summary alarms vs raw storm
- Export formats for CMMS and incident reviews (coordinate with operations)
## HMI and SCADA server logic
This skill covers **server-side behavior**, not screen graphics alone.
| Capability | Examples |
|---|---|
| Calculations | Derived tags, mass/energy balances, KPI rollups |
| Command validation | Role checks, interlock verification before write |
| Faceplate logic | Min/max enforcement, mode labels, permissive display |
| Scripts | Scheduled reports, aggregated statuses, comms health |
| Navigation rules | Deep links, forced acknowledgment workflows |
Document **write paths**: who can command, through which service, with what timeout and feedback.
## Operator workflow
- Align alarm text with **operations vocabulary**—avoid vendor-generic messages
- Provide **recommended action** fields where standards allow
- Separate **control** faceplates from **monitoring** dashboards for critical tags
- Test workflows under **loss of comms** and **degraded quality** scenarios
## Performance and flooding
| Risk | Mitigation |
|---|---|
| Alarm storms | Rate limits, grouping, first-out capture, dynamic suppression policies |
| Historian overload | Tiered sampling, edge buffering, drop policies for non-critical tags |
| HMI script load | Move heavy analytics to services; keep scan-synchronous work minimal |
| Client fan-out | OPC subscription tuning; MQTT topic QoS choices |
When graphics teams own pixels, control software still owns **tag behavior, alarms, and server scripts**—hand off visual design separately.
references/industrial_protocols_and_integration.md
# Industrial protocols and integration
## Table of contents
1. [Protocol selection](#protocol-selection)
2. [OPC UA](#opc-ua)
3. [Modbus](#modbus)
4. [DNP3](#dnp3)
5. [MQTT and AMQP](#mqtt-and-amqp)
6. [Gateways and quality](#gateways-and-quality)
7. [Security interfaces](#security-interfaces)
## Protocol selection
| Need | Typical choice | Caveat |
|---|---|---|
| Plant-wide data model, rich typing | OPC UA | Server capacity, certificate lifecycle |
| Simple register access, legacy devices | Modbus TCP/RTU | No built-in discovery; endianness and mapping errors |
| Electric utility telemetry/control | DNP3 | Strict addressing and event buffering semantics |
| Cloud/IT analytics fan-out | MQTT / AMQP | Not a substitute for deterministic control paths |
| High-rate control I/O | Fieldbus/vendor I/O (document only) | Route deep fieldbus design to vendor docs + embedded peer if custom |
## OPC UA
- Define **namespace**, node IDs, and browse paths in a tag dictionary shared with HMI/historian
- Specify **subscription** rates, queue sizes, and discard policies for overload
- Plan **certificates**, trust lists, and renewal without breaking production clients
- Separate **read-only** analytics clients from **write-capable** operators; gate writes in server logic
## Modbus
- Document **register map** (function codes, scaling, signedness, word order)
- Handle **exception responses** and comm timeouts with explicit quality degradation
- Avoid using Modbus as sole SOE path—timestamps are often weak compared to native event systems
- Rate-limit concurrent masters to protect fragile serial devices
## DNP3
- Clarify **outstation vs master** roles, event classes, and unsolicited responses
- Plan buffer sizes for comm outages; define backfill behavior
- Align **time sync** strategy with SOE requirements
- Treat control commands with **select-before-operate** patterns where required
## MQTT and AMQP
| Pattern | Use |
|---|---|
| Sparkplug B / UDT-style topics | Normalized plant metrics to cloud with birth/death certificates |
| Command topics | Only with authentication, ACLs, and server-side validation—never direct unguarded writes |
| AMQP routing | Enterprise integration, work queues, audit-friendly consumers |
Document **at-least-once** semantics: idempotent consumers, dedup keys, and stale command rejection.
## Gateways and quality
- Place gateways at **zone boundaries** per OT architecture (coordinate with `scada-ics-cyber-security-specialist`)
- Propagate **quality flags** (good, uncertain, bad) through mappings—do not coerce bad to good
- Define **back-pressure**: when historian or cloud sinks lag, shed non-critical publishes first
- Maintain **mapping version** alongside logic version for rollback
## Security interfaces
This skill does not own OT hardening. When adding protocols, deliver to OT security:
- New listen ports, brokers, and certificate stores
- Write paths and authentication models
- Data exfiltration surfaces (cloud historians, remote vendors)
Route control testing of security features to `scada-ics-cyber-security-specialist` and bench security to `hardware-in-the-loop-security-tester` as appropriate.
references/realtime_loops_and_determinism.md
# Real-time loops and determinism
## Table of contents
1. [Scan-cycle model](#scan-cycle-model)
2. [Control loop patterns](#control-loop-patterns)
3. [Jitter and overrun](#jitter-and-overrun)
4. [I/O synchronization](#io-synchronization)
5. [Soft-PLC and PC-based control](#soft-plc-and-pc-based-control)
6. [Evidence and measurement](#evidence-and-measurement)
## Scan-cycle model
| Concept | Guidance |
|---|---|
| Cycle time | Choose from process dynamics (fast loops vs slow sequences); document minimum stable period |
| Task order | Define deterministic order: inputs → logic → outputs; avoid hidden reorder across vendors |
| Fast vs slow tasks | Partition high-rate loops from slow sequences; avoid starving fast tasks |
| Redundancy | Clarify primary/standby execution, bump-less transfer, and I/O failover semantics |
## Control loop patterns
| Pattern | Notes |
|---|---|
| PID / regulatory | Anti-windup, bumpless transfer, mode tracking (auto/manual/cascade) |
| Cascade / ratio | Subordinate limits, saturation handling, explicit mode per layer |
| Sequences | Step timers, permissives, abort paths, hold/resume, interlock precedence |
| Interlocks | Hard vs soft; never implement SIS functions in BPCS without explicit boundary |
| State machines | Explicit states, illegal transition handling, logging on transitions |
## Jitter and overrun
| Signal | Action |
|---|---|
| Cycle overrun | Define shed policy: skip non-critical work, alarm, safe output hold |
| Jitter budget | Allocate % of cycle to I/O, logic, comms; measure before tuning gains |
| Watchdog | Align software watchdog with hardware/OS watchdog where present |
| Timestamping | Use consistent clock source for SOE; document leap/smear behavior at integration |
## I/O synchronization
- Map physical I/O refresh to scan boundaries; document one-scan delay where unavoidable
- For networked I/O, include transport latency in control design (do not assume wire-speed)
- For buffered inputs, define validity windows and stale-data handling
- Document bad-quality I/O behavior: last-good-value vs fail-safe vs forced safe state per tag class
## Soft-PLC and PC-based control
| Topic | Guidance |
|---|---|
| Runtime isolation | Prefer dedicated industrial PCs or RT hypervisor partitions for determinism |
| OS jitter | Measure under load; avoid best-effort scheduling for fast loops |
| NIC offload | Document interrupt load from high-rate protocols |
| Storage | Separate config/logs from control runtime disk; plan wear and corruption recovery |
## Evidence and measurement
Produce a **timing budget table**: cycle time, measured worst case, overrun policy, and test method (logic analyzer, vendor diagnostics, built-in profilers).
For disputes between teams, prefer **measured traces** over nominal vendor marketing cycle times.
SKILL.md
---
name: control-software-developer
description: |
Guides industrial control application software—real-time loops and application layers above field
devices; DCS/PLC/RTU integration; OPC UA, Modbus, DNP3, MQTT/AMQP; historian and alarm/event
pipelines; HMI/SCADA server-side logic (not graphics-only); soft-PLC/PC control; deterministic scan
cycles; MIL/SIL (high level); versioned OT deploy; coordination with OT security/safety without
owning plant ops. Use for control logic, PLC/DCS apps, protocol integration, historian/alarms, SCADA
server logic, scan-cycle determinism, MIL/SIL planning, OT software deployment—not OT cyber only
(scada-ics-cyber-security-specialist), MCU firmware only (embedded-real-time-software-engineer),
HIL security bench (hardware-in-the-loop-security-tester), enterprise web/backend
(senior-software-engineer), tiering without control depth (mission-critical), HRO only
(zero-tolerance-for-failure).
---
# Control Software Developer
## When to Use
- Design **control application software** above field I/O—loops, sequences, interlocks, mode logic, permissives
- Integrate **DCS, PLC, RTU**, and soft-PLC/PC-based controllers with consistent tag and alarm models
- Implement **industrial protocols**—OPC UA, Modbus, DNP3, MQTT/AMQP, and gateway patterns in modern stacks
- Build **historian, alarm, and event** pipelines—priorities, shelving, flood suppression, SOE correlation
- Author **HMI/SCADA server-side logic**—scripts, calculations, faceplate behavior, command validation (not graphics-only UX)
- Engineer **deterministic scan cycles**—jitter budgets, task partitioning, I/O synchronization, watchdog coupling
- Plan **MIL/SIL** at a high level—simulation interfaces, stub I/O, regression suites before field deploy
- Define **versioned OT deployment**—staging, rollback, checksums, change windows, coordination with operations
- Coordinate **safety and security interfaces**—SIS boundaries, write constraints, audit trails (without owning OT IR or plant ops)
## When NOT to Use
- **OT cyber program**, Purdue segmentation, IEC 62443 gap assessment, passive ICS monitoring → `scada-ics-cyber-security-specialist`
- **Bare-metal MCU firmware**, ISR/RTOS on chip, WCET on MCU, driver bring-up without plant application layer → `embedded-real-time-software-engineer` (unless implementing control stack on that target)
- **HIL security bench**, bus fault injection, authorized exploitation on hardware rigs → `hardware-in-the-loop-security-tester`
- **Generic backend**, APIs, microservices, or cloud SaaS without control-cycle constraints → `senior-software-engineer`
- **Criticality tiering**, RTO/RPO, enterprise redundancy patterns without control logic → `mission-critical`
- **HRO culture**, stop-the-line, defect-escape metrics without implementation → `zero-tolerance-for-failure`
- **Process safety engineering** (SIL calculation, LOPA) or legal certification claims → site process safety / engineering
- **HMI graphics-only** UX, branding, or visual design systems → design/frontend skills as appropriate
## Related skills
| Need | Skill |
|---|---|
| OT/ICS security, segmentation, monitoring, hardening roadmaps | `scada-ics-cyber-security-specialist` |
| MCU/RTOS firmware, drivers, WCET on embedded targets | `embedded-real-time-software-engineer` |
| HIL security assessment, bus injection on benches | `hardware-in-the-loop-security-tester` |
| Mission-critical tiering, availability objectives | `mission-critical` |
| Failure-prevention culture, verification gates, FMEA mindset | `zero-tolerance-for-failure` |
| Enterprise backend and cloud services | `senior-software-engineer` |
| SRE SLOs and service reliability (IT/cloud) | `site-reliability-engineer` |
| BCM/DR program and crisis continuity | `bcm-disaster-recovery-specialist` |
## Core Workflows
### 1. Scope and role boundaries
Define control-application boundaries, safety interfaces, and handoffs with operations, OT security, and embedded teams.
**See `references/control_software_scope.md`.**
### 2. Real-time loops and determinism
Design scan cycles, loop execution order, jitter acceptance, and synchronization with I/O and higher-level applications.
**See `references/realtime_loops_and_determinism.md`.**
### 3. Industrial protocols and integration
Select protocol stacks, address mapping, quality flags, gateway placement, and back-pressure for historians and cloud bridges.
**See `references/industrial_protocols_and_integration.md`.**
### 4. DCS / PLC / RTU architecture
Partition logic across controllers, redundancy, download semantics, and engineering workstation workflows.
**See `references/dcs_plc_rtu_architecture.md`.**
### 5. Historians, alarms, and HMI logic
Model alarms, events, shelving, historian compression, and server-side HMI/SCADA behavior.
**See `references/historians_alarms_and_hmi_logic.md`.**
### 6. Deployment, testing, and safety coordination
Plan FAT/SAT hooks, MIL/SIL staging, versioned deploy, rollback, and coordination with OT security without unsafe live changes.
**See `references/deployment_testing_and_safety.md`.**
## Outputs
- **Control application design** — loops, sequences, modes, interlocks, tag dictionary, execution order
- **Integration specification** — protocol roles, endpoints, scan rates, exception handling, gateway map
- **Scan-cycle and timing budget** — cycle time, task split, I/O latency, watchdog and overrun handling
- **Alarm and event model** — priorities, classes, shelving rules, flood logic, SOE requirements
- **Historian pipeline design** — sampling, compression, retention, archival handoff
- **HMI/SCADA logic spec** — server scripts, validations, command gating (not screen mockups alone)
- **Deploy and rollback runbook** — versions, checksums, staging path, verification steps, operations sign-off
- **MIL/SIL test outline** — stubs, scenarios, acceptance criteria (high level; not safety certification)
- **Handoff notes for OT security** — attack surfaces introduced by new integrations (for `scada-ics-cyber-security-specialist`)
## Principles
- **Respect scan-cycle determinism** — document cycle time, execution order, and overrun behavior before optimizing
- **Keep safety systems separate** — do not merge SIS/BPCS logic; enforce write constraints and proven separation
- **Never instruct unsafe live-plant changes** — require operations authorization for downloads affecting running process
- **Prefer simulation before field** — MIL/SIL and staged controllers before production OT networks
- **Version everything** — logic, configs, HMI server scripts, and protocol maps with traceable deploy artifacts
- **Coordinate, do not own OT security or plant ops** — frame risks and interfaces; route hardening and operations decisions to peers
- **Separate graphics from control logic** — HMI pixels are not a substitute for documented server-side behavior and alarms
## When to load references
| Topic | Reference |
|---|---|
| Role scope, terminology, RACI | `references/control_software_scope.md` |
| Scan cycles, loops, jitter, determinism | `references/realtime_loops_and_determinism.md` |
| OPC UA, Modbus, DNP3, MQTT/AMQP | `references/industrial_protocols_and_integration.md` |
| DCS, PLC, RTU, soft-PLC patterns | `references/dcs_plc_rtu_architecture.md` |
| Historians, alarms, HMI server logic | `references/historians_alarms_and_hmi_logic.md` |
| Deploy, MIL/SIL, testing, safety gates | `references/deployment_testing_and_safety.md` |