ࡱ> ~yz{4XRoot Entry FW-Ħ#Ŧ2WordDocumentCompObjjSummaryInformation(0p  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~Root Entry FW-Ħ+Ŧ2WordDocument7#'CompObjjSummaryInformation(03  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~L($ Anthony MazyD:\App B 8-11-97.doc@ U, U&U"U::UVVUr"rU U U  U   F%   F%O F%S  F%C F%SA F%45           @HP LJ4 (Here) Non-OA\\Drafuels1\laserjetpostPSCRIPTHP LJ4 (Here) Non-OAHP LJ4 (Here) Non-OAg odXX"0q7JRdܥhW =e+S(D_`!" _: QkL L Xq! 5:#! Custom page 1BBCustom page 2BBCustom page 3BBHP LJ4 (Here) Non-OAthe left are the key entities in the communications model that are clients of the communications process. Also, overlaid on the communications model is an applications model that illustrates the nature of applications of the network. This applications model suggests that there are two classes of application entity to entity applications such as transaction processing, billing and account management, and, communications related applications such as acquisition of metering data, SCADA, and various other applications. The need for timeliness of communications for the first class of applications is typically hours or days, while that for the second class is probably near real-time.  Figure  SEQ Figure \* ARABIC 2 Standard interfaces between entities using communications Figure 2 illustrates the key interfaces where standards may be applied to support the applications model. In this figure are illustrated these interfaces and the identified communicating entities on each side of each interface. For the purposes of this document, the figure illustrates the recommended communications and data format standards available at the interfaces.  AUTONUMLGL 3. Review of requirements This model of access to metering data works through a defined interfaces exposed by the standard interfaces of figure 2. It is designed to support the numerous uses of meter data -- both simple and complex, real-time and archived. Meter data must be represented to several of the new entities Customer, ESC, SC, UDC, and ISO. The information to be exchanged has some common parts and some different parts due to the respective clients need to know. For example, the customer, as the information owner, may be allowed to have access to all information. The UDC may be allowed to have only that information that allows him to manage his distribution system but not do market research on the customer. There are also different kinds of meters, different needs for speed of access, etc.. Also data must be available in raw, validated, and historically archived form. In order to unify these interactions, a common format is to be used. It is advantageous for that format to be one that can be both represented on a database, the MDMA Server, or, through direct communications. What is accomplished by the model is the seamless integration of requirements for access for scada, billing, scheduling, and customer access. The model relies on the UCA 2 and its Common Application Services Model used in conjunction with the data model of IEEE 1377/ANSI C12.19 (Utility Industry End Device Data Tables). This model supports open standards based communications. In addition, the following specific features (complete specifications of course are elsewhere) are valuable to this application: inherent support for the presence or absence of optional parts, support for integration of private custom features, role based application layer security processing, and device oriented data modeling. The balance of this section summarizes the many requirements addressed by the proposed standards suite and a brief comparison to the proposed transitional solution for billing and settlement data.  AUTONUMLGL 3.1. MADAWG/CPUC requirements and constraints The following requirements/constraints for meter modeling have been determined from the MADAWG and CPUC documents and conversations: Scaleable implementation for staged deployment by 1/1/98. Any solution must use predominantly off the shelf software and hardware so as not to jeopardize successful deployment by this date. Role based access each entity such as customer, ESC, SC, UDC, etc.. can have access to data that is filtered by the definition of a role that defines what data can be viewed or changed by the entity in the role. Not predicated on AMR but coexistent with it. Although the CPUC encourages AMR it does not require it for all customers at this time. Therefore, the model needs to support making available automatically acquired data and manually retrieved and/or entered data. Simple access model with minimal data replication. Information should simply be available by query. MDMA is responsible for the integrity of data and communications with the meter. MDMA performs priority mitigation of competing requests. In this responsible role, other data access needs should not be able to pre-empt MDMA activities. Supports selective transfer of minimum data Customer ID, Meter ID, Grid takeout ID, ESP ID, Location, TemplateID, Adjustment Flag, adjustment code, Archival data minimum hourly resolution, tagging of data as to raw, validated, and settlement ready, meter read start / end date Instantaneous (optional), Current period, archival usage 30-60 days hourly minimum could be profiled or actual, adjusted or unadjusted. At a minimum, the usage data provided must be that needed to bill the customer under the customers local regulatory authority-approved UDC/wireco rate schedule and the ISO settlement process. Standards based. Data representation and communications transport should use readily accepted open standards.  AUTONUMLGL 3.2. IEEE 1377/ANSI C12.19 requirements The Utility Industry End Device Data Tables were designed to support the following requirements: Simple to complex meter representation Support for all proposed and in use tariffs Minimal data storage and transport size Can be implemented on a wide range of processors 4 bit/8 bit/16 bit Minimal server implementation Few clients to many servers drives complexity model Support for time tested meter data modeling agreements Simple transport via low cost and limited bandwidth local area networks Covers services broader than meter reading only  AUTONUMLGL 3.3. UCA Common Application Services, CASM, requirements The UCA Common Application Services Model provides the key advantages of standardized and robust access of data. In addition to compact data formats, CASM provides a scaleable architecture for many applications. Built in backwards compatibility is achieved for evolving applications due to unchanging name based data access. A robust event model supports data push allowing the Servers to determine the time and unsolicited presentation of data. The general set of requirements addressed are summarized below. The following summarize the generic application requirements of UCA Common Application Services Model, CASM: Reading/Writing Remote Data Device Control Commands Event Reporting Journaling Security Role and View application layer security model Time Synchronization Management of Remote Devices Network Management Gateway and Adapter Management The following summarizes the object modeling requirements addressed by CASM: Topology, Platform, and Protocol Independent Multicast / Query Support Standardized Data Types, Scales, Units Encryption, Authentication, Secure Views Interoperability and Extensibility Self Description, Inheritance, Aggregation, Polymorphism Tell, dont ask version independent interoperability Client and Server comparable complexity  AUTONUMLGL 3.4. Transitional solution: CSV files / HTTP / Secure Sockets / TCP/IP The proposed transitional solution appears to be an excellent compromise between the short-term requirements of schedule and access for the purposes of exposing billing and settlement data. This set of requirements, however, does not address the long-term needs of the suite of applications a new infrastructure must support. This section, therefore, provides a critical review of this choice as it relates to the longer-term needs. HTTP is a simple, although verbose, protocol used primarily for Internet World Wide Web page transport. However, it is not the universal Internet standard for all transports. Other well formed Internet standards more optimally deal with file transfer (FTP), email (SMTP and POP3), and for transferring real time streams (RTP), for network management (SNMP), for time broadcast (SNTP), and for Network News Transfer (NNTP). There are several advantages of the transitional solution: Widespread availability through ubiquitous WWW browsers available through the retail market Development tools come from Microsoft, as well as many other software tool vendors, etc.. The use of a comma delimited text format facilitates the use of data by unsophisticated organizations that may be part of the initial direct access client base i.e. ESPs. Most data analysis programs such as Microsoft Access and Excel can directly import such files for use. The initial set of information is relatively limited in scope and purpose. The use of the secure sockets layer for TCP/IP (SSL3) allows use of an existing and externally maintained security infrastructure thus simplifying secure access. It is designed to address a single application the exchange of billing data. It is therefore concise and to the point. Disadvantages of extending the transitional solution without the addition of national open standards: Effective use of bandwidth Many low cost methods for communications with meters rely on bandwidth constrained media. The use of ASCII encoding maximizes the use of bandwidth. For example, the transport of a time stamp with one minute resolution in the MEP protocol is 15 bytes (CCYYMMDDHHMM) including delimiting comma (we assume that quotes are not transported). In BER (the encoding of UCA, as well as, Internet protocols such as SNMP) the same information would take 8 bytes and provide 1 millisecond precision. The transport of such data from an IEEE 1377/ANSI C12.19 device can be 5 bytes and is an assumed (not self describing) data format. Communications needs The limited protocol in the HTTP message structure does not provide for efficient real-time transport of small application PDUs. In addition, the authenticated and encrypted message transport using secure sockets provides a single view security model. This requires the custom segmentation of data for clients of different roles, which would need to be added in a potentially non-standard way. Scalability The use of a fixed number of fields for common messages means that all permutations of content for a meter read, for example, must be accounted for in advance. Additional needs or manufacturer customization are not easily provided for without defining completely new message types. The use of a version number, while helpful, requires the user to maintain continuous synchronization of his usage software with the changing versions. Interoperability The use of multiple units for the same physical quantity, and, the use of different numeric formats for integers will require clients to have conversion routines to bring the numbers to a common base (ACFT, CFT, MCF). The model leaves out the definition and transport of many parameters that the meter manufacturers in their AMRA tables have found required characterizing readings from utility to utility and meter to meter. Omitting these variables means that custom software would be required to normalize information from utility to utility or from meter manufacturer to manufacturer. Detail level of model The information defined meets the initial needs of one utility at one point in time. However, there is a substantial amount of information not yet defined for transport. Reporting mechanisms are not defined. Load profile data can only define time boundaries and counts. Missing are events such as meter change-out, calibration changes, and time and power interruptions. Extended services There are many additional services that would be desirable to deploy as part of such a system. For example, real time pricing tier and tier schedules, direct load control messaging, power outage detection, theft of service detection, power quality, to name a few. While it may not be an immediate requirement of to support additional services, it should be recognized that between 90% and 95% of the cost of a remote meter reading service is the deployment and maintenance of a messaging capability. The marginal cost of additional features is small. A robust and easily extensible solution would facilitate the growth of enhanced energy services.  AUTONUMLGL 4. Specific recommendations for use of national standards This section describes the current and projected state of appropriate open national standards. These standards are recommended for use in California as the target of the proposed migration path presented in the next section.  AUTONUMLGL 4.1. Proposed required data and communications standards The recommendation for the adoption of IEEE 1377/ANSI C12.19 and UCA 2 anticipates the dynamics of the new environment. Rather than attempting to standardize every aspect of meter to entity communications, the critical standardization of two points in the communications process is specified. The dream of end to end communications interchangeability is not practical now. Reduced stack communications from customer sites to points of large-scale WAN communications networks is not yet supported directly by a clear choice in standards. It is a subject best left to the competitive marketplace at this time. The IEEE 1377/ANSI C12.19 document is that which defines the meter data model as a set of byte packed, arranged, tables of cross referenced information that taken all together describe the capabilities and dynamic data of the meter. The Common Application Services Model document, describes UCA's generic "data model", acutally a Device Object Model, for representing intelligent electronic devices over a wide area network. The document "CASM Mapping of the IEEE 1377/ANSI C12.19 Tables" essentially maps the CASM Device and object oriented data model to the IEEE 1377/ANSI C12.19 model. The CASM version of the model is supportive of small clients that may want to interoperably and simply use data from the meter without supporting the code to assemble the data from the various tables in the C12 version. CASM provides use of and mapping to the IEEE 1377/ANSI C12.19 Utility Industry End Device Data Tables. The CASM table mapping allows the data from extremely simple meters to be passed as byte streams or as object-oriented data structures. In essence, the C12 data model is ideal for the implementation of low cost, protocol lean, meters. The CASM version adds some more data type abstraction and uniformity, and adds protocol to support various and myriad client applications of the data. Together the two representations team to provide a well-proportioned distribution of computing horsepower in support of applications development. For this reason, the sponsors of this paper specify the standardization of the following points in the communications process: At the meter: the use of a reduced set of minimum required IEEE 1377/ANSI C12.19 tables should be selected as the data format to be obtained from the meter. While not specifying a single transport protocol at this point, the choices should be constrained by those selected for reference by the committee. At some point in the communications topology: a UCA stack should be selected. This point must support the EMeter DeviceModel, and optionally the AMRATable DeviceModel, defined using the terminology of the Common Application Services Model, CASM. The application layer PDUs are encoded in MMS (ISO 9506), and use one of the UCA specified transport protocol stacks (such as TCP/IP, OSI Connectionless, OSI Connection oriented, and several reduced stacks). It is believed that by anchoring these two points of communications standardization, applications are facilitated at the WAN through an interchangeable application layer. In addition, standardizing the data format at the meter and at the WAN provide for two standard anchor points. These points will allow the intervening communications techniques to converge towards successful standardization over time. This, in turn, will finally achieve end to end interchangeability of components and software in the communications process.  AUTONUMLGL 4.2. Robustness and timeliness of the proposed standards This section discusses the maturity of the IEEE 1377/ANSI C12.19 and UCA 2 standards components as they relate to the proposed application domain. First, an historic figure is presented to demonstrate the breadth of time during which these applications have been studied and debated through the open standards process. Following are summaries of the current state of each individually. The figure, which follows, shows the time and effort that has gone into the definition of these standards and attests to their robustness for the proposed applications.  Figure  SEQ Figure \* ARABIC 3 History of UCA and IEEE 1377/ANSI C12.19 standards development As shown in the figure, both UCA and IEEE 1377/ANSI C12.19 have had a significant history of development and trial deployment (Note dates for commercial implementations are approximate).  AUTONUMLGL 4.3. Utility Customer Metering Devices: IEEE 1377/ANSI C12.19 Tables The meter itself, typically needs a minimal capability for the exchange of sensor based data from measurement of commodity consumption at the customer premise. Use of IEEE 1377/ANSI C12.19 metering tables is specified as a base of exchange. A specific subset of the complete tables may be presented as byte oriented table information to minimize cost at the meter. The tables structure methodology was chosen such that the most simple meter registers could function within the boundary of the standard as well as allowing the most complex devices as Real Time Pricing and prepay metering. The rules of passing data are the same even though the data structure of the simple may be 2 bytes vs. 20 kbytes for the complex.  AUTONUMLGL 4.3.1. Implementation experience Several trials and metering applications have been done using IEEE 1377/ANSI C12.19. Among them are the following: PSE&G 1000 home trial in NJ using electric and gas meters Industry Canada provided valuable input to the tables work and has adopted this standard for use in Canada. The Southeastern Electric Exchange has accepted this standard as their guideline.  AUTONUMLGL 4.3.2. Maturity This standard for metering data has been technically stable for several years and editorially approved by ANSI this year. In fact, the underlying concepts behind the tables concept has been utilized by Process Systems for 9 years.  AUTONUMLGL 4.3.3. Product availability Meters implementing C12 are available now or will be in the immediate future from ABB, GE, Schlumberger, Process Systems, Nertec, We-X.L., & American Meter.  AUTONUMLGL 4.3.4. Current course of standard over next 6 months The standards activities are continuing the work toward real time pricing and other near future metering functions.  AUTONUMLGL 4.4. WAN/LAN gateway - UCA => SCC36  AUTONUMLGL 4.4.1. Implementation experience UCA has been deployed in various trials coordinated with EPRIs tailored collaboration programs and other trials. This section summarizes some of this experience.  AUTONUMLGL 4.4.1.1. Trials using UCA protocol stacks, MMS, CASM AMR/DSM DEMONSTRATION BY PUBLIC SERVICE ELECTRIC & GAS COMPANY (completed) PSE&G completed a 1000 home trial in NJ in early 1997. This trial used an early version of CASM, along with a UCA WAN consisting of MMS over TCP/IP (RFC1006), CEBus as a local fieldbus, IEEE 1377/ANSI C12.19 Tables in American Meter Gas, General Electric Electric meters, and Honeywell CEBus thermostats. A custom Hybrid-Fiber-Coax reduced stack network was used from the homes to a broadband WAN from the head end of the cable system. The utility used a broadband WAN from their offices to the cable head end. DA/DSM DEMONSTRATION BY CITY PUBLIC SERVICE OF SAN ANTONIO (ongoing) This project is a DA/DSM application utilizing UCA/DAIS compliant communications operating over a fiber optic cable to connect automated field devices (switches, capacitor controllers, regulators and reclosers), substations and the control center. The communications network also will extend to 100 residential and 25 commercial customers. The customer portion of this project will provide direct load control (DLC), end-use metering and automated meter reading (AMR) for electricity, gas and water. A hybrid fiber optic/coaxial cable communications system will be used for AMR and DLC in urban residential areas and radio communications will be used to communicate with residential customers in rural areas. Fiber cable will be extended in close proximity to participating commercial customers who desire direct fiber service. UCA Objectives Automate two distribution feeders. Install AMR and DLC equipment at selected customer locations, conforming to UCA/DAIS for communication, data storage and retrieval functions. Assist in the population and implementation of DA models in CASM for common distribution automation devices. SUBSTATION AUTOMATION American Electric Power (ongoing) The EPRI Utility Communications Architecture (UCA)/Substation Automation Project began over three years ago, to produce industry consensus regarding substation integrated control, protection and data acquisition, and to allow interoperability of substation devices from different manufacturers. An open process has been followed on this project, to review each major project document and milestone in the open forum of standards-related organizations. There have been over 600 participants in this review process worldwide. In mid-1996 American Electric Power (AEP) hosted the first Utility Substations Initiative meeting, as a continuation of the EPRI UCA/Substation Automation Project. After eight meetings in less than one year, approximately 25 utilities and 15 vendors are participating, having formed vendor/utility teams to define the vendor IED functionality, and to implement a standard IED protocol (UCA 2.0 profile) and local area network protocol (Ethernet). Prototype protocols and topologies have been staged and benchmarked to verify the recommended approaches are based on sound technology. New IED products with this functionality are scheduled to be commercially available in mid-1998. The utilities will provide demonstration sites for the implementation of the new IED products, to occur in the last half of 1998, to demonstrate interoperability between IED equipment from different vendors, and to evaluate and recommend a suitable UCA-compliant substation LAN. The following installations are part of this project: TVA Distribution Substation, 2Q98 American Electric Power Distribution Substation, 2Q98 GPU Distribution Substation, 2Q98 Ontario Hydro Transmission Substation, 4Q98 Boston Edison Distribution Substation, 4Q98 Northern States Power Transmission Substation, 4Q98 American Electric Power Transmission Substation, 1Q99 Commonwealth Edison, Tampa Electric, SOCAL Ed, T.B.D. UCA Objectives: To evaluate and recommend a suitable Utility Communications Architecture (UCATM) compliant substation LAN. To demonstrate the use of this substation LAN technology in one or more pilot projects at one or more designated utility sites. To demonstrate interoperability between IED equipment from different vendors. Implement and test the requirements specified in the EPRI UCA/Substation Automation Project (RP3599) for substation automation  AUTONUMLGL 4.4.1.2. Completed trials using UCA protocol stacks, MMS, ICCP, RDA-DAIS DA/DAIS DEMONSTRATION BY PUBLIC SERVICE ELECTRIC & GAS COMPANY The PSE&G demonstration will evaluate and demonstrate the technology and economics of UCA and DAIS in the PSE&G Electric Systems Operations Center. UCA and DAIS compliant hardware and software will provide a migration strategy to open systems from multiple data links and databases. A distributed database management system for the Generation Energy Cost System (GECS) will be featured. A uniform view of the data system will be provided throughout PSE&G using Oracle and proprietary (non-relational) databases running over UCA compliant RDA/OSI communication stacks, a hybrid RDA/TCP/IP, and proprietary TCP/IP communication stacks. Functional Benefits PSE&G expects to obtain operating flexibility which will permit them to adjust to the rapid changes occurring in the electric utility marketplace caused by deregulation and environmental constraints. The GECS data will be available anywhere within PSE&G's LAN/WAN. The systems developed in this project will be an integral, ongoing part of PSE&G's operations. UCA Objectives The objective of this project is to show that UCA/DAIS concepts are applicable to an on-line operational Energy Management System. Also, this project will demonstrate that UCA increases system and data flexibility with proper system design and implementation. OGLETHORPE POWER CORP. INTEGRATES CONTROL CENTER WITH SCADA Oglethorpe Power Corporation (OPC) is the nation's largest generation and transmission cooperative. OPC's control center communicates with Electric Member Cooperatives (EMCs) for system operation, load control, and distribution management purposes. The company will install, test and evaluate integrated distribution automation with its EMCs through the use of open data communications. This work will employ the following UCA-compliant protocols: - Inter-Control Center Communications Protocol (ICCP). - Master-to-Remote Protocol (MRP). - Master-to-Intelligent Electronic Device Protocol. These protocols all use the Manufacturing Message Specification (MMS), a UCA application level standard. The OPC project is jointly funded by EPRI and the National Rural Electric Cooperative Association. It is a companion to the United Power Association (UPA) effort RP 3674-02, described in a related Project Profile. During the final phase of the project, the OPC and UPA communication systems will be interconnected to demonstrate the interoperability of new protocols. Functional Benefits Presently, communications between the OPC Energy Management System (EMS), and EMCs' Load Management/Supervisory Control and Data Acquisition (LM/SCADA) systems use proprietary protocols. They require proprietary communications interface units, which are data specific, limited in expansion capability, and costly to maintain or expand. This project will develop and test a UCA-compliant interface to replace the proprietary interface units. The new communications system will bring the flexibility and expansion capability of open systems to the daily operations of OPC and its EMCs. UCA Objectives The objective is to demonstrate the exchange of real-time data using UCA-compliant protocols between the: - OPC control center and two or more EMC control centers. - Two EMC control centers and one or more Remote Terminal Units (RTUs) per control center. UNITED POWER ASSOCIATION AUTOMATES & INTEGRATES DISTRIBUTION CONTROL United Power Association (UPA), a Minnesota-based generation and transmission cooperative, is advancing development of UCA-compliant distribution automation equipment and systems. The project will demonstrate substation, feeder, and customer automation functions. This will involve key concepts, described below, that UPA is integrating into its Distribution Automation Master Plan, and Telecommunications Plan. The UPA research project is jointly sponsored by EPRI, UPA and the National Rural Electric Cooperative Association's Rural Electric Research Program. UCA Objectives UPA's project will increase interoperability among substation and distribution-line equipment, communications systems, databases and applications. The approach is to: - Deploy functioning UCA-compliant distribution automation systems that address the needs of UPA member cooperatives (see Table 1). - Provide the market opportunity and integration/test environment for vendors to develop UCA compliant products. - Share project results through press releases, demonstrations, and public information. - Advance the use of international communication standards to increase the functional and economic benefits of distribution automation. NORTHERN STATES POWER AUTOMATES DISTRIBUTION WITH UTILITY COMMUNICATIONS ARCHITECTURE (UCAtm) Project Overview Distribution control systems most often evolve into multi-vendor, multi-product systems. This results in an inability to access accurate, real-time operational data throughout the distribution system, and requires that it be operated with a significant built-in safety margin. Operating a distribution system below capacity is costly. Integration to resolve this problem requires either custom interfacing and programming, or the use of standard interfaces in distribution control development. The volume of distribution field equipment dictates a need for simple maintenance procedures and a high degree of interconnectivity. The ability to replace or upgrade communications devices requires well-defined hardware and software interfaces. UCA offers the greatest potential for solving these problems and providing short and long term benefits. Northern States Power's (NSP) distribution automation system was upgraded using UCA to provide comprehensive remote data and control access through peer-to-peer communications. These enhancements improved the existing distribution system's reliability and load carrying capability without replacing or adding additional electric network equipment. NSP demonstrated that: - UCA protocols can easily link computers and small, inexpensive field devices. - UCA compliant applications can be transferred easily to different operating environments. - UCA and the Manufacturing Message Specification (MMS) offer distribution automation software developers a platform to write flexible applications. - UCA can fit within an established communications operating environment concurrently with proprietary protocols and specialized vendor equipment (e.g. radio). Functional Benefits Integration of NSP field devices and corporate headquarters yielded the following benefits: - Reduced data networking costs - Improved timeliness and accessibility of distribution load data - Improved functionality of capacitor controllers as a result of report-by-exception and peer-to-peer communication among field devices These benefits result from MMS' superior functionality over proprietary Supervisory control and Data Acquisition (SCADA) protocols. It's features include: - Simple, recognizable names and well defined value representations - Off-the-shelf applications that provide a direct, non-proprietary link between field data and corporate applications - Application layer maturity allowing the user to concentrate on data exchange, instead of the protocol details UCA Objectives The project identified the most cost-effective and efficient method for integrating UCA into NSP's distribution communications. Design requirements included: - An application interface using UCA protocols, that supports switched capacitor control - A simple network interface that permits message transfer and network routing with minimal configuration and setup - The ability to retrofit an existing installed base numbering thousands of units The project also defined a migration path for UCA field device deployment and distribution management system development.  AUTONUMLGL 4.4.1.3. Other trials The following utilities have been involved in various tests and implementations of UCA compliant protocols: Georgia Power Company, Kansas City Power & Light, Con Ed of NY, Entergy, PG&E, Philadelphia Electric  AUTONUMLGL 4.4.2. Maturity UCA communications transports are a selection of well-known and massively deployed national and international communications standards including TCP/IP, MMS, OSI connection oriented and connectionless stacks, and various reduced stacks. For device modeling and utility to utility exchange of SCADA data, UCA uses the OSI Manufacturing Message Specification, which can be transported interoperably over all UCA transports. MMS first completed international standardization in 1991 as ISO 9506 parts 1 & 2. The Common Application Services Model has just completed development. CASM does not add protocol to the messaging, and in fact cannot be directly found on the wire. However, it does represent a set of agreements on a constrained and interoperable application of MMS. The meter models of CASM are a direct interpretation of the data in the IEEE 1377/ANSI C12.19 standard. They are a collaborative interpretation between the UCA Forum and the ANSI / IEEE committees. Besides transporting metering data, the UCA Forum is defining models of all major substation and distribution automation devices so that all classes of devices can share a communications infrastructure deployed for metering.  AUTONUMLGL 4.4.3. Product availability  AUTONUMLGL 4.4.3.1. Communications protocol stacks CASM aware MMS tools and implementations are primarily available from three major vendors: SISCO MMS - Provides Client and Server MMS implementations on Wintel, Unix, and embedded controller environments, and, over many transport protocols from TCP/IP to OSI and various reduced stacks and physical layers such as packet radio, Ethernet CYCLE SOFTWARE - Provides MMS implementations and directory services on Wintel and other computing platforms, including some embedded ones. TAMARACK CONSULTING Provides a particularly small footprint MMS implementation for low cost device servers.  AUTONUMLGL 4.4.3.2. Field Devices As part of several EPRI Tailored collaboration projects, the following products have implemented or are implementing UCA (note that these are not necessarily commercially available products. However, these companies have implemented or are implementing UCA compatible versions of their products for the purpose of demonstration of capabilities): Siemens, Process Systems Inc., Electric Meter Beckwith, Load Tap Changer Controller, Voltage Regulator Controller, Relays QEI, RTU Valmet, SCADA Master Rochester Instrument Systems, Inc., Recloser and line monitoring Energy Line, Capacitor Bank Controllers GE/Multilin, Relays Basler, Relays Cooper, Relays Sweitzer, Relays Harris, RTU Siemens, Relays, HMI Bitronics, Substation Meters ABB, Relays Landis & Gyr, RTU, Substation Host Doble, Diagnostic equipment Dranetz/BMI, PW monitoring  AUTONUMLGL 4.4.4. Current course of standard over next 6 months UCA is migrating under the umbrella of IEEE as committee SCC36 over the next few months. Under that umbrella, CASM and the DeviceModels of the various utility working groups will be progressed to IEEE standard status. The balance of UCA 2 communications stacks are already international and national standards. Members of the UCA Forum in conjunction with appropriate vendors groups, standards bodies, and project teams, are developing a robust set of DeviceModels for utility IEDs. In addition, several field trials of communications interoperability are underway for applications of UCA / CASM. Specifically, the Cities Public Service of San Antonio is doing a distribution automation project that will eventually include customer interface this summer. American Electric Power is doing a major substation interoperability project. See project descriptions above for some details.  AUTONUMLGL 4.5. Other potentially applicable standards While not the specific domain of the authors, there are appropriate standards for use in transaction processing and billing applications. These should be pursued by knowledgeable parties over the migration period. In a complete meter reading system, there are many interfaces between different products. For example, the output of some meters is a meter reading in electronic format. Other meters are manufactured with outputs that are only closures of reed switches; the pulses produced by such meters must be totaled and translated into an appropriate electronic format before they can be used. Clearly, these two different products require different interfaces, and a flexible system must accommodate both. The Gas Research Institute initially sponsored a project that addressed how products manufactured by different companies and with a wide range of technical capabilities and output formats can be linked in a single system. This work developed into a reference model that defines a series of service layers and the interfaces between them. This work was subsequently expanded to include a set of meter reading system topologies, as well as gateways, routers, and bridges that link LANs and WANs. The model was developed to include sufficiently many layers that aall existing commercial products have product boundaries that coincide with the interfaces in the AMRA Reference Model. This work is progressing as IEEE 1397, Standard for Standard Reference and Topology Model for Automatic Metering and Related Systems, a key framwork document originally developed by the Gas Research Institute and subsequently extended by AMRA to organize the complete set of interfaces in an AMR system. The Automatic Meter Reading Association continues to develop several standards relating to interfaces to and within the meter itself. These include IEEE P1411 (Interface between Storage Layer and Analysis Layer) and IEEE P1412 (Interface between Physical Element and Storage Layer).  AUTONUMLGL 5. Migration strategy It has been discussed earlier that others have proposed a sufficient transitional solution for exposing billing data by 1/1/98. This section describes a proposed migration strategy and plan that will result in the successful deployment of national standards along side the transitional solution. The following figure illustrates the proposed migration strategy:  Figure  SEQ Figure \* ARABIC 4 Migration Strategy Schematic Diagram The figure illustrates the coexistence of a Web based server application and UCA based object oriented view of the same or similar data in the MDMA server as of 1/1/98. The Web based solution will be the official point of commerce for initial deployment while the UCA capability will be demonstration-only as of 7/1/98. Following and coincident with the deployment of these capabilities, a step by step plan is proposed. This plan will migrate towards appropriate national standards for the exchange of meter data for the many identified purposes (only the billing and settlement application is being deployed as of 1/1/98 through the MDMA server). A proposed implementation plan based on the assumption that ANSI C12.19 and UCA CASM and Meter Data Model are the selected national standards for this purpose. If not, substitution of the adopted standards will be required in the plan outline that follows: Step 1: Existing interval metering, data communications and meter data formats are accepted on 1/1/98 as legacy system implementations. Step 2: Common meter data formats proposed in MADAWG must be utilized by all Direct Access market participants needing to exchange meter data commencing on 1/1/98. Step 3: Establish a technical evaluation process under the auspices of the CPUC to review and assess existing and proposed national standards for Metering, Common Application Services Model and a Meter Data Model for Meter Data Formats relative to their technical merits and applicability to Direct Access in California. This process should focus on achieving its objectives of identifying and selecting suitable standards for the two key data communications and data format interfaces : format at the meter and on the Wide Area Network. If the existing or proposed standards are not suitable in their current state participants should work to enhance to proposed standards to a level of suitability. This effort should be completed by 7/1/98. Step 4: Commence the process for development of implementation agreements for standards selected on 1/1/98. This process is absolutely essential in order to ensure interoperability all products built to the selected standards specifications prior to production and deployment by vendors. This process should be completed by 1/1/99 or 6 months after selection of approved standards. It is anticipated that implementation agreements for the selected standards can be reached in much less than 6 months for some standards, such as ANSI C12.19. Step 5: The following migration to use of IEEE 1377/ANSI C12.19 compliant meters is proposed. All new Interval meters for 20 kW demand or greater customers contracted for installation by a customer or ESP on or after the 24th month after publication of ANSI C.12-19 (no later than 1/1/2000) shall comply with that standard. ANSI C12.19 compliant meters can be installed immediately after agreements have been reached for implementation of the standards and meter manufacturers have production quality and quantity meters available. It is expected that this can occur in the mid-to-late1998 time frame. Step - 6: The following migration to use of UCAs CASM and CASM / C.12.19 mapping is proposed. (i) Develop a CASM meter data format Server(s) in parallel with and to be coexistent with the Common meter data format based servers proposed in MADAWG in Step - 2 described above at one or more MDMA server locations by 8/1/98. Note, the CASM based Server can utilize the same or different computer platforms and operating systems as used by the Common meter data format based Server(s) if desired or beneficial. (ii) Gain experiences with, and understand the operational performance, ease of use, benefits and shortcomings of the CASM based Server(s). (iii) Correct any shortcomings in the CASM based Server and meter data represented by 10/1/98 and make it available for Ad Hoc meter data acquisition by ESPs and other authorized users for Load Bidding, balancing and other uses that require access to data on a daily basis. Step - 7: Develop a simple UCA Client software package that can be used by ESPs and other entities that need to access meter data on an Ad Hoc Basis and are willing to work with the MDMAs participating in the development of a CASM based Server described in Step - 6. (i) Identify any specific needs for linking the meter data to ESP or other entity applications. (ii) Have this UCA Client available for use by 8/1/98. Note, this is a rather simple task as UCA Clients already exist and are in use. Step - 8: Develop UCA - C12.19 Meter Model interface software at selected metering sites. Note, there are several different scenarios, relative to where the software will reside, that may need to be addressed in this step depending on Customer demand, meter manufacturer, type of communications system used (radio, Internet, Phone Line, etc.) The key objective of this step is to have a UCA - C12.19 Interface at the point of attachment of the MDMA communications link to that particular customer. (i) Have the UCA -C12.19 Interface available for testing on 1/1/99. (ii) Evaluate communications and meter data acquisition from the MDMA or MA from 1/1/99 to 3/1/99. (iii) Gain experience with and understand the operational performance, ease of use, benefits and shortcomings of UCA -C12.19 Interface. (iv) Correct any shortcomings in the UCA -C12.19 Interface and meter data obtained by 5/1/99. Step - 9: Develop UCA - MV-90 Meter Model interface software at selected ISO metering sites. Note, there are several different scenarios, relative to where the software will reside, that may need to be addressed in this step depending meter manufacturer, type of communications system used (radio, Internet, Phone Line, etc.) The key objective of this step is to have a UCA - MV-90 Interface at the point of attachment of the ESP communications link to that particular meter. ( i ) Have the UCA - MV-90 Interface available for testing on 3/1/99. (ii) Evaluate communications and meter data acquisition from the MDMA or MA from 3/1/99 to 6/1/99. (iii) Gain experiences with and understand the operational performance, ease of use, benefits and shortcomings UCA - MV-90 Interface. (iv) Correct any shortcomings in UCA - MV-90 Interface and meter data obtained by 8/1/99. Step - 10: Expand the use of CASM meter data format Server(s) to additional MDMAs and expand the use of UCA -C12.19 Meter Interfaces at customer sites from 1/1/99 to 4/31/99. (i) Gain experience with and understand the operational performance, ease of use, benefits and shortcomings of the CASM meter data format Server(s), UCA -C12.19 Meter Interfaces and data communications sub-systems throughout this period. (ii) Correct any shortcomings in any of these elements and correct by 7/1/99. Step - 11: Work with meter manufacturers to develop and build UCA compliant meters for use at sites serving customers with a demand of 20 kW and above. Note, this can be accomplished with inclusion of UCA -C12.19 Meter Interface software in the meter itself or ultimately as a native interface in the meter. (i) Target availability of meters for 1/1/2000 and beyond. Step - 12: All new meters to be installed after 1/1/2000 for customers with a demand of 20 kW or greater shall be compliant with C12.19 and a shall include a UCA -C12.19 Meter Interface for connection to the data communications system employed by the MA or MDMA. (i) Any new metering or data communications products or services that will be utilized after 1/1/2000 must be scalable to serve the entire California marketplace. (ii) All new metering or data communications products or services that will be utilized after 1/1/98 shall be interoperable with each other. (iii) All new meter data and meter data format software provided after 1/1/2000 shall be implemented in an extensible manner. Users of the data (ESP, SC, UDC, Customer, etc,) shall not be required to change the software every time new information is provided by any other provider (MA, MDMA, Meter) of information.  AUTONUMLGL 6. References: EPRI, Draft Input for the Utility Communications Architecture Version 2.0: Common Application Service Models (CASM) and Mapping to MMS, April 30, 1997 EPRI, Draft Input for the Utility Communications Architecture Version 2.0: CASM: Guide to Device Modelers, April 30, 1997 EPRI, Generic Object Models for Substation & Feeder Equipment (GOMSFE) Draft, Version 0.4, April 30, 1997 AMRA, Utility industry end device data tables: Tables Version 0.1, Document version 1.9, AMRA/IEEE SCC31 End Device/TIU subcommittee, January 8, 1996 EPRI, CASM Mapping of the ANSIC12.19 Tables, Version 0.3, Draft CIWG Work in progress of the EPRI UCA Forum, June 8, 1997 PG&E, PG&E Metering Exchange Protocol, Version 0.11, April 22, 1997 IEEE Draft, IEEE Standard for Standard Reference and Topology Model for Automatic Metering and Related Systems, March 25, 1995 APPENDIX: Objects, Bits, & Bytes  AUTONUMLGL 7. Using CASM for representing meters This section describes the application interface achieved by the use of CASM for interactions with a meter along with IEEE 1377/ANSI C12.19 tables represented in the meter. Herein the reader can find a more detailed view of the recommended communications model.  AUTONUMLGL 7.1. MDMA Access model The prime goal of the model is to have a representation of the meter that is fairly constant with regard to access method. This means that whether the user is interacting with a database on a server or a live meter, they are presented with the same view of a logical meter.  Figure  SEQ Figure \* ARABIC 5 Meter Data Management View as Logical Meter As shown in the figure, all applications see the meter. Each meter is initially identified by a unique identifier. That identifier can be used to access, or look up, other information for the instance of the meter. The principal difference of whether they see it live or Memorex is their point of communication. The Server based meter model contains a full history e.g. 3 years hourly data as well as the presence of validated and settlement ready data. Each entity that has access to either the Server or the live meter represents itself as having a role in the network. The view obtained of the meter in all cases is filtered based on the defined constraints for that role.  AUTONUMLGL 7.2. The Common Application Services Model  AUTONUMLGL 7.2.1. Modeling of metering devices This section introduces the principal concepts of the UCA view of devices, and specifically, metering devices. The detailed UCA meter model is only presented in outline form in this paper. More detailed descriptions are in the next section and the references. The UCA Common Application Service Models, CASM, provide a common set of communications functions (data access, data reporting, data logging, control functions, etc.) which are found in most real time utility field devices. The use of a standardized set of application services allows for: Isolation of the modeling efforts from the communications details High degree of application interoperability, not just in the message syntax but also in the semantics of the data exchanged. Reduced integration costs, in that there is a consistent access and representation mechanism across all of the real time data. CASM provides the ability to have a communications independent view of devices. This facilitates interoperability for interacting with devices represented by CASM without consideration of the underlying communications means. UCA 2 provides a rich set of open standard and field proven methods for transporting messages according to this representation. As mentioned earlier, these transport methods include TCP/IP, OSI 7 layer, and reduced stacks. The UCA 2 Common Application Services Security Model supports the ability for different role players to achieve a tailored security view of the model. This is accomplished independent of actual security encryption or authentication mechanism. In essence all messages passed to a CASM application layer are accompanied by a role identification that indicates which set of access keys were used to validate and decode the message. The CASM SecurityAgent model provides the infrastructure for this role-based view of the models.  AUTONUMLGL 7.2.2. CASM Overview In CASM objects, that are directly accessible by a Client through a network, are contained in an object from the Server class. The Servers, and the object instances that they contain, are mapped to the UCA communications protocols through the procedures defined in the UCA 2 documents. Network visible objects within a Server that model device behavior inherit from the classes LogicalDevice, DataObject, and DataSet, described in this section. In addition, three special classes that inherit from DataObject are DI (DeviceIdentity) which contains nameplate information, DeviceModel which is the representation of the complete device function, and, FC, FunctionalComponent, which groups common components of device functionality in an easy to use form when used inside a DeviceModel. The figure following is a conceptual model of the Communications Server as represented by CASM (this figure illustrates the composition of the model but omits many details for simplicity). As shown in Figure 5, the Server consists of one or more LogicalDevices, LD (e.g. M1234). Each LogicalDevice contains one DeviceIdentity, DI, one (typically) or more DeviceModels, DM (e.g. EMeter) , and zero or more DataSets, DS (e.g. EMeter.DS.Bill). These principal components will be discussed next. Each DeviceModel contains a set of FunctionalComponents, FCs (e.g. EMeter.CF, EMeter.MX), which in turn contain sets of simpler DataObjects, DO, (EMeter.MX.W.r, ), which represent the behavior of the modeled device. FunctionalComponents group together information of a common purpose for ease of access. Common FCs include MX, for measurements, CF, for configuration information, ST, for status information, LG, for event and logging information, and so on. The use of LD, DO, DM, DI, FC, and DS as abbreviations for the longer names simplifies tables and will be used interchangeably from this point forward. The DMs are described in the UCA Forum working group modeling documents and are templates for making objects that exhibit the desired communications behavior. In this regard, the EMeter DeviceModel is not an EMeter, but is the blueprint for an EMeter. To make an object of the model, one needs to instantiate it. The act of instantiating an EMeter is like building an EMeter from a set of blueprints. There are working groups within the UCA Forum defining customer interface devices (meters, ), distribution automation devices, substation devices, and power plant devices. The EMeter Object is created according to the specifications of the EMeter DeviceModel template and is placed in a virtual version (representation) of an electronic device, a LogicalDevice. However, just like placing a single board computer in an electrical enclosure in order to mount it to facilitate its use, an EMeter object is placed in a container to facilitate its use for communications purposes. The container for the EMeter object (and any other DeviceModel instance) is a LogicalDevice. Similar to the enclosure that houses the circuit board, the LogicalDevice does not externally reveal much about the nature of whats inside. It is only by using or browsing whats inside that makes the functionality of the assembly apparent (to a client device).  Figure  SEQ Figure \* ARABIC 6 CASM Meter device modeling classes and their relationship to objects As with most electronic enclosures, LogicalDevices have a nameplate that list make/model/serial number and other related information. Typically nameplates deal with information that is independent of the purpose of the device. The nameplate class for CASM is the DeviceIdentity, DI. Therefore, the LogicalDevice contains a nameplate and some contained functionality. In CASM the nameplate is an instance of the DI class, and, the functionality is an instance of one or more DMs. Finally, DataSets, DS, represent lists of references to DOs that can be accessed by a single name in communications. The principal advantage is that, for these common groupings, a simple short message can request a substantial amount of selected information. DataSets are also used to describe lists of information for incorporation into reports.  AUTONUMLGL 7.2.3. CASM Security model The CASM application layer security model is based on the model of secured views. These views are determined by a combination of the methods and key parameters used in the lower layer authentication / encryption procedure, and, the asserted role of the client which is also passed up to the application layer. Based on the asserted and then validated role, the LogicalDevices contained within the Server can be said to have a secured View. With the predetermined access permissions for read/write/execute/create/delete for each component of the LogicalDevices that have been set up for the view, the client can obtain an appropriate level of access. Due to the hierarchical nature of the models of devices provided by CASM, this mechanism allows for the strategic regulation of access at relatively few points in any given model. Based on the complexity of the device modeled, and the degree of complexity of the secured access needs from few to many regulation points. The CASM model specifies how this works but not how its implemented or used. By this means, a wide degree of interoperability is achieved for a limited investment in programming. One final point, since the operation of the security model is independent of the data model, interoperability is maintained independent of the individual choices made by different vendors or different product instances regarding security. That is, a secured and unsecured device will respond the same way to the same message that was accompanied by a sufficient role for the secured device.  AUTONUMLGL 7.2.4. Minimal meter model example for direct access These representations are used to provide a complete communications description of field devices. The following summarizes their use in representing metering devices: Server Represents the communications point TimeAgent Time of day maintenance in server SecurityAgent Provides role based access to Logical Devices in Server maintains keys and role descriptions. LogicalDevice Encapsulates the virtual representation of a single device DI Device Identity nameplate information for meter Contains Customer ID, Meter ID, Takeout ID, ESP ID, Location, TemplateID, Location, Vendor name, serial number, EMeter DeviceModel of electric meter functions EMeter.CF.W Current consumption configuration W, WH, scale, etc.. EMeter.MX.W Current consumption measurement W, WH, time stamps, data quality (raw, validated, settlement) EMeter.LG.W Consumption data periodic logging 5 min -> 1 hour EMeter.EV.W Consumption logging event generation EMeter.EV.Bill Bill event generation start and end of period value recording EMeter.RP.Bill Bill report generation publishes end of period billing info report EMeter.DS.Bill Lists components in EMeter to incorporate in billing report EMeter.DS.Stat Lists components in EMeter to incorporate in status report  AUTONUMLGL 8. APPENDIX: Model details and some real packets This section provides an illustration of the nature of the metering data representations in IEEE 1377/ANSI C12.19 and UCA CASM. A simplified model is used to facilitate the discussion. Actual implementations by manufacturers of meters and communications systems would be similar but complete. The following subsections are presented: MEP Meter Data Records: Illustrate a rough correspondence between the data described in the PG&E Metering Exchange Protocol. UCA EMeter model for generic meter and mapping to C12 subset: An hypothetical meter model in CASM and ANSI C12 that would support the generation of the data needed for revenue metering in field devices. Example of API interface to CASM services: A summary description of a programming interface that would allow for simple application development using Microsofts ATX control technology. Sample messages: Some sample messages at the UCA Server and at the meter used to obtain the data.  AUTONUMLGL 8.1. MEP Meter Data Records The following is an approximate mapping of the data in the MEP records to that in the UCA/ IEEE 1377/ANSI C12.19 meter model. CASM MappingMEP FieldDescriptionClass or TypeUCA NameRecord TypeMEPMD01vstr32Record VersionDate CCYYMMDD 19970401UCAVerAccount identifierCustomer IDvstr32DI.UtilID.CustIDESP IdentifierESP identifiervstr32DI.UtilID.EspIDESP customerAdditional customer identifiervstr32DI.UtilID.EspCustIDPurposeReason for record OK, RESEND, SUMMARY, HISTORYCommodityWhich utility G,E,WSee unit of measureUnit of measureREGISTER, PULSE, KWH, THERMuEmeter.CF.W.uCalculation constantMultiplier of measurementssEmeter.CF.W.sIntervalDefault interval between measurementsInt16uMeter.CF.Dmd.IntvlCountNumber of recordsInt16uMeter.CF.LP1.NumBlkIntvl, Number of blocksData Array of data recordsMeter.MX.LP1Data[i].tTime stampBtime6Data[i].qData quality E,V,A,C,N,RqData[i].fFloating point data iMEP FieldDescriptionClass or TypeUCA NameRecord TypeMEPMD02vstr32Record VersionDate CCYYMMDD 19970401UCAVerUCAVer.Account identifierCustomer IDvstr32DI.UtilID.CustIDESP IdentifierESP identifiervstr32DI.UtilID.EspIDESP customerAdditional customer identifiervstr32DI.UtilID.EspCustIDPurposeReason for record OK, RESEND, SUMMARY, HISTORYCommodityWhich utility G,E,WSee unit of measureUnit of measureREGISTER, PULSE, KWH, THERMuEmeter.CF.W.uCalculation constantMultiplier of measurementssEmeter.CF.W.sCountNumber of recordsInt16uMeter.CF.LP1.NumBlkIntvl, Number of blocksDataArray of data recordsData[i].labelTOU label TOTAL,ON-PEAK, OFF-PEAK, PART-PEAK, PART-PEAK-2, PART-PEAK-3, PART-PEAK-4qData[i].qData quality E,V,A,C,N,RqData[i].fFloating point data rTable  SEQ Table \* ARABIC 1 MEP to CASM Mapping for Metering Data  AUTONUMLGL 8.2. UCA EMeter model for generic meter and mapping to C12 subset The following is a hypothetical implementation of a meter that has a small set of features to support revenue metering of a single phase service with hourly load profile. The WAN view of this data would be CASM as shown on the left side. The meter itself would be an IEEE 1377/ANSI C12.19 compliant device with a minimal set of tables to support the revenue-metering task. Some of the variables are directly taken from the meter in the application. Those that are not labled might be constructed from meter reads in a concentrator. NameDescriptionClass or TypeANSI C12.19 nameDI.ClassProduct classificationVstr32Default_set_usedDI.LocLocationVstr128Coordinate_1,2,3DI.InvIDInventory ID (Meter ID)Vstr32Device_idDI.VndIDVendor ID structureVndIDDI.VndID.VndManufacturer nameVstr6ManufacturerDI.VndID.SerNumSerial number (contains MFG name)Vstr32Mfg_serial_numberDI.UtilID.DivUtility divisionVstr32Utility_divisionDI.UtilID.SvcPtService point (Grid Takeout ID)Vstr32Service_point_idDI.UtilID.ElecAdrElectrical address grid and feederVstr32Elec_addrDI.UtilID.TarifIDTariff IDVstr32Tariff_idDI.UtilID.ESPIDESP IDVstr32DI.UtilID.TmpltIDTemplateIDvstr32DI.CustIDCustomer IDvstr32Customer_idEMeter.CF.SrcFlgsSource flags in useMeterSrcFlgs (bstr16)Source_flagsEMeter.CF.RegFuncsRegister functionsMeterRegFuncs(bstr16)reg_func1_bfld, reg_func2_bfldEMeter.ST.EnableEnabled for normal operationboolMetering_flagEMeter.ST.StatusGeneric status of Meterbstr16ed_status_1EMeter.CO.EnableControl of enableboolMetering_flagEMeter.CO.StatusClear generic status of Meterbstr16Clear status flagsEMeter.CO.WControl of WstructEMeter.CO.W.fzFreeze of accumulator (W.r)boolEMeter.MX.Wload center wattsstructEMeter.MX.W.iload center watts, instantaneousint16sEMeter.MX.W.qdata qualitybstr16EMeter.MX.W.rload center watts, totalint48dEMeter.MX.W.frfrozen readingint48dEMeter.MX.W.ftfrozen timestampbtime6EMeter.MX.W.startBillRstart of billing pd rint48dEMeter.MX.W.endBillRend of billing pd rint48dEMeter.MX.W.startBilltstart of billing pd tbtime6EMeter.MX.W.endBilltend of billing pd tbtime6EMeter.CF.Wload center watts configstructEMeter.CF.W.sscaleflt32EMeter.LG.Wlog of readingsLCBEMeter.DS.Billdata set for report of WATTs MonitoringDSEMeter.EV.BillBilling ECBECBEMeter.EV.MonMonitoring 15min or hourly lpECBTable  SEQ Table \* ARABIC 2 Extract from CASM EMeter model Bit definitions of SrcFlgs: BitName1Power fail aftermath exclusion2Reset exclusion3Block demand support4Sliding demand support5Thermal demand support6-15Bit definitions of RegFuncs: BitName1season info field flag2date time field flag3demand reset counter flag4demand reset lock flag5cumulative demand flag6continuous cumulative deman7time remaining flag8self read inhibit overflow flag9self read sequence number flg10daily self read flag11weekly self read flag12self read demand reset13-15Reports Billing cycle report EMeter.DS.Bill = { DI.CustID, DI.InvID, DI.UtilID.ESCID, DI.UtilID.TmpltID, DI.UtilID.TarifID, DI.UtilID.SvcPt, DI.Loc, EMeter.MX.W.startBillR, **** needs to be array for tou billing byt tier EMeter.MX.W.endBillR, **** needs to be array for tou billing byt tier EMeter.MX.W.startBillt, EMeter.MX.W.endBillt, EMeter.CF.RegFuncs, }  AUTONUMLGL 8.3. Example of API interface to CASM services The services described in this section are an example of a possible API that could be used in WINTEL environments to use CASM. The preferred implementation might be as ActiveX Control for Microsoft Windows 95 / WinNT. With this tool, simple applications development can be achieved.  AUTONUMLGL 8.3.1. ActiveX Control Example as API for CASM interaction The following describes a possible API for use in interacting with remote devices exposed using UCA and CASM. Given such an interface, and the nomenclature for meter data, simple programs can written to interact with the LogicalDevices over a network. Such a control could be used locally via appropriate programming tools, or remotely, as part of a Web based server. Properties BSTR ArName; // String version of local address BSTR User; // Users ID BSTR Pw; // Users PW short TxChannel; // Transmit channel # for UCA Stack short RxChannel; // Receive channel # for UCA Stack short Role; // Security role of user boolean IsClient; // Flag shows if this is client or server BSTR RemoteServer; // String remote address Methods short // error return GetDataObjectValues( // used to read DataObjects BSTR RemoteServer, // String remote address VARIANT* ListOfDOReference, // list of DataObjects to read long* ResponseID, // use to match up response boolean WithNames); // return object names with data short // error return SetDataObjectValues( // use to write DataObjects BSTR RemoteServer, // String remote address VARIANT* ListOfDOReference, // list of DataObjects to write long* ResponseID, // use to match up response VARIANT* ListOfData, // list of data to write boolean Confirmed); // is confirmation returned? short // error return RspGetDataObjectValues( // return a response as server short ECode, // error code for response long ResponseID, // response id VARIANT* ListOfData, // list of read data VARIANT* ListOfNames); // optional list of names short // error return RspSetDataObjectValues( // return a response as server long ResponseID, // response ID VARIANT* ListOfResult); // list of results of writes short // error return Open(); // open UCA communications short // error return Close(); // close UCA communications Events void OnRspSetDataObjectValues( // see RspSetDataObjectValues short ECode, long ResponseID, VARIANT* ListOfResult); void OnRspGetDataObjectValues( // see RspGetDataObjectValues short ECode, long ResponseID, VARIANT* ListOfData, VARIANT* ListOfNames); void OnGetDataObjectValues( // see GetDataObjectValues BSTR RemoteServer, VARIANT* ListOfDOReference, long* ResponseID, boolean WithNames); void OnSetDataObjectValues( // see SetDataObjectValues BSTR RemoteServer, VARIANT* ListOfDOReference, long* ResponseID, VARIANT* ListOfData, boolean Confirmed); void OnReportDataObjectValues( // Unsolicited report BSTR RemoteServer, // Remote server source VARIANT* ListOfDOReference, // List of data reported long* ReportID, // Characterize Report VARIANT* ListOfData); // Data contents void Error( // stock error return short Number, BSTR* Description, SCODE Scode, BSTR Source, BSTR HelpFile, long HelpContext, boolean* CancelDisplay); void OnLogPDU( // raw PDU for optional logging short Length, BSTR Data);  AUTONUMLGL 8.3.2. Visual Basic code to obtain meter reading In order to use an interface such as that presented, a fairly basic coding can be used (since the control does all dirty work). For example, in Visual Basic, the code to implement a meter reading might look like this: Subroutine ReadTheMeter Dim ListOfDOReference(10) As Variant Names of data to read Dim ListOfNames(10) As Variant Names of data returned Dim ListOfData(10) As Variant List of data returned Dim id As Long ID of single request message Dim vt As Variant transfer variable Set list of data to read ListOfDOReference(0) = "M1234/EMeter.MX.W.r" get accumulator value ListOfDOReference(1) = "M1234/EMeter.CF.W.s" get meter scale vt = ListOfDOReference Open UCA communications channel Uca1.Open Send read to communications process err = Uca1.GetDataObjectValues("uca.remoteServer.com", vt, id, True) If (err != OK) then do error processing End IF Wait for response (calls DoEvents) It is assumed that the OnRspGetDataObjectValues event will populate ListOfData, ListOfNames with results of read while (WaitForResponse(id, ListOfData, ListOfNames)) Use response data ExportResultsToFileAsCSV(ListOfData, ListOfNames) . Close communications Uca1.Close End Subroutine  AUTONUMLGL 8.4. Sample messages This section provides some examples of actual message packets using the protocols for those who like to see the bytes on the wire.  AUTONUMLGL 8.4.1. IEEE 1377/ANSI C12.19 meter reading samples The sample message here is a trace of a CEBus power line meter read of a Meter: Read the total value of accumulated consumption (total pulses), <8A 0829 05B9 3001 8001 50 ED 50 02 82 F4 38 F6 00 17 00 00 01 00 04 00 >8A 3001 8001 0829 05B9 50 D5 FE F4 34 F6 00 01 e2 40 Analysis of packets: Request 8a 3001 8001 50 ed CEBus message header 50 02 82 Use Tables Context 50, Object 2, Macro 82:Read Partial Table f4 38 f6 Table request has 8 bytes 00 17 Table 23 00 00 01 00 Offset 1 byte 04 00 Count 4 bytes Analysis of packets: Response 8A 3001 8001 0829 05B9 50 D5 CEBus message header FE CEBus success code F4 34 F6 Table response has 4 bytes 00 01 e2 40 4 byte meter reading = 123456 Read the scale factor (WH/Pulse) <89 0829 05B9 3001 8001 50 ED 50 02 82 F4 38 F6 00 0F 00 00 00 00 03 00 >89 3001 8001 0829 05B9 50 D5 FE F4 33 F6 00 02 58 Analysis of request packet: Similar to above Analysis of packets: Response 8A 3001 8001 0829 05B9 50 D5 CEBus message header FE CEBus success code F4 33 F6 Table response has 3 bytes 00 02 58 Scale factor = 600WH / pulse  AUTONUMLGL 8.4.2. UCA CASM samples UCA CASM messages, when mapped to MMS appear on the communications link as MMS PDUs. The following examples show the MMS confirmed PDUs. Omitted are the TCP/IP packets containing them. Read the total value of accumulated consumption (total pulses) (MMS in ASN.1): cnf-ReqPDU { invokeID 1, read { specificationWithResult TRUE, variableAccessSpec listOfVar { { variableSpec name domain-specific { domainID "M1234", itemID "EMeter$MX$W$r" } } } } } cnf-RspPDU { invokeID 001, read { listOfAccessResult { success integer 0123456 } } } Actual bytes on the wire (Application PDU only): Request: a0 28 02 01 01 a4 23 80 01 ff a1 1e a0 1c 30 1a a0 18 a1 16 1a 05 4d 31 32 33 34 1a 0d 45 4d 65 74 65 72 24 4d 58 24 57 24 72 Response: a1 0c 02 01 01 a4 07 a1 05 85 03 01 e2 40 Analysis of packets: Request a0 28 MMS Confirmed Service PDU 02 01 01 Invocation ID a4 23 Read Service 80 01 ff Specification with result(False) a1 1e variable access specification a0 1c list of variable 30 1a a0 18 variable specification a1 16 domain specific 1a 05 4d 31 32 33 34 DomainID=M1234 1a 0d 45 4d 65 74 65 72 24\ 4d 58 24 57 24 72 NamedVariable= EMeter$MX$W$r Analysis of packets: Response a1 0c Confirmed response 02 01 01 Invocation ID a4 07 Read response a1 05 listOfAccess Result 85 03 01 e2 40 (success) Integer value 0123456 Read the total value of accumulated consumption (total pulses), and scale factor in single read (MMS in ASN.1): cnf-ReqPDU { invokeID 1, read { specificationWithResult TRUE, variableAccessSpec listOfVar { { variableSpec name domain-specific { domainID "M1234", itemID "EMeter$MX$W$r" } }, { variableSpec name domain-specific { domainID "M1234", itemID "EMeter$CF$W$s" } } } } } cnf-RspPDU { invokeID 001, read { listOfAccessResult { success integer 0123456, success floating-point '00000001'H } } } Actual bytes on the wire (Application PDU only): Request: a0 44 02 01 01 a4 3f 80 01 ff a1 3a a0 38 30 1a a0 18 a1 16 1a 05 4d 31 32 33 34 1a 0d 45 4d 65 74 65 72 24 4d 58 24 57 24 72 30 1a a0 18 a1 16 1a 05 4d 31 32 33 34 1a 0d 45 4d 65 74 65 72 24 43 46 24 57 24 73 Response: a1 12 02 01 01 a4 0d a1 0b 85 03 01 e2 40 87 04 00 00 00 01 Direct Access: National Standards based communications  DATE \@ "MM/dd/yy" 08/11/97 TIME \@ "h:mm AM/PM" 7:08 PM  PAGE 1 AMRA/EPRI/ORA Tech Annex  /=.........)()()/=xx??????????????/=??????????????/=??????????????B:&~'  !6&L8 &&TNPPb=Pu & TNPP &&TNPP   v "---  @TTimes New Roman|-. Times New Roman-.  "- Ot t ~t- -  $ ##  $,,//  $88;;  $DDGG  $PPSS  $\\__  $hhkk  $ttww  $||  $||  $||  $||  $||  $||  $||  $||  $ttqq  $hhee  $\\YY  $PPMM  $DDAA  $8855  $,,))  $   $    $    $    $    $    $    $    $  -- - B-  $E B B#E#  $E,B,B/E/  $E8B8B;E;  $EDBDBGEG  $EPBPBSES  $E\B\B_E_  $EhBhBkEk  $EtBtBwEw  $I|ILL|  $U|UXX|  $a|add|  $m|mpp|  $y|y|||  $||  $||  $||  $uurr  $iiff  $]]ZZ  $QQNN  $EEBB  $9966  $--**  $!!   $    $    $    $ ||   $s spp   $g gdd   $[ [XX   $O OLL -- \  & --"Systemn-@)-  $h'e'e*h*  $h3e3e6h6  $h?e?eBhB  $hKeKeNhN  $hWeWeZhZ  $hcecefhf  $hoeoerhr  $h{e{e~h~  $heeh  $heeh  $heeh  $heeh  $heeh  $heeh  $heeh  $heeh  $heeh  $heeh  $heeh  $h e eh  $heeh  $h#e#e&h&  $h/e/e2h2  $h;e;e>h>  $hGeGeJhJ  $hSeSeVhV  $h_e_ebhb  $hkekenhn  $hwewezhz  $heeh  $heeh  $heeh  $heeh  $heeh  $heeh  $heeh  $heeh  $heeh  $heeh  $heeh  $hee h   $heeh  $hee"h"  $h+e+e.h.  $h7e7e:h:  $hCeCeFhF  $hOeOeRhR  $h[e[e^h^  $hgegejhj  $hsesevhv  $heeh  $heeh  $heeh  $heeh --'--@)-  $''**  $3366  $??BB  $KKNN  $WWZZ  $ccff  $oorr  ${{~~  $  $  $  $  $  $  $  $  $  $  $  $    $  $##&&  $//22  $;;>>  $GGJJ  $SSVV  $__bb  $kknn  $wwzz  $  $  $  $  $  $  $  $  $  $  $  $    $  $""  $++..  $77::  $CCFF  $OORR  $[[^^  $ggjj  $ssvv  $  $  $  $ --'--@)-  $''**  $3366  $??BB  $KKNN  $WWZZ  $ccff  $oorr  ${{~~  $  $  $  $  $  $  $  $  $  $  $  $   $  $##&&  $//22  $;;>>  $GGJJ  $SSVV  $__bb  $kknn  $wwzz  $  $  $  $  $  $  $  $  $  $  $  $    $  $""  $++..  $77::  $CCFF  $OORR  $[[^^  $ggjj  $ssvv  $  $  $  $ --' &Times New Roman-.  2 ,FPublicTimes New Roman|-.  2 hFWAN or private .$$   Times New Roman-.  $2 Flarge scale network  $Times New Roman|-.  2 h7Reduced Stack or!  Times New Roman-.  2 7 bandwidth WAN# .$#Times New Roman|-.  2 , Local area   Times New Roman-.  2 hpremises&Times New Roman|-.  2 network$ "-- Times New Roman-.  2 ]Wan/Lan gateway.   $Times New Roman|-.  *2 )sUtility/Customer device# ! & Times New Roman-.  (2 Other premises devices# &  ---  "---'-  $ --6 "-6--'-  $ --a<B "-YB4--'-  $62*BTimes New Roman-.  4 2 \MDMA,#,$Times New Roman|-.   2 tUDC#$!Times New Roman-.   2 [SC!Times New Roman|-.   2 tISO# "-- MtTimes New Roman-.  62 Wan / Wan reduced stack gateway.  /    $ ---[ "-[--'-  $X]fO "--qTimes New Roman-.  [2 Billing! Times New Roman|-.  $2 Accounte management# &'---@{ "-y--'-  $X --B@ "-<--'-  $/5/^ "--Times New Roman|-.  <!2 ,Meter data access,   Times New Roman-.  !2 hReal time pricing! &  Times New Roman|-.  $2 Direct load control#  Times New Roman-.  +2 Enhanced energy services   "- %V+---@f "-NdN--'-  $r?lNr]CN --@  "-NN--'-  $]N?)NTimes New Roman-.  N2 Applications#Times New Roman|-.  2 Communications#)) ---@) "-JJ#--'--@# "-!--'--@ "---'--@ "---'--@ "---'--@ "-##--'--@} "-J{J--'--@-  $ILLI  $ILLI  $ILLI  $ILLI  $ILLI  $ILLI  $ILLI  $ILLI  $ILLI  $ILLI  $IL L I  $ILLI  $IL"L"I  $+I+L.L.I  $7I7L:L:I  $CICLFLFI  $OIOLRLRI  $[I[L^L^I  $gIgLjLjI  $sIsLvLvI  $ILLI  $ILLI  $ILLI  $ILLI --'--@ "-JJ--'--@^ "-J\J--'--@ "-JJ--'&TNPP &-- Y:7." , &WordMicrosoft Word  r  -@Times New Roman- &I&f u "--%qq%ii "--&&   "--%%  --&&  "--%%--&&B Q "--%MM%EE--&- "-<--,!).2 )rCustomer !./.2 /rPremises! .'-->M-- k- .2 rMeter% .'--<--,j- .2 rMeter% ..2 rAgent .'----;- R.2 RrMDMA%%.'--g--v- .2  rData Users  .@WingdingsZ- 2 rn@"Arial-. 2 r ,.-.2 rESP.r'- 2 rn-. 2 r ,.-.2 rUDC.r'- 2 Drn-C. 2 Cr ,.-C.2 CrISO.r'- 2 vrn-u. 2 ur ,.-u.2 urCustomer !.r''----v- .2 rMeter% ./.2 /rSocket .'----- ).2 )rMeter% .-3.2 -3rData ._.2 _rFormats! .'--Zi--<- .2 rMeter% .-.2 -rRaw Data  .].2 ]rTransfer ..2 rFormats! .'----- &.2 &rMeter% .-.2 - rData Storage   .]9.2 ]9rand..2  rDistribution    ..2 rFormats! .'----/- c. 2 crCommunications!!  .A.2 A rBoundaries .'------ a. 2 arCommunications!!  .A.2 ArEntities .'& P "--%M-- $---&&K| "- -%M]- - $Uya--&&K "- -%M - - $--&&KL "- -%M+ - - $'I+--&& "- -%- - $--&& "- -%- - $--&&+ "- -%=- - $1-L--&& "- -%- - $u--&& "- -%- - $--&- "- -- ,- -.2 - rANSI C12.19  .'- "- xi-- g,z- +~.2 +~ rUCA/CASM/ % .]}.2 ]} rANSI C12.19  .'&--$ $      $   $ $ $ !  !!"""$ '&%%&''((($ -,++,--...$ 3211233444$ 9877899:::$ ?>==>??@@@$ EDCCDEEFFF$ KJIIJKKLLL$ QPOOPQQRRR$ WVUUVWWXXX$ ]\[[\]]^^^$ cbaabccddd$ ihgghiijjj$ onmmnooppp$ utsstuuvvv$ {zyyz{{|||$ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $          $ $ $ $ #"!!"##$$$$ )(''())***$ /.--.//000$ 5433455666$ ;:99:;;<<<$ A@??@AABBB$ GFEEFGGHHH$ MLKKLMMNNN$ SRQQRSSTTT$ YXWWXYYZZZ$ _^]]^__```$ edccdeefff$ kjiijkklll$ qpoopqqrrr$ wvuuvwwxxx$ }|{{|}}~~~$ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $       $ $ $    $ %$##$%%&&&$ +*))*++,,,$ 10//011222$ 7655677888$ =<;;<==>>>$ CBAABCCDDD$ IHGGHIIJJJ$ ONMMNOOPPP$ UTSSTUUVVV$ [ZYYZ[[\\\$ a`__`aabbb$ gfeefgghhh$ mlkklmmnnn$ srqqrssttt$ yxwwxyyzzz$ ~}}~$ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $      $   $ $ $ !  !!"""$ '&%%&''((($ -,++,--...$ 3211233444$ 9877899:::$ ?>==>??@@@$ EDCCDEEFFF$ KJIIJKKLLL$ QPOOPQQRRR$ WVUUVWWXXX$ ]\[[\]]^^^$ cbaabccddd$ ihgghiijjj$ onmmnooppp$ utsstuuvvv$ {zyyz{{|||$ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $          $ $ $ $ #"!!"##$$$$ )(''())***$ /.--.//000$ 5433455666$ ;:99:;;<<<$ A@??@AABBB$ GFEEFGGHHH$ MLKKLMMNNN$ SRQQRSSTTT$ YXWWXYYZZZ$ _^]]^__```$ edccdeefff$ kjiijkklll$ qpoopqqrrr$ wvuuvwwxxx$ }|{{|}}~~~$ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $       $ $ $    $ %$##$%%&&&$ +*))*++,,,$ 10//011222$ 7655677888$ =<;;<==>>>$ CBAABCCDDD$ IHGGHIIJJJ$ ONMMNOOPPP$ UTSSTUUVVV$ [ZYYZ[[\\\$ a`__`aabbb$ gfeefgghhh$ mlkklmmnnn$ srqqrssttt$ yxwwxyyzzz$ ~}}~$ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $      $   $ $ $ !  !!"""$ '&%%&''((($ -,++,--...$ 3211233444$ 9877899:::$ ?>==>??@@@$ EDCCDEEFFF$ KJIIJKKLLL$ QPOOPQQRRR$ WVUUVWWXXX$ ]\[[\]]^^^$ cbaabccddd$ ihgghiijjj$ onmmnooppp$ utsstuuvvv$ {zyyz{{|||$ $ $ --&- "- -- ,- +.2 + rUCA/CASM/ % .].2 ] rANSI C12.19  .'- "- p-- ^- -.2 -rUCA..2  rTransport ."*.2 "*rStack .'- "- pxi-- ^gz- .2 rUCA..2  rTransport .".2 "rStack .'- "- p-- ^- .2 rManual % ..2 rOr. .2   rLAN based .".2 " rTransport .'---- !-  U. 2 UrCommunications!!  .;.2 ; rStandards .mP. 2 mPrRecommendation!! .'-":1%  o%&: j &&#TNPP0D & TNPP &&TNPP   j:  - "-- !p@ -- "-&1A& - &iA& --\-- "Arial- . 2 719886565.--\--  . 2 719926565.--Dc S--  . 2 p19966565.&)U ] "--%,X Y--&&Hp& "Arialg- .2 KI UCA1 Start#"  .&  "--% --&&X[&  .%2 IEEE/C12/Industry CA #  # .&$Y &$, "--%'(--&&_f "--%bb--&& "--%--&&~& "--%--&& "--%--&&v~ "--%yz--&&&.& "--%--&&.5 "--%11--&& "--%--&&&  "--% --&&Q Y  "--%T U --&&--D  -- "Arial- . 2  19986565.&q  "--%t --&&s?& "Arialg- . 2 GE& .&SP&  . 2 +ABB .&QM U "--%TP Q--&--5 0-- "Arial- . 2 wMUCAFE@.&  "--% --&-- -- "Arialg- . 2 CIWG4D8.-->t0--  .2 M ANSI C12.190404((((. .2 MIEEE1397000((((.&c $ & "Arial- .2  MeterModel( ( .--H-- "Arialg- .2 ld ABB Meters000<(($.--Dzl--  .2  GE Meters,80<(($. . 2 $....&I & "Arial- .2 STD1397/C12.19 "".&~go&  .2 JUCA1 Published#"   .& O? W&  .2 2 UCA2 Published#"   .& p&  .2 K UCA2 Start#"  .--:~-- "Arialg- .2 PSE&G00008.&  "--% --&&G & "Arial- .2 { Lucent/PSE&G &.&s&  . 2 Duke#. . 2 l Pwr #. .2 o Tables  .&jl&  .2 H<ICCP Published"#  .--"Systemn-&TNPP &VV:&?,$#  |&WordMicrosoft Word  Fu  -@Times New Roman B- &F)D "--.$ONMMNOPPPNNHGGGHIJJHI$ JJIHGGGHIJ$ J J I H G GGHIJ$ J JIHGG+G,H-I-J,$ J5J4I3H3G4G@GAHBIBJA$ JJJIIHHHGIGUGVHWIWJV$ J_J^I]H]G^GjGkHlIlJk$ JtJsIrHrGsGGHIJ$ JJIHGGGHIJ$ JJIHGGGHIJ$ JJIHGGGHIJ6$JHHGGHIJJIJKRSTTSLKMLKJIK$ \[ZZ[ghiih$ qpoop|}~~}$ $ $ $ $ $ $ $ $%&&%$ .-,,-9:;;:$ CBAABNOPPO$ XWVVWcdeed$ mlkklxyzzy$ $ $ $ $ $ $      $  !""!$ *)(()56776$ ?>==>JKLLK$ TSRRS_`aa`$ ihgghtuvvu8$}||}~~~~~$ $ $ $ yzzyxlkklm$ deedcWVVWX$ OPPONBAABC$ :;;:9-,,-.$ %&&%$$ $ $ $ $ $ $ $ }~~}|poopq$ hiihg[ZZ[\$ STTSRFEEFG$ >??>=10012$ )**)($ $ $ $ $ $ $ $ tsstu$ lmmlk_^^_`&$cba`~`}a|b|b}ddcbba~a}b~d$ aabbddcbba$ aabbddcbba$ aabbddcbba$ aabbddcbba$ aabbddcbba$ aabbddcbba$ aa b bddcbba$ $a#a"b"b#d/d/c0b0b0a$ 9a8a7b7b8dDdDcEbEbEa$ NaMaLbLbMdYdYcZbZbZa$ cabaababbdndncoboboa$ xawavbvbwddcbba$ aabbddcbba$ aabbddcbba$ aabbddcbba$ aabbddcbba$ aabbddcbba$ aabbddcbba$ a a b b ddcbba$ aabbd+d+c,b,b,a,$5a4a3b3b4d>d?d@c?a?c?c@cAbAa@`@`?`>a>b?a$ @YAZBZCYCXCLBKAK@L@M$ @DAEBECDCCC7B6A6@7@8.$@/A0B0C/C.C+A*A*;*:+:-:.;/</=.=,;+<-B-A+@,$ =7=6<5;5:6:B:C;D<D=C$ =L=K<J;J:K:W:X;Y<Y=XP$&;]:^:_;`<`?^?\?\>[>[=[<\;]:_:_;a>a>`?_@_@]?\>\=]=^=`>_?^<^;_=`>^?]=\>^?^>\>[$ 7^8]8\7[6[*[)\)]*^+^$ "^#]#\"[![[\]^^$ ^]\ [ [[\]^^$ ^]\[[[\]^^$ ^]\[[[\]^^$ ^]\[[[\]^^$ ^]\[[[\]^^$ ^]\[[[\]^^$ ^]\[[[\]^^$ z^{]{\z[y[m[l\l]m^n^$ e^f]f\e[d[X[W\W]X^Y^$ P^Q]Q\P[O[C[B\B]C^D^$ ;^<]<\;[:[.[-\-].^/^$ &^']'\&[%[[\]^^$ ^]\[[[\]^^$ ^]\[[[\]^^$ ^]\[[[\]^^$ ^]\[[[\]^^$ ^]\[[[\]^^$ ^]\[[[\]^^$ ^]\[[[\]^^.$~^]\~[}[}[|[{\z]y_yeyfzg{g|f|`}^~]|\}^~^$ |o|n{mzmynyzy{z|{||{$ ||{zyyyz{|$ ||{zyyyz{|$ ||{zyyyz{|$ ||{zyyyz{|$ ||{zyyyz{|$ ||{zyyyz{|$ ||{zyy yz{|$ ||{zyy"y#z${$|#$ |,|+{*z*y+y7y8z9{9|8$ |A|@{?z?y@yLyMzN{N|M$ |V|U{TzTyUyaybzc{c|b$ |k|j{iziyjyvywzx{x|w$ ||{~z~yyyz{|$ ||{zyyyz{|$ ||{zyyyz{|$ ||{zyyyz{|$ ||{zyyyz{|$ ||{zyyyz{|$ ||{zyy y z { | $ ||{zyyyz { |$ |(|'{&z&y'y3y4z5{5|4$ |=|<{;z;y<yHyIzJ{J|I$ |R|Q{PzPyQy]y^z_{_|^$ |g|f{ezeyfyryszt{t|s$ |||{{zzzy{yyz{|$ ||{zyyyz{|$ ||{zyyyz{|$ ||{zyyyz{|>$||{zyyyz}}~}}xwwxy~}||}~{z|$ pppoocbbcd$ [[[ZZNMMNO$ FFFEE9889:$ 11100$##$%$ $ $ $ $ $ $ $ |{{|}$ tttssgffgh$ ___^^RQQRS$ JJJII=<<=>$ 55544(''()$   $     $ $ $ $ $ $ $ xxxwwkjjkl$ cccbbVUUVWJ$#NNNMMKJJMNNOPONMLKJJKLMNLLMMLMNPMKL$ MNOPPPONMM$ MNOPPPONMM$ MNOPPPONMM$ MNOPPPxOwNwMxMy$ MpNqOqPpPoPcObNbMcMd$ M[N\O\P[PZPNOMNMMNMO$ MFNGOGPFPEP9O8N8M9M:$ M1N2O2P1P0P$O#N#M$M%$ MNOPPPONMM$ MNOPPPONMM "--&&1M4-3-$L3>/13>L3--&&=--"$9967766<<<;9--&& --$   --&--- !t ------ !<---&--$--&-- ---- --------- !W5-----rp----ca----rp----ca----_[----- !5-----?=----20----?N=J----2]0X-----p*m----l^cV----j]bV--i]bV@"Arial Black- aV. 2 aVuFC.- '--l^cV----j]bV--i]bV- aV. 2 aVuFC.- '------} ----} x---- ---- -- @"Arial Rounded MT Bold-   . 2 uFT.-'------vr------- -- !- --- "- -- &t2|>-- $u2t3x={;u2-- &&r0~@ "- -%u2t3x={;u2- -&- "- "un- - --k--- "- Xs- - - "- Tv- - - -Qz- -&@N-- $@@M@-- &&@N-- $@@M@-- &&z 2-- $ z  //  ~1z1z -- &&%-- $ ##$$--&&~' "- -% ##$$- -&& --&$--&&" "- -&%- -&- "- - - @@@- "- (&- - @@@- "- (&- - @@@- "- (&- - @@@- "- A?- - @@@- "- A?- - &5:--8$55567886556688888999987655--&&5:--"$555899885588855--&&5:--$9955559--&&5:--*$5555667899888887765--&&5:--*$5555667899888887765--&&5:--"$555899885588855--&&5:--"$555899885588855--&&5:--"$555899885588855--&-  "- -- -  "- -- -  "- -- -  "- -- -  "- -- & -- $  --&----&-- $--&& -- $ --&----&-- $--&&-- $--&--1)----1*--0*@Times New Roman4-  ).2 )uFMeterInc.- '--1)----1*--0*-  ).2 ) uF. Model 12b.- '--4,----4---3--  ,.#2 ,uF2 Phase, 120VAC,.- '--8/----70--60-  /.2 /uF200A.- '- "- :.-- - -- !.- - -- -- !.- - ---- !.---- -- !.- - -- "- 31- - &5;-3- :$5889:::::::9988766788999855-- &&3= "- -:%5889:::::::9988766788999855- -&3- "- :7- - 3- "- :7- - 3- "- :7- - 3- "- :7- - 3- "- :7- - &/6-- z$;443221100//////////0011123343323343332333433323334332333454--&&-8 "- -z%;443221100//////////0011123343323343332333433323334332333454- -&&.5 "- - %210- -&&.5 "- - %012- -&--8/----6.--4.- -. 2 -uFU.- '--8/----6.--4.- -. 2 -uFU.- '--8/----6.--4.- -. 2 -uFC.- '--8/----6.--4.- -. 2 -uFC.- '--;2----92--82- 1. 2 1uFA.- '--;2----92--82- 1. 2 1uFA.- '&/5-3- D$ ////0011112234332222321100//////-- &&-7 "- -<%////00111223433222232110////- -&&/6-3- B$//////00112334544333432110/////-- &&-8 "- -B%//////00112334544333432110/////- -&--5.----5.--4.-  -.2 -uFTM.-'- "-nk- -&jo "- -%ll- -&&in "- -%kk- -&- "- t-- --5----5--5@Times New Roman0-  5.2 5uFMV-90 .-'--1----1--1-  1.2 1uFCustID,  .-'--%#----*"--)"-  ".2 "uFLogChans  .-'--F+----L"+--K"+-  "+.2 "+uFTimStart .-'--k|AR----p{FQ--n{FQ-  FQ. 2 FQuF.-'--- !Y3---&*B-- $*5A*--&&++AB-- $+A@5+++A--&--A----@--?@Times New Roman4- .2 uFAdaption  .-'--2-----5---4-- .2 uFLayer .-'--- !4mY-----e----j--j-  j.2 juFISO .-'- -- !- --- "- --&t|--$utx{u--&&r~ "--%utx{u--&- "-u}q----W--- "-Js--- "-Kv----Nz--&-- $--&&-- $--&&zs--$ zs{{s~zzs--&&|-- $ |||--&&~z "--% |||--&&}--&$}}}}}}}--&&{ "--&%}}}}}}}--&- "---@@@- "---@@@- "---@@@- "---@@@- "---@@@- "---&--6$--&&--$$--&&--$--&&--&$--&&--($--&&--$$--&&--$$--&&--$$--&-  "-yg---  "-kX---  "-gT---  "-yg---  "-kX--&nr-- $nqpn--&&aj-- $abia--&&hr-- $pqhp--&&`d-- $`cb`--&&T_-- $\^T\--&---------  .2 uFMeterInc.- '---------  .2  uF. Model 12b.- '---------  .#2 uF2 Phase, 120VAC,.- '---------  .2 uF200A.- '- "------ !------ !------ !------ !---- "---&-3-8$--&& "--8%--&3- "---3- "---3- "---3- "---3- "---&-- x$:--&& "--x%:--&& "-- %--&& "-- %--&--------- . 2 uFU.- '--------- . 2 uFU.- '--------- . 2 uFC.- '--------- . 2 uFC.- '--------- . 2 uFA.- '--------- . 2 uFA.- '&-3-L$$--&& "--F%!--&&-3-@$--&& "--@%--&---------  .2 uFTM.-'- "-|lzi--&gxm "--%izj|--&&fxl "--%hzi|--&- "-----A----F--E-  .2 uFPG&E MEP.-'--c95----g>5--f>5-  >5.2 >5uFCustID,  .-'--[7----`7--_7-  _7.2 _7uFESPID, .-'--|----------  -.2 -uFMeterID,  .-'--[----X--X-  .2 uFTim.-'--eP----dP--dP-  P. 2 PuF,.-'--W----W--W-  W.2 WuFPT.-'--y--y-  y.2 yuF,Val .-'--V----V--V-  V. 2 VuF.-'--- !Z---&-- $--&&)?-- $)>))--&--w>S----z=W--y=V- V.2 VuFAdaption  .-'--+m----+q--*q- q.2 quFLayer .-'--- !&-----O----M--M-  .2 uFMDMA.-'- -- !$- --- "-(--&1g:r--$4g1h6q9p4g--&&/e<t "--%4g1h6q9p4g--&- "-W2K.----&A--- "-0--- "-4----7--&BuU-- $BuTuTBu--&&u-- $uuu--&&8@f--$ 8@>JJAccURU=e8e8@--&&=JZ-- $ =JJXXTHTHY=Y=J--&&;H\ "--% =JJXXTHTHY=Y=J--&&KKU--&$KKWKZNeNhKuKyNNKKSySwTfTdSKSKK--&&IIW "--&%KKWKZNeNhKuKyNNKKSySwTfTdSKSKK--&- "-SOM--@@@- "-\^Z[--@@@- "-\qZn--@@@- "-\Z--@@@- "-xeub--@@@- "-vztx--&uiyn--4$uiwixjxkxlvlvkvjujukvkvlululvlxlxmwmumumulukujui--&&giln--"$iiiikjklimimglilijijililglgjii--&&|in--$|m~m~i|i|j|m--&&^icn--*$^ibibj`j`kakblblam`m^l^l`l`l`l`l`l^k^i--&&bifn--*$bieiejdjdkekelelemdmblbldldldldldlbkbi--&&kion--"$liminjnlmmlmklmlmjmjmlmlklkjli--&&oisn--"$oiqirjrlqmomolplpjqjqlplolojoi--&&yi|n--"$yizi{j{lzmymylylyjzjzlylylyjyi--&-  "-GT5B---  "-9b'P---  "-5x"e---  "-G5---  "-9'z--&<@-- $<?><--&&08-- $0170--&&E6M@-- $L<J?E6L<--&&P-[2-- $Z-Z1P0Z---&&m#u--- $m*o,t#m*--&--fy^e----ew^e--dw^e-  ]e.2 ]euFMeterInc.- '--f^p----e^p--d^p-  ]p.2 ]p uF. Model 12b.- '--iad----ibc--gbc-  `c.#2 `cuF2 Phase, 120VAC,.- '--mqed----loec--jndc-  cc.2 ccuF200A.- '- "-mbN----- !bV------ !bV------ !bV------ !bV---- "-h[eX--&Ti\p-3-:$[i[l[l[mZmZnYnXnWoWnWnVnUnUmTmTlTlUlVlVlWmWmXmXlYlYi[i--&&Rg^r "--:%[i[l[l[mZmZnYnXnWoWnWnVnUnUmTmTlTlUlVlVlWmWmXmXlYlYi[i--&3- "-n[lX--3- "-n[lX--3- "-n[lX--3- "-n[lX--3- "-n[lX--&Pc]j-- z$;PhPhPgPgQgQfReRdRdScScTcUcVcWcWcXcXcYcYdZd[e[f[f[g[g\g\h[g[g[gZgYgYhXhXgWgWgWgWgVgUgUhUgTgTgTgSgShSgRgRgRgRgQgPgPhPiPh--&&Na_l "--z%;PhPhPgPgQgQfReRdRdScScTcUcVcWcWcXcXcYcYdZd[e[f[f[g[g\g\h[g[g[gZgYgYhXhXgWgWgWgWgVgUgUhUgTgTgTgSgShSgRgRgRgRgQgPgPhPiPh--&&RbYj "-- %TgUeVd--&&SbZj "-- %UdVeWg--&--l\cT----j[bS--i[bS- aS. 2 aSuFU.- '--l\cT----j[bS--i[bS- aS. 2 aSuFU.- '--p\gT----n[gS--mZfS- eS. 2 eSuFA.- '--p\gT----n[gS--mZfS- eS. 2 eSuFA.- '&OcWj-3-R$'UcTcTcScRcRdRdReQeQfPfPgPgOgOhOiOhPhPgQgQgRgRgRgRhRgSgRgSgSfSeSdTdTcTcTcUcVcUc--&&MaYl "--F%!UcTcTcScRcRdRdReQeQfPgPgOgOhOiOhPhPgQgQgRgRgRgShSgSgSfSeTdTcTcUcVc--&&Uc]j-3-J$#UcUcVcWcWcXcYcYdZdZe[e[f[g[g\g\h\i\h[h[g[gZgYgYhXhXgXgXfXeWdWcWcWcVcUc--&&Sa_l "--J%#UcUcVcWcWcXcYcYdZdZe[e[f[g[g\g\h\i\h[h[g[gZgYgYhXhXgXgXfXeWdWcWcWcVcUc--&--iabX----ibbW--hbbW-  aW.2 aWuFTM.-'- "-R+O)--&'N-U "--%)P*R--&&'N-U "--%)P*R--&--- !Zg---&_v-- $_ku_--&&>`Tw-- $>vSk>`>v--&--MT)----PS---OS-- -.2 -uFAdaption  .-'--hAD----kAG--i@G- G.2 GuFLayer .-'- "------------  .2  uFTable Bytes  .-'--- ! -----8----<--;-  .2 uFTable  .-'--8----<--;-  . 2 uF0.-'--Z0----^5--]5-  5.2 5uFTable  .-'--Z0----^5--]5-  5. 2 5uF1.-'--|R----X--X-  W.2 WuF...-'--t----z--y-  y.2 yuF...-'--- !+D~-----c----b--b-  .2  uFTables Meter    .-'--- !------ ! ------ ! ------ !------ !------ !------ !------ !------ !------ ! ------ !#------ !'------ !(------ !,------ !.------ !2------ !5------ !6------ !9------ !<------ !>------ !A------ !C------ !E---- "-H ----- !------ !------ !------ !------ !------ !------ !------ !------ !------ !------ !------ !------ ! ------ ! ------ !------ !------ !------ !------ !------ !------ !!------ !#------ !'------ !)------ !,------ !/------ !2------ !5------ !7------ !:------ !=------ !@------ !C------ !E------ !H------ !K------ !N------ !R------ !S------ !W------ !Z------ !\------ !_------ !a------ !c------ !f------ !i---- "-l--& m--$  J l--&&o "--%  J l--&--- !N---- "-N--& "--%--&&  "--%--&&BG "--%DD--&--- ! o---- "-wp--- "-c--&--$--&& "--%--&- "-----fz--- "-Pj--- "-Mj----Jn--& -- $  --&&3B-- $A33A--&&K--$ DJJF7--&&F-- $ EE<<--&&H "--% EE<<--&&;--&$ #&/1::'%--&&= "--&% #&/1::'%--&- "-8--@@@- "---@@@- "- --@@@- "-.,--@@@- "---@@@- "-*&--&"'--8$#%&&%&%%%$$%%$$%&&%#""#""#--&&--$ --&&)+--$)**))))--&&--&$--&&--&$--&&--$ --&&"--"$!!!!  --&&&*--$ &())(&&'''&&&--&-  "----  "-w---  "-%t---  "-A4---  "-5w'----<9--&:C-- $::B:--&--0}---&-~3-- $/~-~2/~--&&-- $--&&}-- $ } ~ }--&&s#{-- $yz"sy--&--'----&--&-  .2 uFMeterInc.- '--7----4--4-  .2  uF. Model 12b.- '--6----2--1-  .#2 uF2 Phase, 120VAC,.- '---------  .2 uF200A.- '- "-9----- ! ------ ! ------ ! ------ ! ---&-3-2$                   --&& "--2%                   --&&-- L$$                 --&& "--L%$                 --&&  "-- %  --&& "-- %   --&--------- . 2 uFU.- '--------- . 2 uFU.- '-- ---- -- -  . 2 uFC.- '-- ---- -- -  . 2 uFC.- '--------- . 2 uFA.- '--------- . 2 uFA.- '& -3-<$    --&&  "--6%   --&& -3-2$                     --&& "--2%                     --&-- ---- -- -   . 2 uFM.-'& "--%--&& "--%--&--8----Dx!--Cx!@Times New Roman4- !.|2 !KuFClient Applications Billing, Scheduler, Consumer, Distribution Automation                  .'--O%--M%-  %.2 %uFUCA.-'------m1C--k1C-  C.2 C uFTransports   .-'------mq--lq-  p.#2 puFInternet TCP/IP,    .- .2 uFSSL 3.-'--?-------  .2 uFOSI .-'------c--c-  .2  uFReduced Stack   .-'--"Z----'--&-  .2 uFWireless  .-'--S-----------  .2 uFCommon Meter  .- .2 uFData Model  .-'- -- !Z- --- "-0L----h--&Zc--$]Z_b]--&&Xe "--%]Z_b]--&- "-ZV--- "- Z--- "-[----a--&k~-- $k}}k--&&-- $--&&`--$ `h{f``--&&f-- $ fqqff--&&d "--% fqqff--&&t--&$ttt--&&r "--&%ttt--&- "-w--@@@- "---@@@- "---@@@- "---@@@- "---@@@- "---&--8$--&&--"$--&&--$--&&--*$--&&--*$--&&--"$--&&--"$--&&--"$--&-  "-~l---  "-z---  "----  "----  "-------&-- $--&&-- $--&&nv-- $usnu--&&y-- $y--&&-- $--&-------------  .2 uFMeterInc.- '---------  .2  uF. Model 12b.- '---------  .#2 uF2 Phase, 120VAC,.- '---------  .2 uF200A.- '- "-y----- !~------ !~------ !~------ !~---&}-3-@$~~}}}}}~--&&{ "--@%~~}}}}}~--&&y-- f$1yyyzzz{||}}~~}}}}|{zzzyyy--&&w "--f%1yyyzzz{||}}~~}}}}|{zzzyyy--&&{ "-- %}}~--&&{ "-- %}--&--}----}--}- }. 2 }uFU.- '--}----}--}- }. 2 }uFU.- '--------- . 2 uFC.- '--------- . 2 uFC.- '--}----}--}- }. 2 }uFA.- '--}----}--}- }. 2 }uFA.- '&x-3-@$}}||{{zzzyyxxxyzzz{|{||||}}}~}--&&v "--:%}}||{{zzzyyxxxyzzz{|||||}}~--&&~-3-@$~~~--&&| "--@%~~~--&---------  .2 uFTM.-'&PV "--%RS--&&PU "--%RR--&--u6K----z3Q--y3Q-  Q.(2 QuFUCA-C12 Meter Model    .-'--$S----)R--(R-  .2  uFUCA Meter  .-'--\a2----W]8#--U]8#-  7#.+2 7#uFTransitional MEP HTTP   .- '--~8T----7Y--7Y-  Y.2 YuFWEB.- '-->u----={--={-  {.2 {uFServer  .- '--T----R--Q-  .2  uFInternet    .- '&--$--&&--$--&&&--$ %--&--\--[-  .2  uFCommon Meter  .- 8.2 8 uFData Model  .-'---n--+m-  .2  uFCommon Meter  .-  .2  uFData Model  .-'-----  .2  uFCommon Meter  .- .2  uFData Model  .-'- -- !y- --- "-\a--Zc@Times New Roman0- d.2 d uFEDI ST 814 ..2 uF{Common..2 uFData  ..2 uFModel .. 2 uF}.'- -- !y- --- "-4La--1Jc- d.2 duFHTTP..2  uFGet / Put  ..2 uF{Common..2 uFData  ..2 uFModel .. 2 uF}.'- -- !/y- --- "-Za--Xc- d.2 duFMMS..2  uFReadNamed..2  uFVariable /   ..2  uFWriteNamedV ..2 uFariable  .$.2 $uF{Common.I.2 IuFData  .I.2 IuFModel } .'--Ɨ:^05 K j&ZNf &&#TNPP0D & TNPP &&TNPP  NZ  | - "-a@- "- - - "-! A0 --- "-a@-- @"ArialBl- . 2 C.& > - "- ? --&* } "-- $a  J & i \ O --&- "- ] 5 --&Y  .  -- I|f R㞿    &Xp8 & &$TNPPMicrosoft PowerPoint & TNPPP & &TNPP  &=(&=(&Vo7- "- "- R㞿7oV & &-- & & ]&-]& &n- $ &&n & &P&n $&P&Pn &  & &=$ =9J b { &  &  & &=&#- "-$#y#ysksk   & &50-- "-$$55)}%}m55}},5(5( I  & &-- "- $ &  & &l)&%@@@-- "-% & &0@@@-- "-0 & &u@@@-- "-u & &Ou@@@-- "-uO & &6b@@@-- "-b6 &  & &Q&--8$5BOSS///jjSSSqqOB5 & &e"$zmzemeggggege & &=g$KggD=K & &($//BmmYYjjFF2 & &4($11/ /4B4m mYYjjFF2 & &"$mmggggg & &T"$"@TTm@"mg)g)99g)gg & &2"$22mmfffff &  & &%i5&%i5&-  "- & &:--  "-: & &- --  "- - & &:--  "-: & &--  "- &  & & &N--O & &( $(( &  & &Z&vv & &NR $NR &  & &8e & & &B< $ B< &  & &m&vOPv & &?v+ $+v+? &  & &r!&U6 $ 6U & &#BC$ &  &  &  & &TNPP & --'--'&& p> --? q -- Times New Roman- .2 4 MeterInc+ . .2 4 . Model + . . 2 n v12b. .2 J2 Phase,  . .2  120VAC, 200A## #.- "-L < --&  2N --9 3 ----9 3 ----- !& ------ !& ------ !& ------ !& ---- "- .  -- &) = -3->$. 3 4 6 6 6 7 6 6 6 6 4 4 4 3 2 1 0 1 1 2 3 4 4 4 4 3 . . -- "-->%. 3 4 6 6 6 7 6 6 6 6 4 4 4 3 2 1 0 1 1 2 3 4 4 4 4 3 . . --&3- "- 1 0 -- 3- "- 1 0 -- 3- "- 1 0 -- 3- "- 1 0 -- 3- "- 1 0 -- &  2+ --j$ $ # "                                                        ! ! # # $ % & ' ' ( ) ) * +" ,# ,% ,$ ,$ +# +# *" *" )" ) ( ' ' & & $ $ # " !      ! " " " # # # # " "                 " " # # # # "              ! " " # # # " " " !          ! " " # $ % $ -- "--j% $ # "                                                        ! ! # # $ % & ' ' ( ) ) * +" ,# ,% ,$ ,$ +# +# *" *" )" ) ( ' ' & & $ $ # " !      ! " " " # # # # " "                 " " # # # # "              ! " " # # # " " " !          ! " " # $ % $ --&&  , "--% %     --&& ", "--%        % --&--O ) -- "Arial Black- . 2 + UC. 3. 2 * UC. . 2 H A. 3. 2 G A.& & -3-$O                              " # $ % # # " "          ! " # "                    --&&  + "--%J                            " # $ % # # " "          ! " # "                 --&& 2+ -___-$N                  ! ! # # $ % & ' ' ( ) ) * * *! +" ,# ,$ ,% +$ *# *# )" )! (! ' & $ $ # " ! !    ! ! " # $ # # !                  -- "--%N                  ! ! # # $ % & ' ' ( ) ) * * *! +" ,# ,$ ,% +$ *# *# )" )! (! ' & $ $ # " ! !    ! ! " # $ # # !                  --&--! $ -- 3"Arial Rounded MT Bold- . 2  TM.&&& 4 - "-  1 -- && 1 "--%+ + --&& + "--%% % --&&&&\P  - "-  X -- &j = "-- $   -- &- "-  A u-- &O  .  -- I|f n    &Xp8 & &$TNPPMicrosoft PowerPoint & TNPPP & &TNPP  &=(&=(&Vo7- "- "-  n7oV & &- -  & & ]&-]& &n- $ &&n & &P&n $&P&Pn &  & &=$ =9J b { &  &  & &=&#-  "- $#y#ysksk   & &50-  - "- $$55)}%}m55}},5(5( I  & &- - "-  $ &  & &l)&%@@@- - "- % & &0@@@-  - "- 0 & &u@@@- - "-  u & &Ou@@@- - "- uO & &6b@@@-  - "- b6 &  & &Q&- - 8$5BOSS///jjSSSqqOB5 & &e"$zmzemeggggege & &=g$KggD=K & &($//BmmYYjjFF2 & &4($11/ /4B4m mYYjjFF2 & &"$mmggggg & &T"$"@TTm@"mg)g)99g)gg & &2"$22mmfffff &  & &%i5&%i5&-   "-  & &:-  -  "- : & &- - -  "-   - & &:- -  "- : & &-  -  "-  &  & & &N- - O & &( $(( &  & &Z&vv & &NR $NR &  & &8e & & &B< $ B< &  & &m&vOPv & &?v+ $+v+? &  & &r!&U6 $ 6U & &#BC$ &  &  &  & &TNPP & - -  '--'&&  --  -- Times New Roman- .2 8MeterInc+ . .2 . Model + . . 2 . 12b. .2 h 2 Phase,  . .2 B 120VAC, 200A## #.- "- | "--&& r -- > .---- Y A----- !& J------ !& J------ !& J------ !& J---- "-  N M-- &B V -3->$P P O N M L L J I I H H G G G G G H H I I I I J L M M M P -- "-->%P P O N M L L J I I H H G G G G G H H I I I I J L M M M P --&3- "-  N K-- 3- "-  N K-- 3- "-  N L-- 3- "-  N L-- 3- "-  N M-- && r --j$, , , - - - . / 0 0 2 2 4 4 5 5 7 7 8 : ; ; < > ? @ A B C E F H I J K L M N O P Q R S S U U V X X Y Y Z [ \ \ ] ^ ^ _ ` a a c c d e f g g h i i j k l l l l k k j j i i h g g f f d d c b a ` ` _ ^ ^ ^ ^ ] \ \ \ [ [ Z Y Y X W V V U U T S R Q Q P O O N M M L K K K J I H G G F E E D C B B A @ ? ? ? > = = < < ; ; ; : : : 8 8 7 7 5 5 4 4 2 2 1 0 / / - - , , + , -- "--j%, , , - - - . / 0 0 2 2 4 4 5 5 7 7 8 : ; ; < > ? @ A B C E F H I J K L M N O P Q R S S U U V X X Y Y Z [ \ \ ] ^ ^ _ ` a a c c d e f g g h i i j k l l l l k k j j i i h g g f f d d c b a ` ` _ ^ ^ ^ ^ ] \ \ \ [ [ Z Y Y X W V V U U T S R Q Q P O O N M M L K K K J I H G G F E E D C B B A @ ? ? ? > = = < < ; ; ; : : : 8 8 7 7 5 5 4 4 2 2 1 0 / / - - , , + , --&&7 R "--%< = @ D J --&&F b "--%K K L O R W Z [ --&-- i =-- "Arial Black- . 2 @UC. 3. 2 ?UC. . 2  @A. 3. 2  ?A.&+ K -3-$OI I F F C A > = < ; : : 9 9 8 8 6 6 5 4 3 3 2 2 1 0 0 / . - - , , , + , - - . / / 0 2 2 3 4 5 5 6 6 7 8 8 9 : : ; ; ; ; < < < = = > ? @ A A C D E F H J I H I --&&& P "--%JJ G F C A ? = < ; : : 9 9 8 7 6 5 4 3 3 2 1 1 1 0 / . - - , , , + , - - . / / 1 1 2 3 4 5 5 6 7 7 8 9 : : ; < < < < < < = = = ? ? @ A B C D E G H J --&&F r -___-$NM K L M P R S U V X Z Z [ ] ^ ` ` a a c c d e f g g h i i j j j k l l l k j j i i h g f d d c b a a ` ` _ ^ ^ ] \ [ [ [ [ [ [ Z Z Z Y X W W U T S R P O M M -- "--%NM K L M P R S U V X Z Z [ ] ^ ` ` a a c c d e f g g h i i j j j k l l l k j j i i h g f d d c b a a ` ` _ ^ ^ ] \ [ [ [ [ [ [ Z Z Z Y X W W U T S R P O M M --&-- d S-- 3"Arial Rounded MT Bold- . 2 UTM.&&&\W t - "- x q^ `-- &fW q "--%k\ ky --&&`W k "--%e\ ey --&&&-- ` -- @"ArialBl- . 2 7Z D.--`--  . 2 7JESP.--f --  .2 J MDM Function5ukk`5+kk.--  P --  .2 Serverk@`k@.-- --  . 2 :C.-- --  . 2 ZESCO.--q Pp--  .2 'NPR / LRF / GOV555ku555.--qP0 --  .2 'j T/ISO/SCu555.--qP--  . 2 'JPX.--qP@--  . 2 'zPM.--a E @ P--  . 2  VEE.--  --  . 2 RAW.&+ & "--%0  -- $   --&& z 6 "--% -- $ 0  --&&{f "--%` -- $--&&6f "--%` -- $0--&& Kf "--% < E t-- $ V `  $Z Z P4 --&&v "--%p-- $ --&&K4F "--%PX-- $ x@@9--&&;Ff "--%`j-- $#@@S--&& kF6 "--%@0 -- $  p --&&k  "--% -- $+wp--&&] "--%> -- $J b p7 --&&6 "--% -- $0--&&H "--% l d -- $  Pu N $E   --&& v "--%p -- $   --&--! --  .2 Valid/k++k5. .2 Settlmentk55+kk5.&{6--$ }|}$ $ $ $ $ $ $ $ $    $    #$# $ 0-,-003430$ @=<=@@CDC@$ PMLMPPSTSP$ `]\]``cdc`$ pmlmppstsp$ }|}$ $ $ $ $ $ $ $ $    $    #$# $ 0-,-003430$ @=<=@@CDC@$ PMLMPPSTSP$ `]\]``cdc`$ pmlmppstsp$ }|}$ $ $ $ $ $ $ $ $    $    #$# $ 0-,-003430$ @=<=@@CDC@$ PMLMPPSTSP$ `]\]``cdc`$ pmlmppstsp$ }|}$ $ $ $ $ $ $ $ $    $    #$# $ 0-,-003430$ @=<=@@CDC@$ PMLMPPSTSP$ `]\]``cdc`$ pmlmppstsp$ }|}$ $ $ $ $ $ $ $        $           $       # $ #  $ 0 - , - 0 0 3 4 3 0 $ @ = < = @ @ C D C @ $ P M L M P P S T S P $ ` ] \ ] ` ` c d c ` $ p m l m p p s t s p $  } | }       $           $           $           $           $           $           $           $           $           $       # $ #  $ 0 - , - 0 0 3 4 3 0 $ @ = < = @ @ C D C @ $ P M L M P P S T S P $ ` ] \ ] ` ` c d c ` $ p m l m p p s t s p $  } | }       $           $           $           $           $           $           $           $           $           $       # $ #  $ 0 - , - 0 0 3 4 3 0 $ @ = < = @ @ C D C @ $ P M L M P P S T S P $ ` ] \ ] ` ` c d c ` $ p m l m p p s t s p $  } | }       $           $           $           $           $           $           $           $           $           $       # $ #  $ 0 - , - 0 0 3 4 3 0 $ @ = < = @ @ C D C @ $ P M L M P P S T S P $ ` ] \ ] ` ` c d c ` $ p m l m p p s t s p $  } | }       $           $           $           $           $           $           $           $           $           $       # $ #  $ 0 - , - 0 0 3 4 3 0 $ @ = < = @ @ C D C @ $ P M L M P P S T S P $ ` ] \ ] ` ` c d c ` $ p m l m p p s t s p $  } | }       $           $           $           $           $           $           $           $    $    $    #$# $ 0-,-003430$ @=<=@@CDC@$ PMLMPPSTSP$ `]\]``cdc`$ pmlmppstsp$ }|}$ $ $ $ $ $ $ $ $    $    #$# --&- "---  .2 Fieldu+k+k. . 2 View+k.- "- --  .2 ^Serverk@`k@. . 2 ^View+k.--"Systemn-&TNPP & f:-:vD &  H =&WordMicrosoft Word    -@Times New Roman- - "-- !c-- "-- "-KZ----- !---- "-c--- "-EgX\--- "-'I:>--- "- + ----i,0--d04@ Arial-14.2 14M1234#.-'- "-w:L----w:j--s>n- ?n.2 ?nDI .8-'--x--|@ Arial2- }.2 }DataSet  .8@Times New Roman8- '--- !<---- .#2 Server@
).8-'- "- (-- .@ ArialNe-  /.2 /Other! .8_.2 _ Models and#  .8- .2 Services .8-'&O-- $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $     $   $ $ $ $ $!!## $%%'' $))++ $--// $1133 $5577 $99;; $==?? $AACC $EEGG $IIKK $MMOO $QQSS $UUWW $YY[[ $]]__ $aacc $eegg $iikk $mmoo $qqss $uuww $yy{{ $}} $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $     $   $ $ $ $ $!!## $%%'' $))++ $--// $1133 $5577 $99;; $==?? $AACC $EEGG $IIKK $MMOO $QQSS $UUWW $YY[[ $]]__ $aacc $eegg $iikk $mmoo $qqss $uuww $yy{{ $}} $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $     $   $ $ $ $ $!!## $%%'' $))++ $--// $1133 $5577 $99;; $==?? $AACC $EEGG $IIKK $MMOO $QQSS $UUWW $YY[[ $]]__ $aacc $eegg $iikk $mmoo $qqss $uuww $yy{{ $}} $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $     $   $ $ $ $ $!!## $%%'' $))++ $--// $1133 $5577 $99;; $==?? $AACC $EEGG $IIKK $MMOO $QQSS $UUWW $YY[[ $]]__ $aacc $eegg $iikk $mmoo $qqss $uuww $yy{{ $}} $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $$  $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $   $   $ $ $ $ $  "" $$$&& $((** $,,.. $0022 $4466 $88:: $<<>> $@@BB $DDFF $HHJJ $LLNN $PPRR $TTVV $XXZZ $\\^^ $``bb $ddff $hhjj $llnn $pprr $ttvv $xxzz $||~~ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $   $   $ $ $ $ $  "" $$$&& $((** $,,.. $0022 $4466 $88:: $<<>> $@@BB $DDFF $HHJJ $LLNN $PPRR $TTVV $XXZZ $\\^^ $``bb $ddff $hhjj $llnn $pprr $ttvv $xxzz $||~~ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $   $   $ $ $ $ $  "" $$$&& $((** $,,.. $0022 $4466 $88:: $<<>> $@@BB $DDFF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $F}H}H{F{ $FyHyHwFw $FuHuHsFs $FqHqHoFo $FmHmHkFk $FiHiHgFg $FeHeHcFc $FaHaH_F_ $F]H]H[F[ $FYHYHWFW $FUHUHSFS $FQHQHOFO $FMHMHKFK $FIHIHGFG $FEHEHCFC $FAHAH?F? $F=H=H;F; $F9H9H7F7 $F5H5H3F3 $F1H1H/F/ $F-H-H+F+ $F)H)H'F' $F%H%H#F# $F!H!HF $FHHF $FHHF $FHHF $FHHF $F H H F  $F H HF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $F}H}H{F{ $FyHyHwFw $FuHuHsFs $FqHqHoFo $FmHmHkFk $FiHiHgFg $FeHeHcFc $FaHaH_F_ $F]H]H[F[ $FYHYHWFW $FUHUHSFS $FQHQHOFO $FMHMHKFK $FIHIHGFG $FEHEHCFC $FAHAH?F? $F=H=H;F; $F9H9H7F7 $F5H5H3F3 $F1H1H/F/ $F-H-H+F+ $F)H)H'F' $F%H%H#F# $F!H!HF $FHHF $FHHF $FHHF $FHHF $F H H F  $F H HF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $F}H}H{F{ $FyHyHwFw $FuHuHsFs $FqHqHoFo $FmHmHkFk $FiHiHgFg $FeHeHcFc $FaHaH_F_ $F]H]H[F[ $FYHYHWFW $FUHUHSFS $FQHQHOFO $FMHMHKFK $FIHIHGFG $FEHEHCFC $FAHAH?F? $F=H=H;F; $F9H9H7F7 $F5H5H3F3 $F1H1H/F/ $F-H-H+F+ $F)H)H'F' $F%H%H#F# $F!H!HF $FHHF $FHHF $FHHF $FHHF $F H H F  $F H HF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $F}H}H{F{ $FyHyHwFw $FuHuHsFs $FqHqHoFo $FmHmHkFk $FiHiHgFg $FeHeHcFc $FaHaH_F_ $F]H]H[F[ $FYHYHWFW $FUHUHSFS $FQHQHOFO $FMHMHKFK $FIHIHGFG $FEHEHCFC $FAHAH?F? $F=H=H;F; $F9H9H7F7 $F5H5H3F3 $F1H1H/F/ $F-H-H+F+ $F)H)H'F' $F%H%H#F# $F!H!HF $FHHF $FHHF $FHHF $FHHF $F H H F  $F H HF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $FHHF $GGEE $CCAA $??== $;;99 $7755 $3311 $//-- $++)) $''%% $##!! $ $ $ $ $   $     $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $}} ${{yy $wwuu $ssqq $oomm $kkii $ggee $ccaa $__]] $[[YY $WWUU $SSQQ $OOMM $KKII $GGEE $CCAA $??== $;;99 $7755 $3311 $//-- $++)) $''%% $##!! $ $ $ $ $   $     $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $}} ${{yy $wwuu $ssqq $oomm $kkii $ggee $ccaa $__]] $[[YY $WWUU $SSQQ $OOMM $KKII $GGEE $CCAA $??== $;;99 $7755 $3311 $//-- $++)) $''%% $##!! $ $ $ $ $   $     $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $--&- "- *w-- --+x--(|- }.(2 }FunctionalComponent   .8@ Arial- }#8- '--x--|- }.2 } LogicalDevice   .8- '--x--|- }.2 } DeviceModel  .8- '--/--,- .2 EMeter#.8'& "- -% - - $--&&/ "- -%,- - $--&& "- -%- - $--&--x --|$- }$.2 }$Server  .8- '&Oi "- -%\s\- - $Qq\fq--&--x--|- }. 2 }DeviceIdentity   .8- '&!= "- -%-- - $#:2--&&Vwy "- -%gkt- - $baXvoq--&--=--9- .=2 !CASM Classes for Modeling Devices#    #   .8-'--+Z--(^- ^.2 ^Object! .8- .82 s representing devices through     .8- ^.(2 ^communications are $$    .8-.2 instance .8- .2 s of  .8- ^.2 ^CASM # .8-.2 Class .8- R.2 Res.8-'& x- "- x -- & "- -% - -&&x- "- x-- & "- -%- -&&x- "- x-- & "- -%- -&&x- "- x-- & "- -%- -&&x*- "- +x-- &. "- -%*- -&--xH--|L- }L.2 }L DataObject   .8- '&Hx- "- xH-- &E "- -%H- -&&x- "- x-- & "- -%- -&&" "- -%- -&&@ "- - %<\- -&&@ "- - %<t- -&&E} "- - %tH- -&&}" "- - %\- -&&)0 "- -%,,- -&&: "- -%.- - $#75--&- "- gvh-- a|n-  }n. 2 }nEMeter.DS.Bill   .8- n. 2 n .8w.2 w EMeter.MX.W.   " .8- K.2 K startBillR   .8- - n. 2 n .8w.2 w EMeter.MX.W.   " .8- K.2 KendBillR .8--n.2 n *.8'n.2 'n *.8'&} "- -% z- - $--&&xw "- -%tu- -&&v(}w "- -%xtz*- -&- "- r-- - "- d-- - "- g "-- --g[--cX- .2  EMeter.CF# .8%. 2 % .8%.2 % EMeter.CF.W.s#  ' .8'--b#--] - .2  EMeter.MX# #.8.2  .8.2  EMeter.MX.W# # '.8.2  .8.2  EMeter.MX.W.i# # ' .8,.2 , .8,.2 , EMeter.MX.W.r# # ' .8.2  EMeter.EV# .8.2  .8. 2 EMeter.EV.Bill#   .8.2  .8.2  EMeter.EV.W#  '.8X.2 X EMeter.LG# !.8.2  .8.2  EMeter.LG.W# ! '.8.2  EMeter.RP# .8 .2  .8 . 2 EMeter.RP.Bill#   .8'--/--,- . 2 *.8'- "- -- "- $.2 $ SecureAgent .8V.2 V  Role 1:UDC    .8.2   Role 2:ESC    .8.2   Role 3:ISO    .8.2   Role 4:SC    .8.2   Role 5:Cust     .8P.2 P *.8'- "- -- - .2  TimeAgent ! .8.2  .8App B 8-11-97.docJ Anthony Mazyolo6ooMicrosoft Word for Windows 95@F#@@@Ħ@Ŧ!*V՜.+,0HP`hp x T&NTR } ]California Direct Access: Proposed Implementation of National Standards based communications      !"#$%&'()*+,-./w0ABCDEFGHIJKLMNOPQRSTUVWZ[\]^qrstuv FMicrosoft Word Document MSWordDocWord.Document.69qOh+'00<Hd |    ]California Direct Access: Proposed Implementation of National Standards based communicationsIAugust J. NevoloHAg odXX"0q7JRd      !"#$%&'()*+,-./w05689:;<=>_ABCDEFGHIJKLMNOPQRSTUVWf`abcde@ghijklmox|}Custom page 1BBCustom page 2BBCustom page 3BBR(S(((((((((((S+++++++++_Times New Roman Symbol &Arial"Helvetica Times5Courier New"h\&\&[&*V!} !Y\California Direct Access: Proposed Implementation of National Standards based communicationsAugust J. Nevolo Anthony MazyܥhW e+#'S(D$a`!"%_: .@@@QL!L)%?&X&G% 5:#  G%     .+Ŧ-l . $ Appendix B AMRA/EPRI/ORA Technical Annex JOINT COMMENTS OF THE AUTOMATIC METER READING ASSOCIATION, THE ELECTRIC POWER RESEARCH INSTITUTE, ANDTHE OFFICE OF RATEPAYER ADVOCATES ON THE FINAL METERING AND DATA COMMUNICATIONS STANDARDS California Direct Access: Proposed implementation of national standards based communications Presented to the CPUC Metering & Data Management Workshop by EPRI, IEEE SCC36 with contributions by IEEE/ANSI/AMRA/IGT For comments and questions contact: Martin J. Burns, Hypertek Inc. for EPRI (301)216-9836 burnsmarty@aol.com August Nevolo, T&NTR for EPRI (415)776-8140 anevolo@ccnet.com Bill Blair, EPRI (415)855-2173 bblair@epri.com This paper outlines in detail a proposed migration strategy to deploy national standards based metering communications in California as part of the Direct Access Initiative. The following issues are presented: Introduction Communications topology for utility metering applications Requirements addressed by national standards Specific recommendations for use of national standards Migration strategy Some model details and component mapping to MADAWG data API using CASM over TCP/IP with secure sockets Examples of transport  AUTONUMLGL 1. Introduction MADAWG has specified a transitional format for the presentation of billing and settlement data to a community of clients of the Meter Data Management Agent entity. This is a part of the California Direct Access Initiative. This transitional format is simple and direct in addressing the specific needs of the aggressive Direct Access schedule (1/1/98). However, it is limited in scope and depth and was therefore proposed as an initial solution only. The MADAWG attendees have demanded a more robust set of solutions based on national standards and a migration path to move to standards from the transitional solution as soon as practicable. In addition to the need to present settlement ready billing and account status messaging between business entities separated by the California initiative, various parties have need for access to near real-time data, for purposes of scheduling and network management. The short time scale of implementation by 1/1/98 precludes the instant implementation of technologies, and, the deployment of communications equipment to support them on such short notice. However, in the immediate future, the complexities of the newly created distributed environment will demand these applications. This document presents a model for the introduction of technologies that will support current and future applications based on available and scaleable national standards.  AUTONUMLGL 2. Communications topology for utility metering applications The purpose of this section is to describe a reference topology for use in discussing communications standards for use in representing metering data. The following figures illustrate the topology and applications from communications of meter related information:  Figure  SEQ Figure \* ARABIC 1 Communications topology of meter data management Figure 1 illustrates a generic communications capability to support communications of meter data as well as other enhanced energy services. Shown are the key transitions from LAN at the customer premises, to a reduced stack WAN, to a large scale WAN capability. Shown on ST`agh"#+,BCDE ,-9:<= !-.23mn              ]kuD`VauD uD?c[%dghiijjjgkkkmxnnToopqCqs}}}}{usoooooouo\<<$ 8 48-8  4\  4\ 4sH' 4! 'JJJJII4! HI[elvw%23FYo'JJJJII4! ' 4! o 16DEVt{ 'JJJJII4! $  9@ABP]deft1EL !'JJJJII4! "LMNe{  !'JJJJII4! 'JJJJII4! !"1Y\]^my}~ 7H 'JJJJII4! 'JJJJII4! 78:JKMbce|}!89 ! H !9;RSUqrt!,-Obny!H  $ \ u      I     ( ^    $&.}PQm <l Co[[<<)PQm!/AYZ`"6Sfz{#$*\[<<[[+<K_m{G#;w=>Y"#I[[[[*?n  ?LS(55  55555555 55555555555555555 555 555 5555 5 5555557LUVmuw~ !Title (L($ Anthony MazyD:\App B 8-11-97.doc@HP LJ4 (Here) Non-OA\\Drafuels1\laserjetpostPSCRIPTHP LJ4 (Here) Non-OAHP LJ4 (Here) Non-OAg odXX"0q7JRdCustom page 1BBCustom page 2BBCustom page 3BBHP LJ4 (Here) Non-OAg odXX"0q7JRdCustom page 1BBCustom page 2BBCustom page 3BBR(S(((((((((((iS+i++++++++_Times New Roman Symbol &Arial"Helvetica Times5Courier New"h\&\&[&*V!} !Y\California Direct Access: Proposed Implementation of National Standards based communicationsAugust J. Nevolo Anthony Mazy &.   +]  ?!@!L!M!S!T!!"p"##$$$$$&&}'')4* ++S+++++++++++++++++++iiiiiiuPaP uDPa]cU^U^uD]kO ,-./M1oq~/g P !y!y!y!y!y!!y!!!!!!!!!!!!!!!!!! 4 4 8 4h@< F !!!! ! !!f!#!!! !!!! 4 4 4 4 4BF 4!`!!J"#$:$$$$%^%|%%!I!!F!F!F!Z!F!!!Z!1!Z!I!z!z!z!z!z!z!$  4h 8 4h 4 4%%/&_&&()2)J)Z)e)))))*P*}**** +C+|+++-W///H0`1!!!!I!!!!!!!!!!!!!!!!!!!!!I!!!!!!$  4h!# < 4h`11M22-35[79y;=??@A?B|CeDEG'IIJLNNP+Q-QQIRR TsUUVQV!!!! !!! !! !!!!I!!!!!!!!!!!I!!!l!!!I!!!!!$ h 4h)h@ #QVVW0WXCXX&YYYYZZ0[2]w]o^k_```saab%d!!!!!!!!!I!!!!!\ 4 4$ 8 48-8\<<+Z .E  *+STQRhi[[h[[)& \ ]        !!?!f!!"p"}"""""""#=#l#s#y#~##########[[h[*######$#$S$$$$$$$$%.%C%u%%%%%&Q&{&&&&&'%'E'{'|'}'''((@[ [[0[((/(E(T(}(((()*)[)`)d)g)i)j)v)y))))))))))))+*4*e**** + ++F+R+S+++[[0[*+++++iii[^K @ Normal<<a @!R Heading 1$@!R$ Heading 2Vc&@!R& Heading 3xP]c(@!R( Heading 4xPV]c$@!R$ Heading 5xPc&@!R& Heading 6xPVc&@!R& Heading 7P<]c(@!R( Heading 8P<V]c( @!R( Heading 9 P<V]c"A@"Default Paragraph Font&$@A&Envelope Address )@ Page NumberU(>@(Title U]c k"O"IssueV]@2Header$"@R$CaptionxVc"B@R" Body Text  @bFooter(@r(Annotation Textxc4O4 Footnote BaseE$c*OQ*Block Quotation V OQB Picture OQDate&O!&Document Labelh] *@ Endnote Referenceh +@ Endnote Textx$%@A$Envelope Return(O( Header Base !"@" Footnote Text!x &@! Footnote Referenceh$/@Q2$List#P OA Lead-in EmphasisUV(@Q Line Number]c^0@1b^ List BulletC&  4 ?^1@1r^ List NumberC'  4h.&-@Q& Macro Text (x]$OA$Return Address) dp dp% ddiMAINdp ddiMAINdp ddiMAINdp ddiMAINdp ddiMAINdp ddiMAINdp ddiMAINdp ddiMAINddiMAINd 2rZ( , , . . !           "       $     !F  xŦ+l$Appendix B AMRA/EPRI/ORA Technical Annex JOINT COMMENTS OF THE AUTOMATIC METER READING ASSOCIATION, THE ELECTRIC POWER RESEARCH INSTITUTE, ANDTHE OFFICE OF RATEPAYER ADVOCATES ON THE FINAL METERING AND DATA COMMUNICATIONS STANDARDS California Direct Access: Proposed implementation of national standards based communications Presented to the CPUC Metering & Data Management Workshop by EPRI, IEEE SCC36 with contributions by IEEE/ANSI/AMRA/IGT For comments and questions contact: Martin J. Burns, Hypertek Inc. for EPRI (301)216-9836 burnsmarty@aol.com August Nevolo, T&NTR for EPRI (415)776-8140 anevolo@ccnet.com Bill Blair, EPRI (415)855-2173 bblair@epri.com This paper outlines in detail a proposed migration strategy to deploy national standards based metering communications in California as part of the Direct Access Initiative. The following issues are presented: Introduction Communications topology for utility metering applications Requirements addressed by national standards Specific recommendations for use of national standards Migration strategy Some model details and component mapping to MADAWG data API using CASM over TCP/IP with secure sockets Examples of transport  AUTONUMLGL 1. Introduction MADAWG has specified a transitional format for the presentation of billing and settlement data to a community of clients of the Meter Data Management Agent entity. This is a part of the California Direct Access Initiative. This transitional format is simple and direct in addressing the specific needs of the aggressive Direct Access schedule (1/1/98). However, it is limited in scope and depth and was therefore proposed as an initial solution only. The MADAWG attendees have demanded a more robust set of solutions based on national standards and a migration path to move to standards from the transitional solution as soon as practicable. In addition to the need to present settlement ready billing and account status messaging between business entities separated by the California initiative, various parties have need for access to near real-time data, for purposes of scheduling and network management. The short time scale of implementation by 1/1/98 precludes the instant implementation of technologies, and, the deployment of communications equipment to support them on such short notice. However, in the immediate future, the complexities of the newly created distributed environment will demand these applications. This document presents a model for the introduction of technologies that will support current and future applications based on available and scaleable national standards.  AUTONUMLGL 2. Communications topology for utility metering applications The purpose of this section is to describe a reference topology for use in discussing communications standards for use in representing metering data. The following figures illustrate the topology and applications from communications of meter related information:  Figure  SEQ Figure \* ARABIC 1 Communications topology of meter data management Figure 1 illustrates a generic communications capability to support communications of meter data as well as other enhanced energy services. Shown are the key transitions from LAN at the customer premises, to a reduced stack WAN, to a large scale WAN capability. Shown on . 2 t .8,.2 , .8,.2 ,Dst .8^.2 ^ .8^.2 ^Tz.8.2  *.8'- "- 6v-K"*8hEIO2Zg(srZ[>,^ZE$(Lp7iT R #D>sB@ >6 2ZwZo[k\]]]s^^_%adeffgggghhhjxkkTllmnCnp?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~uu#vUxdx yyz^zzF{W{E}~iǀ^pւ`aB-<څ5y p}aBmr Ks’ג#Z[ؔT+@i˪,*-̰۱<ŲeM/uٸao^!+ξ[P8L6krABSwGxF !"$o0LKC,l9 K"$3NOWjv} DEGQef{(/CI[b !#-9 GQ]eln}#BI^f 9;JPbi%@BDNceg'5GPgn!'5Egn7>I[elw%3FYo- - "- J-- - "- e-- - "- h-- n-  n. 2 nEMeter.DS.Stat    .8 n. 2 n .8 v.2 vDI.Loc DocumentSummaryInformation8 016EVt{ 9@BP]dft1ELNe{  "1Y\^my} 8:KMce}!9;SUrt!-Obny\uI    ( ^    $ & . }    P Q m    < l      CoPQm!/AYZ`"6Sfz{#$*\<K_m{G#;w=>Y"#I+Z .E  *+STQRhi&\]?f!p} = l s y ~               !#!S!!!!!!!!"."C"u"""""#Q#{#####$%$E${$|$}$$$%%/%E%T%}%%%%&*&[&`&d&g&i&j&v&y&&&&&&&&&&&&+'4'e'''' ( ((F(R((!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!xxxxxxxxxxxxxxxx!!!!!!I!!!!!!!I! !!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!I!!!!!!I!!!!!Z!Z!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!@Y.81n.2 1n DI.  .81.2 1 DI.InvID,   .8Wn. 2 Wn .8Wv.#2 WvDI.UtilID.ESCID,   .8}n. 2 }n .8}v.&2 }vDI.UtilID.TmpltID,   .8n. 2 n .8v.&2 vDI.UtilID.TarifID,   .8n. 2 n .8v.#2 vDI.UtilID.SvcPt,   .8n. 2 n .8v.2 v EMeter.MX.W.i   .8n. 2 n .8v.2 v EMeter.MX.W.r   .8;n. 2 ;n!.8'- 1 2/0]nF G S T V W $$$$$$_&`&l&m&q&r&++++++??????@@@@@@NNNNNN+Q,Q4Q5QKQLQMQuD uDraauD/uDP]kZMQNQIRJRVRWR[R\RsUtUUUUUWWWW%W&WXX%X&X,X-XXXXXXXYYYYYYYYYYYYZZZZZZZ0[2]w]abgkhktkuk}k~kkkqCqx#y}!~"~E~yzpq}~эBCOPVWmnz{^U]kuD`[\hiop&'+,()+,ˣ̣ͣΣƨ˭խ)*37̳ճĵŵεMVƼ !+*+67CDFGrsUchcMcUcauD@uDYST`agh"#+,BCDE ,-9:<= !-.23mn              ]kuD`VauD uD?c[ &.   +]  ?!@!L!M!S!T!!"p"##$$$$$&&}'')4* ++S+++++++++++++++++++iiiiiiuPaP uDPa]cU^U^uD]kM ,-./M1oq~/g P !y!y!y!y!y!!y!!!!!!!!!!!!!!!!!! 4 4 8 4h@< F !!!! ! !!f!#!!! !!!! 4 4 4 4 4BF 4!`!!J"#$:$$$$%^%|%%!I!!F!F!F!Z!F!!!Z!1!Z!I!z!z!z!z!z!z!$  4h 8 4h 4 4%%/&_&&()2)J)Z)e)))))*P*}**** +C+|+++-W///H0`1!!!!I!!!!!!!!!!!!!!!!!!!!!I!!!!!!$  4h!# < 4h`11M22-35[79y;=??@A?B|CeDEG'IIJLNNP+Q-QQIRR TsUUVQV!!!! !!! !! !!!!I!!!!!!!!!!!I!!!l!!!I!!!!!$ h 4h)h@ #QVVW0WXCXX&YYYYZZ0[2]w]o^k_```saab%d!!!!!!!!!I!!!!!\ 4 4$ 8 48-8\<<+Z .E  *+STQRhi[[h[[)& \ ]        !!?!f!!"p"}"""""""#=#l#s#y#~##########[[h[*######$#$S$$$$$$$$%.%C%u%%%%%&Q&{&&&&&'%'E'{'|'}'''((@[ [[0[((/(E(T(}(((()*)[)`)d)g)i)j)v)y))))))))))))+*4*e**** + ++F+R+S+++[[0[*+++++iii[^K @ Normal<<a @!R Heading 1$@!R$ Heading 2Vc&@!R& Heading 3xP]c(@!R( Heading 4xPV]c$@!R$ Heading 5xPc&@!R& Heading 6xPVc&@!R& Heading 7P<]c(@!R( Heading 8P<V]c( @!R( Heading 9 P<V]c"A@"Default Paragraph Font&$@A&Envelope Address )@ Page NumberU(>@(Title U]c k"O"IssueV]@2Header$"@R$CaptionxVc"B@R" Body Text  @bFooter(@r(Annotation Textxc4O4 Footnote BaseE$c*OQ*Block Quotation V OQB Picture OQDate&O!&Document Labelh] *@ Endnote Referenceh +@ Endnote Textx$%@A$Envelope Return(O( Header Base !"@" Footnote Text!x &@! Footnote Referenceh$/@Q2$List#P OA Lead-in EmphasisUV(@Q Line Number]c^0@1b^ List BulletC&  4 ?^1@1r^ List NumberC'  4h.&-@Q& Macro Text (x]$OA$Return Address)*OaR*Subtitle Cover*UVc$O Superscripth"OQ"Author,Uc,O!, Chapter Label -h^c*O!* Chapter Title .Xc .OR.Chapter Subtitle/hhUVc$Oa$ Footer First 0!Oa Footer Even1$Oa"$ Footer Odd 2$O12$ Header First 3!O1B Header Even4$O1R$ Header Odd 5*O*Block Quotation First6x(OR(Block Quotation Last7&Oab&List Bullet First8P$OaR$List Bullet Last9O12 List First:PO1R List Last;&Oqr&List Number First<P$OqR$List Number Last= O! Part Title>X*OR* Part Subtitle?hUVc &O& Body Text 2@U]c`D@1` List ContinueCA  4h"2@1""List 2B88"3@12"List 3C"4@1B"List 4D"5@1R"List 5Epp"=@qb" List Number 5Fp"<@qr" List Number 4G";@q" List Number 3H":@q" List Number 2I8X9@aX List Bullet 5;Jp 4 ?X8@aX List Bullet 4;K 4 ?X7@aX List Bullet 3;L 4 ?X6@aX List Bullet 2;M8 4 ?$E@$List Continue 2N8*O!* Part Label OXU^c OQ Body Text KeepP OQ Subject LineQV^2OR2 Heading Base Rx U]c$kO1EmphasisV&OQB&AddressT$'@Q$Annotation Referencec(O!( Title Cover Vc0$F@r$List Continue 3W$G@$List Continue 4X$H@$List Continue 5Yp(O(Body Text Indent 2Z0(O(Program []c&O&Body Text Indent 3\O Hyperlink^bdiMAINdp dp dp dp dp dp dp dp 碕-ŏQfŠ悏^fƏ悁$f筂碂壔䠩0f̏磂ɏҁ؏碂ُ碂碂碕䠥0ffFf䠵0f̏砂悏f堵0f̏硂ɏҁ؏碂碕-ُ碂碂碕Ƃf碕悁整f̏箂؏碂碕‚ُ碂碂̏硂碕f悁8f粃Ffύ?i鍀ꪨ͛뢮ɋ쬮񸴼ӑ޺ŷړݝߍ۹^غŃ殯昙顠闖diMAINdϫԦ˂rZ( , , . . !              "       $     !F K"*8hEIO2Zg(srZ[>,^ZE$(Lp7iT R #D>sB@ >6 2ZwZo[k\]]]s^^_%adeffgggghhhjxkkTllmnCnpI[elw%3FYo16EVt{ 9@BP]dft1ELNe{  "1Y\^my} 8:KMce}!9;SUrt!-Obny\uI    ( ^    $ & . }    P Q m    < l      CoPQm!/AYZ`"6Sfz{#$*\<K_m{G#;w=>Y"#I+Z .E  *+STQRhi&\]?f!p} = l s y ~               !#!S!!!!!!!!"."C"u"""""#Q#{#####$%$E${$|$}$$$%%/%E%T%}%%%%&*&[&`&d&g&i&j&v&y&&&&&&&&&&&&+'4'e'''' ( ((F(R((!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!xxxxxxxxxxxxxxxx!!!!!!I!!!!!!!I! !!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!I!!!!!!I!!!!!Z!Z!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!I!!j BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB!!I!!!6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t!!X X X X X X X !!X X X X X X X X X X X X X X !!!!!!!!!!!I!!j BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB!!I!!!6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t6n t!!X X X X X X X !!X X X X X X X X X X X X X X !!!!!!!!!!!!!!!!I!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!I!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ,-./M1oq~/gP F BF4`J !:!!!!"^"|"""/#_##%&2&J&Z&e&&&&&'P'}'''' (C(|(((*W,,,H-`..M//-02[46y8:<<=>??|@eABD'FFGIKKM+N-NNIOO QsRRSQSST0TUCUU&VVVVWW0X2ZwZo[k\]]]s^^_%adeffgggghhhjxkkTllmnCnpY"#I+Z .E  *+STQRhi&\]?f!p} = l s y ~               !#!S!!!!!!!!"."C"u"""""#Q#{#####$%$E${$|$}$$$%%/%E%T%}%%%%&*&[&`&d&g&i&j&v&y&&&&&&&&&&&&+'4'e'''' ( ((F(R(((@@###$$$$$4D\\\\\\\4D\DD4$$44$$$$$$D[[[[[[[[[D[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[D[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[$[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[$[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[$[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[@[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[MQ 56789 %`1QV%dsT[x#"Ho L!79#(+:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\Unknown Anthony MazyLynn G. Van WagenenA Valued Microsoft CustomerCorporate Planning.#.A Valued Microsoft Customer@4A Valued Microsoft CustomerCorporate PlanningmR Greg Lizak,Greg LizakA Valued Microsoft Customer&t ,Greg LizakA Valued Microsoft Customer&t Dr. Martin J. Burns Debbie L Henderson 4Debbie L HendersonA Valued Microsoft Customerc 4Debbie L HendersonA Valued Microsoft CustomerOLorenzo Kristov(Lorenzo KristovDebbie L Henderson3(Lorenzo KristovDebbie L Henderson71Lorenzo KristovA Valued Microsoft Customer;1Lorenzo KristovA Valued Microsoft Customer@1Lorenzo KristovA Valued Microsoft CustomerA(Lorenzo KristovDebbie L Henderson5(Lorenzo KristovDebbie L Henderson6(Lorenzo KristovDebbie L Henderson41Lorenzo KristovA Valued Microsoft CustomerD1Lorenzo KristovA Valued Microsoft CustomerE1Lorenzo KristovA Valued Microsoft CustomerF1Lorenzo KristovA Valued Microsoft CustomerG1Lorenzo KristovA Valued Microsoft CustomerH1Lorenzo KristovA Valued Microsoft CustomerX1Lorenzo KristovA Valued Microsoft CustomerZ1Lorenzo KristovA Valued Microsoft Customer[1Lorenzo KristovA Valued Microsoft CustomerP 1Lorenzo KristovA Valued Microsoft CustomerQ!1Lorenzo KristovA Valued Microsoft CustomerR"1Lorenzo KristovA Valued Microsoft Customer\#1Lorenzo KristovA Valued Microsoft Customer]$1Lorenzo KristovA Valued Microsoft CustomerV%1Lorenzo KristovA Valued Microsoft Customer^&1Lorenzo KristovA Valued Microsoft Customer_'1Lorenzo KristovA Valued Microsoft CustomerW(1Lorenzo KristovA Valued Microsoft Customer`)1Lorenzo KristovA Valued Microsoft Customera*1Lorenzo KristovA Valued Microsoft Customerb+1Lorenzo KristovA Valued Microsoft Customerc,Diamond Technology Partners- John D. Payne.Energy Rates Branch/&Anthony MazyEnergy Rates Branch&YU0foobar1August J. Nevolo2F S V !!!_#l#q#(((<<<===KKK4NKNMNIOVO[OsRRRTT%TU%U,UUUUVVVVVVWWWghth}hyp}BOVmz[ho&+(+ˠ͠6CFrS`g+BD,9< -2m  ?LS(55  55555555 55555555555555555 555 555 5555 5 5555557LUVmuw~ !Title (