Bacnet white paper


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Bacnet white paper

  1. 1. Remote monitor/control of devices over BACnet through handheld devices. Overview of the protocol: This section will cover the basic concept of BACnet over IP network, uses of the protocol, range of devices that the protocol can be used to monitor/control. BACnet is basically a communications protocol, used primarily for building automation and control networks. This protocol can be used in systems designed to remotely control/monitor systems for applications such as heating, ventilating, and air-conditioning control, lighting control, access control, and fire detection systems and their associated equipment. These appliances may be any of industrial (large boilers, engines, air and water flow valves, furnaces etc.), public infrastructural (hospitals, railways stations, airports, stadiums etc.), or even user appliances (ACs, heaters, fridges etc.). The BACnet protocol specifies 50 different objects. BACnet works with IPv4 (and also IPv6, protocol evolving). This makes it deployable with common operating systems like Windows and Linux. With Linux, portable embedded devices can be deployed integrated on board or as enhancement. In the above diagram, the appliances 2 to 6 are being monitored/controlled by appliance 1 which may be a small application running over a PC.
  2. 2. Aim: The aim of this presentation is to bring BACnet together with other internet and telecom technologies. This is the technical side. For users’ perspective, the aim is to make BACnet protocol more near to human and make remote monitoring/control of devices possible with existing infrastructure and devices like cellphones and internet. This will mean no/minimal investment to hardware. Technical overview and architecture: This is a scenario where a user can remotely control/monitor a wide range of appliances through sms/ussd or smart phone applications.
  3. 3. Scenario 1 – Through SMS/USSD: The user will have to register through service provider using USSD, the way we register or query for several services like - *123#, type BACnet and send it to 5566. If user wants to know the status of device ID 4ad3 at a network with network ID 0eBAC98, the SMS to be sent may look like: STAT 4ad3 0eBAC98 And the response may look like: Device 4ad3 at 0eBAC98 is active since 02/02/2012. 340 C, 2000 rpm. The number 5546 should correspond to our BACnet service, which already should be registered with our service provider. This means, we may need to register our service with every service provider so that end user can access the service from any network. Disadvantages: The server will have to register with many service providers to enable users of all service providers this service. Also, when the user travels to a different geographical region or country, there is no guarantee of availability of service. Scenario 2 – Through smart application: The user will require a valid user ID/password. Once logged in, the application can query for devices using XML/SOAP/REST messages. The appliance may have a local database of devices mapped with device ID. An application may look like:
  4. 4. When data is required for user appliances, it may look like this: A query by this appliance to the server may look like: POST /InStock HTTP/1.1 Host: Content-Type: application/soap+xml; charset=utf-8 Content-Length: 157 <?xml version="1.0"?> <soap:Envelope xmlns:soap=""> <soap:Body> <soap:NetworkID>0eBAC98 </soap:networkID> <soap:DeviceID>4ad3</soap:DeviceID> </soap:Body> </soap:Envelope> This scenario is much robust when service availability with changing service provider or geography is concerned. Disadvantages/Issues with this scenario: 1) This will require different application for different handheld OS. 2) May require persistent connections.
  5. 5. Parallel Ideas: