The subject matter disclosed herein relates generally to building management systems, and more particularly to a building management system that provides for the creation of an event filter and the reporting of event data matching the event filter.
A building management system may be used to detect the occurrence of events at a building system by processing building system data. For example, in an HVAC application, a building management system may be used to monitor existing chiller water temperatures and to issue an event in the form of an alarm if the chiller water temperature exceeds a limit. In current building installations, each system (HVAC, security, safety, and building transportation) provides a huge number of events. Event data provided by devices belonging to different systems can only be accessed and controlled through heterogeneous, often proprietary protocols, and/or managed by isolated building management systems. As a result, accessing event data can be burdensome, given the multitude of protocols and isolated nature of the diverse building systems.
According to one embodiment, a building management system includes a building system interface configured to access a building system; an event service module configured to access event data in the building system through the building system interface; a knowledge base providing a model of the building system, the model including semantic descriptions of the event data, the semantic descriptions of the event data being arranged in an ontology; a semantic service module in communication with the knowledge base; and a user interface in communication with the semantic service module and the event service module, the user interface generating a user request to create an event filter having a filter criterion and report event data matching the filter criterion.
In addition to one or more of the features described above, or as an alternative, further embodiments may include wherein the semantic service module accesses the knowledge base to retrieve event data entries matching the event filter.
In addition to one or more of the features described above, or as an alternative, further embodiments may include wherein the knowledge base provides metadata from event data entries matching the event filter to the user interface.
In addition to one or more of the features described above, or as an alternative, further embodiments may include wherein the user interface sends a request to the event service module to report event data matching the filter criterion.
In addition to one or more of the features described above, or as an alternative, further embodiments may include wherein the event service module sends a request to the building system interface to retrieve event data matching the filter criterion.
In addition to one or more of the features described above, or as an alternative, further embodiments may include wherein the building system interface sends event data matching the filter criterion to the event service module.
In addition to one or more of the features described above, or as an alternative, further embodiments may include wherein the event service module sends the event data matching the filter criterion to the user interface.
In addition to one or more of the features described above, or as an alternative, further embodiments may include wherein the user interface accesses the semantic service module to convert the event data matching the filter criterion from a building system format to a semantic format.
In addition to one or more of the features described above, or as an alternative, further embodiments may include wherein the semantic service module forwards the event data matching the filter criterion in the semantic format to the user interface.
In addition to one or more of the features described above, or as an alternative, further embodiments may include wherein the user request to create the event filter includes a reporting period.
In addition to one or more of the features described above, or as an alternative, further embodiments may include wherein the event service module sends the event data matching the filter criterion to the user interface in response to the reporting period.
Technical effects of embodiments of the disclosure include the ability to create an event filter having a filter criterion and report event data matching the filter criterion to user.
These and other advantages and features will become more apparent from the following description taken in conjunction with the drawings.
A knowledge base 12 is provided to store building system data, including event data. The knowledge base 12 may be embodied on a microprocessor-based device having a memory, such as a computer server. The building system data from building system 10 is processed to form semantic descriptions of the building system data. The semantic descriptions of the building system data are stored in ontologies in knowledge base 12. In addition to variables and control values, the knowledge base 12 includes a model of the building system 10 across different domains (HVAC, building transportation, security, safety, etc.). Through the semantic descriptions and the ontology, entities (e.g., equipment, devices, zones, spaces, event sources, data sources, sensors, commands, configuration parameters) and their relationships are defined in the knowledge base 12.
A user interface 14 is used to access the knowledge base 12 in response to user queries. The user interface 14 may be implemented using an application program interface (API) accessible over a network such as a LAN, WAN, global network (e.g., Internet), etc. The user interface 14 provides an interface for creating an event filter and reporting event data matching the event filter criterion.
The ontology of the knowledge base 12 provides a model of the business system 10 by interrelating entries in the knowledge base 12 to provide an organization and representation of the physical business system 10. The ontology defines and models entities such as spaces (e.g., physically-delimited areas such as sites, buildings, floors, etc.), equipment (e.g., mechanical devices that compose a system (e.g., chillers, AHUs, access doors, etc.)), devices (e.g., electronic devices that provide I/O or data elaboration functionality (e.g., actuators, systems on a chip, sensor devices, etc.)) and information objects (e.g., information entities associated with devices and possibly representing inputs, outputs, configuration parameters, events, etc.). The building system model is encoded in a machine-processable ontology language, describing building entities and relationships relevant to each addressed domain (e.g., HVAC, building transportation, security, safety). The implementation of such a reference model may rely on formal/logic-based languages (e.g., OWL/RDF, description logics, datalog variants, F-logic) that enable automated inference and efficient query capabilities.
Access to the knowledge base 12 may be made through semantic query languages, such as SPARQL. An example embodiment can be based on the use of RDF as generic data model for the representation of the building systems as semantic graphs, where various entities occurring in the building systems are related to each other and mapped to the ontology according to a linked data architecture. Examples of information provided by the ontology of the knowledge base 12 include, but are not limited to, the structure of a building (floors, room, etc.); the devices installed in the building located into spaces; relationships among equipment pieces (e.g., a specific air handling unit serves a specific variable air volume box); an annotated description of I/O, commands and configurable parameters provided by each device, together with the related source system addressing information. It is understood that the ontology of the knowledge base 12 may define and model a wide variety of entities, and embodiments are not limited to the examples provided in this disclosure.
The event service module 26 may be implemented by a software application executing on a microprocessor-based device having a memory, such as a computer server. The event service module 26 abstracts with a unique and universal interface a variety of systems and permits receiving event data from a variety of devices in the building system 10. The event service module 26 uniquely addresses data points and receives event data through an integration bus where system-specific connectors and low-level drivers may be connected.
A semantic service module 30 may be used to create commands for interfacing with the knowledge base 12 in a format recognized by the knowledge base 12. The semantic service module 30 may be embodied on a microprocessor-based device having a memory, such as a computer server. In one embodiment, the semantic service module 30 may serve as a RESTful endpoint to provide GET, PUT, POST or DELETE commands in a format recognized by the knowledge base 12. The semantic service module 30 provides semantic facilities for allowing the user interface 14 to identify the filter criterion for an event filter formulated in a way that is independent from the type or domain of any individual system. The semantic service module 30 is built on top of a query engine exploiting the semantic knowledge-base 12, which provides a reconciled, integrated and linked view of building system data sources across different domains.
The user interface 14 provides an interface to both the semantic service module 30 and the event service module 26. Both creation of the event filter and reporting event data matching the event filter criterion may be initiated from the user interface 14, as described in further detail herein. The user interface 14 can coordinate operations by the semantic service module 30 and the event service module 26. In some embodiments, the user interface 14 will issue one request to the semantic service module 30 and the event service module 26, which will then implement event filtering. In other embodiments, the user interface 14 interacts with the semantic service module 30 and the event service module 26 commanding operations in sequence.
At 420, the semantic service module 30 accesses knowledge base 12 to retrieve event data entries matching the user request. The semantic service module 30 converts the user filter criterion to a form compatible with searching knowledge base 12.
At 430, the knowledge base 12 provides metadata from event data entries matching the user filter criterion to the user interface 14. The metadata related to the matching filter criterion in knowledge base 12 may include addressing information to identify the event source through the event service; characterization of the observable event (e.g., temperature, running status); related “tags” (e.g., chilled_water_leaving); type of event source (e.g., change-of-value, alarm, notification); communication protocol used to access the building system (e.g., analog input, binary value); capabilities and allowed values.
If the user filter criterion results in no entries in the knowledge base 12, then an error message may be generated by either the semantic service module at 410 or by the knowledge base 12 at 420. For example, the user may submit event filter criteria requesting unauthorized access attempts for a main lobby. However, the main lobby main be an open public space, meaning that there will be no unauthorized access attempts. In such cases, the semantic service module 30 or knowledge base 12 will notify the user interface 14 at 430 that the event filter criterion does not exist in the event data in the knowledge base 12. At 435, the user interface 14 sends a request to create an event filter to the event service module 26 based on the meta-data retrieved from the knowledge base at 430, which encode the filter criteria identified at 410.
The request may include a reporting period for reporting event data, such as report event data in real time, report event data once a day, once a week, etc. At 440, the event service module 26 creates the event filter, including the reporting period and send an acknowledgement to the user interface 14 that the event filter has been created.
At 575, the event service module 26 sends event data retrieved from the building system interface and matching the filter criterion to the user interface 14. The event data is sent to the user interface 14 in accordance with the reporting period (e.g., once per day) identified in the request to create the event filter. The user interface 14 receives the event data from the event service module 26 in a building format of the building system 10. At 580, the user interface 14 accesses the semantic service module 30 to achieve a semantically normalized representation of the data received at 575, i.e., to convert the event data from the building format of the building system 10 to a semantic format interpretable by a user. For example, the event filter may request all alarm events associated with a chiller. The value returned at 570 may be a binary representation of an alarm (e.g., 01, 10 or 11). The processing at 580 converts the building system data from the building system format to a semantic format. In this example, the semantic service module 30 determines that the building system format of “10” corresponds to semantic format of “mid-level alarm.” At 590, the event data in the semantic format is provided to the user interface 14 (i.e., the user interface indicates that a mid-level alarm occurred).
Embodiments provide a number of benefits including the use of a single user interface to define semantic events across multiple domains (e.g., HVAC, security, transportation, etc.), in order to identify event data matching particular features. The user interface provides a unique workflow, common to all building systems to access, normalize and control heterogeneous devices' event data, therefore focusing on the actual value proposition. Embodiments leverage querying and inferences execution performance with specific semantics-based techniques.
While the disclosure has been described in detail in connection with only a limited number of embodiments, it should be readily understood that the disclosure is not limited to such disclosed embodiments. Rather, the disclosure can be modified to incorporate any number of variations, alterations, substitutions or equivalent arrangements not heretofore described, but which are commensurate with the spirit and scope of the disclosure. Additionally, while various embodiments of the disclosure have been described, it is to be understood that aspects of the disclosure may include only some of the described embodiments. Accordingly, the disclosure is not to be seen as limited by the foregoing description, but is only limited by the scope of the appended claims.
Number | Date | Country | Kind |
---|---|---|---|
201611039964 | Nov 2016 | IN | national |
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/US2017/062778 | 11/21/2017 | WO | 00 |
Publishing Document | Publishing Date | Country | Kind |
---|---|---|---|
WO2018/098148 | 5/31/2018 | WO | A |
Number | Name | Date | Kind |
---|---|---|---|
6167316 | Loudeman et al. | Dec 2000 | A |
6973410 | Siegel | Dec 2005 | B2 |
7734572 | Wiemeyer et al. | Jun 2010 | B2 |
7895257 | Helal et al. | Feb 2011 | B2 |
8117233 | Liu et al. | Feb 2012 | B2 |
8234704 | Ghai et al. | Jul 2012 | B2 |
RE43803 | Frank et al. | Nov 2012 | E |
8516016 | Park et al. | Aug 2013 | B2 |
8522195 | Miloslavsky et al. | Aug 2013 | B2 |
8682921 | Park et al. | Mar 2014 | B2 |
8818930 | Yanase | Aug 2014 | B2 |
9111088 | Ghai et al. | Aug 2015 | B2 |
9116978 | Park et al. | Aug 2015 | B2 |
9157647 | Leen et al. | Oct 2015 | B2 |
9189527 | Park et al. | Nov 2015 | B2 |
20020072982 | Barton et al. | Jun 2002 | A1 |
20070236346 | Helal | Oct 2007 | A1 |
20080228812 | Oglesby et al. | Sep 2008 | A1 |
20090177634 | Behrendt et al. | Jul 2009 | A1 |
20100324927 | Tinsley | Dec 2010 | A1 |
20100324962 | Nesler | Dec 2010 | A1 |
20110078107 | Almeida et al. | Mar 2011 | A1 |
20110088000 | Mackay | Apr 2011 | A1 |
20110273283 | Schmuttor | Nov 2011 | A1 |
20120011126 | Park et al. | Jan 2012 | A1 |
20120110158 | Koch et al. | May 2012 | A1 |
20120203806 | Panushev | Aug 2012 | A1 |
20130218349 | Coogan et al. | Aug 2013 | A1 |
20130238795 | Geffin et al. | Sep 2013 | A1 |
20130261833 | Meghani et al. | Oct 2013 | A1 |
20130268317 | Mattila | Oct 2013 | A1 |
20130339104 | Bose | Dec 2013 | A1 |
20140149249 | Goad et al. | May 2014 | A1 |
20140207759 | Park et al. | Jul 2014 | A1 |
20140337010 | Akolkar et al. | Nov 2014 | A1 |
20140344718 | Rapaport et al. | Nov 2014 | A1 |
20150088312 | Lo et al. | Mar 2015 | A1 |
20150113462 | Chen et al. | Apr 2015 | A1 |
20150253748 | Brun et al. | Sep 2015 | A1 |
20150294543 | Ricks | Oct 2015 | A1 |
20160026631 | Salam et al. | Jan 2016 | A1 |
20160197769 | Britt et al. | Jul 2016 | A1 |
20170366414 | Hamilton | Dec 2017 | A1 |
Number | Date | Country |
---|---|---|
103440309 | Dec 2013 | CN |
105205148 | Dec 2015 | CN |
105677795 | Jun 2016 | CN |
2043009 | Apr 2009 | EP |
2701357 | Feb 2014 | EP |
2005052720 | Jun 2005 | WO |
2007098468 | Aug 2007 | WO |
2012091541 | Jul 2012 | WO |
2012177630 | Dec 2012 | WO |
2013173108 | Nov 2013 | WO |
2015011446 | Jan 2015 | WO |
Entry |
---|
International Search Report and Written Opinion for application PCT/US2017/062778, dated Feb. 19, 2018, 13 pages. |
International Search Report and Written Opinion for application PCT/US2017/062783, dated Feb. 1, 2018, 12 pages. |
Number | Date | Country | |
---|---|---|---|
20190379555 A1 | Dec 2019 | US |