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:
The present application is related to U.S. patent application Ser. No. 12/260,046, filed Oct. 28, 2008, entitled “A Building Management Configuration System”. U.S. patent application Ser. No. 12/260,046, filed Oct. 28, 2008, is hereby incorporated by reference. The present application is also related to U.S. patent application Ser. No. 12/703,476, filed Feb. 10, 2010, entitled “A Multi-Site Controller Batch Update System”; and U.S. patent application Ser. No. 12/643,865, filed Dec. 21, 2009, entitled “Approaches for Shifting a Schedule”; all of which are hereby incorporated by reference. 
     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&#39;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&#39;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&#39;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&#39;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-&gt;Site-&gt;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&#39;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.