BEFORE THE PUBLIC UTILITIES COMMISSION OF THE
STATE OF CALIFORNIA
Order Instituting Rulemaking on the Commission’s Proposed Policies Governing Restructuring California’s Electric Services Industry and Reforming Regulation	)))))	
R.94-04-031
(Filed April 20, 1994)	
Order Instituting Investigation on the Commission’s Proposed Policies Governing Restructuring California’s Electric Services Industry and Reforming Regulation	))))))	
I.94-04-032
(Filed April 20, 1994)	
PERMANENT STANDARDS OF METERING AND METER DATA USED IN DIRECT ACCESS

Submitted to the
California Public Utilities Commission
By
Permanent Standards Working Group

Names 

Attorneys for
COMPANIES
Address
Post Office Box
City, California  9xxxx
Telephone:	
Facsimile:	
Dated:  July 29, 1998

PERMANENT STANDARDS OF METERING AND METER DATA USED IN DIRECT ACCESS

Submitted to the
California Public Utilities Commission

By
Permanent Standards Working Group  

July 29, 1998

Table of Contents

(To be edited when report is completed)

I. 	Executive Summary
Commission Decision 97-12-048 ordered the creation of a Permanent Standards Working Group, (PSWG) to review the interim standards adopted in the decision and recommend what permanent standards should be adopted by the Commission The PSWG met and worked intensively for six months. In the following report, the PSWG recommends permanent requirements for meter and meter-related data. All recommendations included in this report were voted through by at two thirds of the eligible voting membership not including abstentions and absences. However there were areas without 100% agreement. In these areas, the opposing party(ies) alternative position is included. All recommendations include a list of entities who voted to adopt the recommendation, entities who voted against and entities who abstained. Other parties may also include their perspective to give the CPUC.

I.1. 	Recommendations on what CPUC should adopt
PSWG recommends that the CPUC adopt all recommendations in the report and the Appendices that have no alternative positions.

I.2.	Recommendations on decisions CPUC must make
PSWG requests that the CPUC review recommendations that have an alternative position and decide how to proceed based upon the information provided.

I.3.	Process for Standard Revisions 
PSWG categorized several subject areas and determined that some will require immediate ongoing work and some will only need to be addressed infrequently. PSWG recommends that the Commission formally adopt the recoomendations for the various subject areas in Section X of the report.

II.	PSWG History and Organization

II.1.	History/Regulatory references
CPUC Decision 97-12-048 ordered the creation of a Permanent Standards Working Group, (PSWG) to review the interim standards adopted in the decision and recommend what permanent standards should be adopted by the Commission. The decision also ordered PSWG to indicate whether other standards are expected in the future and recommend a process for reviewing possible future changes to the permanent standards. Within 180 days of the initial workshop convened by the Energy Division, the PSWG must file a report with the CPUC with the proposed permanent standards attached.

Consistent with that order, the Energy Division convened a workshop on January 29, 1998. The PSWG created a structure consisting of four subgroups to address technical issues and an additional subcommittee to recommend a process for updating standards in the future. Membership was inclusive, open and equitable

The PSWG agreed that the scope of the group was to::
•	Review interim, national, existing, or UDC, standards in progress or completed and make recommendations to the CPUC.
•	Propose an ongoing process for standards selection.
•	Clarify functional requirements and business processes.

The following evaluation criteria were applied in the selection of standards/requirements for the Direct Access Marketplace:
•	Be consistent with RSIF and DQI data requirements 
•	Be reconciled with DA rules
•	Meet: safety, accuracy and reliability consistent with the current UDC level of meter reading or higher if business requirements demand
•	Address interoperability and open Architecture
•	Promote customer choice
•	Allow market innovation
•	Prevent meters from being a barrier to changing suppliers
•	Allow efficient Process
•	Be economical (include the UDCs)
•	Be feasible, ability to implement (includes UDC)
•	Be the minimum required for competition consistent with defined requirements
•	Address the minimum functional/business requirements
•	Be uniform statewide 
	
II.2 	Organization/structure/meeting frequency
The PSWG established four subgroups, each dealing with a different technical area of review. The Meter Data Management Subgroup also created a technical subcommitte to address Validating, Editing and Estimating of usage data.

1.	Meter Equipment Subgroup-Chair Jamie Patterson, (CEC) 
2.	Meter Communications Subgroup-Chair; Kirsten Stacey, (PG&E)
3.	Meter Data Management & Meter Reading-Chair, Chris King, (CellNet)
	Validating, Editing and Estimating Subcommittee-Chair, Kathy Smith, (ABB)
4.	Meter Installation, Maintenance, Testing and Calibration-Chair Michele Wynne, (MZA Grid Services)

A separate subcommittee was created to investigate the issues of national coordination and the ongoing review of evolving standards that may apply to California and to suggest a process for changing applicable standards after permanent standards are adopted by the CPUC.  The committee consisted of, August Nevolo, Chair (EPRI), Greg Lizak (Star Data Services), Ted York (ABB), Tom Chen (eTCom),  Lee Simmons (Enron), Ed Quiroz (ORA), and Jamie Patterson (CEC). 

Additionally, the group agreed that the Plenary (full PSWG membership) will address unresolved issues, vote on final recommendations, address questions or requests from the subgroups, and review business requirements. The facilitator for the PSWG Plenary was Kirsten Stacey, PG&E and the Secretary was Bill Buckley, Itron.

The coordinating committee consisted of the chairs of the 4 subgroups and the facilitator of the main PSWG.  The responsibilities of the coordinating committee were to ensure gaps and overlaps between the subgroups were addressed or resolved and work with the subcommittee chairs to resolve technical issues.  The coordinating committee also had the role of arbitrator on conflicts between the subcommittees.

The four subgroups met once every two weeks for half a day each. Once a month, the PSWG Plenary convened to monitor overall progress and vote through the items recommended by the subgroups for adoption. Additionally several side groups held conference calls and/or worked on issues via the internet.. 

The ORA provided an e-mail website for postings as well as an “e-mail exploder.”  E-mails sent to this exploder were distributed to all PSWG members and other subscribers who were interested in the process. On June 29, 112 individuals were subscribed to the exploder representing 64 organizations. This communication tool greatly enhanced information exchange and allowed entities who could not participate in PSWG to stay informed of developments that might affect them.

Overall the process was intense and included active input from an average of 25 different entities. (including meter service providers, meter data management agents, meter manufacturers,ESPs, UDCs, employee representative groups, etc.) 

II.3	Voting Rules and Membership
On February 29, 1998, the PSWG adopted the following voting and membership rules:

Rule #1 - A quorum consists of a minimum of 50% of the total qualified voting members.

Rule #2 - Meeting Attendees may speak to the group only when recognized by the convener or facilitator.  Side discussions will not be allowed.  Sarcasm is not permitted and subject to censure.

Rule #3 - Final recommendations to the CPUC will be decided by a two thirds majority vote of the qualified voting membership.  The final report will include a list of every one who voted and will include any submitted minority reports.  The word “consensus” will not be used.

Rule #4 - There will be a single vote for each entity.

Rule #5 - To maintain voting membership,  an entity must have representatives at two of the last three meetings.  The three meetings will include the current or most recent meeting.

Rule #6 - Membership is open to stakeholders and interested parties (firms or entities, not individuals) defined as manufacturers, government entities, trade organizations, consumer advocacy groups, consultants, utilities, employee organizations or service organizations (ESPs, MDMAs, UDCs, MSPs etc.).  Eligibility for membership is subject to challenges at the PSWG meeting.  Consultants can only vote if representing an entity. 

Rule #7 - To accommodate parties’ desires, a simple majority of parties in attendance are required to approve modification of meeting dates or locations or other minor issues. These issues are called motions of convenience.

Rule #8 - The 4 subgroups will have the same voting and membership rules as the main PSWG.

Rule #9 - A two thirds majority of qualified voting members are required to change Procedures or Voting Rules.

Rule #10 - Proxies are not permitted for non attendees of meetings.  However a proxy is permitted for a voting member who attends a meeting,  in the event that the members absence is temporary from that meeting.  Such proxies will be submitted to the convener or chair in writing, designating the person who is to vote on behalf of the qualified member exercising the proxy privilege.  

Rule #11- A minimum notification of 14 calendar days in advance is required for meeting notifications that will include meeting location, meeting dates, and how to contact the host. Notification will consist of either posting the meeting announcement to the ORA WEB page or to the E-Mail exploder. (E-Mail pswg@dra1.cpuc.ca.gov)

Rule #12 - A minimum notification of 7 calendar days in advance is required for advance meeting agendas.  Agendas will include items that are to be voted on.  Any agenda is subject to the approval and changes of the membership at the meeting. Notification will consist of either posting the meeting agenda to the ORA WEB page or to the E-Mail exploder. (pswg@dra1.cpuc.ca.gov)

Rule #13 - Roberts Rules of Order will only be utilized at the Facilitator’s discretion for handling difficult, or contentious issues.  If conflicts occur between these rules and Roberts Rules of Order, these rules will prevail.

Rule #14 - When voting, the qualified members may vote “YES,” “NO,” or “Abstain.” Providing comments or reasons, by the entity voting, is optional.  A written minority report may be included with the majority report or reasons for any vote.

Rule #15 - When calculating the 100% quantity,  “abstain” votes will not be included.

III. 	Meter Communications 
The Meter Communications group addressed the communication between the meter and the meter reader. Essentially, the group focused on how to facilitate this communication for all settlements. The goal was to provide customer choice without imposing undue hardship on the vendors or precluding market development. In discussions, the group identified applicable ANSI standards and made recommendations on which should be adopted to enhance interoperability. Additionally the group addressed the issue of an on-site meter display minimum, pulse output requirement as well as password authentication.

Recommendations:
The PSWG recommends that the CPUC adopt the meter communications requirements listed in appendix MC. This area was the most controversial, therefore, where there are alternative opinions the PSWG requests that the CPUC consider the alternatives and decide based upon the evidence presented.

III.1.	Diagrams of Interconnections of Meter and Meter Data Systems:
Following are two diagrams which describe how meter and meter data systems are interconnected and data communications take place between one another.  The diagrams are intended to show the connections between functions and layers of possible interoperability.  The boxes in the Diagrams A and B describe functions not specific equipment types.   

Diagram A shows that there are two possible places (represented by two small circles) to have open architecture.  The first one is between MDM and retail market participant, and the second one is between the meter and meter reading system.  Between the meter and meter reading system, there are various connections between the meter, meter mount and communication device.  These devices are grouped together in the big ellipse.  This group is broken up into four boxes: (1) Communication Mechanism, (2) Physical Communication Connection, (3) Meter Device Data Format, and (4) Physical Communication Device so that they can be assigned to different PSWG Subgroup for discussions and recommendations of standards.  As agreed by the PSWG, Boxes (1), (2) and (3) were assigned to the PSWG Meter Communications Subgroup, and Box (4) was assigned to the PSWG Meter Equipment Subgroup.  Since there are many communications technologies, and not any standards available, the PSWG agreed to not recommend a standard for Box (1) .  The PSWG focused its discussions on applicable standards (ANSI C12.18 and ANSI C12..19) for Boxes (2) and (3).  And lastly, Box (4) is covered under the certification requirement developed in the PSWG Meter Equipment Subgroup.

Box (1):  Communication Mechanism is communication means and is defined as the communication technology or method by which data and/or information is transported to and from a meter.  This technology includes communication protocol, speed and medium.  The protocol includes handshakes and data bit format.  The speed determines how fast the data is transmitted.  The medium is the environment in which the data bits are transmitted.  Examples of these communication technologies are radio, microwave, power line carrier, phone, satellite, etc.  Within each communication technology, there are still many ways for data bits to be transmitted.

Box (2): Physical Communication Connection is a gate way through which data or information is transmitted.  The connection may be different for each communication technology and is established when communication devices needs to communicate or transmit data among each other.  Some of the existing physical connections as seen on meters and meter devices are optical port, phone jack, antenna, wires, etc.
 
Box (3): Meter Device Data Format defines how data is organized when transported through its gate way to its receiving ends.  This data format may be the same as the device data table format inside a meter or meter device or it may be different.  This data format is different from the communication protocol of data bits in which each byte or group of data bits is transmitted.

Diagram B Shows… Diagram B illustrates some of the many steps(interfaces) information must pass through during communication between the meter and the MDM. Meters can be interoperable on selected interfaces or every interface. PSWG focused on external interfaces. If an interface is mandatory, it cannot be embedded in another interface.   However, an optional interface can be embedded.

Diagram B 

Diagram B is for illustrative purposes and clarification. The group did not agree to identify or recommend standards at all interface levels in the stack.

III.2.	Open Architecture and Interoperability:
Decision 97-12-048 states (findings of fact #9) that the goal of direct access is to facilitate customer choice and (findings of fact #10) open architecture serves as the vehicle for allowing interoperability to take place. On page 9 of the Decision, it states,

“Interoperability in turn enables customers to choose from multiple suppliers of electric services the providers that best meet their needs.”…In order for different metering systems to communicate with each other, consideration must be given to an open architecture standard.” (d. 97-12-048, p. 9.) To address the CPUC’s concerns, PSWG formed one subgroup to specifically address open architecture and meter communications issues. 

The group started with the definition in the CPUC decision: “Interoperability is the ability of dissimilar devices or systems to communicate between each other in such a way that the characteristics of the device or system providing the service to the user of the data are transparent.“(d.12-97-048, p.9)

The group discussed where meters should fall on the interoperability continuum. If the group recommended a required standard for every interface there would be interchangeability within a specific meter communication technology, (e.g. telemetering, radio frequency, etc.)  However, is interchangeability a requirement for interoperability? For example: IBM and MacIntosh are interoperable on the Internet but not interchangeable. The group felt that defining interoperability to this degree of detail was too cumbersome.

To treat the issue of interoperability, the group either needed to define the requirements of a basic meter with the understanding that there will be a lot of equipment traded out which should be left to the marketplace or define one meter that is completely interchangeable which would be quite costly to manufacture. The group opted to define a basic meter which would be less costly to manufacture. 

On the other end of the interoperability continuum, the group questioned whether interoperability at the MDM server was sufficient such that no further standards needed to be recommended. The group agreed that the method of communicating the data could change, but the data needs to remain constant. Interoperability currently exists at the MDM through the current mandated data format. However, the closer one is to the point of measurement, the higher the mobility of the customer. Therefore, this group elected to define some level of interoperability at plane 3 of diagram B.

In conclusion, the group felt ideally interoperability should be available in the following three areas. Identifying standards at these three points would be sufficient to move the market toward interoperability without imposing too much regulatory restraint.

1) 	MDM-Output data format
2) 	Data format tables- The meter device data format (Box #3 of diagram A) can provide a basic interoperability-functional continuity for the market place. The group recommended C12.19
3) 	Physical communication device, (if the meter has an optical port, there should be a standard, or the meter should be read manually.) Box #2 of Diagram A hooks up the device, provides the handshake. There are no applicable national standards approved at this time.

III.3.	Standards Required and Not Required for Direct Access 
III.2.1.	Requirement of ANSI C12.19 Standard Application
The group discussed one ANSI standard, the C12.19 data format standard as a means to achieve a minimal level of interoperability at Box 3 without adversely affecting the technologies that are currently being sold in the market place. C12.19 was defined as the language that can be transported through various mediums. 
C12.19 is...
The group agreed that although the meter should communicate in the format specified by C12.19 it should not be required to store the data in the C12.19 format.
The discussion of C12.19 was quite extensive. The group realized that C12.19 would not provide a “plug and play” option to the marketplace (i.e. if a customer has a meter which communicates over a microwave frequency and switches to an ESP who reads meters over the telephone, the meter will have to be replaced.) Additionally, C12.19 has a table which would allow a manufacturer to program some data in a manner that is proprietary. Another concern was the costs of implementing C12.19 on the market. However no real cost evaluation was proposed or reviewed.
The majority of the group felt that C12.19 would create limited interchangeability. For example, PSWG recommended that C12.18 be adopted for meters with type 2 optical ports. Meters with C12.18 compliant optical ports could switch MSPs/MDMAs transparently.. Additionally, although the telephone modems do not currently have a standard, the technology is consistent enough that C12.19 would also make it possible for customers on telephone read meters to switch ESPs to other telephone-read meters without having to replace their meters) This would be beneficial to the UDCs in their role of providing default services.
One issue that the group grappled over was the use of C12.19 for radio frequency technologies. Everyone agreed that currently C12.19 would not work well for radio frequency based technologies. It would have an impact on bandwidth and response times. Also it would increase the message length, making radio frequency transmissions more expensive (unless the manufacturers change bandwidth.) In order to accommodate these challenges, the group considered exempting radio frequency technologies from compliance. However the simpler alternative was to exempt all meter products released before March 20, 2000 from compliance for the duration of their commercial product life. This would allow time for the radio technologies to design data communications to C12.19 and continue selling their current products.

III.2.2.	Communications Standards Not Required for Direct Access
Two ANSI  standards, C12.21 and C.12.22 were potentially identified for Box #2 of diagram A. However they have not been approved to date and were therefore not discussed.
III.4.	KYZ Pulse Outputs and Consumer Protection
If meter has external pulse output it should be KYZ per ANSI 12.1. But meters do not need to be required to have a pulse output .  Will a meter vendor/ESP be obligated to tell a customer who uses KYZ for an energy management system if the proposed meter does not have a KYZ output?  

Recommendation: This issue should be referred to a consumer protection proceeding.

III.5.	Back-up Meter Read Requirements:
There are two reasons for requiring a meter display. 1) For consumer protection. The consumer can verify that the meter read matches the bill and 2) for on-site interrogation when another communications system fails. This would enable entities who are responsible for billing/settlements to obtain the meter read when investigating the communications failure. The PSWG agreed that the dials on a electromechanical meter are sufficient for on-site interrogation however,. an electronic meter must have a visual display of the total kwh energy consumption as minimum. Additionally a meter must have a physical interface to enable on-site interrogation of all stored meter data.

Alternative position:
ABB and Nertec do not believe the requirement that all meters have a local display is in the consumer’s or industry’s best interests. The PSWG should recommend the functional requirements necessary to make the market work, but not limit the technology based on today’s products.  Two reasons for local access to total kWh have been discussed - the customer’s need for access to verify their bill, and the UDC’s need for access if all other means of obtaining a meter reading fail.  Both of these needs could be met today by different technologies.  For example, a customer with a solid state meter may prefer the convenience of having a display inside their home or business, or to access the data on their pc, rather than walking outside to read their meter.  Technologies such as CEBus or LonWorks can be used to provide this capability today.  A meter could have a local Type 2 optical port that complies with C12.18 and C12.19, providing standard access at the meter for the UDC to ALL meter data, not just total kWh.  ABB is not pushing either of these technologies, but desires to point out there are alternate solutions.  By prescribing the technology required to meet legitimate customer and UDC needs, the PSWG is limiting product innovation and imposing additional costs on the consumer, who may need to pay for a display both on the meter and in the home or business if that is what he/she prefers.
IV. 	Meter Equipment
The Meter Equipment Subgroup reviewed the applicable national standards and recommended which performance standards should be required for direct access meters. Appendix MH includes two tables. Table 1 summarizes performance standards recommended for adoption with some additional clarification for tests for ANSI 12.1 and 12.20. Table 2 summarizes national standards the group reveiwed and recommended not be adopted, along with an explanation in the comments column of the table 

Recommendation: PSWG recommends that the CPUC adopt the standards listed in Table 1 of Appendix MH. Further, PSWG recommends that the CPUC not adopt the standards listed in Table 2 of Appendix MH. 

V. 	Meter Data Management/Meter Reader
(to be edited)

(Should the following to be written in Appendix MDM?)
V. 1. 	Functions
MDMA business functions include Meter Reading (MR) and Meter Data Management (MDM) functions. The group recommends that the CPUC adopt these functions in its definition of an MDMA. Such action would clarify the CPUC’s description of an MDMA as stated in D.97-12-048.  

At a summary level, the MDMA business functions include the following:

V.1.1.	Functions performed by Meter Data Management entity 
A.	Accept raw meter reads from meter reading entity
B.	As necessary, translate data into format for internal processing
C.	Associate meter reads with customer identifiers for use in estimation, if needed
D.	Validate, edit, and estimate data
E.	If necessary, translate data into CPUC-approved format prior to posting to MDMA Server
F.	Post VEE’d meter reads to MDMA Server for retrieval by market participants
1.	Perform data adjustments as required
2.	Re-frame data as required
3.	Resend previously posted data as required
G.	Maintain MDMA Server
H.	Archive raw data and validated data for 36 months

V.1.2.	Functions performed by Meter Reading Entity 
A.	Collect data at the meter, including routine meter reads, special reads, and date and time of reads
B.	Transport data to the MDM
C.	Perform any Validation that is required to be performed either on-site or at the time of reading
D.	Check for and report suspected energy theft
E.	Check for and report hazardous conditions (if meter reading is performed locally)

V.2.	Meter Reader Approval
"We recommend the Commission change D.97-12-048 to allow an entity to be approved for all or any subset of MDMA functions, but, if approved for a subset, the entity must operate as a subcontractor to an approved MDMA.  Also, the entity need not be re-approved to provide such functions as subcontractor to another MDMA."

V.3.	EDI
(to be edited)

V.3.1.	General Recommendations
For meter usage data transactions currently handled in CMEP, PSWG recommends." 

"For any new transactions between MDMAs and market participants (other than in item a above), the preferred method is EDI."

V.3.2.	EDI and Meter Specific Information
For electronic communications concerning Meter-Specific Information
Flows, such as those described in the October 15, 1997, report to the
CPUC, the preferred method is EDI
V.3.3. EDI and Meter Usage Data

VII.4	Validating Editing and Estimating (VEE)
The VEE subcommittee held a series of conference calls and meetings to review the Interval VEE Rules 1.3 and develop VEE rules for monthly data.  Notices for all meetings and conference calls were distributed to the PSWG email exploder and website, as well as anyone who asked to be put on the mailing list; they were also announced at the joint UDC/MDMA meetings.  The meetings and calls were open to all interested parties.  Notes for each meeting or call were also distributed to the PSWG email exploder and website, as well as interested parties.

Several principles developed during the course of the meetings, which apply both to the work this spring as well as to any future work:
•	The rules should promote fairness in the marketplace
•	The goal of the rules is to provide quality data
•	Solutions must fit the magnitude of the problem - when evaluating solutions, the costs must be considered against the frequency of occurrence and the quality of the data
•	Modifications to the rules should typically be required when they result in a significant improvement in the data quality
•	When modifications to the rules are made, reasonable implementation plans should be defined allowing time for all parties to comply
•	Variations for different technologies should be allowed where appropriate
Interval Data

Seven conference calls were held to review the Interval VEE Rules 1.3 published in December, 1997, culminating in a final review meeting on June 18, 1998.  Participation in the meetings was as follows, with a Y indicating at least partial attendance:

Company	4/7	4/20	5/8	5/18	5/27	6/5	6/12	6/18	
ABB	Y	Y	Y	Y	Y	Y	Y	Y	
Cellnet	Y	Y	Y	Y	Y			Y	
Energy Interactive	Y	Y		Y	Y	Y	Y	Y	
Energy Management Services	Y		Y						
Enron				Y				Y	
eT	Y	Y				Y			
FirstPoint			Y						
ORA	Y	Y					Y		
PG&E	Y	Y	Y	Y	Y	Y	Y	Y	
SCE	Y	Y	Y					Y	
Schlumberger					Y				
SDG&E	Y	Y				Y	Y	Y	
Sierra Pacific	Y	Y							
Stardata									

The group reviewed the existing rules in light of market startup, clarified the rules, and addressed situations that were not addressed previously due to time constraints.  The detailed rules are included as separate documents.  Major changes and clarifications include the following:
•	Spike check threshold - For very low usage customers, a valid pulse count of a few pulses may result in failing the spike check.  An optional minimum threshold was added to allow MDMAs to automate checking for this condition and passing the data.
•	kVARh check threshold - For very low usage customers, a valid pulse count of a few pulses may result in failing the kVARh check.  An optional minimum threshold was added to allow MDMAs to automate checking for this condition and passing the data.
•	Use of partial days as reference data for estimation - Days containing less than 24 hours of good interval data may be used as reference data to estimate data for other days
•	Use of days containing power failure as reference data for estimation - Days in which a power failure occurred should not be used as reference data for estimation.
•	Use of accurate meter readings to scale estimated intervals - When data is estimated based on historical data, and accurate meter readings or usage are available, the estimated data can be scaled based on the actual usage.
•	Simplified proration algorithm (when meter clock is off) - A simpler method to prorate data when the meter clock was off is provided.  
•	Automating handling of irregular usage customers - Rules are provided to determine which customers are irregular usage, and how special tests can be designed and automated for those customers.
•	Test mode intervals - The MDMA may report zero usage during times when a meter was in test mode.  The MDMA must not report the test load.  If the meter is inadvertently left in test mode, the data will be estimated.
•	Clarifying interpretation of reference day selection for estimation - reference days selected as “like” days for estimation are the days chronologically closest to the day requiring estimation, whether that is in historical data or the present billing period.
•	High/low usage check - The high/low usage check is always performed on the data that has passed or been verified for previous checks, with no estimated values included.  It can optionally be performed on the final data, including estimated values.
•	kVARh checks - kVARh checks are only required when kVARh is used for billing.  
Only 3 of the above changes were considered required by the group; the rest are optional and may be implemented at the MDMA’s discretion.  The proposed implementation plan for the changes is described in the following table.  The Optional/Required column indicates if market participants will be required to make this change.  The Earliest date acceptable column indicates the earliest a market participant is allowed to implement this change (note to UDCs - this means the VEE test would need to allow these options), and the Required by column indicates the date by which market participants must implement the option (only applies to required options).  MDMAs that were accepted prior to the required date must comply, but do not need to go through the acceptance process again.
During the discussion, it was noted that some of the optional changes have a bigger impact on some technologies than others.

Modification	Optional/Required?	Earliest date acceptable	Required by	
Spike check threshold	Optional	Now	n/a	
kVARh check threshold	Optional	Now	n/a	
Use of partial days for estimation	Optional (may make a bigger difference with some technologies than others)	Now	n/a	
Don’t use days containing power fail as source for estimation	Required	Now	90 days after Commission decision	
Allow use of accurate meter readings scale estimated data	Optional (may apply more to some technologies than others)	Now	n/a	
Simplified proration algorithm when meter clock is off	Optional	Now	n/a	
Automated handling of irregular usage	Optional	Now 	n/a	
Handling of test mode intervals	Required	Now	90 days after Commission decision	
Clarification of selection of reference days	Required	Now	90 days after Commission decision	
High/low usage check	Required	Now	90 days after Commission decision	
kVARh check	Optional	Now	na	

The group felt examples and flowcharts would be helpful to new market participants, but did not have time to develop them.  Also, the checks should be reviewed for effectiveness after there is more actual market experience; checks that don’t uncover expected problems should be modified or deleted, and checks may need to be added to uncover problems not foreseen when the tests were written.
Monthly Data
Five meetings and a conference call were held to develop rules for monthly VEE, based on Decision  97-12-048 dated December 3, 1997.  Participation in the meetings was as follows:

Company	4/27*	5/6	5/27	6/10	6/15	6/17	
ABB	Y	Y	Y	Y	Y	Y	
Cellnet	Y	Y	Y				
Energy Interactive	?						
Energy Management Services	?						
Enron	Y	Y	Y	Y			
eT	?		Y				
FirstPoint	Y	Y					
ORA	Y			Y	Y		
PG&E	Y	Y	Y	Y	Y	Y	
SCE	Y			Y		Y	
Schlumberger	Y						
SDG&E	Y	Y	Y		Y	Y	
Sierra Pacific	Y						
Stardata	Y	Y					

The attendance record from this meeting was not available; the column is based on participants memories of the meeting.
The group further defined the monthly validation and estimation rules found in the Commission ruling, as well as defining estimation rules for TOU data.  The rules defined include the following:
•	Time check of meter reading device/system
•	Time check of meter
•	High/low usage check
•	High/low demand check
•	Time-of-Use (TOU) check
•	Zero usage on active meters
•	Number of dials on meter
•	Number of demand decimal places
•	Meter identification

The group agreed that the usage for inactive meters check was not the responsibility of the MDMA and should not be required.

Estimation rules were defined for:
•	Usage
•	Demand
•	TOU Usage
•	TOU Demand

Recommendations
General Recommendations:
1.	Publish the rules (CEC has volunteered to do this) and make them available on the web site.
2.	Submit the rules to IEEE SCC 31 as an initial starting point for a national VEE standard.
3.	Publicize the rules by publishing the rules themselves or a white paper in an industry magazine.
4.	Clarify the rules by adding examples, flow charts, and definitions. 
5.	Review the rules after the market has been operational.  Suggest review interval rules 4/99 and review monthly rules 6/99.  A change management procedure should be put in place, following the principles outlined in the Introduction.
6.	Adopt the policy that in the event of a large catastrophe (i.e., hurricanes, earthquakes, etc.) that precludes the MDMA reading meters, the MDMA should estimate and post the data.  This estimated data should be reported separately by the MDMA in their performance report, and not be included in any performance penalties assessed against the MDMA.
7.	Adopt the policy that estimated data due to meter failure where meter is not accurately recording usage should be reported separately by the MDMA in their performance report, and not be included in any performance penalties assessed against the MDMA.
8.	Eliminate the existing requirement to include the estimation algorithm when the data is posted.  Note that data that was estimated for any reason must always be flagged as estimated..  The MDMA must record and maintain the estimation algorithm as long as it is required to store the data (for the 3 year archive); this information will be made available upon request to the appropriate UDC or ESP.  This should be reviewed when the rules are reviewed to see if it is necessary based on market experience.
9.	Add an additional code to CMEP (or other approved format) for verified data.  Verified data is data which failed at least one validation check, but was determined to be valid.  
10.	MDMA performance standards should be investigated to consider the number of consecutive months data for a given meter may be estimated.  

Interval VEE Recommendations:
1.	Adopt modifications to interval rules as outlined in section 2 of this summary and described in detail in the Interval VEE document.  

Monthly VEE Recommendations:
1.	Adopt monthly validation and estimation rules as outlined in section 3 of this summary and described in the Monthly VEE document.  Note that if this is not done in a timely fashion it may delay MDMAs ability to enter this market.
2.	Establish a group to define rules to convert interval data to billing determinants.  Monthly data validation and estimation rules would be reviewed as part of the process to determine any impact.
3.	No rules for TOU demand validation or for TOU usage or demand estimation were included in Decision  97-12-048  December 3, 1997.  Estimation rules for TOU were developed and are included.  Validation rules for TOU demand and usage should be investigated. 
4.	Determine what is statistically valid as a minimum density requirement for rules based on similar customers.
5.	Determine sample calculations for optional trend factors to incorporate climatic and demographic areas in validation and estimation.
6.	UDCs will lead an effort to develop a standardized approach to acceptance testing for monthly data, commencing by 9/1/98.

VI. 	Meter Installation, Testing and Maintenance
(to be edited)

VII. 	Security
Introduction

The purpose of this proposal is to discuss issues addressing the appropriate implementation of data security practices and related standards that may impact the PSWG.   This  strawman presented some ideas and concepts that should be considered for further security policy and standards evaluation recommendations. 

Goal

Data is transferred at each interface in the data chain described as part of each subgroup in the PSWG.  The new business environment that is at the center of this new commerce is not risk free. As electric restructuring moves more to a set of  business models  that encompass parts resembling electronic commerce, many of the new risks are unique to this environment. The previous integrated monopoly structure created data flows that possessed little or no value to others.  In a restructured competitive industries, the value of this data dramatically changes.  The methods through which this data is secured must also change.

The strawman proposal was intended to describe data security concerns that occur as an indirect result of some of the PSWG processes being evaluated.  It was also intended to initiate discussion on ongoing data security national standards and whether the PSWG should be considering these standards as part of its evaluation process.

Vulnerability Potential and implications

A matrix table  (Table 1) was presented as a means of  evaluating potential data vulnerabilities as they might exist at different  places within the PSWG subgroups.  It was presented , not as an all inclusive list, but, rather as a way of assessing risks at different data interfaces.  The discussion intended was to further the understanding on the what these vulnerabilities are and what standards exist that might address these vulnerabilities. 

Table 1 - Vulnerability  and Implications
Vulnerability Assessment	Implication	Hardware	Communication	Data Management	installation	
						
False Identity	false identity or copied identity	Minimal risk for residential, greater risks for commercial/industrial	Applicable	Affects who can access various parts of MDMA functions	Minimal risks for residential, some risks for commercial/industrial	
Privacy/Confidentiality breach 	Transactions duplicated,copied 	low risk	medium risk	Higher risk	Low risk	
Data Theft/Fraud (unaccounted for Data)
.	transactions inserted or suppressed	Unauthorized meter programming 	Greater risks at concentrator	Higher risk as data is aggregated and goes through VEE	Minimal risk, unique identifier should eliminate	
Data integrity Violations
	transactions altered or duplicated	Minimal risk for residential, greater risks for commercial/industrial	Possible signal access	Higher risk as data is aggregated and goes through VEE	Depends on device programming	
Service denial
	transactions intercepted or delayed	Minimal risk for residential, greater risks for commercial/industrial	Possible signal blockage	Higher risk as data is aggregated and goes through VEE	NA	

Discussion of Standards

Jointly, the UDCs have recommended  a combined strategy of Secure Socket Layer (SSL) as a mechanism for secure data transmission from the MDMA server to other parties over a common carrier.  Additionally, the integration of firewall technology (for unauthorized external access), encryption  or some other reasonable security measure(s) are minimums recommended..  The presence of these elements are a reasonable step, but may not represent a completely secured  solution.  No discussion has been had in the PSWG or its MDM subgroup whether  this set of recommendations represent a reasonable approach or if other standards exist to provide similar functions or better security.

The migration to EDI based transaction systems also requires that some thinking should be directed at draft standards for EDI related security.   Some of these additional  standards include format for digital certificates as specified by International Telecommunication Union (ITU) X.509. 

Security Architecture

A  security architectural perspective was proposed that considered these components as part of the building blocks:
•	AUTHENTICATION
•	AUTHORIZATION
•	SESSION INTEGRITY   
•	PRIVACY/CONFIDENTIALITY 
•	NONREPUDIATION

Proposed Security Policies Further Evaluation

As part of an extended evaluation, the proposal suggested to look at additional areas that could play an increasing role in data security.  These areas include:

•	cryptography
•	public key infrastructure (pki).
•	digital Signatures
•	digital Certificates
•	certificate authorities

The basis for extending this evaluation was to introduce consistency to the security efforts that are starting to occur elsewhere in the electric restructuring marketplace.  It was noted that the California Independent System Operators (CAISO)  had proposed a system of data security policies that recognizes levels of achievable security and corresponding policies.  The strawman proposed to evaluate some of the CAISO security proposals to determine their relevance to the PSWG.

Data Security Matrix Review

A second matrix table was developed that presented the security components discussed and proposed a possible set of strategies that could be deployed.  The table also presented a suggestion , based on the four subgroups, where this deployment would be most effective.

Table 2 Data Security Components and Deployment Strategy
Security component	Strategy	Meter Hardware	Meter Communication	Meter Data Management	Meter installation	
						
AUTHENTICATION
establishing identity within a transaction	Password Encryption is a start. Future establishment of digital certification via certification authority	Low Requirement	Medium Requirement	High Requirement	Low Requirement	
AUTHORIZATION
	SSL feature. Future establishment of digital certification via certification authority	Low Requirement	Medium Requirement	High Requirement	Low Requirement	
SESSION INTEGRITY
	PGP	Low Requirement	Medium Requirement	High Requirement	Low Requirement	
PRIVACY/CONFIDENTIALITY
	PGP	Low Requirement	Medium Requirement	High Requirement	Low Requirement	
NONREPUDIATION
	Password Encryption provides no basis. Need establishment of digital certification via certification authority	Low Requirement	Medium Requirement	High Requirement	Low Requirement	

Malicious Action
	unauthorized access and data attacks/corruption	Minimal risk for residential, greater risks for commercial/industrial	Possible intrusion and unauthorized service access	Higher risk as data is aggregated and goes through VEE	Low risk	

The Strawman Proposal

The strawman present four possible choices on how to proceed:

Choice 1 - Business as usual - SSL3.0  and password  and encryption of data on MDMA server is sufficient.  The current system does not address the concerns of data integrity and non repudiation and thus may not be fully secure as the electric market moves forward. 

Choice 2 - Evaluate further standards to develop Security policy that emphasizes scalability based on vulnerability potential.  In moving to EDI based systems, develop security policies based on an architecture that integrates S/MIME , PGP and digital signatures.

Choice 3 - Evaluate further standards to develop Security policy that includes choices 1 and 2 and integrates Digital Certification and Certifying Authority (CA) practices.  

Choice 4 - Recognize that data security policy cuts across the entire market place and a working group that has been created to look at data flow and integrity issues is a more appropriate home for further discussions rather than the PSWG.  

PSWG Recommendation

Data security has a significant impact on the overall confidence in market data quality and integrity.  As such, its perspective should be a complete market view. the Data Quality and Integrity Working Group (DQIWG) is currently evaluating market issues that address the areas of  information flows, gaps and overall data integrity.  PSWG recommends that the CPUC refer security policy development to the DQIWG.

Future of PSWG
The PSWG categorized the different areas of work that has been reviewed within this report and recommends the following for each category.

Subject Area	Convene as needed	Ongoing Committee Work	
Meter Hardware Standards	X		
Meter Communication Standards	X		
Meter Worker Qualifications	X		
Meter Installation Procedures	X		
Meter Maintenance, Testing and Calibrations	X		
Electronic Commerce/data flows		X	
Validating, editing and estimating usage data		X	
MDM issues		X	

PSWG recommendation for items in Convene as Needed category
For the majority of subject areas, the PSWG feels that the review done and agreements reached in this document should suffice and do not require immediate ongoing work.

For the issues categorized as “convene as needed” the group recommends that the procedure for reconvening the PSWG would be for any stakeholder to file a petition to modify the CPUC-approved requirements.  If the CPUC feels further technical expertise is not needed after receiving and reviewing comments from other entities, the CPUC will issue its decision accordingly.  If the CPUC wishes market participants to seek solutions on this issue, it will order the PSWG to reconvene, discuss the issue and make recommendations within a reasonable period.  However, PSWG shall not be reconvened more often than once within an six month period."

PSWG recommendations for items in Ongoing Work category
The areas which may require ongoing committee work are generally not supported by national standards bodies or have more to be defined before they can become a requirement.
For the subject areas identified as requiring ongoing committee work, PSWG recommends that the Electronic Commerce issues be addressed in the Rule 22 working group. A subcommittee is currently addressing DASR and account maintenance issues involving EDI and it would be preferable to have all EDI issues in the same forum. The PSWG requests the CPUC order the interested market participants to continue to work on permanent  ( with any required timeline for implementation) informational interactions and exchange standards including, outlining areas of responsibility and accountability, and finally compliance and enforcement issues.

PSWG recommends that ongoing VEE and MDM issues be addressed and resolved in the UDC/MDMA meetings that were ordered by the CPUC in d. 97-12-048.

Appendices:
MC - Requirements for Meter Communications in Direct Access
MH - Requirements for Meter Products Used in Direct Access
MDM - Requirements for Meter Data Management
MI - Requirements for Meter Installation, Testing and Maintenance
MR - Minority Report ?
MS - Meter Specific transactions
VEE - VEE rules
D - Definitions?
Voting records? All Vote items? Just vote items with minority report?