SDG&E Functional & Technical Requirements 1 · Web viewTable of Contents. 0 Bidder Notes &...

Appendix D: Functional and Technical Requirements 1. AMI Technology

Appendix D Functional and Technical Requirements 1. AMI TechnologyTable of Contents

0 Bidder Notes & Instructions.....................................................................................................2

1 Scope.......................................................................................................................................3

2 Objective..................................................................................................................................4

3 Summary.................................................................................................................................5

4 Company AMI and OpEx 20/20 Technology Experience........................................................5

5 Product/Service History and Strategy......................................................................................6

6 Approach, Methodology and Capacity to Deliver....................................................................8

7 AMI and OpEx 20/20 System Information Requirements........................................................8

8 AMI Technology: Support Requirements...............................................................................83

9 AMI Technology: Field Tests.................................................................................................85

10 AMI Technology: Design, Build, Run, Transfer...................................................................86

Confidential material protected pursuant to California Public Utilities Code Section 583, General Order 66-C, and applicable Non Disclosure Agreements

1


0 Bidder Notes & Ins t ruc t ions 1

0.1 Bidder NotesThis solicitation is a re-release of the Company’s AMI Technology solicitation of October 2005. In order to facilitate responses for bidders this solicitation maintains the original solicitation structure and numbering. Revisions to the original specification are denoted as follows:

New or changed specifications/requirements are shown in red.

Deleted specifications/requirements are shown in strikethrough.

Bidders are instructed to note that appendices have been revised and expanded, however, they do not employ revision marks.

0.2 Bidder InstructionsThroughout this document the term “Requirement” or “Requirements” is intended to identify desired specifications of the proposed AMI and OpEx 20/20 solution. The term “Optional” is intended to identify desired specifications that the Bidder is encouraged to provide, but not required to provide.

AMI Technology Bidder(s) may be asked to provide working production end devices and network hardware, software and configuration tools upon request of the Company within 30 days of the RFP response due date.

The functional, performance, information, and physical Requirements for the Company’s AMI System are provided in a top-down decomposition as follows:

Section 7.1: AMI and OpEx 20/20 System Information Requirements. These are the application-level functional and performance Requirements of the complete AMI and OpEx 20/20 System. These Requirements shall be met by the System proposed, however, the Company is not prescribing where within the System, or how the System will meet these Requirements. Bidders are instructed to propose a complete solution composed of end-point devices through head-end data collection, and to respond to specifications based on the functionality and performance of the complete system. For example, it is not acceptable to defer requirements based on underlying meter capabilities. Bidders proposing integrated meter and communications products shall respond based on the performance and functionality of proposed integrated products.

1 Following the document convention this entire section should be shown in red, however, for clarity of demonstrations, this section does not follow the document conventions employed throughout the remainder.


2


Section 7.2: AMI and OpEx 20/20 System Requirements. These are the functional, performance, and information Requirements of the complete AMI and OpEx 20/20 System including the communications infrastructure.

Section 7.3: AMI and OpEx 20/20 Network Communications Equipment Requirements. These are the functional, performance, information, and physical Requirements of the network communications equipment comprising the proposed AMI and OpEx 20/20 System.

Section 7.4: AMI End-Point Device Requirements. These are the functional, performance, information, and physical Requirements of the meters, modules and other end-point equipment comprising the proposed AMI System.

Section 7.5: AMI Head-End System Requirements. These are the functional, performance, information, and physical Requirements of the head-end data collection system comprising the proposed AMI System.

Bidders shall provide complete written responses to each specification citing exact functionality and performance with sufficient support to enable the Company to ascertain the validity of each response. Bidders are allowed to copy and paste responses from their previous submissions as deemed appropriate by the Bidder. Insufficient responses such as “Specification/Requirement Met”, without explanation, shall be deemed non-responsive and thus non-compliant. 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).

0.3 This is an Example SpecificationThis is an example of the response to the specification.

Bidders are advised to avoid introduction of new styles into the response document in order to maintain document integrity by utilizing Microsoft Word’s “Paste special …unformatted text” feature when pasting existing text from other sources. Formatting within the response boxes, including, the addition of diagrams is left open to Bidders. Bidders can use the response box to reference an included file, but must provide within the response box the exact filename so as to facilitate Company evaluation.

1 Scope

This request for proposal is seeking advanced metering infrastructure (AMI) for the Company’s territory consisting of 1.4 million electric meters, and 900 thousand gas meters as well as a communications infrastructure for the Company’s OpEx 20/20 initiative.

The Company’s OpEx 20/20 initiative plans to re-architect the day-to-day operations of the electric and gas business and consists of three major sub-initiatives: customer care, field-force mobility, and asset management. Each of these three sub-initiatives has data communications


3


needs within, and throughout, the service territories of Southern California Gas Company and San Diego Gas & Electric Company.

This request for proposal consists of specifications/requirements for a complete AMI system as well as the communications-only specifications/requirements for the OpEx 20/20 initiative. It is the Company’s desire to leverage the AMI communications infrastructure for the provision of OpEx 20/20 communications needs. Bidders are request to consider the following response options:

• Bidders shall bid AMI stand-alone. A complete AMI Technology solution must be provided per the specification herein. A complete AMI solution is defined as an electric solution, gas solution or an electric and gas solution.

• Bidders may OpEx20/20 incremental to a stand-alone AMI proposal. Bidders may provide solutions to one or all OpEx 20/20 sub-initiatives as long as a complete AMI Technology solution is provided per the specification herein. All OpEx 20/20 pricing shall be incremental to AMI.

2 Objec t ive

2.1 The Company has the following objectives in deploying AMI:2.1.1 Partial, to Complete coverage of Company’s service territory and all of the

electric and gas meters contained within as defined by the segmentation criteria (Appendix F – AMI Segments).

2.1.2 To adhere to the CEC 6 Policy Goals.

2.1.3 Deploy a comprehensive and flexible AMI system that enables Company to utilize the system for additional future applications and benefits as detailed.

2.2 The Company will adhere to the following AMI project schedule:2.2.1 Technology field tests may be conducted with selected Bidders commencing

2007, ending September 2008.

2.2.2 Partial to Full-scale deployment of the selected AMI Technology/Technologies shall not commence prior to Q3, 2008.

2.2.3 Full-scale deployment of the selected AMI Technology/Technologies shall be completed no later than 1st quarter 2011.

2.3 The Company has the following objectives in deploying OpEx 20/20:2.3.1 Utilize technology to improve customer satisfaction and service, to increase

efficiency of the field forces and to enhance return on investment of company assets.

2.3.2 Leverage common technology investments to the greatest extent possible to achieve the objectives stated above.


4


2.4 The Company will adhere to the following OpEx 20/20 project schedule:2.4.1 Customer Care: Remote agents deployed in 2011.

2.4.2 Field Force Mobility: Mobile Data Terminal (MDT) rollouts beginning in late 2007.

2.4.3 Asset Management - OMS/DMS: Deployment in late 2009, individual equipment upgrade schedule per requirements section, rollout may last up to 10 years.

3 Summary

The Company’s AMI system is expected to have a minimum functional life of fifteen (15) years and be deployed over a three (3) year, or shorter, period. The AMI system should be capable of supporting:

• All customer segments and meters per Appendix F - AMI Segments.

• Replacing and/or retrofitting the Company’s existing population of electric meters and replacing and/or retrofitting the Company’s existing population of gas meters as defined in Appendix G - Existing Meter Population.

• Supporting all Technical and Engineering Meter/Module Specifications as defined in Appendix J – Technical and Engineering Meter Specifications.

• Supporting all current Company tariffs as defined in Appendix I - Existing Tariffs.

• Supporting all future tariffs as defined in the system information requirements.

• Supporting outage and restoration detection and notification as defined in the functional requirements.

• Supporting the information needs of Billing, Customer Service, Field and Meter Services, and Dispatch and Operations as defined in the functional requirements.

• Supporting integration with the Company’s existing and future Information Technology systems as defined in the functional requirements.

• Bidders are instructed to provide a total solution that does not rely on any existing Company AMI or communications infrastructure. Bidders may optionally provide details regarding potential synergies with existing Company AMI or communications infrastructure.

4 Company AMI and OpEx 20 /20 Techno logy Exper ience

Bidder shall provide detailed answers to the following questions:

4.1 Describe your company’s experience in the AMI and OpEx 20/20 fields, as appropriate.

Please respond here.


5


4.2 Provide a list of your installations for utilities in North America. For each project, provide details of utility, number of endpoints covered contractually (breakdown by electric, gas and water endpoints, SCADA, etc.), number of these endpoints actually deployed to date, type of AMI and OpEx 20/20 technology, as appropriate, used, whether the project is a pilot/trial or in production mode.


4.3 Provide at least three (3) references for AMI and OpEx 20/20 projects, as appropriate, where your company’s technology has been used in North America. Provide a contact at the utility, all relevant contact information, and a concise description for each project (including start and end dates).


5 Product /Serv ice H is tory and S t ra tegy


5.1 Describe the AMI and OpEx 20/20 products and services, as appropriate, your company offers and the estimated percentage of total company revenues for each product/service. For each product/service indicate if commercialized, how many years in production and, if not commercialized, when your company expects to bring the technology to market.


5.2 Provide a history for the past five years for units ordered, units delivered, units returned for warranty and overall failure rate for all the products comprising the proposed AMI System (end points, network equipment, data collection hardware, etc.). If also bidding OpEx 20/20 communications infrastructure provide a history for the past five years of similar deployments. Please cite availability and reliability of deployed infrastructure.


5.3 Describe your product strategy and product plan for the next three years. Highlight any planned evolutions of current technology and provide a description of how future and current technologies will maintain compatibility and interoperability within your system. If bidding AMI and OpEx 20/20 please provide a response for each set of applications.



6


5.4 Do you have a User’s Group? How often does the User’s Group meet? How does the User’s Group provide formal input to product development/enhancement and track resulting developments?


5.5 What alliances does your company have to complement your product/service offering? Provide a list of these alliances and indicate the partner company, nature of alliance (joint venture, joint sales and marketing relationship, distributor, joint product development, licensing, etc.), years in place, joint projects completed/underway, and how the Company may benefit from such an alliance. Ensure relationships highlighted include all relevant aspects of this Company’s AMI and OpEx 20/20 initiatives, as appropriate, including, but necessarily limited to, meters, public/private communications networks, data collection, meter data management systems, system integration, and total program management or primes. Cite where alliances have been used in actual programs and provide utility references for programs cited.


5.6 If your company has utilized the proposed AMI technology in pre-payment applications describe your experience, the number of customers participating in each segment including drop-out rates, utilities where installed and reference contact information (include name, title, phone number of contacts), equipment failure rates, expected benefits, verified energy savings, utility override capability, reports on customer experience, security issues, and political reaction.


5.7 If your company has utilized the proposed AMI and/or OpEx 20/20 technology in Demand Response (DR) programs you should also provide the following information:

5.7.1 Identify the US States that the proposed meter/system has been demonstrated to facilitate DR program(s) and describe the program(s), control application(s) used, device(s) controlled and the benefit(s) of the meter/system in facilitating load reduction and response.


5.7.2 For the DR program(s) described above, identify the number and percentage of participating customers in each of the three market segments (residential, small commercial < 200kW and large commercial/industrial > 200kW), description of participant and/or utility override capability, program manager name and contact information (include title, phone number, e-mail address and company


7


name), actual energy savings (kWh), capacity savings (kW) and expected benefits. Break out each DR program separately.


5.7.3 Where consumption data was provided to the customer, describe the display device, message or signal sent and method of communication (through the meter/system or wirelessly). Also identify the time delay (15 minute, 1-hour or next day) in providing this data and the associated cost.


6 Approach , Methodology and Capaci ty to Del iver


6.1 Describe your project management and solution delivery methodology and processes required to meet the Company’s AMI and OpEx 20/20 project needs and schedule. Provide your recommended approach and solution by application (AMI, OpEx 20/20) and segment.


6.2 Compare the Company’s AMI and OpEx 20/20 System production requirements (product, service and manpower) for all full service territory implementation to your company’s existing deployments and capacity, and explain your company’s plan to meet the Company’s needs.


6.3 Describe the production ramp up process for delivery of the AMI and OpEx 20/20 system and discuss any issues that could negatively or positively impact the delivery schedule for the proposed full service territory implementation. Provide a proposed implementation plan that will meet the Company’s requirements and schedule.


7 AMI and OpEx 20 /20 System In fo rmat ion Requ irements

This section identifies the minimum requirements that any AMI Technology must meet to be considered for the Company deployment. The Company will place value on performance exceeding the minimal requirements in its evaluation of Responses. It is anticipated that multiple technologies could be required to meet the economic and technical requirements, therefore, the preferred solutions will demonstrate an open architecture capable of supporting existing and future products from multiple suppliers. The AMI system requirements are as follows:


8


7.1 System Information Requirements. See Appendix F - AMI Segments for exceptions to the following general information requirements for certain segments.

7.1.1 Electric Metering ApplicationsElectric days are defined as twenty-four (24) hour periods from 12:00 AM Midnight of one day, to 12:00 AM Midnight of the subsequent day. All data requirements shall deliver complete electric day data (from the previous day), unless otherwise specified. All consumption, demand, time-of-use, and interval, data delivered shall have sufficient resolution (e.g. 5 Wh) to meet ANSI C12.20 accuracy for any data provided (e.g. a single hour interval).

Bidders must respond to section 7.1.1 from the perspective of the complete AMI system bid. Responses must be given relative to the electricity metering products proposed. Failure to propose integrated electricity metering products, or failure to provide a response inclusive of the electricity metering products, shall be deemed non-compliant by the Company.

7.1.1.1 Cumulative Total Consumption (kWh).7.1.1.1.1 Daily. A minimum of 98.5% of all prior electric day

consumption data for 98.5% of all meters by 8:00 AM of the next day. Minimum cumulative of 99.5% of all consumption data for 99.5% of all meters within three (3) days.


7.1.1.1.1.1 Daily (OPTIONAL). A minimum of 99.5% of all prior electric day consumption data, for 99.5% of all meters, by 8:00 AM of the next day.


7.1.1.1.2 Other. Bidder should provide details on any other reading capabilities by percentage of available meter population with accuracy percentage by data availability.


7.1.1.2 Demand (kW). Support for fifteen (15) minute block, and optionally five (5), fifteen (15), thirty (30) and sixty (60) minute block and rolling demand interval periods.



9


7.1.1.2.1 Per Billing Cycle. A minimum of 98.5% of all billing cycle peak demands as well as date and time of peak for 98.5% of all demand meters by 8:00 AM of the billing day. Minimum cumulative of 99.5% of billing cycle demand peaks for 99.5% of all meters within three (3) days. Billing cycle peak average demand shall be reset following successful billing cycle read.


7.1.1.2.1.1 Per Billing Cycle (OPTIONAL). A minimum of 99.5% of all billing cycle peak demands as well as date and time of peak for 99.5% of all demand meters by 8:00 AM of the billing day. Billing cycle peak average demand shall be reset following successful billing cycle read.


7.1.1.2.2 Accuracy. Time accuracy of demand period to less than one (1) minute of NIST synchronized to on the hour.


7.1.1.2.3 Programmability. Ability to change demand interval length and demand calculation method by individual meter, or batch of meters, remotely within eight (8) hours of initiation by system. Current demand must be retained if demand reprogramming occurs prior to a demand reset.


7.1.1.3 Coincident Demand. Support for Power Factor/kVAR measurement at kW demand peak.


7.1.1.3.1 Per Billing Cycle. A minimum of 98.5% of all billing cycle coincident demands for 98.5% of all coincident demand meters by 8:00 AM of the billing day. Minimum cumulative of 99.5% of billing cycle coincident demand peaks for 99.5% of all meters


10


within three (3) days. Billing cycle coincident demand shall be reset following successful read.


7.1.1.3.1.1 Per Billing Cycle (OPTIONAL). A minimum of 99.5% of all billing cycle coincident demands for 99.5% of all coincident demand meters by 8:00 AM of the billing day. Billing cycle coincident demand shall be reset following successful read.




7.1.1.3.3 Programmability. Ability to change demand interval length and demand calculation method by individual meter, or batch of meters, remotely within eight (8) hours of initiation by system. Current demand must be retained if demand reprogramming occurs prior to a demand reset.


7.1.1.4 Interval Data. Support for fifteen (15) and sixty (60) minute interval data for recording for a minimum of one (1) channel for electric residential, and support for five (5), fifteen (15), thirty (30), and sixty (60) minute interval data recording for a minimum of four (4) channels for electric commercial and industrial meters.


7.1.1.4.1 Daily. Minimum of 98.5% of all prior electric day interval data for 98.5% of all meters by 8:00 AM of the next day. Minimum cumulative of 99.5% of all interval data for 99.5% of all meters within three (3) days.


7.1.1.4.1.1 Daily (OPTIONAL). A minimum of 99.5% of all prior electric day interval


11


data for 99.5% of all meters by 8:00 AM of the next day.


7.1.1.4.2 Hourly (OPTIONAL ). A minimum of 98.5% of all prior interval data for 2% of all commercial & industrial meters within one (1) hour of the consumption (e.g. interval data from 1pm to 2pm shall be delivered no later than 3pm of the same day).


7.1.1.4.3 15 Minute (OPTIONAL ). A minimum of 98.5% of all prior 15 minute interval data for 1% of all commercial & industrial meters within 15 minutes of the consumption (e.g. 15 minute interval data from 1pm to 1:15pm shall be delivered no later than 1:30pm of the same day).


7.1.1.4.4 5 Minute (OPTIONAL ). A minimum of 98.5% of all 5 minute interval data for no more than 1000 meters of the total commercial and industrial interval data meter population within 5 minutes of the consumption (e.g. 5 minute interval data from 1pm to 1:05pm shall be delivered no later than 1:10pm of the same day).


7.1.1.4.5 Accuracy. Time accuracy of interval data to less than one (1) minute of NIST synchronized to on the hour. Less than one percent (1%) allocated data per interval.


7.1.1.4.6 Programmability. Ability to change interval recording channel quantities, interval data delivery frequency, and interval recording length by individual meter, or batch of meters, remotely within eight (8) hours of initiation by system.



12


7.1.1.5 Time-Of-Use (OPTIONAL). Support for four (4) season, four (4) rate, Time-of-Use (TOU) with weekday, weekend, day of week, and holiday day types with a minimum of eight (8) switch points per day at a minimum of fifteen (15) minute resolution.


7.1.1.5.1 Daily. A minimum of 98.5% of all prior electric day TOU data for 98.5% of all meters by 8:00 AM of the next day. Minimum cumulative of 99.5% of all TOU data for 99.5% of all meters within three (3) days.


7.1.1.5.1.1 Daily (OPTIONAL). A minimum of 99.5% of all prior electric day TOU data for 99.5% of all meters by 8:00 AM of the next day.




7.1.1.5.3 Programmability. Ability to program TOU calendars including seasons, day types, and daily schedules by individual meter, or batch of meters, remotely within eight (8) hours of initiation by system. The calendar shall be capable of accommodating leap years, daylight saving time changes, and recurring holidays.


7.1.1.6 Bi-Directional Metering. Support for measurement and collection of delivered and received energy consumption, demand, coincident demand, interval data, and TOU per requirements, 7.1.1.1 through 7.1.1.5 for all commercial and industrial meters.


7.1.1.6.1 Bi-Directional Metering (OPTIONAL). Support for measurement and collection of delivered and received energy consumption, interval data, and


13


TOU per requirements 7.1.1.1 7.1.1.4, and 7.1.1.5 for all residential meters.


7.1.1.7 Net Metering. Support for measurement and collection of net energy consumption, interval data, and TOU per requirements 7.1.1.1, 7.1.1.4, and 7.1.1.5 by means of delivered minus received bi-directionally metered quantities of 7.1.1.6 for all residential meters.


7.1.1.8 Virtual Metering. Support for the creation of virtual meters consisting of arbitrary aggregations (sums and differences) of physical meters, and for each, the capability to provide consumption, demand, coincident demand, interval data, and TOU per requirements 7.1.1.1 through 7.1.1.5 for all meters.


7.1.1.9 Reactive Energy (OPTIONAL). Support for measurement and collection of reactive energy (kVAR) consumption, demand, coincident demand, interval data, and TOU per requirements 7.1.1.1 through 7.1.1.5 for the commercial and industrial meters.


7.1.1.9.1 Programmability. Ability to configure commercial and industrial meters for reactive measurement by meter, or batch of meters, remotely within eight (8) hours of initiation by system.


7.1.1.10 Apparent Energy (OPTIONAL). Support for measurement and collection of apparent energy (kVA) consumption, demand, coincident demand, interval data, and TOU per requirements 7.1.1.1 through 7.1.1.5 for all commercial and industrial meters. Bidder shall provide apparent energy measurement methods supported.


7.1.1.10.1 Programmability. Ability to configure commercial and industrial meters for apparent measurement by meter, or batch of meters, remotely within eight (8) hours of initiation by system.


14



7.1.1.11 On-Cycle Reading. The system shall support assignment of entire meter population across pre-defined billing cycles (nominally 21 per month). All on-cycle billing data must be available by 8:00 AM on the actual bill day.


7.1.1.12 Off-Cycle Reading. The system, in addition to On-Cycle Reading, shall support the reading of up to 10% of the total meter population by segment via a daily off-cycle request. The off-cycle request must be initiated by 6:00 PM of the prior day. 99.5% of all off-cycle data must be available for 99.5% of all meters by segment within one (1) day of the request.


7.1.1.13 On-Demand Data. Support remotely initiated request for any available meter and system data.

7.1.1.13.1 Energized Meter Verification. Response of system request initiation, by individual meter, or batch of meters, of line side meter status. System to timestamp requests and responses and calculate elapsed durations. Bidder should provide, by segment, performance of energized meter verification. At a minimum this performance should include response time for a given volume of requests including nominal and worst-case scenarios. For failed verifications, reason, if available, should be provided for failure including the identification of the any system elements that could be the cause of failed verifications (e.g. communications equipment).


7.1.1.13.1.1The System shall respond to on-demand energized meter verification requests in less than 30 seconds for simultaneous requests of 100 or fewer meters.


7.1.1.13.2 On-Request Data Read. Response of system request, by individual meter or batch of meters, of


15


any available meter registers (consumption, demand, coincident demand, specific data, specific day interval data, meter/system status, etc.). System to timestamp requests and responses and calculate elapsed durations. Bidder shall provide, by segment, performance of on-request data read. At a minimum this performance should include response time for a given volume of requests including nominal, and worst-case scenarios. For failed verifications, reason, if available, should be provided for failure including the identification of the any system elements that could be the cause of the failure (e.g. communications equipment).


7.1.1.13.2.1The System shall respond to on-demand meter read requests (any data) in less than 60 seconds for simultaneous requests of 10 or fewer meters. For consumption requests only, the system shall respond in less than 60 seconds for 100 or fewer meters.


7.1.1.14 Power Outage Notification. The system shall detect, timestamp, and report the loss of power. Loss of power is defined as the reduction of line-side voltage of 40% or more of nominal voltage for a programmable number of continuous seconds (nominally 60 seconds). Outage detection notification for each meter, by segment, should be available from the system head-end within the prescribed post detection latency and reliability. Latency is defined as the time between the identification of the actual power outage at the meter and when the head-end receives the notification. Reliability is stated as a percentage of total meter population within the segment.


7.1.1.14.1 Single Customer Outage (Single No-light Secondary Outage). Latency of less than one (1) minute with a reliability of 99.5% or better.



16


7.1.1.14.2 Multiple Customer (Less Than Ten (10)) Secondary Restoration or Single Transformer Restoration. Latency of less than one (1) minute with a reliability of 99.5% or better.


7.1.1.14.3 Small Scale Outage (Multiple Transformer Primary Outage). Latency of less than one (1) minute with a reliability of 95% or better for a simultaneous outage of ten (10) to one hundred (100) customers.


7.1.1.14.4 Medium Scale Outage (Primary Outage). Latency of less than two (2) minutes with a reliability of 80% or better for a simultaneous outage of one hundred one (101) to five hundred (500) customers.


7.1.1.14.5 Large Scale Outage (Primary Outage). Latency of less than five (5) minutes with a reliability of 60% or better for a simultaneous outage of greater than five hundred (500) customers.


7.1.1.14.6 Time Recording. System shall date and time stamp detection of outage at meter and shall date and time stamp availability of outage report at system head end.


7.1.1.14.7 Outage Filtering. System should be capable of providing programmatic filters for sustained outages defined as outages exceeding five (5) minutes in duration, and momentary outages, voltage flicker, or recloser cycling defined as outages less than five (5) minutes in duration.


7.1.1.14.8 Reporting. Reporting is on event, by customer, upon duration threshold excursion.



17


7.1.1.15 Momentary Interruption Count. The system should have the capability to capture and maintain a count of momentary outages. Momentary outages are defined as a reduction of line-side voltage of 40% or less of nominal for duration of five (5) minutes or less as defined by the Company. Momentary interruption counts should be reported during on-cycle billing or daily reads as defined above.


7.1.1.16 Voltage Event Monitoring and Reporting (OPTIONAL). The system should be capable of monitoring, detecting, date and time stamping, and reporting all line-side voltage reduction events in addition to outages including transients, momentaries, and optionally voltage deviations such as sags and swells the duration and magnitude (if applicable) which are defined by remotely programmable thresholds. Reporting should support on event and upon daily reading. If programmable thresholds are not available, the system shall record maximum and minimum voltage values during each reported interval.


7.1.1.17 Power Restoration Notification. The system shall detect, timestamp and report the restoration of power. Restoration of power is defined as the presence of line-side voltage within 60% or more of nominal for more than a programmable number of continuous seconds (nominally sixty (60) seconds) following a power outage. Restoration detection notification for each meter should be available from the system head-end within the prescribed post detection latency (less Company defined programmable delay to minimize false reporting and data collisions) and reliability where reliability is stated as a percentage of total meter population within the segment.


7.1.1.17.1 Single Customer to Restoration. Latency of less than two (2) minutes with a reliability of 99.5% or better.


7.1.1.17.2 Multiple Customer (Less than 10) Secondary Restoration or Single Transformer Restoration. Latency of less than two (2) minutes with a reliability of 99.5% or better.


18



7.1.1.17.3 Small Scale Restoration (Primary Outage). Latency of less than two (2) minutes with a reliability of 98% or better for a simultaneous outage of ten (10) to one hundred (100) customers.


7.1.1.17.4 Primary Outage Restoration (greater than 100 customers). Reliability of 50% within the first five (5) minutes, 75% within the first fifteen (15) minutes, and 99.5% or better within thirty (30) minutes.


7.1.1.17.5 Large Scale Restoration (Primary Outage). latency of less than fifteen (15) minutes with a reliability of 90% or better for a simultaneous outage of greater than five hundred (500) customers.

7.1.1.17.6 Time Recording. System shall date and time stamp detection of restoration at meter as well as date and time stamp reporting of restoration at system head end.


7.1.1.17.7 Reporting. Reporting is on event, by customer, upon duration threshold excursion.


7.1.1.18 Revenue Integrity Monitoring. The system shall monitor the load and metering equipment, make available status of all such monitoring via alarm/event message initiation and/or on-demand reads, and programmatically report abnormal conditions indicative of potential revenue loss via equipment failure or energy diversion as follows.

7.1.1.18.1 Reverse Energy. The system shall detect reverse power flow on a meter programmed or operating as a non-net energy meter or non-bidirectional energy meter.


7.1.1.18.2 Voltage Deviation. The system shall detect line-side RMS voltage deviations beyond a


19


programmable threshold including single potential loss in a meter.


7.1.1.18.3 Reverse Energy plus Outage (OPTIONAL). The system should detect reverse energy flow immediately following a power outage indicating single phase meter inversion.


7.1.1.18.4 Physical Tilt (OPTIONAL). The system should detect physical inversion of meters.


7.1.1.18.5 Magnetic Tamper (OPTIONAL). The system should detect the presence of strong magnetic fields indicative of electromechanical meter tampering.


7.1.1.18.6 Polyphase Voltages and Currents. The system shall monitor voltage, current, per phase and phase angles to detect incorrect polarity per phase or incorrect phase sequencing on polyphase meters.


7.1.1.18.7 Polyphase Direct Current and Harmonics (OPTIONAL). The system should monitor the presence of DC or total harmonic distortion is in excess of programmable thresholds in polyphase meters.


7.1.1.18.8 Other. Bidder should describe any other revenue integrity functionality supported by their proposed system, including, but not limited to, any self diagnostic errors identified within the meter and communications equipment.



20


7.1.1.18.9 Reporting. Shall be on event, by customer upon threshold excursion or daily summary reporting via scheduled reads.


7.1.1.18.10 On-Demand. All monitoring activities shall be available via on-demand data as defined in 7.1.1.13.


7.1.1.18.11 Programmability. Ability to change monitoring properties and event reporting thresholds by individual meter, or batch of meters, remotely within one (1) hour of initiation by system.


7.1.1.19 Remote Disconnect and Reconnect (OPTIONAL ). The system should support remote disconnect and reconnect by individual meter, or batch of meters, for the total residential meter population, within sixty (60) seconds of initiation by system. In addition, the system shall support the setting of load limiting parameters (levels and times) and the remote activation/deactivation of demand threshold limits resulting in operation of the remote disconnect within individual residential meters without further communication to the meter.


7.1.2 Gas7.1.2.1 Cumulative Total Volume.

7.1.2.1.1 Daily. A minimum of 98.5% of all cumulative volume data for 98.5% of all gas meters by 8:00 AM of the next day. Minimum cumulative of 99.5% of all cumulative volume data for 99.5% of all meters within three (3) days.


7.1.2.1.2 Daily (OPTIONAL). A minimum of 99.5% of all cumulative volume data for 99.5% all gas meters by 8:00 AM of the next day.



21


7.1.2.1.3 Other. Bidder should provide details on any other reading capabilities by percentage of available meter population with accuracy percentage by data availability.


7.1.2.2 Interval Data (OPTIONAL). Support for five (5), fifteen (15), thirty (30), and sixty (60) minute recording for maximum of one (1) channel for gas residential meters, and two (2) channels for gas commercial and industrial meters.


7.1.2.2.1 Per Billing Cycle. 99.5% of all billing cycle interval data for 99.5% of all gas meters by 8:00 AM of the billing day.


7.1.2.2.2 Daily. 99.5% of all prior day interval data for 99.5% of all gas meters by 10:00 AM of the next day.


7.1.2.2.3 Accuracy. Time accuracy of interval data to less than one (1) minute of NIST synchronized to on the hour. Less than one percent (1%) missing or estimated data per interval.


7.1.2.2.4 Programmability. Ability to change interval recording channel quantities and interval recording length by individual meter, or batch of meters, remotely within eight (8) hours of initiation by system.


7.1.2.3 Virtual Metering. Support for the creation of virtual meters consisting of arbitrary aggregations (sums and differences) of physical meters, and for each, the capability to provide cumulative volume and interval data per requirements 7.1.2.1 through 7.1.2.2.



22


7.1.2.4 Corrected Consumption. The system shall support corrected gas consumption where correctors are utilized. See Appendix G - Existing Meter Population for details of the correctors currently in use by Company.


7.1.2.4.1 Uncorrected Consumption (OPTIONAL). The system should support uncorrected, in addition to corrected, consumption where correctors are utilized. See Appendix G - Existing Meter Population for details of the correctors currently in use by Company.


7.1.2.5 On-Cycle Reading. The system shall support assignment of entire meter population across pre-defined billing cycles (nominally twenty one (21) per month). All on-cycle billing data must be available by 8:00 AM on the actual bill day.


7.1.2.6 Off-Cycle Reading. The system, in addition to On-Cycle Reading, shall support the reading of up to 10% of the total meter population by segment via a daily off-cycle request. The off-cycle request must be initiated by 6:00 PM of the prior day. 99.5% of all off-cycle data must be available for 99.5% of all meters by segment within one (1) day of the request.


7.1.2.7 On-Request Data Read (OPTIONAL). Response of system request, by individual meter or batch of meters, of any available meter register (consumption, specific day interval data, meter/system status, etc.). System to timestamp requests and responses and calculate elapsed durations. Bidder should provide, by segment, performance of on-request data read. At a minimum this performance should include response time for a given volume of requests including nominal and worst-case scenarios. For failed verifications, reason, if available, should be provided for failure including the identification of the any system elements that could be the cause of the failure (e.g. communications equipment).



23


7.1.2.8 Revenue Integrity Monitoring (OPTIONAL). The system should monitor the consumption and metering equipment for abnormal load conditions indicative of potential revenue loss via equipment failure or energy diversion. Bidder should describe revenue integrity functionality supported by their proposed system.


7.1.2.8.1 Physical Tilt. The system should detect an attempt at removing the device and or an attempt to change the orientation of the gas meter. See Appendix J - Technical and Engineering Meter Specifications for restrictions on the use of hazardous materials, such as mercury, that might be utilized in tilt switch technology.


7.1.2.8.2 Magnetic Tamper. The system should detect the presence of strong magnetic fields indicative of electromechanical meter tampering.


7.1.2.8.3 Battery Alarm. The system should detect imminent battery failure.


7.1.2.8.4 High/Low Flow Alarm. The system should detect high and low flow conditions.


7.1.2.8.5 Other. Bidder should describe any other revenue integrity functionality supported by their proposed system, including, but not limited to, any self diagnostic errors identified within the meter and communications equipment.


7.1.2.8.6 Reporting. Reporting is on event, by customer, upon threshold excursion or summary reporting daily via scheduled reads.



24


7.1.2.8.7 Programmability. Ability to change monitoring properties and event reporting thresholds by individual meter, or batch of meters, remotely within one (1) hour of initiation by system.


7.1.3 Water (OPTIONAL). Bidder should provide details regarding their abilities to support water meter reading per the requirements of 7.1.2 (with the exception of 7.1.2.4).


7.1.4 Utility Home Area Networking (HAN). The system must provide two-way HAN communications from the meter into the home/premise. The Utility HAN must support communications from the meter into the home/premise independently of the communications from the meter to the Company (e.g. meter may provide hourly interval data daily from the meter to the Company, however, must be able to simultaneously support functionality as defined in section 7.1.4.3). The Utility HAN must also support pass-through communications from the Company into the home/premise. Utility HAN communications must be based on a non-proprietary, open, industry standard protocol and hardware interface.


7.1.4.1 Certification Compliance. All network communications equipment must comply with FCC Regulations and documentation demonstrating said compliance should be included in Bidder’s Response. Please refer to Appendix GG - Documentation for summary of documentation requirements.


7.1.4.1.1 Industrial Compliance. Bidder shall provide all documentation to the company regarding product compliance standards. The Company may, if desired, request additional compliance from the Bidder.


7.1.4.1.2 Interoperability. Bidder shall provide all existing certification documentation to the Company regarding HAN interoperability.



25


7.1.4.2 Operating Environment. The Utility HAN must be able to operate reliably in the environments typical of Southern California construction. This will include residential single-family homes, residential multi-family homes, residential high-rise condominiums/apartments/hotels, and small, medium and large commercial and industrial buildings.


7.1.4.2.1 Bidder shall specifically describe how the Utility HAN will successfully communicate in the following environments:

7.1.4.2.1.1 Residential multi-family premises where electric meters are located in a meter closet and not in close proximity to the premise.


7.1.4.2.1.2 Residential high-rise condominiums where electric meters are located on the ground floor or basement and premises are up to 20 stories above.


7.1.4.2.1.3 Small, medium and large commercial and industrial buildings where electric meters are located outside of building inside metal meter cabinets.


7.1.4.2.1.3.1 Large, multi-building campuses where a central electric meter is located inside a metal cabinet outside a single building.


7.1.4.2.1.3.2 Residential, single-family homes with multiple building materials and the meter is located on a metal panel box on an exterior


26


facing wall. Building materials may include, but not be limited to metal or wood framing, plaster on metal lathe, stucco on wire mesh, aluminum foil backed insulation, etc. (see existing, new and proposed California Building Codes for types of building construction).


7.1.4.2.1.3.3 If the consumer premise supplies its own HAN, describe how the Utility HAN will securely join the Consumer HAN communication technology.


7.1.4.2.1.3.4 For a building with an energy management system (EMS) (Johnson Controls, Siemens, BACNet, Honeywell, etc.) describe how the AMI communication network will interface with and connect to the EMS.


7.1.4.2.1.4 Company prefers a single type communication Utility HAN between the AMI communication network and the customer premise. If more than one Utility HAN technology is recommended by the bidder in 7.1.4.2.1, provide details on AMI communication network to Utility HAN


27


hardware interoperability for multiple communication device standards:


7.1.4.2.1.4.1 Describe how closely proposed solution complies with CEC Demand Response reference design for the Utility HAN.


7.1.4.2.1.4.2 Describe how the AMI communication network to Utility HAN communication technology is standardized between AMI system and Utility HAN types.


7.1.4.3 In Premise Communications. The Utility HAN must provide real time usage information (instantaneous demand and total consumption) within two (2) seconds of a change in instantaneous demand or consumption. The resolution of the change information that is transmitted should be configurable but typically transmitted as 1/10th of a kilowatt demand or 1/10th of a kilowatt-hour total consumption. This capability should be able to be activated and deactivated based on a customer’s ability to make use of this information.


7.1.4.4 Programmable Communicating Thermostat (PCT). The system must support in-premise load control via thermostat control by premise or batch, within one hundred twenty (120) seconds of initiation by system. Visual indication of temperature set-backs and/or load control with option for customer rejection. Multiple thermostats per premise should be supported and uniquely addressable. Bidder should describe their supported functionality and products (including any third party compatible products) and the scalability of their proposed solution to support thermostat control devices, and provide the performance criteria by which these devices would operate


28


(percent of total devices acknowledged activated within time latency for acknowledged activation). At a minimum, 57,000 PCTs will be required for the initial AMI deployment for small and medium commercial and industrial customers.


7.1.4.5 Programmable Communicating Thermostat (PCT) Capabilities. Refer to Appendix II – CEC PCT for the CEC “Reference Design for Programmable Communicating Thermostats Compliant with Title 24-2008” requirements. In addition:


7.1.4.5.1 The Company does not require the one-way default communications as described in the Reference Design Section 1.1 (of CEC “Reference Design for Programmable Communicating Thermostats Compliant with Title 24-2008”) – “PCTs shall provide a non-removable communications capability that is compatible with the default statewide Demand Response (DR) communications system (to be determined). The default communications system will be one-way, whereby utilities issue messages to PCTs. Utilities shall use the default communications system to notify customer PCTs about price events and emergency events.”


7.1.4.5.2 The PCT shall be capable of receiving and responding to price and emergency signals from the Company.


7.1.4.5.3 The communication module shall be activated by the Company at the time of customer enrollment in an appropriate utility program.


7.1.4.5.4 The PCT shall have two-way communications capability utilizing the same open, industry standard Utility HAN communications described in Section 7.1.4. The two-way communications hardware may be either built in to the PCT or supplied as a


29


separate and removable module. All thermostat functionality shall be disabled when such a removable communications module is removed from an already activated PCT.


7.1.4.5.5 A PCT that is equipped with built-in communication hardware shall be distributed with the default communication device and thermostat functionality disabled until enabled by installer or end customer at time of installation.


7.1.4.5.6 The PCT shall have two separate default offsets, one for emergency events, and one for price events.


7.1.4.5.7 The vendor must describe their method for PCT activation.


7.1.4.5.8 The PCT must be able to send back a heartbeat at least daily to the Company or respond to a query from the Company to indicate it is still functioning properly.


7.1.4.5.9 Emergency Events. Upon receiving an emergency signal, the PCT shall be able to adjust the set point by the number of degrees specified in the PCT default emergency offset of four (4) degrees (up in cooling mode and down in heating mode) for the duration of time specified in the signal. The PCT shall also be capable of responding to alternative commands contained in the emergency signal, including changing the offset by any number of degrees or to a specific temperature set point. The PCT shall not allow the customer to change thermostat settings during emergency events except for customers who file for medical exemption with the controlling utility. The PCT shall send a message back to the Company confirming that the


30


signal was received and the desired action performed.


7.1.4.5.10 Price Events. Price signals will contain information on event timing and duration. Upon receiving a price signal, the PCT shall be able to adjust the thermostat set point by four (4) degrees Fahrenheit (up in cooling mode and down in heating mode) for the duration of time specified in the signal. The PCT shall allow the customer to change the default price offset and thermostat settings at any time, including during price events (override). The PCT shall send a message back to the Company confirming that the signal was received and the desired action performed. If the customer overrides the price event, the PCT shall send a message back to the Company indicating so.


7.1.4.6 Host Application. The bidder shall provide a Host application to enable Utility originated PCT functionality.


7.1.4.6.1 Scalability/Expandability. Bidder shall provide/describe the scalability/expandability of the Host to meet the future PCT and other additional applications, such as smart appliances.


7.1.4.7 Security. Bidder must demonstrate that the proposed Utility HAN supports the security provisions of Section 7.2.12 and must meet all IT requirements as detailed in Appendix U – IT Questionnaire.


7.1.4.7.1 Bidder must describe how to protect the AMI communication network from HAN (Utility and/or Consumer) security threats.


7.1.4.7.2 Bidder must describe how to provide future software/firmware upgrades to the Utility HAN.


31



7.1.4.7.3 Bidder must describe how to provision, monitor and maintain security components of the Utility HAN that interface with AMI.


7.1.4.7.3.1 Describe for Utility HAN.


7.1.4.7.3.2 Describe for Consumer HAN.


7.1.4.8 PCT and Utility HAN Security: Describe Bidder’s experience with deploying a secure Utility HAN with PCT devices connected to an AMI network.

7.1.4.8.1 Describe how to maintain confidentiality, integrity, availability and authenticity between all of these components that will be integrated together (i.e. Utility HAN, PCT Devices, Meter Devices, AMI network, and Head-end). Please address each of the following security controls and how the integration of the Utility HAN and PCT devices will impact the proposed security architecture of the AMI network:


7.1.4.8.1.1 Describe how end-to-end authentication is initiated, maintained, and validated throughout the network. Describe any established trust relationships between devices on the network.


7.1.4.8.1.2 Describe any support of encryption of data in transit and at rest in the device. Describe encryption algorithm support and key management (i.e. location of keys, changing of keys, strength of keys, etc).



32


7.1.4.8.1.3 Describe where security logs are created and maintained. What attributes are captured as part of the logs?


7.1.4.8.1.4 Describe how sessions are managed to prevent replay attacks.


7.1.4.8.1.5 Describe any reliance on proprietary technology for security and how that technology is an adequate replacement of standard security controls.


7.1.4.8.2 Describe any vulnerability/security testing that has been performed for the proposed Utility HAN and PCT devices.


7.1.4.9 Gas Module (OPTIONAL). Bidder should provide details regarding their abilities to support Utility HAN communication with gas modules that meet the requirements detailed in Sections 7.1.2 and 7.4.3.


7.1.4.10 Water Module (OPTIONAL). Bidder should provide details regarding their abilities to support Utility HAN communication with water modules that meet the requirements detailed in Section 7.1.2.


7.1.4.11 In-Premise Load Control (OPTIONAL). The system should support in-premise control of loads such as, but not limited to, pool-pump, water heater, air conditioner, clothes washing machine and/or dryer, dish washer, etc. Control applications should include, but not be limited to, air conditioner cycling or compressor shut down, pool pump shut down, delayed startup or pump rate reduction, heating element shutoff for dryer, dishwasher, water heater, etc. Control methods should either be through a central in-premise control device, direct access,


33


circuit control or a combination of all, within one hundred twenty (120) seconds of initiation by the system. Controlled loads can be configured at the utility. The system may control some, all or none of the controllable loads. Bidder should describe their currently supported functionality and products (including any third party compatible products), and the scalability of their proposed solution to support in-premise load control devices, and provide the performance criteria by which these devices would operate (percent of total devices acknowledged activated within time latency for acknowledged activation).


7.1.4.12 In-Premise Displays (OPTIONAL). The system should support in-premise displays for customer communication. The Company anticipates the types of communications could include, but not be limited to, critical peak pricing events, energy rates, outages, energy costs and consumption, and other critical non-utility communications. Other types of communications could include user overrides of load control signals, election into Company offered demand response or energy efficiency programs. Bidder should define the time lag between consumption and display, describe their supported functionality and products (including any third party compatible products) and the scalability of their proposed solution to support in-premise display devices. Provide the performance criteria by which these devices would operate (amount of data communicated with acknowledgement to percent of total devices within time latency for acknowledged communications).


7.1.5 Pre-Payment (OPTIONAL). The system should support pre-payment for energy whereby customers pay for the electricity prior to use, and service may be disconnected upon the exhaustion of credit. The system should also permit the utility to override the service disconnect and/or reconnect remotely upon receipt of an additional prepaid funds. Prepaid meters must integrate with the AMI system and satisfy all other AMI requirements herein. The system must provide an in-premise display as described in 7.1.5.2 The pre-payment process of how a customer purchases the credit should be described in sufficient detail as to demonstrate that the service would not increase customer dependence on utility payment offices and that functionality would work for both cash paying customers and customers paying electronically. Describe, in sufficient detail, the entire product offering, including any and all supported functionality (including any third party compatible products), the expected


34


benefits of the system, the scalability of the proposed prepaid solution, and performance criteria for the system.

Please respond here

7.1.5.1 Pre-Payment System. Identify any unique processes beyond those of the basic AMI installation required for the installation of the entire pre-payment system. Also identify the addition of any pre-payment functionality to standard AMI devices. Bidders proposing pre-payment capabilities must identify all unique devices in Section 7.2 below.


7.1.5.2 In-Premise Display. Bidder should describe the functionality of the in-premise display, including but not limited to energy consumption and warning alerts, and how the in-premise display will be integrated with cycle billing, tiered energy rates, dynamic rates, and rate changes. The in-premise display should also have the ability to provide pre-paid customers with sufficient notice of when the credit is expected to be exhausted. Describe how the in-premise display will provide this notice, the timing of the notice and the frequency of providing energy consumption information (instantaneous, hourly, daily, etc.).


7.1.6 OpEx 20/20 (OPTIONAL)7.1.6.1 Customer Care.

Key performance indicators for the Company include a focus on providing the highest levels of customer service. As part of this effort, the Company is replacing or upgrading the major platforms that support the Customer Call Centers (CCC). These include the call distributors, computer/telephony interface, voice response units and others. Additionally, the capability of having Customer Service Representatives (CSRs) operate at remote locations will be provisioned.

7.1.6.1.1 Current Environment. The Southern California Gas Company operates two CCCs, one in Redlands and the other in San Dimas. The Company operates a primary CCC at the Century Park facility in San Diego and backup CCC at El Cajon. Only the Company CSRs will be affected by the plan to enable them to work from home. Planning is for approximately 25 to 30% of the Company CSR base to participate.


35


7.1.6.1.2 Scope. The screens viewed by the CSR from remote location will be the same as currently used in the CCC. Therefore the same applications will be accessed from a remote location with minimal change required to the platform. It is anticipated that these remote agents will use a PC based device with soft phone (VOIP) capability to perform their duties. The scope of the requirements under this section is aimed solely at the communications provided between the employee’s home and the Company back-office systems. The primary Company data center is located in Rancho Bernardo. The link is anticipated to be a secure connection over the Internet via wired or wireless links to a fixed residential location.

7.1.6.1.3 Requirements. Company expects one hundred (100) remote CSR’s in 2011 provisioned with the following:


7.1.6.1.3.1 Communications. Full 2-way, high availability Internet access, with sufficient capacity (500kbps estimated) for Voice Over IP (Avaya IP telephony) and back-office systems access within Company service territory as defined in Appendix F – AMI Segments.


7.1.6.1.3.2 Data Rate. Estimated needs of 512kbps, or better, downstream to CSR and 128kbps, or better, upstream from CSR.


7.1.6.1.3.3 Broadcast. Capability to support broadcast of priority notifications downstream to CSR’s.


7.1.6.1.3.4 Interfaces. Ethernet to desktop device within CSR residence/premise.

Please respond here.Confidential material protected pursuant to California Public Utilities Code Section 583, General Order 66-C, and applicable Non Disclosure Agreements

36


7.1.6.2 Field Force MobilityThe goal of the Field Force Mobility initiative is to implement planning, scheduling and routing capabilities to drive improvements in crew utilization and productivity. These capabilities will be applied to all types of field-work including construction, operations, field service, maintenance, disaster response and troubleshooting. Both the Company and the Southern California Gas Company transmission and distribution teams will be impacted. Gas and electric teams are part of the project as are substation and storage activities.

7.1.6.2.1 Current Environment. There are existing field-force mobility systems in place at the Company and the Southern California Gas Company that provide RF transport capability to the utilities. At the Company, there are approximately 400 Mobile Data Terminals (MDT’s) using a data rate of 19.2 kbps. At the Southern California Gas Company, there are approximately 1,500 MDTs operating at 4.8 kbps. These systems are primarily used to dispatch service work orders throughout the territory. The existing service order dispatch platforms at each utility will be retained and are not being replaced as part of this initiative. There are also a few hundred MDTs that require higher throughput operating over commercial systems.

7.1.6.2.2 Scope. The Company envisions that some of the primary applications for this initiative include: work management, mobile dispatching, forecasting and scheduling, GIS, and GPS. Back office and mobile applications as well as the mobile equipment eventually deployed in support of these applications are outside the scope of this solicitation. Communications from the mobile devices to the back office are the only scope of this solicitation.

7.1.6.2.3 Requirements. Company expects approximately two thousand (2,000) remote workforce employees starting late 2007 lasting 3 years provisioned with the following:


7.1.6.2.3.1 Communications. Full 2-way communications to each MDT.



37


7.1.6.2.3.2 Communications Traffic. 2,500 to 3,000 non-customer service work orders per day, and an additional 3,200 “locate and mark” GIS activities.


7.1.6.2.3.3 Communications Sizing. Service work orders expected message sizing of 4 to 12 kilobits. GIS related messaging has yet to be quantified, but is anticipated to potentially result in significant added message sizes. Bidder’s are encourage to provide limits of their capabilities.


7.1.6.2.3.4 Broadcast. Communications system shall support broadcast and multicast message to MDT’s.


7.1.6.2.3.5 Reliability. Routine orders should be in near real time but are not considered mission critical. Restoration work is critical and will require highly reliable throughput capabilities.


7.1.6.2.3.6 Latency. A target turnaround time of less than 7 seconds will help drive user acceptance of the system.


7.1.6.2.3.7 Environment. Primarily in-vehicle, however, Bidder’s are expected to cite all out of vehicle capabilities.


7.1.6.2.3.8 Interfaces. MDT platform remains unspecified. Bidders are expected to provide all supported MDT interfaces.


38



7.1.6.2.3.9 Location. MDTs will be distributed across the 57 locations at SoCalGas and 5 at SDG&E approximately equally. Facilities are as shown in the Appendix H – Distribution Network Details - Facilities. MDT’s will be utilized throughout the Company’s entire service territory.


7.1.6.3 Asset Management: OMS/DMSBeginning in 2009, the Company will deploy sensor technology throughout the electric system as a means of providing advanced outage management and distribution automation functionality. Approximately 170,000 devices will be equipped with communications capability in addition to the metering devices that are part of the AMI system. The Company is currently investigating the actual configuration options for the platforms to be used to enable this automation. Regardless of the application selected, the Company anticipates that all of the equipment shown will communicate with the back office systems and may communicate with other devices in the field.

7.1.6.3.1 Current Environment. The Company has two types of SCADA networks for the electric system: one for the transmission system based on Remote Telemetry Units (RTUs), located at transmission substations and another for the distribution system. Only the distribution system is applicable to these OMS/DMS requirements. The existing distribution SCADA system consists of over 800 RTU’s. Communications is over licensed, 900 MHz MAS frequencies. Some 902 – 928 MHz spread spectrum is used to extend the range of the MAS devices. The system uses either S-Com on DNP3.0. Appendix H – Distribution Network Details – Electric Distribution identifies current locations.

7.1.6.3.2 Scope: The future OMS/DMS systems will be broken down into three primary components as follows:

Sensors : A variety of sensor types will be required for complete system functionality. Each electric system device may require numerous sensor types


39


as well as control capability on selected units. Both embedded and external instrumentation is anticipated. New devices will likely be ordered already equipped while other equipment not nearing the end of lifecycle may be retrofitted. Consolidation of inputs and controls for a single unit may result in the provisioning of a RTU versus the use of discrete communications interfaces. Actual interfaces are not determined.

Application : Back office applications along with client firmware and software will be required. Complete capabilities have not yet been solidified.

Communications : The equipment required to transport data from the communications port on the remote devices to the Company’s back office platform is defined as the communications system.

Only the communications system is within the scope of this document. The communications systems must be capable of multiple types of messages, both sense and control. Bidder’s are requested to provide detailed information regarding the separation of these networks and channels, as well as the Quality of Service (QoS) mechanisms employed to prioritize control traffic over other types of communications. Sensor and application platforms will be procured outside of this solicitation. However, should a Bidder be capable of providing some of this functionality, it should be so identified in the response.

7.1.6.3.3 Capacitor Bank Requirements. The Company expects communications to be provision for 820 switched and 560 fixed capacitor banks as detailed in Appendix H - Distribution Network Details – Electric Distribution – Capacitor Banks. Approximately 25% of the devices shall be automated annually according to the following:


7.1.6.3.3.1 Communications. Two-way capability is required including status and control. Inbound messaging to be event driven, outbound to be interrogation and on-demand.


40



7.1.6.3.3.2 Communications Traffic. Daily interrogations, minimal messaging.


7.1.6.3.3.3 Communications Size. Estimated message size is less then 100 bytes.


7.1.6.3.3.4 Communications Reliability. System needs to be reliable and available but back-up paths are not required. Bidder’s must provide expected reliability and availability.


7.1.6.3.3.5 Interfaces. Communications I/O to capacitor bank controller should be assumed to be serial.


7.1.6.3.3.6 Environment. Outdoor, pole or pad mounted.


7.1.6.3.4 Regulator Requirements. The Company employs on hundred and twenty-seven (127) regulators on the system per Appendix H – Distribution Network Details – Electric Distribution – Regulators and plans to automate 10% per year. Each regulator will have 33 position settings along with current and voltage readings and requires the following communications support:


7.1.6.3.4.1 Communications. Two-way, including status and control.



41


7.1.6.3.4.2 Communications Traffic. Interrogation daily, minimal transmissions throughout day.


7.1.6.3.4.3 Communications Size. Estimated at less than 2 kilobits.


7.1.6.3.4.4 Communications Reliability. System needs to be reliable and available but back-up paths are not required. Bidder’s must provide expected reliability and availability.


7.1.6.3.4.5 Interfaces. Communications I/O to controller should be assumed to be serial.




7.1.6.3.5 Switch/Recloser Requirements. The Company employs 4,662 switches and 211 reclosers. Remote control of selected switches is currently enabled by an RF based SCADA system. Capability will be expanded throughout the Company’s system. Capabilities will include machine-to-machine communications to enable automatic switching in the event of a fault. The company expects to automate 10% of the total population annually according to the following:


7.1.6.3.5.1 Communications. Two-way including status and control. System shall allow peer to peer communications among monitoring devices and switches for automated outage prevention or restoration.


42



7.1.6.3.5.2 Communications Traffic. Interrogation daily. Peer to peer communications shall be supported. Low latency due to automation requirements, should be < 2 seconds.


7.1.6.3.5.3 Communications Size. Estimated at less than 2 kilobits.


7.1.6.3.5.4 Criticality. Required to enable fault indicator to switch communications for outage restoration.


7.1.6.3.5.5 Broadcast. Not required, units may communicate with one another without going through the application but only singly.


7.1.6.3.5.6 Communications Reliability. High reliability communications is required to accommodate the need for automatic outage prevention and restoration. Bidders must provide expected reliability and availability.


7.1.6.3.5.7 Interfaces. Typically serial, however, future models should have Ethernet connections.





43


7.1.6.3.6 Fault Indicator Requirements. Currently, the Company utilizes 5,141 fault indicators that provide only local annunciation, and expects to automate 20% of the existing population annually. Full communications capability to both a back office application as well as potentially to switches (peer-to-peer) for automating the detection, prevention and restoration of outages is required as follows:


7.1.6.3.6.1 Communications. Two-way, including status and control. System shall allow peer-to-peer communications among monitoring devices and switches for automated outage prevention or restoration.


7.1.6.3.6.2 Communications Traffic. Interrogation daily. Peer-to-peer communications shall be supported. Latency target less than 30 seconds.


7.1.6.3.6.3 Communications Size. Estimated at less than 100 bytes.


7.1.6.3.6.4 Criticality. Required to enable system automation.


7.1.6.3.6.5 Broadcast. Not required, units may communicate with one another without going through the application but only singly.


7.1.6.3.6.6 Communications Reliability. High reliability communications is required to accommodate the need for automatic outage prevention and


44


restoration. Bidders must provide expected reliability and availability.


7.1.6.3.6.7 Interfaces. Typically serial, however, future models should have Ethernet connections.




7.1.6.3.7 Distribution Transformer Monitoring Requirements. The Company employs approximately 155,000 12 KV and 4 KV distribution transformers, with an average of 7.8 drops per transformer. The Company expects to automate 5-10% of these transformers annually according to the following:


7.1.6.3.7.1 Communications. Communications to be inbound for status and alarm reporting with interrogation capability required.


7.1.6.3.7.2 Communications Traffic. Interrogation daily, minimal messaging. Latency target less than 60 seconds.


7.1.6.3.7.3 Communications Size. Estimated at approximately 2 kilobits.


7.1.6.3.7.4 Criticality. Not mission critical but a significant enabler of outage information and restoration status.



45


7.1.6.3.7.5 Communications Reliability. High reliability required. Bidder’s must provide expected reliability and availability.


7.1.6.3.7.6 Interfaces. To be defined. Bidders are requested to provide all supported interfaces.




7.1.7 Residential Electric Load Limiter 7.1.7.1 The System shall provide the ability to limit consumption via

remote disconnect/reconnect capability per Requirement 7.1.1.19. Load limiting shall be supported via disconnection of load when the load exceeds a specified threshold. Upon this threshold excursion, the load shall be disconnected for a specified duration, and then reconnected. The System shall support the following functionality:

7.1.7.1.1 Load Limit Threshold. The load limit threshold shall be configurable based on magnitude and duration. Magnitude shall be based on RMS current (in amperes), and duration shall be based on time (in seconds).


7.1.7.1.2 Load Disconnect Duration. The System shall support a configurable load disconnect duration in seconds. This parameter shall designate the amount of time the load is disconnected prior to reconnection.


7.1.7.1.3 Load Limit Lockout. The System shall support a configurable load limit lockout, which shall govern the maximum number of load limit


46


disconnect/reconnect cycles within a specified period of time. The number of load-limit cycles and the time period (in hours) shall be configurable. Lockouts shall leave the load disconnected and shall be reported upon occurrence. Lockouts shall have to be cleared remotely.


7.1.7.1.4 Load Limit Enable. Independent of the load limit threshold(s), the System shall support enabling or disabling of load limiting functionality. Support for enabling or disabling load limiting shall be possible by individual meter, or batch of meters, within one hundred twenty (120) seconds of initiation.


7.1.7.2 Time Accuracy. Time accuracy of all load-limiting functions shall within one (1) minute of NIST synchronized to the top of the hour.


7.1.7.3 Programmability. Ability to configure all load-limiting parameters defined herein shall be possible by individual meter, or batch of meters, remotely within eight (8) hours of initiation by System, unless superceded by the requirements above.


7.2 AMI & OpEx 20/20 System Requirements AMI system requirements apply to meters, retrofit gas modules, communications network, data collection software and hardware. OpEx 20/20 requirements apply to communications network only.

7.2.1 AMI & Opex 20/20 System Operating Life. The operating life of the system is expected to be fifteen (15) years from deployment. The system is further expected to remain operational, with slightly degraded failure rates, for up to two extensions of three (3) years each, in order to enable replacement of the system at end-of-life. The Bidder should describe how their systems will meet these requirements and should provide design, accelerated life test, and actual field performance data to support operating life claims as noted below.



47


7.2.1.1 AMI Technology Bidder(s) shall provide with the RFP responses evidence of the following information in the form of a table of contents as referred to by Appendix GG – Documentation, for the following documents, as per:

7.2.1.1.1 End device and Network component manufacturers Quality Control Assurance Plans


7.2.1.1.2 Certified Design Test Reports for each unique combination of metering products and Network components


7.2.1.1.3 ANSI compliance Test Report for each unique combination of metering products


7.2.1.1.4 Environmental and/or Safety Test Reports for each unique combination of metering products and Network components


7.2.1.1.5 Reliability/Life Cycle Test Reports for each unique combination of metering product and network components


7.2.2 AMI & Opex 20/20 System Installation. Bidder(s) will furnish and install all AMI and OpEx 20/20 network communications equipment to provide the services specified herein. AMI equipment shall include, but not be limited to, end-point external (fix-up) antennas, towers, collectors or concentrators, repeaters, injectors, transformer bypasses, grounding devices, communications links, data collection software, hardware and facilities required to provide the data services covered within this RFP. OpEx 20/20 equipment shall include all communications infrastructure (towers, collectors or concentrators, repeaters, injectors, transformer bypasses, grounding devices, etc.) required to provide the data services covered within this RFP.


7.2.2.1 AMI Technology Bidder(s)/Installation Vendor Responsibilities. An AMI Meter Installation Vendor will be selected via a separate RFP to perform all meter and associated


48


endpoint installations including any testing required to verify AMI system connectivity and operation. AMI Technology Bidder(s) will be required to work with the selected AMI Meter Installation contractor under the design, build, run, and transfer requirements provided herein.


7.2.2.2 Special Equipment. The AMI Technology Bidder(s) must provide all necessary special purpose equipment, tools, and software to enable the AMI Meter Installation Vendor to install all required meters and associated meter-site communications devices, and to perform on-site testing to ensure that local communications have been established prior to departure. It is currently anticipated that meter installations will take place according to segments detailed in Appendix F AMI Segments.


7.2.2.2.1 AMI Technology Bidder is responsible for ensuring device communication to the network. AMI Technology Bidder is responsible for installation of all equipment necessary to establish and maintain communications with the network including but not limited to external (fix-up) antennas, signal boosters, filters, transformer by-pass devices, etc.


7.2.2.3 Warehousing and Materials Management. AMI and OpEx 20/20 Technology Bidder(s) will provide all necessary warehousing and materials management facilities and capabilities needed to perform the AMI network installation within the prescribed deployment period. In addition, all office, vehicle storage, computer services, or other facilities needed in connection with installation of the AMI and OpEx 20/20 network will be provided by the AMI and OpEx 20/20 Technology Bidder(s).


7.2.2.4 Documentation. Bidder(s) will supply all necessary documentation for installation, testing, quality assurance, equipment tracking, security and operation of the AMI and OpEx 20/20 system and hardware deployment. The Company’s personnel will be provided with sufficient copies of all installation guides, testing, maintenance, operating and other manuals and guidelines deemed appropriate to oversee installation and


49


operation of the system, including head end software specifications and operating manuals. Similarly, the AMI Meter Installation Vendor will be provided with all necessary materials and installation guides, including installation and test software as appropriate, to properly install and test AMI end-point equipment.


7.2.2.4.1 Documentation List. Bidder is requested to provide a complete list of all system documentation that will be made available to the Company including a Table of Contents for each document. Minimum documentation requirements are included in Appendix GG - Documentation.


7.2.2.5 AMI and OpEx 20/20 Acceptance Testing. AMI and OpEx 20/20 Bidder(s) shall be required to perform a formal acceptance test. OpEx 20/20 bidder(s) shall be required to develop and provide an appropriate acceptance test plan, and will test the OpEx 20/20 communications infrastructure in a means representative of the applications capabilities (including security) to the Company’s satisfaction prior to system acceptance.


7.2.2.5.1 The Company shall participate in development of the test plan, or plans, as appropriate to ensure that all system capacity and functional requirements are satisfied. In all cases, the Company will retain final approval over testing and system acceptance. Bidders must provide your proposed approach to AMI and OpEx 20/20 Acceptance Testing and any actual deployed test plans that the Company may review.


7.2.2.5.2 At a minimum, the Company will require the following testing:

7.2.2.5.2.1 Functional and performance testing prior to, during, and post deployment.



50


7.2.2.5.2.2 Firmware (application layer) and configuration software testing.


7.2.2.5.2.3 Stress, safety, reliability, and security testing.


7.2.2.5.2.4 Data accuracy testing for transmitted quantities.


7.2.2.6 Training. Bidder(s) will be responsible to train the Company personnel, AMI Meter Installation Vendor personnel, and designated subcontractor personnel as necessary to install, test, operate and maintain the AMI system through its operating and extended operating lives. Provide recommended roles, responsibilities, personnel counts, and a proposed training schedule within the proposed system deployment schedule. Please refer to Appendix HH - Training for complete training requirements.


7.2.2.7 Safety. The Company provides safe products and services to our customers. Safety is one of the Company's corporate values and in all that we do. We are committed to deliver products and services safely. The Company is committed to comply with applicable international, federal, state and local health and safety laws and requirements. Bidders must complete Safety Requirements in Appendix FF - Safety Questionnaire.


7.2.2.8 Facility Access/Security. Bidder must provide a detailed description of all physical and logical Company facility access required to deploy the AMI network. Physical access descriptions should include, but not be limited to, types of facilities, duration of access, Company personnel required, and Bidder and/or Bidder’s subcontractors requiring access. Logical facility access descriptions should include, but are not be limited to, types of operating system utilized, frequency of security updates, types of anti-virus software utilized, and any other security software supported on (i.e. personal firewalls).


51


7.2.2.9 Equipment Location. Bidder must capture the GPS coordinates of all network equipment devices deployed. GPS accuracy must be ± five (5) meters (latitude, longitude, and altitude). Working with the Company, Bidder should also provide the circuit ID of all powered network devices and location information as defined in Appendix LL – Network Device Attributes Head End.


7.2.2.9.1 Optionally the GPS must have sub-meter (less than one (1) meter) accuracy for latitude, longitude, and altitude.


7.2.3 Engineering/Operating Requirements. Bidder(s) will comply with all Company engineering, operating requirements concerning installation of equipment on the Company’s facilities, obtaining access to substations and other facilities, and adhering to operating rules and requirements involving safe contact with Company equipment and gas and power lines. Bidders must comply with CPUC General Order (GO) 95 (Overhead) and (GO) 128 (Underground).


7.2.4 AMI & OpEx 20/20 System Reliability. The AMI and OpEx 20/20 system shall employ sufficient fault tolerance, redundancy, failover, and/or self-healing to guarantee the system information performance requirements (note some OpEx 20/20 applications require backup communications facilities as well). The Bidder must provide a detailed systematic failure analysis of all elements of their proposed AMI and OpEx 20/20 system giving failure types, expected annual failure rates (as predicted by design, accelerated life testing, and observed field failure rates at existing deployments), impacts of failures on system performance, and provisions for fault tolerance and how these provisions mitigate the impacts of failure.


7.2.4.1 Quality Control. Bidder must describe in detail mechanisms and processes used during the designing and manufacturing process for all equipment to ensure system reliability. (e.g. FMEA – Failure Mode and Effects Analysis).


7.2.4.2 Predictive/Preventative Reliability. Bidder must describe in detail the mechanisms and processes used to track and report


52


performance of all elements of the AMI and OpEx 20/20 system to ensure system reliability, and proactively identify potential situations that could become system problems. System reliability should be measured in terms of the performance criteria established herein for required timeliness and accuracy of delivered network data, and tracking and reporting systems should be adequate to conclusively demonstrate system performance.


7.2.4.3 Upgradeable. Bidder must describe in detail mechanisms and processes used to upgrade the system (software/firmware) and all necessary components (head end, network equipment residential, commercial, and industrial meters) without system service interruption (firmware upgrade of gas modules is not required). Software/firmware upgrades should be processed remotely and run automatically once initiated, and backwards compatibility of functionality upon upgrade must be assured.


7.2.4.4 Standard Warranty. Bidder shall provide a minimum standard parts and labor warranty of five (5) years from date of installation for all AMI and OpEx 20/20 system equipment. Failed AMI and OpEx 20/20 network equipment shall be replaced and reinstalled by the Bidder. Failed AMI end-point equipment (electric meters and gas modules), shall be replaced, and Bidder shall reimburse the Company the cost of reinstallation (a standard weighted average rate of $42 per end-point should be assumed). Battery warranties extend beyond the standard warranty as specified further in this document . Beyond the first five (5) years, Bidders should provided extended warranties for all failures beyond the specified annual failure rates as follows:


7.2.4.4.1 Extended Warranties (OPTIONAL). Bidders should provide costs for extended warranties in five (5) year increments past each of the standard warranty time period shown in the table below. Extended warranties shall cover parts and labor for all product failures beyond the specified annual failure rates on an increasing share for higher failure rates and declining share for increased age as follows:

Annual Failure Rate

Years 6-10 Years 11-15 Years 16-20

> AFR & < 2% 70% 40% 0%


53


Parts> AFR & < 2% Labor

70% 40% 0%

2-5% Parts 80% 60% 20%2-5% Labor 80% 60% 20%

>5% Parts 90% 70% 40%>5% Labor 90% 70% 40%


7.2.4.5 Repair. Bidder must describe their repair capabilities and the process by which system equipment is returned for warranty/repair work and the failure mode analysis/reporting that is performed on devices returned for repair.


7.2.4.6 Service Option (OPTIONAL). Bidder should provide an annual service option alternative to cover maintenance and/or replacement of network communications equipment on an outsourced basis for the entire operating system life (for AMI beyond the Design, Build, Run, and Transfer phase), and extended operating life of the system. Services should be provided at a level to maintain the system at herein designated performance levels. Service options should detail the types and numbers of support staff required, their location, and the proposed service level agreement to maintain the network as required.


7.2.5 Disaster Recovery. The system shall support the Company’s disaster recovery framework as defined in Appendix N - Disaster Recovery and via the reliability provisions of 7.2.4.


7.2.6 AMI & OpEx 20/20 System Maintenance. Bidder must provide a detailed schedule with estimated time and materials costs of all field work required to maintain the AMI and OpEx 20/20 system for the operating life and extended operating life, including but not limited to battery replacements, communications frequency testing/adjustments, anticipated program or


54


firmware upgrades to ensure system compatibility, and AMI and OpEx 20/20 component product replacements due to end of life concerns.


7.2.7 AMI & OpEx 20/20 System Troubleshooting. Bidder must provide tools required to survey, install, field test and troubleshoot all network equipment and associated links. Bidder shall provide the necessary documentation and troubleshooting guides (please refer to Appendix GG - Documentation for summary of documentation requirements).


7.2.8 Communications Interference. Bidder must provide a detailed analysis of all potential sources of communications interference (external) on, or by the AMI and OpEx 20/20 system (self-inflicted), the impact of said interference, and methods the Bidder proposes to monitor and detect all potential interference. Bidder’s discussion must include all known potential sources and the actions Bidder has taken to either eliminate or mitigate the impact of these interferers. In addition, the Bidder shall provide a listing of all known sources of interference with the AMI and OpEx 20/20 technology solution such as paging systems, Navy radar, etc.


7.2.8.1 Federal Communications Commission (FCC) Regulation . Bidder must provide verification that the AMI and OpEx 20/20 System will operate within all FCC Regulation limits.


7.2.8.2 Interference Management. Bidder must ensure that its system will not cause any harmful interference to other systems. Bidder shall resolve any impact with other parties.


7.2.8.3 Radiation Exposure. Bidder must describe how they will consider provide necessary studies to ensure that their devices and installations are within the acceptable human exposure limits within the Company’s service territory.


7.2.9 AMI System Design. Bidder must provide a detailed design of the AMI and OpEx 20/20 systems’ communications infrastructure that shows how the system is capable of meeting the information requirements. The detailed


55


design must demonstrate how communications packet sizes, data rates, communications protocols, error detection and correction techniques, network data capacities based on proposed deployment, bandwidth and margin at system load (defined as daily collection of, daily volume data for all retrofitted gas meters, hourly interval data for all residential electric meters, and fifteen (15) minute interval data for all commercial and industrial (C&I) meters, plus 25% additional end-point capacity for load control devices, smart thermostats, in-premise displays, etc.) are utilized to meet the prescribed requirements at the prescribed performance levels.


7.2.9.1 Two-Way Communications. The proposed AMI system must support full two-way communications (full or half duplex) to/from all end-point devices except gas modules. The proposed AMI system must support one-way communications from all gas modules. The proposed OpEx 20/20 system must support full two-way communications to/from all end-point devices.


7.2.9.1.1 Two-Way Gas Communications (OPTIONAL). The proposed AMI system shall support full or limited two-way communications (full or half duplex) to/from all gas modules. Limited two-way communications is defined as acknowledged communications to a gas module from the network, and the ability for the network to transmit information to the gas with, or subsequent to the acknowledgement (i.e. only when the gas module “wakes-up” and transmits data can the network acknowledge and transmit additional information to the module before it returns to “sleep”).


7.2.9.2 Scalability. AMI and OpEx 20/20 System design shall meet capacity requirements based on the number of current Company customers and requirements described herein up to a maximum capacity of two (2) times.


7.2.9.2.1 System Growth. Bidder technology shall allow for expected Company customer and OpEx 20/20 device growth without significant cost impact.


56


7.2.9.3 AMI System Enhancement. Bidder must describe how system bandwidth and capacity can be incrementally increased to handle additional network traffic (water meters, load control devices, customer premise displays, etc.) based on the proposed deployment.


7.2.9.4 Design Verification. Bidders shall provide the following:

7.2.9.4.1 Design Parameterization. Bidder shall complete design parameterization spreadsheet in Appendix X - System Design Parameterization.


7.2.9.4.2 AMI System Design Simulation. Bidder shall provide simulation and propagation studies showing the estimated number of collectors/concentrators and aggregators with a confidence level in order to meet the requirements described herein. Bidder shall provide simulation detailing maximum endpoint capacity.


7.2.9.4.3 Network Block Diagram. Bidder shall provide a network block diagram showing each of the AMI and OpEx 20/20 system components and how they functionally work together.


7.2.9.5 Open Standards. The Company encourages the use of open standards throughout the AMI and OpEx 20/20 system. Bidder must provide detailed description of the use of open standards, including, but not limited to, protocols, discovery, authentication, and system monitoring, diagnostics and management within the proposed solution. Bidders must describe what interoperability is supported across all the elements of their proposed AMI and OpEx 20/20 system.


7.2.10 Public Networks. If Bidder’s solution makes use of public communications networks, Bidder must demonstrate, certification from the carrier to operate on the public communications network, availability of network within physical boundaries of the Company’s targeted territory, ability of the overall system to meet the information and performance requirements detailed herein, and


57


provide detailed monthly public network usage estimates for the operating and extended life of the system based upon the base system load defined in 7.2.9.


7.2.10.1 Security. Bidder must demonstrate that the proposed public network(s) support the security provisions of 7.2.12.


7.2.10.2 Reliability. Bidder must demonstrate that the public network supports the reliability requirements of 7.2.4.


7.2.11 Technical Obsolescence. Bidder must describe what system elements are at risk of technical obsolescence over the operating life of the system.


7.2.11.1 Technology Plan. Bidder must describe their current technology plan and procedures for implementing enhancements over the operating life of the system.


7.2.11.2 Forward/Backward Compatibility. Bidder shall ensure that proposed technology solutions will be supported for the life of the system, and that network parts, equipment and software will be available to maintain the required level of system performance. Bidder shall provide historical evidence if available of compatibility provisions.


7.2.12 AMI System Security. The AMI system must have security provisions preventing unauthorized access to all system elements.

7.2.12.1 Data Security. Bidder must provide a systematic description of how data security is maintained from the meters to the system head end.


7.2.12.2 Authentication. Bidder must describe how all communications in the system is authenticated between all communicating elements of the system and what mechanisms are employed to detect and announce non-authenticated communications attempts.


58



7.2.12.3 Access Control. Bidder must provide a systematic description of how system and data access control is maintained across all AMI system elements with remote access provisions (meters through system head-end as applicable).


7.2.12.3.1 Access History. AMI system must have provisions for access histories (logs) that at a minimum maintain date and time, user, and data or functionality accessed.


7.2.12.4 Security Administration. Bidder must describe how system security is configured enabling the creation and maintenance of accounts, passwords, and information and functionality access levels.


7.2.12.5 Intrusion Detection. Bidder must describe how the AMI system monitors security provisions and reports any abnormalities or suspected intrusion.


7.2.12.6 Physical Security. Bidder must describe provisions of all AMI system elements to maintain physical security preventing on-site tampering.


7.2.12.7 Virus Protection. Bidder must describe built-in virus detection capabilities provided in connection with all proposed software platforms and solutions.


7.2.12.8 Denial of Service Attack Protection. Bidder must describe methods to detect and prevent Denial of Service attacks.


7.2.12.9 Testing/Certification. Bidder must describe the types of security testing/certification that have been performed on the


59


system architecture, end-points, network elements, and head-end.


7.2.12.10 Vulnerabilities. Bidder must provide a detailed list of any potential security vulnerabilities for end-points, network elements, and system head-end. Analysis should include types of protocols utilized, all open/utilized ports, use of public networks, etc.


7.2.12.11 Data Confidentiality, Integrity and Availability. Bidder must describe how the Confidentiality of the data is maintained, the Integrity of the data exchanged between systems remains intact, and the system Availability of the host system is maintained. All areas of data Confidentiality, Integrity and Availability must be addressed.


7.2.13 AMI & OpEx 20/20 System Deployment Planning. Bidder must describe the planning processes and timing requirements for AMI system deployment and provide a detailed proposal.


7.2.13.1 Equipment Siting. Bidder must detail all equipment siting requirements, what site survey work must occur prior to deployment, what flexibility exists in physically siting specific equipment, reasons that would induce re-engineering and/or equipment, and any assistance the Bidder needs in acquiring access to Company facilities. The Company will provide access to its own distribution and/or communication poles, towers and substations as required and as allowed by Company, to install AMI and OpEx 20/20 equipment and will help the Bidder to identify these sites as required for AMI and OpEx 20/20 field communications devices. Any work done in the power space must be done by a Company approved union line contractor. Refer to Appendix M - Facility Access Regulations and Appendix DD – Pole & Building Device Installation for regulations on access to Company facilities. If access to non-Company facilities is required, Bidder must detail how they will manage all logistics of obtaining said access on behalf of the Company, as well as comply with all applicable Federal, State, and local regulations (e.g. FAA, California Environmental Quality Act (CEQA), etc.) .


60



7.2.13.2 Spectrum Licensing. If the proposed AMI and OpEx 20/20 system utilizes licensed radio frequency spectrum, Bidder must provide detailed information on license requirements, viable licensors, and estimated costs of leasing required licenses for operating and extended life of the AMI and OpEx 20/20 system versus estimated costs of acquiring licenses for operating and extended life of the AMI and OpEx 20/20 system. Bidder must also price the option of fully provisioning required licenses on behalf of the Company via either a lease or acquisition.


7.2.14 Wide Area Network (WAN)/Backhaul. Bidder must demonstrate that proposed public/commercial and/or private WAN/Backhaul provides coverage as necessary across the Company’s service territory. Bidder must provide coverage maps for public/commercial and/or private WAN/Backhauls referencing locations of needed WAN/Backhaul communications per proposed system. If multiple communications networks are proposed to address complete WAN/Backhaul needs, Bidder must describe how proposed network equipment supports these multiple WAN/backhaul communications networks.


7.2.14.1 Device Specifications. Bidder shall provide WAN/Backhaul communications device specifications for each supported WAN/backhaul communications network (e.g. cellular modem proposed, etc.) per Appendix GG - Documentation.


7.3 AMI and OpEx 20/20 Network Communications Equipment Requirements. Pertains to all devices deployed for the collection, storage, transport, and aggregation of data to meet the AMI & OpEx 20/20 System Requirements

7.3.1 Data Storage. All network communications equipment must utilize non-volatile memory for storing and retaining data. AMI network equipment data storage must be sufficient to provide redundancy for one full billing cycle (i.e. should any communications link malfunction prevent data from reaching the system head end, the communications network will provide redundant storage to ensure no data loss within a complete billing cycle). Bidder should provide a detailed explanation of where this data resides, how it is protected/secured and the level of risk involved for lost data.



61


7.3.1.1 Data Extraction. All network communications equipment must provide a means for extracting stored data directly from the device in the event of network communications or equipment failure.


7.3.2 Power Supply. All network communications equipment, outside of a substation, must be capable of connecting to a main voltage ranging from 120V to 480V. Equipment located on street secondary must be capable of operating on 120/240 volt service, with battery backup as appropriate to maintain system integrity in case of loss of power. Bidder must supply power consumption requirements of each unique piece of AMI system equipment. Sufficient battery carryover must be provided to meet the power outage notification requirements from the end points and provide a minimum of eight (8) hours of communications infrastructure operation after a power outage. Network equipment batteries must have a minimum guaranteed operating life of five (5) years.


7.3.2.1 Network Equipment Battery Replacement. If it is necessary to replace network equipment batteries within the required operating life of the system. Bidder must provide detailed estimates of the number of potential replacements along with diagnostics and battery replacement instructions and estimated labor and equipment costs (time and materials) required to conduct the replacements. Battery replacement functions should also be included in the service provisions outlined in 7.2.4.6.


7.3.3 Upgrade Capability. All network communications equipment, including but not limited to concentrators/repeaters and end-point devices such as electric meters, gas modules (on-site), Utility HAN devices, must support head-end, remote and on-site upgrades.


7.3.4 Certification Compliance. All network communications equipment must comply with all applicable FCC and IEEE Regulations and documentation demonstrating said compliance should be included in Bidder’s Response.



62


7.3.4.1 Carrier Certification. If necessary, Bidder shall obtain all necessary carrier certifications and provide documentation in Response.


7.3.4.2 Industrial Compliance. Bidder shall provide all documentation to the company regarding product compliance standards. The Company may, if desired, request additional compliance from the Bidder.


7.3.4.3 IEEE P1775. All BPL communication devices shall comply with Class 3 requirements as defined in Section 8 of IEEE P1775.


7.3.5 Failure Rate. Less than 0.75% failure rate per annum for all network communications equipment over the required operating life of the system. Less than 1.50% failure rate per annum for all network communications equipment over the extended operating life of the system. Battery failures during the operating life of the battery shall constitute network equipment failures.


7.3.5.1 Diagnostics. All network communications equipment must support local (on-site) and remote (system head-end) diagnostics capable of detecting any abnormal operating parameters including, but not limited to, network communications, memory failure, power supply degradation, microprocessors(s) failures (e.g. COP watch dog events, NMI’s, etc.), firmware/software problems, excessive device temperature, etc. Bidder must provide a detailed list of supported diagnostics for each piece of network communications equipment.


7.3.5.2 AMI System Reports. System reports must be generated that are capable of analyzing system level performance in terms of missed reads, poor communications performance and lost outage and tamper alarms.


7.3.6 Time Synchronization. All network communications equipment shall be time synchronized to a single head-end source to within one (1) minute of NIST, and


63


should provide for synchronization of all applicable (time based) end-point equipment. Time synchronization shall support Pacific Standard and Daylight Savings Time. All network communications equipment shall support remote Daylight Savings Time switch programmability in support of upcoming time changes due to energy bill enactment.


7.3.7 Installation and Testing. Bidder must provide any unique tools required to correctly install and field test communications equipment. Bidder should enumerate required tools and propose number of instances required to meet deployment requirements and schedule.


7.3.8 Test Equipment. Bidder must provide tools required for survey, installation, field testing and troubleshooting of all network equipment and associated links.


7.3.9 Discovery. Network must support automatic and/or programmatic discovery of all end-point devices (meters, load control device, thermostats, in-premise displays, etc.) and communications equipment (relays, concentrators, etc.) for both initial deployments and maintenance of metering, load controls, displays and communications equipment. Bidder must describe how this is accomplished by the proposed solution.


7.3.10 Operations and Maintenance. Bidder shall provide a full explanation of how monitoring of the AMI and OpEx 20/20 communications network is conducted, what preventative and/or predictive measures need to be employed, and what level of field support is required. Bidder shall provide recommendations for locations of field personnel, spare network communications equipment, timeframes for dispatch, arrival, and restoration of network faults.


7.3.11 Technical Documentation. Bidder(s) will supply all necessary documentation for installation, testing and operation of each device. Documentation shall include link budget parameters as detailed in Appendix X - System Design Parameterization datasheets and block diagrams. Refer to Appendix GG - Documentation for summary of all documentation requirements.



64


7.4 AMI End-point Device Requirements7.4.1 Electric - Single Phase and Network.

7.4.1.1 Meter Specification. All meters shall comply with the Company’s technical and engineering specifications for electric metering equipment as defined in Appendix J - Technical and Engineering Meter Specifications. Please identify which Technical Specifications cannot be met with the proposed solution, and provide costs (in pricing only) if an alternate metering solution can provide the additional functionality. The Company requests a minimum of two (2) sources separate meter manufacturers for the purposes of this solicitation and pricing.


7.4.1.1.1 Bidders must provide details for all available meter sources and complete the Residential Data Source Matrix in Appendix J – Technical and Engineering Meter Specifications for all proposed AMI electric solutions.


7.4.1.2 Measurement. Support for measurement and collection of active energy consumption, interval data and bidirectional (optional) metering per the detailed requirements in 7.1.1 (with the exception of 7.1.1.2, 7.1.1.3, 7.1.1.5, 7.1.1.9, 7.1.1.10, 7.1.1.16 , 7.1.1.18.6 and 7.1.1.18.7) are required.


7.4.1.3 Data Storage. All metering equipment shall utilize non-volatile memory for storing and retaining data. Data storage in the end-device meter must be sufficient to provide redundancy for one full billing cycle. Meter data must be retained without loss or degradation for at least ninety (90) days without power and be retrievable without having to remove a meter cover.


7.4.1.4 Communications. Meters should incorporate “under glass” AMI communications via integrated meter and communications, or retrofit communications modules for electromechanical meters if possible. Optionally, meters should provide on-site indication of communications with the AMI network, so that a technician servicing a meter could determine communications success with an AMI network.


65



7.4.1.5 Products. Bidder shall provide sufficient integrated and/or retrofit portfolio of products to address the Company’s meter population retrofit criteria defined in Appendix G - Existing Meter Population. Bidder shall identify specific gaps within their portfolio and recommendations on how to overcome these gaps.


7.4.1.5.1 Retrofit. If Bidder is proposing a solution based on retrofits then Bidder is responsible for retrofitting AMI modules to new or refurbished meters and refurbishing and retesting all meters. All costs incurred to retrofit existing Company meters must be incurred by the Bidder and must be included in unit product (ready-to install) pricing.

7.4.1.5.1.1 Retrofit Process. Bidder’s retrofit process shall include, but not be limited to, selection of retrofitable meters within the Company’s allowable meter population, transportation of meters from Company to Bidder retrofit facility, refurbishment of meters (see below), installation of communications module, meter and module test, capture and delivery of as left calibration data, and transportation of retrofitted meters back to the meter installation Bidder.

7.4.1.5.1.2 Meter Refurbishment. Bidder shall recalibrate electromechanical meters to Company technical and engineering specifications for electric metering equipment as defined in Appendix J Technical and Engineering Meter Specifications and reset the dials to zero. As-left meter test data shall be provided to the Company for each meter product that is refurbished.

7.4.1.6 Battery. Meter shall not utilize a battery that requires any form of maintenance or replacement for the operating life and extended operating life of the meter. Disposal of the battery at end of product life shall not require any special procedures.


66


Battery failures during the operating and extended operating life of the meter shall be constitute meter failures per 7.4.1.8.


7.4.1.7 Display. Meter shall provide for on-site display of total energy consumption, status of remote disconnect contacts and critical meter status. In addition, an indication of energy consumption utilizing a simulated disk shall be visible on the display of the meter and accurately represent consumption usage.


7.4.1.7.1 Disconnect/Reconnect Switch Indication. The display shall visually indicate the status of the integrated disconnect/reconnect switch per 7.4.1.11 (open or closed).


7.4.1.7.2 Energy Consumption. The display shall accurately indicate energy consumption utilizing a simulated disk.


7.4.1.8 Failure Rate. Less than 0.50% annualized failure rate for all meters/modules over the required operating life of the system. Less than 1.0% annualized failure rate for all meters over the extended operating life of the system.


7.4.1.8.1 Diagnostics. All solid state metering equipment shall support local (on-site) and/or remote (system head-end) diagnostics capable of detecting any abnormal operating parameters including, but not limited to, communications, memory failure, power supply degradation, microprocessors(s) failures (ex. COP watch dog events), firmware/software problems, excessive device temperature, etc.


7.4.1.9 Time Synchronization. Meter shall maintain time synchronization to a single head end source to within one (1) minute of NIST. Time synchronization shall support Pacific Standard and Daylight Savings Time. All meters shall support remote Daylight Savings Time switch programmability in support


67


of upcoming time changes due to energy bill enactment. Bidder must describe how time synchronization is maintained in a meter or data collection point following a power outage.


7.4.1.10 Meter Inputs/Outputs (OPTIONAL). The Company may have installations that require a form C contact closure inputs/outputs (also known as KYZ). Meter should allow for optional form C contact closure inputs/outputs (also know as KYZ) and should support optional retrofit with this capability without the use of any special tools or significant difficulty. Based on quantity and options required, the Company may choose to utilize a commercial meter hardware solution, approved under Company’s Poly-phase Solid State Meters Specification 811 (refer to Appendix J - Technical and Engineering Meter Specifications).


7.4.1.11 Remote Disconnect and Reconnect (OPTIONAL ). The meter should include support an integral or separate remote service disconnect and support remote service disconnect and service reconnect capability for Form 1S, 2S and 12S meter configurations. Remote reconnect functionality shall have the remotely configurable option of requiring manual customer intervention and shall not reconnect if load side voltage is present when disconnect is open on a disconnected load .


7.4.1.11.1 Installation. The integrated remote disconnect/reconnect switch shall be configurable in the field, at time of meter installation, with provided meter installation tools per requirement 7.4.1.14 (e.g. if account is disconnected at time of meter installation).


7.4.1.11.2 Switch Specification. The disconnect/reconnect switch shall have the following minimum characteristics:

Contact Rating 200A continuous make or break (heat rise maintained within ANSI specifications)

Cycles Minimum 10,000 open/close cyclesFailure Mode Switch open


68



7.4.1.12 Meter Testing. All meters shall be able to work with existing standard meter shop and field metrological testing equipment and tools employed by the Company as detailed in Appendix K - Meter Shop Field Testing Tools Requirements. If not, Bidder shall provide appropriate test equipment and instructions on use.


7.4.1.13 Communications Testing. Bidder must provide tools for on-site communications testing to troubleshoot meter to network connectivity. Tools should be able to diagnose communications signal strength as appropriate. In addition, an AMI communications solution that utilizes the electric meter for relaying gas module reads shall also utilize the test equipment to diagnose communications gas communications signal strength.


7.4.1.14 Installation. Bidder must provide all specific/unique tools required to correctly install, configure, and test meters within the AMI system.


7.4.1.15 On-Site Reading (OPTIONAL). All solid state meters should optionally support on-site reading via ANSI C12.18 Type 2 optical port or other means to extract data held in memory of the meter.


7.4.1.16 Function During Power Disturbances. The AMI system is to provide time synchronization for end devices to ensure accurate data collection and to ensure the maintenance of time in the meter for Interval Data recording (IDR) functionality.


7.4.1.16.1 During a power outage critical program and billing data shall be retained. When power is restored, normal operation shall resume without loss of data.


69


7.4.1.16.2 Following a power outage of less than eight (8) hours, register “catch-up” time shall be a maximum of sixty (60) seconds. During the “catch-up” time the Meter shall still calculate consumption quantities even though communication with the network may not be established.


7.4.1.16.3 The Meter shall flag any power outage in the load profile interval data, and provide a last gasp power fail message when power is lost and power restore messages when power is applied to the meter for more than configurable duration (in seconds) per requirement 7.1.1.17.


7.4.2 Electric – Poly Phase. 7.4.2.1 Meter Specification. All meters shall comply with the

Company’s technical and engineering specifications for electric metering equipment as defined in Appendix J - Technical and Engineering Meter Specifications. Please identify which Technical Specifications cannot be met with the proposed solution, and provide costs (in pricing only) if an alternate metering solution can provide the additional functionality. The Company requests a minimum of two (2) sources separate meter manufacturers for the purposes of this solicitation and pricing.


7.4.2.1.1 Bidders must provide details for all available meter sources and complete the Commercial Data Source Matrix in Appendix J - Technical and Engineering Meter Specifications for all proposed AMI electric solutions.


7.4.2.2 Measurement. Support for measurement and collection of active energy consumption, demand, coincident demand and interval data per detailed requirements in section 7.1.1.


7.4.2.2.1 Measurement (OPTIONAL). Additional measured quantities listed below are optional and require


70


separate pricing depending upon the capabilities of the poly-phase solution offered:

7.4.2.2.1.1 Reactive Measurement. Reactive measurement shall be remotely configurable per requirement 7.1.1.9.


7.4.2.2.1.2 Apparent Measurement. Apparent measurement shall be remotely configurable per requirement 7.1.1.10.


7.4.2.2.1.3 Power Quality. Power quality measurement per the following specification shall be remotely configurable on meter, or batch of meters basis. Power Quality measurement shall consist of:


7.4.2.2.1.3.1 Record Minimum and/or Maximum phase voltages in the load profiling channels of the meter.


7.4.2.2.1.3.2 Logging dates and times when voltage surges, sags and imbalances exceed the threshold limits programmed remotely into the meter.


7.4.2.2.1.3.3 Perform waveform capture during excursion events and log histories that can be extracted through the AMI network for analysis.



71


7.4.2.2.1.3.4 Perform harmonic analysis of the current and voltage waveforms applied to the meter.


7.4.2.2.1.4 Time-of-Use. TOU measurement per requirement 7.1.1.5 should be remotely configurable in the meter and activated without visiting the site. In addition the TOU information shall be able to be uploaded through the network for processing by the head-end.


7.4.2.3 Data Storage. All metering equipment shall utilize non-volatile memory for storing and retaining data. Data storage in the meter shall be sufficient to provide redundancy for one full billing cycle. Meter data shall be retained without loss or degradation for at least ninety (90) days without power and be retrievable without having to remove a meter cover.


7.4.2.4 Communications. Meters shall incorporate “under glass” AMI communications via an integrated meter and communication module, or retrofit modules to existing solid state or electromechanical meters . Optionally meters must provide on-site indication of communications with AMI network.


7.4.2.5 Products. Bidder must provide sufficient integrated and/or retrofit portfolio of products to address the Company’s meter population defined in Appendix G - Existing Meter Population. Bidder must identify specific gaps within their portfolio and recommendations on how to overcome these gaps.


7.4.2.5.1 Retrofit. If Bidder is proposing a solution based on retrofits then Bidder is responsible for retrofitting AMI modules to existing solid-state polyphase meters. All costs incurred to retrofit meters must be borne by the Bidder and must be included in unit product pricing.


72


7.4.2.5.1.1 Retrofit Process. Bidder’s retrofit process must include, but not be limited to, selection of retrofitable meters within the Company’s allowable meter population, transportation of meters from the Company to Bidder retrofit facility, refurbishment of meters (see below), installation of communications module, meter and module test, capture and delivery of as left calibration data, and transportation of retrofitted meters back to the AMI Meter Installation Vendor.

7.4.2.5.1.2 Meter Refurbishment. Bidder shall test and verify the calibration of solid state meters after installing an AMI device under the meter cover to the Company’s technical and engineering specifications for electric metering equipment as defined in Appendix J Technical and Engineering Meter Specifications. As-left meter test data shall be provided to the Company for each meter product that is refurbished.

7.4.2.6 Battery. If meters utilize a battery to support network communications (i.e. integrated meters and concentrators/relays) or time keeping, and said battery requires replacement within the operating life and extended operating life of the system, Bidder must provide detailed estimates of the number of potential replacements along with diagnostics and battery replacement instructions and estimated labor and equipment costs (time and materials) required to conduct the replacements.


7.4.2.7 Display. Meter shall provide for on-site display of all measured energy consumption and demand quantities. Other parameters used to validate proper operation and programming shall also be available on the display such as (date, time, program ID, etc.).


7.4.2.7.1 Energy Consumption. The display shall accurately indicate energy consumption utilizing a simulated disk.


73



7.4.2.8 Failure Rate. Less than 0.75% annualized failure rate for all meters/modules over the required operating life of the system. Less than 1.5% annualized failure rate for all meters over the extended operating life of the system.


7.4.2.8.1 Diagnostics. All metering equipment shall support local (on-site) and/or remote (system head end) diagnostics capable of detecting any abnormal operating parameters including, but not limited to, communications, memory failure, power supply degradation, loss of phase voltage (blown fuse), microprocessors(s) failures (ex. COP watch dog events), firmware/software problems, excessive device temperature, etc.


7.4.2.9 Time Synchronization. All meters must be time synchronized to a single head end source to within one (1) minute of NIST. Time synchronization shall support Pacific Standard and Daylight Savings Time. All meters shall support remote Daylight Savings Time switch programmability in support of upcoming time changes due to energy bill enactment . Bidder must describe how time synchronization is maintained in a meter following a power outage.


7.4.2.9.1 Time Synchronization (OPTIONAL). All meters supporting TOU must be time synchronized to a single head-end source to within one (1) minute of NIST. Time synchronization shall support Pacific Standard and Daylight Savings Time.


7.4.2.10 Meter Inputs/Outputs (OPTIONAL). Meter should allow for optional form C contact closure inputs/outputs (also know as KYZ) and should support optional retrofit with this capability without the use of any special tools or significant difficulty.



74


7.4.2.11 Remote Disconnect and Reconnect (OPTIONAL). The meter should support an integral or separate remote service disconnect and service reconnect capability. Remote reconnect functionality shall require manual customer intervention and shall not reconnect if load side voltage is present on a disconnected load.

7.4.2.12 Meter Testing. All meters must be able to work with existing standard shop and field metrological testing equipment and tools employed by the Company as detailed in Appendix K - Meter Shop Field Testing Tools Requirements. If not Bidder shall provide appropriate test equipment and instructions on use.


7.4.2.13 Communications Testing. Bidder must provide tools for on-site communications testing to troubleshoot meter to network connectivity. Tools should be able to diagnose communications signal strength as appropriate. In addition, an AMI communications solution that utilizes the electric meter for relaying gas module reads shall also utilize the test equipment to diagnose gas communications signal strength.


7.4.2.14 Installation. Bidder must provide all specific/unique tools required to correctly install, configure, and test meters within AMI system.


7.4.2.15 On-Site Reading. All meters must provide and support on-site reading via ANSI C12.18 Type 2 optical port of all measured and stored quantities or other means to extract data held in memory of the meter.


7.4.2.16 On-Site Configuration. All meters must support on-site configuration via ANSI C12.18 Type 2 optical port and ANSI C12.19 protocol.


7.4.2.17 Function During Power Disturbances. The AMI system is to provide time synchronization for end devices to ensure accurate data collection and to ensure the maintenance of time in the meter for IDR functionality.


75



7.4.2.17.1 During a power outage critical program and billing data shall be retained. When power is restored, normal operation shall resume without loss of data.


7.4.2.17.2 Following a power outage of less than eight (8) hours, register “catch-up” time shall be a maximum of sixty (60) seconds. During the “catch-up” time the meter shall still calculate consumption quantities even though communication with the network may not be established.


7.4.2.17.3 The meter shall flag any power outage in the load profile interval data, and provide a last gasp power fail message when power is lost and power restore messages when power is applied to the meter for more than configurable duration (in seconds) per requirement 7.1.1.17.


7.4.3 Gas7.4.3.1 Module Specification. All gas meter retrofit technology shall

comply with the Company’s technical and engineering specifications for gas metering equipment as defined in Appendix J - Technical and Engineering Meter Specifications. The bidder shall identify which specifications cannot be met with the proposed solution.


7.4.3.2 Measurement. Support for measurement and collection of gas volume.


7.4.3.3 Data Storage. All gas meter retrofit modules shall utilize non-volatile memory for storing and retaining data. Data storage must be sufficient to provide redundancy for one full billing cycle. Meter data must be retained without loss or degradation for at least ninety (90) days without power.



76


7.4.3.4 Communications. The gas meter technology will incorporate AMI communications via retrofit modules. Optionally, the modules should provide on-site indication of communications with AMI network.


7.4.3.5 Products. Bidder shall provide sufficient retrofit portfolio of products to address the Company’s meter and corrector population defined in Appendix G - Existing Company Meter Population. Bidder shall identify their proposed solution for each meter and corrector listed. Bidder shall also identify specific gaps within their portfolio and recommendations on how to overcome these gaps.


7.4.3.5.1 Retrofit Solutions. Bidder is responsible for providing AMI retrofit solutions for new or existing installed meters. All costs incurred to retrofit existing Company meters must be bourn by the Bidder and must be included in unit product pricing.


7.4.3.5.1.1 Direct Mount Retrofit Solution. Bidder shall provide a direct mountable retrofit solution for each meter listed in Appendix G - Existing Company Meter Population. This solution must include, but not be limited to, the communications module, and meter adapter plate or adapter kit if needed, for existing installed gas meters. Bidder’s direct mount solution must comply with Appendix J Technical and Engineering Meter Specifications. Bidder shall identify which meters in Appendix G - Existing Company Meter Population the proposed solution is compatible, and if there are exceptions, the Bidder is to identify and recommend how to overcome these exceptions.



77


7.4.3.5.1.2 Remote Mount Retrofit Solution. Bidder shall provide a remote mountable retrofit solution for use as exception to a direct mounted solution and for use with electronic volume correctors. The remote mount retrofit solution must include, but not be limited to, gas meter pulser, pulser wiring, and communications module, for existing installed gas meters. Bidder’s remote mount solution must comply with Appendix J - Technical and Engineering Meter Specifications. Bidder shall identify which meters listed in Appendix G - Existing Company Meter Population the proposed solution is compatible, and if there are exceptions, the Bidder is to identify and recommend how to overcome these exceptions.


7.4.3.6 Battery. If the gas module battery requires replacement within the operating life and extended operating life of the system, Bidder must provide detailed estimates of the number of potential replacements along with diagnostics and battery replacement instructions and estimated labor and equipment costs (time and materials) required to conduct the replacements. Bidder shall also provide supported battery life expectancies for the various operating and transmitting duty cycles the gas modules can be programmed.


7.4.3.7 Failure Rate. Less than 0.50% annualized failure rate for all modules over the required operating life of the system. Less than 1.0% annualized failure rate for all meters over the extended operating life of the system. Battery failures during the operating life of the battery shall be constitute AMI gas end-point failures.


7.4.3.7.1 Diagnostics. All modules shall support local (on-site) and/or remote (system head-end) diagnostics capable of detecting any abnormal operating parameters including, but not limited to,


78


communications, memory failure, power supply degradation, microprocessors(s) failures (ex. COP watch dog events), firmware/software problems, excessive device temperature, etc.


7.4.3.8 Time Synchronization (OPTIONAL). Optionally gas modules should maintain time synchronization to a single head-end source to within one (1) minute of NIST. Bidder should describe how time synchronization is maintained in the gas module.


7.4.3.9 Module Testing. All modules shall be able to work with existing standard meter shop and field metrological testing equipment and tools employed by the Company as detailed in Appendix K - Meter Shop Field Testing Tools Requirements. If not, Bidder shall provide appropriate test equipment and instructions on use.


7.4.3.10 Communications Testing. Bidder must provide tools for on-site communications testing to troubleshoot meter to network connectivity. Tools should be able to diagnose communications signal strength as appropriate.


7.4.3.11 Installation. Bidder must provide all specific/unique tools required to correctly install, configure, troubleshoot and test meters within AMI system including the retrieval of on-site data (i.e., consumption read, tamper alarms, battery health and any other diagnostic data).


7.4.3.12 On-Site Reading. All proposed gas meter retrofit technology must allow for the retention and incorporation of the meter’s original reading index. Bidder shall also provide the specific tools necessary to allow for on-site interrogation of the gas module and its configured parameters to allow for comparison to the gas meter’s actual index reading and meter configuration for troubleshooting purposes.



79


7.4.3.13 Intrinsic Safety Certification. All gas meter retrofit modules shall be certified intrinsically safe for Class I, Division 2, Group D environments as defined by the National Electrical Code. See Appendix J - Technical and Engineering Meter Specifications for certification requirements.


7.5 AMI Head-End System Requirements7.5.1 The head-end system is comprised of all the hardware and software required to

collect, monitor and control the AMI system and send and receive data to meet the system requirements detailed in sections 7.1 through 7.4 above. “Support” in this section refers the capability of the head-end system to collect, store, and make available via a bidder supplied user interface and published programmatic interfaces the data necessary to fulfill the listed functionalities.


7.5.1.1 Current/Future Company IT Environment. Bidder shall complete questionnaire included in Appendix U - IT Questionnaire and, adhere to the requirements laid out in Appendix L - IT Standards, Appendix O - Current Company IT Environment (Network Topology) and Appendix P - AMI Solution Architecture.


7.5.1.2 Deployment. The head end system shall support AMI system deployment.


7.5.1.3 Network Management, Monitoring and Control. The head end system shall support centralized remote management, monitoring and control of all network hardware.


7.5.1.3.1 Bidder shall work with the company to incorporate appropriate network management, monitoring and control capabilities based on the proposed AMI Technology.


7.5.1.3.2 Bidder shall provide a complete list, including definitions, of network parameters used for Network Management, Monitoring and Control.


80



7.5.1.3.3 Bidder shall provide a complete list, including definitions, of network alarms/events used for Network Management, Monitoring and Control. Definitions shall describe alarm/event detection and delivery latency.


7.5.1.3.4 Bidder shall provide applications and secure interfaces to allow real-time (live) monitoring and control of network activities.


7.5.1.3.5 The network management system shall have ability to automatically rectify network problems.


7.5.1.3.6 Bidder shall describe how integration of its Network Management, Monitoring and Control applications can be achieved with enterprise level applications (e.g. HP OpenView).


7.5.1.4 Billing Support. The head end system shall support on-cycle and off-cycle billing.


7.5.1.5 Diagnostic and Performance Report. The system shall provide daily, weekly and monthly performance reports tracking equipment failures, communications failures, and data latency for all customer and equipment classes.


7.5.1.5.1 Bidder shall provide a complete list, including definitions, of error codes used for Diagnostic and Performance Reporting.


7.5.1.5.2 Bidder shall ensure that all reports can be easily integrated with spreadsheet and/or database products for tracking purposes.


81



7.5.1.5.3 Head End System shall have ability to monitor received data integrity. It shall have option to automatically retrieve missing or corrupt data.


7.5.1.6 Change of Party (OPTIONAL). The head end system should support change of party by performing an off-cycle closing read and an off-cycle or on-cycle opening reading as determined by the move-out and move-in dates .

7.5.1.7 Disconnect/Reconnect (OPTIONAL ). The head end system should support disconnect/reconnect by meter/customer or batch of meters/customers. The system shall support the use and processing of remote closing reads for virtual disconnect functionality, and provide a way of tracking and flagging energy usage for metering locations where power has been shutoff.


7.5.1.8 Energized Check. The head end system shall support an energized meter check by meter/customer of batch of meters/customers.


7.5.1.9 On-Request Read. The head end system shall support on-request reading of any available information by meter/customer or batch or meters/customers.


7.5.1.9.1 The head end system shall be capable of retrieving partial and complete historical data from all electric meters.


7.5.1.10 Revenue Integrity Monitoring. The head end system shall support revenue integrity monitoring across the entire meter/customer population including, but not limited to, meter tamper, energy diversion, site diagnostics, and load diagnostics.


7.5.1.11 Outage Management. The head end system shall provide outage detection notification and power restoration notification


82


information in support of enhanced outage management and improved customer satisfaction. All electric meters shall deliver power outage notification and restoration timestamps to the head-end in order to calculate outage duration.


7.5.1.12 Transmission and Distribution Operations (OPTIONAL). The head end system should support Transmission and Distribution (T&D) operations applications such as system planning, transformer load management, and maintenance .

7.5.1.13 Load Forecasting and Rate Design (OPTIONAL). The head end system should support load forecasting and rate design .

7.5.1.14 Asset Management. The head end system shall support tracking and management of all AMI system assets including all network communications equipment. Bidders must provide a response to Appendix - LL Network Device Attributes Head-end for details of the Company’s asset management requirements.


7.5.1.14.1 Maintenance and Calibration. The head end system shall support a means for defining periodic maintenance on both predictive and preventative basis along with prescribed calibration cycles or meter sampling per ANSI standards. As-left meter calibration information must be retained by the system and passed to the appropriate Company system for storage.


7.5.1.15 AMI Network Bulk Install Update. The AMI Technology Bidder will provide a scheduled load of installed AMI network and connectivity data per 7.2.2.9, which can be loaded into the Company’s GIS (GFMS) system. The AMI network data will be different depending on the AMI technology selected by the Company and should include all deployed network equipment.


7.5.1.16 Utility Home Area Network. The head end system should support load control in response to 7.1.4. Bidder should provide detailed information regarding load control applications supported. The system must be capable of addressing any single or multiple single premise, or multiple premise load control devices optionally controlled or not controlled.


83



7.5.1.16.1 Head end system shall support on demand verification of customer premise load control device status.


7.5.1.16.2 Head end system shall support control and messaging to the premise via the Utility HAN through an externally accessible interface. This interface shall be controlled only from the head end monitoring console.


7.5.1.17 Pre-Payment (OPTIONAL). The head end system should support the pre-payment capabilities in response to 7.1.5. Bidder should provide detailed information regarding pre-payment applications supported.


7.5.1.18 Distribution Automation (OPTIONAL). The head end system shall support the distribution automation capabilities in response to 7.1.6. Bidder should provide detailed information regarding distribution automation applications supported and how they would interface with existing and future systems .

7.5.1.19 Data Repository. The head end system must provide up to one (1) month of on-line storage for all collected AMI system information. The system must further support access to repository by multiple users and systems with no degradation of performance.


7.5.1.19.1 Database Management. The head end system must support open database management tools for database extraction, loading, transformation, reporting, and administration.


7.5.1.20 Scalability. The head end system must support sufficient scalability to provide an additional 25% a margin with respect to the segment addressed up to a maximum capacity of two (2) times the total meter population.


84



7.5.1.21 Integration. The head end system must support commercial enterprise application integration means of interface to a Meter Data Management System (MDMS) or the Company’s customer information management, outage management, and T&D operations systems.


7.5.1.22 Fault Tolerance. The head end system must provide full high availability and backup/recovery for all of the head end system hardware.


7.5.1.23 Disaster Recovery. The head end system must support the Company’s disaster recovery framework in Appendix N - Disaster Recovery.


7.5.1.24 Security Administration and Monitoring. The head end system shall administer and monitor security requirements as stated in Appendix U - IT Questionnaire and Section 7.2.12.


7.5.1.25 Upgradeability. The head end system shall support the software/firmware upgrade capabilities as stated in section 7.2.4.3 and this support shall extend to network devices and communication modules within two-way end-point devices .


7.5.1.26 Metrology Software/Firmware Upgrade. The head end shall support the remote software/firmware upgrade of the electric meter metrology.


7.5.1.27 Utility HAN Software/Firmware Upgrade. The head end shall support the remote software/firmware upgrade of the Utility HAN.


7.5.1.28 Configurability. The head-end system shall support configuration changes for all devices.


85



8 AMI Technology: Suppor t Requi rements

Upon award of contract, the Bidder shall provide the following training and documentation materials for the AMI Technology, meter installation, network maintenance and operations, and head-end system maintenance and operations.

8.1 Management training for personnel assigned supervisory and managerial responsibilities for meter installation personnel, network equipment operations and maintenance personnel, head-end system installation, operations, and maintenance personnel.


8.2 Operations “train-the-trainer” training for personnel assigned to operate and maintain the AMI meters, AMI communications network, and AMI head-end system in day-to-day operations.


8.3 System integrator/administrator training for personnel assigned to configure, integrate, operate, and maintain the AMI head-end system software, including training on the design and use of all Bidder supplied administration and configuration tools.


8.4 The Bidder shall provide, at a minimum, the documents listed below or their equivalents in hard copy and CD-ROM form. The digital copy shall be in common Microsoft Office and Acrobat Reader PDF formats. The Company shall have the right to make and distribute as many paper and digital copies of all documentations as it deems necessary for internal Company use. The Bidder shall provide the Company new or updated additions to the manuals when they become available. Please refer to Appendix GG - Documentation for summary of additional documentation requirements.


8.4.1 AMI System Architecture Documents, including AMI meters, PCT’s, Utility HAN devices, communications network, and head-end system architecture overviews, logical and technical architectures, and physical architectures of the Company implementation.



86


8.4.2 User Manuals, describing the functions of the AMI modules and/or meters, communications network equipment and head-end system.


8.4.3 Application Guides, describing the processes and steps for performing each of head end applications.


8.4.4 AMI System Administration Manuals, including user account management, levels of authority, backup and restore procedures, troubleshooting procedures, etc.


8.4.5 Database Management System Manuals, including data load, incremental update, data errors and troubleshooting guide, data backup and restore procedures for the AMI head-end system.


8.4.6 Configuration Manuals for meters, communications network equipment, and head end system.


9 AMI Technology: F ie ld Tests

The Company may, at its option, conduct technology field tests commencing in mid 2006 and ending mid 2008. Field tests will be conducted to validate functional and performance capabilities of the chosen technology/technologies across a representative sample of the Company’s deployment segments.

9.1 Field tests will be limited to 500 meters or less.


9.2 Bidders selected for field tests will provide sufficient AMI meters, network equipment, as well as an AMI head end free of charge to the Company.


9.3 If the Company does not select a field tested AMI technology for partial to full deployment, the Company will return all AMI meters, network equipment, and head-end software to the Bidder.


87



9.4 If the Company selects a field tested AMI technology for partial to full deployment, the Company will acquire all field test equipment at pricing provided by Bidder as detailed in the Bidder’s Response to this solicitation.


9.5 If the Company elects to field test more than 500 meters, the Company will acquire the necessary meters and network equipment at pricing provided by Bidder as detailed in the Bidder’s Response to this solicitation.


10 AMI Technology: Des ign , Bu i ld , Run, Transfer

Bidders are requested to provide design, build, run, transfer services for the AMI system deployment and up to the formal acceptance of the AMI system per 7.2.2.5.

10.1 Bidder shall design, build, and run AMI technology network during full deployment period of thirty (30) months and an additional three to six (3-6) months for acceptance testing, then transfer operations to the Company.


10.1.1 Assets. The Company will procure and own all data collection head-end, network and meter assets. The Company may withhold small portions of asset payments for Service Level Agreements (SLA) incentives and penalties as mutually agreed to.


10.1.2 Bidder shall provide on-site program management for complete deployment of AMI system including all meters, communications network, and data collection head end, including securing access and leases for all network equipment. Upon deployment bidder shall also provide on-site operations, and maintenance of the deployed communications network and data collection head end (the Company shall provide operations and maintenance of deployed AMI end-points).


10.1.2.1 Data collection head end shall be housed within the Company’s primary and redundant data centers with design, deployment,


88


configuration, operations and maintenance performed by Bidder until transfer (the Company shall own the software and hardware).


10.1.2.2 Program Management Services:

10.1.2.2.1 AMI Technology. If full deployment of electric and gas segments requires the use of more than one commercially available technology, then the Bidder of the largest component (based on meter volume) will be requested to provide program management of all other AMI Bidder(s). The Company reserves the right to make all final technology sourcing decisions.


10.1.2.2.2 End-point Installation. Bidders shall also provide program management and subcontracting of the meter installation service provider(s). The Company reserves the right to make all final end-point installation sourcing decisions.


10.1.2.2.3 Program Management Coordination. The Company has awarded and contracted with a Prime Services Vendor to provide an overall AMI Program Management Organization. AMI Technology Bidder’s are request to acknowledge their willingness to have all activities of design, build, run, and transfer, including SLA incentives and penalties, coordinated through the Company’s contracted Prime Services Vendor.


10.1.3 Transfer of AMI System (meters, communications network, and data collection head-end) operations from bidder to Company shall be based upon demonstrated System performance per RFP accuracy and reliability specifications herein and negotiated cost targets.


10.1.3.1 Upon completion of deployment, performance monitoring of entire System will commence. Transfer of System after three to six (3-6) months of full-deployment operations at herein


89


specified performance levels and completion of Company resource training per 7.2.2.6.


10.1.3.1.1 Company resources shall actively participate in System deployment and operations as part of hands-on training for transfer of operations.


10.1.3.2 Completed System cost not to exceed negotiated range of bid.


10.1.4 Price of design, build, run and transfer should include all startup, training, documentation, field operations and maintenance, WAN, site costs to get the System up and running and operating per performance specifications herein for term of design, build, and run phase with a successful transfer to Company.


10.1.4.1 Equipment shall continue to be purchased by the Company along with replacement parts within the range of failure rates and specifications submitted by Bidder in original bid.


10.1.4.2 Payment terms shall be performance-based on a set of agreed upon SLA-driven milestones agreed upon by parties.

Please respond here

10.1.4.2.1 Please provide acceptable SLA concepts based upon proposed network installation per 7.2.2, deployment planning per 7.2.13, and other requirements herein.


10.1.4.3 Design, build, run and transfer option shall adhere to coverage of all meters as originally bid by the AMI Technology Bidder(s). The costs of any additional equipment beyond this bid shall be deemed to be part of the total cost target for the solution and performance of such technology and shall be included in the overall performance targets established for the bid.



90


10.1.4.4 WAN availability shall be discussed with Company. WAN contract and site attachment fees shall be negotiated by Bidder and be transferable to Company at end of design, build, run, and transfer term with an option to terminate and have Company provide its own WAN and site attachment contracts.



91

SDG&E Functional & Technical Requirements 1 · Web viewTable of Contents. 0 Bidder Notes &...

Documents

Transcript of SDG&E Functional & Technical Requirements 1 · Web viewTable of Contents. 0 Bidder Notes &...