BACnet/IoT brings BACnet™ to the world of IoT

BACnet™ is a standard communication protocol for Building Automation and Control Networks developed by the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE).

Take advantage of BACnet™ in your IoT projects

INTRODUCTION

It is common misunderstanding that BACnet only has to do with Building Automation. BACnet is a fully blown device-to-device communication standard that defines Physical-, DataLink-, Network- and Application- layers of the ISO model. Most importantly it defines the Application layer, how devices communicate with each other on a network and the outer world. This is very important as it gives devices from different vendors capability to communicate intelligently with each other right from installation.

Very good BACnet introduction videos exist on Youtube. Feel free to watch all 8 videos, starting from here... (2 3 4 5 6 7 8)

BACnet/IoT is our implementation of the BACnet standard. We decided to implement it almost from scratch using C++ and high level POCO C++ library. That way we get the fastest, smallest footprint code without loosing development speed. Most of BACnet/IoT will be open source for our customers in 2017. By that we will build up a community contributing to the software.  

BACnet/IoT takes specially into account IoT needs. For example we decided from the beginning that we would implement the BACnet/WS (Web Services) part of the standard, even before that part of the standard was fully defined. This is because of the need to connect IoT devices to the Internet, securely on a standard manner without loosing functionality. BACnet/WS is very comprehensive making it possible to perform whatever operation needed over the Internet. This is not true for other more simple standards like MQTT. Standards like MQTT can therefor easily be implemented as a subset of BACnet/WS. Actually we are doing so when this is written, by implementing a MQTT-to-BACnet/WS software module.

 

BACnet/IoT takes specially into account IoT needs. For example we decided from the beginning that we would implement the BACnet/WS (Web Services) part of the standard, even before that part of the standard was fully defined. This is because of the need to connect IoT devices to the Internet, securely on a standard manner without loosing functionality. BACnet/WS is very comprehensive making it possible to perform whatever operation needed over the Internet. This is not true for other more simple standards like MQTT. Standards like MQTT can therefor easily be implemented as a subset of BACnet/WS. Actually we are doing so when this is written, by implementing a MQTT-to-BACnet/WS software module.

BACNET/IOT SERVER

BACnet/IoT Server is a one of it's kind server, as its configuration is dynamic (configuration of objects, properties, gateways, etc.). It can be fully configured from DINGO MANAGER or other utility that uses the Restful Web Services for configuration. The server is also completely independent of origination of properties like "Present_Value". Those can come from Modbus devices, the GPIOs of DINGO, 1-Wire, I2C connected chip, PINGO device, etc. or even from a web service or database. Only a single handle into DINGO Peripheral Manager specifies the source of BACnet property value.

Currently BACnet/IoT supports those BACnet object types:

  • Analog Input
  • Analog Output
  • Binary Input
  • Binary Output
  • Device
  • Program (in beta)
  • Pulse Converter
  • Schedule (in beta)
  • Trend Log
  • Trend Log Multiple (in beta)
  • ...more coming soon

And those are the services supported:

  • Alarm & Event Services:
    • Change of Value (COV) reporting 
    • Subscribe COV
  • File Access Services:
    • Atomic Write File (in alpha)
  • Object Access Services:
    • Create Object (in beta)
    • Delete Object (in beta)
    • Read Property
    • Read Property Multiple
    • Read Range
    • Write Property
    • Write Property Multiple
  • Remote Device Management Services:
    • Reinitialize Device (in beta)
    • Time Synchronization
    • UTC Time Synchronization
    • I have
    • I am

The BACnet server has access to BACnet/IoT client such that it can easily perform service request to other BACnet devices. This is important for example doing trend-logging from another device.

DINGO BACnet/IoT PICS can can be accessed here...

BACNET/IOT CLIENT

Our customers can of course select BACnet client products from any vendor. There is a large flora of such products in the market, ranging from simple free test-clients to advanced SCADA systems and server products.
Simple test clients are many free of charge, and fun to play with. Such clients exist even for mobiles, for example bacmove

BACnet/IoT supplies a BACnet Client library to be used with C++. This library is first and foremost intended for those who want to access BACnet servers directly with small foot-print APPs written in C++ or those that want to contribute to our open source BACnet Server/Client.

BACnet/IoT comes with many demo APPs that explain how to use this library.

BACNET/IOT WEB SERVICES

BACnet/IoT implements the cutting edge BACnet/WS part of the standard. This is very important for extending BACnet to the world of IoT.

The BACnet/WS module is a free standing software module. It is only needed to be installed on one device (or computer) in the network of devices to be accessed from the LAN or WAN (the Internet). This module does not only enable BACnet/WS access to our DINGO and WINGO products, but also any other BACnet device on the network, from whatever vendor it is.

Key features are:

  • CRUD operations via simple POST-, GET-, PUT- and DELETE-requests.
  • Supports Change Of Value (COV) subscriptions by web socket push notifications.
  • Supports XML and JSON for structured data.
  • Supports plain text for primitive data.
  • Runs under HTTP and HTTPS.
  • Contains authorization - OAuth 2.0 (available soon).

BACnet/WS is very easy to use. You are welcome to test it on our live demo BACnet network here...

BACNET/IOT VIRTUAL GATEWAY

A DINGO BACKBONE can manage very many sensors and actuators on many peripherals and buses. If all are configured in one flat structure as BACnet objects, maintenance and browsing becomes difficult.
Therefore we have introduced the BACnet/IoT Virtual Gateway, where BACnet objects can be grouped behind Virtual Gateways (VGs). A VG show up as a BACnet-router with a unique network address.

A simple example is if managing hundreds of 1-Wire temperature sensors in a big building, those can be grouped behind 10 VGs, one fore each storey.
In the same installation there might be 10 energy meters on Modbus. Those could be grouped behind the same VGs.

A special variant of the VG is the BACnet APDU-to-APDU gateway (A2AG). A2AGs are used to virtualize BACnet servers behind slow master/slave media like PINGO. Accessing those directly via BACnet requests, would be slow and cause timeouts in the requesting BACnet client.
To solve this problem an A2AG, has its values ready by intelligent polling, when requested by BACnet client. Similar happens when writing to such a BACnet server. The A2AG returns immediately when a BACnet client writes to an BACnet object behind slow media, but afterwards the A2AG starts writing the value over the slow media as a background task. If that fails the value is rolled back in the A2AG BACnet object and it's Reliability property set to a fault value.

More about DINGO BACKBONE here...

BACNET/IOT OVER 6LOWPAN

Our upcoming family of WINGO sensors and actuators will be able running a native BACnet Server. This is a very small footprint variant of BACnet/IoT server that is enabled to communicate on a 6LoWPAN network.

Fortunately the BACnet committee has recently published Addendum for supporting IPv6.
Read about it here...

6LoWPAN has many limitation. It is low bandwidth network (250/40/20 kbps). The payload in each packet is limited only 103 bytes. BACnet was originally designed for low bandwidth communication over RS485 networks. Therefore today it is the device communication standard that sends the most compact packets back and forth, utilizing the small payload space for 6LoWPAN best possible. Compared to competing alternatives that most use XML or JSON strings, BACnet only needs a fraction in terms of bandwidth.
BACnet is therefore the ideal choice for 6LoWPAN.

More about WINGO here...