The subject matter disclosed herein relates generally to building management systems, and more particularly to a building management system that provides semantics-enabled access to building system data.
A building management system may be used to read building system data from a building system and to write building system data to a building system. For example, in an HVAC application, a building management system may be used to read existing chiller water temperatures and to write an updated chiller water temperature set point to the chiller controller. In current building installations, each system (HVAC, security, safety, and building transportation) provides a huge number of data points, i.e., I/Os, commands and configurable parameters. However, data points 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, reading or writing building systems 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; a data service module configured to access building system 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 building system data, the semantic descriptions of the building system 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 data service module, the user interface generating a user access request to access building system data.
In addition to one or more of the features described above, or as an alternative, further embodiments may include wherein the user access request is a read request.
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 building system data entries matching the user access request.
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 building system data entries matching the user access request 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 data service module to retrieve values from data sources identified by the knowledge base.
In addition to one or more of the features described above, or as an alternative, further embodiments may include wherein the data service module sends a request to the building system interface to retrieve the building system data in response to the metadata.
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 the requested building system data to the data service module.
In addition to one or more of the features described above, or as an alternative, further embodiments may include wherein the data service module sends the requested building system data 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 building system data 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 building system data 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 access request is a write request.
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 building system data entries matching the user access request.
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 building system data entries matching the user access request 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 building system data from a semantic format to a building system format.
In addition to one or more of the features described above, or as an alternative, further embodiments may include wherein the user interface send the building system data in the building system format to the data service module.
In addition to one or more of the features described above, or as an alternative, further embodiments may include wherein the data service module sends a write command to the building system interface with the building system data to be updated in the building system format.
In addition to one or more of the features described above, or as an alternative, further embodiments may include wherein the building system interface accesses the building system to update the building system data.
In addition to one or more of the features described above, or as an alternative, further embodiments may include wherein the building system interface forwards an acknowledgment of the update to the building system data to the data service module.
In addition to one or more of the features described above, or as an alternative, further embodiments may include wherein the data service module forwards the acknowledgment to the user interface.
Technical effects of embodiments of the disclosure include reading and writing building system data using semantic descriptions of the building system data.
These and other advantages and features will become more apparent from the following description taken in conjunction with the drawings.
and
A knowledge base 12 is provided to store building system 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 reading and writing building system data.
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.
A data 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 data service module 26 abstracts with a unique and universal interface a variety of systems and permits sensing/actuating a variety of devices in the building system 10. The data service module 26 uniquely addresses data points and performs read/write operations from/to the building system data 20 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 search facilities for allowing the user interface 14 to identify the relevant data sources and to answer search queries 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 data service module 26. Both read and write operations 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 data service module 26. In some embodiments, the user interface 14 will issue one request to the semantic service module 30 and the data service module 26, which will then implement a read or write as discussed herein. In other embodiments, the user interface 14 interacts with the semantic service module 30 and the data service module 26 commanding operations in sequence.
At 430, the knowledge base 12 provides metadata from building system data entries matching the user access request to the user interface 14. The metadata related to the matching data points in knowledge base 12 may include addressing information to identify the data source; characterization of the observable property manipulated by the data point (e.g., temperature, running status); related “tags” (e.g., chilled_water_leaving); type of data point (sensor, command, set point); communication protocol used to access the building system (e.g., analog input, binary value); capabilities and allowed values.
At 435, the user interface 14 send a request to the data service module 26 to retrieve values from the data sources identified at 410, including the retrieved metadata. At 440, the data service module 26 then uses the metadata to access the building system interface 24 to retrieve the building system data. At 450, the building system interface 24 accesses the physical building system 10, which replies with the requested building system data at 460. At 470, the building system interface 24 sends the retrieved building system data to the data service module 26. At 475 the user interface 14 receives the building system data in a building format of the building system 10. At 480, the user interface 14 accesses the semantic service module 30 to achieve a semantically normalized representation of the data retrieved at 475, i.e., to convert the building system data from the building format of the building system 10 to a semantic format interpretable by a user. For example, the user access request may request the current status of a valve. The value returned at 470 may be a number (e.g., 1 or 0). The processing at 480 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 “1” corresponds to semantic format of “open” (reference value defined in the ontology to be adopted for all the systems). At 490, the building system data in the semantic format is provided to the user interface 14 (i.e., the user interface indicates that the valve is open).
At 530, the knowledge base 12 provides a semantic description of building system data entries matching the user access request to the user interface 14. The semantic description includes metadata related to the matching data points in knowledge base 12. The metadata may include addressing information to identify the data source; characterization of the observable property manipulated by the data point (e.g., temperature, running status); related “tags” (e.g., chilled_water_leaving); type of data point (sensor, command, set point); communication protocol used to access the building system (e.g., analog input, binary value); capabilities and allowed values.
At 540, the user interface 14 access the semantic service module to convert the value/command the user want to push into the system to a format recognizable by the building system 10, which are returned at 550. Similar to the read operation of
At 555 user interface 14 issues a request to the data service module 26 to write a particular value/command on the identified parameter/set/commendable point. At 560, the data service module 26 sends a write command to the building system interface 24 along with the building system data to be updated in the building system format. At 570, the building system interface 24 accesses the physical building system 10 to update the building system data. At 580, the building system 10 sends an acknowledgement to the building system interface 24 that the building system data has been updated. At 590, the building system interface 24 forwards the acknowledgment to the data service 26. At 595, the data service module 26 forwards the acknowledgment to the user interface 14.
Embodiments provide a number of benefits including the use of a single user interface to perform semantic searches across multiple domains (e.g., HVAC, security, transportation, etc.), in order to identify data points matching particular features. The user interface provides a unique workflow, common to all building systems to access, normalize and control heterogeneous devices' data points, 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 |
---|---|---|---|
201611039965 | Nov 2016 | IN | national |
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/US2017/062783 | 11/21/2017 | WO | 00 |