OFFLINE CONFIGURATION AND DOWNLOAD APPROACH

Abstract

A system for creating a station having a configuration and making the station active within a supervisor application without a need of actual site controller hardware. The configuration may be changed. The new station may be downloaded with the changed configuration to a site controller. Multiple steps for effecting the present configuration design and station download may automatically be accomplished by fewer steps.

Description

BACKGROUND

The invention pertains to software and controllers and particularly to controller configurations. More particularly, the invention pertains to configuration designing.

SUMMARY

The invention is an approach for creating a station with a configuration and making it active within a supervisor application without a need of actual site controller hardware. The configuration may be changed. The new station may be downloaded to a site controller. The approach may automate multiple steps into one or more sequences of operations.

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 is a flow diagram for an offline configuration and download approach;

FIG. 2 is a flow diagram of a jar transfer which is one of the features in an offline configuration and download;

FIG. 3 is a diagram of interaction among a user, a supervisor, and a controller;

FIG. 4 is a flow diagram of a user's case for a manual backup/restore;

FIG. 5 is a flow diagram of a restore for a redownload; and

FIGS. 6-25 are diagrams of screen shots showing significant portions of a process of the present application or approach.

DESCRIPTION

The Tridium™ (Tridium) NiagaraAX™ (NiagaraAX, Niagara) Framework™ (framework) may particularly be a base software application or approach for developing a site offline configuration and download feature. The feature may capture improvements made to an existing Niagara Workbench™ (workbench) user interface application to provide the customer a desired user experience in creating controller configurations and deploying them to site controllers.

The Novar™ (Novar) Opus™ (Opus) Supervisor™ (supervisor) may provide a basis of the present application or approach. The framework may generally be a software platform for integrating diverse systems and devices regardless of manufacturers, or communication protocols into a unified platform which can be managed and controlled in real time over an internet using a standard web browser. The supervisor may be a software platform built on the framework. The supervisor may communicate with site controllers via an intranet or internet. A site controller may be referred to as an XCM (executive control module) controller (XCM).

The supervisor may serve real-time graphical information displays to standard web-browser clients and provide server-level functions such as centralized data logging, archiving, alarming, real-time graphical displays, master scheduling, system-wide database management, and integration with Novar Enterprise™ (enterprise) software. The enterprise software family may be used for energy analysis and business-critical requirements such as alarm handling, systems configuration, data collection and performance monitoring.

A definition of “creating a site configuration offline” may indicate that a site controller configuration is created and made active within a supervisor application without a need of actual site controller hardware. A customer of a Novar retail business may wish to create a site configuration offline and, when complete, initiate a download of this configuration to a site controller. Upon completion of the download, the customer may want to have a copy of the downloaded site configuration safely backed up within the supervisor. The customer may want these operations to require minimal user interaction with the supervisor application.

The NiagaraAX workbench may be capable of approaches for creating an offline site controller configuration and then deploying it to a remote site controller. However, there are numerous user interactions that may be required to accomplish this task. The present approach may minimize these user interactions by automating multiple steps into sequences of operations.

The following items are individual user manual steps which may be required when using Niagara workbench technology. One may note that the term “supervisor” may be used to refer to the workbench application. The steps may incorporate the following: 1) Use a toolbar option to create a new site controller station baseline configuration within the supervisor; 2) Provide a unique station name based on guidelines using best practices; 3) Provide a unique port number for running within the supervisor; 4) Navigate to an application director view within the supervisor; 5) Select the newly created station and invoke a start command; 6) Connect the workbench to the running station within the supervisor; 7) Perform site specific configuration additions and changes; 8) Change the station to correct a port number for deployment; 9) Stop the station running within the supervisor; 10) Connect the workbench to a site controller platform service; 11) Navigate to the software manager view; 12) Ensure that required jar (Java archive) files are installed and up to date; 13) Navigate to the station copier view; 14) Select the new station to download and initiate a download; 15) Connect the workbench to the newly deployed site controller; and 16) Initiate a backup operation to create a safe archive of the site configuration. This set of steps may be simplified with some of the steps being automatically performed by the present application or approach.

The present application may provide the user an ability to create a logical, hierarchal structure representing the user's business and site deployment structure. A solution for the issue noted herein may be to provide a user friendly, streamlined experience to create and deploy the user's site configurations. Here, the user may perform the following steps: 1) Select a site node and use a right click menu option to create a new site controller station baseline configuration—This user action 1) may accomplish steps 1 through 6 specified for the related application or approach noted herein, by automatically performing the following four sub-steps: a) A unique station name may be constructed from hierarchal component branch names; b) The application may assign a unique temporary port number used while running in a supervisor; c) The station may be started within the supervisor environment; and d) The workbench application may be connected to the running station; step 2) Perform site specific configuration changes which may include additions and deletions—This may be the same user action as step 7 specified for the related application or approach noted herein; 3) Set a site controller IP address into an executive property sheet; 4) Select a new site controller node and use the right click menu option for a download, and to initiate the download—This user action may accomplish steps 8 through 16, specified for the related application or approach noted herein, by automatically performing the following six sub-steps: a) The present application or approach may stop the running station within the supervisor and release the temporary port number; b) The application may connect to the site controller platform service; c) The application may confirm that required jar files are installed; d) The application may perform a station download; e) The application may connect to the newly deployed site controller; and f) The application may perform a backup operation.

The present application or approach may be implemented as part of a “profiled” Niagara workbench. This means that the base workbench may be used as a basis and then extended to provide the desired user features which are needed. The Niagara framework may provide a public application programming interface to allow many of the manual operations to be initiated programmatically. To implement the present application, the application may consolidate the calls to the application program interfaces (API's) into sequences and may be initiated by simple and intuitive menu options.

In the flow diagrams in the present description, various instances of actions may be referred to as steps, blocks, actions, and the like. However, for illustrative purposes, the instances may be referred to as occurring at the symbols in the respective diagrams.

FIG. 1 is a diagram which indicates an overall flow of the present approach. The approach may go from a start place 121 to a symbol 122 where a new group, site and XCM may be created. At symbol 123, a station may be constructed with a unique station name. Additionally, a unique temporary port number may be assigned at symbol 124. The station may be started within a supervisor (i.e., begin a run mode) at symbol 125 to be running. A user may perform site specific configuration additions and changes at symbol 126. Changes may incorporate additions and deletions. At symbol 127, a download may be initiated. A question arises at symbol 128 as to whether an XCM address is available for a download. If the answer is no, then an XCM IP address may be accepted to download at symbol 129 and then go to symbol 130, or if an address is already had then go to symbol 130 where the simulated station is stopped from running (i.e., end the run mode or put into a non-run mode) at the supervisor. Then a question of whether the JACE station is running may be asked at symbol 131. If the answer is yes, then the station may be stopped at the XCM (JACE) as indicated at symbol 132. If the answer is no, then the station may be deleted at the XCM (JACE) at symbol 133. A question at symbol 134 concerns whether the XCM has all of the required JAR files to initiate a download. If not, the all of the required JAR files may be copied from the Opus client to the XCM (JACE) at symbol 135. If the question is yes, then at symbol 136, the offline station may be copied from the supervisor to the XCM. The XCM may be rebooted and the station started at symbol 137. An enterprise hierarchy may be created at the JACE level (i.e., Group->Site->XCM) according to symbol 138. An initial backup may be initiated from the XCM to the supervisor at symbol 139. At symbol 140, the approach may be stopped.

FIG. 2 is a flow diagram of a jar transfer approach as it may relate to an offline configuration and download to a site controller. From a start 11, there may be a module dependency list generated from config.Bog, platform.bog and px files at symbol 12. Opus™ (Opus) and Niagara related jars may be added to a generated list at symbol 13. At symbol 14, client and XCM (executive control module) Niagara versions may be compared. If the result of a comparison reveals the versions to be the same, then an inter-dependent module list may be generated from a client at symbol 15. If the result of the comparison reveals the versions to be different, then an inter-dependent module list may be generated from the XCM at symbol 16 and the download may be continued at symbol 18.

After generating an inter-dependent module list from the client at symbol 15, the availability of all of the dependent modules in the XCM may be checked for at symbol 17. If all of the dependent modules are available in the XCM at symbol 17, then the download may be continued at symbol 18. If all of the dependent modules are not available in the XCM at symbol 17, then all the missing modules may be transferred at symbol 19 and on to continue download at symbol 18.

After generating an inter-dependent module list from the XCM at symbol 16, the availability of all of the dependent modules in the XCM may be checked for at symbol 21. If all of the dependent modules are available in the XCM at symbol 21, then the download may be continued at symbol 18. If all of the dependent modules are not available in the XCM at symbol 21, then a question of whether a missing module list contains only Opus jars may be asked at symbol 22. If the answer at symbol 22 is no, then the download may be stopped and the missing modules be shown at symbol 24. If the answer at symbol 22 is yes, then the Opus modules may be transferred at symbol 23 and the download continued at symbol 18.

FIG. 3 is a diagram of interaction activity of the user 41, Opus supervisor 42 and the XCM 43. User 41 may enter the XCM IP address and credentials at a line 44 and initiate download( ) at a line 45 going from the user 41 to supervisor 42. There may be a stop offline station( ) at line 46 going from user 41 to supervisor 42. From Opus supervisor 42 to XCM 43, the items may include a stop running XCM station( ) at a line 47, a check( ) for dependency jars at line 49, a transfer dependent jars to XCM( ) at line 38, a delete existing XCM station( ) at line 48, a create new station at XCM( ) at line 52, a reboot XCM( ) at line 51, a start station in XCM( ) at line 39, a create enterprise hierarchy at XCM( ) at line 50, and an initial backup( ) at line 53. The Opus supervisor 42 may indicate to user 41 the XCM download as successful( ) at line 54.

FIG. 4 is a flow diagram of a user's case for a manual backup/restore. A user 56 may go to an Opus workbench 57 and then to an Opus supervisor 58 to initiate a backup in an XCM node at symbol 59. Then a backup dist (distribution) file may be generated at symbol 61.

FIG. 5 is a flow diagram of a restore for a redownload. A user 81 may go to an Opus workbench at symbol 82 and connect to an Opus supervisor at symbol 83. At symbol 84, the user 81 may initiate a restore for a redownload at a dist file under a backup folder. The dist filed may be restored at the supervisor for an offline simulation at symbol 85. A download flag set to false at symbol 86 may be included in the action at symbol 85.

FIGS. 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24 and 25 are diagrams of screen shots 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, and 119, respectively, which show portions of a process of the present application. The screen shots are from a demonstration provided by a WebEx™ player with a label 91, as shown in screen shot 101 of FIG. 6, revealing the time of each screen shot taken during the process.

In the present specification, some of the matter may be of a hypothetical or prophetic nature although stated in another manner or tense.

Although the present system has been described with respect to at least one illustrative example, many variations and modifications will become apparent to those skilled in the art upon reading the specification. It is therefore the intention that the appended claims be interpreted as broadly as possible in view of the prior art to include all such variations and modifications.

Claims

1. A method for offline configuring and offloading, comprising: creating in a software platform, outside of a site controller, an offline station having a configuration;running the offline station;changing the configuration; andproviding an address for the offline station;stopping the offline station;stopping an existing station at the site controller;deleting the existing station; anddownloading the offline station to the site controller.

2. The method of claim 1, further comprising: rebooting the site controller; andstarting the offline station at the site controller.

3. The method of claim 2, further comprising backing up the offline station from the site controller to the software platform.

4. The method of claim 1, wherein the software platform is a supervisor.

5. The method of claim 1, wherein the address for the offline station comprises a unique station name.

6. The method of claim 1, wherein the address for the offline station comprises a unique temporary port number.

7. The method of claim 1, further comprising assuring that required jar files are at the site controller prior to downloading the offline station to the site controller.

8. The method of claim 2, further comprising creating an enterprise hierarchy after rebooting the site controller and starting the offline station at the site controller.

9. The method of claim 1, wherein: the software platform is an OPUS supervisor; andthe site controller is an XCM controller.

10. An offline configuring system comprising: a software platform; andan offline station having a configuration on the software platform; andwherein:the offline station is put into a run mode;changes are made to the configuration;the offline station is put into a non-run mode;a site controller is checked to note if an existing station is in a run mode;if the existing station is in a run mode, then the existing station is put into a non-run mode and eliminated; andthe offline station is downloaded to the site controller.

11. The system of claim 10, wherein: the site controller is rebooted; andthe offline station is put into the run mode at the site controller.

12. The system of claim 11, wherein the offline station is backed up from the site controller to the software platform.

13. The system of claim 10, wherein prior to the offline station being downloaded to the site controller, the site controller has all needed jar files.

14. The system of claim 11, wherein: the software platform is a supervisor; andan enterprise hierarchy is created at the site controller.

15. The system of claim 10, wherein: the offline station has a unique station name; andthe offline station is assigned a temporary port number.

16. The system of claim 10, wherein the software platform is an OPUS supervisor; andthe site controller is an XCM controller.

17. A method for providing offline configuring and offloading, comprising; selecting a site node in a supervisor environment;clicking a menu option to create a new site controller station baseline configuration;performing site specific configuration changes;setting a site controller IP address into an executive property sheet;selecting a new site controller node; andclicking a menu option for a download.

18. The method of claim 17, wherein selecting site node and clicking a menu option to create a new site controller station baseline configuration automatically accomplishes the following: constructing a unique station name;assigning a unique temporary port number used while running in the supervisor environment;starting the station within the supervisor environment; andconnecting a workbench application to the running station.

19. The method of claim 17, wherein the selecting a new site controller node and clicking on a menu opinion for a downloading automatically accomplishes the following: stop the running station within the supervisor environment and release the temporary port number:connect to a site controller platform service;confirm an installation of jar files as required to a newly deployed site controller;perform a station download;connect to the newly deployed site controller; andperform a backup operation of the station at the newly deployed site controller.

20. The method of claim 19, wherein the supervisor environment is of an OPUS supervisor; andthe newly deployed site controller is an XCM controller.