US20180011461A1

US20180011461A1 - Building Asset Management System

Info

Publication number: US20180011461A1
Application number: US15/446,256
Authority: US
Inventors: Juan Miguel Mariño Camarasa; Federico Fala; Joseph Piccolo, III; David G. Dahlstrom; Amy Quiring; Oana Secara; Nicolae Bogdan Pavel; Alexandra Norton; Tyler Brown; Joshua Tanner; Craig Trivelpiece
Original assignee: Tyco Fire and Security GmbH
Current assignee: Tyco Fire and Security GmbH; Johnson Controls Inc; Johnson Controls US Holdings LLC
Priority date: 2016-07-07
Filing date: 2017-03-01
Publication date: 2018-01-11
Also published as: US20180012482A1; US10216164B2; US20180011455A1; US20190146444A1; US10831167B2

Abstract

A connected services system manages assets of building management systems of different organizations. An application server collects information from the assets, which is stored in various data stores associated with an account of the client organization, including an asset store, a group hierarchy store, a user account store, an asset ownership store, and a group ownership store. The group hierarchy store organizes the assets into tiered groups such as campuses, buildings, floors and wings. Users view, on graphical interfaces displayed on the displays of user devices, information from the asset store pertaining to assets that are owned by or shared with them according to the group ownership and asset ownership stores. The graphical interfaces include an asset panel for displaying detailed information about assets, a grouping selector, for filtering which assets for which information is displayed, and a status graphic for providing information concerning the status of the assets.

Description

RELATED APPLICATIONS

This application claims the benefit under 35 USC 119(e) of U.S. Provisional Application No. 62/359,428, filed on Jul. 7, 2016, which is incorporated herein by reference in its entirety.
This application is related to U.S. application Ser. No. ______ filed on an even date herewith, entitled “Building Management System Method and Interface”, attorney docket number 0324.0026US2/F-FD001622US, now U.S. Patent Publication No.: ______, which is incorporated herein by reference in its entirety.

BACKGROUND OF THE INVENTION

Building management systems are often installed within buildings owned or operated by commercial, residential, or governmental organizations. Examples of these buildings include offices, hospitals, warehouses, schools, shopping malls, government offices, and casinos.
Building management systems include fire systems, security systems, access control systems, heating, ventilation and air conditioning (HVAC) systems, and theft prevention systems. They each typically include assets such as control panels or controllers and distributed devices.
The fire alarm systems, for example, typically include a number of different types of fire alarm assets. Fire control panels (or control panels) function as system controllers. Fire detection/initiation devices and alarm notification devices are then installed throughout the buildings and connected to the panels. Some examples of fire detection/initiation devices include smoke detectors, carbon monoxide detectors, flame detectors, temperature sensors, and/or pull stations (also known as manual call points). Some examples of fire notification devices include speakers, horns, bells, chimes, light emitting diode (LED) reader boards, and/or flashing lights (e.g., strobes).
The fire detection devices monitor the buildings for indicators of fire, Upon detection of an indicator of fire such as smoke or heat or flames, the device is activated and a signal is sent from the activated device to the control panel. The control panel then initiates an alarm condition by activating audio and visible alarms of the fire notification devices of the fire alarm system. Additionally, the control panel will also send an alarm signal to a monitoring station, which will notify the local fire department or fire brigade.
The security systems can often include one or more of a number of related systems and subsystems. Most commonly security systems include intrusion systems. However, access control systems and video surveillance systems, for example, can also be a part of an organization's security systems.
Intrusion systems typically include a number of different types of security assets. Usually, intrusion control panels function as system controllers. intrusion detection devices are then installed throughout the buildings and connected to the intrusion panels. Some examples include motion detectors, and magnetic reed switches to detect window/door opening events, among others.
Access control and video surveillance systems will have their own assets. Access control systems typically include controllers and readers, which are installed at access points. On the other hand, video surveillance systems will include video cameras, video storage systems, monitoring stations, video server systems and/or video analytics systems.
The monitoring stations for fire and security systems will typically monitor multiple fire alarm systems and security systems for alarm and trouble signals and then notify the proper authorities. Monitoring stations are often required by regulations, making them a standard component of most fire alarm systems, regardless of age or manufacturer of the fire alarm systems' components. These monitoring stations can be administered by a third party company, the same company that provides or manufactures the fire and security systems, or a public agency, among examples.
More recently, it has been proposed to use connected services systems to monitor building management systems. In some cases, the control panels have been given network connectivity to communicate with the connected services systems; in other cases, the technicians have temporarily connected testing computers to the control panels that functioned as gateways. This has allowed the control panels to report status information to the connected services systems, which are typically administered by fire and security systems companies and include, for example, databases for storing historical status information. These connected services systems will also often have remote diagnostic capabilities. As such, connected services systems facilitate the maintenance, compliance and tracking of repairs of fire and security systems.

SUMMARY OF THE INVENTION

Typically, previous connected services systems assign only one user account per customer for both accessing information stored by the connected services systems and for managing and configuring the assets of these systems. The single user account for each customer of the connected services system is utilized to configure and manage the operational state of the assets and display information associated with each of the assets (e.g. status, state, type/model number). This “one size fits all” approach creates problems when different users at the same customer premises, such as facility managers, fire safety compliance managers, and physical asset managers, want to manage or view different or overlapping aspects of the systems and their assets. Specifically, the presentation of the assets in a web application is typically not organized or grouped in a way that suits the job functions of each user.
The present connected services system provides multiple user accounts per premises for customers of the service. Users can organize or group the assets in a logical fashion that suits the job function or task goals of the users of each account type. For this purpose, the users assign ownership of each asset to a specific user account and then share access to the asset across other user accounts. This is in contrast to current systems, where typically only one user account is provided per customer, and therefore all assets are assigned to or associated with the single user account.
Multiple user accounts for the same customer are created that enable potentially different groupings of the assets, and many kinds of logical groupings of assets are possible.
In one example, the groupings are determined based on geographical or physical divisions of the premises or organization, such as countries, states, campuses, buildings, floors, or wings.
In another example, a separate user account for security guards stationed at a security desk within each campus can be created. The security guards create different logical groupings of the same assets, where the groupings of the assets are relevant to the tasks and objectives of the security guards.
In another example, a user account associated with a corporate asset manager user is created. This user account provides a view of the assets for purposes of ascertaining local and national fire code compliance for each of the assets of a company, with a potentially national scope.
In another example, a grouping can be created that is based on assets installed on or after a certain date, for accounting/fiscal year management of assets by users in an accounting division within a company.
In yet another example, groupings can be created by security managers that organize assets in accordance with locations of relative risk. For example, a fire alarm panel installed at a chemical laboratory of a building may be assigned to a grouping associated with a high risk of fire, where a fire alarm panel installed at a building of the same company that includes corporate offices would likely be assigned to a grouping associated with a low risk of fire. At the same time, an intrusion panel asset at the same corporate building would likely be assigned to a grouping associated with a high risk of intrusions. This enables enhanced focus and priority for assets based on the characteristics of each grouping.
A graphical user interface displayed on the display of a user device presents information pertaining to assets owned by and shared with a specific user account. The interface further allows the user to filter information concerning assets according to logical groups via a grouping selector, which displays a graphical representation of the groups (for example, as graphical node icons) organized into groups in a hierarchical fashion. The information is displayed on an asset pane of the graphical user interface, preferably in a table format.
Additionally, a status graphic can be displayed on the graphical user interface. The status graphic presents information concerning the status of the assets, such as the relative percentage of assets associated with different asset status types. In one example, the status graphic can be a status circle, with different arcs that correspond to status “sub-types” of that asset status type. In addition, in one implementation, the presentation of the arcs can change in response to the relative percentage of “Overall Status” that each sub-type contributes to the “Overall Status”. Each arc within the status circle can also be rendered in a different color, where the color conveys a context-specific meaning. For example, an arc associated with the status “Normal” can be green, while the arc associated with the “Alarm status” can be red or yellow to convey a warning.
In general, according to one aspect, the invention features a system for managing assets of building management systems. The system comprises an asset store for storing information concerning the assets of the building management systems, a user account store for storing information concerning user accounts, and an ownership store for enabling access by the user accounts in the user account store to the information in the asset store.
The ownership store preferably enables access by designating user accounts from the user account store as owners of assets represented in the asset store. The ownership store also enables access by designating which user accounts with which information about assets represented in the asset store is shared. In some examples, the ownership store further designates specific types of information to be shared with the user accounts.
A group hierarchy store can also be provided for storing groups for the assets. The groups can be ordered in a tree structure, and the groups can have owners, and the groups can be shared with other users.
In the context of cloud-based system, sets of asset stores, user account stores and ownership stores can be maintained for different organizations.
In general, according to another aspect, the invention features a method for managing assets of building management systems. The method comprises an asset store storing information concerning the assets of the building management systems, a user account store information concerning storing user accounts, and an ownership store enabling access by the user accounts in the user account store to the information in the asset store.
In general, according to another aspect, the invention features a system for managing assets of building management systems. The system comprises an asset store for storing information concerning the assets of the building management systems, a user account store for storing information concerning user accounts, an ownership store, for enabling access by the user accounts in the user account store to the information in the asset store, and a custom name store for allowing each of the users to store a custom name for assets that are owned by or shared with the users.
In general, according to another aspect, the invention features a method for managing assets of building management systems. The method comprises an asset store storing information concerning the assets of the building management systems, a user account store information concerning storing user accounts, an ownership store enabling access by the user accounts in the user account store to the information in the asset store, and a custom name store storing custom names assigned by the users for assets that are owned by or shared with the users.
In general, according to another aspect, the invention features a system for managing assets of building management systems. The system comprises an asset manager including an asset store for storing information concerning the assets of the building management systems, a user account store for storing information concerning user accounts, and an ownership store, for enabling access by the user accounts in the user account store to the information in the asset store. A user device is further provided for displaying a graphic user interface including names of assets and an ownership status of the assets as being owned or shared.
In general, according to another aspect, the invention features a method for managing assets of building management systems. The method comprises storing information concerning the assets of the building management systems, storing information concerning user accounts, and enabling access users to the information in the asset store and showing the users names of assets and ownership statuses of the assets as being owned or shared.
The above and other features of the invention including various novel details of construction and combinations of parts, and other advantages, will now be more particularly described with reference to the accompanying drawings and pointed out in the claims. It will be understood that the particular method and device embodying the invention are shown by way of illustration and not as a limitation of the invention. The principles and features of this invention may be employed in various and numerous embodiments without departing from the scope of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

In the accompanying drawings, reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale; emphasis has instead been placed upon illustrating the principles of the invention. Of the drawings:

FIG. 1 is a block diagram of a connected services system monitoring building management systems for different organizations according to the present invention;

FIG. 2A is a schematic diagram showing the asset store for storing information concerning the assets of the fire and security systems;

FIG. 2B is a schematic diagram showing the organization of the group hierarchy store;

FIG. 2C is a schematic diagram showing the organization of the user account store;

FIG. 2D is a schematic diagram showing the asset ownership store;

FIG. 2E is a schematic diagram showing the group ownership store;

FIG. 2F is a schematic diagram showing the user account custom name store;

FIG. 3 is an example of a graphical user interface displayed on a user device for the users showing an interface for user management;

FIG. 4 is an example of a graphical user interface displayed on a user device for the users showing an interface for user information editing;

FIG. 5 is an example of a graphical user interface displayed on a user device for the users showing an interface for user notification preferences management;

FIG. 6A is an example of a graphical user interface displayed on a user device for a user, showing an interface for product management;

FIG. 6B is an example of a graphical user interface displayed on a user device, showing an interface for product management, in which the asset names are displayed as custom names for a different user;

FIG. 7 is an example of a graphical user interface displayed on a user device for the users showing an interface for product detail management;

FIG. 8 is an example of a graphical user interface displayed on a user device for the users showing an interface for finding and adding an asset to a user's account;

FIG. 9 is an example of a graphical user interface displayed on a user device for the users showing an interface for display asset for selected groups;

FIGS. 10, 11, and 12 illustrate group selection within the graphical user interface;

FIG. 13 is an example of a graphical user interface displayed on a user device for the users showing a dashboard;

FIG. 14 is an example of a graphical user interface displayed on a user device for the users showing a dashboard when the status pane is selected;

FIGS. 15 and 16 are examples of a graphical user interface displayed on a user device for the users showing a dashboard when an arc segment within the status widget is selected; and

FIGS. 17 is an example of a graphical user interface displayed on a user device for the users showing a dashboard when an arc segment within the status widget is selected.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The invention now will be described more fully hereinafter with reference to the accompanying drawings, in which illustrative embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.
As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items. Further, the singular forms and the articles “a”, “an” and “the” are intended to include the plural forms as well, unless expressly stated otherwise. It will be further understood that the terms: includes, comprises, including and/or comprising, when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. Further, it will be understood that when an element, including component or subsystem, is referred to and/or shown as being connected or coupled to another element, it can be directly connected or coupled to the other element or intervening elements may be present.
FIG. 1 is a block diagram of a connected services system 12 according to the present invention.
In general, the connected services system 12 facilitates the monitoring, maintenance, testing, configuration and repair of building management systems 100-1, 100-2, 100-N for different organizations 10-1, 10-2, 10-N by gathering and storing information from connected building management systems.
The connected services system 12 includes an application server system 60 that can be implemented as a server computer or a set of servers. In other cases, the system can be implemented on a cloud computing system maintained by a third party cloud services company.
The application server 60 accesses a number of different asset managers 14-1, 14-2, 14-N. Each asset manager instantiation 14-1, 14-2, 14-N corresponds to a different one of the organizations 10-1, 10-2, 10-N. These asset managers manage the assets of a fire and security system by storing status information for the assets and information concerning users that have responsibilities with respect to these assets and the information accessed by these users. All of the status information for the assets and the information concerning users are stored in a common database system, for example. As a result, the information is not duplicated for each account and for each user within an organization, for example.
In more detail, the application server 60 maintains a number of different data stores 44, 56, 66, 68, 72, 74 in each of the asset managers 14-1, 14-2, 14-N. These stores 44, 56, 66, 68, 72, 74 are repositories for persistently storing and managing the data from the fire building management systems in different bins for each of the client organizations 10-1, 10-2, 10-N, respectively, of the connected services system 12. Depending on the specific implementation and the nature of the data, the data stores can be repositories like databases (relational, object-oriented), distributed data stores, linked lists, or other files and file systems. The data is stored in a common database and data for each of the client organizations 10-1, 10-2, 10-N and not duplicated.
In terms of relevance here, the data stores accessed the application server 60 include a user account store 44, an asset store 66, a group hierarchy store 56, an asset ownership store 68, a group ownership store 72, and a user account custom name store 74.
The application server 60 provides access to the information contained in the user account store 44, asset store 66, group hierarchy store 56, asset ownership store 68, group ownership store 72, and a user account custom name store 74 to users 70 by transmitting the information to user devices 102 operated by the users 70. Examples of user devices 102 include desktop and workstation computers and mobile devices such as smart phones, tablets, laptops, and other mobile computing devices. Each of the user devices includes a display 103, such as a computer monitor, touch screen display, or augmented reality display on which a user interface is displayed, containing information provided by the application server 60.
The application server 60 receives information from various connected building management systems 100-1, 100-2, 100-N typically via a public network 23, which is a wide area network such as the internet, and stores the information in the asset manager 14-1, 14-2, 14-N for the corresponding organization.
In the illustrated example, the building management system is a fire and security system. However, it will be understood that building management systems can further include access control systems, heating, ventilation and air conditioning (HVAC) systems, and theft prevention systems, to list a few other examples.
The application server 60 gathers data from fire and security systems 100-1, 100-2, 100-N for different organizations 10-1, 10-2, 10-3 by receiving information reported and transmitted from the fire and security systems' control panel assets 16, 26. Control panels 16, 26 are assets that direct the function of fire and security systems by determining and displaying the operational status of connected slave de^-vice and by receiving alarm signals from slave devices, among other examples.
In addition to control panel assets 16, fire alarm systems typically include a number different types of fire alarm assets installed throughout the buildings and connected to the panels 16. Some examples of fire detection/initiation assets include smoke detectors, carbon monoxide detectors, flame detectors, temperature sensors, and/or pull stations (also known as manual call points). Some examples of fire notification devices include speakers, horns, bells, chimes, light emitting diode (LED) reader boards, annunciators and/or flashing lights (e.g., strobes).
Similarly, other building management systems and security systems typically include a number of different types of security assets installed throughout the buildings and connected to the security control panels 26. For intrusion systems, examples include motion detectors, magnetic reed switched to detect window/door opening events. For access control and video surveillance systems, examples include controllers and readers, which are installed at access points, video cameras, video storage systems, monitoring stations, video server systems and/or video analytics systems.
For example, the details of an exemplary client organization 10-1 are shown. It includes different campuses 12A, 12B, 12C and different buildings 50A-50F distributed between the different campuses. Each of the buildings includes one or more assets that report their status to the application server. For example, building 50E in the South Campus 12B has an intrusion panel 26-4 that reports to the application server system 60 via the public network 23. Somewhat similarly, building 50C in the North Campus 12A has a fire panel 16-4 and an intrusion panel 26-2 that report to the application server system 60 via the organization's enterprise network 13-1 and the public network 23.
Each of the fire and intrusion panels 16, 26 will support one or multiple loops or networks of fire or security assets. For clarity, however, only one network of fire detection and alarm notification devices is shown, connected to the fire panel 16-6 of building 50F. The fire detection devices 109-1 to 109-3 connect to the fire panel 16-6 via a safety and security wired and/or wireless network 111 (also known as a loop), which supports data communication between the devices 109-1 to 109-3 and the control panel 16-6.
The illustrated example includes fire and intrusion panels 16-1, 16-3, 16-4, 16-5, 16-6, 26-1, 26-2, 26-3, 26-4, which transmit data to the application server system 60 via the public network 23, sometimes through enterprise and/or cellular data networks 13-1. Data transmitted from fire and intrusion panels 16-1, 16-3, 16-4, 16-5, 16-6, 26-1, 26-2, 26-3, 26-4, to the application server system 60 include status information, diagnostic information and testing information pertaining to the control panel and other slave devices of the fire and security systems such as fire detection and notification and intrusion devices. Status information is information about whether the fire alarm system and intrusion systems are operational and whether an alarm state is indicated. Generally, diagnostic information is data detected by various components of the fire and security systems that can be used to optimize or repair the system, and testing information is information about any tests of the fire and security systems. In some examples, diagnostic information includes identification information such as a unique identifier for the fire or intrusion panel 16, 26, address of the asset or assets, location information such as a physical location of the assets, a date and time of the activation, status information, including a fault state of the activated assets, analog and/or detected value generated by the assets such as a detected smoke level or detected ambient temperature.
In the illustrated example, fire panel 16-2 is a non-compatible panel. Non-compatible control panels are legacy or third party control panels that lack network connectivity and thus are unable to connect directly via the public network 23. Such control panels 16-2 can be manufactured by the same company providing the connected services system 12 but at a time before network connectivity was desirable in control panels. Third party control panels are control panels manufactured by different companies or business entities than that providing the connected services system 12 and may or may not have network connectivity. Even if they have network connectivity, third party control panels will often use different protocols than the connected services system to communicate status, diagnostic and testing information.
Non-compatible control panels 16-2, can be retrofitted with devices that enable network connectivity. In the illustrated example, the non-compatible control panel 16-2 connects to a gateway device 116. The gateway device 116 provides access for the non-compatible control panel 16-2 to the public network 23 and thus to the application server system 60.
FIG. 2A shows the asset store 66, which stores information concerning the assets of the fire and security system.
In the illustrated example, the asset store 66 is arranged in the form of a table as might be found in a relational database. A first column holds the asset ID. This is usually a multi-digit number that is unique to each asset. The second column is the asset pin. This is a number that is generated by and typically only known by the owner of the asset. The third column is the asset name. Often this name includes information concerning where the asset is installed and is commonly assigned at the time of the device's installation. The fourth column is the asset type. For example, if the asset is a fire panel or an intrusion panel, this information is contained in this column. The fifth column provides information concerning the model of the asset. This is usually the designation provided by the manufacturer for the specific product.
The hierarchy assignment column identifies the hierarchy within the organization that the owner of the asset has assigned to the asset. This hierarchy is typically created by or for the organization and is descriptive of where this asset is installed within a logical framework created by the organization. For example, in the example shown in FIG. 1, for organization 10-1, the hierarchy assignment may indicate in which campus and in which building the asset is installed. In another example, the hierarchy may further include information concerning the function of the asset such as whether it is an intrusion panel or a fire panel. It could also include information such as in which state or country the panel is installed.
The product status column indicates the general status of the product. For example statuses include an alarm state, a trouble state, a normal state, an offline state, and an armed state. Specifically, if a fire panel is currently detecting a fire, then the alarm state will be true. On the other hand, if the intrusion panel is not working, then its trouble state may be true. Generally, the normal state is true when the panel, fire panel or intrusion panel, is operating normally. An intrusion panel will have a positive armed state when it is armed such as during off business hours.
The inspection status column indicates whether the panel has been properly inspected. For example, fire panels must often be inspected to ensure operation at least annually. On the other hand, the organization may designate a certain inspection cycle for intrusion panels, for example.
The last three columns are the dirty status, service status, and updated status. The dirty status is mostly relevant to fire panels. Often some fire alarm systems' slave devices will become dirty over time and must be replaced or cleaned. The service status column indicates whether or not the panel needs to be serviced. Finally, the updated status column indicates whether or not the firmware of the panel has been updated to a new version of the firmware.
FIG. 213 shows the organization of the group hierarchy store 56. The group hierarchy store 56 stores groups for the assets. In the illustrated example, the groups are ordered in a tree structure.
Many kinds of logical groupings of assets in the group hierarchy store 56 are possible.
In one example, the groupings are determined based on geographical or physical divisions of the premises or organization, such as countries, states, campuses, buildings, floors, or wings. In the illustrated example, the groups for the organization 10-1 include campuses, buildings, floors and wings.
In another example, which is not illustrated, a separate user account for security guards stationed at a security desk within each campus can be created. The security guards create different logical groupings of the same assets, where the groupings of the assets are relevant to the tasks and objectives of the security guards.
In another example, a user account associated with a corporate asset manager user is created. This user account provides a view of the assets for purposes of ascertaining local and national fire code compliance for each of the assets of a company, with a potentially national scope.
In another example, a grouping can be created that is based on assets installed on or after a certain date, for accounting/fiscal year management of assets by users in an accounting division within a company.
In yet another example, groupings can be created by security managers that organize assets in accordance with locations of relative risk. For example, a fire alarm panel installed at a chemical laboratory of a building may be assigned to a grouping associated with a high risk of fire, where a fire alarm panel installed at a building of the same company that includes corporate offices would likely be assigned to a grouping associated with a low risk of fire. At the same time, an intrusion panel asset at the same corporate building would likely be assigned to a grouping associated with a high risk of intrusions. This enables enhanced focus and priority for assets based on the characteristics of each grouping.
In more detail, the group hierarchy store 56 comprises a top level that corresponds to the organization. In the illustrated example, the top level corresponds to organization 10-1. Within the organization are a series of first level groups. For example, in the example of organization 10-1, there might be three first level groups: North Campus, South Campus, and Satellite Campus. Then, each of the first level groups may have their own second-level groups. For example, the North Campus contains three groups: building 50A, building 50B, and building 50C. In a similar vein, the South Campus will have two groups: building 50D and building 50E. Further, the second level groups can each then have their own third level groups. For example, building 50A may have groups corresponding to its different floors. In another example, a larger building may have separate wings. Then, each of those separate wings could then have their own fourth level groups corresponding to floor, as shown. Other examples may have a deeper or shallower level structure depending on its complexity and how that organization wished to organize its assets.
FIG. 2C shows the user account store 44, which stores information concerning user accounts. In the typical implementation, each user has a user ID. This is usually a multi-digit number that is unique to each user. A user pin is often secret alphanumeric sequence that the user must enter to access their account. Other biographic information will also be typically contained in the user account store 44 such as a name or an email address and/or mobile phone number. Additionally, the user's role within the organization may also be stored in this table.
FIG. 2D shows the asset ownership store 68, which enables access by the user accounts in the user account store 44 to the information in the asset store 66. In one example, it includes a column that specifies a particular asset such as the asset ID. The second column indicates the owner of that asset. In one example, the second column has the user ID for the user that is the designated owner of the corresponding asset. A third column indicates the users with whom information from this asset are shared. These are the other users with whom the asset owner has designated to receive information concerning the asset. Finally, a fourth column includes share limitations, which indicate any limitations to the information that is shared with the users specified in the third column. Share limitations can include sharing only the product status, sharing only the inspection status, or sharing only the alarm status of the assets.
FIG. 2E shows the group ownership store 72. This includes a column that corresponds to the different groups specified in the group hierarchy store 56. The second column indicates the owner of that group. And the third column indicates the users with whom the owner shares access to the group. In this way, entire groups of assets can be assigned ownership. Further, that owner can then assign share access to those assets to still other users. The group ownership store 72 also includes share limitations.
FIG. 2F shows the user account custom name store 74, which allows each of the users to store a custom name for each of the assets that are owned by or shared with the respective users. This includes a column that corresponds to user accounts (User ID, a multi-digit number that is unique to each user), a column that corresponds to assets (Asset ID, the multi-digit number that is unique to each asset), and a column indicating a custom name for the asset to be displayed when the associated user views information about the asset. In this way, different users can create, assign and then view different names (which are relevant to the responsibilities of the user) for the same assets.
For example, the user with the User ID=3, has assigned the name “4100ES 012345678” to the asset with the Asset ID=4.
The custom name assignment might allow an account manager to assign and/or view an accounting system's asset tracking numbers as the custom names of assets. In another example, a facilities manager can assign and/or view the name or number of the room in which the asset is located as the asset's name. In another example, a security group can assign and/or view the address of the building in which the asset is located as the asset's name. In yet another example, service personnel can assign and/or view the address and panel, or model number, of the asset as the asset's name. In short, each of these different users can personalize the naming of the assets depending on their individual roles.
FIGS. 3 through 18 show a series of graphical user interfaces that are displayed on the displays 103 of the user devices 102 for the users 70. The information contained in the graphical user interfaces is provided by the application server system 60 by obtaining the information from the corresponding asset manager 14-1, 14-2, 14-N of the respective the organization 10-1, 10-2, 10-N for whom the user is employed.
FIG. 3 shows the overall organization of the graphical user interface, which is displayed on the display 103 of the user devices 102. It comprises a user navigation pane 310. In the center is a user list pane 312. Across the top are four tabs: an assets tab 12-1, a dashboard tab 12-2, a managed products tab 12-3, and a users tab 12-4.
Selection of the users tab 12-4 results in the display of the user list pane 312 and the user navigation pane 310. The user list pane 312. lists various users, their email addresses, the status of their user account, such as validated or waiting to be validated, and a series of control buttons 34-1 through 34-4 that allows for management actions to be taken on the indicated account.
In the user navigation pane 310, a series of graphical buttons are provided that allow the user to access accounts by selecting graphical button 13-1, edit a specific user by selecting graphical button 13-2, or add a new user by selecting graphical button 13-3.
FIG. 4 shows the graphical user interface when the edit user graphical button 13-2 is selected. Specifically, an edit user pane 316 is displayed on the user device 102. There, the user can enter an email address, password, the user's first name, their surname, and a nickname. Further, a profile picture can be uploaded.
FIG. 5 shows the graphical user interface when the accounts graphical button 13-1 is selected. Specifically, a notification preferences pane 318 is displayed. This preferences pane lists the different assets that are owned or shared with the user. Specifically, a fire panel asset 320-1 is listed along with an intrusion panel asset 320-2. For each of these assets, a list of potential statuses is provided 322-1, 322-2. For example, for fire panel 320-1, the potential statuses are alarm, trouble, normal, and offline. An email checkbox 324 and a SMS checkbox 326 is then provided for each of these statuses for each of these assets. By selecting the email or SMS checkbox, the asset manager will send either an email or an SMS message when that status is true for the corresponding asset. For example, checking box 326 will result in the asset manager 14-1 executing on the application server 60 to send an SMS message via the application server system 60 when the fire panel 320-1 is in an alarm state. Checkbox 328 is selected when the user wishes to receive a notification when the asset is in a test mode.
FIG. 6A shows the graphical user interface when the manage products tab 12-3 is selected by the user 70. It includes a manage products navigation pane 350, and a product list pane 352.
FIG. 6B shows an alternate screen using custom names displayed by the graphical user interface when the manage products tabs 12-3 is selected by a different user 70 with custom names assigned. In the illustrated example, the names are displayed as an asset tracking number for an accounting system. For example, the name for the first fire panel (named “James Admin Main Bldg” in FIG. 6A) is now named “00001.”
The manage products navigation pane 350 has five graphical buttons, a list products graphical button 13-4, an add product graphical button 13-5, a product details graphical button 13-6, a manage groupings graphical button 13-7, and a share/transfer graphical button 13-8.
The products list pane 352 lists the assets to which the user has access. Specifically, the first column 354 provides the asset name for the asset. Often this is the location where the asset is installed. This information is obtained from the third column of the asset store 66. The second column 356 indicates the type of the asset, such as whether the asset is a fire panel or intrusion panel. This information is obtained from the fourth column of the asset store 66. The third column 358 indicates the model of the asset. This information is obtained from the fifth column of the asset store 66. The fourth column 360 indicates the ownership status of that asset for the user. This information is obtained from the second and/or third column of the asset ownership store 68. For example, the indicated user owns the James Admin Main Building fire panel but shares the James Admin Main Building intrusion panel. Also shown are other ownership statuses such as Pending Sharing Request and one case where a request to share was denied.
FIG. 7 shows the graphical user interface when the product details graphical button 13-6 is selected in the manage products navigation pane 350.
Specifically, a product detail pane 366 is displayed. This includes details of the asset displayed in section 364. Section 365 allows management of the asset by entry of information by the user. Here, the user can edit the name assigned to the asset by selecting edit in area 368. This process will update the third column of the asset's record in the asset store 66. The user can change the group to which the asset is assigned by selecting the edit command in area 370. This process will update the sixth column of the asset's record in the asset store 66. The user can delete the other users with whom the asset is shared by selecting one of the shared accounts in area 372 and selecting the delete command. This will delete the corresponding share information stored in the asset ownership store 68. Finally, the privacy settings can be selected by selecting the options in area 374.
FIG. 8 shows the user interface when the add product graphical button 13-5 is selected in the manage products navigation pane 350.
Specifically, an add product pane 405 is displayed. This allows the user to select an identification type in selection box 410. Then, the user enters the asset ID in box 412 for the asset that should be added to their account. Finally, in box 414, the user enters the PIN for the corresponding asset.
If the user does not have the specific asset ID for the asset that they want to add, the user can select the search button 418. This will generate list in area 416 of potential assets to add, indicating the asset ID of those assets and also the ownership status for the corresponding asset. Once the desired asset is found, an add graphical button 419 is selected by the user, which adds the asset to the user's account by updating the asset ownership store 68.
FIG. 9 shows the graphical interface when the assets tab 12-1 is selected. Specifically, a group selector pane 510 is displayed on the left and an asset list pane 512 is displayed in the center and right region.
The group selector pane 510 graphically illustrates the group hierarchy information stored in the group hierarchy store 56. Nodes 514, 516, 518, 520, 522 are graphic icons that represent different level groups as stored in the group hierarchy store 56 for the group's asset manager 14. In the illustrated example, the top level group is indicated by node icon 514, which represents the organization 10-1, which is the entirety of the exemplary State University System as illustrated in previous figures. This node icon 514 is indicated as selected by the “check” graphic. The first level groups are then shown as a series of nodes 516, 518, 520, 522, which are connected to node 514 and indented. Each of these nodes corresponds to the North Campus, South Campus, East Campus, and West Campus, respectively. These nodes correspond to the first level groups for the organization as stored in the group hierarchy store 56. In general, in this way, the information in the group hierarchy store 56 is graphically displayed on the group selector pane 510 as a series graphical icons representing parent and child nodes, with parent node icons corresponding to higher level groups and child node icons corresponding to lower level groups in the group hierarchy store 56. In the group selector pane 510, selection of nodes 516. 518, 520, 522 corresponding to higher level groups causes child nodes corresponding to lower level groups to be displayed.
Also provided is a multi-group mode selector 530. With the top level node 514 selected, the asset list pane 512 lists all of the assets that are within the selected node, i.e., fall within the selected group or are within a group under the selected group within the group hierarchy. Since the top level node 514 is selected, this is a complete list of assets in the asset list pane 512 or the organization. Specifically, the asset list pane 512 comprises four columns that are populated with information about the assets in the groups, which is from the asset store 66. The first column 540 indicates the status of the asset such as normal, armed, or offline, for example (from column 7 of the asset store 66). The second column 542 provides the name of the asset (from column 3 of the asset store 66). The third column 544 indicates the type of the asset such as fire panel or intrusion panel, along with the model of that asset (from columns 4 and 5 of the asset store 66). Finally, the fourth column 546 indicates the group to which the asset is assigned in the group hierarchy store 56 (from column 6 of the asset store 66).
FIG. 10 illustrates how the multi-group mode selector 530, introduced in FIG. 9, controls the information displayed in the asset list pane 512. Specifically, when the multi-group mode selector 530 is deselected or disabled, information about all assets for all groups are displayed in the asset list pane 512. Then, selection of one of the nodes 516, 518, 520, 522 then affects the display of the tree in the group selector pane 510, by displaying or hiding, in the group selector pane 510, any nodes connected to the selected node. The assets displayed in the asset list pane 512 are unaffected. Specifically, control of and the selection of the nodes 516-522 does not change or filter the list of assets displayed in the asset list pane 512.
As shown in FIG. 11, while the multi-group mode selector 530 is deselected or disabled, the user can then select each of the nodes 516, 518, 520, 522 that correspond to the first level groups. Selection of these nodes will then cause the display of second level nodes for each of the corresponding first level groups. For example, selection of first level node 516 that corresponds to a first level group causes the display of the second level nodes 570, 572 that correspond to the second level groups as stored within the group hierarchy store 56. In a. similar vein, the first level node 518 can be selected to spawn the second level nodes 574, 576 that correspond to the second level groups under the first level group to which first level node 518 corresponds.
FIG. 12 shows how the user interface is displayed when the multi-group mode selector 530 is enabled. Specifically, the asset list pane 512, and specifically the specific assets that are listed in that pane 512, are filtered to be only those assets within the groups that are selected in the group selector pane 510. Thus, the assets of groups corresponding to nodes 570 and 520 are displayed in the asset list pane 512. In the illustrated example, in the asset list pane 512, information pertaining to exemplary asset “A1” is displayed, because second-level node 570, corresponding to exemplary asset “A1” is selected. Similarly, information pertaining to exemplary assets “C1”, “C2”, “C3”, and “C4” is displayed in the asset list pane 512, because first-level node, corresponding to exemplary group “C”, which includes assets “C1”, “C2”, “C3”, and “C4”, is selected. No other assets are displayed in the asset list pane 512, because no other nodes are selected in the group selector pane 510.
FIG. 13 shows the graphical user interface when the dashboard tab 12-2 is selected. Specifically, the graphical interface in this mode has a status type selector area 118, a status widget 120, and a status pane 126.
The status type selector area 118 has a series of graphical buttons: an overall status graphical button 72-1, a product status graphical button 72-2, an inspection status graphical button 72-3, a dirty status graphical button 72-4, a connect status graphical button 72-5, and a service status graphical button 72-6.
The status widget 120 is a graphic that provides information concerning the status of the assets. The status widget 120 generally comprises a series of arc segments 122 arranged along a common circle. The arc segments 122 correspond to groups of assets with the same status. Also included are textual annotations 82, 92, 102 that are associated with each of the arc segments 122.
Finally, the status pane 126 displays textual information for the assets and comprises an asset name column 610, an overall status indicator column 612, and a product status column 614.
The graphical interface displayed corresponds to the selection of the overall status graphical button 72-1. When this button is selected, the status widget 120 provides the overall status of the assets within the user's account, typically all of those assets either owned by the user or that have been shared with the user. Specifically, in the illustrated example, the status widget includes an arc segment 122-1 that is 18% of the complete circle. This indicates that 18% of the assets are in an alarm state (see annotation 82-1). The annotation 92-1 provides the percentage amount. The textual annotation 102-1 indicates that the actual number of assets is ten. An offline arc segment 122-2 corresponds to 9% of the circle. This corresponds to the 9% of the assets (see annotation 92-2) that are in an offline state (see annotation 82-2). The annotations provide an asset count of five with annotation 102-2.
The normal assets arc segment 122-3 corresponds to 55% of the circle and indicates the fact that 55% of the assets (see annotation 92-3) are in a normal state (see annotation 82-3). Annotation 102-3 indicates the 55% and the total number of assets which is 29 (see annotation 102-3). As indicated by the fault arc segment 122-4, 9% of the assets, or five assets, are in a fault state. The offline-normal arc segment 122-5 indicates that 9% of the assets, or five assets, are in an offline-normal state.
The status pane 126 lists the asset names in column 610. The second column 612 provides an overall status indicator. Finally, the product status is indicated in column 614 for each of the listed assets.
FIG. 14 shows the graphical user interface when the status pane 126 is selected. The pane expands to overlap the status widget 120. More detailed status information is provided in the pane from the information stored in the asset store 66. Specifically, the expanded status pane 126 shows the asset names column 610, the overall status indicator column 612, along with the product status column 614 from the respective columns in the asset store 66. In addition, however, it further comprises a dirty status column 616, an inspection status column 618, an updated status column 620, and a service status column 622. in this way, the inspection status, updated status, service status and dirty status of the specific products listed in column 612 are displayed based on the information contained in the asset store 66 of the asset manager 14.
FIG. 15 shows how the user interface changes when one of the arc segments 122 within the status widget 120 is selected. Specifically, in the illustrated example, the normal arc widget 122-3 has been selected by the user. This causes the status pane 126 to provide a filtered list of assets. Specifically, rather than all of the assets being listed in the status panel, the list is filtered to only those assets that have a normal status. In addition, selection of the normal arc widget 122-3 also causes the segment to become wider relative to the other arcs, indicating that it has been selected.
FIG. 16 shows the user interface when the alarm status arc 122-1 is selected by the user. The status pane 126 is updated. Specifically, the list provided in the status pane 126 are only those assets that are in an alarm status. The alarm status arc 122-1 also becomes wider relative to the other arcs, indicating that it has been selected.
FIG. 17 shows the graphical user interface when the inspection status graphical button 72-3 is selected. Specifically, the status pane 126 is updated to show the inspection status of the listed assets. Specifically, the asset list column 610 is provided. But two new columns 670 and 672 are shown. Specifically, column 670 shows the inspection status of the asset such as whether the inspection status is up to date or it is overdue for an inspection. In the case where an inspection is due in a short period of time, an imminent status is indicated. The additional information column 672 provides further information such as, if an inspection is due, in specifically and how many days, or, if the inspection is overdue, the number of days by which the inspection is overdue.
While this invention has been particularly shown and described with references to preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims.

Claims

What is claimed is:

1. A system for managing assets of building management systems, the system comprising:

an asset store for storing information concerning the assets of the building management systems;

a user account store for storing information concerning user accounts; and

an ownership store for enabling access by the user accounts in the user account store to the information in the asset store.

2. The system as claimed in claim 1, wherein the ownership store enables access by designating user accounts from the user account store as owners of assets represented in the asset store.

3. The system as claimed in claim 1, wherein the ownership store enables access by designating which user accounts with which information about assets represented in the asset store is shared.

4. The system as claimed in claim 3, wherein the ownership store further designates specific types of information to be shared with the user accounts.

5. The system as claimed in claim 1, further comprising a group hierarchy store for storing groups for the assets.

6. The system as claimed in claim 5, wherein the groups are ordered in a tree structure.

7. The system as claimed in claim 5, wherein the groups have owners, and the groups can be shared with other users.

8. The system as claimed in claim 1, wherein the assets include fire panels and intrusion panels.

9. The system as claimed in claim 1, further comprising sets of asset stores, user account stores and ownership stores being maintained for different organizations.

10. A method for managing assets of building management systems, the method comprising:

an asset store storing information concerning the assets of the building management systems;

a user account store information concerning storing user accounts; and

an ownership store enabling access by the user accounts in the user account store to the information in the asset store.

11. The method as claimed in claim 10, further comprising the ownership store enabling access by designating user accounts from the user account store as owners of assets represented in the asset store.

12. The method as claimed in claim 10, further comprising the ownership store enabling access by designating which user accounts with which information about assets represented in the asset store is shared.

13. The method as claimed in claim 12, further comprising the ownership store designating specific types of information to be shared with the user accounts.

14. The method as claimed in claim 10, further comprising group hierarchy stores storing groups for the assets.

15. The method as claimed in claim 14, wherein the groups are ordered in a tree structure.

16. The method as claimed in claim 14, wherein the groups have owners, and the groups can be shared with other users.

17. A system for managing assets of building management systems, the system comprising:

a user account store for storing information concerning user accounts;

an ownership store, for enabling access by the user accounts in the user account store to the information in the asset store; and

a custom name store for allowing each of the users to store a custom name for assets that are owned by or shared with the users.

18. A method for managing assets of building management systems, the method comprising:

a user account store information concerning storing user accounts; and

an ownership store enabling access by the user accounts in the user account store to the information in the asset store; and

a custom name store storing custom names assigned by the users for assets that are owned by or shared with the users.

19. A system for managing assets of building management systems, the system comprising:

an asset manager including an asset store for storing information concerning the assets of the building management systems, a user account store for storing information concerning user accounts, and an ownership store, for enabling access by the user accounts in the user account store to the information in the asset store;

a user device displaying a graphic user interface including names of assets and an ownership status of the assets as being owned or shared.

20. A method for managing assets of building management systems, the method comprising:

storing information concerning the assets of the building management systems;

storing information concerning user accounts; and

enabling access users to the information in the asset store and showing the users names of assets and ownership statuses of the assets as being owned or shared.