Patent Description:
The present disclosure relates generally to devices, methods, and systems for configuring and operating building management systems. More particularly, the present disclosure relates to devices, methods, and system for configuring, monitoring, and servicing building management systems.

Building management systems often include and/or are deployed to control various electrical and electromechanical components and/or systems of or installed at a building. Example components and/or systems installed in a building include, but are not limited to, heating, ventilation, and air conditioning (HVAC) systems and components thereof, surveillance systems and components thereof, security systems and components thereof, etc. Building systems of or for control by a building management system may include devices from a single company configured to communicate and/or operate using a single, common protocol; however, often times a building management system may include devices from various companies and/or devices configured to communicate and/or operate on a different protocol than one or more other devices of the building system. Building systems controlled and/or monitored by a building management system may be located at a single building and/or two or more buildings located adjacent one another and/or geographically spaced apart.

<CIT> discloses methods and apparatus for virtualizing building management systems. An apparatus embodiment comprises a first API for accessing on-premise building management systems; coupled to the first API, a virtualization engine configured to receive and deploy commands to the first API; and coupled to the virtualization engine, a second API configured to receive and deploy commands to the virtualization engine.

<CIT> discloses control infrastructure comprising a script execution module that comprises a compiler that compiles scripts, having instructions that reference device properties, into virtual-machine programs, a virtual machine that executes virtual-machine programs, and a script manager that stores scripts, retrieves scripts, and loads scripts into the compiler.

The present disclosure generally relates to configuring building management systems, and more particularly, to configuring, monitoring, and servicing of a building management system using a common building management system model.

The present system and approach may incorporate one or more processors, computers, controllers, user interfaces, wireless and/or wire connections, and/or the like, in an implementation described and/or shown.

Building management systems may include one or more models of one or more related building systems to facilitate monitoring and/or controlling devices of the building systems. Example building systems and devices include, but are not limited to, HVAC systems, controllers, thermostats, dampers, air handling units (AHU), roof top units (RTU), variable air volume systems (VAV), particle sensors, gas sensors (e.g., volatile organic compounds (VOC) sensors and/or other suitable gas sensors), humidity sensors, temperature sensors, carbon dioxide sensors, carbon monoxide sensors, variable refrigerant flow (VRF) systems, and/or one or more other suitable building systems and/or devices.

A building management system supervisor may be implemented to facilitate an organization interacting with its building management system. The supervisor may include graphics pages, schedules, histories, trends, etc. for the building management system and devices thereof. Three types of building management system supervisor deployments may exist and may be determined based on a size, footprint, and/or factor relevant to an organization. The types include a single-site type, a multi-site type, and a cloud based deployment type. In a single site, a standalone deployment of a building management system supervisor may be installed on a premise of an organization location either as an embedded supervisor or installed on a computing device which may communicate with controllers and/or field devices. In a large site or multi-site type, deployment of the building management system supervisor may be at a data center so as to be scalable. In a cloud based deployment of a building management system supervisor, a portion of or the complete supervisor may be hosted in the cloud and may communicate with installed devices via one or more network connections.

Building management systems may include a system model of the building systems of one or more buildings. The system model may be utilized in different phases of using the building management system including, but not limited to an installation phase, an engineering phase, a commissioning phase, an operation phase, a maintenance phase, and/or one or more other suitable phases of using the building management system. In some cases, the system model may facilitate field technicians with installing and/or configuring building devices (e.g., gateways (e.g., a plant controller), controllers, thermostats, etc.) that may be responsible for controlling building equipment (e.g., VRF systems, AHUs, lighting, etc.). Building devices and building equipment may referred to herein collectively as devices, equipment, and/or devices and equipment.

System models for building management systems may provide system details and a hierarchy of locations, devices, and equipment for creating, installing, and operating the building management systems. System models may be accessible and configurable by one or more technicians during a setup and/or during operation of a building management system for one or more buildings. Further, the system model may support a building or facility manager in monitoring and/or controlling devices at a building. In one example, the system model may facilitate a building manager in monitoring and/or controlling one or more sites at different levels of an organization hierarchy (e.g., at a state level, at a region level, at a country level, etc., which may differ in each organization and/or system model). Additionally or alternatively, the system model may facilitate a technician in trouble shooting issues in devices and/or equipment by providing details related to the device and the noted issue (e.g., by providing details of applications present in relevant devices, details of the devices, details of equipment controlled by a device, etc.).

System models may be hardware and/or software specific. For example, a system model may specify one or more communication and/or operational protocols supported by a device or piece of equipment, specify one or more application structures supported by firmware present in a device or piece of equipment, aid in handling one or more limitations of the hardware and/or software of a device (e.g., a maximum number of data points supported, types of data points supported, application size limits, etc.). As a result, the system model may only be suitable to configure and/or install specified products, which may make it difficult to have a seamless solution for all devices and equipment provided by one or more manufacturers of the devices and equipment across multiple phases of a building management system development, implementation, operation, and/or other suitable phases. Due to the specified nature of system models for building management systems, users and/or user tools (e.g., hardware and/or software tools) may need to reenter the same data or utilize a manual mechanism (e.g., exporting and/or importing data), which is prone to error. As a result, it is desirable to utilize a system model (e.g., a common model) that is agnostic to which manufacturer provides a device and/or a protocol on which the device operates.

The system model may be configured to enforce standardized device names and/or standardized point names that are hardware agnostic for a plurality of devices and/or equipment installed at one or more buildings of an organization utilizing the building management system. Further, the system model may receive hardware agnostic point information and provide hardware agnostic control commands for controlling the plurality of devices and/or equipment installed at the one or more buildings.

<FIG> depicts a schematic over view of a building management system (BMS) <NUM>. The building management system may have, include, and/or be in communication with one or more devices, device access mechanisms, and/or equipment at one or more building sites and/or locations. All or at least some of the devices, device access mechanisms, and/or equipment may be, may include, and/or may be configured to communicate with computing devices.

Example devices of the BMS <NUM> may include, but are not limited to, a server <NUM> (e.g., a remote server, a local server, and/or one or more other suitable server), a hub and/or gateway <NUM> (e.g., a Modbus gateway, a Zigbee hub, Beats gateway) for facilitating a connection between the equipment and the server <NUM>, and/or other suitable devices. Example device access mechanisms of the BMS <NUM> may include, but are not limited to, a cloud platform, a web portal (e.g., a web application, a website, etc.) for accessing the BMS <NUM> from a mobile device <NUM>, computer <NUM> (e.g., a laptop, a personal computer (PC), etc.), and/or other suitable computing device. Example equipment for a building <NUM> operating within the BMS <NUM> may include, but are not limited to, a lighting level sensor <NUM>, a motion detection sensor <NUM> (e.g., a PIR sensor and/or other suitable motion detection sensor), a VOC sensor <NUM>, a temperature/humidity sensor <NUM>, a CO<NUM> sensor <NUM>, a sensor <NUM> in communication with an input/output (I/O) port <NUM> (e.g., a smart I/O portion, a communications port, etc.), a VRF unit <NUM>, lighting <NUM>, a thermostat <NUM>, an RTU <NUM>, a meter <NUM> (e.g., an energy meter and/or other suitable meter), and/or one or more other suitable pieces of equipment. Although <FIG> depicts the BMS <NUM> including the server <NUM> being remote from the computer <NUM>, the BMS may be implemented in the computer <NUM> and/or one or more other suitable computers that are local and/or remote from one or more buildings <NUM> within the BMS <NUM>. Further, although the BMS <NUM> depicted in <FIG> shows equipment at a single building, the BMS <NUM> may be configured to span across two or more buildings and/or locations.

<FIG> illustrates an example of a computing device <NUM> that may be or may be included in the computing devices discussed herein. The computing device <NUM> may represent all or part of one or more of the devices, device access mechanisms, and/or pieces of equipment of the BMS <NUM>, and/or tools utilized with and/or to communicate with the BMS <NUM>. The computing device <NUM> may be and/or may be part of, for instance, a smart phone, a tablet, a personal digital assistant (PDA), a personal computer, a beacon, a camera, a display device, a video recorder, a network component, and/or other suitable computing device. However, configurations of the present disclosure are not limited to a particular type of computing device <NUM>.

As shown in <FIG>, the computing device <NUM> may include memory <NUM> and a processor <NUM> that may communicate with one another such that the processor <NUM> may execute instructions (e.g., application program code of a mobile application or software, among other instructions) stored on the memory <NUM>. The computing device <NUM> may further include a user interface <NUM>, a communications port <NUM>, and/or one or more other suitable components.

The memory <NUM> may be any type of storage medium that can be accessed by the processor <NUM> to perform various examples of the present disclosure. For example, the memory <NUM> may be a non-transitory computer readable medium having computer readable instructions (e.g., computer or application program instructions) stored thereon that are executable by the processor <NUM> for performing one or more methods or techniques described herein.

The memory <NUM> may be may be volatile or nonvolatile memory. The memory <NUM> may also be removable (e.g., portable) memory, or non-removable (e.g., internal) memory. For example, the memory <NUM> may be random access memory (RAM) (e.g., dynamic random access memory (DRAM) and/or phase change random access memory (PCRAM)), read-only memory (ROM) (e.g., electrically erasable programmable read-only memory (EEPROM) and/or compact-disk read-only memory (CD-ROM)), flash memory, a laser disk, a digital versatile disk (DVD) or other optical disk storage, and/or a magnetic medium such as magnetic cassettes, tapes, or disks, among other types of memory.

Further, although the memory <NUM> is illustrated as being located in the computing device <NUM>, embodiments of the present disclosure are not so limited. For example, the memory <NUM> may also be located internal to another computing resource (e.g., enabling computer readable instructions to be downloaded over the Internet or another wired or wireless connection).

The processor <NUM> of the computing device <NUM> may include a single processor or more than one processor working individually or with one another (e.g., dual-core, etc.). The processor <NUM> may be configured to execute instructions, including instructions that may be loaded into the memory <NUM> and/or other suitable memory. Example processor components may include, but are not limited to, microprocessors, microcontrollers, multi-core processors, graphical processing units, digital signal processors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), discrete circuitry, and/or other suitable types of data processing devices.

The user interface <NUM>, when provided, may be any suitable user interface and/or user interface components configured to facilitate a user of the computing device <NUM> interacting with the computing device <NUM> via the user interface <NUM>. For example, the user interface <NUM> may be used to provide information to and receive information from the user of the computing device <NUM>. For instance, the user interface <NUM> may receive selections of equipment and equipment settings, provide notifications of events and/or alerts, etc. The user interface <NUM> may include a keyboard or keyboard functionality, a pointer (e.g., a mouse, touch pad, or touch ball) or pointer functionality, a microphone, a speaker, a light system, a haptic system, a camera, a video camera, and/or other suitable user interface features the user may use to input information into and/or receive information from the computing device <NUM>. Configurations of the present disclosure, however, are not limited to a particular type(s) of user interface <NUM>.

In some cases, the user interface <NUM> may include a graphical user interface (GUI) that may have a display <NUM> (e.g., a screen) that may provide and/or receive information to and/or from the user of the computing device <NUM>. The display <NUM> may be, for instance, a touch-screen (e.g., the GUI may include touch-screen capabilities).

The communications port <NUM> may be any type of communication port(s) and may facilitate wired and/or wireless communication with one or more networks. In one example, the communications port <NUM> may facilitate communication with one or more networks and/or other devices (e.g., sensors, equipment, other computing devices, mobile devices, servers, and/or other suitable devices) through any suitable connection including, but not limited to, radio communication, Ethernet, cellular communication, ZigBee, REDLINK™, Bluetooth, Bluetooth, Modbus, Beats, Low Energy (BLE), WiFi, IrDA, dedicated short range communication (DSRC), EnOcean, Near Field Communication (NFC), and/or any other suitable common or proprietary wired or wireless protocol. In one example, the communications port <NUM> may at least include a port configured to communicate over a Wi-Fi and/or Bluetooth connection with one or more pieces of building equipment (e.g., temperature sensors, thermostats, controllers, etc.).

<FIG> depicts a block diagram of example phases of creating and implementing a system model of the BMS <NUM>. Example phases of creating and implementing the system model of the BMS <NUM> may include at least one or more of a first phase <NUM> of gathering project information, a second phase <NUM> of commercial preparation, a third phase <NUM> of controller configuration, a fourth phase <NUM> of site model configuration, a fifth phase <NUM> of system configuration, and a sixth phase <NUM> of installation and checkout.

The first phase <NUM>, gathering project, information may include one or more steps. The one or more steps of the first phase <NUM> may include, but are not limited to, collecting organization information relating to the organization of the company utilizing the BMS <NUM>, collecting spatial information for the building sites of the company utilizing the BMS <NUM>, selecting a cloud analytics package for analyzing, operating, and maintaining the BMS <NUM>, etc..

The second phase <NUM>, commercial preparation, may include one or more steps. The one or more steps of the second phase <NUM> may include, but are not limited to, project estimation to define the scope and the cost of creating, implementing, and/or maintaining the BMS <NUM>, creating a sales proposal with the project estimation, licensing, etc..

The third phase <NUM>, controller configuration, may include one or more steps. The one or more steps of the third phase <NUM> may include, but are not limited to, hardware engineering, software engineering, etc. In some cases, the hardware engineering and/or software engineering may include identifying the equipment needed for the BMS <NUM> and creating configurations for controllers using various tools (e.g., IQSET, PG5, etc.).

The fourth phase <NUM>, site model configuration, may include one or more steps. The one or more steps of the fourth phase <NUM> may include, but are not limited to, point configuration, etc. In some cases, the point configuration may utilize a migration wizard tool that migrates information from the third phase <NUM> to the fourth phase <NUM> to identify data points needed to operate the equipment and maintain the BMS <NUM>.

The fifth phase <NUM>, system configuration, may include one or more steps. The one or more steps of the fifth phase <NUM> may include, but are not limited to, creating schematics, graphics, etc. for the system model of the BMS <NUM>, create a navigation structure through the various components of the BMS <NUM> (e.g., sites, devices, equipment, etc.), set up schedules, trends, alarms for operating and/or maintaining devices of the BMS <NUM>, assign users to various portions of the system model (e.g., as access rights, etc.), build dashboards for interacting with the BMS <NUM> to operate and/or maintain the BMS <NUM>, create summary screens to provide summaries of the operation and/or maintenance of the BMS <NUM>, set up analytics for operating, monitoring, and/or maintaining the BMS <NUM>, etc. In some cases, NIAGARA™ workbench and/or HONEYWELL™ BMS Supervisor creation tool may be utilized for the fifth phase <NUM>.

The sixth phase <NUM>, installation and checkout, may include one or more steps. The one or more steps of the sixth phase <NUM> may include, but are not limited to, rough-in and install devices of the BMS <NUM>, provide a point-to-point checkout of the devices, provide system commissioning, turnover the system to the company utilizing the BMS <NUM>. In some cases, users may operate and/or maintain the equipment at one or more building sites utilizing the BMS <NUM> through a supervisor user interface providing access to the system model.

Generally, various tools are utilized at different phases of the system model creation and implementation to access and/or configure the system model. In some cases, the various tools may be configured to directly access and update the system model. The various tools may be configured to run on mobile devices and/or other suitable devices.

In some cases, the tools used to create and implement the system model may utilize a context discovery feature which may parse names of data points to building contextual information for equipment types, data point roles, control parameter usage, etc., but such context discovery features may be prone to error and require manual review and entry because the data points parsed do not follow a standard naming protocol. As a result, a hardware/software agnostic manner of preparing a system model for the BMS <NUM> has been developed that offers a seamless solution for developing, installing, configuring, monitoring, and/or servicing the BMS <NUM>, where the BMS <NUM> utilizes devices from different product lines and/or different manufacturers, without users having to manually monitor the results of context discovery features and/or manually enter information at each phase of the system model development.

The system model (e.g., the common model) for the BMS <NUM> may include various features and/or details of the BMS <NUM> that allows for creation and implementation of the BMS <NUM> without a need to utilize a migration tool and/or manually entering information at various phases of the system model creation that were entered at previous phases. The features and/or details of the BMS <NUM> provided in the system model may include, but are not limited to, one or more of a site hierarchy model (e.g., an organizational hierarchy such as one or more portfolios → one or more regions → one or more countries → one or more sites and/or other suitable site hierarchy model created based on a structure followed in an organization utilizing the BMS <NUM>), spatial hierarchy and/or spatial elements (e.g., a space configuration at a site, such as a building, where the site may be split up by one or more floors → one or more zones → one or more rooms, etc.), elements (e.g., devices and/or equipment of the BMS <NUM>) that may be defined as generic structure that may contain only equipment details and reference to a spatial location at which the equipment is installed, but not specific details depending on a manufacturer and/or protocol of the equipment, property set up (e.g.. details of data points, control parameters of the application, etc.), installed locations of at least some of the devices installed in the buildings, alarm configuration (e.g., configuration of alarms that need to be raised in case of undesired operation of and/or of components of the BMS <NUM> (e.g., a high and/or low limit for temperature and/or other suitable alarm configurations)), schedule configuration (e.g., automated time-based control of equipment of the BMS <NUM>), etc..

In some cases, the system model as it is being developed and when it is completed may be stored on the cloud and/or at a central database that may be accessible by different tools utilized for the different phases of system model development. Utilizing a single database or location for storing the system model as it is being developed and/or once it is completed, may facilitate utilizing a single ontology for developing the system model and ensuring tools for the different phases of the system model receive updated and complete information without requiring manual re-entry by users of already provided information.

The single ontology may define a generic naming structure based on standard definitions of equipment. Rather than providing specific product naming to equipment, the single ontology may define standard equipment type name such as AHU, VRF, lighting, thermostat, etc. and standard data point roles (e.g., ZoneTemperature, ZoneHumidity, etc.) independent of manufacturer and operational protocols. In some cases, the model may support storing data based on a standard protocol (e.g., BACnet, Modbus, etc.) in custom attributes used by equipment when configurations in the system model are pushed to the equipment, but this is not required and the system model may be protocol agnostic.

To facilitate creating system models and/or adding to system models using the single ontology, the tool (e.g., a website, a web application, etc.) used to create and/or add to system models may utilize templates to create sites, devices, and/or equipment in the system model. The templates may include drop down menus and/or other selectable or automatically implemented elements to create devices and/or equipment in the system model (e.g., a sample "lighting" equipment template that may require monitoring of temperature in a zone, and occupancy, may utilize generic names "OccupancySensor", "NetworkOverride", "Status", "ZoneTemperature", along with associated parameters). A system model created in such away may be operationally ready and available out of the box, such that gateway devices may translate the generic names of devices and/or equipment to protocols utilized by the devices and equipment provided by one or more manufacturers and/or that operate on two or more protocols.

The gateway may be software-based and/or hardware based. Further, the gateway may be part of a cloud service and/or a separate device at a building and/or a site.

In operation, the BMS <NUM> may be monitored using a web application, a website, a web portal, and/or other suitable portal. Such a portal may be called a "supervisor portal" and any additions or modifications made at the supervisor portal may adhere to the standard definitions based on the single ontology. Moreover, devices, equipment, and data provided in the view of the supervisor portal may follow the standard definitions and single ontology.

<FIG> is a schematic view of how the system model of the BMS <NUM>, which utilizes the standard definitions and single ontology, may be created and/or utilized. Engineering tools <NUM> may be utilized to create, build, and/or add to the system model of the BMS <NUM>. The engineering tools may be software tools accessed via mobile devices, where the engineering tools <NUM> may be utilized to build the system model from one or more common templates stored at a central database <NUM> (e.g., where the central database <NUM> may be in the cloud as a cloud server, at an organizational computing device at one or more building locations of the organization, and/or at one or more other suitable locations). Installation and commissioning tools <NUM> may be utilized to install the system model from the central database <NUM> into the devices of or in communication with the BMS <NUM>. Further, a supervisors <NUM> may access the supervisor portal of the system model and BMS <NUM> from the central database <NUM>. Service of the BMS <NUM> may be provided via facility management <NUM> through a web portal and interacting with the system model having the generic naming structure.

In operation, data from the devices of the BMS <NUM> may be provided to the gateway in the generic naming structure and/or a naming structure specific to a device or equipment. The gateway may translate any device-type specific data into the generic naming structure of the system model and save the data at the central database <NUM> and/or at a database in communication with the central database <NUM>. The data may then be presented to a user via the supervisor portal (e.g., from the central database <NUM>) using the generic naming structure and the control of devices may be implemented and/or modified by a user via the supervisor portal.

Because the engineering tools <NUM>, the installation and commissioning tools <NUM>, the supervisor <NUM>, and the facility management <NUM> are accessing system models utilizing a single ontology and naming structure, there is no need for manual re-entry of data from tool to tool. Instead, tools are able to seamlessly integrate data as needed and control and maintenance from a supervisory level may be done independent of or agnostic to a particular device type or protocol type.

<FIG> is a box diagram schematically depicting the flow of information between devices <NUM> and user tools <NUM>. The device and/or equipment <NUM> may utilize various protocols including, but not limited to, BACnet, LON, LonWorks, Modbus, MBus, DALI, KNX, EnOcean, Ethernet, Zigbee, Wifi, Redlink, and/or other suitable protocols. In some cases, the devices may be provided by one or more different building management and/or automation companies including, but not limited to Honeywell, Trend, SBC, Centraline, Inncom, Alerton, Webs, etc. The data from and/or the configurations of devices and/or equipment utilizing the protocols may be provided to a gateway <NUM> having a common object model (e.g., the common object model may be utilized to translate protocol specific information into the general names based on the single ontology).

The gateway <NUM> may provide one or more functions. For example, the gateway <NUM> may perform a protocol normalization (e.g., to one of BACnet, LonWorks, Modbus, etc.), transform and/or normalize data formats, protocols, drivers, etc. (e.g., provide device hardware agnostic point information and translate device hardware agnostic point information into hardware specific point information for controlling the hardware (e.g., devices installed at the one or more buildings)), provide migration tools, perform context analytics, and provide a connection to the cloud through which the system model at the central database may receive hardware agnostic point information.

In operation, the gateway <NUM> may be communicatively coupled to one or more devices and/or pieces of equipment installed at one or more buildings utilizing the BMS <NUM> and the central database (e.g., the central database <NUM> or other suitable central database <NUM>). The gateway <NUM> may be configured to receive point information and/or other suitable data from the one or more devices installed at the one or more buildings and convert the received point information into hardware agnostic point information before sending the hardware agnostic point information to the system model. Further, the gateway <NUM> may be configured to receive hardware agnostic control commands from the system model and convert the received hardware agnostic control commands into hardware specific control commands before sending the hardware specific control commands to the associated devices and/or pieces of equipment installed at the one or more buildings.

The gateway <NUM> may be located at a building of the one or more building and/or at the central database <NUM>. In one example the gateway <NUM> may be installed at a building of the one or more buildings, such that the gateway <NUM> may communicate with the central database <NUM> over one or more network connections.

From the gateway <NUM>, a single common messaging system or bus <NUM> may be utilized to provide the general interactions between the gateway(s) <NUM> to the cloud or centralized services/platform/database <NUM>. The single common messaging system or bus <NUM> may utilize standard internet of things (IoT) protocols like MQTT/AMQP and/or other suitable protocols.

The centralized services/platform/database <NUM> may include, among other features, platform services, supervisory services, the system model (e.g., a common building model), administrative services, model services, a database, tool APIs, and/or other suitable features. The supervisory services may include, but are not limited to, one or more of alarm/event services, history services, scheduling services, analytics services, point read/write services, OTA (over the air) updates, COV/subscription notifications, etc. The administrative services may include, but are not limited to, one or more of user/organization CRUD, RBAC, licensing APIs, subscription APIs, etc. The model services may include, but are not limited to, one or more of model CRUD, model sync, model discovery, context discovery. Features of the tools API may include, but are not limited to, common templates, common libraries, translation APIs, etc. In some cases, the services and/or features provided by the cloud or centralized services/platform/database <NUM> may be considered to be and/or may utilize microservices.

Users may interact with the information and/or the system model of the BMS <NUM> with user tools <NUM> (e.g., a supervisory web portal) through a common API <NUM> and/or other suitable components. The user tools <NUM> may be based on microservice applications, but this is not required. The user tools <NUM> may include user interface components, web applications, supervisor web applications, etc. In some cases, the user tools <NUM> may provide and/or allow FM/operator/occupant features including, but not limited to, one or more of hierarchy/system navigation, a trend viewer, alarm management, dashboard/graphics, schedule management, analytics applications, energy management, etc. In some cases, the user tools <NUM> may provide and/or allow Administrative features including, but not limited to, one or more of user/role management, organization/customer onboarding, licensing, subscription management, etc. In some cases, the user tools <NUM> may provide and/or allow system life cycle features including, but not limited to, one or more of install features, time and/or operational estimate features, engineering features, commissioning features, check out features.

<FIG> depicts a schematic flow diagram of an illustrative method <NUM> of setting up a building management system (e.g., the BMS <NUM> and/or other suitable BMS) for controlling a plurality of devices installed at one or more buildings of an organization that may utilize the building management system. The method <NUM> may include retrieving <NUM> a system model (e.g., a common model). In some cases, the system model may be retrieved from a central database (e.g., the central database <NUM>) and may define one or more predefined templates. The one or more predefined templates may define a general naming structure for one or more of data points, control parameters, schedule configurations, alarm configurations and/or for one or more other suitable component of the building management system for corresponding or associated devices and/or equipment. The general naming structure may enforce standardized device and equipment names and standardized point names that may be hardware agnostic.

The predefined templates of the system model may be used <NUM> to create a plurality of devices and/or equipment located at the one or more buildings within the system model in a hardware and/or protocol agnostic manner. In some cases, the predefined templates may be accessed, selected, and/or configured using a mobile device and/or other suitable device that is operatively coupled to the system model over one or more networks.

Once created, the system model may be linked <NUM> to one or more gateways (e.g., the gateways <NUM> and/or other suitable gateways). Once linked, the system model may be configured to receive hardware agnostic point information and/or other suitable information from the gateway and/or provide hardware agnostic control commands for controlling the plurality of devices and/or equipment added to or represented in the system model of the building management system to the gateway.

The gateways may be communicatively coupled to the one or more devices and/or equipment installed at the one or more buildings. The gateways may be setup or otherwise configured to receive point information and/or other suitable information from the one or more devices and/or equipment installed at the one or more buildings and convert the received point information and/or other suitable information into hardware agnostic point information and/or other suitable information before sending the information to the system model. Additionally or alternatively, the gateway may be setup or otherwise configured to receive hardware agnostic control commands from the system model (e.g., as initiated via a supervisor application) and convert the received hardware agnostic control commands into hardware specific control commands (e.g., hardware type- and/or protocol-specific control commands) before sending the hardware specific control commands to the appropriate devices and/or equipment installed at the one or more buildings.

The gateways may be located at one or more buildings of an organization utilizing the building management system. The gateway, however, may be located at one or more other suitable locations including, but not limited to, in the cloud.

Claim 1:
A Building Management System, BMS, (<NUM>) for controlling a plurality of devices installed at a building, the BMS (<NUM>) comprising:
a system model that is configured to be used in controlling the plurality of devices installed in the building, the system model is further configured to be developed and implemented in stages using templates with selectable elements to adhere to a single ontology of the plurality of devices installed at the building during different phases of use of the BMS (<NUM>) including two or more of installation, engineering, commissioning, operation, and maintenance, wherein different tools utilizing the templates are used by technicians to develop and implement the system model during each of the two or more different phases, where the system model is configured to be directly accessed and updated by the different tools (<NUM>), the system model is structured to enforce standardized device names and standardized point names that are hardware agnostic for the plurality of devices installed at the building, the system model is configured to define the single ontology of the plurality of devices installed at the building so that the different tools (<NUM>) used by the technicians when developing and implementing the system model receive complete information without requiring manual re-entry by the technicians of already provided information, the system model is further configured to receive hardware agnostic point information from a gateway (<NUM>) and provide hardware agnostic control commands to the gateway (<NUM>) for controlling the plurality of devices installed at the building;
the gateway (<NUM>) communicatively coupled to the system model and one or more of the devices installed at the building, the gateway (<NUM>) configured to:
receive point information from the one or more of the plurality of devices installed at the building and convert the received point information into hardware agnostic point information before sending the hardware agnostic point information to the system model; and
receive hardware agnostic control commands from the system model and convert the received hardware agnostic control commands into hardware specific control commands before sending the hardware specific control commands to the appropriate devices installed at the building.