Many people believe that only new buildings can be smart buildings, but Jess Costanzo, Specification Sales Manager at Simmtronic, disagrees. She thinks it’s just about getting the infrastructure in place to do it.
The industry-wide push to make commercial buildings into smart buildings has been accelerated this year by two factors. The first is the indication that part home/part office working looks like it will be the norm for many workers. That leads to the need for building managers to look at office space requirements, hotdesking and flexible space usage, to optimise building use and costs. The second is the need to reduce energy consumption.
Lighting control systems have an important part to play in both cases. They typically use presence detectors to reduce energy use; their presence information is also increasingly shared with other systems, such as an HVAC system which then uses the same information to reduce its energy usage. For a smart building, the same presence information is also key to monitoring and optimising building use. It allows building users to be directed to free space that suits their current needs, for example meeting rooms or an available desk. It can also provide ‘heat maps’ that allow building use to be visualised in real-time or in an animated replay.
Lighting control systems have a key part to play in smart optimisation of energy use. Since they control the lighting, they can potentially report on lighting energy use in real-time. This data allows energy ‘hot spots’ to be identified and then adjustments to control regimes or light levels can be devised. This is unlike an electricity metre which only tells you what energy you have used, not how to improve the usage.
You may think that these smart building functions require the latest IoT technology to be installed. Certainly, IoT devices are one option for deploying smart buildings, but the lighting control system that has been in a building for up to 10-15 years may also be able to serve the same needs, without a costly refit and without all of the IT security issues that go with deploying large numbers of networked smart IoT devices.
As above, much of the information you need to drive a smart building is quite possibly already in the lighting control system and the question is then how easy it is to export it into other building systems. Export of information via the industry standard BACnet protocol has been commonplace in many lighting systems for 10 years, most often to interface to the HVAC system. BACnet is popular because of its simple structure, which means that nearly all systems will successfully interoperate. But the information that it conveys is primitive, without the richness that typical smart building applications wish to exploit.
The ‘new kid on the block’ that can provide the required data richness is the MQTT protocol. MQTT also has two further benefits: it delivers its data in web-like structures that software engineers can most efficiently manipulate, and it can publish events immediately when anything happens. This is in contrast to most other protocols where the recipient needs to keep ‘polling’ – repeatedly asking if anything has changed. In an MQTT deployment, other building systems ‘subscribe’ to these publications, which means that they receive notifications via MQTT of all information in which they are interested, as soon as it is published. Again, your existing lighting control system may likely contain all the information you would like to extract via MQTT and it is well worth finding out whether an MQTT interface is available for it.
For any smart building deployment, a key issue to consider early on is ‘asset tagging’. If multiple systems are to share rich data about assets in the building, they must agree on a name or tag for each asset. Each control system will typically have its own ‘address’ for each asset it controls, but this address will mean nothing to other systems. For a brand-new building that is being constructed as a smart building, the assignment of asset tags to assets should be part of the initial BIM process and should be propagated from the BIM system to all the other systems before they are commissioned. In the case of a lighting control system, which may be controlling 50,000 lights, it is important that the propagation is automated – nobody wants to retype 50,000 asset tags, nor could they do so without errors.
If smart building technology is to be fitted to an existing building, another way must be found to create and propagate these asset tags. Some lighting control systems can assign asset tags automatically in regular patterns for an existing building; once again it is well worth finding out whether the system you have can do this. MQTT then provides an important link in the chain – the rich data published by the lighting control system can include the floor name, coordinates, device description and asset tag for each device. This means that any systems that subscribe to this information can then use it to build up an equivalent database description of the lighting assets.
If your existing lighting control system can provide the smart building information you want via MQTT, the last thing to check is how close to real-time the publication of events will be. This is particularly important for the large systems that are typical of smart building deployments.
Lighting control technologies vary dramatically in whether they can deliver real-time data across a large installation. At one extreme there are systems in which the state of control is ‘fully distributed’, which means that no single device knows the status of each light or sensor. Extracting real-time data via MQTT may be impossible. A number, but not all, of wireless control protocols fall into this category.
Then there are systems designed around Lighting Control Modules, which know the status of the lights they control and the sensors that feed them. The question for these systems is whether the network infrastructure that links them has the capacity to deliver this information in real-time to an MQTT ‘pairing point’ where it can be exported for use as smart building data. Systems vary significantly – some have a ‘push’ architecture in which events are delivered to a pairing point as soon as they occur, while others provide access to the data only for ‘Head End’ use, so that a building manager can look at the status of one individual device at a time: in this case, real-time bulk data export is unlikely.
So, when considering an MQTT interface for smart building deployment, check both the richness of the data available and the real-time performance. Preferably ask for a demonstration in a live building and see if the data gushes out or trickles.
