HomeMy WebLinkAboutRFP - 7190 METER DATA MANAGEMENT SYSTEMRFP – Meter Data Management System
Financial Services
Purchasing Division
215 N. Mason St. 2nd Floor
PO Box 580
Fort Collins, CO 80522
970.221.6775
970.221.6707
fcgov.com/purchasing
REQUEST FOR PROPOSAL
#7190 Meter Data Management System
The City of Fort Collins Utilities is soliciting proposals for Meter Data Management System
(MDMS), as an integral part of the smart grid components that are already in place and for
those that will be implemented as part of the Fort Collins Utilities Smart Grid project. To that
end, The City of Fort Collins Utilities is issuing this Request for Proposal (RFP) for a Meter Data
Management System that will enable Smart Grid applications and capabilities, and the water
and electric distribution systems that serve them.
Written proposals will be received at the City of Fort Collins' Purchasing Division, 215 North
Mason St., 2nd floor, Fort Collins, Colorado 80521. Proposals will be received before 3:00 p.m.
(our clock), January 11, 2011. Proposal No. #7190. If delivered, they are to be sent to 215
North Mason Street, 2nd Floor, Fort Collins, Colorado 80521. If mailed, the address is P.O. Box
580, Fort Collins, 80522-0580.
This contract is funded by the ‘‘American Recovery and Reinvestment Act of 2009’’ (ARRA). In
compliance with the ARRA contractors and subcontractor must adhere to the following
provisions as outlined in Attachment A (2 pages) immediately following this Invitation to Bid.
Questions concerning the scope of the project should be directed electronically to Project
Manager Dennis Sumner, dsumner@fcgov.com.
Questions regarding bid submittal or process should be directed to Opal Dick, CPPO, Senior
Buyer, odick@fcgov.com, (970)221-6778.
A copy of the Proposal may be obtained as follows:
1. Download the Proposal/Bid from the BuySpeed Webpage,
www.fcgov.com/eprocurement
2. Come by Purchasing at 215 North Mason St., 2nd floor, Fort Collins, and request
a copy of the Bid.
The City of Fort Collins is subject to public information laws, which permit access to most
records and documents. Proprietary information in your response must be clearly identified and
will be protected to the extent legally permissible. Proposals may not be marked ‘Proprietary’ in
their entirety. Information considered proprietary is limited to material treated as confidential in
the normal conduct of business, trade secrets, discount information, and individual product or
service pricing. Summary price information may not be designated as proprietary as such
information may be carried forward into other public documents. All provisions of any contract
resulting from this request for proposal will be public information.
Sales Prohibited/Conflict of Interest: No officer, employee, or member of City Council, shall have
a financial interest in the sale to the City of any real or personal property, equipment, material,
RFP – Meter Data Management System
2
supplies or services where such officer or employee exercises directly or indirectly any decision-
making authority concerning such sale or any supervisory authority over the services to be
rendered. This rule also applies to subcontracts with the City. Soliciting or accepting any gift,
gratuity favor, entertainment, kickback or any items of monetary value from any person who has
or is seeking to do business with the City of Fort Collins is prohibited.
Collusive or sham proposals: Any proposal deemed to be collusive or a sham proposal will be
rejected and reported to authorities as such. Your authorized signature of this proposal assures
that such proposal is genuine and is not a collusive or sham proposal.
The City of Fort Collins reserves the right to reject any and all proposals and to waive any
irregularities or informalities.
Sincerely,
James B. O'Neill II, CPPO, FNIGP
Director of Purchasing & Risk Management
RFP – Meter Data Management System
ATTACHMENT A - ‘‘American Recovery and Reinvestment Act of 2009’’
Procurement Provisions:
This contract is funded by the ‘‘American Recovery and Reinvestment Act of 2009’’ (ARRA). In
compliance with the ARRA contractors and subcontractor must adhere to the following
provisions:
ARRA TITLE XV—ACCOUNTABILITY AND TRANSPARENCY
BUY AMERICAN
SEC. 1605. USE OF AMERICAN IRON, STEEL, AND MANUFACTURED GOODS.
(a) None of the funds appropriated or otherwise made available by this Act may be used for a
project for the construction, alteration, maintenance, or repair of a public building or public work
unless all of the iron, steel, and manufactured goods used in the project are produced in the
United States.
(b) Subsection (a) shall not apply in any case or category of cases in which the head of the
Federal department or agency involved finds that—
(1) applying subsection (a) would be inconsistent with the public interest;
(2) iron, steel, and the relevant manufactured goods are not produced in the United
States in sufficient and reasonably available quantities and of a satisfactory quality; or
(3) inclusion of iron, steel, and manufactured goods produced in the United States will
increase the cost of the overall project by more than 25 percent.
(c) If the head of a Federal department or agency determines that it is necessary to waive the
application of subsection (a) based on a finding under subsection
(b), the head of the department or agency shall publish in the Federal Register a detailed written
justification as to why the provision is being waived.
(d) This section shall be applied in a manner consistent with United States obligations under
international agreements.
WAGE RATE REQUIREMENTS SEC. 1606.
Notwithstanding any other provision of law and in a manner consistent with other provisions in
this Act all laborers and mechanics employed by contractors and subcontractors on projects
funded directly by or assisted in whole or in part by and through the Federal Government
pursuant to this Act shall be paid wages at rates not less than those prevailing on projects of a
character similar in the locality as determined by the Secretary of Labor in accordance with
subchapter IV of chapter 31 of title 40, United States Code. With respect to the labor standards
specified in this section, the Secretary of Labor shall have the authority and functions set forth
in Reorganization Plan Numbered 14 of 1950 (64 Stat. 1267; 5 .S.C. App.) and section 3145 of
title 40, United States Code.
RFP – Meter Data Management System
4
ECONOMIC STABILIZATION CONTRACTING SEC. 1611. HIRING AMERICAN WORKERS IN
COMPANIES RECEIVING TARP FUNDING.
(a) SHORT TITLE.—This section may be cited as the ‘‘Employ American Workers Act’’.
(b) PROHIBITION —
(1) IN GENERAL — Notwithstanding any other provision of law, it shall be unlawful for any
recipient of funding under title I of the Emergency Economic Stabilization Act of 2008
(Public Law 110–343) or section 13 of the Federal Reserve Act (12 U.S.C. 342 et seq.) to hire
any nonimmigrant described in section 101(a)(15)(h)(i)(b) of the Immigration and Nationality Act
(8 U.S.C. 1101(a)(15)(h)(i)(b)) unless the recipient is in compliance with the requirements for an
H–1B dependent employer (as defined in section 212(n)(3) of such Act (8 U.S.C.1182(n)(3))),
except that the second sentence of section 212(n)(1)(E)(ii) of such Act shall not apply.
(2) DEFINED TERM — In this subsection, the term ‘‘hire’’ means to permit a new employee to
commence a period of employment.
RFP – Meter Data Management System
5
TABLE OF CONTENTS
REQUEST FOR PROPOSAL .................................................................................................................... 1
ATTACHMENT A - ‘‘American Recovery and Reinvestment Act of 2009’’ .......................................... 3
TABLE OF CONTENTS............................................................................................................................ 5
REQUEST FOR PROPOSAL .................................................................................................................... 6
1 Introduction......................................................................................................................................... 6
2 Objective............................................................................................................................................. 7
3 Background......................................................................................................................................... 8
4 Request for Proposal Schedule ........................................................................................................... 9
5 Project Scope and Expectations.......................................................................................................... 9
6 Offeror Instructions........................................................................................................................... 12
7 List of Appendices ............................................................................................................................ 14
8 Method of Award.............................................................................................................................. 14
9 Selection Process .............................................................................................................................. 15
10 Submittal........................................................................................................................................... 19
11 Company Background ...................................................................................................................... 19
12 Financial Background ....................................................................................................................... 22
13 MDMS Functional Requirements..................................................................................................... 23
14 MDMS Integration Requirements..................................................................................................... 50
15 MDMS Information Technology & Security Requirements ............................................................ 57
16 MDMS Implementation Services ..................................................................................................... 72
EXHIBIT A - Terms and Conditions........................................................................................................ 74
RFP – Meter Data Management System
6
REQUEST FOR PROPOSAL
Fort Collins Utilities Request For Proposal For Meter Data Management System
1 Introduction
Fort Collins Utilities seeks to implement an advanced metering infrastructure (AMI) and a meter data
management system (MDMS) that will operate as an integral part of the smart grid components that are
already in place and for those that will be implemented as part of the Fort Collins Utilities Smart Grid
project. To that end, The City of Fort Collins Utilities is issuing this Request for Proposal (RFP) for a
Meter Data Management System that will be integrated with the advanced metering infrastructure that
will enable Smart Grid applications and capabilities, Home Area Networks (HAN) to enhance interaction
between our customers and the water and electric distribution systems that serve them.
Fort Collins Utilities currently reads meters in one of two ways each month:
Manually using handheld data collection devices that download through Itron’s MVRS interface
(residential meters),
Through an Itron MV90 automated meter reading (AMR) system (commercial / industrial
customers).
Manufacturers of systems or system integrators who are proposing solutions in response to this RFP,
hereinafter referred to as “Offeror” or “Offerors,” shall address compatibility, integration, and integration
support between their proposed system and other systems described in this RFP. If an Offeror will offer
project management support during installation and implementation for their MDMS, it shall also be
described in the response.
The Fort Collins Smart Grid Project is supported through the American Reinvestment and Recovery Act
(ARRA) Smart Grid Investment Grant (SGIG), so Offerors are advised that bids to this RFP should
comply with all applicable requirements of ARRA funding. The successful Offeror’s contract will include
terms that the Offeror understands and will comply with all applicable ARRA requirements. Provisions
of ARRA funding that may be of specific concern to Offerors include Buy America and the Davis Bacon
Act requirements.
The Fort Collins Smart Grid Project encompasses a number of technologies intended to enhance
electric delivery and reliability to modernize the electric grid, and support other developing technologies
that will either feed into or draw from the distribution system. The project will link energy usage and
home area networks, automate and optimize grid operations to improve reliability and efficiency, enable
customers to control energy usage. Fort Collins Utilities expects to own and operate the
communications infrastructure and MDMS system described herein and expects it to be a flexible,
scalable foundation for the smart grid applications described above as well as other wireless, IP-based,
and broadband applications as may be needed in the future.
RFP – Meter Data Management System
7
2 Objective
Our goals of energy conservation, demand reduction, integration of renewable and conventional
distributed generation (DG), and transition from traditional gasoline powered vehicles to Plug-in Hybrid
Electric Vehicles (PHEV) and electric vehicles (EV) requires an increase in the level of communication,
control, and data collected on the distribution system. To achieve our aggressive conservation and
demand reduction goals, we must provide feedback to customers as they request it, rather than once a
month at the end of a billing period. This will provide customers an opportunity to take a more active
role in controlling their energy usage. The infrastructure required to meet our goals begins with the
installation of an Advanced Metering Infrastructure (AMI) system comprising 64,223 electric meters,
33,728 water meters, supported by a communications system able to connect those meters to the other
applications described herein as part of the Fort Collins Utilities smart grid project.
AMI meters will be the basis of the enhanced interface between the utility distribution system and our
customers. The ability to monitor loads and reconfigure the system in response to changing demand is
critical to enable the integration of the growing number of DG and PHEVs. The development of the
Smart Grid cannot be achieved without the successful implementation of a communication
infrastructure with adequate bandwidth to move and manage large volumes of data. The ability to store,
manage, and mine the data from the AMI meters will be an important part of our smart grid project, and
is considered an integral part of a successful project.
Offerors to this request for proposal (RFP) will be asked to address a number of aspects including but
not limited to the following:
MDMS compatibility with existing systems, current capabilities and considerations for future
expansion
Compatibility with Demand Response system aspects to enable customer response during peak
periods and help manage loads, including Home Area Network (HAN), in-home thermostats
(IHTs) with informational displays, in-home displays (IHDs), and air conditioning (AC) and water
heater control switches
Security Enhancements and security considerations (cyber-security and physical security)
Integration of home area network (HAN) technologies with demand response technologies will proceed
once the AMI system and MDMS are in place, so it is critical that the Offeror describe in detail the
capabilities of the HAN communications capabilities of their proposed system and ability to
communicate with other HAN technologies.
The Fort Collins Smart Grid Project will enable Fort Collins Utilities to meet specific strategic objectives
related our long range technology strategic plan. The Smart Grid project strictly aligns with, and is
critical to, the success of meeting each of the utility objectives identified below.
RFP – Meter Data Management System
8
2.1 Overarching Technology Requirements
Flexible and robust technology that will take us well into the future and not become prematurely
obsolete.
Vendor neutrality. We expressly must avoid getting locked into a solution that forces utilization
of a specific meter manufacturer or AMI-associated technology vendor on an on-going basis or
to the detriment of future expansion possibilities.
Solutions selected/deployed utilize open standards based architecture.
Recognition that Data and pragmatic use of the data is a key goal of the project.
All technology components must integrate with existing legacy systems, such as our current CIS
billing system.
Adherence to important, emerging, open industry standards.
Deployed technology must be changeable and interoperable with future systems and with new
technologies.
2.2 Respondent Experience
Demonstrable prior experience in successful MDMS deployments.
Must show quick forward momentum from the onset. Offeror must recognize that our project is
time-bound and parse out deliverables to appropriately meet our aggressive timeframe
3 Background
Utility provides electric service throughout the city limits and a small portion of the suburban fringe limits
(approximately 53 square miles). Water service is provided to the central portion of the city limits and
some suburban fringe (approximately 28 square miles). City population is estimated at 137,200 as of
July 2009.
The following is a summary of active customers’ electric and water meters as of February 1010.
Electric Customers by Type of Meter
Type of Meter Active Meters
Residential 57,034
Commercial Single Phase 3,916
Commercial Poly Phase 3,273
TOTAL 64,223
RFP – Meter Data Management System
9
Water Customers by Type of Service
Type of Service Active Meters
Residential 30,963
Commercial 2,765
TOTAL 33,728
4 Request for Proposal Schedule
The expected schedule for the response for proposal is as shown below.
Event Date
RFP Released November 23, 2010
Cutoff date for Offeror Questions December 10, 2010, 3:00 pm MST
All responses to Offeror Questions
answered December 17, 2010, 3:00 pm MST
Responses to RFP Due January 11, 2011, 3:00 pm MST
Read/Review Proposals Jan. 12. – Feb. 11, 2011
Shortlist Interview Presentations Feb. 14 – 18, 2011
Final Offeror Recommendation February 28, 2011
5 Project Scope and Expectations
Fort Collins plans to deploy an AMI system covering 100% of our service territory with an integrated
system comprising both electric and water meters. All existing electromechanical electric meters will be
replaced with solid state electronic meters designed to communicate with an AMI system capable of
supporting the features discussed in this RFP. More than one technology meeting geographic needs
may be necessary. Interoperability, therefore, is going to be a key consideration in this project and in
the selection of the AMI and MDMS systems.
Fort Collins is planning on implementing the AMI/MDMS in three phases (the schedule is reflected in
Appendix C):
Phase 1 – Basic Meter to Cash. This consists of an AMI deployment of approximately 4,000
electric and 2,000 water meters. MDMS functionality in support of provisioning, commissioning,
and billing existing Fort Collins’ consumption and demand rates will be supported.
Phase 2 – Interval Billing. Mass deployment of AMI meters will be underway. MDMS
functionality to support interval billing will be enabled. Simple TOU rate capabilities will be
implemented along with real-time business processes for on-demand reads. Basic web portal
presentment of consumption and demand billing rates will be enabled.
Phase 3 – Advanced Rates. Additional rates may be configured in the MDMS. Such rates may
include a range of dynamic pricing, critical peak pricing, and related advanced billing rate
structures. ‘Rate Analysis’ capabilities will be enabled. Also service order processes and
integration with the web portal will be deployed, along with presentment of interval and TOU rate
RFP – Meter Data Management System
10
structures. HAN and Demand Response capabilities will be enabled. Real-time business
processes for remote connects/disconnects will be enabled.
System features include two-way communication between the meters, collectors and the master
station, consumption and demand meter reads, load profile capabilities, meter status indications,
remote disconnect for single phase electric meters, in-home thermostats (IHTs) and in-home displays
(IHDs) with displays capable of sharing information through the AMI system with the customer, air
conditioning (AC) and water heater control switches, load management, outage management
integration, power quality monitoring, time of use (TOU) and critical peak pricing (CPP) billing, voltage
monitoring, integration with HANs and DG. The aforementioned features of the AMI system must also
be support by the MDMS system.
The following outlines the various AMI components and features that Offerors to this RFP must
address:
5.1 AMI Meters
The AMI meters included in the project shall be advanced, solid state, digital devices capable of
recording hourly and sub-hourly interval data. Interval data will include energy consumption and may
also include additional quantities such as voltage, and power factor information. The meters will also be
capable of calculating both TOU and CPP rates, outage and tamper detection, interval meter data and
power quality monitoring. AMI meters will support bi-directional communications between the meter and
the Master Station and net metering capabilities to enable renewable DG installations. Water meter
nodes should be capable of providing backflow detection.
5.2 Meter Data Management System
With AMI, Fort Collins Utilities plans to record meter readings at 15-minute intervals, and possibly 5-
minute intervals for limited customer classes, creating new challenges in the storage, management,
analysis and distribution of the data.
The MDMS needed to manage meter data will provide data validation and editing, storage, archiving,
retrieval, and will interface to a large variety of critical utility business systems. The MDMS will provide
the meter data storage and management platform, allow links to business applications and analysis
tools to enable staff to make use of the AMI data and will supply available information to customers.
MDMS will provide the basics such as collection, storage, management, and validation of meter
readings (including estimations and data editing), meter asset management functions, support for
virtual connects/disconnects (through the service switches in the electric meters), on-demand reads,
high/low usage monitoring, and coordination of service orders, support for rate design and analysis
functions.
MDMS also will provide support for customer service representatives, customer bill inquiries, real-time
customer support via phone, e-mail, and on-line web access, data transfer to an outage management
system (OMS), enhanced customer support and information, electric system planning and design,
system loss detection/estimation and other advanced applications.
5.3 Billing System
Fort Collins employs Ventyx “Customer Suite” (formerly known as Banner)for billing functions. Offerors
to this RFP who propose an MDMS as part of the AMI system will be required to provide compatibility
with Fort Collins Utilities’ CIS system.
RFP – Meter Data Management System
11
5.4 Customer Interface and Billing Options
Online presentment is the facility by which utility customers can view their usage information via web-
based services. This online facility may be housed and administered through the AMI headend, as part
of the MDMS, or through a system securely linked to either of the aforementioned systems. For
presentation to external end users (e.g., the online presentment application), the system shall support
the protection and masking of sensitive data Personal Identifying Information.
Customers will be provided enhanced billing options such as selectable bills dates, grouped billing for
those customers with more than one account, and off-cycle billing eliminating the need for utility
personnel to physically visit each site for a final read out and bill thereby reducing utility costs.
5.5 Load Analysis Information
AMI is expected to provide the information necessary to properly plan, forecast, and understand system
loads and formulate decisions for more effective results. Properly sized transformers and distribution
equipment will reduce electricity costs and improve system reliability. Understanding system loads is
essential to this task; therefore, Fort Collins Utilities seeks to have useful, granular data on system
loads. Such analysis capability must exist in either the head-end or MDMS.
5.6 Service Switch
Internal service switches will be installed on all residential AMI meters. This feature will allow remote
disconnection and reconnection of electric service via the AMI network, eliminating the need for utility
personnel to physically visit each site. The service switch also will allow for future pre-payment
applications and load limiting capabilities.
5.7 Outage Management
Outage management is extremely important to Fort Collins Utilities. Utilities will leverage existing OMS
and utilize the capabilities of AMI and grid automation to improve grid reliability by more quickly and
accurately identifying the location and magnitude of an outage, resulting in faster restoration. The OMS
will be integrated with other utility data systems so that service restoration information is available to
utility staff, emergency services and to customers in near real-time.
5.8 Fraud/Tamper Detection
Fort Collins Utilities plans to utilize tamper detection features provided by AMI to reduce revenue losses
and create a proactive approach to identifying theft of service. The AMI system shall offer a variety of
tamper detection features, including under voltage registration device contained within the meter,
reverse energy flow, tilt features, and others.
5.9 Demand Response and HAN
Fort Collins Utilities expects to offer our customers the ability to take a more active role in controlling
their own consumption, demand, and resulting costs. Fort Collins is interested in obtaining information
regarding customer response to time-varying rates and incentives, IHTs, AC control and water heater
control switches used to reduce peak demand and overall energy consumption.
Fort Collins’ current Load Management Program controls approximately 2,000 electric water heaters,
1,000 AC units and 30 commercial customer loads via a Comverge one-way radio-frequency system.
To improve control reliability, and fine-tune maintenance of the existing system load control program
RFP – Meter Data Management System
12
Fort Collins expects to transition to a two-way communication system integrated with the home area
network (HAN) capabilities of the AMI system described in this RFP. Offerors to this RFP will be asked
to describe the interoperability of their HAN solution with end-user devices as well as the capability of
their software to communicate with the devices via the AMI system.
The proposed demand response and direct load control project will install “smart” programmable
communicating IHT units with displays capable of delivering electricity pricing information, notification of
peak periods, and custom messaging to our customers.
5.10 SCADA and OMS Integration
Fort Collins utilizes an open architecture Ole for Process Control (OPC) SCADA system. The Human
Machine Interface (HMI) software is provided by Iconics and a standard OPC server is used to
communicate with field devices capable of running a multitude of protocols. The open architecture
design allows for unlimited protocols and full integration of security, data acquisition and control, and
power quality waveform capture.
It is through this OPC protocol that we expect to pass information to our outage management system in
a secure fashion. Offerors will be asked to describe the capabilities of passing electric meter “last gasp”
signals from the MDMS or AMI headend to our SCADA system, which houses our OMS.
6 Offeror Instructions
6.1 General
Offeror shall propose a MDMS solution that addresses all Fort Collins’ requirements per the
specifications provided herein.
Offeror may sub-contract a portion of this work to one or more sub-contractors as part of its bid subject
to Fort Collins’ approval.
Offerors providing a joint proposal shall clearly define the technologies and/or services proposed by
each Offeror, and the aspects of the solution being addressed by each Offeror. Offerors shall provide a
full response per the specifications provided herein, for each proposed solution.
Throughout this document, the term “shall” is intended to identify specifications of the proposed MDMS
solution that the Offeror must meet or address. The term “optional” is intended to identify desired
specifications that the Offeror is encouraged to provide.
The functional, performance, information, and physical specifications for Fort Collins’ MDMS system
are provided as follows:
• Section 11: Company Background. These request information about the Offeror’s market
experience and references.
• Section 12: Financial Background. These request information about the Offeror’s financial
standing.
• Section 13: MDMS Functional Requirements. These are the application level functional
specifications to be supported by the MDMS. These specifications shall be met by the system
proposed; however, Fort Collins is not prescribing how the system will meet these
specifications.
RFP – Meter Data Management System
13
• Section 14: MDMS Integration Requirements. These are the requirements regarding
interfaces that may be needed to support system integration with other information systems.
• Section 15: MDMS Information and Technology Requirements. These provide the non-
functional requirements of the Offeror’s MDMS including performance, security, database
management, reporting functionality, etc.
• Section 16: MDMS Implementation Services. These are the implementation services and
processes required by the Offeror to ensure project management capabilities, appropriate
delivery, and integration methodology, solution implementation procedures, data management,
and configuration management.
Offerors shall provide complete written responses to each specification citing exact functionality and
performance with sufficient support to enable Fort Collins to ascertain the validity of a response.
For requirements that don’t request a description, provision of information or some other form of input,
Offeror shall indicate compliance.
In addition to a written description of system capability, the Offeror may submit supporting material
attachments as appropriate and clearly labeled within a reference point within the requirement to a
master table of response Exhibits (with externally protruding labeled tabs inserted), for such things as
system or platform drawing, GUI screen shots, and prescribed system documents.
It is critical that the Offeror clearly identify at the start of each written response whether the capabilities
that it describes are currently available in the existing product “core,” are “planned”, or require
“customization”. Unless the Offeror identifies within its written answer that the capability does not exist,
Fort Collins will assume that it is existing and if chosen, the Offeror will be required to provide this
capability.
Offeror shall also provide indication of compliance for all requirements at the beginning of the response
as displayed in the Example requirement. This shall be indicated by one of the following:
• “Comply” – Core product, current availability
• “Not Comply” – no compliant solution, roadmap item, etc.
Written responses shall be inserted directly into the structure of this document without alteration of the
numbering scheme. The document template includes a “Response” style that shall be used for all
responses (as shown below).
This is an example requirement:
Response: <Comply/Not Comply>; <Core/Planned/Customization>
<Written description or clarification; screen shots as necessary>
Offerors are advised to avoid introduction of new styles into the response document in order to maintain
document integrity by using Microsoft Word’s “Paste special …unformatted text” feature when pasting
existing text from other sources.
6.2 Pricing and Bidding Options
Respondents should respond to this RFP with itemized costs for the components of the system making
sure that residual or maintenance fees for software, firmware, and hardware are clearly described.
Respondents to this RFP may propose:
RFP – Meter Data Management System
14
Option 1 – standalone bid for AMI and/or MDMS
Option 2 – combined bid for AMI and MDMS
If the Offeror selects Option 1, the Offeror will submit a proposal consist with the specific RFP being
bid.
If the Offeror is bidding Option 2, the Offeror will submit proposals for both the AMI and MDMS RFPs.
The Offeror must meet the requirements for both RFPs. Fort Collins will not separate the Offeror’s
response for Option 2. The proposal will only be considered as a complete solution.
If the Offeror wants to be considered under both Options, the Offeror will need to submit pricing
worksheets for both Option 1 and Option 2. For example, an Offeror bidding AMI and MDMS for both
options, would submit 4 pricing worksheets – AMI Option 1, MDMS Option 1, AMI Option 2, and MDMS
Option 2.
Offeror shall refer to Appendix D – Pricing Instructions – Fort Collins MDMS Technology RFP, for
instructions on how Offeror is required to provide pricing information for the requirements contained
within this RFP.
If the Offeror bids Option 2, the Offeror should provide additional documentation in a separate appendix
to address the following topics:
A summary of the Option 2 proposal.
A summary description of the differences between the Option 1 and Option 2 proposals, if any.
The advantage to Fort Collins in selecting the Offeror’s Option 2 proposal.
7 List of Appendices
Included as part of this RFP are the following Appendices. These Appendices are referenced in the
sections shown in parentheses.
Appendix A – Fort Collins IT Standards and System Infrastructure
Appendix B – Fort Collins Information Systems
Appendix C – Smart Grid Implementation [Summary] Schedule
Appendix D – Pricing Instructions – Fort Collins MDMS Technology RFP
Appendix E-1 – Option 1 - MDMS Pricing Workbook
Appendix E-2 – Option 2 - MDMS Pricing Workbook
8 Method of Award
The City of Fort Collins will review and rank submittals based on the criteria provided in this Request for
Proposal. Award shall be made as described in Section 9, “Selection Process.”
RFP – Meter Data Management System
15
9 Selection Process
9.1 Minimum Compliance Review
9.1.1 Further Consideration of Offeror’s Proposal
Offeror’s proposal will be reviewed to determine if it meets Minimum Compliance Requirements for
further consideration. If it is concluded by the City of Fort Collins that Offeror’s proposal does not meet
these requirements the proposal will be rejected at this point and will not receive any further
consideration. This review shall be based on the sole determination of the City of Fort Collins and the
conclusions of this review shall be final.
Offeror is advised that they shall not have the opportunity to address any deficiencies after their
proposal has been submitted. Proposal should be complete and clearly include the required
information described below.
Minimum MDMS Requirements for Initial Review Requirement Number
The Offeror’s MDMS is supporting at least one electric AMI
deployment the same size or larger than Fort Collins.
10.6, 13.4.1.1
The Offeror’s MDMS is supporting at least one water AMI
deployment the same size or larger than Fort Collins.
10.6, 13.4.2.1
The Offeror’s MDMS architecture must not require any UNIX
operating system.
15.1.1.1, 15.1.3
The Offeror’s MDMS must apply meter multipliers to meter data
after it is received from the AMI system.
13.2.1.3.1
The Offeror’s MDMS must be capable of handling meter
multipliers with a value less than one (e.g., 0.04).
13.2.1.3.4
The Offeror must submit the required document on project
methodology and scope defined in section 16.2
16.2
For System Data and Security (Sect. 15.5), Utility seeks evidence
that the Offeror meets or intends to meet the spirit of currently
released and applicable security standards including but not
limited to NIST SP 800-53 and FIPS 140-2.
15.5
9.2 Initial Proposal Review
9.2.1 Intention of Initial Review
The intention of the Initial Review is to narrow the number of proposals for further consideration to the
top three. The exact number of proposals to receive further review will be at the sole determination of
the City. That determination will be based on factors that include the numeric evaluation of proposals
based on the Initial Proposal Review and comparative numeric distribution of those numeric ratings.
9.2.2 Evaluation Criteria and Weighting
RFP – Meter Data Management System
16
Offeror’s written proposals that pass the Minimum Compliance Review will be evaluated using the
following criteria and comparative weighting factors.
Weighting
Factors
Qualification Standard
20% Cost / Pricing Each rater will score based on normalized
pricing information and value for the proposed
solution. Does the proposed solution compare
favorably with the Utilities needs and budget?
30% MDMS Functional
Requirements
To what extent does the proposer's solution
meet the specification and operational
requirements of the MDMS.
20% MDMS Integration
Requirements
To what extent does the proposer's solution
meet the integration requirements of the
MDMS.
15% MDMS Information
Technology and Security
Requirements
Does the proposer adequately address the
NIST SP 800-53 control families identified in
the technical requirement of this RFP? To
what extent does the proposer's MDMS
solution meet the specification and
operational requirements identified in this
RFP?
15% Proposer Capabilities,
System Implementation and
Operations Specifications
Does the proposer who will be working on the
project have the necessary skills, equipment
and methodology to satisfy the project needs
and successfully transfer knowledge and
operations to the Utility? Are sufficient people
of the requisite skills assigned to the project?
Does the proposer demonstrate past
experience in implementing, project managing
other Smart Grid projects to successful
completion? What has been their success
rate in delivering quality results in prior
engagements? Is the firm interested and are
they capable of doing the work in the required
time frame?
9.2.3 Cost / Pricing Determination
Based on information included in the written proposals, the City shall determine what it believes to be
the anticipated Lifecycle costs of the respective proposal. That Lifecycle cost shall serve as the basis
for the Cost / Pricing component of this evaluation.
In addition to the use of factors included in written proposal, Lifecycle cost determination may include
and will not be limited to factors such as:
Utility systems growth
Cost escalation factor
Maintenance cost for system infrastructure
RFP – Meter Data Management System
17
9.2.4 Proposal Evaluation Process
Written proposals will be evaluated by a City of Fort Collins Team. Members of that team shall
independently evaluate each technical qualification category as included in the above evaluation criteria
listing. Those individual ratings will be combined into a total evaluation for each proposal to determine
the total numeric rating of that proposal.
9.3 Short List Evaluation of Proposal and Interview
9.3.1 Offeror Interview
City will provide a detailed agenda for Offeror to address in the Offeror Interview. It is anticipated this
interview will be a one to two day session at the City’s site, 700 Wood Street, Fort Collins CO.
9.3.2 Best and Final Offer
It is anticipated that both the Offeror and the City will gain added insight into one another through the
above process to this point. It is further anticipated, that based on that added insight gained by the
Offeror and any additional factors of consideration to the Offeror, the Offeror may desire to offer a Best
and Final offer for the City’s consideration in selecting an Offeror for contract negotiations. Those
improved details from the Offeror’s offer might include increased warranty provisions, reduced pricing,
provision of additional functionality or services, etc.
9.3.3 Short List Evaluation Criteria and Weighting
Offeror final comparative review will be evaluated using the following criteria and comparative weighting
factors.
Weighting
Factors
Qualification Standard
30% Cost / Pricing Each rater will score based on normalized
pricing information and value for the proposed
solution. Does the proposed solution compare
favorably with the Utilities needs and budget?
20% MDMS Functional
Requirements
To what extent does the proposer's solution
meet the specification and operational
requirements of the MDMS.
20% MDMS Integration
Requirements
To what extent does the proposer's solution
meet the integration requirements of the
MDMS.
15% MDMS Information
Technology and Security
Requirements
Does the proposer adequately address the
NIST SP 800-53 control families identified in
the technical requirement of this RFP? To
what extent does the proposer's MDMS
solution meet the specification and
operational requirements identified in this
RFP?
RFP – Meter Data Management System
18
Weighting
Factors
Qualification Standard
15% Proposer Capabilities,
System Implementation and
Operations Specifications
Does the proposer who will be working on the
project have the necessary skills, equipment
and methodology to satisfy the project needs
and successfully transfer knowledge and
operations to the Utility? Are sufficient people
of the requisite skills assigned to the project?
Does the proposer demonstrate past
experience in implementing, project managing
other Smart Grid projects to successful
completion? What has been their success
rate in delivering quality results in prior
engagements? Is the firm interested and are
they capable of doing the work in the required
time frame?
9.3.4 Cost / Pricing Determination
The City shall use all cost/pricing information as determined to this point including Lifecycle costs in the
comparative evaluation of the cost/pricing proposals.
9.3.5 Proposal Evaluation Process
Comparative numeric evaluations of the Offerors who are on the Short List will be done by the City.
Final determination of the highest evaluation will be done at this time and shall be at the sole
determination of the City.
9.4 Final Selection and Contract Negotiations
9.4.1 Reference Checks
City will make reference checks on the Offeror selected for contract negotiations. Based on the City’s
conclusion from those contacts, the City will determine at its sole discretion if contract negotiations will
proceed with the given Proposer. Any information gained in these reference checks shall be
considered privileged and private information between the City and the party providing reference
comments and shall not be made available to any other party.
The City Utilities’ Project Manager will check references. Criteria for those reference checks may
include the following or other qualifications. The evaluation rankings will be labeled
Satisfactory/Unsatisfactory.
Qualification Standard
Overall Performance Would you hire this Professional again? Did they show the skills
required by this project?
Timetable Was the original Scope of Work completed within the specified
time? Were interim deadlines met in a timely manner?
Completeness Was the Professional responsive to client needs; did the
Professional anticipate problems? Were problems solved quickly
and effectively?
RFP – Meter Data Management System
19
Qualification Standard
Budget Was the original Scope of Work completed within the project
budget?
Job Knowledge If a study, did it meet the Scope of Work?
If Professional administered a construction contract, was the
project functional upon completion and did it operate properly?
Were problems corrected quickly and effectively?
9.4.2 Critical Time Table
Contract negotiations between the City and the selected Offeror are time critical. The City reserves the
right at any time in the contract negations to terminate these negotiations if in the City’s sole opinion
these negotiations are not proceeding towards the City’s best interests. Factors that will contribute to
those considerations include any all details concerning costs, terms and conditions and the time
required to try and reach a final contract with the Proposer.
10 Submittal
Offeror will submit the following items to the City of Fort Collins, Purchasing Division, per the following
schedule:
Event Date
Responses to RFP due January 11, 2011, 3:00 pm MST
Submit an electronic copy to the City of Fort Collins, Purchasing Division: purchasing@fcgov.com.
Electronic copy can be sent via email, on a CD or USB flash drive.
Submit a total of fourteen (14) printed copies to the City of Fort Collins, Purchasing Division.
11 Company Background
11.1 Offeror shall provide the name of vendor (include address) submitting the proposal to which
Fort Collins will engage in the contractual obligations. Please also provide the name and
contact information for a single point of contact (include phone, email, address and fax).
Response:
RFP – Meter Data Management System
20
11.2 Offeror shall list all affiliates of the contracting entity including subsidiaries, parent company
(ies), and all other subsidiaries of the parent company (ies). An entity is a parent if it directly (or
through intermediate entities) owns or controls at least 10% of the stock (or analogous voting
interests) of another company. An entity is a subsidiary if it has one or more parents.
Response:
11.3 Offeror shall provide a chart of all ownership relationships from the parent company through all
direct and indirect subsidiaries of the contracting entity.
Response:
11.4 Fort Collins wishes to engage with a MDMS supplier that possesses sufficient experience in the
design, delivery, and support of MDMS implementations. The MDMS solution for Fort Collins
will act as a core component in enabling a variety of initiatives and benefits to Fort Collins and
its customers. The Offeror should use this section to provide sufficient information for Fort
Collins to understand its experience, capabilities and vision with regard to MDMS solutions.
Response:
11.5 Provide a list of alliances and/or formalized partnerships that complement your product/service
offering. Ensure alliances and partnerships highlighted include all relevant aspects of Fort
Collins’ AMI technologies, IT platform, system integration, support services, industry standards
setting organizations, and total program management or primes.
Response:
11.6 Provide a list of your MDMS solution deployments for utilities or
municipal electric companies in North America. For each deployment:
Name the utility or municipality.
Indicate number of endpoints supported (breakdown by electric, gas and
water endpoints).
Indicate the number of AMI endpoints supported to date. Distinguish by
deployed and operating vs. under contract, and by production vs. pilot.
Indicate the extent of demand response (DR) and/or home area network
(HAN) capability supported. Please include the actual number of In-home
devices registered on the system.
RFP – Meter Data Management System
21
Indicate the initial installation date for the MDMS solution, the initial
version level deployed and the current version level.
Indicate whether the project is a pilot/trial or in production mode.
Indicate what types of advanced rates are being created by the MDMS.
Indicate the level of metering information being managed (i.e. daily or
monthly register reads, interval data (indicate interval length).
Provide the name of the AMI system vendor that Offeror has integrated or
plans to integrate its head-end with to date.
If the cited deployments are pilots/trials, provide details regarding the
progress, evaluation criteria, and expected outcome.
If cited deployments are in progress, provide details regarding major
deployment milestones and expected completion.
Indicate, by name, any partners, particularly system integrators, that
participated in the deployment, and their level of participation.
Response:
11.7 From the above list of all deployments, provide at least three verifiable references and all
relevant contact information. References should address electric meter solution experience.
Fort Collins intends to contact these references. Fort Collins reserves the right to request
additional references.
Response:
11.8 Identify the key differentiators of your solution relative to your competitors. Offeror should
ensure that these differentiators are appropriate to a utility the size and structure of Fort Collins.
Response:
11.9 Is there a User’s Group for your MDMS product and if so, how often does your User’s Group
meet? How is the User’s Group managed? Explain how user’s input is included and prioritized
in the roadmap and enhancement process of the product.
Response:
RFP – Meter Data Management System
22
11.10 Is your firm currently pursuing legal action against another entity related to your MDMS
solution? Is your firm currently defending itself against legal action related to your MDMS
solution? Provide details about either scenario if applicable.
Response:
12 Financial Background
12.1 Offeror shall provide its Tax Identification Number (TIN).
Response:
12.2 Offeror shall provide copies of your company’s audited annual financial statements for the two
most recently completed fiscal years.
Response:
12.3 Offeror shall list all major investments in the last two years relative to asset acquisition, capital
infrastructure upgrades, etc as it relates to the scope of this RFP.
Response:
12.4 Describe the MDMS solutions that you offer and the estimated percentage of total annual
revenues for MDMS solutions as compared to total corporate revenue. Please also indicate
the annual R&D investment made into the MDMS solution.
Response:
12.5 Offeror shall state your Company’s relevant assets (in dollar value) as they relate to the scope
of this RFP.
Response:
RFP – Meter Data Management System
23
12.6 Offeror shall provide its most current financial ratings from Moody's. Please identify any
changes in ratings in the last two years.
Response:
12.7 Offeror shall provide the most current financial ratings from S&P. Please identify any changes
in ratings in the last two years.
Response:
12.8 Offeror shall provide its Dun and Bradstreet number and current ratings.
Response:
12.9 Offeror shall indicate any involvement in any sale, merger or acquisition activity. If yes, please
explain.
Response:
12.10 Offeror shall indicate if it has ever filed for bankruptcy.
Response:
12.11 Offeror shall describe how it anticipates meeting the financial obligations and resource
requirements of this project.
Response:
13 MDMS Functional Requirements
13.1 Bid Version
13.1.1 The Offeror shall identify the version of its solution that is the basis for the functional
requirements in this bid. (By definition, any functionality identified by the Offeror as “comply” in
the remaining sections of this document pertain to the version identified in this question.) The
Offeror shall identify if the bid version is not the current production release. If it is not the
current production release, the Offeror shall identify the schedule release date of this version;
RFP – Meter Data Management System
24
references to fiscal quarters are not acceptable. It is expected that if the Offeror is invited to the
short list presentations, that they will be demoing the bid version of the solution.
Response:
13.2 Asset Management
Fort Collins Utilities uses Ventyx “Customer Suite” (formerly known as Banner) for the majority of meter
asset information and billing configuration. Fort Collins also has several Access databases for more
detailed electric and water meter asset management, such as historical device location and testing
results. Fort Collins has a long term vision of consolidating all meter asset management into a single
application and wants the MDMS to be that future asset repository.
For each of the following requirements, the Offeror shall indicate its solutions ability to meet the
requirement.
13.2.1 The MDMS shall maintain the current installed location and physical relationships between the
following:
13.2.1.1 Meters
Response:
13.2.1.2 Water Modules
Response:
13.2.1.2.1 The Offeror shall explain the data relationships its solution requires to associate
water modules with water meters.
Response:
13.2.1.3 Meter multiplier (Fort Collins uses a single billing multiplier for all billed meters.)
Response:
13.2.1.3.1 The Offeror shall explain how its solution applies meter multipliers to raw meter
data for storage and/or framing of billing determinants.
Response:
RFP – Meter Data Management System
25
13.2.1.3.2 Non-billing multipliers. (Fort Collins wants to store CT and PT values as
attributes of a service point. These values will not be used in any calculations
within the MDMS.)
Response:
13.2.1.3.3 The Offeror shall explain how its solution addresses compound water meters.
At Fort Collins, the compound water meter will have one meter number and
two, unique Register IDs, and each register will have its own multiplier.
Response:
13.2.1.3.4 The Offeror shall explain how its solution applies meter multipliers with a value
less than 1.0 (for example, 0.04).
Response:
13.2.1.4 Non-metering endpoint devices (i.e. direct load control devices, in-home displays)
Response:
13.2.1.5 Service Point Locations
Response:
13.2.1.6 Premise Location. Discuss how your system associates meters and Premise
Location/Service Point Locations when there are multiple meters at the same location (e.g.,
multiple electric meters and/or water meters). The Offeror shall explain what its solution
expects from CIS to associate multiple meters at the same location.
Response:
13.2.1.7 (Optional) GIS supplied information such as transformer, feeder, etc.
Response:
13.2.1.8 AMI fixed network collection device (if supplied by the AMI system)
Response:
RFP – Meter Data Management System
26
13.2.1.9 Hard Meter Configuration. Fort Collins to provide MDMS with hard meter configuration data
for meters or communication modules that have been installed in the field (for example, form,
phase, internal disconnect, etc).
Response:
13.2.1.10 Soft Meter Configuration. Fort Collins to provide MDMS with the initial programmed soft
meter configuration information (for example, firmware revisions, recorded interval length).
Response:
13.2.1.10.1 Soft Meter Configuration Update. The Offeror shall explain how its solution is
involved in updating soft meter configuration parameters to the AMI head-
end/meter.
Response:
13.2.1.11 (Optional) Meter test results
Response:
13.2.2 The MDMS shall have the ability to receive input from multiple metering systems including MV-
90, MV-RS and the fixed network AMI system and specify which system manages each
endpoint device.
Response:
13.3 AMI Installation Support
Fort Collins Utilities plans to use an Installation Services Vendor to perform the bulk of the electric
meter replacements. It is anticipated that the chosen meter installation vendor will possess its own
robust meter information management system that will interface with various Fort Collins Utilities
applications, such as CIS. However, it is expected the MDMS solution must provide a level of
installation capabilities in order to effectively support the field installation process. The Offeror shall
identify the capabilities of the proposed MDMS solution to provide AMI installation support in this
section.
13.3.1 The MDMS shall automatically facilitate the provisioning (ensuring successful communication)
of the installed meter or module with the AMI head end.
Response:
RFP – Meter Data Management System
27
13.3.2 The MDMS shall generate exceptions for meter or modules that failed to be provisioned with the
AMI head end.
Response:
13.3.3 The MDMS shall generate exceptions for meter or modules not delivering the correct meter data
based on the installed meter program.
Response:
13.3.4 The MDMS shall provide a reconciliation report that identifies the meters that have been
identified to the MDMS as having been deployed but have not been successfully provisioned for
a designated (configurable) number of days.
Response:
13.3.5 The MDMS shall generate reports on the number of meters installed in comparison to the
number of meters successfully provisioned.
Response:
13.4 Meter Data Collection
The MDMS solution must be able to process and manage the information that is collected from the
planned AMI System, MV-90, and MV-RS. This section provides a description of the core information
that is anticipated. Offeror shall identify the ability to meet these requirements and identify any areas
where the proposed system is unable to comply, along with proposed efforts to resolve the lack of
compliance.
13.4.1 Support Electric Metering
13.4.1.1 The MDMS shall support electric metering. Identify each AMI vendor that your system is
currently operationally deployed with. Identify the version of the AMI solution deployed.
Response:
13.4.1.2 The MDMS shall input, process, store, and analyze interval data, register reads, cycle
demand, daily demand, TOU bins, and net usage from a fixed network AMI system.
Response:
13.4.1.3 The MDMS shall support storage of all collected event and alarm data from meters, network
equipment, and the AMI Host System.
RFP – Meter Data Management System
28
Response:
13.4.1.4 The MDMS shall input, process, store, and analyze interval data, register reads, cycle
demand, and interval demand from MVRS and MV-90.
Response:
13.4.1.5 The MDMS shall support storage of all collected event and alarm data for meters provided by
MV-90.
Response:
13.4.1.6 The MDMS shall collect and report on the performance and availability of data being
delivered per AMI technology and trend performance over time. Report on meters not being
read.
Response:
13.4.1.7 Required electric metering data
13.4.1.7.1 The MDMS shall support net metering - provide the ability to manage positive,
negative, and net meter read values across multiple channels of the same
meter separately.
Response:
13.4.1.7.2 The MDMS shall have the ability to manage at a minimum 1, 5, 15, 30, and 60
minute interval data, and different interval lengths on different channels of the
same meter.
Response:
13.4.1.7.3 The MDMS shall input, process and store non-billing meter data, such as
voltage and power quality measures such as momentary interruptions and
harmonics, etc., as they are available from AMI for electric meters.
Response:
13.4.1.7.4 The MDMS shall process input from pulsed meters and transform into
appropriate metering units.
RFP – Meter Data Management System
29
Response:
13.4.2 Support Water Metering
13.4.2.1 The MDMS shall support water metering. Identify each AMI vendor that your system is
currently operationally deployed with. Identify the version of the AMI solution deployed.
Response:
13.4.2.2 The MDMS shall input, process, store, and analyze interval data and register reads from a
fixed network AMI system.
Response:
13.4.2.3 The MDMS shall input, process, store, and analyze interval data and register reads from
MVRS.
Response:
13.4.2.4 The MDMS shall collect and report on the performance and availability of data being
delivered per AMI technology and trend performance over time. Report on meters not being
read.
Response:
13.4.2.5 Required water metering data
13.4.2.5.1 The MDMS shall have the ability to manage at a minimum 15, 30, and 60
minute interval data.
Response:
13.4.2.5.2 The MDMS shall input, process and store non-billing meter data, such as
pressure, as they are available from AMI for water meters.
Response:
13.4.3 It is expected that the daily water reads will be collected on all meters, captured at midnight.
Response:
RFP – Meter Data Management System
30
13.4.4 (Optional) The Offeror shall explain its solutions ability to store data from non-traditional
metering sources, such as, water pressure sensors and rectifier reads from cathodic protection
test stations.
Response:
13.4.5 Time Management.
The MDMS shall accurately track and provide time stamps as appropriate to data and information
receipt, management and process activities.
13.4.5.1 The Offeror shall identify the start and end of day date/time stamps for its solution.
Response:
13.4.5.2 The Offeror shall indicate if its solution manages all time stamps in local time or other time
basis (i.e., UTC).
Response:
13.4.5.3 The Offeror shall indicate how its solution manages Daylight Saving Times.
Response:
13.4.5.4 The Offeror shall identify system functionality to normalize date/time stamps to a common
start/end of day if metering systems have different start/end of day time stamps.
Response:
13.4.6 Data Integrity
13.4.6.1 The Offeror shall explain how its solution performs programmatic data integrity checks
including, for example, checksum, time check, pulse, and overflow, on all metered data
received from data collection systems. Include a list of the validations performed on interval
and register data.
Response:
13.4.6.2 The Offeror shall explain how its solution identifies and flags any missing or corrupt data and
generate reports. Validation rules shall be configurable by data type, meter and AMI
technology, and customer class.
RFP – Meter Data Management System
31
Response:
13.5 Exception Management
An important aspect of any information system is how that system manages exceptions. This includes
how exceptions are categorized, identified, managed and reported. As the MDMS will provide a crucial
link in Fort Collins Utilities’ meter to bill process, as well as support other future advanced services, the
Offeror shall describe how the proposed MDMS performs exception management. For each of the
following requirements, the Offeror shall indicate its solutions ability to meet the requirement.
13.5.1 Exception Generation. The MDMS shall generate exceptions based on configurable business
rules. The exceptions may be in regards to:
13.5.1.1 Meter, register, communication module health
Response:
13.5.1.2 Suspected consumption on an inactive meter
Response:
13.5.1.3 Combined analysis based on the consumption of two commodities (electric and water) at the
same premise/account
Response:
13.5.2 Exception Generation Criteria.
Exceptions may be generated based on the combinations of the following configurable parameters.
13.5.2.1 Meter tamper alerts received from the meter via the AMI.
Response:
13.5.2.2 Meter, communication module health/diagnostic alerts received from the meter via the AMI.
Response:
13.5.2.3 Zero Consumption - Electric. Meters with no change in registration for a programmable
number of days.
Response:
RFP – Meter Data Management System
32
13.5.2.4 Zero Consumption - Water. Meters with no interval with zero consumption in a 24 hour
period.
Response:
13.5.2.5 Additionally, the system shall be capable of using other CIS supplied factors, such as a
seasonal use designation code, or an “out of service” code, in order to validate zero
consumption field activities.
Response:
13.5.2.6 Negative Consumption. Meters with negative change in registration for a programmable
number of days.
Response:
13.5.2.7 Daily Consumption Verification. Meter daily usage above or below a programmable threshold
for a configurable number of days. The threshold being a percent difference in usage for the
customer on that meter on similar days (weekday, weekend, holiday) or percent difference in
usage for the customer on that meter as compared to other ‘like’ customers (as identified by
a common demographic attributes).
Response:
13.5.2.8 Complex Daily and Billing Cycle Verification. The system shall perform the same daily and bill
cycle verifications for other billing quantities including demand and Time-of-Use.
Response:
13.5.2.9 Power outage indications received from the meter via the AMI.
Response:
13.5.2.10 Attributes of the meter or the account associated with meter, such as the account being in-
active, service being cut at the pole, or the meter being in the open, disconnected mode.
Response:
RFP – Meter Data Management System
33
13.6 Service Orders
Fort Collins Utilities utilizes CIS for generation, handling and reporting of service orders. CIS will
remain the primary System of Record for service order management. For each of the following
requirements, the Offeror shall indicate its solutions ability to meet the requirement.
13.6.1 The Offeror shall explain how its solution enables a utility user to identify a problem with, and
request an exchange of, an endpoint. The request will be communicated as a service order
request to the CIS system for execution.
Response:
13.6.2 The Offeror shall explain how its solution monitors and identifies specific meter diagnostic flags
provided by the AMI fixed network system, (such as stop-meters, reverse rotation, etc) and uses
configurable rules to automatically generate service order requests for CIS. The system shall
also identify combinations of flags over a specified period of time.
Response:
13.6.3 The Offeror shall explain how its solution receives and identifies trouble codes provided by the
MV-RS system and uses configurable rules to automatically generate service order requests for
CIS.
Response:
13.6.4 The Offeror shall explain how its solution supports configurable parameters for generating
service orders and may be defined separately for different groups of meters, based on common
attributes of the meter, premise, account or customer (such as for all customers on the same
rate).
Response:
13.7 Commissioning
Fort Collins expects the MDMS to assist in cutting over from manually read data to AMI collected data
for billing. The Offeror should provide detailed explanations of how the proposed product meets the
requirements below.
13.7.1 The Offeror shall explain how its solution compares AMI data to manual reads from MV-RS
and/or historical consumption to determine if the AMI data is accurate and can be used for
billing.
Response:
RFP – Meter Data Management System
34
13.7.2 The Offeror shall explain any exception processes if the AMI data is not accurate.
Response:
13.7.3 The Offeror shall explain how its solution notifies the CIS that a meter is ready for AMI billing.
Response:
13.7.4 The Offeror shall explain how its solution holds individual meters that are “ready for AMI billing”
and release them as a group to CIS. Identify the meter relationships that can be used to group
meters for this purpose.
Response:
13.7.5 The Offeror shall explain if its solution generates reports on the number of meters successfully
provisioned in comparison to the number of meters commissioned to AMI collected data for
billing
Response:
13.7.6 The Offeror shall explain if its solution generates reports on the number of meters successfully
commissioned in relationship to total meters within the route.
Response:
13.8 Billing
Fort Collins Utilities intends to use the MDMS as the central data management application for all Fort
Collins Utilities metering information. The information collected from the AMI system(s) will be funneled
through the proposed MDMS into the CIS system as billing determinants. Future business releases will
also add MV-90 and MV-RS data to the MDMS. As these systems are added, the MDMS will be
responsible for all VEE of the existing monthly and C&I interval data as well as AMI data.
The requirements in this section are key items for Fort Collins Utilities and the Offeror should provide
detailed explanations of how the proposed product meets the requirements.
13.8.1 Data Validation, Estimation, and Editing (VEE).
13.8.1.1 The Offeror shall provide a list of estimation methods provided for interval data.
Response:
13.8.1.2 The Offeror shall provide a list of estimation methods provided for register data.
RFP – Meter Data Management System
35
Response:
13.8.1.3 The MDMS shall maintain both the original received raw data in a non-manipulated state, in
addition to VEE’d data.
Response:
13.8.1.4 The Offeror shall explain how its solution applies estimation to intervals flagged with an
outage quality code. Identify any other quality codes associated with AMI intervals that
receive special estimation handling.
Response:
13.8.1.5 The Offeror shall explain how its solution provides a GUI for configuring estimation
parameters and support configuring estimation for specific meters/accounts or groups of
meters/accounts. Additionally the system shall support the ability to establish specific
thresholds or boundaries for estimation on specific accounts by meter/customer, group, or
tariff/rate. Exceeding such a threshold would flag the need to manually edit the data.
Response:
13.8.1.6 The MDMS shall allow some meters to be identified as meters that cannot be estimated.
Response:
13.8.1.7 The MDMS shall flag all estimated or manually edited data, identify data gaps (where
automatic estimation cannot be accurately performed), and generate alerts/notifications for
manual data editing.
Response:
13.8.1.8 The MDMS must clearly distinguish visually within the GUI between metered, estimated, and
manually edited data.
Response:
13.8.1.9 The MDMS shall have a manual interface for VEE, and retain appropriate user controls and
audit to investigate actual raw data collected and the manual edited data.
Response:
RFP – Meter Data Management System
36
13.8.1.10 The MDMS shall allow for a configurable number of missing intervals to make a
determination if a billing determinant is flagged as an estimate (i.e. How many intervals in a
bill cycle are estimated for the billing determinant to be an estimate).
Response:
13.8.1.11 Notwithstanding the latency of data collection via the AMI system, once the MDMS receives
meter read data, the VEE process occurs in real-time and the post-VEE data is then
immediately available to user or external systems.
Response:
13.8.1.12 External Data Import
13.8.1.12.1 The MDMS shall be able to import standard load profiles per customer or
account type for use in the VEE processes.
Response:
13.8.1.12.2 The MDMS shall be able to import weather data or similar information to
provide for normalization to be used in the VEE processes.
Response:
13.8.2 Billing Determinants Calculations
13.8.2.1 The Offeror shall confirm the ability to deliver electric billing determinants, to include: register
reads and consumption interval data (kWh), demand (kW), kVA , Power Factor, and net
usage.
Response:
13.8.2.2 The Offeror shall confirm the ability to deliver water billing determinants, to include: gallons
and thousands of gallons (TGAL).
Response:
13.8.2.3 The Offeror shall detail the MDMS’s capability to support Time-of-Use (TOU) rate structures.
Response:
RFP – Meter Data Management System
37
13.8.2.4 The Offeror shall explain how its solution allows Fort Collins Utilities to configure multiple
TOU options (e.g. the number and duration of TOU rate periods) by customer type, tariffs,
day type (weekend, weekdays, and holidays) and by season.
Response:
13.8.2.5 The Offeror shall explain how its solution supports Critical Peak Pricing (CPP) rates. Also
discuss how the solution records the initiation of a critical peak event by Fort Collins Utilities
personnel so as to track customer consumption during critical peak periods.
Response:
13.8.2.5.1 The Offeror shall explain how its solution applies estimation during a CPP
event.
Response:
13.8.2.6 (Optional) The Offeror shall explain how its solution supports Peak Time Rebate (PTR) rates.
Provide the algorithm used to create the comparison baseline. Discuss how the solution
stores, versions, and enables editing of this baseline.
Response:
13.8.2.7 (Optional) The Offeror shall explain how its solution supports On Bill Financing. Discuss
how the solution stores, versions, and enables editing of the consumption baseline and
reports “savings” over time.
Response:
13.8.2.8 The Offeror shall explain how its solution supports rates using coincident peak demand.
Response:
13.8.2.9 The Offeror shall explain how its solution supports totalized billing where usage interval data
is totalized across multiple sub-meters into one master meter prior to aggregating the
consumption and demand. The system shall be able to identify meters that are part of a
totalized relationship.
Response:
RFP – Meter Data Management System
38
13.8.2.9.1 The Offeror shall explain the information required from the CIS to create
totalization relationships. This explanation must include an explanation of how
the solution responds to totalized meters with different interval length and one
meter in the relationship having estimated data.
Response:
13.8.2.10 The Offeror shall explain how its solution has the ability to convert finer resolution interval
data into required rate class billing determinants. For example, converting 15 minute
intervals into an hourly rate or 15 minute intervals into a 30 minute block demand.
Response:
13.8.2.11 The Offeror shall explain when its solution calculates billing determinants For example,
billing determinants are calculated each day so that cumulative billing determinants to date
are available. Or, billing determinants are calculated at the time billing determinants are
requested.
Response:
13.8.2.12 Fort Collins does not bill a customer for the peak demand if the peak occurs within 2 hours
of the completion of an outage at that account. Fort Collins will use the next highest demand
for the bill. The Offeror shall explain how its system can be configured to support this billing
process.
Response:
13.8.3 Delivering Billing Information
The billing determinants the MDMS creates must be provided to Fort Collins Utilities’ CIS system in an
organized, timely manner to support the effective creation of customer bills. The maintenance of the
integrity of the billing process is of paramount concern to Fort Collins Utilities. The Offeror shall
describe how the proposed MDMS solution meets the requirements below.
13.8.3.1 The Offeror shall provide a comprehensive list of the data validations that the system
provides at the time data is framed for billing.
Response:
13.8.3.1.1 These validations shall use the individual customer’s historic usage patterns.
Response:
RFP – Meter Data Management System
39
13.8.3.1.2 These validation rules shall be configurable by customer class and tariff/rate.
Response:
13.8.3.2 The MDMS shall receive a billing request from CIS and respond with the configured billing
determinants.
Response:
13.8.3.3 The MDMS shall provide the capability to receive and respond to ad-hoc requests for off-
cycle billing determinants via both the user interface and an API, for events such as a
customer move-in and out or a cancel and re-bill.
Response:
13.8.3.4 The Offeror shall explain how the delivery of billing determinants to CIS will be impacted by
events that occurred during the billing period, such as, meter exchanges, season changes,
price adjustment events, etc.
Response:
13.8.3.5 The MDMS shall provide configurable business rules around the billing window regarding
VEE behavior when billing determinants are missing (i.e. estimate and deliver to billing,
schedule an on-demand read as necessary, create a service order to collect read data).
Response:
13.8.3.6 The MDMS shall provide the ability to pass to the CIS a flag identifying an estimated value,
along with the reason for the estimate.
Response:
13.8.3.7 The MDMS should issue notifications when it receives actual reads from the AMI that were
previously estimated in calculating the billing determinants sent to CIS.
Response:
RFP – Meter Data Management System
40
13.8.3.8 The Offeror shall explain how its solution supports the cancel/rebill process. The Offeror
shall explain the suggested process and interaction with CIS to complete this bill correction
process.
Response:
13.8.3.9 The Offeror shall explain how its solution supports a switched meter process. The Offeror
shall explain the suggested process and interaction with CIS to complete the process of
moving the correct meter and associated meter data to the correct premise.
Response:
13.8.3.10 The MDMS shall receive, store and pass the MV-RS trouble and skip codes to CIS in the
billing delivery for manually read meters. This also includes a skip code value of 99 which is
coded as “other” and has associated text (known as a trouble message).
Response:
13.8.4 Usage Analysis
Fort Collins Utilities intends to use the MDMS to analyze the data provided by the AMI system to
perform various billing data tests, to flag conditions to Fort Collins Utilities which require additional
investigation, or highlight a potential problem. For each of the following requirements, the Offeror shall
indicate its solutions ability to meet the requirement.
13.8.4.1 The MDMS shall identify any meter daily usage above or below a programmable threshold
and generate reports and flags accordingly. The programmable threshold shall be
configurable by customer attributes and meter characteristics.
Response:
13.8.4.2 The MDMS shall identify any meter with cumulative usage since the last bill greater than a
programmable threshold as derived from the individual customer’s historical standard
deviation and generate reports and flags accordingly.
Response:
13.8.4.3 The MDMS shall perform the same checks for all daily and billing quantities including net,
demand quantities, Time-of-Use, and interval data.
Response:
RFP – Meter Data Management System
41
13.8.4.4 Fort Collins uses tiered rates for and water. The Offeror shall explain how its solution can be
configured to notify customers prior to hitting the next tier in the rate and when they enter the
next tier.
Response:
13.8.4.5 Fort Collins uses water rates with allotments – a customer has an allotment of water to use
each month and a surcharge is added if the allotment is exceeded. The Offeror shall explain
how its solution can be configured to notify customers prior to reaching the allotment and
when the allotment is exceeded.
Response:
13.8.4.6 The MDMS shall be able to track cogeneration or self-generation customers to provide a flag
to be used in data analysis activity.
Response:
13.8.5 Pre-Pay (Optional)
13.8.5.1 The Offeror shall explain how its solution support pre-pay business processes. Please
provide examples of where the Offeror’s solution has supported utility pre-pay programs, with
either the utility’s legacy systems or a third-party provider.
Response:
13.9 Customer Service Support
Fort Collins Utilities must have access to the essential information and capabilities that are contained in
the MDMS in order to make effective use of the valuable information in transforming the customer
support process. The requirements below must be supported between the MDMS and the CIS system
to enable the users to perform their activities.
13.9.1 The Offeror shall explain how its solution provides users with access to current and historical
consumption and interval data, outage flags, voltage and power quality indications. The data
shall be displayed in graphical and tabular form depending on user choice. Provide samples of
the user interface.
Response:
13.9.2 The Offeror shall explain the recommended approach for integrating your GUI into the CIS user
experience.
Response:
RFP – Meter Data Management System
42
13.10 Real-Time Applications Support
The MDMS shall support real-time support for other applications in their use of MDMS information or
MDMS managed AMI services. For each of the following requirements, the Offeror shall indicate its
solutions ability to meet the requirement.
13.10.1 The MDMS shall supports requests for an on-demand read from external applications, such
as CIS.
Response:
13.10.2 The MDMS shall provide a means for users to request an on-demand read and view results
via a GUI. Any information that is available through the AMI system should be available via this
capability.
Response:
13.10.3 If the AMI system supports the capability, the MDMS shall be able to request and receive
on-demand power quality information.
Response:
13.10.4 The MDMS must determine if an on-demand read is possible and inform the user if the
device does not support the request.
Response:
13.10.5 The MDMS shall provide, on request, any available meter registers (consumption, demand,
specific day interval data, meter/system status, voltage, etc.) of an individual meter, or batch of
meters. The MDMS shall timestamp requests and responses.
Response:
13.10.6 The MDMS shall provide, on request, the ability for a disconnect/re-connect request to be
executed by the AMI system on a specific meter or batch of meters identified by individual
service points.
Response:
RFP – Meter Data Management System
43
13.10.7 The Offeror shall explain how its solution schedules and/or throttles disconnect requests to
manage Call Center call volume following the disconnect.
Response:
13.10.8 The MDMS shall track all current disconnect switch positions (open or closed) and provide
exception where the same switch position is requested.
Response:
13.10.9 The Offeror shall explain how its solution supports soft closes or virtual disconnects. Identify
the explicit steps Fort Collins must execute to soft close an account. This could result from Fort
Collins doing soft closes on AMI meters without remote disconnect capability or automatically
following a failed remote disconnect command.
Response:
13.11 External Support and Analysis
The MDMS shall support other external systems at Fort Collins Utilities in the future. The Offeror will
identify how the proposed MDMS supports these applications.
13.11.1 Virtual Metering
13.11.1.1 The MDMS shall enable the creation and maintenance of virtual meters. Virtual meters
aggregate metering data from a specified set of physical meters. Virtual meters shall support
all metering functionality allowed by the lowest common device capability.
Response:
13.11.1.2 The MDMS shall allow the user to add or remove one or more physical meters from a virtual
meter.
Response:
13.11.1.3 The MDMS shall allow assigning one physical meter to more than one virtual meter.
Response:
13.11.1.4 The MDMS shall be capable of receiving virtual meter relationships from an external system
such as CIS, GIS, or a distribution analysis system.
Response:
RFP – Meter Data Management System
44
13.11.1.5 The Offeror shall describe the information needed from an external system to assign
physical meters to a virtual meter.
Response:
13.11.1.6 The Offeror shall describe how your system combines physical meters with different interval
length, channel configurations, etc. into a virtual meter.
Response:
13.11.1.7 The MDMS shall support display and export of load profile data for a specified virtual meter
or set of virtual meters.
Response:
13.11.2 The MDMS shall be capable of calculating when the system wide peak occurred based on
the supplied meter read data and export the load profile with identified date and time.
Response:
13.11.3 The MDMS shall enable export of voltage and current data obtained from AMI electric
meters.
Response:
13.11.4 The Offeror shall identify the methods for exporting data for a specific meter or group of
meters to MV-90 for analysis.
Response:
13.11.5 The Offeror shall identify the methods for exporting data for a specific meter to an external
system, including specific data export formats supported. These external systems could
include: Access, SAS, Excel, etc.
Response:
RFP – Meter Data Management System
45
13.11.6 The Offeror shall identify the methods for exporting load data for all the meters on a feeder
to an external system such as Milsoft WindMil (load flow analysis) and Milsoft LightTable (fuse
coordination).
Response:
13.11.7 The MDMS shall display load profiles by season and day type (weekday, weekend, holiday,
etc.) and by rate class, customer type, or any user specified collection of meters.
Response:
13.12 Reporting
In order for Fort Collins to be able to effectively use the MDMS to its fullest extent, it is imperative that
the proposed MDMS have sufficient reporting capability. The Offeror shall fully explain the solution’s
capabilities, placing special attention on what is included in the MDMS out-of-the-box, user-
configurable, requires additional reporting packages, etc. Fort Collins has adopted Crystal reports as a
primary user ad-hoc reporting tool.
13.12.1 The Offeror shall provide a list of the standard reports that are provided with the MDMS
solution out-of-the-box, with a brief description of each.
Response:
13.12.2 The Offeror shall explain how its solution support users modifying standard reports to better
meet specific reporting requirements
Response:
13.12.3 The MDMS shall enable Fort Collins to deliver out-of-the-box reports in digital format such
as PDF, Excel, etc.
Response:
13.12.4 The MDMS shall enable Fort Collins to configure the grouping, filtering, and delivery of the
system generated reports to predetermined email addresses, network file directory, ftp sites,
and/or printers.
Response:
RFP – Meter Data Management System
46
13.12.5 The Offeror shall provide a description of the MDMS’ Dashboard reporting tool including the
primary information contained in the dashboard. Offeror should include a sample of the
dashboard.
Response:
13.12.6 The MDMS shall enable authorized users to generate ad-hoc reports utilizing Crystal
reporting. Offeror shall identify which versions of Crystal reports are supported.
Response:
13.12.7 The Offeror shall explain how its solution supports users accessing a data dictionary of
tables, fields, relationships, and indexes to support ad-hoc report generation.
Response:
13.12.8 (Optional) The Offeror shall explain how its solution supports ETL for loading a data
warehouse on a daily basis.
Response:
13.12.9 During the implementation, the Offeror will provide a data model of the system, in an agreed
upon format, to support internal report generation needs.
Response:
13.12.10 During the implementation, the Offeror will provide example queries to support internal
report generation needs.
Response:
13.13 Outage Management (Optional)
The Offeror shall identify the value-added functionality the MDMS provides in analyzing or routing real-
time outage events to/from AMI meters.
13.13.1 Offeror shall describe its solution’s functionality in processing power outage events from AMI
meters. Please describe the best practice approach based on your experience.
Response:
RFP – Meter Data Management System
47
13.13.2 Offeror shall describe its solution’s functionality in processing power restoration events from
AMI meters. Please describe the best practice approach based on your experience.
Response:
13.13.3 Offeror shall describe its solution’s functionality in processing power status verification
requests from outage management or CIS to AMI meters. Please describe the best practice
approach based on your experience.
Response:
13.13.4 Offeror shall describe how, if at all, outage and power restoration events are used beyond
outage management in your system.
Response:
13.14 Revenue Protection Support (Optional)
Fort Collins Utilities intends to utilize the additional information available from AMI systems to pursue
potential revenue protection issues. For each of the following requirements, the Offeror shall indicate its
solutions ability to meet the requirement.
13.14.1 The MDMS shall have the ability to analyze meter tampering flags, power outages, power
quality and usage trends to find potential revenue protection situations, including unauthorized
usage, and process this data into meaningful revenue protection support.
Response:
13.14.2 The business rules for revenue protection alerts shall be configurable via a user-friendly
interface.
Response:
13.14.3 The MDMS shall filter out revenue protection alerts that may be caused by field activities if
the field activity information is provided to the MDMS.
Response:
13.14.4 The MDMS shall provide a user interface to support the analytics/investigation (i.e. view
current and historical usage patterns) to valid suspected revenue protection issues.
Response:
RFP – Meter Data Management System
48
13.15 Demand Control/Demand Response Support (Optional)
Fort Collins Utilities intends to support the adoption of Home Area Networks (HAN) and Demand
Response (DR) programs. This section indicates the desired functionality in support of DR programs.
13.15.1 The Offeror shall describe how the solution supports the following analysis:
13.15.1.1 Totaling the actual consumption during the DR event.
Response:
13.15.1.2 Totaling the actual consumption of accounts that participated in the DR event.
Response:
13.15.1.3 Comparing the actual to a baseline consumption for the groups in 14.1.1 and 14.1.2 above.
Response:
13.15.2 Offeror shall describe how its MDMS supports common market SmartGrid Demand
Response programs involving HAN and DR systems. Please provide your future roadmap in
support of Demand Response programs.
Response:
13.15.3 Offeror shall indicate if proposed functionality is an integrated module, an add-on module or
a separate application that interfaces with the MDMS application. Offeror shall also indicate if
this product is a third-party application.
Response:
13.15.4 Offeror shall describe how the MDMS supports the tracking, monitoring and managing of DR
assets and events, and monitors customer response to facilitate payment of customer
incentives.
Response:
RFP – Meter Data Management System
49
13.15.4.1 In the event that the MDMS and AMI are used to facilitate the communication with the DR
devices in the field, describe how the MDMS brokers requests from an external system in
regards to a customer programming their thermostat profiles (change setting, or raise/ lower
temperature setting by X degrees, respond to the different pricing levels in addition to normal
weekday, weekend, and time of day settings) or the time windows for which a Plug-in Vehicle
should charge.
Response:
13.15.4.2 The Offeror shall describe how the MDMS is able to track the communication connectivity
relationship between the HAN DR devices, In-Home Displays, Programmable thermostats,
Load Control Devices, Plug-in Vehicles and meters.
Response:
13.15.4.3 The Offeror shall indicate how the proposed solution facilitates tracking the physical
relationship between the DR assets and customer premises, and the relationship between
DR assets and communication assets.
Response:
13.15.4.4 The Offeror shall describe how the solution facilitates the device pairing process associated
with the ZigBee SEP profile and confirmation of device pairing success.
Response:
13.15.4.5 The Offeror shall describe how the solution facilitates the tracking of DR assets within the
electrical distribution system.
Response:
13.15.4.6 The Offeror shall describe how the MDMS facilitates the tracking of customer overrides of
curtailment events as provided back by the AMI system and other DR systems.
Response:
13.15.5 The MDMS shall support the following data flows between itself and the AMI system(s) in
support of Demand Response devices.
RFP – Meter Data Management System
50
13.15.5.1 Device Control (i.e.: Display Price Event and PHEV control). In the event that the AMI Head
End is used as a gateway to communicate with HAN devices, the MDMS will broker this
communication to control these devices via the AMI Head End. Describe the MDMS support
of this data flow.
Response:
13.15.5.2 Request and Response Remote Programming (Thermostat Settings). In the event that the
AMI Head End is used as a gateway to communicate with HAN devices, the MDMS will
broker this communication to remotely program these devices via the AMI Head End.
Describe the MDMS support of this data flow.
Response:
13.15.5.3 The Offeror shall describe how the solution facilitates and manages the meter to HAN
device pairing process regardless of HAN technology, ZigBee or other.
Response:
14 MDMS Integration Requirements
The following integration points may be needed to support system integration with other information
systems as defined in the above requirements sections. For each of the interface requirements, where
responses are requested, please indicate and discuss your capabilities. If the Offeror’s solution
integration points do not exactly match the interfaces defined here, clarify how the implied functionality
is met by the Offeror’s solution.
For each interface, Fort Collin’s objective is to understand the following:
• The integration method(s) available to fulfill the functional requirements. For example, if Fort
Collin’s has the choice of meeting the functional requirements via a file-based, message-based,
or web service integration, please state these options.
• The periodicity of the integration options. Is it a daily batch integration or an event based
integration?
14.1 How has the Offeror’s solution been SOA enabled?
Response:
RFP – Meter Data Management System
51
14.2 Please give a detailed explanation of Offeror’s CIM compatibility. Has Offeror adapted its
product’s adapters to the CIM model? If so, explain how adapters have been implemented on the
CIM platform? What level of commitment is provided to the CIM effort and its related
organizations?
Response:
14.3 Offeror shall indicate the actual experience in implementing its solution at a utility in an SOA
environment, including the types of services that have been implemented.
Response:
14.4 Customer Information System (CIS) and MDMS
The MDMS shall support interface characteristics with the CIS system as defined below.
14.4.1 Data Synchronization – Initial Load. The Offeror shall explain how the solution is synchronized
with the CIS regarding: Customer, Account, Premise, Service Point, Meter, Route, Bill Cycle,
Hard Meter Configuration, Soft Meter Configuration, etc. for the initial load of meters.
Response:
14.4.2 Data Synchronization – Updates. The Offeror shall explain how the solution is synchronized
with the CIS regarding: Customer, Account, Premise, Service Point, Meter, Route, Bill Cycle,
Hard Meter Configuration, Soft Meter Configuration, etc. as individual data elements are
updated.
Response:
14.4.3 Data Synchronization – Maintenance. The Offeror shall explain how the solution is
synchronized with the CIS regarding: Customer, Account, Premise, Service Point, Meter,
Route, Bill Cycle, Hard Meter Configuration, Soft Meter Configuration, etc. to confirm all data
updates have been received correctly. Identify functionality to “audit” the synchronization
process.
Response:
14.4.4 The Offeror shall explain how the synchronization process will change from the initial project
phases when only AMI meters will be billed via the MDMS and later phases when MV-90 and
MV-RS reads will be added to billing.
Response:
RFP – Meter Data Management System
52
14.4.5 Commissioning Notification. The Offeror shall explain how the solution will notify CIS when AMI
meters are ready to be cutover from billing via manual reads to billing via AMI reads. (See
Section 6 for related functionality.)
Response:
14.4.6 Billing Cycle Consumption/Read Request. CIS will send to MDMS daily scheduled requests for
billing determinants for on-cycle meters. These requests will be for meters for which the MDMS
has collected data from one of the meter reading systems.
Response:
14.4.7 Billing Cycle Consumption/Read Response. MDMS shall respond to the above request by
sending to CIS billing determinants as defined by the rate.
Response:
14.4.8 Off-Cycle Consumption/Read Request. CIS shall send to MDMS a request for off-cycle billing
determinants for turn-on/turn-off and cancel/re-bill scenarios. These requests will be for meters
for which the MDMS has collected data from one of the meter reading systems.
Response:
14.4.9 Off-Cycle Consumption/Read Response. MDMS shall respond to the above request by sending
CIS billing determinants for the off-cycle request.
Response:
14.4.10 Turn On/Off Request. CIS will send customer turn-on and turn-off to MDMS to act upon via
virtual connect/disconnect or remote physical connect/disconnect, where equipped.
Response:
14.4.11 Turn On/Off Response. MDMS will send completion information of turn-on/turn-off service
orders to CIS.
Response:
RFP – Meter Data Management System
53
14.4.12 On-Demand Read Request. CIS will send the request for an on-demand read for a specific
meter to MDMS.
Response:
14.4.13 On-Demand Read Response. MDMS will send the results of the request to CIS, including
failures.
Response:
14.4.14 Service Orders. MDMS will send field activity requests to the CIS of a variety of order types.
Offeror shall identify the types of service orders the MDMS can create and send to CIS.
Response:
14.4.15 (Optional) Price Adjustment Event Dates. In the future, CIS will send MDMS notification of
Price Adjustment Events that may occur during the year. The Offeror shall explain how its
solution will use this information in the process of delivering billing determinants.
Response:
14.4.16 Meter Field Activity Dispatch Status. MDMS will receive the status and completion
information of field activities from the CIS that are related to activities that touch meters in the
field. Also, the MDMS will receive status information about Service Orders that the MDMS had
previously sent to the CIS.
Response:
14.4.17 The Offeror will identify any additional integration required between CIS and MDMS to
enable the functionality identified in this document.
Response:
14.5 MDMS and AMI Data Collection System
The MDMS shall support the following data flows between itself and the AMI system(s).
14.5.1 Account, Service Point, Hard Meter Configuration. MDMS to provide AMI Data Collection Head
End with account, service point and hard meter configuration data for meters or communication
modules that have been installed in the field. This is to indicate to the AMI Data Collection
system which meters or communication modules should be heard from.
RFP – Meter Data Management System
54
Response:
14.5.2 Soft Meter Configuration. AMI Data Collection Head End to provide MDMS with the current soft
meter configuration information and the MDMS shall store this information and make available
for export (for example, recorded interval length, firmware version, etc).
Response:
14.5.3 Soft Meter Configuration Command. MDMS to send AMI Data Collection Head End commands
to change soft meter configuration parameters.
Response:
14.5.4 Read Data, Alarms/Flags and Meter Diagnostics. AMI Data Collection Head End to provide
MDMS with read data, flags and meter diagnostics.
Response:
14.5.5 Real-time Read/Status Request. MDMS to request meter read/status information from the AMI
Head End.
Response:
14.5.6 Real-time Read/Status Response. The AMI Head End to supply responses to the requested
read/status information in real-time.
Response:
14.5.7 Real-time Remote Connect/Disconnect Request. MDMS to request the AMI Head End to
perform a real-time remote connect/disconnect.
Response:
14.5.8 Real-time Remote Connect/Disconnect Response. AMI Head End to supply MDMS with
responses to the requested real-time remote connect/disconnect
Response:
RFP – Meter Data Management System
55
14.5.9 Outage/Restoration Notifications. AMI Head End to supply MDMS with outage/restoration
notifications.
Response:
14.5.10 (Optional) Device Control (Display Price Event, and PHEV control). In the event that the
AMI Head End is used as a gateway to communicate with HAN devices, the MDMS will broker
this communication to control these devices via the AMI Head End.
Response:
14.5.11 The Offeror will identify any additional integration required between MDMS and AMI to
enable the functionality identified in this document.
Response:
14.6 MDMS and OMS (Optional)
The MDMS solution shall integrate with Fort Collins Utilities’ distribution/outage management system
and support the following data flows.
14.6.1 Outage Notifications. MDMS shall initiate outage calls to OMS upon receiving meter outage
event notifications from AMI system.
Response:
14.6.2 Restoration Notifications. MDMS will send outage restoration events, upon receiving the events
from AMI, to OMS, which will update the outage restoration time with the AMI outage restoration
timestamp as supplied by MDMS.
Response:
14.6.3 Meter Power Status Y/N Request. OMS will query MDMS to verify a service outage on a meter
or group of meters to verify service restorations.
Response:
14.6.4 Meter Power Status Y/N Response. MDMS will provide the power status of a meter or group of
meters in response to the OMS initiated query to the MDMS. OMS query may be initiated by
OMS internal processes or via the connected IVR.
Response:
RFP – Meter Data Management System
56
14.7 MDMS and Existing Data Collection Systems
The MDMS will support the existing Fort Collins Utilities meter collection systems
14.7.1 Bill Cycle Read Response (MVRS). MVRS will send to MDMS the manually collected daily
meter reads.
Response:
14.7.2 MV-90 Collected Consumption and Interval Data. MDMS to receive meter read data collected
via MV-90. Does the Offeror’s solution support HHF as a standard interface?
Response:
14.8 MDMS and GIS
14.8.1 Virtual Meter Definitions. GIS will send virtual meter point definitions to MDMS that correspond
to pre-determined points in the circuit’s connectivity hierarchy.
Response:
14.8.2 GIS Capabilities. Offeror shall describe any requirements necessary to interface a GIS system
with your system.
Response:
14.9 Presentment
14.9.1 The Offeror shall detail integrations its solution provides to access customer historical usage
information for presentment via an external web presentment application. Identify security
protocols supported by the integration to limit access.
Response:
14.9.2 The Offeror shall detail integrations its solution provides to notify external customers of events
occurring within the MDMS via email, text, etc. For example, notifying a customer when they
have reached the next tier in a tiered rate structure, consumption above historical patterns, etc.
Response:
RFP – Meter Data Management System
57
15 MDMS Information Technology & Security Requirements
15.1 Overall Architecture
15.1.1 Architecture. Offeror shall provide a system architecture diagram showing all of the modules
that support the mandatory and optional requirements. Offeror shall clearly annotate the
diagram to indicate which modules support the mandatory requirements and which support the
optional requirements.
Response:
15.1.1.1 Offeror shall provide a table that, for each vendor module/component/product, lists: a)
Product Name, b) Current Version, c) Product Functionality d) Required O/S and where it
resides; desktop or server, and whether the client application (where applicable) is thick-client
or thin-client
Response:
15.1.1.2 Offeror shall include in its table the typical server and workstation configurations used to
support an operating center with a highly available server configuration, and a business
continuity configuration that includes both a remote data center and a remote operating
center.
Response:
15.1.1.3 Offeror shall identify all software that exists in the solution’s “runtime” environment, including
all external dependencies. The Offeror shall specify any 3rd party software Fort Collins
Utilities must acquire to operate the MDMS solution (i.e.: 3rd party software NOT provided by
Offeror as part of the bundled MDMS solution).
Response:
15.1.1.4 Offeror shall adhere to all of Fort Collins Utilities’ IT standards, policies and procedures in the
delivery, configuration and maintenance of the proposed MDMS solution. Offeror shall review
and confirm acceptance of the specific Fort Collins Utilities’ IT standards document included
as an Appendix attached to this RFP. Offeror shall explicitly note any and all exception that it
takes with the documents or any components with which it cannot comply.
Response:
15.1.2 Offeror shall describe what software platform is used in the development of its MDMS solution,
(i.e. .net, Java, etc.).
RFP – Meter Data Management System
58
Response:
15.1.3 Offeror shall identify its recommended MDMS hardware and operating system platforms and
solutions on which the Offeror’s solution has been deployed.
Response:
15.1.4 Offeror shall identify the MDMS preferred database platform, including all versions currently
supported, period of time that the current version will be supported and the planned version
migration strategy. If more than one database platform is supported, Vendor shall provide
examples where each platform has been deployed to Production
Response:
15.1.4.1 Offeror shall highlight how its architecture can make use of its database as both the RDBMS
for the operational system and as a future data feed for Fort Collins’ data mart and reporting
module(s).
Response:
15.1.5 Does the Offeror's product support VM for application servers? Does the Offeror warrant VM?
Please include a client reference that is using VM in production if possible.
Response:
15.1.6 Offeror shall describe the product's mechanism for process scheduling.
Response:
15.1.7 Offeror shall describe product’s GUI support for Administration and monitoring capability built
into the MDMS solution. Please provide screen shots of the GUI related to this requirement.
Response:
15.1.8 Offeror shall describe what network protocols they support (If not IPV6 - please provide a
description of where this fits in the product roadmap)
Response:
RFP – Meter Data Management System
59
15.1.9 Offeror shall indicate how the system shall expose status of internal processes to external
monitoring systems.
Response:
15.1.10 Offeror shall indicate if any aspect of its solution to the requirements contained herein is a
hosted solution. If it is hosted, explain in detail the connectivity with the core head-end and how
data transfer is securely managed.
Response:
15.2 High Availability, Disaster Recovery and Fault Tolerance
15.2.1 The MDMS system architecture shall support full high-availability configuration with automatic
failover, and automated backup/recovery. The MDMS shall operate 24 hours a day, 7 days a
week, 365 days a year, and demonstrate annual availability of at least 99.99%. It shall have the
ability to re-run/restart/recover without loss of data (e.g., checkpoint/restart capability).
Response:
15.2.2 The MDMS system shall utilize two data centers, a production location and a backup location.
The backup location shall be capable of operation in the production environment within 24
hours.
Response:
15.2.3 Describe your product’s architecture ability to make use of high availability mechanisms to
support high availability configurations that deal with a hardware server failure and allow the
operations center to continue to receive outages within 5 minutes of a hardware server failure.
Response:
15.2.4 Describe your product’s architecture use of SAN backup and recovery mechanisms to support a
redundant data center for business continuity that would support a backup data center to be up
and working within 24 hours after the primary data center was declared unfit for operations.
Response:
RFP – Meter Data Management System
60
15.2.5 Offeror shall describe what required routine maintenance of the MDMS is expected and whether
this maintenance shall require the application to be off-line and for what period.
Response:
15.2.6 Offeror shall describe the process and documentation (including API changes) for implementing
major and minor head-end software upgrades or patches in the production system, specifically
indicating if the tasks shall require the application to be off-line and for what period. Offeror shall
clarify how the upgrade would be backed out either during or after the upgrade process is
completed.
Response:
15.3 Product Roadmap, Lifecycles and Enhancements
15.3.1 Offeror shall describe their Software Development Lifecycle, including but not limited to their
unique methodology, tools, best practices, quality gates and example artifacts.
Response:
15.3.2 For the Offeror's proposed MDMS: a) define the planned major releases of the MDMS over the
next 2 years; and b) provide a history of major releases and patches over the past 24 months.
For the preceding, provide an overview of the significant features and capabilities planned or
provided.
Response:
15.3.3 Offeror shall describe its process to solicit and incorporate Utility customer feedback on
features, functions, enhancements, etc. that Utility would like to see Offeror incorporate into
future releases.
Response:
15.3.4 Describe Offeror's support of its system upgrades and service patch releases. Specifically
address the process and timeframe to regression test Offeror's system with each service patch
release and major operating system revision release. Describe Offeror's schedule for major
releases and patches.
Response:
RFP – Meter Data Management System
61
15.3.5 Offeror shall indicate compliance and/or further clarify the definition of on-going software
updates and upgrades in relationship to base License and annual Maintenance Fees or any
additional required cost anticipated.
15.3.5.1 “Updates” and "Upgrades" mean patches or other maintenance releases of the Software that
correct processing errors and other faults and defects found in the previous minor or major
releases of the Software. This includes all modifications, revisions, additions, alterations,
error corrections of the Software that represent minor or major releases of new versions of
the Software. All updates would be provided under the maintenance and service agreement
at no additional cost.
Response:
15.3.5.2 New Software modules which create new functionality and would not be enhancements.
Enhancements to existing functionality would be considered Updates. These would be
considered amendments to the base license and amended to the master license agreement.
Response:
15.3.5.3 Offeror shall describe the communications, license term, support services and process that
would be offered to support a future core product change that would effectively render the
currently licensed version into a future state of "un-supported" or retired version.
Response:
15.3.6 Offeror shall provide or describe the Change Management Plan in support of software Updates.
This plan should address a minimum of basic elements including: Communications; Change
Risk; Priority; Customer Impact; Description of Change; Systems Effected; Programs Impacted;
Implementation Procedure; Back-out Procedure; Testing Procedure; Post Change Success
Criteria; Post Change Review Notes. Offeror may alternatively include a sample Release Notes
document.
Response:
15.4 Sizing, Data Storage and Data Architecture
The vendor shall specify and deliver an initial system that supports the collection and storage of 15
minute interval data for 85,000 electric meters, and 1 hour interval data for 44,000 water meters. The
system shall be readily scalable to accommodate 3% annual growth thereafter over the life of the
contract
15.4.1 Offeror shall identify the specific hardware requirements (memory requirements, processor
quantity/speed or SPEC rating, interconnectivity, etc.) to support the Production environment
and non-production environments including: development, test, and disaster recovery.
RFP – Meter Data Management System
62
Response:
15.4.2 Offeror shall provide an estimate of disk growth for one, three, and five years, for the production
environment and appropriate test environment.
Response:
15.4.3 The MDMS shall have the ability to selectively choose which data to be maintained and which to
be purged or archived.
Response:
15.4.4 The MDMS shall support open database management tools for database extraction, loading,
transformation, reporting, and administration.
Response:
15.4.5 The MDMS shall be configurable to support rules and parameters that can be set up for
users/accounts with specific attributes and batch files, such as rates or customer type.
Response:
15.4.6 Offeror shall explain how its solution supports a multi-participant model. This model consists of
separate operating companies on one environment with partitioned data, different VEE
configurations, different support rules and parameters, etc.
Response:
15.5 System Security
Cyber Security requirements are integral to Fort Collins Utility’s Smart Grid implementation. As a
foundational element of the total Fort Collins Smart Grid implementation, the security aspects of the
MDMS solution are critical. Therefore, it is required that the Offeror’s policies, procedures, personnel,
products, and services used to design, build, code, configure, deliver, manage data, integrate, test,
deploy, and support the MDMS solution comply with the currently released and applicable security
standards including but not limited to NIST SP 800 -53 and FIPS 140-2.
15.5.1 . Security Development Lifecycle: Offeror shall describe their implementation of a Secure
Development Lifecycle as part of their larger Product Development Lifecycle, including but not
limited to their unique methodology, tools, best practices, quality gates and example artifacts.
RFP – Meter Data Management System
63
Response:
15.5.2 Security Testing: Offeror shall describe their approaches, methods and artifacts for security
testing, including but not limited to the following scenarios:
15.5.2.1 Internal passive and active testing
Response:
15.5.2.2 3rd party external passive and active testing;
Response:
15.5.2.3 3rd party certifications achieved;
Response:
15.5.2.4 Detailed reports of vulnerabilities found, remediation conducted and evidence of re-testing.
Response:
15.5.3 Resiliency: The Offeror shall describe all approaches, capabilities, and mechanisms for
maintaining resiliency within the System, including but not limited to self-healing, intrusion
detection/prevention, denial of service prevention/resistance, fault tolerance, disaster recovery.
Offeror shall also describe approaches and mechanisms to detect and alert system failed
resiliency status and/or events.
Response:
15.5.4 Third Party Security Review: If Offeror is selected, Utility reserves the right to commission a
third-party security review or penetration test of any and all components of the Offeror’s solution
prior to production implementation. Security issues or vulnerabilities discovered must be
remediated by the Offeror prior to production implementation, at the sole discretion of Utility,
and at the Offeror’s expense.
Response:
15.5.5 Access Control (AC). The Offeror shall describe all approaches, capabilities, and mechanisms
for Access Control within the System, including but not limited to Access Control Lists, Role
RFP – Meter Data Management System
64
Based Access Control (RBAC) models, Active Directory Services (ADS), identity management,
restricted use notification splash screens, unsuccessful login attempt controls, and any others
(ref. NIST SP 800-53 AC-3, AC-7, AC-8).
Response:
15.5.6 Audit and Accountability (AU). The Offeror shall describe all approaches, capabilities, and
mechanisms for generating audit records/logs within the System for the minimum list of
auditable events with the minimum list of information items identified below (ref. NIST SP 800-
53 AU-2, AU-3, AU-12, MA-4):
Response:
15.5.6.1 Auditable events:
15.5.6.1.1 Unsuccessful access attempts,
Response:
15.5.6.1.2 Alteration of configuration files,
Response:
15.5.6.1.3 Alteration of database files,
Response:
15.5.6.1.4 Alteration of authenticator content,
Response:
15.5.6.1.5 Application error events (i.e. oracle db errors),
Response:
15.5.6.1.6 Application failure events,
Response:
RFP – Meter Data Management System
65
15.5.6.1.7 Maintenance and diagnostic events (for local and remote accesses)
Response:
15.5.6.2 Content of audit records:
15.5.6.2.1 Type of event that occurred,
Response:
15.5.6.2.2 Date and time of the event
Response:
15.5.6.2.3 Location the event occurred
Response:
15.5.6.2.4 Outcome of the event (success or failure)
Response:
15.5.6.2.5 Identity of any associated user/subject associated with the event
Response:
15.5.6.3 Allow Utility privileged System users to select which auditable events are to be audited by
specific System components.
Response:
15.5.7 The Offeror shall describe all approaches, capabilities, and mechanisms for responses including
alerts to audit record process failures such as but not limited to event messages no longer being
generated/logged, shut down system, overwrite oldest audit records, stop generating audit
records, etc. (ref. NIST SP 800-53 AU-5).
Response:
RFP – Meter Data Management System
66
15.5.8 The Offeror shall describe all approaches, capabilities, and mechanisms for generating date and
time stamps for event logs/audit records based on (ref. NIST SP 800-53 AU-8):
Response:
15.5.8.1 Internal system time clock.
Response:
15.5.8.2 Synchronization of internal system time clock to a universal/centralized time server, UTC,
GMT, to support inter-system audit record review and analysis.
Response:
15.5.9 The Offeror shall describe all approaches, capabilities, and mechanisms for protecting audit
information/logs and tools from unauthorized access, modification, and deletion (ref. NIST SP
800-53 AU-9).
Response:
15.5.10 The Offeror shall describe all approaches, capabilities, and mechanisms for Non-
Repudiation within the System, including but not limited to encryption, key management, PKI,
hashing, digital signatures, and/or digital message receipts (ref. NIST SP 800-53 AU-10).
Response:
15.5.11 Configuration Management (CM)
15.5.11.1 The Offeror shall describe all approaches, capabilities, and mechanisms for establishing,
documenting, tracking, managing, controlling, and verifying System hardware, firmware,
software, and System setting configurations for baseline and updated/upgraded systems (ref.
NIST SP 800-53 CM-2, CM-6)
Response:
15.5.11.2 The Offeror shall describe all approaches, capabilities, and mechanisms for establishing,
documenting, tracking, managing, controlling, and validating an operational system
configuration of 'Least Functionality' where non-required functions, ports, services, and
protocols are disabled/prohibited (ref. NIST SP 800-53 CM-7).
Response:
RFP – Meter Data Management System
67
15.5.12 Identification and Authentication (IA)
15.5.12.1 The Offeror shall describe all approaches, capabilities, and mechanisms such as but not
limited to user IDs, passwords, tokens, biometrics, in the case of multifactor methods some
combination thereof for uniquely identifying and authenticating users or processes acting on
behalf of users whether access is via local interfaces or network connections (ref. NIST SP
800-53 IA-2).
Response:
15.5.12.2 The Offeror shall describe all approaches, capabilities, and mechanisms to protect and
manage authenticator content (i.e. passwords) for users, devices, and systems such as but
not limited to content stored in hashed or encrypted formats for the following system aspects
(ref. NIST SP 800-53 IA-5, IA-6, IA-7):
Response:
15.5.12.2.1 Protect authenticator content from unauthorized disclosure and modification.
Response:
15.5.12.2.2 Obscure feedback (display) of authentication content (passwords) when
entering authentication content in authentication windows/dialog boxes (i.e.
masking characters via asterisks or dots).
Response:
15.5.12.2.3 Encrypt authentication content (passwords) during transit to an authentication
server during authentication processes (.i.e. system shall not send passwords
in the clear).
Response:
15.5.12.2.4 Use of cryptographic module mechanisms for authentication consistent with
FIPS 140-2.
Response:
RFP – Meter Data Management System
68
15.5.13 Incident Response (IR). If so capable, the Offeror shall describe all approaches,
capabilities, and mechanisms used to provide/support Utility incident response investigations
such as forensic activities or incident source determinations (ref. NIST SP 800-53 IR-7).
Response:
15.5.14 Media Protection (MP). The Offeror shall describe approaches, mechanisms, and capability
for protecting Fort Collins media per the following (ref. NIST SP 800-53 MP-2, MP-6):
15.5.14.1 Limiting access to Fort Collins media in accordance with NDAs and limit access to only
those personnel whom are directly involved on the Fort Collins project.
Response:
15.5.14.2 Sanitize system media, both digital and non-digital, prior to disposal, release out of company
control, or release for reuse.
Response:
15.5.14.3 Dispose of Fort Collins Utility sensitive or classified information upon the request of Fort
Collins and/or at the end of the project.
Response:
15.5.15 Personnel Security (PS). The Offeror shall describe approaches, mechanisms, and
capability to comply with Fort Collins Utility contractor personnel security policy requirements
that include but are not limited to the following (ref. NIST SP 800-53 PS-6, PS-7, IA-8):
15.5.15.1 Providing proof of background checks in accordance with Utility policies when working on
Fort Collins Utility property, using remote network connections to the system, etc.
Response:
15.5.15.2 Signing Fort Collins Utility access agreements prior to being granted access to Utility
facilities.
Response:
15.5.15.3 Enforcing personnel use of unique identity user accounts and authentication content for
System accesses whether via local interfaces or network connections (i.e. user IDs,
passwords, tokens, biometrics, in the case of multifactor methods some combination
thereof).
RFP – Meter Data Management System
69
Response:
15.5.16 Systems and Services Acquisition Policies and Procedures (SA).
15.5.16.1 The Offeror shall describe all approaches, capabilities, and mechanisms to provide the
following information to Fort Collins (ref. NIST SP 800-53 SA-5):
15.5.16.1.1 Administrator documentation for the System that describes secure
configuration, installation, and operation of the System.
Response:
15.5.16.1.2 Known vulnerabilities regarding configuration and use of administrative (i.e.,
privileged) functions.
Response:
15.5.16.1.3 User responsibilities in maintaining the security of the information and
information system.
Response:
15.5.16.1.4 Effective use and maintenance of security features/functions.
Response:
15.5.16.1.5 Methods for user interaction with the information system, which enables
individuals to use the System in a more/most secure manner.
Response:
15.5.16.1.6 User documentation for the System that describes user-accessible security
features/functions and how to effectively use those security features/functions.
Response:
15.5.16.2 Should the Offeror require persistent remote network connection (i.e. VPN) to Fort Collins
Utility Systems, the Offeror shall describe all approaches, capabilities, and mechanisms to
comply with Fort Collins Utility defined security standards that include but are not limited to
configuration management, testing, access management, and boundary protection (ref. NIST
SP 800-53 SA-9).
RFP – Meter Data Management System
70
Response:
15.5.16.3 When providing System developer and integrator services to Fort Collins Utility, the Offeror
shall describe all approaches, capabilities, and mechanisms to perform the following
developer/integrator configuration management (ref. NIST SP 800-53 SA-10):
15.5.16.3.1 Configuration management during system design, development,
implementation, and operation.
Response:
15.5.16.3.2 Manage and control changes to the System.
Response:
15.5.16.3.3 Implement only Utility approved changes to the System.
Response:
15.5.16.3.4 Document approved changes to the System.
Response:
15.5.16.3.5 Track security flaws and flaw resolution.
Response:
15.5.16.4 The Offeror shall describe all approaches, capabilities, and mechanisms system
developer/integrator personnel shall apply in consultation w/security personnel/engineers
(ref. NIST SP 800-53 SA-11):
15.5.16.4.1 Create and implement a security test and evaluation plan(s).
Response:
15.5.16.4.2 Implement a verifiable flaw remediation process to correct
weaknesses/deficiencies identified during security testing and evaluation
processes.
Response:
RFP – Meter Data Management System
71
15.5.16.4.3 Document security testing/evaluation and flaw remediation processes.
Response:
15.5.17 System and Communications Protection (SC). The Offeror shall describe all approaches
and mechanisms for maintaining Data Integrity within the system, including but not limited to
encryption and Key Management, PKI, hashing, CCM, CBC-MAC and any others. Offeror shall
also describe approaches and mechanisms to detect and alert failed Data Integrity compromise
attempts (ref. NIST SP 800-53 SC-13).
Response:
15.5.18 System and Information Integrity (SI).
15.5.18.1 The Offeror shall describe all approaches, capabilities, and mechanisms for System flaw
remediation for, but not limited to, the following (ref. NIST SP 800-53 SI-2):
15.5.18.1.1 Identify, report, and correct System flaws.
Response:
15.5.18.1.2 Test software updates related to flaw remediation (i.e. patches, service packs,
hot fixes) for effectiveness and potential side effects on Utility System(s) before
installation.
Response:
15.5.18.1.3 Incorporate flaw remediation into the Utility configuration management process.
Response:
15.5.18.2 The Offeror shall describe all approaches, capabilities, and mechanisms for protecting the
System from malicious code (ref. NIST SP 800-53 SI-3, SI-5):
15.5.18.2.1 Including but not limited to anti-virus or other anti-malware components, system
hardening and any others.
Response:
RFP – Meter Data Management System
72
15.5.18.2.2 Address the receipt of false positives during malicious code detection and
eradication operations and the resulting potential impact on the availability of
the System.
Response:
15.5.18.2.3 Providing applicable System security alerts and advisories to Fort Collins Utility.
Response:
16 MDMS Implementation Services
16.1 Offeror shall provide a summary of the Offeror’s proposed project team including resumes for key
personnel. Represent the project team members on an organizational chart and outline the roles
and responsibilities of each.
Response:
16.2 Offeror shall provide a detailed description of the Offeror’s project implementation methodology in
a separate appendix. Fort Collin’s must be able to clearly identify the following components in the
project methodology:
• The tasks included in the Offeror’s implementation methodology.
• The list of workshops that are included in the Offeror’s design phase, to include: a typical
workshop schedule, duration, and expected Fort Collins and other vendor participants in each
workshop.
• The list of deliverables to Fort Collins at the completion of the design phase.
• Offeror and Fort Collins activities during the build phase of the project, specifically related to
building hardware environments, configuring the MDMS application, building integrations, etc.
• Offeror and Fort Collins activities in preparation for and execution of the testing phase of the
project, to include: Offeror’s test phase deliverables, test phases, and levels of support.
• Offeror and Fort Collins activities in preparation for and execution of the training phase of the
project, to include: Offeror’s test phase deliverables and levels of support, and overall training
program.
• Offeror’s support for the multiple Business Releases of the project.
• Offeror’s proposed schedule for the project.
• Offeror’s assumptions that impact the Services pricing in the Offeror’s proposal, including a
specific list of items identified in the bullets above that are not included in the Offeror’s pricing.
16.3 Offeror shall describe the technical support levels available to Fort Collins and who provides
them. The description of the service levels should include response times, phone support, email
support, on-site support, 24/7 support, etc. In this description, Offeror shall indicate the number
RFP – Meter Data Management System
73
and type of personnel that is currently available or envisions being available to provide support
services to its customers
Response:
RFP – Meter Data Management System
74
EXHIBIT A - Terms and Conditions
The City of Fort Collins Utilities will be issuing its set of Terms and Conditions to the Offerors; the
expected date of availability is Dec. 6, 2010. Please check the procurement website for further
information on this availability.