1 Scope
NOTE This specification covers the supervisory control and data acquisition (SCADA) software and the operator human-machine interface (HMI) for industrial, process, and water and wastewater treatment facilities. (1.1)
NOTE Software and functions covered include the SCADA server application, the operator HMI client software, the process data historian, the alarm subsystem, trending and reporting, user access and security administration, time synchronization, and the communication drivers that poll the field controllers. (1.3)
NOTE The boundary of work under this standard is the SCADA software environment and the operator workstations; the controller hardware, the control network, the field instruments, and the final control elements are each covered by their own standards. (1.4)
1.5The SCADA platform shall present a consistent operator interface across all workstations and shall maintain a single authoritative real-time process database from which all clients are served.
1.7The Contractor shall coordinate the SCADA configuration with the controller programming, the network architecture, the instrument index and tag database, and the process control narrative so that every monitored and controlled point is consistently named and addressed across all layers.
1.8This standard applies to process SCADA and shall not be used to specify a commercial building automation head-end, which is governed by Building Automation System. 2 Referenced Standards
2.1Software, configuration, and acceptance testing shall comply with the latest adopted edition of each of the following 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-101.01 |
Human Machine Interfaces for Process Automation Systems |
| ANSI/ISA-18.2 |
Management of Alarm Systems for the Process Industries |
| IEC 62682 |
Management of Alarm Systems for the Process Industries (international counterpart to ISA-18.2) |
| ANSI/ISA-5.1 |
Instrumentation Symbols and Identification |
| ANSI/ISA-62443 / IEC 62443 (series) |
Security for Industrial Automation and Control Systems |
| IEC 62443-2-1 |
Security Program Requirements for IACS Asset Owners |
| IEC 62443-3-3 |
System Security Requirements and Security Levels |
| NIST SP 800-82 |
Guide to Operational Technology (OT) Security |
| ANSI/AWWA G430 |
Security Practices for Operation and Management (water/wastewater) |
| IEC 62541 |
OPC Unified Architecture (OPC UA) |
| IEEE 1815 |
Distributed Network Protocol (DNP3) |
| IEC 60870-5-104 |
Telecontrol Equipment and Systems — Network Access for IEC 60870-5-101 |
| IETF RFC 5905 |
Network Time Protocol Version 4 (NTPv4) |
| IEEE 1588 |
Precision Clock Synchronization Protocol (PTP) for Networked Measurement and Control Systems |
| ISA-TR99 / ISA-62443 technical reports |
Supporting technical reports for industrial cybersecurity |
| NFPA 70 |
National Electrical Code (NEC) — power to SCADA equipment |
3 Submittals
3.1 Action Submittals
3.1.1The Contractor shall submit the following for the Engineer's review and approval prior to configuration and procurement.
- SCADA system architecture drawing showing servers, workstations, historian, network connections to the control network, and the redundancy scheme, with each node identified by function and IP addressing scheme
- Software bill of materials listing the SCADA platform, HMI client, historian, reporting, and security/anti-malware software with version numbers, and the license model and license counts (tags, clients, concurrent users) for each
- HMI style guide and display hierarchy demonstrating compliance with ANSI/ISA-101.01, including the display level structure (overview, unit, detail, and diagnostic levels), the color palette, the grayscale background scheme, the symbol library, and the navigation model
- Alarm management documentation per ANSI/ISA-18.2, including the alarm philosophy document, the rationalized alarm list with priority assignments, alarm setpoints and deadbands, and the suppression/shelving rules
- Tag database (point list) cross-referenced to the instrument index and the controller I/O, showing tag name, description, engineering units, range, alarm limits, and the source controller and address for each point
- Historian configuration showing the points archived, the scan/store rates, the compression (deadband) settings, the retention period, and the storage sizing calculation
- Cybersecurity plan demonstrating compliance with the project's target Security Level per IEC 62443-3-3, including the user role matrix, password and account policy, patch management approach, backup approach, and the zone-and-conduit segmentation relative to Process Control Networks
- Time synchronization design identifying the time source (master clock or NTP/PTP server), the distribution method, and every node synchronized
- Reporting package description listing each standard and regulatory report, its data sources, and its generation schedule
- Factory acceptance test (FAT) and site acceptance test (SAT) procedures
- Software license agreements and any required maintenance/support agreement terms
☐ SCADA architecture drawing with redundancy scheme
☐ Software bill of materials and license model
☐ HMI style guide and display hierarchy (ISA-101.01)
☐ Alarm philosophy and rationalized alarm list (ISA-18.2)
☐ Tag database cross-referenced to instrument index
☐ Historian configuration and storage sizing
☐ Cybersecurity plan and user role matrix (IEC 62443)
☐ Time synchronization design
☐ Reporting package description
☐ FAT and SAT procedures
☐ Software license and support agreements
3.1.2Configuration and procurement shall not proceed until action submittals have been reviewed and returned.
3.2 Closeout Submittals
3.2.1At substantial completion, the Contractor shall provide the following before the SCADA system is accepted.
- Operation and maintenance manuals for the SCADA platform, HMI, historian, and all supporting software, organized with a table of contents
- As-built system architecture drawings reflecting the final node configuration, IP addressing, and network connections
- As-built tag database, HMI displays, alarm configuration, and historian configuration in both human-readable and native export formats
- Software license certificates and registration records transferred to the Owner
- Cybersecurity as-built documentation, including the final user role matrix, the account inventory, the applied hardening checklist, and the patch baseline
- Backup and restore procedure with a verified full system backup delivered on Owner-retained media
- FAT and SAT reports with all punch-list items closed
- Operator and administrator training records
- Source configuration and any custom code, scripts, or report templates, with sufficient documentation for the Owner to maintain them
☐ Operation and maintenance manuals
☐ As-built architecture drawings
☐ As-built tag database, displays, alarms, historian (native export)
☐ Software license certificates transferred to Owner
☐ Cybersecurity as-built and hardening records
☐ Verified full system backup on Owner media
☐ FAT and SAT reports with punch list closed
☐ Operator and administrator training records
☐ Source configuration, scripts, and report templates
4 Quality Assurance
4.1 System Integrator Qualifications
4.1.1The SCADA system shall be configured by a system integrator with a minimum of five years of continuous experience deploying the proposed SCADA platform on process or water/wastewater projects of comparable size and complexity.
4.1.2The integrator shall hold the proposed platform manufacturer's current certification or system-integrator partnership for the version being deployed.
4.1.3The integrator shall provide at least three references for comparable SCADA installations placed in service within the last five years.
NOTE A SCADA platform is only as reliable as its configuration; certified integrator experience on the specific platform is the principal defense against a system that functions in the factory but fails to fail over, lose alarms, or corrupt the historian in service. (4.1.4)
4.2.1The SCADA software shall be a commercially available, currently supported product, not a discontinued or end-of-life version.
4.2.2The proposed major version shall have been generally available for at least six months and shall not be a pre-release or beta build.
4.2.3The platform shall be supported by the manufacturer with security patches for the duration of the warranty period at minimum.
NOTE Deploying an unsupported or end-of-life SCADA version leaves the Owner unable to obtain security patches, which is a direct cybersecurity liability on a critical-infrastructure system. (4.2.4)
4.3.1The SCADA platform and its configuration shall conform to the target Security Level established for the project under IEC 62443-3-3.
SL 1 — protection against casual or coincidental violation
SL 2 — protection against intentional violation using simple means
SL 3 — protection against intentional violation using sophisticated means (typical for water/wastewater critical infrastructure)
SL 4 — protection against intentional violation using sophisticated means with extended resources
4.3.2The target Security Level shall be established by the Owner's risk assessment; SL 2 is typical for general industrial process SCADA and SL 3 is typical for critical water/wastewater infrastructure.
4.3.3Water and wastewater utility SCADA shall additionally support the Owner's security program under ANSI/AWWA G430 and shall follow the operational-technology guidance of NIST SP 800-82.
4.4 Pre-Configuration Coordination
4.4.1Before configuration begins, a coordination meeting shall be held with the integrator, the controls contractor, the network contractor, the commissioning agent, and the Owner's operations and IT/OT security representatives.
4.4.2The agenda shall include the tag naming convention, the alarm philosophy, the HMI style guide, the user role matrix, the network and addressing plan, the time-synchronization source, and the FAT/SAT schedule.
4.4.3The tag naming convention shall be agreed and frozen before configuration so that controller, SCADA, historian, and instrument-index names are identical across all layers.
5 Environmental and Service Conditions
5.1 Workstation and Server Environment
5.1.1SCADA servers and operator workstations shall be selected and rated for the conditions of the room in which they are installed.
Air-conditioned control room / server room (standard)
Industrial workstation — elevated temperature and dust (process area)
Sealed NEMA-rated enclosure HMI — outdoor or washdown area
5.1.2Servers and primary workstations shall be located in a clean, temperature- and humidity-controlled environment with conditioned, backed-up power.
5.1.3Operator workstations located on the plant floor, in pump stations, or in washdown areas shall use industrial-grade or sealed hardware rated for the ambient temperature, humidity, dust, and washdown exposure of the installed location.
NOTE Workstation hardware specified for an office environment fails prematurely in a process area; matching the hardware rating to the actual installed environment is required. (5.1.4)
5.2 Power and Ride-Through
5.2.1SCADA servers, historian, network equipment serving the SCADA, and the primary operator workstations shall be powered from an uninterruptible power supply (UPS).
5.2.2The UPS runtime shall support an orderly shutdown of the servers and historian, and shall be coordinated with the facility standby-power system.
NOTE A SCADA server that loses power without an orderly shutdown can corrupt the historian database and the real-time database; UPS-backed power with automatic graceful shutdown protects against this. (5.2.3)
6 System Architecture
6.1 Architecture Type
NOTE A standalone (single-node) architecture runs the SCADA server, HMI, and historian on one computer and is appropriate only for small, non-critical processes where loss of the SCADA does not stop the plant. (6.1.1)
NOTE A client/server architecture separates the SCADA server(s) and historian from multiple thin or full HMI clients, allowing many operator workstations to share one authoritative database and scaling to large plants; it is the standard for process and water/wastewater facilities. (6.1.2)
○ Standalone — single node (small, non-critical processes only)
○ Client/server — central server(s) with multiple HMI clients (standard for process/water)
○ Distributed client/server — multiple servers by area, federated for plant-wide view
6.1.4A loss of the SCADA layer shall not by itself stop the process, because real-time regulatory control and interlocks reside in the field controllers (Programmable Logic Controllers) and continue to run independently of the SCADA. 6.2 Server Redundancy
NOTE Server redundancy protects continuous monitoring and supervisory control against the failure of a single server. (6.2.1)
○ None — single server (small, non-critical processes only)
○ Hot-standby (active/standby) — synchronized standby with automatic failover (standard for critical process/water)
○ Redundant active/active — load-shared servers
6.2.2For critical process and water/wastewater facilities, the SCADA servers shall be configured as a redundant hot-standby (active/standby) pair.
6.2.3The standby server shall maintain a synchronized copy of the real-time database and shall assume control automatically on failure of the primary, with no operator intervention required.
6.2.4Client workstations shall automatically reconnect to the active server on failover without loss of the operator view.
6.2.5On restoration of a failed server, the historian and real-time database shall resynchronize automatically without manual data reconciliation.
NOTE A redundancy scheme that requires an operator to manually promote the standby, or that loses historical data during the failover, does not meet the intent; automatic, data-preserving failover is the requirement. (6.2.6)
6.3 Operator Workstations
☐ Primary control room workstation (full HMI client)
☐ Redundant control room workstation (independent client)
☐ Engineering/administration workstation (configuration access)
☐ Local plant-area HMI station (industrial hardware)
☐ Remote workstation — secure access over WAN/VPN
☐ Web/thin client — read-only or limited control
6.3.2At least two independent operator workstations shall be provided in the primary control area so that operation continues if one workstation fails.
6.3.3Each operator workstation shall be capable of full monitoring and, subject to the user's role, full supervisory control of the entire process.
6.4 Remote Operator Access
NOTE Remote operator access shall be provided only through the secured remote-access path coordinated with
Process Control Networks.
(6.4.1) None — no remote operator access
Read-only remote view (no control)
Full remote control via hardened VPN with multi-factor authentication
Remote access via dedicated secure gateway / jump host with MFA
6.4.2Where remote operator access is provided, it shall require multi-factor authentication and shall traverse a hardened gateway or jump host within the control-network security architecture.
6.4.3Remote access shall be logged and shall be subject to the same role-based permissions as local access.
NOTE Unsecured remote access to a process SCADA system is among the most exploited attack vectors on critical infrastructure; remote access shall never bypass the security architecture established in
Process Control Networks.
(6.4.4) 7 HMI Design and Graphics
7.1 HMI Design Standard
7.1.1The HMI shall be designed, implemented, and maintained in accordance with the high-performance HMI principles of ANSI/ISA-101.01 across the display lifecycle.
7.1.2The HMI design shall be governed by a documented HMI style guide that establishes the display hierarchy, color palette, symbol library, navigation, and presentation conventions, applied consistently to every display.
NOTE A high-performance HMI is designed to maximize operator situational awareness — the operator's ability to detect, understand, and respond to abnormal conditions — rather than to render a photorealistic picture of the plant. (7.1.3)
7.2 Display Hierarchy
7.2.1The HMI shall present a structured display hierarchy.
☐ Level 1 — plant/process overview (key performance indicators, area status)
☐ Level 2 — process unit / area control display
☐ Level 3 — equipment detail and faceplates
☐ Level 4 — diagnostic, configuration, and troubleshooting
7.2.2The display hierarchy shall allow an operator to move from a plant overview, to a process-area display, to equipment detail, with consistent navigation on every screen.
7.2.3The overview (Level 1) display shall present the key process indicators and the status of each area so that an operator can assess the whole plant at a glance.
7.3 Graphic Color Discipline
7.3.1Process graphics shall use a low-contrast, neutral grayscale background with process equipment and lines depicted in muted, consistent shades.
7.3.2Saturated and bright colors shall be reserved for abnormal conditions, active alarms, and operator-actionable states, and shall not be used for normal-state decoration.
7.3.3Color shall not be the sole means of conveying a state; each meaningful state shall also be distinguished by shape, text, or a symbol so the display remains usable for color-impaired operators.
NOTE Reserving color for abnormal conditions is the core of the high-performance approach: when 90% of the screen is neutral, an operator's eye is drawn immediately to the one element that has changed color, which measurably improves early detection of developing problems. (7.3.4)
NOTE A traditional high-color, photorealistic graphic hides developing abnormal conditions in a sea of always-on color and is not acceptable for new process HMIs. (7.3.5)
7.4 Analog Value Presentation
7.4.1Analog process values shall be presented with context — such as a trend sparkline, a moving analog indicator, or a range bar showing the normal operating range and alarm limits — and not as a bare number.
7.4.2Engineering units shall be displayed adjacent to every analog value.
NOTE A bare number gives an operator no indication of whether a value is trending toward an alarm; an indicator that shows the value relative to its normal range and limits conveys that trajectory at a glance. (7.4.3)
7.5 Symbol and Tag Conventions
7.5.1Process equipment symbols and instrument identification shall follow ANSI/ISA-5.1 conventions and shall be consistent across all displays.
7.5.2Every controllable device and monitored point shall carry its tag name consistent with the frozen tag database.
8 Alarm Management
8.1 Alarm Philosophy
8.1.1Alarm management shall conform to ANSI/ISA-18.2 (and its international counterpart IEC 62682) across the alarm lifecycle.
8.1.2An alarm philosophy document shall be established defining what constitutes an alarm, the priority scheme, the design of alarm presentation, and the performance metrics used to manage the alarm system.
NOTE An alarm shall be defined as an audible and/or visible indication of an abnormal condition that requires a timely operator response; status changes and information that require no response shall not be configured as alarms. (8.1.3)
8.1.4Every alarm shall be rationalized — justified, prioritized, and documented — before it is configured, and the rationalized alarm list shall be a submittal.
NOTE Unrationalized alarms cause alarm floods that overwhelm operators during the upsets when clear information matters most; rationalization is the discipline that prevents the flood, and high-performance graphics depend on it. (8.1.5)
8.2 Alarm Priority
8.2.1Each alarm shall be assigned a priority reflecting the severity of the consequence and the time available for the operator to respond.
○ Three priorities — High / Medium / Low (ISA-18.2 typical)
○ Four priorities — Urgent / High / Medium / Low
○ Priorities plus a separate Critical/Emergency level
8.2.2Alarm priority shall be conveyed by a consistent color and symbol coding used uniformly on every display and on the alarm summary.
8.2.3The distribution of alarms across priorities shall be managed so that the highest priority is reserved for the few alarms with the most severe and time-critical consequences.
8.3 Alarm Presentation and Handling
8.3.1The HMI shall provide an alarm summary that lists active alarms with their priority, time, tag, description, and acknowledgment state, and that allows sorting and filtering.
8.3.2The operator shall be able to acknowledge alarms, and acknowledgment shall be logged with the user identity and timestamp.
☐ Alarm summary with priority sort/filter
☐ Per-alarm acknowledge with operator audit log
☐ Alarm shelving (time-limited, with auto-reinstate and audit)
☐ Operator-settable alarm suppression by documented rule
☐ Alarm flood detection and indication
☐ State-based / mode-based alarm suppression
8.3.3Alarm shelving and suppression shall be available only as a controlled function with an audit trail and automatic reinstatement, per ANSI/ISA-18.2.
NOTE Uncontrolled, permanent disabling of an alarm removes a layer of protection without record; shelving with automatic reinstatement and an audit trail lets an operator quiet a known nuisance alarm temporarily without losing it permanently. (8.3.4)
8.4.1The system shall record alarm-system performance metrics — alarm rate per operator, standing (stale) alarms, and the most frequent (bad-actor) alarms — to support ongoing management per ANSI/ISA-18.2.
8.4.2A historian-based alarm and event log shall retain alarm occurrences, acknowledgments, and returns-to-normal for the retention period specified for the historian.
9 Data Historian and Trending
9.1 Historian
9.1.1The SCADA platform shall include a process data historian that records time-stamped process values, alarms, and events for long-term storage and retrieval.
9.1.2The historian shall be capable of backfilling from controller or local buffers after a communication or server interruption so that no recorded data is lost during the outage.
NOTE Loss of the SCADA link must not create a permanent gap in the historical record; backfill from controller buffers on restoration closes the gap that would otherwise compromise regulatory reporting. (9.1.3)
9.2 Historian Configuration
Periodic scan at fixed interval
Exception (deadband) — store on change beyond deadband (standard, reduces storage)
Periodic scan plus exception for critical points
1 year
3 years
5 years
7 years (regulatory reporting, common for water/wastewater)
10 years or per regulatory requirement
9.2.1The points to be historized, their scan and store rates, and the compression deadbands shall be defined in the historian configuration submittal.
9.2.2The historian retention period shall meet or exceed the longest applicable regulatory recordkeeping requirement for the facility.
NOTE Water and wastewater facilities have regulatory reporting obligations that depend on the historical record; the retention period shall be confirmed against the governing permit and regulatory requirements. (9.2.3)
9.3 Trending
9.3.1The HMI shall provide both real-time and historical trending of any historized point, with operator-selectable pens, time spans, and scaling.
9.3.2Operators shall be able to create ad-hoc trends and recall predefined trend groups.
10 Communications and Polling
10.1 Protocols
OPC UA (IEC 62541) — preferred open protocol
Modbus TCP/IP
EtherNet/IP
DNP3 (IEEE 1815) — common for distributed water/wastewater sites
IEC 60870-5-104 — telecontrol for distributed sites
Manufacturer-native driver (where open protocol unavailable)
10.1.2Where the field architecture is geographically distributed (remote pump stations, lift stations, well sites, tanks), a report-by-exception telemetry protocol such as DNP3 (IEEE 1815) shall be used to conserve communication bandwidth.
NOTE Open protocols shall be preferred over proprietary drivers so that the Owner is not locked to a single vendor for future expansion; this requirement is coordinated with
Process Control Networks.
(10.1.3) 10.2 Polling and Scan Rate
10.2.1Scan (poll) rates shall be configured so that the update rate of each point matches its process significance, and so that the aggregate communication load does not saturate the control network.
10.2.2Critical control and alarm points shall be scanned fast enough to support the operator's required response time; slow-moving or archival points may be scanned less frequently.
NOTE Polling every point at the fastest rate needlessly loads the network and the controllers; matching scan rate to process significance is the correct practice. (10.2.3)
10.3 Communication Failure Handling
10.3.1The SCADA shall detect and indicate loss of communication with any field controller and shall mark the affected points as stale or bad-quality rather than displaying the last value as if it were current.
10.3.2Communication-failure alarms shall be configured for each controller link.
NOTE Displaying a frozen last-known value as if it were live is a dangerous failure mode that has misled operators into wrong actions; explicit bad-quality indication is required. (10.3.3)
11 Security and User Access
11.1 Role-Based Access Control
11.1.1User access shall be controlled by role-based access control (RBAC) conforming to the access-control requirements of IEC 62443-3-3, granting each user only the privileges required for that user's function.
☐ View-only — monitor and trend, no control
☐ Operator — supervisory control within assigned area
☐ Senior operator / lead — control plus setpoint and alarm-limit changes
☐ Maintenance / technician — diagnostics and device service functions
☐ Engineer — configuration and display modification
☐ Administrator — user, security, and system administration
11.1.2A documented user role matrix mapping each role to its permitted functions shall be a submittal and shall be implemented exactly as approved.
11.1.3Privileges shall be assigned to roles, and users assigned to roles; privileges shall not be granted to individual user accounts outside the role structure.
NOTE Granting every user broad privileges so the system is convenient defeats the purpose of access control; least-privilege roles limit the damage a compromised or mistaken account can do. (11.1.4)
11.2 Authentication and Accounts
11.2.1Each user shall have a unique, individually attributable account; shared or generic operator logins shall not be used for actions that require attribution.
11.2.2Account and password policy — complexity, expiration, lockout, and inactivity timeout — shall conform to the target Security Level and the Owner's policy.
11.2.3Administrative and engineering access shall require stronger authentication than routine operator access where supported by the platform.
NOTE Shared logins make it impossible to attribute a control action or a security event to a person, which undermines both safety investigation and the audit trail; unique accounts are required. (11.2.4)
11.3 Audit Logging
11.3.1The system shall maintain a secure, tamper-evident audit log of operator control actions, setpoint and alarm-limit changes, logins and logouts, and security-relevant configuration changes, each with user identity and timestamp.
11.3.2The audit log shall be retained for the period required by the Owner's security program and applicable regulation.
11.4 Backup and Recovery
11.4.1A documented backup and recovery procedure shall be provided, and a verified full system backup shall be delivered to the Owner at closeout.
Scheduled automated backup to on-site secured storage
Scheduled automated backup to on-site and off-site/secured storage
Automated backup plus periodic full image to Owner-retained media
11.4.2The recovery procedure shall be tested during commissioning by restoring a backup to demonstrate that the system can be rebuilt from the backup alone.
NOTE A backup that has never been test-restored cannot be relied on; the demonstrated restore is the proof that the recovery procedure actually works. (11.4.3)
12 Time Synchronization
12.1 Time Source
12.1.1All SCADA servers, workstations, the historian, and the field controllers shall be synchronized to a single authoritative time source so that timestamps on data, alarms, and events are consistent across the system.
Network Time Protocol (NTP) server — millisecond accuracy (standard for SCADA)
GPS-disciplined master clock distributing NTP
Precision Time Protocol (IEEE 1588 PTP) — sub-microsecond, where required
12.1.2A single time source shall serve the entire system; servers and workstations shall not each keep independent time.
NOTE Without a common time source, alarm and event timestamps from different nodes disagree, making post-event sequence-of-events analysis impossible; one authoritative clock is required. (12.1.3)
12.1.4Where high-resolution sequence-of-events analysis is required, IEEE 1588 Precision Time Protocol (PTP) shall be used; otherwise NTP synchronization is sufficient for supervisory SCADA.
13 Software Licensing
13.1 License Model
13.1.1The software license model, and the licensed quantities of tags, clients, and concurrent users, shall be defined in the submittal and sized for the as-built system plus a documented spare capacity.
500100000
500100025005000100002500050000100000
Default: 5000 tags
10% spare tags above as-built
20% spare tags above as-built (recommended)
25% spare tags above as-built
Unlimited-tag license (where offered)
13.1.2The license shall be issued in the Owner's name and shall be transferable to the Owner at closeout.
NOTE A tag-limited license sized exactly to the as-built point count leaves no room for the small additions every plant makes; spare license capacity is far cheaper to buy initially than to add later. (13.1.3)
13.2 License Ownership
13.2.1All software licenses, activation keys, and registration records shall be transferred to and registered in the Owner's name at substantial completion.
13.2.2The Owner shall not be dependent on the integrator's accounts or credentials to operate, back up, or restore the licensed software.
14 Testing and Commissioning
14.1 Factory Acceptance Test
14.1.1A factory acceptance test (FAT) shall be performed on the assembled SCADA system, with the controllers (or controller emulation) connected, before shipment or deployment to the site.
☐ Display navigation and hierarchy verification
☐ Tag database point-to-point verification (sample or full)
☐ Alarm generation, priority, acknowledge, and shelving
☐ Server failover (force primary failure, confirm automatic failover)
☐ Historian record, backfill, and trend retrieval
☐ User role and permission enforcement
☐ Communication-failure / bad-quality indication
☐ Report generation
14.1.2The FAT shall demonstrate automatic server failover by forcing a failure of the primary server and confirming that the standby assumes control with no loss of operator view or historical data.
14.1.3The FAT shall verify alarm generation, priority, acknowledgment, and shelving against the rationalized alarm list, and shall verify enforcement of the user role matrix.
14.1.4The FAT shall be witnessed by the Engineer or the Owner's representative, and all deficiencies shall be corrected and retested before the system ships to the site.
14.2 Site Acceptance Test
14.2.1A site acceptance test (SAT) shall be performed after installation, with the actual field controllers and instruments connected, to verify end-to-end function.
14.2.2The SAT shall verify point-to-point correspondence from the field instrument or final element through the controller to the HMI display value and control action, coordinated with Control Systems Integration. 14.2.3The SAT shall verify time synchronization across all nodes, communication-failure handling on each controller link, and the backup-and-restore procedure.
NOTE Point-to-point verification from the field device to the screen is the only test that proves the tag database, the controller addressing, and the HMI all agree; a FAT alone cannot prove the field wiring and addressing are correct. (14.2.4)
14.3 Operator Training
14.3.1The integrator shall provide operator and administrator training on the as-built system before the Owner assumes operation.
☐ Operator training — monitoring, control, alarm handling, trending
☐ Administrator training — user/security administration, backup/restore
☐ Configuration training — display, tag, and alarm modification
☐ Recorded training sessions delivered to Owner
14.3.2Training shall be conducted on the as-built configuration, not on a generic platform demonstration, so that operators learn the actual displays and procedures they will use.
15 Warranty
15.1 Warranty Terms
1 year software support and updates (standard)
2 years software support and updates
3 years software support and updates
15.1.1The integrator shall warrant the SCADA configuration against defects for a minimum of one year from substantial completion.
15.1.2The software manufacturer shall provide security patches and updates for the warranty term, and the integrator shall apply approved patches under a coordinated change-management procedure.
NOTE Patches shall be tested before application to the production system, because an untested patch can break a working SCADA configuration as readily as it fixes a vulnerability. (15.1.3)
16 Spare Parts and Software
16.1.1The Contractor shall furnish the Owner with the installation media (or download entitlements), license keys, and a verified full system backup sufficient to rebuild the system without the integrator.
☐ Installation media or download entitlements for all software
☐ License keys and activation records in Owner's name
☐ Verified full system backup image on Owner-retained media
☐ Documented bare-metal recovery procedure
☐ Spare workstation hardware (one of each type)
16.1.2Where the Owner elects to stock spare workstation hardware, one spare of each workstation type shall be provided, pre-loaded or imaged so it can replace a failed unit quickly.
NOTE The recovery package shall be sufficient for the Owner, or a different integrator, to rebuild the system; the Owner shall not be dependent on a single integrator for disaster recovery. (16.1.3)