HomeMy WebLinkAboutAgenda Report - November 7, 2007 E-06AGENDA ITEM U40(o
is% CITY OF LODI
COUNCIL COMMUNICATION
TM
AGENDA TITLE: Approve Request for Proposal (RFP) to Replace and Upgrade the Existing
Utility Supervisory Control and Data Acquisition (SCADA) System (EUD)
MEETING DATE: November 7,2007
PREPARED B Y Electric Utility Director
RECOMMENDED ACTION: Approve Requestfor Proposal (RFP) to replace and upgrade the
existing utility Supervisory Control and Data Acquisition (SCADA)
System.
BACKGROUND INFORMATION: The existing SCADA System is comprised of two separate systems;
one of 1980s vintage and the other purchased in 2001, and is based
on the Siemens' Telegyr platform. It is used by the EUD Dispatch
Center to control, monitor and acquire the status, alarms, sequence of events, data and other parameters
pertinent to real-time operation of water, wastewater and electric utilities in the City. Remoteterminal
units (RTU) are installed in each well, pump, storm/lift stations and also to all four electrical distribution
substation facilities within the City. The SCADA System's interfacewith these RTUs is through leased
lines provided by the local telephone company.
The first SCADA System was placed in operation in the 1980s utilizing two units to provide necessary
redundancy. The first unit has been inoperable for an extended period due to non-availabilityof parts
and the second is plagued with periodic operational problems.
The second SCADA System was purchased in 2001 with the intent of replacing the first SCADA System
when fully operational. While the basic SCADA framework and software were configured and integrated
by Siemens, the remainder of the system was to be programmed by in-house personnel. Due to a
variety of issues, this second SCADA System was neverfully implemented and its hardware/software is
now obsolete.
The City's utility operations are dependent on an adequate, secure and reliable SCADA System. As
noted above, the existing SCADA systems are only marginally operational and not fully redundant as is
needed for reliability. The proposed system under the RFP will be built with redundant units operating in
parallel and will be provided on a "turn -key" basis.
FISCAL IMPACT: Estimated cost is approximately $125,000.
FUNDING AVAILABLE: Transfer of funds from unencumbered bond proceeds (Electric Utility
Department 2002 Certificate of Participation Series A) to Account
No. 1 2
c E ans, Budget Manager
APPROVED:
Blair ing, City Manager
Approve Request for Proposal (RFP) to Replace and Upgrade the Existing Utility Supervisory Control and Data
Acquisition (SCADA) System (EUD)
November 7.2007
Page 2 of 2
Gefge F. Morrow
Electric Utility Director
PREPARED BY: Demy Bucaneg, Jr.. P.E.,Manager, Engineering& Operations
GFM/DB/Ist
Attachments
October 23, 2007
Exhibit 1 - Specifications
City of Lodi Electric Utility Department (EUD) SCADA10.07 SPEC
Purpose: It is the expressed purpose of this specification to established a minimum
guideline in which any prospective bidder(s) in association with the City of Lodi should
comply with for the engineering, design and building of the whole or any part of the
electric utilities SCADA (Supervisory Control and DATA Acquisition) system.
1 of 40
TABLE OF CONTENTS
CHAPTER I - INTRODUCTION
General Overview
Bidder Requirements
Bidder's Responsibilities
City of Lodi's Responsibilities
Standards
CHAPTER 2 - SYSTEM CONFIGURATION
Primary Master Station
Redundant Master Station
Optional Quad Redundant Master Station
Configuration
User Interface
Master -to -RTU Communication
Master -to -IED Communication
System Sizing
System Maintainability
CHAPTER 3 - SYSTEM HARDWARE
Hardware Platform
Host Servers
Workstation Consoles
Remote Consoles
Communication Interfaces
Peripherals
CHAPTER 4 - SYSTEM SOFTWARE
Compliance with Open System Standards
Operating System
Database Structure
Historical Database
CHAPTER 5 - SYSTEM FUNCTIONAL REQUIREMENTS
Data Acquisition
Supervisory Control
RTU Communication
Status Data Processing
Analog Data Processing
Pulse Accumulator Data Processing
Sequence of Events Data Processing
Control Output Requirements
Areas of Responsibility
Tag Management
Calculations
Command Sequencing
Graphical User Interface (GUI) Environment
Operator Displays
Global map Display
Notes
Drawing File Import
2 of 40
Control Panels
Full Graphics Editor
Drawing Tools
Data Quality
Database Editor
IED Wizard
User Rights and Privileges
Alarm Processing
Alarm Priorities
Alarm Formatting
Master/Slave Alarm Suppression
Remote Alarm Annunciation
External Alarm Bell
Event Data Recording
Report Generation
Report Editor
Data Export to MS Excel and MS Access
Data Collection and Storage
Historical Information System
Data Trending
Disturbance Data Capture
Operations and Outage Accounting
Operator Training Simulator
ICCP (Inter Control Center Protocol) — TASE.2
Network Topology Processor
Switch Order Preparation and Management
Interface to GIS Systems
CHAPTER 6 —SYSTEM IMPLEMENTATION
Project Schedule and Coordination
System Testing
Shipping and Installation
Site Acceptance Test (SAT)
Support Plan
Training
Documentation
APPENDIX "A" — SYSTEM SIZING REQUIREMENTS
APPENDIX "B" — RTU INFORMATION
3 of 40
CHAPTER I - INTRODUCTION
General Overview
This document describes the requirements for the replacement and upgrade of the existing Supervisory Control
and Data Acquisition (SCADA) system for the City of Lodi (City). The SCADA System shall be installed in the
Electric Utility Department (EUD) Dispatch Center located at 1331 South Ham lane Lodi, California 95242.
All exceptions and/or clarifications shall be clearly identified and shall be referenced to the specific paragraph
and/or section of this specification. They shall be submitted as part of the bidder's proposal as indicated in the
Request for Proposal (RFP). Minor exceptions between the bidder's proposal and the specification may be
allowed, however any major exceptions may be considered non-compliant and be the cause for rejection.
Bidder Requirements
The prospective bidder shall be able to fulfill the following qualification requirements:
a. Bidder shall state the number of years of experience in the design and manufacture of systems of the
type specified;
b. Bidder shall provide ten (10) customer reference projects with a similar configuration and functionality to
the system proposed. The list of reference projects shall include at least the following information:
customer name and address, contact name and phone/email, starting date of commercial operation,
operating system platform.
c. Bidder shall utilize standard off-the-shelf hardware and operating system software which are available at
least from two different commercial sources;
d. Bidder shall provide support services with a 24/7 availability;
e. Bidder shall state whether there are any anticipated changes in ownership or major corporate policy
changes in the next 12 months;
f. Bidder shall state whether there are or there have been any legal claims or litigation actions against him
regarding the performance of projects.
Bidder's Responsibilities
The prospective bidder shall be responsible for the following:
a. As turn -key contract, design, assemble, manufacture, factory test, deliver, install and commission a
complete and fully functional replacement and upgrade of the existing SCADA System according to
the SCADA RFP and specifications;
b. Interface with existing and new RTUs and other City's existing and supplied devices;
c. Work with designated City Staff for the integration, test and commissioning of all special application
programs for water and power facilities;
d. Provide training courses at the City's facilities;
e. Provide on-site supervision of installation and commissioning of the system;
f. Provide technical support and assistance during the commercial operation of the system.
City's Responsibilities
The City shall be responsible for the following:
a. Provide air conditioned environment in the control room;
b. Provide power sources and communication wiring to the equipment locations;
c. Technical review of the successful bidder's documentation;
4 of 40
d. Participate in the factory acceptance testing;
e. Provide copy of the existing database, if any, in an electronic format for conversion;
f. Provide programs for special application processes on City's water and power facilities;
g. Attend the training courses on site;
h. Provide a project person for the coordination of all project activities with the successful bidder's project
manager.
Standards
The bidder shall state the standards which apply in the design and manufacture of the proposed system. The
standards shall include but not be limited to the following standards:
a. ANSI American National Standards Institute
b. IEEE Institute of Electrical and Electronics Engineers
c. IEC International Electrical Code
d. NERC North American Electrical Reliability Council
e. NEMA National Electrical Manufacturers Association
f. EPRI Electrical Power Research Institute
Where the proposed standards differ from above, bidder shall state which standard applies. Where non-
standard hardware, software or services are offered, bidder shall justify their adequacy and applicability in
relation to the functions to be performed.
5 of 40
CHAPTER 2 - SYSTEM CONFIGURATION
Primary Master Station
The master station shall consist of a host computer (SCADA server), with separate operator workstations
(SCADA clients), and communication servers (terminal servers), all interconnected by a high-speed local -area
network (LAN). The system shall support the TCP/IP protocol which will be used for all data exchanges between
the various nodes on the network.
Redundant Master Station
As an option, the master station shall consist of a redundant configuration with dual host computers (SCADA
servers), with separate operator workstations (SCADA clients), and terminal servers, all interconnected by a
high-speed local area network (LAN). The network shall support the TCP/IP protocol which will be used by the
SCADA system for all network communications.
The active host computer shall maintain the standby computer in a fully synchronized state via the network. In
the event of a failure of the active machine, the standby computer shall automatically assume control of all
peripherals and communication lines with no action required from the system operator.
Optional Quad Redundant Master Station
As an option, the system shall also be able to handle quad redundant configurations, i.e. comprising four (4)
servers running in main/hot-standby mode.
Confiauration
The host server(s) and all workstations shall consist of standard PC architecture machines utilizing Intel or
equivalent processors. Operating system software shall be industry standard, off-the-shelf software. It shall
provide a windowing graphical user interface environment.
The SCADA host software and the operator interface software shall run directly in the operating system's own
windowing environment. X -Windows sessions or other emulations are not acceptable. A system of pull-down
menus and dialog boxes shall provide the operator with quick, intuitive access to normal SCADA operations, as
well as to database editing and system configuration functions.
The operator interface shall be graphics based and shall be capable of importing vector graphic data from other
mapping systems such as AutoCAD or GIS for incorporation into the SCADA displays. Such imports shall be
based on the DWG or DXF file formats. The operator interface software shall include the ability to merge
multiple imported maps into one SCADA display and to edit the imported graphics.
For communication with RTUs, IEDs and other serial -data peripheral equipment, commonly available terminal
servers shall be provided to off-load serial communication processing from the host computers. The serial data
ports provided by the terminal servers shall be capable of two-way serial communications.
User Interface
The operator interface software shall provide a single world coordinates based graphical view of the system,
arranged schematically or geographically as defined by the user. It shall be possible to navigate freely in this
global map, scrolling in two dimensions (panning) and zooming in or out to view any location at any desired
6 of 40
degree of magnification. The displays shall contain static graphical information, as well as dynamic elements
that reflect the information contained in the host computer's database. Database point values displayed by such
dynamic elements may be either telemetered from RTUs or calculated by the host server.
Operator interaction with database points shall be by means of clicks of the mouse on the dynamic display
elements. This will include operations such as controlling field devices, setting database values, e.g. manual
updates, acknowledging or blocking alarms and tagging data points to inhibit control. The user shall be able to
use elements on the display as pushbuttons to initiate pre -defined actions. These shall include, as a minimum,
the ability to:
o bring up pop-up notes
o bring up trend graphs
o bring up other displays
o bring up Microsoft Excel or Access based reports
o run command sequences
o access records in other databases
o access other displays within the global map
Displays are specific rectangular areas within the global map. The user shall be able to define any number of
displays in the global map. The operator shall be able to go to a display by means of either a pushbutton or by
selection from a list. To facilitate navigation through the list of displays, it shall be possible to organize the list in
a hierarchical set of named folders.
The system shall support an unlimited number of graphical layers which can be de -cluttered either automatically
(based on zoom level) or manually by the operator. The system shall also support an unlimited number of
displays.
Master -to -RTU Communication
The SCADA system shall support the protocols used by the City's existing and/or proposed/new RTUs. In
addition, the system shall have the following open protocols available as options:
o DNP3.0 Level 2
o IEC 870-5-101
o Modbus
These protocols shall be available for both serial and network interfaces (TCP/IP). The above protocols shall be
run in native mode, i.e. there shall be no need for an external protocol converter (hardware unit) or internal
converter (third party software driver), nor shall there be any need for any kind of front-end processor. The
proposed system shall not have any limitation in the number of communication lines whether serial or over
TCP/IP. No software upgrades or additional licenses shall be required to increase the number of communication
lines for protocols that already run on the system.
The master station database editor shall allow the user to define key parameters for each communication line:
baud rate, time allowed for the RTU to respond, the number of retries, accumulator poll interval, interval
between scans, and protocol -specific configuration parameters. The communication software shall maintain
communication statistics for each RTU. These statistics shall be available as database points so that they can
be incorporated in user -defined displays, reports, and alarms.
In cases where the RTU protocol supports exception polling, the communication software shall make use of it to
provide rapid alarm throughput and capture of multiple, rapid succession alarms. The communication software
shall automatically interleave polls for results from controls between normal round-robin exception polls. Where
applicable, all station accumulator freeze -commands shall be used to provide simultaneous system -wide
sampling of accumulator points.
7 of 40
Master -to -IED Communication
Intelligent Electronic Devices (IEDs), if included in the system, shall be able to either be polled directly by the
host server in the same manner as RTUs, or to be polled by an RTU. In the latter case, IED data gathered by
the RTU shall be reported to the Master Station along with the RTU's own data.
The Master Station shall support the communication protocols used by the IEDs connected directly to the
Master Station. IEDs that are connected to an RTU that is supplied by the vendor shall be mapped into the
RTU's database by means of user defined mapping tables. These tables shall allow any subset of each IED's
data to be mapped into RTU's database. The structure of these mapping tables shall support multiple IEDs on
each communication port in the RTU. Different IED protocols shall be supported by the RTU on each port.
The mapping tables used by the vendor's RTUs shall be maintainable at the SCADA host server and
automatically downloaded to the RTUs by the communication software. The proposed system shall not have
any limitation in the number of field devices and IEDs to be connected. No software upgrades or additional
licenses shall be required to increase the number of IEDs to be integrated into the system.
System Sizing
The SCADA system hardware shall be equipped for the quantities indicated in the Appendix A. The required
capacity for future expansion is also included in the Appendix A. The system software shall be capable of
accommodating in its database an unlimited quantity of status and control points, analog input points, text
points, communication lines, RTUs, IEDs, operator wokstations, reports, graphic symbols. These unlimited
capacities may only be limited by the resources of the servers, operating system (memory size) and network.
The size of the system map shall be up to a maximum of 1 billion x 1 billion drawing units.
The system shall be able to fully process a continuous alarm throughput of 50 alarms per second for at least 60
seconds. Both the World Coordinate map and the displays on all workstations shall be updated and responsive
to controls throughout the alarm burst.
Svstem Maintainabilit
The system shall be designed such that the user will be able to maintain the SCADA system with minimum
reliance on the successful bidder's services. The system shall include all the necessary software for
configuration of the system, integration and maintenance of the database. The database maintenance software
shall provide a convenient graphical view of the entire database, with easy navigation throughout the database.
The database editor shall allow interact with the user in an intuitive manner by means of dialog boxes and other
familiar controls that are standard to the operating system. The successful bidder shall provide training courses
covering these subject areas.
The successful bidder shall provide with the system, a dial-up diagnostic maintenance modem to provide access
for system troubleshooting and software updates. The successful bidder shall have the ability to provide same
day diagnostic troubleshooting and database assistance from the vendor's software facilities during normal
working hours.
The successful bidder shall provide evidence that:
o The proposed software is owned and controlled by the bidder.
o The proposed system has a low cost of ownership.
8 of 40
o The bidder has full-time designing and programming staff capable of supporting and enhancing the
software.
o The bidder maintains a full-time customer service department capable of providing same day
diagnostic services via modem or VPN.
o The proposed software has a sizeable installed customer base.
o The bidder maintains an active User's Group organization.
The bidder shall have a formal version release method and shall be able to offer upgrades to newer versions of
the proposed system software.
9 of 40
CHAPTER 3 - SYSTEM HARDWARE
Hardware Platform
The hardware platform encompasses all of the physical hardware devices utilized by the SCADA system
including host servers, operator workstations (local and remote), storage devices, communication interfaces,
printers, GUI devices (LCD Flat Panels) and LANs to which all the hardware devices shall connect.
The system shall be implemented with industry standard general purpose devices and interfaces. The proposed
hardware devices shall be available from at least two different commercial sources (brands) on the market. The
hardware platform shall be scalable such that existing devices shall be able to be replaced with higher
performance/capacity devices with no or minimal impact to the system.
All materials and equipment furnished for permanent installation in the work shall conform to applicable standard
specifications and shall be new, unused, and undamaged.
Host Servers
The system supplier shall provide the Master Station server hardware and peripherals built by a leading
computer industry manufacturer. The preferred computer manufacturer is Dell. The servers shall be wholly
designed, manufactured, warrantee, and assembled by the computer manufacturer. Composite component
computer frames assembled with multi -vendor cards by second source manufacturers will not be accepted.
The host servers shall have as a minimum 3.OGHz Intel or equivalent processors with 1GB RAM memory, 80
GB internal disk drive, Read -Write CD-ROM, 40 GB tape backup drive, 10/100baseT Ethernet adapter. One 15 -
inch color Flat Panel LCD shall be provided with a KVM (keyboard -video -mouse) extender for switching
between servers for trouble -shooting purposes. A 56K internal modem or better shall be provided for remote
diagnosis by the system supplier via dial-up.
The host servers and associated communication equipment shall be delivered rack -mounted in cabinets with
perforated walls for easy ventilation. The host servers shall run the latest MS Windows 2003 Server Edition
operating system.
Workstation Consoles
The system supplier shall provide workstation console hardware and peripherals built by a leading computer
industry manufacturer. The computer manufacturer shall be the same as for the host servers. The proposed
workstation shall have as a minimum 3.0 GHz Intel or equivalent processor with 512MB RAM memory, 40 GB
internal disk drive, Read -Write CD-ROM, 10/100baseT Ethernet adapter, one (or two, or more ) 20 -inch Flat
Panel LCD with graphic adapter with a minimum resolution of 1280 x 1024 pixels, wireless keyboard and
mouse.
The workstations shall run the latest MS Windows XP Professional operating system. The system shall be able
to support any number of workstation consoles without any need for upgrading the system hardware and
software.
Remote Consoles
As an option, the proposed system shall be provided with remote consoles which are based on laptop
(notebook) computers.
10 of 40
The remote consoles shall use a dialup modem integral to the laptop to call the master station. As an option, the
remote consoles shall use a communication wide area network (WAN) or a virtual private network (VPN) for
accessing the host server. All functions and features in the local GUI shall also be accessible from the remote
consoles.
Communication Interfaces
The communication servers shall provide the interfaces between the Master Station and the RTUs and/or IEDs
in the field. The vendor shall propose industry standard, off-the-shelf terminal servers which shall support both
standard asynchronous serial interfaces and TCP/IP interfaces. Each communication port on the terminal server
shall be able to be used either as a serial RS232 port or as a network TCP/IP port, at user's choice. When
external modems are required, a Bell 202D modem shall be configured for each channel.
The terminal servers shall be provided in dual redundant configurations, in the case of a dual redundant Master
Station. In this case, each terminal server shall be connected to a Local Area Network (LAN) in a dual redundant
LAN configuration. The terminal servers shall be modular and easily expandable in modules of eight or sixteen
ports. This interface approach shall support communication via phone leased lines, microwave, radio, optical
fiber, satellite and other methods of telecommunication.
Peripherals
The system shall be provided with a logger which shall be a 300 cps dot matrix printer for logging purposes. The
system shall also be provided with a laser or inkjet printer that will produce high quality graphical printouts of the
system screens at 1200 dpi with speeds up to 11 ppm in color. The printer shall support a parallel or Ethernet
network interface.
11 of 40
CHAPTER 4 - SYSTEM SOFTWARE
Compliance with Open System Standards
The proposed SCADA system shall have been designed for openness. The Master Station shall have been
designed around off-the-shelf industry standard software to provide open access across any TCP/IP based
networks.
The following industry standards shall be part of the foundation of the proposed system:
a. MS Windows Operating System. The Windows version running on the host servers shall be Windows
server edition whereas the version running on the workstation consoles shall be Windows XP
Professional. Hybrid or multiple operating systems such as a combination of MS Windows with
OpenVMS, UNIX or LINUX will not be acceptable.
b. MS SQL Server Relational Database. An off-the-shelf package designed for storing data, sorting
information, retrieving data in custom reports and providing an industry standard interface to other
applications shall be used.
c. Interfacing to AutoCAD and/or GIS or AM/FM systems using DXF or DWG graphic industry standards.
d. ODBC (Open Database Connectivity) standard which is supported by Microsoft, Oracle, Novell and
many others, and creates a common relational database and SQL structure for interoperability between
different applications.
e. TCP/IP — inter -process communications standard which provides a standard protocol for LAN/WAN
communications and a standard language for Client/Server applications.
f. DNP3.0 Level 2 as a standard communication protocol for RTUs and IEDs adopted by the utility industry
in North America.
g. OPC (Microsoft Ole for Process Control) — as a standard for integrating applications for industrial
systems such as: water, gas, etc, used in the vertical utilities.
Operating System
The system shall use a true multi-user, multi -tasking operating system platform as provided by Microsoft
Windows. The operating system shall exhibit robust security features, shall support resource accounting at both
the user and application level, shall support Microsoft Windows without emulation as well as DOS, shall support
32-bit processing and be memory addressable to 2 GB.
The system platform shall be scalable including the capability for a distributed architecture with multiple
distributed peer workstations, performing concurrent task processing, supporting engineering, management and
development activities at various sites. The system shall be provided with adequate tools and utilities to monitor
the performances and to manage the resources of all subsystems.
Database Structure
The database structure shall be specifically designed for high performance real-time operation. A proprietary
hierarchical database will be acceptable for reasons of providing high performance and fast response times.
12 of 40
The real-time database shall be accessible via ODBC interfaces to import and export data from the SCADA
database to standard commercial applications such as Microsoft Excel or Access.
On-line database editing capability for adding, replacing or deleting points in the database, RTUs,
communication lines, etc, shall be possible without any interference to the system operation.
A user-friendly graphic editor shall be provided for building of new global maps and displays and for editing
existing ones through interactive and intuitive methods.
Access to capabilities of editing both the database and displays shall be available at all operator and
engineering workstation consoles; however it shall be restricted only to users with appropriate rights and
privileges.
The system database size shall be able to be expanded to handle additional points without any need to expand
the hardware, perform any software change, or pay additional licenses.
Historical Database
The historical database shall be able to store any data from the real-time database on a periodic or snapshot
basis definable by the user. The historical information subsystem shall be able to provide storage of unlimited
quantities of historical data depending only on the limitation of hardware resources (disk storage, etc). The
stored historical data shall be accessible to other applications for data review and analysis and to trending
displays.
The underlying platform of the historical information subsystem shall be a commercial, industry standard
RDBMS (Relational Database Management System) such as: MS SQL Server, Oracle, and Sybase. The
preferred RDBMS platform for this project is MS SQL Server.
13 of 40
CHAPTER 5 - SYSTEM FUNCTIONAL REQUIREMENTS
Data Acquisition
The proposed system shall be able to provide the following data acquisition functions:
a. Monitor analog values such as Volts, Amps, Watts and VARs at each substation. Convert these values
to a digital format. Transmit changed values back to the Master Station. Convert these values into
engineering units. Display these values on single line diagrams and provide alarm limit checking.
Provide historical storage at user definable interval and retention periods.
b. Monitor the status changes of various switch contacts and other equipment in the field. Provide an
audible and visual alarm when the switches have changed status without being commanded.
c. Accumulate kilowatt-hour pulses from pulse initiators at each substation. Provide a freeze of counts by
RTU on a user definable interval. Transmit the counts back to the Master Station. Convert the counts
into interval and hourly deltas. Provide historical storage at a user definable interval and retention
period.
Supervisory Control
The proposed system shall be able to provide the following supervisory control functions:
i. Allow the system operator at the Master Station to issue controls to trip and close breakers through a
select -before -operate sequence and automatically monitor breaker auxiliary contacts to ensure
operation,
ii. Allow the operator to manually control load tap changers and monitor the tap position,
iii. Allow the operator to manually control the circuit breakers.
iv. Allow the operator to provide output pulses to generator units. The system shall be able to download
both a variable number of pulses and a variable length pulse.
V. Allow the operator to run a switching order sequence which allows the user to define various automatic
controls that occur under predefined conditions.
RTU Communication
The bidders shall list the available and proposed protocols that the proposed master station can support. As a
minimum, in addition to the protocols required for existing or proposed RTUs and IEDs, the master station shall
also have available, as options, such open protocols as DNP3.0, IEC 870-5-101 and Modbus for both serial
RS232 and IP -based network communication.
The software subsystem for the proposed protocols shall implement all features of the RTUs and IEDs that are
required by the City of Lodi. As a minimum, the following functions shall be included:
a. Rapid polling of RTUs for exceptions
b. Select -before -operate control execution
c. Variable control durations for momentary controls
14 of 40
d. Detect and report multiple changes of state between poll cycles , if the RTU does not buffer changes but
instead reports a "multiple change detect" bit
e. Automatic interleaving of multiple priority messages, e.g. automatic "fast scan" after a control and "error
scan" after a communication error
f. Scheduled accumulator freezes and polls
g. Scheduled integrity (general interrogation) polls
h. Time synchronization of the RTUs
Sequence of events data uploading and processing
When a user -definable error retry count expires for an RTU, the system shall declare the RTU failed by means
of a status point and an accompanying alarm. On RTU failure, the system shall mark all points that are
telemetered by the RTU as "telemetry failed". For each point, this telemetry failed quality code shall not clear
until a value is subsequently received from the point.
The user shall be able to define alternate communication ports (or IP addresses) that can be used to reach the
RTUs. On a series of communication errors with an RTU, the system shall switch ports after a user -definable
port retry count expires. A separate port status point for each RTU shall be maintained to indicate which port is
currently being used to poll each RTU. If the communication line is looped, it shall be possible to determine
between which two RTUs a break exists by examining the values of the port status points.
By manually setting the value of a port status point, it shall be possible for the user to force the system to use
only one port for the associated RTU. By manually setting the value of an RTU's status point, it shall be possible
for the user to shut down polling of that RTU. For each RTU, the system shall maintain communication statistics
in the form of analog points that may be viewed on displays, printed in reports, or stored in historical data files.
Such statistics shall include percentage of successful communication, number of timeouts and number of
security errors.
After an RTU has been declared failed, the system shall continue to poll it but at a reduced rate, for example:
poll only one failed RTU on each round-robin poll cycle. If all RTUs are failed on a communication line (on both
ports, if two ports are defined), the system shall declare the entire communication line as failed.
Each communication protocol software module shall support a communication monitoring facility that allows the
user to view the messages issued to and returned from the RTUs. The operator shall be able to monitor
individual RTUs or all RTUs.
Status Data Processin
The system shall be able to acquire process and display status points (single and multi -bit). Each status point
may have a control point associated with it. A control command shall initiate a timer to check if the back -
indication is received within a certain time period from the initiation of the control command and if not, an alarm
shall be generated. If a change of status is detected which is not the result of a control command, an alarm shall
be generated.
The system shall be able to process the following types of status changes:
a. 2 -state status. This type of input shall be used to indicate the status of a device that may be in one of
two possible states. The user shall be able to define the names of each state, e.g. ON and OFF, Open
and Closed. In addition, a color shall be associated with each state such that a normal state could be
green while abnormal could be red.
15 of 40
b. 3 -state status. These inputs are similar to the 2 -state status points except that the device may take on
any of three possible states. The user shall be able to define the names and colors associated with
each state, e.g. Open, Closed and In -transit, or Illegal.
c. Multiple State Change. This feature shall provide support for multiple status changes that result from
control commands. For each control point, it shall be possible to specify a list of up to 30 status points
that may change as a result of a command. If not all the expected transitions occur within the control
point response time-out, the system shall generate an alarm for the control point as well as an additional
alarm for each associated point that did not undergo the expected transitions.
Analoa Data Processin
The system shall scan every analog input in the RTUs at predefined scanning intervals. Any failure to complete
a scan shall be marked with a data quality flag. Also the system shall scan each analog input every second and
compare that input to the previously reported input. When the difference between these values exceeds its
reporting band, the analog value shall be reported (report -by -exception).
The master station shall convert each scanned analog point to engineering units whereby both the telemetered
and converted data shall be stored in the database. The user shall be able to specify the scale factor and offset
to represent the conversion factors for a linear conversion of the telemetered input values to engineering units.
The system shall be capable of checking the analog values for at least three sets of limits: warning, emergency
and reasonability. Each of these three sets of limits shall be provided wit an upper limit, a lower limit and a
deadband. The deadband associated with each limit is used to prevent multiple alarms from being generated
when the value hovers near a limit value.
To allow the removal of noise readings around the zero mark of the engineering scale, a range of engineering
values inside the point value range shall be specified which shall clamp the input value to zero. For example, if
the zero -clamp deadband s 3.0, any input value which is converted to between +3.0 and -3.0 engineering units
will be clamped to zero.
The system shall provide a rate -of -change for analog input values by computing the difference between the new
and previous value and dividing this by the difference between the current time and the time the point was last
updated. The rate -of -change shall be checked against the limits for rate -of -change.
Pulse Accumulator Data Processing
The system shall be able to process accumulators received from the RTUs. The system shall send a command
to freeze the accumulators either to all RTUs or to selected RTUs. However this freeze command shall not reset
the accumulators in the individual RTUs. Upon receiving the accumulator readings at the master station, the
system shall automatically calculate the difference from the last reading.
The system shall retrieve the hourly accumulators every hour from the RTUs and shall convert them to
engineering units. The system shall also be able to retrieve accumulators at user -definable intervals from 15 to
30 minute intervals.
Sequence of Events Data Processing
The system shall be capable of processing digital indications from the RTUs which are tagged with the time of
event occurrence (SOEs) provided that the RTU protocol supports this feature. The Master Station shall perform
a time synchronization of all the RTUs which are equipped with SOEs. The system shall provide a separate
SOE Summary List with the chronologically or reverse chronologically sorted SOEs.
16 of 40
Control Output Requirements
The system shall perform all control operations to field devices in a safe secure manner. The operator shall be
promptly informed if any anomalies occur during the control sequence. There shall be the following types of
controls available in the system: control & indication, raise/lower control, analog output control, pulse output
control.
The control & indication type shall be used for controlling the status of breakers, recloser circuits, ground
circuits, line switches and similar devices. This type of control shall be able to accommodate either a single
sending contact (two -state control & indication) or two sensing contacts (three- or four -state control & indication)
per point. The raise/lower controls shall be used for controlling tap changes, control valves and similar devices.
The analog output control shall be used for providing setpoints to local controllers (generation controllers,
pressure controllers, flow controllers, etc). The pulse output controls shall be used for generator control and
shall be provided with either variable duration pulse or a train of pulses.
Where supported by the RTU protocol, the system shall utilize a Select-Checkback-Execute technique that
requires secure handshaking with the RTU before any controls are executed. In such cases, control of a point
requires the following exchange of messages:
o Master to RTU - control point selection
o RTU to Master - point address check -back
o Master to RTU - control execution
o RTU to Master - execute acknowledgement
If the Master Station does not receive proper acknowledgement of either the select request or the execute
command, a check -back failure alarm shall be generated by the system. If the acknowledgements are correct,
but the expected status change does not occur within the point's control response timeout, a control failure
alarm shall be generated. An optional multiple status change validation feature shall be available to handle
cases where a control causes multiple status changes to occur.
Areas of Responsibility
The SCADA software shall be able to be partitioned into 128 areas (or zones) of responsibility. The user shall
have the ability to assign any combination of the 128 zones to each database point (telemetered or calculated)
and/or to each login account. Examples of how zones may be used to partition the system are into separate
utilities, if the system is a combined electric, gas and water system, or into high voltage and low voltage circuits,
if the system is an electric distribution network and operators have different license requirements for different
voltage levels.
The user shall be able to create any number of zone groups containing various combinations of the 128 zones
and to give each zone group a name. In addition, each user account shall specify the types of activity that are
permitted for that user. These individual user privileges must be individually enabled or disabled and should
consist of such activities as point editing, report editing, alarm acknowledgement and blocking, manual set and
control, and tagging. An operator shall be able to manipulate only those points whose zones overlap those of his
login account.
Tag Management
When a controlled device or a line fed by a controlled device requires maintenance, it is required that the system
provide a facility for limiting control of that device. The system shall allow operators to inhibit control of devices
17 of 40
by means of a secure, multi-level tagging feature. This feature shall allow operators to apply up to eight tags to
each point, each tag being stored with a date/time stamp and optional operator -entered description. Each point
shall be able to be provided with a visual attribute showing that the point has one or more tags on each display
where that point is shown. ). It shall be possible to create tables of symbols that are to be displayed on tagged
points. If a point is tagged, the display shall show the symbol that corresponds to the highest -level tag on the
point.
The system shall provide the capability to configure a custom set of tag types that are mapped to the following
four basic types of tags: Inhibit ON and OFF controls, Inhibit ON control only, Inhibit OFF control only,
Information only (no control inhibit). The system shall permit no means of bypassing the control inhibit caused
by a tag. This applies to any and every application supplied by the vendor or written by the City of Lodi using
the vendor's API.
A group tag function shall be provided that allows an operator to define a tag, select multiple points and apply
the same tag to all selected points.
Calculations
The system shall include a periodic calculations program that allows the user to define both arithmetic and
Boolean calculations.
The following built-in functions shall be available:
a. Arithmetic (+, -, *, / ) operations
b. Boolean (AND, OR, XOR, NOT) operations
c. Comparisons (GT, LT, EQ, etc)
d. Trigonometric functions (sine and cosine)
e. Exponential and natural logarithm
f. General digital filter
g. Minute/hourly/daily/weekly/monthly sample
h. Minute/hourly/daily/weekly/monthly reset
i. Average over time
j. Current date and time
k. Accumulated time open/closed
I. Hourly/daily maximum, minimum and average
m. Normalized rate accumulation
n. Interlock (inhibit control)
o. Setpoint Deviation
The user shall be able to create custom complex functions using expressions and a high-level language similar
to or identical to that offered in the Command Sequencing option described below.
Command Sequencing
As an option, the proposed system shall provide an object-oriented visual programming development
environment to allow the user to develop custom calculations and control programs. Since this environment will
be used by non -programmers, the program development tools shall be intuitive and similar to other popular
visual development environments such as Microsoft Visual Basic. The programming environment shall allow the
user to select a statement from a menu leaving the user to just insert the arguments.
The environment shall support comments and all of the functions described below:
• Math/logic functions, with following expressions:
18 of 40
➢ arithmetic
➢ logical operators (AND,OR, NOT, XOR)
➢ magnitude comparison
➢ absolute value
➢ integer truncation
➢ square root
➢ circular functions (SIN, COS, TAN, ASIN, ACOS, ATAN)
➢ exponential & logarithm
➢ maximum and minimum in list
➢ time/date
• Read and write status and analog points. Full alarm processing on calculated results.
• Issue controls and setpoints.
• Raise alarms.
• Add and remove tags.
• Issue hard copy report requests.
• Call other command sequences as subroutines.
• Conditional (IF -THEN -ELSE) branching and DO WHILE loops.
• Variable delay commands
• Two-dimensional table look -up in arrays of up to 256 x 256 elements
The system shall provide the capability to build customized template functions which become part of the library
of functions available for use in command sequences and calculations.
Graphical User Interface (GUI) Environment
The operator interface shall utilize the Windows graphical user interface (GUI) environment, making extensive
use of mouse point -click -drag functions, pull-down menus and interactive dialog boxes. The operator interface
should support the display of multiple windows that can be re -sized, moved, overlaid in a tiled fashion, or shrunk
to an icon.
Operator Displays
The system shall provide the following types of displays for use by the operators:
o Global Map Display. This type of display shall consist of a high-resolution vector map of the
user's network with the current analog values and status of devices superimposed on the
map. The display shall allow the operator to select displayed objects in order to issue or
inhibit controls, acknowledge or block alarms, or modify operating parameters such as
limits.
o Alarm Summary Display. This type of display shall show a user -customizable list of alarms
that are in the system. The operator shall have the ability to acknowledge and/or block
alarms and to control the operation of the audible alarm. This display shall be configurable
by the operator by means of filtering by station, zone of responsibility, alarm priorities,
19 of 40
chronological or reverse chronological order, typeface and size of text, blocked alarms, any
combination of active, cleared, acknowledged or unacknowledged alarms.
o Operator Summary Display. This type of display shall show the operations messages that
have been logged by the system. This display shall be configurable by the operator by
means of filtering by alarm priority, station, zone of responsibility, specific database points,
time range, typeface and size of text.
o Tabular Data Display. This type of display shall list the status and analog points by station
and systemwise. The information shown on this display shall include the point names,
descriptions, current values and quality codes and other parameters from the database, e.g.
transition counts and alarm limits. This display shall be used for operation and control in the
sense that from this display, the operator can perform point operations such as control, tag,
alarm acknowledge or block, as well as modify operating limits and reset transition counts.
Global Mao Disola
This display shall consist of a high-resolution environment in which the operator uses a movable window on a
large-scale global map. The operator shall be able to navigate through the map using convenient mouse -
oriented tools that include continuous panning and zooming, as well as poke points that cause the global map to
jump to pre -defined displays. A user -extendable library of ready -to -use symbols, colors and text styles shall be
provided.
Methods of navigation within the global map display shall include the ability to continuously pan and zoom, to
jump to other displays at pre -defined locations and magnification levels and to snap to a view that is defined by
rubberband mouse operation, i.e. a view selection rectangle. The global map display shall be implemented in a
multilayered structure. When a map is imported from a DWG or DXF file, the layers that are contained in the
DWG/DXF file should be preserved in the resulting SCADA global map. There should be no upper limit on the
number layers that may be contained in the global map.
It shall be possible to assign a specific zoom level to each layer for automatic de -cluttering. Such assignments
should be easy to make by navigating to desired zoom levels and clicking on pushbuttons in a dialog fashion.
De -clutter levels shall not be lost when the map is re -imported from an updated DWG/DXF file. The operator
shall have the ability to override the automatic de -cluttering and manually either turn a layer on or off regardless
of the current zoom level. By organizing layers in a hierarchical system of folders, it shall be possible to easily
turn entire folders of layers on or off. The system of folders shall be preserved when the map is re -imported from
an updated DWG/DXF file.
The user shall be able to specify the number of alarm lines for the unacknowledged alarms to be displayed in an
alarm banner at the bottom of any display. The alarm banner shall not resize when the operator zooms in or out
on the global map display. The operator shall be able to temporarily resize the alarm banner by dragging the
frame separator, showing more or less alarm lines. The operator shall be able to toggle the alarm banner on or
off. It shall also be possible to acknowledge and/or block the alarms that are displayed in the alarm banner via a
pop-up menu. The user shall be able to represent status points with animated GIF (Graphics Interchange
Format) files. Animated GIFs are a popular way to display the change of state of a device, or motion such as a
pump in operation. The operator shall be able to set the blink rate to control the speed of the GIF file.
It shall be possible to use bitmaps (image files) rather than symbols to represent status points, station points,
and pushbuttons. The displayed bitmaps should scale as the user will zoom in and out. The supported bitmap
file types shall include GIF, JPG and BMP. The user shall have the ability to create any number of views within
the global map display. The views may be accessed via a scrollable list box or via pushbutton (poke points) on
the global map display. For ease of navigation in the views list box, it shall be possible to organize the views in a
hierarchical system of folders. Both the folders and the views themselves shall be preserved when the map is
re -imported from an updated DWG/DXF file.
20 of 40
Notes
The displays shall support a system of "post -it" notes that allows operators to add and remove note icons on any
display. Clicking on a note icon shall cause a pop-up window to appear to show free -form notes on any topic.
The notes can be entered and modified in this window.
The system shall also support notes that are specific to database points. Such notes shall be accessible from a
pushbutton in the point dialog box that appears when the point is selected. When a point has some notes, the
pushbutton icon in the dialog box shall be highlighted.
Point -specific notes shall also be accessible from the alarms display. When a point -related alarm is selected, a
pushbutton in the tool bar should highlight if there are notes for the selected point. Clicking on this pushbutton
shall bring up the point's notes.
Drawing File Import
The proposed system shall provide the capability to import graphics from other drawing packages (e.g.
AutoCAD and GIS systems) via direct DXF and DWG file import. The layers contained in the DXF/DWG file
shall be preserved as layers in the SCADA global map. The symbols, colors and text styles contained in the
DXF/DWG file shall be imported into the libraries used by the SCADA global map, where they may be edited or
used as is in dynamic map elements.
The system shall allow the import of multiple DXF/DWG files into the same SCADA global map. It shall be
possible to subsequently re -import an updated DXF/DWG file and have its layers replace the corresponding
layers in the existing SCADA global map without disturbing the graphics contained in the other layers of the
SCADA map.
Control Panels
As an option, the proposed system shall include the capability of Control Panels as a tool for visualizing the data
collected from IEDs in the substations.
The Control Panel shall be provided as a rapid graphical user interface (GUI) development tool that is built into
the operator interface. It allows dynamic elements and database values to be superimposed over a picture.
Although any picture may be used, the most common application shall be a picture of the front panel of an IED.
In the case of an IED, the Control Panel operates in the same fashion and displays the same information as if
the operator was standing directly in front of the device in the substation. For each IED in the substation, the
user shall be able to simply select the template and to specify the station name of the IED. The system shall
take care of instantiating all of the indications and controls.
It shall be possible to use picture files (*.bmp, *.jpg, *.gif) in the system GUI as well as to overlay pictures with
dynamic elements of indication, analog values, and control. The user shall be able to create custom control
panels and to use points from up to four different IED's in each control panel. The successful bidder shall supply
a library of control panel templates for the most common IEDs available.
Full Graphics Editor
A full graphics editor shall be provided as an integral part of the database and display building tools. Access to
the editing capabilities shall be available at all local and remote consoles; however it shall be password -
protected. A copy of the global map and supporting libraries shall reside on each workstation console, such that
21 of 40
when viewed in live mode, only dynamic data such as point values and alarms shall be retrieved from the host
server in order to minimize network traffic and make feasible dial-up connections even with large displays.
Publication of changes to the displays and libraries to other workstations shall be via standard file transfer
mechanisms.
The full graphics editor shall allow the user to create any number of layers and displays of the global map. The
editor shall allow the user to assign zoom levels to each layer for automatic decluttering. The editor shall allow
the user to specify an image file for any display that is to be used as a background for the display. The image
file formats that can be used for this shall include JPG, GIF and BMP.
The full graphics editor shall contain easy-to-use tools for re -layering, re -coloring and re -styling (text) as well as
duplication (copy/cut and paste), stretch and re -size. The full graphics editor utility shall provide topological
support. It shall allow consistency checks between the graphical display and the corresponding database.
Connectivity information shall be stored in the database in order to allow the topology to be dynamically
changed.
Drawing Tools
The proposed system shall include drawing tools as part of a full graphics editor to allow the user to add to
and/or modify the drawings that were imported via DWG/DXF file. The drawing tools that are provided in edit
mode shall include at least the following capabilities:
a. draw line
b. draw rectangle (open and filled)
c. draw polygon (open and filled)
d. draw circle and ellipse (open and filled)
e. draw arc (open and filled)
f. insert text
g. insert symbol
h. insert dynamic element (e.g. point or poke point)
The following editing functions shall be provided:
o cut and paste
o rotate
o snap to grid
o stretch
The following alignment tools shall be provided:
o Align objects left
o Align objects right
o Align objects top
o Align objects bottom
o Center objects vertically
o Center objects horizontally
o Distribute objects vertically
o Distribute objects horizontally
o Distribute objects matrix (user details the number of rows and columns)
o Resize to maximum selected object height
o Resize to maximum selected object width
o Resize to maximum selected object height and width
o Resize to minimum selected object height
o Resize to minimum selected object width
22 of 40
o Resize to minimum selected object height and width
The editor shall support at least 99 undo and redo editing changes.
The user shall be able to create libraries of the following:
o drawing styles (colors and line styles)
o text styles
o symbols
o dynamic elements
The system should include an initial ready -to -use set of such libraries. On import of a DWG/DXF file, the colors,
text styles and symbols that are contained in the DWG/DXF file should be imported into the libraries, where they
may be customized or just used as is.
The display editors shall allow the user to define displays of dynamic data fields as follows:
L analog values
ii. status values
iii. station alarm status
iv. remote station status
V. dynamic line segment coloring
vi. historical data trend graphs
vii. text strings
The proposed system shall provide the capability to display a telemetered or calculated analog value in the form
of a numeric string, horizontal or vertical bar graph (the length of a bar graph reflects the value of the analog
point), or in an analog gauge. Both numeric strings and bar graphs shall be color -coded to reflect any violation
of alarm limits. The color -coding shall be user -definable. It shall be possible to create multiple color -coding
schemes. Analog gauges shall have the capability to represent a meter or dial type gauge. The user -definable
properties shall include: angle start, angle length, dial color, dial direction, label properties, limits properties,
major/minor divisions, needle properties, and the radius. The proposed system shall provide the capability to
display the state of a telemetered or calculated status point by means of a user -definable dynamic element that
specifies one of the following:
o a set of four symbols
o a set of four text strings
0 one symbol and a set of four colors.
Two -state points shall use only two of the four symbols, strings or colors.
Data Quality
The proposed system shall provide the capability to display data quality indications adjacent to each analog
value or status point indication. These shall include the following as a minimum:
a. telemetry failed
b. manually set
c. calculated from manually set data
d. alarm blocked
e. out -of -range
f. tagged
g. interlocked
23 of 40
Database Editor
The system database shall be defined and maintained with the help of an interactive database editor. The
database editor shall be of Windows dialog style and shall be supported by a detailed database manual that
explains the format, purpose and interrelationships of all database fields.
The database editor shall provide a graphical tree -like representation of the complete database and shall
support easy navigation throughout the database to the desired items to be edited. Database items to be edited
in this way shall include Stations, Communication Lines, Communication Channels, RTUs, IEDs, as well as all
the individual database points (analog values, status indications, accumulators, etc). The database editor shall
operate as a "client" program which communicates with a "server" program running on the host computer.
However the database editor shall be able to run on any computer that is connected to the host server via the
network. With this arrangement, it shall be possible to manage the database maintenance from any suitably
configured PC on the network without being necessary to go to the control room to do it.
The database editor shall include features which will make it easy to create and modify the database such as:
1. using the Station Cloning feature to create an entire new station and all its points, based on an existing
station;
2. copying, cutting and pasting in the Windows environment;
3. using a model feature to create points and other database items that are based on previously created
ones;
4. using a Station Rename feature to copy a portion of an existing display, and to reassign all those
dynamic points to points in a different station, all in one operation;
5. editing or modifying the database on an MS Excel spreadsheet and importing it into the system real-
time database;
6. deleting existing database points;
7. providing a consistent "look and feel" to the system.
All changes and updates of the database shall be completed and validated while the system is in online
operation. Under no circumstances shall the real-time system operation be interrupted or disturbed by the
database editing and maintenance process.
IED Wizard
The proposed system shall provide an IED Wizard feature which automates the creation of the database for an
IED. In just a few simple steps, it shall be possible to create not only the required points in the real-time
database system, but also, for an IED that is a slave to an RTU, the mapping of these points for automatic
download to the RTU.
The IED wizard shall contain an extensive library of the most common IEDs that are available on the market.
The mapping process shall be based on a series of intuitive templates that will guide the user through the
process. The user shall be able to select from a list of devices for each IED vendor, specify a unit address and
the point group, and drag the point group into the RTU's point map. All of the telemetry and control addresses
and RTU -to -IED mapping shall be automatically generated. The IED Wizard should completely eliminate the
tedious error -prone data entry of telemetry addresses and mapping tables.
The user shall be able to create for each IED multiple templates with different sets of point definitions. The
vendor shall supply tools for creating templates for those IEDs or devices that are not in his current library.
Templates shall be easy to modify and an unlimited number of different versions or variations of the same or
similar templates shall be possible to handle for use in the system.
24 of 40
User Rights and Privileges
The proposed system shall provide for a highly secure environment which only allows authorized users to
interact with the system and its database. There shall be user names and passwords assigned on all servers
and workstations for general operating login. There shall also be user names and passwords assigned on all
workstations for login to the SCADA functions. The user name, password and user rights shall be defined in a
user account. Each user account shall be assigned a set of user rights that determines the actions that the user
may take. This shall provide individual control over various operating and editing functions. As a minimum, the
user rights for normal operation shall determine the access of a user to the following functions:
1. alarm acknowledge
2. alarm page acknowledge
3. alarm block
4. alarm unblock
5. alarm station acknowledge
6. alarm silence
7. manual set operations
8. control points operations
9. activate points operations
10. tag points operations
11. run command sequences
In addition, the user rights for changes to the system shall determine the privileges of a user for the following
functions:
a. edit database
b. edit display
c. edit report
d. edit analog limits
e. edit notes
f. edit control sequences
Each user account may also be assigned Privilege Mode or Training Mode. If neither of these is assigned, the
user is in Normal Mode. Privilege Mode shall be required to access certain high-level functions in the system
depending on the applications. Training Mode shall restrict the operator to only those stations in the database
that are also in training mode. This shall prevent the operator from controlling real system devices in training
mode. Each user's account, functional levels, zones of responsibilities, etc, shall be controlled from an access
management set of displays. Only the system administrator shall have the right to edit and modify the access
management displays.
The proposed system shall be able to handle an unlimited number of user accounts with their corresponding
user rights and privileges.
Alarm Processing
The system shall alert he operator when abnormal conditions or certain events that are designated as being
important occur such as:
a. any uncommanded change in a status input or calculated status;
b. any analog input or calculated value that crosses over any defined alarm limits;
c. any commanded change of a control & indication point that does not result in a back -
indication within some specified period;
d. any failure of the Master Station to communicate with any RTU;
25 of 40
e. any failure of a given RTU to respond correctly to a previously specified number of
interrogations;
f. any failure of a major component of the SCADA system.
Alarms and operational events shall be continuously synchronized in real-time to the standby host server, in the
case of a dual -redundant system configuration.
The proposed system shall be able to handle a minimum of 100 alarms or events per second per operator
consoles regardless of the other workload.
Alarm Priorities
The system shall provide at least five (5) alarm priority levels. Alarms with priority zero - the lowest, shall be
considered to be pre -acknowledged. Such alarms shall neither sound any audio alarm signals nor cause points
to flash on the display. Higher priority alarms shall require acknowledgement and shall sound audio alarm
signals. The audio alarm signals shall consist of .WAV files that can be assigned to each priority. All alarms shall
be logged regardless of priority to at least three destinations: alarm summary displays, event printers and
operator log files.
For each status point, it shall be possible to define which state (0 or 1) is abnormal and to assign a separate
alarm priority to each state. When either the select or execute check -back fails, the system shall generate a
check -back failure alarm. If the check -back is successful but the expected status change does not occur within a
timeout period that is user -definable for each control, the system shall generate a control failure alarm.
For each analog point, the user shall be able to define three sets of nested upper and lower alarm limits, with a
separate deadband for each limit. In addition, analog points shall be able to generate an alarm when a rate of
change is exceeded, either in the increasing or decreasing direction, or both. Each alarm limit shall support a
separate alarm priority. The system shall provide the operator with a visible "telemetry failure" indication when
the value of any displayed point is not currently being updated by the system because of an RTU or
communication line failure. Any points that are calculated using, as inputs, the values of other telemetry failed
points, shall also be marked telemetry failed.
The user shall be able to specify any Windows sound file (*.WAV) to be used for the audio alarm signal. The
system shall allow the user to browse for sounds and to test play the selected sounds. The system shall allow
different sounds for each alarm type and a different set of sounds for each workstation.
Alarm Formatting
The user shall have control over the format of alarm messages by means of alarm format statements. As a
minimum, the message format editor shall allow the user to incorporate the following into the alarm messages in
any desired sequence:
a. strings of fixed text
b. name of the point in alarm
c. point description
d. station name of the point in alarm
e. station description
f. alarm priority level
g. point value or status
h. alarm limit that was violated (for analog limit violation)
i. calculated rate -of -change that violated the rate -of -change limit
j. point engineering units
26 of 40
The system shall provide summary lists for all unacknowledged, acknowledged, blocked, suppressed and for all
alarms. The user shall be able to perform alarm filtering based on certain parameters or filters. The filtering of
alarm summary lists shall be performed from a template where the operator can enter the filtering parameters
and obtain the filtered lists.
Master/Slave Alarm Suppression
The proposed system shall provide a Master/Slave Alarm capability that allows the user to define a hierarchy of
primary/secondary (master/slave) alarm point relationships. This feature shall allow the user to focus on the
conditions that are the real cause of a disturbance by filtering an avalanche of alarms and presenting to the
operator only those that are really important. The master/slave relationship may be used for either or both of the
following purposes:
o Alarm Suppression
If the alarm suppression function is enabled for a particular master/slave relationship, then as long as
the master point is in the alarm state, alarms on its slave points will be suppressed (i.e. the alarm
severity is reduced to zero). The suppression may be specified to be either time-limited or indefinite.
o Group Acknowledgement
If the group acknowledgement function is enabled for a particular master/slave relationship, then
whenever the user acknowledges alarms on the master point, he/she also acknowledges alarms on its
slaves.
Each master point shall be able to have any number of slaves, each slave shall be able to can have any number
of masters, and a slave shall also be able to be a master and have slaves of its own.
The Master/Slave Alarms option described above shall also allow the user to suppress alarms of any desired
priority (typically the low priorities). This feature shall allow the user to exclusively focus on the most critical
alarms in the system and once these have been handled, the operator can look at the lower priority alarms.
Alarms that are suppressed in this manner shall be hidden from the alarm lists until the user un -suppresses the
corresponding alarm priorities. The alarms must be recorded in the database, however, and become viewable
as soon as the suppression is removed. Such alarms should be automatically acknowledged when they become
viewable.
The above features shall be fully integrated into the SCADA system with no need for any third party software.
Remote Alarm Annunciation
The proposed system shall have the ability to remotely transmit any pre -defined alarm condition to any
commercial paging system, e-mail or SMS (short -message -service). There shall be no limit in the number of
alarm conditions that are required to be remotely annunciated. This function shall be fully integrated into the
SCADA system and no third party software shall be required to achieve the functionality. The communication
between the remote alarm annunciation system and the annunciation providers shall be available over serial
connections, e.g. modems, as well as over TCP/IP wide area networks, e.g. Ethernet, VPN, Sonet/SDH,
satellite, etc.
The system shall have the capability to send e-mails for alarm messages. The user shall be able to define which
points are annunciated in this fashion, and for each point, which alarms, e.g., which states for a status point and
which limits for analog point. The system shall also have the capability to call a central paging computer service
to forward alarm messages to digital pagers. The user shall be able to define which points are annunciated in
this fashion, and for each point, which alarms, e.g. which states for a status point and which limits for analog
point. The pagers shall be identified in up to eight groups, with up to 30 pagers per group. For each group, the
user shall be able to specify the telephone number of the paging computer, and the alarm priorities and zones of
27 of 40
responsibilities of the alarms that are to be sent to those pagers. The same alarm may be directed to multiple
pager groups.
The user shall be able to define a schedule for remote alarm annunciation so that it starts automatically after
hours and turns off automatically in the morning. The user shall also be able to specify an annunciation time
delay, so that if someone is in the building but not in the control room, he/she will have time to come back to the
control room and respond to the alarm before someone is paged. The user shall be able to specify a re -
annunciation time interval, such that if the alarm is not acknowledged after this time interval, the page will be re-
issued.
External Alarm Bell
For operations under noisy conditions or remotely from the control room, the external alarm bell feature shall be
used to control (activate/de-activate) several different external alarm bells based on alarm priorities for any of
the alarm zone groups. A local RTU may be required for enabling the control of the external alarm bells. Audible
alarms shall still be generated at each workstation by the operator interface.
Event Data Recording
The SCADA system shall maintain an event file that records all status changes, operator controls and SOE
data. This file shall be re -sizable to store several million events, if desired. Non-SOE events shall be time -
stamped to the nearest second. SOE data shall be stamped to the nearest 1 millisecond, subject to the
capabilities of the RTU protocol. The operator shall have the ability to request event data reports with time range
and point search capabilities.
Report Generation
The system shall support a report generation capability that will allow the user a high level of flexibility in the
definition, formatting and scheduling of on -demand and periodic reports. The reports shall include data from
both the real-time database the historical database. The system will allow the user to schedule reports for
automatic printing or saving to hard disk files for subsequent transfer to CD or tape. The system shall use
commercial tools such as Miscrosoft Excel and Access to generate the reports.
Report Editor
A report editor shall be available to allow the user to define reports by specifying a database table, a set of
desired data fields and the selection criteria for retrieving records from the database table. In a report definition,
the user shall be able to specify:
a. Choice of database table to access (e.g. status points, alarm file)
b. Choice of the data fields available in the chosen table
c. Filtering by the value of any data field in the selected table
d. Ordering data by value of any data field
e. Grouping of displayed data according to any data field
Examples of such selection and filtering requests are reports for:
1. points in specific "point type" categories
2. points in certain stations
28 of 40
3. points in certain zone(s) of responsibility
4. points associated with a specific communication line
5. points that are manually set
6. analog values that are in out -of -range condition
7. points that are tagged
8. points in alarm condition
A graphical report in the form of scheduled prints of selected views of the global map shall also be provided. The
system shall include a scheduling facility that will allow the operator to define the schedules and destinations for
all reports. It shall be possible to direct a scheduled report to multiple printers, one or more of which can be
directories on disk.
Data Exhort to MS Excel and MS Access
The proposed system shall be provided with direct interfaces using open standards such as ODBC, DDE and
SQL that will allow the user to export real-time and historical data from the SCADA system to MS Excel and MS
Access. All data points in the database, not just values, shall be available for export.
The user shall be able to specify the desired data fields, the column headings, as well as to define compound
selection criteria that will filter the data to be exported, e.g. Value > 100, or Value < 100. The process shall not
require any programming by the user, but rather a direct pointing by mouse clicks to the data desired to be
included in the spreadsheet. The user shall be able to save multiple queries on the same spreadsheet or on
multiple spreadsheets and to have queries automatically executed when the spreadsheet is invoked.
The system shall provide the ability to set timers to have one or more queries periodically executed at fixed time
intervals as well as on a pre -defined change.
Data Collection and Storaae
The system will provide a historical data collection facility that allows the user to define the points that are to be
sampled, the sample frequency and how long to retain the sample data. In each dataset, the oldest samples
should be overwritten by the newest.
The collected historical data must be able to be trended, included in reports, exported to MS Excel or MS
Access or transcribed to relational databases.
The historical data software shall be capable of sampling at intervals as low as 1 second. There should be no
upper bound on the duration of samples within each dataset, and thus no upper bound on the amount of
historical data that can be stored other than the limitation imposed by available disk space.
The historical data software shall allow the user to specify recording of statistics in the sample records. The
statistics shall include time averages, summations, maximums and minimums, and times of maximums and
minimums and shall be based on user -definable observation intervals.
The system shall also allow the user to create "secondary" datasets that extract information from primary
datasets. For example, a primary dataset could contain 15 -second samples for several days. A secondary
dataset could extract daily maximums and minimums, as well as the times of the maximums and minimums and
record these for ten years.
29 of 40
Historical Information Svstem
As an option, the proposed system shall provide a Historical Information System (HIS) function which allows the
user to transcribe real-time database values, historical data, operation messages and alarm and event logs
including SOEs onto a relational database management system. The HIS function shall use as a platform any of
the established commercial relational database management systems including MS Access, MS SQL Server,
Oracle, etc.
The ability of transcribing the current real-time database values shall be bi-directional, i.e. it shall be possible to
transcribe data from a table into a relational database into real-time database points. If a real-time database
point is manually set, the transcription program shall not update it.
The system shall provide the ability to transcribe data to multiple databases on multiple platforms. For each
target database, the user shall be able to specify exactly what is to be transcribed, e.g. what points and what
historical data tables. Also the user shall be able to specify the schedule of transcriptions.
The transcription process shall maintain a connection to the currently active host computer during a failover from
one host to the other. The transcription process shall be able to keep track of where it left off since the last
connection, and in case of a period of downtime, it shall be able to recover all historical data that was not
transcribed during the downtime.
Data Trending
The proposed system shall provide the ability to store and view any data value from the database in a trend
graphical format. The system shall bring up pixel -resolution trend graphs of historical data. Sample rates as low
as 1 second must be supported.
Trend graphs shall be displayed in separate windows that can be moved, re -sized and minimized to an icon.
The trend graph window shall include tools that allow the user to configure and customize the graph display. A
trend graph window shall have the ability to plot at least five points from the historical database. The trend graph
displays shall be interactive allowing the operator to quickly adjust the time frame, duration and resolution of the
graph.
In cases where there are more samples in the dataset than can be displayed in the graph window, it shall be
possible to scroll back in time. It shall be possible to see the numeric values and time -stamp of the traces at any
time position in the graph by manipulating a time cursor inside the trend graph.
The user shall be able to display trend comparison graphs from left to right, for at least five comparison trends.
In trend comparison graphs, the time origin at the extreme left of the graph is a fixed time of the day; however it
may be a different day for each trend. The purpose of this is to allow the user to observe the build-up of the
current day's trace, e.g. a load curve, against that of other days in the past, typically the days that contained the
last week peak or the current month peak, etc. The trend comparison graph shall have an option to set a start
time and day of the week so that the trend graph is automatically launched.
Disturbance Data Capture
The proposed system shall provide a disturbance data capture function that allows the user to analyze the entire
state of the system leading up to, during and after a disturbance. All changes in analog and status points
system -wide are recorded when a user defined disturbance is detected.
The user shall be able to define the pre- and post -disturbance duration and sampling rates. The pre -disturbance
duration shall be definable from 1 to 15 minutes with a sampling rate of 15 seconds to 15 minutes. The post -
disturbance duration shall be definable from 1 to 15 minutes, with a sampling rate of 5 seconds to 15 minutes.
30 of 40
A disturbance data capture editor shall be provided that allows the user to specify which points can trigger
disturbance captures, and for each point, what would signal a disturbance. Status can trigger a disturbance
capture for any change of state which is either Abnormal, or Open, or Closed, or any other change. Analog
points can trigger a disturbance capture for any limit violation. There should be no limit other than that imposed
by disk space on the number of disturbance capture files that can be accumulated.
The system shall keep a log of all disturbances, detailing the date and time of the disturbance, the point that
triggered the disturbance, the reason code, and the recorded length pre- and post -disturbance. The disturbance
data capture shall include a viewer facility which allows the user to analyze points from anywhere in the system
for a given disturbance. The viewer facility shall also allow the user to select any disturbance file and export it to
commercial applications via ODBC or SQL for further analysis.
Ooerations and Outaae Accountin
The system shall provide a function that maintains operations and outage accounting data for user-specified
breakers. Operation counts for both commanded and uncommanded operations shall be maintained for each
breaker. An alarm shall be generated when the total operation count for a breaker exceeds the user -definable
limit for that breaker.
A Device Operations Report shall be available for each breaker showing the date and time of last operation,
number of operations caused by control, or caused by protective relaying, operation count limit, number of
operations divided by operations limit as a percentage, and limit status: OK, Warning, and Exceed.
The report shall highlight devices whose operation counts are within a user -definable percentage of their
warning limits, or that have not been operated for a user-specified number of days.
An Outage Report shall be available showing, for each outage in the last N days, where "N" is user-specified,
the name and description of the device, date and time of the start of the outage, and the duration of the outage,
three phase currents that were present immediately before the outage, and a summary of the accumulated total
outage time for each device during the requested reporting interval. Outages that are less than one minute in
duration, and those caused by an operator initiated control shall be excluded from the outage report.
Ooerator Trainina Simulator
As an option, the proposed system shall provide an Operator Training Simulator (OTS) function that creates a
parallel real-time environment for training and simulation studies.
The operator training simulator shall include an instructor's control panel that allows an instructor to start and
stop the simulator, take current real-time database snapshots, save and load previously saved study databases,
and execute scripts. It shall not be necessary for the user to build a separate database and displays.
The operator training simulator shall provide the means to create simulation control files containing If -Then -Else
rules that determine how the simulator will react to the trainee's actions, or to events triggered by the instructor's
scripts. The instructor shall have the ability to maintain a library of simulation control files that have been pre-
defined for different operator responsibilities, or for varying levels of difficulty for the trainee.
To support What -If studies, it shall be possible to have operator interface windows open to both OTS and the
real-time system on the same workstation at the same time. The user should not have to log in and out to switch
between OTS windows and real-time windows. The operator interface windows that are connected to OTS shall
have some clearly visible distinguishing characteristic so that they are not mistaken for real-time windows.
31 of 40
ICCP (Inter Control Center Protocol) — TASE.2
As an option, the vendor shall propose a data link based on the ICCP protocol. ICCP (Inter Control Center
Protocol) is an IEC industry standard (TASE.2) for Master Station to Master Station communications. The ICCP
application shall consist of both client and server software. The client software shall connect to other members
on the network to request point data and forward control requests from operators and application programs. The
server software shall respond to client requests by returning the requested data and executing, if possible, the
requested controls.
The proposed system shall not have any limitation in the number of communication nodes (remote
clients/servers). No software upgrades or additional licenses shall be required to increase the number of
communication nodes to be accessed via ICCP. The system shall provide the ICCP function on the host
servers. It shall not be acceptable either to use separate servers to handle the ICCP function, or to use third
party software to achieve ICCP connectivity with other systems. This should ensure that it will not be necessary
to redefine the ICCP database points in other databases and/or servers other than the real-time database
servers. The proposed ICCP function shall include a database editor which allows the user to specify what data
points are to be transmitted to the partners. The selected data points may include status changes, analogs and
calculated values from the real-time database. Quality codes, such as manual set and telemetry failed, shall be
transmitted along with the data. In device control operations, tags on the server system shall be respected.
Any member of the ICCP network can act as either a client or a server or both. The relationship between any
pair of members may be fully bidirectional. That is, both members may act as both client and server to each
other. Furthermore, any member may act as a server to multiple clients, and at the same time act as a client
with multiple servers. Establishment of the connections shall be the responsibility of the client software.
The proposed ICCP software shall support at least the conformance blocks 1, 2 and 5.
Network ToDoloav Processor
A network topology processor shall be provided that calculates the energized/de-energized and
pressurized/depressurized status of electric, gas and water line sections, and displays them on global maps.
The connectivity calculation shall be based on the topology of the distribution system and the current status of
breakers or valves. For areas that are energized or pressurized, the connectivity calculation shall also indicate
where the network is paralleled and/or looped. When a circuit becomes de -energized, depressurized, or
paralleled and/or looped, an alarm shall be generated to alert the operator.
The color -coding used to indicate line section status shall be user -definable. Multiple color -coding schemes shall
be supported. The user shall be able to assign different energized colors to different feeders and have the
display propagate that feeder color to all line sections that are connected to that feeder. The user shall be able
to specify separate colors for looped and paralleled conditions.
For an electrical line section, the system shall compute the status of each phase independently, such that line
sections that are downstream of non -ganged switching devices may contain both energized and de -energized
phases. The user shall be able to specify colors for "partially energized" or "partially looped" etc.
The topology processor shall also be able to highlight portions of the network that have anomalies in the form of
limit violations and/or excessive rate of change for associated analog quantities. The analog points used for this
purpose shall be identified in the line section database. The user shall be able to specify colors to be used to
highlight all line sections downstream of such anomalies. The topology processor shall also include a feeder
trace function that allows the user to select a trace color and have the length of a feeder highlighted in the
selected trace color. Multiple simultaneous traces in different colors shall be supported.
The topology database shall be entered by means of an interactive graphical line section editor built into the
display editor. For an electrical network, the user shall be able to specify any combination of phases in each line
32 of 40
section. It shall not be necessary to use separate line sections to represent each phase of a circuit element that
is controlled by non -ganged switching devices upstream.
The user shall be able to call up the line section data by clicking on the desired line section on the display. The
line section data window that appears shall show the status of each phase contained in the line section, the
number of customers, and also identify the source feeder for each phase. If the selected line section is
downstream of a substation, the line section data window shall identify both the upstream substation feeders
and the transformer station feeders that feed the circuit. If the selected line section is above the substation level,
the line section data window shall only identify the upstream transformer station feeders.
Switch Order Preparation and Manaaement
The system shall provide a switch order preparation and management function. A switch order is a series of
steps involving both switching operations and tags that shall result into conditions for which a clearance may be
issued. Two types of switch orders are required:
• Order to operate
This shall be used to define switching actions and application of tags. An order to operate is executed prior
to issuing the accompanying clearances.
• Restoration order
This shall be used to define switching actions and removal of tags in order to undo the work performed by
an order to operate. The restoration order is executed after all of the clearances associated with the order to
operate have been surrendered.
Switch order editing should be interactive and be performed using the GUI (graphical user interface) by clicking
on the device to be operated and selecting from a menu the type of operation, e.g. open, close, tag, etc, and the
label to be used. If special conditions require an operation that is not in the operations menu, the user shall be
able to type in the desired operation. Similarly, if the equipment involved is not represented by a database point
in the SCADA system, the user shall be able to simply type in its name and location. Each switch order shall be
able to contain up to 200 sequences. It shall be possible to edit sequences in an exiting switch order and to
easily change the order of the sequences. The sequences shall be annotated by means of a short text string of
up to 20 characters. The annotation shall be done either during editing or execution of the switch order. It shall
be possible to frequently save used switch orders as templates for later re -usage.
Before a switch order can be executed, it shall be mandatory that it be checked (authorized) by having an
authorized person log in and click on a pushbutton. This would usually be done by a supervisor, but it shall be
possible for an operator to do it in an emergency. The check function shall be logged and the login account
name of the person who did it shall be included in the log message as well as displayed on the switch order
form. When a switch order is printed that has not yet been checked, the printout shall include the word
"unchecked" in the background. If a checked switch order is modified, it shall be necessary to have it checked
again before it can be executed. The user shall be able to create up to five associated clearances for each
switch order. A completed clearance record shall contain the following information:
o Title, type of clearance and job number
o Date and time the clearance was issued, and to whom
o Date and time the clearance was surrendered, and by whom
o Associated clearance number, entered if the clearance is issued on behalf of another company
o Date and time grounds were applied, recorded after the clearance has been issued
o Date and time grounds were removed, recorded before the clearance can be surrendered
o Reason for the clearance
o Remarks
o Up to 50 tags
33 of 40
Once a clearance has been issued, the operator shall not be able to change anything in the clearance until the
clearance has been surrendered, except to update the remarks field and to record when grounds have been
applied and removed. If a switch order has an associated clearance, the restoration order shall not be allowed to
be executed until the clearance has been surrendered. The clearance shall not be allowed to be surrendered
until removal of the grounds has been recorded.
The user shall be able to create switch order sequences not only on the active real-time system, but also in
simulation mode, so that the user is able to verify the effect of the switching sequence on the network topology
prior to executing it in real-time mode. Switch orders thus created in simulation mode shall be able to be saved
as templates.
Interface to GIS Systems
As an option, the proposed system shall include a GIS interface as a dynamic data link to the user's current or
future GIS system. The preferred interface to the GIS system is a MultiSpeak Version 2 compliant interface. A
MultiSpeak compliant interface allows a seamless integration between SCADA, GIS and other enterprise
applications such as engineering analysis software, customer information systems, etc.
The MultiSpeak based interface between the SCADA and GIS system shall allow the automatic data transfer in
real-time in both directions. It shall also allow the import in batch mode of the entire spatial database from the
GIS, or AM/FM system, into the real-time SCADA database without any need for manual intervention for
updating of data. The GIS spatial database will contain the topology and connectivity information as well as all
the equipment characteristics.
34 of 40
CHAPTER 6 - SYSTEM IMPLEMENTATION
Project Schedule and Coordination
The prospective bidders shall submit a narrative project approach, project team and qualifications, workplan and
schedule with the bid proposal as identified in the Request for Proposal.
System Testing
The Vendor shall provide two levels of equipment and software tests:
Factory Acceptance Test (FAT).
Site Acceptance Test (SAT) or field test.
The successful bidder shall prepare test documentation and test logs necessary for all factory and site tests to
the satisfaction of the City. The purpose of these tests is to demonstrate that the functional, performance,
availability and other requirements in this specification are met. The test procedure document shall be prepared
by the Vendor and shall follow a consistent format and be submitted to the City for review. The formal factory
acceptance test shall not take place until the test procedure document has been reviewed and agreed upon by
the City. The City reserves the right to modify, add to or remove items from the test procedure document as they
see fit.
Discrepancies found during the testing shall be documented and maintained in a problem log file. The
subsequent correction shall be described and representatives of the City and the successful bidder shall verify
proper operation. Faulty and/or incorrect operation of major functions (major discrepancies) may, at the
discretion of the City, be cause for the suspension or restarting of the entire test, pending the correction of the
problem. Minor discrepancies shall be corrected and re -tested. The City may request that other modules that
may be impacted by the correction be re -tested also.
The System shall not be shipped until the City certifies successful completion of the factory test. Shipping delays
due to testing failures shall not be considered an unavoidable delay. The possibility exists that for some
presently unforeseeable reason, the City may approve the successful bidder's request for shipment of the
system before it successfully passed all the factory tests. If such approval is given, the shipment of the system
shall not constitute nor imply a waiver of any requirements. Re -testing of requirements not met during factory
testing will be part of the site acceptance test (SAT).
To provide the City full confidence in the System, unstructured time shall be provided during the factory test.
The City shall be allowed at least 32 normal work hours (from 7:OOAM to 4:OOPM on regular workdays) for this
unstructured testing. Unstructured testing will consist of the City determining what tests to perform for any or all
of the subsystems or the system as a whole. The City will have available to them the necessary Vendor
personnel and test equipment needed to carry out any test deemed necessary by the City. At a minimum, the
Seller shall have personnel to monitor all phases of the unstructured test.
Shipping and Installation
All equipment deliveries shall be F.O.B. destination prepaid and allowed to the City's EUD Dispatch Center
located in 1331 South Ham Lane, Lodi, CA. Deliveries shall be sent to the Manager of Engineering &
Operations Division.
35 of 40
The successful bidder shall provide all plans and procedures necessary for the system installation and
integration. This includes all supplied equipment, including third party or subcontractor equipment the Vendor is
providing or has made part of its system. This also includes hardware recommended by the Vendor for
purchase by the City to support the system. The City shall have the opportunity to review all installation plans
and procedures prior to installation. The City will prepare all sites for the installation of equipment in coordination
with the successful bidder.
The successful bidder shall be responsible for starting up the system. The purpose of system startup shall be for
the Vendor to verify that all system functions that were demonstrated during FAT now operate properly under
actual field conditions. This shall include all application programs. The main purpose of system startup shall be
to prepare the system for SAT. The SAT shall include helping establish communications at the master station to
all substation facilities and to the existing sites for wells, pumps and/or lift stations as determined by the City.
The City will provide general service power, lighting, and room/equipment air conditioning. The successful
bidder shall indicate the general service circuit capacity, environmental, and protection requirements for each
headquarters and field equipment installation as applicable.
Site Acceptance Test (SAT
In coordination and under the guidance of the successful bidder, Site Acceptance Testing (SAT) shall be
conducted at the City's facilities. Following the successful start-up of the headquarters and remote equipment,
the City personnel shall re -conduct the factory acceptance test and other tests in a field environment. The SAT
period shall be re -initialized whenever a major problem, in the opinion of the City, is encountered. All
requirements in this specification must be met for successful completion of the site -testing milestone.
Any problems encountered during SAT will be reported immediately. The successful bidder shall promptly
correct all problems encountered with its own field service personnel unless the City agrees to provide
personnel for a particular item. Successful completion of SAT means the City is satisfied that the system has
met all requirements described in this specification, excluding warranty provisions and other items that survive
the site -testing milestone.
The SAT may include re -executing structured test procedures used in the FAT as reasonably necessary as well
as executing test procedures that could not satisfactorily be demonstrated in a factory setting. The SAT may
also include unstructured tests. Furthermore, the site testing shall include verifying system capabilities to
communicate as expected with RTUs and to interface as may be expected with other information systems.
Personnel from the successful bidder shall be present and shall be coordinating all the activities during the test
process.
Support Plan
The City shall have the option to purchase maintenance and support plan on at least an annual basis. The City
will determine if it wishes to load the fix or update or wait for a single annual enhancement. The software
updates are to keep the City's system current with the latest product releases offered by the successful bidder.
The successful bidder shall propose options for two level of response: business day only and 24x7 support
plans. Response times within 30 minutes from the call shall be required for critical problems. A response means
a qualified person from the successful bidder's organization has contacted the City and is working on the
problem. The successful bidder shall provide remote diagnostics support from Vendor's facilities via a dial -in or
VPN connection at City facilities. The City shall have the option to accept or decline the support plan prior to the
warranty period ending. The Vendor shall properly inform the City of Lodi 30 to 60 days before expiration of the
warranty period that there is a need to address continuation of a support plan.
36 of 40
The Vendor shall recommend and include in its proposal, reasonable quantities of spare parts. For hardware
that is not widely available from common third -party hardware providers, e.g., CISCO, Dell, HP Compaq, etc,
the Vendor shall provide a complete spare parts list.
Training
The successful bidder shall make available to the City, training on the operation, maintenance, failover/startup,
recovery, application software, display, and database maintenance. The class training shall be conducted at the
City of Lodi including the Dispatcher/Operator training classes.
Training course outlines shall be included in the bidder's bid. Each course outline shall include, in addition to the
subject matter, a short review of the prerequisite subjects, how this course fits into the overall training program,
and its objective. Qualified and experienced personnel from the successful bidder shall conduct the training.
The City's staff shall receive individual copies of the training materials and pertinent documents prior to the
scheduled start of the course. A suggested training plan and schedule suitable to the needs of the City shall be
provided as part of the proposal. The plan and schedule shall include a description of the training classes and
perquisites, proposed order of the classes, length of classes, the minimum and maximum number of attendees
per class, and standard cost per attendee.
Documentation
The documentation requirements shall apply to all items described in this specification. This includes all items
provided by subcontractors or suppliers of the successful bidder unless specifically noted otherwise. The
successful bidder shall provide a complete documentation list/inventory and shall update it periodically during
the project to reflect what documentation has been delivered.
The software documentation shall provide, through a set of logically coordinated documents, a comprehensive
and detailed description of all software necessary for the operation and maintenance of the proposed system. It
shall describe the system's overall functions, subsystems, databases, macros, libraries and procedures. The
requirements in this section do not apply to Original Equipment Manufacturer (OEM) provided software, e.g.,
operating systems). For OEM provided software, the standard OEM manuals shall be provided.
The successful bidder shall provide the documentation electronically wherever it is appropriate. At a minimum,
two (2) complete printed sets of all documentation - standard and project specific - shall be provided to the City.
37 of 40
APPENDIX "A" - SYSTEM SIZING REQUIREMENTS
1. Communicate with existing 49 RTU's via Bell 202T modems
2. Number of status= 24-72 indications, 16-208 analogs, and 0-56 control points at each RTU —see
appendix B
3. Provide 2 Host/ Servers
4. Proved redundant SCADA (2) LAN's (severs should be able to connect / swap to both LAN's
independently)
5. Number of operators consoles 3 consoles with (3 monitors on the main control counsel ) and 2 for
the relief shift desk
6. Utilize existing loggers Dot matrix printer for alarm logging via serial link from Dec Sever provided
by the successful bidder
7. Utilize existing network laser or inkjet printers for reports, alarms summery, historical graphs etc.
8. Utilize 47 communication lines via Bell 202T modems to communicate with remote RTU's
(Note: 2 field RTUS share same leased line)
9. Utilize existing leased lines and Bell 202T modems for connection to field RTU's
(City staff to identify and assist in wiring)
10. Protocols used by the RTU's = Telgyr 6000-6500 or equivalent, Telgyr 8979
11. Provide additional protocols desired for future use = Modbus RTU, DNP 3.0
12. Number of analog points to be stored in the historical database = 500 at 15 minute interval,
13. Number of months for storage of historical data = 15
38 of 40
APPENDIX "B" - RTU Information
#
RTU
NAME
LOCATION
#
ANALOG
#
INDCIATION
ACCUM.
SOE
#
SBO
ANALOG
SET.
PROTOCOL
COMM. LINE
ADDRESS
1
HS
HENNING SUB.
72
80
16
0
56
8
TG6000
HENNING
1
2
MS
MC LANE SUB.
64
80
16
0
40
0
TG6000
MCLANE
1
3
KS
KILLELEA SUB.
80
80
16
0
56
0
TG6000
KILLELEA
1
4
W1
WELL 1
24
32
16
0
8
0
TG6000
WELL 1
1
5
W2
WELL 2
24
32
16
0
8
0
TG6000
WELL 2
2
6
W3
WELL 3
24
32
16
0
8
0
TG6000
WELL 3
3
7
W4
WELL 4
24
64
16
0
16
0
TG6000
WELL 4
4
8
W5
WELL 5
24
32
16
0
8
0
TG6000
WELL 5
5
9
W6
WELL 6
24
32
16
0
8
0
TG6000
WELL 6
6
10
W7
WELL 7
24
32
16
0
8
0
TG6000
WELL 7
7
11
W8
WELL 8
24
32
16
0
8
0
TG6000
WELL 8
8
12
W9
WELL 9
24
48
16
0
8
0
TG6000
WELL 9
9
13
W10
WELL 10
24
32
16
0
8
0
TG6000
WELL 10
10
14
W11
WELL 11
24
32
16
0
8
0
TG6000
WELL 11
11
15
W12
WELL 12
24
32
16
0
8
0
TG6000
WELL 12
12
16
W13
WELL 13
24
32
16
0
8
0
TG6000
WELL 13
13
17
W14
WELL 14
24
32
16
0
8
0
TG6000
WELL 14
14
18
W15
WELL15
24
32
16
0
8
0
TG6000
WELL15
15
19
W16
WELL 16
24
32
16
0
8
0
TG6000
WELL 16
16
20
W17
WELL 17
24
32
16
0
8
0
TG6000
WELL 17
17
21
W18
WELL 18
24
32
16
0
8
0
TG6000
WELL 18
18
22
W19
WELL 19
24
32
16
0
8
0
TG6000
WELL 19
19
23
W20
WELL 20
24
32
16
0
8
0
TG6000
WELL 20
20
24
W21
WELL 21
24
32
16
0
8
0
TG6000
WELL 21
21
25
W22
WELL 22
24
32
16
0
8
0
TG6000
WELL 22
22
26
W23
WELL 23
24
32
16
0
8
0
TG6000
WELL 23
23
27
W24
WELL 24
24
32
16
0
0
0
TG6000
WELL 24
24
INDUSTRIAL SUB.
28
IS1
60KV
56
208
16
0
40
0
TG6000
INDUSTRIAL
1
29
G2
N.C.P.A. GEN. SITE
24
16
16
0
0
0
TG6000
MCLANE
4
30
SL
SACRAMENTO LIFT
24
32
16
0
0
0
TG6000
SACRAMENTO LIFT
16
39 of 40
31
PB
PETERSON BASIN
24
32
16
0
0
0
TG6000
32
WLL
WOODLAKE LIFT
24
32
16
0
0
0
TG6000
33
CAB
CLUFF AVE. BASIN
24
32
16
0
0
0
TG6000
34
SB
SALAS BASIN
24
32
16
0
0
0
TG6000
35
VWB
VINEWOOD BASIN
24
32
16
0
0
0
TG6000
36
LLB
LODI LAKE BASIN
24
32
16
0
0
0
TG6000
37
KFB
KOFU BASIN
24
32
16
0
0
0
TG6000
38
NEL
NORTHEAST LIFT
24
32
16
0
0
0
TG6000
39
ML
MOKELUMNE LIFT
24
32
16
0
0
0
TG6000
40
RGL
RIVERGATE LIFT
24
32
16
0
0
0
TG6000
41
GM
GENERAL MILLS
24
32 16
0 0
0
TG6000
INDUSTRIAL SUB
42
IS2
12KV
64
96 16
0 56
0
TG6000
43
TDL
TIENDA DRIVE LIFT
24
16
16
0
0
0
TG6000
44
W25
WELL 25
24
32
16
0
8
0
TG6000
45
TOW
TOWER
24
32
16
0
0
0
TG6000
ALARM RTU - BACK
46
ALR
ROOM
24
80
16
0
32
0
TG6000
TURNER RD.
47
TRU
UNDERPASS
24
32
16
0
0
0
TG6000
48
W26
WELL 26
24
32
16
0
8
0
TG6000
49
WELL 28
24
32
16
0
8
0
TG6000
Total
1392
2016
784
0
496
8
PETERSON BASIN LIFT 1
WOODLAKE LIFT 4
CLUFF AVE. BASIN 2
SALAS BASIN 3
VINEWOOD BASIN 5
LODI LAKE BASIN 6
KOFU BASIN 7
NORTHEAST LIFT 13
MOKELUMNE LIFT 14
RIVERGATE LIFT 15
INDUSTRIAL
2
TIENDA DRIVE LIFT
17
WELL 25
25
TOWER
2
ALARM RTU
1
TURNER BASIN
8
WELL 26
26
WELL 28
28
51
WEA
WEATHER
24
16
16
0
0
0
SPARE 8
58
52
SUP
SUPPORT RTUS
24
16
16
0
0
0
HENNING
60
53
PUMP SUPPORT
24
16
16
0
0
0
SPARE 8
62
55
COM
COMM. RTU
24
16
16
0
0
0
SPARE 8
54
56
STORM PUMP
24
16
16
0
0
8
SPARE 8
56
57
TAL
TEMP. ALARM RTU
24
80
16
0
8
0
SPARE 7
26
58
TSR
TRAINING SUB.
24
16
16
0
0
0
SPARE 8
52
40 of 40
CITY COUNCIL
BOB JOHNSON, Mayor
JOANNE MOUNCE,
Mayor Pro Tempore
LARRY D. HANSEN
SUSAN HITCHCOCK
PHIL KATZAKIAN
To Prospective Bidders
CITY OF LODI
ELECTRIC UTILITY DEPARTMENT
GEORGE F. MORROW, DIRECTOR
1331 S HAM LANE
LODI, CALIFORNIA 95242-3995
(209) 333-6762
FAX (209) 333-6839
October 23, 2007
BLAIR KING, City Manager
RANDI JOHL, City Clerk
D. STEPHEN SCHWABAUER,
City Attorney
Subject: Request for Proposal (RFP) to replace and upgrade the existing Supervisory
Control and Data Acquisition (SCADA) System for the Water, Wastewater
and Power Distribution Systems
The City of Lodi (City) hereby invites sealed proposals to provide services to design and build a
comprehensive system to replace and upgrade the existing SCADA. Each bid shall be in
accordance with this notice and specifications on file and available from the Engineering and
Operations Manager, City of Lodi Electric Utility Department, 1331 South Ham Lane, Lodi,
California 95242, (209) 333-6811. No bid will be considered unless it is submitted on a format
according to the `ORGANIZATION OF PROPOSAL' Section of this RFP document.
Sealed proposals shall be delivered to the Budget Manager — Finance Department at the City Hall
Annex, 300 West Pine Street, Lodi, CA 95240 (P.O. Box 3006, Lodi, CA 95241-1910) on or
before
November 28, 2007, Wednesday at 11:00 a.m.
At that date and hour said sealed proposals will be publicly opened and read in the Public Works
Conference Room, City Hall, 221 West Pine Street, Lodi, California. Bidders or their authorized
representatives are invited to be present.
Please submit detailed proposal. If there are any questions regarding this request for proposal,
you may contact Mr. Abel Palacio, Sr. at (209) 333-6809, or by email to
ahpalacio(a)lodielectric.com.
Demy Bucaneg, Jr. -PE
Manager, Engineering & Operations Division
Tel. No. (209) 333-6811
Email: dbucaneg@lodielectric.com
BACKGROUND
The current SCADA Systems of the City is based on the Siemens Telgyr 8500 System. It is a 1984
technology and is no longer supported by Siemens or any third party vendors. Multiple failures and
the inability to obtain spare parts and software have made it difficult to operate the water,
wastewater and power distribution utilities efficiently and economically. The existing SCADA
System monitors and controls the water well pumping sequence. The water well and booster
pump system provides a systematic rotation of the water well pumps and pressure equalization in
the system. Another function of the SCADA system includes the sewage treatment lift station well
monitoring, alarm acknowledgement and flow status. In addition, the SCADA also provides
monitoring of the storm station status as well as alarms. Finally, the SCADA system provides
monitoring and direct control of the power grid system in the City's electric transmission and
distribution system. The communication network used to interface the SCADA computer to the
remote station are leased telephone lines from the local Telephone Company. The existing
SCADA system uses communication ports to connect to those leased lines via T202 modems to
Remote Terminal Units (RTU) at each respective location. This RFP requires the selected
contractor to utilize the existing communications lines and RTU's in their proposal.
At present, the City has two (2) SCADA Systems with each system having a duplicate unit
designed to operate in parallel for redundancy. The first system was placed in operation in the
1980s utilizing its System B unit and has been operating with several failures experienced in a
monthly basis. Its System A is currently inoperable for quite a long time now. Attempts to make it
work proved challenging due non-availability of parts and issues of failing the entire first SCADA
System whenever it was connected on line. The System B is still being utilized by operations and
appeared to be the most reliable unit. This first system is a Siemens product.
The existing second system is also supplied by Siemens. It was awarded in mid -2001 with the
approach that City personnel will do in-house programming for the control and monitor of the
water, wastewater and power operations. The basic SCADA framework and softwares were
configured and integrated by Siemens. This second system was partly operational in its monitoring
functions and provided unreliable values. Both System A and B units were never put into full
operation until now. This SCADA System was also infected with virus. Its hardware and software
features were determined to be obsolete with today's technology that required replacement and
updating.
The SCADA System is vital to the operation of the City's utilities that needs immediate
implementation. The replacement and upgraded SCADA shall include but not limited to the
following monitor and control functions:
• Comply with City of Lodi RFP and Exhibit 1 - Specifications
• (4) Electrical Substations, and accompanied transmission and distribution Control of PCB
(primary circuit breakers) load changers (LTC), re -closure function. Monitor voltage,
current, KVA, KW, PF, and various digital and analog signals
• (27) Water wells and booster pump control and monitoring with auto failure over during
communication failure of SCADA. Monitors system pressure, flow, levels, alarms etc.
• (6) Wastewater lift station monitor of sump levels, pump status, emergency gen-set,
alarms, etc.
• (8) Storm station levels, flow pump status, alarms etc
• (1) Co -Generation system, monitor conditions, power etc.
SCOPE OF WORK
The scope of work shall include all the requirements as stipulated in the 'Exhibit 1 — Specifications'
and other requirements as stated in this RFP and also the items below.
• Provide dual SCADA servers, dual SCADA host with 2 monitors each 21" for total of 4
monitors and other associated hardware, Dual 64 channel communications boards
(connect to existing T202 modems), (1) new web server. All devices shall be rack
mounted.
• All associated software. Windows Server 2003, Windows XP, Microsoft office 2003
SCADA software, Telgyr 6000 and DNP 3.0 protocol drivers, SCADA alarm, (5) custom
script applications based on flow charts provided by the City.
• Migration of existing database and screens. Or build new from scratch with COL
assistance.
• Selected bidder shall field verify all connections, communication lines and protocol's used
by City of Lodi telemetry system.
ORGANIZATION OF PROPOSAL
Prospective Bidders are furnished with one request for proposal (RFP) document and the Exhibit 1
- Specifications. Proposals shall follow the following format:
A. Project approach narrative — This section should demonstrate an understanding of the
task at hand and include a narrative describing how the Bidder would go about the work.
B. Project team — Describe the personnel who will carry out project tasks, and their
respective responsibilities.
C. Qualifications — Provide curricula vitae for all personnel on the project team and a
narrative describing how the team as a whole meets the qualifications for the project.
Include a list of prior relevant work or projects. Include in this section the information being
solicited in the 'Exhibit 1 — Specifications, Bidder Requirements' as part of the bid
proposal.
D. Workplan — This section should include an allocation of time to the work to be
accomplished and an indication of who will carry out which tasks. Include in this section
the information being solicited in the 'Exhibit 1 — Specifications, Bidder's Responsibilities'
as part of the bid proposal.
E. Exceptions and Clarifications — This section shall include a summary of all the exceptions
and clarifications with references to specific paragraph and/or section of the
specifications.
F. Budget — This section should consist of a bid including hourly rates and an overall contract
price for the scope of work specified.
G. Time — The bid proposal shall include detailed project schedule. The replacement and
upgraded SCADA System shall be completed, tested, commissioned and fully operational
in six (6) months from the date of contract execution and/or Notice to Proceed.
H. Signatures - The proposal must be signed with the full name and address of the bidder, by
an authorized representative of the company with all the information below.
i.
Name of company
ii.
Address
iii.
Authorized signature
iv.
Name
v.
Title
vi.
Telephone No.
vii.
Fax No.
viii.
Date
Note - The City of Lodi reserves the right to reject any or all bids, to waive any informality
in any bid, to accept other than the lowest bid, or not to award the bid.
PROPOSAL SUBMISSION
A. The Budget Manager —Finance Department will receive sealed proposals at the following
address until
11:00am, Wednesday, November 28, 2007.
B. Proposals shall be submitted under sealed cover, plainly marked
Proposal — Lodi Electric Utility SCADA System
Bid Opening - November 28, 2007.
Bids which are not properly identified may be disregarded. Bids, which are not received
by 11:00am, Wednesday, November 28, 2007 will be returned to the bidder unopened.
Bids shall be submitted
To: Lodi City Council
c/o Budget Manager —Finance Department
(If delivered by FedEx, UPS, or courier): (If delivered by mail):
300 West Pine Street P O Box 3006
Lodi CA 95240 Lodi CA 95241-1910
BID OPENING
A. At 11:OOAM, Wednesday, November 28, 2007, or as soon as possible thereafter, in the
Public Works Conference Room, City Hall, 221 West Pine Street, Lodi, California,
proposals will be publicly opened and read. Bidders or their authorized representatives
are invited to be present.
SELECTION PROCESS
Proposals will be reviewed by the Utility Operations Supervisor, Senior Power Engineer, the
Engineering & Operations Manager and the Electric Utility Director. Complete proposals will be
evaluated based on the information submitted. This will permit a recommendation to the City
Council for contract award. The following equally weighted criteria will be used to evaluate
submitted proposals:
A. The likelihood of the proposed approach to produce the desired results.
B. Qualifications of the Bidder.
C. The value offered by the Bidder's price in relation to the proposed approach.
REJECTION OF PROPOSALS
The City of Lodi Electric Utility Department reserves the right to reject any and all proposals and to
solicit new proposals with modified terms and conditions. It also reserves the right to waive any
informality in connection with the proposals.
CONTRACT AWARD
1. The City of Lodi reserves the right to reject any or all bids, to waive any informality in any
bid, to accept other than the lowest bid, or not to award the bid.
2. If there will be a tie in the submitted proposals, the tie will be broken by a coin toss,
conducted by the Budget Manager —Finance Department. Tie bidders will be notified and
may be present.
3. Where alternative bids are received, the City Council reserves the right to select the bid
most advantageous to the City.
4. The award, if made, will be made within forty-five (45) days after the opening of the bids.
5. The bid proposal as submitted by the selected bidder, the SCADA RFP and the Exhibit 1 —
Specifications shall be the supporting documents and considered as parts of the contract.
GENERAL PROVISIONS
5-409 Responsibility for Damage The City of Lodi, its elected and appointed boards,
commissions, officers, agents and employees shall not accept responsibility for any loss or
damages that occur during the scope of work to the work or any part thereof; or for any material or
equipment used in performing the work; or for injury or damage to any person or persons, either
work personnel or the public; for damage to adjoining property arising from or related to
Contractor's negligence or willful misconduct during the progress of the work or any time before
final acceptance.
The Contractor shall indemnify and save harmless the City of Lodi, its elected and appointed
boards, commissions, officers, agents and employees from any suits, claims or actions brought by
any person or persons for or on account of any injuries or damages sustained or arising out of
Contractor's negligent acts, errors or omissions in the performance of the work or in consequence
thereof. The City of Lodi may retain as much of the money due the Contractor as shall be
considered necessary until disposition has been made of such suits or claims for damages as
aforesaid.
5-413 Insurance Requirements for Contractor The Contractor shall provide proof of
insurance to be maintained during the life of this contract as listed under General Liability and
Automobile Liability coverage listed below. These insurance policies shall protect the Contractor
and any subcontractor performing work covered by this contract from claims for damages for
personal injury, including accidental death, as well as from claims for property damages, which
may arise from Contractor's operations under this contract, whether such operations be by
Contractor or by any subcontractor or by anyone directly or indirectly employed by either of them,
and the amount of such insurance shall be as follows:
COMMERCIAL GENERAL LIABILITY
Per Occurrence
$1,000,000 Property Damage
Personal & Adv Injury
$2,000,000 General Aggregate
2. COMPREHENSIVE AUTOMOBILE LIABILITY
$1,000,000 Combined Single Limits
NOTE: Contractor agrees and stipulates that any insurance coverage provided to the City of Lodi
shall provide for a claims period following termination of coverage, which is at least consistent with
the claims period, or statutes of limitations found in the California Tort Claims Act (California
Government Code Section§ 810 et seq.).
A copy of the certificate of insurance with the following endorsements shall be furnished to the City
of Lodi:
(a) Additional Named Insured Endorsement with Primary Wording
Such insurance as is afforded by this policy shall also apply to the City of Lodi, its elected
and appointed Boards, Commissions, Officers, Agents and Employees as additional named
insured, insofar as work performed by the insured under written contract with the City of Lodi.
(This endorsement shall be on a form furnished to the City of Lodi and shall be included with
Contractor's policies.)
Wording: Such insurance as is afforded by the endorsement for the Additional Insureds shall
apply as primary insurance. Any other insurance maintained by the City of Lodi or its officers
and employees shall be excess only and not contributing with the insurance afforded by this
endorsement.
(c) Severability of Interest Clause
The term "insured" is used severally and not collectively, but the inclusion herein of more
than one insured shall not operate to increase the limit of the company's liability.
(d) Notice of Cancellation or Change in Coverage Endorsement
This policy may not be canceled nor the coverage reduced by the company without 30 days'
prior written notice of such cancellation or reduction in coverage to the City Attorney, City of
Lodi, P.O. Box 3006, Lodi, CA 95241.
(e) Contractor agrees and stipulates that any insurance coverage provided to the City of Lodi
shall provide for a claims period following termination of coverage, which is at least
consistent with the claims period, or statutes of limitations found in the California Tort Claims
Act (California Government Code Section 810 et seq.).
"Claims made" coverage requiring the insureds to give notice of any potential liability during a
time period shorter than that found in the Tort Claims Act shall be unacceptable.
5-414 Workers' Compensation Insurance The Contractor shall provide proof of and
maintain during the life of this contract, Worker's Compensation Insurance for all Contractor's
employees employed at the site of the project and, if any work is Subcontracted, Contractor shall
require the subcontractor similarly to provide Worker's Compensation Insurance for all of the
latter's employees unless such employees are covered by the protection afforded by the
Contractor. In case any class of employees engaged in hazardous work under this contract at the
site of the project is not protected under the Worker's Compensation Statute, the Contractor shall
provide and shall cause each subcontractor to provide insurance for the protection of said
employees. This policy may not be canceled nor the coverage reduced by the company without
30 days' prior written notice of such cancellation or reduction in coverage to the City Attorney, City
of Lodi, P.O. Box 3006, Lodi, CA 95241.