Control Systems Integration and Testing
Remake for template neutrality (from-scratch field inventory, five-state defaults, parameters and derived fields, schedule deferrals)
Showing changes from Rev 3
to Rev 4
in Control Systems Integration and Testing.
---
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.
+ When to use: The integration, configuration, and acceptance-testing scope performed by the control system integrator on an industrial, process, or water and wastewater treatment project, whether the plant is new, expanded, or migrated to a replacement control platform. Covers the division of responsibility between the integrator, the electrical trade, the mechanical and process trade, and the packaged-equipment vendors; the authorship and content of the control narratives; tag and point naming per ANSI/ISA-5.1; the controlled I/O list and the loop diagrams per ANSI/ISA-5.4; the software configuration management workflow from first baseline through as-built; the integration of packaged-skid controls into the plant SCADA; the integrator's secure delivery of the configured system; the integration-seam verification of safety instrumented functions; the factory acceptance test, site acceptance test, site integration test, loop checks, performance verification test, and endurance test under ANSI/ISA-62381 and ANSI/ISA-62382; the commissioning sequence; training on the narratives and the maintenance of the delivered configuration; as-built documentation; the integration warranty; and the turnover of source configuration.
− 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.
+ Not intended for: The equipment the integrator configures and commands, each of which is specified in its own standard: controllers ([[sync/programmable-logic-controllers]]), the SCADA and HMI platform with its alarm philosophy, graphics conventions, historian, and operator training ([[sync/scada-and-hmi-systems]]), process control networks with their protocol set and the OT cybersecurity baseline ([[sync/process-control-networks]]), industrial control panels ([[sync/industrial-control-panels]]), process instrumentation and its calibration methods ([[sync/process-instrumentation]], [[sync/flow-measurement]], [[sync/analytical-instrumentation]], [[sync/level-sensors]]), instrument mounting and tubing ([[sync/instrument-installation-and-tubing]]), control valves and actuators ([[sync/control-valves-and-actuators]]), and motor starting and protection ([[sync/motor-control-centers]]). Commercial building HVAC controls integration is governed by [[sync/building-automation-system]]. The functional-safety lifecycle, the hazard and risk analysis, the safety integrity level determination, and the design of the safety instrumented system itself belong to the process safety scope under IEC 61511; this standard verifies only the interface between that system and 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 work that turns 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}
−## 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 work comprises the control narratives, the tag and I/O database, the configured controller logic and SCADA application, the integration of every packaged subsystem, the test program that proves the assembled system against the narratives, the commissioning sequence, the training, the as-built record, and the turnover of the source configuration to the Owner. {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]].
+## The equipment the integrator configures is furnished, rated, and warranted under its own standard; this standard specifies none of that equipment and instead governs what the integrator does with it. {note}
−## 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.
+## A plant control system is the one deliverable on a process project that no single trade can complete alone: the electrical trade lands the wires, the process trade sets the equipment, the vendors ship the skids, and the integrator is the party whose work is defined by making all of it behave as one system. {note}
−## Scope Boundaries {toc}
+## The process systems to be integrated under this standard shall be as indicated on [[drawing: the process and instrumentation diagrams]].
−### 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}
+## The points the control system reads and writes shall be as indicated on [[drawing: the input and output schedules]].
−### 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}
+## The following are outside this standard and are governed elsewhere: {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}
+- controller hardware, memory, spare I/O capacity, analog signal standards, programming languages, and controller redundancy, governed by [[sync/programmable-logic-controllers]]
+- the SCADA platform, server architecture, HMI graphics and display hierarchy, alarm philosophy and priority scheme, historian, license ownership, and operator training on the platform, governed by [[sync/scada-and-hmi-systems]]
+- the process control network, the permitted industrial protocols, remote-site telemetry, the zone-and-conduit architecture, and the OT cybersecurity baseline of device hardening, account management, patching, logging, and network backup, governed by [[sync/process-control-networks]]
+- the control panels the controllers are housed in, governed by [[sync/industrial-control-panels]]
+- the instruments and final elements themselves and the calibration and stroke methods that apply to them, governed by [[sync/process-instrumentation]], [[sync/flow-measurement]], [[sync/analytical-instrumentation]], [[sync/level-sensors]], and [[sync/control-valves-and-actuators]]
+- the safety instrumented system, its logic solver, and the functional-safety lifecycle under IEC 61511
+- commercial building automation, governed by [[sync/building-automation-system]]
+- the whole-building commissioning process where a Commissioning Authority is engaged under [[sync/commissioning]]
−### 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.
+## Where the contract documents, the adopted code, or a referenced standard impose conflicting requirements on the same subject, the more stringent requirement shall govern unless the Engineer of Record directs otherwise in writing.
# 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.
+## Work under this standard shall comply with the latest adopted edition of each of the following unless a specific edition is cited.
+## Where referenced standards conflict with one another, 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-62381 | Automation Systems in the Process Industry: Factory Acceptance Test (FAT), Site Acceptance Test (SAT), and Site Integration Test (SIT) |
+| ANSI/ISA-62382 | Automation Systems in the Process Industry: Electrical and Instrumentation Loop Check |
+| IEC 62337 | Commissioning of Electrical, Instrumentation and Control Systems in the Process Industry: Specific Phases and Milestones |
| 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-88.00.01 | Batch Control Part 1: Models and Terminology |
+| ISA-TR106.00.01 | Procedure Automation for Continuous Process Operations: Models and Terminology |
+| ANSI/ISA-95.00.01 | Enterprise-Control System Integration Part 1: Models and Terminology |
| 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 |
+| ANSI/ISA-61511-1 (IEC 61511-1) | 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) |
+| NFPA 70 | National Electrical Code |
+| NFPA 79 | Electrical Standard for Industrial Machinery |
+| Ten States Standards | Recommended Standards for Water Works and for Wastewater Facilities |
# Submittals {toc}
## Action Submittals {toc}
−### The Contractor shall submit the following for the Engineer's review and return before configuration and field integration proceed:
+### The Contractor shall submit the following for the Engineer of Record's review and return before controller configuration and field integration begin:
−- 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
+- a division-of-responsibility matrix identifying, for every device and packaged subsystem, the party that furnishes it, the party that installs and wires it, the party that programs it, and the party that tests it
+- a control narrative for every process system, written to the content required by this standard and cross-referenced to the process and instrumentation diagrams, to each affected loop, and to each I/O point it commands or reads
+- the controlled I/O list, organized by controller and by process system, carrying every attribute required by this standard
+- the tag and point naming convention, including the loop-numbering scheme and any Owner naming overlay, with the reconciliation between the two documented
+- loop diagrams for the loops within the loop diagram scope selected in the datasheet
+- the software configuration management plan, identifying the version control tool, the baselining method, the change-log procedure, and the backup and restore method
+- a network architecture and integration drawing showing every controller, server, client, network segment, boundary device, and packaged-subsystem interface with its interface method identified, coordinated with [[sync/process-control-networks]]
+- the packaged-subsystem integration register, listing each vendor controller to be integrated, its native protocol, the points to be exposed to the plant SCADA, and the interface method
+- the factory acceptance test plan and procedures, with the test case list traced to the narratives and the I/O list and the pass and fail criterion for each case
+- the site acceptance test, site integration test, loop check, performance verification test, and endurance test plans and procedures, with the schedule and the acceptance criterion for each
+- the training plan, identifying each session, its content, its duration, its audience, and its materials
```datasheet
…2 unchanged lines
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"
+ - "Control narratives"
+ - "Controlled I/O list"
+ - "Tag and point naming convention"
+ - "Loop diagrams"
+ - "Software 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"
+ - "Packaged-subsystem integration register"
+ - "Factory acceptance test plan and procedures"
+ - "Site test, loop check, performance verification, and endurance test plans"
+ - "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"
+ - "Control narratives"
+ - "Controlled I/O list"
+ - "Tag and point naming convention"
+ - "Loop diagrams"
+ - "Software configuration management plan"
+ - "Network architecture and integration drawing"
+ - "Packaged-subsystem integration register"
+ - "Factory acceptance test plan and procedures"
+ - "Site test, loop check, performance verification, and endurance test plans"
+ - "Training plan"
```
−### 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.
+### The control narratives, the I/O list, and the process and instrumentation diagrams shall be reconciled to one another before any of them is submitted, and a narrative that commands a point absent from the I/O list, or a listed point with no defined behavior in any 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.
+### Controller configuration for a process system shall not begin until the narrative and the I/O list for that system have been returned by the Engineer of Record.
+### The narrative is the document the logic is written to and the tests are written from, so a narrative changed after configuration begins is a change to logic already written and to test cases already drafted; review before configuration is what keeps a narrative correction from becoming a rework cycle. {note}
+
+## Informational Submittals {toc}
+
+### The Contractor shall submit the following qualifications and records with or before the action submittals:
+
+- the integrator's qualification evidence required by this standard, with the comparable-project references identified by facility, scope, and a current Owner contact
+- the names and platform certifications of the application engineers who will configure the controllers and the SCADA application on this project
+- the cybersecurity configuration record for the delivered system, identifying the accounts and roles to be created, the services to be disabled, the removable-media and engineering-workstation controls, and the remote-access path where one is selected, consistent with the project plan under [[sync/process-control-networks]]
+- the factory acceptance test simulation description, identifying how each field signal and each packaged-subsystem interface will be simulated
+
+```datasheet
+label: Informational Submittals Required
+type: checkbox
+options:
+ - "Integrator qualification evidence and references"
+ - "Application engineer names and platform certifications"
+ - "Cybersecurity configuration record"
+ - "Factory acceptance test simulation description"
+default:
+ - "Integrator qualification evidence and references"
+ - "Application engineer names and platform certifications"
+ - "Cybersecurity configuration record"
+ - "Factory acceptance test simulation description"
+```
+
## Closeout Submittals {toc}
−### The Contractor shall provide the following before the control system is accepted at substantial completion:
+### The Contractor shall submit 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
+- as-built control narratives reflecting each sequence as commissioned, with every setpoint, deadband, timer, and threshold recorded at its final value
+- the as-built I/O list and tag database reflecting the installed points, scaling, alarm limits, and channel assignments
+- as-built loop diagrams reflecting the installed routing and terminations
+- a complete, restorable backup of every controller program, the SCADA application, graphics, alarm and historian configuration, and databases, in the platform's native format and in a portable export where the platform provides one
+- the configuration management record showing the final baseline of every program and application and the change log from the factory acceptance test baseline forward
+- signed factory acceptance, site acceptance, site integration, loop check, performance verification, and endurance test reports with every punch-list item closed or dispositioned in writing by the Engineer of Record
+- loop check sheets, instrument calibration records, and valve stroke records for every loop within the loop check scope
+- the cybersecurity closeout record, giving the account and role inventory, the installed firmware and software versions with their dates, the configured backup schedule, and a signed statement that every default credential on every device delivered under this standard has been changed
+- the force and override removal record required by this standard
+- operation and maintenance data prepared in accordance with [[sync/operation-and-maintenance-data]], including the as-built narratives, the tag database, alarm response guidance, the backup and restore procedure, and the recommended preventive maintenance
+- training records naming the personnel trained, the dates, and the topics
+- a signed receipt from the Owner for the software, media, and source configuration turned over under this standard
```datasheet
−label: Required Closeout Submittals
+label: Closeout Submittals Required
type: checkbox
options:
− - "As-built control narratives (final tuned values)"
+ - "As-built control narratives with 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"
+ - "As-built loop diagrams"
+ - "Restorable backup of every program, application, and database"
+ - "Configuration management record and change log"
+ - "Signed test reports with punch list closed"
+ - "Loop check, calibration, and valve stroke records"
+ - "Cybersecurity closeout record"
+ - "Force and override removal record"
+ - "Operation and maintenance data"
- "Training records"
+ - "Owner receipt for software and source configuration"
default:
− - "As-built control narratives (final tuned values)"
+ - "As-built control narratives with 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"
+ - "As-built loop diagrams"
+ - "Restorable backup of every program, application, and database"
+ - "Configuration management record and change log"
+ - "Signed test reports with punch list closed"
+ - "Loop check, calibration, and valve stroke records"
+ - "Cybersecurity closeout record"
+ - "Force and override removal record"
+ - "Operation and maintenance data"
+ - "Training records"
+ - "Owner receipt for software and source configuration"
```
+### The closeout package is what allows a successor integrator, or the Owner's own staff, to change the system after the integrator has left; a control system whose source configuration and as-built narratives were never delivered is one that no one can safely modify. {note}
+
+### The Contractor shall submit the closeout documents not later than the number of days after substantial completion indicated in the datasheet.
+
+```datasheet
+label: Closeout Submission Deadline After Substantial Completion
+type: range
+unit: days
+options:
+ min: 0
+ max: 90
+ setpoints: [0, 14, 30, 45, 60, 90]
+```
+
# 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.
+### The integration, configuration, programming, and testing under this standard shall be performed by a control system integrator that has integrated control systems of comparable type, scale, and process complexity for not less than the period indicated in the datasheet.
−### For municipal water and wastewater work, the integrator shall have documented experience integrating plant SCADA for treatment facilities of comparable unit-process scope.
+```datasheet
+label: Minimum Integrator Experience
+type: range
+unit: years
+options:
+ min: 0
+ max: 15
+ setpoints: [0, 2, 3, 5, 10, 15]
+default: 5
+```
−### The integrator should maintain a documented quality management system and certified application engineers on the proposed controller and SCADA platforms.
+### The integrator shall furnish the qualification evidence indicated in the datasheet.
−### 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}
+```datasheet
+label: Integrator Qualification Evidence Required
+type: checkbox
+options:
+ - "Current manufacturer certification on the controller platform"
+ - "Current manufacturer certification on the SCADA platform"
+ - "Certification under the Control System Integrators Association program"
+ - "Registered quality management system"
+ - "Application engineers under the direction of a licensed professional engineer"
+ - "Comparable-project references"
+default:
+ - "Current manufacturer certification on the controller platform"
+ - "Current manufacturer certification on the SCADA platform"
+ - "Comparable-project references"
+```
+### Certification under the Control System Integrators Association program means the integrator's engineering, project-management, quality, and financial practices have been audited against a published checklist by an independent auditor; where the Owner has no controls engineering staff of its own to evaluate an integrator's process, that audit stands in for one the Owner would otherwise have to perform, and where the Owner does have such staff the certification adds less. {note}
+
+### Where comparable-project references are required, the integrator shall furnish not fewer than the number of references indicated in the datasheet, each for a system placed in service within the preceding five years.
+
+```datasheet
+label: Minimum Comparable-Project References
+type: range
+unit: references
+options:
+ min: 1
+ max: 10
+ setpoints: [1, 2, 3, 5, 10]
+default: 3
+```
+
+### Where the facility is a water or wastewater treatment plant, the integrator's comparable experience shall include plant SCADA integration for treatment facilities of comparable unit-process scope.
+
+### Where the plant includes remote sites reporting by telemetry, the integrator's comparable experience shall include distributed telemetry integration.
+
+### A treatment plant is a chain of unit processes whose sequences interlock across the chain, and an integrator whose experience is confined to discrete manufacturing or single-skid systems has not encountered the plant-wide interactions that make treatment-plant integration a distinct competence. {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.
+### One party shall hold single point of responsibility for the integration, configuration, testing, and commissioning of the plant control system, and that party shall be the integrator, or the lead integrator where the datasheet selects discipline integrators.
−### 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.
+### Where a portion of the control system arrives as factory-programmed packaged-equipment controls, the responsible party shall remain responsible for integrating that subsystem into the plant SCADA and for verifying that every point in the integration register 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.
+### The responsible party shall verify, before the site acceptance test, that every point in the I/O list is present, correctly scaled, correctly named, and behaving as its narrative describes.
## 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.
+### Attendees shall include the integrator, the electrical contractor, the mechanical and process contractor, each packaged-equipment vendor whose equipment has a control interface, the Owner's operations and OT security 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.
+### The agenda shall include the division-of-responsibility matrix, the tag and I/O conventions, the network and OT boundary coordination, the interface method for each packaged subsystem, the test sequence and schedule, and the access controls that will govern engineering connections 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}
+## An unclear boundary between the integrator, the electrical trade, the process trade, and the vendors is the most frequent source of requests for information, disputes, and schedule slip on a controls project, and it fails in two ways at once: work performed twice and work performed by no one. {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}
+## Responsibility Matrix {toc}
−## 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.
+### A division-of-responsibility matrix shall be prepared by the integrator, agreed by every party at the pre-integration conference, and maintained through commissioning, assigning for every device and subsystem the furnish, install-and-wire, program, and test responsibility.
−## 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 matrix shall implement the assignments made in the datasheet under this article, and where the matrix and the datasheet disagree, the datasheet shall govern.
−## 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.
+### The party that authors the control narratives shall be as indicated in the datasheet.
−## 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.
+```datasheet
+label: Control Narrative Author
+type: select
+options:
+ - "Engineer of Record"
+ - "Control system integrator"
+ - "Owner's engineering staff"
+default: "Engineer of Record"
+```
−## Responsibility Matrix {toc}
+### The narrative states the process intent, and process intent belongs to whoever designed the process; where the Engineer of Record designed the treatment or production process, the narrative is that party's statement of how the design is meant to run, and an integrator asked to author it is being asked to reconstruct intent from the drawings. Under a design-build or progressive delivery in which the integrator sits inside the design team, the integrator authors from the process engineer's intent directly, and under an Owner with a fleet standard the Owner's staff may author to keep every plant on one convention. {note}
−### 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.
+### The party that authors the device-level logic shall be as indicated in the datasheet.
```datasheet
−label: Control Narrative Authorship
−type: radio
+label: Device-Level Logic Author
+type: select
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)"
+ - "Control system integrator"
+ - "Engineer of Record"
+ - "Owner's engineering staff"
+default: "Control system integrator"
```
−### 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.
+### Device-level logic is the standard behavior of a motor, a modulating valve, or an analog input regardless of the process it serves, and it is separable from the process narrative: one party can state that the lead pump starts on low level while another party writes the block that starts a pump, monitors its run feedback, and alarms on failure to start. {note}
+
+### The integration delivery model shall be as indicated in the datasheet.
+
```datasheet
−label: System Integration Delivery Model
+label: Integration Delivery Model
+type: select
+options:
+ - "Single integrator for the entire plant"
+ - "Discipline or area integrators with a designated lead integrator"
+ - "Owner-designated standard integrator"
+default: "Single integrator for the entire plant"
+```
+
+### A single integrator removes every seam between integrators but concentrates the schedule on one firm's capacity; discipline or area integrators spread the work across firms that each know their equipment and create a seam at the SCADA that the lead integrator has to own; an Owner-designated integrator keeps a fleet of plants on one convention and one support relationship at the cost of competitive pricing on the integration scope. {note}
+
+### The party that furnishes the control panels housing the controllers shall be as indicated in the datasheet.
+
+```datasheet
+label: Control Panel Furnishing Responsibility
+type: select
+options:
+ - "Control system integrator"
+ - "Electrical contractor"
+ - "Owner-furnished"
+default: "Control system integrator"
+```
+
+### The party that terminates field wiring at the control panel terminals shall be as indicated in the datasheet.
+
+```datasheet
+label: Field Wiring Termination at Control Panels
+type: select
+options:
+ - "Electrical contractor"
+ - "Control system integrator"
+ - "Control panel fabricator"
+```
+
+### Where the electrical contractor terminates at the panel, one trade owns the whole conductor from the field device to the terminal, and a wiring fault has one responsible party; where the integrator terminates at the panel, the party that will perform the loop check has landed the panel end itself and the termination drawing and the checkout sheet come from one hand, at the cost of a hand-off in the middle of every conductor. {note}
+
+### The party that performs instrument calibration for the loop checks shall be as indicated in the datasheet.
+
+```datasheet
+label: Instrument Calibration Responsibility
+type: select
+options:
+ - "Control system integrator"
+ - "Instrument supplier's service representative"
+ - "Mechanical and process contractor"
+ - "Independent calibration service"
+```
+
+### Field wiring routing and the wiring between field devices and panels shall be as indicated on [[drawing: the control wiring and interconnection diagrams]].
+
+## Trade Obligations {toc}
+
+### The integrator shall configure and program the controllers and the SCADA application, shall integrate every packaged subsystem, and shall provide the narratives, the I/O list, the loop diagrams, and the test procedures assigned to it under this standard.
+
+### The electrical trade shall furnish and install control power, raceways, control wiring, and instrument and valve field wiring in accordance with the project electrical standards, and shall land conductors at the field devices and at the panel terminals assigned to it in the datasheet.
+
+### The mechanical and process trade shall furnish and install the process equipment, the in-line instruments, and the final elements, and shall make each item available, with process fluid or a substitute where the test requires it, for loop checks and commissioning at the time the test schedule requires.
+
+### Each packaged-equipment vendor shall furnish its skid controls, shall expose the points listed for it in the integration register, and shall furnish the register map and interface documentation this standard requires.
+
+### Each packaged-equipment vendor shall make a controls representative available during the loop check and site testing of its subsystem, in the manner indicated in the datasheet.
+
+```datasheet
+label: Vendor Controls Representative During Subsystem Testing
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)"
+ - "On site"
+ - "Remote"
+ - "Not required"
```
−### 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 vendor whose controller misbehaves at the interface is the only party that can change that controller, so the question the datasheet settles is whether that party is in the room, on the phone, or reached later through a service call while the test waits. {note}
−## 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}
+# Control Narratives {toc}
−## 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 is the written sequence of operation for a process system: the human-readable statement of how the system is meant to behave under every condition, against which the logic is programmed, the tests are written, and the operators are trained. {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.
+## The narrative is the bridge between the process design and the executable logic, and every party downstream of it reads it differently: the programmer configures to it, the test engineer derives cases from it, and the operator learns the plant from it. {note}
−## 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.
+## A control narrative shall be provided for every process system within the scope of this standard.
−## 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.
+## The narratives shall be documented in the framework indicated in the datasheet.
+```datasheet
+label: Control Narrative Documentation Framework
+type: select
+options:
+ - "ISA-5.06.01 functional requirements format"
+ - "Owner's narrative template"
+ - "Integrator's standard narrative format"
+```
+
+## Where the Owner operates several plants, the Owner's template puts every plant's narrative in the same shape for the same operators; ISA-5.06.01 gives a project without such a template a published structure that separates the requirement from its implementation; and an integrator's own format is the one that firm's engineers write and test fastest, at the cost of being unfamiliar to the next integrator. {note}
+
## Narrative Content {toc}
−### Each control narrative shall address, at minimum, the following:
+### Each control narrative shall address the content indicated in the datasheet.
−- 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
+```datasheet
+label: Control Narrative Content Required
+type: checkbox
+options:
+ - "Process purpose and equipment served"
+ - "Normal automatic sequence"
+ - "Operator manual mode and available manual commands"
+ - "Startup and shutdown sequences with permissives"
+ - "Lead, lag, standby, and duty-rotation logic"
+ - "Interlocks and permissives with initiating condition and action"
+ - "Alarm conditions with priority and expected operator response"
+ - "Failure response on loss of signal, power, and communications"
+ - "Adjustable parameters listed with initial values"
+ - "Operator-entered limits and their permitted ranges"
+default:
+ - "Process purpose and equipment served"
+ - "Normal automatic sequence"
+ - "Operator manual mode and available manual commands"
+ - "Startup and shutdown sequences with permissives"
+ - "Lead, lag, standby, and duty-rotation logic"
+ - "Interlocks and permissives with initiating condition and action"
+ - "Alarm conditions with priority and expected operator response"
+ - "Failure response on loss of signal, power, and communications"
+ - "Adjustable parameters listed with initial values"
+```
−### 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]].
+### Each narrative shall be cross-referenced to the process and instrumentation diagram, to every control loop it affects, and to every I/O point it commands or reads, so that the narrative, the loop diagrams, and the I/O list form a closed and mutually consistent set.
−### A narrative that omits the failure response leaves the most safety-relevant behavior of the system undefined and untestable. {note}
+### Each step that depends on a setpoint, deadband, timer, or threshold shall identify that parameter as adjustable and shall state its initial value.
+### The fail-safe state of every final element shall be stated in the narrative and shall match the failure mode configured on the valve, actuator, or drive under [[sync/control-valves-and-actuators]].
+
+### The failure response is the most safety-relevant behavior a narrative describes and the one most often left out, and a narrative that omits it leaves that behavior undefined, unprogrammed, and untestable. {note}
+
+### Where the Engineer of Record authors the narratives, the integrator shall report in writing every condition it encounters in configuration that the narrative does not address, and shall not resolve such a condition by its own assumption.
+
## Control Modes {toc}
+### Every controlled loop and device shall support the control modes indicated in the datasheet, with the active mode displayed at the operator interface.
+
```datasheet
−label: Required Control Modes Per Loop
+label: Control Modes Required 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)"
+ - "Automatic"
+ - "Manual at the operator interface"
+ - "Local at the field device or local control station"
+ - "Off or locked out"
+ - "Cascade or remote setpoint"
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"
+ - "Automatic"
+ - "Manual at the operator interface"
+ - "Local at the field device or local control station"
+ - "Off or 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.
+### Where local mode is selected, the SCADA shall continue to monitor the device while it is under local control, shall display the local state, and shall not issue commands to the device until it is returned to remote control.
+### Cascade or remote setpoint mode applies to a loop whose setpoint is driven by another loop or by a supervisory calculation, and the narrative for such a loop shall state the source of the remote setpoint and the behavior when that source is unavailable.
+
+### Transfer between modes shall be bumpless for every modulating loop, so that a transfer from automatic to manual, or from manual back to automatic, 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}
+## One naming convention applied identically across the process and instrumentation diagrams, the I/O list, the controller logic, and the SCADA database is what lets an operator, a programmer, and a maintenance technician 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.
+## The tag naming basis shall be as indicated in the datasheet.
−## 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
+type: select
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)"
+ - "ANSI/ISA-5.1 loop-and-function tagging"
+ - "ANSI/ISA-5.1 tagging with an Owner asset-numbering overlay"
+ - "Owner naming standard mapped to ANSI/ISA-5.1 functions"
```
+## A new plant with no existing tag database can adopt ANSI/ISA-5.1 directly; an expansion or a migration of a plant that already carries thousands of tags in a maintenance management system inherits that plant's convention, and the question becomes how the new tags map onto it rather than which convention is cleaner. {note}
+
+## Instrument and loop tags shall identify the measured or initiating variable and the device function in accordance with ANSI/ISA-5.1.
+
+## Each loop shall carry a unique loop number, and every device within a loop shall share that number with a distinguishing function identifier.
+
+## A device shall carry one and only one tag across the drawings, the I/O list, the loop diagrams, the controller logic, and the SCADA database.
+
+## Where an Owner overlay or Owner standard is selected, the reconciliation between it and ANSI/ISA-5.1 shall be documented in the naming convention submittal.
+
# 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}
+## Controlled I/O List {toc}
−## 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 is the master index of every signal the control system reads or writes, and it is the basis of the point-to-point checkout, of the SCADA database build, and of the controller and panel sizing performed under the equipment standards. {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.
+### The integrator shall maintain a single controlled I/O list as the authoritative point database from the first submittal through as-built, and every revision to it shall be carried into the controller configuration and the SCADA database.
+### 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.
+
+### The analog signal standards, the spare I/O allowance, and the I/O module types are selected under [[sync/programmable-logic-controllers]], and the I/O list shall reflect the selections made there. {note}
+
+## Loop Diagrams {toc}
+
+### Loop diagrams shall be provided for the loops within the scope indicated in the datasheet.
+
```datasheet
−label: Analog Signal Standard
+label: Loop Diagram Scope
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"
+ - "Every control loop, analog and discrete"
+ - "Analog and modulating loops, with discrete points shown on panel wiring diagrams"
+ - "Panel wiring and interconnection diagrams in place of loop diagrams"
```
−### 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.
+### Each loop diagram provided shall conform to ANSI/ISA-5.4 and shall show every device in the loop, the signal path from sensor to final element, the wiring and terminations, and the power source.
−## Loop Diagrams {toc}
+### A loop diagram per loop is the document a technician carries to a loop check and to every later troubleshooting call; on a plant with a large discrete point count it is also the largest single drawing deliverable, and a discrete point whose whole path is a dry contact and a terminal is fully described on a wiring diagram. {note}
−### 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.
+# Software Configuration Management {toc}
−### 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}
+## Version Control and Baselines {toc}
−# Software Development and Configuration Management {toc}
+### Controller logic and the SCADA application are software, and they shall be developed, versioned, baselined, and backed up under a documented configuration management process.
−## 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 integrator shall place every controller program and the SCADA application under version control before the factory acceptance test.
−## 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.
+### A documented baseline of every program and application shall be recorded at each milestone indicated in the datasheet.
−## 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.
+```datasheet
+label: Configuration Baseline Milestones
+type: checkbox
+options:
+ - "Completion of the factory acceptance test"
+ - "Completion of the site acceptance test"
+ - "Completion of the performance verification test"
+ - "Substantial completion"
+ - "End of the warranty period"
+default:
+ - "Completion of the factory acceptance test"
+ - "Completion of the site acceptance test"
+ - "Substantial completion"
+```
−## 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.
+### Every change to a baselined program or application shall be recorded in a change log identifying what changed, why, who made the change, and when.
−## Modular and Reusable Logic {toc}
+### A change made in the field and never carried back into the baseline is the ordinary origin of a plant whose running program no longer matches any copy anyone holds. {note}
−### 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.
+## Backup and Restore {toc}
−### 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}
+### A full, restorable backup of every controller program, the SCADA application, graphics, alarm and historian configuration, and databases shall be maintained from the factory acceptance test baseline onward.
−### Where the process is batch or sequential, the control structure should follow the procedural and equipment models of ANSI/ISA-88.
+### A restore from backup onto a target other than the running system shall be demonstrated before substantial completion, and the demonstration shall be witnessed and recorded.
−## Verification and Validation {toc}
+### The backup methods and media for the SCADA platform are selected under [[sync/scada-and-hmi-systems]], and the restore demonstrated under this standard shall use them. {note}
−### 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.
+## Standard Device Logic {toc}
−### 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.
+### The source of the standard device blocks used for like devices shall be as indicated in the datasheet.
−# Third-Party and Packaged Equipment Integration {toc}
+```datasheet
+label: Standard Device Block Library Source
+type: select
+options:
+ - "Integrator's standard library"
+ - "Owner's standard library"
+ - "Platform manufacturer's process library"
+ - "Developed for the project"
+```
−## 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}
+### The program organization and the reuse of parameterized device blocks are required under [[sync/programmable-logic-controllers]]; this article settles only whose blocks are used. {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}
+### An Owner with a fleet of plants that all run one library gains a maintenance staff that recognizes every motor block on sight; an integrator's library is the one its engineers have already debugged; the platform manufacturer's library is supported past the life of either firm's relationship with the plant; and a library developed for the project fits a process no existing block describes, at the cost of being tested for the first time on this project. {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.
+### Each standard device block shall be tested once in full at the factory acceptance test, and each instance of the block thereafter shall be tested for its instance-specific parameters and its I/O assignment.
−## 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.
+### Where the process is batch or sequential, the control structure shall follow the procedural and equipment models of ANSI/ISA-88.00.01, and where a continuous process is automated as a sequence of procedures, the models of ISA-TR106.00.01 shall apply.
−## 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.
+## Verification Traceability {toc}
+### The software shall be verified against the control narratives and the I/O list through the test program of this standard, consistent with the verification and validation framework of IEEE 1012.
+
+### The test plans shall trace every narrative step and every I/O point to a test case, and a function that no test case demonstrates shall be treated as unverified.
+
+### The factory acceptance test shall exercise the controller logic using the simulation method indicated in the datasheet.
+
```datasheet
−label: Packaged Equipment Integration Method
+label: Factory Acceptance Test Simulation 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)"
+ - "Forced I/O at the controller"
+ - "Simulation panel with switches and signal sources"
+ - "Software process simulation driving the controller I/O"
+ - "Emulated controllers with a process model"
```
+### Forcing I/O at the controller proves the logic reads and writes the right bits and nothing else; a simulation panel adds the physical signal path and lets a witness operate the test; a software process model closes the loop so that a pump start produces a level change and the sequence can be run end to end; and emulated controllers with a model allow the whole plant to be run before any hardware exists, at the cost of building the model. The simulation method sets how much of the process behavior the factory test can prove and how much is left to the site. {note}
+
+# Packaged Equipment Integration {toc}
+
+## Integration Register {toc}
+
+### A process plant arrives as a collection of packaged skids, each with its own factory-programmed controller, and the plant SCADA is where all of them have to be made to look and behave like one system. {note}
+
+### The integrator shall obtain from each packaged-equipment vendor, and shall verify against the integration register, the native protocol, the register or object map, and the complete list of points the skid controller exposes.
+
+### The integrator shall integrate each packaged subsystem so that the operator sees a uniform tag tree and a consistent operating interface regardless of the underlying vendor platform.
+
+### The points each packaged subsystem exposes to the plant SCADA shall include, at minimum, those indicated in the datasheet.
+
```datasheet
−label: Integration Communication Protocol
+label: Packaged Subsystem Points Exposed to Plant SCADA
+type: checkbox
+options:
+ - "Run and ready status"
+ - "Fault status with fault code"
+ - "Local or remote mode status"
+ - "Principal process variables"
+ - "Principal setpoints the plant is permitted to command"
+ - "Active alarm list"
+ - "Runtime and cycle counts"
+ - "Energy and consumable usage"
+default:
+ - "Run and ready status"
+ - "Fault status with fault code"
+ - "Local or remote mode status"
+ - "Principal process variables"
+ - "Principal setpoints the plant is permitted to command"
+ - "Runtime and cycle counts"
+```
+
+### The datasheet selection sets the categories every subsystem exposes; the specific points within those categories differ skid by skid and are scheduled rather than selected. {note}
+
+### The specific points exposed by each subsystem shall be as indicated on [[drawing: the packaged-equipment interface schedules]].
+
+## Data Interface {toc}
+
+### The data interface between each packaged subsystem and the plant control system shall be as indicated in the datasheet.
+
+```datasheet
+label: Packaged Subsystem Data Interface
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"
+ - "Native protocol over the plant network"
+ - "Protocol gateway to the plant network"
+ - "OPC UA server on the skid controller"
+ - "Hardwired discrete and analog I/O"
```
−### 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.
+### The protocols permitted on the plant network are selected under [[sync/process-control-networks]], and a skid whose native protocol is on that set connects directly, while one whose protocol is not on it needs a gateway, an OPC UA server, or a hardwired interface; the datasheet selection is the policy applied where the register shows a mismatch. {note}
−### A network protocol may mirror a safety interlock for monitoring, but the protective action itself shall not depend on the network. {note}
+### A hardwired interface carries a fixed handful of signals and cannot be extended without pulling wire, but it depends on no firmware, no address table, and no protocol revision, and it is the interface the operator can trace with a meter. {note}
−# Alarm Management {toc}
+### Where a protocol gateway is used, the gateway shall be listed in the integration register, its configuration shall be placed under the configuration management of this standard, and its configuration backup shall be included in the closeout backup.
−## 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}
+## Safety-Critical Interlocks {toc}
−## 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.
+### The signal path for each safety-critical interlock between a packaged subsystem and the plant shall be as indicated in the datasheet.
−## 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: Safety-Critical Interlock Signal Path
+type: select
+options:
+ - "Hardwired discrete signal"
+ - "Safety-rated network protocol"
+default: "Hardwired discrete signal"
+```
+### A hardwired interlock is unaffected by a network fault, a switch reboot, or a protocol revision, and it is the arrangement the operator and the electrician can both trace; a safety-rated network protocol carries the interlock with a diagnostic coverage and a defined failure response that a plain protocol does not have, and it applies where the controllers on both ends support it and the network is engineered for it under [[sync/process-control-networks]]. {note}
+
+### Unless a safety-rated network protocol is selected in the datasheet, a safety-critical interlock shall not depend on a network protocol for its protective action.
+
+### The state of each safety-critical interlock shall be reported to the plant SCADA for indication over the data interface, and that indication shall not be the path by which the protective action is carried.
+
+# Secure Delivery of the Configured System {toc}
+
+## The OT cybersecurity baseline for the plant, including the zone-and-conduit architecture, device hardening, account management, patching, logging, and network backup, is established under [[sync/process-control-networks]], and the SCADA platform's role-based access, authentication, and audit logging under [[sync/scada-and-hmi-systems]]; this section governs what the integrator does while building and delivering the configuration inside that baseline. {note}
+
+## Every default and vendor-default credential on every controller, server, workstation, gateway, and integrated device delivered under this standard shall be changed before the site acceptance test, and the change shall be attested in the cybersecurity closeout record.
+
+## Accounts created in the delivered controllers and application shall be named individual accounts assigned to roles, and the integrator shall not leave a shared engineering account, a test account, or its own account active at substantial completion.
+
+## Services, ports, and protocols not required for plant operation shall be disabled on every delivered device, consistent with the hardening plan under [[sync/process-control-networks]].
+
+## Engineering workstations used to configure the delivered system shall be governed by the policy indicated in the datasheet.
+
```datasheet
−label: Alarm Priority Levels
+label: Integrator Engineering Workstation Policy
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)"
+ - "Owner-furnished engineering workstation only"
+ - "Integrator workstation after Owner scan and approval"
+ - "Integrator workstation without restriction"
```
+## A laptop that has visited a dozen other plants is the most common carrier of malware into an otherwise isolated control network, and the workstation policy is what decides whether that laptop touches this one. {note}
+
+## Removable media used to transfer configuration to a delivered device shall be scanned on an Owner-approved station before use, and media used on the plant network shall not be reused outside it.
+
+## Remote Engineering Access {toc}
+
+### Remote engineering access for the integrator during commissioning and warranty support shall be as indicated in the datasheet.
+
```datasheet
−label: Alarm Suppression and Shelving Methods
−type: checkbox
+label: Integrator Remote Engineering Access
+type: select
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)]
+ - "None"
+ - "Owner-managed VPN with multi-factor authentication to a jump host"
+ - "Owner-controlled vendor support connection enabled per session"
```
−### 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.
+### Where no remote engineering access is selected, all commissioning support and warranty correction shall be performed on site, and the warranty response time of this standard shall be measured to arrival on site.
−# Operator Interface {toc}
+### Where remote engineering access is provided, it shall traverse a path controlled, authenticated, and logged by the Owner, and the integrator shall not install or retain a connection of its own.
−## 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}
+### A persistent always-on vendor connection shall not be provided.
−## 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.
+### Remote access resolves a warranty call in an hour instead of a day and is the difference between a tuning correction made the same afternoon and one made after a site visit is scheduled; an air-gapped plant gives that up in exchange for having no path at all to defend, and the choice belongs to the Owner's security program rather than to the integrator. {note}
−## 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.
+# Functional Safety Interface {toc}
−## 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.
+## Where a safety instrumented function exists, it is implemented in a logic solver separate from and independent of the basic process control system, and this standard governs only the seam between the two. {note}
−### 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}
+## Verification of the interface between the basic process control system and the safety instrumented system shall be as indicated in the datasheet.
−# Cybersecurity Coordination {toc}
+```datasheet
+label: Safety Instrumented System Interface Verification
+type: radio
+derived: "the presence of a safety instrumented function that interfaces with the basic process control system, as identified in the project safety requirements specification"
+options:
+ - "Required"
+ - "Not applicable"
+default: derived
+```
−## 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}
+## Where interface verification is required, the integrator shall verify during the site acceptance test that each interface behaves exactly as the safety requirements specification defines, including that a trip drives the basic-control final elements to their defined safe state and that the basic process control system cannot command a state the safety system has tripped.
−## 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 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 safety system under IEC 61511.
−## 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.
+## Any bypass, maintenance override, or reset of a safety function presented at the operator interface shall be implemented as the safety system design defines, shall be access-controlled, and shall be alarmed and logged while active.
−## Secure Configuration {toc}
+## The integrator shall not modify the configuration of a safety logic solver except as authorized in writing under the project functional-safety management-of-change procedure, with the authorization retained in the configuration management record.
−### 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.
+# Testing {toc}
−### 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.
+## Test Sequence {toc}
−### Unused services, ports, and protocols on delivered controllers and servers shall be disabled, leaving only those required for plant operation.
+### The test program shall proceed in the sequence of factory acceptance test, installation, loop checks with calibration and stroking, site acceptance test, site integration test, performance verification test, and endurance test, with each phase complete and documented before the next begins.
−### 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.
+### Each phase shall be conducted under a written procedure returned by the Engineer of Record before the phase begins, and each test case shall record the expected result, the observed result, the pass or fail determination, and the signature of the party who witnessed it.
+### Where the parties disagree whether an observed result meets the acceptance criterion, the Engineer of Record shall make the initial determination.
+
+## Factory Acceptance Test {toc}
+
+### A factory acceptance test conforming to ANSI/ISA-62381 shall be performed on the assembled and configured control system before it is shipped to the site.
+
+### The factory acceptance test shall be conducted at the location indicated in the datasheet.
+
```datasheet
−label: Remote Access Method
−type: radio
+label: Factory Acceptance Test Location
+type: select
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"
+ - "Integrator's facility"
+ - "Control panel fabricator's facility"
+ - "Owner-designated staging facility"
+default: "Integrator's facility"
```
−### 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.
+### The integrator shall give the Owner and the Engineer of Record written notice of the factory acceptance test date not less than the number of days indicated in the datasheet before the test begins.
−# Functional Safety Interface {toc}
+```datasheet
+label: Factory Acceptance Test Notice Period
+type: range
+unit: days
+options:
+ min: 7
+ max: 30
+ setpoints: [7, 10, 14, 21, 30]
+default: 14
+```
−## 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 Owner's witnessing of the factory acceptance test shall be as indicated in the datasheet.
−## 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.
+```datasheet
+label: Owner Factory Acceptance Test Witnessing
+type: select
+options:
+ - "In person"
+ - "Remote by video and screen share"
+ - "Report review without witnessing"
+```
−## 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.
+### The Engineer of Record's witnessing of the factory acceptance test shall be as indicated in the datasheet.
−## 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.
+```datasheet
+label: Engineer Factory Acceptance Test Witnessing
+type: select
+options:
+ - "In person"
+ - "Remote by video and screen share"
+ - "Report review without witnessing"
+```
−## The integrator shall not modify safety logic solver configuration except under the project functional-safety management of change procedure, with the authorization recorded.
+### Remote witnessing covers a screen-based test as well as presence does, because the logic, the graphics, and the alarm behavior are all on the screen being shared; a test that also inspects the assembled panels, the wiring, and the physical simulation is one a remote witness cannot see, and a plant whose operators will run the system for twenty years is one the Owner's staff often chooses to meet at the factory. {note}
−# Testing {toc}
+### The factory acceptance test shall cover the elements indicated in the datasheet.
−## Factory Acceptance Test {toc}
+```datasheet
+label: Factory Acceptance Test Scope
+type: checkbox
+options:
+ - "Every control narrative sequence"
+ - "Mode transitions and bumpless transfer"
+ - "Interlock and permissive behavior"
+ - "Alarm generation against the rationalized alarm list"
+ - "Packaged subsystem interfaces by simulation"
+ - "Integrated network with every controller and server connected"
+ - "Safety instrumented system interface by simulation"
+ - "Backup and restore of the tested baseline"
+default:
+ - "Every control narrative sequence"
+ - "Mode transitions and bumpless transfer"
+ - "Interlock and permissive behavior"
+ - "Alarm generation against the rationalized alarm list"
+ - "Packaged subsystem interfaces by simulation"
+```
−### 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 controller-hardware and SCADA-platform tests of the factory acceptance test are specified under [[sync/programmable-logic-controllers]] and [[sync/scada-and-hmi-systems]], and the integrated test under this standard shall be conducted with those tests, on the same assembled system. {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.
+### The proportion of I/O points exercised by simulation at the factory acceptance test shall be not less than that indicated in the datasheet.
−### 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: I/O Point Coverage at the Factory Acceptance Test
+type: range
+unit: '%'
+options:
+ min: 10
+ max: 100
+ setpoints: [10, 25, 50, 100]
+default: 100
+```
+### The basis on which the factory acceptance test is accepted for shipment shall be as indicated in the datasheet.
+
```datasheet
−label: FAT Witnessing
−type: radio
+label: Factory Acceptance Test Acceptance Basis
+type: select
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)"
+ - "Every item closed before shipment"
+ - "Critical items closed before shipment and minor items carried to the site punch list"
```
−### 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 critical item is a failed test case affecting a control narrative sequence, an interlock, a permissive, a fail-safe response, or an alarm; a minor item is one that affects only presentation or documentation, and where the parties disagree on the classification of an item, the Engineer of Record shall make the initial determination.
−### 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.
+### Where the factory acceptance test is stopped or repeated because of defects in work under this standard, the integrator shall bear the cost of the repeated test, including the travel and time of the witnesses.
−### 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.
+### A defect found at the factory costs a software edit; the same defect found on site costs mobilization, process downtime, and schedule, which is why the factory test is the least expensive test on the project to make thorough. {note}
−## Loop Checks and Point-to-Point Checkout {toc}
+## Loop Checks {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.
+### A loop check conforming to ANSI/ISA-62382 shall be performed on every I/O point after installation and before the site acceptance test, verifying continuity from the field device through the wiring and the controller to a correctly scaled and correctly named indication at the operator interface.
−### 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 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 operator interface at not fewer than three points across the range, and each analog output loop by commanding known outputs 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.
+### Each discrete point shall be verified by actuating the field condition and confirming the state and tag at the operator interface, and each discrete output by commanding it 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]].
+### Instrument calibration shall be performed with the loop check by the party assigned in the datasheet, against a reference traceable to a national standard, with as-found and as-left readings recorded, using the methods specified for each instrument class under [[sync/process-instrumentation]], [[sync/flow-measurement]], [[sync/analytical-instrumentation]], and [[sync/level-sensors]].
−### 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.
+### Each control valve and actuator shall be stroked with the loop check and its travel verified against command, and its fail-safe position shall be confirmed by removing the signal and separately by removing the power, in coordination with [[sync/control-valves-and-actuators]].
+### The loop check documentation shall include the records indicated in the datasheet.
+
```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)"
+ - "Per-loop checkout sheet"
+ - "Instrument calibration record"
+ - "Valve and actuator stroke record"
+ - "Fail-safe position verification record"
- "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)"
+ - "Per-loop checkout sheet"
+ - "Instrument calibration record"
+ - "Valve and actuator stroke record"
+ - "Fail-safe position verification record"
```
+### The per-loop checkout sheet shall record the tag, the signal injected or condition actuated, the expected and observed values at each test point, the pass or fail determination, and the signature of the person who performed the check.
+
+### The Engineer of Record shall witness not less than the proportion of loop checks indicated in the datasheet, selected by the Engineer of Record across every controller and process system.
+
+```datasheet
+label: Loop Checks Witnessed by the Engineer
+type: range
+unit: '%'
+options:
+ min: 0
+ max: 100
+ setpoints: [0, 10, 25, 50, 100]
+```
+
+### A witnessed sample proves the integrator's own checkout is trustworthy at a fraction of the witness time a full audit costs; a fully witnessed loop check is the arrangement where the loop count is small or where the consequence of a wrong point is high enough that the Owner wants its own signature on every loop. {note}
+
+### Where a witnessed loop fails, the Engineer of Record may expand the witnessed sample, and the cost of the expanded witnessing shall be borne by the integrator.
+
+## Site Acceptance Test {toc}
+
+### A site acceptance test conforming to ANSI/ISA-62381 shall be performed after the loop checks are complete to verify the installed system against the narratives under field conditions, repeating the factory test cases that depend on real field devices.
+
+### The site acceptance test shall confirm that every I/O point is present, scaled, named, and behaving as its narrative describes, and shall verify the safety instrumented system interfaces where the datasheet requires their verification.
+
+### The controller and SCADA site tests specified under [[sync/programmable-logic-controllers]] and [[sync/scada-and-hmi-systems]] shall be conducted with the site acceptance test under this standard. {note}
+
+## Site Integration Test {toc}
+
+### A site integration test conforming to ANSI/ISA-62381 shall be performed after the site acceptance test to verify the interfaces between the plant control system and every packaged subsystem, the network and its boundary devices, and every remote site, with the real vendor controllers and the real network in place.
+
+### For each packaged subsystem, the site integration test shall confirm that every point in the integration register is read or written correctly at the plant SCADA, that the subsystem's local and remote modes behave as its narrative describes, and that each safety-critical interlock acts through the path selected in the datasheet.
+
+### The site integration test shall confirm the behavior of every integrated interface on loss and restoration of communication, including the state the plant SCADA displays and the state the subsystem assumes.
+
+### A subsystem that passed its own factory test and a plant that passed its site acceptance test have each been proven alone; the site integration test is the first time either is proven against the other, and the loss-of-communication case is the one neither party tested. {note}
+
## 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.
+### A performance verification test shall be performed after the site integration test to demonstrate that the integrated system performs its sequences under live process conditions.
−### 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.
+### The performance verification test shall exercise every control narrative under actual operation, including automatic control, mode transitions, lead, lag, and standby rotation, interlocks, permissives, and the response to induced abnormal conditions.
−### 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.
+### Each regulatory control loop shall be tuned during the performance verification test so that it is stable and responsive without sustained oscillation or steady offset at the operating conditions available during the test, and the final tuning values shall be recorded in the as-built narrative.
+### Alarm setpoints, deadbands, and on-delays shall be tuned during the performance verification test against the rationalized alarm list established under [[sync/scada-and-hmi-systems]], so that nuisance alarms are suppressed while genuine ones are preserved, and the final values shall be recorded in the as-built narrative.
+
+### The Owner shall provide process feed, operating staff, and the operating conditions required by the test procedure during the performance verification test and the endurance test.
+
+### A loop tuned at the conditions of a spring startup may oscillate in the summer, which is why the tuning correction under seasonal conditions is a warranty obligation of this standard rather than an extra. {note}
+
## 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.
+### An endurance test shall be performed after the performance verification test for the continuous period indicated in the datasheet, to demonstrate that the integrated system operates without unexplained failure over a sustained period.
```datasheet
label: Endurance Test Duration
+type: range
+unit: days
+options:
+ min: 0
+ max: 60
+ setpoints: [0, 3, 7, 14, 30, 60]
+```
+
+### Seven days covers every daily cycle and one full weekly cycle of the plant's operation; thirty days covers the monthly cycles of filter backwash, sludge wasting, and reporting that a week never reaches, at the cost of a month of the integrator's attendance; and a duration of zero waives the endurance test, which is the arrangement where the plant will run under the integrator's warranty attendance in any case. {note}
+
+### During the endurance test the system shall operate continuously with no unexplained failure of any controller, server, network segment, or integrated subsystem.
+
+### The restart of the endurance period after a failure shall be as indicated in the datasheet.
+
+```datasheet
+label: Endurance Test Restart After Failure
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)"
+ - "Period restarts from zero after any failure"
+ - "Period restarts from zero after a failure attributable to work under this standard"
+ - "Period pauses during correction and resumes"
```
−### 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.
+### A restart after any failure holds the integrator to failures of equipment it did not furnish, which on a plant full of vendor skids can extend the test indefinitely; a restart only after a failure attributable to this standard's work leaves a failure of a packaged subsystem to that vendor's warranty; and a pause-and-resume treats the endurance period as a quantity of proven hours rather than as a proven uninterrupted stretch. {note}
−# Startup and Commissioning {toc}
+### Where the parties disagree whether a failure is attributable to work under this standard, the Engineer of Record shall make the initial determination.
−## 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.
+### Trend and historian data shall be retained for the full endurance period, and where the buffer capacity is insufficient, the data shall be offloaded during the test so that no record is lost.
−## 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.
+# Startup and Commissioning {toc}
−## 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.
+## The integrator shall coordinate commissioning with the electrical and process trades, the packaged-equipment vendors, and the Commissioning Authority where one is engaged, so that each item is installed, energized, and available when the phase that needs it is scheduled.
−## 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.
+## The Commissioning Authority, where engaged, shall witness the site acceptance test, the performance verification test, and the endurance test, and shall verify the as-built narratives, the I/O list, and the alarm and interlock behavior.
−## 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}
+## Every force and override placed in controller logic or at the operator interface to facilitate testing shall be logged at the time it is placed, with the point, the reason, the person, and the date.
−# Training {toc}
+## Every logged force and override shall be removed before substantial completion, and the removal shall be verified by a second person and recorded in the force and override removal record.
−## Operator Training {toc}
+## A force left in a controller after commissioning defeats a control or protective function silently and is found when that function is needed, which is why the removal is verified by a second person rather than reported by the one who placed it. {note}
−### 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.
+## Commissioning phases and milestones shall be identified in the test schedule in the terms of IEC 62337, so that every party names each phase the same way.
−### Operator training shall be conducted on the commissioned system or an equivalent simulation, hands-on, before the Owner assumes operation.
+# Training {toc}
−## Maintenance Training {toc}
+## Operator training on the SCADA platform, its displays, alarm handling, and trending is provided under [[sync/scada-and-hmi-systems]]; the training under this standard covers the plant's process sequences as configured and the maintenance of the delivered configuration. {note}
−### 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.
+## The integrator shall provide the training sessions indicated in the datasheet.
```datasheet
−label: Training Delivery
+label: Training Sessions Provided
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"
+ - "Process operation training on the control narratives"
+ - "Maintenance training on the I/O list, loop diagrams, and troubleshooting"
+ - "Configuration management and backup and restore training"
+ - "Cybersecurity practices for the delivered system"
+ - "Recorded sessions delivered to the Owner"
default:
− - "Operator training (narratives, HMI, alarms, modes, routine operation)"
− - "Maintenance training (I/O, loop diagrams, troubleshooting, calibration)"
− - "Configuration management and backup/restore training"
+ - "Process operation training on the control narratives"
+ - "Maintenance training on the I/O list, loop diagrams, and troubleshooting"
+ - "Configuration management and backup and 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}
+## Process operation training shall cover the control narratives as commissioned, the control modes and the transfers between them, the interlocks and permissives, and the expected operator response to each alarm, and shall be conducted hands-on on the commissioned system or a simulation of it before the Owner assumes operation.
+
+## The duration of process operation training shall be not less than that indicated in the datasheet.
+
+```datasheet
+label: Process Operation Training Duration
+type: range
+unit: hours
+options:
+ min: 0
+ max: 80
+ setpoints: [0, 4, 8, 16, 24, 40, 80]
+```
+
+## Maintenance training shall cover the I/O list and loop diagrams, point-to-point troubleshooting, the coordination of instrument calibration and valve stroking with the control system, the configuration management and backup and restore procedure, and the cybersecurity provisions the Owner maintains after acceptance.
+
+## The duration of maintenance training shall be not less than that indicated in the datasheet.
+
+```datasheet
+label: Maintenance Training Duration
+type: range
+unit: hours
+options:
+ min: 0
+ max: 80
+ setpoints: [0, 4, 8, 16, 24, 40, 80]
+```
+
+## Where recorded sessions are selected, the recordings shall be delivered to the Owner in a common playback format, so that staff hired after commissioning can be trained on the system as built.
+
# 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 integrator 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 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 as-built narratives shall be delivered in an editable format and in a portable format, so that the Owner can revise them when the plant is next modified.
−## 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 operation and maintenance data delivered under this standard shall be prepared in accordance with [[sync/operation-and-maintenance-data]] and shall be closed out in accordance with [[sync/closeout-procedures]].
−## 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.
+## The as-built documentation is what allows the Owner to operate, troubleshoot, and eventually modify the control system after the integrator has left, and an as-built narrative that still carries the design setpoints rather than the commissioned ones is a document that misleads the next engineer to open it. {note}
# Warranty {toc}
−## Warranty Terms {toc}
+## The integrator shall warrant the integration, configuration, and programming against defects for the period indicated in the datasheet, measured from substantial completion.
−### The integrator shall warrant the integration, configuration, and programming against defects for a minimum of one year from substantial completion.
+```datasheet
+label: Integration Warranty Term
+type: range
+unit: years
+options:
+ min: 1
+ max: 3
+ setpoints: [1, 2, 3]
+default: 1
+```
−### 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.
+## Where the contract documents state a longer warranty period than the datasheet, the longer period shall govern.
+## During the warranty period the integrator shall correct configuration and programming defects, including loop tuning and alarm deficiencies that appear under seasonal, load, or process conditions not present at commissioning, at no cost to the Owner.
+
+## The integrator shall respond to a warranty call within the time indicated in the datasheet, measured from the Owner's notice to the integrator's engineer beginning work on the reported condition, remotely where the datasheet provides remote access and on site where it does not.
+
```datasheet
−label: Integration Warranty Term
−type: select
+label: Warranty Response Time
+type: range
+unit: hours
options:
− - "1 year from substantial completion (standard)"
− - "2 years from substantial completion"
− - "Extended term per Owner requirement"
−default: "1 year from substantial completion (standard)"
+ min: 2
+ max: 72
+ setpoints: [2, 4, 8, 24, 48, 72]
```
−### 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}
+## A response time measured in hours presumes a remote path or a local integrator; a plant with no remote access and an integrator several hundred miles away can be promised a day, and the datasheet should carry the number the selected access arrangement can actually meet. {note}
−## Software and Configuration {toc}
+## Warranty corrections shall be made to the controlled baseline under the configuration management of this standard, and never to an undocumented field copy, and each correction shall be recorded in the change log and carried into a refreshed backup.
−### 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.
+## Work performed under this warranty shall itself be warranted for a full new term equal to the original period measured from the date the correction is completed, or for the remainder of the original period, whichever ends later.
+# Software and Configuration Turnover {toc}
+
+## The integrator shall turn over to the Owner the items indicated in the datasheet before substantial completion, and shall obtain a signed receipt for them.
+
```datasheet
label: Software and Configuration Turnover
type: checkbox
options:
− - "Licensed development/configuration software for controllers and SCADA"
+ - "Licensed development software for the controller platform"
+ - "Licensed development software for the SCADA platform"
- "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]
+ - "Source configuration for the SCADA application and graphics"
+ - "Gateway and network device configurations"
+ - "Verified backup media with the documented restore procedure"
+ - "Standard device block library with documentation"
+default:
+ - "Licensed development software for the controller platform"
+ - "Licensed development software for the SCADA platform"
+ - "Source configuration for every controller program"
+ - "Source configuration for the SCADA application and graphics"
+ - "Verified backup media with the documented restore procedure"
```
−### 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.
+## The ownership and registration of the SCADA platform licenses are governed by [[sync/scada-and-hmi-systems]], and the turnover under this standard is in addition to that transfer. {note}
−### 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}
+## The Owner shall receive the rights and the media necessary to maintain and modify the delivered control system without dependence on the integrator, subject only to the platform licensing.
+
+## Source configuration shall be turned over with the symbol names, comments, and documentation intact, and not as a compiled or stripped runtime.
+
+## A compiled runtime without the source configuration leaves the Owner unable to make even a trivial change, and a source file stripped of its comments leaves the next engineer reverse-engineering the plant's own logic; the controlled, documented source is the deliverable that makes the system the Owner's. {note}