-
Notifications
You must be signed in to change notification settings - Fork 0
Building Management Systems
BMS systems are generally designed in a reflexive manner; they take data from sensors and parameters, and process this in real time to set the behaviour of controllers. Heating, Ventilation and Air Conditioning (HVAC) is probably the most well known type of BMS application, but there are also security and energy management BMS capabilities.
A BMS does not generally have any built-in analytics capability, as its focus is on managing the building in real-time; predictive action is usually controlled by parameters and timers, either fixed in the system when the building was constructed, or set from control panels by estates staff. A BMS is often an embedded system of dedicated controllers rather than software-defined.
BMS's are often part of a stack of estates systems, including Building Information Management Systems (BIMS) and Facilities Management Systems (FMS).
There are many different systems in use; there is no single survey I could locate for identifying BMS market share. The UCISA CIS survey does ask about Estates IT in general; for 2017 the results where:
- Planon 32
- Archibus 13
- None 13
- QuEMIS 11
- Bespoke/in-house 6
- Not known 5
- CAFM 4
- FSI Concept 4
- Other 4
- Micad 4
- IBM Maximo 3
- QFM Estates Manager 3
- Planet FM 2
- Honeywell BMS 2
- TOPdesk 2
- Various 2
- Tribal - K2 1
- Badger 1
- UNIT4 Field Force 1
- Tabs FM 1
- SysAid - Estates Helpdesk 1
- Q5 1
- Trend 1
- SAP 1
- FAMIS 1
- Manhattan 1
- ServiceNow 1
- Pirana 1
- Quantarc 1
- SiteHelpdesk 1
However this is a mix of BIMS, BMS and FMS products.
BMS systems have been around in some form for a long time. There are numerous low-level standards for the communications architecture of a BMS, e.g. ISO 16484-5:2017 specifies the Building automation and control systems (BACS, usually abbreviated BACNet to distinguish it from the banking system) protocol used by many sensors and actuators linked to a BMS.
BACNet defines how controllers, sensors and management consoles exchange messages, and a set of common "objects":
- Access Credential
- Access Door
- Access Point
- Access Rights
- Access User
- Access Zone
- Accumulator
- Alert Enrollment
- Analog Input
- Analog Output
- Analog Value
- Averaging
- Binary Input
- Binary Lighting Output
- Binary Output
- Binary Value
- BitString Value
- Calendar
- Channel
- CharacterString Value
- Command
- Credential Data Input
- Date Pattern Value
- Date Value
- DateTime Pattern Value
- DateTime Value
- Device
- Elevator Group
- Escalator
- Event Enrollment
- Event Log
- File
- Global Group
- Group
- Integer Value
- Large Analog Value
- Life Safety Point
- Life Safety Zone
- Lift
- Lighting Output
- Load Control
- Loop
- Multi-state Input
- Multi-state Output
- Multi-state Value
- Network Port
- Network Security
- Notification Class
- Notification Forwarder
- Octetstring Value
- Positive Integer Value
- Program
- Pulse Converter
- Schedule
- Structured View
- Time Pattern Value
- Time Value
- Timer
- Trend Log
- Trend Log Multiple
Each object can have various properties, and send and receive messages ("services" in BACNet terminology) to read and set those properties.
An "Analog Input Object" is the BACNet object typically used for communication with sensors.
More information here: http://www.bacnet.org/Bibliography/ES-7-96/ES-7-96.htm
Currently the level of semantic information is very low. However, there is an initiative to harmonise semantic tagging of BACNet "objects" with Project Haystack. This would then make it easier to gather data from devices as you would be able to query them by type of sensor, for example.
Modbus RTU is another common standard; but this is very low-level.
Proprietary interfaces include Trend BEMS Protocol and LonWorks LON Protocol; many other manufacturers have their own proprietary interfaces.
Wattsense is an example of an API layer over the top of BMS controllers and sensors:
This abstracts over ModBus and BACNet devices with a REST API. It provides methods to get the properties of a sensor with a given ID for a specified time range. This makes it easier to build dashboards and applications that make use of BMS sensors and controllers.
SkySpark is an example of building analytics that uses BACNet interfaces to gather data. Visual BACNet is another example.
For BMS sensors using BACNet for the intelligent campus, some bridging will be required. This can be facilitated down at the device level by using semantic tags in the BACNet devices themselves (see https://newdeal.blog/bacnet-a-foundation-for-building-analytics-16ee91d9aaa3), but at least some level of middleware will be needed to gather properties from devices and convert those properties into intelligent campus sensor measurement events.
The WattSense "Box" looks like one potential solution for this. Also, Project Haystack looks like an interesting open-source approach. Otherwise, events will need to be mediated by higher-level systems in the estates "stack" such as the BIMS or FMS.