Supervisor user management system

An approach for control of users relative to access to controllers of a site in a hierarchy of controllers and building equipment. When a user of a customer has established a read write connection to a site controller, the customer does not necessarily want any subsequent user to establish a read write connection to the site controller or another controller within the same site and also make changes, for example, to settings of building equipment. Thus, a subsequent user may be allowed a read only connection and just be able to view building equipment information. When the first user has disconnected either intentionally or by inactivity, the site controller may be cleared allowing a subsequent user to obtain a read write connection. If the first user is inactive but fails to disconnect from the controller, an auto log-off provision may disconnect the user after a specified period of inactivity.

BACKGROUND

The present disclosure pertains to controllers and particularly to hierarchies of controllers and components. Particularly, the disclosure pertains to users and the respective controllers.

SUMMARY

The disclosure reveals control of users relative to access to controllers of a site in a hierarchy of controllers and components. When a first or primary user's client application has established a read write connection to a site controller, a customer does not necessarily want any subsequent or secondary users allowed a read write connection to the site controller within a site of other controllers and also make changes. The secondary users may obtain a read only connection and therefore will only be able to view site controller information and not be allowed to make changes. When the primary user has disconnected either intentionally or by inactivity, the site controller may be cleared thereby allowing the next user connection to be given full read/write permission. User behavior may be extended to all controllers within the same site. This means that if the primary user connects to a first site controller, then virtually all of the other site controllers within the site may have knowledge of this event, so as to ensure that a secondary user connection to any of the controllers of the site is given read only access at any controller of the site. Another aspect to the present approach may ensure that the primary user cannot prevent secondary user access if the first user fails to disconnect from the site. If the primary user connects to a site controller and leaves for the day, the connection may remain, thus blocking secondary users from achieving full access. However there may be an auto log-off provision where, after a specified time period of inactivity, the primary user can be disconnected.

DESCRIPTION

A customer using the Novar™ Opus™ supervisor may manage and communicate with hundreds or thousands of remote site controllers from a centralized location via the users' intranet. Each of the site controllers may be referred to as an XCM (executive control module) or an XCM controller. The XCM or site controller in turn may manage and communicate with tens or hundreds of field controllers within the site that perform real time control of building equipment such as HVAC units, lighting panels, refrigeration circuits, and so forth.

FIG. 1is a diagram of an example hierarchy160of the supervisor161. Numerous site controllers162may be managed by supervisor161. Numerous field controllers may be managed by a site controller162. Numerous components of building equipment164may be managed by a field controller.

The present system and approach, as described herein and/or shown in the Figures, may incorporate one or more processors, computers, controllers, user interfaces, wireless and/or wire connections, and/or the like, wherever desired or needed.

The previous Opus system may be configured to allow for multiple, simultaneous user access logins. The customer may have a scenario where there may be multiple users responding to alarms or alert events that have been reported from the same site of XCM controllers. When a user elects to “work” an alarm, the user may use the Opus Architect™ to navigate the supervisor to establish a connection with a site XCM controller. Alternately, the user may be using a web browser to do the same. Once connected, the user may observe runtime statuses and make setpoint adjustments to diagnose the alarm condition. An issue is that more than one user may be simultaneously connected to the same XCM or an XCM within the same site and make changes affecting each other. Also, the customer operational process may be for the user to initiate a field technician to visit the site to resolve a physical issue. If two users are working two different issues from the same site, they may potentially initiate two field technician visits incurring double the maintenance cost. The probability of multi-user conflicts or incurring the extra maintenance costs appears higher as the customer may have 20 to 30 simultaneous users working alarms from over 5000 sites.

When the first user's client application has established a connection to the XCM, the customer does not necessarily want any secondary users to be allowed to connect to an XCM within the same site and make changes. The secondary users may connect but will only be able to view the XCM information and will not necessarily be allowed to change settings. When the secondary user connects, the user may be informed that another primary (first) user (by name) is connected and the second user may be assigned read only privileges. When the first user has disconnected either manually or by inactivity, the XCM will clear allowing the next user connection to be given full read/write permission. If a secondary user has been given read only permission, the user may need to disconnect and reconnect to establish full permission. Additionally, the customer may ask to extend this behavior to all XCM controllers within the same site. This means that if the first user connects to XCM #1, then virtually all of the other XCMs within this site may have knowledge of this event, so as to ensure that a second user connection to any XCM is given read only access.

Also, a secondary aspect to the present approach may ensure that the first primary user cannot prevent secondary user access if the first user fails to disconnect from the site. The previous Opus implementation does not necessarily time out user client sessions. If the first user connects to an XCM and leaves for the day, the connection may be maintained blocking other secondary users from full access. The present approach may include an auto log-off provision where, after a specified time period, the user client session may be disconnected.

A feature summary may encompass the following items. 1) A feature may incorporate single user write access across all XCMs within a single site. When a write-enabled user connects to an XCM, the user may have sole write access to this XCM and the other XCM's within the same site. 2) The feature may apply to users configured with write permission. Users without write permission may virtually always be given their configured permissions. 3) When the first write-enabled user connects to a site XCM, the user may be assigned its configured permissions. 4) When a secondary write-enable user connects to a site XCM, the user may be assigned read only permissions. 5) When a secondary write-enabled user connects to a site XCM, the user may be informed that the user has been given read only permission because another primary user (by name) is already connected to a site XCM. 6) A user client auto log-off after a specified time out may ensure that a site is not left blocked by an inactive primary user.

Issues may incorporate allowing un-restricted multi-user access regardless of user permission levels, and a user leaving a client connected to an XCM indefinitely.

A new single user access login service feature may be developed using two new service components. (Incidentally, labels like OpusSingleUserService may be broken up with spaces in the present description.) First, an Opus Single User Service may be added into the XCM Services and may operate within the Opus XCMs. Second, an Opus Single User Client Service may operate within the Opus Architect client application. The Opus Single User Service may be available in the Opus Enterprise™ module. The Opus Single User Client Service may be installed automatically in the Opus Architect client application and may be verified in the client “Workbench Service Manager” option in the Tools menu. In addition, the user may need to ensure that virtually all site XCMs have their respective Niagara™ networks configured to allow communication with all of the other site XCM's. This may be to ensure that the single user sign-on service operates for all of the XCM's within a site.

When configured, the services may allow only the first write enabled user's client application to establish a connection and have full access to an XCM within the site. This same user may also have the same access to all other XCMs within the same site. The service may prevent secondary write capable users from being connected to any XCM within the site. When the secondary write user connects, the user may be informed that another user (by name) is connected and the user may continue in its connection with read only privileges. In order for this automated reduction of user access privileges to occur, in one scenario, the built-in “guest” user may have to be enabled and configured for read only. This guest user may be used by the service to allow the secondary user to proceed with read only access. If the quest user is disabled or not configured, the service may inform the secondary user that there is already a primary user connected and that the secondary user needs to re-login as a read-only user. The secondary user session may then be disconnected and access is prevented. This element may go about performing the duties necessary to fulfill its responsibilities. This approach may encompass a description of any algorithms used, changes of state, relevant time or space complexity, concurrency, methods of creation, initialization and cleanup, and a handling of exceptional conditions.

The auto log-off should be configured within the Opus Auto Log Service added to the Opus Supervisor. The user may enable the auto log-off and set a notification time period and a force disconnect time period. The notification time period may be the amount of inactivity time that expires from the last time the user accessed an XCM. When this notification time expires, the client application may inform the user that the XCM session is about to be disconnected. The user may have the option to manually reset this time period allowing continued access. If the user does not respond to the notification dialog, the force-disconnect time period may be observed and when it expires the XCM session may be forcibly disconnected. This may ensure a user that leaves for the day does not necessarily lock out other users.

The Opus Single User Service may perform the server side user login synchronization. It may accomplish this by tracking the login attempts and sharing the active user information between the peer XCMs within the same site. This service may also determine when a secondary user connection occurs, and establish a block on the connection.

When an Opus Architect user connects to the XCM, the Opus Single User Client Service may read the user login status maintained in the Opus Single User Service. If the user is found to be “blocked”, the Opus Single User Client Service may proceed to reject the login attempt.

InFIG. 2, a diagram of the Opus Architect client view11shows a dialog12presented to the secondary user as the user attempts connecting to an XCM where another primary user is already connected.

FIG. 3is a diagram of an image13showing the Opus Sync Client Service and the Opus Auto Log Off Client Service installed as client side companion services, with indications of installation, auto start and running status.

The following use cases may be used to accomplish the single user access.

FIG. 4is a diagram14of a single user access. An Opus user15may have a logical interface, as indicated by a system boundary16, between user15and a system. The items interfaced by user15may incorporate a configure Opus sync service17, a login user18and a logout user19. A feature may allow the single user write access across all XCMs within a single site. When a write-enabled user connects to an XCM, the user may have sole write access to this XCM and other XCMs within the same site. This feature should not allow the secondary write-enable user to connect to a site XCM and the user may be informed to re-login as a read only permission user, or if guest user is enabled and configured for read only, the feature will connect the secondary user as guest. The feature may allow virtually all of the secondary read only users. The feature may work both on thick clients and thin clients.

The present design may accomplish the requirement is handled by two sides of processing, one being the client side processing and other on server side processing. Specifically, the service makes use of a timer on client side and fox sessions on server side.

FIG. 5is a diagram21relating to client/server interaction processing. The client side processing may execute independent of a server side's interaction and may be achieved through workbench service Opus Single User Client Service. This service may use Opus Client Session Monitor to monitor the active fox sessions to block any secondary read write user who ever attempts to login. The timer may run every 2 seconds to check any blocked users on the connected sessions. If a blocked user is found, the service may display a message to the user depending on guest user configuration. If the guest user is enabled and configured for read only access, the current read write session may be disconnected and guest user may be logged in, and if guest is disabled or configured for read write access, the secondary read write session may be informed about the other primary write user and may be simply disconnected.

As for thin client support, Opus XCM Web Profile may have to be set in virtually all XCMs for all the users to have single user access to work on a web applet. An Opus XCM Web Profile has View( ) approach may be overridden to process the above described logic on a client web applet.

Diagram21may pertain to a user work flow interaction having a UI client22, an XCM23, and a supervisor24, respectively. A start25in UI client portion22may lead to a connect to supervisor at symbol26, with a session established with supervisor24at symbol33, navigate to site XCM at symbol27, and initiate a connection to the XCM at symbol28. Symbol28may lead to a session established indicated by symbol29at XCM23. The established session may lead to providing login credentials (read/write) at symbol31at UI client22. Upon providing login credentials, a single write user may be verified at XCM23of symbol32. If the user is a primary write user at symbol34of XCM23, then the session may be disconnected at XCM23of symbol35. The user may be informed of a login rejection at a UI client as indicated in symbol36.

FIG. 6is a diagram41that may relate to client to server session processing. At the server side, the whole processing of identifying the primary read write user and secondary read write user may occur. Once the Opus Single User Service is added to the station, the fox session listeners may be registered, fox session listeners may include the listener who listens to the sessions being connected or disconnected to the station where the service is added. The present logic may differentiate the different connected sessions like workbench, applet, and so forth, from other stations. The service may act only on the session connected from workbench and applet view.

As soon as the workbench or applet connection is made to the station, i.e., any user logged in to the station, a fox listener call back approach may be invoked and the service may identify the user and its permission levels.

A primary user may be decided, if there are no Opus remote user details under its Opus Single User Service and the other station's Opus Single User Service.

If the current user logged in is the first read write user in the site, the user may become a primary user and be granted full access permissions, and the Opus remote user details like username, permissions, login time and ip address may be synced (added under Opus single user service) across the stations under the site. Once the information is synced, a heart beat timer may be started to send the primary user access details every 5 minutes to handle the fail over scenarios like a lost connection between stations.

If another user with read write permissions tries to login into the site, the service may identify the user as a secondary read write user and block the user by setting a flag on the Opus single user service. The blocked user flag may be monitored by the client service (refer to client side processing), and depending on the guest user configuration, the user may be shown a message to re login or login as guest user.

If the logged user is a read only user, there may be no processing done for this user, and the user may be allowed to login without any processing.

Once the primary user is logged out from the station, there may be a call back on the fox listener, and then the service may remove the Opus remote user details locally and from the other stations. The heart beat timer may be cancelled as the primary user is logged out.

Diagram41shows a client session monitor as indicated on a profiled workbench42. A timer43may have an output that causes an interaction through all of the active sessions at symbol44on workbench42. An output from symbol44may go to get server side sync service information at symbol45. A question of whether the service exists may be asked at symbol46. If not, no actions may be taken and then a return may be made to symbol44where another iteration through the active session may occur, and again the question of sync service existence is asked at symbol46. If the service exists, then a blocked user flag may be sought at symbol47. A question of whether the flag state indicating blocked can be obtained may be asked at symbol48. If not, then a return may be made to symbol44where another iteration through the active session occurs, and again the question of sync service may be asked at symbol46. If the service exists, then a blocked user flag may be sought at symbol47. The question of whether the flag state indicating blocked can be obtained may be asked at symbol48. If the flag indicating user blocked is obtained, then a message of a blocked user may be provided to symbol49where the message is displayed to a secondary read write user. At this place, the session may be closed at symbol51.

In the following may be various sections of Opus single user service. Diagrams ofFIGS. 7 and 8may be noted. Opus Single User Service may be configured in view ofFIG. 7. Steps may incorporate: 1) Open Opus Enterprise module in a Palette; 2) Drag and Drop Opus Single User Service from palette to XCM station under services; 3) Allow only one Opus sync service to be in station; 4) Opus sync service will register the fox listeners as explained above; 5) Reset or clean the Opus sync service (Opus remote user details); and 6) Sync with other XCM stations (add the remote user details under the local Opus Single User Service).

FIG. 7is a flow diagram52for a configure Opus single user service. From a start place54in a profiled workbench53, an Opus single user service from a symbol55may be dragged and dropped according to symbol56into an XCM57at symbol58. The drag and drop may be an only user action in the configuration of diagram52. Going from symbol58to symbol59, a check of whether an Opus single user service already exists may be made. There may be only one Opus single user service per station/XCM. If the service exists, then the process may stop at symbol61. If not, then a fox listener may be registered at symbol62. The listener may listen to user login and logout events. Then at symbol63, the sync service may be reset or cleaned. This step may be used at restart of the station, and the reset may clean the Opus single user service and make it ready to sync with other stations. The sync with other stations may occur at symbols64and65to get all user information from remote stations. The process may stop at symbol61or the Opus single user service as indicated at symbol66in XCM267may sync at symbol65to update user information.

FIG. 8is a diagram61of the configure Opus single user service. An Opus user62may be at stage63where an Opus single user service is added at stage64as indicated at symbol65. The Opus single user service may be added under an XCM station's service. A fox session listener at symbol66may be created new at stage67. The listener may get event call backs for a user added or removed. The Opus single user service may be reset at stage64. Sync of user information may be provided from stage64to a stage68at a fox transmitter as indicated in symbol69.

FIG. 9is a diagram71that refers to the workflow of the login user activities. Steps for the login user may incorporate the following. 1) A user may try to log into the XCM under a particular site. 2) Flows to Opus Fox listener may be controlled. The Opus Fox listener may do so below. 3) There may be differentiation of workbench sessions with station sessions. 4) Current user permissions may be checked. 5) If the current user finds read only, the login may be allowed. 6) If the current user is a read write user, then the primary user may be checked as explained in the server side processing, i.e., the user is the first user on site. 7) If the current user is a first write user, then allow login and start a timer running every one minute to send heart beats to remote stations; and if the current user is a secondary read write user, set a flag and disconnect.

Diagram71may reveal activity of a login of a user. From a start point72in a profiled workbench73, a user may try logging into an XCM74as indicated at symbol75. If a login is successful, the user may get a fox session listener at symbol76in XCM74. Then at symbol77, a check may be made to see if a connection is that of a workbench or a station. A question of whether it is a workbench connection at symbol78may be asked. If yes, then current user access is checked at symbol79. After the check at symbol79, whether the user is a read only may be determined to be true or false at symbol81. “Read only” users may be users with all category masks marked with “Operator Read” and “Admin Read.” If it is true that the user is a read only, then login may be allowed with read only access at symbol82. If false, then a question of whether the user is the first user on site may be asked at symbol83. A check may be made to note whether there is any read write user locally and any on remote stations. It does not connect to remote stations for user information. Instead, it may check the entries made by remote stations under the local Opus single user service as part of a sync mechanism.

If the user is not the first user on site at symbol83, then the user may be a secondary user. At symbol84, a question may be asked of whether the guest user account is enabled and read only. If not, then a message may be displayed which states, “user must re-login as a ‘guest’ (read-only) user”, as indicated at symbol85. Thus, the user may log off at symbol86.

If an answer to the question at symbol84of whether the guest user account is enabled and read only guest is yes, then a message “continues as user ‘guest’ with Read-only permissions” at symbol87. At symbol88, the current session and login as a guest user may be disconnected.

If an answer to the question about the user being a first user on site is yes, the user may be a primary user. The user may be added as a current read write user locally at symbol89. The addition here may be used when remote stations want to sync up the data, i.e., a remote station may copy the user information from the XCM74to be in sync. It may happen at a restart of the stations.

A timer may be started to send a heart beat every minute to remote stations, at symbol91. At symbol92, the user may be allowed login with read write access. Sync may occur at symbol93with a signal to a fox transmitter at symbol94. The sync may happen only to the remote stations which will match the local site information. Only read write user information may be synced across the stations. From the fox transmitter at symbol94, a signal may go to an Opus single user service at symbol95in XCM196.

FIG. 10is a diagram101that may refer to a user logout. The logout may be as in the following. 1) The user may be logging out. 2) Flows to the fox listener may be controlled. The fox listener does as indicated below. 3) The current read write user may be removed locally. 4) The heart beat timer which sends a heart beat every minute to other remote stations may be cancelled. User information may be synced, i.e., the current read write user entries on the remote stations may be removed.

In diagram101, a start point105in profiled workbench102may invoke a logout and/or disconnect at symbol106. Fox service may be triggered at symbol107in XCM103. The current read write user may be logged out at symbol108and logged off at symbol109. The read write may be removed locally at symbol110and the heart beat timer may be stopped at symbol111. A synch may occur at symbol112and be passed on to a fox transmitter at symbol113. Then there may be an Opus single user service at symbol114in XCM1104that sync's the removal of the user.

FIGS. 11 and 12are diagrams115and121, respectively, relating to an auto log off. The Opus supervisor may allow for one or more users to connect the Opus Architect to the supervisor to navigate to and connect to the remote site XCM controllers. In this process, the Opus Architect users may have established connections to the supervisor station and then additional connections to each site XCM controller that they navigate. The Opus Architect may maintain all of the TCP/IP connections until one of the following actions occurs: 1) The user closes the Opus Architect; or 2) The user manually disconnects the Opus Architect from the site XCM's and supervisor.

If the user leaves the application open and continually navigates to different site XCM controllers without manually disconnecting, the connections to all the sites visited may be maintained building up a large set of connection resources. A need may be to ensure that these connections are discontinued after a period of inactivity. The user may establish a time period in minutes which specifies the maximum allowable period of inactivity. The Opus system may setup a monitor of these connections and when the notification (inactivity) time expires, the system may either automatically disconnect the TCP/IP connections, or optionally inform the user in an alert window that one or more connections are about to be closed giving the user an opportunity to override. If there is no user response after the force disconnect period, then the connections may be closed. The notification timer should be defaulted to 30 minutes. Also, the notification timer should be run independently for each connection. The user option for the alert window might be in the user service.

The Opus supervisor may allow for one or more users to connect the Opus Architect to the supervisor to navigate to and connect to the remote site XCM controllers. In this process, the Opus Architect users may have established connections to the supervisor station and then additional connections to each site XCM controller that they navigate. The Opus Architect may maintain all the TCP/IP connections until one of the following actions occurs: 1) The user closes the Opus Architect; or 2) The user manually disconnects the Opus Architect from the site XCM's and supervisor.

Diagram115may be of a screen print showing the user configurable properties for the Opus Auto Log-off service. The items incorporated in the screen print may be an auto log off enable, a notification period and a force disconnect period.

If the user leaves the application open and continually navigates to different site XCM controllers without manually disconnecting, the connections to all the sites visited may be maintained, building up a large set of connection resources. The present approach may ensure that the connections are discontinued after a period of inactivity. The supervisor user may establish an auto logoff period in minutes which specifies the maximum allowable period of inactivity.

The Opus system may setup a monitor of these connections, and when the inactivity time expires, the system may either automatically disconnect the TCP/IP connections or optionally inform the user in an alert window that one or more connections are about to be closed, giving the user an opportunity to override one or more closures of the connections.

Diagram121in essence is of an auto log off feature. The feature may allow the supervisor user to configure the auto log off period, allow the supervisor user to enable and disable the auto log off service, allow the inactive connections to be discontinued after a period of inactivity, and display to the user with all sessions about to expire, with an exception of the supervisor and active sessions, to be disconnected or reset.

The approach to accomplish the requirement may be handled by the client side processing and be a pre-configured Opus Auto Log Off service at the supervisor. As to client processing, the client service Opus Auto Log Off Client Service may have two timers to accomplish the task, one being the session activity monitor and other the session time-out monitor. The timers may run irrespective of service enabled or disabled. The timers, i.e., the Session Timeout Monitor and Session Activity Monitor, may be started when the profiled work bench is started and stopped, or when the profiled work bench is closed.

Diagram121may reveal an auto log off service in a symbol124of supervisor123which in turn is linked to a profiled workbench122. As part of auto log off service in symbol124, there may be an auto log off period, an auto log off enabled and a show message on log off. Along with auto log off service of supervisor123, there may be a session activity monitor of symbol125and a session time out monitor of symbol126as a part of the profiled workbench at symbol122. The session activity monitor may run, for example, every second to monitor an active view opened on the workbench. The session time out monitor may run, for example, every 10 seconds, to monitor the time outs of the sessions between the profiled workbench at symbol122and the supervisor at symbol123.

FIG. 13is a diagram128relating to a Session Activity Monitor. The Session Activity Monitor may run every second to capture user actions. The Session Activity timer may store the active view, i.e., a fox session, which is active at that second and the current time which is stored into activity map.

Diagram128may reveal the session activity monitor of symbol125in a profiled workbench122. There may be a timer at symbol131with an output to a symbol132where an entry to a sessions activity map may be added. An output of symbol132, which may have the entry indicated there, may go along with the session and current time to symbol133which represents the session activity map. The timer at symbol131may run every second to track the active view open on the profile workbench122. The activity represented by symbol132may include specifically the fox session and the current time.

FIG. 14is a diagram129that may relate to the Session Time Out Monitor. The monitor may run every, for example, 10 seconds to time out the expired sessions. The timer may start picking up the Opus Auto Log Off Service from the Supervisor session, and if the auto log off is enabled, then it may start the process for auto log off.

Virtually all of the sessions on the client may be processed on a one by one basis to check if the session is expired or still active. Expiry of the session may have arrived if the current time is after the last active time plus the auto log off period. The time period may be adjustable and be served by the supervisor. If any one of the sessions is found to be expired, then all of the other sessions, except the supervisor and current active sessions, may be displayed to the user along with the time left to expire.

The user may have an option to reset the session timers or to disconnect the sessions. Once the user selects the station to reset, then the session for the station may be set to active, and the unselected stations may be disconnected.

There may be a server side interface. An Opus Auto Log Off Service may be a pre configured service in a supervisor station. The properties for this service may be the following. There may be an Auto Log Off (Enable/Disable) that enables and disables the Opus auto log off feature—enabled. There may be a notification period (BRelTime) of a maximum allowable period of inactivity, e.g., 59 minutes. There may be a force disconnect period (BRelTime) of a maximum allowable period for the user to respond for the session dialog before forcing the XCM disconnect, e.g., 5 minutes.

Diagram129may reveal a session time out monitor126in profiled workbench122. A timer134that, for example, runs every 10 seconds may have an output to symbol135where an auto log off service of symbol136is got from a supervisor session. At the next symbol137, a check of whether the auto log off is enabled may be made. A question of whether the auto log off is enabled may be made at symbol138. If not, then a return to timer134may be with a subsequent pass through items of symbols135and137, and the question of enablement at symbol138may be asked again.

The process through the items of symbols134,135,137and138, in that order, may be repeated until the question is answered as yes which means that the auto log off is enabled. If enabled, then there may be an iteration through all of the active sessions on workbench122at symbol139. A question at symbol140is whether an active session exists in a session map of symbol141. If not, then the activity at symbol139may be repeated. If yes, in that the active session exists, then at symbol142a last active time from the session map may be obtained. An auto log off period may be obtained at symbol143. The session may be checked to note whether the session is timed out at symbol144. The check may incorporate whether the current time is after the auto off period plus the last active time.

A question of whether the session is on a time out may be asked at symbol145. If not, symbols139,140,142-145may be repeated until a response at symbol145indicates the session as timed out. If timed out, then a message may be displayed with all of the active sessions and their remaining times, excluding current active and supervisor sessions, as in symbol146. Selected sessions may be got to reset as indicated by symbol147. A question of whether the session is for reset may be asked at symbol148. If an answer is no, then the session may be closed at symbol149. If the answer is yes, then the time out in the session map may be reset, as indicated at symbol150.

To recap, a control and resolution system for building equipment, may incorporate a supervisor, one or more of site controllers managed and/or communicated with by the supervisor, one or more field controllers managed and/or communicated with by a site controller, and building equipment controlled by a field controller. If a user is to review information of building equipment, the user may navigate the supervisor to establish a connection with a site controller cognizant of the building equipment. If the user is to make changes relative to the information of the building equipment, the user may obtain write permission for the connection with the site controller.

A user may be a primary user if the user has write permission for the connection to the site controller. Virtually any user having a connection to the site controller without write permission may be a secondary user.

Information of the building equipment may incorporate at least one or more alarms, statuses, setpoints, alert events and/or the like of the building equipment. Building equipment may incorporate HVAC units, lighting panels, refrigeration circuits, and related mechanisms.

If a user attempts to connect to a controller which already has a user with write permission connected to the controller, the user may be informed that the user only can connect to the controller with a read only permission.

When the primary user disconnects, the controller may clear the primary user thereby permitting another user to receive read and write permission. A maximum of one primary user may be permitted to be connected relative to virtually all site controllers within a site.

If a secondary user has read only permission, then the secondary user may receive write permission in the event that the primary user disconnects from the controller and the secondary user reconnects as a new primary user.

If the primary user does not disconnect from the controller but is inactive, an auto log-off provision may disconnect the primary user after a predetermined time period. Upon disconnection of the primary user, another user may connect to a controller within the site and have write permission.

Virtually all of the controllers within the site may communicate with one another. A connect service for a user may operate for virtually all of the controllers within the site. The connect service may permit the primary user to have write permission to virtually all the controllers in the site. The connect service may prevent a secondary user from having write permission to virtually any controller within the site. When a user attempts to obtain write permission when logging in to connect to a controller in the site, the connect service may inform the secondary user that there is a primary user connected and that the secondary user can login as a read-only user.

An auto log-off may be enabled relative to a primary user. A notification time period may be set as a predetermined amount of inactivity time that expires from a last time the primary user accessed the controller. When the notification time period expires before the primary user may again access the controller or another controller within the same site, a force disconnect time period may be set as a predetermined amount of inactivity time that occurs until the primary user is forcibly disconnected from the controller. The primary user may be informed when the notification time period expires that the connection by the primary user to the controller is about to be disconnected. The primary user may reset the force disconnect time period to allow continued access by the primary user to the controller.

A supervisor user management system may incorporate a supervisor, one or more site controllers of a site subject to management by and/or communication with the supervisor, one or more field controllers subject to management by and/or communication with a site controller of the one or more site controllers, and building equipment subject to observation and/or control by a field controller of the one or more field controllers.

A user may navigate the supervisor to connect to a site controller of the one or more site controllers to observe and/or control of building equipment. A first user of one or more users connected to a site controller of the one or more site controllers may have write permission relative to the site controller. If a second user is connected to the site controller of the one or more site controllers, the second user may have read only permission relative to the site controller. At least one controller may incorporate a processor.

A user with write permission may be a primary user. A user with read only permission may be a secondary user. The primary user may have write permission for virtually any site controller of the one or more site controllers of the site. The secondary user may have read only permission for virtually any site controller of the one or more site controllers of the site.

The system may further incorporate an auto log-off module connected to the supervisor. The auto log-off module may monitor activity of a primary user while connected to a site controller. If no activity of the primary user relative to the site controller is detected for a first predetermined period of time, the primary user may be notified about the inactivity. If no activity of the primary user relative to the site controller is detected for a second predetermined period of time after the first predetermined period of time, then the primary user may be disconnected from the site controller. The primary user may reset the second predetermined period of time in order to remain connected to the site controller.

The system may further incorporate a user logic synchronization module. The user synchronization module may track login attempts, share active user information among other controllers of the site, note a secondary user connection, establish a block on the connection, and/or reject a login attempt by the secondary user as a write user in view of a primary user presently being logged in.

An approach for managing user access to controllers for building control, may incorporate making a connection for a user to a site controller of one or more controllers of a site, classifying the user as a primary or secondary user according to a read only or write connection to the site controller, respectively, and limiting to one a number of primary users connected to the one or more controllers of the site. The primary user may view site controller information about building control and make changes to the information. The site controller information about building control may pertain to alarms, statuses, setpoints and/or event alerts and/or monitoring and actuation mechanisms of building control equipment.

The approach may further incorporate making a connection for one or more secondary users to the controller of the one or more controllers of the site. A secondary user may view site controller information but not make changes to the information.

The approach may further incorporate measuring a time of a connection without activity of the primary user to the site controller of the one or more site controllers, providing a notification to the primary user when the time of the connection without activity of the primary user to the site controller of the one or more site controllers reaches a first predetermined amount, measuring a time after the notification without activity of the primary user to the site controller of the one or more site controllers, and forcibly disconnecting the primary user when the time after the notification without activity of the primary user to the controller of the one or more site controllers reaches a second predetermined amount. The primary user may reset the time for measuring a time of a connection without activity of the primary user to the site controller of the one or more site controllers after the notification to avoid the forcibly disconnecting the primary user from the site controller.

Access details of a primary user may be synced across site controllers of a site. Upon the access details of the primary user being synced, a heart beat timer may be started to send access details at every certain number of units of time to handle fail over scenarios. The heart beat timer may be cancelled when the primary user is logged out.

The following applications may be related to the present application. U.S. patent application Ser. No. 12/260,046, filed Oct. 28, 2008, entitled “A Building Management Configuration System”, is hereby incorporated by reference. U.S. patent application Ser. No. 12/643,865, filed Dec. 21, 2009, entitled “Approaches for Shifting a Schedule”, is hereby incorporated by reference. U.S. patent application Ser. No. 12/703,476, filed Feb. 10, 2010, entitled “A Multi-Site Controller Batch Update System”, is hereby incorporated by reference.

Although the present system and/or approach 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 related art to include all such variations and modifications.