1 Scope
NOTE 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. (1.1)
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. (1.2)
NOTE This standard applies to new plants, plant expansions, and control system replacements (migrations) in industrial, process, and municipal water and wastewater facilities. (1.3)
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. (1.4)
1.6Where 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.
1.7 Scope Boundaries
NOTE 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. (1.7.1)
NOTE Cybersecurity provisions in this standard are the integration-seam responsibilities of the integrator — secure configuration, account setup, network segmentation coordination, and hardening of the delivered application — applied within the zone-and-conduit architecture established by ISA/IEC 62443; the Owner's OT security program governs above this baseline. (1.7.2)
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. (1.7.3)
1.7.4The 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.
2 Referenced Standards
2.1Work under this standard shall comply with the latest adopted edition of the following standards unless a specific edition is cited.
2.2Where conflicts exist between referenced standards, the more stringent requirement shall govern unless the Engineer of Record directs otherwise in writing.
| Standard |
Title |
| ANSI/ISA-5.1 |
Instrumentation Symbols and Identification |
| ANSI/ISA-5.4 |
Instrument Loop Diagrams |
| ISA-5.06.01 |
Functional Requirements Documentation for Control Software Applications |
| ANSI/ISA-62381 (IEC 62381 modified) |
Automation Systems in the Process Industry — Factory Acceptance Test (FAT), Site Acceptance Test (SAT), and Site Integration Test (SIT) |
| ISA-TR105.00.01 |
Documentation of FAT/SAT/SIT for Automation Systems |
| ANSI/ISA-101.01 |
Human Machine Interfaces for Process Automation Systems |
| ANSI/ISA-18.2 |
Management of Alarm Systems for the Process Industries |
| ANSI/ISA-88.00.01 |
Batch Control — Part 1: Models and Terminology |
| ANSI/ISA-95.00.01 |
Enterprise-Control System Integration — Part 1: Models and Terminology |
| ANSI/ISA-106 |
Procedure Automation for Continuous Process Operations |
| ANSI/ISA/IEC 62443 (series) |
Security for Industrial Automation and Control Systems |
| IEC 61511 / ANSI/ISA-84.00.01 |
Functional Safety — Safety Instrumented Systems for the Process Industry Sector |
| IEEE 1012 |
System, Software, and Hardware Verification and Validation |
| NIST SP 800-82 |
Guide to Operational Technology (OT) Security |
| NFPA 70 |
National Electrical Code (Articles 725 — Class 2 control circuits, 800 — Communications) |
| NFPA 79 |
Electrical Standard for Industrial Machinery (functional testing of control functions) |
| ISA-84 / ISA-91 |
Identification and Application of Safety Instrumented and Permissive Functions |
| 10 States Standards |
Recommended Standards for Water Works / Wastewater Facilities (water/wastewater instrumentation and control reference) |
3 Submittals
3.1 Action Submittals
3.1.1The Contractor shall submit the following for the Engineer's review and return before configuration and field integration proceed:
- Division-of-responsibility matrix, identifying for every system and packaged item which party furnishes the device, which party wires it, which party programs it, and which party tests it
- Control narratives / process control descriptions for every process system, written as the sequences of operation, including normal, abnormal, alarm, interlock, permissive, fail-safe, and manual-override behavior, cross-referenced to the P&IDs and to each affected loop and I/O point
- Complete I/O list, organized by controller and by process system, listing each point's tag, description, signal type, engineering range, scaling, normal state, failure state, and the controller/module/channel assignment
- Tag and point naming convention document conforming to ANSI/ISA-5.1, including the loop-numbering scheme and any Owner-mandated naming overlay
- Control loop descriptions and loop diagrams per ANSI/ISA-5.4 for each regulatory and discrete control loop
- Software development and configuration management plan, identifying the version control system, the controller and SCADA application baselining method, the change-log procedure, and the backup and recovery method
- Network architecture and integration drawing showing controllers, the SCADA/HMI servers and clients, the process control network segments, the OT/IT boundary, and every third-party and packaged-equipment integration with its protocol and gateway identified
- Third-party / packaged-skid integration register, listing each OEM controller to be integrated, its native protocol, the points to be exposed to the plant SCADA, and the gateway or driver method
- HMI graphics intent per ANSI/ISA-101.01, including the display hierarchy, navigation model, color and status convention, and representative process graphics with live point overlays
- Alarm rationalization deliverable per ANSI/ISA-18.2, listing each alarm with its setpoint, priority, consequence, operator response, and any suppression or shelving rule
- Factory acceptance test (FAT) plan and procedures per ANSI/ISA-62381, with the test point list and pass/fail criteria
- Site acceptance test (SAT), loop check, performance verification test (PVT), and endurance test plans and procedures, with schedules and acceptance criteria
- Cybersecurity configuration plan addressing zone-and-conduit segmentation, account and role design, secure-protocol selection, patch baseline, removable-media policy, remote-access method, and audit logging, at a level of detail consistent with the project ISA/IEC 62443 target security levels
- Operator and maintenance training plan, identifying course content, duration, audience, and materials
☐ Division-of-responsibility matrix
☐ Control narratives / process control descriptions
☐ Complete I/O list by controller and process system
☐ ISA-5.1 tag and point naming convention
☐ Control loop descriptions and ISA-5.4 loop diagrams
☐ Software development and configuration management plan
☐ Network architecture and integration drawing
☐ Third-party / packaged-skid integration register
☐ ISA-101.01 HMI graphics intent
☐ ISA-18.2 alarm rationalization deliverable
☐ FAT plan and procedures (ISA-62381)
☐ SAT, loop check, PVT, and endurance test plans
☐ Cybersecurity configuration plan (ISA/IEC 62443)
☐ Operator and maintenance training plan
3.1.2The 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.
3.1.3Submittals 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.
3.2 Closeout Submittals
3.2.1The Contractor shall provide the following before the control system is accepted at substantial completion:
- As-built control narratives reflecting the sequences as commissioned, with every field-tuned setpoint, deadband, timer, and interlock recorded at its final value
- As-built I/O list and tag database reflecting the final installed points, scaling, alarm limits, and channel assignments
- As-built loop diagrams per ANSI/ISA-5.4 reflecting installed routing and terminations
- Complete copy of all controller programs, the SCADA/HMI application, graphics, alarm and historian configuration, and the server database, in the manufacturer's native backup format and in a portable export where available
- Software configuration management record showing the final baseline version of every controller program and application, with the change log from FAT through commissioning
- Signed FAT, SAT, loop check, PVT, and endurance test reports with all punch-list items closed
- Instrument calibration records for every analog loop, showing as-found and as-left readings against a traceable reference
- Valve and actuator stroke and travel records for every modulating and on/off final element commissioned under this scope
- Cybersecurity closeout: account and role inventory, installed firmware and software versions with patch dates, configured backup schedule, and signed acknowledgement that all default and vendor-default credentials have been changed
- Operation and maintenance manuals including the as-built sequences, the tag database, alarm response guidance, and recommended preventive maintenance
- Training records documenting personnel trained, dates, and topics
☐ As-built control narratives (final tuned values)
☐ As-built I/O list and tag database
☐ As-built ISA-5.4 loop diagrams
☐ Complete program, application, graphics, and database backup
☐ Software configuration management record and change log
☐ Signed FAT, SAT, loop check, PVT, and endurance test reports
☐ Instrument calibration records (as-found / as-left)
☐ Valve and actuator stroke and travel records
☐ Cybersecurity closeout (accounts, versions, backup, credential acknowledgement)
☐ Operation and maintenance manuals
☐ Training records
4 Quality Assurance
4.1 Integrator Qualifications
4.1.1The 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.
4.1.2For municipal water and wastewater work, the integrator shall have documented experience integrating plant SCADA for treatment facilities of comparable unit-process scope.
4.1.3The integrator should maintain a documented quality management system and certified application engineers on the proposed controller and SCADA platforms.
NOTE 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. (4.1.4)
4.2 Single Point of Responsibility
4.2.1The 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.
4.2.2Where 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.
4.2.3The 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.
4.3 Pre-Integration Conference
4.3.1A pre-integration conference shall be held before any control system field integration begins.
4.3.2Attendees 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.
4.3.3The 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.
5 Division of Responsibility
NOTE 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. (5.1)
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. (5.2)
5.3The 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.
5.4The electrical trade shall furnish and install control power, raceways, control wiring, instrument and valve field wiring, and panel terminations per Industrial Control Panels and the project electrical standards, and shall land conductors at field devices and at controller terminals. 5.5The 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.
5.6Each 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.
5.7 Responsibility Matrix
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. (5.7.1)
○ 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
NOTE 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. (5.7.2)
○ 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)
6 Control Narratives and Process Control Descriptions
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. (6.1)
NOTE The narrative is the bridge between the process design and the executable logic: the programmer configures to it, the test engineer writes FAT and SAT cases from it, and the operator is trained on it. (6.2)
6.3A 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.
6.4Each 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.
6.5Each 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.
6.6 Narrative Content
NOTE Each control narrative shall address, at minimum, the following: (6.6.1)
- 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
NOTE A narrative that omits the failure response leaves the most safety-relevant behavior of the system undefined and untestable. (6.6.3)
6.7 Control Modes
☐ 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)
6.7.1Every controlled loop and device shall support, at minimum, automatic, manual, and local/off modes, with the active mode displayed at the operator interface.
6.7.2Transfer between modes shall be bumpless for modulating loops, so that switching from automatic to manual does not step the final element.
7 Tag and Point Naming
NOTE 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. (7.1)
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. (7.2)
7.3Instrument 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.
7.4Each 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.
7.5The 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.
7.6Where 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.
○ 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
NOTE 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. (8.1)
NOTE The Contractor shall maintain a single controlled I/O list as the authoritative point database from design through as-built, and every revision shall be reflected in the controller configuration and the SCADA database. (8.2)
8.3The 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.
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
NOTE 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. (8.3.1)
8.3.2A spare I/O allowance shall be provided on each controller; the spare allowance shall be as indicated on the I/O schedules and should be a minimum of 15% spare channels of each type for future expansion. 8.4 Loop Diagrams
8.4.1A 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.
NOTE 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. (8.4.2)
9 Software Development and Configuration Management
NOTE 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. (9.1)
9.2The 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.
9.3Every 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.
9.4A 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.
9.5 Modular and Reusable Logic
9.5.1Controller 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.
NOTE 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. (9.5.2)
9.5.3Where the process is batch or sequential, the control structure should follow the procedural and equipment models of ANSI/ISA-88.
9.6 Verification and Validation
9.6.1The 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.
NOTE 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. (9.6.2)
10 Third-Party and Packaged Equipment Integration
NOTE 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. (10.1)
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. (10.2)
10.3For 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.
10.4The 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.
10.5The 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.
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
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
NOTE 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. (10.5.1)
10.5.2Safety-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.
NOTE A network protocol may mirror a safety interlock for monitoring, but the protective action itself shall not depend on the network. (10.5.3)
11 Alarm Management
NOTE 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. (11.1)
11.2The 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.
11.3Each alarm shall be actionable — an alarm to which the operator can take no action shall be reclassified as an indication, not an alarm.
3 levels (High / Medium / Low)
4 levels (Critical / High / Medium / Low)
4 levels with a separate Safety/Emergency class
☐ 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
11.3.1Alarm 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.
11.3.2Alarm setpoints, deadbands, and on-delays shall be tunable and shall be tuned during commissioning to suppress nuisance alarms while preserving genuine ones.
12 Operator Interface
NOTE 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. (12.1)
12.2The 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.
12.3Color 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.
12.4Each 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.
13 Cybersecurity Coordination
NOTE 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. (13.1)
13.2The 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.
13.3The integrator shall coordinate the OT/IT boundary, network segmentation, and any remote-access provision with the Owner's OT security organization and with Process Control Networks; the Owner's program governs above this baseline. 13.4 Secure Configuration
13.4.1All 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.
13.4.2The delivered system shall implement role-based access control with named individual accounts; shared accounts shall not be used for operator, engineer, or administrator access.
13.4.3Unused services, ports, and protocols on delivered controllers and servers shall be disabled, leaving only those required for plant operation.
13.4.4Where 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.
○ 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
13.4.5Remote access, where provided, shall traverse an Owner-controlled, authenticated, and logged path; persistent always-on vendor connections shall not be provided.
13.4.6Audit 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.
14 Functional Safety Interface
NOTE 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. (14.1)
14.2The 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.
14.3The 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.
14.4Any 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.
14.5The integrator shall not modify safety logic solver configuration except under the project functional-safety management of change procedure, with the authorization recorded.
15 Testing
15.1 Factory Acceptance Test
NOTE 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. (15.1.1)
15.1.2The 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.
15.1.3Every 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.
○ 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
NOTE 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. (15.1.4)
15.2 Site Acceptance Test
15.2.1A 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.
15.2.2The 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.
15.3 Loop Checks and Point-to-Point Checkout
NOTE 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. (15.3.1)
15.3.2Each 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.
15.3.3Each 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.
15.3.5Each control valve and actuator shall be stroked and its travel verified against command in coordination with Control Valves And Actuators, and the fail-safe position shall be confirmed by removing the signal and the power. ☐ Per-loop checkout sheet (tag, signal injected, expected vs. actual, pass/fail, sign-off)
☐ Instrument calibration record (as-found / as-left vs. traceable reference)
☐ Valve/actuator stroke and travel record vs. command
☐ Fail-safe position verification (loss of signal and loss of power)
☐ Alarm and interlock verification per point
NOTE 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. (15.4.1)
15.4.2The 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.
15.4.3Control 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.
15.5 Endurance Test
NOTE 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. (15.5.1)
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
15.5.2The 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.
15.5.3Trend 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.
16 Startup and Commissioning
NOTE 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. (16.1)
16.2The 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.
16.3The 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.
16.4During 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.
NOTE 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. (16.5)
17 Training
17.1 Operator Training
17.1.1The 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.
17.1.2Operator training shall be conducted on the commissioned system or an equivalent simulation, hands-on, before the Owner assumes operation.
17.2 Maintenance Training
17.2.1The 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.
☐ 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
NOTE 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. (17.2.2)
18 Documentation and As-Builts
NOTE 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. (18.1)
18.2The 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.
18.3The 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.
18.4The 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.
19 Warranty
19.1 Warranty Terms
19.1.1The integrator shall warrant the integration, configuration, and programming against defects for a minimum of one year from substantial completion.
19.1.2During 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.
1 year from substantial completion (standard)
2 years from substantial completion
Extended term per Owner requirement
19.1.3The 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.
20 Spare Parts and Software
20.1 Software and Configuration
20.1.1The 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.
20.1.2The 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.
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. (20.1.3)
☐ Licensed development/configuration software for controllers and SCADA
☐ Source configuration for every controller program
☐ Source configuration for the SCADA/HMI application and graphics
☐ Documented backup/restore procedure and verified backup media
☐ License keys and registration transferred to Owner