Document Number: D16/38808 Standard for SCADA File: 47662E

Shoalhaven Water - Standard for SCADA Installations

For more information contact Shoalhaven Water

City Administration Centre Bridge Road (PO Box 42) Nowra NSW Australia 2541P: (02) 4429 3214F: (02) 4429 [email protected]

Document Number: D16/38808File: 47662E

mailto:[email protected]

http://www.shoalwater.nsw.gov.au/

Shoalhaven Water – Standard for SCADA Installations P a g e | 1

www.shoalwater.nsw.gov.au

For more information contact Shoalhaven WaterCity Administrative CentreBridge Road (PO Box 42), Nowra NSW Australia 2541P: (02)4429 3214 F: (02) 4429 [email protected] www.shoalwater.nsw.gov.au

DisclaimerEvery effort has been made to provide accurate and complete information. However, Shoalhaven City Council assumes no responsibility for any direct, indirect, incidental or consequential damages arising the use of information in this document.

Copyright NoticeNo part of this publication may be reproduced in any form or stored in a database or retrieval system, or transmitted or distributed in any form by any means, electronic, mechanical photocopying, recording, or otherwise without written permission from Shoalhaven City Council. All rights reserved. Copyright © 2013, Shoalhaven City Council.

mailto:[email protected]

http://www.shoalwater.nsw.gov.au/



Contents

1. Introduction.......................................................................................................................61.1 Background ......................................................................................................................61.2 Scope and Purpose ..........................................................................................................61.3 Definitions and Abbreviations ...........................................................................................61.4 Terminology......................................................................................................................62. Control System Design ....................................................................................................82.1 Hardware and Software Deployed at Shoalhaven Water .................................................82.1.1 System Architecture .......................................................................................................82.1.2 Preferred and Nominated Equipment Suppliers .............................................................82.2 Design Process ................................................................................................................92.2.1 Standards, Codes and Guidelines..................................................................................92.2.2 Basis of Software Design .............................................................................................102.2.3 Software Development Process ...................................................................................102.3 PLC and SCADA Guidelines ..........................................................................................142.3.1 General.........................................................................................................................142.3.2 Data Communications ..................................................................................................142.3.3 PLC Functions..............................................................................................................152.3.4 SCADA Functions.........................................................................................................152.4 Intellectual Property........................................................................................................163. PLC Guidelines ...............................................................................................................173.1 Purpose ..........................................................................................................................173.2 Approach to software programming ...............................................................................173.2.1 General.........................................................................................................................173.2.2 Specific Requirements..................................................................................................173.3 Program Module Construction........................................................................................193.3.1 Overarching Program ...................................................................................................193.3.2 Function Block Layout ..................................................................................................193.3.3 Program Block Structure ..............................................................................................193.3.4 User Function Block Programming...............................................................................223.3.5 Examples of unacceptable User Function Blocks ........................................................233.3.6 Example of acceptable user FB ...................................................................................263.4 Structure of Program Folders .........................................................................................26



3.5 PLC Tag Naming ............................................................................................................283.6 Alarms ............................................................................................................................293.6.1 General Principles ........................................................................................................293.6.2 Alarm Prioritisation .......................................................................................................293.6.3 Alarm Monitoring Concepts ..........................................................................................303.6.4 SMS Requirements ......................................................................................................324. SCADA Guidelines..........................................................................................................334.1 General Application Framework .....................................................................................334.2 Specific Guidelines .........................................................................................................334.3 SCADA Displays.............................................................................................................354.3.1 General Development Guidelines ................................................................................354.3.2 SCADA Display Hierarchy............................................................................................374.3.3 Description of Displays.................................................................................................384.3.4 Process Graphics .........................................................................................................394.4 Alarm/Event Management ..............................................................................................414.4.1 General Guidelines.......................................................................................................414.4.2 Alarm graphics..............................................................................................................414.4.3 Alarm categorisation.....................................................................................................414.4.4 Alarm Conditioning and Discrimination ........................................................................424.4.5 SCADA Alarm Configuration ........................................................................................424.5 Security...........................................................................................................................434.6 Historian Functionality ....................................................................................................444.6.1 General.........................................................................................................................444.6.2 Trends ..........................................................................................................................444.6.3 Operational Reports .....................................................................................................444.6.4 Historical Alarm and Event Log ....................................................................................444.6.5 Other Functionality .......................................................................................................454.7 SMS Alarms and Securenet ...........................................................................................454.8 Example Screens ...........................................................................................................454.9 Suggested ClearSCADA Database Structure ................................................................625. SCADA and PLC Works - Testing and Commissioning ..............................................645.1 General...........................................................................................................................645.2 Testing and Commissioning Plan ...................................................................................645.3 Summary of Testing and Commissioning Process for Major PLC, SCADA and RTU

Works .............................................................................................................................64



5.4 Test Results Sheets .......................................................................................................655.5 Factory Acceptance Testing ...........................................................................................665.5.1 Introduction...................................................................................................................665.5.2 Resources ....................................................................................................................665.6 Pre-Factory Acceptance Testing ....................................................................................665.7 Factory Acceptance Testing ...........................................................................................675.8 Site Acceptance Testing.................................................................................................685.8.1 Pre-Site Acceptance Testing (Pre-SAT).......................................................................685.8.2 Site Acceptance Testing...............................................................................................685.9 System Tests..................................................................................................................706. Documentation................................................................................................................716.1 Documentation to be submitted......................................................................................716.2 Operations and Maintenance Manuals...........................................................................716.2.1 General.........................................................................................................................716.2.2 Contents .......................................................................................................................72Appendix A..............................................................................................................................73

List of FiguresFigure 1 PLC and SCADA coding process....................................................................................11

Figure 2 SCADA screen design process .......................................................................................12

Figure 3 Example 1 of unacceptable user FB (Motor).................................................................23

Figure 4 Example 2 of unacceptable user FB (Valve) .................................................................24

Figure 5 Example 3 of unacceptable user FB...............................................................................25

Figure 6 Acceptable user FB ...........................................................................................................26

Figure 7 General Layout and Organisation of PLC Programs ...................................................27

Figure 8 Colour conventions for SCADA displays........................................................................35

Figure 9 SCADA Display Hierarchy................................................................................................37

Figure 10 Opening Screen .................................................................................................................46

Figure 11 Alum Dosing .......................................................................................................................47

Figure 12 Drive Summary ..................................................................................................................48

Figure 13 EAT Status..........................................................................................................................49

Figure 14 Lime Dosing........................................................................................................................50

Figure 15 Effluent Reuse and Ferric Chloride.................................................................................51

Figure 16 Flow Statistics ....................................................................................................................52



Figure 17 Grit Removal System ........................................................................................................53

Figure 18 PLC and PC Network ........................................................................................................54

Figure 19 Storm Return Pump Station .............................................................................................55

Figure 20 Plant Overview ...................................................................................................................56

Figure 21 PLC Clock Setting..............................................................................................................57

Figure 22 Power Supply Monitoring and Area Lighting .................................................................58

Figure 23 Screenings System............................................................................................................59

Figure 24 Supernatant Station...........................................................................................................60

Figure 25 Sample of Setup Screens.................................................................................................60

Figure 26 Sample of Pop-Ups ...........................................................................................................62

Figure 27 ClearSCADA Database Structure ...................................................................................63

List of Tables

Table 1 Nominated Equipment Suppliers............................................................................................8

Table 2 Alarm Configuration Table ..................................................................................................13

Table 3 Trend Configuration Table ...................................................................................................13

Table 4 Typical Derived Alarms .......................................................................................................31



1. Introduction

1.1 BackgroundShoalhaven Water is embarking on a program of upgrade projects for their water and wastewater assets. The organisation has a strategic view to establish consistency for the delivery of PLC, RTU and SCADA-related works through the development of a suite of standard guidelines for software design and programming so that future works can be designed and implemented to derive the benefits of harmonisation including:

Increased safety in operations and maintenance due to consistency of design and software programming practices

Cost savings due to:

‒ reduced training needs for a less variable range of software design practices

‒ potential reduction in software implementation costs that are attributed to ‘bespoke’ design, and the consequential reduction in project management costs of system integrators and programmers

1.2 Scope and PurposeThis document sets out the minimum guidelines for the design of software for PLC, RTU and SCADA to be installed on Shoalhaven Water plants and pump stations. It is intended to provide consistency in software design and programming requirements and through the harmonisation, allow Shoalhaven Water to fulfil its health, safety and environmental obligations in the delivery and implementation of control system software works.

This document is not intended to be prescriptive to the extent that it restricts software design and configuration choices by the system integrator. However, any alternative design decisions shall require the prior approval of Council. Where there is a conflict between this document and statutory requirements, the later takes precedence.

1.3 Definitions and Abbreviations

Abbreviation Definition

PLC Programmable Logic Controller

RTU Remote Terminal Unit

SCA Switchgear and Controlgear Assembly

SCC Shoalhaven City Council

1.4 TerminologyThe following terms are used interchangeably in this Document:

Shoalhaven Water and Council

Principal and Principal’s Authorised Representative

The term ‘control system’ is generally used to collectively describe the PLC, RTU and SCADA systems.



The term ‘System Integrator’ is used to refer to the service provider that provides software development works for the PLC, RTU or SCADA systems, usually in conjunction with supplying other associated works such as communications networks and other computer system peripherals.



2. Control System Design

2.1 Hardware and Software Deployed at Shoalhaven Water

2.1.1 System ArchitectureShoalhaven Water’s major water assets comprise dams, water filtration plants, water pumping stations, water reservoirs, water and sewer pipes, wastewater treatment plants and wastewater pumping stations.

To control and monitor these water assets, Shoalhaven Water operates an organisation-wide Supervisory Control and Data Acquisition (SCADA) system comprising the following major items:

SCADA master and standby computers at the wastewater treatment plants which are configured to provide control and monitoring of both the treatment plant and its associated catchment area as follows:

o Connected to Omron PLCs for the monitoring and control of the treatment plant and

o Connected over radio telemetry network to a group of RTUs to control and monitor the associated catchment area of the wastewater network

o A telemetry RTU connected to the treatment plant ‘master’ PLC via Modbus protocol over Ethernet or serial provides critical time-stamped plant data to be displayed on the SCADA master station Telemetry Station Page

A SCADA master station at Shoalhaven Water’s Flinders Street depot connected across the Council-wide corporate IT network to all plant SCADA master stations for the supervisory monitoring only with history and systems backup of the whole wastewater and water networks

SCADA master stations for the Bamarang (Northern) and Milton (Southern) water operations, associated with a group of some 70 RTUs.

2.1.2 Preferred and Nominated Equipment SuppliersThe term “preferred” as applied in this Specification implies that the “family” or brand of products is known or familiar to Council but does not necessarily mean restrictions to selection of other brands.

The term “nominated” as applied in this Specification implies that where possible, the “family” or brand of products should be selected to ensure proper harmonisation and interfacing with key equipment already installed in the plant.

Alternative brands and models of nominated equipment shall be subject to Council’s approval. Where such alternative brands and models are offered and accepted by Council, the System Integrator will be required to warrant the substituted brand and model, and may be required to alter standard design drawings.

The following table lists nominated equipment suppliers for the PLC, SCADA and telemetry equipment.



Table 1 Nominated Equipment Suppliers

Equipment Brand Notes

SCADA Software3 Schneider Electric ClearSCADA

Programmable Logic Controller

Omron

Remote Telemetry Unit Schneider Electric SCADAPack

Data Radios Schneider Electric Trio Q Series Digital

Other radios may be used for different applications. Refer to the Principal for specific requirements on a case by case basis.

SCADA PCs2 Dell Council will supply detailed specifications

Network Switches1 Council will supply detailed requirements

Notes:

1. Network IP addresses will be supplied upon engagement of the System Integrator.

2. The System Integrator will be required to coordinate with Council in configuring and adding PCs to Council’s IT network.

3. When purchasing SCADA licenses for the Principal, the System Integrator shall register the licenses with the Shoalhaven Water site ID details.

2.2 Design Process

2.2.1 Standards, Codes and GuidelinesPLC software development shall comply with the following standard:

AS IEC 61131.8 Guidelines for the application and implementation of programming languages;

The system engineering and design process for PLC, SCADA and RTU works shall also generally comply or align with agreed industry standard system engineering principles, including but not limited to the following:

AS/NZS 4258 Software User Documentation Process;

AS/NZS 4042 Software Configuration Management Plans;

AS/NZS 4043 Software Configuration Management;

AS/NZS 4009 Software Reviews and Audits;



2.2.2 Basis of Software DesignShoalhaven Water typically engages design consultants or contractors to develop process functional descriptions (PFD) which document the high level process requirements and concepts for automatic and manual operation of the plant to be constructed.

The PFD will typically be supplied to the System Integrator as a basis for the development of software documentation. The PFD is intended to show the intent and functional requirements of the plant.

The System Integrator shall be required to prepare a detailed Functional Description Specification which shall:

describe the sequence of operations for all equipment and processes;

include I/O listings;

include alarm listings which cover the following details:

‒ Alarm description

‒ Alarm categorisation (e.g. critical / non-critical alarms, urgent, emergency)

‒ Possible initiating conditions

‒ Action required

‒ Explanatory remarks

include logic flowcharts where required to demonstrate clarity in designing the logic sequencing. A clear functional description of the function blocks to be programmed shall be included.

The Functional Requirements Specification shall be submitted to the Principal for approval prior to the commencement of software configuration and programming.

Software design deliverables shall also include but not be limited to:

PLC Program Listing demonstrating that the code is complete, is fully commented and labelled, and ready for commissioning

SCADA mimic diagrams in accordance with the Principal’s SCADA standards and showing general arrangement of both static and dynamic information with sufficient supporting information to enable an adequate review. It is preferable that these be made available in electronic format with supporting software to enable viewing of the mimic diagrams on a computer screen.

2.2.3 Software Development ProcessGeneral

Subject to the specific scope of the contract, it is the Principal’s preference that both SCADA and PLC configuration be carried out in parallel due to the dependency of common configuration details such as PLC register assignment and tag allocation.

The Principal’s SCADA applications software is developed using an object-based system. New object templates and graphics shall be developed based on the rules, guidelines and attributes already in place for existing device templates and graphics. These details will be supplied by the Principal.

The flowcharts below illustrate the software development process expected by the Principal to be followed by the System Integrator:



Figure 1 PLC and SCADA coding process

Start

Initial Design Concept

Concept OK ?

Review of Design Concept with

Shoalhaven Water

NoRe-Design after SW review

Coding

Simulation and Testing

Errors ?YesDesign Concept or Coding Error

Coding Error

Design Error

NO

Review with Shoalhaven Water

Review successful

YES

Complete

NO Design Change required

NO

YES



Figure 2 SCADA screen design process

Start

Define Screen Purpose [How Screen relates to control design]

Concept OK ?

Define place in Navigation of all Screen

YES

Coding

Simulation and Testing

Errors ?

Design Error

NO

Review with Shoalhaven Water

Review successful

YES

Complete

NO Design Change required

Allocate Information to be displayed [ equipment status/analog values/gauges/ trends realtime and historic/animations/

alarms]

Allocate Control capabilities.[ pop ups for control/alarm setpoints]

Allocate Control capabilities.[ pop ups for control/alarm setpoints ]

Allocate Trending Display capabilities

Compile Completed Concept

NO

Coding Error

YES



Software Configuration Management

The System Integrator develop a configuration management plan that ensures all PLCs and processes impacted by software development work are tracked properly with regard to:

Status of the PLC and SCADA applications development against the development process shown in the previous clause;

Version control, with revisions tracked by incrementing the version number (Vx_x) including a detailed record of the changes made at each revision level and the person responsible for the changes.

Design of SCADA Alarms

To allow the Principal to review proposed alarms during the software development process, a configuration table similar to the following shall be completed for all alarms:

Table 2 Alarm Configuration Table

Histo ric a l

L o g Du ra t io n

Group Priority Disable

Level SMS Level SMS Level SMS Level SMS Value Time Lo Hi

Ta g n a meHiHi Deadband

Adjust LevelDe sc rip t io nLoLo Lo Hi

Cla ssif ic a t io n S e t t in g s Op e ra to r Co n t ro l

A similar table shall be used to show proposed discrete alarms.

To ensure that alarms can be managed effectively, a detailed plan shall be developed by the System Integrator and reviewed by the Principal. The plan shall describe alarm group hierarchy and alarm priority assignment. Factors to be considered during the design process shall include the ability to treat alarm as groups (e.g. if door alarms are grouped, they can easily be enabled/disabled depending upon time of day), filtering of alarms for historical analysis, etc.

Design of Historian functionality

In order to assist the Principal with the review process, a trend configuration table similar to the following shall be provided before programming commences. A similar table to the trend configuration table shall also be developed for Statistical Process Control (SPC) configuration identifying interrelationships between various parameters, control limits, etc.

Table 3 Trend Configuration Table

Hourly Daily

MaxMin Max Avg Total Min Avg TotalTagname Description

Valid Range Deadband Historical Summary Generation

Min Max Units Value Time



DesigDesign of SMS Alarm functionality

SMS alarm configuration information shall be presented in a tabular fashion in order to aid operational review and understanding. The following tables provide a sample of how this information may be tabulated for review and approval by the Principal.

2.3 PLC and SCADA Guidelines

2.3.1 GeneralThe overall PLC and SCADA system is designed in a modular fashion in order to facilitate easy integration. As part of this philosophy, it is to be noted that “spare” field inputs/outputs (I/O) are assigned at strategic locations to provide for ease of expansion.

These sections describes the general concept and philosophy of the PLC and SCADA system in providing an integrated control and monitoring solution, including how the two systems interact.

2.3.2 Data Communications

1. Each PLC and SCADA node shall have individual unique network addresses on each network segment upon which they reside. IP addresses shall be hard-coded for all SCADA and PLC nodes. IP addresses will be supplied by Shoalhaven Water SCADA Co-Ordinator.

2. PLC’s that are deployed shall have consecutive node addresses.

Delay (sec) 1st Page 2nd Page Securenet

Working Hours

Individual Alarms ? ? ? No

Out of Hours

Individual Alarms ? ? ? YES

# of Retries ?Time between Retries (seconds) ?

Common Settings



3. All PLCs and SCADA nodes shall have internal clocks synchronised periodically to a master clock. Synchronisation shall provide time and date stamping accuracy to within one second of the master clock for all nodes.

4. All analog values shall be converted into floating point values in the PLC.

5. Read and Write registers shall be unique (e.g. SCADA writes to Rx to set value, but reads value back from Ry to display value).

6. Discrete control actions shall use a single bit (e.g. setting Hx starts device, resetting Hx stops the device).

7. Control automation and monitoring shall continue without disruption in the event of communication failures.

8. Control functions that rely on information affected by communications to SCADA or other PLC, shall be configured to run in a safe mode if necessary.

9. Tag/register parameters shall be defined at the lowest level possible and shall be consistent throughout the integrated PLC and SCADA system. For example, the description used in the PLC for the register is to match the description for the corresponding tag in ClearSCADA.

2.3.3 PLC FunctionsIn general, the PLC shall perform the following functions.

1. Control automation independent of SCADA and other PLCs.

2. Collect data from all field devices not directly connected to the IP network.

3. Provide all automated control functions.

4. Detect critical alarm conditions and provide annunciation (including the Process Area Alarm Siren where deemed appropriate).

5. Sequence operation of equipment based on duty cycle, failure, operator request, time of day, etc.

6. Provide process optimisation automation (e.g. Dissolved oxygen (DO) based Blower Control).

7. Monitor breakers (where provision for mechanical lockouts are required at the field device).

8. Monitor all field device interlocks (both hard-wired and programmed).

9. Functionality not specifically required within the PLC for control purposes shall be performed by the SCADA. For example, analog alarm management (HIHI, HI, LO, LOLO alarm determination) shall be managed by the SCADA system.

2.3.4 SCADA FunctionsIn general, the SCADA system shall perform the following functions:

1. Provide operators with an interface to monitor and control the various process systems required.

2. Provide real time supervisory monitoring and operational information management.

3. Provide comprehensive alarm management and generation based on the data acquired and analysed.



4. Manage all historical alarms, trends and detailed historical operational data.

5. Generate reports of historical statistical summary information (daily flow totals, chemical consumption, etc.)

6. Calculate and generate reports of maintenance related information such as equipment run-times, and start/stop frequency counts for equipment with intermittent duty cycles such as: motors, generators, and pumps.

7. Perform all data manipulation such as summation and subtraction that is used for display of historical data but not used for control purposes within the PLC.

2.4 Intellectual PropertyThe System Integrator irrevocably assigns to the Principal ownership of intellectual property rights including all existing and future copyright in relation to the PLC, SCADA and RTU software specifically developed and/or customised for the Principal. The System Integrator warrants that it will not breach the intellectual property rights of any third party.



3. PLC Guidelines

3.1 PurposeThis section contains general guidelines for the design of the control logic in the PLC to ensure that there is a consistent and structured flow of the logic. The System Integrator is at a liberty to implement PLC code in any format that they consider appropriate provided that the intent of the following guidelines is met.

3.2 Approach to software programming

3.2.1 GeneralPLCs shall be programmed using ladder logic, function blocks or structured text as applicable.

Program names shall be in accordance with Shoalhaven Water conventions.

The program shall be written in a structured format to achieve reliability and efficient utilisation of the PLC scan times and to facilitate software maintenance and trouble-shooting.

All software addresses shall be systematically allocated, ensuring that data transfer to the SCADA system will be efficient and that spare or unused addresses can be tracked to facilitate future editing or reprogramming. Each program module or subroutine shall be allocated its own ‘block’ of addresses for continuity.

The program annotation shall be clear and concise, and shall include full descriptions of all logic functions and subroutines.

PLC registers, discrete points and SCADA tag name descriptors shall be systematically formulated in accordance with the section on PLC Tag Naming and documented with full descriptions of their meanings.

3.2.2 Specific Requirements

1. The first program shall only be run on first scan. This block shall copy all default values to associated registers.

2. Setpoints shall be stored as retentive register values to allow these values to be adjusted without modification to the actual program.

3. At pumping stations, default register values shall be hard-coded into the program and adjustable only via the PLC programming software.

4. At treatment plants, certain default values shall only be hard-coded and adjustable via the programming software while other values can be adjusted via the SCADA interface.

5. All analog I/O shall be converted to floating point as part of the pre-conditioning logic (i.e. performed within the COMMS conditioning block).

6. The following modified engineering units shall be used for instantaneous flow:

‒ Flow for individual water, wastewater, chemical feed pumps – l/s

‒ Return, waste, effluent, total section/plant inflow/outflow – kL/day

‒ Aeration flow – m3/hr

7. Device interface and control automation logic shall use exclusively discrete coils and floating point registers.



8. Where more than one line of logic is required in order to perform a required function, continuation contacts shall be used. Continuation logic which uses the continuation contact will immediately follow the line ending with the associated continuation coil.

9. Where it is necessary to maintain a coil, the control logic shall make use of “set” and “reset” coils. All lines of code associated with the control of a common coil (i.e. “set”/”reset” coils) shall be logically grouped together in a structured manner and shall always reside within the same program block.

10. Generally, outputs shall only be used once within the program. The only exceptions are those outputs controlled by “set”/”reset” logic which function in pairs, and values which are initiated in the “run first” program block. Even under these unique cases, references within the program shall not exceed two (2).

11. At each rung, a comment shall be provided which outlines in clear English the function performed by the rung (or grouping of rungs in the case of “set”/”reset” rungs or continuation rungs).

12. Each logical process shall be programmed as a separate program block, including function blocks.

13. Each program block shall have a detailed comment provided which describes in detail the control philosophy achieved within the programming block.

14. Output rung enabling conditions shall be grouped at the beginning of each rung (left side) followed by conditions that inhibit the output at the end.

15. Where appropriate “PLC Running and Rack Active” interlocks shall be provided where an output rung is dependent on inputs and/or outputs from another rack or PLC or RTU.

16. Where built-in or PLC vendor-supplied control function blocks are provided as part of the programming language, such as PID loop control blocks, they shall be used in preference to bespoke function block algorithms.

17. Techniques, functions and data types not in accordance with good practice must not be used within the program. These shall include but not be limited to:

‒ Logic jumps

‒ Indirect addressing

‒ Latching logic (as opposed to “set”/”reset” coils)

‒ Momentary contacts (edge trigger should be used instead)

‒ Any type of master control relay

‒ Equal operator in conjunction with floating point values

‒ Bit masks

18. Device status shall provide tri-state information to SCADA (Opened/In Transit/Closed) where the analog value is not provided or not available.

19. All value parsing between ClearSCADA and PLCs and Control Equipment shall be scaled within ClearSCADA. Core values that have been scaled in the PLC shall not be re-scaled within ClearSCADA for display.



3.3 Program Module Construction

3.3.1 Overarching ProgramTypically, each PLC program shall comprise ‘modules’ corresponding to a particular process area e.g. inlet flow, grit removal, bar screen, chemical dosing, supernatant, etc. The overarching flow of logic shall generally be as follows:

1. start-up permissives and conditions

2. normal shut-down conditions (i.e. initiated by the operator or normal process condition such as low level)

3. abnormal shut-down conditions (i.e. abnormal process conditions or equipment fault)

4. presentation of interlocks to other systems

5. derivation of specific status and alarms to the SCADA system

3.3.2 Function Block LayoutStandard Modules

1. Standard device/process algorithms shall be used to link field equipment I/O to high- level automatic control strategies and to manual operator actions.

2. The functions performed by these algorithms (or modules) shall be all encompassing such that the PLC programming should only involve assembling program/function blocks included in this library. Modules shall include but not be limited to the following:

‒ Pump Control

‒ Statistical Analysis

‒ Control Mode – Auto/Step

Function Block Module Descriptions

The following information shall be included in the functional description of new function block modules submitted for review.

Overview – Provides a general description of the function performed and the rationale and philosophy for the control logic that forms the function block module.

Control – Details the functionality of the algorithms (in the case of a device control function block, this will be subdivided into control modes such as Auto, Manual and Local).

Failure Response and Lockout – Describes the actions required of the algorithm upon detecting that the process is not responding in the desired fashion.

Control Mode Transfer – Describes how the algorithm behaves when modes change

Presets – Lists all preset control settings and dead-bands.

Commissioning – Describes procedures to be followed to configure/customise the function block module for a given application.

3.3.3 Program Block StructureAt a more detailed level, the following program block structure shall be as follows, with block names for the specific blocks listed formulated as shown within the parenthesis:

1. First Scan and Start-up (STARTUP)



This block performs all initial housekeeping and initialisation of all addresses. The programming within this block is run only once upon the PLC transitioning from “Off” to “Run”.

2. Simulation (SIM)

This block simulates field I/O as required to allow the program to be tested and debugged before connection to actual field devices. This block shall be interlocked with the I/O disabled contact such that the simulation code will only function when I/O is disabled. Under normal operation, the rung associated with this block is disabled.

3. Communication (COMMS)

This block manages communication PLC to Remote I/O, PLC to PLC and PLC to SCADA. This includes monitoring communication status for each communication link.

4. Input Buffering and Conditioning – Conventional Signals (INPUT_BUFCOND)

This block moves a data image of all real world inputs into internal registers, buffering and conditioning the real world I/O for direct use in the PLC program logic. This covers conventional hard-wired signals only.

For discrete inputs, as part of buffering to internal registers, negative logic signals shall be inverted such that all logic development can be completed as positive logic.

If required, timers are used to condition hard-wired discrete inputs, addressing noise problems, or holding transient alarms for an adequate duration (e.g. door limit switches) for the event to be captured by SCADA.

For discrete inputs the buffering and conditioning shall be performed in a single rung.

For analog inputs, field values are to be converted to floating point values.

For analog values, values shall be checked to determine validity. Each analog value shall have an associated discrete status bit which shall be set if the information is invalid. Analog values shall also be normalised where signal noise may be a problem. This can be done by averaging the last ten scan values taken.

5. Alarm Handling (ALARM)

This block manages PLC-derived alarms. These alarms are limited to those alarms that are used within the control logic, alarms that trigger local alarm sirens, and the local alarm test system (local alarm test and acknowledge buttons).

6. Statistical Processes (STATISTICS)

The logic within this subroutine generates running totals such as process variable totals, number of start/stops, and other running totals.

7. Control Logic

System and subsystem blocks shall be named in accordance with the Principal’s equipment element naming conventions.

Program function blocks shall be arranged in a hierarchal structure with control for each subsystem programmed as a separate block assigned as a sub-block to the associated system block. All system blocks shall reside as sub-blocks to the Control Logic Block. Variations from this structure may be allowed for PLCs that control single process subsystems, such as a PLC for a pumping station or part of the plant.



The control logic shall consist of device algorithms, device drivers, and process automation algorithms.

The standard process automation algorithms contain one or all of the required common logic for duty selection (ps DTY), duty start/stop request and sequencing (ps RQS and SEQ), or duty speed management (ps PRM and STOP).

All control logic associated with a given subsystem shall be programmed within the respective subsystem block.

Logic common to all subsystem blocks shall be programmed in the associated system block, NOT within one of the subsystem blocks.

Each logical sequence shall be subdivided into a well-defined series of simple steps. In order to monitor transitions between steps, a unique integer register shall be used as a pointer for each such sequence to facilitate determining the currently active program step.

8. Output Buffer – Conventional Hard-wired Signals (OUTPUT_BUFFER)

This block moves a data image of all corresponding internal registers to real world outputs. This covers conventional hard-wired signals only.

For discrete inputs, as part of moving the outputs from internal registers, outputs to devices which function based on negative logic will be inverted.

For analog inputs, internal values shall be converted from floating point engineering units to integer raw values.

9. PLC Memory Organisation

Programs shall comply with the following memory organisation conventions and guidelines:

PLC memory shall be organised into segments.

Each segment shall contain adequate memory for future expansion.

Within each section, the memory shall be organised into logical blocks with adequate room for future expansion.

When configuring PLC Memory registers, the following guidelines shall be followed:-

Within the programming software, the register name and description shall be in accordance with Shoalhaven Water naming conventions.

In addition, the register length parameter shall be adjusted as required in order to ensure that register sequences associated with timers, PID blocks etc. are clearly defined.

Register assignment shall be organised in the same hierarchy as used for program structure. As such, blocks of registers shall be assigned to each system to be controlled. The block assigned shall include adequate spares to allow for program modification without requiring additional registers to be assigned.

10. Field I/O Configuration

Conventional Analog I/O

‒ If applicable, field equipment shall be calibrated for 4-20mA

‒ PLC I/O blocks shall be configured as 4-20mA



‒ PLC / SCADA Logic shall recognise <4mA as “BAD” Data / Device Offline and shall adjust relevant functionality accordingly.

Field Communication I/O

‒ In situations where information is either not available, or the device indicates that the information may be questionable, the “0” value shall be transferred to the associated register; and PLC / SCADA Logic shall recognise the data provided as indicating “BAD” Data / Device Offline and adjust the relevant functionality accordingly.

A sample PLC logic construction is attached in Appendix A. The intent of this sample is to guide the System Integrator-supplied PLC software design such that it aligns with the flow of logic currently applied within the Principal’s installed PLC systems.

3.3.4 User Function Block ProgrammingThe use of function blocks (FB) shall be restricted to a function block per function, i.e. for operating a pump, a valve etc.

Details such as statistics should be provided via a separate FB.

Embedded Omron FBs are allowed to be included in a user FB, but no user FBs are to be used embedded within other user FBs.

FBs shall be interconnected for the control of a whole section. FBs shall be used for repetitive functions, not for single instance of program code. FBs shall be annotated with clear functional descriptions.

In the case of a particular treatment process which involves sequential or stepped operation or definitive steps in the treatment process which can be tracked for improved trouble-shooting, the FB shall be designed such that each step in the sequence can be tracked or can be clearly indicated on the user interface.



3.3.5 Examples of unacceptable User Function Blocks Due to the inclusion in part of statistics in the control FB, the following figure illustrates unacceptable design of user FB.

Figure 3 Example 1 of unacceptable user FB (Motor)



Figure 4 Example 2 of unacceptable user FB (Valve)



Figure 5 Example 3 of unacceptable user FB



3.3.6 Example of acceptable user FBFigure 6 Acceptable user FB

3.4 Structure of Program FoldersPanel drawings, instrumentation and control drawings, “Plain English” documentation on control philosophies and related information shall be incorporated as MS Word® in the application folder as part of the PLC program documentation. The System Integrator shall provide and allow the Principal access to these folders via an approved, secure method (e.g. “LargeFile Transfer”), and under strict version control.

The programs in multiple PLCs shall be organised in a logical structure as illustrated in Figure 1.



Figure 7 General Layout and Organisation of PLC Programs



3.5 PLC Tag NamingThe convention for PLC tag naming shall use the ‘Camelcase’ method which is a method of expressing programming labels with words or abbreviation that begin with a capital letter.

This convention is illustrated as follows:

AreaSectionEquipmentFunction

Where examples of Area, Section, Equipment and Function are as follows:

Area:

‒ EAT

‒ Effluentps OR EffluentPS

‒ Inletworks

‒ Stormreturn

Section

‒ General

‒ Inletflow

‒ Eatdrives

‒ Gritremoval

Equipment

‒ Motor

‒ Valve

‒ Belt

‒ Rake

Function

‒ Command Functions

RunCmd

OpenCmd

StopCmd

CloseCmd

ResetCmd

AckFaultAlarmCmd

‒ Status Functions

Switches [physical or virtual]

ModeAutoSW

ModeManSW

PushButtons [physical or virtual]

StartPB

StopPB



Mode

ModeAuto

ModeMan

PLC Input [physical or virtual bit]

Running

Stopped

FaultAlarm

Opened

Closed

Notwithstanding the above naming method, PLC register/discrete points and SCADA tag name descriptors shall be kept as simple and as readily understandable as possible and be consistent throughout the program. Specific pieces of equipment or instrumentation shall be referenced by using Shoalhaven Water Standard device identifiers.

3.6 Alarms

3.6.1 General PrinciplesThis section describes guidelines on the alarms to be configured for the control system. Specific examples are described here. Not all alarms are listed as the requirements of each process, plant or pump station are subject to detailed design.

Uniformly applied principles of alarming will help operators respond appropriately to abnormal situations.

Operators shall be able to view all alarm conditions throughout the system from any ViewX client.

Operationally, operations staff will review the alarm summary display at the start of the working day and deal with all displayed alarms before commencing other duties at the plant. Priority alarms shall be triggered as SMS alarms as operators will normally be performing other tasks and will not be constantly monitoring ViewX client. As such, all conditions that require operator response before the end of the working day shall be alerted via SMS.

Alarms that are disabled shall be shown highlighted in purple background.

3.6.2 Alarm PrioritisationPriority

Priority shall be based upon how quickly operator attention is required in order to address the problems in accordance with the following guidelines:

Priority 1 alarms require immediate operator attention.

Priority 2 alarms require operator attention as soon as convenient (typically 30 to 90 minutes).

Priority 3 alarms provide operational status information and do not require operator intervention.

Events do not require operator attention.



Priority Assignment Guidelines

Alarms shall be assigned priority in a consistent manner across all plants in order to provide consistent (and therefore safe) experience for operators who are typically assigned to operate different processes.

For new alarm points, software developers shall assign preliminary priorities based upon the examples in the following table. These preliminary priorities shall then be discussed and approved by the Principal prior to commissioning.

Alarm Priority examples

1. Example of Priority 1

‒ Critical water quality condition

‒ Pump fail and its standby unit could not be started up

‒ Chlorine leak

‒ Chemical spill (ferric chloride, sodium hypo-chlorite)

‒ Combustible gas (methane, natural gas) concentration high

‒ Toxic gas concentration high

‒ Flood

‒ High wet well level

‒ Process controller failure


‒ Pump fail and its standby unit was started successfully

‒ Historical logging failure

‒ Failure of auxiliary systems (compressed air, lubrication system, heating, cooling, ventilation system, backup instrument power) Instrument failure

‒ Dissolved oxygen concentration low


‒ Device switched out of Auto Mode

3.6.3 Alarm Monitoring ConceptsGenerally

The alarm monitoring practice at Shoalhaven Water is to bring into the SCADA system sufficient alarm details as needed for remote diagnosis of problems. The alarm and related information shall enable appropriate responses to be taken. The number of alarms from a particular device or facility shall be reviewed on a case-by-case basis with Shoalhaven Water.

Abnormal status of all auxiliary systems that are essential to the functioning of the control system and/or process equipment (e.g. instrument air supply pressure) shall be alarmed.

Additional details shall be included in Priority 1 alarm descriptions in order to allow appropriate action to be quickly taken.



Alarms from I/O

The inputs for each drive, valve or penstock which are status or fault indication shall be configured as alarms or status on the SCADA system. Such inputs shall include:

Available

Running

Fault

Seal Fail (as applicable)

Other alarms configured directly from the PLC inputs shall include those from switched instruments such as level, pressure and flow switches.

Derived Alarms

Derived alarms are those which shall be generated within the FB for the drive or valve. In addition to being alarms, these signals shall be used in the graphical pages for status indication. Table 4 summarises typical derived alarms. The actual configuration and definition of alarms may vary depending on the actual design of motor starters and the process itself. This table is intended to illustrate the intent of providing for derived alarms so as to facilitate diagnostics of equipment or plant alarm and failure events.

Table 4 Typical Derived Alarms

Item Description Derived from

1 Drive not available Manually operated switches and pushbuttons which have been activated to prevent a drive from being operated by the PLC (eg. isolator opened, emergency lockstop operated, auto/manual selector switch in manual position).

2 Drive fault Protective starter devices such thermal overload, thermistor relay tripped, overtorque on valve actuators which have tripped the motor.

3 Drive failed to start1 From a comparison between the request to start signal from the logic and the energisation of the contactor feedback. Used to pick up wiring and other abnormal faults

4 Drive failed to stop1 From a comparison between the request to stop signal from the logic and the deenergisation of the contactor feedback. Used to pick up wiring and other abnormal faults.

5 Valve failed to open1

From a comparison between the request to open signal form the logic and the ‘opened’ position feedback from the valve limit switch.

6 Valve failed to close1

From a comparison between the request to close signal from the logic and the ‘closed’ position feedback from the valve limit switch.



1The ‘failed to start/stop’ and ‘failed to open/close’ alarms shall be latched within the logic until an operator acknowledgment is initiated from the SCADA workstation.

In addition to all of the above flags which are related to faults and alarm conditions within the physical starter, other alarms shall be generated as necessary, including but not limited to:

No Flow DetectedApplicable to pumps and triggered when the reflux valve limit switch is not activated after a set period or by flow switch

Analog Instrument Alarm PointsApplicable to analog readings which are required to be processed by the PLC logic to determine out-of-operating-range values

3.6.4 SMS RequirementsThe SMS alarming feature shall provide full alphanumeric SMS text such that operators are provided with the full text message for each alarm condition.

SMS text alarm messages shall be assigned to specific operational areas or functions to support automatic dialling upon the occurrence of alarm conditions. A specific staff member will be assigned the mobile for a given period. In this way, the responsibility for responding to alarms is easily understood i.e. the individual who holds the mobile that receives the SMS alarm messages is responsible for responding to the received alarms.

If a SMS is not acknowledged within a set time, the SMS system shall forward the SMS text to the supervisor.

The SMS system shall support access by mobile both for acknowledgement and review of alarm conditions.



4. SCADA Guidelines

4.1 General Application Framework

1. The programming of the SCADA software is object oriented in that each device or system is represented as an object containing all relevant attributes. The attributes represent device conditions such as statuses and faults, as well as control points, such as start and stop commands. These attributes are associated with registers in the PLC.

2. Base object templates define device types such as a pump or valve, and additional templates can be derived from these base templates to incorporate attributes that are not part of the base template. Many field devices of the same type contain the same attributes and template objects allow a library of device types to be created that represent all field devices. Any modifications made to base templates or any parent template is propagated to all derived templates.

3. Manufacturers’ templates shall be used in preference to any other source.

4. Each instance of a device is derived from an object template and immediately provides attributes associated with the device.

4.2 Specific GuidelinesThe SCADA software shall be configured in accordance with, but not limited to the following guidelines:

1. The following SCADA real-time attributes shall be developed.

‒ Discrete inputs are required for every available point of digital information available over the network (both from the PLC and from devices directly connected to the network).

‒ Discrete outputs are required for field resets, and discrete device commands.

‒ Analog inputs are required for every analog parameter available from the field.

‒ Analog outputs are required for every process setpoint and every process limit that the operator can change from the displays.

2. As the PLC scales all connected analog values, Raw to EU scaling for these values is 1:1. Analog information provided directly from field devices shall be scaled at the device level.

3. SCADA object and attribute names shall consist of the field I/O descriptor with the addition of the standardised tagname suffix. The naming convention for these names shall be as described under the PLC Tag Naming section of this document.

4. All comment fields, item descriptions, etc. available within the SCADA software to generate documentation of the application, shall be completed in as meaningful a manner as possible.

5. Scripts shall be kept as simple as possible and performing only a single task. Comments shall be included in the script that clearly defines the logic for transitions between sequence steps. Logical sequences shall be subdivided into well-defined series of simple steps with each step commented.

6. Where the same logical task is to be performed on multiple subroutines, call blocks shall be developed and used to avoid duplication of similar logic.



7. Under no circumstance shall SCADA scripts be used in such a way that the loss of PLC communications will hamper the ability for the PLC to safely control processes.

8. Objects such as bar charts and real time trends shall be configured such that associated attributes (max value, min value, units and time base) can be adjusted from an analog object control screen so periodic (e.g. seasonal) changes can be made to ensure that ranges are suitable for current operating conditions.

9. SCADA Points:

‒ History: All points, analog and digital, shall have history enabled where appropriate to track process and process changes

‒ Instrumentation: All monitored instrumentation shall have analog, and where, appropriate pulse values.

For example:

(1) pH probe would have an analog point

(2) flow meter would have an analog point and a pulse point

‒ Analog Points [ unless otherwise determined ]:

(1) Deadband of analog values should be set to 10% of normal range

(2) Resolution of displayed values

Range Resolution

0-1 0.000

1-999 000.00

1000+ 0000

‒ Digital Points: Where a digital point is used to indicate a pump running, and it is known what the flow value is, such a digital point shall have a parameter that can be edited to set that flow value. The combination of the time the digital point is active and the flow value for that point shall be used to calculate flows.

10. SafeGuards for EPA:

‒ Alarms will be raised for any measurements that become widely divergent, for example, the inflow flow measurement, analog [area under curve] and pulse [accumulated total], shall be within a set value of each other.



4.3 SCADA Displays

4.3.1 General Development GuidelinesIntroduction

SCADA displays shall provide the operator with plant-wide monitoring, control, alarming and access to historical data (historical trending) both of the overall process, individual processes and of each piece of equipment that is involved with the process. Plain English prompts and commands shall be used for system/operator communications. The “look and feel” of all SCADA displays across Shoalhaven Water’s assets shall be consistent.

The requirements described in this section are intended to provide a framework to ensure consistency across applications.

The following details applicable to screen development are contained in other Shoalhaven Water Standards available from the Principal.

1. Colours for piping and chemical systems

2. Colours for display of dynamic information

3. Colours to differentiate function of dynamic buttons

4. Colours for the differentiation of alarm status

5. Standard symbols to be used for all devices

All dynamic information on screens shall be driven by information acquired from PLCs/ field devices.

It shall not be possible for operators to change the display status of any device except by the actual field state changing of that device. Where the operators are provided with the appropriate privileges to over-ride values (ie maintenance technician level and above) the display shall be highlighted by a colour change to a mustard colour to signify the overridden status.

The operator interface display graphic shall be arranged to display the following sections:

Top Section reserved for screen navigation, Plant Name and Process Area

Centre tile used for specific information

Bottom section reserved for alarm banner

Operating status and/or position of all devices monitored by SCADA shall be displayed by dynamic symbols (i.e. colour, and or shape change as stated).

Devices controlled by the SCADA shall display a text message beside the device indicating field modes as either Local (controlled locally in the field) or Remote (controlled by the PLC) depending upon field switch position.

Colour Conventions

The following describe the key colour conventions.

The figures below illustrate the colours to be applied to drives which shall also be applicable to valves and other equipment.



Figure 8 Colour conventions for SCADA displays

Other colours are explained as follows:

Item Colour

1 Analog Values

1.1 Normal range White on black

1.2 Advisory range Cyan on black

1.3 Alarm range Red on black

1.4 Off-scan or communications failed (last value)

Purple on black

2 Control Modes

2.1 Local Black

2.2 Local Auto Cyan

2.3 Out of Service Yellow

2.4 Auto Blue

2.5 Manual White

3 Miscellaneous

3.1 Equipment outlines (tank, etc.) Dark grey

3.2 Building outlines, etc. Dark grey



3.3 Active buttons Black text, grey background

3.4 Inactive Buttons Dark grey text, grey background

3.5 Screen background Light grey

The following screen designations in the table below shall be created. Note that in some cases the screen designation corresponds to a single screen – in other cases the screen designation

refers to a set of screens.

Screen Designation Description

Main Menu Overview of the entire system or map of the area.

Plant Overview Overview of each Plant providing navigation links to specific processes.

Process Graphic Individual process detail or equipment grouping

Performance Monitor This screen shall provide detailed SPC charting of all the performance monitoring criteria described in the narratives contained in the Process Functional Description documents.

Communication Summary

Schematic showing status of all network devices (PLCs, SCADA Nodes, etc.)

Graphics and tables providing detailed diagnostic information for all communications links within the system

Control Set-points Visualisation of all control set-points, recipe control, and analog display controls

Alarm Set-points Visualisation of all alarm set-points and alarm controlActive Alarms Visualisation of all alarms with scroll bars

Alarm and Event Historian

Access to alarm and event statistics such as frequency and duration. Allows an operator to filter alarms based on alarm groups, priority, etc. Also allows alarms to be searched on specific text strings and allows operators to add comments and hotlink alarms to specific trends.

PDF View View of operations manuals and control manuals

Pop-ups Device settings, Real time trends etc



4.3.2 SCADA Display HierarchyOperator graphic displays shall be organised in the structured hierarchy shown below. All individual mimic pages for the treatment plant processes shall contain links to other pages as follows:

A “return” navigation key/tab to the Treatment Plant Overview Mimic;

“next” and “previous” keys/tabs in a circulatory way through all STP mimics;

Navigation keys/tabs for other process STP mimics which bear relevance to the process shown on that page.

Figure 9 SCADA Display Hierarchy

Process Graphic

Main Menu

System Trends Plant Overview

Reports

Special Process Graphic Process Graphic Process Graphic

Control Setpoint PID

4.3.3 Description of Displays

Main Menu:

entire system graphical overview;

quick “click” panes to dedicated pages or navigation links to the various facility groupings;

consideration of an interactive GIS-based aerial area view for remote stations and aerial view of treatment plant site;

layout shall be in the order of the process flow and interconnecting the various displays that make up the whole process train.

Plant Overview:

Contains navigational links to individual process display screens;

Displays status of:



‒ key analog values;

‒ process:

‒ step;

‒ mode;

‒ dry weather;

‒ wet weather;

‒ storm event

4.3.4 Process Graphics

1. Wherever there is an individual process, such a process shall have its own individual mimic page.

2. Each major plant process shall be displayed with at least one status page, one settings page and one trend page e.g. EAT process.

3. Each minor plant process shall be displayed with at least one individual/allocated control page and at least one trend page e.g. chemical plant.

4. The process steps (where warranted) of the particular process shall be shown on the associated individual mimic to indicate the progress of the steps in that particular process.

5. Displays status of:

‒ key analog values

‒ process

a) Step

b) Detailed overviews of all equipment and process data monitored within an area of the plant, an example being clarifiers and aeration, which, in addition to depicting the status of equipment, links are provided to the control popup windows.

6. Mimics shall be provided with an operator note pad facility that has the following features:

‒ “pop-up” operator notes (tabulated)

‒ indication of note being present, when updated and by who

‒ indication of note having been updated and not yet read

Miscellaneous display details

Overview screens, process piping on the screen shall be restricted to that which is critical to controlling the operation of the system and to understanding the process being shown.

Individual process graphic screens shall show all process piping and control devices applicable.

Dashboard faceplate hyperlinks shall be used to link each device to its control display.

Control displays shall consist of popup windows, which shall be easily viewed on screen, providing control for specific devices.

Guidelines for device control shall comply with the following:



Entry/Control interaction can be achieved without keyboard;

Operator input fields shall support graphical data entry (e.g. pick boxes, scroll bars, radio buttons, etc.);

Value boundaries (Maximum and minimum) shall be defined for all analog set-point inputs to ensure ‘correct’ data entry restricting operators to only entering values between these limits;

For critical equipment, the control action shall call another small “popup” display that will require the operator to verify that the control action is desired.

The operator shall set equipment to manual or automatic mode from the control displays. Equipment must be in automatic in order for the PLC to automatically start/stop, open/close, adjust speed, or otherwise adjust equipment operation without operator intervention.

Device control “pop-up” windows/faceplates shall be available for all applicable equipment and shall display, as a minimum, but not limited to the following information.

‒ Status;

‒ Mode;

‒ Number of running hours;

‒ Number of cycles (start/stop, open/close);

‒ Standard alarms and alarm state;

‒ Settings (setpoints, speed, levels, flow, etc);

‒ Power quality information (e.g. current, power factor, kWh, etc).

Devices such as PID controllers are considered a special case of a control “popup” window. The ability to adjust PID parameters shall be restricted to those with the appropriate privileges (i.e. maintenance technician and above).

The setpoint graphic display shall provide a single location for operators to view and adjust all setpoints and control modes necessary to operate the automatic control of the area.

The setpoint display shall be called from the individual Process Graphic by clicking on a screen button assigned specifically for this purpose.

Plant performance graphic displays all key performance indicators using standard Statistical Process Control (SPC) charts. Charts shall be configured to display, as a minimum and not limited to:

‒ performance indicators;

‒ upper and lower control limits.

Trends

1. Historic trends shall display a graphical representation of process variables.

2. The default time span shall be the last 24hrs with ability to select present time spans to today, yesterday, this week, last week.

3. When the trend graphic is called from the process area graphic, the screen shall automatically display the most common set of pre-configured trend points.

4. When called from the main menu, the trend graphic shall provide a “quick” selection to pre-configured plant trend points.



5. There shall also be the option to open an empty trend window ready for the operator to create a custom trend, and be able to save in document store, either globally or locally (personally).

4.4 Alarm/Event Management

4.4.1 General GuidelinesThe alarm and event management system forms a significant component of the SCADA system.

The primary ClearSCADA server for each location is always defined as the primary alarm provider for the location. When the server is offline, each system will switch to a redundant hot standby server.

In addition to the typical process, equipment and plant alarms, alarms shall also be configured for the following system-related conditions:

Low system resources alarm;

CPU loading;

Hard drive free space;

Permanent Standby offline alarm [ICM derived];

Communication status alarm for communication links;

SCADA Network Faults;

The following PLC Faults;

‒ Real time clock not synchronized;

‒ Rack faults;

‒ Low battery;

‒ Loss of communication;

‒ I/O Faults (e.g. serial communication error).

4.4.2 Alarm GraphicsThe alarm summary graphic provides:

a listing of all recent alarms reported to the SCADA workstation as presented on the alarm banner;

access to all additional alarm history and summary information.

The alarm banner shall:

display a list of the most current alarms, as designated in ClearSCADA;

be filterable to process areas;

be displayed at the bottom of the operator interface;

comply with the ClearSCADA standard;

display the most recent active unacknowledged alarms at the top of the alarm banner;

indicate the date, time and description of the alarm condition.



4.4.3 Alarm CategorisationAlarms shall be divided into the following logical alarm groups and subgroups and by facility.

Critical Alarms: Triggered by conditions where events have the potential to result in damage to persons, environment, property or equipment without immediate intervention. Critical alarms shall result in a pop-up window being displayed describing the alarm condition and the significance of the alarm.

Class 1 – PLC Driven: The operator must acknowledge these alarms. As these alarms function independent of SCADA, it shall be possible to acknowledge these alarms by local PLC-connected reset buttons in addition to acknowledgement via SCADA. These alarms shall remain in Alarm State in the PLC until acknowledged at the SCADA level.

Class 2 – SCADA Driven: Similar to Class 1 alarms but are not relevant when the SCADA is offline. The SCADA software, independently of the PLC, manages these alarms.

Informational Warning Alarms: These alarms do not require immediate operator intervention but shall indicate to the operator the status of the plant/individual process when it is in variance from optimal operation.

Events (Information Only): Events shall record useful information about the normal operation of the system (e.g. sequence of a filter backwash). Events do not appear on the alarm banner. Events are subdivided into the following categories:

‒ Compliance - Records information associated with Health and Safety requirements;

‒ Environmental – Records issues associated with the site EPA operating license;

‒ Operator Actions – Records relevant operational changes such as operator changes to set points.

‒ Operational – Records all other events.

4.4.4 Alarm Conditioning and DiscriminationWhere PLC based alarm conditions are used for interlocks and/or to drive alarm sirens connected at the PLC level the alarm registers to be monitored by the SCADA system for alarm status shall be the same as the registers used by the PLC for the related control functions.

Alarms which may be falsely triggered due to communication failures or signal transients, shall be time delayed to allow an opportunity for communication to be re-established, or transients to subside. The individual time delay periods shall be adjustable.

Should communication problems result in total communication failure to a field controller, all site alarms associated with the specific controller shall be disabled and a single specific controller critical communication failure alarm generated.

4.4.5 SCADA Alarm ConfigurationAlarms originating from field contacts or generated by software shall be displayed at local operator HMIs (if present) and the main ClearSCADA screen. The following table shows configuration by alarm priority.

Priority Pop-up Window

Computer Audible

SMS Securenet Relay #

Alarm Summary

Alarm /Event Filter

On Graphics



1 Yes Yes Yes Yes - Yes2 - - Yes Yes Yes Yes3 - - - Yes Yes YesEvent - - - - Yes Yes

Notes:

SMS and alarm acknowledgements shall be restricted to only authorised individuals.

Critical alarms:

‒ SMS out and Securenet Relay activation during out of work hours.

‒ Pop-up window fills about a quarter of the display screen and contains the alarm description, date and time of occurrence and the current status.

‒ The window shall also list response actions or else provide a button to select response directions and “help” information.

4.5 SecurityIn general, security is managed via Windows Authentication, and standard user templates for privileges.

The following user levels are applied at Shoalhaven Water:

1. Administrator

‒ Level 3 privileges plus global access and ability to configure ClearSCADA database;

2. Level 3 [e.g. technician]

‒ Level 2 privileges plus access to varying settings for controlling/fine-tuning the process such as control loop tuning parameters (e.g. proportional, integral and derivative) and other fixed or “hard-coded” settings;

3. Level 2 [e.g. supervisor]

‒ Level 1 privileges plus access to setting process values (setpoints, cut-in/cut-out levels, alarm thresholds) but not control loop parameters;

4. Level 1 [e.g. operator]

‒ Acknowledge and disable alarms, select modes of operation, start processes, query and interrogate plant;

5. Guest

‒ View only of all data and screens;

Other security features shall be as follows:

1. If a ViewX session is not used for a pre-specified period of time [30 mins], the current user shall be automatically logged out.

2. Users shall be able to log onto any SCADA control computer on the network and have the ability to perform those tasks for which they have been granted privileges.

3. If an individual does not have a valid Shoalhaven Water user account, they can navigate the GUI but no action is allowable other than viewing. For the purposes of this document, this level of security will be referred to as “Guest”.



4. If an individual logs in attempts to perform an activity that they do not have sufficient rights to perform, a pop-up message shall be posted indicating the level of security they are currently logged in with and the level of security required in order to perform the activity.

4.6 Historian Functionality

4.6.1 GeneralThe Historian function is part of the ClearSCADA software and as such shall be configured to manage all historical data (alarms, events, trends, SPC data, etc.). Individual ClearSCADA servers are configured to back up to the one central server hosting multiple concurrent permanent standby servers. This server is known as CS-Standby.

The primary Historian located at Flinders Water Depot is configured as a permanent DMZ redundant configuration based on Schneider Electric ClearSCADA server technology.

4.6.2 TrendsThe Historian function shall manage historical trend information.

4.6.3 Operational ReportsThe following outlines the historical report generation requirements to be provided:

a) Reporting requirements shall be as a minimum and not limited to:

‒ Monthly filter summary;

‒ Annual filter summary;

‒ Monthly equipment runtime;

‒ Annual equipment run-time;

‒ Monthly chemical usage;

‒ Annual chemical usage;

‒ Monthly operational;

‒ Annual operations;

‒ Analytical summary;

‒ EPA compliance reports.

b) A data verification process shall be provided to verify information collected by the SCADA system for the purpose of exception reporting.

4.6.4 Historical Alarm and Event LogThe Historian function shall manage all historical alarms and events.

The following outlines the primary functional requirements:

a) On alarm becoming ACTIVE, an alarm record shall be generated. This record shall track the time of occurrence, time of acknowledgment, and name of the user who acknowledged the alarm.

b) Operators shall be able to filter alarms and events with an operator definable filters including specific text string occurrence, date and time, priority, alarm group, etc.



c) Once a specific alarm is identified, the operator shall be able to add comments to the alarm.

d) Historical alarms shall be logged on the CS Historian servers at Flinders, which provides for long term historical alarm management.

4.6.5 Other FunctionalityThe following statistical process control (SPC) functionality shall be incorporated.

a) Process performance indicators shall be tracked within the SPC system with appropriate control limits set such that operators are able to identify and rectify operational inefficiencies.

b) Where statistics derived alarms such as rate of change and degree of deviation alarms are required, these alarms shall be generated by the SCADA SPC component to ensure that they are properly calculated.

The following additional functions shall be performed as part of the Historian functionality:

a) Where deemed applicable by the Principal, stored recipes shall be used to manage SCADA control system settings and setpoints (e.g. adjustable alarm levels) such that the information is readily accessible via ViewX clients. Examples may be settings required to change from dry weather (default) to wet weather or storm events etc

b) PLC backup (to allow information to be restored from the SCADA system to the PLCs upon PLC failure):

‒ PLC totalisers;

‒ settings and setpoints (e.g. adjustable alarm levels, runtimes, etc.).

4.7 SMS Alarms and SecurenetThe following information provides details on how the SMS alarm system shall function.

a) SMS alarms shall be triggered based on the HIHI and LOLO alarm limits set within SCADA ViewX.

b) Alarms shall be grouped and all alarms within a group shall be transmitted by SMS to a specific list of individuals. The individuals within this prescribed list shall be the only individuals who will be able to acknowledge the alarms that are assigned to this group.

c) When an individual ‘dials’ into the system, they shall be required to acknowledge each alarm individually or as a group and shall be able to check the current values for key operating parameters such as certain control levels.

d) The SMS features shall include the ability to acknowledge alarms by sending an SMS to the CS Server directly with a code provided as part of the page.

e) If an alarm is acknowledged at a ViewX client, the SMS alarm shall abort.

4.8 Example ScreensThe following figures indicate the screens in use at the Principal’s plants. It must be noted that these figures are included to demonstrate the general layout and arrangement of the graphic elements only. The “look and feel” (e.g fonts, line thicknesses, etc) is based on an outdated SCADA software version and is not to be relied upon.



Figure 10 Opening Screen



Figure 11 Alum Dosing



Figure 12 Drive Summary



Figure 13 EAT Status



Figure 14 Lime Dosing



Figure 15 Effluent Reuse and Ferric Chloride



Figure 16 Flow Statistics



Figure 17 Grit Removal System



Figure 18 PLC and PC Network



Figure 19 Storm Return Pump Station



Figure 20 Plant Overview



Figure 21 PLC Clock Setting



Figure 22 Power Supply Monitoring and Area Lighting



Figure 23 Screenings System



Figure 24 Supernatant Station

Figure 25 Sample of Setup Screens





Figure 26 Sample of Pop-Ups

4.9 Suggested ClearSCADA Database StructureThe figure below illustrates the database structure established by the Principal. The System Integrator shall refer to the latest version of the following Configuration Manuals for further details of the required structure. These manuals will be supplied by the Principal upon request.

SCADAPack 334e Configuration

Shoalhaven City Council ClearSCADA Upgrade – Advanced Configuration Manual

The System Integrator will also be provided with the following to ensure that configuration is in accordance with current templates and to ensure clear understanding of the required structure and configuration details:

ClearSCADA Templates

An export of the ClearSCADA Application for Nowra / Bomaderry

SCADAPack IsaGraph information



Figure 27 ClearSCADA Database Structure



5. SCADA and PLC Works - Testing and Commissioning

5.1 GeneralThe following sections indicate the typical processes for the testing and commissioning of major PLC, SCADA and RTU works. The actual process(es) to be followed for each project will be subject to the complexity of the scope and nature of the works. These sections are intended to provide guidelines for establishing a structured approach, plans and procedures for testing and commissioning.

5.2 Testing and Commissioning PlanA “Testing and Commissioning” plan shall be developed for all works testing and commissioning. The plan shall allow sufficient time for testing (including Pre-FAT), and if necessary re-testing of equipment and fit in with the overall project completion time. The plan shall take into consideration the experience obtained from previous sites of a similar type and complexity.

The plan shall show:

commencement and completion date and times and the number of personnel present for the pre-FAT and FAT;

the number of commissioning staff associated with each aspect of testing and commissioning;

format, template or sample of each test result sheet proposed to be used during the testing and commissioning process;

software configuration change management procedures and sample of change management record sheet.

Before undertaking commissioning of the plant, all test instruments shall be calibrated by a NATA approved test authority within two (2) months of actual site usage. Test certificates shall be submitted to the Principal before commissioning commences.

5.3 Summary of Testing and Commissioning Process for Major PLC, SCADA and RTU WorksTesting and commissioning of major works related to control systems shall be carried in the following order:

The System Integrator provides updated functional specifications, software, and Operations and Maintenance Manuals, and “Testing and Commissioning” plans for the FAT and SAT of the control system(s);

System Integrator completes all Pre-FATs requirements and at the same time completes the “Pre-FAT Test Results Record Sheets”;

System Integrator submits the completed “Pre-FAT Test Results Record Sheets” to the Principal for review;

System Integrator completes FAT and submits the completed “FAT Test Results Record Sheets” to the Principal. The Principal will also be required to witness the FAT;

Provided the Principal has accepted the FAT results and approved delivery of the software (and hardware if supplied by System Integrator), the System Integrator installs the hardware and software on site;



The System Integrator provides written notification to the Principal of the proposed commencement of a pre-SAT or a SAT;

The System Integrator meets with the Principal at least one week prior to a scheduled SAT. This meeting will discuss the proposed commissioning methodology and any issues arising out of the preparatory work for SAT;

System Integrator completes all Pre-SATs and the “Pre SAT Test Results Record Sheets” and submits the “Pre-SAT Test Results Record Sheets”. The Principal will witness the Pre-SAT. The Principal will advise the System Integrator of the acceptance or otherwise of the Pre-SAT results;

System Integrator provides all relevant information and confirms date for the SAT;

System Integrator completes all SAT. The Principal will witness the SAT. The System Integrator submits the “SAT Test Results Record Sheets”. The Principal will advise the System Integrator of the acceptance or otherwise of the SAT results;

Operator training; and

Handover, after submission of test results, final Operations Maintenance Manual (OMM), Work-As-Executed software and software documentation, any other supporting documentation and operator training material.

5.4 Test Results SheetsTest sheets are to be prepared by the System Integrator and forwarded to the Principal for approval one month before any testing is to be carried out.

Test sheets to be provided before testing are:

Pre-Factory Acceptance Test (Pre-FAT) Results Record Sheets;

Factory Acceptance Test (FAT) Results Record Sheets;

Pre-Site Acceptance Test (Pre-SAT) Results Record Sheets;

Site Acceptance Test (SAT) Results Record Sheets;

Software configuration Change Management Record Sheets;

Typically, the test results sheets will include, but not be limited to the following:

Test title e.g. Aeration Sequence Operation;

Purpose of test: e.g. prove PLC control of the aeration sequence, operation of interlocks;

Test conditions or configuration: e.g. Dissolved oxygen variables simulated by entering a set value into PLC;

Description of each test in sequential order;

Expected result on SCADA display e.g. aerator drive status correctly displayed;

Acceptance criteria;

Duration of test e.g. 1 minute for soft starter ramp up;

Comments;

Pass or Fail; and

Sign off by tester, another witness from the System Integrator’s organisation and the Principal.



Typically, separate sheets shall be provided for:-

FAT/SAT visual check;

SAT system configuration completeness check;

FAT/SAT Instrument Calibration (where relevant to the scope);

SAT functional check;

FAT/SAT System Test;

FAT/SAT documentation check.

5.5 Factory Acceptance Testing

5.5.1 IntroductionTesting for the control system shall consist of two formal tests. A Pre-Factory Acceptance Test (Pre-FAT) and a Factory Acceptance Test (FAT). The FAT will be witnessed by the Principal. The Pre-FAT will be witnessed at the Principal’s discretion.

The Principal shall have the right to witness any tests and inspect any equipment or the software development process at any stage of the Contract to confirm progress and conformance. This may involve re-testing if considered warranted by the Principal. This shall not relieve the System Integrator of any responsibility to ensure the proper operation of any works under their scope.

Detailed testing procedures, commissioning procedures and check sheets are to be prepared and provided to the Principal one month prior to testing. These sheets must be completed during testing and test data submitted for approval. These sheets shall be a site specific document providing a formal comprehensive testing procedure and test record. The test sheets will be checked during formal testing and during various audits by the Principal. Any testing or recording inaccuracies must be recorded and measures put in place to prevent re-occurrence.

5.5.2 ResourcesAll testing shall be accompanied by the necessary labour, materials and test equipment required for testing, including a complete set of spare equipment for any minor items, such as current injection units, relays, lamps, etc for simulation of field signals prior to site testing, so that the testing process is not delayed due to the failure of such items.

All test equipment shall have been checked for calibration prior to tests. Calibration documentation shall be made available

5.6 Pre-Factory Acceptance TestingA Pre-FAT is shall be carried out when:

Manufacturing is complete;

Software is fully configured and the system or sub-system is fully assembled;

The control system is ready for transportation to site; and

Calibration sheets (where required) are complete and available.

The Pre-FAT and FAT shall be carried out at the manufacturer’s works when software development and other works are complete.



The Pre-FAT shall be carried out prior to a FAT. This is intended to check the scope of work and minimise the amount of time required to complete the FAT by eliminating wiring, labelling, workmanship, equipment functionality and software configuration problems. Some Pre-FATs may be repeated during the FAT to verify correctness of the results.

The Principal will not normally witness the Pre-FAT, however, he shall have the right to do so.

The “Pre-FAT Test Result Record Sheets” shall be supplied by the System Integrator and shall detail all tests required during Pre-FAT.

Two (2) copies of the “Pre-FAT Test Results Record Sheets” shall be submitted at the start of the FAT for approval with the “FAT Test Results Record Sheets”. Each test shall be dated and signed off by two representative of the System Integrator.

The Pre-FATs shall itemise and cover all tests associated with the following:

Completeness of work to relevant standards and workmanship;

Correctness of database entries, software configuration details and settings;

Simulated functional operations of logic, etc.

5.7 Factory Acceptance TestingA FAT shall be carried out when:

All Pre-FATS have been successful/completed;

Operation and maintenance manuals are complete;

An updated set of all documentation is available;

The “Pre-FAT Test Results Record Sheets” are completed;

The FAT shall be carried out at the manufacturer’s works;

At least one (1) weeks’ notice shall be given of a proposed FAT;

Complete all tests detailed on the “FAT Test Result Record Sheets” during the FAT. Each test shall be dated and signed off by the System Integrator;

The FAT shall be a full simulated test of all PLC/RTU logic and SCADA display states. Where practical, external equipment shall be connected to simulate actual field devices, e.g. switches, signal generators, etc. The FAT shall cover as much of the hardwired operational system of the site as possible;

The Principal will witness the FAT;

If requested by the Principal, some Pre-FAT results may be re-tested to verify the results of the Pre-FAT;

Any drawing changes resulting from the FAT shall be recorded and incorporated into the next drawing issue;

Two (2) copies of the “Pre-FAT Test Results Record Sheets” and “FAT Test Results Record Sheets” shall be submitted for approval at the conclusion of the FAT;

During the FAT the Principal may issue Non Conformance Reports. These will indicate that equipment or the procedure does not conform to the Specification. In this case, the system shall be modified and re-tested. This process shall be repeated until the test is successful. It will be up to the Principal to determine whether re-testing can be carried



out as part of the current FAT or re-scheduled to another date. The System Integrator shall sign all NCRs;

At the conclusion of the FAT, after all NCRs are cleared and approval is given by the Principal, then the equipment can be delivered to site.

5.8 Site Acceptance Testing

5.8.1 Pre-Site Acceptance Testing (Pre-SAT) A Pre-SAT shall be carried out when:

‒ All preparation work and notifications are complete;

‒ All software documentation has been provided and is available on site;

Calibration sheets are complete and are available on site;

The Pre-SAT is intended to minimise the amount of time required to complete the SAT by checking the scope of works and preliminary testing of software configuration and SCADA interfaces, thus minimising the risk of software or configuration issues on site;

At least two (2) weeks’ notice to all parties shall be required for a proposed Pre-SAT. The Pre-Sat will be witnessed by the Principal;

The “Pre-SAT Test Result Record Sheets” shall detail all checks and tests required during Pre-SAT. These sheets shall be completed during Pre-SAT and submitted to the Principal at the completion of the Pre-SAT for approval. Each test shall be dated and signed off by the System Integrator, System Integrator’s witness and the Principal;

Two (2) copies of the completed “Pre-SAT Test Results Record Sheets” shall be submitted at the conclusion of the Pre-SAT;

The Pre-SATs shall itemise and cover all tests associated with the following:

‒ Completeness of configuration work to relevant standards;

‒ Accuracy of drawings;

‒ Labelling and setting checks;

‒ Check that FAT test results match the site data sheets;

‒ Functional test of the configured logic and software;

‒ Testing new field devices and instruments that can be installed and connected without affecting the operation of the existing equipment;

‒ Check for damaged or marked equipment; and

‒ Check software settings and parameters against commissioning data sheets.

5.8.2 Site Acceptance Testing A SAT shall be carried out as soon as possible after successful completion of the Pre-

SAT and when:

‒ All possible Scopes of Works are completed;

‒ No outstanding major NCRs at the discretion of the Principal;

‒ All parties have been notified and are ready;



‒ All documentation is available for viewing on site including latest software documentation, software configuration management plans, data sheets, test sheets, site access, contingency plan, etc;

‒ Operation and maintenance manuals are complete;

‒ An updated set of all software documentation is available;

‒ The “Pre-SAT test results record sheets” are completed and approved;

‒ There is a period of dry weather if testing is required to be outdoors. SATs are to be cancelled if unexpected wet weather affect the ability to conduct the testing; and

‒ Approval has been given to carry out the SAT by the Principal.

At least two (2) weeks’ notice shall be provided for a proposed SAT. This should allow sufficient time to co-ordinate all relevant parties associated with the SAT. It is expected that a SAT notification will be provided at the same time as a Pre-SAT notification;

Before agreeing to a SAT the Principal may visit the site to confirm its readiness;

The Principal will witness the SAT;

Unless the SAT is carried out immediately after the Pre-SAT then prior to the commencement of the changeover, critical components shall be functional, and if required by the Principal, re-test some Pre-SAT results to verify their correctness. If any fault is found, it is up to the Principal to determine whether the SAT can commence or be re-scheduled to another date;

“SAT Test Result Record Sheets” shall be supplied and all tests detailed on the “SAT Test Result Record Sheets” completed, during the SAT. Each test shall be dated and signed off by the System Integrator;

During the SAT the Principal may issue Non Conformance Reports. These will indicate that the software or equipment does not conform to the specification or that the correct procedure has not been followed. The System Integrator shall sign all NCR. The system shall be modified and re-tested if any test is not approved. This process shall be repeated until the test is successful. It will be up to the Principal to determine whether re-testing can be carried out as part of the current SAT or re-scheduled to another date;

No repairs or modifications shall be carried out unless agreed by all parties;

Equipment shall not be put into operation unless all software tests have been completed and approval is obtained from the Principal;

Two (2) copies of the completed “SAT Test Results Record Sheets” shall be signed off and submitted for approval at conclusion of the SAT;

Any drawing changes resulting from the SAT shall be recorded and incorporated into the Work As Executed drawings;

The results of each test shall be recorded immediately after the test is performed;

Any tests postponed from the Pre-SAT for any reason shall be included in the SAT. The implications that this will have on the transition time and the additional risk involved in carrying out these tests during the SAT shall be reported;

The SATs shall itemise and cover all tests associated with the following:

‒ Normal operational tests;

‒ Abnormal operational tests, e.g. mains power failure; and



‒ Decommissioning checks (e.g. temporary “work-around”, software “bridges” etc).

5.9 System TestsThe whole of the engineering services installed under the particular project shall be tested for operation under full load, normal and emergency operations.

Coordination with other third parties shall be required via the Principal’s Authorised Representative to ensure that all systems can be tested simultaneously.



6. Documentation

6.1 Documentation to be submittedDocumentation for electrical, PLC and SCADA works shall comply with the following requirements:

Electrical, instrumentation and control system documentation shall be prepared in accordance with the following standards:

‒ AS 1102 Graphical symbols for electro-technology; and

‒ ISA-S5.4 Instrument Loop Diagram;

Documentation to describe the PLC, SCADA and RTU systems shall include but not be limited to the following:

‒ Drawing register or index;

‒ Telemetry and network schematics (where relevant);

‒ PLC/RTU connection diagram (where relevant to the System Integrator scope of works);

‒ PLC/RTU input and output schematics (where relevant to the System Integrator scope of works);

Cable Schedules listing PLC, RTU and SCADA peripheral cables:

‒ Cable number;

‒ Origin;

‒ Destination;

‒ Type of cable

‒ Size of conductor;

‒ Number of cores; and

‒ Installation details such as cable route.

Equipment layout and cable route drawings and installation details;

Detailed Functional and Software Specification;

A complete and fully annotated PLC Program Listing;

SCADA mimic diagrams in accordance with the Principal’s SCADA standards described in this document and showing general arrangement of both static and dynamic information, supplied in electronic format with supporting software to enable viewing of the mimic diagrams on a computer screen;

Operations and Maintenance Manuals.

6.2 Operations and Maintenance Manuals

6.2.1 GeneralThe System Integrator shall compile comprehensive operating and maintenance manuals for the control systems supplied.



A draft of the proposed manuals, complete with binders and all fully complete, shall be provided for the approval of the Principal’s Authorised Representative not later than 6 weeks prior to the due date for practical completion of the work. Practical completion will not be granted until such time as the Principal’s Authorised Representative provides written approval.

After approval three (3) copies of each volume shall be compiled and supplied to the Principal’s Authorised Representative prior to the issue of the Certificate of Practical Completion. Each volume shall also be provided in an electronic format readable by Microsoft Word and PDF as well as by the PLC and SCADA system software for the PLC and SCADA files respectively.

All diagrams, tables and pages shall be numbered. A comprehensive index is to be included. The text shall be written in clear concise English and easily understood by a trained operator.

6.2.2 ContentsThe Operation and Maintenance manuals shall include a full system description, component data, trouble shooting, spare parts, maintenance procedure schedule and reference drawings and document list. Sub-sections of the manuals shall be logically organised into:

Functional and Software Specification;

PLC Program Listings;

SCADA functions in logical order (e.g. SCADA overview mimic, individual mimic, report generation, trends, alarms, events log);

Printouts of SCADA mimic pages;

Trouble shooting procedures and fault finding recommendations;

Each sub-section shall cover the following details:

List and component data (brochures), where relevant;

Records of PLC settings and parameters (such as protection settings, control loop setpoints, alarm thresholds, timers, etc.);

Maintenance operations and schedules;

Recommendations for adjustments and routine maintenance procedures;

Instructions for dismantling (where applicable); and

Reference drawings.

The manuals shall also include the following:

Test Certificates and Commissioning Reports for all tests including a list of tests to be carried out and shall contain signed test reports and certifications;

All guarantees and warranties on all equipment supplied; and

Work As Executed drawings produced by the System Integrator for approval, final marked-up Work-As-Executed drawings and other relevant drawings not submitted for approval.



Appendix A Sample PLC logic from Shoalhaven Water



Sample structure of PLC logic installed in Shoalhaven Water’s existing PLCs

Modes:

Automatic Mode:

allow process to continually run

Maintenance Mode [or Single Cycle Mode ]:

one complete process sequence

configurable trigger to run at set times/days

Step Mode:

Definable steps of a process sequence (conditional)

Over-ride Step Mode:

Allows for shifting through process sequence without conditional control

‘Pushbutton’ Inputs

Start:

Used to initiate Automatic State or a Single Cycle of Process

Stop:

Used to initiate a controlled stop at end of process sequence in Automatic

Reset:

Attempt to clear a fault to allow process to continue

Step:

Conditional

‒ initiates (when in step mode) one step of process to run, then stop and await a further Step press.

In Over-ride:

ignoring necessary conditions to normally continue, initiates one step of process to run, then stop and await a further Step press.

Switching between States (Modes)

Automatic Mode

Whilst in Automatic:

single cycle selected then the process should continue to end of cycle

Step or Over-ride Step mode selected then the process should stop at end of present process step

Single Cycle Mode

Whilst in Single Cycle Mode

Automatic Mode selected then the process should continue on and go into Automatic

Step or Over-ride Step mode selected then the process should stop at end of present process step



Step Mode

Whilst in Step or Over-ride Step Mode

Automatic Mode selected then the process should wait for Start and then continue on and go into Automatic Mode

single cycle selected await a Start to initiate continuation of the process to end of cycle

Reset

Should clear fault if fault no longer active and allow continuation of cycle, then

await Start Initiate

Sequence Reset

If sequence Reset then operating mode will stay the same, be it Automatic, Maintenance or Step but the sequencing of the process will be returned to ‘SETTLE’

Treatment Works Process Cycles

Where ever there is an individual process, such a process should have its own individual control within the PLC program to allow for the mode selections.

There should only be one set of PLC coding to control each individual process in any automation mode.

Cycles

There will be the following cycles available to select in a 24/7 configurable schedule:

Peak

Off Peak

Storm

Delay Start

Documents

Document Number: D16/38808 Standard for SCADA File: 47662E