MXPA00002496A - Automated meter reading system - Google Patents
Automated meter reading systemInfo
- Publication number
- MXPA00002496A MXPA00002496A MXPA/A/2000/002496A MXPA00002496A MXPA00002496A MX PA00002496 A MXPA00002496 A MX PA00002496A MX PA00002496 A MXPA00002496 A MX PA00002496A MX PA00002496 A MXPA00002496 A MX PA00002496A
- Authority
- MX
- Mexico
- Prior art keywords
- server
- data
- distributed
- subsystem
- meter reading
- Prior art date
Links
- 238000010200 validation analysis Methods 0.000 claims abstract description 64
- 238000003860 storage Methods 0.000 claims abstract description 31
- 238000011144 upstream manufacturing Methods 0.000 claims abstract description 6
- 230000000694 effects Effects 0.000 claims description 342
- 238000004891 communication Methods 0.000 claims description 113
- 238000000034 method Methods 0.000 claims description 108
- 230000001360 synchronised Effects 0.000 claims description 47
- 238000011068 load Methods 0.000 claims description 29
- 230000004044 response Effects 0.000 claims description 29
- 238000006243 chemical reaction Methods 0.000 claims description 24
- 238000005259 measurement Methods 0.000 claims description 21
- 210000004556 Brain Anatomy 0.000 claims description 20
- 238000003780 insertion Methods 0.000 claims description 18
- 239000003795 chemical substances by application Substances 0.000 claims description 14
- 239000010410 layer Substances 0.000 claims description 13
- 230000004048 modification Effects 0.000 claims description 13
- 238000006011 modification reaction Methods 0.000 claims description 13
- 230000004301 light adaptation Effects 0.000 claims description 12
- 230000015654 memory Effects 0.000 claims description 12
- 238000011084 recovery Methods 0.000 claims description 12
- 230000001603 reducing Effects 0.000 claims description 11
- 238000006722 reduction reaction Methods 0.000 claims description 11
- 230000001105 regulatory Effects 0.000 claims description 11
- 230000006399 behavior Effects 0.000 claims description 10
- 230000000875 corresponding Effects 0.000 claims description 10
- 230000002085 persistent Effects 0.000 claims description 10
- 230000001419 dependent Effects 0.000 claims description 9
- 230000002452 interceptive Effects 0.000 claims description 9
- 239000003607 modifier Substances 0.000 claims description 9
- 230000002123 temporal effect Effects 0.000 claims description 9
- 238000010276 construction Methods 0.000 claims description 8
- 230000001960 triggered Effects 0.000 claims description 8
- 230000004913 activation Effects 0.000 claims description 7
- 238000005538 encapsulation Methods 0.000 claims description 6
- 241001417511 Ardis Species 0.000 claims description 4
- 230000000903 blocking Effects 0.000 claims description 4
- 238000003066 decision tree Methods 0.000 claims description 4
- 238000000605 extraction Methods 0.000 claims description 4
- 229920003258 poly(methylsilmethylene) Polymers 0.000 claims description 4
- 238000007374 clinical diagnostic method Methods 0.000 claims description 3
- 239000002365 multiple layer Substances 0.000 claims description 3
- 101700064519 PSTN Proteins 0.000 claims description 2
- 230000000977 initiatory Effects 0.000 claims description 2
- 230000011514 reflex Effects 0.000 claims description 2
- 230000015572 biosynthetic process Effects 0.000 claims 1
- 238000005755 formation reaction Methods 0.000 claims 1
- 230000005540 biological transmission Effects 0.000 abstract description 7
- 230000002688 persistence Effects 0.000 description 30
- 230000035492 administration Effects 0.000 description 14
- 230000003993 interaction Effects 0.000 description 13
- 238000004581 coalescence Methods 0.000 description 10
- 238000009826 distribution Methods 0.000 description 7
- 238000002955 isolation Methods 0.000 description 6
- 238000004519 manufacturing process Methods 0.000 description 6
- 239000000463 material Substances 0.000 description 6
- 101700053137 RTCA Proteins 0.000 description 5
- 238000011030 bottleneck Methods 0.000 description 5
- 238000010586 diagram Methods 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 5
- 239000000203 mixture Substances 0.000 description 5
- SHXWCVYOXRDMCX-UHFFFAOYSA-N MDMA Chemical compound CNC(C)CC1=CC=C2OCOC2=C1 SHXWCVYOXRDMCX-UHFFFAOYSA-N 0.000 description 4
- 235000008469 Oxalis tuberosa Nutrition 0.000 description 4
- 240000000645 Oxalis tuberosa Species 0.000 description 4
- 230000002354 daily Effects 0.000 description 4
- 230000002074 deregulated Effects 0.000 description 4
- 229940095399 Enema Drugs 0.000 description 3
- 241000792859 Enema Species 0.000 description 3
- 230000001413 cellular Effects 0.000 description 3
- 230000003831 deregulation Effects 0.000 description 3
- 239000007920 enema Substances 0.000 description 3
- 239000003999 initiator Substances 0.000 description 3
- 238000009434 installation Methods 0.000 description 3
- 239000000123 paper Substances 0.000 description 3
- 230000000737 periodic Effects 0.000 description 3
- 239000011089 white board Substances 0.000 description 3
- 206010000210 Abortion Diseases 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 2
- 231100000176 abortion Toxicity 0.000 description 2
- 239000002253 acid Substances 0.000 description 2
- 238000007792 addition Methods 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 2
- 230000000712 assembly Effects 0.000 description 2
- 238000004140 cleaning Methods 0.000 description 2
- 238000007418 data mining Methods 0.000 description 2
- 230000016507 interphase Effects 0.000 description 2
- 230000014759 maintenance of location Effects 0.000 description 2
- 238000002161 passivation Methods 0.000 description 2
- 230000003068 static Effects 0.000 description 2
- 230000014616 translation Effects 0.000 description 2
- 240000005020 Acaciella glauca Species 0.000 description 1
- 235000001211 Talinum portulacifolium Nutrition 0.000 description 1
- 240000004958 Talinum portulacifolium Species 0.000 description 1
- 238000009825 accumulation Methods 0.000 description 1
- 230000003044 adaptive Effects 0.000 description 1
- 230000002776 aggregation Effects 0.000 description 1
- 235000010357 aspartame Nutrition 0.000 description 1
- 238000010923 batch production Methods 0.000 description 1
- 230000003796 beauty Effects 0.000 description 1
- 239000000969 carrier Substances 0.000 description 1
- 150000001875 compounds Chemical class 0.000 description 1
- 230000001276 controlling effect Effects 0.000 description 1
- 230000002950 deficient Effects 0.000 description 1
- 238000003379 elimination reaction Methods 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 238000007667 floating Methods 0.000 description 1
- 239000000446 fuel Substances 0.000 description 1
- 230000003116 impacting Effects 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 230000000306 recurrent Effects 0.000 description 1
- 235000003499 redwood Nutrition 0.000 description 1
- 239000002965 rope Substances 0.000 description 1
- 230000002104 routine Effects 0.000 description 1
- 238000005070 sampling Methods 0.000 description 1
- 230000035945 sensitivity Effects 0.000 description 1
- 230000001131 transforming Effects 0.000 description 1
- 239000011800 void material Substances 0.000 description 1
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 1
- 230000003442 weekly Effects 0.000 description 1
Abstract
An automated meter reading server (15) having an open, distributed architecture that collects, loads, and manages system-wide data collected from energy meters (60) and routes the data automatically to upstream business systems. The automated meter reading server includes a repository (120) of metering data, and additionally provides timely access to information by including collection, storage, validation, estimation, editing, publishing and securing of meter consumption and interval data. The automated meter reading server obtains data from meters (60) equipped with modems via standard telephone lines or public RF networks. The data is converted from the format of the meter/communications infrastructure to a format usable by the automated meter reading server and the repository (120). The data is converted from the automated meter reading server compatible form to a format of a specific upstream business system prior to transmission.
Description
AUTOMATED METER READING SYSTEM
CROSS REFERENCE TO RELATED APPLICATIONS This application claims the benefit of the Provisional Patent Application of the United States of America with serial number 60 / 058,659, for Kelley et al., Filed on September 11, 1997, entitled "AUTOMATIC READING SYSTEM OF METERS ".
FIELD OF THE INVENTION The present invention relates in general to an automated meter reading system (AMR), and more particularly to an AMR server within the automated reading system which collects, loads and manages data from the meter meters. energy, and process and store meter data to route it to end users and business systems.
ACRONYMS AND KEYWORDS The described description provided herein contains acronyms and keywords to describe the various components and services of the system. Although it is known, the use of several of the acronyms and keywords is not standardized in the art. For the purposes of the description written herein, the acronyms and
keywords as follows: ACID - Atomicity, Consistency, Isolation, Durability
AMPS - Analog Mobile Phone System AMR - Automated Reader Reading API - BOM Application Program Interface - C &I Material Invoice - Commercial and Industrial CIS - CDS Client Information System - CDMA Phone Directory Service - Multiplexed Access Division of Code CDPD - Data in Digital Cellular Package CM - Communication Manager CORBA - Architecture of Common Purpose Request Broker
CPU - Central Processing Unit CRUDLE - Create, Read, Update, Delete, List and Exist
CSR - Customer Service Representative CURDLE - Create, Update, Read, Delete, List and Exist
DAO - Data Access Object DCE - Distributed Computing Environment DFS - Distributed File Service DSS - Distributed Security Service DTS - Distributed Time Service ESCO - Energy Service Companies that are not part of the national network nor are they commercial ESP - Energy Service Provider
GUI - User Interface Graph IDL - Definition Language of Inferid ISO - Operator of Independent System LAN - Network of Area Local LECRUD - List, Exist, Create, Read, Update and Delete
MDMA - Meter Data Management Agent OMS - Production Management System 00 - Object Oriented PM - Wholesale Energy Market Services PSTN - Public Switched Telephone Network PX - Energy Exchange RDBMS - Database Management System Relational
RF - RM Radio Frequency - RPC Resource Managers - RPU Remote Procedure Call - RQS Real-Time Processor Unit - RSP Recoverable Queue System - RTG Remote Storage Procedure - RTU Remote Terminal Door - Remote Telemetry Unit SC - Program Coordinator SCADA - Supervisory Control and Data Acquisition SFS - Structured File System SNMP - Simple Network Management Protocol SOE - Sequence of Events
TDMA - TM Time Division Multiple Access - TOU Transaction Manager - UDC Usage Time - UPC Services Distribution Company - VEE Universal Protocol Converter - WAN Validation, Editing, and Estimation - FM Wide Area Network - Flow Manager Job
BACKGROUND OF THE INVENTION The reading of electric power has historically been carried out with human readers of meters that arrive at the site of the clients' premises and manually document the readings. Over time, the manual reading of the meters has been improved by mobile reading systems that use radio communications between the meters and a meter reading device. The information of these travel or driving systems increase the collection, but still the functions provided by the communication systems are limited. More recently, in recent years, an effort has been made to automate the reading of meters by installing fixed networks that allow data to flow from the meter to a central computer system without human intervention, these systems have been named in the
technical as automated meter reading systems (AMR). Automated meter reading systems have gained interest because there are approximately 150 million meters installed, of which 17 million are considered "difficult to read" due to their location, and so on. One limitation in these automated meter reading systems is that they typically use only one type of communications infrastructure to collect data. For example, the automated meter reading system can receive meter data via any one of a fixed proprietary radio frequency communication infrastructure, the public switched telephone network O- power line transmission. This communication of a data infrastructure has led to the development of automated reading systems of incompatible meters that are tied to the particular communications infrastructure, use proprietary protocols and devices, and have unacceptably low data rates. These implementations are also deficient because radio frequency coverage is limited, and the public switched telephone network and energy line transmission solutions require relatively long periods of time to communicate data from the meter. In addition to the limitations with respect to communication infrastructures, reading systems
Automated conventional meters are not easily adaptable to changing requirements of both the energy supplier and the energy consumer. For example, although most meters measure energy monthly in kilowatt hours or time of use (TOU), consumers' growing demand for daily kilowatt hour or TOU readings, measurement of the load profile along with the capabilities of demand, production, power quality and monitoring of attempted violation will render conventional systems obsolete. For example, automated meter reading systems collect conventional data via a pulsed input, and for a period of time to determine the use of energy or can create a load profile. These systems, however, are not capable of reading data from intelligent meters that have been developed currently that provide a load profile information and similar to the automated meter reading system. Another limitation of the conventional automated meter reading system is that it does not adapt to the requirements of end-user systems (for example, billing systems, power management systems and supervisory control systems). These systems are typically independent systems, separate from the measurement system. One of the main reasons that the requirements of the end user systems are not met is due to the
limitations mentioned above because the automated reading systems of conventional meters were designed with proprietary systems instead of open systems. These systems generally produce the meter data in a raw format that is not compatible with the end user systems and that have to be converted for use. In this way, the automated reading systems of conventional meters perform validation, editing or estimation of the output data, and require a relatively high amount of manual intervention to transfer data from the automated meter reading system to the end users for further processing . Still another limitation of the automated reading systems of conventional meters is that the measurement data has been captured and managed using a traditional structure or biatated client / server architectures. While the structure and customer / server solutions have so far been relatively successful in addressing the needs of services and their customers, automated meter reading systems are increasingly becoming larger and more complex for conventional technologies. due to the amount of data that flows in and out of the system (for example, it may be necessary to store and process meter data daily or hourly for millions of meters). Like the
Data requirements increase steadily in the automated meter reading system, traditional structure and biatated architectures (non-distributed systems) experience limitations in memory, capacity of central processing units, and storage capacity due to an increasing amount of traffic Data on the network leads to bottlenecks that result in performance limitations as the data is shipped between the database and the customer, and records in the database can be blocked when client programs need to block data to use them. Updating these systems to increase the load capacity and performance requires interrupting the system. In addition, the cost of maintaining and updating these systems increases as companies try to solve client / server performance problems and scalability problems by buying larger and faster machines. In addition to the limitations mentioned above in the automated reading systems of conventional meters, perhaps the greatest limitation of the automated reading systems of existing meters is that the electrical services market moves towards deregulation. Under deregulation, service customers will be able to choose their electric service providers. As a result, the deregulated market has created many new entities of
business, which will place additional demands on automated meter reading systems. For example, in California, a server data management agent (MDMA) has been created which is responsible for collecting and publishing the data required for billing. In addition, MDMA requires that establishment quality data be provided as the MDMA publishes data for multiple business entities, including ESP, UDC, and other potential ancillary services (for example, third-party billing companies, etc.). However, the automated reading systems of conventional meters were not designed to conform to the demands of the deregulated market or provide these capabilities. In addition, automated meter reading systems are not adapted to the needs of commercial and industrial customers (C &I) and residential customers who are interested in determining usage statistics. Specific examples of automated meter reading systems and automated meter reading type are described in U.S. Patent No. 5,602,744, of the prior art, to Meek et al, entitled "Universal Data Collection System". Use of Send / Receive Services ", which describes a universal service usage data collection system that can respond and transmit consumption
of the registered service to readers manufactured by other vendors. An emulated "buried" protocol responds to another interrogation pulse from the vendor and tricks the other reader of the vendor into thinking he is communicating with one of his own meters. The interrogator and the data collection system can communicate synchronously or asynchronously depending on the vendor's implementation. U.S. Patent No. 5,553,094, to Johnson et al., Entitled "Radiocommunication Network for Remote Data Generation Stations", describes a wide area communications network that collects data generated by a plurality of electrical meters for the transmission to a central data terminal. The information is transmitted from network service modules to remote cell nodes, which then transfer the information to a central data terminal via intermediate data terminals. The network service modules transmit data packets over radio frequency transmission links to the remote cell nodes located at approximately two kilometer intervals, for example, at service poles or a building. The remote cell nodes periodically send information via radio frequency transmission links to the intermediate data terminals. The intermediate data terminals are located at intervals of 15 kilometers. Intermediate data terminals communicate
to the central data terminal via different types of links that include telephone lines, IT carriers, fiber optic channels, coaxial, microwave, or satellite cables. U.S. Patent No. 5,590,179, to Shincovich et al., Entitled "Remote Automatic Meter Reader Apparatus" discloses an adapter for providing automatic reading of conventional hour meter meters without requiring modifications to the meters or the cabinet in the which meters are mounted. The adapter is interconnected between the meter and the socket and includes internal telephone communication circuits. During a predefined transmission interval, a controller in the adapter changes the modes so that the adapter can be contacted via telephone to send data to the central service site. Distributed networks are also known to communicate data from devices having different formats and / or protocols. U.S. Patent No. 5,619,685, to Schiavone, entitled "Dynamic Adaptive Time Processing Process to Facilitate Communication between Computer Programs" describes a system whereby two different software programs can communicate with each other in a distributed network mapping memory blocks in and out.
In addition to the previous system, there are specific examples of automated meter reading products in use. A first is MV-90, which is a product sold by Itron / UTS. While the MV-90 supports multiple protocols of electrical meter manufacturers, as well as several gas meters, it gathers load profile, usage time, consumption and demand data, and performs some of the validation of meter data and issues alerts / alarms, the MV-90 only connects to a corresponding owner billing system (ie, the MV-PBS energy billing system). Another limitation is that the MV-90 is an automated meter reading system based on DOS, and therefore is a small-scale solution and is not scalable to accommodate larger scale entities. In addition, the MV-90 is limited to communicating with meters via a single telephone modem interface, therefore it is considered only a tactical solution for many energy service providers. Furthermore, MV-90 has not been designed to adapt and support multiple deregulated business entities and validation and estimation schemes of specific regulatory agencies. An example of another automated meter reading product is MAPS, which is offered by Schlumberger. MAPS is a server-client, automated meter reading system based on UNIX that collects data from
water, gas and electric. MAPS has central software that provides programming, network administration, access to use and load profile information, and analysis for the use of energy. The usage information can be shared with other systems such as billing. While the MAPS may be more robust than the MV-90, it is also limited by the number of meter endpoints from which the information can be collected. In addition, there are no validation or data estimation schemes, and MAPS will not adapt to multiple market entities. In view of the limitations of automated meter reading systems and automated meter reading type, the automated meter reading system of the present invention attacks the needs and limitations of known systems, providing an end-to-end system that combines communications, data storage, processing and consolidation as well as presentation and standard application interface options. In particular, the present invention provides an all-inclusive, highly automated solution providing an integrated system that is capable of receiving data from a plurality of dissimilar measurement devices and communication networks, managing the data, and communicating the data to a plurality of applications and end-user systems. The automated meter reading system of this
invention is adapted to communicate with copyrighted systems and other proprietary systems to provide a total automated meter reading solution not found anywhere in the prior art. The automated meter reading system addresses the need for diverse communications technologies resulting from the relationship of radio frequency coverage with population density (for example, rural areas can use implemented telephone solutions due to a population density very low, while urban areas are more likely to use radiofrequency solutions). The automated meter reading system of the present invention addresses the needs of energy suppliers by enabling them to meet the expectations and demands of the consumer and to compete more effectively in the industry that is currently deregulating to encourage increased competition.
SUMMARY OF THE INVENTION In view of the foregoing, the present invention, through one or more of its various aspects and / or modalities, provides one or more features and advantages over the prior art, such as those noted below. The present invention is directed to an automated meter reading system (AMR) server that offers
a large-scale system solution to address the needs of measurement data administrations of the entities involved in the distribution of energy. The automated meter reading server is a distributed, open architecture, which collects, loads, and manages large system data collected from energy meters and routes the data automatically to upstream business systems. The automated meter reading server is an end-to-end, integrated, scalable, standards-based measurement data management solution. Energy suppliers can capture consumption and measure the data range for hundreds of thousands of meters, deliver them directly to business functions such as billing or CIS, and supply the data to large industrial trading accounts. The automated meter reading server is designed to be a repository of measurement data, and additionally provides timely access to critical energy information including features such as collection, storage, validation, estimation, editing, publication and assurance of meter consumption and data in intervals. The automated meter reading server also performs server data aggregations, meter and account management, and includes application program interfaces published for integration of
business systems. The automated meter reading server also includes a scalable database that has a distributed architecture that can store data from hundreds of thousands of measurement points. The data of each meter can be managed separately, or added to subsets defined by the user. The automated meter reading server obtains data from meters equipped with modems via standard telephone lines or public radiofrequency networks. The automated meter reading server is designed to provide acceptable entry and update times for a large volume of data, provide fast response times for online users, interfaces with multiple dissimilar platforms and unalterable meter memories, maintain system availability , provide fast data recovery, be accessible to multiple systems with legacy, and be accessible from an application program interface (API) for communication servers, adapt to a variety of third-party communications technologies. In accordance with one aspect of the invention, an automated meter reading device is provided that collects telemetry data for remote customer locations and processes the telemetry data for use by end users and upstream business systems.
The automated meter reading server comprises a data warehouse for storing the telemetry data, at least one external interface for communicating with external systems of the automated meter reading server, and software architecture distributed in multiple layers. The software architecture distributed in multiple layers includes subsystems of applications and infrastructure that includes services that are distributed throughout the server of automated reading of meters to cooperate to carry out previously defined business functions, software adapted to the client to facilitate scalability , transaction processing, and object mapping to the data warehouse, and application structures to facilitate access to the data warehouse and the creation of processes that comply with the software adapted to the client. Business functionalities determine the processes by which the automated meter reading server receives data from downstream collection points, processes the telemetry data, and manipulates the data warehouse. According to a feature of the invention, the client-adapted software provides communications facilities for communicating information between clients of the automated meter reading server and the automated meter reading server, data transport and
data conversion facilities; and a mechanism through which clients can locate servers within the distributed architecture. Client-adapted software also provides load balancing and scheduling by assigning services to application servers based on a priority. Each of the application servers can consist of multiple processing agents and can be multi-wired. A plurality of application servers can be executed simultaneously on multiple physical devices comprising the automated meter reading server to distribute the loads of clients across the multiple physical devices. In accordance with another feature of the present invention, the automated meter reading server accesses the data warehouse via transactions and transaction processing. Transactions are isolated from each other to prevent other transactions from accessing data that a particular transaction is using until the particular transaction ends. A recoverable queue system can be provided to queue the transaction job to complete at a later time. The data warehouse comprises an object-oriented design that is resident in a relational database implementation, so that object-to-relational mapping is done by mapping a tabular relational database to object structures and can
use a temporary structure. The temporal structure comprises timestamp ranges for each table within the relational database to provide different historical views of the data stored therein. The data warehouse can be designed to represent a high-level model and so that each high-level object is mapped to the data warehouse. According to still another feature of the present invention, the application structures comprise a data access object structure and a distributed services structure. The structure of distributed services includes classes to provide a factory for any object or type of atomic data that has been defined within a class mapping directory, a pointing to an instance of a specific type of object, and a wrap around the instance , a whiteboard to share the information used in an existing Activity Plan, a mechanism that provides an invocation to the execution time of the functions based on a representation of a function name, and a mechanism that provides encapsulation of a chain of pairs of label values and manipulation and extraction of information from the chain. The structure of distributed services hides the detailed implementation of the data warehouse of an application providing representatives of distributed objects, and where the deposit
of data is not accessed directly by external applications. The data access object structure provides representatives, administrator servers, and back end implementation servers to isolate the relationships of the telemetry data in the data warehouse in order to provide access to the telemetry data. According to another feature of the invention, the infrastructure subsystem supports the application subsystem, and comprises generic and reusable components that are not aware of the application domain of the automated meter reading server. The application subsystem includes services that execute a plurality of application servers that have detailed and specific knowledge about the automated meter reading domain. According to another characteristic, the infrastructure subsystem comprises an activity management subsystem. The functionalities of the business that will be performed by the automated meter reading server are extracted in Activity Plans to isolate the business functionalities of the application code comprising the software architecture in order to provide various business functions without requiring substantial modification of the application code. Activity Plans control the workflow within the server
of automated reading of meters, and the activity management subsystem invokes and manages the Activity Plans. Activity Plans include at least one task, where a task is a discrete unit of work in the Activity Plan that is controlled by a single server in the system. The tasks are responsible for the processors to overcome failures, being the processors to overcome failures a list of operations that are going to be carried out in case of a failure, being determining the fault based on conditions of return after executing an activity. The activity management subsystem includes an Activity Plan builder to build an orderly collection of tasks and initialize a message board to share information, a dispatcher panel to initiate Activity Plans, and route responses from servers within the automated reader server. meters to an appropriate Activity Plan where it works within the Activity Plan and sends queued messages to other servers within the automated meter reading server, a dispatcher storage manager to control access to persistent Activity Plans, and a Plan of Activity monitor to show a user the status of any type of activity by name, or by selection. According to another characteristic, the infrastructure subsystem comprises a programmer subsystem, which manages
the construction and execution of programs within the automated meter reading server. The programs are used to control the time-based execution of work within the automated meter reading server. The programmer subsystem comprises a program manager server and a programmer, which manages the creation, updating and retrieval of programs from and from the data warehouse, and retrieves programs. The programmer determines the duration of the execution of a task and adjusts the execution durations according to heuristic-tuning parameters. The scheduler subsystem may comprise a delivery schedule that notifies a provider when to deliver data to the automated meter reading server, a billing program that determines the timing of data delivery from the automated meter reading server to the service for invoice, and a collection program that determines when to collect data and what type of data to collect. According to still another feature of the present invention, the infrastructure subsystem comprises an alarm subsystem that receives requests for timed messages, and when an alarm occurs, a response call is made to an alarm subscriber. According to another feature of the present invention, the infrastructure subsystem comprises a
a management awareness subsystem that provides distributed event management and an occupancy mapping for entities within the automated meter reading server. Entities include a seller, which is someone who can provide notification of an event, or a solicitor, who is someone who has an interest or concern in an item that can be provided by a seller. According to a feature of the invention, the infrastructure subsystem comprises a mapping subsystem which provides services for the adaptation to the client of file formats for exporting data from, and importing data from, the automated meter reading server. The adaptation to the client of the file formats is done according to maps. The map subsystem can include a canonical mapper, which includes an input map, a canon, and an output map to map information from an input file format to an output file format. Input and output maps are used to map information through subdomains, where there are at least two subdomains under the same root domain. A mapping interface server that sends requests to the canonical mapper can be included, and the input and output maps can be bypass trees. The canonical mapper builds a syntax scanner / analyzer for an input entry subio,
traverses the input map, analyzes the data of the input file in a canonical list, and maps from the canonical list to an output subdomain by crossing the output map and reinterpreting the corresponding element of the canonical list to conform the new format of data to create the specific output file. According to yet another feature, the infrastructure subsystem comprises a record / trace subsystem that generates records for monitoring purposes and determines a cause of problems that occur in the meter reading server. The records can be activated at runtime or by any of the individual servers within the automated meter reading server. According to still another feature, the application subsystem further comprises a provider subsystem that is adapted to communicate with a provider according to a provider format. The provider subsystem encapsulates differences in communication formats so that customers of the external interface do not need to know what type of provider they are communicating with. Exit requests to suppliers are carried out through the Activity Plans that control the work flow within the automated meter reading server, and the services fired from a provider
they will begin Activity Plans to carry out the tasks. The provider subsystem may comprise a provider administrator, a supplier's exit, a supplier's entry, and reduction control servers, and route meter service requests from automated meter reading services to an automated meter reading service responsible to connect with an external system. The provider subsystem directs the requests for incoming service from the communication servers, connected to the automated meter reading server, with activities within the automated meter reading server responsible for attending the request. According to a further feature, the application subsystem comprises a subsystem of data access object. The data access object subsystem contains data access objects for manipulating data within the data warehouse, wherein the data access objects are representations of tables within the data warehouse. The data access objects have a hierarchical relationship with each other, so that a type of object or collection contains or is contained by another type of object or collection. In addition, the data access subsystem uses proxy objects to interact with the application structures, where the proxy objects are provided by the application structures to encapsulate relationships and the
behavior of data. The data access object subsystem may comprise a plurality of management servers that provide meter-related services, tariff-related services, services related to meter groups, upload of received and mapped data in the data warehouse, retrieve samples of reading the automated meter read data repository, determining the capabilities of a particular recomponent instance, and providing lists of reference data. According to yet another feature, the application subsystem comprises an export subsystem that exports data to external application systems by mapping and formatting data from the application systems. The export subsystem can comprise an export administrator and a validation, editing and estimating administrator. The Validation, Editing and Estimation Manager performs the validation, editing and estimation of output data to be exported so that the output data have the characteristics desired by a requestor of the output data. The Validation, Editing and Estimation Manager performs the validation according to a plurality of regulatory agencies to produce the establishment of quality data. In addition, the administrator of validation, editing, estimation uses Plans
of Activity to control the work flow within the server of automated reading of meters. According to another feature of the present invention, the application subsystem comprises a service interface that communicates with external systems and accepts requests from external systems. A graphical user interface can be provided which interacts with the service subsystem and provides at least one of the accesses to the automated meter reading server to manually invoke all interfaces of the online business system, search meter-specific information / account / rate / event, provide access to the monitor of the activity management system, and provide an interface to programs. The graphical user interface can use application programming interfaces of the application system provided by the service interface subsystem to initiate requests. According to a feature of the invention, the external interface includes a standards-based application programming interface and a file-based interface. The external interface mechanism communicates with a canonical mapper that constructs a map that specifies the translation required to perform a conversion from an input format to an output format. Interphase application programming interface requests based on
standards can be either synchronous or asynchronous requests. Synchronous requests return request outputs directly to a requestor where the request was made, and where the asynchronous requests return to the status of a request start from the application subsystem to the requestor and, at a later time, provide an asynchronous notification the requestor with the request exits. In accordance with another feature of the invention, the automated meter reading server is adapted to manage a plurality of dissimilar legacy systems and dissimilar client-to-client requirements, business functionality logic, and regulatory requirements. According to another feature, at least one communication server is provided for communicating telemetry data on at least one communication network. The automated meter reading server is adapted to receive telemetry data via dissimilar communications networks. In addition, a plurality of dissimilar meters communicate the telemetry data vi dissimilar communications networks. The communications networks can be wireless or public switched telephone networks. According to another feature, the automated meter reading server notifies end users about service interruption alerts, notification
of attempted violation, home viewing of electrical information, programming of meters, remote monitoring of energy quality, and customer service diagnostics. The automated meter reading server measures the use of energy, the use of energy being measured in one of kVARh, kVAh, kh, and time of use. In accordance with another aspect of the invention, a distributed server is provided that receives and processes information for use by end users. The distributed server includes a data warehouse for storing the information, at least one external interface for communicating with external systems of the distributed server, and a multi-layer distributed software architecture. The multi-layer distributed software architecture distributes application and infrastructure subsystems that comprise distributed services throughout the distributed server that cooperates to perform operations within the server, software adapted to the client to facilitate scalability, transaction processing, and object mapping to the data repository, and application structures to facilitate access to the data warehouse and the creation of processes that comply with the software adapted to the client. The distributed server receives data from collection points downstream, processes the data, and manipulates the data warehouse to carry out the operations.
According to still another aspect of the invention, a resident server with a multi-layer distributed software architecture is provided. The server includes a data warehouse for storing data received by the server, at least one external interface for communicating with systems external to the server, a subsystem of services comprising distributed services running application servers within the distributed architecture, software adapted to the client to facilitate the scalability, transaction processing, and object mapping to the data warehouse, and application structures to facilitate access to the data warehouse and the creation of processes that comply with the software adapted to the client. Server-based procedures are managed according to predetermined activities. The features of the latter aspects of the invention include those noted above with respect to the automated meter reading server.
BRIEF DESCRIPTION OF THE DRAWINGS The above summary, as well as the following detailed description of the preferred embodiments, is best understood when read together with the accompanying drawings.
For the purpose of illustrating the invention, the currently preferred embodiment is shown in the drawings, in which
Like reference numerals represent similar parts in all views of the drawings, it being understood, however, that the invention is not limited to the specific methods and instrumentalities described. In the drawings: Figure 1 illustrates an overview of an architecture of automated meter reading systems according to the present invention. Figures 2A-2D illustrate an exemplary hardware configuration of an automated meter reading server for small scale deployment. Figure 3 illustrates the software architecture of the automated meter reading server which includes a triatated system, software products adapted to the client, a database repository and external interfaces. Figure 4 extends the automated meter reading application and the infrastructure subsystem block shown in Figure 3. Figure 5 illustrates the relationship of a delivery schedule with a programmer subsystem. Figure 6 illustrates the relationship of a mapping interface server with subsystems of the AMR. Figure 7 illustrates the process of converting a file between two applications. Figure 8 illustrates a record / trace subsystem. Figure 9 illustrates in block diagram format
a GUI client connected to the automated meter reading server. Figure 10 illustrates a provider subsystem in accordance with the present invention. Figure 11 illustrates the process of synchronous requests to the automated meter reading server. Figures 12A and 12B illustrate the process of asynchronous requests to the automated meter reading server in asynchronous notifications of the automated meter reading server. Figures 13 and 14 show the interaction between admin servers, representatives, and deployment servers within a DAO subsystem. Figure 15 illustrates the process performed each time a method is invoked in a representative. Figure 16 illustrates an exemplary structure of the database designed as a high-level object model. Figure 17 illustrates the logical architecture of the account management subsystem. Figures 18A-D illustrate the logical architecture of the capacity manager. Figure 19 illustrates the logical architecture of the meter manager. Figure 20 illustrates the logical architecture of the tariff manager.
Figure 21 illustrates the logical architecture of the read management server. Figures 22A-B illustrate the logical architecture of the program manager. Figures 23A-E illustrate the program manager. Figure 24 illustrates the logical architecture of the system parameters. Figure 25 illustrates the logical architecture of the translation service. Figure 26 illustrates the process of a measurement reading on demand. Figure 27 illustrates a canonical element "BOM". Figure 28 illustrates the "cost" canon. Figure 29 illustrates the main screen of the builder of the Activity Plan according to the present invention. Figure 30 is a graphic representation of several available paths for a particular workflow. Figure 31 illustrates a modification of a particular task to execute, undo, or end an operation. Figure 32 illustrates modifications of an operation. Figure 33 illustrates slot names with a whiteboard object that contains the types of specific values used to execute the operations.
Figures 34A-D illustrate the interaction of strings with the subsystem of validation, editing and estimation.
BRIEF DESCRIPTION OF THE APPENDIXES In order to facilitate the detailed description of the present invention, reference is made to the annotated plurality of appendices by way of non-limiting examples of the preferred embodiments of the present invention, which are provided with respect to several features, operations and functions of the invention, and wherein: Appendix A contains a top-level interaction diagram illustrating different servers and objects invoked for an operation; and Appendix B contains the database structure for the automated meter reading server of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED MODALITIES The automated meter reading server of the present invention advantageously offers a large-scale system solution for directing the measurement data management and administration of the systems that the administration performs. The automated meter reading server is designed to provide business entities in the energy industry with reading systems
Automated meters that could serve as a single source to measure data. As will be described in detail below, the automated meter reading system of the present invention is designed as a distributed system to adapt to a variety of legacy systems and existing platforms in the current market, and is scalable, flexible and adaptable. The system is adapted to adapt to customer-to-customer differences in requirements, business logic, and regulatory requirements. An overview of the architecture of the automated meter reading system 10 is illustrated in Figure 1. The automated meter reading system includes an automated meter reading server 15 that collects, loads, and manages measurement data across the entire system with electronic or electromechanical meters 60 located in customer premises 70 and automatically routes them to upstream business systems 50
(collectively, external application and communication systems). Energy suppliers can capture the consumption and data from interval meters for hundreds of thousands of meters 60, deliver them directly to functions and business systems 50, and finally supply the data to large commercial and industrial accounts 40. In addition, the automated meter reading server 15 serves as
deposit for existing business application systems 50 that belong to energy service providers (ESP) and / or service distribution companies (UDC), such as customer information systems (CIS), billing, customer services, and interruption management systems (OMS). The measurement data can be collected via the communication servers .30 from a variety of dissimilar meters 60 and transmitted using multiple dissimilar types of media and infrastructures 80. The automated meter reading server 15 is designed to compensate complications introduced by variations in dissimilar meters 60 and means of communication 80, and presenting an abstract view of the entire measurement system to the business applications of end users 50. The automated meter reading server 15 allows various business systems 50 to interact with meters 60 and measure data without the restrictions of the configuration details of the systems. For example, the automated meter reading server 15 allows a billing system to create a billing program for a collection of meters 60 and have this data delivered to a specific location according to the program. The collection of meters 60 that will be invoiced can be of different types of meters and distributed through several
means of communication 80 each having different network restrictions that complicate data collection. Meanwhile, the billing system is not required to be aware of these complexities. As will be described in greater detail hereinafter, the architecture of the automated meter reading server 15 is represented as a cooperative set of services running in a distributed architecture. The distributed architecture of the automated meter reading server 15 is designed with three ties, instead of the traditional two. A triatated system advantageously allows customers to make small requests for services, instead of large data requests, via application servers that can be programmed so that they do not create blocked contention in the database. Application servers can run on many machines simultaneously in a configuration called "application replication" that distributes client loads across multiple machines and allows for greater availability, scalability, and performance. Additionally, the total number of connections in the database can be reduced because the application servers manage client "sessions" and multiple clients can share the database connections. The architecture is designed to be scalable from a small service (approximately 10 thousand
meters) up to a large service (3 million meters or more). The automated meter reading server 15 is preferably a distributed architecture because these systems are flexible, scalable, and efficient. Another advantage of distributed systems is that the hardware components of a distributed system can be located and added when needed. Therefore, as needs change over time, the components of a distributed system can be easily moved and reconfigured without impacting performance. Distributed processing allows the automated meter reading server 15 to be scalable and grow, as the data management needs change. In addition, by distributing large amounts of data across multiple servers, higher results are achieved resulting in better performance and better data management. Distributed systems can provide greater availability because planned interruptions can occur and are immune to single points of failure. Individual computers or links can be disconnected from the system to test, repair, or modify them without a negative impact on the system. In addition, the automated meter reading server 15 will provide SNMP support supplemented with other tools. Communication with the meter or meter modems
preferably it is supported as initiated by the server and calls initiated by the meter modem. Communications in two directions allow both service providers and end users to have functionalities that are currently limited in availability. Some of these functions would include: interrupt alerts, buffer notification, home viewing of electrical information, meter scheduling, remote energy quality monitoring, customer service diagnostics and more. The communication infrastructures supported in the automated meter reading system 10 include, but are not limited to, CDMA (Code Division, Multiple Access), telephone and international DAA, ARDIS, X25, RAM, ReFlex, AMPS (Mobile Phone System) Analog), CDPD (Data in Digital Cellular Package), TDMA (Multiple Access Time Division), and AMPS (Digital Analog Mobile Phone System). Figure 2a-2d illustrates an exemplary hardware configuration of the automated meter reading server 15 for a small scale dump. The exemplary hardware configuration assumes an initial void configuration with a design scope of approximately 10 thousand meter points. As illustrated, the exemplary initial configuration includes Sun E3000 database server (or another enterprise level server) running Oracle® RDBMS, and the
Monitor Suite Encina®; a Sun Ultra 2 running all other distributed systems; an EMC disk array, a Veritas ATL DLT backup system; and a Proliant 5000 compaq that runs a canonical mapper (discussed later). This configuration is scalable to adapt larger numbers of meters, as noted above. The communication servers 30 of this base configuration run over a wide area network (WAN) and can be scaled to a geographically dispersed telephone solution or a wireless communication system (e.g., Ardis, CDPD or PCS). The communications server 30 may comprise an RCS 250, available ABB Power T &D Information Systems, Raleigh, North Carolina, as configured in Figures 2A-2D. Returning to the software implementation of the automated meter reading server 15, it is noted that in recent years object orientation in software development has shown that the encapsulation of the logic or behavior with the data is useful for building flexible systems. However, new systems require dynamic business functionality based on changing customer needs or customer differences. Triatated architectures are implemented using views and interfaces of simple application programs to connect to a domain server that in turn handles encapsulated business objects that are persistently stored in the base
of data. This works well for business logic abstracted from the application logic; however, they are limited because when the business logic changes, business logic objects must be recoded within the system. The present invention improves traditional triating systems by being flexible and adapting to dynamic business requirements. This flexibility is provided by the automated meter reading server 15 as an extension made to traditional triating approach. This extension is to extract the business logic in objects called Activity Plans. Activity Plans or control of workflows control the workflow in a system. The Activity Plans are a set driven independently of flexible and cooperative services that do not require programming, since the work logic is not firmly codified in the system, but appears as tasks in the Activity Plans. Activity Plans can thus be accommodated to different business models. In addition, the Activity Plans contain a well-defined interface, and include dynamic rules. Referring now to Figure 3, as part of the triatado system, software products tailored to the client are used to promote scalability and adaptability in the automated meter reading infrastructure and
automated meter reading architecture. For example, software products tailored to the client such as Common Purpose Request Broker Architecture (CORBA) and Distributed Computing Environment (DCE) 112 can be used. However, it is preferable to use DCE since CORBA does not provide some key capabilities (eg, Distributed Services, Distributed File Services, Distributed Security, and Transaction Processing support) that are preferably provided on the automated meter reading server. In addition, CORBA is a relatively new technology and lacks support for all major platforms (eg PCS for mainframes). The DCE 112 environment consists of a series of integrated software services that are part of a computer system infrastructure. The DCE 112 plays an important role in critical areas of computing, such as security, Internet-Intranet computing, or distributed objects. The DCE 112 technology is designed to operate independently of the operating system 118 and in the networking technology used by the applications. As a result, it allows interaction between clients and servers of any environment. As shown in Figure 3, the DCE technology comprises software services that logically reside "on top" of operating system 118. These services
they employ low-level operation systems 118 and network resources to carry out their tasks. DCE 112 services include a remote procedure call (RPC) that facilitates client-server communication so that applications can effectively access resources distributed through a network, a security service that authenticates the identities of users and authorizes access to resources using a user method and an account manager, a directory service that provides a single appointment model throughout the distributed environment, a time service that synchronizes system clocks across the network, a service of string that provides multiple strings of execution, and a distributed file service that provides access to files through a network. Each one will be briefly described now. The DCE RPC facility facilitates the development of the distributed application by modeling distributed processes as a subroutine of the caller of that subroutine. The subroutine is the implementation of the server and the caller of the subroutine is the client. The DCE RPC provides the developer with basic services that the application developer would otherwise have to implement, such as communication facilities required to communicate between the client and the server, mechanisms for the client to locate the
server within the network and data transport through the network, and conversion of data from one format to another as necessary. Distributed time service (DTS) serves two important purposes. The DTS service keeps all computers within the network reasonably close to the same time (even if their hardware clocks do not run at exactly the same speed) and keeps the network nodes connected to a synchronized public time service. The distributed security service (DSS) ensures that services are provided only to the designated parties. Security in a distributed environment presents important challenges because as users disperse in several places they need to have authorization to access the system. An appropriate level of access is determined for each of the users who are authorized to access the system. Also, security privileges are verified against the actions that users want to perform. The Distributed File Service (DFS) provides the ability of programs to access files located on a file server as if the files were located on the local system's hard drive. The distributed application does not have to know where the files are located or that the files are not locally located on the disk. The DFS has a unique namespace,
consistent, and global for all files, which means that all the nodes in the network identify the same file by the same name and see it located in the same directory. The DCE cellular directory service (CDS) provides a reliable mechanism by which distributed applications can associate information with names. The main purpose of the CDS is to allow customers to locate servers. The cell directory service implements a hierarchy of names accommodated in a tree structure in which each item has exactly one parent and zero or more children. The CDS provides appointment of a local set of nodes called a cell. Within the distributed environment, transactions are monitored to ensure the proper functioning of the system. On the automated meter reading server 15, Encina® 106 (version 2.5 or higher) is used to monitor transactions (see Figure 3). Encina® 106 is a family of products, offered by Transare® Corporation, to develop, execute, and manage distributed transaction processing systems. A distributed system consists of multiple software components that run separately in separate processes on different machines in a network. Transactions are a tool for programming distributed systems that signify failure scenarios. A transaction is a set of
operations that make up data from one consistent state to another. This set of operations is an indivisible unit of work, and in some contexts, a transaction is called a logical unit of work. Transactions that configure a transaction typically consist of requests for existing data, requests to modify existing data, requests to add new data, or combinations of these requests. Transactions provide several important properties called ACID properties (atomicity, consistency, isolation, and durability). Atomicity refers to the property that a transaction is either successful or not successful. A successful transaction is said to be fulfilled. An unsuccessful transaction is said to abort. Any operation performed by an aborted transaction is not done (backed down) so that its effects are not visible. Consistency refers to the property in which each transaction transforms distributed data from one consistent state into another. The application program is responsible for ensuring consistency. Isolation refers to the property in which each transaction seems to run independently of other transactions that are running concurrently. The effects of the transaction are not visible to other transactions until the transaction is completed (either fulfilled or aborted). The transactions
they appear to be serialized, with two or more transactions acting as one completed before the other begins, even when they are executed concurrently. Durability, also known as permanence, refers to property where the effects of a transaction are permanent as soon as they are completed. Preferably, transactions are used to control and moderate access to a database. ® Transactions are monitored by the Encina ® Monitor (not shown). Enema Monitor provides the infrastructure to build and empty client / server applications, such as an environment that protects application programmers from the complexities of distributed computing, fault tolerance across heterogeneous environments to provide high performance and integrity. transactions, and a comprehensive management environment that allows widely distributed monitor-based systems to be managed as a single logically defined system. The Enema ® Monitor provides methods to simplify load balancing and programming. These methods include assigning a priority to each application server, multiple processing agents for each application server, and multiple application servers for ropes. Transactions are preferably isolated from each other to prevent these transactions from accessing data at a
particular transaction that is being used until the transaction is complete. This could result in blocking the database and preventing other users from accessing the data until the transaction is completed or aborted. An important design goal of transaction applications is to complete transactions quickly, unblock blocked data and give other transactions access to data as quickly as possible. This characteristic is carried out via a retrievable queue system (RQS), which will be described later. ® The Encina Structured File Server (SFS) is a record-oriented file system that provides transaction integrity, record-based recovery, and broad scalability. The SFS uses structured files that are composed of records. The records themselves are made of fields. The structured file system is the collection of data managed by a single structured file server (SFS). All access to a structured file system is through a single server, using a special type of open file descriptor (OFD). As noted above, the automated meter reading server 15 is an object oriented system that retrieves and stores a large amount of persistent data. While an object-oriented database or a relational database could be implemented in the
automated meter reading server 15 for storing persistent data, object-oriented databases (00) are new and have not actually been tested on large distributed systems because they are unable to handle the large volume of data. The relational databases have been established, tested and implemented for years and since then the relational database technology entails transactional integrity, blocking and concurrency solutions, and distributed databases. However, it is preferable to use a combination of relational database / object-oriented solution in the automated meter reading server 15. The automated meter reading server 15 uses a relational database with an object-oriented design in the top of the relational strategy. The database preferably comprises Oracle RDBMS 116, and the application servers Encina 106 (Meter Manager, Rate Manager, etc. that will be discussed later) uses design 00 to implement its mapping to related data in Oracle. He
® Oracle RDBMS 116 shown in Figure 3 is available from
® Oracle Corporation, Redwood Shores, California. In order to attack the mismatch between the 00 development and a relational database, the software
Persistence (version 3.4.2 or greater) 108 was selected, as shown in Figure 3. The Persistence 108 software is
available at Persistence Software Inc., San Mateo, California. Persistence 108 performs object-to-relational mapping which is the tedious translation and mapping of the two-dimensional relational database 120 to the much more complex object structures in the automated meter reading server 15. Persistence 108 also performs memory Immediate object that provides the automated meter reading server with a "local copy" in the database to improve performance and monitors and updates the changes in the database in the instant memory. In addition, the Persistence 108 provides database independence which ensures that the database functionality works consistently on the automated meter reading server 15 regardless of the type of relational database system behind Persistence. This latter capacity, although not essential, is preferred. The Persistence 108 software provides a platform independent class library interface, independent of the platform, to a variety of relational database management systems (RDBMS). The Persistence 108 software consists of the class libraries of the Persistence Object Builder and the Persistence Object Server. The Persistence object constructor automatically generates object-oriented C ++ classes for use when building database applications
high performance relationships. The Persistence object constructor creates the C ++ classes generated by Persistence based on a database schema designed for the automated meter reading server 15. The Persistence object server class library supports the classes generated by Persistence and mediates the activity of RDBMS. The generated classes contain derived methods for all common database operations. The automated meter reading server 15 preferably accesses the relational database 120 transactionally. This capability is provided via Transaction Processing (see protocol XA 110 in Figure 3). The relational database management system (RDBMS) 116 or one of the Encina 106 resource managers (such as SFS or RQS) preferably supports transactional semantics that ensure if the transaction is aborted, any changes in the database are undone . The XA specification describes what a resource manager does to support transactional access. Briefly, X / Open, an international standards body, defines the components that interact in a typical transaction processing system. These include the Transaction Manager (TM), which manages distributed transactions and decides whether they are fulfilled or aborted; Resource Managers (RM), which
store recoverable data; the Communications Manager (CM), which communicates between transaction managers and other components; and the application code. There are also X / Open standards for the interactions between these components. The most commonly implemented specification is the XA specification, which defines the interaction between TM and RM. Typically, Encina® 106 acts as the TM, and the databases that comply with XA are the RMs. The XA ® specification defines the interaction between RM and TM. In Encina 106, the XA 110 protocol is implemented in the TMXA module. The TMXA, in turn, registers functions to return the call with TRAN to determine when the transactions are prepared, aborted, and fulfilled. It also records response calls with the "cuerdaTid" module to be notified when a new transaction is submitted. The XA 110 protocol specifies how the TM interacts with the RMs. However, it does not specify how the application code connects to the RM. Application programmers using the XA 110 protocol use the TM application program interface to start and end transactions, and use the original RM application program interface to access and modify data. The XA 110 specification is not a communications protocol, but a set of functions that is
implemented through the RM and are called by the TM. There are also some functions implemented by the TM that will be called by the RM. It is important that the TM be able to handle transactions in several RMs at the same time. Thus, these XA functions are provided to the TM by means of a table of function pointers. This structure is called the "XA switch". Defined by each RM, the switch includes function flags for the functions in the XA application program interface, and marks those that specify the exact behavior of the RM. Referring again to Figure 3, a database access object structure 102 and a distributed services structure 104 (collectively called application structures) are built on top of the software products adapted to the client to simplify the use of these products and alleviating the need for programmers to have detailed knowledge of the creation of applications that initiate and establish the environment required for these products. The database access object structure 102 hides the detailed implementation of the database 120, as represented by the Persistence objects, from the application by providing representatives of distributed objects. The distributed services structure 104 provides classes that hide the details of how to create the servers that comply with
®. . .
DCE / Encma (processes). The structure of distributed services
104 also protects the application of the underlying communication mechanism (RPC or queued) that is being used. The distributed services structure 104 comprises several kinds of services including object store, generic object, board, executor and tag value list classes. The object store is a unique one that exists within the process space of a module. The WarehouseObject class is provided to serve as a factory for any object or type of atomic data that has been defined within the mapping directory of the WarehouseObject class. You can create new instances of these objects based on a string representation of the class name of the object to be created. It also provides functionality to model these newly created instances to the appropriate data types, so that messages can subsequently be sent and accessed if the object was specifically urged to the objects in the code. Because the communication limits for the automated meter reading server 15 are difficult to define, a common mechanism for interprocess communication has been created. This common mechanism is "messaging". The pieces move easily in and out of the automated meter reading server 15 as needs arise using a messaging concept for all
Intra and inter systems communication. Messages are sent to named objects. A third party or "broker" is responsible for delivering the message to the recipient and ensuring that the return value is returned to the requester. Commonly, this type of interprocess communication is described by the CORBA standard. Typically, messages are defined that are supported by all systems and use a common language called the interface definition language (IDL). By building the automated meter reading server 15 along these lines, this provides manageable changes for the automated meter reading server 15 in the future. The generic object class provides some of the dynamic functionality that is similar to a run-time limit environment typed weekly such as Samlltalk. The generic object class is designed to be used as an extension of the WarehouseObject. An example of a GenericObject contains a pointer to an instance of a specific object type, and provides a "wrapper" around that instance. The board class uses the structure class
Object Storage, GenericObject, and GenericDictionary to provide a heterogeneous dictionary that can be saved, and restored from, a persistent medium such as a file or a relational database. The board can be used as a central repository for shared information used
in an existing workflow. The whiteboard can also be used to store parameters that will be supplied to a task invoked automatically for a programmer or alarm server. A blackboard is defined unambiguously by a number, which is represented in data type. The producing class (discussed earlier, with reference to RQS) has its origins in Smalltalk, where weak typing and late binding or link is used at runtime. However, C ++ has a different and opposite ideology. Thus, the filmmaker attempts to solve this dichotomy by simulating the runtime invocation of functions based on a representation of the RWC string of the function name. The director is a kind of template and a template instance specific to the director is requested for each type of class of these functions to be executed. The list of tag values is a class that encapsulates the concept of a string of pairs of tag values, and provides several functionalities for manipulating and extracting information from this string. The concept of a tag value list is useful when a function can take a variable and diverse number of parameters that can be more easily realized in the form of a string of pairs of tag values that may have special meaning within the function. Each server object in the reading server
Automated Meter 15 is a subclass of the distributed service structure App server classes. The server class model App models the concepts of RPC clients and servers as objects. These classes provide both the RPC-based interfaces and the queue-based interfaces. The server class App makes the different interface types (RPC or queue-based) very transparent to the developer. The App server provides the following generic behavior for all subclasses. The App server contains methods to support: trace interface, registration and error reporting systems, DCE registration and start (registration of space name and security record), vendor messages required by the Concern manager, initialization of any common object to starting from the start file (queue names served), it automatically starts the string to read and invokes methods on itself from queued messages, opens messages and uses the service name to map to a method within the object, and decodes the label value list to provide arguments. The automated meter reading server 15 may have named queues attached to it for asynchronous requests, exporting interface objects representing real RPCs that can be made to the server; where each interface object can be synchronous (based on RPC), asynchronous, or both. The server may also need to initialize and
connect to resource managers, described later. The server classes App use other classes of services from the structure of distributed services
104. As noted above, the distributed services structure 104 contains queue management classes
(RQS) which are classes that encapsulate the concepts of RQS in
® Encina 106 as C ++ objects to reduce the complexity and redundancy typically involved when using RQS. The RQS allows applications for queued transactional work that will be completed at a later time. The RQS approach provides several advantages, such as avoiding the overhead of a server fed into queue when a large number of requests are sent to it. Also, if a server is out of service, requests are still received and placed in its queue and will be processed when the server again works. Also, the RQS advantageously provides a transactional queuing service, so that if a request is aborted, it is placed back on the server queue and not lost. Each server can have one or more sets of queues. A queue set is a collection of one or more queues (that is, from 1 to n queues) that are given a priority of 1 through n. The class of queues feeds messages through a class to a configurable read receiver to eliminate queue bottlenecks and over-execute the number of readings that the server would be processing. To do
this function, the queues are also assigned that service in reverse order. The queue with priority 1 obtains a level of service n, the queue of priority 2 obtains a level of service n-l, and so on, strings are created to service the queues. Also included are the kinds of queues that are used by the servers to queue articles / actions according to the service priority / service level for asynchronous processing. In addition, the tail element class is an abstract base class that contains pure virtual functions gettingAction () and getlnase (). This class assumes that all queue elements contain an action and an interface name that the action will perform on it. To increase or decrease the output of a server, the number of strings is configurable on a per-server basis via a configuration file (for example, 172b in Figure 8). When a request arrives at a server in the form of a queue element, one of the strings attends the queue removes the item from the queue and starts the transaction. The string then obtains the interface and service that will be invoked from the queue element and the messages for that interface to invoke the function associated with the name of the service. If the service is invalid, an exception is placed and the string discards the tail element. If the service is valid, the director invokes the appropriate function. When the
function returns, the return status is optionally sent back to the service requester via a separate queue element where it is processed if necessary. Referring again to Figure 3, subsystems of applications and infrastructure 100 are provided, which include subsystems that lie at the top of the customer-adapted software products discussed above. The AMR subsystems of applications and infrastructure 100 both directly and indirectly use software products adapted to the client described above. RogueWave 114, is a library of previously compiled software class used to help in the development of common and routine tasks within a system. RogueWave 114 provides many useful services that protect the automated meter reading server software from the underlying operating system 118. RogueWave 114 is platform independent between different UNIX variants as well as Windows NT. Figure 3 also illustrates various external interface mechanisms that allow automated meter reading application services to interact with external application systems 50. As illustrated, an DCE application program interface 132 is provided which is based on the RPC DEC mechanism discussed above. The interfaces of individual RPC application programs
provided by the automated meter reading server 15 will be described later. Another interface available for external systems is the file-based interface 128. The file-based interface 128 is provided because the RPCs are not designed to efficiently handle exchanges in data volume, such as sending meter data to a billing system. . Most billing systems currently use a file-based protocol to receive billing information, and they have specific formats for the billing data file. Currently, there is no standard data format specified for use by billing systems. In view of the incompatibilities in the file formats, the automated meter reading server 15 uses a canonical mapper 140a that can convert from any file format to another file format. The canonical mapper 140a constructs a map that specifies the translation required to perform the conversion. The canonical mapper 140a advantageously allows the automated meter reading server 15 to quickly adapt to different formats for the data without writing the code and collecting the software. The final interface illustrated in Figure 3 is the database of the application program interface 124. The automated meter reading server 15 provides the ability to populate the output stage database
122 with data from the automated meter reading data store 120. The output stage database 122 scheme is made public to allow application developers of external systems to produce their own database access routines. The automated meter reading server 15 does not directly provide the interfaces of database application programs 124 shown in Figure 3 but the architecture of the system allows these application program interfaces to be developed while maintaining isolation between the business systems and the automated meter reading server 15. Future interfaces 126, such as CORBA, can be provided as needed. A provision may be made in the automated meter reading server 15 for these future interfaces 126. The data loading in the database of the automated meter reading server 15 is the largest volume task in the system. For this reason, the load imports volume data to the database very efficiently. To this end, the data warehouse of the automated meter reading server 120 is not directly accessed by external applications. If the external applications have direct SQL access to this database, then the read server applications
Automated meters could not ensure these applications would not perform inefficient queries that would block sections of the data and consume necessary processing power. In addition, if the applications are allowed direct access to the database then the encapsulation is lost and any changes made to the database structure need to be coordinated with the external applications that have direct use of the database. Instead, the architecture of the automated meter reading server 15 provides periodic data mining from the data warehouse 120 to another database (see output stage database 122 in Figure 3). The structure of the output stage database 122 may remain stable and isolated from the automated meter reading server applications 15. As changes occur in the data warehouse of the automated meter read server 120, only the application of data mining has to change. External applications can be developed using SQL or other commercially available reporting tools to access the contents of the output stage database 122. Referring now to Figure 4, the automated meter reading server 15 uses Independent subsystems (SS) to carry out business goals
great gears. Figure 4 extends the automated meter reading application and the infrastructure subsystem block 100 shown in Figure 3 as well as other systems. These subsystems host specialized services that can be distributed throughout the automated meter reading server 15. The subsystems are named to help locate the services within the distributed system, but the subsystems have no physical limits. Subsystems simply use named places (that is, named spaces) to conveniently group services that collaborate to achieve a business goal. The messages are not sent to the subsystems, but to the services (methods, functions, etc.) within the subsystems. Typically, the services provided by a subsystem are contained in executables (servers) or provided as class libraries that perform a specific set of services. There may be only one server within the subsystem (called the same as the subsystem), or there may be multiple servers in a subsystem that interacts to implement the service (s). The AMR subsystems (software architecture) are divided into two broad categories, shown as the infrastructure and application subsystems 100. The infrastructure subsystems provide the services and structure required to support the subsystems of
application. The infrastructure subsystems are developed as generic and reusable components. These subsystems have no knowledge of the AMR application domain. The application subsystems, on the other hand, have detailed and specific knowledge about the automated reading domain of meters. These subsystems implement the requirements for automated meter reading application. For example, the automated reading domain of meters deals with meters 60, tariffs, accounts, meter data, etc., and the application subsystems know how to operate on these entities, and they know their relationships. The application subsystems can be further subdivided into support services, and data management services. As shown in Figure 4, the automated meter reading software architecture is composed of the following subsystems. Infrastructure sub-systems include activity management 146, scheduler 138, alarm 134, concern administration 136, mapping 140, and trace / trace subsystems 142. Application subsystems include a GUI subsystem 92. As noted above, the Application subsystems may comprise support services and data management services. Support services are a group of subsystems that accept requests, and communicate to external systems to AMR. Support subsystems include the service interface
144 and a provider interface 148. Data management services store, retrieve, and format the relatively large amounts of data that the system will handle. The data management subsystems include a data access subsystem 150 and an export subsystem 152. Each automated meter reading subsystem is composed of one or more software servers. As noted above, the automated meter reading server 15 is modeled as a set of cooperative system services and encapsulated objects within the servers that implement these services. The capabilities of the system are seen as the combined capabilities of its services. As used herein, cooperating objects perform services. The interface of these objects is through their public methods. Many methods can interact to carry out a service, but only some are exposed as interfaces to the service. All the objects that cooperate to satisfy a service physically live in the process space of one or more servers (processes that are executed apart from the client processes in the same machine, local area network or wide area network). The portion of the client or end user in the system will almost never contain the real objects that provide services. These servers are implemented in the upper part of the software adapted to the
® DCE / Encina customer. As such, they are capable of either receiving remote procedure calls (to interfaces exposed through the IDL) or reading queue requests (Encina RQS). The services on the automated meter reading server 15 are triggered by both RPC calls and requests fed by queue, depending on the nature of the service. The services that access an object in the database and return some attribute or that immediately answer a question, are triggered synchronously via RPC. Services that perform long operations (such as mapping a list of values) are triggered asynchronously via a message queued through RQS. Some objects can be designed to behave both asynchronously and synchronously for different methods. Referring again to Figure 4, the various subsystems illustrated therein will now be described in detail beginning with the infrastructure subsystems. The activity management subsystem 146 hosts services that invoke and manage the Activity Plans. As much as possible, the business logic is abstracted from the level of service in the Activity Plans (which will be discussed later). Services are reduced to finite business objects that perform a task or service for the system, usually on behalf of an Activity Plan
major gear. As noted above, Activity Plans can be thought of as a list of tasks or operations that are performed to complete a business unit of work. The tasks themselves do not perform the work, but simply invoke a system service for their task and have information delivered and returned. Each operation can have defined overcoming nested failures, undoing actions, and final fulfilled operations. The Activity Plan is a decision tree of these operations together with contextual information carried for the flow and available for each operation. The Activity Plan also defines which operations depend on others and thus, which operations can be executed in parallel. The services within the activity dispatcher initiate (initiate) an Activity Plan, negotiate responses and events for Activity Plans, and monitor the current status of all Activity Plans in progress. The Activity Plans themselves are enrolled outside the coding environment and are easily modified to accommodate the automated meter reading server 15 for the business requirements of a particular client. In this way, business requirements can be easily changed without recoding the services and underlying objects. The decision process to guide execution is controlled by a direct graph of business logic encapsulated in each Activity Plan. The purpose of the Plan
Activity represents a state machine that addresses itself. The dispatcher simply provides the objects of the Activity Plan with an environment in which it is executed. The tasks have the following responsibilities. The first is the sequencing of tasks, which determines which tasks are to be executed in parallel versus in series. The second responsibility is the administration of the board, which maintains and manages access to the board for all tasks. The third is the task status management, which tracks what tasks are in progress. Another responsibility is a next operation that is a fixed graph rule setting to determine which task to do next based on the status of the Activity Plan. Activity Plans are also responsible for registering tasks, which record the results of the tasks as they are completed. The task is a discrete unit of work in an Activity Plan that is performed by a single service in the system. An Activity Plan task is responsible for precondition processing that predetermines the ability of the task to execute based on the availability of required revenue. The task also has an activity that performs responsibilities which are a unique identifier for the specific operation that is to be performed by an agent. The agent is a server capable of
perform the activity. The tasks are responsible for fault processors, which are a list of operations that must be performed in the case of failure based on return conditions from executing an activity. The activity management subsystem 146 acts as a workflow manager within the automated meter reading server 15. It is a machine that handles business events that contain a knowledge base of the business rule that are domain specific . Acts in concert with the transaction manager (TM) to coordinate high-level business events such as observing and acting on unit dependencies within the unit or controlling an event with a legacy system. An example of a controlled legacy event would be the case where the billing system requests that a route be read in three days. The application would request a workflow called, for example, a ReadRoute. The Workflow Administrator (WFM) uses a previously defined workflow dictionary to determine the prerequisites for the business flow and all the required operations that comprise the workflow. Each of the operations in the workflow are autonomous but operate either in series or in line with other operations. Each operation performs some atomic unit of
work (or other workflow) in the system and reports its success or fails again to the workflow manager. Each operation can have failure clauses that allow the recovery of error or cleaning. In summary, the business rules used by the workflow manager are preferably the primary mechanism for building functionality in the automated meter reading server 15. No small changes or changes to the general application set need to be made. Each of the systems within the automated meter reading server 15 responds to messages sent by operations. All intrasystem data is communicated via objects to facilitate state maintenance. Each operation is verified or stored as it falls asleep between changes of state in the database 120. Now the servers of the subsystem of administration of activities 146 will be described. In order that the activity plans sensibly control the actions of the system, the system is modeled and implemented as a cooperative set of services from intermediate to low level. The services are grouped and put in series to perform business operations. The grouping and control of the execution of the service (to carry out a specific high-level business task) is the work of the Activity Plan object.
The instances of the Activity Plan are named, for example, by the business unit of the work they carry out and contain an ordered list of tasks that interact with individual services of the system. Task instances are named by the service they invoke and know their prerequisites and possible alternative cases in the case of service failure. To support the execution of the business logic through the Activity Plans, a support structure is assembled to build, dispatch, register, monitor and route. This subsystem consists of a set of five servers that perform these tasks. They are illustrated in Figure 3 as the Activity Plan builder 146d, the dispatch panel 146a, the dispatcher brain 146b, the dispatcher storage manager 146e, and the Activity Plan monitor 146c. The servers will now be described. The dispatcher panel 146a, the dispatcher brain 146b and the blackboard object comprise the dispatcher of the Activity Plan. The builder of Activity Plan 146d is provided because Activity Plans are not useful objects immediately after installation. They are built and passivated for later use because Activity Plans are objects that manage a set of tasks to perform a business unit of work. In addition, the object of the Activity Plan itself is simply a
administrator and container of the tasks that causes the work to be done. An ordered collection of tasks is constructed and assigned to the Activity Plan before it becomes useful. Tasks use the data exchange object board, which is initialized before use. To accomplish this, a tool is used to build and manage a useful task dictionary, initialize board slots, and assemble Activity Plans. The blackboard object provides methods for creating, accessing, updating and erasing blackboards and content of slots within the boards. All the boards are stored as a string object (blob) encoded by a unique identifier. As used in conjunction with the Activity Plans, the unique identifier conceives the identification of the Activity Plan with its associated Activity Plan. When used for Activity Plans, the blackboard object has predefined slots required to communicate information between the different tasks of the Activity Plan. Each task in the Activity Plan retrieves entries from predetermined board slots, and places outputs in other predetermined slots. The board is stored in another persistent store labeled Activity Plan. An Activity Plan object is constructed with the same name as the blackboard, describing the business unit of work to be performed. The user then uses the constructor
to populate the Activity Plan named with the required tasks. The Activity Plan builder 146d is a development tool comprising a front end graphic user interface (GUI), controller, and domain object capable of being persistently stored and used by the dispatcher. The constructor allows easy construction of tasks and store them in a dictionary for easy insertion in Activity Plans. In the same way, the Activity Plans must be constructed through the constructor 146d by selecting tasks from the dictionary, validating the static prerequisites that the static prerequisites are met, and inserting them into the list of tasks contained in the Activity Plan. All Activity Plans are stored in a dictionary used by the dispatcher to be copied in execution upon request. Constructor 146d is used in the development cycle to initiate task objects that will be used in one or more Activity Plans. The constructor stores tasks in a persistent dictionary by the name of the task. The constructor 146d also prepares a chalkboard object for the Activity Plan. The preparation of the board is a matter of predefining slot names and initialization values. The constructor 146d is also an editor. It is able to easily allow the user to refer to stored tasks, to the board,
o Activity Plan and change its contents. Referring to Figure 29, the main screen of the Activity Plan builder 146d is illustrated. As illustrated, the input screen in Figure 29 provides the user the ability to view, edit and delete existing workflows, tasks and operations as well as create new ones. The attributes for each workflow, tasks, and operation are listed next to each article. As can be seen from the workflows illustrated in the top panel, the workflow allocates contained tasks (for example, ModifyMeditorSave Workflow contains the ModifyMeasure task). Figure 30 is a graphic representation of the various paths available through that particular workflow. This screen is accessible from the main screen shown in Figure 29. In this example, a workflow to modify meter is illustrated with three main paths of execution. The first one is a normal path (STS_NORMAL) that results in a simple update in the database 120. The second is to move to non-communicative (STS_MOVER_A_NO COMMUNICATIVE), which lists the required tasks that must be completed in order to execute with Successful work flow. The third is to move to communicative (STS_MOVER_A_COMMUNICATIVE), which lists the required tasks that must be completed in order to execute with
Successful work flow. Crossing several paths (decisions) is based on returned states at each individual decision point. If each task within a workflow is completed successfully, the final branch returns to the add update meter task aliases at the end of the first decision tree. The first 31 shows how a particular task of the main screen of Figure 29 can be modified to execute, undo, or end an operation. In an undo, the operation is reverted to a previous task and to a previous state in order to resolve fault conditions. Finish an operation performs cleaning operations for any operation that was initiated in a task by, for example, deleting files, and so on. Figure 32 illustrates how an operation can be modified. The following fields are used in the modification: Name - Name of the operation; queue name - queue assigned to administrator (server) responsible for the operation; interface name - DCE interface that contains the method for the operation; service name - method used for the operation; return queue name - queue name for return results of the operation;
name of return interface - DCE interface for the return of the operation; and return service name - method used for the return operation. Figure 33 illustrates the names of the slots within the board object that contain the specific value types used to execute the operations. The dispatcher panel (DPanel) 146a urges Activity Plans by name and initiates processing. This server handles requests to initiate Activity Plans and field requests for current status and obtain results from the completed Activity Plans. The DPanel 146a has an application program interface used by requesters to start Activity Plans and receive results of completed Activity Plans. The DPpanel 146a can also be called to investigate the status of the Activity Plan. All calls to DPanel 146a are synchronous. Upon request, DPanel 146a calls for an Activity Plan named from the storage area of Activity Plans, together with its associated board, both with a unique identifier but not executing it. Activity Plans are urged and passivated using the dispatcher storage manager 146a, with password for the Activity Plan identifier. After the passivation of a new instance in the Active Activity Plan area, the DPanel 146a sends a message through
RQS to DCerebro 146b (described below) using the Activity Plan identifier. The DPanel 146a can then process requests for status or results. The Activity Plans themselves are instantiated objects, and outside of a process space (except in CORBA environments) they are unable to receive messages themselves. Therefore, they are invoked and administered by a process. In the case of a DCE 112 environment, an RPC / queue server receives and dispatches all communication between other system objects and the Activity Plan (s). This server is called dispatcher brain (DCerebro) 146b that executes Activity Plans and handles responses from other servers sent to activate the Activity Plans. DCerebro 146b is mainly messaged through the RQS server. The only function of DCerebro 146b is to execute Activity Plans and route responses from other servers to an appropriate Activity Plan where tasks within an Activity Plan (executed in the process space of DCerebro 146b) send queued messages to other servers. Individual plans can receive priority in activation based on dynamically set priorities. During processing, Activity Plans are passivated when dependencies prohibit the next task from being executed, and can be reactivated by DCerebro 146b when the dependent task (s) are completed, after receiving an event notification (administrator of compliance 136 ) , Y
when the Activity Plans mature (that is, when the time ends). DCerebro 146b is a seller of special events called status changes of the Activity Plan. The compliance administrator 136 has a corresponding special interface for requestors to request status change information for the identity of the Activity Plan, be it a specific instance of an Activity Plan, or all the Activity Plans with a given name. Special events DCerebro 146b can sell are the start of Activity Plan, abortion and termination. DCerebro 146b is responsible for registering the operations and parameters of an Activity Plan as well as debugging. As each task begins and ends, a registry entry is written. The log entry contains the status of the Activity Plan and the contents of the board (either entirely or selectively) in each step. The dispatcher storage manager (ADAd Storage) 146e is used to control access (add, update, read, etc.) to the persistent Activity Plans. Adm storage 146c is used concurrently by the dispatcher DC 146b and the monitor to avoid collisions while accessing Activity Plans. The Drerebro 146b server uses the storage manager to maintain the status of activity
persistently through system interruptions and dispatcher failures. Many Activity Plans can be activated in the system at the same time, and can operate for hours or days. It is important to be able to monitor the status or status of any and all Activity Plans. The Activity Plan (APM) monitor 146c shows a user the status of any Activity Plan by name, or by selection. The monitor 146c does not examine the record but only knows the current state of the Activity Plan as represented in the database. It monitors the status of active Activity Plans and allows the examination of completed and aborted Activity Plans based on the Activity Plans File. Referring again to Figure 4, a Programmer subsystem 138 manages the construction and execution of programs for the Automated Meter Read Server 15. The programs are used to control the execution based on the working time within the automated Read Server. meters The programs can be recurrent, specified, activated at the start time, or activated in activated time. The Programming subsystem 138 provides a single database access point for creating, retrieving, and updating programs. In addition, the Programming Subsystem 138 executes programmed activities in the appropriate time, and optimizes the execution of activities
programmed to avoid conflicts, lost deadlines, and redundant work. The Programming subsystem 138 is provided to accommodate changing business requirements. It also maintains the portability of core objects so that the components can be shared with the Programming Subsystem 138 in the Vendor System 148. The Programs within the Automated Meter Reading Server 15 do not perform the work; instead, the programs control the activation of the work, as noted above, the work within the automated meter reading server 15 is typically controlled by an Activity Plan that is initiated by the Programming Subsystem 138. The programs in the automated reading domain of meters are used to control the delivery of data from the providers to the automated meter reading server 15 based on business activities such as billing export or other data export from the automated meter reading server 15. The Programs also control other tasks such as loading the Output Stages Database 122 (Figure 3), and generating reports. The model object for the programs can have, for example, a class of ProgramTarea at the top. The ProgramTarea class handles any external program in the business world. A subclass for programs (for example,
meters 60, accounts, etc.). A program has several aspects, that is, what to do, when to do it, what objects to perform the action, and where the action is taking place. The TaskTape object can contain two component objects, for example ProgramEvent that represents what to do, and TimeTime that represents when to do it. The set of objects in which to perform operations can be represented by an association with a GroupMeter object. In the automated meter reading server 15, a program may exist, for example, because the data is to be exported to a service, or because the data will be made available in the automated reading database of meters 120. Programmer 138 may also handle complex timed execution of other operations, or may simply indicate the expected arrival of data from a provider. In the latter case, there is no action expected for the AMR. It is noted that the automated meter reading server 15 maintains reception programs because the automated meter reading server 15 maintains what has been given to the providers, and because these programs represent a restriction in the start times of related AMR actions. Referring again to Figure 4, the program subsystem 138 has two main servers, the program manager 138b and the programmer 138a. He
programmer 138a and program manager 138b primarily interact with each other, database 120, activity management system 146, and alarm service 134. Program management server 138b handles the creation, updating, and retrieval of programs for and from the database. The program manager 138b preferably uses representatives of the data access object (DAO) (to be described later) to interact with the program implementation server of the data access object subsystem 102 to perform all of the data access object operations. the database . Activity Plans and other subsystems that create and use programs will interact with the program manager 138b. Additional server processes that implement distributed objects of the programs may supplement the program manager 138b. The other aspect of the programming system is the scheduler server 138a, which is responsible for initiating the execution of scheduled activities. The 138a programmer retrieves programs through the program manager 138b and organizes execution plans. At appropriate times, the 138a programmer initiates Activity Plans to perform the scheduled operations. The greatest incoming stimuli to the 138a programmer are news from the program manager 138b that the programs have changed, and alarm calls
of the alarm subsystem 134. All outgoing stimuli are Activity Plans. Programmer 138a also stores some private persistent objects in database 120. Programmer 138a server uses the programs provided by program manager 138b to build and execute Activity Plans that drive data collection and export actions. Most commonly used Activity Plans rebuild to schedule the generation of billing reports and other intensive resource tasks that must be completed within a certain time interval. Programmer 138a obtains the average time to process program items, and then determines a number of scheduled tasks for a given work plan. Programmer 138a appropriately adjusts estimates to schedule a task that begins with a start time and start event so that the task can be completed within the expiration interval. A restriction of the programmer 138a is the need to adjust for real-world influences that can not be accurately predicted. To schedule a job, the 138a programmer needs to determine how long it will take. However, the execution time can only be estimated at the most; will change from day to day and will probably change as the number of associated meters changes. 60 The execution time will also vary based on how much
The automated meter reading server 15 is heavily loaded. If a new program is added that runs at the same time as an existing program, the times for charging the load need to be adjusted. Important automated meter reading programs are restricted by matching programs with the provider, for example, the automated meter reading server 15 can not start exporting data until the data has reached AMR 10. Therefore, the programmer 138a allocates some space when creating vendor programs, and new programs will have to defer to the former to choose execution times. The programmer 138a contains several parameters of heuristic tuning to adjust the estimated execution times. The parameters are set and changed by the configuration file interface by the automated meter reading server 15. The classes of cores that are implemented in the 138a programmer are designed to be generic, and independent of the application domain and the platform of implementation. Programmer 138a can use several important classes to build and execute Activity Plans. For example, you can use the Activity Plan that translates the time specification algorithms of the programs, describing multiple executions, in specific tasks with
specific start times. In order to maintain the portable programming code, three classes are provided that isolate system dependencies, the program constructor, the program view, and the work plan agent. The process works as follows. The programmer class implements an Encina 106 interface. The inferno then makes method calls to the program constructor class, which must be independent of the platform. The program builder uses a program view object to retrieve and filter the programs. The database access dependencies are preferably handled by the program list and remain transparent to the program constructor. As soon as the Activity Plan is built, the program builder gives the Activity Plan to an Activity Plan agent for execution. The agent handles persistent storage for the plan, and details of fixing and responding to alarms and initiates actions. Figure 5 illustrates the relationship of a delivery schedule 162/32 to the scheduler subsystem 138. The delivery schedule 162/32 notifies the provider 30 when to deliver data to the automated meter reading server 15 in a recurring manner. The 162/32 delivery program belongs to the automated meter reading server 15 and is the consolidated billing program and available programs provided by the service. The billing program 154
determines the data delivery timer from the automated meter reading server 15 to the billing service. The availability program 156 notifies the automated meter reading server 15 when to make the read (or visible) data available to the service. Both billing 154 and availability 156 programs are created by the service; however, the automated meter reading server 15 will keep the programs in its database. The automated meter reading server 15 derives the delivery schedule 162/32 by taking the most restrictive time account from billing 154 and availability program 156. For example, if the billing program 154 is once a month (the last day of the month), and the availability program 156 is daily (for enhanced customer service), the automated meter reading server 15 will choose a daily delivery schedule 162/32 in order to satisfy the billing requirements and availability. A collection program 34 determines when to collect data and what type of data to collect. The automated meter reading server 15 provides the provider with information about the components of the collection 164, i.e., the type of collection and the load profile interval. Collection component 164 is based on rate 158 and other data requirements 160 (eg,
energy quality) provided by the service. The automated meter reading server 15 does not inform the provider about the time account of the data collection since it is assumed that the provider has a superior understanding of the communications network and other restrictions. It is also noted that the delivery program 162/32 of the automated meter reading server 15 should be used to derive the collection program 34. The programs can be specialized in two types: delivery programs and reception programs. The delivery programs specify when the automated meter reading server 15 will deliver the data from the grouped meters 60 to the external application systems. Billing programs and data export programs are examples of delivery programs. The reception programs specify when the data will be received from the communication servers 30 (servers). The reception programs are derived through the subsystem of automated meter read programming from the delivery programs. The automated meter reading server 15 preferably uses several data structures to transfer data and programs / collection information between the automated meter reading server 15 and the communication servers 30. The structures encapsulate the data
required by the application program interface provider to allow maximum flexibility and future expansion. Referring again to Figure 4, the alarm subsystem 134. is shown. The alarm subsystem 134 receives requests for timed messages. The alarm subsystem 134 keeps on the list of alarm clocks for any applicant in the system. The alarm clock is stored with a message to send back to the requestor when a predetermined time expires. The Activity Plans and the program subsystem 138 most frequently request the services of the alarm subsystem 134. The alarm subsystem 134 is composed of a single server, the alarm server 134a. The alarm server 134a is designed as an Enema ® server, and will use the distributed services structure 104, described above, for its implementation. This service is preferably concurrent (muit-strung) in order to support multiple clients concurrently to set and process alarms. The alarm server 134a can provide both synchronous and asynchronous interfaces to its functions. The requests will be per transaction, because if an operation fails for any reason, it will have no effect. All active alarms managed by this service will be stored persistently through their cycles of
life, which will allow the alarm server 134a to restore its status in the event that it is interrupted and restarted when there is an active alarm. When an alarm occurs, a call back is made to the subscriber via the asynchronous interface provided by, for example, the useful queue library. If the alarm was set with some information, this will be passed with the SOQ queue element back to the subscriber. Optionally, the alarm server 134a will support a callback mechanism using synchronous RPC to subscribers that do not read from a queue. Referring again to Figure 4, the automated meter reading server 15 is also provided with a dependency management subsystem 136. The occupation management facility 136 is a set of services that provides distributed event management for other entities within the system. The entities can be either a "seller" and / or "solicitor". A "seller" is something that can provide notification of an "event", or more generically, something that can "sell" a particular item. The term "event" is used within the described description meaning that the occurrence of one or more specific and defined circumstances can be detected and described tangibly. A "solicitor" is something that has an interest or concern in an article that
It can be provided by a vendor, and usually you want to have the item or in case of an event, be aware of its occurrence. It is noted that a particular customer of the care manager service 136 can be either a vendor or a solicitor, much like a server can also be a customer in the RPC world. The design attempts to advantageously solve the problem of how to allow requesters to express a concern for particular events and vendors and send these events to a concerned solicitor in a system diagram of interaction services. The above implies a processor / server / device that tracks which vendors can provide specific events and which solicitors are interested in these events. The referral administrator 136a has a centralized service that coordinates the aforementioned interaction. This relieves the burden of vendors to manage interactions with their requesters. The vendor will communicate all event information to a central service. The solicitors do not need to know which vendor (s) can provide specific events, but only to know the types of events that can be provided. From the solicitor's perspective, simply notify this central service that you are interested in a particular event, and the compliance manager sends any occurrence of
this event back to the requestor. From the seller's point of view, he simply notifies the central service about any event he can sell, and sends them over the central service when they are presented. To be efficient, the central service can notify a vendor when they need to start sending events, since there is no need to send a specific event if there are no solicitors interested in the event. The concern management subsystem 136 is comprised of a server, the case manager 136a. The compliance manager 136a is designed as an Encina server, and uses a distributed services structure 104 as the basis for its implementation. This service is preferably concurrent (uiti-stringing) in order to support multiple clients concurrently to manage interests and events. The compliance manager 136a will provide both synchronous and asynchronous interface to its functions. The requests will be per transaction, because if an operation fails for any reason, it will have no effect. All active concerns managed by these services will be persistently stored throughout lifecycles, which will allow the 136a care administrator to restore their status if it is interrupted and restored when there are active concerns.
The referral administrator 136a is responsible for accepting requests from requesters and retaining a mapping of the concern. This map contains enough information to make a call back to the solicitor some time later with notification of the event if it is presented. The referral administrator 136a provides a server interface to record which events may occur and callback information to enable and disable the sending of these events. At the start, all salespeople record the events they can produce. Sellers register each type of event separately. The vendor will provide the type of event and enable or disable return calls. Event reporting is considered disabled for a salesperson until the 136a care manager receives an interest in a particular event. The referral administrator 136a makes the call back enabled to all the vendors who have registered that can provide this particular type of event. Whenever this event is presented within the context of a qualified vendor, the vendor sends the event to the compliance administrator 136a to be handled. On the applicant's side, the applicants register interests for each event separately. The request consists of the name of the event and a call back from the
solicitor to notify when that event occurs. When a vendor sends an event that matches a type for which the solicitor is interested, the solicitor is notified via the return call of the occurrence of the event. The solicitors explicitly withdraw interest from events. The return calls can be provided through the queue of a solicitor or vendor, or through non-queue servers (eg DCE only / not Encina), through a synchronous return call interface. To help integrate other servers in the system with the compliance manager 136a, the distributed services structure 104 is used which allows the developer to model the server as a vendor and / or solicitor and use the functions of the respective member just like other functions of the server member. Referring again to Figure 4, a mapping subsystem 140 provides services that allow easy adaptation to the client of the file formats for exporting data from, and importing data from, the automated meter reading server 15. The mapping subsystem it comprises the canonical mapper which is included to increase the client's adaptation of the automated reading server of meters 15. The purpose of the canonical mapper 140a is to produce maps that can be used to map information to
through subdomains. The mapper assumes that there are at least two mapped subdomains in which to transfer information through them. Both subdomains are mapped under the same root domain. The user invokes the mapping tool instead of the map builder to create a service capable of transforming information from one selected subdomain to the other. The user interface is simple. Display all maps in two lists and allow the user to select a map from each list. A list represents the subdomain from which data will be mapped. The other list represents the subdomain to which data will be mapped. The canonical mapper 140a is preferably implemented in Smalltalk and therefore requires integration of the DCE / Encina® environment of the automated meter reading server 15. To carry out this integration, a mapping interface server 170 provides the service requests DCE / Encina® from the automated meter reading subsystems, as shown in Figure 6. The mapping interface server 170 will connect to the canonical mapping server using a socket connection. The mapping interface server 170 will provide a service that allows an automated meter reading subsystem to specify an input file 166, an input map, an output file 168, and an output map. The mapping interface server 170 will send this request to the mapper
canon 140a through the socket interface shown in Figure 6. The input and output maps are bypass trees. Using these maps, the canonical mapper 140a running in a headless mode, will build a syntax scanner / analyzer for the FROM subdomain. The canonical mapper 140a will then traverse the input map, analyze the data of the input file in a canonical list. After the crossing of the entry map is completed, there will be a canonical list, populated with elements of the input subdomain. Next, the canonical mapper 140a will map from the canonical list to the output subdomain by traversing the output map and reinterpreting the corresponding element from the canonical list to conform the new data format. This action creates the specific output file. The canonical mapper 140a can be configured to accommodate different file formats as follows. As noted, the purpose of the canonical mapper 140a is to standardize data formats so that information that is spread across different business units can be easily converted from one format to another. In the detailed description of the canonical mapper 140a, the following terms are used to describe the characteristics of the canonical mapper 140a. A "canon" is a tree that relates all the data attributes within a
information domain (for example, materials invoice). "Canonical elements" are specific parts of a canon. A "map" is a data structure that describes the format of a particular file in terms of the canon. A "domain" is a collection of semantically consistent data (for example, the same data format). "Scanning" is the process of identifying elements of the input text. "Analyze the syntax" is to encode input text in terms of its relation to the output text. A "record" is an article added to the value in a file to describe the format of the text. An "action" is a tool to modify the appearance of a particular file, that is, an "action" performs operations on the text (for example, it adds transport returns, adds punctuation marks, etc.). The canonical mapper 140a preferably consists of services to create canons, construct maps, and translate files. A royalty service can be included to create a royalty. The canon is an abstract template or master file that describes a general structure for an information domain. In other words, the canon is a template that describes a general format for an information domain that is to be converted. A canon can be analogous with a tree or a sketch that is used as a template for the conversion of information. The canon begins with a root from which other subordinate parts grow. The root of the tree is the
name of the canon, in this way the root is the father of all other parts of the tree. Those parts that are nested or indented within the root are the children. The canon is described from top to bottom by the relationships of each part with the others, similar to a sketch. Each parent contains specific information (ie children) and a child can contain other children. Each child and parent is a node in the tree. A node that does not contain any children is a terminal node or leaf node. Each article in the canon is a canonical element.
For the canon to function correctly, each element can be defined so that when data is fed through the canon, the data can be interpreted accurately. The entire domain is described in terms of a canonical element that is an abstraction, and then each division or part of that element is subsequently defined in terms of less abstract elements until the entire document is defined. Each abstract element is finally resolved into a concrete element. For example, as shown in Figure 27, if the user is mapping a domain that is a material invoice document (BOM), select the domain sample and select the canonical element "BOM". Like this point, the user has abstractly represented the entire entry as a "BOM". So. The user continues to identify more detailed abstractions in the entry. For example, himuser selects the domain entry that comprises all the assemblies and selects canon assemblies. Within that selection, it also subselects a single current that describes a set and maps it into the canonical element "assemble". The mapping continues in this way until all the discrete elements of the entry have been mapped in the canon. Relations exist when the domain contains data that is dependent on other data in the domain. For example, a domain entry describing a part, wherein a part has a plurality of attributes. The word "has" infers a relation, that is, the part may include a part identifier, material identifier and a parent identifier. The domain can be mapped to the canon with the following relationships: + Parties (Group) + Party (Group, is repeating) + Parteldentity (Group) ParteldLabel (Id) ParteldResult (Result) + Matterlessness (Group, is Optional) MaterialID (Id) MaterialResult (Result) + Padreldentity (Group) PadrelTag (Id) ParentResult (Result)
As exemplified above, the part can be described as a first part of a canonical element. This is an abstract element denoted by its type (ie group). The next nested element is part, which indicates that Parties have a Party. Nesting indicates a relationship. Part has three relationships, Parteldentity, Matter Identity, and Padrel Identity. The user controls how these relationships are formed by selecting a previously mapped element to add a new relation. The canonical elements can also be assigned attributes that define certain qualities about those elements. For example, attributes may include types of elements (for example, group and result elements) and modifiers. Group elements are elements that contain children (for example, "Parteld" contains "ParteldValor") and there are elements that contain a variable piece of information that identifies a specific value (for example, "ParldValor" contains a particular value). A graphic view of the canonical elements can be derived, as shown in Figure 28 for the "costs" canon. A map service is included to create a map to translate data from one format into another. Since there may be many different file formats and applications within a particular domain, it is desirable that the software be sufficiently flexible to allow users to create
maps adapted to the client for their particular applications and file formats. These maps are based on the canon for which data conversion is needed. The maps specifically describe formats for the conversion of information between two applications, that is, a map is a way of describing the output destined in terms of the canonical elements. The map does not perform real conversion, but acts as a relationship between the canon, the input file and the application used to create the input file. A map is essentially a tree that represents a formula for converting a file. Whenever there is a need for data conversion between different applications and there are no existing maps for these applications, a map should be created that describes how the converted information should look. In other words, for every two tools that need to communicate with each other, there must be a map for each tool. As soon as the maps are created, they can be used repeatedly to convert information between the two applications. The construction of a map involves selecting each component of the input file and defining its function in terms of the canon that is being used. Attributes about certain canonical elements are defined during the process of building a map. For example, group elements can have modifiers defined for them. A modifier is a conditional statement that also defines
its function. Modifiers can indicate that a group element is not required, indicate that the group element appears more than once, indicate that the group contains a series of results that are grouped within the element, or indicate that the element is required. In addition to modifiers, the identifier can be included for constant information of a file. The identifiers can be used to identify a result element for a particular piece of information. An example identifier can be an ordered number for a material invoice. The tabs and actions are defined in the map service. The tabs specify the format of the results (that is, values) on the map. Tabs are defined because they define specific values that change depending on the input text. The actions structure the appearance of certain parts of the file. For example, a transport return action instructs the mapper to insert a transport return at a particular point in a file. You can perform two types of actions, canon actions and exit actions. The canon actions are performed in the input text as it is converted to the canonical form (step 202) or when some actions are necessary before the output map has acted on the file (step 204). Once the information has traveled through the exit map, the exit actions are activated. These actions are carried out
because the file has been changed and may need to be reinterpreted before it can be displayed correctly. An interactive translator service is provided to test the actual translation of a file to be mapped for the conversion process. The interactive translator bases the conversion on the canon, the input map that was created to describe the conversion of the input text, the output map that is used to describe the output text, and the input text that is being converted. The interactive translator then produces an output text file based on the information provided. Once a successful translation has been made in the interactive translator, then the translation through the domains is done in a headless translator. By selecting the appropriate input map, the output map, and the input text, the headless translator performs the conversion to create the translated text file. In this way, the mapping process can be divided into four main steps: create the canon (royalty service), create the maps for the canon (map service), test the file conversion (interactive translator), and map the information from the input map to the output map (translator without a head) to create the converted file. Referring now to Figure 7, the process of converting a file between two will be described.
applications (that is, from one domain to another). Using the map service, the input text file 200 is selected. In order for the mapping to be successful, the input text 200 is translated to the canonical form according to an input map 202. The particular canonical form of the input text depends on the input map 202 that is being used. The text must be transformed into a canonical form in step 202 so that the text can be sent to the output map 204 in a format it can accept. As soon as the text file has been converted to its canonical form, it is interpreted by the interactive translator according to output map 204 which was specifically designed to convert files between two applications to generate an output text file 206. The file The output text 206 is analyzed grammatically and translated by the headless translator into a text file 208 that can be printed, saved or placed in a word processing document. Referring again to Figure 4 and Figure 8, a record / trace subsystem 142 is provided which is a group of class libraries available to all servers through the App server class. The register / trace subsystem 143 provides all servers with a common mechanism to record and trace. The record and the trace are initialized from a system configuration file 174 that activates the record and specifies the destination
of the default log file 176. These fixations can be modified during runtime using a management service (ASADMIN 180) provided with the system. The ASADMIN 180 service is a program that allows the system level to control the servers running the automated meter reading server 15. The ASADMIN 180 is able to start and stop the servers. In addition, ASADMIN 180 can modify and consult system configuration variables. The configuration options (asadmin config) can provide options to reload the particular configuration file of the server 172b, returning the file name of the configuration used by the server, setting a variable on the server, returning the configuration information by variable, returning the configuration information by group, and recovering all possible fixes of the record from the server. Several inscriptions can be used per configuration. A first registration (rearar) can be written to start or finish all the servers. The enrollment preferably attempts to start all servers for the purpose of dependency by the automated meter reading server 15. A second registration (configServer) can be used to configure an individual Encina® server 106. However, the Encina® cell,
You must configure properly before this enrollment is executed. After configuring the Encina® 106 cell, the configServer registration can validate the different parameters, configure the server in Encina, set the ACL interface, start the server, modify server directory permissions so that they are more open, and set the queue ACL. A third enrollment (amrsetup :) can be used to configure or deconfigure all the automated meter reading servers. Use the configServer registration to configure all the servers and configure a location of the config file as reference, additional environment variables required, lists of interfaces exported by the server, different switches (-noasync-nobase dedatos-cuerdaunica), the name Encina®, and the name of the executable. It is noted that when the automated meter reading server 15 event is implemented and distributed on Sun platforms, the Sun parcel service is used. This is the same service used to distribute the Sun software. Users of the automated meter reading server 15 can retrieve records 176 of the registration subsystem 142. The files 176 can be used for external monitoring purposes and can support certain standard types of queries. An example of a typical registration requirement is to record the activation of each call invoked from the program interface application system
of application with, for example, the following information: application program interface invoked, User, Time and Parameters supplied. Registry 176 is internationalized, since users of the system can see its contents. The messages contain, for example, the following levels: INFO, WARNING, ERROR, and FATAL. Users can use trace 142 to "trace" the execution of the system to solve problems. When the trace component is activated, it will place messages in a specific trace file 178. The trace messages have trace categories that can be controlled by adjusting the trace masks of the servers in the system. Typical trace categories are defined by performance, monitoring, function, exception, debugging, and categories defined for the user. The trace is initialized from the system configuration file 174. The default configuration for a delivered system is to have the trace disabled. The trace is only required to track problems that occur in the execution system and can be activated at run time on the entire system or on any of the individual servers within the system using the ASADMIN 180 service. The ability to plot masks specific for execution servers provides a mechanism to adjust (increase or decrease) the amount of information
traced by the server. The trace could be used where there is a problem with the provider manager 148a and a user needs to see the trace messages for functions, exception and debugging to understand and isolate the problem. At run-time, the ASADMIN service 180 can be used to activate the trace on the Vendor Manager server 148a, with a trace mask allowing these categories (function, exception, debugging), and a specific trace file for the departure. Seeing the trace messages that come out of the Vendor Manager 148a when a problem occurs, the developer has much more idea of how the system is reacting. Each of the subsystems described above comprises the infrastructure subsystems of the automated meter reading server 15. The application subsystems will now be described, also with reference to Figure 4. The automated reading server of graphical user interface meters 15 ( GUI) 92 provides users with access to system functionality. The GUI 92 provides user interface that is self-explanatory and easy to use. For example, GUI 92 uses mouse and keyboard input devices and as such does not mesh with data input volumes. For massive data entry, automated meter reading application systems
they automate massive data entry through the supplied DCE 132 and the file-based interfaces 128. The GUI 92 is intended for quick access to functionality for smaller data entry tasks. The AMR GUI 92 is preferably executed in
Windows NT® 4.0 or UNIX workstations and is preferably implemented in a windows environment. The GUI 92 provides a user friendly and intuitive environment to access various automated meter reading activities. The GUI 92 allows the user to manually invoke all interfaces of the online business system, allows the user to search for specific information about meter / account / tariff / event, provides access to the monitor of the activity management system 146c, and provides interphase to programs. The GUI 92 is preferably developed in Java® to provide platform independence and the ability to remotely execute as a standard Internet search engine applet. The GUI 92 uses the application program interface of the standard application system provided by the service interface subsystem 144 to initiate requests. In order to connect a Java® client to the automated meter reading server 15 through
DCE had to overcome several technical challenges due to the relatively immature state of Java®. The next section
explains the GUI interface architecture required to carry out this unique connection. As shown in Figures 4 and 9 below, there are five important "pieces" involved in connecting the Java® GUI client with the automated meter reading server 15. These are: a 92A GUI client, a weight client port light® (Encina® DE-Light DCE 92b, a client gateway server (ServiceConfiguration) 92c, client notification server 92d, and an automated meter reading server 15 (service interface) 144a.The GUI 92a client it is preferably implemented in Java® and performs all communications using the DE-Light gate 92b.The client 92a provides a "thin" client that is capable of running on a wide variety of platforms.The GUI 92 submits the end-user requests to the automated meter reading server 15 and is responsible for interpreting and displaying any data returned from the automated meter reading server 15. The GUI 92 is capable of performing a variety of activities related to Adas with the meter station, such as adding a new meter, installing a meter, uninstalling a meter, finishing a meter, modifying a meter, estimating a meter reading, manually entering a meter reading, reading a meter, adding a meter to an account, remove a meter from an account, add a fee or meter, remove a fee from a
meter, add a meter to a data collection group, remove a meter from a data collection group, and define communication parameters for a meter. To perform each of the following activities, the user can click on icons or press a combination of keys that will be presented with a data entry screen. The data entry screen includes a list of the required and optional fields in which the information can be entered using the keyboard and / or mouse. The DELight 92b gate, available from Transare® Corporation, is provided to allow the Java® GUI 92a client to make RPC calls on Encina® 106 servers. It is used as a software adapted to the communications client to connect the Java® 92a client to the server of configuration of Encina® services. The DE-Light gate 92b allows the Java® client 92a to make a secure connection to the automated meter reading server 15 using the DCE security service. The service configuration server 92c is provided to work around limitations in DE-Light
92b. In particular, it acts as a custom translator between the Java® 92c client and the automated meter reading server 15. It mainly performs data conversion
(such as serialization) and does not contain any meaningful application logic. All RPC calls from GUI 92 are
direct to the service configuration server 92c. This server 92c will provide the Java® client 92a with a mechanism for collecting asynchronous replies for the service interface 144a via a notification server 92d. Notification server 92d acts as a queue that allows clients that can not handle entering RPC calls to process asynchronous notifications. The 92d server assigns a unique customer identification to each client. Customers then label their requests to the automated meter reading server 15 with their customer identification. The automated meter reading server 15 calls the notification server 92d when the asynchronous requests are complete and stores any information provided, including the requesting customer identification, in a delivery queue. Clients execute a simple cycle, extracting available notifications from the memory and processing each one at a time. If a client tries to extract a notification from the memory when none is available, the call will be blocked until a new notification arrives (or there is an elapsed time), thus avoiding busy accumulation. Notification server 92d is preferably written using direct DCE (without Encina®) and does not use the automated reading structure of meters. In accordance with one aspect of the present invention, the automated read server of
Meters 15 performs all the actual processing. Therefore, it accepts client requests and returns data back to the client (either synchronously or asynchronously) via the 92d notifications server. When the GUI client 92a receives a notification that an Activity Plan is complete, the GUI client 92a receives data based again on a waiting call, or the client 92a may call the service interface 144a, as noted above. The call to the service interface 144a is preferably an RPC call, however, it can be done by having direct access to the board. In addition, the GUI 92 is designed to handle a situation where the 92nd client terminates. For example, if client 92a removes the central part, then server 15 will be at the end of time. If the client 92a is disconnected peacefully, then the notification server 94d will be able to call an abortion. On the other hand, if one of the servers in the automated meter reading server 15 ends, then the client 92a will attempt to reconnect a predetermined number of times or a predetermined period of time (eg, ten times or five minutes). If the server reconnects, then the 92a client will reconnect and its pending requests, if any, can be reissued. If the server fails to connect, then client 92a will be unable to reconnect and will be notified that the application
which is calling from the server can be closed. Referring again to Figure 4, the automated meter reading server 15 includes support services that are a group of subsystems that accept requests, and communicate with the external systems 90 to the automated meter reading server 15. The subsystem Service interface 144 is the entry point for the application systems that request the automated meter reading server 15. All client requests come through this subsystem. All external business services that are required of the automated meter reading server 15 that is performed are represented by an application program interface service in this interface. The services within the service interface 144a have some common characteristics (using a common set of services within this subsystem). When an application program interface service is invoked, then accompanying arguments or parameters are validated, and translated into a form used within the automated meter reading server 15. The service interface subsystem 144 is composed of a single server , the service interface server 144a. This server is an RPC server that provides DCE interface only for external application systems 50. This server controls access to services
within the system by means of security mechanisms built into the message layer and translates owner data from the service client into a format useful for the automated meter reading server 15. The service interface server 144a does not directly perform the work required The services provided by the service interface are "windows" in the system through which the work request passes. After the necessary mapping / validation of the parameters after it is completed, these services give the message to the activity dispatcher 136a to invoke an Activity Plan that carries out the business tasks of the request. All services are synchronized because they immediately return a result to the requestor. However, the nature of results differs, based on whether the invoked service is interactive, or the initiator of a batch process. Interactive services, or those that require an immediate response to the user, will wait for the Activity Plan to be completed and a response will be returned. These types of requests can be quickly satisfied within the system through access to stored data. Other services initiate background work in batch. These services give the message to the 146a activity dispatcher panel to begin an Activity Plan that will be completed at some time in the future. These types of requests are called requests
asynchronous or deferred. When the service interface 144 activates an Activity Plan, it receives a unique identifier from the Activity Plan assigned by the dispatcher panel 146a, and uses this identifier to register an interest in completing the activity with the compliance administrator 136a. The external job requestor is immediately answered the identity of the Activity Plan. The applicant may then use other services to verify the status of the Activity Plan and / or be notified when an Activity Plan has been completed. The activity dispatcher brain 146b communicates with the compliance administrator 136a which in turn notifies all interested parties when the activity has ended. When the service interface administrator 144a receives the termination notification from the Activity Plan, it will return the results to the requesting client. This asynchronous or deferred service requests from the systems external to the service interface subsystem, to be able to provide a client context, which is taken through the automated meter reading server 15 not modified, and returned with the corresponding results.
This service allows an external system to create a meaningful context identifier for your application that can be used to match the response to the original request. In addition, the service interface 144 allows an external system to specify in each asynchronous request /
deferred, the link information of the RPC server within your system that must receive the results of the request. If the request does not provide this link information, then the specified RPC server will be used as a default server throughout the system. The default RPC server in the entire system can be set using the configuration file. Referring to Figures 4 and 10, provider subsystem 148 is illustrated. Vendor subsystem 148 is analogous to service interface subsystem 144. The "Order Compliance Center" for the system could be considered. There are two terms used to discuss the systems that provide measurement data to the automated meter reading server 15. The terms "Provider" and "Communications Server" are used interchangeably herein. The term "Provider" is used because the external systems that are in communication with the automated meter reading server 15 are not "Communications Systems" in the normal sense of the word computer. Instead, it is simply other computer systems that have their own application program or database interface formats to retrieve information that is supplied to the automated meter reading server 15. From the perspective of the reading server
automated meter 15, a "com" system or communications system is one that operates asynchronously and delivers its data in an unprocessed (or unstructured) format and in its own time not in the system (ie, in real time) or near real time). The external information systems 50 that collect and report meter information should appear to communicate with the automated meter reading server 15 in the same way that the automated meter reading server 15 could communicate with any other information system. With this in mind, it is preferable that the automated meter reading server 15 communicate with an external system in the same way that the internal systems or components within the automated meter reading server 15 communicate. For example, a message model can use a broker to resolve a location and an IDL to define interfaces. In accordance with the foregoing, the automated meter reading server 15 uses the same model to communicate with external systems. The automated meter reading server 15 sees each of the external systems by "type" and lists the attributes or types of information it will require as input, and the type of information it will provide as output. The automated meter reading server 15 is then able to find commonality between the systems and define a high
level of interface descriptions that will work with each type. The automated meter reading server 15 maintains the interface with the external systems abstracted as far from the system as possible to protect against future change or new systems. Specifically, the automated meter reading server 15 performs this isolation by finding common things in the existing systems and defining generic interfaces that will be communicated to the "wrappers" of the server 15 for the specific communication systems. Thus, the only components that will change over time will be the interfaces of third parties and in what way the automated meter reading server 15 wraps those interfaces. The automated meter reading server 15 can add new systems by constructing wrappers that communicate with generic IDL definitions for services within the automated meter reading server 15. Legacy systems can be treated similarly to external communication systems. Nevertheless, due to the nature of these legacy systems, it is likely that the type of information retrieved will not be compatible with the message-based architecture of the automated meter reading server 15. In particular, it is likely that legacy systems will transmit information via files
planes that must be analyzed syntactically in the sent messages, and conversely, in the automated meter reading server 15 the messages of the automated meter reading server 15 will need to be collected in batches to form flat files to be imported into the legacy system. This can be done better by determining the superset or attribute canon that will be communicated through legacy systems. The canonical mapper 140a, described above, maps specific legacy formats into common formats that have optimized the syntax parsers designed for the messages. The provider subsystem 148 hosts services that are specific to how a provider communicates information; this means that there will be interfaces of separate providers for different interface modes (asynchronous / synchronous) with the limitations and extensions necessary to support fixed networks, telephony, and so on. The type and capabilities of a provider are determined by the identification of the meter. The supplier interface asks suppliers for actions, such as remote disconnection, and permanence orders
(sample delivery). The interface encapsulates the differences between the synchronous and asynchronous forms of the interface as well as differences in types of networks so that the clients of the interface do not need to know with what "type" of provider they are interacting.
These services are similar to service interface services because they perform any required translation of internal key encoding in proprietary formats expected by external information providers. All outgoing requests to providers are carried out through Activity Plans (via activity dispatcher 146a). The services fired from a provider will begin the Activity Plans by performing tasks such as requesting information for a group of devices and then moving the results to the reception subsystem 15Od in the data access objects subsystem 150 (discussed below) for prosecution. Thus, the main purpose of the provider subsystem 148 is to provide the automated readout subsystems of secure access meters for data collected and stored on any communications server 30. To accomplish this, the ProviderAdm 148a, ProviderEcgress 148c servers, and Provider-income 148d interact with each other, the automated meter reading business objects, the activity management subsystem 146, and the automated meter reading event services (see Figure 4). In addition, the Vendor Vendor 148c and Vendor Vendor 148d servers are designed to interact with specific types of supported communication servers 30. Vendor Manager 148a is used
within the provider subsystem 148 to hide the differences in communication systems. From the level of automated meter reading server 15, all communication systems appear identical as seen from the provider interface. It is also the purpose of the provider subsystem 148 to provide a single secure access point for the automated meter reading subsystems 100 to all supported meter communication servers 30. The appropriate interface is chosen by the provider subsystem 148, protecting from this other automated meter reading subsystems of intricators to link to a specific interface. The provider subsystem 148 also provides a single secure access point for all supported meter communications servers to the services provided by the automated meter reading server 15. In addition, the provider subsystem 148 encapsulates the differences between the server interfaces of communications 30, as well as the differences in types of networks, so that the subsystems of automated reading of meters do not need to know with what type of provider they are interacting. The provider subsystem 148 supports both synchronous and asynchronous communications server interfaces, performs the required data transfer between the automated reading business objects
of internal meters and the data structure supported in the supplier application program interface, and performs any required translation of coding in internal keys in proprietary formats expected by external information providers. The main restrictions on access to the communication server 30 are considerations of security and transaction control. Security considerations are attacked by the DCE security services. Transaction control internal to the supplier subsystem and during interactions with other automated meter reading services is provided by Encina® 106. For the communication servers 30 that make up the synchronous model (Figure 11 described below), the subsystem of The workflow interacts with the 148mAdmin Provider through RQS and the data is passed through representatives of passivated business objects in the automated meter reading board object. Based on information obtained from representatives of business objects, Adm. Vendor 148a can route the request, along with the representatives of required business objects, to the appropriate Vendor Vendor 148c server. The Vendor Vendor 148c translates the data as required by the provider application program interface and sends the request to the communication server 30. The information
returned is used to update the business objects of automated meter reading. The service requests of the communication servers 30 are sent by the ingress provider server to a reduction control interface 148b, which initiates a workflow to perform the required tasks. The asynchronous communications server model (Figure 12a and 12b described below) is similar to the synchronous model with the exception that the requested activity does not expect response from the provider subsystem. The result is returned at a later time through the entry provider server 148d and can be tied to the original request using the automated meter reading context passed to the communication server 30 with the original request and returned with the response. Referring to Figure 11, the synchronous requests, (from the application system) where their specific outputs are directly. They can also provide application status and automated meter reading context information that can be used to retrieve information about the system record. Synchronous requests usually provide the fastest execution of an automated meter reading service. However, they are tied to the requestor string and the user's window (if any) until they are made.
Figure 12a illustrates the process of an asynchronous request. Requests that may require data from the communication servers or physical meters 60 will be made through the asynchronous mode because they can take a relatively long time to be carried out. Requests that can return in a large volume of data should be made through asynchronous mode. RPC through DCE does not support true asynchronous requests, so that the automated meter reading server 15 will make asynchronous requests generating a separate RPC call to inform the application system when the request is complete. Asynchronous requests (from the application system) return the request start status, and the automated meter reading context (reference) of the requesting RPC call. The answer
(message) provides the global status of the service. The answer contains either the output data directly or the output locations. The application system can also provide its own context information returned with the response so that the application system can associate the appropriate request with its response. Referring to Figure 12B, the asynchronous notifications will now be described. The automated meter reading server 15 will generate some scheduled services. For example, it generates services
periodically to store and collect meter readings for each billing program. The automated meter reading server 15 will notify the application system when these services are complete by invoking an RPC call to the service. The notification call will contain the outputs, and the context of automated reading of meters (reference) of the service. The provider subsystem 148 is comprised of three real servers, anAdmin 148a, an Expenser 148c, an Inbound provider 148d, and a logical server (not shown), and a reduction control 148b. VendorAdm 148a server is the main access point to the other automated meter reading subsystems. As shown in Figure 4, the Admirer 148a serves as the interface between the automated meter reading activity management subsystem 146 and the specific automated meter reading server 15 managing communication with communication servers 30. Routes the Meter service requests for automated meter reading services to automated meter reading services 148 responsible for connecting to the communications server 30 handling requests for the specific meter. The provider administrator 148a also manages the delivery schedules and the distribution of components of
collection for communication servers 30 (Figure 5). For example, when an automated meter reading program for data (billing program, data collection group program, etc.) is added or deleted, it is the responsibility of the VendorAdmin provider provider 148a to determine which communication server 30 should have a added or erased delivery program based on the meters 60 that the communication server 30 supports. It will be noted that the network layer of the communication server preferably supports several network technologies without changing the application code. A successful communications architecture should ensure that the specific instructions of a network are pushed as low as possible, and that common communications instructions are raised to ensure minimum amounts of new code development with each different communications environment. There are multiple Vendor Vendor 148c servers running on the automated meter reading server 15. As the name implies, Vendor Vendor Server 148 handles communication between the service to or the communication servers. In general, each Vendor Vendor 148c is responsible for a particular type of communication server 30 (not a particular instance). This can be a one-to-many relationship from the ProviderEgress server to communication servers 30.
The Vendor Vendor 148c shown in Figure 4 acts as an Encina® server 106 for the VendorAdm 148a and as a RTC client for the communication server 30, assuming that the communication server 30 supports DCE. The automated meter reading server publishes a standard distributed computing environment application program interface to connect to communication servers 30. If a communication server 30 does not support the distributed computing environment, but provides some other interface, then it is The work of the expense provider uses this connection gap and conceals the implementation details of this client interface from other automated meter reading subsystems. The ProviderEvents 148c server is responsible for the transfer of data between the business objects of automated reading of internal meters and the data and file structures supported in the standard application program interface provider (discussed below), or in data structures. data adapted to the client for different types of communication servers 30. In general, it is assumed that a server provider adapted to customer 148c will be required for each different communication server 30 supported by the automated meter reading server 15.
There may be multiple vendor revenue servers 148d running on the automated meter reading server 15. As its name implies, the Provider ingress 148d handles communications from the communication servers to the automated meter reading server 15. In general, each server Inbound provider 148b is responsible for a particular type of communication server 30 (not a particular instance of a communication server). In the specific case of the RCS-250 communication server, there will be a one-to-one relationship between the incoming Provider 48d server and the communication server. The provider Provider 148d shown in Figure 4 acts as an Encina® client 106 of the reduction control 148b and as an RPC server for the communication server 30, assuming that the communication server 30 supports DCE. The automated meter reading server 15 publishes a standard distributed computing environment application program interface to connect to the communication servers 30. The automated meter reading server 15 has a designed sensitivity with respect to how to measure (and others) ) communication information from data providers. It is preferable to maintain the automated meter reading interface to receive information as open as possible that some
providers will be sophisticated and will make use of the RPC interface while others push (or pull) flat files into our file system. Other possibilities include, but are not limited to, remote table readings and reading of remote message queues. An important note is that the Ingrid 148d Provider does not retrieve information directly from the devices and is not a data provider. If the automated meter reading server 15 is required to read device data, it is necessary to add a separate (sub) system acting as a provider. If a communications server 30 does not support DCE 112, but provides another interface, then it is the task of the ingress provider 148d to bypass this interface gap and hide the implementation details of this client interface from other automated meter reading subsystems. The Provider ingress 148d server is responsible for the transfer of data between the external data structures to the business objects of automated reading of internal meters. In general, it is assumed that an income Provider server tied to the client 148d will be required for each different type of the communication server 30 supported by the automated meter reading server 15. As shown in Figure 4, the reduction control 148b is a logical server, (really content
within the same process space as the Provider ingresser 148d) which connects between the Provider ingresser 148d and the activity management subsystem 146. The redress control 148b directs service requests to input the communication servers 30 to the responsible activities to service the request. In some situations, reduction control services 148b are triggered by data arriving from suppliers, which then direct the work to the appropriate reception point (reception services). Data can be sent from providers such as files moved to a receiving DFS directory, an RPC with a reference to a table space, an RPC with a reference to a remote file, an RPC containing an individual update, and an RPC with reference to messages available in a provider queue. The reduction control 148b is an object whose application program interface acts as a "traffic director". Control of reductions 148b begins the Activity Plans to handle data from suppliers. The different nature of the data (large load versus outbound messages) requires submanagers (delegated objects) to do the actual work. Therefore, the reduction control 148b is simply a management point very similar to the service interface 144. As discussed above, the reduction control 148b provides an interface for its use by
the Provider server 148d. Referring again to Figure 4, the application subsystems also comprise the data management services. The data management services are provided by two subsystems, a data access object subsystem 150, and an export subsystem 152. The data access object (DAO) subsystem 150 shown in Figure 4 is the primary subsystem of data management services. The data access object subsystem contains persistence objects to manipulate the Oracle® database, thus isolating the use of Persistence 108 intermediary from a set of specialized servers within this subsystem. Persistence objects (DAO) are representations of table objects within a relationship database. The data access objects represent the different components of the database. Objects have a hierarchical relationship with each other; A type of object or collection contains or is contained by another type of object or collection. The data access object subsystem 150 is responsible for providing application support services with access to the data warehouse 120. This subsystem simplifies the storage and handling of samples of collected meters. The relationships between request, store, retrieve and combine
The data collected is understandably complex. The data access object subsystem 150 is provided so that application developers do not need to have an understanding of the complex data relationships in the system in order to access data. Successive layers of encapsulation isolate the complexity of managing complex system data. For this purpose, representative objects are used to encapsulate the relationships and behavior of these data. These representative objects collectively are called "business objects". Representative objects are typically used by the admin servers, as well as by other application support services. For example, the data on the behavior of the tariff information are complex. This complexity is hidden within a set of tariff business objects for example (tariffs, tariff meter, component tariff, capacity measurement, etc.) that have a higher level interface called "150b rate administrator". There are many of these business object managers through which application developers have access to business objects or perform operations geared to the environment. There are successive layers of encapsulation that isolate the complexity of handling complex system data. These layers comprise the structure of
data access object 102 shown in Figure 3 and described below. The distributed access object structure 102 is provided to simplify the development of distributed objects in the Encina® 106 environment. The system can be considered as consisting of two main structure components, a DOF library, which provides a dynamic / time interface of execution to create server objects in the Encina® 106 environment and a code generator (genlnterfase), which generates objects and business representatives. The distributed access object structure 102 advantageously provides an environment where the creation, deletion and use of distributed business objects are transparent to the user. The distributed access object structure 102 also provides standard methods and implementations for all business objects, and hides all the details of the persistence data access objects 108 (DAO), DCE communications, DCE data types, and so on. To this end, the data access object structure 102 provides representatives, back-end servers, and back-end implementation servers for various business objects in the automated meter reading server 15. Figures 14 and 15 show an example of a measuring object, showing the paper
of the representative, a meter administrator server and a 150a meter rear end deployment server. As noted above, representative objects are mapped to the data access object, which in turn are representations of table objects within a relationship database. The logical architecture of the data access objects for various administrators and subsystems will be described below. When an administrator server invokes one of the client methods in a representative, the representative will call the back end implementation counterpart to perform the actual work with the associated data access objects. The so-called rear end implementation can be performed via RPC representative and the data access object is not in the same processing space and the representatives are distributed objects of "are there" as data access objects on the Encina® server. Data access objects, by their nature, can be distributed and stored in memory. Therefore, the representatives represent, or "wrap around", their respective data access objects within the Encina® servers, while the data access objects receive instant memory for quick access. In this way, the data and the integrity of transactions are maintained in a distributed environment. This distribution creates a lightweight administrator server
Relatively it is responsible for the coordination of several representatives to carry out the service of domain of automated reading of meters required. It also provides isolation of the persistence 108 broker to the deployment servers. The deployment servers and the administrator (shown together in Figure 4) can then be distributed through machines if necessary, and the system is required to scale up, without sacrificing the integrity of the transactions. To be efficient, this structure is developed as an option to build the local back end implementation behavior with the administrator server. Figures 13 and 14 show the interaction between the admin servers, representatives, and the implementation servers within the data access object subsystem 150; as other subsystems can use representatives directly to increase efficiency when simple types of creating, reading, updating, deleting, listing and existing (CRUDLE) requests are needed, - how exceptions are handled and become the subject of standard system state within the data access object subsystem. The meter manager server 150a contains a BO_Representative Rate in addition to a BO_Representante Meter. This is typical in the design of all
administrative servers, because the administrative servers are responsible for providing automated meter reading domain services. For example, the meter manager provides the meter rate recovery service, which requires you to create a rate representative in order to perform "readings" for a specific meter. Each representative is coupled with a dedicated back end implementation, which in turn is coupled with a dedicated set of data access objects (see fee implementation server 150b and meter implementation server 150a discussed below with reference to Figure 16). Figure 13 additionally shows how the service interface server 144a (an application support service) can create directly and use representatives. This is the typical use that any application support subsystem can make of the representatives. In these cases, the application support subsystem uses the create, update, read, delete, enlist, and exist methods (CURDLE) wrapped provided by the representatives to perform these simple operations against the deployment servers and the data warehouse 120 In these examples, knowledge of the automated meter reading domain provided by the admin servers is not required.
Although not explicitly stated in Figure 13, the design also supports implementation servers that do not have an explicit administrator service such as meter manager 150a and rate manager 150b. An example of this type of deployment servers is the external translation implementation server. In this case, other administrator servers that need translations for these deployment servers will be made and used by representatives of external translators, whose implementation of back end and data access objects reside in the external translation implementation server. Figure 13 also shows exception handling and system state conversion performed within the data access object subsystem 150. The main purpose of the system state (sysStatus) is to drive the logic of the Activity Plan. In addition, the sysStatus is used for information purposes outside the automated meter reading server system 15. No exceptions will be thrown across a server limit due to Encina® exception handling limitations. The responsibilities of the administrator / other servers (users of representatives) will get the sysStatus exception thrown by representatives (for logical control), convert the sysStatus exception in the appropriate sysStatus based on the context and return via RTC in the argument of
status or in the WFColaElementoestatusStruct, cross out communications exceptions, and cross out basic exceptions. The responsibilities of the implementation server are: cross all exceptions, translate to sysStatus and return via RPC in argument status and never re-throw exceptions through server limits. Referring to Figure 15, the process performed each time a method is invoked in a representative is shown. When the client needs to use a distributed object, call the constructor (step 1) on the distributed object. From the customer's point of view, this is similar to calling builders on any object. Internally, however, the distributed object / representative knows that it is named DO Factory, and calls a create (step 2) in the factory. This results in the RPC creating (step 3) the interface DOFabrica of the server. The routine create implementation in the server calls (step 4) the constructor in the distributed object interface using store object and performer. The RPC then consults the interface object to know its Encina® reference and returns to the Create RPC, which returns it to the representative. As soon as the distributed object representative receives the reference, the representative calls a repeater (step 5) on himself using the reference. At this point, the representative is established with a one-to-one correspondence with the object of
Rear end interface. The user calls, for example, to set AT the representative (step 6), the structure routes the call through a corresponding RPC. With respect to transaction work, any work that is performed by the distributed object that needs access to the database is carried out via the transaction RPC between the representative object and the back end implementation (for example, CURDL methods) . Distributed objects perform CURDL methods using key values / attributes that are set (step 7) on the business objects. Typically, the customer starts a transaction by invoking a transaction method, such as createobject () (step 8) in the representative. This results in a transaction RPC to the back end implementation (step 9). With the transaction RPC, an XA connection through persistence is opened and the Persistence data access objects are built (step 10). All attributes are copied right away from the back end implementation to the data access object (step 11). The data access object is deleted (step 12), which floods its data to the database 120. The XA connection is then closed. Thus, Persistence data access objects never exist through transaction RPCs, since they are mainly used to pass data to the database. As soon as a client commits, all changes are
commit to the database. The top-level scenarios of the above are contained in Appendix A. The data access object management servers 150a-150p illustrated in Figure 4 will now be described. The administrator servers 150a-15Op are primarily used by the dispatcher brain 146b of the activity management subsystem 146. The services / methods provided by the 150a-15Op admin servers are typically tasks of an Activity Plan. This section will highlight the media meshed services provided by several administrator servers 150a-15Op shown in Figure 4. As will be apparent to those skilled in the art, services are merely named in an exemplary manner since other services can be performed by different servers . The meter manager server 150a is responsible for providing all services related to the meters 60. The meter manager 150a can provide services to add a meter, add a meter map, install or uninstall a meter, update meter data, terminate a meter, calculate or verify a meter stage, set a meter connection status, and retrieve accounts or rates for a meter. The fee administrator server 150b is responsible for providing all related services
with rates. For example, the rate administrator 150b can provide services to add or remove a rate, retrieve rate components, assign and de-allocate a meter to a rate. The servers administrator of meter groups
150c is responsible for providing all services related to meter groups (for example, accounts, data collection, etc.). To provide these services, the 150c meter group administrator will interact with the account deployment server, and with the data collection implementation server. The 150c meter group administrator can provide services to add, modify or remove an account, retrieve the meter rate for an account, terminate meter groups, retrieve meters for a group, assign meters to a group, de-assign meters from a group and calculate a group stage. The receiving administrator 150b is responsible for uploading and receiving and mapping data in the repository. This is carried out either through a volume loading process for large data shipments, or through data access objects for individual meter readings on request. The receiving administrator 150b can provide services such as receiving a meter reading, receiving a load in volume.
The 15Ok reader manager is responsible for retrieving read samples from the automated meter reading data store 120. The service 150k reader manager includes retrieving readings (using fresh), assembling read data, and retrieving readings for meter rates. The I50j capability manager is responsible for determining the abilities of a particular component instance. "Capabilities" are attributes of various types of components in an automated meter reading server 15. For example, meters 60 of different types have different capacities that they can support. In addition, the different communication systems have different capacities that they support. "Skills" are "capabilities" enabled for an individual component. In other words, the skills are based on instances. The 15Oj capacity manager can provide services that allocate capabilities and validate tariff components. The reference data manager 15On is responsible for efficiently providing several lists of reference data such as meter identifications, meter types, types of communications, etc. from the automated meter reading data store 120. The data manager 150n reference uses persistence data access objects directly to recover
this information via simple queries of the automated meter reading data store 120. The reference data manager 150n does not use proxy objects and therefore there is no implementation server for reference data. This information is mainly used by a GUI subsystem to obtain lists of the automated meter reading data warehouse 120 for users to select. The 15On reference data manager is a service to retrieve reference data. As discussed above with reference to the
Figure 14, the data access object implementation servers 150a-150p contain the back end implementation for the representative objects and the persistence data access objects. The back end implementation provides representative users with services that operate on associated persistence data access objects and, therefore, their related Oracle® tables. The services performed by the deployment servers below are provided for exemplary purposes and are not limited to only the services noted. The meter implementation server 150a provides users with meter representatives for meter related services, such as changing or setting a meter, and retrieving and setting meter configuration information. The implementation server
rates 150b provides users with representatives of service fees, such as creating, updating, and reading tariff information from a meter. The 150i program implementation server provides users with representatives of service programs that include retrieving and scheduling times and events. The 150c meter group deployment server provides users with representatives of groups of service meters that include modifying meter groups, defining properties of meter groups, and mapping meters to groups. The 15Op account deployment server provides users of representatives of service accounts, such as determining the names of accounts, the status of groups, and defining account information. The meter group administrator server 150c is the primary server that will use the 15Op account implementation server services through the representatives. The data collection implementation server 150g provides users with representatives of data collection groups of data collection services. It is mainly the administrator server of meter groups 150c that will use these services through the representatives. The sample data implementation server 150f provides users with data representatives of service samples, such as reading sample data, and determining the validation of the data.
information. The 15Oh external translation implementation server translates from external to internal representation and vice versa. All the administrative servers that require identification translations between internal and external representation use the services of the external translation implementation server 15Oh. Some typical objects that have external representations are: meters 60, tariffs, programs, communications servers 30, accounts, data collection groups, and so on. The external translation implementation server 150h provides users of external translation representatives of services that perform operations on the associated persistence data access objects and therefore their related Oracle® database tables. The external translation implementation server does not have a specific administrator server, but is mainly used by the service interface 144. Referring again to Figure 4, the automated meter reading server 15 is responsible for generating data exports to the external application systems. The automated meter reading server 15 reports scheduled billing data, deferred requests, supplier performance statistics, and so on. The data used for these reports is available through the business objects managed by the business object servers. However, the results are gathered, mapped, and
format export to application systems. These services are encapsulated by the export subsystem 152. The export operation is conducted by specific Activity Plans to an export scenario, but the services needed to produce the export are contained within the generator together with fine grain control objects and medium. Referring to Figure 4, the export subsystem 152 is composed of two servers, an export administrator (EM) 152b and a validation, edition, and estimation (VEE) 152a administrator. These servers will process a large volume of data, so efficiency is an important consideration. One of the first functions of the export subsystem 152 that it supports is generating a billing report. To perform the billing process the data may require validation, editing, and estimation. The data export subsystem 152 of the automated meter reading server 15 uses template files to dynamically define which data is exported from the automated meter reading database 120. The basic concept of the export process is to extract data for a given hierarchy of information from the automated meter reading database 120 for a range of data and writing the data into a file using a format of
specific file. This file format is referred to herein as an automated meter reading file format, for example, an export of billing data from the automated meter reading server 15 consists of producing a file containing a hierarchical grouping of accounts, meters, data components and meter readings. That is, an account contains meters that contain data components that contain meter readings, all of which are encompassed by the range of data supplied. A template file defines what attributes will appear in the export file for each object in the hierarchy. For example, a meter has many attributes associated with it, such as its transformer factor, meter identification, communication status, type, etc., but for billing purposes, this information may not be relevant. However, for the purpose of loading this meter into another database, all attributes may be necessary. The template concept helps solve this problem by allowing the specification of what attributes will be extracted from a given object for a particular export task. Each type of export can use a different template, which allows the extraction of only the required information. This advantageously provides faster export times and smaller export files.
The following is an example of a template entry for a meter object in the automated meter reading server 15. + Medidorld Meter: measurer / obtainMeasure Id / longFax TransformerFactor: transfer / obtainMultiplier / Floating Measurement CommStatus: comms / obtain / CommunicationStatus / RWCCadena
-Measurer
As an exemplary export, an entry is used that maps the automated reading format file of meters to the export format. As an exemplary import, the import file can be converted into a set of C ++ objects. The template is applied against the objects to produce an automated meter reading format file, similar to the business objects noted above. The automated meter reading format file is then loaded into the receiving subsystem 150d. The export administrator (EM) 152b is one of the agents in the Activity Plan. When a billing report is generated, the export administrator 152b will receive a list of account IDs to process and identifications of services and paper. For each account, the
Export administrator 152b will retrieve a list of meters 60 for that account. The export administrator 152b then interrogates each meter to determine the list for a given service and paper identification. As soon as the rate for that meter is known, the components of the meter can be determined. For each meter component, one or more readings are collected. As is evident to one skilled in the art, this information nesting will make it difficult to assemble the export data in a mass query manner. Each reading is preferably validated (and possibly estimated) before it is exported. This creates a problem for the export administrator 152b because the data must be written for estimated readings and each reading must be updated as soon as it is validated. In addition, what would normally be non-transactional database operations this makes them transactional. These operations pose problems because there is a limitation in the number of database operations that can be performed on a single unit of transactions (smaller lot units), and that transactional readings are involved on XA header and can significantly slow down the process. The validation, edition, estimation (VEE) 152a administrator is responsible for performing the validation, editing,
and estimation specified by a particular regulatory agency to produce settlement quality data for export from the automated meter reading server 15. As with the Encina® servers in the system, the validation, editing and estimating administrator 152a uses server classes App to receive service requests through RQS. The 152a validation, editing and estimation manager uses a directed graph and the performer to execute different functions. Each request is for administrator of validation, editing, estimation 152a in a particular combination of meter / tariff and will be executed within its own string. Although logically shown as existing within the export subsystem 152, the validation, editing and estimation manager 152a is actually contained within the same process space of the read manager. The 152a validation, edition, and estimation administrator will, however, provide a separate interface and be joined as if it were a separate server. Physically it resides with the reading administrator as a performance utilization to minimize the transport of data through the network and benefit from the instant memory of local persistence object. Figures 34A-D illustrate the various strings executed in the validation, editing, estimation 152a manager. The tasks of validation, editing and estimation are
they must perform on raw data to certify data with settlement quality. Associated with these validation checks are specific estimation algorithms that must be performed on the raw data when a validation check fails. Unprocessed and estimated data values may also need to be stored and maintained for years due to legal stipulations regarding billing disputes. The additional storage of estimated data not only compounds database size and performance problems, but also creates the need for temporary solutions (discussed later). A thorough analysis of abnormal billing scenarios produces several situations that require an automated meter reading server 15 to maintain multiple history versions of both raw and estimated data for a meter 60. For example, consider the scenario where all the Billing data from an individual meter can not be collected due to a communication failure. The validation, edition and estimation rules specified will connect the missing data producing settlement quality data for this meter to support the customer's billing process. In case it happens that the actual raw data for this meter arrives after the billing processing has been completed
of the client, then an invoice adjustment process is required. The actual raw data received from this meter requires validation to be performed before it can be used to determine the appropriate invoice adjustment. This validation process may fail in any of the specific validation tasks and requires the estimation to produce the settlement quality data for the invoice adjustment. For example, if in the future (one month later), the customer has a billing dispute related to this abnormal billing period, a complete history of both the original transactions and the adjusted invoice (including raw and estimated data) ) will be required to resolve the customer's dispute. Another example of billing abnormalities is the case where the configuration data (for example, the transformer factor) of a customer's meter was entered incorrectly and was not detected during some monthly billing cycles. In this case, the meter data management agent needs to correct the configuration data (transformer factor) for the meter and recalculate the different bill months for this customer to determine the adjustment. Since both the original data sets and raw data and estimates were used to support the billing process, this data must be maintained by the system to resolve any dispute over
future billing. In order to carry out validation, editing and estimation, the validation, editing and estimating administrator 152a will use local Activity Plans and a local dispatcher to execute these plans. This local dispatcher approach has been designed for use in validation, editing and estimation 152a to take advantage of the fact that the primary objects used in validation, editing and estimation 152a are in the same process space. The local dispatcher performs a local Activity Plan which only executes local operations that carry out actions on local objects. The local operations generate a workflow slot, and a necessary forced re-reading, which indicates the need to re-read the physical meter 60 or the communication server 30 to retrieve more accurate readings during a specific period of time and then apply the readings to the administrator of validation, edition, estimate 152a. All parameters are on the board. Other batch services may use the local dispatcher approach for performance improvement, if they also strictly rely on local objects that are performed synchronously. This implementation uses a modified version of the infrastructure developed by the activity management subsystem 46. The guided graphic logic will contain the specific tasks of the agency
regulator and the rules. The Local Activity Plan (workflow) acts as a list of tasks in which the local dispatcher reads. For each task, the local Dispatcher asks the Director to perform the task. The Director uses a method dictionary to consult the Functor associated with the task. A Functor object executes the appropriate C ++ method to do the actual job of the task. The validation, editing and estimation interface 152a is used by other subsystems within the automated meter reading server 15. The service provided by the validation, editing, estimation 152a administrator includes verifying missing components, the use of interval information, calculating several consumption data, estimate the use of load profile, determine if a meter requires maintenance, apportion the use and load profile, and estimate the use. Referring now to Figure 4, the database (automated meter reading data warehouse 120) is an Oracle® relational database management system (RDBMS). The structure of the database is designed to represent a high-level object model, as shown in Figure 16. With respect to data storage, two signal factors of the automated meter reading server 15
preferably they use a distributed approach due to the tremendous volume of data stored, and the extremely high speed of data capture, manipulation, and extraction. For example, a meter undergoes 15 minutes of load profile readings on two channels for 24 hours per day, having a data retention period of 37 months, requiring a total of 63 bytes per row, a validation reading, editing and Simple reading estimate and 10 percent rereading and revalidation will require 14.97 megabytes (Mb) of storage space for your readings only. Given this per storage requirement per meter, the data storage requirements are as follows:
In addition, the data insertion speed is also large. Using Ardis, communication with the meters is available only 4 to 6 hours a day, usually between 10 p.m.
and 4 a.m. In the above 1000 meter system scenario this means that the automated meter reading database 120 performs 96 simple readings per meter, with an average size of 63 bytes per reading, or 96,000 insertions. This produces 4.44 inserts per meter per second during a six-hour collection period. When scaling is considered:
A conventional Unix relational database server installation consists of a single Unix central computer with a single relational database server process (or set of processes). For this configuration, conventional relational databases begin to experience problems maintaining an insertion speed of between 200 or 500 inserts per second. Thus, the conventional relational database server is inadequate to support the desired scalability of the automated meter reading database. To solve this, the data warehouse 120 of the present invention employs a
distribution of workload. This is done using multiple central computers to perform database duties. This type of parallelization can take two forms. The first is a true database distribution, in which multiple fully separate central computers operate separately under the control of management processes, and the second is parallelization, in which a machine can have multiple central processing units, input / output bus bars, etc. and can also participate in a loosely coupled nest of machines that are directed to a shared disk farm. The meters 60 can be associated with one or more tariffs, combine in groups of meters, and have many capacities and abilities. The capabilities are based on types of meters and specify the functionality supported by that type of meter. The skills are associated with a particular instance of a meter and represent the capabilities that are enabled by the programming of this particular meter. The rates specify what data is required to be collected for particular purposes (ie billing). When a meter 60 is assigned to a particular tariff, the skills of the meters are checked to verify that the meter 60 can support the data requirements specified by the tariff. A fee is set for
data collection components. These components have several types (load profile components, consumption components, etc.). These components have readings (consumption readings, load profile reading) that are associated with data samples. The groups of meters are associated with programs and specialize in two types of account and data collection. The accounts are specialized groups that are related to the billing process. The accounts contain meters that have different rates that are used to bill a particular customer. The data collection groups are meters 60 that share the same data collection components. These groups are mainly used to collect equal data from meters 60 possibly for export of the automated meter reading server 15 to an application system. Each of the objects in the high-level object diagram of Figure 16, the database is mapped as illustrated in Figures 17-25. Figure 17 illustrates the logical architecture of the 15Op account management subsystem. The 15Op account management subsystem provides operations in groups of meters 60, and resolves many-to-many relationships between a group and its elements. Figures 18a-b
illustrate the logical architecture of the 15Oj capacity manager. As noted earlier, skills are skills enabled. Capabilities are actions that a mechanism is capable of performing (for example, measurement, information and control). The abilities can be enabled either intrinsically or explicitly. A skill corresponding to a particular object and not to others (that is, the abilities are based on instances). Figure 19 illustrates the logical architecture of a meter manager 150a. As illustrated, the meter manager 150a provides to set the specific communication parameters to a particular meter. The meter manager 150a also contains a list of the communication states that a meter can have, the status of an electrical connection of the meter, the current meter stage in its life cycle (ie, ordered, inventoried, installed, readable , collectible, finished). Figure 20 illustrates the logical architecture of the tariff manager 150b. The 150b rate administrator sets rates for particular meters 60 (or vice versa). The data component instance (DC) application of the data collection template (DCPlantilla) to a particular meter. Only certain combinations of DCTemplates are allowed. Figure 21 illustrates the logical architecture of the read administration server 150k. The 15Ok read manager server provides scalar readings
(consumption or demand) or arrangements (load profile or time of use) and the reading of the meter is divided between two tables
(Sample of Meter and Sample Data). The method of acquiring each data point in the meter reading is determined for data quality purposes, as well as why the meter was read. Figures 22A-B illustrate the logical architecture of the program manager 138b. The program manager 138b provides setting the program of periodic delivery of exported data to a service. To perform the export, the external data characteristics are set, for example, file name, when to deliver the data. Program manager 138b is also responsible for scheduling workflows. The expected time for each workflow and the total number of workflows are taken into account to determine when to start the workflow so that the system is not overloaded. Reception events and internal events within the AMR are also programmed by the program manager 138b. For example, the data that is going to be received from a provider is programmed as well as the actions that the AMR has to do to make the data available to the service. The logical view of the program manager 150f is shown in Figures 23A-E. The program management subsystem accepts requests via the workflow to create and store programs from the collection of
data It is the Encina® meter interface to build work plans (Activity Plans) for billing programs. The program builder constructs work plans, adapting the activities in the different programs as tasks, determines when to start the activities, and sets the alarms to trigger the execution. For example, when a new billing program is entered into the system, a delivery schedule for the data provider needs to be determined. In addition, a work plan for a time range needs to be built, including, find all programs with times within range, arrange in chronological order, include start times that result in acceptable completion times, put work into a plan of work, set alarms to trigger the tasks and the remote procedure call operation for the subsystem. In addition, programmed actions, conflicts of events are also determined, and if an event is added to another event. A scheduled task is something that has to do with a scheduled time. As noted above, it consists of "what to do" and "when to do it". "What to do" is a scheduled event, which carries all the information about the activity. "When to do it" is a programmed time, which carries all the information about the time. Figure 24 illustrates the logical architecture of the system parameters. The parameters of the system are a
catalog of the properties of the automated meter reading server 15. They can be used to set omissions on an amplitude basis of the system, and set service omissions on a service amplitude basis. Figure 25 illustrates the logical architecture of the 15Oh translation service. The 15Oh translation service can be used to validate fields such as state codes and zip codes, and determine a regulatory agency for a jurisdiction in which the meter resides. Relational databases suffer from a deficiency because they generally keep only current data, since all previous versions of the data are overwritten. In this way, the relational database approach does not provide a historical view of the data. The solution to this problem is to use a temporal structure approach. This approach includes arguing the database to maintain two time stamp ranges for each table, causing stored procedures to perform the temporary equivalent of relational insertions, update and delete, providing a template technique to select the correct version of data to Starting from the database for different views of the history, and performing relatively minor registry of application servers to use the temporary structure. The database 120 is implemented using
temporary time stamps in relation tables. An explanation of the use of temporary time stamps in the relationship tables is given below. The conceptual and temporal data model is preferably used in the automated meter reading server 15 due to the ability of this model to satisfy the requirements of the electrical deregulation information market. The bitemporal conceptual data model is an extension of the relational data model that allows two independent, orthogonal time periods, which are associated with each row in a relation (table). This is done using the time stamp data type to append two time periods to each multiple: valid time and transaction time. The valid and the transaction have two limits, start time and end time. The two periods are orthogonal, that is, they register different, independent aspects of the multiple. The valid period is the range of time during which an event is true. The transaction period is the range of time during which the knowledge of an event is current, or in other words, the range of time during which an event is recorded in the database. The temporal time stamp is modeled as two dependent relationship attributes, start time and end time, where the start time is always less than or equal to the end time.
The limits of time periods also have different meanings. For valid, the start time is when an event becomes true or effective. The valid end time is when a fact ceases to be true. For the transaction time period, the start time is when a fact (row) is registered in the database; the final time records how much the fact represents the current state of the relationship. In other words, the end time records the expiration or deletion time or an event as conforming represents current relationships. With respect to the operations of the database, there are three possible write operations that involve temporary time stamps: inserts, updates, and deletions. In addition, there are two possible scenarios for updates: valid attributes are modified or not modified. Modification of the valid time stamp can be done to reflect a new understanding of the period of time by which an event was (is) true. In the temporal sense, the three write operations in the database work as follows: 1. During an insertion, a row is inserted into the appropriate database table. 2. During an update, a new row with the updated data is inserted into the appropriate database table. The final transaction time of the row
previously updated is updated at the time of completion of the updated operation. 3. During a deletion, the current row is not actually removed from the database, but is logically deleted by updating the final transaction time somewhat less than infinite, but not necessarily less than the time stamp of completing the transaction. delete. If the final transaction time is set in a longer time than now, the fact is current until that time, that is, the event is previously set to expire at the end of the transaction. As an example, a meter can have many rates and a rate can be applied to many meters 60. What needs to be determined is when this ratio of meters 60 and rates is effective (valid). This is indicated by the valid time and transaction stamps of the meter, the rate in the intersection table that solves the ratio of many to many meter-rates. Some samples of these tables are shown below: Table 1
The meter Id is the main key of the meter table, while the meter type is a variant attribute in time that is not periodic. OCA is the optimistic control attribute; it is compared with the OCA value stored in a passive representative object, to determine whether the data retrieved from the database represents the state of the representative object before passivation. Vs and Ve are the start time and the end time the limits of the valid time stamp. Ts and Te are similar. It is useful to think that these two values comprise a type of data. As shown in Table 1, meter 1 has a type of AID meter, and this is valid and current from April 1 to the following. This is an example of a direct insertion. Meter 2 originally had a type of meter A1K, and this was valid from April 1 onwards, and current from April 1 to July 4. The type of meter for meter 2 was changed to A1-K2 on July 4 and was returned the current fact. Note, that since the valid time stamp did not change, this reflects a meter type correction back to April 1, essentially correcting the history of the meter. This is an example of an update that modifies the valid time stamp. Note the OCA value to meter 2 also changed from 0 to 1. These mark the row as being different than before, and it is used for optimistic blocking. The optimistic block will be discussed later.
Table 2
As shown in Figures 2A-2D, tariff 10 has a type of LP KVA tariff that is a current rate type from April 1 to April 15 at that time the customer requested the change to the LP rate type KVAR at the end of the fourth billing cycle. The valid period for the previous rate type ends at the end of the fourth billing cycle (April 25), and the new rate type is valid from the beginning of the fifth billing cycle (April 26) onwards. The change was recorded in the database on April 15, however, and thus becomes current at this time. This logical update represents a new status for rate 10. This is an example of an update that modifies the valid time stamp. Rate 11 is another example of a direct insertion.
Table 3
As shown in Table 3, the tariff meter is an insertion table that solves the many-to-many relationships between the meter and the tariff. As such it has two parts keys, medidorld and tarifald. For rate meter (1, 11), the association between meter 1 and rate 11 becomes valid on April 1 and thus continues forever. As used herein, the "forever" time refers to the date 2-5-2037, since this is the last date that can be represented by the preferred database software. The association between meter 1 and rate 11 is also current for the same period of time. It represents a direct insertion in the table of insertions. For meter rate (2, 10), there are two possibilities.
The first possibility is represented above in Table 3. When tariff 10 changed on April 15, meter rate could be updated to reflect a change in the association, that is, meter rate, that is, rate meter (2, 10) sample the change of state of one of its associates. Other
possibility is that the same association has not changed, so that the two rows previously shown by the rate meter (2, 10) could be represented by a single row: Table 4
However, with this representation, the ability to distinguish which rate to use during the valid time period of the association is ambiguous. If the current state is selected, rate 10 with the current transaction time stamp (the one with a longer end time than now) would be used. During a billing run for the billing cycle 4, the fee 10 with the valid time stamp (s) covering the time period of the billing cycle is used. The logic used to select the correct rate representation 10 may be inherent to the navigation of the relationships in Table 3. If represented as Table 4, the programmer is left to choose which tariff representation to use. The techniques for selecting the correct data are presented later. Changes to valid times can cause an overlap with the valid time period of other versions
(rows) of the entity instance. In this case, a special operation, coalescent, may be required. It is noted that this should not be confused with the COALESCE operation of
Oracle®. Two or more rows with identical non-temporal attribute values are value equivalents. Equivalent value rows with adjacent or overlapping time periods represent a time extension of a single event and therefore must coalesce in a single row. This is the case with rate meter (2, 10) present in Table 3, if the OCA value is not taken into account. The coalescing operation is similar to duplicating the elimination in a "select different" operation. Coalescence is an extremely expensive operation in a relational database machine purely, and should be avoided if possible. To determine how to avoid coalescence, it is necessary to examine the three ways in which the equivalent rows of value can be materialized in a database. The first way that rows of equivalent value can appear through the insertion of rows of equivalent value with different time stamps. Consider Table 5:
Table 5
In Table 5, the validity of meter rate (2, 10) extends from April 25 onwards, and the update extends from April 15 until forever. These two rows have equivalent value and have adjacent time stamps. Therefore they can be coalesced in a single row without any loss of semantic information, as shown in Table 6. Table 6
However, the coalescence operation is performed either in the application that modifies the data, or through the processing code stored in the database. If done by the C ++ programmer, the appropriate pre-conditions for coalescence are detected and a method called that literally updates the database, instead of performing a
temporary update. If it is done by the stored procedure of insertion of the programmer, each new record inserted in the database is preferably tested with all other records of the same primary key. If the coalescence criteria are satisfied, the stored procedure extends the valid or transaction time stamp, or both, of an existing row by performing a classic database update. To effectively perform the coalescence in C ++ code, the programmer needs to perform a search for rows with equivalent value before any insertion, retrieve any candidate, evaluate the criteria of coalescence, and call a special method that performs a classic database update in an existing row. This algorithm is also duplicated for each implementation of low level representatives. This technique, however, is expensive in terms of processing time and network bandwidth but has the advantage, in a multi-tasking environment, of extending work over many processes. It can also be a template, after a form, and the requirement code generated by the representatives code generators. The code generators are similar software production lines, given an order, the generator creates a reproducible code that shares characteristics with other units of the production line. To expand the analogy,
The models of an automobile manufacturer differ in size, model, style, color, options, and price. However, each car shares a nuclear set of similarities that allow the driver to operate any of these vehicles without restrictions. For example, the steering wheels are always round and when they are turned clockwise they make the vehicle turn to the right. The pedal design and operation are always the same. The indicator meters present familiar information, although possibly in a different format. The fuel is standardized, since it is the basic movement operation. This standardization extends to the production line that produced the automobiles. Although the list of available options is set for a certain model and year, each client can specify which options they want for their vehicle. The production line can then take this specification and produce the right vehicle for that customer. The client is then responsible for any adaptation to the client that he wishes to make in his car. The code generators serve a similar function in the automated meter reading server 15. When creating the specification for an App server, a representative, or a data access object, the programmer can have the most shared code, standard generated by them. This code represents a substantial portion of the
code required to implement one of these classes. In addition, the result is reproducible, since the code is not built by hand every time, which reduces the potential for error and time to return to work. Thus, the overall quality of the automated meter reading server 15 is greatly improved by using code generators, and the cost in terms of time is reduced proportionally. If the stored insertion procedure is responsible for the coalescence, it also evaluates the table for any equivalent row in value that satisfies the coalescence criteria, and then performs a classic database update in an existing row. This approach has the disadvantage of locating all the processing in the database machine, which is less distributable than the Encina® servers. The location may be an advantage, however, because it simplifies the work of C ++ programmers, and the stored procedure code can be generated via an appropriately modified generator. Also, this approach curtails network traffic, which preferably avoids bottlenecks throughout the automated meter reading server 15. The second way that rows of equivalent value may appear is temporarily updating the row with adjacent timestamps or overlapping Table 7 shows the table of meters that contains a single row,
valid and current forever. Table 7
If the row is temporarily updated (a new row is inserted and becomes current, and the Te value of the existing row changes to the time stamp fulfilled) with values equivalent in value, it results in a new row, as shown in Table 8. Table 8
This condition can be more easily avoided by detecting the equivalence in value of the "new" row in the representative code, and disabling the update. A third way that rows of equivalent value can appear is by updating one row so that it becomes temporarily adjacent or coincident with another row, as shown in Table 9.
Table 9
Suppose that meter 2 was assigned rate 11 by mistake. If RateMeter (2, 11) is corrected to reflect that rate should actually be rate 10 instead of rate 11, the result is shown in Table 10. Table 10
If the operation is allowed, then the three rows above represent a single, temporarily continuous fact of rate meter (2, 10) and must coalesce. There is a problem with this specific operation. As a policy, are "errors" valid data, and therefore remain in the story, or can they be corrected without loss of information? If the first thing happens, then modify the Tarifald
MeterTariff (2, 11) should not be allowed, and instead apply a temporary update. This results in Table 11. Table 11
Examining the valid timestamps, we see that rows 1, 4, and 3 have adjacent and overlapping validities, and therefore form a single temporally continuous fact with respect to validity, that is, row 2 represents a state of error. However, if they are coalesced, the details of the history with error shown in row 2 are removed. Examining the transaction time stamps of rows 1, 4 and 3, it is seen that rows 1 and 4 are not temporarily adjacent, even though their validities are temporarily adjacent. In addition, rows 3 and 4 have overlapping and valid transaction periods. These two rows can be coalesced without loss of information, since the valid period for the erroneous fact lies completely within the valid period of the coalesced rows 3 and 4, and the period
transaction for row 3 completely contains transaction period for row 4. The result is presented in Table 12.
Table 12
Note that the valid periods of rows 1 and 3 are adjacent, and the transaction period for row 3 is later than the transaction period for row 2, which indicates that row 3 follows row 2. The same information now it occupies 37 bytes less. To further illustrate this example, suppose that a billing run was made in May on the above data. Row 3 may not yet exist, so the erroneous rate 11 is used in the billing run. As soon as the error was discovered in June and corrected, another billing run would use rate 10 to publish the amendment to the May results, and rate 10 would be used since then. In addition, the fact that an incorrect rate has been used once could be detected and examined without
Degrade the proper behavior of the system. If table 11 is rearranged in some way, the result is Table 13. Note that the order of rows 4 and 3 was exchanged. Table 13
The second and third rows are the "wrong" fact and the "corrected" fact. This reordering makes it apparent that meter rate (2, 10) has been the association valid since April 1. This is shown because the continuity is indicated by the adjacent valid time stamps and the larger transaction time stamp (posterior in time) temporarily of row 3 compared to row 2. When the question is asked "how much Has meter 2 been at rate 10? " The time range that answers this question begins on April 1 and continues until now. This implies that the query should return a single response, instead of consecutive multiple adjacent results. This type of coalescence is done at the time of the consultation instead of
during the writing of the database. Each scenario presented above should be examined and tested to determine the most effective and efficient techniques to implement the history in the production of the automated meter reading server.
. With respect to data manipulation techniques, the following clauses are used. To select the current version of the data, the following "where" clause is used in the selected statement: where the transaction time begins <: now and the transaction time ends > : Now "where: now" is a variable that has the transaction start time selected. To select a version of data that matches a specific date, use the following "where" clause: where: specify date between valid time start and valid end time "where: specify date" is the specific date of interest. To select a version of data that falls in a certain period of time, use the following clause "where": where validTimeTime (valid start time) between: startPeriodTime (time period start) and: EndTimeTimer (end of time period) and validFinTime (valid end time)
between: timePeriodStart and: timePeriod EndThe last clause "where" is typical of navigation queries that traverse the relationship scheme, denouncing the relationships between parent and dependent tables. The limits of either a valid or transaction period of the parent record. The following explains the transition that each period experiences during the operations of writing the databases. All times are registered in the UTC time zone. During an insertion, a row is inserted into the appropriate database table. The policy for valid and transaction periods is as follows: validTimeTime can be set to a past or future date. If it is not set, by default it will be the time fulfilled of the database transaction. Valid EndTime can be set to a past or future date, as long as it is greater than the valid StartTime. If FinTime is not set, it is set to infinite by default, which occurs on February 5, 2037 (the maximum time that RogueWave, RWTime (UINT_MAX) can accommodate). The initial transaction is fixed in the time fulfilled by the transaction of the database. This remains consistent among all the database scripts that are presented during a single database transaction. Transaction end time is set to RWTime (UINT_MAX). During an update, a new row with the
Updated data is inserted into the appropriate database table. The end time transaction of the current row is previously updated for the time completed of the update operation. The policy of the valid and transaction periods of the new row is as follows: valid start Time can be updated. If so, valid start Time can be changed to a past or future date. It may not exceed the end of time. If the start Time is not updated, it will not be changed in the database. Valid endTime can be updated. Valid endTime may change to a past or future date, as long as it is greater than valid startTime. If end of time is not updated, it will not be changed in the database. Transaction start Time is set to the time fulfilled of the database transaction. This remains consistent among all database writes that are submitted during a single database transaction. Transaction finTime is set to RWTime (UINT_MAX). During a deletion, the current row is not actually removed from the database, but is logically deleted by updating the transaction finTime some time less than infinite, but not necessarily less than or equal to erase the stamp of time fulfilled operation. If transaction end time is set in a longer time than now, the fact is current until that moment, that is, the fact is previously set so that it expires in transaction finTiempo. This is
It may become problematic though, and it is not recommended. Valid start Time does not change. Valid endTime does not change. Transaction start Time does not change. Transaction finTime is updated to the time completed of the deleted operation. The functionality of the bitemporal conceptual data model accommodates both strategic and tactical directions to vendors, database standards, and automated meter reading server 15, and is preferably used to meet the needs of the deregulated electrical service industry . As shown in Figures 3 and 4, the automated meter reading server 15 supports many interfaces of external application programs (APIs) 124 and 132. The automated meter reading server 15 provides a remote procedure call (RPC) of application interface of distributed computing environment for application systems. External systems will require a distributed computing environment in order to use the application interface of the automated meter reading server 15. The distributed computing environment is supported with all the important platforms including the central structures, servers / workstations UNIX, and PCS. The application program interface of the automated meter reading server 15 provides an external system with access to
services within the automated meter reading server 15. The initiator of a remote procedure call (RPC) acts as an RPC client and the receiver of a remote procedure call acts as an RPC server. Each application program interface service request returns to the request status. Note that all application program interface calls return distributed computing environment error status. The diagrams below show the high-level interactions of the service initiator and receiver. The following will highlight the application program interface calls available to an RPC client running in an application system (application program interfaces invoked from the application system for automated meter reading). Application program interface meter life cycle: Add meter Defines a meter in the AMR data request base. The synchronous addition / definition of a meter to the AMR database is done through the primary meter service (or third party vendor).
Install meter Registers the physical installation of
Request a meter at your location. synchronous
Uninstall Records the physical removal of a meter from your location. Synchronous request
Modify meter Modifies the definition of an existing synchronous meter request
End Mediro Removes the meter from the Data Request database after a specific synchronous expiration.
Account life cycle. Interfaces of application programs:
Add meter Add a new inactive account. Application An account can refer to a synchronous new or existing service.
Add meter to Add a meter to an account. The account account may or may not have other Request Meters 60 associated with it. synchronous
Remove Meter from Disassociate a meter from an account. account This disassociation does not physically remove the meter. synchronous
Modify Account Modifies the definition of an existing Account Request. synchronous
Terminate account Terminate an account. The account does not
Request must have meters 60 assigned to her synchronous.
Rates include the functions necessary to define and manage rates including usage and interval data. Different meters 60 for the same account may have different rates; however, a single meter can only be associated with a rate at any given time. The data available in the meter that could be used as "data from
Billing "(and therefore included in the billing information required by a rate type) includes" * "total for this billing period, and" * "load profile (typically 5, 15, 30, or 60 minutes) where "*" can be any of the following: kW (h) delivered, kW (h) received, kVA (h) delivered, kVA (h) received, kVAR (h) delivered, kVAR (h) received, kVAR (h) for quadrants 1, 2, 3, 4, kQ (h) delivered, kQ (h) received, and energy factor per peak demand, peak demand for time of use and load profile. of application include: Create fee Define a fee on the basis of Request AMR data A fee consists of synchronous one or more data components that provide specific information required to calculate an invoice.
Assign rate to Assign a fee to a meter Synchronous request
Remove fee from Remove a fee from a meter Synchronous request
Delete rate Deletes a fee from the base of the synchronous AMR data request
With respect to the interval data, the data is normalized when a clock in the meter does not match the clock of the computer reading the meter. These phenomena are called "clock offset". The clock offset can be positive or negative depending on whether the actual time (on the computer) is greater than (negative offset) or less than (positive offset) on the clock in the meter. The measurement data includes the functions necessary to retrieve meter reading information used for billing and for information (rate studies), and sends it to the appropriate systems or. This includes both consumption and interval data.
Meter reading Retrieves meter readings at request request for a specific meter Request database using asynchronous specific recovery parameters that are passed with the request. If the readings stored in the database are not recent enough, the reading is retrieved from the meter. This recovery can be done via a meter, account, or data collection group.
Export data Collect billing data billing based on a program and prepares the billing data in a scheduled
Notification "Destination file". The asynchronous client is notified that the billing data file is ready for recovery. Validation must be done on a date prior to shipment.
Export Reg data in which way the measurement scheduler, an operator, or an external system notification exports data from asynchronous interval of the AMR database or to the external system. The export data can be in a range of times / dates and for a group of data collection, channels or specific meters, or meters 60.
Enter Manual manual data entry of meter data into the AMR database. Request when a synchronous AMR reading is not available. The reading can be real or estimated. The reading is not imported from a file.
Import data from Registers the import of meter data components for meters Request 60 from a system or synchronous external operator. This data can come from a meter via a device such as a manual and then enter the system through this import process. The import of meter data represents a scenario that is neither typical nor automatic.
The programmer includes billing programming functions to define which meters 60 will be read on which billing days for billing purposes or information purposes. The billing reading program includes the "billing day", and identifies other information necessary to collect and process billing information. An allowance is assigned to an account and assigned to a billing program.
The interfaces of associated application programs are as follows:
Create program Define a billing invoicing program for the AMR database of Request according to the program given by a synchronous client. The program specifies both when the billing readings are delivered to the billing system and what actually constitutes a valid billing reading (freshness).
Assign account to Assign an account to a specific billing program program. invoicing Synchronous request
Remove account Remove an account from a specific billing program program. invoicing Synchronous request
Delete program Delete a billing billing program the AMR database Synchronous request
The interfaces of group application programs are as follows:
Create group Define a data collection collection group. The data data collection group defines data components that are periodically synchronized to be retrieved from the meter and stored in the database.
Add meter to Add a meter to an existing data collection group group. The request collection includes the name of the data collection group data and a Request list of meters 60 that will be synchronously added to the group. A meter can belong to more than one data collection group.
Delete meter from the Remove a meter from a group of data collection group. The collection removal stops the data collection data for that meter. Previously
Request data collected are still synchronous available for recovery based on recovery rules.
Delete group from Remove a data collection collection group from the AMR database A group data can only be deleted Request when there are no synchronous meters 60 associated with it. The data is still available for recovery until the data retention period expires.
Interfaces of administrative application programs:
Synchronize time Check the time inside of a meter meter. Synchronous request
Validation Edit and estimate data
The automated meter reading server 15 tracks the electrical service connection status (disconnect / reconnect) of the meters 60 within its database. For example, as soon as a meter technician has physically connected or disconnected electrical service to a premises, notification must be sent to the automated meter reading server 15 via the modifying meter application program interface and the status flag of the meter is updated. adequate meter. In addition, meter readings can be obtained and identified as "connect" or "disconnect" readings in the database with their associated date / time stamps and reason codes. The interfaces of the provider system (application program interfaces) will now be described. The automated meter reading server 15 provides services allowing automated meter reading of different types of electrical measurements from a variety of meter types and communication networks. These services integrate the various types of meters 60 and communication servers in a uniform flow of data that will better support the business and engineering units of the
services. The services provided by the automated meter reading server 15 should be as transparent as possible to the type of network or communication networks used by the service. The application program interface provider is a set of common application program interfaces that protects the individual from the vendor-specific communication servers 30 and the application server service networks of the meter 15 automated reading server. service wishes to add another type of communication network to the automated meter reading server 15, this will only require the addition of a new communications interface on the meter reading server 15 and will not impact the AMR application software or service. The application program interface of the Provider presents different scenarios of the application program interface of the communication server 30 that interact with the automated meter reading server 15 in both synchronous and asynchronous communication modes. The application program interface is used as an interface between the automated meter reading server and the communication server. Some interfaces of application programs will be called by the automated meter reading server 15 for the servers of
communications 30, while others will be invoked from the communications server 30 to the automated meter reading server 15. Not all application program interfaces will be applied to a particular communications server. If an application program interface is not applicable to a specific communication server, the application program interface can still be called, but the status code AMR_NO_SUPPORTED will return. In general, all interfaces of application programs interact with the provider interface on the automated meter reading server 15. However, the receiving subsystem will process the received volume delivery data and on-demand readings. The automated meter reading server 15 faces the challenge of accepting a variety of data types (i.e., formats) from different types of meters 60 and communication servers 30. Therefore, a flexible data format is needed to facilitate data mapping and integration. At the same time, in order to make the application interface secure to the type and avoid potential runtime errors, the automated meter reading server 15 has fixed data types. The AMR 10 employs enuminated junctions of distributed computing environment so that each different structure can be supported at run time, while still
You are given a type of verification. Extensions of the application program interface can be made without affecting old times by using the numbering of the distributed computing environment version. In some cases, a data format based on label value can be used for maximum flexibility. This format applies labels to all values. The beauty of this format is the ability to store any type of data with defined labels; however, you could increase the size of the data for an application program interface. The predominantly labeled fields will be used for parameters such as service context, which can have any information that the company's service wishes the automated meter reading server 15 to carry as context information. The top-level scenarios of the supplier application program interfaces are contained in appendix A. The application program interfaces invoked from the communications server 30 to the AMR are the following: DiscoverMeasurement Inform the AMR 15 server that is has found a new meter in the field.
Delivered to Notify server AMR 15 that the volume consumption and / or volume loading profile for the specific delivery program has been delivered and is available in the specific file.
The interfaces of application programs invoked from the AMR to the communications server 30 are as follows:
Add Meter Add a new meter to the communication server.
Delete Meter Erases a specific meter.
Readings Request the meter reading data on request meter for the specific meter. The read data may consist of consumption and / or interval data depending on the input argument of the component array. The data is returned in file name.
Add program Creates a new program with the given program identification delivery for the delivery of data from the communications server 30 to the AMR 15 server.
Add collection Creates the collection of component components for consumption and / or interval data in the communication server 30 and returns the identifications of assigned components.
Sync Meter Requests the timing of Time for the specific meter. The local distributed time service DCE to the communication server is used as the source of the time.
Add Meter Assign the specific pickup components component and program program delivery to the specific meter.
Obtain Meter Retrieve meter configuration Config and type information for the specific meter from the communication server.
Delete Collection Removes the components of -Component collection from the communication server.
Delete Delivery - Deletes a program for delivery to Program from the communication server.
Delete Meter Deletes component program delivery / component collection program assignments for the specific meter.
An automated meter reading server scenario 15 for a meter reading on demand will now be described with reference to Figure 26. The following numbered steps correspond to the numbered flows illustrated in Figure 26. 1. The user presses "Submit" in a Java® AMR application
2. The Encina® ConfigUtility server performs back end support for the Java® application and gives messages in the utility interface on request reading interface of the application program 3. The UtilityMgr (ServiceAdm) server Encina® hosts the interface service interface of application programs. For this call, the Adm Service uses the meter representative and the tariff representative to populate the appropriate data and request execution of the workflow at the request of the reading meter. 4. The Encina® panel dispatcher server retrieves the meter reading workflow on request, assign a workflow identification, and queue a message to the dispatcher brain. 5. The Dispenser Cebrebro Encina® server executes the meter reading workflow on request. 6. The brain queues a message to the Adm Encina® reading server requesting a service to obtain readings using freshness. 7. ReadingAdm uses data sample representative (Encina® read serverAdm) to read samples from the automated meter reading database 8. If the return status is STS_PASADO_LECTURAS then the brain dispatcher queues a message to the providerAdmin server Encina® requesting a service
meter reading on request. 9. SupplierAdm determines the correct Encina® delivery server server to put message for the meter. 10. The RCS Encina® server (running in NT) verifies the local database for the appropriate reading data. If the data is outdated, the meter is marked and the data is read from the meter. The read file is written to the distributed file service directory. 11. Brain Dispatcher queues a message to the Adm Encina® receiving server requesting a service to receive meter readings. 12. ExceptionAdm retrieves the specific read file from the distributed file service and analyzes the file syntactically. The server samples data Encina® stores the readings in the automated meter reading database. 13. Brain Dispatcher queues a message to readAdm requesting service to obtain meter readings. 14. LecturasAdm uses sample meter and data sampling representatives (Encina® sample server displays) to read samples from the automated meter reading database. Samples are stored in a file in the distributed file service directory. 15. The brain dispatcher meets the flow of
work and notify the dispatcherPanel and concernenciaAdm of the completion of the workflow and final status. 16. ConcernAdm notifies Adm services of completion of workflow and final status. 17. The useful service agent notifies services of completion of the workflow, final status, and read file. 18. ConcernServices notifies the Java® application of automated meter reading of the completion of the workflow and of the reading file. The results are displayed to the user. Another facet of the automated meter reading server 15 is the aby to adapt the system to the client. Client adaptation is essential because the scope of operation of the automated meter reading server 15 may include data collection from meters 60 in different states in the United States and in the world and under different regulatory authorities. The system adapts to the application of processes such as editing and estimation with unique sets of finite rules depending on the applicable business or regulatory authority. Examples of parameters that may vary include regulatory authority parameters (for example, state agencies, validation, editing and estimation, and time synchronization), service parameters (for example, data freshness values of
meter, and timing and number of meter readings / retries), and system parameters (eg, C &I server system specifications, meter characteristics and capabies, standard communications features, size and length of data storage, and size and duration of system records). The automated meter reading server 15 will also need to be managed by an appropriate set of tools, and accordingly, the administration of the automated meter reading server 15 comprises a basic system administration plan and tools. The plans are tailored to support existing customer practices and will include, at a minimum, hardware and software configuration, administration tools, operation documentation and operator training. The tools for system administration will match the existing client standards. In the event there are no standards, platform specific system administration tools can be used to monitor and assist in the operation and maintenance of the automated meter reading server 15. The maintenance windows planned for each client should be implemented, and will be dependent on the customer's critical operating time frames. Routine maintenance will be required and will be staggered to provide the least impact
to the operation of the system. The tools include a disk storage solution which is configured to support both online and archive storage. The solutions will support a variety of options to support the growth and scalability of the system and provide software-based hardware and raid system options. A backup solution that supports both UNIX and Windows NT® environments should be included as part of a "turn key" solution. The backups will be of the size and will be automated to provide growth capacity. The backup solutions do not require the system to be interrupted since the online (ie live) backups of the Oracle® database will be an integral part of the backup solution. The data recovery metrics in the event of a failure will match defined operational metrics. Network administration is preferably provided with the industry standard mechanism to provide network management support, i.e., simple network management protocol (SNMP). The Oracle® database supports SNMP and provides the ability to monitor the status of Oracle® services, identify performance bottlenecks, "discover" Oracle® databases, or tools that start at any node
of the system, receive alerts when exceptional events occur (ie, that the database is shrinking), define thresholds and automatic responses to specific events, detect and diagnose potential problems quickly and easily, be notified when certain events occur, and store, report, filter and analyze historical data. It is also possible that the Encina® servers can be used for network management of the automated meter reading server applications 15. The Encina® services provide the ability to: monitor error messages, enable the selective tracing of execution paths, download information about the status of Encina® servers (which includes the automated meter reading server 15), analyze the use of queues, detect hanging transactions, and monitor stops and server starts. The aforementioned Oracle® network management tools, automated meter reading server log, and Encina® will help manage and isolate systems bottlenecks and problem areas. These tools ensure that the entire system remains functional and that no component causes the unscheduled system to stop working. It is noted that the previous examples have been
provided solely for the purpose of explanation and are in no way considered to be limiting of the present invention. Although the invention has been described with reference to preferred embodiments, it is understood that the words that have been used herein are description and illustration words instead of words of limitations. Further, although the invention has been described herein with reference to particular means, materials and embodiments, the invention is not intended to be limited to the particulars described herein; instead, the invention extends to all functionally equivalent structures, methods and uses, such as to be within the scope of the appended claims. Those skilled in the art, having the benefit of the teachings of this specification, may make numerous modifications thereto and changes may be made without departing from the spirit and scope of the invention in its aspects.
Claims (204)
1. An automated meter reading server that collects telemetry data from remote client locations and processes the telemetry data to be used by end users and upstream business systems, including the automated meter reading server: a deposit of data to store the telemetry data; at least one external interface to communicate with external systems to the automated meter reading server; and a multi-layer distributed software architecture comprising: application and infrastructure subsystems, said application and infrastructure subsystems comprise services, distributed throughout the automated meter reading server, which cooperate to carry out predefined business functions; software adapted to the client, the software adapted to the client being provided to facilitate the scalability, the transaction processing, and the mapping of objects to said deposit of data and application structures, facilitating the application structures access to the data warehouse and the creation of processes that comply with the software adapted to the client, where the business functionalities determine processes by which the automated measurement reading server receives data from collection points downstream, processes the telemetry data, and manipulates the data warehouse.
2. The automated meter reading server as claimed in claim 1, wherein the software adapted to the client provides communication facilities for communicating information between the clients of the automated meter reading server and the automated meter reading server, data transport and data conversion facilities; and a mechanism through which clients can locate servers within the distributed architecture.
3. The automated meter reading server as claimed in claim 1, wherein the software adapted to the client provides load balancing and programming to assign the services to application servers based on a priority, and wherein each of the Application servers consists of multiple processing agents and is mul i-strung.
4. The automated meter reading server as claimed in claim 3, wherein a plurality of application servers run simultaneously on multiple physical devices comprising the automated automated meter reading server to distribute the client loads across the multiple physical devices.
5. The automated meter reading server as claimed in claim 1, wherein the automated meter reading server accesses the data warehouse via transactions and transaction processing.
6. The automated meter reading server as claimed in claim 5, wherein the transactions are isolated from each other to prevent other transactions from accessing data that another particular transaction is using until the particular transaction is completed, and where provides a recoverable queue system to queue the transaction job to completion at a later time.
The automated meter reading server as claimed in claim 5, wherein the data warehouse comprises an object-oriented design that resides in a relational database implementation and where the mapping of the relational object is performed by mapping from a tabular relational database to object structures.
8. The automated meter reading server as claimed in claim 1, wherein the data repository comprises a relational database having a temporal structure, wherein the temporal structure comprises timestamp ranges for each table within the relational database to provide different historical views of the data stored in it.
9. The automated meter reading server as claimed in claim 8, where the temporal structure comprises a bitemporal conceptual data model, with the bitemporal conceptual data model providing two independent, orthogonal time periods, which will be associated with each row in a table, these two independent, orthogonal periods of time, they comprise a valid time and a transaction time, where the valid time and the transaction time each comprise a start time and an end time, and where the valid time is a range of time during which a fact is true, and the transaction period is the range of time during which the fact is recorded in the data warehouse.
10. The automated meter reading server as claimed in claim 1, wherein the data warehouse is designed to represent a high-level object model and wherein each high-level object is mapped to the data warehouse.
11. The automated meter reading server as claimed in claim 1, the application structures comprise a data access object structure and a distributed services structure.
12. The automated meter reading server as claimed in claim 11, wherein the structure of distributed services comprises: classes to provide a factory for any object or type of atomic data that has been defined within a mapping directory of class; a pointing to an instance of a specific type of object and a wrap around that instance; a chalkboard to share information used in an existing activity plan; a mechanism that provides a function runtime invocation based on a representation of a function name; and a mechanism that provides encapsulation of a chain of pairs of label values and manipulation and extraction of information from said chain.
13. The automated meter reading server as claimed in claim 11, wherein the distributed service structure hides the detailed implementation of the data warehouse from an application providing representatives of distributed objects, and where the deposit Data is not accessed directly by external applications.
The automated meter reading server as claimed in claim 11, wherein the data access object structure provides representatives, servers, administrators, and back end implementation servers to isolate relationships of the telemetry data in the deposit of data in order to provide access to telemetry data.
15. The automated meter reading server as claimed in claim 1, wherein the infrastructure subsystem supports the application subsystem, the infrastructure subsystem comprising generic and reusable components that are not aware of the application domain of the reading server automated meters, and the application subsystem comprising services that run on a plurality of application servers that have detailed and specific knowledge about the automated meter reading domain.
16. The automated meter reading server as claimed in claim 15, the infrastructure subsystem comprises an activity management subsystem, wherein the business functionalities that are to be performed by said automated meter reading server are extracted in Activity Plans to isolate the business functionalities of the application code comprising the software architecture in order to provide different business functionalities without requiring substantial modification of the application code, where the Activity Plans control the work flow within the automated meter reading server , and where the activity management subsystem invokes and manages Activity Plans.
17. The automated meter reading server as claimed in claim 16, said Plans of Activity comprise at least one task, where a task is a discrete unit of work in the Activity Plan that is controlled by a single server in the system.
18. The automated meter reading server as claimed in claim 17, wherein the task is responsible for processors to overcome failures, the processors to overcome failures are a list of operations that are performed in case of a failure, being the failure determined based on conditions returned after executing an activity.
19. The automated meter reading server as claimed in claim 16, wherein the activity management subsystem urges the Activity Plan, negotiates responses and events for Activity Plans, and monitors the current status of Activity Plans in progress.
20. The automated meter reading server as claimed in claim 16, comprising the activity management subsystem: an Activity Plan builder which is an interface for building an ordered collection of tasks and initializes a message sharing board; a dispatch panel that urges Activity Plans and routes responses from servers within the automated meter reading server to an appropriate Activity Plan where it works within an Activity Plan and sends queued messages to other servers within the server automated meter reading; a dispatcher brain that executes the Activity Plan and handles responses for other servers sent to activate the Activity Plan; a dispatcher storage manager that controls access to persistent Activity Plans; and an Activity Plan monitor that displays the status of any Activity Plan by name, or by selection.
21. The automated meter reading server as claimed in claim 15, the infrastructure subsystem comprises a programmer subsystem, wherein the programmer subsystem handles construction and execution of programs within the automated meter reading server, where the programs are used to control the execution based on the time of work within the automated meter reading server.
22. The automated meter reading server as claimed in claim 21, the programmer subsystem comprising a program manager server and a programmer, wherein the program manager server handles the creation, updating and retrieval of programs to and from the warehouse of data, and the programmer retrieves programs through the program manager server.
23. The automated meter reading server as claimed in claim 21, wherein the scheduler determines a duration of work execution and adjusts the execution durations according to heuristic-tuning parameters.
24. The automated meter reading server as claimed in claim 21, wherein the programmer subsystem comprises a delivery program that notifies a provider when to deliver data to the automated meter reading server, a billing program that determines the Timing of data delivery from the automated meter reading server to the service for billing, and a collection program that determines when Complete data and what type of data to collect.
25. The automated meter reading server as claimed in claim 15, the infrastructure subsystem comprising an alarm subsystem and requests for messages in time, and where an alarm occurs, a call is made back to the alarm subscriber.
26. The automated meter reading server as claimed in claim 15, the infrastructure subsystem comprising a concern management subsystem that provides distributed event management and occupancy mapping for entities within the automated meter reading server, wherein the entities comprise a seller, which is something that can provide notification of an event, or a solicitor, which is something that has an interest or concern in an item that can be provided by a seller.
27. The automated meter reading server as claimed in claim 15, the infrastructure subsystem comprises a mapping subsystem that provides services for the adaptation to the client of file formats to export data from, and import data to, the server of automated reading of meters, the adaptation to the client of the file formats is done according to maps.
28. The automated meter reading server as claimed in claim 27, wherein the mapping subsystem comprises a canonical mapper, the canonical mapper comprising an input map, a canon, and an output map for mapping information from the format of input file to an output file format.
29. The automated meter reading server as claimed in claim 28, wherein the input and output maps are used to map information through subdomains, where there are at least two subdomains under a root subdomain.
30. The automated meter reading server as claimed in claim 28, further comprising a mapping interface server which sends requests to the canonical mapper, where the input and output maps are bypass trees, and where the canonical mapper constructs a syntax scanner / analyzer for an input subdomain, traverses the input map, analyzes the syntax of the input file data in canonical lists, and maps the canonical list to an output subdomain by traversing the map output and reinterpreting the corresponding element of the canonical list to conform the format of new data to create the specific output file.
31. The automated meter reading server as claimed in claim 15, the infrastructure subsystem comprises a record / trace subsystem that generates records for external monitoring purposes that are adapted to support certain standard types of queries, and wherein the system Log / trace is provided to determine a cause of the problems that occur in the automated meter reading server and that can be activated at runtime or any of the individual servers within the automated meter reading server.
32. The automated meter reading server as claimed in claim 15, wherein the application subsystem further comprises a provider subsystem, the provider subsystem adapted to communicate with a provider in accordance with a provider format, and wherein the provider subsystem encapsulates differences in communication formats so that clients of the external interface do not need to know with what type of provider they are communicating.
33. The automated reading meter server as claimed in claim 32, wherein the requests for departures from the providers are carried out through Activity Plans to control the work flow within the automated read server of the meter. meters, and where services triggered from a provider will begin Activity Plans to carry out tasks.
34. The automated meter reading server as claimed in claim 32, the provider subsystem comprises a provider administrator, supplier egress, vendor entry, and reduction control servers, wherein the vendor subsystem routes the requests Meter server from automated meter reading services to an automated meter reading service responsible for connecting to an external system, and manages information delivery and collection programs, and manages communication from the automated reading server of meters to the external system.
35. The automated meter reading server as claimed in claim 34, wherein the provider subsystem directs service requests for entry from communications servers, connected to the automated meter reading server, to activities within the automated meter reading server responsible for meeting the request.
36. The automated meter reading server as claimed in claim 15, wherein the application subsystem comprises a subsystem of access object of data
37. The automated meter reading server as claimed in claim 36, wherein the data access object subsystem contains data access objects that manipulate data within the data warehouse, wherein the data access objects they are representations of tables within the data warehouse.
38. The automated meter reading server as claimed in claim 37, wherein the data access objects are hierarchically related to each other, such that a type of object or collection contains or is contained by another type of object or collection.
39. The automated meter reading server as claimed in claim 36, wherein the data access subsystem uses proxy objects to interact with the application structures, wherein the proxy objects are provided by the application structures to encapsulate relationships and behavior of data.
40. The automated meter reading server as claimed in claim 39, wherein the proxy objects are mapped into data access subsystem objects, wherein, the objects in the data access subsystem are representations of data objects. tables within the data warehouse.
41. The automated meter reading server as claimed in claim 40, wherein the proxy objects are distributed and stored instantly in a memory in the meter reader server.
42. The automated meter reading server as claimed in claim 36, wherein the data access object subsystem comprises a plurality of administrator servers, wherein the administering servers provide meter-related services, fee-related services, services related to groups of meters, loading of the data received and mapped in the data warehouse, recovery of reading samples from the data warehouse of automated reading of meters, determines the skills of a _. instance of a particular component, and provides lists of reference data.
43. The automated meter reading server as claimed in claim 15, wherein the application subsystem comprises an export subsystem.
44. The automated meter reading server as claimed in claim 43, wherein the export subsystem exports data to the external application system by mapping and formatting data from the application systems.
45. The automated meter reading server as claimed in claim 43, wherein the export subsystem comprises an export administrator, a validation, edition, and estimation administrator.
46. The automated meter reading server as claimed in claim 45, wherein the validation, editing and estimation manager performs the validation, editing and estimation of output data to be exported so that the output data They have the characteristics desired by a data requester.
47. The automated meter reading server as claimed in claim 46, wherein the validation, edition, estimation administrator performs validation in accordance with a plurality of regulatory agencies to produce settlement quality data.
48. The automated meter reading server as claimed in claim 45, wherein the validation, editing, estimating administrator uses Activity Plans to control the work flow within the automated meter reading server.
49. The automated meter reading server as claimed in claim 15, wherein the application subsystem comprises a utility interface, the utility interface that communicates with external systems and accepts requests from external systems.
50. The automated meter reading server as claimed in claim 49, which further comprises a graphical user interface that interacts with the service subsystem and provides at least one of the accesses to the automated meter reading server to manually invoke all interfaces of the online business system , look for specific meter / account / rate / event information, provide access to the monitor of the activity management system, and provide an interface to the programs.
51. The automated meter reading server as claimed in claim 50, wherein the graphic user interface uses programming interfaces of standard application system applications provided by the service interface subsystem to initiate requests.
52. The automated meter reading server as claimed in claim 1, wherein at least one external interface includes one of the standards-based application programming interfaces and a file-based interface.
53. The automated meter reading server as claimed in claim 52, wherein the external interface mechanism communicates with a canonical mapper, building the canonical mapper a map specifying the translation required to perform a conversion of a format of input to an output format.
54. The automated meter reading server as claimed in claim 52, wherein the standards-based interface application programming interface requests are used to interact with the automated meter reading server, the interface request requests of the meter. standards-based application programming comprises synchronous and asynchronous requests, where synchronous requests return request outputs directly to a requestor when a request is made, and where the asynchronous requests return the status of a request start from the subsystem of application to a solicitor and, at a later time, provide asynchronous notification to the solicitor with the request outputs.
55. The automated meter reading server as claimed in claim 1, wherein the automated meter reading server is adapted to manage a plurality of dissimilar legacy systems and dissimilar customer-to-client requirements, business functionality logic. , and regulatory requirements.
56. The automated meter reading server as claimed in claim 1, further comprising at least one communication server for communicating the telemetry data on at least one network of communications, and where the automated meter read server is adapted to receive telemetry data via dissimilar communications networks.
57. The automated meter reading server as claimed in claim 56, wherein a plurality of dissimilar meters communicate the telemetry data via the dissimilar communications networks.
58. The automated meter reading server as claimed in claim 56, wherein at least one communication network comprises at least one of a wireless network and a public switched telephone network, and wherein the at least one server of communications establishes communication sessions to read the telemetry data from meters, interprets the meter protocols, converts the data from a meter protocol to a communication server protocol, and sends the telemetry data to the communications server.
59. The automated meter reading server as claimed in claim 58, wherein the communication server supports at least one CDMA, telephone & International DAA, PSTN, PCS, Ardis, x.25 modem, RAM, ReFlex, Amps, CDPD, and TDMA.
60. The automated meter reading server as claimed in claim 56, wherein the automated meter read server is adapted to support an ability to overcome fails at all levels in the case of a failure, and where if an individual process fails, the automated meter reading server changes the failed processes to other processes, and where the communication server fails, the automatic routing to other communication servers is established.
61. The automated meter reading server as claimed in claim 1, wherein the automated meter reader server notifies end users of interrupt alerts, blocking notification, home display of electrical information, meter programming , remote monitoring of energy quality, and customer service diagnostics.
62. The automated meter reading server as claimed in claim 1, wherein the automated meter reading server measures the use of energy, the energy usage being measured at one of kVARh, kVAh, kW, and time of use.
63. A distributed server that receives and processes information for use by end users, the distributed server comprising: a data warehouse to store said information; at least one external interface to communicate with systems external to the distributed server; Y a multi-layer distributed software architecture comprising: application subsystems and infrastructure, said application and infrastructure subsystems comprise services, distributed throughout the distributed server, cooperating to carry out operations within the server; software adapted to the client, the software adapted to the client being provided to facilitate scalability, transaction processing, and object mapping to said data warehouse; and application structures, facilitating the application structures access to the data repository and the creation of processes that comply with the software adapted to the client, where the distributed server receives data from collection points downstream, processes the data, and manipulates the data warehouse to carry out the operations.
64. The distributed server as claimed in claim 63, wherein the software adapted to the client provides load balancing and programming to assign each of the services to an application server based on a priority, and wherein each of the application servers consists of multiple processing agents and It is multi-corded.
65. The distributed server as claimed in claim 64, wherein a plurality of application servers run simultaneously on multiple physical devices comprising the distributed server to distribute the client's loads across the multiple physical devices.
66. The distributed server as claimed in claim 63, wherein the distributed server accesses the data warehouse via transactions and transaction processing.
67. The distributed server as claimed in claim 66, wherein the transactions are isolated from each other to prevent other transactions from accessing the data that a particular transaction is using until the particular transaction is completed, and wherein a transaction is provided. recoverable queue system to queue the transaction job to complete at a later time.
68. The distributed server as claimed in claim 66, wherein the data warehouse comprises an object-oriented design that resides in a relational database implementation and wherein the mapping of the relational object is performed by mapping from a database base to a database. tabular relational data to object structures.
69. The server distributed as claimed in the Claim 63, wherein the data warehouse is designed to represent a high-level object model and wherein each high-level object is mapped to the data warehouse.
70. The server distributed as claimed in claim 63, the application structures comprise a data access object structure and a distributed services structure.
71. The distributed server as claimed in claim 70, wherein the distributed service structure hides the detailed implementation of the data warehouse from an application providing representatives of distributed objects, and where the data warehouse is not directly accessed. through external applications.
72. The distributed server as claimed in claim 70, wherein the data access object structure provides representatives, servers, administrators, and back end implementation servers to isolate relationships of the information in the data warehouse with the order to provide access to information.
73. The distributed server as claimed in claim 63, wherein the infrastructure subsystem supports the application subsystem, the infrastructure subsystem comprising generic and reusable components that have no knowledge of the application domain of the distributed server, and where the subsystem Application includes services that run on application servers that have detailed and specific knowledge about the distributed domain.
74. The distributed server as claimed in claim 73, the infrastructure subsystem comprises an activity management subsystem, wherein the operations are extracted in Activity Plans to be performed by the distributed server to isolate the operations of the application code which comprises the software architecture to provide dissimilar operations that are to be performed without requiring substantial modification of the application code, wherein the Activity Plans control the workflow control within the distributed server, wherein the activity management subsystem invokes and manages the Activity Plans.
75. The distributed server as claimed in claim 74, the Activity Plans comprise at least one task, and wherein a task is a discrete unit of work in the Activity Plan that is controlled by a single server in the distributed server .
76. The distributed server as claimed in claim 75, wherein the tasks are responsible for processors that overcome failures, being the processors that overcome failures a list of operations to be performed in the case of failure, the failure being determined based on conditions returned after executing an activity.
77. The distributed server as claimed in claim 74, wherein the activity management subsystem urges the Activity Plan, negotiates responses and events for Activity Plans, and monitors the current status of the Activity Plans in progress.
78. The server distributed as claimed in claim 73, the infrastructure subsystem comprises a programmer subsystem, wherein the programmer subsystem manages the construction and execution of programs within the distributed server where programs are used to control execution based on work time within the distributed server.
79. The distributed server as claimed in claim 78, wherein the programmer subsystem determines the duration of execution of a task and adjusts the execution durations according to heuristic-tuning parameters.
80. The distributed server as claimed in claim 73, the infrastructure subsystem comprises an alarm subsystem that receives requests for timed messages, and where when an alarm occurs, a call is made to the subscriber of the alarm.
81. The server distributed as claimed in the claim 73, the infrastructure subsystem, which comprises a concern management subsystem, provides distributed event management and an interest mapping for entities within the distributed server, wherein the entities comprise vendors, which are something that can provide notification of a event, solicitor, which is something that has an interest or concern in an item that can be provided by a seller.
82. The distributed server as claimed in claim 73, the infrastructure subsystem comprising a mapping subsystem which provides services for the adaptation to the client of file formats for exporting data from, and importing data to, distributed servers, being made the adaptation to the client according to the maps.
83. The distributed server as claimed in claim 82, wherein the mapping subsystem comprises a canonical mapper, the canonical mapper comprising an input map, a canon, an output map, to map information from a format of input file to an output file format.
84. The distributed server as claimed in claim 83, wherein the input and output maps are used to map information through subdomains, where there are at least two subdomains under the same domain root.
85. The distributed server as claimed in claim 73, the infrastructure subsystem comprises a record / trace subsystem that generates records for external monitoring purposes that are adapted to support certain standard types of queries, and wherein the registration system / trace is provided to determine a cause of the problems that occur in the distributed server and can be activated at runtime or by any of the individual servers within the distributed server.
86. The distributed server as claimed in claim 73, wherein the application subsystem further comprises a subsystem provider, the provider subsystem adapted to communicate with a provider according to a provider format and wherein the provider subsystem encapsulates differences in a format so that the clients of the interface do not need to know what type of provider they are interacting with.
87. The distributed server as claimed in claim 86, wherein the requests for departures to suppliers are carried out through Activity Plans that control the work flow within the distributed server, and where the services fired from the provider will begin the Activity Plans to carry out tasks.
88. The server distributed as claimed in the claim 86, wherein the provider subsystem directs incoming service requests from communication servers, connected to the distributed server to activities within the distributed server responsible for serving the request.
89. The distributed server as claimed in claim 73, wherein the application subsystem comprises a data access object subsystem.
90. The distributed server as claimed in claim 89, wherein the data access object subsystem contains data access objects for manipulating data within the data warehouse, wherein the data access objects are representations of tables inside the data warehouse.
91. The distributed server as claimed in claim 90, wherein the data access objects have a hierarchical relationship with each other, such that a type of object or collection contains or is contained in another type of object or collection.
92. The distributed server as claimed in claim 89, wherein the data access subsystem uses proxy objects to interact with the application structures, wherein the proxy objects are provided by the application structures to encapsulate relationships and behavior of data.
93. The distributed server as claimed in claim 92, wherein the proxy objects are mapped to objects in the data access subsystem, wherein, the objects in the data access subsystem are representations of table objects within the data warehouse. data
94. The distributed server as claimed in claim 93, wherein the representative objects are distributed and stored instantly in a memory in the meter reader server.
95. The distributed server as claimed in claim 74, wherein the application subsystem comprises an export system that exports data to external application systems by mapping and formatting data from the application systems.
96. The distributed server as claimed in claim 95, wherein the export subsystem comprises an export administrator and a validation, edition, and estimation administrator, wherein the validation, edition, estimate administrator performs validation, editing and estimation of the data to be exported so that the output data have characteristics desired by a requestor of the output data.
97. The server distributed as claimed in the Claim 96, where the administrator of validation, editing, estimation uses Activity Plans to control the work flow within the distributed server.
98. The distributed server as claimed in claim 73, wherein the application subsystem comprises a service interface, the service interface communicating with external systems and accepting requests from external systems.
99. The distributed server as claimed in claim 98, further comprising a graphical user interface that interacts with the service subsystem and provides at least one of the accesses to the distributed server to manually invoke all interfaces of the business system in line, look for meter / account / rate / event specific information, provide access to the activity management system monitor, and provide an interface to the programs.
100. The distributed server as claimed in claim 99, wherein the graphic user interface uses application programming interfaces of standard application systems provided by the service interface subsystem to initiate requests.
101. The distributed server as claimed in claim 63, wherein the at least one external interface includes one of the programming interface of standards-based application and file-based interface.
102. The distributed server as claimed in claim 101, wherein the external interface mechanism communicates with a canonical mapper, the canonical mapper constructing a map specifying the translation required to perform a conversion of an input format to a format of exit.
103. The distributed server as claimed in claim 101, wherein the standards-based interface application programming interface requests are used to interact with the distributed server, the standards-based application programming interface requests comprise requests synchronous and asynchronous, where synchronous requests return requests outputs directly to a requestor when the request is made, and where the asynchronous requests return the state of application initiation from the application subsystem to the requestor and, at a later time , provide asynchronous notification to the requestor with the request outputs.
104. The distributed server as claimed in claim 63, further comprising at least one communication server that communicates the information of at least one communications network, and where the distributed server is adapted to receive information from dissimilar communications networks.
105. A server that resides within a multi-layer distributed software architecture comprising the server: a data warehouse for storing data received by the server; at least one external interface to communicate with the external systems of the server; a server subsystem that includes distributed servers, distributed servers running on application servers within the distributed architecture; software adapted to the client, provided to facilitate scalability, transaction processing, and object mapping to the data warehouse, - and application structures, which facilitate access to the data warehouse and the creation of processes that comply with the software adapted to the client , where the server-based procedures are administered according to predetermined activities.
106. The server as claimed in claim 105, wherein the application servers are run simultaneously on multiple physical devices for distribute client loads across multiple physical devices.
107. The server as claimed in claim 105, where the server accesses the data warehouse via transactions and transaction processing.
108. The server as claimed in claim 107, wherein the transactions are isolated from each other to prevent transactions from accessing data that a particular transaction is using until the particular transaction is complete, and where a system is provided. queue formation training to queue the transaction work that is to be completed at a later time.
109. The server as claimed in claim 105, the application structures comprise data access object structures and distributed service structure.
110. The server as claimed in claim 109, wherein the structure of distributed services hides the detailed implementation of the data warehouse from an application providing representatives of distributed objects, and where the data warehouse is not directly accessed by external applications.
111. The server as claimed in claim 109, wherein the data access object structure provides representatives, administrators servers, and back end deployment servers to isolate the data relationships within the data warehouse in order to provide access to the data.
112. The server as claimed in claim 105, the service subsystem comprising an activity management subsystem, wherein the predetermined activities comprise Activity Plans that are to be performed by the server which isolates the predetermined activities from the security code. application that includes the subsystem of services to provide dissimilar activities that are going to be carried out without requiring substantial modifications of the application code, where the Activity Plans control the workflow control inside the server, where the activity management subsystem invokes and manages the Activity Plans.
113. The server as claimed in claim 112, wherein the Activity Plans comprise at least one task, and wherein a task is a discrete unit of work in the Activity Plan that is controlled by a single server.
114. The server as claimed in claim 105, the service subsystem comprises a mapping subsystem that provides services for the adaptation to the client of file formats to export data from and import data to the server. \
115. The server as claimed in the claim 114, wherein the mapping subsystem comprises a canonical mapper, the canonical mapper comprising an input map, a canon, an output map for mapping information from an input file format to an output file format.
116. The server as claimed in the claim 115, where the input and output maps are used to map information through subdomains, where there are at least two subdomains under the same root domain.
117. The server as claimed in claim 105, wherein the service subsystem further comprises a subsystem provider, the subsystem provider, adapted to communicate with a provider according to a provider format, and wherein the provider subsystem encapsulates differences in formats so that the clients of the interface do not need to know what type of provider they are interacting with.
118. The server as claimed in the claim 117, where requests to exit suppliers are carried out through Activity Plans that control the work flow within the server, and where the services triggered by a provider will start work plans to carry out tasks.
119. The server as claimed in claim 105, wherein the service subsystem comprises an export subsystem that exports data to external application systems by mapping and formatting data from the service subsystems.
120. The server as claimed in the claim 119, where the export subsystem includes a validation, edition and estimation manager, where the validation, edition, estimate administrator performs the validation, edition, and estimation of whether the data to be exported has the characteristics desired by a requestor of the output data.
121. The server as claimed in the claim 120, where the administrator of validation, editing, estimation uses Activity Plans to control the work flow within the server.
122. The server as claimed in the claim 105, wherein the server comprises an automated meter reading server.
123. In a computer system, a canonical mapper to translate an input file from an input domain to an output domain, comprising the canonical mapper: a canon service that builds a canon, the canon being a tree that relate all the attributes of data within an information domain, and the domain being a collection of data that has the same data format, - a map service that creates input and output maps that specify the translation from the input domain to the output domain, with the input map being data structure that describes a format of the input domain, and the output map being a data structure that describes an output domain format, - and a translator service that performs the translation of the input file into the output file according to with the canon and helps the input and output maps, where the input domain and the output domain have different formats.
124. The canonical mapper as claimed in claim 123, wherein the canonical mapper converts the files onto at least two mapped subdomains, the at least two subdomains mapped to the same root domain.
125. The canonical mapper as claimed in claim 123, wherein the input map and the output map are bypass trees, and the canonical mapper uses the input map and the output map to build a scanner / analyzer of syntax for the input file domain.
126. The canonical mapper as claimed in the claim 125, wherein the canonical mapper traverses the input map to analyze syntactically data from the input file in the canonical list.
127. The canonical mapper as claimed in claim 126, wherein the canonical mapper maps from the canonical list to the output domain to generate the output file by traversing the output map and reinterpreting a corresponding element in the canonical list so that the corresponding element forms the output domain.
128. The canonical mapper as claimed in claim 123, wherein the canon comprises an abstract template that describes a structure of the information domain, the canon being structured as a tree comprising canonical elements that are used to interpret data contained within the input file.
129. The canonical mapper as claimed in claim 128, wherein each canonical element is an abstraction, and the canonical elements nested under the higher-level canonical elements are subsequently defined in terms of less abstract elements until they resolve a particular element .
130. The canonical mapper as claimed in claim 129, wherein there are relations where the domain contains data that is independent of other data in the domain.
131. The canonical mapper as claimed in claim 128, wherein the canonical elements are assigned attributes that define qualities of the canonical elements.
132. The canonical mapper as claimed in claim 128, wherein the input map and the output map are created according to the canon, and wherein the input map and the output map describe the output designated in terms of the canonical elements.
133. The canonical mapper as claimed in claim 132, wherein the input map defines a function of each component of the input file in terms of the canon, and the output map defines a function of each component of the output file in terms of the canon.
134. The canonical mapper as claimed in claim 133, wherein the input and output maps also comprise attributes that define the canonical elements, tokens that represent values, and actions that define the format of the canonical elements.
135. The canonical mapper as claimed in claim 134, wherein the attributes comprise types of elements and modifiers, wherein the element types include group elements that are canonical elements having nested canonical elements and result elements that they contain a specific value, and where the modifiers are associated with the group elements and are conditional statements about the group element.
136. The canonical mapper as claimed in claim 135, wherein the conditional statements comprise optional, repeating, and mandatory group results.
137. The canonical mapper as claimed in claim 135, wherein the tokens are defined for the result elements and represent the specific value based on the input file.
138. The canonical mapper as claimed in claim 123, further comprising an interactive translator service to test the actual translation of the input file to be mapped for the translation process, performing the test in accordance with the canon, the input map, the output map, and the input file.
139. The canonical mapper as claimed in claim 123, wherein the translator service is executed in a headless mode.
140. A method for mapping an input file having an input domain to an output file having an output domain using a canonical mapper, the canonical mapper comprising a royalty service, a map service and a translator service, where a domain is a collection of data that have the same format, including the method: create a canon using the canon service, comprising the canon canonical elements; create input and output maps using the map service according to the canon to perform the conversion of the input file to the output file, - and map the input map information to the output map to create the output file using the translator service.
141. The method as claimed in claim 140, wherein creating a canon comprises.- defining the canonical elements so that the canonical elements have a hierarchical structure, the hierarchical structure having a root and children nested under the root; define the children of the root, defining the children specific information about the root; and define relationships of the canonical elements.
142. The method as claimed in the claim 140, where the creation of input and output maps comprises: selecting each component of the input file and defining its function in terms of the canon; define attributes about the canonical elements, - define tabs, specifying the tabs a format of the results of mapping the input file using the input and output maps, - and define actions to structure the appearance of portions in the input file or the output file.
143. The method as claimed in claim 142, wherein the definition attributes on the canonical elements comprise: defining modifiers for the canonical elements, determining the modifiers if a value of a particular canonical element is required, if the value appears more at once, and if the canonical element includes a series of said values, or if the canonical element is required, - and define identifiers, the identifiers being constant values within the input file.
144. The method as claimed in claim 140, wherein mapping the input map information into the output map to create the output file further comprises testing the conversion.
145. On a server that resides within a distributed multilayer software architecture that receives and processes data, the server comprises a data warehouse to store the data, at least one external interface to communicate with systems external to the server, a service subsystem comprising distributed services, distributed services running on application servers within the distributed architecture, software adapted to the client to facilitate scalability, transaction processing, and object mapping to the data warehouse, and application structures to facilitate access to the data warehouse and the creation of processes that comply with the software adapted to the client, a canonical mapping server that includes: a canon service that builds a canon, the canon being a tree that relates all the data attributes within an information domain, and the domain being a collection of data that has the same data format; a map service that creates input and output maps that specify the translation of the input domain to the output domain, the input map being a data structure that describes a format of the input domain, and the output map being a structure of data describing an output domain format; and a translator service that performs the translation of the input file to the output file, where the input domain and the output domain have different formats.
146. The server as claimed in claim 145, wherein the canonical mapping server resides in a mapping subsystem that provides the adaptation to the client of file formats to export data from and import data to the server.
147. The server as claimed in claim 146, further comprising a mapping interface server that connects to the canonical mapper, wherein the mapping interface server provides service requests adapted to the client from the subsystem's services.
148. The server as claimed in claim 147, wherein the mapping interface server is connected to the canonical mapping server using a socket connection, and wherein the mapping interface server provides a service that allows a service in the subsystem of services to specify the input file, the input map, the output file, and the output map.
149. The server as claimed in claim 145, wherein the input map and the output map are created according to the canon.
150. A distributed server that resides within a multilayer software architecture, comprising the distributed server: a service subsystem that comprises distributed services, with distributed services running on application servers within the distributed architecture; software adapted to the client, the software being adapted to the client provided to facilitate the scalability and transaction processing; and application structures, said application structures facilitate the creation of processes that comply with the software adapted to the client, where the service subsystem is implemented as a set of cooperation services from low to medium level that are grouped and put into series to perform certain functions, and where the predetermined functions are operations that are to be performed by the distributed server, and are extracted in Activity Plans that control the workflow within the distributed server, and where the Activity Plans isolate the predetermined functions of the application code comprising software architecture in order to provide that the ability of the server to perform various functions may be without requiring substantial modification of the application code.
151. The distributed server as claimed in claim 150, the service subsystem comprising an activity plan management subsystem, wherein the activity management subsystem invokes and manages the Activity Plans.
152. The distributed server as claimed in claim 151, wherein the activity management subsystem urges the Activity Plan, negotiates responses and events for Activity Plans, and monitors the current status of the Activity Plans in progress.
153. The distributed server as claimed in claim 152, the Activity Plans comprising at least one task, wherein a task is a discrete unit of work in an Activity Plan that is controlled by a single server in the distributed server.
154. The server as claimed in claim 153, wherein the tasks invoke a particular service within the service subsystem to process information, wherein the Activity Plan is a decision tree of the tasks that define which tasks are dependent on others, and contain contextual information carried for the workflow and available for each task.
155. The distributed server as claimed in claim 154, wherein the Activity Plan controls the execution within the distributed server via a directed graph that encapsulates the various functions of the application code.
156. The distributed server as claimed in claim 155, wherein the tasks perform at least one of determining which tasks can be executed in parallel or Run serially, manage a data exchange object to exchange information between tasks, manage task statuses that track which tasks are in progress, determine which task to do next based on the status of the Activity Plan and a set of rules of the graph directed , record tasks to record task results as they are completed, preconditioning processing that determines if the task can be executed based on the availability of required inputs, and fault-solving processors that are a list of operations to perform in the event of failure based on conditions of return from the execution of an activity.
157. The distributed server as claimed in claim 156, wherein the data exchange object comprises predefined slots that are used to communicate information between various tasks, wherein each task retrieves predetermined slot entries, and places outputs in other slots in the data exchange object.
158. The distributed server as claimed in claim 150, wherein the Activity Plans are enrolled outside of an application code environment and are adapted to be modified to adapt to the distributed server from a particular set of end-user requirements.
159. The server distributed as claimed in the Claim 153, the activity management subsystem comprises: an Activity Plan builder that is an interface to construct an ordered collection of tasks and initializes a data exchange object to share information; a dispatcher panel that installs Activity Plans and routes responses from servers within the distributed server to an appropriate Activity Plan where it works within an Activity Plan and sends queued messages to other servers within the distributed server; a dispatcher brain that executes the Activity Plan and handles responses for other servers sent to activate the Activity Plan; a dispatcher storage administrator that controls access to Activity Plans; and an Activity Plan monitor that displays the status of any Activity Plan.
160. The distributed server as claimed in claim 159, the Activity Plan builder comprising a development tool having a graphical user interface, a controller, domain objects capable of being persistently stored and used by the dispatcher, where the Activity Plan builder provides a mechanism to build, store and edit tasks in a dictionary for insertion in Activity Plans.
161. The distributed server as claimed in claim 159, wherein the dispatcher panel urges the Activity Plan and initiates processing within the distributed server, and where the dispatcher panel has an application programming interface that is used by the applicants to start the Activity Plans and receive results of completed Activity Plans.
162. The distributed server as claimed in claim 159, wherein the Activity Plans receive priority in activation based on dynamically set priorities, and wherein the Activity Plans are passivated when the dependencies prohibit the execution of a next task, and it can be reactivated by the dispatcher brain when a dependent task is finished.
163. The distributed server as claimed in claim 159, wherein the dispatcher storage manager controls access to the Activity Plans, and where the dispatcher storage manager cooperates with the dispatcher brain, and the Activity Plan monitors for avoid collisions when accessing Activity Plans.
164. The distributed server as claimed in claim 150, further comprising at least one external interface for communicating with the external system of the distributed server.
165. The distributed server as claimed in claim 164, the service subsystem comprises a subsystem provider that is adapted to communicate with a provider via at least one external interface to a provider, where outgoing requests to providers are carried out through the Activity Plans, and where the services triggered from a provider will begin activity plans to carry out tasks.
166. The distributed server as claimed in claim 165, wherein at least one of the external interfaces is communicated in accordance with a provider's format, and wherein the provider subsystem encapsulates differences in communication formats so that the clients of the external interface within the distributed server do not need to know what type of provider they are communicating with.
167. The distributed server as claimed in claim 164, the service subsystem comprises an export subsystem for exporting data to external export systems by mapping and formatting data from the service subsystems, where the data is exported to systems of external applications through the Plans of Activity.
168. The server distributed as claimed in claim 167, where the export subsystem comprises a validation system.
169. The distributed server as claimed in claim 167, wherein the validation system performs validation and editing of data to be exported so that the output data has the characteristics desired by the requestor of the output data.
170. The server distributed as claimed in claim 150, the service subsystem comprises a programmer subsystem, which manages the construction and execution of programs within the distributed server, where programs are used to control execution and activation based on the time of the Activity Plans within the distributed server.
171. The distributed server as claimed in claim 170, wherein the programs control the delivery and receipt of external provider data to the distributed server.
172. The distributed server as claimed in claim 170, the service subsystem comprises an Activity Plan management subsystem, wherein the activity management subsystem invokes and manages the Activity Plans, and wherein the administration subsystem from activity urges the Activity Plan, negotiates responses and events for Activity Plans, and monitors the current status of all Activity Plans in progress.
173. The distributed server as claimed in claim 172, the Activity Plans comprise at least one task, wherein a task is a discrete unit of work in an Activity Plan that is controlled by a single server in a distributed server.
174. The distributed server as claimed in claim 173, wherein the tasks invoke a service within the service system to process information, wherein the Activity Plan is a decision tree of the tasks defining tasks where the tasks they are dependent on the others, and contain contextual information taken from the workflow and available for each task.
175. The distributed server as claimed in claim 174, wherein the Activity Plan controls the execution within the distributed server via a directed graph that encapsulates the different functions of the application code.
176. In a computer system comprising a multi-layer distributed software architecture that receives and processes data, an activity management server comprising: an Activity Plan consultant that is a interface to build an ordered collection of tasks and initialize a data exchange object to share information between tasks; a dispatcher panel that urges Activity Plans and routes server responses within the computer system to an appropriate Activity Plan where tasks within an Activity Plan and sends queued messages to other servers within the computer system; a dispatcher brain that executes Activity Plans and handles responses from other servers sent to activate the Activity Plans; a dispatcher warehouse manager that controls access to Activity Plans; and an Activity Plan monitor that displays the status of any Activity Plan, where the predetermined functions to be performed by the distributed server are extracted in Activity Plans to control the work flow within the computer system, where Activity Plans isolate the predetermined functions of the application code comprising software architecture in order to provide that the ability of the computer system to perform various functions may be without requiring substantial modification of the application code, and where a task is a discrete unit of work in an Activity Plan that is controlled by a single server in a computer system.
177. The computer system as claimed in claim 176, comprising the plan builder of Activity a development tool that has a graphical user interface, a controller, and domain objects capable of being persistently stored and used by the dispatcher, where the Activity Plan builder provides a mechanism to build, store and edit tasks in a dictionary for insertion in Activity Plans.
178. The computer system as claimed in claim 176, wherein the dispatcher panel urges the Activity Plan and initiates processing within the computer system, and wherein the dispatcher panel has an application programming interface that is used by the requestors to start the Activity Plans and receive results of the completed Activity Plans.
179. The computer system as claimed in claim 176, wherein the activity plans receive priority in activation based on dynamically established priorities, and where the activity plans are passivated when the dependencies prohibit the execution of a next one. task, and can be reactivated by the dispatcher brain when a dependent task ends.
180. The computer system as claimed in claim 176, where the dispatcher storage manager controls access to the activity plans, and where the dispatcher storage manager cooperates with the dispatcher brain, and the activity plan monitor to avoid collisions when accessing the plans of activity.
181. On a distributed distributed server within a distributed multilayer software architecture that receives and processes data, the distributed server comprises a data warehouse for storing the data, and at least one external interface for communicating with external systems of the distributed server , a subsystem of services that includes distributed services, distributed services are executed in application servers within the distributed architecture, software adapted to the client to facilitate scalability, transaction processing, and object mapping to the data warehouse, and application structures to facilitate access to the data warehouse and the creation of processes that comply with the software adapted to the client, an activity management server that includes: an activity plan builder which is an interface to build an ordered collection of tasks and initializes a data exchange object to share information; a dispatcher panel which urges activity plans and routes server responses within the distributed server to an appropriate activity plan where it works within an activity plan and sends queued messages to other servers within the distributed server; a dispatcher brain that executes activity plans and handles responses from other servers sent to activate the activity plan; a dispatcher brain that executes activity plans and handles responses from other servers sent to activate the activity plan; a dispatcher storage administrator that controls access to activity plans; and an activity plan monitor that displays the status of any activity plan, where the predetermined functions that are to be performed by the distributed server are extracted into activity plans that control the workflow within the computer system, in where the activity plans isolate the predetermined functions of the application code comprising the software architecture in order to provide the capacity of the computer system for perform various functions can be without requiring substantial modification of the application code, and where a task is a discrete unit of work in an activity plan that is controlled by a single server in the computer system.
182. The distributed server as claimed in claim 181, the subsystem of services comprising a programmer subsystem, which handles the construction and execution of programs within the distributed server, wherein the programs are used to control execution and activation based on the time of activity plans within the distributed server.
183. The distributed server as claimed in claim 182, wherein the programs control the delivery and reception of data from external providers of the distributed server.
184. The distributed server as claimed in claim 181, further comprising at least one external interface for communicating with external systems of the distributed server.
185. The distributed server as claimed in claim 184, the service subsystem comprising a subsystem provider that is adapted to communicate with a provider via the at least one external interface to a provider, wherein the requests withdrawn to the providers they are carried out through the activity plans, and where the services triggered by a provider begin the activity plans to carry out tasks.
186. The distributed server as claimed in claim 185, wherein the at least one external interface is communicated in accordance with a provider format, and wherein the provider subsystem encapsulates differences in communication formats so that the clients of the external interface within the distributed server does not need to know with what type of provider they are communicating.
187. The distributed server as claimed in claim 184, the service subsystem comprising an export subsystem for exporting data to external application systems by mapping and formatting data from the service subsystems, where the data is exported to application systems externalities through the activity plans.
188. The distributed server as claimed in claim 187, wherein the export subsystem comprises a validation system.
189. The distributed server as claimed in claim 187, wherein the validation system performs validation and editing of data to be exported so that the output data has the characteristics desired by a requestor of the output data.
190. A client for use with a distributed server comprising a multi-layer software architecture and external interface mechanisms that communicate information between the client and the distributed server, comprising the software architecture adapted to the client to access services within the server , the client comprising: a user interface; a communications gate adapted to the client to provide communication between the client and the software adapted to the client; and a gateway server for data conversion, wherein the client user interface interacts with the external interface mechanisms and provides access to the server to invoke services provided by the server.
191. The customer as claimed in the claim 190, wherein the application programming interfaces of standard application systems provided by the external interface mechanisms are used to initiate requests.
192. The customer as claimed in the claim 191, where the client performs all communication using a software communications gate adapted to the client, wherein the software communications door adapted to the client is provided to allow the client to make remote procedure calls to said subsystems.
193. The client as claimed in claim 192, wherein the gateway server is provided as a translator between the client and the server.
194. The client as claimed in claim 190, wherein it further comprises a notification server, wherein the notification server is provided as a queue that allows clients that can not handle incoming remote procedure calls to process asynchronous notifications .
195. The client as claimed in claim 194, wherein the notification server assigns a unique client identification to each client and each client labels requests to the client with the customer identification and where the client calls the notification server when the requests are complete.
196. The client as claimed in claim 190, wherein the client is developed in Java to provide platform independence and the ability to remotely execute as an applet of standard Internet browsers.
197. On a distributed server that resides within a multi-layer distributed software architecture that receives and processes data, the distributed server that comprises a data warehouse to store the data, at least an external interface to communicate with external systems of the distributed server, a subsystem of services that comprises distributed services, the distributed services are executed in servers of application with the distributed architecture, software adapted to the client to facilitate scalability, transaction processing, and object mapping to the data warehouse, and application structures to facilitate access to the data warehouse and the creation of processes that comply with the software adapted to the client, a client that runs in cooperation with the distributed server comprising: a client user interface; a software communications gate adapted to the client to provide communication between the client and the software adapted to the client; and a gateway server for data conversion, wherein the client user interface interacts with the external interface mechanisms and provides access to the server to invoke services provided by the server.
198. The customer as claimed in the claim 197, where the application programming interface of the standard application system provided by said External interface mechanisms are used to initiate requests.
199. The customer as claimed in the claim 198, wherein the client is implemented, performs all communications using the software communications door adapted to the client, where the software communications door adapted to the client is provided to allow the customer to make remote procedure calls within the subsystems
200. The customer as claimed in the claim 199, wherein the gateway server is provided as a translator between the client and the server.
201. The customer as claimed in the claim 197, further comprises a notifications server, wherein the notifications server is provided as a queue that allows clients who can not handle incoming remote procedure calls to process asynchronous notifications.
202. The client as claimed in claim 201, wherein the notification server assigns a unique customer identification to each client and each customer labels the requests to said client with that customer identification and where the client calls the client server. notifications when the requests are complete.
203. The customer as claimed in the claim 197, where the client is developed in Java to provide platform independence and the ability to remotely execute as an applet from standard Internet browsers.
204. A client for use with a server having a distributed multilayer software architecture, the distributed software architecture comprising multiple layers of software adapted to the client to provide data exchange between the application services and a server operating system, the client comprising: a user interface of the client, - a software communications gate adapted to the client to provide communication between the client and the software adapted to the client, - and a gate server to perform the data conversion, where the The client user interface interacts with external interface mechanisms and provides access to the server to invoke services provided by the server.
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US60/058,659 | 1997-09-11 | ||
| US09/082,647 | 1998-05-21 | ||
| US09/082,568 | 1998-05-21 | ||
| US09/082,811 | 1998-05-21 | ||
| US09/082,758 | 1998-05-21 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| MXPA00002496A true MXPA00002496A (en) | 2001-03-05 |
Family
ID=
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6199068B1 (en) | Mapping interface for a distributed server to translate between dissimilar file formats | |
| US6088659A (en) | Automated meter reading system | |
| CA2303064C (en) | Automated meter reading system | |
| US7467198B2 (en) | Architectures for netcentric computing systems | |
| US6701345B1 (en) | Providing a notification when a plurality of users are altering similar data in a health care solution environment | |
| US7403901B1 (en) | Error and load summary reporting in a health care solution environment | |
| US7003560B1 (en) | Data warehouse computing system | |
| CA2388624C (en) | Architectures for netcentric computing systems | |
| CN105739987A (en) | SOA-oriented rapid JavaWeb application construction system framework | |
| US20010052108A1 (en) | System, method and article of manufacturing for a development architecture framework | |
| Alonso et al. | Workflow management: the next generation of distributed processing tools | |
| US20080052253A1 (en) | System and method for message-bus-based advanced meter information system | |
| Brondum et al. | Visualising architectural dependencies | |
| Johnson | Enterprise software system integration: An architectural perspective | |
| EP1250669A1 (en) | Data warehouse computing system | |
| CN114548833A (en) | Integrated intelligent operation and maintenance control method, system and operation and maintenance platform | |
| Nobrega et al. | LHCb computing technical design report | |
| US20050187888A1 (en) | Method for associating information pertaining to a meter data acquisition system | |
| CA2406421C (en) | Method for a health care solution framework | |
| Wolf | Succeedings of the second international software architecture workshop (isaw-2) | |
| MXPA00002496A (en) | Automated meter reading system | |
| AU2001253522A1 (en) | Method for a health care solution framework | |
| Denaro et al. | Performance testing of distributed component architectures | |
| CN111061789A (en) | Smart power grids capital construction information management system | |
| WO1997042589A1 (en) | Integration management template method and system |