SynC™

SynC · Historical revision

Control Systems Integration and Testing

Revision5
EditedOct 12, 2026
StatusSuperseded
Contents

View changes in this revision   Revision history

Historical revision. This is editorial revision 5, kept so citations to it stay resolvable. It is not the current text of this standard — see the current revision.

SynC Standards Team — Specifier (Platform Standards) ✓ OfficialDiscloses employment SynC (SynC Platform Team)
Datasheet constraints: every range, checkbox and listbox field now states its direction

1 Scope

NOTE This standard governs the work that turns individually furnished controllers, instruments, valves, panels, networks, and packaged-equipment controls into one coordinated plant control system that executes the project's documented sequences of operation. (1.1)
NOTE The work comprises the control narratives, the tag and I/O database, the configured controller logic and SCADA application, the integration of every packaged subsystem, the test program that proves the assembled system against the narratives, the commissioning sequence, the training, the as-built record, and the turnover of the source configuration to the Owner. (1.2)
NOTE The equipment the integrator configures is furnished, rated, and warranted under its own standard; this standard specifies none of that equipment and instead governs what the integrator does with it. (1.3)
NOTE A plant control system is the one deliverable on a process project that no single trade can complete alone: the electrical trade lands the wires, the process trade sets the equipment, the vendors ship the skids, and the integrator is the party whose work is defined by making all of it behave as one system. (1.4)
1.5 The process systems to be integrated under this standard shall be as indicated on the process and instrumentation diagrams.
1.6 The points the control system reads and writes shall be as indicated on the input and output schedules.
NOTE The following are outside this standard and are governed elsewhere: (1.7)
  • controller hardware, memory, spare I/O capacity, analog signal standards, programming languages, and controller redundancy, governed by Programmable Logic ControllersProgrammable Logic ControllersResolves to the current adopted revision.sync/programmable-logic-controllers
  • the SCADA platform, server architecture, HMI graphics and display hierarchy, alarm philosophy and priority scheme, historian, license ownership, and operator training on the platform, governed by SCADA And HMI SystemsSCADA and HMI SystemsResolves to the current adopted revision.sync/scada-and-hmi-systems
  • the process control network, the permitted industrial protocols, remote-site telemetry, the zone-and-conduit architecture, and the OT cybersecurity baseline of device hardening, account management, patching, logging, and network backup, governed by Process Control NetworksProcess Control NetworksResolves to the current adopted revision.sync/process-control-networks
  • the control panels the controllers are housed in, governed by Industrial Control PanelsIndustrial Control PanelsResolves to the current adopted revision.sync/industrial-control-panels
  • the instruments and final elements themselves and the calibration and stroke methods that apply to them, governed by Process InstrumentationProcess InstrumentationResolves to the current adopted revision.sync/process-instrumentation, Flow MeasurementFlow MeasurementResolves to the current adopted revision.sync/flow-measurement, Analytical InstrumentationAnalytical InstrumentationResolves to the current adopted revision.sync/analytical-instrumentation, Level SensorsLevel MeasurementResolves to the current adopted revision.sync/level-sensors, and Control Valves And ActuatorsControl Valves and ActuatorsResolves to the current adopted revision.sync/control-valves-and-actuators
  • the safety instrumented system, its logic solver, and the functional-safety lifecycle under IEC 61511
  • commercial building automation, governed by Building Automation SystemBuilding Automation SystemResolves to the current adopted revision.sync/building-automation-system
  • the whole-building commissioning process where a Commissioning Authority is engaged under CommissioningTotal Building CommissioningResolves to the current adopted revision.sync/commissioning
1.8 Where the contract documents, the adopted code, or a referenced standard impose conflicting requirements on the same subject, the more stringent requirement shall govern unless the Engineer of Record directs otherwise in writing.

2 Referenced Standards

2.1 Work under this standard shall comply with the latest adopted edition of each of the following unless a specific edition is cited.
2.2 Where referenced standards conflict with one another, the more stringent requirement shall govern unless the Engineer of Record directs otherwise in writing.
Standard Title
ANSI/ISA-5.1 Instrumentation Symbols and Identification
ANSI/ISA-5.4 Instrument Loop Diagrams
ISA-5.06.01 Functional Requirements Documentation for Control Software Applications
ANSI/ISA-62381 Automation Systems in the Process Industry: Factory Acceptance Test (FAT), Site Acceptance Test (SAT), and Site Integration Test (SIT)
ANSI/ISA-62382 Automation Systems in the Process Industry: Electrical and Instrumentation Loop Check
IEC 62337 Commissioning of Electrical, Instrumentation and Control Systems in the Process Industry: Specific Phases and Milestones
ANSI/ISA-101.01 Human Machine Interfaces for Process Automation Systems
ANSI/ISA-18.2 Management of Alarm Systems for the Process Industries
ANSI/ISA-88.00.01 Batch Control Part 1: Models and Terminology
ISA-TR106.00.01 Procedure Automation for Continuous Process Operations: Models and Terminology
ANSI/ISA-95.00.01 Enterprise-Control System Integration Part 1: Models and Terminology
ANSI/ISA/IEC 62443 (series) Security for Industrial Automation and Control Systems
ANSI/ISA-61511-1 (IEC 61511-1) Functional Safety: Safety Instrumented Systems for the Process Industry Sector
IEEE 1012 System, Software, and Hardware Verification and Validation
NIST SP 800-82 Guide to Operational Technology (OT) Security
NFPA 70 National Electrical Code
NFPA 79 Electrical Standard for Industrial Machinery
Ten States Standards Recommended Standards for Water Works and for Wastewater Facilities

3 Submittals

3.1 Action Submittals

3.1.1 The Contractor shall submit the following for the Engineer of Record's review and return before controller configuration and field integration begin:
  • a division-of-responsibility matrix identifying, for every device and packaged subsystem, the party that furnishes it, the party that installs and wires it, the party that programs it, and the party that tests it
  • a control narrative for every process system, written to the content required by this standard and cross-referenced to the process and instrumentation diagrams, to each affected loop, and to each I/O point it commands or reads
  • the controlled I/O list, organized by controller and by process system, carrying every attribute required by this standard
  • the tag and point naming convention, including the loop-numbering scheme and any Owner naming overlay, with the reconciliation between the two documented
  • loop diagrams for the loops within the loop diagram scope selected in the datasheet
  • the software configuration management plan, identifying the version control tool, the baselining method, the change-log procedure, and the backup and restore method
  • a network architecture and integration drawing showing every controller, server, client, network segment, boundary device, and packaged-subsystem interface with its interface method identified, coordinated with Process Control NetworksProcess Control NetworksResolves to the current adopted revision.sync/process-control-networks
  • the packaged-subsystem integration register, listing each vendor controller to be integrated, its native protocol, the points to be exposed to the plant SCADA, and the interface method
  • the factory acceptance test plan and procedures, with the test case list traced to the narratives and the I/O list and the pass and fail criterion for each case
  • the site acceptance test, site integration test, loop check, performance verification test, and endurance test plans and procedures, with the schedule and the acceptance criterion for each
  • the training plan, identifying each session, its content, its duration, its audience, and its materials
Action Submittals Requiredcheckbox
☑ Division-of-responsibility matrix
☑ Control narratives
☑ Controlled I/O list
☑ Tag and point naming convention
☑ Loop diagrams
☑ Software configuration management plan
☑ Network architecture and integration drawing
☑ Packaged-subsystem integration register
☑ Factory acceptance test plan and procedures
☑ Site test, loop check, performance verification, and endurance test plans
☑ Training plan
3.1.2 The control narratives, the I/O list, and the process and instrumentation diagrams shall be reconciled to one another before any of them is submitted, and a narrative that commands a point absent from the I/O list, or a listed point with no defined behavior in any narrative, shall be resolved before submittal.
3.1.3 Controller configuration for a process system shall not begin until the narrative and the I/O list for that system have been returned by the Engineer of Record.
NOTE The narrative is the document the logic is written to and the tests are written from, so a narrative changed after configuration begins is a change to logic already written and to test cases already drafted; review before configuration is what keeps a narrative correction from becoming a rework cycle. (3.1.4)

3.2 Informational Submittals

3.2.1 The Contractor shall submit the following qualifications and records with or before the action submittals:
  • the integrator's qualification evidence required by this standard, with the comparable-project references identified by facility, scope, and a current Owner contact
  • the names and platform certifications of the application engineers who will configure the controllers and the SCADA application on this project
  • the cybersecurity configuration record for the delivered system, identifying the accounts and roles to be created, the services to be disabled, the removable-media and engineering-workstation controls, and the remote-access path where one is selected, consistent with the project plan under Process Control NetworksProcess Control NetworksResolves to the current adopted revision.sync/process-control-networks
  • the factory acceptance test simulation description, identifying how each field signal and each packaged-subsystem interface will be simulated
Informational Submittals Requiredcheckbox
☑ Integrator qualification evidence and references
☑ Application engineer names and platform certifications
☑ Cybersecurity configuration record
☑ Factory acceptance test simulation description

3.3 Closeout Submittals

3.3.1 The Contractor shall submit the following before the control system is accepted at substantial completion:
  • as-built control narratives reflecting each sequence as commissioned, with every setpoint, deadband, timer, and threshold recorded at its final value
  • the as-built I/O list and tag database reflecting the installed points, scaling, alarm limits, and channel assignments
  • as-built loop diagrams reflecting the installed routing and terminations
  • a complete, restorable backup of every controller program, the SCADA application, graphics, alarm and historian configuration, and databases, in the platform's native format and in a portable export where the platform provides one
  • the configuration management record showing the final baseline of every program and application and the change log from the factory acceptance test baseline forward
  • signed factory acceptance, site acceptance, site integration, loop check, performance verification, and endurance test reports with every punch-list item closed or dispositioned in writing by the Engineer of Record
  • loop check sheets, instrument calibration records, and valve stroke records for every loop within the loop check scope
  • the cybersecurity closeout record, giving the account and role inventory, the installed firmware and software versions with their dates, the configured backup schedule, and a signed statement that every default credential on every device delivered under this standard has been changed
  • the force and override removal record required by this standard
  • operation and maintenance data prepared in accordance with Operation And Maintenance DataOperation and Maintenance DataResolves to the current adopted revision.sync/operation-and-maintenance-data, including the as-built narratives, the tag database, alarm response guidance, the backup and restore procedure, and the recommended preventive maintenance
  • training records naming the personnel trained, the dates, and the topics
  • a signed receipt from the Owner for the software, media, and source configuration turned over under this standard
Closeout Submittals Requiredcheckbox
☑ As-built control narratives with final tuned values
☑ As-built I/O list and tag database
☑ As-built loop diagrams
☑ Restorable backup of every program, application, and database
☑ Configuration management record and change log
☑ Signed test reports with punch list closed
☑ Loop check, calibration, and valve stroke records
☑ Cybersecurity closeout record
☑ Force and override removal record
☑ Operation and maintenance data
☑ Training records
☑ Owner receipt for software and source configuration
NOTE The closeout package is what allows a successor integrator, or the Owner's own staff, to change the system after the integrator has left; a control system whose source configuration and as-built narratives were never delivered is one that no one can safely modify. (3.3.2)
3.3.3 The Contractor shall submit the closeout documents not later than the number of days after substantial completion indicated in the datasheet.
Closeout Submission Deadline After Substantial Completionrange
Not more than
days
1430456090

4 Quality Assurance

4.1 Integrator Qualifications

4.1.1 The integration, configuration, programming, and testing under this standard shall be performed by a control system integrator that has integrated control systems of comparable type, scale, and process complexity for not less than the period indicated in the datasheet.
Integrator Experiencerange
Not less than
years
2351015
4.1.2 The integrator shall furnish the qualification evidence indicated in the datasheet.
Integrator Qualification Evidence Requiredcheckbox
☑ Current manufacturer certification on the controller platform
☑ Current manufacturer certification on the SCADA platform
☐ Certification under the Control System Integrators Association program
☐ Registered quality management system
☐ Application engineers under the direction of a licensed professional engineer
☑ Comparable-project references
NOTE Certification under the Control System Integrators Association program means the integrator's engineering, project-management, quality, and financial practices have been audited against a published checklist by an independent auditor; where the Owner has no controls engineering staff of its own to evaluate an integrator's process, that audit stands in for one the Owner would otherwise have to perform, and where the Owner does have such staff the certification adds less. (4.1.3)
4.1.4 Where comparable-project references are required, the integrator shall furnish not fewer than the number of references indicated in the datasheet, each for a system placed in service within the preceding five years.
Comparable-Project Referencesrange
Not less than
references
123510
4.1.5 Where the facility is a water or wastewater treatment plant, the integrator's comparable experience shall include plant SCADA integration for treatment facilities of comparable unit-process scope.
4.1.6 Where the plant includes remote sites reporting by telemetry, the integrator's comparable experience shall include distributed telemetry integration.
NOTE A treatment plant is a chain of unit processes whose sequences interlock across the chain, and an integrator whose experience is confined to discrete manufacturing or single-skid systems has not encountered the plant-wide interactions that make treatment-plant integration a distinct competence. (4.1.7)

4.2 Single Point of Responsibility

4.2.1 One party shall hold single point of responsibility for the integration, configuration, testing, and commissioning of the plant control system, and that party shall be the integrator, or the lead integrator where the datasheet selects discipline integrators.
4.2.2 Where a portion of the control system arrives as factory-programmed packaged-equipment controls, the responsible party shall remain responsible for integrating that subsystem into the plant SCADA and for verifying that every point in the integration register is visible and operable at the operator interface.
4.2.3 The responsible party shall verify, before the site acceptance test, that every point in the I/O list is present, correctly scaled, correctly named, and behaving as its narrative describes.

4.3 Pre-Integration Conference

4.3.1 A pre-integration conference shall be held before any control system field integration begins.
4.3.2 Attendees shall include the integrator, the electrical contractor, the mechanical and process contractor, each packaged-equipment vendor whose equipment has a control interface, the Owner's operations and OT security representatives, and the Commissioning Authority where one is engaged.
4.3.3 The agenda shall include the division-of-responsibility matrix, the tag and I/O conventions, the network and OT boundary coordination, the interface method for each packaged subsystem, the test sequence and schedule, and the access controls that will govern engineering connections during construction and after acceptance.

5 Division of Responsibility

NOTE An unclear boundary between the integrator, the electrical trade, the process trade, and the vendors is the most frequent source of requests for information, disputes, and schedule slip on a controls project, and it fails in two ways at once: work performed twice and work performed by no one. (5.1)

5.2 Responsibility Matrix

5.2.1 A division-of-responsibility matrix shall be prepared by the integrator, agreed by every party at the pre-integration conference, and maintained through commissioning, assigning for every device and subsystem the furnish, install-and-wire, program, and test responsibility.
5.2.2 The matrix shall implement the assignments made in the datasheet under this article, and where the matrix and the datasheet disagree, the datasheet shall govern.
5.2.3 The party that authors the control narratives shall be as indicated in the datasheet.
Control Narrative Authorselect
Engineer of Record
Control system integrator
Owner's engineering staff
NOTE The narrative states the process intent, and process intent belongs to whoever designed the process; where the Engineer of Record designed the treatment or production process, the narrative is that party's statement of how the design is meant to run, and an integrator asked to author it is being asked to reconstruct intent from the drawings. Under a design-build or progressive delivery in which the integrator sits inside the design team, the integrator authors from the process engineer's intent directly, and under an Owner with a fleet standard the Owner's staff may author to keep every plant on one convention. (5.2.4)
5.2.5 The party that authors the device-level logic shall be as indicated in the datasheet.
Device-Level Logic Authorselect
Control system integrator
Engineer of Record
Owner's engineering staff
NOTE Device-level logic is the standard behavior of a motor, a modulating valve, or an analog input regardless of the process it serves, and it is separable from the process narrative: one party can state that the lead pump starts on low level while another party writes the block that starts a pump, monitors its run feedback, and alarms on failure to start. (5.2.6)
5.2.7 The integration delivery model shall be as indicated in the datasheet.
Integration Delivery Modelselect
Single integrator for the entire plant
Discipline or area integrators with a designated lead integrator
Owner-designated standard integrator
NOTE A single integrator removes every seam between integrators but concentrates the schedule on one firm's capacity; discipline or area integrators spread the work across firms that each know their equipment and create a seam at the SCADA that the lead integrator has to own; an Owner-designated integrator keeps a fleet of plants on one convention and one support relationship at the cost of competitive pricing on the integration scope. (5.2.8)
5.2.9 The party that furnishes the control panels housing the controllers shall be as indicated in the datasheet.
Control Panel Furnishing Responsibilityselect
Control system integrator
Electrical contractor
Owner-furnished
5.2.10 The party that terminates field wiring at the control panel terminals shall be as indicated in the datasheet.
Field Wiring Termination at Control Panelsselect
Electrical contractor
Control system integrator
Control panel fabricator
NOTE Where the electrical contractor terminates at the panel, one trade owns the whole conductor from the field device to the terminal, and a wiring fault has one responsible party; where the integrator terminates at the panel, the party that will perform the loop check has landed the panel end itself and the termination drawing and the checkout sheet come from one hand, at the cost of a hand-off in the middle of every conductor. (5.2.11)
5.2.12 The party that performs instrument calibration for the loop checks shall be as indicated in the datasheet.
Instrument Calibration Responsibilityselect
Control system integrator
Instrument supplier's service representative
Mechanical and process contractor
Independent calibration service
5.2.13 Field wiring routing and the wiring between field devices and panels shall be as indicated on the control wiring and interconnection diagrams.

5.3 Trade Obligations

5.3.1 The integrator shall configure and program the controllers and the SCADA application, shall integrate every packaged subsystem, and shall provide the narratives, the I/O list, the loop diagrams, and the test procedures assigned to it under this standard.
5.3.2 The electrical trade shall furnish and install control power, raceways, control wiring, and instrument and valve field wiring in accordance with the project electrical standards, and shall land conductors at the field devices and at the panel terminals assigned to it in the datasheet.
5.3.3 The mechanical and process trade shall furnish and install the process equipment, the in-line instruments, and the final elements, and shall make each item available, with process fluid or a substitute where the test requires it, for loop checks and commissioning at the time the test schedule requires.
5.3.4 Each packaged-equipment vendor shall furnish its skid controls, shall expose the points listed for it in the integration register, and shall furnish the register map and interface documentation this standard requires.
5.3.5 Each packaged-equipment vendor shall make a controls representative available during the loop check and site testing of its subsystem, in the manner indicated in the datasheet.
Vendor Controls Representative During Subsystem Testingradio
○ On site
○ Remote
○ Not required
NOTE A vendor whose controller misbehaves at the interface is the only party that can change that controller, so the question the datasheet settles is whether that party is in the room, on the phone, or reached later through a service call while the test waits. (5.3.6)

6 Control Narratives

NOTE A control narrative is the written sequence of operation for a process system: the human-readable statement of how the system is meant to behave under every condition, against which the logic is programmed, the tests are written, and the operators are trained. (6.1)
NOTE The narrative is the bridge between the process design and the executable logic, and every party downstream of it reads it differently: the programmer configures to it, the test engineer derives cases from it, and the operator learns the plant from it. (6.2)
6.3 A control narrative shall be provided for every process system within the scope of this standard.
6.4 The narratives shall be documented in the framework indicated in the datasheet.
Control Narrative Documentation Frameworkselect
ISA-5.06.01 functional requirements format
Owner's narrative template
Integrator's standard narrative format
NOTE Where the Owner operates several plants, the Owner's template puts every plant's narrative in the same shape for the same operators; ISA-5.06.01 gives a project without such a template a published structure that separates the requirement from its implementation; and an integrator's own format is the one that firm's engineers write and test fastest, at the cost of being unfamiliar to the next integrator. (6.5)

6.6 Narrative Content

6.6.1 Each control narrative shall address the content indicated in the datasheet.
Control Narrative Content Requiredcheckbox
☑ Process purpose and equipment served
☑ Normal automatic sequence
☑ Operator manual mode and available manual commands
☑ Startup and shutdown sequences with permissives
☑ Lead, lag, standby, and duty-rotation logic
☑ Interlocks and permissives with initiating condition and action
☑ Alarm conditions with priority and expected operator response
☑ Failure response on loss of signal, power, and communications
☑ Adjustable parameters listed with initial values
☐ Operator-entered limits and their permitted ranges
6.6.2 Each narrative shall be cross-referenced to the process and instrumentation diagram, to every control loop it affects, and to every I/O point it commands or reads, so that the narrative, the loop diagrams, and the I/O list form a closed and mutually consistent set.
6.6.3 Each step that depends on a setpoint, deadband, timer, or threshold shall identify that parameter as adjustable and shall state its initial value.
6.6.4 The fail-safe state of every final element shall be stated in the narrative and shall match the failure mode configured on the valve, actuator, or drive under Control Valves And ActuatorsControl Valves and ActuatorsResolves to the current adopted revision.sync/control-valves-and-actuators.
NOTE The failure response is the most safety-relevant behavior a narrative describes and the one most often left out, and a narrative that omits it leaves that behavior undefined, unprogrammed, and untestable. (6.6.5)
6.6.6 Where the Engineer of Record authors the narratives, the integrator shall report in writing every condition it encounters in configuration that the narrative does not address, and shall not resolve such a condition by its own assumption.

6.7 Control Modes

6.7.1 Every controlled loop and device shall support the control modes indicated in the datasheet, with the active mode displayed at the operator interface.
Control Modes Required Per Loopcheckbox
☑ Automatic
☑ Manual at the operator interface
☑ Local at the field device or local control station
☑ Off or locked out
☐ Cascade or remote setpoint
6.7.2 Where local mode is selected, the SCADA shall continue to monitor the device while it is under local control, shall display the local state, and shall not issue commands to the device until it is returned to remote control.
6.7.3 Cascade or remote setpoint mode applies to a loop whose setpoint is driven by another loop or by a supervisory calculation, and the narrative for such a loop shall state the source of the remote setpoint and the behavior when that source is unavailable.
6.7.4 Transfer between modes shall be bumpless for every modulating loop, so that a transfer from automatic to manual, or from manual back to automatic, does not step the final element.

7 Tag and Point Naming

NOTE One naming convention applied identically across the process and instrumentation diagrams, the I/O list, the controller logic, and the SCADA database is what lets an operator, a programmer, and a maintenance technician refer to the same device by the same name. (7.1)
NOTE Inconsistent tagging between the drawings and the database is a chronic source of commissioning error and is the first thing an integration audit checks. (7.2)
7.3 The tag naming basis shall be as indicated in the datasheet.
Tag Naming Basisselect
ANSI/ISA-5.1 loop-and-function tagging
ANSI/ISA-5.1 tagging with an Owner asset-numbering overlay
Owner naming standard mapped to ANSI/ISA-5.1 functions
NOTE A new plant with no existing tag database can adopt ANSI/ISA-5.1 directly; an expansion or a migration of a plant that already carries thousands of tags in a maintenance management system inherits that plant's convention, and the question becomes how the new tags map onto it rather than which convention is cleaner. (7.4)
7.5 Instrument and loop tags shall identify the measured or initiating variable and the device function in accordance with ANSI/ISA-5.1.
7.6 Each loop shall carry a unique loop number, and every device within a loop shall share that number with a distinguishing function identifier.
7.7 A device shall carry one and only one tag across the drawings, the I/O list, the loop diagrams, the controller logic, and the SCADA database.
7.8 Where an Owner overlay or Owner standard is selected, the reconciliation between it and ANSI/ISA-5.1 shall be documented in the naming convention submittal.

8 Input/Output List and Loop Diagrams

8.1 Controlled I/O List

NOTE The I/O list is the master index of every signal the control system reads or writes, and it is the basis of the point-to-point checkout, of the SCADA database build, and of the controller and panel sizing performed under the equipment standards. (8.1.1)
8.1.2 The integrator shall maintain a single controlled I/O list as the authoritative point database from the first submittal through as-built, and every revision to it shall be carried into the controller configuration and the SCADA database.
8.1.3 The I/O list shall identify, for each point, the tag, the description, the signal type, the engineering range and units, the scaling, the normal and failure states, the alarm limits, and the controller, module, and channel assignment.
NOTE The analog signal standards, the spare I/O allowance, and the I/O module types are selected under Programmable Logic ControllersProgrammable Logic ControllersResolves to the current adopted revision.sync/programmable-logic-controllers, and the I/O list shall reflect the selections made there. (8.1.4)

8.2 Loop Diagrams

8.2.1 Loop diagrams shall be provided for the loops within the scope indicated in the datasheet.
Loop Diagram Scopeselect
Every control loop, analog and discrete
Analog and modulating loops, with discrete points shown on panel wiring diagrams
Panel wiring and interconnection diagrams in place of loop diagrams
8.2.2 Each loop diagram provided shall conform to ANSI/ISA-5.4 and shall show every device in the loop, the signal path from sensor to final element, the wiring and terminations, and the power source.
NOTE A loop diagram per loop is the document a technician carries to a loop check and to every later troubleshooting call; on a plant with a large discrete point count it is also the largest single drawing deliverable, and a discrete point whose whole path is a dry contact and a terminal is fully described on a wiring diagram. (8.2.3)

9 Software Configuration Management

9.1 Version Control and Baselines

9.1.1 Controller logic and the SCADA application are software, and they shall be developed, versioned, baselined, and backed up under a documented configuration management process.
9.1.2 The integrator shall place every controller program and the SCADA application under version control before the factory acceptance test.
9.1.3 A documented baseline of every program and application shall be recorded at each milestone indicated in the datasheet.
Configuration Baseline Milestonescheckbox
☑ Completion of the factory acceptance test
☑ Completion of the site acceptance test
☐ Completion of the performance verification test
☑ Substantial completion
☐ End of the warranty period
9.1.4 Every change to a baselined program or application shall be recorded in a change log identifying what changed, why, who made the change, and when.
NOTE A change made in the field and never carried back into the baseline is the ordinary origin of a plant whose running program no longer matches any copy anyone holds. (9.1.5)

9.2 Backup and Restore

9.2.1 A full, restorable backup of every controller program, the SCADA application, graphics, alarm and historian configuration, and databases shall be maintained from the factory acceptance test baseline onward.
9.2.2 A restore from backup onto a target other than the running system shall be demonstrated before substantial completion, and the demonstration shall be witnessed and recorded.
NOTE The backup methods and media for the SCADA platform are selected under SCADA And HMI SystemsSCADA and HMI SystemsResolves to the current adopted revision.sync/scada-and-hmi-systems, and the restore demonstrated under this standard shall use them. (9.2.3)

9.3 Standard Device Logic

9.3.1 The source of the standard device blocks used for like devices shall be as indicated in the datasheet.
Standard Device Block Library Sourceselect
Integrator's standard library
Owner's standard library
Platform manufacturer's process library
Developed for the project
NOTE The program organization and the reuse of parameterized device blocks are required under Programmable Logic ControllersProgrammable Logic ControllersResolves to the current adopted revision.sync/programmable-logic-controllers; this article settles only whose blocks are used. (9.3.2)
NOTE An Owner with a fleet of plants that all run one library gains a maintenance staff that recognizes every motor block on sight; an integrator's library is the one its engineers have already debugged; the platform manufacturer's library is supported past the life of either firm's relationship with the plant; and a library developed for the project fits a process no existing block describes, at the cost of being tested for the first time on this project. (9.3.3)
9.3.4 Each standard device block shall be tested once in full at the factory acceptance test, and each instance of the block thereafter shall be tested for its instance-specific parameters and its I/O assignment.
9.3.5 Where the process is batch or sequential, the control structure shall follow the procedural and equipment models of ANSI/ISA-88.00.01, and where a continuous process is automated as a sequence of procedures, the models of ISA-TR106.00.01 shall apply.

9.4 Verification Traceability

9.4.1 The software shall be verified against the control narratives and the I/O list through the test program of this standard, consistent with the verification and validation framework of IEEE 1012.
9.4.2 The test plans shall trace every narrative step and every I/O point to a test case, and a function that no test case demonstrates shall be treated as unverified.
9.4.3 The factory acceptance test shall exercise the controller logic using the simulation method indicated in the datasheet.
Factory Acceptance Test Simulation Methodselect
Forced I/O at the controller
Simulation panel with switches and signal sources
Software process simulation driving the controller I/O
Emulated controllers with a process model
NOTE Forcing I/O at the controller proves the logic reads and writes the right bits and nothing else; a simulation panel adds the physical signal path and lets a witness operate the test; a software process model closes the loop so that a pump start produces a level change and the sequence can be run end to end; and emulated controllers with a model allow the whole plant to be run before any hardware exists, at the cost of building the model. The simulation method sets how much of the process behavior the factory test can prove and how much is left to the site. (9.4.4)

10 Packaged Equipment Integration

10.1 Integration Register

NOTE A process plant arrives as a collection of packaged skids, each with its own factory-programmed controller, and the plant SCADA is where all of them have to be made to look and behave like one system. (10.1.1)
10.1.2 The integrator shall obtain from each packaged-equipment vendor, and shall verify against the integration register, the native protocol, the register or object map, and the complete list of points the skid controller exposes.
10.1.3 The integrator shall integrate each packaged subsystem so that the operator sees a uniform tag tree and a consistent operating interface regardless of the underlying vendor platform.
10.1.4 The points each packaged subsystem exposes to the plant SCADA shall include, at minimum, those indicated in the datasheet.
Packaged Subsystem Points Exposed to Plant SCADAcheckbox
☑ Run and ready status
☑ Fault status with fault code
☑ Local or remote mode status
☑ Principal process variables
☑ Principal setpoints the plant is permitted to command
☐ Active alarm list
☑ Runtime and cycle counts
☐ Energy and consumable usage
NOTE The datasheet selection sets the categories every subsystem exposes; the specific points within those categories differ skid by skid and are scheduled rather than selected. (10.1.5)
10.1.6 The specific points exposed by each subsystem shall be as indicated on the packaged-equipment interface schedules.

10.2 Data Interface

10.2.1 The data interface between each packaged subsystem and the plant control system shall be as indicated in the datasheet.
Packaged Subsystem Data Interfaceselect
Native protocol over the plant network
Protocol gateway to the plant network
OPC UA server on the skid controller
Hardwired discrete and analog I/O
NOTE The protocols permitted on the plant network are selected under Process Control NetworksProcess Control NetworksResolves to the current adopted revision.sync/process-control-networks, and a skid whose native protocol is on that set connects directly, while one whose protocol is not on it needs a gateway, an OPC UA server, or a hardwired interface; the datasheet selection is the policy applied where the register shows a mismatch. (10.2.2)
NOTE A hardwired interface carries a fixed handful of signals and cannot be extended without pulling wire, but it depends on no firmware, no address table, and no protocol revision, and it is the interface the operator can trace with a meter. (10.2.3)
10.2.4 Where a protocol gateway is used, the gateway shall be listed in the integration register, its configuration shall be placed under the configuration management of this standard, and its configuration backup shall be included in the closeout backup.

10.3 Safety-Critical Interlocks

10.3.1 The signal path for each safety-critical interlock between a packaged subsystem and the plant shall be as indicated in the datasheet.
Safety-Critical Interlock Signal Pathselect
Hardwired discrete signal
Safety-rated network protocol
NOTE A hardwired interlock is unaffected by a network fault, a switch reboot, or a protocol revision, and it is the arrangement the operator and the electrician can both trace; a safety-rated network protocol carries the interlock with a diagnostic coverage and a defined failure response that a plain protocol does not have, and it applies where the controllers on both ends support it and the network is engineered for it under Process Control NetworksProcess Control NetworksResolves to the current adopted revision.sync/process-control-networks. (10.3.2)
10.3.3 Unless a safety-rated network protocol is selected in the datasheet, a safety-critical interlock shall not depend on a network protocol for its protective action.
10.3.4 The state of each safety-critical interlock shall be reported to the plant SCADA for indication over the data interface, and that indication shall not be the path by which the protective action is carried.

11 Secure Delivery of the Configured System

NOTE The OT cybersecurity baseline for the plant, including the zone-and-conduit architecture, device hardening, account management, patching, logging, and network backup, is established under Process Control NetworksProcess Control NetworksResolves to the current adopted revision.sync/process-control-networks, and the SCADA platform's role-based access, authentication, and audit logging under SCADA And HMI SystemsSCADA and HMI SystemsResolves to the current adopted revision.sync/scada-and-hmi-systems; this section governs what the integrator does while building and delivering the configuration inside that baseline. (11.1)
11.2 Every default and vendor-default credential on every controller, server, workstation, gateway, and integrated device delivered under this standard shall be changed before the site acceptance test, and the change shall be attested in the cybersecurity closeout record.
11.3 Accounts created in the delivered controllers and application shall be named individual accounts assigned to roles, and the integrator shall not leave a shared engineering account, a test account, or its own account active at substantial completion.
11.4 Services, ports, and protocols not required for plant operation shall be disabled on every delivered device, consistent with the hardening plan under Process Control NetworksProcess Control NetworksResolves to the current adopted revision.sync/process-control-networks.
11.5 Engineering workstations used to configure the delivered system shall be governed by the policy indicated in the datasheet.
Integrator Engineering Workstation Policyselect
Owner-furnished engineering workstation only
Integrator workstation after Owner scan and approval
Integrator workstation without restriction
NOTE A laptop that has visited a dozen other plants is the most common carrier of malware into an otherwise isolated control network, and the workstation policy is what decides whether that laptop touches this one. (11.6)
11.7 Removable media used to transfer configuration to a delivered device shall be scanned on an Owner-approved station before use, and media used on the plant network shall not be reused outside it.

11.8 Remote Engineering Access

11.8.1 Remote engineering access for the integrator during commissioning and warranty support shall be as indicated in the datasheet.
Integrator Remote Engineering Accessselect
None
Owner-managed VPN with multi-factor authentication to a jump host
Owner-controlled vendor support connection enabled per session
11.8.2 Where no remote engineering access is selected, all commissioning support and warranty correction shall be performed on site, and the warranty response time of this standard shall be measured to arrival on site.
11.8.3 Where remote engineering access is provided, it shall traverse a path controlled, authenticated, and logged by the Owner, and the integrator shall not install or retain a connection of its own.
11.8.4 A persistent always-on vendor connection shall not be provided.
NOTE Remote access resolves a warranty call in an hour instead of a day and is the difference between a tuning correction made the same afternoon and one made after a site visit is scheduled; an air-gapped plant gives that up in exchange for having no path at all to defend, and the choice belongs to the Owner's security program rather than to the integrator. (11.8.5)

12 Functional Safety Interface

NOTE Where a safety instrumented function exists, it is implemented in a logic solver separate from and independent of the basic process control system, and this standard governs only the seam between the two. (12.1)
12.2 Verification of the interface between the basic process control system and the safety instrumented system shall be as indicated in the datasheet.
Safety Instrumented System Interface Verificationradio
○ Required
○ Not applicable
Derived — the presence of a safety instrumented function that interfaces with the basic process control system, as identified in the project safety requirements specification (by default)
12.3 Where interface verification is required, the integrator shall verify during the site acceptance test that each interface behaves exactly as the safety requirements specification defines, including that a trip drives the basic-control final elements to their defined safe state and that the basic process control system cannot command a state the safety system has tripped.
12.4 The basic process control system shall not be capable of defeating, bypassing, or overriding a safety instrumented function except through the bypass and override provisions designed into the safety system under IEC 61511.
12.5 Any bypass, maintenance override, or reset of a safety function presented at the operator interface shall be implemented as the safety system design defines, shall be access-controlled, and shall be alarmed and logged while active.
12.6 The integrator shall not modify the configuration of a safety logic solver except as authorized in writing under the project functional-safety management-of-change procedure, with the authorization retained in the configuration management record.

13 Testing

13.1 Test Sequence

13.1.1 The test program shall proceed in the sequence of factory acceptance test, installation, loop checks with calibration and stroking, site acceptance test, site integration test, performance verification test, and endurance test, with each phase complete and documented before the next begins.
13.1.2 Each phase shall be conducted under a written procedure returned by the Engineer of Record before the phase begins, and each test case shall record the expected result, the observed result, the pass or fail determination, and the signature of the party who witnessed it.
13.1.3 Where the parties disagree whether an observed result meets the acceptance criterion, the Engineer of Record shall make the initial determination.

13.2 Factory Acceptance Test

13.2.1 A factory acceptance test conforming to ANSI/ISA-62381 shall be performed on the assembled and configured control system before it is shipped to the site.
13.2.2 The factory acceptance test shall be conducted at the location indicated in the datasheet.
Factory Acceptance Test Locationselect
Integrator's facility
Control panel fabricator's facility
Owner-designated staging facility
13.2.3 The integrator shall give the Owner and the Engineer of Record written notice of the factory acceptance test date not less than the number of days indicated in the datasheet before the test begins.
Factory Acceptance Test Notice Periodrange
Not less than
days
710142130
13.2.4 The Owner's witnessing of the factory acceptance test shall be as indicated in the datasheet.
Owner Factory Acceptance Test Witnessingselect
In person
Remote by video and screen share
Report review without witnessing
13.2.5 The Engineer of Record's witnessing of the factory acceptance test shall be as indicated in the datasheet.
Engineer Factory Acceptance Test Witnessingselect
In person
Remote by video and screen share
Report review without witnessing
NOTE Remote witnessing covers a screen-based test as well as presence does, because the logic, the graphics, and the alarm behavior are all on the screen being shared; a test that also inspects the assembled panels, the wiring, and the physical simulation is one a remote witness cannot see, and a plant whose operators will run the system for twenty years is one the Owner's staff often chooses to meet at the factory. (13.2.6)
13.2.7 The factory acceptance test shall cover the elements indicated in the datasheet.
Factory Acceptance Test Scopecheckbox
☑ Every control narrative sequence
☑ Mode transitions and bumpless transfer
☑ Interlock and permissive behavior
☑ Alarm generation against the rationalized alarm list
☑ Packaged subsystem interfaces by simulation
☐ Integrated network with every controller and server connected
☐ Safety instrumented system interface by simulation
☐ Backup and restore of the tested baseline
NOTE The controller-hardware and SCADA-platform tests of the factory acceptance test are specified under Programmable Logic ControllersProgrammable Logic ControllersResolves to the current adopted revision.sync/programmable-logic-controllers and SCADA And HMI SystemsSCADA and HMI SystemsResolves to the current adopted revision.sync/scada-and-hmi-systems, and the integrated test under this standard shall be conducted with those tests, on the same assembled system. (13.2.8)
13.2.9 The proportion of I/O points exercised by simulation at the factory acceptance test shall be not less than that indicated in the datasheet.
I/O Point Coverage at the Factory Acceptance Testrange
Not less than
%
102550100
13.2.10 The basis on which the factory acceptance test is accepted for shipment shall be as indicated in the datasheet.
Factory Acceptance Test Acceptance Basisselect
Every item closed before shipment
Critical items closed before shipment and minor items carried to the site punch list
13.2.11 A critical item is a failed test case affecting a control narrative sequence, an interlock, a permissive, a fail-safe response, or an alarm; a minor item is one that affects only presentation or documentation, and where the parties disagree on the classification of an item, the Engineer of Record shall make the initial determination.
13.2.12 Where the factory acceptance test is stopped or repeated because of defects in work under this standard, the integrator shall bear the cost of the repeated test, including the travel and time of the witnesses.
NOTE A defect found at the factory costs a software edit; the same defect found on site costs mobilization, process downtime, and schedule, which is why the factory test is the least expensive test on the project to make thorough. (13.2.13)

13.3 Loop Checks

13.3.1 A loop check conforming to ANSI/ISA-62382 shall be performed on every I/O point after installation and before the site acceptance test, verifying continuity from the field device through the wiring and the controller to a correctly scaled and correctly named indication at the operator interface.
13.3.2 Each analog input loop shall be verified by injecting or driving a known value at the field device and confirming the reading and scaling at the operator interface at not fewer than three points across the range, and each analog output loop by commanding known outputs and confirming the final element responds.
13.3.3 Each discrete point shall be verified by actuating the field condition and confirming the state and tag at the operator interface, and each discrete output by commanding it and confirming the device responds.
13.3.4 Instrument calibration shall be performed with the loop check by the party assigned in the datasheet, against a reference traceable to a national standard, with as-found and as-left readings recorded, using the methods specified for each instrument class under Process InstrumentationProcess InstrumentationResolves to the current adopted revision.sync/process-instrumentation, Flow MeasurementFlow MeasurementResolves to the current adopted revision.sync/flow-measurement, Analytical InstrumentationAnalytical InstrumentationResolves to the current adopted revision.sync/analytical-instrumentation, and Level SensorsLevel MeasurementResolves to the current adopted revision.sync/level-sensors.
13.3.5 Each control valve and actuator shall be stroked with the loop check and its travel verified against command, and its fail-safe position shall be confirmed by removing the signal and separately by removing the power, in coordination with Control Valves And ActuatorsControl Valves and ActuatorsResolves to the current adopted revision.sync/control-valves-and-actuators.
13.3.6 The loop check documentation shall include the records indicated in the datasheet.
Loop Check Documentationcheckbox
☑ Per-loop checkout sheet
☑ Instrument calibration record
☑ Valve and actuator stroke record
☑ Fail-safe position verification record
☐ Alarm and interlock verification per point
13.3.7 The per-loop checkout sheet shall record the tag, the signal injected or condition actuated, the expected and observed values at each test point, the pass or fail determination, and the signature of the person who performed the check.
13.3.8 The Engineer of Record shall witness not less than the proportion of loop checks indicated in the datasheet, selected by the Engineer of Record across every controller and process system.
Loop Checks Witnessed by the Engineerrange
Not less than
%
102550100
NOTE A witnessed sample proves the integrator's own checkout is trustworthy at a fraction of the witness time a full audit costs; a fully witnessed loop check is the arrangement where the loop count is small or where the consequence of a wrong point is high enough that the Owner wants its own signature on every loop. (13.3.9)
13.3.10 Where a witnessed loop fails, the Engineer of Record may expand the witnessed sample, and the cost of the expanded witnessing shall be borne by the integrator.

13.4 Site Acceptance Test

13.4.1 A site acceptance test conforming to ANSI/ISA-62381 shall be performed after the loop checks are complete to verify the installed system against the narratives under field conditions, repeating the factory test cases that depend on real field devices.
13.4.2 The site acceptance test shall confirm that every I/O point is present, scaled, named, and behaving as its narrative describes, and shall verify the safety instrumented system interfaces where the datasheet requires their verification.
NOTE The controller and SCADA site tests specified under Programmable Logic ControllersProgrammable Logic ControllersResolves to the current adopted revision.sync/programmable-logic-controllers and SCADA And HMI SystemsSCADA and HMI SystemsResolves to the current adopted revision.sync/scada-and-hmi-systems shall be conducted with the site acceptance test under this standard. (13.4.3)

13.5 Site Integration Test

13.5.1 A site integration test conforming to ANSI/ISA-62381 shall be performed after the site acceptance test to verify the interfaces between the plant control system and every packaged subsystem, the network and its boundary devices, and every remote site, with the real vendor controllers and the real network in place.
13.5.2 For each packaged subsystem, the site integration test shall confirm that every point in the integration register is read or written correctly at the plant SCADA, that the subsystem's local and remote modes behave as its narrative describes, and that each safety-critical interlock acts through the path selected in the datasheet.
13.5.3 The site integration test shall confirm the behavior of every integrated interface on loss and restoration of communication, including the state the plant SCADA displays and the state the subsystem assumes.
NOTE A subsystem that passed its own factory test and a plant that passed its site acceptance test have each been proven alone; the site integration test is the first time either is proven against the other, and the loss-of-communication case is the one neither party tested. (13.5.4)

13.6 Performance Verification Test

13.6.1 A performance verification test shall be performed after the site integration test to demonstrate that the integrated system performs its sequences under live process conditions.
13.6.2 The performance verification test shall exercise every control narrative under actual operation, including automatic control, mode transitions, lead, lag, and standby rotation, interlocks, permissives, and the response to induced abnormal conditions.
13.6.3 Each regulatory control loop shall be tuned during the performance verification test so that it is stable and responsive without sustained oscillation or steady offset at the operating conditions available during the test, and the final tuning values shall be recorded in the as-built narrative.
13.6.4 Alarm setpoints, deadbands, and on-delays shall be tuned during the performance verification test against the rationalized alarm list established under SCADA And HMI SystemsSCADA and HMI SystemsResolves to the current adopted revision.sync/scada-and-hmi-systems, so that nuisance alarms are suppressed while genuine ones are preserved, and the final values shall be recorded in the as-built narrative.
13.6.5 The Owner shall provide process feed, operating staff, and the operating conditions required by the test procedure during the performance verification test and the endurance test.
NOTE A loop tuned at the conditions of a spring startup may oscillate in the summer, which is why the tuning correction under seasonal conditions is a warranty obligation of this standard rather than an extra. (13.6.6)

13.7 Endurance Test

13.7.1 An endurance test shall be performed after the performance verification test for the continuous period indicated in the datasheet, to demonstrate that the integrated system operates without unexplained failure over a sustained period.
Endurance Test Durationrange
Not less than
days
37143060
NOTE Seven days covers every daily cycle and one full weekly cycle of the plant's operation; thirty days covers the monthly cycles of filter backwash, sludge wasting, and reporting that a week never reaches, at the cost of a month of the integrator's attendance; and a duration of zero waives the endurance test, which is the arrangement where the plant will run under the integrator's warranty attendance in any case. (13.7.2)
13.7.3 During the endurance test the system shall operate continuously with no unexplained failure of any controller, server, network segment, or integrated subsystem.
13.7.4 The restart of the endurance period after a failure shall be as indicated in the datasheet.
Endurance Test Restart After Failureselect
Period restarts from zero after any failure
Period restarts from zero after a failure attributable to work under this standard
Period pauses during correction and resumes
NOTE A restart after any failure holds the integrator to failures of equipment it did not furnish, which on a plant full of vendor skids can extend the test indefinitely; a restart only after a failure attributable to this standard's work leaves a failure of a packaged subsystem to that vendor's warranty; and a pause-and-resume treats the endurance period as a quantity of proven hours rather than as a proven uninterrupted stretch. (13.7.5)
13.7.6 Where the parties disagree whether a failure is attributable to work under this standard, the Engineer of Record shall make the initial determination.
13.7.7 Trend and historian data shall be retained for the full endurance period, and where the buffer capacity is insufficient, the data shall be offloaded during the test so that no record is lost.

14 Startup and Commissioning

14.1 The integrator shall coordinate commissioning with the electrical and process trades, the packaged-equipment vendors, and the Commissioning Authority where one is engaged, so that each item is installed, energized, and available when the phase that needs it is scheduled.
14.2 The Commissioning Authority, where engaged, shall witness the site acceptance test, the performance verification test, and the endurance test, and shall verify the as-built narratives, the I/O list, and the alarm and interlock behavior.
14.3 Every force and override placed in controller logic or at the operator interface to facilitate testing shall be logged at the time it is placed, with the point, the reason, the person, and the date.
14.4 Every logged force and override shall be removed before substantial completion, and the removal shall be verified by a second person and recorded in the force and override removal record.
NOTE A force left in a controller after commissioning defeats a control or protective function silently and is found when that function is needed, which is why the removal is verified by a second person rather than reported by the one who placed it. (14.5)
14.6 Commissioning phases and milestones shall be identified in the test schedule in the terms of IEC 62337, so that every party names each phase the same way.

15 Training

15.2 The integrator shall provide the training sessions indicated in the datasheet.
Training Sessions Providedcheckbox
☑ Process operation training on the control narratives
☑ Maintenance training on the I/O list, loop diagrams, and troubleshooting
☑ Configuration management and backup and restore training
☐ Cybersecurity practices for the delivered system
☐ Recorded sessions delivered to the Owner
15.3 Process operation training shall cover the control narratives as commissioned, the control modes and the transfers between them, the interlocks and permissives, and the expected operator response to each alarm, and shall be conducted hands-on on the commissioned system or a simulation of it before the Owner assumes operation.
15.4 The duration of process operation training shall be not less than that indicated in the datasheet.
Process Operation Training Durationrange
Not less than
hours
4816244080
15.5 Maintenance training shall cover the I/O list and loop diagrams, point-to-point troubleshooting, the coordination of instrument calibration and valve stroking with the control system, the configuration management and backup and restore procedure, and the cybersecurity provisions the Owner maintains after acceptance.
15.6 The duration of maintenance training shall be not less than that indicated in the datasheet.
Maintenance Training Durationrange
Not less than
hours
4816244080
15.7 Where recorded sessions are selected, the recordings shall be delivered to the Owner in a common playback format, so that staff hired after commissioning can be trained on the system as built.

16 Documentation and As-Builts

16.1 The integrator shall update the control narratives, the I/O list, the tag database, and the loop diagrams to as-built condition, reflecting every field change and every final tuned value.
16.2 The as-built narratives shall be delivered in an editable format and in a portable format, so that the Owner can revise them when the plant is next modified.
16.3 The operation and maintenance data delivered under this standard shall be prepared in accordance with Operation And Maintenance DataOperation and Maintenance DataResolves to the current adopted revision.sync/operation-and-maintenance-data and shall be closed out in accordance with Closeout ProceduresCloseout ProceduresResolves to the current adopted revision.sync/closeout-procedures.
NOTE The as-built documentation is what allows the Owner to operate, troubleshoot, and eventually modify the control system after the integrator has left, and an as-built narrative that still carries the design setpoints rather than the commissioned ones is a document that misleads the next engineer to open it. (16.4)

17 Warranty

17.1 The integrator shall warrant the integration, configuration, and programming against defects for the period indicated in the datasheet, measured from substantial completion.
Integration Warranty Termrange
Not less than
years
123
17.2 Where the contract documents state a longer warranty period than the datasheet, the longer period shall govern.
17.3 During the warranty period the integrator shall correct configuration and programming defects, including loop tuning and alarm deficiencies that appear under seasonal, load, or process conditions not present at commissioning, at no cost to the Owner.
17.4 The integrator shall respond to a warranty call within the time indicated in the datasheet, measured from the Owner's notice to the integrator's engineer beginning work on the reported condition, remotely where the datasheet provides remote access and on site where it does not.
Warranty Response Timerange
Not more than
hours
248244872
NOTE A response time measured in hours presumes a remote path or a local integrator; a plant with no remote access and an integrator several hundred miles away can be promised a day, and the datasheet should carry the number the selected access arrangement can actually meet. (17.5)
17.6 Warranty corrections shall be made to the controlled baseline under the configuration management of this standard, and never to an undocumented field copy, and each correction shall be recorded in the change log and carried into a refreshed backup.
17.7 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.

18 Software and Configuration Turnover

18.1 The integrator shall turn over to the Owner the items indicated in the datasheet before substantial completion, and shall obtain a signed receipt for them.
Software and Configuration Turnovercheckbox
☑ Licensed development software for the controller platform
☑ Licensed development software for the SCADA platform
☑ Source configuration for every controller program
☑ Source configuration for the SCADA application and graphics
☐ Gateway and network device configurations
☑ Verified backup media with the documented restore procedure
☐ Standard device block library with documentation
NOTE The ownership and registration of the SCADA platform licenses are governed by SCADA And HMI SystemsSCADA and HMI SystemsResolves to the current adopted revision.sync/scada-and-hmi-systems, and the turnover under this standard is in addition to that transfer. (18.2)
18.3 The Owner shall receive the rights and the media necessary to maintain and modify the delivered control system without dependence on the integrator, subject only to the platform licensing.
18.4 Source configuration shall be turned over with the symbol names, comments, and documentation intact, and not as a compiled or stripped runtime.
NOTE A compiled runtime without the source configuration leaves the Owner unable to make even a trivial change, and a source file stripped of its comments leaves the next engineer reverse-engineering the plant's own logic; the controlled, documented source is the deliverable that makes the system the Owner's. (18.5)