WO2014036073A2

WO2014036073A2 - Method and apparatus for browsing large data network topology trees

Info

Publication number: WO2014036073A2
Application number: PCT/US2013/056973
Authority: WO
Inventors: Gilberto Augusto Matos; Evgeny Pavlovich KARATAEV
Original assignee: Siemens Aktiengesellschaft
Priority date: 2012-08-28
Filing date: 2013-08-28
Publication date: 2014-03-06
Also published as: WO2014036073A3

Abstract

A method (100) for constructing a tree visualization of the hierarchical data of an electric distribution network in which concurrent and asynchronous requests to a data server may be made (104) to retrieve respective parts of the network topology (106, 112).

Description

METHOD AND APPARATUS FOR

BROWSING LARGE DATA NETWORK TOPOLOGY TREES

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of Provisional U.S. Patent Application Serial No. 61/693,897 entitled, "Robust, Scalable Interactive Browser Of Large Electric Network Topology Tree For Rich Client Applications", filed in the name of Gilberto Augusto Matos and Evgeny Pavlovich Karataev, on August 28, 2012, the disclosure of which is also hereby incorporated herein by reference.

FIELD OF INVENTION

The present invention relates to data communications. More particularly, the present invention relates to a user computer interface to interactively manage large amounts of data and complex data structures.

BACKGROUND OF THE INVENTION

Electric distribution grids/networks are controlled by power utilities via a combination of automated and non-automated mechanisms. Additional automation and more efficient mechanisms of automation would provide, generally, a more robust management of electric load demand by power utility customers, especially industrial and commercial customers. For example, until recently, a power utility's demand response has been largely a non-automated process. Demand response is a process to meet grid peaking power capacity requirements, typically, by purchasing peaking power on the wholesale market to satisfy demand. Demand response can be expensive. Power utilities are now seeking to automate demand response processes to make them more cost-effective, for example, by reducing the purchase of expensive wholesale power from inefficient forms of peaking power generation.

An electric load management tool common to both automated and non-automated mechanisms is a representation/visualization of a respective electric distribution network as a hierarchical tree comprised of a connected number of nodes representing utility assets/facilities and electric loads (typically, customers). For a given large power utility, the size of the distribution network extends into millions of customers and the number of different ways of aggregating their loads for various load management purposes and demand response programs can easily have thousands of aggregation nodes representing, for example, various utility assets (such as substations, feeder lines, etc.), or loads with similar profile (such as, restaurants, office buildings, apartment buildings, etc.), or various geographic areas (such as, by county, ZIP code, distribution utility, etc.), or by contract and business relationships (such as, sites for a specific company, customers with a specific distribution or demand response contract, etc.). It is evident that automated mechanisms for load management would be useful in working with such hierarchical tree representations/visualizations.

Automated mechanisms can take on various configurations. An exemplary, simplified control system for automated electric load management of a respective electric distribution network may comprise a command workstation, located at an appropriate power utility facility, that controls and communicates with remote server computers located at respective physical sites of the power utility assets/facilities and electric loads. The servers are adapted to act as application servers and may be used to execute application software programs that operate the appropriate equipment generating and transmitting electric power. The command workstation is adapted to act as a user interface and may be used to construct, manipulate, and view the representations/visualizations of a hierarchical tree for the network to implement the control of the servers and, thus, the electric loads. A data server(s) is used by both the command workstation and the servers to upload and download appropriate information for executing the application software programs for load management. In some cases, one or more remote servers may also act as a data server(s). Communications among the system elements may be realized using the Internet and appropriate data communications protocols. The application software programs may be in the form of a rich Web client application, i.e., an Internet-based application in the command workstation that allows user interface and related activity to run on the command station ("client side") and data manipulation and operation to run on the server side. A rich Web client application normally runs inside/atop a Web browser application on the client side.

However, the size and complexity of the structures of certain hierarchical trees of an electric distribution network makes a user's interactive browsing (e.g., via the command workstation) on a remote rich Web client application have significant data transmission delays. In fact, the number of nodes in a respective hierarchical tree can make the tree unusable when it overwhelms the viewing size of an output display of the user interface. Also, remote operation raises the risk of failed communication, so the user needs to be notified if and when such failures occur. Rich Web client applications generally simplify the handling of server communication by delegating the request and response processing to the underlying browser, with the client side script providing coarse grained response and failure handlers. This works very well in most common rich Web client applications where each message carries a full data set sufficient for a server transaction or for fully updating the client presentation view or some of its components (i.e., pre -built models within the application software). However, when it comes to data communications for large industrial systems, like electric distribution networks, the size and complexity of relationships of the data sets is commonly such that only partial information can be transferred in any given HTTP (hypertext transfer protocol) request that is expected to finish within a user acceptable time. The rich Web client application must reconstruct a view of a respective data set from such partial data set structures, while being robust in the presence of communication and processing errors.

The primary problem in achieving this is that the underlying browser does not provide any request identification information for successful data calls or when communication failures or generic server failures occur. This prevents multiple HTTP data requests from being distinguished.

Prior systems addressed this problem in several ways. Often they did concurrent data retrieval on the server, using the richer and more powerful programming languages at the server, often with multithreaded processes. Serialized data was then sent to the client side. The primary shortcoming of this approach is that it requires a server side footprint for the respective application, and makes the client side tightly coupled with the data server. With the emerging architecture of rich Web client applications or mobile applications which generally rely on low processing power, often scripting languages, and rich data access on the server side, this type of approach is no longer practical.

Many systems simply ignore the coupling of an HTTP request with the processing of its result, by using the forwarding pattern. For example, map browsing systems issue multiple map tile requests, but their expected results are forwarded directly to specific locations, with specific magnification ratios, in the browser window shown in an output display of the user interface on the client side. Thus, if a tile request succeeds, that part of the map is displayed and, if a tile request fails, that part of the map is missing from the display. But the system does not treat this as a problem. Upon subsequent zooming or panning around the map view by the user, the system will make requests for some of the same map tiles, and if they are loaded then they will get displayed as part of the map view.

Disadvantageously, without handling the concurrent HTTP requests from the client side scripts/code, rich web client applications are tightly coupled with a server side component and lack flexibility for individual customization. When the client side scripts operate without associating individual requests to individual objects and visualized controls, it becomes impossible to notify the user with proper detail when failures occur. Thus, this approach can't scale to large and complex systems. When systems don't handle the problem of having large numbers of child nodes in individual tree nodes, the interactive browsing by a user becomes hard due to loading latency and the visibility of the tree structure can be lost by focusing on large groups of sibling nodes.

There are several existing applications and frameworks that relate to displays of hierarchical data, as provided by an electric distribution network, arranged as an expandable tree. Flex is a software development kit to build rich Web client applications. Flex tree control provides the basic infrastructure for an interactive tree control with a rich user interactivity and ability to dynamically update the tree data with corresponding updates to the actually displayed tree structure and individual node details. This control provides an open interface for extending the functionality of the component in various ways, but it does not provide the scalability and error handling features that are desirable for handling hierarchical trees of an electric distribution network, nor does it integrate the tree with a data server.

The Microsoft server-backed tree control in ASP.Net allows multiple tree nodes to be loaded in parallel when the user clicks on them (i.e., selects and activates them using a suitable graphical user interface). However, the Microsoft tree control is implemented as a server side code -behind component that feeds the display-only visual component. As noted above, the server side implementation of a concurrent data retrieval mechanism is generally much simpler than a client side approach because it can take advantage of more powerful programming languages, and generally has access to multiple controllable threads. But, server-side supported components are also more adversely affected by any communication errors or problems on the server, and have problems in saving or recovering a user's state after such errors.

Modest Maps/OpenStreetMap (for Flex or for JavaScript) are open source components that provide a scalable and interactive map control with all standard map browsing features. The interactive user browsing is supported by the on-demand loading of map tiles as they become visible. The tiles are structured as a tree of images for various zoom levels and different granularity map rectangles. As the user zooms or pans the interactive map viewer, the map controller determines which tiles need to be displayed, and in what position in the map. The requests for all relevant tiles in a given map view state are sent asynchronously to the map tile server, and left to the browser to serialize within its request concurrence limits. The browser also caches the previously loaded tile images, and can display them when they are present without actually contacting the map server.

As a result, the interactive browsing preserves some visual information, and quickly starts loading additional tiles so the map seems to update with very little latency. Even in case of multiple zooming or panning operations in short sequence, the system has some degree of fault tolerance since failure to load some tile can be partially covered by the continued display of a tile for a different (previous) zoom level, and the most recent request is generally displayed to overlap the previous ones. While the Modest Maps system has some fault tolerance in displaying useful data, it has no error recovery capability once a map tile fails to load. The domain of this system is also very limited to the map browsing, which is a well defined area with well understood interactions, and takes advantage of visual overlap of tile images. It does not handle more generic, complex data structures that can represent, for example, electric grid and load management assets.

SUMMARY OF THE INVENTION

An embodiment of the invention obviates the above problems by providing a computer- implemented method of managing a hierarchal tree visualization for a complex data structure, comprising originating concurrent loading requests for a plurality of subsets of the complex data structure; distinguishing requests of successful loadings from requests of failed loadings; and concurrently updating the hierarchal tree visualization from successful loadings and failed loadings. The hierarchal tree visualization may be decoupled from the complex data structure that is being represented. The concurrently updating step may comprise indicating a loading status at a node of the hierarchal tree visualization pertaining to a respective loading in progress. Also, the concurrently updating step may comprise limiting the scale of node expansion in the updated hierarchal tree visualization and indicating additional information is hidden. Alternatively, the concurrently updating step may comprise initially limiting the scale of node expansion in the updated hierarchal tree visualization and permitting additional node expansion upon further request. The concurrently updating step may also comprise indicating a loading error at a node of the hierarchal tree visualization pertaining to a respective failed loading and permitting a retry of a respective request of a failed loading.

Each loading request may comprise an asynchronous HTTP data request to a server and the distinguishing step may comprise identifying a request of a successful loading by associating a respective callback object and function for the request of a successful loading and identifying a request of a failed loading by associating a respective callback object and function for the request of a failed loading. Also, the loading of a subset of the complex data structure may not block the hierarchal tree visualization.

Another embodiment of the invention may provide a method of retrieving and presenting for display a hierarchal structure of nodes representing various views of a data network, comprising: a) delivering, upon selection of a first node for expansion, an asynchronous data request for loading of node data of the first node to at least one data server containing node information of the data network; b) retrieving and loading the respective node data into the hierarchal structure and displaying the hierarchal structure with the loaded respective node data; c) monitoring the retrieving and loading of the respective node data and displaying a status indicator in the hierarchal structure during the time the retrieving and loading is in progress; and d) processing a failure in retrieving and loading the respective node data and displaying an error message in the hierarchal structure.

The displaying the hierarchal structure with the loaded respective node data may comprise displaying a limited amount of nodes of the hierarchal structure with the loaded respective node data and displaying an indicator of additional available node data in the hierarchal structure. In such case, the indicator of additional available data in the hierarchal structure may be adapted to permit additional available node data to be displayed upon request. The processing a failure step may comprise permitting a retry of the data request for loading of the respective node data. Also, a displayed hierarchal structure may be decoupled from the hierarchal structure of nodes that is being represented. The retrieving and loading step may not block displaying of a respective hierarchal structure. The method may further comprise delivering, upon selection of a second node for expansion, an asynchronous data request for loading of the node data of the second node to at least one data server containing node information of the data network, said delivering being concurrent with the delivering of the asynchronous data request for loading of the node data of the first node. In such case, each data request may comprise an HTTP data request having an event handling function that associates a retrieving and loading of node data with the respective selected node and a failure in retrieving and loading node data with the respective selected node.

Another embodiment of the invention may provide an apparatus for constructing visualizations of the hierarchical data of an electric distribution network, comprising a) a server that operates equipment generating and transmitting electric power at a respective physical site of network; b) a user control that allows a user to interact with the apparatus so as to provide interactive visualizations of the hierarchical data to the user for controlling and communicating with the server; and c) a data server that stores hierarchal data of the network and application software programs for access by the user control and the server, said user control being adapted to provide interactive visualizations by executing a tree viewer application software program that generates concurrent and asynchronous requests to the data server to retrieve hierarchal data of the network, permits partial loading and visualization of hierarchal data of the network, indicates in a visualization an erroneous loading of hierarchal data of the network, and permits retry requests in the case of an erroneous loading, and said visualizations of the hierarchical data being de-coupled from the underlying hierarchal data.

Another embodiment of the invention may provide an apparatus for providing an interactive and on-demand loading tree viewer for network topology structures, comprising a data server storing network data and application software programs, and a processor executing a tree viewer application software program that de-couples a tree view of a network topology structure from associated network topology structure data; generates concurrent, asynchronous requests to the data server to retrieve and load network topology structure data; permits retry requests in the case of an erroneous loading; and updates a tree view with erroneous loading messages and partial loadings of network topology structure data.

Advantageously, the present invention solves the problem of providing a full distinction between multiple HTTP data requests in Flex, a scripting, single -threaded programming language meant for development of rich Web client applications (although the present invention approach is not limited to Flex and can be implemented in any client side framework). The present invention distinguishes the HTTP requests both for successful and failed calls, which are then used for concurrent updates to a complex and large scale visualized data structure. While the browser infrastructure usable by an apparatus or method of the present invention does not allow request identification info associated with an HTTP request, it does associate a callback object and function both for success and failure. The present invention creates a new class instance with the specific purpose of handling the responses for one HTTP request, and that instance can uniquely identify the partial data set that it expects. In this way, an apparatus or method of the present invention can process multiple tree interactions by the user, which can occur in a short period based on a user's interaction with several nodes of a respective tree widget. Additionally, an apparatus or method of the present invention can also handle the scalability of the visual representation by only showing limited number of child nodes at first, and allowing the loading of additional nodes upon explicit request. Finally, an apparatus or method of the present invention also specifically identifies when the details or child nodes of a specific tree node failed to be retrieved, so it can be marked and visualized, as well as allows the user to request a retry of the child expansion operation.

DESCRIPTION OF THE DRAWINGS

For a better understanding of the present invention, reference is made to the following description of an exemplary embodiment thereof, and to the accompanying drawings, wherein:

Figure 1 is a block diagram of a system (simplified) that operates in accordance with an embodiment of the present invention;

Figure 2 is a flow chart of a method carried out in accordance with an embodiment of the present invention;

Figure 3 is a first view of a tree control of the system of Figure 1, in a stable state;

Figure 4 is a second view of the tree control of Figure 3, in a state of loading in progress for certain nodes;

Figure 5 is a third view of the tree control of Figure 3 with loading errors represented in the tree; and

Figure 6 is a fourth view of the tree control of Figure 3 with a node limit indication. DETAILED DESCRIPTION

Figure 1 is a block diagram of an exemplary, simplified control system 10 for electric load management of an electric distribution network that operates in accordance with an embodiment of the present invention. The system 10 comprises a client side command station 12 that allows a user to transmit information, receive information, and otherwise interact/interface with the system 10. The command station 12 may take on various appropriate forms, for example, a desktop computer/workstation, etc. The command workstation 12 may comprise subsystems, such as, data storage media 12a, a processor 12b, a user input/output devices(s) 12c (like displays with graphical user interfaces (GUIs)), etc. The data storage media 12a is adapted to store/access data that is produced by the command station 12 and other system 10 elements, as well as application software programs that may be utilized by the command station 12 and implemented by the processor 12b which directs and carries out the functions of the command station 12. The command station 12 may be located at an appropriate power utility facility of a respective electric distribution network.

The command station 12 is operably connected, via a communications channel 14, to at least one remote server computer 16 (also called simply a "server"). The communications channel 14 may be implemented by physical connections, wireless communications, or a combination, and may utilize appropriate networks, for example, LANS, WANS, the Internet, etc. Communications between system 10 elements may be realized using the Internet and appropriate data communications protocols.

The server 16 comprises sub-systems, such as, data storage media 16a and a processor 16b. The data storage media 16a is adapted to store/access data that is produced by the server 16 and other system 10 elements, as well as application software programs that may be utilized by the server 16 and implemented by the processor 16b which directs and carries out the functions of the server 16. The server 16 may also comprise a user interface device 16c to locally monitor and control the operation of the server 16 and its various elements. The user interface device 16c may comprise appropriate user input/output devices, like displays, storage media, etc. The server 16 may be located at a respective physical site of the power utility assets/facilities and electric loads.

The command station 12 is adapted to control and communicate with the server 16 which is adapted to operate the appropriate equipment generating and transmitting electric power of a respective physical site of the power utility assets/facilities and electric loads. To accomplish this, the command station 12 is adapted to store/access and execute, among other application software programs, a control application software program (also known as a "tree viewer") which may be in the form of a rich Web client application. As noted above, generally, the rich Web client application allows user interface and related activity to run on the command station 12 and data manipulation and operation to run on the server 16. The rich Web client application normally runs inside/atop a Web browser application software program stored/accessed and executed by the command station 12. Also, the server 16 is adapted to store/access and execute, among other application software programs, a server side portion of the control application software program/tree viewer. By executing the control application/tree viewer, the command station 12 may be used to construct, view, and manipulate representations/visualizations of a hierarchical data tree for the electric distribution network. In this way, a user may control the server 16 and, thus, the associated electric load(s).

The system 10 also comprises a data server(s) 18 that is accessible and useable by both the command workstation 12 and the server 16 to upload and download appropriate information and applications software programs, including the control application/tree viewer. The command station 12 and the server 16 are operably connected to the data server 18 via the communications channel 14. Alternatively, the server 16 may be adapted to act as both an application server (as described above) and a data server.

The various elements of the system 10 may be conventional and well known. They may be configured and interconnected in various ways as necessary or as desired. The system 10 is adapted to operate and to implement methods in accordance with the embodiments of the present invention, for example, the method 100 shown in Figure 2.

Figure 2 is a flow chart of a method 100 for constructing representations/visualizations of the hierarchical data of an electric distribution network carried out in accordance with an embodiment of the present invention. Briefly, in order to provide interactive and on-demand loading tree viewer for electrical grid topology structures, the system 10 uses concurrent and asynchronous requests to the data server 18 to retrieve limited parts of the network topology in order to speed up the display at the command station 12 of relevant data in response to user browsing requests. Since the system 10 component (i.e., the control application/tree viewer) is intended for use with very large data structures, it also supports partial loading and presentation of the information, which reduces the communication latency and improves the use of available display screen resources. Further, since complex systems like electric distribution networks must be able to deal with a variety of partial or complete failures in their parts, subsystems, or communication channels, the control application/tree viewer supports graceful degradation in case of a variety of failures on remote systems or communication channels, as well as a retry/recover mechanism for dealing with temporary losses of functionality or connectivity.

Finally, using the control application/tree viewer, the command station 12 constructs and presents a hierarchal tree to the user that only exists at the client side application, and that can correspond to a view of a much more complex data structure or set thereof that resides on one or multiple servers 16.

The system 10 tree viewer may be based on the standard Flex tree control widget, which uses the model view controller paradigm. However, the system 10 tree viewer approach is not limited to Flex and can be implemented in any client side framework. The Flex tree control uses an XML (Extensible Markup Language) hierarchical structure as a model, and this model allows for a very general structure providing the users with wide flexibility for using their existing XML-represented data. The XML structure is marked as a Flex dataProvider for the tree control, thus generating update events whenever something about a respective object changes. The system 10 tree viewer takes advantage of these two aspects of the object model for

improvements in scalability, error resistance, and user friendly display of data retrieval status. Also, the tree viewer in the Flex tree control is a component that produces a standard view of the tree structure in the XML object. The system 10 tree viewer implementation of view control does not make any changes to how the tree is viewed. Rather, the system 10 tree viewer manipulates the XML nodes in the model to give them the right properties so that the standard view will satisfy the system 10 needs.

The Flex tree control performs two primary functions: it updates the displayed parts of a respective tree as a result of user interaction with the nodes (for example, expanding a closed node to show child nodes, or collapsing a node to hide its child nodes), and it updates the entire tree view when changes happen to the model for the visible/expanded nodes of the tree. It also captures all events visible to the tree or any of its individual sub-widgets (icons, labels, indicators), and makes these events available to the containing component for subscription using the Flex AddEventListener mechanism. The system 10 tree viewer doesn't introduce any changes to the Flex tree control, and uses a variety of event listeners to capture the user interactions of interest for supporting the rich, scalable and error resistant tree display. In sum, the method 100 may use the Flex tree control as a visualization and interaction mechanism, and builds scalability, concurrent loading and error handling into the way the respective model object is managed before the Flex tree control widget updates its display.

In operation, a user may operate the command station 12, and utilize the tree viewer, to define the initial state of a respective tree by the initial data loaded into the XML model object (Step 102), which can be just the root node of the tree or some subset or even an entire tree. As the user interacts with the tree (Step 104), e.g., selects and expands/collapses a parent tree node, the child nodes for expanded parent tree nodes are retrieved, added to the model, and represented in the display component and thus visualized at the command station 12 display (Step 106). The nodes that get added subsequently to the XML model object are not distinguishable from the original ones. Figure 3 shows one view of the tree control, in a stable state without any ongoing action. The tree control views may be seen via the command station 12 display.

When a user selects and expands a parent tree node whose child nodes have not been loaded yet, the tree viewer process for loading node data asynchronously is activated (Step 108). Expanding the respective parent node is not a blocking operation, i.e., the GUI of the command station 12 display will not be blocked by the operation even if a node has a large number of children. Each parent node whose child nodes have not been loaded has a generic child node indicating that the loading of related nodes is in progress ("loading indication") (Step 110). Consequently, when the parent node is expanded, the immediate local effect is that the user sees in the command station 12 display an indication (e.g., "loading ...") that the nodes are being loaded. In this way, there is a partial loading and display of the data request for the child nodes.

The node selection and expansion also triggers a tree event which the tree viewer is monitoring. When this event is observed, the tree viewer identifies the respective target/selected node and a respective asynchronous data request for its child nodes can be generated. Node data includes the node's identification information, which is used to make requests to the data server 18 about the child nodes to show in the tree for that node, and the unique tree path from the root node of the tree to the target/selected node, which is used in modifying the corresponding part of the XML tree, in order to make the updated data/child nodes show in the tree. The user can select several nodes to expand in short succession, and the requests will be created and sent from the command station 12 to the data server 18 through the regular Flex HTTP request mechanism, as supported by the host browser of the command station 12. First requests will be submitted to the data server 18, and when the browser limit on concurrent requests is reached, the subsequent requests get buffered and sent as their predecessors are processed and returned. Since the requests are asynchronous, some which require less server processing may be completed faster and return to the command station 12 before longer running requests which were submitted earlier. For this reason, each submitted request has its own instance of event handling component, which takes care of both the successful and failed requests, and updates the XML model object accordingly. This is particularly important for handling failed requests which generally don't include any user or client specific identifying information, but the indication of erroneous loading needs to be associated with the correct expanded node. Note that the term "instance" is well-understood in computer science to refer to a particular type of component, object, etc.

The XML code below illustrates the state of an exemplary parent node before its child nodes are loaded, and how the parameters of a parent node are adjusted after expansion.

Initially, as noted above, the "loading indication" is the only child of a parent node, and as soon as the node is expanded, the indicator is visible automatically, by the normal behavior. The initial value for the attribute "loaded" is empty, allowing the event handler of the respective tree viewer to submit a request for child nodes of this selected parent node.

<FolderNode name="Locals" loaded- ' " isBranch- 'true" useld="2" subtype=""

isDynamic- 'false" path="l .2">

</FolderNode>

When the child nodes are retrieved and inserted into the XML model object, the expanded parent node has its attribute "loaded" set to true, so it will not request loading child nodes again if the user expands the parent node again (Step 1 12). All child nodes are added to the XML node as a list of embedded XML tags of the same type and structure. Also, the retrieved and inserted child nodes replace the initial generic child node in the tree (i.e., the "loading ..." indicator) (Step 114). The following XML code illustrates this updated state of the exemplary parent node:

<FolderNode name="Locals" loaded="true" isBranch="true" useld="2" subtype=""

isDynamic- 'false" path="l .2">

</FolderNode>

Figure 4 shows a second view of the tree control, in the state when two nodes are expanded in a short time and the server data for the expansion calls takes a while to be retrieved. Two (or more) areas of the tree are shown in the process of loading as several parallel requests are submitted by the browser at the command station 12. The parent nodes will get updated with their child nodes when the results arrive, which could happen in any order. Also some of the requests may result in failures (Step 116a) in which case the expanded parent node needs to be marked accordingly (Step 1 16b).

The component of the tree viewer that processes the return and failure events for a given node expansion request is defined in the class TreeRemoteCallsHandler. This class has one required constructor parameter: the specific node in the XML model object that corresponds to the parent tree node whose child nodes are being loaded. This class also has one primary function in the system 10: a call to initiate the process of retrieving the child nodes. This object retrieves the node information from the model reference, it constructs the appropriate request for child nodes (which can be conditional on the node information or options specified for this instance), and it then submits the request to the data server 18, while subscribing its own event handlers to process the successful or failed return for the service call.

The following XML code shows the instantiation and invocation sequence for the TreeRemoteCallsHandler from a container handling the update to a tree node (with treeXML being the actual node in the XML model for the displayed tree): treeRemoteCalls = new TreeRemoteCallsHandler(treeXML:XML)

_treeRemoteCalls.retrieveAggregationOneLevel(aggNodeld, showSiteLevelOption, nodeLimit} ;

In this example, showSiteLevelOption specifies whether leaf level nodes should be shown in the tree at all since this is an optional behavior. In situations where aggregation nodes are being managed, the leaf nodes may not be of interest. In situations where the electric distribution network topology is being browsed to find individual loads of interest, showing the leaf nodes (individual loads or meters) is necessary. The parameter "nodeLimit" specifies the maximum number of child nodes to request in expanding a given tree node. If a node has more child nodes than the limit, the requested number is returned (Step 118a), and a warning/subnode(s) can be displayed informing the user of the truncation and providing the ability to load additional nodes upon user request (Step 118b).

The constructor of the TreeRemoteCallsHandler has one input parameter with reference to the XML node which needs to be expanded. The request result or error message, in case of fault, will be added to that XML tree as child XML nodes, and the existing XML child node indicating loading in process gets replaced by the new nodes. When the loading of child nodes succeeds, the parent node in the model is also updated to indicate its "loaded" attribute as "true".

TreeRemoteCallsHandler also has two events that allow the container to be informed and trigger additional actions when the loading of child nodes succeeds or fails:

[Event(name="treeLoadDataCompleted",

type="com.scr.drms. events .AggregationTreeViewEvents")]

[Event(name="treeLoadDataFail", type="com.scr.drms.events.AggregationTreeViewEvents")]

When the user expands a respective node, the TreeRemoteCallsHandler instance is created. That instance is responsible to send a request to the data server 18 and get the response from it. Therefore, in the case of failure, there is a dedicated instance of the faultFunction to handle the fault. Without doing that, it would be impossible to distinguish which node has failed. If any of the requests to the data server 18 fails, it will have no impact on other concurrent requests, since each is handled by a dedicated call handler. The node which failed to expand will be marked and an error message will be displayed as the child node (Step 116b). When the child nodes request fails, the "loaded" attribute of the parent node is not modified to "true". Subsequent user interaction with this node will be able to trigger another call to try to load the child nodes if the previous call failed, for example, due to some transient error or communication problem (Step 1 16c).

Errors in loading child nodes, or exceeding the specified limit for child nodes are marked the same way, i.e., by adding a child node to the model object with the information that clearly indicates the issue. Simply by inserting the appropriate node into the model object, the tree viewer/Flex tree control updates the view and indicates the uncovered issue or error in a way that clearly associates it with the parent node that it applies to. Also, the tree event handlers can recognize these nodes, and perform an appropriate action when the user interacts with them. For error indications, the user via the command station 12 can re-try the request (i.e., re-select and re- expand parent node), and display the child nodes normally once the re-tried request succeeds (Step 116c). Figure 5 shows a third view of the tree control, specifically how errors are represented in the tree, and the following XML code shows how this node is represented in the XML model object:

<FolderNode name="SIM-0" path="" useld="35" isDynamic="false" loaded=" "

isBranch="true">

<FolderNode name="Unable to find child aggregations sites" path=""

icon="erroriconSymbol" loaded=""/>

</FolderNode>

When some parent nodes have too many child nodes, the displaying of all these child nodes causes a long delay in loading the data. In addition, it makes the tree view almost unusable because the large number of child nodes on one parent node pushes the tree structure out of view of a typical display screen at the command station 12. In order to allow the tree view to be used for very large data sets, the tree viewer limits the number of child nodes it shows for any given parent tree node (Step 1 18a). The tree viewer shows a limited number of child nodes, and if the limit is exceeded, it also adds an indication that additional elements are hidden (Step 118b). This may be just an indication without interactivity, or the tree viewer can recognize the overLimit node and make additional requests for more child nodes (with or without limits, depending on the application). Figure 6 shows the overLimit indication as an added tree node ("Show More") with the possibility of showing all child nodes upon an additional expansion. The XML code below shows the encoding of such a node in the model object:

</FolderNode>

Accordingly, the system 10 integrates the concurrent and fully object mapped HTTP data loading requests with client side scripted code that does not introduce new threads or blocking of the user interaction. The system 10 also handles data loading errors and limits the scale of expansion for any node, as well as, notifies the user in these situations and allows them to explicitly request a retry or additional information. Finally, by being a strictly client side control, the system 10 tree viewer is decoupled from any individual server technology, and can be used to access and browse heterogeneous data servers while providing the user with a single unified view.

The system 10 supports interactive browsing of a hierarchical structure of load management nodes representing various views of a respective electric distribution network. This permits, then, the management of energy consumption across large utility-scale networks of aggregated loads, including demand response processes. The system 10 can address generic, complex structures that can represent electric grid and load management assets, but can also be used to browse any type of complex data sets consisting of objects and heterogeneous relationships. This includes any remote rich client interactive application working with large data sets and searches (including standard web-based applications and native mobile apps used to access complex data).

It is noted that, in addition to the points detailed above, the present invention differs in other ways with the Microsoft tree control. For example, unlike the tree viewer, the Microsoft tree control does not cover the ability to limit the amount of detail in case some tree node has a very large number of child nodes, or the ability to mark a part of the tree as failed to load and to allow a later retry. Even if these aspects were developed for the Microsoft tree control, they would be developed in the server side code, not as part of a rich Web client application. Further, the system 10 decouples the visualization of the tree from the actual data structure that is being represented, while the Microsoft component actually maintains a tree object or data source coupling in the code behind, and then displays the visualization of that tree. In the system 10, the tree can correspond to any XML structure, and since the XML is constructed on demand, it may represent an arbitrary collection of data sources, including distributed and heterogeneous servers.

Other modifications are possible within the scope of the invention. For example, the command station 12 may be adapted to control and communicate with more than one server 16, each server 16 being adapted to operate the appropriate equipment generating and transmitting electric power of a respective physical site of the power utility assets/facilities and electric loads. Also, various communications protocols may be utilized on the communications channel 14 to communicate data signals among the command station 12, the server 16, and the data server 18. Also, in lieu of user action, the initial state of a respective tree may be automatically defined by the system 10 which may be based on prior made settings/user preferences or it may be a dynamic activity.

Also, although the steps of the method 100 have been described in a specific sequence, the order of the steps may be re-ordered in part or in whole and the steps may be modified, supplemented, or omitted as appropriate. Also, the method 100 may use various well known algorithms and software applications to implement the steps and substeps. Further, the method 100 may be implemented in a variety of algorithms and software applications. Further, the method 100 may be supplemented by additional steps or techniques. It is also understood that the method 100 may carry out all or any of the steps using real-time data, stored data from a data archive or database, data from a remote computer network, or a mix of data sources.

Also, the various described instrumentation and tools may be configured and

interconnected in various ways as necessary or as desired. Further, although in the described method 100 the user may use self-contained instrumentation and tools, the user may use other instrumentation or tools in combination with or in place of the instrumentation and tools described for any step or all the steps of the method 100, including those that may be made available via telecommunication means. Further, the described method 100, or any steps, may be carried out automatically by appropriate instrumentation and tools or with some manual intervention.

Claims

WHAT IS CLAIMED IS:

1. A computer-implemented method of managing a hierarchal tree visualization for a

complex data structure, comprising:

a. originating concurrent loading requests for a plurality of subsets of the complex data structure;

b. distinguishing requests of successful loadings from requests of failed loadings; and

c. concurrently updating the hierarchal tree visualization from successful loadings and failed loadings.

2. The method of claim 1 , wherein the hierarchal tree visualization is decoupled from the complex data structure that is being represented.

3. The method of claim 1, wherein the concurrently updating step comprises indicating a loading status at a node of the hierarchal tree visualization pertaining to a respective loading in progress.

4. The method of claim 1, wherein the concurrently updating step comprises limiting the scale of node expansion in the updated hierarchal tree visualization and indicating additional information is hidden.

5. The method of claim 1, wherein the concurrently updating step comprises initially

limiting the scale of node expansion in the updated hierarchal tree visualization and permitting additional node expansion upon further request.

6. The method of claim 1, wherein the concurrently updating step comprises indicating a loading error at a node of the hierarchal tree visualization pertaining to a respective failed loading and permitting a retry of a respective request of a failed loading.

7. The method of claim 1, wherein each loading request comprises an asynchronous HTTP data request to a server and the distinguishing step comprises identifying a request of a successful loading by associating a respective callback object and function for the request of a successful loading and identifying a request of a failed loading by associating a respective callback object and function for the request of a failed loading.

8. The method of claim 1, wherein loading a subset of the complex data structure does not block the hierarchal tree visualization.

9. A method of retrieving and presenting for display a hierarchal structure of nodes representing various views of a data network, comprising:

a. delivering, upon selection of a first node for expansion, an asynchronous data request for loading of node data of the first node to at least one data server containing node information of the data network;

b. retrieving and loading the respective node data into the hierarchal structure and displaying the hierarchal structure with the loaded respective node data; c. monitoring the retrieving and loading of the respective node data and displaying a status indicator in the hierarchal structure during the time the retrieving and loading is in progress; and

d. processing a failure in retrieving and loading the respective node data and

displaying an error message in the hierarchal structure.

10. The method of claim 9, wherein displaying the hierarchal structure with the loaded

respective node data comprises displaying a limited amount of nodes of the hierarchal structure with the loaded respective node data and displaying an indicator of additional available node data in the hierarchal structure.

11. The method of claim 10, wherein the indicator of additional available data in the

hierarchal structure is adapted to permit additional available node data to be displayed upon request.

12. The method of claim 9, wherein processing a failure comprises permitting a retry of the data request for loading of the respective node data.

13. The method of claim 9, wherein a displayed hierarchal structure is decoupled from the hierarchal structure of nodes that is being represented.

14. The method of claim 9, wherein the retrieving and loading step does not block displaying of a respective hierarchal structure.

15. The method of claim 9, further comprising delivering, upon selection of a second node for expansion, an asynchronous data request for loading of the node data of the second node to at least one data server containing node information of the data network, said delivering being concurrent with the delivering of the asynchronous data request for loading of the node data of the first node.

16. The method of claim 15, wherein each data request comprises an HTTP data request having an event handling function that associates a retrieving and loading of node data with the respective selected node and a failure in retrieving and loading node data with the respective selected node.

17. An apparatus for constructing visualizations of the hierarchical data of an electric

distribution network, comprising:

a. a server that operates equipment generating and transmitting electric power at a respective physical site of network;

b. a user control that allows a user to interact with the apparatus so as to provide interactive visualizations of the hierarchical data to the user for controlling and communicating with the server; and

c. a data server that stores hierarchal data of the network and application software programs for access by the user control and the server, said user control being adapted to provide interactive visualizations by executing a tree viewer application software program that generates concurrent and asynchronous requests to the data server to retrieve hierarchal data of the network, permits partial loading and visualization of hierarchal data of the network, indicates in a visualization an erroneous loading of hierarchal data of the network, and permits retry requests in the case of an erroneous loading, and said visualizations of the hierarchical data being de-coupled from the underlying hierarchal data.

18. An apparatus for providing an interactive and on-demand loading tree viewer for network topology structures, comprising a data server storing network data and application software programs, and a processor executing a tree viewer application software program that de-couples a tree view of a network topology structure from associated network topology structure data; generates concurrent, asynchronous requests to the data server to retrieve and load network topology structure data; permits retry requests in the case of an erroneous loading; and updates a tree view with erroneous loading messages and partial loadings of network topology structure data.