Control Software Developer

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

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

Control software scope

Table of contents

1. Purpose 2. Terminology 3. In scope 4. Out of scope 5. Safety and operational constraints 6. Roles and RACI 7. 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

In scope

Out of scope

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

Handoffs

DCS, PLC, and RTU architecture

Table of contents

1. Platform classes 2. Logic partitioning 3. Redundancy and failover 4. Engineering workflow 5. RTU and remote sites 6. Soft-PLC and PC control

Platform classes

Logic partitioning

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

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

Deployment, testing, and safety coordination

Table of contents

1. Test pyramid for control software 2. MIL and SIL (high level) 3. FAT and SAT hooks 4. Versioned OT deployment 5. Rollback and verification 6. Safety and security coordination

Test pyramid for control software

Prefer automated regression where vendor tooling allows; export traces for diff on logic changes.

MIL and SIL (high level)

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

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

Never recommend live-plant security testing (scanning, fuzzing, exploit validation) as part of application deploy—route to OT security with safety gates.

Historians, alarms, and HMI logic

Table of contents

1. Historian pipelines 2. Alarm philosophy 3. Events and SOE 4. HMI and SCADA server logic 5. Operator workflow 6. Performance and flooding

Historian pipelines

Document timestamp source (controller vs server vs gateway) for forensic alignment.

Alarm philosophy

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.

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

When graphics teams own pixels, control software still owns tag behavior, alarms, and server scripts—hand off visual design separately.

Industrial protocols and integration

Table of contents

1. Protocol selection 2. OPC UA 3. Modbus 4. DNP3 5. MQTT and AMQP 6. Gateways and quality 7. Security interfaces

Protocol selection

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

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.

Real-time loops and determinism

Table of contents

1. Scan-cycle model 2. Control loop patterns 3. Jitter and overrun 4. I/O synchronization 5. Soft-PLC and PC-based control 6. Evidence and measurement

Scan-cycle model

Control loop patterns

Jitter and overrun

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

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.