Addendum No. 1_354-UT27-17_Combined.pdf

Project No. WT1389/1171 1 RFP 354-UT27-17 Swift Creek Pump Station PLC Improvements – Addendum# 1

DATE:

PROJECT:

ADDENDUM NUMBER 1

October 19, 2026

RFP 354-UT27-17 Swift Creek Pump Station PLC Improvements

TOWN OF CARY JOB No. SW1171/SW1389

OWNER: TOWN OF CARY, NORTH CAROLINA

ENGINEER: Yang Song, PE

TO: All Plan Holders

This Addendum forms a part of the RFP Documents and modifies the Bidding Documents posted October 14, 2026, with amendments and additions noted herein below.

Acknowledge receipt of this Addendum in the proposal. Failure to do so may disqualify the Bidder.

Signature: Date: 10/19/2026

GENERAL CLARIFICATIONS:

A. The attachments for the advertised RFP are now included in this addendum. As noted in RFP section 3.11, the documentation available for review include:

• Attachment 1 - HMI Software Development Standards

• Attachment 2 - PLC Controller Development Standards and Tag names Conventions

• Attachment 3 Swift Creek Pump Station Electrical Improvement Drawings

• Attachment 4 Existing Old Wet Well Pump Control PLC Cabinet Drawings

• Attachment 5 Existing Old Wet Well Pump Valve Control Details and Assembly

-END OF DOCUMENT-

Attachment 1 - HMI Software Development Standards (24 Pages)

Technical Memorandum No. 7 HMI Software Development

Use of contents on this sheet is subject to the limitations specified at the beginning of this document.

P:\Cary\131943 - Western Wake SCADA\TM7 Software Implementation Phase Documentation\Western Wake TM7\TM7.doc

3 . G R A P H I C S O V E R V I E W The graphical HMI and OIT interface will be based on standards prepared specifically for this application in Phase 2 of this project. The interface standards will be consistently applied to development of the interface to insure best usability.

HMI and OIT developments including tag naming scheme, screen navigation methods, use of pop-ups, etc.

should be implemented in a consistent manner. Graphics screen should utilize the same approved standard objects, colors, symbols, fonts, and features to provide an interface to operators that is uniform and consistent for all Owner’s facilities.

3.1 Graphical Display Type

The User Interface is comprised of various types of graphic displays including schematic overview screen, control panel, faceplates, utility displays, and trend displays. The content and layout of each type of interface including navigational and utility features will be defined by the standard. Templates developed in Phase 2.

3.2 Colors

The color standard should define the colors used to indicate dynamics conditions (run, stop, alarm, trouble or fail, ready, etc.), process-specific applications (raw water, settled water, finished water, chemicals, etc.), graphic display backgrounds, dynamic data objects, text, control objects, etc. Some examples are listed below:

Red = Stopped/ Closed Green = Running/Open Yellow = Alarm Condition Blue = Transition State

3.3 Terminology

All terminology used to annotate the graphical interface should be consistent. The terminology includes the following:

Descriptive names used to identify the treatment processes, systems, structures, equipment, process variables, etc.

Units of measurement for all process variables Alarm condition descriptors Abbreviations

4 . H M I A N D O I T D E V E L O P M E N T O V E R V I E W

4.1 Screen Region

The top screen region will be used for the title bar; this will include screen name, time, user and HMI server information. Navigation buttons will be used to access areas, which are not part of the current screen layout;

these can be placed directly below the main screen, or next to areas which do not have graphic components that can be used for navigation to the more detail screens. This will include alarming. The alarm button will be used to notify the user of alarm status and also navigate to the alarm summary screen. The remaining

Use of contents on this sheet is subject to the limitations specified at the beginning of this document.

P:\Cary\131943 - Western Wake SCADA\TM7 Software Implementation Phase Documentation\Western Wake TM7\TM7.doc screen area, apart from navigation and the title bar will be used for site layouts. A default template screen will be developed in Phase 2. The default screen will be used as a template to create new screens. This will help keep the screen properties that same throughout the application.

4.2 Development Guidelines

The graphical operator interface should be developed in accordance with recognized usability practices, listed below, to insure efficient and effective use of the process control system. The completed graphical operator interface should adhere to the following three principles of usability:

Learnability – As defined by ISO 9126. The graphical operator interface should be easy to learn so that the user can quickly start being productive with the tools provided by the system

Efficiency – The graphical operator interface should be efficient to use, so that once the user has learned the system, a high level of productivity is possible

Memorability – The graphical operator interface should be easy to remember, so that the casual user is able to return to the system after some period of absence without the need to learn the interface over again

Adherence to the stated principles of usability should be achieved through consistent application of the following development standards defined herein.

Graphic Design. The layout and organization of each graphic display should be consistent among the graphic display types and adhere to the following standards:

The Default Template Screen will be developed in Phase 2 and will be used as a template when creating a new display; this will ensure that display components are located in the same place. The Default Template should follow these guidelines:

• Data displays should use global objects for displaying data, to enforce consistence

• Color conventions should be consistently applied throughout the graphical interface. Foreground colors should be selected to provide contrast to the background color. Verify that all colors chosen can be viewed by the end-user

• Text font sizes, colors and types should be consistently applied throughout the graphical interface

• Selectable items such as navigation, control and set point buttons should be easy to recognize and use

4.3 General Graphic Display Configuration

Graphic displays should be configured as either full screen displays or pop-up displays. Each type of display configuration should include the following features:

Full Screen Displays:

Full screen displays should be maximized, occupying the full, usable area of the window. Screens should be set to the size of 1280 X 1024 pixels.

Controls to close or minimize the window may be disabled depending on configuration of hardware at client computers.

Window exit control should be embedded in the graphic display’s navigational controls.

Full screen displays should remain in the background when a pop-up display is called from navigational hot links within the full screen display.

Use of contents on this sheet is subject to the limitations specified at the beginning of this document.

P:\Cary\131943 - Western Wake SCADA\TM7 Software Implementation Phase Documentation\Western Wake TM7\TM7.doc

Pop-up Displays:

Pop-up displays should not occupy the full window and should appear in the foreground when called from a full screen display Pop-up displays should appear at a user-defined location on the background display when called, but should have the capability to be dragged to a different location on the screen Pop-up displays should not be resizable Pop-up displays should be provided with close control

4.4 Graphic Display Types

Graphic displays should be categorized as schematic, overview, control panel, or trend.

4.4.1 Schematic Overview

The schematic overview graphic display should be presented as a process flow diagram and should represent major process piping, major equipment, process variable data, and process alarm and status data. Note that schematic overview screens should start with the least level of detail with sub schematic overview screens created to represent greater levels of detail were applicable. A schematic overview screen may be created to represent an entire SCADA system while sub schematic overview screens may be created to represent process areas and equipment.

Schematic overview displays should be prepared in accordance with the following guidelines:

1. Numeric display objects should be provided to indicate the instantaneous value of all analog process data associated with the process. In addition, standard objects should be used to indicate analog process data representing level

2. Standard objects should be provided to indicate run, off, and fault conditions for all major equipment associated with the process

3. Continuation labels should be provided to access associated schematic overview displays

4. Navigation links should be provided on equipment symbols to provide access to an associated control panel display or faceplate. When utilized the SCADA operator should be able to select a device symbol (hot link) and the associated device control panel or faceplate should appear

5. Navigation links should be provided on numeric display objects to access associated trend displays (were applicable)

6. Schematic overview should be a full screen display

4.4.2 Control Panel

The control panel graphic display should be presented as a virtual control panel providing a point of operator interface for control of a specific equipment item or system. The control panel is not necessarily a duplicate of any physical Local Control Panel (LCP) for the specific piece of equipment.

Control Panel graphic displays should be prepared in accordance with the following guidelines:

1. Graphic objects representing selector switches, pushbutton, slider bars, etc., should be provided to initiate the appropriate control function

2. All pertinent operating status data associated with the equipment or system controlled by the panel should be indicated

Use of contents on this sheet is subject to the limitations specified at the beginning of this document.

P:\Cary\131943 - Western Wake SCADA\TM7 Software Implementation Phase Documentation\Western Wake TM7\TM7.doc

3. Navigational control in the form of short-cut icons or labels should be provided to access associated graphic displays

4. Control panels should be configured as pop-up graphic displays or full screens where necessary

4.4.3 Trend Display

The Wonderware Trend Display is an Active – X Trend Object that pulls data from the InSQL:

1. Ensure colors specified for the pen display legibly on the trend screen and are easily distinguished from other pen colors

2. Range of analog signal should be configured when pens are added to show good resolution of the signal

3. Trend graphic displays should be configured as full screen displays

4.5 Navigation System

The navigation system should be configured to provide a logical, intuitive path through the graphical operator interface and also provide the flexibility to directly access graphic displays and system utilities. The graphical operator interface should be generally organized by process area; however, shortcuts should be provided to navigate beyond process boundaries.

The graphical operator interface should incorporate features to accommodate mouse-oriented navigation throughout the process control system. Scrollable menus, button bars, embedded hotlinks and continuation labels should be used to create a navigational system which provides ready-access to commonly used displays and utilities.

The navigation system should be implemented in accordance with the following guidelines:

4.5.1 Process Overview Graphic Display

A process overview display schematically representing the overall facility should be function as the system startup display and "home base” for conventional system navigation.

5 . O P E R A T O R S C R E E N C O N F I G U R A T I O N This section provides detailed examples of items discussed in Section 3 and 4 of this document. These examples are part of the South Cary Water Reclamation Facility graphics programming recently completed and included as an example in Attachment A. Additional screen examples following these guidelines, but developed for other Owners are included as Attachment B and Attachment C.

Overview Screens. The overall screen resolution should be 1280 X 1024. Overview screens should be five pixels wider than the display to ensure full screen. Overview screens should have the window properties indicated on Figure 5-1.

Use of contents on this sheet is subject to the limitations specified at the beginning of this document.

P:\Cary\131943 - Western Wake SCADA\TM7 Software Implementation Phase Documentation\Western Wake TM7\TM7.doc

Figure 5-1. Overview Screen Properties

Specifically dimensions for the overview screens should be 1285 X 800, located at 0,130. The type should be a replace type with no title bar and no sizing options. The following script example will be used in each overview window to ensure the header, footer are shown, while hiding the navigation pop-up and setting the screen name screen name variable to show the screen name in the title window.

The overview screen footer should have the window properties indicated on Figure 5-2.

Figure 5-2. Screen Footer Properties

Specifically dimensions for the footer screen should be 1285 X 100, located at 0,925. The type should be a replace type with no title bar and no sizing options. The footer should contain the alarm banner and login/logout buttons. Refer to Figure 5-3 for an example of the footer alarm banner.

Figure 5-3. Alarm Banner

Use of contents on this sheet is subject to the limitations specified at the beginning of this document.

P:\Cary\131943 - Western Wake SCADA\TM7 Software Implementation Phase Documentation\Western Wake TM7\TM7.doc

Navigation Bar. The navigation bar and other navigation properties are identified on Figure 5-4.

Figure 5-4. Navigation Bar Properties

Specifically dimensions for the navigation screen should be 1285 X 32, located at 0,100. The type should be a pop-up type with no title bar and no sizing options. An example of the navigation bar is shown in Figure 5-5.

The navigation bar contains a tab for each major process area or site, plus the overview and alarm screens.

Figure 5-5. Navigation Bar Example

The navigation buttons serve two purposes. If there is only one screen associated with the area or location, the navigation bar will use the listed action on Figure 5-6 to open the associated overview screen.

Use of contents on this sheet is subject to the limitations specified at the beginning of this document.

P:\Cary\131943 - Western Wake SCADA\TM7 Software Implementation Phase Documentation\Western Wake TM7\TM7.doc

Figure 5-6. Single Overview Screen Example

The embedded show window function should be avoided, as the windows identification indexing will cause a loss of navigation on imported screens. Any navigation buttons that navigate to the screen should have a visibility associated with them to avoid having multiple screens opened. An example of the visibility condition is show on Figure 5-7.

Figure 5-7. Visibility Conditions

The second purpose is if there are multiple screens in a given area the navigation bar will open a navigation pop-up window. The navigation pop-up window will be located below the navigation button which opens it.

The navigation pop-up buttons will adhere to the requirements listed above for the navigation buttons that open the overview screens; in reference to the visibility and action that they provide. Figure 5-8 is an example of a navigation pop-up window:

Use of contents on this sheet is subject to the limitations specified at the beginning of this document.

P:\Cary\131943 - Western Wake SCADA\TM7 Software Implementation Phase Documentation\Western Wake TM7\TM7.doc

Figure 5-8. Navigation Pop-Up Example

Pop-ups. Pop-up screens can be used for several functions in the HMI specifically when control, settings or display of specific function that is related to a give overview screen is required. Pop-up screen should have the window properties indicated on Figure 5-9.

Figure 5-9. Pop-Up Screen Properties

They should specifically be of pop-up window type, with a title bar. The sizing of the window will be a variable, depending on what objects and information is required on the screen. A button will be provided on the pop-up screen as a means of closing the pop-up screen. Figure 5-10 is an example of a pop-up screen:

Use of contents on this sheet is subject to the limitations specified at the beginning of this document.

P:\Cary\131943 - Western Wake SCADA\TM7 Software Implementation Phase Documentation\Western Wake TM7\TM7.doc

Figure 5-10. Pop-Up Screen Example

Alarm Display and Acknowledgement. Three types of alarm displays will be used for system alarming. The first is that a small alarm object will be used in the footer to give a quick status of current system alarms.

Figure 5-11 is an example of this alarm object:

Figure 5-11. Small Alarm Object

The alarm object query set up will be used to show alarms from the alarm servers in to distributed application. Figures 5-12, 5-13, and 5-14 are samples of the alarm object set up. They should be used as a guide for setting up alarm objects.

Use of contents on this sheet is subject to the limitations specified at the beginning of this document.

P:\Cary\131943 - Western Wake SCADA\TM7 Software Implementation Phase Documentation\Western Wake TM7\TM7.doc

Figure 5-12. Alarm Object Set Up

Use of contents on this sheet is subject to the limitations specified at the beginning of this document.

P:\Cary\131943 - Western Wake SCADA\TM7 Software Implementation Phase Documentation\Western Wake TM7\TM7.doc

Figure 5-13. Alarm Object Set Up

Use of contents on this sheet is subject to the limitations specified at the beginning of this document.

P:\Cary\131943 - Western Wake SCADA\TM7 Software Implementation Phase Documentation\Western Wake TM7\TM7.doc

Figure 5-14. Alarm Object Set Up

Figure 5-14 indicates all Unacknowledged Alarms in a red field in the object set up. The Alarms Summary Settings Configuration Screen on Figure 5-18 provides different alarm colors based on the priority of the alarm.

Use of contents on this sheet is subject to the limitations specified at the beginning of this document.

P:\Cary\131943 - Western Wake SCADA\TM7 Software Implementation Phase Documentation\Western Wake TM7\TM7.doc

The second alarm display will be the Alarm Overview. This will give a larger list of alarm statuses for the distributed application. Figure 5-15 is an example of an Alarm Overview Screen:

Figure 5-15. Alarm Overview Screen Example

Use of contents on this sheet is subject to the limitations specified at the beginning of this document.

P:\Cary\131943 - Western Wake SCADA\TM7 Software Implementation Phase Documentation\Western Wake TM7\TM7.doc

The settings listed in Figure 5-16, 5-17, and 5-18 will be used as a guide to configure the alarms summary object:

Figure 5-16. Alarms Summary Settings

Use of contents on this sheet is subject to the limitations specified at the beginning of this document.

P:\Cary\131943 - Western Wake SCADA\TM7 Software Implementation Phase Documentation\Western Wake TM7\TM7.doc

Figure 5-17. Alarms Summary Settings

Use of contents on this sheet is subject to the limitations specified at the beginning of this document.

P:\Cary\131943 - Western Wake SCADA\TM7 Software Implementation Phase Documentation\Western Wake TM7\TM7.doc

Figure 5-18. Alarms Summary Settings

Figure 5-18 indicates all unacknowledged alarms in a different color fields in the object set up. This facilitates alarm management by providing different alarm colors based on the priority of the alarm.

Use of contents on this sheet is subject to the limitations specified at the beginning of this document.

P:\Cary\131943 - Western Wake SCADA\TM7 Software Implementation Phase Documentation\Western Wake TM7\TM7.doc

The third alarm display is the alarm and event history view. This active X component will be configured to store the historical alarm database on the desired distributed computer. The default configuration of the object will be used as a guide to configure this component. Figure 5-19 is an example of the historical alarm viewer:

Figure 5-19. Historical Alarm Viewer Example

Trending. The ActiveFactory Trending Active-X component should be used for historical trending of system variable which are recorded on the InSQL Historian server.

System Status. The system status screens should show the status of the distributed system computers and Input/Output (I/O) topics. The I/O topics should be monitored Via the TopServer Topic. Table 5-1 provides the TopServer System Variables to be used to monitor the topic status.

Use of contents on this sheet is subject to the limitations specified at the beginning of this document.

P:\Cary\131943 - Western Wake SCADA\TM7 Software Implementation Phase Documentation\Western Wake TM7\TM7.doc

Table 5-1 Topserver System Variables

Item ID Access

Path Data Type Active

SCWRF_AOS1.BLWR._System._Simulated Boolean TRUE SCWRF_AOS1.BLWR._System._RequestTimeout Long TRUE SCWRF_AOS1.BLWR._System._RequestAttempts Long TRUE SCWRF_AOS1.BLWR._System._NoError Boolean TRUE SCWRF_AOS1.BLWR._System._Error Boolean TRUE SCWRF_AOS1.BLWR._System._Enabled Boolean TRUE SCWRF_AOS1.BLWR._System._DeviceId String TRUE SCWRF_AOS1.BLWR._System._ConnectTimeout Long TRUE SCWRF_AOS1.BLWR._System._AutoDemotionIntervalMS Long TRUE SCWRF_AOS1.BLWR._System._AutoDemotionFailureCount Long TRUE SCWRF_AOS1.BLWR._System._AutoDemotionEnabled Boolean TRUE SCWRF_AOS1.BLWR._System._AutoDemotionDiscardWrites Boolean TRUE SCWRF_AOS1.BLWR._System._AutoDemoted Boolean TRUE

For monitoring the Wondware distributed components, the packaged Archestra Objects found in the Displays folder of Archestra Symbol Library in the sample galaxy should be used. The sample galaxy is included in this document on CD, Attachment E.

6 . S T A N D A R D A R C H E S T R A V I E W O B J E C T S The standard objects that are located in the Wonderware industry packs, specifically the Water and Wastewater and SCWRF objects, should be used exclusively where they meet the requirements for the objects used to build the view application. If there are no objects that meet the needs, and new or modified objects are needed; refer to Section 3.b for the specific guidelines for creation of new objects.

There are two folders in the sample Galaxy where the Archestra View objects reside.

The first folder is the Archestra Symbol Library. This folder contains sample Archestra symbols. These symbols should be used as a guide to create new Archestra symbols. Objects inside of the Archestra Symbol Library should not be modified. These objects can be copied to another folder, renamed and modified to create new objects. New objects that are created or modified should be moved to a separate folder.

The second folder is the Wonderware Industry Packs Folder. Under this folder are the Water and Wastewater standard objects and the SCWRF standard objects. The Water and Wastewater objects should be used where ever possible. The objects inside of the Water and Wastewater folder should not be modified, but can be copied and move to another folder where they can be renamed and modified. Additionally the Water and Wastewater objects can be used as a guide create and modify Archestra symbols. These new symbols should be placed in another directory as with the SCWRF folder under the Wonderware Industry Packs folder.

Design and modification of objects. When graphics are not embedded with the application symbols, Archestra object properties should match the naming of the application symbols.

The objects properties should be created to minimize the tagging required for screen objects.

Use of contents on this sheet is subject to the limitations specified at the beginning of this document.

P:\Cary\131943 - Western Wake SCADA\TM7 Software Implementation Phase Documentation\Western Wake TM7\TM7.doc

Scripting should be kept to a minimum and only used where needed. Control system logic should not be placed in object scripting. Animations should be added using the Wonderware standard library as a guide.

Figure 6-1 is a sample of an Archestra object. A complete library of the objects can be found in the attached sample galaxy.

Figure 6-1. Archestra Object Example

Figure 6-2 is an example of a tagging screen for the object indicated on Figure 6-1. This interface will be used to tag the objects in window maker.

Use of contents on this sheet is subject to the limitations specified at the beginning of this document.

P:\Cary\131943 - Western Wake SCADA\TM7 Software Implementation Phase Documentation\Western Wake TM7\TM7.doc

Figure 6-2. Tagging Screen Interface

7 . G A L A X Y ( D A T A B A S E ) C O N F I G U R A T I O N Standardization of database development and usage is vital in achieving a consistent and optimal graphical control system. The Asset Management Identification Plan (AMIP) TM outlines the recommended tag naming convention to follow in programming the HMI database.

Tagging Standards. Analog data and digital data in the galaxy are represented by tags. The format of these tags should be as such that the average technician can look at the tag and know what the data is and where it comes from. To be able to achieve this recognition, the tag needs to have a standard format that is common in all SCADA systems. This standard format is identified and explained in the AMIP. These tagging standards include the following information needed to create data base tags in the HMI database:

Site ID – refer to AMIP Process Area ID – refer to AMIP Equipment Type/Instrument ID – refer to AMIP Equipment ID – refer to AMIP

In addition to the requirements in the AMIP, the following tag information is required for the HMI database tags.

Control Source. The control source is the function of the tag at the tags data source. Multiple tags may be formatted the same but vary only in the tags control source. The following list of characters to be used in the control source area of the tag.

DI Digital Input to PLC from the Field

DO Digital Output from the PLC to the Field

Use of contents on this sheet is subject to the limitations specified at the beginning of this document.

P:\Cary\131943 - Western Wake SCADA\TM7 Software Implementation Phase Documentation\Western Wake TM7\TM7.doc

AI Analog Input to the PLC from the Field

AO Analog Output from the PLC to the Field

OC Control Initiated by SCADA

OS Status Point to SCADA from the PLC

OA Alarm Point to SCADA from the PLC

PC Control Initiated by PLC for PLC use

PS Status by PLC for PLC use

PA Alarm by PLC for PLC use

SI Scaled Input Value (AI to Real)

SO Scaled Output Value (Real to AO)

Control Mnemonic. The Control Mnemonic of the tag shows the description of the data's purpose. For example, the tag displays if the valve is opened (OPND) or closed (CLSD). When using this tag naming convention to name objects in a galaxy, the control mnemonic may be as many as 8 to 10 characters including any additional underscores. Common tag abbreviation examples are shown below (others can be used depending on programmers discretion). A complete list should be established as a standard for all programming to provide consistency.

AL(xx) Alarm, xx shows what type of alarm it is

AUTO Auto mode

AP(xx) Alarm setpoint, xx shows what type of setpoint it is

CLSD Closed

OPND Opened

DO Dissolved oxygen

FAIL Equipment Failure

FLW Flow

LVL Level

MAN Manual

OVLD Overload

CLSE Close

OPEN Open

POS Position

PR Pressure

REM Remote

Use of contents on this sheet is subject to the limitations specified at the beginning of this document.

P:\Cary\131943 - Western Wake SCADA\TM7 Software Implementation Phase Documentation\Western Wake TM7\TM7.doc

RUN Run command

RNG Running

RST Reset

SP(xx) Non alarm setpoint, xx shows what type of setpoint it is

SI Speed Indication

STOP Stop

TE Temperature

WGT weight

Galaxy Objects. The Wonderware galaxy is an object orientated database. These objects are organized in areas which simulate areas of plant or site that the SCADA is connected to. These objects simulate the real world pieces of equipment and contain all I/O and control points associated with that real world piece of equipment. The configuration of the areas and objects in the areas will vary with each SCADA application developed. The only parts of the galaxy that should remain consistent from application to application are the objects themselves. There are standard objects supplied by Wonderware and there are user-defined objects that were created for Western Wake projects that can be used in building a new galaxy. Attached to this TM is a CD with a sample configured galaxy which contains these Wonderware standard objects and objects that were created for Western Wake.

Objects in the Galaxy are configured using the Galaxy Repository. When naming the objects in the galaxy the site code, process code, device code and ID number are used to name the object. Figure 7-1 shows the Configuration Screen for a derived instance of standard object and how the object is named.

Use of contents on this sheet is subject to the limitations specified at the beginning of this document.

P:\Cary\131943 - Western Wake SCADA\TM7 Software Implementation Phase Documentation\Western Wake TM7\TM7.doc

Figure 7-3. Object Configuration Screen

When the operator screen refers to an object, the dotfield in the name refers to the attribute of the object in the galaxy. Inherent attributes are default attributes form the software. Field attributes have been assigned as part of the standards. Figure 7-2 is the sample configuration of the attributes in an object. Notice this is also where the alarming for the tag is configured.

Use of contents on this sheet is subject to the limitations specified at the beginning of this document.

P:\Cary\131943 - Western Wake SCADA\TM7 Software Implementation Phase Documentation\Western Wake TM7\TM7.doc

Figure 7-2. object Attributes Configuration Screen

Scripting can also be done inside the galaxy objects. The object scripting should be limited in scope Extensive object scripting will slow the execution times of the object. All programming for runtimes, flow totals, and scaling should be done in the PLC programming and not in object scripting.

8 . D A T A A C Q U I S I T I O N Data acquisition is done by Software Toolbox's Topserver software running on the application on both application object servers. Topserver topics are configured the same on both machines to provide redundancy. Topserver uses their Allen Bradley suite to retrieve data from the PLCs in the system.

The Wonderware galaxy uses the OPClient object to communicate with Topserver when requesting data. For consistency the topics should have the same name in the Wonderware OPClient and Topserver. A topic for each PLC in the system should be used. A complete list of tags for topics must be done in the OPClient object. Other objects in the Galaxy will be pointed to the tags in the OPClient to get their data.

The Topserver topics should be configured to use Ethernet Transmission Control Protocol (TCP/IP) for communication. The Topserver topics should use OPC protocol if possible (AB Contrologix). Figure 8-1 shows a typical configuration for a Topserver topic.

Attachment 2 - PLC Controller Development Standards and Tag names Conventions (24 Pages)

1-1

P:\Cary\Western Wake SCADA-PLC Programming Standards-139815\Report\Final\WW PLC Programming Standards 20110210.doc

Section 1

Programmable Logic Controller Application Development Standards

1.1 Programmable Logic Controller Application Development

Standards

1.1.1 Overview

The Standards for PLC Application Development is used to program the PLCs in a consistence and logical format.

Any approved PLC can be utilized for SCADA system plant control systems within a Western Wake Water or Wastewater Facility or RTUs at remote sites. These PLCs provide the automatic control of the equipment at each process area. The statuses, process values and alarms are sent back to the SCADA Server from the PLCs.

1.1.2 Architecture

The basic hardware top to bottom layout for a control system starts with remote piece of communications hardware that is used to link the SCADA to the process area PLC. Communications hardware is used to transmit data (alarms, statuses, values, etc.) to the SCADA Server from the process area PLC and for the SCADA Server to send commands (Auto/Manual Selection, Setpoints, Start/Stop etc.) to the process area PLC. Communications hardware can include but is not limited to Spread Spectrum Ethernet Radio, License Frequency Ethernet Radio, Hardwired Ethernet Switch or Hardwired Ethernet Router.

The PLC in a process area can provide the following Functions:

• Alarming (process and equipment)

• Equipment Status

• Equipment Process Values

• PLC Automatic Controls

• Remote SCADA Manual Controls

• Intrusion Alarms

The PLC is assigned a unique network address. The PLC has four basic types of modules to interface with the field devices. The four types are DI, DO, AI and AO. The PLC field DI are 24VDC with 16 points to a module. The PLC field DO are 24 - 250 VAC Relay normally open Contact Outputs with 16 points to a module on the ControlLogix platform. The PLC field AI are 4-20 mADC/1-5 VDC configurable and are setup for 4-20 mA range with 8 channels to a module. The PLC AO are configurable and are setup for 4- 20 mA range with 4 channels to a module.

WWWMF PLC Programming Standards Section 1

1-2

P:\Cary\Western Wake SCADA-PLC Programming Standards-139815\Report\Final\WW PLC Programming Standards 20110210.doc

The basic software within the PLC is segregated into sections and each section is executed in an assigned priority order. That order is as follows Hardware Configuration (where Applicable), I/O Scaling (where applicable), I/O Mapping, Alarming, and Equipment Control. Equipment Control can be broken into any number of required routines and shall be organized to execute in an order of most important first. Generally a block of programming code will be pulled from the Western Wake code library and will be modified to match the control needs of the piece of equipment.

• Hardware Configuration were Applicable

• I/O Scaling were Applicable

• I/O Mapping

• Alarming

• Equipment Control 1

• Equipment Control

• Equipment Control

Special Note: The PLC programming is to be designed to allow the equipment to default to an AUTOMATIC mode of operation after power loss and power has been restored unless otherwise specified in the equipment’s specific control strategy in Section 17900.

1.2 Real I/O to SCADA Database Configuration

1.2.1 Analog Scaling/Values

All the analog values are scaled to REAL values. The analog values from the PLC analog input modules are read as raw binary values, these raw values are scaled to the field input range within the PLC program. Each raw analog value is scaled from zero, or its minimum, to the high field unit value. These scaled values are used by both the SCADA Server and the PLC program for comparisons (alarms, on/off Setpoints, etc.), PID control or the SCADA display/trending.

1.2.2 Discrete I/O Mapping

All discrete I/O are sent to/from the SCADA Server as PLC Controller Tags. No actual input or output hardware addresses are used as the interface to the SCADA Server.

1.2.3 Register Input/Holding Mapping

Process values and Setpoints are formatted as REAL numbers. REAL numbers in the PLC are floating point values. The format complies with 32-Bit IEEE-754 standards. This requires the Controller Tag be formatted as a REAL data type.

Timer presets and sequence indexes are formatted as INTEGER (INT) numbers. The range is 0-32,767 and requires the Controller Tag be formatted as an INT data type.

All analog inputs are sent to the SCADA Server as PLC REAL numbers and are retrieved from internal Controller Tag names. No actual hardware addresses are used as the interface to the SCADA Server.

All analog outputs are sent from the SCADA Server as PLC REAL numbers and are stored in internal Controller Tag names. No actual hardware addresses are used as the interface to the RTU.

All Setpoints are sent from the SCADA Server as PLC REAL numbers and are stored in internal Controller Tag names.

1-3

P:\Cary\Western Wake SCADA-PLC Programming Standards-139815\Report\Final\WW PLC Programming Standards 20110210.doc

1.3 PLC Basic Configuration

PLC configuration is based on the Allen-Bradley Process Automation Controller Family of PLCs and the RSLogix 5000 software is used to program it. All programs must be created in RSLogix 5000 software version 16 or later as this is the first version to accept user defined function blocks such as the Western Wake standard blocks. The model of processor, backplane, I/O cards and location of the I/O cards on the backplane must be specified in the software.

1.4 Predefined Code Conventions

Western Wake has an extensive library of code usage instructions for predefined blocks that have been used and tested in previous projects or will be created for specific projects. These blocks are added to the Logix5000 software as Add-On Instructions. The following sections break down how the most common of the predefined blocks of code work and how they should be used. Refer to the Western Wake Usage Instructions for each Block for more detail.

1.4.1 Auto/Manual Run Control (Dautoman Block)

The Auto/Manual Run Control routine will determine when a device which has auto and or manual controls will run. The routine will receive data such as auto status, manual status, auto start/stop, manual start/stop and an Enable. Generally when the code receives an auto status and it is enabled then the auto start/stop commands will toggle the run command. This same scenario applies to the manual status and manual start/stop inputs. The enable input will prevent the run command from turning on and will generally be triggered by alarms. The remote status will enable the auto/manual/run code while the local status will disable auto/manual/run code.

Inputs:

• Manual Mode Status

• Auto Mode Status

• Manual Mode Start Command

• Manual Mode Stop Command

• Auto Mode Start Command

• Auto Mode Stop Command

• Local Status

• Remote Status

• Enable Status

Outputs:

• Run Command

1.4.2 Equipment Runtime (Runtime Block)

RUNTIME provides the time keeping of a piece of equipment. In most cases the routine will only provide the total time that a piece of equipment has run, however the routine can possess the ability to provide the runtime for the previous and present day, week, month and year. To provide the total runtime the routine only needs run status of the piece of equipment and a reset command for manually resetting the counter. When the Running bit is active, time is added to the total runtime. If more detailed time keeping is required then the routine will require the present date and time as well.

1-4

P:\Cary\Western Wake SCADA-PLC Programming Standards-139815\Report\Final\WW PLC Programming Standards 20110210.doc

Inputs:

• Run Status Input

• Present Date

• Present Time

• Reset Command

Outputs:

• Present Day Runtime (Optional)

• Present Week Runtime (Optional)

• Present Month Runtime (Optional)

• Present Year Runtime (Optional)

• Last Day Runtime (Optional)

• Last Week Runtime (Optional)

• Last Month Runtime (Optional)

• Last Year Runtime (Optional)

• Totalized Runtime

1.4.3 Flow Totalization (Flow or Flowtotal Block)

The Flow Totalization routine provides the totalizing of flow from a flow meter. Generally flow meters will provide a real value for flow in gallons per minute (gpm) or gallons per hour (gph) or the flow meter will provide a pulse indicating a flow volume. When the real value is provided, the average flow is taken over the flow value time period (hours, minutes). At the end of each time period the average flow is added to the total. If a pulse is provided then at each pulse a volume value (Gallons, liters) will be added to the total. The flow total will be reset when the reset input is triggered. Flow can be broken up into previous and present day, week, month and year. If more detailed flow totals are required the routine will need the present date and time.

Inputs:

• Real Flow Value

• Flow Pulse

• Volume per Pulse

• Present Date

• Present Time

• Reset the Totalized Flow

Outputs:

• Total Flow

• Flow per Day (Optional)

• Flow per Week (Optional)

• Flow per Month (Optional)

• Flow per Year (Optional)

• Flow Previous Day (Optional)

• Flow Previous Week (Optional)

• Flow Previous Month (Optional)

• Flow Previous Year (Optional)

1-5

P:\Cary\Western Wake SCADA-PLC Programming Standards-139815\Report\Final\WW PLC Programming Standards 20110210.doc

1.4.4 Alarming (Almlatch Block)

Alarming can be implemented in different ways depending on alarming requirements and the PLC and SCADA software used. Alarms can be generated from both discrete and analog values. When a discrete alarming condition is true for a set time period then the alarm shall also be true. When an analog process variable exceeds a predetermined or setpoint value for a set time period then the alarm shall also be true.

An optional alarm acknowledgement and resets can be used to ensure alarms are received and viewed by an operator. When the alarm is received by SCADA the Acknowledge bit will be sent from the SCADA to the PLC in the form of a discrete value. An operator reset can be used which must be triggered before an alarm condition will clear. Acknowledges are triggered automatically by the SCADA software while Resets are triggered by an operator through the SCADA software.

Inputs:

• Analog process variable for alarming versus a setpoint

• Setpoint of the alarm

• Discrete Input alarm

• Alarm reset (Optional)

• Acknowledge the alarm (Optional)

• Time delay on the alarming (Optional)

Outputs:

• Alarm

Valve Control (DCS_O_C Block) –

Inputs:

Valve Control provides the basic auto control for a valve. This code will receive an auto close and open condition which it will compare with a process variable and if the valve is in remote open and close the valve based on those conditions. This subroutine can be used with the auto/manual/run subroutine to provide additional control.

• Process Variable

• Auto Close Condition

• Auto Open Condition

• Local/Remote Status

• Enable Status

Outputs:

• PLC Close Command

• PLC Open Command

Sequencing (SEQ3 OR SEQ4 Block) –

Inputs:

Sequencing is used to determine the starting order of equipment and in most cases is used for pumps. Sequencing also provides rotation which cycles each device from lead to lag1 to lag2 and standby. This provides even wear on equipment. Generally a demand for a number of pumps will be input to the function, and depending equipment availability and the current sequence, those pieces of equipment will be called to start. Note that the call to start can be routed through the Auto/Manual subroutine were applicable.

• Sequence Number (1, 2, 3, OR 4)

• Number of Pumps Required

1-6

P:\Cary\Western Wake SCADA-PLC Programming Standards-139815\Report\Final\WW PLC Programming Standards 20110210.doc

• Pump Order in Rotation (1, 2, 3, or 4)

• 1 Ready (1) or Disabled (0)

• 2 Ready (1) or Disabled (0)

• 3 Ready (1) or Disabled (0)

• 4 Ready (1) or Disabled (0)

Outputs:

• Pump Start Output

1.5 Alarm Conventions

1.5.1 PLC Internal Status Alarms

Under Range – The under range fault bit is set by the PLC program when the input signal is below 4 mA, and the process is on for a valid analog value.

Analog Input Module Out-Of-Range (Under/Over Range)

Over Range – The over range fault bit is set by the PLC program when the input signal is above 20 mA.

Channel Fault – The channel fault bit is set by the analog input module when an under range, over range or channel fault occurs on the module.

Channel Fault

1.5.2 Equipment Alarms

Fault Alarms – A fault alarm indicates problem with a piece of equipment and generally comes from the field inputs. Fault alarms can include equipment failure, trouble or other relay signals.

1.5.3 Process Alarms

Process alarms shall be generated when a process value exceeds the limits given to it by setpoint or hard coded value. The alarm conditions must be present for a set period of time before the alarm is annunciated. Process alarms shall manually clear, automatic clearing of alarms shall not be allowed.

Process values generally include but are not limited to Pressure, Flow, Level, pH and Chlorine Residual.

1.5.4 Security Alarms

Intrusion is alarmed after a timer delay and the alarm will be reset after the alarm condition clears and the alarm is acknowledged by SCADA.

1.6 Documentation

1.6.1 PLC I/O Database

The PLC I/O Database is to be documented in an Excel spreadsheet. The information required for each I/O is as follows:

• Tag Name – per the Western Wake tagging standards

• PLC Slot/Point Module Assignment

• Description

• Analog Inputs:

− Range (0-100, 0-5000, 0-16, 0-150)

1-7

P:\Cary\Western Wake SCADA-PLC Programming Standards-139815\Report\Final\WW PLC Programming Standards 20110210.doc

− Engineer Units (PSI, GPM, FT, LBS) − Alarm Limits

• Discrete Inputs:

− Status (On, Off) − Alarm (Low, High, LO-LO, HI-HI)

• Analog Outputs:

− Range (0-100, 0-1800) − Engineer Units (%, RPM)

1.6.2 SCADA I/O Database

The SCADA I/O Database is to be documented in an Excel spreadsheet.

• Tag Name - per the Western Wake tagging standards

• PLC Address Assignment (where applicable)

• Description

• Analog Inputs:

− Range (0-100, 0-5000, 0-16, 0-150) − Engineer Units (PSI, GPM, FT, LBS) − Alarm Limits

• Discrete Inputs:

− Status (On, Off) − Alarm (Low, High, LO-LO, HI-HI)

• Analog Outputs:

− Range (0-100, 0-1800) − Engineer Units (%, RPM)

Special Note: All Alarm points to the SCADA are in an alarm state when the point is set to 1 (high state) and in Normal state when the point is set to 0 (low state).

1.6.3 Basic Initial Settings (Set Points; Analog Scaling; Timer Values; Comm Ports…) The initial settings are values that allow the process control and alarming to properly restore the process areas RTU to a nominal working state. These values are to be documented in an Excel spread sheet and those values that are setpoints or timers are initialized in the PLC program. These values are restored into the PLC when the program is reloaded.

• Tag Name per the Western Wake tagging standards

• PLC Address Assignment (where applicable)

• Description

• Analog Inputs /Setpoints for normal process controls and alarms:

− Range (0-100, 0-5000, 0-16, 0-150) − Engineer Units (PSI, GPM, FT, LBS) − Process Limits − Alarm Limits

1-8

P:\Cary\Western Wake SCADA-PLC Programming Standards-139815\Report\Final\WW PLC Programming Standards 20110210.doc

• Timers:

− Range (0-100, 20-90) − Delay Type(On, Off, Repeat)

• Function:

− Process − Alarm (Low, High, LO-LO, HI-HI)

2-1

P:\Cary\Western Wake SCADA-PLC Programming Standards-139815\Report\Final\WW PLC Programming Standards 20110210.doc

Section 2

Tagnames Conventions

2.1 Tagnames Conventions

Tagnames used in PLC, Operator Interface Terminals (OITs), and HMI shall follow format below:

Figure 2-1. SCADA TAG Standard

Example of Tagnames:

Tag name: WWTP_PRE_INF_LIT1511_OA_ALHH

Tag name: WWTP_PRE_INF_SCN1112_DI_STS

Tag name: WWTP_SEC_AAB_B2611_DI_STS

Tag name: WWTP_BLD_GEN1_DI_STS

Tag name: RS06_PRE_INF_P1011_DI_STS

Remote Site 06, Preliminary Treatment, Influent Code, Pump 1011, Digital Input, Status

2.1.1 Tag Description Field

Database tag description fields are a vital part of the tag, as it is this description that will appear in alarm summary displays and alarm log files. This field is limited to 128 characters so it is imperative that the description adequately describe the point for which it has been assigned, yet brief enough to fit within the size constraints. All descriptions should be prefixed with an appropriate process area code. The remainder of the description field should state the device or process, device number, alarm condition, and tag functionality.

Tag name: WWTP_PRE_INF_ LIT1511_OA_ALHH Example of Description Field

Description: WWTP Preliminary Influent Channel 1 High-High Level Alarm Abbreviations can be used, if necessary, but should be kept to a minimum.

WWWMF PLC Programming Standards Section 2

2-2

P:\Cary\Western Wake SCADA-PLC Programming Standards-139815\Report\Final\WW PLC Programming Standards 20110210.doc

2.2 Site ID

The Site ID is used to identify a geographic location. The location identified can be a treatment plant or remote site. Generally the Site ID will be determined by the Owner.

Table 2-1. Site ID

Site ID Description Site ID Description

SCWRF Wastewater Treatment Plant 026 Westwood Park (Future)

NCWRF Wastewater Treatment Plant 027 Kensington

WCWRF Future Wastewater Treatment Plant

028 Cary Park

001 Swift Creek 029 Future

002 Walnut Creek 030 Grey Hawk

003 Kit Creek 031 Terrington

004 White Oak 032 Park at West Lake

005 Nelson 033 Forest Oaks

006 Crossroads 034 Copperleaf

007 Glenmitt Stone 035 West Cary

008 Fieldstone 036 Beaver Creek

009 I 40 037 WWWRF Effluent p.s.

010 Glenridge 038 Lower Breckenridge

011 Jones Franklin 039 Terrace II

012 Medfield 040 West Breckenridge

013 Blanche 041 Woodlands

014 Talloway 042 Aviation Parkway

015 Gateway Center 043 Circandian Court

016 RDU Center 044 Paramount

017 MacGregor Park 045 (Future)

018 Ronaldsby 046 Perimeter Park

019 Morris Branch 047 Lake Crabtree

020 Carystone 048 Kitts Creek

021 Thresher 049 Wimberly Road

022 Future 050 (Future)

023 Town Hall Dr. 051 (Future)

024 Holly Brook Water Treatment Plant

025 Rocky Branch

2-3

P:\Cary\Western Wake SCADA-PLC Programming Standards-139815\Report\Final\WW PLC Programming Standards 20110210.doc

2.3 Process Areas ID

Table 2-2 illustrates the Process Area ID. It is the intention of this identifier to organize equipment and systems in to process areas within a geographical site. The Process Area ID is a typical identifier defined herein as a three digit alpha character set. This process area character set defines the process area and directly correlates with a series of drawings.

Table 2-2. Process Area ID

ID Process Area Description

PRE Preliminary Treatment

PRI Primary Treatment

SEC Secondary Treatment

TER Tertiary Treatment

EFF Effluent Treatment

SOL Solids Treatment

CHM Chemical System

BLD Support…