MXPA01005211A - Field upgradeable dynamic data exchange server - Google Patents

Abstract

A dynamic data exchange (DDE) server (100) which allows external programs to access power management data is presented. The DDE server (100) provides a mnemonic cross reference between register items and standardized, alphanumeric parameter names. This mnemonic interface allows the user to retrieve data from a device without knowledge of the actual device register item number. The DDE server (100) is optimized for either the Modbus RTU or Ethernet protocol. The DDE server (100) acts as a link between a client requesting device data and a field device which can provide the data. The DDE server (100) communicates to the field device through communication ports and to the client via DDE or NetDDE message link. A client sends its requests to server to read/write some device register. The server maps each request to suitable device read/write request packets and carries out the necessary transaction with device. Then it relays the result back to the client after processing and casting the collected device data to proper format. To configure the DDE server (100), the user can export and import files containing register groups and mnemonics in comma separated value format. By importing and exporting register groups and mnemonics, the user can change the firmware revision register map or mnemonics of a device class supported by the DDE server (100), change the number or types of registers or mnemonics, or add a new generic device type.

Description

DYNAMIC DATA EXCHANGE SERVER FIELD IMPROVERS RELATED REQUESTS The present is a continuation in part of the patent application of E.U.A. No. 08 / 628,533 filed April 3, 1996, which is incorporated herein by reference.

BACKGROUND OF THE INVENTION The invention relates generally to a dynamic data exchange server for use in a power management control system and, in particular, to a dynamic data exchange server field enhancer. In current energy management control systems, a variety of energy control or verification devices are connected to a common bus, which allows power verification or control devices to communicate with a server. A standard protocol used for communication between the server and the control and energy verification devices is the Modbus RTU standard. Another protocol, Dynamic Data Exchange (DDE), independently allows developed programs to share data and instructions with each other. Using these protocols, the system server can allow external programs to access power management data. There are many Modbus RTU / DDE servers (DDE servers) commercially available for a wide variety of applications. All major electric distribution companies have a similar product. The narrow reach of these servers is their main imitation. These systems expect client applications (human-machine interfaces) to handle the complexities of current energy measurement and control devices. Many of the servers are designed to communicate using a protocol to design only certain devices, family of devices or specially designed devices. Also, not all servers are capable of supporting any generic Modbus RTU device.

An improved DDE server is described in the US patent. No. 5,764,155 entitled "Dynamic Data Exchange Server" (the '155' patent). The DDE server described in that patent provides a mnemonic cross reference between registration items and standardized alphanumeric parameter names. This mnemonic interface allows the user to retrieve data from a device without knowing the actual device registration device article number. The DDE server acts as a link between a client requesting device data and a field device which can provide the data. The DDE server communicates with the field device through communication ports and with the client through a DDE server or NetDDE message link (NetDDE is a DDE extension allowing programs running on different computers to share the data ). A client sends its requests to the server to read / write some device records. The server maps each request for read / write request packets from suitable devices and performs the necessary transaction with the device. It then retransmits the result back to the client after processing and disseminating the collected device data to the appropriate format. The DDE server in the '155 patent is a drastic improvement over those previously known in the art. However, the DDE server of the '155 patent and the DDE servers of the prior art are programmed to serve for a particular release of the wired microprogramming of the final device (firmware). In this way, when the wired microprogramming of the final device is improved, a new release of DDE server software may be required. In addition, in order to support a new type of generic device, the registration map and the mnemonics may have to be manually entered into the DDE server software. The programming required to improve the wired microprogramming or to configure a new generic device results in both time and money costs, and a modification to the wired microprogramming of the DDE server increases the danger of introducing new software errors.

COMPENDIUM OF THE INVENTION A DDE server field enhancer can be configured without modifying the DDE server software. In an illustrative embodiment of the invention, the DDE server is configured by importing a file containing registration group data for a group of records into a plurality of energy control or verification records. The registration group data includes addresses for the group of records and a group name. A record map for the record group is created using the addresses, and the record map is associated with the group name. In an alternative mode, the DDE server is configured by importing a file including a mnemonic and an address for a record in a power verification and control device. A registration map for the record is created using the address and the mnemonic is associated with the registration map.

BRIEF DESCRIPTION OF THE DRAWINGS Referring now to the drawings, in which like elements are similarly enumerated, in the various Figures: Figure 1 is a block diagram of an energy management and control system according to a Modbus embodiment of the present invention; Figure 2 is a block diagram of an energy management and control system according to an Ethernet embodiment of the present invention; Figure 3 is a block diagram of the computer software used in the energy management and control system of the present invention; Figure 4 is a schematic block diagram of the DDE server link between clients and devices of the power management and control system of the present invention; Figure 5 is a schematic block diagram of the DDE server registration map scheme of the energy management and control system of the present invention; Figure 6 is a schematic block diagram of the DDE server, record map and message survey of the energy management and control system of the present invention; Figure 7 is a schematic block diagram of the component subsystems of the DDE server, including a server module, a DDE handler module, a device module, a registration group module and a communication module; Figures 8 and 9 are diagrams of the device module of Figure 7; Figure 10 is a diagram of the registration group module of Figure 7; Figures 11 and 12 are diagrams of the communication module of Figure 7; Figures 13 and 14 are views of a server window application window generated by the computer software of Figure 3; Figure 15 is a device configuration window generated by the computer software of Figure 3; Figure 16 is a view of an addition device configuration window generated by the computer software of Figure 3: Figure 17 is a view of a modification device configuration window generated by the computer software of Figure 3; Figure 18 is a view of the server window application window generated by the computer software of Figure 3; Figure 19 is a view of a device type window generated by the computer software of Figure 3; Figure 20 is a view of a mnemonic window with import and export characteristics generated by the computer software of Figure 3; Figure 21 is a view of an addition / modification mnemonic dialog box generated by the computer software of Figure 3; Figure 22 is a print sample of a mnemonic file in a separate character value format for importing into or exporting from the mnemonic window of Figure 20; Figure 23 is a view of a registration map window with import and export characteristics generated by the computer software of Figure 3; Figure 24 is a view of a function code window Modbus generated by the computer software of Figure 23; Figure 25 is a view of a selection register group type window generated by the computer software of Figure 3; Figure 26 is a view of a register-group status window generated by the computer software of Figure 3; Figure 27 in a view of an invalid addition registration window generated by the computer software of Figure 3; Figure 28 is an a view of an invalid registration window of modification generated by the computer software of the Figure 3; Figure 29 is a print sample of a registration group file in a separate value format of character to import into or export from the registration map window of Figure 22; Figure 30 is a view of the server window application window generated by the computer software of Figure 3; Figure 31 is a view of a communication port configuration window generated by the computer software of Figure 3; Figures 32-37 are views of the server window application window generated by the computer software of Figure 3; Figure 38 is a view of an input / output traffic display window generated by the computer software of Figure 3; Fig. 39 is a view of an input / output traffic display / selection device window generated by the computer software of Fig. 3; and Fig. 40 is a view of the server window application window generated by the computer software of Fig. 3.

DETAILED DESCRIPTION OF THE INVENTION Referring to Figure 1, a network diagram for an energy management and control system (PMCS) is shown in 10, according to the application of E. U.A. 08/628, 533 mentioned above, which is incorporated herein by reference. The system 10 comprises a host computer 12, for example, a compatible machine I BM-PC AT which is based on a Pentium processor, having standard RS485 interface cards 14 or an RS232 to RS485 converter, and adapters insta sides in their input / output slots, see, EIA-485, Standard for Electrical Characteristics of Generator ad Receivers for Use in Digital Multipoint Systems (Standard for Electrical Characteristics of Generators and Receivers for Use in Digital Multipoint Systems ilibrated). The guest host 12 furthermore comprises a local area network (LAN) interface card 16, such as an Ethernet card in another of its input / output slots. Guest host 12 contains software to verify and control selected aspects of energy use / consumption, as described further below. The cards 14 provide input / output ports, which define multiple industry standard Modbus RT networks 1 8 and 20, see, for example, "Modicon Mod Bus Modbus Reference Reference" Rev. E., Modicon, I nc . In this example, up to 8 Modbus RT networks can be provided with a 1 2 host computer. The Modbus RTU protocol is a well-known industry standard. The card 16 provides an input / output port which allows the host computer 12 to communicate with a LAN 22. Devices with a Modbus RTU interface can be connected directly to the Modbus, for example, control devices 24, such as Multilin models 269 and 565, EPM 371 0 and EPM 3720, of power management and Universal Relay of General Electric Co. of the family of modular relay devices. Other devices communicate in the comment protocol and include disconnect units 26, for example, the Tripo, Enhanced Trip-D, Trip PM and Enhanced Trip-C Units units, which are commercially available from General Electric Co., meters 28 for example, Power Leader Meters commercially available from General Electric Co., and relays 30, for example, Spectra ECM and Power Leaders MDP, of General Electric Co., are also employed as described above with respect to the prior art. A Modbus concentrator provides an interface between the Modbus RTU protocol and the comment protocol, so these devices can communicate through the Modbus 32 concentrator over the Modbus (again, a standard industry protocol). In this example, up to 32 devices (that is, direct connection devices or Modbus hubs) can be connected to each Modbus RTU network. The LAN network 22 includes a vision node computer 34 an internet gate 36. The vision node computer 34 interacts with the PMCS network 10 through NetDDE links to the host computer 12 established in the LAN network 22. Similarly, a far vision node computer 38 can interact with the PMCS network 10 through NetDDE links with the host computer 12 established through the internet, internet gate 36 and the LAN network 22. Referring to Figure 2, a network diagram for a second mode of the energy management and control system, usually shown at 50, according to the US patent application 08 / 628,533 previously mentioned.

The system 50 comprises a computer 52, for example, a PC-based computer, having standard 54 Ethernet interface cards and adapters installed in its input / output slots. The computer 52 contains software to control and verify selected aspects of the use / consumption of energy, as will be described in more detail below. The Ethernet TCP / IP protocol is a well-known standard, which may allow a user of the power management and control system of the present invention to use his or her existing LAN network. Using a LAN significantly can reduce the cost of installing the system, since much of the system's cabling is already in place. The Ethernet gates 60 are connected to the Ethernet TCP / IP networks 56 and 58 to provide an interface between the Ethernet TCP / IP protocol and the Modbus RTU protocol. In the example herein, each Ethernet gate 60 provides a connection between an Ethernet TCP / IP network 56 and 58 and four Modbus RTU networks. The connections to any of the Modbus RTU networks are the same as those described with respect to the embodiment of Figure 1. More specifically, devices with a Modbus RTU interface can be connected directly to the Modbus, for example, control devices 24 such as Multilin models 269 and 565, and the Universal Relay Family of General Electric Co., of modular relay devices. Disconnection units 26, for example, the Trip, Enhanced Trip-d, Trip PM and Enhanced Trip-C Units units which are commercially available from General Electric Co., Meters 28, for example, Power Leader Meters commercially available from General Electric Co., and relays 30, for example, Spectra ECM and Power Leader MDP of General Electric Co. , they are also employed as described above with respect to the prior art. The Modbus 32 concentrator provides an interface between the Modbus RTU protocol and the comment protocol, so these devices can be communicated through the Modbus 32 hub over the Ethernet. The device 62 with the ethernet TCP / IP interface can be connected directly to the TCP / IP network of Ethernet 56 or 58, for example, the Universal Realy family of General Electric Co., of the family of relay devices Modular Ethernet TCP / IP networks 56 and 58 may also include a vision node computer 34 and an internet gate 36. In the example herein, the vision node computer 34 interacts with the host computer 32. through NetDDE links established through the Ethernet TCP / IP network 58. Similarly, a far vision node computer 38 may interact with the host computer 52 through NetDDE links established through the Internet gateway. Internet 36 and Ethernet TCP / IP network 58. Referring now to Fig. 3, a block diagram of the software is generally shown to verify and control selected aspects of the use / consumption of energy. This software is loaded onto the computer as described above and includes a dynamic data exchange (DDE) server 100. The DDE 100 server allows external programs (clients) that operate on guest and view node computers to access data. of energy management in a Microsoft Windows environment. The data interface for the DDE server 100 is provided by the system through a human-machine interface (HMI) utility. The DDE server is a 16-bit application under Windows NT. A configuration and control interface for the DDE server is provided through server application window menus. Associated with the DDE server 100 are the logical data tables 102 and related modules, i.e., an Excel application module or other DDE warning application module 104, a waveform capture module 106., an event recorder module 108, productivity modules 110 and an HMI module 112. The module 112 includes a tool kit for designing screens and interfaces, and a graphic user interface 114 for verifying and controlling the electrical distribution system . The graphic user interface 114 for the server operates in a Windows or Windows NT 32-bit environment and HIM collection functions. The module 106 provides the vision and analysis of waveforms (eg, Fourier, frequency analysis and / or harmonics) captured by sophisticated measurement devices. Module 108 provides the vision, organization and analysis of unusual behavior in an energy system. The productivity modules include, for example, a cost distribution module and a load management module, the cost distribution module provides tracking of energy consumption at the subunit level, developing methods and internal billing reports, thus reducing the cost. The load management module provides tracking energy demand and automatically protects non-critical loads to avoid peak demand penalties and provides network-based timer control for power consumption. The DDE server 1 00 is shared via the interface card, ie the interface cards RS485, 14 or an RS232 to RS485 converter, in the embodiment of FIG. 1, on the Ethernet interface cards 54 in the mode of Fig. 2. The DDE server 100 is described herein for the RS485 interface mode. However, it will be appreciated that it is applicable for the Ethernet interface mode with the exception that the server is optimized for the Ethernet protocol (instead of the Modbus RTU protocol). The DDE 100 server provides a mnemonic cross-reference between the Modbus RTU register items and the standardized, alphanumeric parameter names. This mnemonic interface allows the user to retrieve data from the device without knowing the actual device registration item number. The DDE server 1 00 also provides a consistent device event data article for different devices. Also, the DDE 1 00 server automatically performs time synchronization for all supported devices and provides a consistent waveform interface. The DDE 100 server for the RS485 interface, is optimized for the Modbus RTU protocol by compensating invalid registers scales in the device survey packets and also provides capabilities to remove superior protocol errors by deploying all Modbus I / O packet traffic RTU. In addition, DDE server 100 performs automatic conversion between 16-bit and 32-bit device registration modes. A generic interface allows any Modbus RTU device to be used with the system. The DDE server uses the Modbus RTU protocol standard to communicate with the measurement, relay and input / output devices using the RS-485 communications ports. Each window application is registered in a window kernel with an application name. To iden only one data item for communication between two cooperation window applications (process nocation) the data item is idened through tupia (application, topic, articles). The topic name provides a grouping, and the article name specifies the name of real data that will be accessed under a topic. For the DDE server the application name is the name executable by the server. The topic name may be the device idencation name and the article name may be the registration idencation of a field data point. For example, with an EPM meter from General Electric Co., the tupia can be GE16MODB, EPM1, AMP.sub.-A, where GE16MODB is the application name for a DDE server, EPM1 is the name of the meter identification, and AMP.sub- A is the current for phase A. The DDE messages are mainly they include requests to send data as identified by the topic name and article. They can also be to set points to download the data point as identified by the topic and article names. The input parameter values are reported by field devices in the communication interface in response to a survey by the server. This value can be a float value, an integer value, or a discrete state strip or bits. The DDE server includes tool equipment functions that are used to maintain DDE or NetDDE communications. The records can be classified into a quick survey record, slow survey records and records from a single survey. Rapid survey records are polled at a rate defined by the "scan interval", which is entered during the device / topic configuration. Slow survey records are polled once in each "n" search for quick survey records and the value of "n" is read from an initialization file. "Single survey" records are polled only once when an article in that group remains active. "Single survey" records are also polled when a device status changes from DEAD to ACTIVE. The fix point records are to be downloaded based on the request of a DDE client ie a program, for example, such as an HMI package or MS-Excel, which requests data items from the DDE server and accepts data through DDE or NetDDE. Referring to Figure 4, the DDE server acts as a link between a client requesting device data and a field device that can provide the data. The DDE server communicates with the field device through communication ports and with the client through a DDE message link or NetDDE. A client sends its requests to the server to read / write some device records. The server designs maps of each request for suitable device read / write request packets and performs the necessary transaction with the device. Then, it retransmits the result back to the client after processing and, if necessary, converts the assembled device data to the appropriate format. In addition to reporting the contents of normal device registers, the server can also collect special data such as capture data / waveform record from the device and pass it to a client. To facilitate the configuration of the field data points, the user can access the field data points in the DDE or NetDDE link. Using mnemonics, which easily identifies data points instead of using register addresses. At the same time, article names based on the registry are provided to maintain compatibility with Modbus RTU protocol conventions. Referring to Figure 5, the DDE server designs article name maps for its registration addresses. The design database of name and function maps are implemented in such a way that the underlying server is not affected when new naming conventions for the article are to be implemented. Preferably, an off-line utility develops a device mnemonic to record an address map. The device mnemonic for reg- istering the map can then be im- ported during out-of-line mode, as described later. The DDE server supports the following data types: indicated integer, integer not signaled, signal length, module 10, 000, number of floating points in the I EEE format, discrete bits, and a provision of any of the aforementioned data types. The DDE server is connected through the RS485 interface, for example, a RD485 Stargate communication card with multiple ports (4 ports or 8 ports) or through an RS232 / RS485 converter. The RTS line has to be activated / deactivated to ensure proper control of the flow. Hardware flow control for all ports is enabled / disabled when the communication port is configured. In the example hereof, the DDE server supports a maximum of 8 communication ports, so that a maximum of 247 Modbus RTU devices can be connected on each port, and the Modbus co-centrators can not have one. address greater than 32. The addresses of the devices connected to any port must be unique. The DDE 100 server can connect to client nodes in a network using NetDDE support for DDE communication. The DDE server supports the following data: integer not signaled, an omission for the article name Rnnnrn; indicated integer, "I" is specified with an article name Rnnnnnl; designated long integer specified as "L" with an article name of RnnnnnL; floating point value, specified as "F" with an article name of RnnnnnF; discrete state bits, specified as "D" with an article name of RnnnnnDxxxxx; module 10000, specified as "E" with an article name RnnnnnE; and disposition values, a disposition either of indicated integer, integer not signaled, long signaled integer and float values with provision specified as 'Axxx'. Referring to Figure 6, the DDE server handles field device communication through stopwatch call functions. The DDE server polls the devices that are in an active list and from each device acquires records (articles), which are in the active list. The DDE server can group several articles while performing the data acquisition to optimize the required survey of field devices. Device registration maps usually have some gaps for future use. Although grouping several items in a survey cycle, the DDE server represents invalid registration addresses for a particular device. The fast and slow group records are not packaged in the same package. The DDE server can limit clustering due to limitations on the length of the response packet package or the download packet. The maximum length of the packet is restricted to 125 registers (250 bytes) through the Modbus RTU protocol standards. The DDE server executes fix point commands received from client applications and communicates all fix point values to the devices. The DDE server periodically synchronizes the time with the connected devices and adjusts the time formats for each of these devices.

The Modbus concentrate accepts time-write write requests for all devices connected to it, but does not change the time-record value of any device in response to written requests. Time records for all devices connected to a Modbus hub will be changed only when the server synchronizes time with the hub. Periodic time downloading to selected devices is performed even if no particular device is affected. Time synchronization for other devices is done as for the record format specified for device registration maps. The DDE server maintains a current status (DEAD / ACTIVE) of all active topics (Device). This information does not have any direct record associated with the device topic name and therefore a pseudo article called "STATE" is maintained by the DDE server. If the DDE server does not get a response from any device during "n" consecutive survey cycles, then that particular device is declared DEAD. The value of "n" is read from an initialization file. The status of any device will be updated for a client only if a predefined item called "STATUS" becomes active. DEAD devices can be polled one period at a DEAL device scan interval (available in the initialization file) instead of the device scan interval. DEAD devices will remain ACTIVE when responding to a survey request. The DDE server displays the communication traffic in a text format in its window, if it is programmed to do this. A fixation option is provided in the server's main menu for this purpose. Communications traffic displayed in a "scrollable" window for selected devices and selected options. In addition, the DDE server records communication errors, which include, by way of example, out-of-time errors, CRC errors, erroneous station identification responses, and extra bytes reported in response to a request from the device. The DDE server registers communication errors for ACTIVE devices only, and registers the status of the device each time a device becomes ACTIVE or DEAD. The configuration data of the server are accepted through the interfaces and are stored in initialization files or other configuration files. The configuration is an offline function and is disabled during the operation time. The configuration utility is provided for: communication port configuration, device / topical configuration, device type registry map configuration, device type record type survey priority configuration, function code configuration supported by device types, invalid registration addresses of device type registration map, mnemonic of the article to record the map design, and server operational parameters. The configuration utility also allows the import and export of registry and mnemonic groups. In the example here, up to 8 communication ports can be configured. It will be appreciated that this is restricted by the number of ports that the Windows communication unit or Windows NT 16-bit can support. For each port, the following parameters can be configured: Baud rate: 1200, 2400, 4800, 9600, 14400, 19200, 38400, 57600 Parity: Par, non, no Detention bits: 1, 2 Hardware flow control: enable, disable Currently, Modbus RTU protocol standards require 8 bits. At the time of initialization, the DDE server configures the communication ports, devices and timers, as defined by the user. Also, all the specific databases of the device are initialized. From the main menu, the user can start the server, stop the server, suspend the protocol and resume the protocol during the operation time. The configuration scales in the example hereof are as follows; a device name can be up to 20 characters, a scan interval can be on the scale of 1-9999999 milliseconds, and a slave address can be on the scale of 1-247. It will be appreciated that multiple topics can be configured with the same slave address and communication port. The configuration utility will detect multiple topics before being configured in the same slave address and will issue a warning message to this effect when the user configures a topic in an already configured address. The communication port to which a device is connected can be previously defined. A device-type register map must be configured for each of the device topics connected to it. The system provides the configuration of a valid starting address, a last valid address, a group of invalid registration blocks, using this utility. Valid records in the example hereof are ROXXXX; R1XXXX; R3XXXX; or R4XXXX. Accordingly, the DDE 100 server supports the following Modbus register types: ROXXXX-discrete coils, R1 XXXXX-discrete state registers, R3XXXX-input registers and R4XXXX-fix point register. With these generic types, a user can configure any number of record types. Each of these types will have polling speed attributes (ie, fast polling, slow polling, or once polled). Buffer events, read / write date / time registers for time synchronization, waveform capture data and waveform record data are implemented differently in the devices that support it, therefore , no common configuration utility is provided for these functions. The DDE server handles each of these functions in a specific way. Again, a mnemonic name is associated with a registration address. In addition, a user can configure the sound of the protocol timer and the value of time out of valid data with this utility. The time out server sound is read from an initialization file. By way of example, several of the devices discussed above, namely EPM, RMS6, RMS9B, RMS9C, RMS9D, ECM, MDP and the Modbus concentrator, include record types R3XXXX; R4XXXX; and ROXXXX. To acquire data from these devices and to download fixation points, the DDE server implements Modbus function codes, 01, 03, 04, 05, 05, 16, 56. Several recording groups, ie dynamic values, fixing points , command registers, event records, fixed value record, and comment statistics can be configured by the user, either in a slow survey record or quick survey records, or records from a single survey. The DDE server downloads time points for all these devices on a regular basis. The periodicity of downloading time is available in an initialization file. An event account record is polled at the fast polling rate. When the event account record is not zero, an event search is performed by reading the start address of the event buffer. Each event is read and set sequentially in time. The event code is expanded with a description, additional data fields, and a date setting of the events before being sent to the client. In general, the DDE server provides appropriate return values as specified by all clients, ie periodic survey packages for topics and active items, periodic survey packages for events and statuses, periodic update of time for all devices, update of value of data for clients for items purchased, event / status reports for the HIM package, so that it becomes part of the normal alarm record, and status update for active topics (device). The fix point write requests are appropriately formatted download points communication packets for the request. The execution and termination of the server are initiated in a user request from the DDE server window menu. The following Modbus function codes are supported by the DDE server of the present invention: Function Code 1: Reading coils, Function Code 2: Reading input status, Function code 3: Reading support registers, Function code 4: Read input registers, Function code 5: Individual write coil, Function code 6: Register of individual writing support, Function Code 15: Multiple write coils, Function Code 16: Multiple write support registers and Function Code 56: Last retransmission response. Referring to Figure 7, the component subsystems (ie, modules) of the DDE server include: the server (application) 150, the device module 152; the registry group module 154; the communication module 156; the DDD 158 management module. All these modules (except the DDE handler) employ an object-oriented aspect. Each module comprises several classes. The application module 150 handles all the external inputs to the system, that is, user interactions and client requests through the DDE or NetDDE link. As described above, the server is configured for several devices when the server is offline. The configuration parameters include, registry map configuration, mnemonic configuration, and configuration of the communication port that the device is attached to. While online, the server will wait for client requests through the DDE handler and will service those requests. It also receives any special command from the user, for example, obtain the protocol, and perform it properly. In the application module, class, server, provides server communication with the tool team through the DDE handler and synchronizes the processing. Referring to FIGS. 8 and 9, the device module 1 52 extracts a field device and handles multiple register categories (or register groups). Class, Coil Cartridge, provides support for special discrete register bit operations for reference register types RO and R1. Class, C device contains all device information such as device name, device identification, device type name and port address. Class, device type C, summarizes a type of field device that the server will talk to, has a variable number of registry groups, contains a mnemonic list, and has function codes associated with it. Class, discrete article C, extracts a discrete bit array in a register, for a 16 bit register, all 16 bits can be programmed whereas for a 32 bit register only the lower 16 bits can be specified by the user. Class, event item C, handles the event processing for a selected device, for example a General Electric Co. device, formats an event strip and passes it to the client. Class, type of device CGE supports an event registration group, by way of example, part numbers EPM, RMS6, RMS9B, RMS9C, RMS9D, PLMeter and MDP that qualify as device types of General Electric Co. Class, items C , take care of items of designated and unmarked whole. Class, article C is a data point present in a field device. Article C comprises a plurality of records in the device and can handle a single type or type arrangement. Article C is a base class for different types of articles present in the application and includes whole, long, real, coil, discrete bits and real-time parameters. An article has reference to the registration group to which it belongs. Any new article that has been created or activated, a simulated registry block is created and immediately polled for the quick update of the article. Class, long article C, handles a long type of data indicated. Class, mnemonic C contains the mnemonic name and the corresponding record format. Class, type of CModbus concentrator automatically synchronizes time with all Modbus concentrator devices which only have the property of time discharge. Class, event article Cmultilin565E handles the special event processing present for the Multilin 565 device. Class, Type CMultilin565, supports the event registration group and for Multilin meters, which are similar to those of the General Electric Co. devices. Class, C online device exist only when the server is operating, every time an online device has been created, a copy of this type device is created and is attached to the device online. Class, Meter Type CPL is associated Power Leader meter devices from General Electric Co., and supports the CPLMeterWFCR record group for waveform capture. Class, data item CPLMeterWFD, is a text article associated with the PLMeter. Data item CPLMeterWF is a collection of "n" samples read from the device, with the sample number and sample start address read from the .INI file of the application. Class, event article CPML3710, handles the event processing for a PML3710 device and formats an event strip and passes it to the client. Class, type CPLM3710, supports a PLM3710 device where the default registration group CPML371 OWFCRegGroup supports waveform capture. Event processing is similar to other types of devices, except that it does not contain an event account record. Class, data item CPML3710WFC given, is a text article associated with PML3710. Data item CPML3710WFC is a collection of "n" sample read from the device. Each sample is 12 bits and 2 consecutive records, giving 3 values. The number of samples and the start address of the sample are read from the .INI file of the application. Normally, for two PML devices, the WCF is 99 registers. Class, article available CPML3710, manages the special article PML.sub - WFC.sub - AVIL on the PML3720 device. Class, event graphic artist CPML3720, handles the event processing for a PLM3720 device and formats an event strip and passes it to the client. Class, type CPML3720, supports a PML3720 device. The default registration groups that go with this type of device are the registration group CPML3720WFCRegGroup and CPML3720WFRRegGroup to handle the waveform capture and waveform record, respectively. Class, article CPML3720WFC, is a text article associated with PML3720. Data item CPML3720WFC, is a collection of "n" samples read from the device, where each sample is 12 bits and two consecutive records giving 3 values. The number of samples and sample start addresses are read from the .INI file of the application. Class, data item CPML3720WFR collects required sample data and updates it for the client. Data item CPML3720WFR handles PML special items. sub-- WFR.sub - BFRS.sub - AVAIL and PML. sub - WFR.sub - NEXT.sub - BFR on the PML3720 device. Class, real article C, keeps the data in an IEEE float-point format, in a 16-bit mode, 2 records are required, while in a 32-bit mode, only one record will give the value. Class, state item C, is a graphic text artist that exists on each device. The status strips that are updated by this article for a device are ACTIVE and DEAD. Referring to Figure 10, the record group module 154 supports a record arrangement, some records in the arrangement can be declared invalid. Consecutive records can be grouped together to define an item or a point. An article performs the processing in these registers depending on the type of article. Customers are interested in the item value after the processing has been submitted. The registration group module is designed to handle multiple numbers of such items. Class, event record C supports events that handle the General Electric Co. devices Class, invalid register block C, keeps the scale invalid where it contains a scale of invalid registers in pairs (start, end). Class, invalid record list C, is a list of Objects containing invalid register block objects C for a particular record group. Class, event log CMultili565 supports Multilin565 events. Class, CPL meter coil register handles 2 command coil item, ie TRIGGER.sub-WF.sub-CAPTURE and CLR.sub-WF.sub-CAPTURE for General Electric Co. Power Leader Meter Class, SpISP record of CPL meter, handles fix point records for the Power Leader Meter. A DDE article present in this group WF.sub - SETPT. Class, CPLMeterWFC record, support waveform capture for General Electric Co. Power Leader Meter. The DDE items present in this group are WF.sub - DATA, WF.sub-AVAIL, WF.sub-CHANNEL, WF .sub-HOUR, WF.sub-MIN, WF.sub SEC, and WF.sub-MSEC. This record group supports the retrieval of capture data in the form of a wave. Class, registration event CPML3710, supports PML3710 events. Class, registration PML3710WFC is a registration group for PML3710 and has a DDE article named as PML.sub - WFC. This group of records supports the PML.sub - WFC article to retrieve the WFC data from the device. Class, registration event CPLM3720, handles the PML3720 events. Class, registration CPML3720WFC is a registration group for PML3720 and handles only two DDE items, which are referred to as PML.sub - WFC and PML. sub-- WFC.sub --AVAIL. This registry group supports the PML article. sub - WFC to recover the WFC data of the device depending on the availability of the data (which are known by PML. sub --WFC.sub --AVAIL). Class, registration CPML3720WFR, is a registration group for the PML3720 device and has several DDE items which are referred to as PML. sub - WFR, PML. sub --WFC.sub --BFRS.sub - AVAIL, PML. sub - WFR. sub - NEXT. sub-BFR, PML. sub.- Vl.sub. - WFR, PML. sub. --V2. sub.- WFR, PML. sub. -V3. sub. -WFR, PML. sub. -VAUX. sub. -WFR, PML. sub.- 11. sub. -WFR, PML. sub. -12. sub. -WFR, PML. sub.13. his. -WFR and PML. sub. -IN. sub. -WFR Class, type of register CRO supports function codes 01 (coil reading), 05 (single write coil), 15 (multiple write coils). There is a type of generic record groups from which the user is allowed to dynamically activate many record groups for a device type. Class, record type CR1, supports the function code of 02 (for discrete reading bits). All write commands in this type of discarded record. This is a type of generic record group from which the user is allowed to dynamically activate many record groups for a device type. Class, record type CR3, has a function code 04, (read entry record). All write commands in this type of records are discarded. This is a type of generic logging group, from which the user is allowed to dynamically activate many logging groups for a device type. Class, record type CR4, is a record group that has specific function codes that are 03 (reading support records) 06 (individual reading record), and 16 (multiple reading records). This is a type of generic record group from which the user is allowed to dynamically exemplify many record groups for a device type. Class, C read register block, contains a valid registration scale that can be used while sending a read packet to the device. A valid block can represent one or more of an article. It also contains item start and stop items in the list of record group items for the convenience of the record group, while updating article values in the tool set. Valid blocks are recalculated each time an item is added or removed, therefore the list of register blocks is dynamically changed. Class, registration group C, manages a category of registration whose access will be similar for the client. It has a list of all the active articles of the group in a member named m-article list. It also has a list of valid registration blocks. You can acquire data from all the active articles in the m-article list and download data from an article to the device. Maintains a list of valid blocks, which is sent to the field device one at a time. A valid block is polled in favor of maximum possible items thus optimizing the survey. Class, status register C, handles the STATE article. This registration group and the article are present for all devices. Class, C time download record, download time to Modbus concentrator and General Electric Co. devices, and do not support any item. Class, download C time 565, download the time to the Multilin565 device, and it does not support any article. Class, PML download time C, download time to devices PML 3710 and PML 3720, and does not support any article. Referring to Figures 11, and 12, communication module 156 enables the server to communicate with a device. All client requests are going to be mapped in several Modbus packages and then these packets that have to be transmitted to the device successfully. Also the responses of the devices are received here first and verified for CRC error. This module is also capable of declaring any device as DEAD but can communicate with the ACTIVE device when the communication is resumed with a device previously DEAD. Class, CCom port, supports the transaction of a Modbus package between the server application and the device. The com port maintains a packet queue and returns immediately after transmitting a packet and verifies the response only in the next scan cycle. This improves the production of the packet in / out with the device. Class, protocol CModbusRTU, implements specific Modbus RTU protocol functions. This improves the Modbus RTU protocol of class implements and the method of adding RC to the data bytes before being sent to the device. Also, check CRC for response bits and clean or delete for further processing. Class, package C, implements the common understanding between the server and the device with which both are able to talk to each other. The packages does not contain CRC. Package C contains both the request and the response and acts as a base class for the implementation of function code. The packet interface with articles is set as two bytes per record in a 16-bit mode and 4 bytes per record in a 32-bit mode. For a discrete article, or a coil article, only the bit that is furthest to the right is used, although the other bits are discarded. Class, protocol C, is a generalized protocol base class. A protocol is a setting of rules that govern the format and represent the messages (or packets) that are exchanged between the server and the device. Protocol C is designed so that you can put any error check in bytes before transmitting and also any error verification in response bytes that are received. Class, C reading bit packet, reads discrete registers (reference R1) and coil register (reference RO). Class, C reading package, is a base package class that provides generalized methods for all those Modbus packages that are represented to read registry values. Class, reading record pack C, reading input records (reference R3) and support records (reference R4). Class, write multiple packet C, write in multiple coil registers (reference RO). Class, package of multiple C write records, write in multiple support records (reference R4). Class, write pack C is a base packet class that provides generalized methods for those Modbus packets that represent single or multiple write record values. Class, package of individual write bits C, write to individual coil register (reference R1). Class, individual writing package C, write in individual support records (reference R4). The DDE 158 driver module implements the tool equipment interface functionality to communicate with clients. It handles several DDE communications with clients and uses HMI packet support to connect the server class with the HMI tool set and supports the DDE or NetDDe message protocol.

The DDE server uses the DDE driver to implement DDE or NetDDE communication links. All client requests are conveniently interrupted or separated in one or more of the following operations by the DDE driver: Topic of creation, the server is ready to poll the device indicated by the topic name; create article, an article can be created only for a topic already created and the server ready to poll the article; activate article, the server initiates the polling of the field device that corresponds to the topic whose article has not been activated and supplies the article value to the client that requests it, periodically; deactivate article, the poll of the active article is stopped; delete article, the specific article is no longer required and therefore is eliminated; and execute command, the client performs a command on the device with the specific topic name, so if the device is present, and is able to understand the command, the processing of the command is performed by the server. The DDE-SERVER SERVER WINDOW APPLICATION screen, in off-line mode, is generally shown in Figure 13. The CONFIGURATION button is selected in the SERVERS-SERVER WINDOWS APPLICATION screen, generating a menu from which DEVICE INFORMATION is selected as shown in Figure 14. The selection of DEVICE INFORMATION generates a DEVICE CONFIGURATION screen shown in Figure 15. From the DEVICE SETTINGS screen, the configuration of a new device (ADD , the modification of an existing device (MODIFY), or the deletion of a device (DELETE) can be selected.The selection of the ADD button generates an ADDING DEVICE CONFIGURATION screen shown in Figure 16. The selection of the MODIFY button generates a MODIFY DEVICE CONFIGURATION screen shown in Figure 17. The selection of the DELETE button will give a The result is that the device information for that device is removed. From the menu generated by the CONFIGURATION button on the SERVERS-SERVER WINDOWS APPLICATION screen, DEVICE TYPE INFORMATION is selected as shown in Figure 18. The selection of DEVICE TYPE INFORMATION generates a TYPE OF DEVICE screen. DEVICE shown in Figure 19. From the DEVICE TYPES screen, modify the mnemonic for a type (MNÉMONIC), modify the registration map for a type (REGISTRATION MAP), delete type of omission (DELETE), or add a new one by default device type (DEFAULT TYPE ADD). The selection of the MNEMONIC button generates a MNEMONIC screen, in this example for the ALP device, shown in Figure 20. The selection of the REGISTRATION MAP button generates a REGISTRY MAP screen, in this example, for the ALPS device, shown in Figure 23. The selection of the DELETE button will result in the type of device being deleted. From the MNEMONIC screen of Figure 20, the selection of the ADD button generates an ADD / MODIFY MNEMONIC dialog box of Figure 21. In the ADD / MODIFY MNEMONIC dialog box of Figure 21, a name Mnemonic and its corresponding registration address are entered in their respective fields. Pressing the OK button stores the mnemonic and its corresponding registration address. From the MNEMONIC screen in Figure 20, the illumination of a mnemonic in the list (for example, ACCLONAR_PROT_GRP_NUMERO) after selecting the MODIFY button generates a MNEMONIC ADD / MODIFY dialog box of Figure 21 with the mnemonic illuminated and its corresponding registration address in its respective fields. Selecting OK stores the modifications made to the mnemonic and its corresponding record. From the MNEMONIC screen of Figure 20, the mnemonic lighting in the list then the DELETE button is selected and the illuminated mnemonic is removed. Also shown on the MNEMONCOS screen of Figure 20 are the IMPORT MNEMONIC buttons and EXPORT MNEMONICO. These buttons allow the user to import and export computer files containing a mnemonic arrangement and their corresponding registration addresses in a comma-separated value (CSV) format. The value format separated by a comma is a well-known file format. An example of an impression of a mnemonic file in a CSV format is shown in Figure 22. where each line lists a mnemonic and a definition for its corresponding record. The format used for the record definition is "RyXzzzzzzV" or "RyzzzzzV", where: "R" is the fixed component, "X" notifies that the following address "zzzz" is in a hexadecimal format (without "X", the "zzzzzz" address is in a decimal format), "y" describes the Modbus record type, and "V" describes the format that the DDE server provides to the value. Referring again to the MNEMONIC screen in Figure 20, the EXPORT MNEMONICO button exports the mnemonic actually saved to the mnemonic file, where the data within the file can be modified by the user, using, for example, Microsoft Excel , or through configuration utility. Such modification is necessary, for example, to improve the mnemonic of a device class supported by the DDE server or to configure the DDE server for a new type of generic device. The IMPORT MNEMONIC button is selected to import the file to the DDE server. The modification of the CSV file can be done locally, through the host computer or far away through the vision node computers. When a mnemonic file is imported the DDE server checks the file for an appropriate syntax before accepting the file. The DDE server also verifies the mnemonic to ensure that it does not exceed the allowed length (for example, 20 characters) and compares the mnemonic with the plurality of mnemonics already stored to ensure that the mnemonic is unique. In addition, the DDE server verifies the correlation between the imported mnemonic and the existing registration groups. Verification of this correlation includes inspecting that each of the mnemonic reference references a valid registration group, and verifies that the reference Modbus record type is available in the registration group for that mnemonic. When an error is detected, the user is notified with information containing the name of the mnemonic and its registry definition, allowing the user to correct the error. From the REGISTRATION MAP screen of Figure 23, you can select the addition of a new registration group (ADD NEW REGISTRATION GROUP), delete a registration group (DELETE), modify a registration group (MODIFY ), import and export a record group file (IMPORT REGISTRATION GROUP and EXPORT REGISTRATION GROUP). The selection of the ADD NEW REGISTRATION GROUP button when the registration group is added is the first registration group present in the device type generates a MODBUS FUNCTION CODE screen, in this example for the PML3710 device shown in Figure 24 , for the modification of the function codes. Then, the SELECT REGISTRY GROUP TYPE screen shown in Figure 25 is generated for the selection of the registration group. Selecting the OK button on the SELECT REGISTRATION GROUP TYPE screen after the records have been selected generates a STATUS REGISTER-REGISTER GROUP screen, shown in Figure 26. The REGISTRATION-STATE REGISTRATION GROUP screen provides Registration group information and is presented when the MODIFY button is selected on the REGISTRATION MAP screen. The selection of the ADD button on the STATUS REGISTER-REGISTER GROUP screen, generates a screen of ADDING INVALID REGISTER shown in Figure 27, to add invalid records. The selection of the MODIFY button on the STATUS REGISTER-REGISTER GROUP screen generates a MODIFY INVALID REGISTER screen shown in Figure 28, to modify the invalid registers. Referring again to the REGISTRY MAP screen of Figure 23, the selection of the IMPORT REGISTRATION GROUP or EXPORT REGISTRATION GROUP buttons allows the user to import and export computer files containing a registration group data set in a CSV format. An example of an impression of a record group file is shown in Figure 29. Referring to Figure 29, each line of data in the file contains a definition for a single record group. The first column of data describes whether the group is valid (+) or invalid (-). The second column of data contains the group name, a unique name, with a length of up to 20 characters, of the record group. The third column defines the Modbus record type ("R" followed by types 1, 2, 3, or 4) The fourth column contains a 4-digit hexadecimal address at the start of the registration group (the prefix "Ox" indicates that the value to the right is hexadecimal). The fifth column contains a 4-digit hexadecimal address of the registration group term. The sixth column describes the read and write access available for the records in the group ("RO" -only read, "RW" -read / write, "WO", write only). The seventh column describes the polling rate for the registration group ("once polled", "slow polling", or "fast polling"). On the REGISTRATION MAP screen of Figure 23, the EXPORT REGISTRATION GROUP button exports the registration group data actually saved in the registration group file, where it can be modified by the user using, for example, Microsoft Excel , or through a configuration utility. Such modification is necessary, for example, to improve a class of device supported by the DDE server or to configure the DDE server for a new type of generic device. The IMPORT REGISTRATION GROUP button is selected to import the file to the DDE server. The modification of the CVS file can be done locally, through the host computer, or remotely, through the computers of the vision node. When a file is imported, the DDE server verifies that the file has an appropriate syntax before accepting the file. The DDE server also verifies the file to ensure that the first line of the file writes a valid record group, that there is no valid overlapping record group for the same Modbus record type, and that there is no valid and invalid overlapping record group. In addition, the DDE server verifies the correlation between the imported registry groups and the existing mnemonic. The verification of this correlation involves inspecting that each existing mnemonic refers to a new valid registration group, and that the Modbus record type is referenced by each existing mnemonic and that it is available in the new registration group for that mnemonic. If an error is detected, the user is notified of the invalid registration groups, so that they can be corrected. From the menu generated by the CONFIGURATION button in the SERVERS-SERVER WINDOWS APPLICATION screen, PORTS are selected as shown in Figure 30. The selection of PORTS generates a COMMUNICATION PORT CONFIGURATION screen shown in the Figure 31. From the parity of the PORTS screen, stop bits, flow control and baud rate are displayed and set for each communication port. From the menu generated by the CONFIGURATION button in the SERVERS-SERVER WINDOWS APPLICATION screen, OPERATION PARAMETERS is selected as shown in Figure 32. The selection of OPERATING PARAMETERS generates a SERIAL OPERATIONAL PARAMETERS screen shown in Figure 33. From the SERVER OPERATIONAL PARAMETERS screen, they are displayed and fixed. the protocol stopwatch sound and the time out of valid data. After the configuration is established as previously defined, the SERVER button is selected on the SERVER-SERVER WINDOWS APPLICATION screen generating a menu from which RUN is selected as shown in Figure 34, putting the server in line and disabling the configuration option. From the menu generated by the SERVER button in the SERVERS-SERVER WINDOWS APPLICATION screen, the SUSPEND PROTOCOL is selected, as shown in Figure 35, which allows the suspension of the protocol for analysis purposes. Once the protocol analysis is complete, the menu generated by the SERVER button on the SERVER-SERVER WINDOWS APPLICATION screen displays a RESET PROTOCOL screen, as shown in Figure 36, which is selected to resume the protocol. Once the server is online, as described above, the SEE button is selected in the SERVER-SERVER WINDOWS APPLICATION screen, generating a menu from which DEPLOY INPUT / OUTPUT TRAFFIC is selected as shown in the Figure 37. The selection of DEPLOY INPUT / OUTPUT TRAFFIC generates an ENTRY / EXIT TRAFFIC DEPLOY screen in Figure 38, which provides a presentation of the input / output traffic. Selecting the DELETE button on the DEPLOY INPUT / OUTPUT TRAFFIC screen removes the selected device. Selecting the ADD DEVICE button on the DEPLOY INPUT / OUTPUT TRAFFIC screen generates a DISPLAY TRAFFIC INPUT / OUTPUT SELECT screen DEVICE as shown in Figure 39, where the active devices not selected for the display of input / output traffic are listed for selection. The HELP button on the APPLICATION screen SERVER-SERVER WINDOWS can be selected at any time. The selection of the HELP button generates a menu from which you can select CONTENTS, SEARCH OR ABOUT THE SERVER, as shown in Figure 40. The selection of CONTENTS generates help content screens. The SEARCH selection generates help search topic screens. The selection of WITH RESPECT TO THE SERVER generates an information screen with respect to the DDE server. In summary, the DDE server uses the Modbus protocol to communicate with a field device. The server has to probe these devices continuously and obtain the required data for a client. The communication parameters are set during the configuration by defining which communication is to be carried out. No initialization is necessary before the communication with the devices. The server always assumes that all devices are ready and polls them at their polling rate. All fast polling records are polled quickly, slow polling records are polled "n" times less than fast polling records, where "n" is read from an INI file, all records once polled are polled only once when the item is active. If some devices do not respond, the server declares them as M U ERTOS and informs interested customers. More specifically, the server transmits a request packet and waits for the response, that is, the server is the master and the device is the slave. If a response is received at a fixed time from the specified device, the server verifies the response for CRC error. If CRC available at the end of the response packet matches the CRC calculated by the server, then the response is accepted and processed further. If CRC in the previous case does not match or the CRC response, the server transmits the packet again. A Modbus function code is used, for certain devices that are connected through the hub, to request field devices to retransmit the response packet, where a CRC error has previously occured. Otherwise, a request packet is retransmitted by the server. The server transmits the request packet to the device until it either obtains an accepted response or a specific retransmission limit has been reached. If a retransmission limit is reached, the server declares the corresponding device as DEAD and stores the request packet in a slow polling queue. The same request package will be treated again at a slower frequency. If during the polling of the dead device, the server receives a good response packet from the device, then the server makes the device ACTIVE and will resume normal polling for the device. When the server is not running (ie, offline mode), the user can configure the system using the configuration menu commands. The user can configure: communication port parameters, device address topic, device registration map and invalid registers, registration group survey priority, function codes supported by device type and operational parameters. The user can also import and export record group and mnemonics. When importing and exporting registry and mnemonic group, the user can quickly and dynamically change the wired or mnemonic microprogram review record map of a device class supported by the DDE server, change the number or types of registers or mnemonics, or add a new generic device type, all withhaving to implement a new software. This feature saves time and money costs normally required to write new software codes. This feature, eliminating the need to modify the software code also eliminates the danger of introducing new software errors. When the server is running (say, online mode), the user can see server communications with field devices in the display of inbound / ound traffic. This deployment tells the user everything abthe data packets of the oing and incoming server, as well as the errors that occur during the transactions. The user can select the devices of interest for the vision of the traffic of entrance / exit, using the dialog of display of traffic of entrance / exit. The DDE server starts, reads disk configuration data and initializes all other objects. The system is started in online mode. The application module is used for the configuration of the system. Each time the user confirms the change (for example, by pressing the OK button, accepting the change), all the configuration data is stored on the hard disk. The DDE handler passes all client requests for any topic and any article to the application module. The application module validates that the device exists and passes additional requests for article data to the device module. The device module in turn depends on the registration group to obtain data in the correct format for any article on any device. The registration groups decide which registers are to be polled and with which Modbus function packages. Therefore, the registration groups create an appropriate package and pass it to the communication module. The communication module performs the actual transaction with the device. The result of the transaction is returned to the registration groups, which in turn pass it to the device module. After obtaining the data, the device module updates them for the clients. Although the invention has been described with reference to a preferred embodiment, it will be understood by those skilled in the art that changes can be made and that the equivalents can be replaced by their elements withdeparting from the scope of the invention. In addition, many modifications can be made to adapt a particular situation or material to the teachings of the invention withdeparting from the essential scope thereof. Therefore, it is intended that the invention is not limited to the particular embodiment described as the best mode contemplated for carrying this invention, but that the invention will include all modalities that fall within the scope of the appended claims.

Claims (20)

1. A method for configuring a server for a power management and control system, comprising: importing a file containing registration group data for a group of registers into a plurality of energy control or verification devices, the group data of record including addresses for that group of records and a group name: create a registration map for the record group using the addresses; and associate the registration map with the group name.

The method according to claim 1, wherein the registration group data indicates whether the group of records is valid.

3. The method according to claim 1, wherein the registration group data indicates a Modbus record type for said registration group.

The method according to claim 1, wherein the registration group data indicates read and write access for the group of records.

The method according to claim 1, wherein the registration group data indicates a polling rate for the group of records.

6. The method according to claim 1, wherein the file is in a value format separated by a comma.

7. The method according to claim 1, further comprising: verifying the file for an appropriate syntax.

The method according to claim 1, further comprising verifying a first valid group of records having a Modbus record type that does not overlap a second valid group of records having the Modbus record type.

The method according to claim 1, further comprising: verifying a correlation between the group of records and a map-designed mnemonic for a record within the group of records, the record group data indicating whether the group of records it is valid, and such verification including inspecting that the group of records is valid.

The method according to claim 1, further comprising: verifying a correlation between the group of registers and a map-designed mnemonic for a record within the group of registers, the mnemonic indicating a first Modbus register type, the data of record group indicating a second type of Modbus register, and said verification including inspecting that the first type of Modbus register is the same as the second type of Modbus register.

The method according to claim 1, comprising: verifying that a valid group of records does not overlap an invalid group of records.

12. A method for configuring a server for an energy management and control system, comprising: importing a file including a mnemonic and an address for a record in a power verification or control device; create a registration map for that record using the address; and associate the registration map with the mnemonic.

The method according to claim 12, wherein the file also includes a first type of Modbus register.

The method according to claim 12, wherein the file is in a value format separated by a comma.

15. The method according to claim 12, further comprising: verifying said file for the appropriate syntax.

16. The method according to claim 12, further comprising: comparing the mnemonic with a plurality of mnemonics; and verify that said mnemonic does not exist in the plurality of mnemonics.

The method according to claim 13, further comprising: verifying a correlation between the mnemonic and a group of registers including the register, the group of registers having a second Modbus register type, and said verification including inspecting the type Modbus register is the same as the second Modbus register type.

18. The method according to claim 12, further comprising: verifying that the record is in a valid registration group.

19. A method for configuring a server for a power management and control system, comprising: exporting a file containing registration group data for a group of records into a plurality of energy checking or control devices; modify the registration group data to create modified registry group data; save modified registry group data in a file; import the file containing the modified registry group data; and create a record map for the group of records using modified record group data.

20. A method for configuring a server for an energy management and control system, comprising: exporting a file containing data, said data including a mnemonic and an address for a record in a power verification and control device; modify said data to create modified data; save the modified data in the file; import the file containing the modified data; and create a registration map for the registry, using the modified data. SUMMARY A dynamic data exchange (DDE) server (100) is presented, which allows external programs to access power management data. The DDE server (100) provides a mnemonic cross reference between register items and standardized, alphanumeric parameter names. This mnemonic interface allows the user to retrieve data from a device without recognizing the actual device registration item number. The DDE server (100) is optimized for either the Modbus RTU or Ethernet protocol. The DDE server (100) acts as a link between a client request data device and a field device, which can provide the data. The DDE server (100) communicates with the field device through communication ports and with the client through the DDE message link or NetDDE. A client sends its requests to the server to read / write a device record. The server designs maps for each request for suitable device read / write request packets and performs the necessary transaction with the device. Then, it retransmits the result back to the client after processing and sending the collected device data in an appropriate format. To configure the DDE server (100), the user can export and import files containing registry and mnemonic groups, in a value format separated by a comma. When importing and exporting a record group and mnemonics, the user can change the wired or mnemonic microprogram review record map of a device class supported by the DDE server (100), change the number of record types or mnemonics, or add a new type of generic device.