Advanced Meter Infrastructure Software

The vendor is required to provide from qualified vendors that can effectively support the county in implementing, training, and managing advanced metering infrastructure (AMI) system for its water utility, encompassing the replacement of existing water meters with smart meters, installation of a robust communication network, and development of a data management platform to collect and analyze real-time water usage data, aiming to improve billing accuracy, and promote water conservation initiatives.
- Overall system characteristics
• Provide a schematic depicting the system’s components and configuration.
• Provide a brief overview of the architecture and normal functioning of the system.
• Time synchronization and system commands
• Indicate if meter readings from meter interface unit (MIUS) are time-synchronized (e.g., meters are all read at the top of the hour).
• If so, explain how this is achieved and the clock in the MIU is set.
• Indicate the accuracy of the synchronization (e.g., +/-15 seconds).
• In addition to time-synchronization, describe other commands or information that may be sent to the MIU from the HES or data collection unit in the course of the normal operation and maintenance of the system.
• Meter reading interval
• Indicate the default interval at which the MIU interrogates the meter (e.g., once per hour), and whether the interval can be changed for individual meters or a selected group of MIUS at the same time.
• If so, indicate the settable range of this interval.
• Describe the procedure required to change the interval and reset it.
• Indicate if changing the interval can be accomplished over-the-air from the HES.
• If changing the interval will change the expected MIU battery life, provide specific parameters or examples (e.g., “15-minute interval will reduce expected battery life by x”).
• Transmitting interval
• Indicate the default interval for transmitting readings from the MIU (e.g., once per day), and whether the interval can be changed.
• If so, indicate the settable range of this interval.
• The procedure required to change the interval and reset it.
• If changing the interval will change the expected MIU battery life, provide specific parameters or examples
• Indicate how many full meters register readings and how many increment count reads are transmitted by the MIU at one time.
• Describe how missing reads may be recovered and retransmitted from the endpoint, including automatically backfilling missing interval data.
• Elapsed time (latency)
• Indicate the longest possible elapsed time from a when a meter is read by the MIU to when that meter reading is available at the AMI HES
• Read on demand
• Indicate if the system can obtain a real-time read on demand “over-the-air” from the MIU and meter by sending the MIU a signal.
• Indicate the expected time interval between a user’s on-demand reading request and the response.
• Radio communication band and licenses
• Indicate what radio frequencies are used for interactions between the MIUS and DCUS.
• Indicate what FCC license(s), if any, the system will require. include the cost of licenses in the price schedule as part of the price proposal.
• Indicate the expected length of time to acquire such licenses. offeror shall be responsible for obtaining all necessary licenses on behalf the county and in the county’s name.
• local frequency licenses shall be assigned the county. for national frequencies, the county must be provided an irrevocable right to use the license for its system, so long as the system is in service.
• Indicate the separate charges, if any, for this right in the pricing proposal.
• If the proposed network uses cellular for endpoint connectivity, offeror shall indicate cellular service provider for interactions between the MIUS and DCUS.
• Include the cost of cellular services in the price schedule as part of the price proposal.
• Protection from interference
• Describe procedures that will be used use to regularly check for, identify and remove interlopers on its licensed frequency(ies) or overpowered signals on unlicensed frequencies. indicate who will be responsible for this effort.
• The county, describe provisions offered by offeror or its system to assist in this effort
• Indicate the length of time such protection will be offered in association with this proposal/contract
• Data transmission integrity and security
• Describe measures, such as encryption, error checking and retransmission, transmission of prior reads, etc., used to ensure the accuracy, integrity and security of data transmitted between the MIU and the HES
• Describe any security certifications currently held related to the proposed solution
• Indicate the frequency of and type of security audits and penetration tests conducted by the offeror on the system
• Provide a list of the tamper conditions that will be provided to the system operator (e.g., missing MIU, cut wire, meter register separation, tilting of meter, empty pipe).
• For each, indicate whether the alarm is transmitted instantly or with the next MIU transmission. indicate the number of times or over what period of time a tamper indication will be provided to the system operator before it is automatically cancelled. indicate whether the tamper indication can or must be reset or reprogrammed by the system operator or field service technician, and how this is accomplished.
• Briefly describe the system’s approach to detecting (a) continuous flow (that is, consecutive non-zero intervals), (b) low flow leaks (many but not all consecutive intervals non-zero), and (c) abnormally high flow (“broken pipe”)
• Indicate if the threshold levels for reporting of these anomalies are definable by the county, and if so, for individual customers or groups of meters.
• Describe system capabilities to validate meter readings for reasonableness, such as unusually high or low readings. describe how system handles potential meter rollovers.
• List other conditions (for example, reverse flow) the system can detect. describe how these are accomplished, and how they are reported.
• Describe any additional current capabilities of the proposed system not already described above, such as remote shut-off or turn-on, pressure monitoring, temperature monitoring, chemical concentration monitoring, smart city applications, etc.
• The system’s ability to add instrumentation (pressure, temperature, chemical, etc.) and to collect distribution system performance information and transmit the information from such endpoints.
• Indicate whether additional software would be required for any additional feature listed.
• Indicate any planned future capabilities for the equipment being proposed, the anticipated development and availability schedule, and the expected procedures for upgrading the county’s system, if applicable.
• Include a product roadmap of planned future capabilities
• The data collection network shall be sufficient to obtain:
1. At least one meter-register reading within a 3-day interval from at least 98.5% of all meters on which the system is installed;
2. At least 95.0% percent of all readings taken hourly or at more frequent intervals.
• Meters with MIUS from which transmissions are blocked by readily identifiable temporary physical barriers beyond the control of the county or offeror are not included in the calculation of these success rates.
• Within the requirements above, meters from which readings are not received shall not be geographically clustered
• The data collection network shall be designed to provide 100% coverage of the county’s service area.
• Indicate how the system will obtain readings from meters in basements, ravines, vaults, and other transmission constraining settings. proposer’s approach may include the use of repeaters, remote antennas, other MIUS, slower transmission rates, etc.
• Indicate the number of firmware releases over the past 12 months for each system component and provide firmware release notes.
• Offeror shall provide any available upgrades or patches to MIU, DCU, repeater and other collection network component firmware for a minimum of 20 years, at no additional cost beyond annual maintenance fees for this equipment
• Indicate if and how firmware patches or upgrades would be applied to each system component.
• List the manufacturing facility, facility location (country and state/province), iso9000 or equivalent certifications for each manufacturing facilities.
• The county expects the manufacturer of meters submitted as part of the proposal to submit its meters to a vigorous quality control and testing procedure before shipping.
• All meter accuracy tests shall be conducted in accordance with AWWA test methods and meter standards.
• The manufacturer shall furnish to the county an electronic copy of the test results for each meter shipped.
• Specific information contained within the test results shall include the manufacturer serial number, flow rates, results of each flow rate test, the size of the meters being tested, the model number, the date, and the tester
• Each water meter will be tested; the county will not accept any type of testing protocol that includes a random sample testing of meters produced.
• Equipment shall be subjected to inspection to ensure compliance with the specifications. shipments of equipment shall be subject to sampling and testing for compliance with specifications.
• Shipments failing the sampling and testing protocol shall be rejected in their entirety and returned to the supplier.
• Any individual pieces of material which fail inspection shall also be rejected and returned to the supplier.
• All freight costs and any other costs incurred by the rejection will be borne by the supplier.
• The county has areas within its distribution system that exceed 150 psi the offeror shall propose metering solutions, that could handle a maximum working pressure of 200 psi.
• It is expected that the proposed metering solution will enhance low flow sensitivity and provide extended flow capacity.
• Fire service meters and strainers shall have the underwriter’s laboratories, inc. (ul), and factory mutual (FM) approval for use on fire lines.
• The manufacturers shall guarantee the entire meter, including the register for a period of 20 years from the date of shipment against all defects in material and workmanship.
• The manufacturer’s serial number shall be stamped on the main case of all meters and shall be clearly visible when viewed from above.
• The serial number shall consist of all numeric digits. all meters shall have stamped or cast on them the size and model.
• The direction of the flow through the meter shall be properly indicated.
• The serial number should also be provided on 2 bar code labels attached to the meter, one of which shall be removed for transfer to a paper record.
• The county prefers that the serial number include digits representing the year of manufacture.
• individual shipping containers (if applicable) shall be marked to identify contents and quantity.
• the county desires that this information also be in the form of bar codes for scanning. meter shipments shall be accompanied by a computer file of the meter serial numbers for the county’s database.
• Meter registers should have a flip cap to prevent dirt from interfering with the visual inspection of the register, its id number, its indicators and other information.
• The county requires high resolution registers with the ability to transmit a meter reading with a minimum of 8-digits through the AMI network.
• Indicate the number of transmitted digits.
• Indicate the high-resolution registration capabilities by meter size and type.
• The register and wire connection shall be waterproof and corrosion proof
• Meters that are not factory potted to transmitters shall be provided with waterproof connectors on a 5-foot three-conductor 18- gauge cable potted to the meter register
• Indicate if meter uses a battery and if low battery alarm can be transmitted through the MIU and how long is this alarm available before meter fails to fully function.
• Each encoder register shall have a unique identification number with a minimum of 8 digits that will be transmitted electronically when the meter is interrogated.
• For new meters, this number shall be the number stamped into the meter base.
• The county prefers that this number be permanently stamped into the cap.
• The register should be shipped with an attached bar code corresponding to the register number.
• The meter supplier shall submit nationally and global published literature clearly outlining its meter return rate and current price schedule covering complete meter exchange.
• The offeror should list any, and all lawsuits between the manufacturer and utility systems involving the performance and accuracy of any meter they have manufactured within the last 10 years
• The data should include the last 10-year performance results.
• The county will just accept static-ultrasonic meters as a replacement for its existing meters.
• Offeror shall provide prices for each meter size in the pricing table.
• The county will just accept static-ultrasonic meters as a replacement for its existing large meters. offeror shall provide prices for each large meter size in the pricing table.
• Offeror must provide responses to the requirements in this section for each version for those features that are different, clearly specifying which version they apply to.
• Provide specifications of the proposed MIU(s), including physical characteristics and dimensions.
• Indicate environmental tolerances, including temperature and humidity ranges. indicate if there are different models of MIUS for indoor, outdoor wall-mounted, and vault installations.
• The county prefers a single model with appropriate mounting brackets for different situations
• The MIU that prevent corrosion or degradation of mechanical or electrical performance
• The MIU shall be provided in a waterproof casing rated ip67 or better in accordance with the IP code, IEC standard 60529
• The MIU enclosure should be composed of ultraviolet (UV)- inhibiting abs or similar material
• All materials used in the MIU must be non-hazardous under normal conditions.
• Indicate the duration and strength of radio signals from the MIU in normal or default mode.
• Indicate if an external antenna is required or whether one is optional.
• Indicate under what circumstances an external antenna is needed.
• Please indicate dimensions of available antennae
• Please indicate maximum length of wire between antennae and meter.
• Indicate whether the MIU can be read in both mobile and fixed mode, and if so, whether it needs to be programmed from one to the other mode.
• The procedures for converting the MIU from one mode to the other and indicate whether it can be programmed to do so with mobile DCU or programmer and/or fixed DCU.
• Indicate how many meter readings at what intervals, and what resolution are normally stored in the MIU
• Indicate the maximum number of reads that can be recovered in mobile and fixed collection
• The MIUS shall be designed for a 20-year operating life including battery, transmission strength and all other system performance.
• The expected MIU battery life as a range of years within two standard deviations of the average expected life under normal or default MIU meter interrogation and transmission settings and the climate in the county’s locale.
• The MIU low battery warning system, the warning time in months provided before failure under normal conditions, and how this is accomplished
• Indicate the differences in expected MIU battery life, if any, when reading different types and makes of meter registers
• The MIU can be read in a mobile configuration as well as fixed, indicate if there is a different expected battery life for each reading method.
• 100 indicate to what extent the following functions would affect battery life: (a) installing firmware over the air; (b) extracting 5-minute reads from the meter for a 1-week period (c) on-demand reads more than 4 times per year; and activating a control valve (if available) more than 2 times per year.
• Each MIU shall have a unique, permanent id number that is transmitted with the meter readings. indicate the number of digits
• The MIU shall be permanently labeled on the outside with the manufacturer’s name, model number, MIU identification or serial number, bar code of this number, required fcc labeling, input/output connections, and date of manufacture.
• The label should be weatherproof and attached to the MIU where normal installation will not obscure it
• The county desires that the MIU be shipped with 1 permanent bar code label and 1 removable adhesive bar code label for installation control purposes.
• MIU programming requirements (including equipment), procedures and options
• Indicate if the MIU can be pre-configured in the factory.
• Indicate provisions to avoid installation errors, improper connection to meters, and programming mistakes.
• Indicate if successful initial communication between the MIU and the HES can be verified in real time in the field, and how long it takes.
• Briefly describe procedures that need to be followed to replace failed MIUS .
• Describe physical features (seals, tamper resistant bolts, etc.) to minimize and detect tampering with the MIU.
• Describe safeguards that prevent accidental or malicious effects to the MIUS , such as disruption of the MIU firmware, parameter or clock changes, continuous waking of MIU leading to battery failure, or unwanted activation of water shutoff
• Describe the proposed normal wiring connection between the MIU and the meter, and any options
• Provide photographs and diagrams of any brackets or lid assemblies used to mount the endpoint in vault applications.
• For installations in meter boxes, indicate the minimum requirements for the internal dimensions of the meter box
• The MIU should be compatible with all meter brands furnished with absolute encoder registers and electronic registers and read at minimum 8 digits
• Provide a table showing the degree of compatibility of proposer’s MIUS with the county’s makes and models of water meters in table below.
• Indicate whether concrete or metal meter box or vault lids, respectively, are to be drilled, replaced, and left alone for the proposer’s system to operate to the performance criteria specified.
• Provide in pricing proposal estimates for the installation, operation and maintenance costs of each device. for sites where the county has no facilities, estimates must include tower or roof leasing costs for a county-dedicated or shared network.
• Provide costs for solar panels, if appropriate.
• If the proposed network uses cellular for endpoint connectivity, offeror shall provide a coverage map from the corresponding carrier or perform a drive- by study to develop and provide a coverage map.
• If communication equipment is to be installed on third-party sites, the successful offeror shall obtain or assist the county in obtaining, 20-year rights for installing and operating that equipment; these rights will be transferred to the county at no additional cost at the time of successful system acceptance.
• The case of a county-dedicated network, the county may choose to procure AMI
network monitoring and management services – network as a service (NAAS).
• Offeror would monitor read success rates and overall endpoint performance, monitor and maintain the network, including devices and communications backhaul, and deliver event, alarm and performance reports
• Indicate available options and the preferred or recommended method for communicating with the HES
• Offeror is solely responsible for determining the mix of data collectors and repeaters MIU placement strategies, and MIU communication configuration needed to meet or exceed the specified performance requirements
• Indicate the proposed number of data collection units and repeaters to achieve the levels of system performance specified.
• The county will only be responsible for the costs associated with the proposed network infrastructure and life-cycle cost submitted in the pricing proposal
• Costs associated with additional network devices, installation changes, third-party sites, or additional O&M that are needed to meet the specified performance requirements, will not be reimbursed
• For a county-dedicated network, indicate if the collector firmware is upgradeable, and, if so, describe how it is upgraded.
• Indicate if firmware upgrades can be performed over the network
• The available memory capacity of the DCU in terms of the number of meter readings and usage intervals stored
• For dedicated networks, describe other applications that may use the system’s radio frequency network and data collectors, such as communications for field work automation systems.
• If proposer’s system includes an option for vehicle-mounted mobile meter reading of the endpoints proposed above, provide responses
• If mobile reading capability is provided by a portable-handheld device, even though it can be operated from a vehicle do not respond to this section, but include the relevant information in responses below.
• The proposed solution for collecting meter reads with a mobile collector, specifically describing the collection of both daily and hourly meter reads
• The process for loading routes to and from the mobile collector.
• If data can be transmitted wirelessly, describe this process and requirements.
• The hardware components of the mobile data collection system.
• Indicate which components are ruggedized and/or in weatherproof enclosures.
• Indicate any vehicle-specific requirement(s) for the successful operation of the mobile data collection system.
• The software for the mobile data collection system.
• Indicate map based-features are included
• Provide screen shots.
• Indicate whether the software has the ability to accept a manual reading and/or notes in the account record.
• indicate the maximum vehicle speed for the normal collection of meter readings.
• Indicate the storage capacity of the mobile data collector
• Indicate the average time required to collect a meter read (both daily and hourly) using the mobile data collector
• Indicate if and how the communication protocol from and to the MIU for the mobile data collector is different from the communications protocol used fixed network data collectors.
• Indicate connecting hardware and software, including cables, modem, cradle, battery, charger, etc., are required for the unit to be fully functional.
• Indicate if the programmer and/or handheld interrogators are dedicated units, or software that can be put on a third-party phone, tablet or other devices
• If third-party tablets or other devices may be used for programming, meter reading and diagnostics, indicate the minimum hardware requirements, device operating system type and version, and any apps required including minimum version.
• The dimensions, weight, environmental tolerances, resistance to dropping and submergence, and other physical characteristics of the proposed unit
• The county prefers that the new meter reading and register number be captured automatically through the MIU and visually displayed.
• Indicate if the unit is capable of programming the MIU with any information required for operation that was not factory pre- programmed into the MIU.
• Identify how much data, or how many work orders, each unit can accommodate, and how many meter readings a portable interrogator can accommodate.
• Indicate what connecting hardware and software, including cables, modem, cradle, battery, charger, etc., are required.
• The unit shall include or be capable of capturing and recognizing bar codes to capture meter or MIU identification numbers from bar code labels on these components.
• The unit shall be capable of capturing GPS coordinates at least sub-meter accuracy
• The unit shall be equipped with a digital camera, including flash, for capturing medium resolution images of meter registers, meters, site conditions, etc., in conjunction with installation, maintenance and troubleshooting.
• Provide the unit operation life in hours on a fully charged battery when the unit is involved in installation and programming, including taking up to 3 pictures of each installation
• Provide time it takes to fully recharge the unit’s battery after a full day of normal use.
• Indicate if the battery can be recharged outside of the unit and/or from a 12-volt vehicle system.
• Explain how the unit ensures against accidental data loss in case of a dead battery
• Indicate the angular range of readability
• Indicate whether the unit permits manual entry of meter readings and other information
• Provide screen shots for this other information, including notes or comments.
• Include a detailed description of any hardware (e.g., cradles) or software needed to support portable programmer/reader/ field test units.
• The mechanism and procedure for downloading and uploading data from installation hardware to the AMI HES and/or any other information system normally used in the maintenance of the AMI system.
• The mechanism and procedure for downloading and uploading data from the AMI HES and any other information system to the county’s customer information system and its mobile field work order management system.
• The software shall enable the county to effectively obtain all of the meter readings and other data generated by the system, monitor and manage the AMI system, including underperforming or nonperforming MIUS, repeaters, data collection units and backhaul communications, and determine remediation measures
• Indicate normal modes of operation of the AMI system software, including batch processing and single meter reading query processing.
• The steps a system operator must perform to obtain meter readings from the meters at the customers’ premises, if the functions are not totally automated.
• The county prefers that meter readings for billing are provided automatically in response to an automated request from the billing system following a billing calendar
• The database should be directly accessible by the county
• Indicate procedures for correcting misinterpreted or misassigned data
• Any database file structure used to store and manage meter readings at the AMI HES should be non- proprietary, ODBC-compliant and SQL-compliant, and provided by a standard commercial database supplier
• Indicate if the data structure of the head-end database allows new data elements.
• Changes in database table structures shall be transparent to the county from one revision of the AMI HES to another.
• Indicate what data is stored in the HES.
indicate how much data, in terms of number of months of data, number of meters, full reads versus increments, meter resolution, and number of reads per day are stored.
• The back-up capabilities and procedures to ensure that the HES and consumption data is not corrupted or lost.
• The system software and functions should be quickly and easily accessible to users even in the event of a Failure at the proposer’s data center
• The system provides secure remote access to AMI system functions, reports and data from other workstations or web browsers on or outside the county’s network.
• Indicate how many users can simultaneously access the system for queries and for data entry.
• Describe normal procedures for system administration
• The security infrastructure of the proposed HES; how security is implemented at the presentation, application, database, and network levels; logging of system access and database transactions for all actions, and items captured as part of the security log.
• Provide a list, with brief descriptions and screen shots or sample pages, of all the standard reports provided for system and component performance; missing or late data; errors, anomalies, tampering, and alarm conditions; and data transfer, management, and administration.
• The software should support ad hoc queries and custom reports, using a built-in report writer or a third- party commercially available report writer that is included with the HES.
• Software is required to manage the database of meter readings and other information created by the AMI system.
• This software may be distinct from the HES used to manage the AMI system
• Provide a software architecture diagram and a description of all of the proposed software, including all third-party middleware, database engine, report generator, etc. include version numbers of all products.
• The software shall collect and maintain historical meter read data, including at a minimum: meter identification number, meter attributes, meter location, account and premises identification, mete reads, read dates and times, failures to read, tampering alerts, and leak detection, for each meter in the system.
• The software shall be able to sort and list accounts and their meter reading data.
• The software shall also be able to create user-defined account groups and aggregate consumption profiles
• Indicate normal modes of operation of the AMI system software, including batch processing and single meter reading query processing.
• The system shall maintain at least 24 months of “live” hourly meter reads, and an additional 2 years of “live” daily reads for all of the county’s meters.
• Additional data shall be available on a retrieval basis.
• Indicate the maximum number of meters the MDMS can support with live storage of data as defined above.
• The MDMS must interface to the county’s cis system to provide monthly or on demand meter readings both individually and in batch upon request by the system; synchronize data related to meters, service locations and customers; and provide status reports of alerts for accounts
• Customer information shared and synchronized with the cis should include billing cycle, rate class, customer account-premise-meter relationship, meter type, etc.
• The system’s capability, if available, for handling gaps, overlaps, or implausible reads, estimating missing reads, and backfilling missing or estimated reads with valid reads that are obtained later
• The process should provide an audit history of any data modified or added as a result of the process.
• Indicate procedures for correcting misinterpreted or mis-assigned data
• Identification of possible low flow rate leaks by account
• Identification of possible continuous high consumption events at individual customers’ premises.
• Monitoring “usage on inactive” (registered reads above configurable thresholds without
an active customer account).
• Water theft analysis, use after shut off, and reverse flow.
• Identification of intermittent backflow situations.
• Identification of any meter with little or no change in registration (zero or low consumption) for a configurable number of days.
• Identification of accounts where usage violates temporary restrictions (e.g., apparent outdoor irrigation usage during non-allowed times or days).
• Consumption profiles by season and day type (weekday, weekend, month, holiday, etc.) and by rate class, customer type, and/or any user-specified collection of meters.
• Combining consumption from two registers of a compound meter, including handling the scaling of different registers.
• Consumption histograms to help right size meters
• Indicate which of these conditions can trigger automatically generated alerts and notifications describe (if available) consumption projection analysis
• Describe any capabilities of the software to provide customer, consumption and meter analytics, such as: meter underperformance, unauthorized consumption, non-revenue water analysis, etc.
• The system should enable the comparison of consumption between an individual meter and a group of meters, or between two or more groups of meters.
• The system shall enable the comparison of consumption from all of the meters within a demand management area and the master meter
• The options for obtaining and synchronizing the appropriate master meter data.
• The options for reporting this data, including graphical and tabular, and maps
• Describe capabilities of the software to provide data files to generate field service order requests based on configurable settings, and the ability to send service orders to other work order management systems.
• Describe capabilities of the software to provide data files to cis and/or outbound dialing IVR with messages concerning possible leaks, high consumption, unauthorized irrigation, etc.
• Describe capabilities to generate letters, emails or text messages for customers. indicate data required from cis to provide this capability.
• Describe ability to provide flags to account records in cis of conditions or messages created
• Describe capabilities to keep track of notifications that have been sent and whether they have been received, and to schedule subsequent notifications if the condition still persists.
• Describe responsibilities if a county database administrator (dba) if required to maintain database.
• Describe backups, either incremental or full, without stopping any operational processes
• Describe automated data archiving, purging, and restoration.
• Identify web browser options for proposed system
• Indicate if software supports a session logout that will terminate the user session with a configurable session timeout value.
• Indicate if software supports a session kill on both browser-away and browser-close. describe context sensitive online help.
• Describe the types of configuration changes that would require a system restart.
• Describe functionality to allow the county to set up and change data validation and estimation rules, without modifying source program code and without any proprietary language skills.
• Describe functionality and process to make changes to and alarm/event notifications.
• Describe functionality and tools to change format, content or functionality of user screens and online help contents.
• Provide support for county account file import and account and password authentication, or two-step authentication. describe password requirements
• Indicate if the customer portal can be accessed by a customer from the county’s website or e-billing page.
• The software shall allow the customer to retrieve or re-set a forgotten password via the previously established email.
• The software should provide for password support to county customer service representative (CSRS) to manage forgotten usernames and passwords
• The customer web portal should include a mobile application.
• The software shall allow customers to access and view all meters or accounts they are responsible for in a single logged on session.
• The display will provide all account, address, and meter information relating to that particular customer.
• The software will display the customer consumption history in a graph that can be configured to a customer-specified start and end date.
• The software shall be able to display daily and hourly usage up to the most recent data available in the MDMS.
• The ability of the software to clean up data errors and alarms on customer display. indicate what options the county has to only show validated usage data, or a manual estimation done by a CSR to customer, and to show or suppress register or MIU errors and other alerts.
• The graph shall allow the customer to compare consumption history for different time periods on a single graph
• Describe capabilities of the software to provide data files to cis and/or outbound dialing IVR with messages concerning possible leaks, unauthorized irrigation, etc.
• Describe ability to provide flags to account records in cis of conditions or messages created.
• Describe capabilities to generate letters, emails or text messages for customers. indicate data required from cis to provide this capability.
• Describe capabilities to keep track of notifications (e.g., about continuous flow) that have been sent and whether they have been received, and to schedule subsequent notifications if the condition still persists.
• The software shall allow the customer to download both graphical and chart-based reports of their consumption.
• Network communications
• MDMS and customer portal software.
• interfaces to the county’s cis and other information systems specified in the RFP or proposed by the proposer, which will enable the system to make accessible or deliver readings to and synchronize data with these systems for work orders, asset management, etc.
• Software used to control and manage the proposer’s endpoint installations to ensure that all installation data is captured correctly.
• This includes integration to any handheld devices used in the installation.
• Manuals for any third-party software components incorporated into the system shall be available online or on usb drive in searchable and printable format.
• Provide a method to track and monitor all changes to software, hardware, operation, and maintenance procedures.
• Provide proper training to designated county staff prior to the commencement of installations
• Provide onsite support commencing when AMI SaaS software applications are available to the county and continuing through the county’s issuance of a notice of completion following final system acceptance
• Support shall be provided during any warranty periods for the equipment covered by the support service and during active maintenance agreements
• Provide trained persons to answer technical questions and guide the county employees through the use or diagnosis of the system through a toll-free number
• Provide onsite assistance at the request of the county    
• Onsite support should be rendered within 2 business days of receiving a request for support.
• The AMI system software, including HES, MDMS and customer portal, shall authenticate and authorize users of the system through user login names and encrypted and masked passwords, configurable role and function-based controls to limit access to data, limit access to software functions and features of the system, and provide traceability and thorough user audit logging.
• Provide a schedule of minimum response times for onsite support, and a schedule of costs.
• The process for establishing user access privileges.
• The AMI software shall provide automated methods of preventing cross-site scripting (XSS) attacks or SQL injection attacks from compromising the databases or software functions.
• Provide an overview of proposer’s processes to identify, quantify, and prioritize its AMI system it and infrastructure risks against defined risk acceptance levels and objectives
• Describe offeror organization’s it risks governance, it risks life cycle, and information security policy, including how and how often the policy set is reviewed and maintained.
• Uniform system performance - the system must provide performance that is substantially uniform throughout the county’s service territory, defined as: within 0.25 miles of any MIU from which a standard consumption message was not received, there are not more than 20 other MIUS from which a standard consumption message was also not received.
• Register read performance - the system shall on the day of system acceptance testing provide meter register readings not more than 3 days old from at least 98.5% of the endpoints determined to be available on that day.
• Interval data performance - the system shall on the day of system acceptance testing provide not less than 95% of all the hourly interval readings from all of the endpoints determined to be available on that day, and not less than 80% of the interval reads from any one endpoint
• The proposed meeting plan including reporting requirements, expected participants, and expected topics of meetings.
• Provide access by the county and its customers to the county’s AMI generated data, system features and related applications.
• Provide access by the county and its customers to the county’s AMI generated data, system features and related applications.
• Monitor and maintain the computing hardware required to run the applications.
• Run routine diagnostics for data corruption and abnormalities, rebuild indexes, and remove duplicate records.
• Run routine checks for security flaws and other issues that could compromise database integrity.
• Run compacting and defragmentation procedures and keep database statistics up to date.
• Monitor data and log file size to minimize response time to queries and file requests.
• Run these procedures on a schedule designed to minimize interference with user access
• Problem resolution shall include immediate corrective measures and where appropriate, root cause analysis and long-term preventive measures to prevent reoccurrence
• Offeror shall propose procedures to report on and deal with problem analysis and resolution based on extent and criticality of the problem using a systematic problem diagnosis and decision-making model or procedure, including root cause analysis
• Provide reasonable resources to assist offeror in problem analysis
• Provide a monthly report of the following key performance indicators for each of the software components:
1. System availability as percentage of uptime
2. System uptime as well as software component uptime
• The county’s preferable option is for the offeror to provide network and system monitoring and management services
• Monitor network devices (data collectors and repeaters) and backhaul communications (in terms both of contractual and operational performance), as well as monitor for interference or poor signal to noise ratios on any licensed frequencies involved in AMI system communications, on a 24-hour x 365-day basis.
• For a county-dedicated network, manage the contract with the backhaul communications provider(s) to secure the lowest possible backhaul cost while meeting the system performance requirements.
• Investigate any unplanned network or communications outages, anomalies or performance problems, including office-based troubleshooting and investigations of suspect components, and create work requests for field repairs. offeror shall coordinate directly with backhaul communications supplier to resolve communications and performance problems
• Provide preventive and corrective maintenance for all network devices, including hardware and software.
• Plan for and modify the network (such as adding data collectors) to maintain the system performance requirements, following change management procedures to ensure that modifications to the network are authorized, tested, and approved by the county, properly implemented and documented.
• Provide an organization chart or listing of the staff that will support the managed services, and a brief description of their roles
• These should include, but not be limited to, services manager, system engineers, and support technicians.
• The county-dedicated network infrastructure on-site maintenance shall be provided by proposer’s local technicians or authorized subcontractors that will be dispatched by proposer
• The county prior to and following any updates. offeror shall be responsible for applying network component firmware and software updates to the equipment in the county’s system.
- Contract Period/Term: 1 year
- Pre-Proposal Conference Date: March 21, 2025
- Questions/Inquires Deadline: March 27, 2025