THE METROPOLITAN WATER DISTRICT OF SOUTHERN CALIFORNIA. Addendum No. 1 REQUEST FOR PROPOSALS TO PROVIDE

Transcription

1 THE METROPOLITAN WATER DISTRICT OF SOUTHERN CALIFORNIA Addendum No. 1 REQUEST FOR PROPOSALS TO PROVIDE WATER QUALITY MONITORING AND EVENT DETECTION SYSTEM RFP-PL-912 To all prospective respondents to Request for Proposal (RFP) No. RFP-PL-912, for which proposals are to be received by The Metropolitan Water District of Southern California (Metropolitan or MWD), at its Offices, 700 North Alameda, Fifth Floor, Room 5-113, Los Angeles, California 90012, until 3:00 p.m., PDT, August 10, I. The information given in Addendum No. 1 are official revisions as well as responses to requests submitted by prospective respondents for clarification, and are hereinafter incorporated into RFP-PL-912. II. Proposals will be received until 3:00 p.m., PDT, August 10, This is an extension from the original RFP submittal due date of August 5, III. The following clarification is issued: 1. Q: As part of our proposal we plan to use the [XYZ] system software tools as the primary tool set for the project. Since our company is not a reseller of the software, is it possible for MWD to purchase the software separate from our proposal where MWD would make a separate contract with [XYZ] for the purchase of the software only? A: MWD is willing to purchase vendor specified software from a third party. However, the details of all the software needed, including: name, version, type (e.g. server or client license), quantities and initial purchase, licensing and maintenance costs need to be disclosed in this response. Costs shall be guaranteed by the respondent/vendor, and shall be fully disclosed and itemized in the cost proposal. As this is a not to exceed price contract, any additional software needed to make the system fully functional shall be provided or paid for by the vendor, with licensing applied to MWD. Page 1

2 2. Q: Although it s clear that MWD will purchase all applicable software license(s), will MWD own exclusivity of the code for all custom software or customized elements of COTS software? A: The initial intention is yes, though as each situation is different, this is negotiable. 3. Q: It is assumed that MWD will supply interfacing help with its SCADA system. Has the scope of that help been defined. A: MWD will provide interfacing help up to the borders of the vendor supplied package. Specific cases may vary as based on the interface boundaries of individual system proposals, but in general, the interface boundary crossings consist of data coming in from MWD systems, and notifications going out to MWD systems, as well as the server and network configuration to handle this traffic. We will provide services and assistance as needed at these points. 4. Q: Will we be provided with some level of expectations for the partitioning/segmenting of GUI s? A: As vendor GUI capabilities and offerings are all different, rather than have MWD explicitly define a GUI up-front, it is expected that the respondent propose a GUI solution. We expect that a mature system will have a baseline GUI system defined. As noted elsewhere in the RFP, refining detailed requirements, based on MWD s needs and the system s capabilities, is required. Iterative development and system tuning to meet these requirements is an encouraged approach. Based on this, we will work with the consultant to modify their GUI system, if necessary, within minimal and reasonable limits, capabilities and changes, to obtain an acceptable system. 5. Q: Please identify the COTS SCADA software package(s) currently used by MWD. A: The MWD SCADA system is not a commercial off the shelf system and employees a proprietary protocol for native SCADA communications. The SCADA system has standard protocol interface capabilities. Regardless of the current SCADA package, EDS data collection will be via OPC DA. The EDS OPC DA interface will need to function in the Client mode supporting both reading and writing of OPC tags. 6. Q: Will alarm notification severity levels be characterized to align with trended thresholds or hard-stated MWD guidelines? A: The respondent is to propose alarm notification criteria. Alarm severity should be related to the degree of abnormality detected. Thresholds, probabilities, limits, other methods, or options for several or combinations of these will be evaluated. Flexibility will be appreciated here, as some parameter/alarm criteria are dynamic, while others may remain fixed. Recall that this is a multi-variate analysis system, and differing combinations of multiple parameter readings may alarm at differing levels. 7. Q: Will MWD be open to a FMEA workshop at the end of the requirements development phase (in addition to the stated end of the design phase ) A: MWD encourages FMEA or like analysis at any reasonable point in the project lifecycle. Page 2

3 8. Q: Can MWD provide one or more examples of multi-variate events that MWD would like to detect? Approximately how many such events does MWD anticipate the system will need to look for? A: Examples of multi-variate events include contaminant A, where the multiple variables of turbidity may drop, TOC may drop, and chloramines may drop. Or, Contaminant B, where turbidity increases and ORP drops, while other factors remain relatively constant. Individually, these changes may not indicate the potential of a contaminant, but in concert, they do indicate so. It is not possible to estimate the number of events that occur, or the number of potential contaminants. It is assumed that actual contamination events or abnormalities should be very low. 9. Q: Does MWD plan to look at multiple variables separately and trigger alarms when some specific number of these are violated (e.g. when oxygen is low and turbidity is high) or does it wish to combine these variables using mathematical normalization (i.e. Hotaling T2) to then model multi-variate behavior? A: As contaminant profiles all vary, multiple methods are allowed. As a minimum, a multi-variate method (e.g. statistical, neural network, etc.) is required. While strict rules-based threshold alarming is not acceptable as the sole alarming system (as stated elsewhere in the RFP), it is allowable (and may at time be needed) as a supplement to multi-variate methods. 10. Q: We understand the target project start date is December, Does MWD have a target date for a full implementation of the solution? A: We expect this project to take six months to one year to be fully implemented. 11. Q: With respect to the ArcGIS map integration requirement, would any map integration be acceptable (ex Google) or is there a specific reason to integrate with ArcGIS? A: Other map integration methods are acceptable, subject to approval. MWD does use, and will accept Google Maps, Google Earth, Streets and Trips, and ArcGIS. The reason for listing ArcGIS is to make it clear that our infrastructure is already mapped in this application, providing a ready and mutually cost effective reference. However, we also have, and do use, similar infrastructure information for Google Earth and Google Maps. 12. Q: Page 11 under the Architecture section, the 4th item talks about IPC DA interfaces, should this actually say OPC DA interfaces? A: IPC is a typo error and should read OPC. 13. Q: Page 12 part of the text implies data to come from SCADA; page 12 implies direct link from sensors in situ at up to 100 locations (or are these locations all processed through the SCADA system?). Or is the SCADA interface for alarms and actuation, as on page 15? Please clarify. A: All data will come from SCADA through the OPC DA interface. The respondent need only consider this OPC interface for data. Page 3

4 14. Q: Page 13 Currently, do sensor reports include location, or just sensor number? A: Currently, there are no sensor reports elative to this effort. Sensor reports from this project will need to identify location. 15. Q: Page 8 Does MWD wish to include a GIS type interface to show the location of events (page 18 implies yes, but please confirm)? A: This is not required but would be beneficial. At minimum a simple map is required with instrument/alarm points correctly located on the map. 16. Q: Page 8 Item #10 Alarm and notification What type of notification is required, just visual when logging in and or something else? Can an example be provided? A: Alarming and notification should have multiple capabilities (i.e., alarms within the system, as well as on SCADA, s, pagers, etc.). 17. Q: Page 8 Item #9 - In reference to the user interface for viewing data is this static or will the user need to interact with this view? A: The user will interact with the view. The view parameters (e.g. time, instrument, etc.) should be adjustable. 18. Q: Please elaborate on "The EDS system shall have the ability to flag, report on, trend and subsequently minimize or tune the rate of false positive as well as false negative results." Is this done on a row by row basis or in context with other information? A: Tuning to minimize the rate of false positives should be done based on statistical analysis of all of the baseline data, whether in regards to individual parameters or the data in its entirety. 19. Q: With respect to report configuration and generation, what reports are required, how many, and what data elements? As vendor reporting capabilities and offerings are all different, rather than have MWD explicitly define a reporting system up-front, it is expected that the respondent propose a reporting solution. We expect that a mature system will have a baseline reporting system defined and functional. As noted elsewhere in the RFP, refining detailed requirements, based on MWD s needs and the system s capabilities, is required. Iterative development and system tuning to meet these requirements is an encouraged approach. Based on this, we will work with the consultant to modify their reporting system, if necessary, within minimal and reasonable limits, capabilities and changes, to obtain an acceptable system. Minimum reporting parameters are already defined in the RFP. 20. Q: Sec 2 Page 11 - "An "off-line" environment shall be provided for the purposes of configuration, data analysis, system tuning " Is this the development environment or a separate staging environment? How many instances are required for: 1) Production, 2) Development, 3) Staging, 4) Disaster Recovery (redundant "cold" standby versus - sec 2 page 16 - "a redundant HOT standby system is NOT required".) A: The off-line environment is in the deployment. It is the environment used to analyze data manually as opposed to the real time EDS analysis. Page 4

5 21. Q: Sec 2 Page 13 - Data conditioning and validation and data remediation. Will the specific rules be provided in order that the remediation can be automated, or will the detection of these events require manual intervention for a user to select the remediation option before continuing the processing of those events? A: Data conditioning, remediation and validation are considered standard industry capabilities. As vendor data management capabilities and offerings are all different, rather than have MWD explicitly define data management structure and rules up-front, it is expected that the respondent propose a solution. We expect that a mature system will have a baseline data management and remediation system defined and functional. As noted elsewhere in the RFP, refining detailed requirements, based on MWD s needs and the system s capabilities, is required. Iterative development and system tuning to meet these requirements is an encouraged approach. Based on this, we will work with the consultant to modify their data conditioning, remediation and validation system, if necessary, within minimal and reasonable limits, capabilities and changes, to obtain an acceptable system. Data management automation and human intervention (where required) are discussed elsewhere in the RFP. By example, a user could select use last known good value, ignore data, or extrapolate Q: Sec 2, Page 7 - Can we get more details ( e.g. calculations) on the KPIs required such as: just current real-time values, or additional calculations such as average over time, percentage, std dev., comparisons to previous days, weeks, etc. A: As vendor KPI s and calculation capabilities and offerings are all different, rather than have MWD explicitly define these up-front, it is expected that the respondent propose a solution. We expect that a mature system will have baseline KPI s and calculations defined and functional. As noted elsewhere in the RFP, refining detailed requirements, based on MWD s needs and the system s capabilities, is required. Iterative development and system tuning to meet these requirements is an encouraged approach. Based on this, we will work with the consultant to modify their KPI s and calculations, if necessary, within minimal and reasonable limits, capabilities and changes, to obtain an acceptable system. 23. Q: What granularity for each dimension is required (e.g. time down to the second and rolling up to the month, other dimension hierarchies )? A: The minimum granularity of reporting will be the same as the minimum data posting interval, which is one minute (nominal setting of two minute data). Aggregation of this data is left to the vendor to propose, though hourly, daily, weekly and monthly is recommended. 24. Q: What is the total number of users who will be using the system (both concurrent users and total users)? A: There will be approximately 10 total and five (5) concurrent users. Page 5

6 25. Q: What are the dimensions associated/required with each KPI? e.g. turbidity by time, by analyzer, by plant, by other dimensions, etc.? A: Typical dimensions would consist of analyzer type, tag, location, reading, units and time. As vendor data dimension capabilities and offerings are all different, rather than have MWD explicitly define these up-front, it is expected that the respondent propose a solution. We expect that a mature system will have baseline dimensions defined and functional. As noted elsewhere in the RFP, refining detailed requirements, based on MWD s needs and the system s capabilities, is required. Iterative development and system tuning to meet these requirements is an encouraged approach. Based on this, we will work with the consultant to modify dimensions, where necessary, within minimal and reasonable limits, capabilities and changes, to obtain an acceptable system. 26. Q: What is the raw data throughput expected: e.g. 25 data sources, queried every 2 minutes, 15 parameters per data source, total size of all data extracted for all parameters in each 2 minute query. Storage requirements? A: There will be one data source (OPC DA). Vendor data collection application will function as a OPC DA client which requests data values from the MWD SCADA system OPC DA server. The vendor provided application must store data for analysis at 2 minute intervals. The number of parameters is defined in the RFP specification as follows: The EDS System shall be capable of accepting and processing data from 25 or more locations (up to 15 readings per location) and expandable to over 100 locations. The duration of online data storage is defined within the RFP as follows: Ability to tabulate data in real time and view current data with historic trends (e.g. selectable timeframes, up to one year).. Specific storage resource requirements will be dependent on vendor application. 27. Q: Does MWD have specific statistical rules which should be built into the system (GE Rules for SPC (Statistical Process Control)) or will it be using point violations (i.e. when a point goes above the upper control limit) to trigger alerts? A: As analysis rules, capabilities and offerings are all different between respondents, rather than have MWD explicitly define these up-front, it is expected that the respondent propose a solution. We expect that a mature system will have a baseline analysis system defined and functional. As noted elsewhere in the RFP, refining detailed requirements, based on MWD s needs and the system s capabilities, is required. Iterative development and system tuning to meet these requirements is an encouraged approach. Based on this, we will work with the consultant to modify their analysis systems, if necessary, within minimal and reasonable limits, capabilities and changes, to obtain an acceptable system. Page 6

7 28. Q: Regarding the software demonstration on p. 27 of the RFP... a) Q: Where will the demonstrations take place? At MWD, or at a supplier site? A: The software demonstration will take place at MWD facilities. Short listed respondents will be notified of a specific location. b) Q: For the 10 data sets that will be provided on the day of the demonstration, how large will the data sets be and how will they be provided? If the demo is at MWD, will we be able to FTP the data sets and will a network connection be provided? In what format will the data sets be provided? A: The data sets will be provided as csv files transported via USB flash drive. The data sets will include approx. four weeks of data collection for thirty seven parameters every two minutes. The format will be similar to the following: TAG_NAME, STATUS, DATE, TIME, VALUE. Vendor should be prepared to massage data format to meet their requirements. 29. Q: Page 8 item #7 Network integration with upstream/downstream data Can examples be provided? A: No. 30. Q: Please describe the desired rule capability and example, "Systems based strictly on simple rules-based logic (e.g. simple threshold alarms) and event detection will not be accepted. However, rules-based tools, as a supplement to algorithmic analysis, are encouraged." A: An example of simple rules based threshold alarms is alarming at a specific reading set point, e.g.; if chloramine residual > x.x [mg/l], then alarm. Strict rules based alarming is not acceptable as the primary alarming system (as stated in the RFP). A multivariate analysis must be used to perform analysis and determine alarms. Set point alarming, though acceptable as a supplement to multivariate analysis, is not sufficient to cover the multiple combinations of potential contaminant profiles. 31. Q: Page 11, under Application (second to last bullet). Please describe simulated operational and contaminant data overlays. A: These datasets will be created to simulate contaminant / instrument data profiles (per parameter) under various contaminant scenarios. 32. Q: Please elaborate on the use case that supports the following interface on page 18: EPA EDDIES (4.0 or newer, both RT and ET) A: Since MWD is currently collecting Water Quality data at two minute intervals using EDDIES RT. Data sets for vendor evaluations will be generated using the EDDIES ET. MWD will use the EDDIES ET to generate.csv data files. The vendor application should be able to use these data files as input to perform analysis. Additionally, EDDIES and Canary are established tools (though with limited support) that some vendors already interface with. MWD may utilize EDDIES and Canary as a supplemental tool to this EDS system. Page 7

8 33. Q: Data Types: a) Q: How are the analyzers interfaced with the RTUs? A: The interface between the instrument and the RTU varies by instrument type. However, this is irrelevant to the respondent as the data will be delivered to the vendor application via OPC, regardless of the interface. b) Q: What type of analyzers interface with the RTUs? A: See Section 2 Background of RFP. 34. Q: Scale of Application: a) Q: How many users can be on the system at the same time? A: There will be approximately 10 total and five (5) concurrent users. b) Q: What are the locations of the users? A: Users will be located anywhere within MWD s service area and network coverage, or even outside in cases of remote log-in. c) What are the various roles and security levels of users? A: User roles will vary from administrative to surveillance of alarms to extensive data analysis, tuning, and parameter setting. d) Is remote access to the application server available? A: Remote access to the application server can be made available, with security restrictions. MWD will purchase the server, within the vendor s requirements and MWD s guidelines stated in the RFP. Configuration and deployment will be a mutual effort. 35. Q: User Interface: a) Q: Does the current SCADA system have a graphical user interface? A: Yes, but it has operational and processing limitations and restrictions. Additionally, rather than present a processing burden to the SCADA system, an EDS-specific GUI shall be used. The interface to the SCADA system shall be limited to OPC-DA reads and writes. b) Q: Can the results of the EDS be displayed through the existing [SCADA] graphics. A: As an analog value or digital status (via OPC), yes. At a full GUI/ graphics and report processing and viewing level, no. 36. Q: Scope Diagnostics: a) Q: What are the expected diagnostics for each RTU? A: RTU diagnostics are not within the scope of this application. b) Q: What are the expected diagnostics between RTUs? A: RTU diagnostics are not within the scope of this application. Page 8

9 37. Q: SCADA: a) Q: In addition to the RTU information, what other data is available from the SCADA system? A: There are approximately 120,000 hard and calculated I/O points on the SCADA system These consist, generically, of flow, level, reading, alarm, position, status and digital (e.g. on/off, open/close) readings. b) Q: What SCADA software is installed that must be interfaced to? A: OPC DA Server. 38. Q: Schedule: a) Q: Is there a desired timeline for delivery? A: Six months to one year to be fully deployed. b) Q: Is there an incentive for an accelerated schedule? A: No 39. Q: Will you be publishing notes from the pre-proposal meeting? A: No. All information provided at the non-mandatory pre-proposal meeting is detailed in the RFP. -End of Document- Page 9