+---
+title: Control Systems Integration and Testing
+category: Instrumentation & Controls / Integration & Commissioning
+toc_depth: 3
+description: >
+ When to use: The integration and commissioning scope owned by the control system integrator (CSI) or master systems integrator on an industrial, process, or water and wastewater (WTP/WWTP) project. Covers the division of responsibility between the integrator and the electrical and mechanical/process trades; the written control narratives and process control descriptions (the sequences of operation); I/O lists and point/tag naming per ANSI/ISA-5.1; control loop descriptions and loop diagrams per ISA-5.4; the software development and configuration management workflow; integration of third-party OEM and packaged-skid controls into the plant SCADA; factory acceptance testing (FAT) and site acceptance testing (SAT) per ANSI/ISA-62381; loop checks and point-to-point checkout with instrument calibration and valve stroke coordination; startup and commissioning including the performance verification and endurance tests; operator and maintenance training; documentation, as-builts, and O&M; and OT cybersecurity coordination per ISA/IEC 62443. Where safety instrumented functions exist, references IEC 61511 verification at the integration seam. This standard governs the platform and the process that execute the plant's sequences; the equipment and field devices that the platform commands are governed by the sibling standards and are referenced, not duplicated.
+
+ Not intended for: The equipment itself — programmable logic controllers ([[sync/programmable-logic-controllers]]), the SCADA/HMI platform ([[sync/scada-and-hmi-systems]]), process instrumentation ([[sync/process-instrumentation]]), flow measurement ([[sync/flow-measurement]]), analytical instrumentation ([[sync/analytical-instrumentation]]), control valves and actuators ([[sync/control-valves-and-actuators]]), industrial control panels ([[sync/industrial-control-panels]]), and the process control network media and devices ([[sync/process-control-networks]]) are each specified in their own standard. Commercial-building HVAC controls integration is governed by [[sync/building-automation-system]], not this standard. Motor starting and protection are governed by [[sync/motor-control-centers]]. The full functional-safety lifecycle (hazard and risk analysis, SIL determination, SIS hardware design) is the work of the process safety engineer and the SIS standard; this standard addresses only the integration-seam verification of safety functions that traverse the basic process control system.
+---
+
+# Scope {toc}
+
+## This specification covers the integration, configuration, programming, testing, and commissioning work performed by the control system integrator to assemble individually furnished controllers, instruments, valves, panels, networks, and packaged-equipment controls into one coordinated plant control system that executes the project's documented sequences of operation. {note}
+## The integrator's deliverables addressed here are the control narratives and process control descriptions, the I/O and tag database, the configured controller logic and SCADA/HMI application, the integration of third-party and packaged-skid controls, the factory and site acceptance tests, the loop checks and commissioning, the operator training, and the closeout documentation and as-builts. {note}
+## This standard applies to new plants, plant expansions, and control system replacements (migrations) in industrial, process, and municipal water and wastewater facilities. {note}
+
+## This standard governs the platform and the engineering process that execute the plant's sequences; the field equipment and devices that the platform commands are governed by their own standards and are referenced here, not duplicated. {note}
+
+## The integrator shall execute the control strategy defined in the contract control narratives, the P&IDs, and the input/output schedules, and shall coordinate the work of this standard with [[sync/programmable-logic-controllers]], [[sync/scada-and-hmi-systems]], [[sync/process-instrumentation]], [[sync/flow-measurement]], [[sync/analytical-instrumentation]], [[sync/control-valves-and-actuators]], [[sync/industrial-control-panels]], and [[sync/process-control-networks]].
+
+## Where the contract documents, the adopted code, or a referenced standard conflict, the more stringent requirement shall govern unless the Engineer of Record directs otherwise in writing.
+
+## Scope Boundaries {toc}
+
+### The field devices the integrator commands — controllers, the SCADA/HMI platform, instruments, analyzers, flow meters, control valves, panels, and network media — are each furnished and warranted under their own standards; this standard governs only their integration into a working system. {note}
+
+### Cybersecurity provisions in this standard are the integration-seam responsibilities of the integrator — secure configuration, account setup, network segmentation coordination, and hardening of the delivered application — applied within the zone-and-conduit architecture established by ISA/IEC 62443; the Owner's OT security program governs above this baseline. {note}
+
+### Where the basic process control system interfaces with a safety instrumented system, this standard governs only the verification that the interface behaves as designed; the safety lifecycle, SIL determination, and SIS design are governed by IEC 61511 and the project process-safety scope. {note}
+
+### The integrator shall not modify the configuration of any safety instrumented function logic solver except as authorized in writing under the project functional-safety management of change procedure.
+
+# Referenced Standards {toc}
+
+## Work under this standard shall comply with the latest adopted edition of the following standards unless a specific edition is cited.
+## Where conflicts exist between referenced standards, the more stringent requirement shall govern unless the Engineer of Record directs otherwise in writing.
+
+| Standard | Title |
+|----------|-------|
+| ANSI/ISA-5.1 | Instrumentation Symbols and Identification |
+| ANSI/ISA-5.4 | Instrument Loop Diagrams |
+| ISA-5.06.01 | Functional Requirements Documentation for Control Software Applications |
+| ANSI/ISA-62381 (IEC 62381 modified) | Automation Systems in the Process Industry — Factory Acceptance Test (FAT), Site Acceptance Test (SAT), and Site Integration Test (SIT) |
+| ISA-TR105.00.01 | Documentation of FAT/SAT/SIT for Automation Systems |
+| ANSI/ISA-101.01 | Human Machine Interfaces for Process Automation Systems |
+| ANSI/ISA-18.2 | Management of Alarm Systems for the Process Industries |
+| ANSI/ISA-88.00.01 | Batch Control — Part 1: Models and Terminology |
+| ANSI/ISA-95.00.01 | Enterprise-Control System Integration — Part 1: Models and Terminology |
+| ANSI/ISA-106 | Procedure Automation for Continuous Process Operations |
+| ANSI/ISA/IEC 62443 (series) | Security for Industrial Automation and Control Systems |
+| IEC 61511 / ANSI/ISA-84.00.01 | Functional Safety — Safety Instrumented Systems for the Process Industry Sector |
+| IEEE 1012 | System, Software, and Hardware Verification and Validation |
+| NIST SP 800-82 | Guide to Operational Technology (OT) Security |
+| NFPA 70 | National Electrical Code (Articles 725 — Class 2 control circuits, 800 — Communications) |
+| NFPA 79 | Electrical Standard for Industrial Machinery (functional testing of control functions) |
+| ISA-84 / ISA-91 | Identification and Application of Safety Instrumented and Permissive Functions |
+| 10 States Standards | Recommended Standards for Water Works / Wastewater Facilities (water/wastewater instrumentation and control reference) |
+
+# Submittals {toc}
+
+## Action Submittals {toc}
+
+### The Contractor shall submit the following for the Engineer's review and return before configuration and field integration proceed:
+
+- Division-of-responsibility matrix, identifying for every system and packaged item which party furnishes the device, which party wires it, which party programs it, and which party tests it
+- Control narratives / process control descriptions for every process system, written as the sequences of operation, including normal, abnormal, alarm, interlock, permissive, fail-safe, and manual-override behavior, cross-referenced to the P&IDs and to each affected loop and I/O point
+- Complete I/O list, organized by controller and by process system, listing each point's tag, description, signal type, engineering range, scaling, normal state, failure state, and the controller/module/channel assignment
+- Tag and point naming convention document conforming to ANSI/ISA-5.1, including the loop-numbering scheme and any Owner-mandated naming overlay
+- Control loop descriptions and loop diagrams per ANSI/ISA-5.4 for each regulatory and discrete control loop
+- Software development and configuration management plan, identifying the version control system, the controller and SCADA application baselining method, the change-log procedure, and the backup and recovery method
+- Network architecture and integration drawing showing controllers, the SCADA/HMI servers and clients, the process control network segments, the OT/IT boundary, and every third-party and packaged-equipment integration with its protocol and gateway identified
+- Third-party / packaged-skid integration register, listing each OEM controller to be integrated, its native protocol, the points to be exposed to the plant SCADA, and the gateway or driver method
+- HMI graphics intent per ANSI/ISA-101.01, including the display hierarchy, navigation model, color and status convention, and representative process graphics with live point overlays
+- Alarm rationalization deliverable per ANSI/ISA-18.2, listing each alarm with its setpoint, priority, consequence, operator response, and any suppression or shelving rule
+- Factory acceptance test (FAT) plan and procedures per ANSI/ISA-62381, with the test point list and pass/fail criteria
+- Site acceptance test (SAT), loop check, performance verification test (PVT), and endurance test plans and procedures, with schedules and acceptance criteria
+- Cybersecurity configuration plan addressing zone-and-conduit segmentation, account and role design, secure-protocol selection, patch baseline, removable-media policy, remote-access method, and audit logging, at a level of detail consistent with the project ISA/IEC 62443 target security levels
+- Operator and maintenance training plan, identifying course content, duration, audience, and materials
+
+```datasheet
+label: Action Submittals Required
+type: checkbox
+options:
+ - "Division-of-responsibility matrix"
+ - "Control narratives / process control descriptions"
+ - "Complete I/O list by controller and process system"
+ - "ISA-5.1 tag and point naming convention"
+ - "Control loop descriptions and ISA-5.4 loop diagrams"
+ - "Software development and configuration management plan"
+ - "Network architecture and integration drawing"
+ - "Third-party / packaged-skid integration register"
+ - "ISA-101.01 HMI graphics intent"
+ - "ISA-18.2 alarm rationalization deliverable"
+ - "FAT plan and procedures (ISA-62381)"
+ - "SAT, loop check, PVT, and endurance test plans"
+ - "Cybersecurity configuration plan (ISA/IEC 62443)"
+ - "Operator and maintenance training plan"
+default: [Division-of-responsibility matrix, Control narratives / process control descriptions, Complete I/O list by controller and process system, FAT plan and procedures (ISA-62381), SAT, loop check, PVT, and endurance test plans]
+```
+
+### The control narratives, the I/O list, and the P&IDs shall be reconciled to one another before any are submitted; a control narrative that commands a point absent from the I/O list, or an I/O list point with no defined behavior in a narrative, shall be resolved before submittal.
+
+### Submittals shall be coordinated across all controllers, the SCADA/HMI application, the network, and every integrated subsystem before any item is submitted; piecemeal submittals that require resubmission due to internal inconsistency will not be accepted.
+
+## Closeout Submittals {toc}
+
+### The Contractor shall provide the following before the control system is accepted at substantial completion:
+
+- As-built control narratives reflecting the sequences as commissioned, with every field-tuned setpoint, deadband, timer, and interlock recorded at its final value
+- As-built I/O list and tag database reflecting the final installed points, scaling, alarm limits, and channel assignments
+- As-built loop diagrams per ANSI/ISA-5.4 reflecting installed routing and terminations
+- Complete copy of all controller programs, the SCADA/HMI application, graphics, alarm and historian configuration, and the server database, in the manufacturer's native backup format and in a portable export where available
+- Software configuration management record showing the final baseline version of every controller program and application, with the change log from FAT through commissioning
+- Signed FAT, SAT, loop check, PVT, and endurance test reports with all punch-list items closed
+- Instrument calibration records for every analog loop, showing as-found and as-left readings against a traceable reference
+- Valve and actuator stroke and travel records for every modulating and on/off final element commissioned under this scope
+- Cybersecurity closeout: account and role inventory, installed firmware and software versions with patch dates, configured backup schedule, and signed acknowledgement that all default and vendor-default credentials have been changed
+- Operation and maintenance manuals including the as-built sequences, the tag database, alarm response guidance, and recommended preventive maintenance
+- Training records documenting personnel trained, dates, and topics
+
+```datasheet
+label: Required Closeout Submittals
+type: checkbox
+options:
+ - "As-built control narratives (final tuned values)"
+ - "As-built I/O list and tag database"
+ - "As-built ISA-5.4 loop diagrams"
+ - "Complete program, application, graphics, and database backup"
+ - "Software configuration management record and change log"
+ - "Signed FAT, SAT, loop check, PVT, and endurance test reports"
+ - "Instrument calibration records (as-found / as-left)"
+ - "Valve and actuator stroke and travel records"
+ - "Cybersecurity closeout (accounts, versions, backup, credential acknowledgement)"
+ - "Operation and maintenance manuals"
+ - "Training records"
+default: [As-built control narratives (final tuned values), As-built I/O list and tag database, Signed FAT, SAT, loop check, PVT, and endurance test reports, Instrument calibration records (as-found / as-left), Operation and maintenance manuals]
+```
+
+# Quality Assurance {toc}
+
+## Integrator Qualifications {toc}
+
+### The control system integration, programming, and commissioning shall be performed by a control system integrator with a minimum of five years of documented experience integrating systems of comparable type, scale, and process complexity.
+
+### For municipal water and wastewater work, the integrator shall have documented experience integrating plant SCADA for treatment facilities of comparable unit-process scope.
+
+### The integrator should maintain a documented quality management system and certified application engineers on the proposed controller and SCADA platforms.
+
+### A control system integrator certified under the Control System Integrators Association certification program, or holding equivalent independently audited certification, demonstrates a documented engineering and project-management process and is the preferred qualification. {note}
+
+## Single Point of Responsibility {toc}
+
+### The integration, configuration, programming, testing, and commissioning of the plant control system shall be the responsibility of a single control system integrator under one point of responsibility.
+
+### Where portions of the control system arrive as factory-programmed packaged-equipment controls, the integrator shall remain responsible for integrating those subsystems into the plant SCADA and for verifying that every required point is visible and operable at the operator interface.
+
+### The integrator shall verify, before site acceptance, that every point listed in the I/O list is present, correctly scaled, correctly named, and behaving per its control narrative.
+
+## Pre-Integration Conference {toc}
+
+### A pre-integration conference shall be held before any control system field integration begins.
+
+### Attendees shall include the integrator, the electrical contractor, the mechanical/process contractor, each packaged-equipment vendor with a control interface, the Owner's operations and OT representatives, and the Commissioning Authority where one is engaged.
+
+### The agenda shall include the division-of-responsibility matrix, the I/O and tag conventions, the network and OT/IT boundary coordination, the integration method for each packaged subsystem, the FAT/SAT/PVT/endurance test sequence and schedule, and the cybersecurity constraints governing access during construction and after acceptance.
+
+# Division of Responsibility {toc}
+
+## The single most frequent source of disputes, RFIs, and schedule slip on a controls project is an unclear boundary between the integrator, the electrical trade, and the mechanical/process trade. {note}
+
+## A formal division-of-responsibility matrix prevents the two failure modes of an undefined boundary — work performed twice and work performed by no one. {note}
+
+## The integrator shall furnish, configure, and program the controllers, the SCADA/HMI application, and the integration of all subsystems, and shall provide the control narratives, the I/O list, the loop diagrams, and the test procedures.
+
+## The electrical trade shall furnish and install control power, raceways, control wiring, instrument and valve field wiring, and panel terminations per [[sync/industrial-control-panels]] and the project electrical standards, and shall land conductors at field devices and at controller terminals.
+
+## The mechanical/process trade shall furnish and install the process equipment, the in-line instruments and final elements, and the mechanical connections, and shall make equipment available for loop checks and commissioning.
+
+## Each packaged-equipment vendor shall furnish its skid-mounted controls, expose the points required by the integration register, and support integration and testing of its subsystem into the plant SCADA.
+
+## Responsibility Matrix {toc}
+
+### A division-of-responsibility matrix shall be prepared and agreed at the pre-integration conference, assigning for every device and subsystem the furnish, install/wire, program, and test responsibility. {note}
+
+```datasheet
+label: Control Narrative Authorship
+type: radio
+options:
+ - "Engineer of Record authors the control narratives; integrator implements (typical for design-bid-build)"
+ - "Integrator authors the control narratives from the Engineer's process intent and P&IDs (design-build / progressive)"
+ - "Shared — Engineer authors regulatory and safety sequences; integrator authors detailed device-level logic"
+default: "Engineer of Record authors the control narratives; integrator implements (typical for design-bid-build)"
+```
+### The control narrative is the contractual blueprint that the programmer implements; the party who authors it shall be identified in the matrix so that the integrator is not asked to invent process intent that belongs to the Engineer of Record. {note}
+
+```datasheet
+label: System Integration Delivery Model
+type: radio
+options:
+ - "Single master systems integrator for the entire plant (preferred for multi-process facilities)"
+ - "Discipline integrators with a designated lead integrator at the SCADA seam"
+ - "Owner-directed standard integrator (Owner mandates platform and integrator for fleet consistency)"
+default: "Single master systems integrator for the entire plant (preferred for multi-process facilities)"
+```
+### Field wiring and termination responsibility shall be [[drawing: as indicated on the control wiring and termination drawings and the division-of-responsibility matrix]].
+
+# Control Narratives and Process Control Descriptions {toc}
+
+## A control narrative (process control description) is the written sequence of operation — the authoritative, human-readable description of how each process system is intended to behave under every condition, against which the controller logic is programmed and tested. {note}
+
+## The narrative is the bridge between the process design and the executable logic: the programmer configures to it, the test engineer writes FAT and SAT cases from it, and the operator is trained on it. {note}
+
+## A control narrative shall be provided for every process system and shall describe normal automatic operation, manual operation, startup and shutdown, the response to each alarm and abnormal condition, every interlock and permissive, and the fail-safe state of each final element.
+
+## Each narrative shall be cross-referenced to the P&ID, to every affected control loop, and to every I/O point it commands or reads, so that the narrative, the loop diagram, and the I/O list form a closed, mutually consistent set.
+
+## Each step that depends on a setpoint, deadband, timer, or threshold shall identify that parameter as an adjustable value, and the as-built narrative shall record the final commissioned value of each.
+
+## Narrative Content {toc}
+
+### Each control narrative shall address, at minimum, the following: {note}
+
+- Process purpose and the equipment served, referenced to the P&ID
+- Normal automatic sequence, including modulating control loops and discrete device sequencing
+- Operator manual mode and the available manual commands
+- Startup and shutdown sequences, including any permissives that must be satisfied before start
+- Lead/lag/standby and duty-rotation logic for redundant equipment (pumps, blowers, filters)
+- Interlocks and permissives, identifying each initiating condition and the action taken
+- Alarm conditions, the alarm priority, and the expected operator response
+- Failure response: the state each final element assumes on loss of signal, loss of power, or loss of communications
+
+### The fail-safe state of every final element shall be stated explicitly in the narrative and shall match the configured failure mode of the valve, actuator, or drive per [[sync/control-valves-and-actuators]].
+
+### A narrative that omits the failure response leaves the most safety-relevant behavior of the system undefined and untestable. {note}
+
+## Control Modes {toc}
+
+```datasheet
+label: Required Control Modes Per Loop
+type: checkbox
+options:
+ - "Automatic (closed-loop or sequenced, normal operation)"
+ - "Manual (operator sets output directly at the HMI)"
+ - "Local (control at the field device or local control station, SCADA monitoring only)"
+ - "Off / locked out"
+ - "Cascade / remote setpoint (where a loop's setpoint is driven by another loop)"
+default: [Automatic (closed-loop or sequenced, normal operation), Manual (operator sets output directly at the HMI), Local (control at the field device or local control station, SCADA monitoring only), Off / locked out]
+```
+### Every controlled loop and device shall support, at minimum, automatic, manual, and local/off modes, with the active mode displayed at the operator interface.
+
+### Transfer between modes shall be bumpless for modulating loops, so that switching from automatic to manual does not step the final element.
+
+# Tag and Point Naming {toc}
+
+## A single, consistent tag and point naming convention applied across the P&IDs, the I/O list, the controller logic, and the SCADA database is what lets an operator, a programmer, and a maintenance technician all refer to the same device by the same name. {note}
+
+## Inconsistent tagging between the drawings and the database is a chronic source of commissioning error and is the first thing an integration audit checks. {note}
+
+## Instrument and loop tags shall conform to ANSI/ISA-5.1, with the first letter identifying the measured or initiating variable and succeeding letters identifying the device function.
+
+## Each loop shall carry a unique loop number, and every device within a loop shall share that loop number with a distinguishing function prefix per ANSI/ISA-5.1.
+
+## The naming convention shall be documented and applied identically on the P&IDs, the I/O list, the loop diagrams, the controller logic, and the SCADA tag database; a device shall carry one and only one tag across all deliverables.
+
+## Where the Owner maintains a plant-wide naming or asset-numbering standard, the project tag scheme shall conform to it, and any reconciliation between the Owner overlay and ANSI/ISA-5.1 shall be documented in the naming convention submittal.
+
+```datasheet
+label: Tag Naming Basis
+type: radio
+options:
+ - "ANSI/ISA-5.1 loop-and-function tagging (industry default)"
+ - "ANSI/ISA-5.1 with Owner plant-wide asset-numbering overlay"
+ - "Owner mandated naming standard mapped to ISA-5.1 functions"
+default: "ANSI/ISA-5.1 loop-and-function tagging (industry default)"
+```
+
+# Input/Output List and Loop Diagrams {toc}
+
+## The I/O list is the master index of every signal the control system reads or writes; it is the basis of controller and panel sizing, of point-to-point checkout, and of the SCADA database build. {note}
+
+## The Contractor shall maintain a single controlled I/O list as the authoritative point database from design through as-built, and every revision shall be reflected in the controller configuration and the SCADA database. {note}
+
+## The I/O list shall identify, for each point, the tag, the description, the signal type, the engineering range and units, the scaling, the normal and failure states, the alarm limits, and the controller, module, and channel assignment.
+
+```datasheet
+label: Analog Signal Standard
+type: select
+options:
+ - "4-20 mA analog (with HART overlay where instruments support it) — default"
+ - "4-20 mA analog only (no digital overlay)"
+ - "Digital fieldbus (HART-IP, Foundation Fieldbus, or PROFIBUS PA per [[sync/process-control-networks]])"
+ - "Mixed — 4-20 mA for primary process loops, digital fieldbus for instrument-dense skids"
+default: "4-20 mA analog (with HART overlay where instruments support it) — default"
+```
+### The 4-20 mA current loop remains the dominant process signal because a live-zero of 4 mA distinguishes a true zero reading from a broken wire, and the loop is immune to voltage drop over long plant runs. {note}
+
+### A spare I/O allowance shall be provided on each controller; the spare allowance shall be [[drawing: as indicated on the I/O schedules]] and should be a minimum of 15% spare channels of each type for future expansion.
+
+## Loop Diagrams {toc}
+
+### A loop diagram conforming to ANSI/ISA-5.4 shall be provided for each control loop, showing every device in the loop, the signal path from sensor to final element, the wiring and terminations, and the power source.
+
+### Loop diagrams are the field reference for loop checks and for troubleshooting; an accurate as-built loop diagram is the single most useful maintenance document the integrator delivers. {note}
+
+# Software Development and Configuration Management {toc}
+
+## Controller logic and the SCADA/HMI application are software deliverables, and they shall be developed, versioned, baselined, and backed up under a documented configuration management process. {note}
+
+## The Contractor shall place all controller programs and the SCADA/HMI application under version control, with a documented baseline at FAT, at SAT, and at substantial completion.
+
+## Every change to a baselined program or application after FAT shall be recorded in a change log identifying what changed, why, who made the change, and when.
+
+## A full, restorable backup of every controller program, the SCADA/HMI application, graphics, alarm and historian configuration, and the server database shall be maintained, and a restore shall be demonstrated on a test target before substantial completion.
+
+## Modular and Reusable Logic {toc}
+
+### Controller logic should be organized into reusable, parameterized modules — one standard block per device type (a standard motor block, a standard modulating-valve block, a standard analog-input block) — so that the same tested logic is reused across like devices.
+
+### Modular logic reduces programming error, makes FAT efficient (a device block is tested once and reused), and makes the system maintainable by the Owner; the device-type modeling of ANSI/ISA-88 and the procedural modeling of ANSI/ISA-106 are the recognized frameworks for this structuring. {note}
+
+### Where the process is batch or sequential, the control structure should follow the procedural and equipment models of ANSI/ISA-88.
+
+## Verification and Validation {toc}
+
+### The software shall be verified against the functional requirements (the control narratives and the I/O list) through the FAT and SAT process, consistent with the verification and validation framework of IEEE 1012.
+
+### A function commanded by a control narrative but not demonstrated in a test case is unverified; the test plans shall trace every narrative step and every I/O point to a test case. {note}
+
+# Third-Party and Packaged Equipment Integration {toc}
+
+## Modern process and water/wastewater plants arrive as a collection of packaged skids — each with its own factory-programmed controller — that the integrator must fold into one coherent plant SCADA. {note}
+
+## Examples include chemical feed skids, UV disinfection units, membrane and filtration skids, blower packages, dewatering equipment, dosing systems, and engine-generator and variable-frequency-drive controls. {note}
+
+## For each packaged subsystem, the integrator shall integrate the OEM controller to the plant SCADA so that the operator sees a uniform tag tree and a consistent operating interface regardless of the underlying vendor platform.
+
+## The integrator shall obtain from each vendor, and verify against the integration register, the native protocol, the register or object map, and the complete list of points the skid exposes.
+
+## The integrator shall expose to the plant SCADA, at minimum, each packaged subsystem's run/ready status, fault status with fault code, key process variables, the principal setpoints the plant is permitted to command, and the energy or runtime data required for plant reporting.
+
+```datasheet
+label: Packaged Equipment Integration Method
+type: select
+options:
+ - "Native protocol over the plant network mapped at the SCADA layer (preferred where the skid speaks the plant protocol)"
+ - "Protocol gateway/converter to the plant network (where skid protocol differs)"
+ - "Hardwired discrete and analog I/O only (status, alarm, command — where no usable digital interface exists)"
+ - "Mixed — digital integration for monitoring plus hardwired interlocks for safety-critical commands"
+default: "Native protocol over the plant network mapped at the SCADA layer (preferred where the skid speaks the plant protocol)"
+```
+
+```datasheet
+label: Integration Communication Protocol
+type: select
+options:
+ - "EtherNet/IP"
+ - "Modbus TCP"
+ - "Modbus RTU (RS-485)"
+ - "PROFINET"
+ - "OPC UA (server/client to OEM controller)"
+ - "DNP3 (utility / water-wastewater telemetry)"
+ - "Mixed — protocol per subsystem, normalized at the SCADA layer"
+default: "Mixed — protocol per subsystem, normalized at the SCADA layer"
+```
+### DNP3 is the dominant protocol for municipal water and wastewater telemetry between remote sites and the central SCADA because of its report-by-exception efficiency and timestamped event buffering over constrained links. {note}
+
+### Safety-critical interlocks between a packaged subsystem and the plant shall be hardwired, not carried solely over a network protocol, so that a network failure cannot disable a protective function.
+
+### A network protocol may mirror a safety interlock for monitoring, but the protective action itself shall not depend on the network. {note}
+
+# Alarm Management {toc}
+
+## An un-rationalized alarm system that floods the operator with low-value alarms during an upset is worse than no alarm system, because the operator loses the genuine alarm in the noise. {note}
+
+## The alarm system shall be designed and rationalized per ANSI/ISA-18.2, and each configured alarm shall have a defined setpoint, priority, consequence, operator response, and basis for its priority.
+
+## Each alarm shall be actionable — an alarm to which the operator can take no action shall be reclassified as an indication, not an alarm.
+
+```datasheet
+label: Alarm Priority Levels
+type: select
+options:
+ - "3 levels (High / Medium / Low)"
+ - "4 levels (Critical / High / Medium / Low)"
+ - "4 levels with a separate Safety/Emergency class"
+default: "4 levels (Critical / High / Medium / Low)"
+```
+
+```datasheet
+label: Alarm Suppression and Shelving Methods
+type: checkbox
+options:
+ - "Parent-child suppression (downstream alarms suppressed when parent equipment is off)"
+ - "State-based suppression (alarms suppressed in operating states where they are not meaningful)"
+ - "Time-delay / on-delay (transient excursions shorter than a set time do not alarm)"
+ - "Operator shelving with automatic re-enable and audit trail"
+default: [Parent-child suppression (downstream alarms suppressed when parent equipment is off), State-based suppression (alarms suppressed in operating states where they are not meaningful), Time-delay / on-delay (transient excursions shorter than a set time do not alarm)]
+```
+### Alarm suppression and shelving rules shall be documented in the alarm rationalization deliverable, and shelved alarms shall carry an audit trail and an automatic re-enable.
+
+### Alarm setpoints, deadbands, and on-delays shall be tunable and shall be tuned during commissioning to suppress nuisance alarms while preserving genuine ones.
+
+# Operator Interface {toc}
+
+## The HMI is where the operator forms a mental model of the plant; a cluttered or inconsistent interface degrades situational awareness exactly when it is most needed, during an upset. {note}
+
+## The SCADA/HMI application shall be developed per ANSI/ISA-101.01, with a consistent display hierarchy, navigation model, and color and status convention applied across every graphic.
+
+## Color shall convey process state by exception — alarms and abnormal conditions shall stand out against a low-saturation normal background — and color shall not be the only means of conveying a critical state.
+
+## Each process graphic shall present live values with engineering units, the control mode of each loop, the position or status of each final element, and any active alarm, so that the operator can read the state of the system at a glance.
+
+### The detailed SCADA/HMI platform, server architecture, redundancy, and historian are specified in [[sync/scada-and-hmi-systems]]; this standard governs the application's conformance to the project's narratives, alarms, and graphics conventions. {note}
+
+# Cybersecurity Coordination {toc}
+
+## The process control system is operational technology whose compromise can cause loss of process control, equipment damage, environmental release, or — in a water or wastewater plant — a public-health event. {note}
+
+## The integrator's delivered configuration shall be hardened within the zone-and-conduit architecture and to the target security levels established for the project under ISA/IEC 62443, consistent with the OT security baseline of NIST SP 800-82.
+
+## The integrator shall coordinate the OT/IT boundary, network segmentation, and any remote-access provision with the Owner's OT security organization and with [[sync/process-control-networks]]; the Owner's program governs above this baseline.
+
+## Secure Configuration {toc}
+
+### All default and vendor-default credentials on every controller, server, workstation, switch, and integrated device delivered under this scope shall be changed before substantial completion, and the change shall be acknowledged in the cybersecurity closeout.
+
+### The delivered system shall implement role-based access control with named individual accounts; shared accounts shall not be used for operator, engineer, or administrator access.
+
+### Unused services, ports, and protocols on delivered controllers and servers shall be disabled, leaving only those required for plant operation.
+
+### Where the controllers and SCADA platform support an authenticated, encrypted control protocol, that secure protocol shall be used for traffic that traverses any segment shared with non-control devices.
+
+```datasheet
+label: Remote Access Method
+type: radio
+options:
+ - "No remote access (air-gapped OT, on-site engineering only)"
+ - "Owner-managed VPN with multi-factor authentication into a controlled jump host"
+ - "Vendor remote support through an Owner-controlled, logged, normally-disabled connection"
+ - "Owner-managed VPN plus separate vendor-support path, both logged and MFA-protected"
+default: "Owner-managed VPN with multi-factor authentication into a controlled jump host"
+```
+### Remote access, where provided, shall traverse an Owner-controlled, authenticated, and logged path; persistent always-on vendor connections shall not be provided.
+
+### Audit logging shall be enabled on controllers, servers, and workstations to the extent the platform supports it, and logs shall be retained per the Owner's OT security policy.
+
+# Functional Safety Interface {toc}
+
+## Where a safety instrumented function exists, it is implemented in a logic solver separate from and independent of the basic process control system; this standard governs only the integration seam between the two, not the SIS itself. {note}
+
+## The basic process control system shall not be capable of defeating, bypassing, or overriding a safety instrumented function except through the bypass and override provisions designed into the SIS under IEC 61511.
+
+## The integrator shall verify, during SAT, that each interface between the basic process control system and the SIS behaves exactly as the safety requirements specification defines — including that a SIS trip drives the basic-control final elements to their defined safe state and that the basic control system cannot command a state the SIS has tripped.
+
+## Any bypass, maintenance-override, or reset of a safety function presented at the operator interface shall be implemented per the SIS design, shall be access-controlled, and shall be alarmed and logged while active.
+
+## The integrator shall not modify safety logic solver configuration except under the project functional-safety management of change procedure, with the authorization recorded.
+
+# Testing {toc}
+
+## Factory Acceptance Test {toc}
+
+### A factory acceptance test (FAT) per ANSI/ISA-62381 shall be performed at the integrator's facility, before shipment, to demonstrate that the assembled and configured control system meets the specification under simulated conditions. {note}
+
+### The FAT shall demonstrate controller logic, SCADA/HMI graphics and navigation, alarm behavior, mode transitions, and every control narrative sequence, using simulated inputs for field signals not yet available.
+
+### Every control narrative step and every I/O point shall be traced to a FAT test case, and the FAT shall not be declared complete with open critical items.
+
+```datasheet
+label: FAT Witnessing
+type: radio
+options:
+ - "Owner and Engineer witnessed FAT at integrator's facility (recommended)"
+ - "Engineer witnessed; Owner by remote video"
+ - "Remote witnessed FAT (video and screen-share) for both Owner and Engineer"
+ - "Integrator-run FAT with submitted report, spot-witnessed"
+default: "Owner and Engineer witnessed FAT at integrator's facility (recommended)"
+```
+### A thorough FAT is the cheapest place to find configuration errors; a defect caught at FAT costs a software edit, while the same defect found at site costs mobilization, downtime, and schedule. {note}
+
+## Site Acceptance Test {toc}
+
+### A site acceptance test (SAT) per ANSI/ISA-62381 shall be performed after installation to verify the installed system against the specification under field conditions, repeating the relevant FAT cases now wired to real field devices.
+
+### The SAT shall verify the integration of every packaged subsystem, the network and OT/IT boundary, and the safety-function interfaces, and shall confirm that every I/O point is present, scaled, named, and behaving per its narrative.
+
+## Loop Checks and Point-to-Point Checkout {toc}
+
+### A loop check (point-to-point checkout) shall be performed on every I/O point, verifying continuity from the field device through the wiring and controller to the correct, correctly scaled, correctly named indication at the operator interface. {note}
+
+### Each analog input loop shall be verified by injecting or driving a known value at the field device and confirming the reading and scaling at the HMI, and each analog output loop by commanding a known output and confirming the final element responds.
+
+### Each discrete point shall be verified by actuating the field condition and confirming the correct state and tag at the HMI, and by commanding each output and confirming the device responds.
+
+### Instrument calibration shall be coordinated with the loop check: each analog instrument shall be calibrated against a traceable reference, with as-found and as-left readings recorded, in coordination with [[sync/process-instrumentation]], [[sync/flow-measurement]], and [[sync/analytical-instrumentation]].
+
+### Each control valve and actuator shall be stroked and its travel verified against command in coordination with [[sync/control-valves-and-actuators]], and the fail-safe position shall be confirmed by removing the signal and the power.
+
+```datasheet
+label: Loop Check Documentation
+type: checkbox
+options:
+ - "Per-loop checkout sheet (tag, signal injected, expected vs. actual, pass/fail, sign-off)"
+ - "Instrument calibration record (as-found / as-left vs. traceable reference)"
+ - "Valve/actuator stroke and travel record vs. command"
+ - "Fail-safe position verification (loss of signal and loss of power)"
+ - "Alarm and interlock verification per point"
+default: [Per-loop checkout sheet (tag, signal injected, expected vs. actual, pass/fail, sign-off), Instrument calibration record (as-found / as-left vs. traceable reference), Valve/actuator stroke and travel record vs. command, Fail-safe position verification (loss of signal and loss of power)]
+```
+
+## Performance Verification Test {toc}
+
+### Following successful loop checks and SAT, a performance verification test (PVT) shall be performed to demonstrate that the integrated system performs its sequences correctly under live process conditions. {note}
+
+### The PVT shall exercise every control narrative under actual operation — automatic control, mode transitions, lead/lag/standby rotation, interlocks, permissives, and the response to induced abnormal conditions — and shall demonstrate control loop stability and tuning under load.
+
+### Control loops shall be tuned during the PVT so that each regulatory loop is stable and responsive without sustained oscillation or excessive offset, and the final tuning values shall be recorded in the as-built narrative.
+
+## Endurance Test {toc}
+
+### An endurance test shall be performed after the PVT to demonstrate that the integrated system operates continuously and reliably over a sustained period without unexplained failure. {note}
+
+```datasheet
+label: Endurance Test Duration
+type: select
+options:
+ - "7 days continuous (typical for plant SCADA integration)"
+ - "14 days continuous"
+ - "30 days continuous (large or critical municipal plants)"
+ - "As specified on the contract test requirements"
+drawing_ref: true
+default: "7 days continuous (typical for plant SCADA integration)"
+```
+### The system shall operate continuously for the specified endurance period with no unexplained failure of any controller, server, network segment, or integrated subsystem; any failure shall reset the endurance clock after the cause is corrected.
+
+### Trend and historian data shall be retained for the full endurance period; where buffer capacity is insufficient, trend data shall be offloaded during the test so that no record is lost.
+
+# Startup and Commissioning {toc}
+
+## Commissioning shall proceed in the sequence — FAT, installation, loop checks with calibration and stroking, SAT, PVT, then endurance test — with each phase complete and documented before the next begins. {note}
+
+## The integrator shall coordinate commissioning with the electrical and mechanical/process trades, the packaged-equipment vendors, and the Commissioning Authority where one is engaged, so that equipment is available and energized when each phase requires it.
+
+## The Commissioning Authority, where engaged, shall witness the SAT, PVT, and endurance tests and shall verify the as-built narratives, the I/O list, and the alarm and interlock behavior.
+
+## During commissioning, overrides and forces placed in controller logic or at the HMI to facilitate testing shall be logged, and all such forces shall be removed and the removal verified before substantial completion.
+
+## A force left in a controller after commissioning is a latent failure that can defeat a control or protective function silently; a documented force-removal verification is mandatory. {note}
+
+# Training {toc}
+
+## Operator Training {toc}
+
+### The integrator shall provide operator training covering the plant control narratives, the HMI navigation and graphics, the alarm system and expected responses, the control modes and how to transfer between them, and routine operation of every process system.
+
+### Operator training shall be conducted on the commissioned system or an equivalent simulation, hands-on, before the Owner assumes operation.
+
+## Maintenance Training {toc}
+
+### The integrator shall provide maintenance training covering the I/O list and loop diagrams, point-to-point troubleshooting, instrument calibration and valve stroking, the configuration management and backup/restore procedure, and the cybersecurity provisions the Owner is responsible for maintaining.
+
+```datasheet
+label: Training Delivery
+type: checkbox
+options:
+ - "Operator training (narratives, HMI, alarms, modes, routine operation)"
+ - "Maintenance training (I/O, loop diagrams, troubleshooting, calibration)"
+ - "Configuration management and backup/restore training"
+ - "Cybersecurity awareness for OT (account, patch, removable-media policy)"
+ - "Recorded training sessions retained for future staff"
+default: [Operator training (narratives, HMI, alarms, modes, routine operation), Maintenance training (I/O, loop diagrams, troubleshooting, calibration), Configuration management and backup/restore training]
+```
+### Training sessions should be recorded and the recordings turned over to the Owner so that staff hired after commissioning can be trained on the as-built system. {note}
+
+# Documentation and As-Builts {toc}
+
+## The as-built documentation is what allows the Owner to operate, maintain, troubleshoot, and eventually modify the control system after the integrator has left; incomplete or out-of-date as-builts strand the Owner with a system no one can safely change. {note}
+
+## The Contractor shall update the control narratives, the I/O list, the tag database, and the loop diagrams to as-built condition, reflecting every field change and every final tuned value.
+
+## The Contractor shall deliver a complete, restorable backup of every controller program, the SCADA/HMI application, graphics, and the configuration and historian databases, in native and portable forms.
+
+## The Contractor shall deliver the operation and maintenance manuals, including the as-built sequences, the tag database, alarm response guidance, the configuration management and backup/restore procedure, and recommended preventive maintenance.
+
+# Warranty {toc}
+
+## Warranty Terms {toc}
+
+### The integrator shall warrant the integration, configuration, and programming against defects for a minimum of one year from substantial completion.
+
+### During the warranty period the integrator shall correct configuration and programming defects, including alarm and tuning deficiencies that manifest under seasonal or load conditions not present at commissioning.
+
+```datasheet
+label: Integration Warranty Term
+type: select
+options:
+ - "1 year from substantial completion (standard)"
+ - "2 years from substantial completion"
+ - "Extended term per Owner requirement"
+default: "1 year from substantial completion (standard)"
+```
+### The warranty shall include the controller programs and the SCADA/HMI application as delivered; the integrator shall retain the baselined source configuration so that warranty corrections are made to the controlled baseline, not to an undocumented field copy.
+
+# Spare Parts and Software {toc}
+
+## Software and Configuration {toc}
+
+### The integrator shall turn over to the Owner the licensed development and configuration software, the source configuration for every controller and the SCADA/HMI application, and the documented procedure to restore the system from backup.
+
+### The Owner shall receive the rights and the media necessary to maintain and modify the delivered control system without dependence on the integrator, subject to the platform licensing.
+
+### Turning over only compiled runtime without the source configuration leaves the Owner unable to make even trivial changes; the controlled source configuration is a required deliverable. {note}
+
+```datasheet
+label: Software and Configuration Turnover
+type: checkbox
+options:
+ - "Licensed development/configuration software for controllers and SCADA"
+ - "Source configuration for every controller program"
+ - "Source configuration for the SCADA/HMI application and graphics"
+ - "Documented backup/restore procedure and verified backup media"
+ - "License keys and registration transferred to Owner"
+default: [Licensed development/configuration software for controllers and SCADA, Source configuration for every controller program, Source configuration for the SCADA/HMI application and graphics, Documented backup/restore procedure and verified backup media]
+```