Process Control Networks
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 Process Control Networks.
---
title: Process Control Networks
category: Instrumentation & Controls / Control Panels & Networks
−toc_depth: 3
description: >
− When to use: The operational-technology (OT) communications network that connects controllers, remote and distributed I/O, field instruments, and the supervisory SCADA/HMI layer in industrial, process, and water/wastewater (WTP/WWTP) facilities. Covers the network reference architecture and zone segmentation built on the Purdue / ISA-95 model with a demilitarized zone (DMZ) separating the OT network from the enterprise IT network; industrial protocol selection (EtherNet/IP, PROFINET, and Modbus TCP on Ethernet; Modbus RTU and PROFIBUS on serial; OPC UA for cross-domain integration); transmission media selection (balanced twisted-pair copper versus optical fiber for distance, galvanic isolation, and noise immunity); managed industrial Ethernet switches and ring/redundancy protocols (RSTP, MRP, DLR, PRP/HSR); determinism and latency; network time synchronization (NTP and PTP); remote-site telemetry over licensed/unlicensed radio and cellular for geographically distributed water and wastewater systems; and the OT cybersecurity baseline per ISA/IEC 62443 (zones and conduits, device and switch hardening, patch management, account management, and monitoring). Applicable to new plant networks, full network replacements, and substantial OT network expansions.
+ When to use: The operational technology (OT) communications network that connects programmable controllers, remote and distributed I/O, networked field instruments, and the supervisory SCADA and HMI layer in industrial, process, and water and wastewater facilities. Covers the Purdue reference model and the boundary between the OT network and the enterprise network, security zones and conduits under ISA/IEC 62443, industrial Ethernet and serial protocol selection, transmission media by segment class, managed switches and conduit enforcement devices, redundant topologies and recovery time, traffic prioritization, time synchronization, wide-area telemetry to remote sites, the device hardening, account, patch, logging, and backup baseline, and the cable, functional, and security acceptance tests that put the network into service. Applies to new networks, full replacements, and substantial expansions of an existing OT network.
− Not intended for: Commercial building automation (BAS/DDC) HVAC control networks and their BACnet/Modbus field buses (see [[sync/building-automation-system]]); enterprise IT local area networks, office structured cabling, and data-center cabling; the controllers themselves (see [[sync/programmable-logic-controllers]]); the supervisory software and operator interface (see [[sync/scada-and-hmi-systems]]); the field instruments and final control elements connected to the network (see [[sync/process-instrumentation]], [[sync/flow-measurement]], [[sync/analytical-instrumentation]], [[sync/control-valves-and-actuators]]); the control panels and enclosures that house the network hardware (see [[sync/industrial-control-panels]]); programming, configuration, and overall system integration scope (see [[sync/control-systems-integration]]). Network cable materials and pathway methods are governed by [[sync/conductors-and-cables]] and [[sync/raceways-and-conduit]]; equipotential bonding and grounding of the network by [[sync/grounding-and-bonding]]; these are referenced here, not duplicated.
+ Not intended for: Commercial building automation networks and their BACnet and Modbus building field buses ([[sync/building-automation-system]]); enterprise local area networks, office structured cabling, and telecommunications rooms ([[sync/structured-cabling]], [[sync/telecommunications-rooms-and-pathways]]); the controllers on the network ([[sync/programmable-logic-controllers]]); the supervisory software and operator interface ([[sync/scada-and-hmi-systems]]); the field instruments and final control elements the network reaches ([[sync/process-instrumentation]], [[sync/flow-measurement]], [[sync/analytical-instrumentation]], [[sync/control-valves-and-actuators]]); the panels and enclosures that house network hardware ([[sync/industrial-control-panels]]); programming, configuration, and system integration ([[sync/control-systems-integration]]); cable construction and jacket ratings ([[sync/conductors-and-cables]]); raceway and pathway ([[sync/raceways-and-conduit]]); and the building grounding electrode system ([[sync/grounding-and-bonding]]).
---
# Scope {toc}
−## This specification covers the design, materials, configuration, segmentation, and cybersecurity hardening of the process control network (PCN) — the operational-technology communications network that interconnects programmable controllers, remote and distributed I/O, networked field instruments, and the supervisory SCADA/HMI layer in industrial, process, and water/wastewater facilities. {note}
+## This standard governs the active devices, media, segmentation, redundancy, time distribution, telemetry, and security hardening of the process control network: the operational technology communications network that carries data between controllers, remote I/O, networked field devices, and the supervisory layer. {note}
−## The network addressed in this standard is organized on the Purdue / ISA-95 reference model: Level 0 field devices and instruments, Level 1 controllers and I/O, Level 2 supervisory control and local HMI, and Level 3 site operations and the historian, with a demilitarized zone (DMZ) at Level 3.5 separating the OT network from the Level 4 enterprise/IT network. {note}
+## The scope begins at the network port of each controller, I/O adapter, networked instrument, server, and workstation, and ends at the enterprise-side interface of the boundary device that separates the OT network from the enterprise network; it includes every switch, router, firewall, gateway, media converter, radio, time server, and network cable between those points. {note}
−## The boundary of work under this standard is the OT network itself — the switches, routers, firewalls, media converters, gateways, wireless radios, time servers, network cabling between active devices, and the configuration, segmentation, and security hardening that bind them into zones and conduits. {note}
+## A process control network fails differently from an office network. A dropped office packet is retried and no one notices; a dropped control packet is a controller that has lost its I/O, a pump that has stopped, or an operator who cannot see the process. The provisions in this standard that look like excess caution beside enterprise practice exist because the consequence of a network fault here is physical. {note}
−## The controllers, the SCADA/HMI software, the field instruments, and the panels that the network connects are each governed by their own standard and are referenced here only at the network interface. {note}
+## The following are governed elsewhere and are outside this standard: {note}
−## Network architecture, zones, and conduits shall comply with the Purdue / ISA-95 reference model as defined in ANSI/ISA-95.00.01 (IEC 62264-1) and the segmentation guidance of NIST SP 800-82.
+- the controllers, I/O, and their application programs
+- the SCADA and HMI software, the historian, and operator workstations
+- the field instruments, analyzers, and final control elements connected to the network
+- the control panels, enclosures, and cabinets that house network hardware
+- integration, sequence programming, factory and site acceptance of the assembled control system
+- cable construction, jacket ratings, raceway, tray, and pathway
+- the building grounding electrode system and the telecommunications bonding backbone
+- enterprise local area networks, office cabling, and data-center cabling beyond the boundary device
−## OT cybersecurity provisions shall comply with the ISA/IEC 62443 series.
+## The location of every active network device shall be as indicated on [[drawing: the network architecture drawings]].
−## Industrial Ethernet protocols and cabling shall comply with the applicable parts of IEC 61158, IEC 61784, IEC 61918, and ANSI/TIA-1005.
+## Network architecture, zones, and conduits shall comply with the ISA/IEC 62443 series and the segmentation guidance of NIST SP 800-82.
−## Wiring methods, raceways, bonding, and grounding shall comply with NFPA 70 (National Electrical Code), including Article 725 for Class 2 and Class 3 circuits and Chapter 8 for communications circuits.
+## Wiring methods for network cabling shall comply with NFPA 70, including Article 725 for Class 2 and Class 3 circuits and Chapter 8 for communications circuits.
−## The Contractor shall coordinate the process control network with the controllers ([[sync/programmable-logic-controllers]]), the SCADA/HMI layer ([[sync/scada-and-hmi-systems]]), the field instruments, the control panels ([[sync/industrial-control-panels]]), the overall system integration ([[sync/control-systems-integration]]), and the network cabling, raceway, and grounding standards ([[sync/conductors-and-cables]], [[sync/raceways-and-conduit]], [[sync/grounding-and-bonding]]).
+## The Contractor shall coordinate the network with the controllers under [[sync/programmable-logic-controllers]], the supervisory layer under [[sync/scada-and-hmi-systems]], the panels under [[sync/industrial-control-panels]], and the integration and acceptance work under [[sync/control-systems-integration]].
−## Scope Boundaries {toc}
+## Network cable materials and pathways shall comply with [[sync/conductors-and-cables]] and [[sync/raceways-and-conduit]], and the bonding of network equipment and cable shields shall comply with [[sync/grounding-and-bonding]].
−### This standard governs the industrial OT network and is distinct from the commercial building automation network. {note}
−
−### Commercial building automation (BAS/DDC) networks for HVAC and ancillary building systems — including their BACnet and Modbus building field buses — are outside this scope and are governed by [[sync/building-automation-system]]. {note}
−
−### Enterprise IT networks, office and general-purpose structured cabling, and data-center cabling are outside this scope; the boundary between the OT network and the enterprise network is the DMZ defined in this standard. {note}
−
−### Sequences of operation and control logic are established on the contract documents and executed by the controllers ([[sync/programmable-logic-controllers]]); this standard governs the network that carries the data, not the logic that acts on it. {note}
−
# Referenced Standards {toc}
## Equipment, materials, configuration, and installation shall comply with the latest adopted edition of each of the following 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.
+## Where the contract documents, the Authority Having Jurisdiction, or two referenced standards impose conflicting requirements, the more stringent requirement shall govern unless the Engineer of Record directs otherwise in writing.
−## Standards Table {toc}
−
| Standard | Title |
|----------|-------|
−| ANSI/ISA-95.00.01 / IEC 62264-1 | Enterprise-Control System Integration (Purdue / ISA-95 reference model) |
−| ISA/IEC 62443-1-1 | Security for Industrial Automation and Control Systems — Terminology, Concepts, and Models (foundational requirements) |
−| ISA/IEC 62443-2-1 | Establishing an Industrial Automation and Control Systems Security Program |
−| ISA/IEC 62443-3-2 | Security Risk Assessment for System Design (zones and conduits) |
+| ANSI/ISA-95.00.01 | Enterprise-Control System Integration, Part 1: Models and Terminology |
+| ISA/IEC 62443-1-1 | Security for Industrial Automation and Control Systems: Terminology, Concepts, and Models |
+| ISA/IEC 62443-2-1 | Security Program Requirements for IACS Asset Owners |
+| ISA/IEC 62443-2-4 | Security Program Requirements for IACS Service Providers |
+| ISA/IEC 62443-3-2 | Security Risk Assessment for System Design |
| ISA/IEC 62443-3-3 | System Security Requirements and Security Levels |
| ISA/IEC 62443-4-2 | Technical Security Requirements for IACS Components |
−| NIST SP 800-82 | Guide to Operational Technology (OT) Security |
−| IEC 61158 | Industrial Communication Networks — Fieldbus Specifications |
−| IEC 61784-1 / 61784-2 | Industrial Communication Networks — Profiles (fieldbus and real-time Ethernet) |
−| IEC 61784-5 | Industrial Communication Networks — Installation Profiles |
−| IEC 61918 | Industrial Communication Networks — Installation of Communication Networks in Industrial Premises |
−| ISO/IEC 11801 / ISO/IEC 24702 | Generic Cabling for Customer Premises / Industrial Premises (MICE environmental classification) |
−| ANSI/TIA-568 | Telecommunications Cabling Standard (balanced twisted-pair and optical fiber components) |
+| NIST SP 800-82 | Guide to Operational Technology Security |
+| AWWA G430 | Security Practices for Operations and Management |
+| ANSI/ISA-71.04 | Environmental Conditions for Process Measurement and Control Systems: Airborne Contaminants |
+| IEC 61158 | Industrial Communication Networks: Fieldbus Specifications |
+| IEC 61784-1 and IEC 61784-2 | Industrial Communication Networks: Profiles |
+| IEC 61784-5 | Industrial Communication Networks: Installation Profiles |
+| IEC 61918 | Industrial Communication Networks: Installation of Communication Networks in Industrial Premises |
+| ISO/IEC 24702 | Information Technology: Generic Cabling for Industrial Premises |
+| ANSI/TIA-568 | Telecommunications Cabling Standard series |
| ANSI/TIA-1005 | Telecommunications Infrastructure Standard for Industrial Premises |
−| IEC 62541 | OPC Unified Architecture (OPC UA) |
−| IEC 62439-2 | Media Redundancy Protocol (MRP) |
−| IEC 62439-3 | Parallel Redundancy Protocol (PRP) and High-availability Seamless Redundancy (HSR) |
−| IEEE 802.1D / 802.1Q | Spanning Tree (RSTP) / Bridges and Bridged Networks (VLANs) |
−| IEEE 1588 | Precision Time Protocol (PTP) for Networked Measurement and Control Systems |
+| ANSI/TIA-607 | Generic Telecommunications Bonding and Grounding for Customer Premises |
+| IEEE 802.3 | Ethernet, including Power over Ethernet and single-pair Ethernet clauses |
+| IEEE 802.1Q | Bridges and Bridged Networks |
+| IEEE 802.1AB | Station and Media Access Control Connectivity Discovery |
| IEEE 802.1AS | Timing and Synchronization for Time-Sensitive Applications |
−| IETF RFC 5905 | Network Time Protocol Version 4 (NTPv4) |
−| IEEE 1815 | Distributed Network Protocol (DNP3) |
−| NFPA 70 | National Electrical Code (NEC) — Article 725 (Class 2/3) and Chapter 8 (communications) |
+| IEEE 1588 | Precision Clock Synchronization Protocol for Networked Measurement and Control Systems |
+| IEEE C37.238 | Precision Time Protocol Power Profile |
+| IETF RFC 5905 | Network Time Protocol Version 4 |
+| IEC 62439-2 | Media Redundancy Protocol |
+| IEC 62439-3 | Parallel Redundancy Protocol and High-Availability Seamless Redundancy |
+| IEC 62541 | OPC Unified Architecture |
+| Eclipse Sparkplug | Sparkplug Specification for MQTT Topic Namespace and Payload |
+| IEEE 1815 | Electric Power Systems Communications: Distributed Network Protocol (DNP3) |
+| IEC 60870-5-104 | Telecontrol Equipment and Systems: Network Access for IEC 60870-5-101 |
+| NFPA 70 | National Electrical Code |
+| 47 CFR Part 90 | Private Land Mobile Radio Services |
+| 47 CFR Part 15 | Radio Frequency Devices |
# Submittals {toc}
## Action Submittals {toc}
−### The Contractor shall submit the following for the Engineer's review and approval prior to procurement and installation.
+### The Contractor shall submit the following for review before active network devices are procured:
−- Network architecture drawing showing the Purdue / ISA-95 level assignment of every device, the zones and conduits, the DMZ, and the demarcation between the OT network and the enterprise network
−- Zone and conduit register identifying each zone, its assets, the conduits connecting it, and the target security level (SL-T) assigned per ISA/IEC 62443-3-2
−- IP addressing plan and VLAN schedule, including subnets per zone, management VLAN, and address assignment method (static for OT devices)
−- Product data for all active network devices — managed switches, routers, firewalls, media converters, protocol gateways, wireless radios, and time servers — including port count, media type, ring/redundancy protocol support, protocol support, environmental rating, power input, and ISA/IEC 62443-4-2 component certification where claimed
−- Protocol schedule listing each industrial protocol in use (EtherNet/IP, PROFINET, Modbus TCP, Modbus RTU, PROFIBUS, OPC UA, DNP3) and the devices and conduits on which each operates
−- Media selection schedule identifying copper versus fiber for each network segment with the basis (distance, galvanic isolation, noise immunity, or routing through high-voltage areas)
−- Redundancy scheme description identifying the ring or redundancy protocol (RSTP, MRP, DLR, PRP, or HSR), the recovery-time target, and the ring manager assignment
−- Time synchronization design identifying the grandmaster/reference clock, the protocol (NTP or PTP), the time source (GPS/GNSS or other), and the distribution path
−- Remote-site telemetry design for distributed water/wastewater sites, including the communications bearer (licensed radio, unlicensed radio, or cellular), the telemetry protocol (DNP3 typical), polling and report-by-exception strategy, and store-and-forward behavior on loss of communications
−- Cybersecurity hardening plan addressing device hardening, default-credential elimination, account management, port security, firewall/conduit rule set, patch management, backup, and logging/monitoring per ISA/IEC 62443 and NIST SP 800-82
−- Bill of materials and cable schedule, coordinated with [[sync/conductors-and-cables]] and [[sync/raceways-and-conduit]]
+- a network architecture drawing showing the Purdue level assignment of every device, the zones, the conduits, the boundary between the OT network and the enterprise network, and the services hosted in the demilitarized zone
+- a zone and conduit register listing each zone, the assets in it, the conduits that connect it, and the target security level assigned to each
+- an addressing plan and VLAN assignment listing the subnet and VLAN of every zone and the address of every device
+- product data for every active network device, giving port count and media, supported redundancy protocols, supported management protocols, operating temperature range, power input, environmental rating, and any ISA/IEC 62443-4-2 certification claimed
+- a protocol register listing every industrial protocol in use and the devices and conduits on which each operates
+- a media register identifying the media, category or grade, and length of each backbone and device-level segment
+- a redundancy design identifying the topology, the redundancy protocol, the ring manager assignment, and the recovery time to be demonstrated
+- a time synchronization design identifying the time reference, the distribution protocol on each segment, and the accuracy to be demonstrated
+- a telemetry design for each remote site, identifying the primary and backup bearer, the protocol, the polling strategy, and the behavior on loss of communications
+- a bill of materials and cable schedule coordinated with the cable and raceway standards
```datasheet
−label: Action Submittals Required
+label: Action Submittal Package
type: checkbox
options:
− - "Network architecture drawing (Purdue/ISA-95 levels, zones, conduits, DMZ)"
− - "Zone and conduit register with target security levels (62443-3-2)"
− - "IP addressing plan and VLAN schedule"
− - "Active network device product data (62443-4-2 certification where claimed)"
− - "Protocol schedule (EtherNet/IP, PROFINET, Modbus, OPC UA, DNP3)"
− - "Media selection schedule (copper vs. fiber with basis)"
− - "Redundancy scheme (RSTP/MRP/DLR/PRP/HSR) and recovery target"
− - "Time synchronization design (NTP/PTP, reference clock)"
− - "Remote-site telemetry design (radio/cellular, DNP3)"
− - "Cybersecurity hardening plan (62443 / SP 800-82)"
+ - "Network architecture drawing"
+ - "Zone and conduit register"
+ - "Addressing plan and VLAN assignment"
+ - "Active network device product data"
+ - "Protocol register"
+ - "Media register"
+ - "Redundancy design"
+ - "Time synchronization design"
+ - "Remote site telemetry design"
- "Bill of materials and cable schedule"
−default: "Network architecture drawing (Purdue/ISA-95 levels, zones, conduits, DMZ)"
+default:
+ - "Network architecture drawing"
+ - "Zone and conduit register"
+ - "Addressing plan and VLAN assignment"
+ - "Active network device product data"
+ - "Protocol register"
+ - "Media register"
+ - "Redundancy design"
+ - "Time synchronization design"
+ - "Bill of materials and cable schedule"
```
−### Fabrication, procurement, and installation shall not proceed until action submittals have been reviewed and returned.
+### Active network devices shall not be procured and network cabling shall not be installed until the corresponding action submittals have been reviewed and returned.
+## Informational Submittals {toc}
+
+### The Contractor shall submit the following qualifications, assessments, and plans with or before the action submittals:
+
+- the integrator's experience record and the certifications held by the personnel who will configure switches, boundary devices, radios, and time servers
+- the certification held by each person who will terminate and test optical fiber
+- the risk assessment performed under ISA/IEC 62443-3-2 from which the target security level of each zone was derived
+- the cybersecurity hardening plan, identifying the hardening measures, the account model, the conduit rule set, the patch qualification and application process, the logging design, and the backup procedure
+- the network test plan, identifying the cable test levels, the functional tests, the failover tests, the time synchronization verification, and the security acceptance method
+- the radio path study and the frequency license or license application for each radio telemetry link
+
+```datasheet
+label: Informational Submittal Package
+type: checkbox
+options:
+ - "Integrator experience record and personnel certifications"
+ - "Fiber termination and test certifications"
+ - "ISA/IEC 62443-3-2 risk assessment"
+ - "Cybersecurity hardening plan"
+ - "Network test plan"
+ - "Radio path study and frequency license"
+default:
+ - "Integrator experience record and personnel certifications"
+ - "Fiber termination and test certifications"
+ - "ISA/IEC 62443-3-2 risk assessment"
+ - "Cybersecurity hardening plan"
+ - "Network test plan"
+```
+
## Closeout Submittals {toc}
−### At substantial completion, the Contractor shall provide the following before the network is accepted.
+### The Contractor shall submit the following before the network is accepted:
−- As-built network architecture and topology drawings reflecting all field changes, including final port assignments and patch records
−- As-configured device configuration files (switch, router, firewall, radio, and gateway) exported and provided in both native and human-readable form
−- Final IP addressing and VLAN documentation as commissioned
−- Network commissioning and test records, including cable certification, redundancy failover tests, and time-synchronization verification
−- Cybersecurity hardening record documenting the as-built device hardening, account list, firewall/conduit rules, disabled services and ports, and firmware versions
−- Configuration backup media and the documented restore procedure for each device class
−- Operation and maintenance manuals for all active network devices
−- Warranty documentation
+- as-built network architecture and topology drawings recording every field change, the final port assignment of every device, and the patch record of every cross-connect
+- the as-configured configuration of every switch, router, firewall, gateway, radio, and time server, exported in the device's native format and in a human-readable form
+- the as-commissioned addressing plan and VLAN assignment
+- the cable test records for every copper and fiber link
+- the functional, failover, time synchronization, and telemetry test records
+- the security acceptance record, listing the as-built hardening measures, the accounts on every device, the conduit rule set, the disabled ports and services, and the firmware version of every device
+- the configuration backup media and the written restore procedure for each device class
+- operation and maintenance data for every active network device
+- warranty documentation for the devices and for the configuration work
+- a signed receipt from the Owner for the spare parts delivered
```datasheet
−label: Closeout Submittals Required
+label: Closeout Submittal Package
type: checkbox
options:
− - "As-built network architecture and topology drawings"
− - "As-configured device configuration files (native and readable)"
− - "Final IP addressing and VLAN documentation"
− - "Network commissioning and test records"
− - "Cybersecurity hardening record (accounts, rules, ports, firmware)"
+ - "As-built architecture and topology drawings"
+ - "As-configured device configurations"
+ - "As-commissioned addressing plan and VLAN assignment"
+ - "Cable test records"
+ - "Functional, failover, time, and telemetry test records"
+ - "Security acceptance record"
- "Configuration backup media and restore procedure"
− - "Operation and maintenance manuals"
+ - "Operation and maintenance data"
- "Warranty documentation"
−default: "As-built network architecture and topology drawings"
+ - "Spare parts receipt"
+default:
+ - "As-built architecture and topology drawings"
+ - "As-configured device configurations"
+ - "As-commissioned addressing plan and VLAN assignment"
+ - "Cable test records"
+ - "Functional, failover, time, and telemetry test records"
+ - "Security acceptance record"
+ - "Configuration backup media and restore procedure"
+ - "Operation and maintenance data"
+ - "Warranty documentation"
+ - "Spare parts receipt"
```
…2 unchanged lines
## Integrator Qualifications {toc}
−### The network integrator shall have a minimum of five years of continuous experience designing and commissioning industrial OT networks of the type and scale specified.
+### The network shall be designed, configured, and commissioned by an integrator that has delivered OT networks of comparable scale and architecture for not less than the period indicated in the datasheet.
−### Personnel configuring managed switches, routers, and firewalls shall hold current manufacturer certification on the products supplied, and personnel performing fiber-optic termination and testing shall hold a recognized fiber-optic installer certification.
+```datasheet
+label: Minimum Integrator Experience with OT Networks
+type: range
+unit: years
+options:
+ min: 0
+ max: 15
+ setpoints: [0, 2, 3, 5, 10, 15]
+default: 5
+```
−### For water and wastewater projects, the integrator shall demonstrate prior experience with distributed telemetry and DNP3, which differ materially from a single-site plant network.
+### The personnel who configure switches, boundary devices, radios, and time servers shall hold the credentials indicated in the datasheet.
+```datasheet
+label: Network Configuration Personnel Credentials
+type: checkbox
+options:
+ - "Manufacturer certification on the switch and firewall products furnished"
+ - "Vendor-neutral industrial network certification"
+ - "ISA/IEC 62443 cybersecurity certificate"
+ - "Radio manufacturer certification for the telemetry products furnished"
+default:
+ - "Manufacturer certification on the switch and firewall products furnished"
+```
+
+### Every individual who terminates or tests optical fiber shall hold a recognized fiber installer certification current at the time of the work.
+
+### The integrator's conformance to the service provider requirements of ISA/IEC 62443-2-4 shall be as indicated in the datasheet.
+
+```datasheet
+label: Integrator Security Program Conformance
+type: radio
+options:
+ - "Not required"
+ - "Self-declared conformance to ISA/IEC 62443-2-4"
+ - "Third-party certification to ISA/IEC 62443-2-4"
+```
+
+### Where the network includes remote sites served by telemetry, the integrator shall demonstrate prior delivery of a wide-area telemetry system using the bearer and protocol selected for this project.
+
## Component Security Certification {toc}
+### The active network devices that are required to hold ISA/IEC 62443-4-2 component certification shall be as indicated in the datasheet.
+
```datasheet
−label: Network Device Security Certification (ISA/IEC 62443-4-2)
+label: Network Device Security Certification Scope
type: radio
options:
− - "Required — switches, routers, and firewalls certified to ISA/IEC 62443-4-2"
− - "Required for security-zone boundary devices (firewalls/routers) only"
− - "Not required — hardening per project plan in lieu of certification"
−default: "Required for security-zone boundary devices (firewalls/routers) only"
+ - "Not required"
+ - "Required for zone boundary devices"
+ - "Required for all active network devices"
```
−### Network infrastructure devices should be certified to ISA/IEC 62443-4-2 for the component type (network device or host device) at the target security level assigned to their zone.
+### Where certification is required, each device within the selected scope shall be certified to ISA/IEC 62443-4-2 for its component type at a capability security level not lower than the target security level of the zone it serves.
−### Devices forming a zone or conduit boundary (firewalls and security routers) shall provide the technical security capabilities required by ISA/IEC 62443-3-3 for the target security level of the conduit.
+### Every active network device, whether certified or not, shall be hardened in accordance with the OT Cybersecurity Baseline section of this standard before it is placed in service.
−### 62443-4-2 certification provides independent evidence that a device has the native security capabilities — authentication, access control, integrity protection, and audit — needed to reach a target security level without relying solely on compensating controls. {note}
+### Component certification is independent evidence that a device carries the native capabilities the security level calls for, so that the level is reached through the device itself rather than through compensating controls placed around it; an uncertified device reaches the same level only where the hardening plan demonstrates each required capability another way. {note}
−## Factory Acceptance Test {toc}
+## Staged Factory Acceptance Test {toc}
−### Where the network and its active devices are pre-configured and staged off site, a factory acceptance test (FAT) shall verify device configuration, addressing, VLAN segmentation, redundancy failover, and the firewall/conduit rule set before shipment to site.
+### Whether the active network devices are configured and tested as a staged system before shipment shall be as indicated in the datasheet.
−### The FAT shall be witnessed by the Engineer or the Owner's representative, or recorded and submitted where remote witnessing is accepted.
+```datasheet
+label: Staged Network Factory Acceptance Test
+type: radio
+options:
+ - "Required"
+ - "Not required"
+```
+### Where a staged test is required, it shall verify device addressing, VLAN membership, the conduit rule set, redundancy failover, and time distribution on the assembled devices before they leave the staging location.
+
+### The manner in which the staged test is witnessed shall be as indicated in the datasheet.
+
+```datasheet
+label: Staged Test Witnessing
+type: radio
+options:
+ - "Witnessed in person by the Engineer of Record or the Owner"
+ - "Witnessed remotely"
+ - "Recorded and submitted without witnessing"
+```
+
## Pre-Installation Conference {toc}
−### A pre-installation conference shall be held before network installation begins, attended by the controls integrator, the electrical contractor, the SCADA/HMI integrator, the Owner's OT and IT representatives, and the commissioning agent.
+### A pre-installation conference shall be held before network installation begins, attended by the network integrator, the electrical contractor, the SCADA integrator, the Owner's operations and information technology representatives, and the commissioning agent.
−### The agenda shall include the OT/IT demarcation and DMZ ownership, IP addressing authority, the cybersecurity hardening plan, cable pathway coordination, grounding and bonding, and the commissioning and security-acceptance schedule.
+### The conference shall settle in writing the ownership of the demilitarized zone, the authority over the conduit rule set, the authority over address assignment, and the schedule of the commissioning and security acceptance.
−### The boundary between OT and IT responsibility is the most common source of project conflict; the DMZ owner, the firewall rule authority, and the addressing authority shall be agreed in writing at this conference. {note}
+### The seam between the OT organization and the enterprise organization is where the most project disputes originate, because each assumes the other owns the boundary; naming the owner of the DMZ and the rule set before anything is installed removes that assumption. {note}
# Environmental and Service Conditions {toc}
−## Installation Environment {toc}
+## Installation Environment Classification {toc}
−### Industrial OT network hardware is exposed to temperature extremes, vibration, dust, moisture, and electrical noise that exceed the office environment for which commercial IT switches are designed. {note}
+### The environment a network device or cable occupies is described by the MICE classification of ISO/IEC 24702 and ANSI/TIA-1005, which grades mechanical, ingress, climatic, and electromagnetic severity separately so that the hardware is matched to each. {note}
−### The MICE classification of ISO/IEC 11801 and ISO/IEC 24702 (Mechanical, Ingress, Climatic, Electromagnetic) describes the installation environment and is the basis for selecting hardware and cabling rated for it. {note}
+### Devices and cabling shall be rated for the environmental classification of the location in which they are installed.
−### Active network devices installed outside a conditioned control room shall be industrially hardened, with a wide operating-temperature range, fanless convection cooling, DIN-rail mounting, and redundant DC power input.
+### A network device installed in a classified hazardous location shall be listed for the area classification indicated on [[drawing: the hazardous area classification drawings]].
−### Devices installed in wet wells, lift stations, outdoor cabinets, or washdown areas shall be rated for the ingress and climatic class of the location, and connectors in those locations shall be sealed (e.g., M12 industrial connectors) rather than standard RJ45.
+## Temperature Rating of Devices Outside Conditioned Spaces {toc}
+### The minimum operating temperature rating of active network devices installed outside conditioned spaces shall be as indicated in the datasheet.
+
```datasheet
−label: Network Environment Classification (MICE)
−type: select
+label: Minimum Operating Temperature Rating Outside Conditioned Spaces
+type: range
+unit: "°C"
+derived: "[[parameter: site-ambient-temperature-minimum]] less the margin the enclosure heating provision does not cover"
options:
− - "M1 I1 C1 E1 — office/control-room environment (managed IT-grade hardware acceptable)"
− - "M2 I2 C2 E2 — general industrial / plant floor (industrially rated hardware)"
− - "M3 I3 C3 E3 — harsh / heavy industrial, wet wells, outdoor (hardened hardware, sealed connectors)"
−default: "M2 I2 C2 E2 — general industrial / plant floor (industrially rated hardware)"
+ min: -40
+ max: 0
+ setpoints: [-40, -30, -25, -20, -10, 0]
+default: derived
```
−### Specifying office-grade switches for plant-floor or outdoor service is a frequent and costly error; commercial switches with fans and a narrow temperature range fail early in industrial heat, dust, and vibration. {note}
+### The maximum operating temperature rating of active network devices installed outside conditioned spaces shall be as indicated in the datasheet.
−## Temperature and Power {toc}
+```datasheet
+label: Maximum Operating Temperature Rating Outside Conditioned Spaces
+type: range
+unit: "°C"
+derived: "[[parameter: site-ambient-temperature-maximum]] plus the temperature rise inside the enclosure in which the device is mounted, including solar gain on an outdoor enclosure"
+options:
+ min: 40
+ max: 85
+ setpoints: [40, 45, 50, 55, 60, 70, 75, 85]
+default: derived
+```
+### The air inside a sealed enclosure in direct sun runs well above the ambient outside it, and the air around a switch mounted above a power supply runs above the enclosure average, so the rating is set from the temperature at the device and not from the weather station. {note}
+
+### A device installed inside a conditioned control room or server room is rated for the room and carries no requirement under this article. {note}
+
+## Corrosive and Wet Locations {toc}
+
+### The protection of network device electronics against corrosive atmospheres shall be as indicated in the datasheet.
+
```datasheet
−label: Network Device Operating Temperature Rating
+label: Corrosive Atmosphere Protection for Network Device Electronics
type: select
−unit: "°C"
options:
− - "0 to +45 (control-room / conditioned space)"
− - "-10 to +60 (general industrial)"
− - "-40 to +75 (extended industrial / outdoor / unconditioned)"
−default: "-40 to +75 (extended industrial / outdoor / unconditioned)"
+ - "None"
+ - "Conformal-coated electronics rated to ANSI/ISA-71.04 severity level G2"
+ - "Conformal-coated electronics rated to ANSI/ISA-71.04 severity level G3"
+ - "Conformal-coated electronics rated to ANSI/ISA-71.04 severity level GX"
```
+### Hydrogen sulfide in a wastewater headworks or a lift station attacks the copper and silver on a circuit board at concentrations too low to smell, and the failure it causes is an intermittent contact that no diagnostic reports; conformal coating is the difference between a switch that lasts its rated life in that air and one that does not. {note}
+
+### The connector type for network devices in wet and washdown locations shall be as indicated in the datasheet.
+
```datasheet
−label: Network Device Power Input
+label: Network Connector Type in Wet and Washdown Locations
+type: radio
+options:
+ - "Sealed M12 connectors at the device"
+ - "RJ45 connectors within a sealed enclosure"
+```
+
+## Device Power {toc}
+
+### The power source for active network devices shall be as indicated in the datasheet.
+
+```datasheet
+label: Network Device Power Source
+type: radio
+options:
+ - "DC control power"
+ - "AC branch circuit"
+default: "DC control power"
+```
+
+### Where DC control power is selected, the DC supply voltage shall be as indicated in the datasheet.
+
+```datasheet
+label: DC Supply Voltage for Network Devices
+type: range
+unit: VDC
+options:
+ min: 12
+ max: 48
+ setpoints: [12, 24, 48]
+default: 24
+```
+
+### Where an AC branch circuit is selected, the AC supply voltage shall be as indicated in the datasheet.
+
+```datasheet
+label: AC Supply Voltage for Network Devices
+type: range
+unit: VAC
+options:
+ min: 120
+ max: 240
+ setpoints: [120, 208, 230, 240]
+```
+
+### Whether active network devices are furnished with redundant power inputs shall be as indicated in the datasheet.
+
+```datasheet
+label: Redundant Power Input on Network Devices
+type: radio
+options:
+ - "Required"
+ - "Not required"
+```
+
+### Where redundant power inputs are required, each input shall be fed from a separate power supply.
+
+### The Power over Ethernet class delivered from switches to powered field devices shall be as indicated in the datasheet.
+
+```datasheet
+label: Power over Ethernet Delivered to Field Devices
type: select
options:
− - "24 VDC — single input"
− - "24 VDC — dual redundant inputs"
− - "48 VDC"
− - "120/240 VAC"
− - "Power over Ethernet (PoE/PoE+) for field devices"
−default: "24 VDC — dual redundant inputs"
+ - "Not provided"
+ - "IEEE 802.3af Type 1"
+ - "IEEE 802.3at Type 2"
+ - "IEEE 802.3bt Type 3"
+ - "IEEE 802.3bt Type 4"
```
−### Active network devices should be powered from the same regulated, backed-up DC control power as the controllers they serve, so that a power disturbance does not drop the network while the controllers remain energized.
+### Active network devices shall be powered from the backed-up control power source that serves the controllers they connect, in accordance with [[sync/uninterruptible-power-supply-systems]] where a UPS serves that source.
−### Devices supporting redundant power input shall have both inputs connected to independent supplies where available.
+### A network that drops while the controllers ride through a power disturbance leaves every controller running blind and every operator screen frozen, which is the outcome a backed-up controller supply was bought to prevent. {note}
−# Network Architecture and Reference Model {toc}
+# Network Architecture {toc}
−## Purdue / ISA-95 Reference Model {toc}
+## Reference Model and Level Assignment {toc}
−### The network shall be structured on the Purdue / ISA-95 reference model, with each device assigned to a level: Level 0 (field instruments and final elements), Level 1 (controllers and I/O), Level 2 (supervisory control and local HMI), Level 3 (site operations, historian, engineering workstations), and Level 4 (enterprise/IT, outside this scope).
+### The network shall be organized on the Purdue reference model as described in ANSI/ISA-95.00.01, with every device assigned to a level: Level 0 for field instruments and final elements, Level 1 for controllers and I/O, Level 2 for supervisory control and local operator interface, Level 3 for site operations, the historian, and engineering workstations, and Level 4 for the enterprise.
−### The level assignment of every device shall be shown on the network architecture drawing.
+### The level of every device shall be shown on the network architecture drawing.
−### The Purdue model is the organizing principle for OT network segmentation: traffic flows and trust decrease moving up the levels, and the controls between levels are where security is enforced. {note}
+### Trust decreases and consequence increases moving down the levels, so the model places every control on the path between levels and gives the network a place to enforce it; a device that has no assigned level has no assigned trust and is the device an attacker looks for. {note}
−## OT/IT Demilitarized Zone {toc}
+## OT and Enterprise Boundary {toc}
−### A demilitarized zone (DMZ) shall be provided at Level 3.5 between the OT network (Levels 0 through 3) and the enterprise/IT network (Level 4).
+### The enforcement architecture at the boundary between the OT network and the enterprise network shall be as indicated in the datasheet.
```datasheet
−label: OT/Enterprise Boundary Architecture
+label: OT and Enterprise Boundary Enforcement
type: select
options:
− - "Firewalled DMZ with broker server (historian/reporting replica in DMZ)"
− - "Firewalled DMZ with data diode (one-way OT-to-enterprise only)"
− - "Dual-firewall DMZ (separate OT-side and IT-side firewalls)"
− - "Air-gapped — no enterprise connection"
−default: "Firewalled DMZ with broker server (historian/reporting replica in DMZ)"
+ - "Single firewall with a DMZ interface"
+ - "Two firewalls in series with the DMZ between them"
+ - "Two firewalls in series from different manufacturers"
+ - "Unidirectional gateway"
+ - "No connection to the enterprise network"
```
−### No direct communication path shall exist between the OT network and the enterprise network; all cross-domain data exchange shall traverse the DMZ.
+### The services hosted in the demilitarized zone shall be as indicated in the datasheet.
−### Data shared with the enterprise (historian replication, reporting, remote read-only views) shall be brokered by a server or data diode located in the DMZ, so that no enterprise host initiates a connection directly into the control network.
+```datasheet
+label: Services Hosted in the DMZ
+type: checkbox
+options:
+ - "Historian replica serving enterprise clients"
+ - "Remote access jump host"
+ - "Patch and antivirus update relay"
+ - "File transfer relay"
+ - "Time relay"
+ - "Domain services replica"
+ - "None"
+```
−### The DMZ is the single most important architectural control for protecting the control network; a flat network with the OT and enterprise systems on the same broadcast domain has no defensible boundary and is the condition that lets IT-side malware reach controllers. {note}
+### No connection shall be initiated from an enterprise host directly to a device on the OT network, and every exchange between the two shall terminate on a service in the DMZ.
+### Where a unidirectional gateway is selected, data shall flow only from the OT network toward the enterprise, and no return path shall exist through the gateway.
+
+### Where two firewalls in series are selected, the OT-side firewall shall be administered from the OT network and the enterprise-side firewall from the enterprise network, so that no single administrative credential opens both.
+
+### A brokered DMZ lets enterprise users read plant data from a replica without ever reaching the network the replica came from, and the replica is the only host both sides talk to; a unidirectional gateway removes even that host from the attack surface at the cost of any capability that needs a reply, which rules out remote support and patch delivery through it. {note}
+
+### Where the boundary provides no connection to the enterprise network, the DMZ services field records the services that are not provided, and the remote access, patch relay, and time relay provisions of this standard that depend on the boundary do not apply. {note}
+
## Zones and Conduits {toc}
−### The network shall be partitioned into security zones and conduits in accordance with ISA/IEC 62443-3-2.
+### The network shall be partitioned into security zones and conduits in accordance with ISA/IEC 62443-3-2, with each zone grouping assets that share security requirements and each conduit carrying the controlled traffic between two zones.
−### Each zone shall group assets that share common security requirements, and each conduit shall be the controlled communications path between zones.
+### The target security level of the control zones shall be as indicated in the datasheet.
−### A target security level (SL-T) shall be assigned to each zone and conduit based on a documented risk assessment, and the network controls shall be selected to meet that level.
+```datasheet
+label: Target Security Level for Control Zones
+type: range
+derived: "the documented risk assessment performed for each zone under ISA/IEC 62443-3-2"
+options:
+ min: 1
+ max: 4
+ setpoints: [1, 2, 3, 4]
+default: derived
+```
−### Inter-zone traffic shall pass only through a conduit with an enforcing device (firewall or security router); intra-zone traffic shall not be required to traverse the boundary.
+### The network controls on each zone and conduit shall satisfy the system requirements of ISA/IEC 62443-3-3 for the target security level assigned to it.
−### Zones and conduits convert an abstract risk assessment into concrete firewall rules and VLAN boundaries; without them, every device implicitly trusts every other device on the network. {note}
+### Traffic between zones shall pass only through a conduit whose enforcement device permits it, and traffic within a zone shall not be required to leave the zone.
−## Network Segmentation {toc}
+### The target level is an output of the risk assessment rather than an input to it: the assessment weighs the consequence of a compromise in each zone against the capability of the threat the Owner chooses to defend against, and the level follows from that comparison, so two assessors given the same consequences and the same threat arrive at the same number. {note}
+### Where the facility is a public water or wastewater system, the Owner's security practices under AWWA G430 and any applicable regulatory guidance form part of the inputs to the risk assessment. {note}
+
+## Segmentation Within the OT Network {toc}
+
+### The method by which zones are separated within the OT network shall be as indicated in the datasheet.
+
```datasheet
−label: Segmentation Method
+label: Zone Segmentation Method
type: select
options:
− - "VLANs on managed switches with inter-VLAN firewall/routing"
− - "Physically separate switches per zone"
− - "VLANs plus physically separate switches at zone boundaries"
−default: "VLANs on managed switches with inter-VLAN firewall/routing"
+ - "VLANs on shared managed switches"
+ - "Physically separate switches for each zone"
+ - "Physically separate switches at zone boundaries with VLANs within each"
+default: "VLANs on shared managed switches"
```
−### The control network shall be segmented from the plant business systems and from other zones using VLANs (IEEE 802.1Q) on managed switches, physically separate switches, or a combination, as required to enforce the zone model.
+### The device that enforces the conduit rules between zones inside the OT network shall be as indicated in the datasheet.
−### Broadcast and multicast traffic, which several industrial protocols rely on, shall be contained within the appropriate zone so that a multicast storm in one zone does not degrade another.
+```datasheet
+label: Conduit Enforcement Device Between OT Zones
+type: select
+options:
+ - "Stateful industrial firewall"
+ - "Stateful industrial firewall with industrial protocol inspection"
+ - "Layer 3 switch with access control lists"
+ - "Router with access control lists"
+```
−### Inter-VLAN traffic shall be routed and filtered by a Layer 3 device or firewall, not bridged.
+### The conduit rule set shall deny by default and shall permit only the protocols, source and destination pairs, and ports listed for that conduit in the zone and conduit register.
−# Industrial Protocols {toc}
+### Traffic between VLANs shall be routed and filtered by the conduit enforcement device and shall not be bridged.
−## Ethernet-Based Control Protocols {toc}
+### Broadcast and multicast traffic shall be confined to the zone that originates it, and multicast groups used by the control protocol shall be pruned by IGMP snooping so that a producer's traffic reaches only its consumers.
−### The primary control protocol on the Ethernet network shall be selected to match the controller platform and the installed base, and shall be one of the open industrial Ethernet protocols. {note}
+### A VLAN separates zones on a shared switch fabric and costs one switch per location; physically separate switches remove the fabric itself from the boundary, so a misconfigured trunk cannot join two zones, at the cost of a switch per zone per location. Protocol inspection in the enforcement device examines the industrial protocol inside the packet and can reject a write to a controller on a conduit that permits reads, which an address and port rule cannot distinguish. {note}
−### EtherNet/IP (managed by ODVA, built on the Common Industrial Protocol) is common with one major controller family and uses standard Ethernet with CIP at the application layer. {note}
+### The address assignment method for OT devices shall be as indicated in the datasheet.
−### PROFINET (IEC 61158 / IEC 61784, managed by PI) is common with another major controller family and provides real-time and isochronous classes. {note}
+```datasheet
+label: Address Assignment for OT Devices
+type: radio
+options:
+ - "Static addressing"
+ - "DHCP with reserved leases from a server within the OT network"
+default: "Static addressing"
+```
−### Modbus TCP is a simple, widely supported register-based protocol used for device integration and for equipment that lacks a native EtherNet/IP or PROFINET interface. {note}
+### Every OT device shall hold the address assigned to it in the addressing plan, and no OT device shall obtain an address from a server outside the OT network.
−### The primary control protocol shall be applied consistently within a zone; mixing real-time control protocols within a single zone without a documented reason complicates redundancy, time sync, and troubleshooting.
+## Remote Access {toc}
+### The provision for interactive remote access into the OT network shall be as indicated in the datasheet.
+
```datasheet
+label: Remote Access into the OT Network
+type: select
+options:
+ - "Not provided"
+ - "Jump host in the DMZ reached through the enterprise network"
+ - "Dedicated remote access appliance in the DMZ"
+ - "Out-of-band cellular gateway to a jump host"
+```
+
+### Where remote access is provided, every session shall terminate on the DMZ host, shall require multi-factor authentication, and shall reach a control device only through a second, separately authenticated hop from that host.
+
+### Where remote access is provided, an operator on site shall be able to disable it, and the state of the remote access path shall be annunciated to the supervisory system.
+
+# Industrial Protocols {toc}
+
+## Ethernet Control Protocol {toc}
+
+### The primary control protocol on the Ethernet network shall be as indicated in the datasheet.
+
+```datasheet
label: Primary Ethernet Control Protocol
−type: radio
+type: select
+derived: "the native network protocol of the controller platform furnished under the programmable logic controllers standard"
options:
− - "EtherNet/IP (ODVA / CIP)"
− - "PROFINET (IEC 61158/61784)"
+ - "EtherNet/IP"
+ - "PROFINET"
- "Modbus TCP"
− - "Mixed — multiple protocols gatewayed to a common layer"
−default: "EtherNet/IP (ODVA / CIP)"
+ - "EtherCAT"
+ - "CC-Link IE"
+default: derived
```
−### Where multiple protocols are unavoidable, they shall be bridged at a defined gateway, not by allowing unrelated protocols to share a control VLAN.
+### The secondary Ethernet protocols permitted within control zones for the integration of devices that do not speak the primary protocol shall be as indicated in the datasheet.
−## Serial and Legacy Protocols {toc}
+```datasheet
+label: Secondary Ethernet Protocols Permitted in Control Zones
+type: checkbox
+options:
+ - "Modbus TCP"
+ - "EtherNet/IP"
+ - "PROFINET"
+ - "OPC UA"
+ - "None"
+```
−### Modbus RTU and PROFIBUS DP serve serial-connected and legacy field devices and shall be brought onto the Ethernet network through a gateway at a defined point rather than extended as long serial trunks.
+### The primary control protocol follows from the controller rather than from a network preference: each controller family carries one protocol natively, and choosing a different one on the network means a gateway in every I/O path. {note}
+### EtherNet/IP carries the Common Industrial Protocol over standard Ethernet and multicasts its cyclic I/O; PROFINET provides a real-time class that bypasses the IP stack and an isochronous class for motion; Modbus TCP is a register-read protocol with no cyclic producer model, which is what makes it simple to implement and unsuitable as the sole transport for time-critical I/O. {note}
+
+### A protocol not selected as primary or permitted as secondary shall not be placed on a control zone, and a device that speaks only such a protocol shall be connected through a gateway at a defined point shown on the architecture drawing.
+
+## Serial Field Protocols {toc}
+
+### The serial field protocols present on the project shall be as indicated in the datasheet.
+
```datasheet
label: Serial Field Protocols Present
type: checkbox
options:
− - "Modbus RTU (RS-485)"
− - "PROFIBUS DP (RS-485)"
− - "PROFIBUS PA (IEC 61158-2, process automation)"
− - "Proprietary serial (vendor-specific, behind a gateway)"
− - "None — all devices natively Ethernet"
−default: "Modbus RTU (RS-485)"
+ - "Modbus RTU over RS-485"
+ - "PROFIBUS DP"
+ - "PROFIBUS PA"
+ - "FOUNDATION Fieldbus H1"
+ - "DeviceNet"
+ - "None"
```
−### Serial multidrop segments (RS-485) shall be wired in a daisy-chain (not star) topology, terminated at both ends with the characteristic impedance, and biased per the device requirements.
+### Each serial segment shall be brought onto the Ethernet network through a gateway at a defined point, and a serial trunk shall not be extended between buildings or between panels in different zones.
−### Each serial segment shall be isolated and surge-protected where it leaves a panel, coordinated with [[sync/grounding-and-bonding]].
+### An RS-485 multidrop segment shall be wired as a single daisy chain with no stubs or star branches, terminated at both physical ends with the characteristic impedance of the cable, and biased at one point in accordance with the device requirements.
−### A serial multidrop segment that is star-wired, unterminated, or improperly biased produces intermittent communication faults that are difficult to diagnose; the topology and termination are not optional. {note}
+### A serial segment that leaves a panel shall be galvanically isolated and surge protected at the panel boundary, coordinated with [[sync/surge-protective-devices]].
−## Integration Protocol — OPC UA {toc}
+### A star-wired or unterminated RS-485 segment reflects every transition back onto the line, and the faults it produces come and go with temperature and cable length, which is why they are found by inspection of the topology rather than by any protocol diagnostic. {note}
−### OPC UA (IEC 62541) shall be the protocol for cross-domain and cross-vendor data integration — between the control layer and the historian, MES, or enterprise reporting — where a vendor-neutral, secure interface is required.
+## Cross-Domain Integration Protocol {toc}
−### OPC UA connections shall use the protocol's native security (application authentication, message signing, and encryption) and shall not be exposed across the OT/IT boundary except through the DMZ.
+### The protocol used to move structured data from the control layer to the historian, the DMZ services, and enterprise systems shall be as indicated in the datasheet.
−### OPC UA is an integration layer, not a real-time control protocol; it complements the control protocol rather than replacing it, and is the right tool for moving structured data up the Purdue levels. {note}
+```datasheet
+label: Cross-Domain Integration Protocol
+type: select
+options:
+ - "OPC UA"
+ - "MQTT with Sparkplug B payloads"
+ - "Historian-native replication"
+ - "Modbus TCP through a broker"
+```
+### Cross-domain connections shall use the authentication, signing, and encryption the selected protocol provides, and shall cross the OT and enterprise boundary only through a DMZ service.
+
+### OPC UA carries a typed information model and a security model of its own and is served from the control side on request; MQTT with Sparkplug B publishes state changes to a broker in the DMZ so that the control side never accepts an inbound connection, which suits a unidirectional boundary and a low-bandwidth telemetry bearer alike. Neither is a real-time control protocol, and neither replaces the primary control protocol on a control zone. {note}
+
# Transmission Media {toc}
−## Copper or Fiber Selection {toc}
+## Media by Segment Class {toc}
−### Network media between active devices shall be selected per segment based on distance, the need for galvanic isolation, electrical-noise exposure, and the routing environment.
+### The media for backbone segments between switches shall be as indicated in the datasheet.
−### Balanced twisted-pair copper (Category 6 or 6A per ANSI/TIA-568) is appropriate for segments within a building or panel lineup that are within the 100 m channel limit and not exposed to severe electrical noise or ground-potential differences. {note}
+```datasheet
+label: Backbone Segment Media
+type: select
+options:
+ - "Single-mode optical fiber"
+ - "Multimode optical fiber"
+ - "Balanced twisted-pair copper"
+```
−### Optical fiber is required where the segment exceeds the copper distance limit, crosses between buildings or structures with different ground references, runs through or near medium- and high-voltage equipment, or passes through areas of severe electrical noise. {note}
+### The media for device-level segments between an access switch and a controller, I/O adapter, or networked instrument shall be as indicated in the datasheet.
−### Fiber shall be used for any segment that crosses between separately grounded structures, because fiber is a dielectric and breaks the metallic path that would otherwise carry damaging ground-potential differences and surge current between buildings.
+```datasheet
+label: Device-Level Segment Media
+type: select
+options:
+ - "Balanced twisted-pair copper"
+ - "Multimode optical fiber"
+ - "Single-pair Ethernet 10BASE-T1L"
+```
+### The media for any segment that passes between separately grounded structures shall be as indicated in the datasheet.
+
```datasheet
−label: Backbone / Inter-Building Media
+label: Media for Segments Between Separately Grounded Structures
type: radio
options:
− - "Multimode fiber (OM3) — within plant, short backbone"
− - "Multimode fiber (OM4) — within plant, higher bandwidth/distance"
− - "Single-mode fiber (OS2) — long backbone, inter-building, future-proof"
− - "Balanced twisted-pair copper (Cat 6A) — short, in-building, low-noise only"
−default: "Single-mode fiber (OS2) — long backbone, inter-building, future-proof"
+ - "Optical fiber"
+ - "Balanced twisted-pair copper with isolating surge protection at both ends"
+default: "Optical fiber"
```
−### Copper segments shall not exceed the 100 m channel length of ANSI/TIA-568; segments approaching the limit shall use fiber or an intermediate switch.
+### A balanced twisted-pair copper segment shall not exceed the 100 m channel length of ANSI/TIA-568.
+### Where copper is selected between separately grounded structures, the surge protection at each end shall be bonded to the local grounding electrode system and shall be rated for the data rate of the segment.
+
+### Copper carries power as well as data, and two structures with separate grounding electrodes sit at different potentials during a lightning event or a ground fault, so a copper link between them becomes the path that equalizes the two; fiber has no conductor to carry that current. A copper link with surge protection at both ends survives the event by diverting it, at the cost of a protector that has a finite life and a bond that has to be inspected. {note}
+
+### Copper is limited by the 100 m channel and by the noise it picks up along its route, so its reach and its immunity both fall as the route passes medium-voltage gear, drives, or long parallel power runs; fiber has no distance limit at plant scale and no coupling to any of those, so the question a segment asks is whether its route stays inside those copper limits. {note}
+
+### Single-pair Ethernet extends an Ethernet link over one twisted pair to 1000 m at 10 Mb/s, which lets a process instrument be reached by Ethernet over the kind of cable and distance a 4 to 20 mA loop uses; it does not carry a conventional switch-to-switch backbone. {note}
+
+## Copper Cabling {toc}
+
+### The performance category of balanced twisted-pair copper cabling shall be as indicated in the datasheet.
+
```datasheet
−label: Horizontal / Device-Level Media
−type: radio
+label: Balanced Twisted-Pair Copper Category
+type: select
options:
− - "Category 6A balanced twisted-pair (ANSI/TIA-568)"
− - "Category 6 balanced twisted-pair (ANSI/TIA-568)"
− - "Industrial M12-terminated twisted-pair (harsh locations)"
− - "Multimode fiber to field device (isolation / distance)"
−default: "Category 6A balanced twisted-pair (ANSI/TIA-568)"
+ - "Category 5e"
+ - "Category 6"
+ - "Category 6A"
```
−### Running copper between buildings or near medium-voltage gear is a recurring source of equipment damage and communication faults; the galvanic isolation of fiber eliminates ground loops and induced noise that copper cannot. {note}
+### The shielding construction of balanced twisted-pair copper cabling shall be as indicated in the datasheet.
−## Cabling Installation {toc}
+```datasheet
+label: Copper Cable Shielding Construction
+type: select
+options:
+ - "Unshielded"
+ - "Overall foil shield"
+ - "Overall braid shield with foil-shielded pairs"
+```
−### Network cable types, ratings, and pathway methods shall comply with [[sync/conductors-and-cables]] and [[sync/raceways-and-conduit]] and with NFPA 70 Article 725 and Chapter 8.
+### Category 5e and Category 6 both carry 1 Gb/s over the full channel; Category 6A is what carries 10 Gb/s over the full channel and carries 2.5 Gb/s and 5 Gb/s with margin, so the category follows from the backbone data rate where copper is used for the backbone. {note}
−### Communications and control cabling shall maintain separation from power conductors per the cable manufacturer's instructions and the NEC to limit induced noise.
+### A shield lowers the noise coupled into the pairs where the route runs near drives and switching power, at the cost of a bond at every termination that has to be made consistently or the shield becomes an antenna; an unshielded cable in a quiet route has no bond to get wrong. {note}
−### Cable lengths, routing, and outlet/connector locations are [[drawing: as indicated on the network and cable-route drawings]].
+### Copper connecting hardware shall be rated for the category of the cable it terminates.
−# Switches and Network Devices {toc}
+## Optical Fiber Cabling {toc}
−## Managed Industrial Switches {toc}
+### The grade of multimode optical fiber shall be as indicated in the datasheet.
−### Switches on the control network shall be managed industrial switches, not unmanaged or office-grade switches.
+```datasheet
+label: Multimode Fiber Grade
+type: select
+options:
+ - "OM3"
+ - "OM4"
+ - "OM5"
+```
−### Managed switches shall support VLANs (IEEE 802.1Q), the selected redundancy/ring protocol, port security, SNMP monitoring, and the management interface required by the cybersecurity hardening plan.
+### Single-mode optical fiber shall be OS2 in accordance with ANSI/TIA-568.
+### The optical fiber connector type shall be as indicated in the datasheet.
+
```datasheet
−label: Switch Management Class
+label: Optical Fiber Connector Type
+type: select
+options:
+ - "LC"
+ - "SC"
+ - "ST"
+default: "LC"
+```
+
+### Multimode fiber carries 1 Gb/s to several hundred meters and 10 Gb/s to a distance that shortens with each lower grade; single-mode fiber carries either rate to several kilometers on a transceiver that costs more, so the fiber type follows from the longest link in the backbone and the rate it has to carry. {note}
+
+### Every fiber strand shall be terminated at both ends on connecting hardware in a patch panel or enclosure, and an unterminated strand shall be capped.
+
+## Backbone Data Rate {toc}
+
+### The data rate of backbone segments between switches shall be as indicated in the datasheet.
+
+```datasheet
+label: Backbone Segment Data Rate
+type: range
+unit: Gb/s
+options:
+ min: 0.1
+ max: 10
+ setpoints: [0.1, 1, 2.5, 10]
+default: 1
+```
+
+### Every backbone segment shall be furnished with transceivers and connecting hardware rated for the selected rate over the installed length.
+
+## Cable Installation {toc}
+
+### Network cable routing and segment lengths shall be as indicated on [[drawing: the cable-route drawings]].
+
+### Network cabling shall be separated from power conductors by the distance the cable manufacturer publishes for the category and shielding furnished, and in no case by less than NFPA 70 requires.
+
+### Network cabling shall be installed within the bend radius and pulling tension published for the cable, and a cable that has been kinked or over-tensioned shall be replaced rather than repaired.
+
+### Network cabling that passes through a fire-rated assembly shall be firestopped in accordance with [[sync/firestopping]].
+
+# Switches and Boundary Devices {toc}
+
+## Switch Classes {toc}
+
+### The management class of switches at the core and distribution layers shall be as indicated in the datasheet.
+
+```datasheet
+label: Core and Distribution Switch Class
type: radio
options:
− - "Managed — full L2 (VLAN, ring protocol, port security, SNMP)"
− - "Managed — L3 (routing, inter-VLAN, ACLs) for distribution/core"
− - "Lightly managed — limited configuration (edge field devices only)"
−default: "Managed — full L2 (VLAN, ring protocol, port security, SNMP)"
+ - "Layer 2 managed"
+ - "Layer 3 managed"
```
−### Unmanaged switches shall not be used on the control network because they provide no segmentation, no redundancy participation, no port security, and no diagnostics, and they cannot be hardened.
+### The management class of access switches serving controllers, I/O, and field devices shall be as indicated in the datasheet.
−## Routing and Firewalls {toc}
+```datasheet
+label: Access Switch Class
+type: radio
+options:
+ - "Layer 2 managed"
+ - "Lightly managed"
+ - "Unmanaged"
+default: "Layer 2 managed"
+```
−### Inter-zone routing and filtering shall be performed by a Layer 3 switch, router, or industrial firewall at each conduit boundary.
+### An unmanaged switch shall not be placed on a segment that participates in a redundancy ring or that spans a zone boundary, because it cannot participate in the ring protocol and cannot enforce the boundary.
−### The firewall rule set shall be default-deny, permitting only the specific protocols, source/destination pairs, and ports required by the conduit, and shall be documented in the zone and conduit register.
+### A lightly managed switch shall not be placed on a segment that participates in a redundancy ring unless it supports the selected redundancy protocol, and shall not be placed on a segment that spans a zone boundary.
−### Remote access into the OT network, where provided, shall terminate in the DMZ and require multi-factor authentication, and shall not provide a direct path to control devices.
+### Where unmanaged access switches are selected, the segment served by each shall be treated as a single trust domain within its zone, and the managed switch upstream shall apply port security to the uplink.
−## Protocol Gateways and Media Converters {toc}
+### A Layer 3 core routes between VLANs in the switch itself, which keeps inter-zone traffic off the firewall and moves the rule set into access control lists; a Layer 2 core hands every inter-VLAN packet to the firewall, which keeps one rule set in one place at the cost of the firewall's throughput. A lightly managed switch offers VLAN membership and diagnostics without the full management interface, and an unmanaged switch offers neither, which is why the latter two are confined to the edge. {note}
−### Gateways translating between protocols (e.g., Modbus RTU to Modbus TCP, or serial to Ethernet) shall be placed at a defined boundary and shown on the architecture drawing.
+## Required Switch Capabilities {toc}
−### Media converters (copper-to-fiber) shall be managed where they participate in a redundancy ring; standalone unmanaged converters shall be limited to point-to-point links that do not require ring participation or diagnostics.
+### Managed switches shall provide the capabilities indicated in the datasheet.
+```datasheet
+label: Managed Switch Capabilities Required
+type: checkbox
+options:
+ - "IEEE 802.1Q VLAN tagging and trunking"
+ - "The selected redundancy protocol"
+ - "IGMP snooping and querier"
+ - "IEEE 802.1p traffic prioritization"
+ - "Port security by MAC address"
+ - "SNMPv3 management"
+ - "IEEE 802.1AB link layer discovery"
+ - "Port mirroring"
+ - "Small form-factor pluggable transceiver ports"
+ - "Relay contact output on fault"
+ - "Local event log"
+default:
+ - "IEEE 802.1Q VLAN tagging and trunking"
+ - "The selected redundancy protocol"
+ - "IGMP snooping and querier"
+ - "IEEE 802.1p traffic prioritization"
+ - "Port security by MAC address"
+ - "SNMPv3 management"
+ - "IEEE 802.1AB link layer discovery"
+ - "Port mirroring"
+```
+
+### Each switch shall retain not fewer than the number of spare ports indicated in the datasheet after every scheduled connection to it is made.
+
+```datasheet
+label: Spare Ports per Switch After Commissioning
+type: range
+unit: ports
+options:
+ min: 0
+ max: 8
+ setpoints: [0, 1, 2, 4, 8]
+default: 2
+```
+
+## Media Converters and Protocol Gateways {toc}
+
+### A media converter on a segment that participates in a redundancy ring shall be a managed device that reports link state to the ring protocol.
+
+### An unmanaged media converter shall be used only on a point-to-point segment that neither participates in a ring nor spans a zone boundary.
+
+### A protocol gateway shall be placed at a defined point shown on the architecture drawing, shall be assigned to a zone, and shall be hardened as an active network device.
+
+### An unmanaged converter that loses one side of its link keeps the other side up, so the switch beyond it never sees the failure and the ring never reconverges around it; a managed converter propagates the fault so that the ring does what it was designed to do. {note}
+
# Redundancy and Determinism {toc}
−## Topology and Redundancy Protocol {toc}
+## Backbone Topology {toc}
−### The control-network backbone shall use a redundant topology (ring or redundant star) so that a single cable or switch failure does not isolate controllers from the supervisory layer.
+### The backbone topology shall be as indicated in the datasheet.
−### The redundancy protocol shall be selected to meet the recovery-time requirement of the controlled process.
+```datasheet
+label: Backbone Topology
+type: select
+options:
+ - "Single ring"
+ - "Coupled rings"
+ - "Redundant star"
+ - "Dual parallel networks"
+ - "Non-redundant"
+```
+### Where a redundant topology is selected, a single cable or switch failure shall not separate any controller from the supervisory layer or from its remote I/O.
+
+### Where a non-redundant topology is selected, the single points of failure shall be identified on the architecture drawing and accepted in writing by the Owner before installation.
+
+## Redundancy Protocol {toc}
+
+### The redundancy protocol shall be as indicated in the datasheet.
+
```datasheet
−label: Redundancy / Ring Protocol
+label: Redundancy Protocol
type: select
options:
− - "RSTP (IEEE 802.1D/802.1Q) — recovery in seconds, simple, vendor-neutral"
− - "MRP (IEC 62439-2) — ring recovery typically under 200 ms"
− - "DLR (Device Level Ring, ODVA/EtherNet/IP) — recovery under 3 ms"
− - "PRP (IEC 62439-3) — parallel networks, zero-time seamless"
− - "HSR (IEC 62439-3) — ring, zero-time seamless"
− - "Vendor proprietary fast-ring (within a single switch family)"
−default: "MRP (IEC 62439-2) — ring recovery typically under 200 ms"
+ - "Rapid Spanning Tree Protocol"
+ - "Multiple Spanning Tree Protocol"
+ - "Media Redundancy Protocol"
+ - "Device Level Ring"
+ - "Parallel Redundancy Protocol"
+ - "High-Availability Seamless Redundancy"
+ - "Switch manufacturer ring protocol"
+ - "None"
```
+### The maximum time within which the network shall restore communication after a single cable or switch failure shall be as indicated in the datasheet.
+
```datasheet
−label: Maximum Network Recovery Time
+label: Maximum Recovery Time After a Single Failure
type: range
unit: ms
options:
min: 0
− max: 5000
− setpoints: [0, 3, 30, 50, 200, 500, 2000, 5000]
−default: 200
+ max: 6000
+ setpoints: [0, 3, 30, 50, 200, 500, 2000, 6000]
```
−### A ring topology shall have a designated ring manager (redundancy manager), and the role assignment shall be documented; client switches shall be configured consistently with the manager.
+### The selected protocol shall be capable of the selected recovery time at the number of switches in the ring, and the recovery time shall be demonstrated during commissioning.
−### RSTP recovery is measured in seconds and is acceptable only where the process tolerates that interruption; processes requiring bumpless recovery shall use DLR, PRP, or HSR for seamless or near-seamless switchover.
+### A ring shall have exactly one ring manager, its identity shall be recorded on the architecture drawing, and every other switch in the ring shall be configured as a ring client.
−### Mixing redundancy protocols in one ring, or leaving two ring managers active, creates a network loop or a broadcast storm; the redundancy design shall be coherent across the ring.
+### Two redundancy protocols shall not be run on one ring, and a ring shall not be closed until every switch in it has been configured for the selected protocol.
−## Determinism and Latency {toc}
+### The protocols recover on different time scales: spanning tree reconverges in seconds, a media redundancy ring in tens to a few hundred milliseconds depending on the ring size and the profile, a device level ring in a few milliseconds, and the parallel and seamless protocols in zero time because every frame is already sent on both paths. The recovery time the process tolerates is what selects the protocol, and a controller whose I/O connection times out faster than the ring recovers faults on every failover. {note}
−### Where the controlled process requires deterministic delivery (motion, fast interlocks, isochronous I/O), the network shall be designed for bounded latency using prioritization (QoS / IEEE 802.1Q priority) and, where required, the real-time class of the selected protocol.
+### The parallel and seamless protocols double every frame and every port, which costs a second network interface on every attached device or a redundancy box in front of it; the ring protocols cost nothing at the device and one blocked port at the ring manager. {note}
−### Control traffic shall be prioritized over non-control traffic on shared segments so that bulk transfers (historian backfill, file copies, video) cannot delay control messages.
+## Traffic Prioritization and Loading {toc}
−### Network load on any control segment should be kept well below saturation so that latency and jitter remain bounded under worst-case traffic; an overloaded control segment introduces variable delay that undermines determinism. {note}
+### Control traffic shall be marked and prioritized above non-control traffic on every shared segment, using IEEE 802.1p priority and, where the selected protocol provides one, its real-time class.
+### The maximum utilization of any control segment under worst-case traffic shall not exceed the value indicated in the datasheet, and the utilization shall be measured during commissioning.
+
+```datasheet
+label: Maximum Control Segment Utilization
+type: range
+unit: '%'
+options:
+ min: 10
+ max: 80
+ setpoints: [10, 20, 30, 40, 50, 60, 80]
+```
+
+### Latency on a switched network is bounded only while the queues stay short, and a historian backfill or a file copy fills them; prioritization keeps control frames ahead of the bulk traffic, and a utilization ceiling keeps the queues from filling with control frames alone. {note}
+
# Time Synchronization {toc}
−## Time Source and Protocol {toc}
+## Time Reference {toc}
−### All controllers, servers, switches, and instruments that timestamp data shall be synchronized to a common, traceable time source so that alarms, events, and trends across the system share one timeline. {note}
+### The time reference for the OT network shall be as indicated in the datasheet.
−### The time synchronization protocol shall be specified based on the timing accuracy required by the connected controllers, servers, and instruments.
+```datasheet
+label: OT Network Time Reference
+type: select
+options:
+ - "GNSS-disciplined grandmaster clock on site"
+ - "Site time server disciplined by a GNSS receiver"
+ - "Site time server on a free-running oscillator"
+ - "Time relayed from the enterprise network through a DMZ time relay"
+```
+### Every device on the OT network that keeps time shall take it from the selected reference, and no OT device shall query a time server outside the OT network directly.
+
+### Where time is relayed from the enterprise network, the DMZ time relay shall query the enterprise source and serve the OT network, and the conduit rule shall permit time traffic in that direction alone.
+
+### A free-running site reference keeps every device on the OT network agreeing with each other while drifting together from true time; a GNSS reference holds the network to true time, which is what lets an event on the plant network be correlated with a utility outage or a security log from outside. A relayed enterprise source depends on the boundary being up and on the enterprise clock being trustworthy, and it is the one reference that an attacker on the enterprise side can move. {note}
+
+## Time Distribution Protocol {toc}
+
+### The protocol that distributes time to controllers, servers, workstations, and switches shall be as indicated in the datasheet.
+
```datasheet
−label: Time Synchronization Protocol
+label: General Time Distribution Protocol
type: radio
options:
− - "NTP (RFC 5905) — millisecond accuracy, sufficient for SCADA timestamping"
− - "PTP (IEEE 1588) — sub-microsecond, for motion / sequence-of-events / TSN"
− - "Both — NTP for general devices, PTP where sub-microsecond is required"
−default: "NTP (RFC 5905) — millisecond accuracy, sufficient for SCADA timestamping"
+ - "NTP"
+ - "SNTP"
+ - "PTP"
+default: "NTP"
```
+### The sub-microsecond time distribution provided on segments that require it shall be as indicated in the datasheet.
+
```datasheet
−label: Time Reference Source
+label: Sub-Microsecond Time Distribution
type: select
options:
− - "GPS/GNSS-disciplined grandmaster clock (on site)"
− - "Site NTP server synchronized to GPS/GNSS"
− - "Site NTP server synchronized to an internal reference"
− - "Upstream/enterprise time source via the DMZ (read-only)"
−default: "GPS/GNSS-disciplined grandmaster clock (on site)"
+ - "Not required"
+ - "PTP default profile"
+ - "PTP power profile IEEE C37.238"
+ - "IEEE 802.1AS"
+default: "Not required"
```
−### A site time reference shall be provided, and time shall be distributed within the OT network from that reference rather than from an enterprise source reached across the OT/IT boundary.
+### The time agreement to be maintained between every pair of timestamping devices shall be as indicated in the datasheet.
−### NTP provides millisecond accuracy that is sufficient for SCADA alarm and event timestamping; PTP (IEEE 1588), using hardware timestamping, provides sub-microsecond accuracy required for motion control, sequence-of-events recording, and time-sensitive networking. {note}
+```datasheet
+label: Required Time Agreement Between Devices
+type: range
+unit: ms
+derived: "the finest sequence-of-events resolution required by the connected controllers and by the supervisory alarm and event journal"
+options:
+ min: 0.001
+ max: 1000
+ setpoints: [0.001, 0.01, 0.1, 1, 10, 100, 1000]
+default: derived
+```
−### Unsynchronized clocks make multi-device event sequences impossible to reconstruct after an upset; common time is a prerequisite for meaningful alarm analysis and forensic review. {note}
+### Where PTP is selected on a segment, every switch on that segment shall be a PTP-aware boundary or transparent clock.
−# Remote Site Communications {toc}
+### NTP holds devices within a few milliseconds over a routed network, which resolves the order of alarms and events on a supervisory journal; PTP with hardware timestamping holds them within a microsecond, which is what a sequence-of-events recorder, a synchrophasor, or a motion axis needs, and it needs every switch in the path to participate. {note}
−## Telemetry for Distributed Sites {toc}
+### Two devices that disagree on the time produce a journal in which the effect is logged before the cause, and an upset reconstructed from that journal points at the wrong equipment. {note}
−### Geographically distributed water and wastewater facilities — remote pump stations, lift stations, wells, tanks, and metering sites — shall communicate with the central SCADA system over a wide-area telemetry bearer rather than plant cabling.
+# Remote Site Telemetry {toc}
+## Telemetry Applicability {toc}
+
+### The remote sites served by wide-area telemetry rather than plant cabling shall be those indicated on [[drawing: the system architecture drawings]].
+
+### A remote pump station, lift station, well, tank, or metering site is separated from the plant by distance, by a public right of way, and by a bearer that is slower and less reliable than a plant cable, and the provisions in this section exist so that the site keeps running when that bearer is down. {note}
+
+### Where the project has no remote sites, the telemetry fields in this section are recorded as not applicable and this section imposes no requirement. {note}
+
+## Telemetry Bearer {toc}
+
+### The primary telemetry bearer serving remote sites shall be as indicated in the datasheet.
+
```datasheet
−label: Remote Site Communications Bearer
+label: Primary Telemetry Bearer
type: select
options:
− - "Licensed point-to-multipoint radio (utility-owned spectrum)"
− - "Unlicensed spread-spectrum radio (900 MHz / 2.4 GHz)"
− - "Cellular (private APN, 4G/5G)"
− - "Cellular with radio backup (dual-path)"
− - "Fiber/leased line where available"
−default: "Licensed point-to-multipoint radio (utility-owned spectrum)"
+ - "Licensed narrowband radio"
+ - "Unlicensed spread-spectrum radio"
+ - "Cellular"
+ - "Leased line"
+ - "Owner-furnished fiber"
+ - "Satellite"
+ - "Not applicable"
```
−### Remote sites shall use a controller or RTU that retains local control and logs data when communications are lost, and forwards stored data when communications are restored (store-and-forward).
+### The backup telemetry bearer serving remote sites shall be as indicated in the datasheet.
−### Loss of the telemetry link shall not stop the local process; the remote site shall continue to run on local control and shall annunciate the communications failure to the central SCADA system.
+```datasheet
+label: Backup Telemetry Bearer
+type: select
+options:
+ - "None"
+ - "Licensed narrowband radio"
+ - "Unlicensed spread-spectrum radio"
+ - "Cellular"
+ - "Satellite"
+ - "Not applicable"
+```
−### Treating a remote site as if it were on a reliable plant LAN is a frequent design error; telemetry links are high-latency, low-bandwidth, and intermittent, and the remote controller must be able to run autonomously through an outage. {note}
+### Where a backup bearer is selected, the remote site equipment shall fail over to it without operator action and shall return to the primary bearer when the primary is restored, and both transitions shall be annunciated to the supervisory system.
−## Telemetry Protocol {toc}
+### Licensed radio shall operate under a license held by the Owner in accordance with 47 CFR Part 90, and unlicensed radio shall comply with 47 CFR Part 15.
−### The telemetry protocol for distributed water/wastewater sites should be DNP3 (IEEE 1815), which supports report-by-exception, time-stamped events, store-and-forward, and secure authentication suited to low-bandwidth, intermittent links.
+### A radio path study shall be performed for every radio link and shall demonstrate fade margin at the antenna heights to be installed.
+### Licensed radio gives the Owner a channel no other user is entitled to and a link budget the Owner controls, at the cost of the license and the coordination; unlicensed radio is available at once and shares its band with every other unlicensed user in range; cellular buys the carrier's coverage and pays for it monthly, and the carrier's outage becomes the Owner's outage. {note}
+
+## Telemetry Protocol and Polling {toc}
+
+### The telemetry protocol between the supervisory system and remote sites shall be as indicated in the datasheet.
+
```datasheet
label: Telemetry Protocol
+type: select
+options:
+ - "DNP3"
+ - "IEC 60870-5-104"
+ - "Modbus TCP"
+ - "MQTT with Sparkplug B payloads"
+ - "OPC UA"
+ - "Controller manufacturer native protocol"
+ - "Not applicable"
+```
+
+### The data collection strategy over the telemetry bearer shall be as indicated in the datasheet.
+
+```datasheet
+label: Telemetry Data Collection Strategy
type: radio
options:
− - "DNP3 (IEEE 1815) — report-by-exception, time-stamped, secure auth"
− - "Modbus over the bearer (simple polling)"
− - "OPC UA over cellular VPN (where bandwidth permits)"
− - "Vendor proprietary telemetry protocol"
−default: "DNP3 (IEEE 1815) — report-by-exception, time-stamped, secure auth"
+ - "Polled at a fixed interval"
+ - "Report by exception with a periodic integrity poll"
+ - "Unsolicited reporting"
+ - "Not applicable"
```
−### Polling and report-by-exception parameters shall be tuned to the bearer bandwidth so that the link is not saturated and data collisions are avoided.
+### The protection applied to telemetry traffic on the bearer shall be as indicated in the datasheet.
−### Telemetry traffic crossing public networks (cellular, leased) shall be encrypted (VPN or DNP3 Secure Authentication) so that a remote site cannot be commanded by an unauthorized master.
+```datasheet
+label: Telemetry Link Protection
+type: checkbox
+options:
+ - "IPsec virtual private network"
+ - "Transport layer security"
+ - "DNP3 secure authentication"
+ - "Radio link encryption"
+ - "None on a private bearer"
+ - "Not applicable"
+```
−# OT Cybersecurity Baseline {toc}
+### Telemetry traffic that crosses a public carrier network shall be encrypted and authenticated end to end.
−## Security Program and Levels {toc}
+### The polling interval and the exception deadbands shall be set so that the bearer is not saturated at the worst-case event rate.
−### The OT cybersecurity baseline shall follow ISA/IEC 62443 and NIST SP 800-82 and shall implement the zones, conduits, and target security levels established under Network Architecture.
+### Each remote site shall be controlled by a controller that continues to run its local sequences on loss of the telemetry link, logs data with timestamps while the link is down, and forwards the stored data when the link is restored.
−### A target security level (SL-T) shall be assigned to each zone per ISA/IEC 62443-3-2, and the network controls shall be configured to meet the corresponding system security requirements of ISA/IEC 62443-3-3.
+### Loss of the telemetry link shall be annunciated at the supervisory system and shall not by itself stop, start, or change the state of any equipment at the remote site.
−```datasheet
−label: Minimum Target Security Level (SL-T) for the Control Zone
−type: radio
−options:
− - "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"
− - "SL 4 — protection against intentional violation using sophisticated means with extended resources"
−default: "SL 2 — protection against intentional violation using simple means"
−```
+### Report by exception sends a value when it changes and a full refresh on a slow cycle, which fits the bandwidth of a narrowband bearer; fixed-interval polling sends everything every time, which is simple and predictable and saturates a slow bearer as the point count grows. DNP3 and IEC 60870-5-104 carry timestamped events and buffered reporting in the protocol itself, and Modbus carries neither, so a Modbus telemetry system reconstructs event time from the poll time. {note}
−### For critical infrastructure such as water and wastewater treatment, the Owner's risk assessment and any applicable regulatory guidance (including AWWA cybersecurity guidance and WaterISAC fundamentals) shall inform the selected security level. {note}
+# OT Cybersecurity Baseline {toc}
+## Security Program Basis {toc}
+
+### The hardening, account, patch, logging, and backup provisions of this section shall be implemented on every active network device and shall be recorded in the cybersecurity hardening plan.
+
+### The provisions of this section are the network baseline within the zone and conduit architecture; the Owner's security program under ISA/IEC 62443-2-1 governs above this baseline, and the integration-seam responsibilities of the system integrator are governed by [[sync/control-systems-integration]]. {note}
+
## Device Hardening {toc}
−### Every active network device shall be hardened before being placed in service: default credentials changed, unused physical ports and logical services disabled, secure management protocols enabled (e.g., SSH and HTTPS rather than Telnet and HTTP), and the device firmware updated to a tested, supported version.
+### Every active network device shall be hardened before it is placed in service by the measures indicated in the datasheet.
```datasheet
label: Device Hardening Measures
type: checkbox
options:
− - "Default credentials changed; unique per-device or per-role accounts"
− - "Unused ports administratively disabled"
− - "Port security (MAC limiting / sticky MAC) on access ports"
− - "Insecure management services disabled (Telnet, HTTP, unused SNMP)"
− - "Secure management enabled (SSH, HTTPS, SNMPv3)"
− - "Firmware updated to a tested, supported version"
+ - "Default credentials removed"
+ - "Unused physical ports administratively disabled"
+ - "Port security on access ports"
+ - "Unused logical services disabled"
+ - "Unencrypted management protocols disabled"
+ - "Management access restricted to the management network"
+ - "Firmware at a version tested for the project"
- "Configuration backed up after commissioning"
−default: "Default credentials changed; unique per-device or per-role accounts"
+ - "Physical console port password protected"
+default:
+ - "Default credentials removed"
+ - "Unused physical ports administratively disabled"
+ - "Unused logical services disabled"
+ - "Unencrypted management protocols disabled"
+ - "Management access restricted to the management network"
+ - "Firmware at a version tested for the project"
+ - "Configuration backed up after commissioning"
```
−### Unused switch ports shall be administratively disabled, and port security (MAC limiting or sticky MAC) shall be enabled on access ports where the connected device set is fixed.
+### Where port security is selected, each access port shall be limited to the MAC address of the device scheduled for it, and the port shall shut down and raise an alarm on a violation.
−### Default credentials and open management services are the most exploited weakness in OT devices; an unhardened switch on the control network is a foothold regardless of any firewall in front of it. {note}
+### Where disabling of unencrypted management protocols is selected, Telnet, unencrypted HTTP, and SNMP versions 1 and 2 shall be disabled on every device that supports an encrypted replacement, and management of that device shall be performed over the encrypted replacement.
+### A default credential on a switch is published in the manual, and an open management port on the control VLAN is reachable from every device on it, so an unhardened switch is a foothold that no firewall in front of the zone addresses. {note}
+
## Account Management {toc}
−### Network devices shall use named accounts with role-based privilege rather than shared administrator logins, and accounts shall be managed centrally where the device class supports it.
+### The account model on active network devices shall be as indicated in the datasheet.
−### Access to network device management shall be restricted to the management VLAN and to authorized engineering hosts, and shall not be reachable from the general control VLAN or from outside the OT network except through the DMZ.
+```datasheet
+label: Account Model on Network Devices
+type: radio
+options:
+ - "Individually named local accounts"
+ - "Centrally authenticated named accounts with a local emergency account"
+ - "Role-based shared local accounts"
+```
+### Each account shall carry the least privilege its role requires, and administrative privilege shall not be granted to an account used for routine monitoring.
+
+### Where restriction of management access is selected, the management interface of each network device shall be reachable only from the management VLAN and from the engineering hosts listed in the hardening plan.
+
+### Where a local emergency account is provided, its credential shall be sealed, stored under the Owner's control, and changed after each use.
+
+### A shared account produces a log that says an administrator did something and cannot say which one; a named account produces a log that can be acted on, and central authentication lets a departing employee's access be removed in one place rather than on every switch. Central authentication also depends on the authentication server being reachable, which is what the local emergency account is for. {note}
+
## Patch Management {toc}
−### A patch-management process shall be established that identifies firmware and software updates for network devices, tests them in a non-production environment, and schedules their application during planned outages.
+### The qualification a firmware or software update shall pass before it is applied to a production device shall be as indicated in the datasheet.
−### Patches shall not be applied to production OT devices without testing, because an untested firmware update can disrupt the controlled process; the patch process shall balance vulnerability exposure against availability.
+```datasheet
+label: Patch Qualification Required Before Application
+type: checkbox
+options:
+ - "Validated by the control system manufacturer for the installed platform"
+ - "Tested on a non-production replica of the network"
+ - "Tested on a spare device of the same model"
+default:
+ - "Validated by the control system manufacturer for the installed platform"
+```
+### The handling of an update that closes a vulnerability rated critical shall be as indicated in the datasheet.
+
```datasheet
−label: Patch Management Approach
+label: Security-Critical Update Handling
type: radio
options:
− - "Scheduled — tested updates applied during planned maintenance windows"
− - "Risk-based — security-critical patches expedited after testing; others deferred"
− - "Vendor-validated only — only updates validated by the system vendor are applied"
−default: "Risk-based — security-critical patches expedited after testing; others deferred"
+ - "Applied at the next planned maintenance window"
+ - "Applied in an expedited window after qualification"
```
+### Updates other than security-critical updates shall be applied during planned maintenance windows agreed with the Owner's operations staff.
+
+### No update shall be applied to a production device that has not passed the selected qualification.
+
+### An untested firmware update on a ring switch can change the ring protocol's behavior and take the ring down, which is a process outage caused by a security measure; the qualification step is what keeps the cure from being the disease. {note}
+
## Monitoring and Logging {toc}
−### Network devices shall send security and operational logs to a central collector (syslog or SNMP) located within the OT network, and the time on all devices shall be synchronized so that logged events correlate.
+### Every active network device shall send its security and operational events to a central log collector using the transport indicated in the datasheet.
−### Network monitoring should include passive detection of unexpected devices, unexpected traffic flows between zones, and link or redundancy failures, with alarms surfaced to operations.
+```datasheet
+label: Network Device Log Transport
+type: checkbox
+options:
+ - "Syslog"
+ - "SNMP traps"
+ - "Flow records"
+default:
+ - "Syslog"
+ - "SNMP traps"
+```
−### Logging without synchronized time and without a collector is of little value during an incident; centralized, time-aligned logs are what make an upset or intrusion reconstructable. {note}
+### The location of the central log collector shall be as indicated in the datasheet.
−## Backup and Recovery {toc}
+```datasheet
+label: Central Log Collector Location
+type: radio
+options:
+ - "Within the OT network"
+ - "In the DMZ"
+```
−### The as-commissioned configuration of every active network device shall be backed up, stored securely, and updated whenever a configuration change is made.
+### The period for which network device logs shall be retained on the collector shall be as indicated in the datasheet.
−### A documented restore procedure shall be provided for each device class so that a failed device can be replaced and reconfigured from backup without reconstructing its configuration from memory.
+```datasheet
+label: Network Log Retention Period
+type: range
+unit: days
+options:
+ min: 30
+ max: 730
+ setpoints: [30, 90, 180, 365, 730]
+```
+### The network monitoring functions provided shall be as indicated in the datasheet.
+
+```datasheet
+label: Network Monitoring Functions
+type: checkbox
+options:
+ - "Link and port status to the supervisory system"
+ - "Redundancy state to the supervisory system"
+ - "Passive asset discovery"
+ - "Anomaly detection on inter-zone traffic"
+ - "Switch fault relay contact to the controller"
+default:
+ - "Link and port status to the supervisory system"
+ - "Redundancy state to the supervisory system"
+```
+
+### Logged events shall carry the synchronized time of the OT network so that events from different devices can be placed in order.
+
+### A ring that has lost one segment is still running, and no one knows until the second segment fails and the plant stops; reporting the redundancy state to the operator is what turns a silent single failure into a work order. {note}
+
+## Configuration Backup and Recovery {toc}
+
+### The method by which device configurations are backed up shall be as indicated in the datasheet.
+
+```datasheet
+label: Configuration Backup Method
+type: radio
+options:
+ - "Manual export after each configuration change"
+ - "Automated scheduled export to a repository within the OT network"
+```
+
+### The as-commissioned configuration of every active network device shall be backed up, and the backup shall be updated whenever the configuration is changed.
+
+### A written restore procedure shall be provided for each device class, and it shall be demonstrated during commissioning by restoring one device of each class from its backup.
+
+### Backups shall be stored where a failure of the device, the network, or the host that holds them does not take the backup with it.
+
# Testing and Commissioning {toc}
## Cable and Link Testing {toc}
−### All copper network cabling shall be certified to the ANSI/TIA-568 performance category specified, and all fiber links shall be tested for insertion loss (and OTDR-traced where required), with results recorded per link.
+### The test to which every balanced twisted-pair copper link shall be certified shall be as indicated in the datasheet.
```datasheet
−label: Cable Test Documentation
−type: checkbox
+label: Copper Link Test Level
+type: radio
options:
− - "Copper channel/permanent-link certification (ANSI/TIA-568)"
− - "Fiber insertion-loss (power-meter) test, each link"
− - "Fiber OTDR trace, each backbone link"
− - "Connector/termination inspection record"
−default: "Copper channel/permanent-link certification (ANSI/TIA-568)"
+ - "Permanent link certification to the installed category"
+ - "Channel certification to the installed category"
+ - "Wire map and length verification"
```
−### Cable certification and fiber test results shall be submitted before the network is energized for commissioning.
+### The test to which every optical fiber link shall be certified shall be as indicated in the datasheet.
−## Network Functional Testing {toc}
+```datasheet
+label: Optical Fiber Link Test Level
+type: radio
+options:
+ - "Tier 1 insertion loss"
+ - "Tier 2 insertion loss with OTDR trace"
+```
−### Commissioning shall verify device addressing and VLAN membership, end-to-end communication between each controller and the supervisory layer, and the firewall/conduit rule set against the zone and conduit register.
+### Every termination shall be visually inspected, and the inspection of each fiber connector end face shall be recorded before the link is tested.
−### Redundancy failover shall be tested by breaking each ring segment and each redundant link in turn and confirming that recovery occurs within the specified time and that no controller loses supervisory communication beyond the allowed interruption.
+### Cable test records shall be submitted and accepted before the network is energized for functional testing.
−### Time synchronization shall be verified by confirming that all timestamped devices agree on time to within the accuracy of the selected protocol.
+### A link that fails its test shall be repaired or replaced and retested at the Contractor's expense.
+### Permanent link certification tests the installed cable and its two terminations, which is what the Contractor built; channel certification adds the patch cords, which is what the traffic sees. Tier 1 measures the total loss of a fiber link, which is what the transceiver budget depends on; Tier 2 adds a trace that locates each splice and connector loss along the link, which is what finds the one bad connector on a long backbone. {note}
+
+## Network Functional Testing {toc}
+
+### The functional tests performed during commissioning shall be as indicated in the datasheet.
+
```datasheet
label: Network Commissioning Tests
type: checkbox
options:
− - "Addressing and VLAN membership verification"
− - "End-to-end controller-to-SCADA communication"
− - "Firewall / conduit rule verification against the register"
− - "Redundancy failover test (each ring segment and redundant link)"
− - "Time-synchronization verification"
− - "Remote-site telemetry and store-and-forward test (where applicable)"
− - "Network load / latency measurement on control segments"
−default: "Redundancy failover test (each ring segment and redundant link)"
+ - "Addressing and VLAN membership of every device"
+ - "End-to-end communication between every controller and the supervisory layer"
+ - "Conduit rule set verified against the zone and conduit register"
+ - "Failover by opening each ring segment and each redundant link in turn"
+ - "Recovery time measured at each failover"
+ - "Time agreement measured between timestamping devices"
+ - "Utilization measured on each control segment under worst-case traffic"
+ - "Telemetry failover and store-and-forward at each remote site"
+ - "Restore of one device of each class from backup"
+default:
+ - "Addressing and VLAN membership of every device"
+ - "End-to-end communication between every controller and the supervisory layer"
+ - "Conduit rule set verified against the zone and conduit register"
+ - "Failover by opening each ring segment and each redundant link in turn"
+ - "Recovery time measured at each failover"
+ - "Time agreement measured between timestamping devices"
+ - "Restore of one device of each class from backup"
```
+### Each failover test shall confirm that no controller lost communication with its I/O or with the supervisory layer for longer than the selected recovery time.
+
+### A test that fails shall be corrected and repeated, and the cost of the correction and of every repeated test shall be borne by the Contractor.
+
## Security Acceptance {toc}
−### A security acceptance check shall confirm that device hardening, account management, and the firewall rule set match the approved cybersecurity hardening plan, and that no default credentials, open insecure services, or undocumented network paths remain.
+### The method by which the as-built network is verified against the cybersecurity hardening plan shall be as indicated in the datasheet.
−### Remote-access paths, where provided, shall be tested to confirm they terminate in the DMZ, require multi-factor authentication, and do not provide a direct path to control devices.
+```datasheet
+label: Security Acceptance Method
+type: checkbox
+options:
+ - "Configuration review of every device against the hardening plan"
+ - "Authenticated vulnerability scan of every active network device"
+ - "Passive traffic capture reviewed against the conduit rule set"
+ - "Penetration test of the OT and enterprise boundary"
+default:
+ - "Configuration review of every device against the hardening plan"
+```
+### Security acceptance shall confirm that no default credential remains on any device, that every hardening measure selected in the datasheet has been applied to every device, and that no path between zones exists outside the conduit register.
+
+### Where remote access is provided, the acceptance shall demonstrate that a session terminates on the DMZ host, that multi-factor authentication is enforced, and that no route from the DMZ host to a control device exists without the second authenticated hop.
+
+### An active scan sends traffic to every device it tests, and some OT devices fault when scanned, so an active scan on a live network is performed only during a planned outage and with the Owner's operations staff present. {note}
+
# Installation {toc}
−## Device Mounting and Power {toc}
+## Device Mounting and Power Connection {toc}
−### Active network devices shall be mounted in the control panels or network cabinets [[drawing: as indicated on the panel and network-cabinet drawings]], on DIN rail or rack as appropriate, with the manufacturer's required clearance for cooling and cabling.
+### Active network devices shall be mounted on DIN rail or in a rack within the panel or cabinet assigned to them, with the clearance the device manufacturer publishes for cooling and for cable bend radius.
−### Devices shall be powered from the regulated, backed-up control power source serving the associated controllers, and redundant power inputs shall be connected to independent supplies where available.
+### Where redundant power inputs are furnished, each input shall be wired to its separate supply and each shall be individually fused or protected.
−## Grounding and Bonding {toc}
+### A network device shall not be mounted directly above a heat-producing component in the same enclosure unless the temperature at the device with that component operating remains within the device's operating temperature rating.
−### Network equipment grounding and the bonding of cable shields, racks, and cabinets shall comply with [[sync/grounding-and-bonding]].
+## Shield Bonding and Grounding {toc}
−### Shielded copper cable shields shall be bonded as specified by the cable system (typically at one end for low-frequency, both ends for high-frequency) consistently across a segment, coordinated with the grounding standard, to control noise without creating ground loops.
+### The bonding of the shield on shielded copper network cable shall be as indicated in the datasheet.
−### Fiber shall be used in preference to shielded copper where ground-potential differences between structures make consistent shield bonding impractical, as established under Transmission Media.
+```datasheet
+label: Shielded Copper Cable Shield Bonding
+type: radio
+options:
+ - "Bonded at both ends"
+ - "Bonded at one end at the panel"
+```
−## Labeling and Documentation {toc}
+### The selected shield bonding shall be applied consistently on every shielded segment, and the shield shall be bonded to the panel bonding point in accordance with [[sync/grounding-and-bonding]].
−### Every network device, port, patch, and cable shall be labeled to match the as-built network drawings and the addressing/VLAN documentation.
+### Network equipment, racks, and cabinets shall be bonded in accordance with [[sync/grounding-and-bonding]].
−### Labels shall identify the device name, the zone, and the address so that a technician can correlate physical equipment to the architecture drawing without guessing.
+### A shield bonded at both ends shunts high-frequency noise to ground at each end and is what an Ethernet cable's shield is designed for, and it carries circulating current where the two ends sit at different potentials; a shield bonded at one end carries no circulating current and shunts no noise at the far end. Where both ends are inside one bonded panel lineup the potentials match and both-end bonding costs nothing; where the ends are far apart on one structure the choice weighs the noise against the circulating current, and where they are on separate structures the media selection has already settled it. {note}
+## Identification {toc}
+
+### Every active network device, every port, and both ends of every network cable shall be labeled to match the as-built architecture drawings and the addressing plan.
+
+### The content of each device and cable label shall be as indicated in the datasheet.
+
+```datasheet
+label: Network Device and Cable Label Content
+type: checkbox
+options:
+ - "Device or cable identifier"
+ - "Zone"
+ - "IP address"
+ - "VLAN"
+ - "Far-end device and port"
+default:
+ - "Device or cable identifier"
+ - "Zone"
+ - "IP address"
+ - "Far-end device and port"
+```
+
+### Label materials and methods shall comply with [[sync/electrical-identification]].
+
# Delivery, Storage, and Handling {toc}
−## Network devices shall be delivered in the manufacturer's packaging and protected from moisture, dust, electrostatic discharge, and physical damage until installed.
+## Active network devices shall be delivered in the manufacturer's packaging and protected from moisture, dust, electrostatic discharge, and impact until installed.
−## Fiber-optic cable and connectors shall be protected from contamination and from bend radii smaller than the manufacturer's minimum during delivery, storage, and pulling.
+## Optical fiber cable shall be delivered on reels with both ends sealed, and shall be stored and handled within the minimum bend radius and maximum pulling tension published for the cable.
−## Devices and cable stored on site before installation shall be kept in a dry, temperature-controlled space within the manufacturer's storage limits.
+## Devices and cable stored on site before installation shall be kept in a dry, enclosed space within the storage temperature range published for the product.
+## Optical connectors shall be kept capped until the moment of connection, and a connector that has been exposed shall be cleaned and inspected before it is mated.
+
# Warranty {toc}
−## Warranty Terms {toc}
+## The manufacturer shall warrant each active network device against defects in materials and workmanship for the period indicated in the datasheet, measured from the date of substantial completion.
```datasheet
−label: Network Equipment Warranty Term
−type: select
+label: Network Device Manufacturer Warranty Period
+type: range
+unit: years
options:
− - "1 year (minimum)"
− - "2 years"
− - "3 years"
− - "5 years (where offered for industrial network hardware)"
−default: "2 years"
+ min: 1
+ max: 5
+ setpoints: [1, 2, 3, 5]
```
−### The manufacturer shall warrant each active network device against defects in materials and workmanship for the specified term from substantial completion.
+## The integrator shall warrant the network configuration, including addressing, segmentation, redundancy, time distribution, telemetry, and hardening, for the period indicated in the datasheet, measured from the date of substantial completion.
−### The integrator shall warrant the network configuration and integration work — addressing, segmentation, redundancy, time sync, and security hardening — for a minimum of one year from substantial completion, including correction of defects discovered in that period.
+```datasheet
+label: Network Configuration Warranty Period
+type: range
+unit: years
+options:
+ min: 1
+ max: 3
+ setpoints: [1, 2, 3]
+default: 1
+```
−# Spare Parts {toc}
+## Where the contract documents state a longer warranty period than the datasheet, the longer period shall govern.
−## Spare Parts Package {toc}
+## A device that fails within its warranty period shall be replaced with the same model or a model the manufacturer designates as its successor, and the replacement shall be restored from the configuration backup by the integrator at no cost to the Owner.
−### The Contractor shall furnish manufacturer-recommended spares so that a failed network device can be replaced and restored from backup configuration without ordering parts.
+## 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.
−- One spare managed switch of each type and port configuration deployed
−- Spare media converters and SFP transceivers of each type deployed
−- Spare fiber patch cords and copper patch cords of each type and length deployed
−- One spare remote-site radio or cellular modem of each type deployed (water/wastewater)
+## Manufacturers of industrial network hardware publish warranty terms from one year to five, and the term the Owner buys is a matter of the device count and the cost of a spare against the cost of the longer term, which is why this field asserts no norm. {note}
+# Spare Parts {toc}
+
+## The Contractor shall deliver the spare parts indicated in the datasheet to the Owner before the network is accepted, and shall obtain a signed receipt for them.
+
```datasheet
−label: Spare Parts Package
+label: Spare Parts to Be Furnished
type: checkbox
options:
− - "Spare managed switch of each type/port configuration"
− - "Spare media converters and SFP transceivers"
− - "Spare fiber and copper patch cords"
− - "Spare remote-site radio / cellular modem (water/wastewater)"
− - "Spare power supplies for network devices"
−default: "Spare managed switch of each type/port configuration"
+ - "One managed switch of each model and port configuration installed"
+ - "One media converter of each model installed"
+ - "Two transceivers of each type installed"
+ - "One power supply of each model serving network devices"
+ - "One protocol gateway of each model installed"
+ - "One telemetry radio or cellular gateway of each model installed"
+ - "Fiber and copper patch cords of each type and length installed"
+default:
+ - "One managed switch of each model and port configuration installed"
+ - "Two transceivers of each type installed"
+ - "One power supply of each model serving network devices"
+ - "Fiber and copper patch cords of each type and length installed"
```
−### Spares shall be the same model and firmware-compatible with the installed devices, and the spare-parts list shall be included in the closeout documentation.
+## Spare devices shall be the same model as the installed devices, shall carry a firmware version compatible with the installed configuration, and shall be delivered in their original unopened packaging.
+
+## Spare devices shall be labeled with the model, the firmware version, and the installed device classes they are able to replace.