BACnet MSTP

A brief Description

Here is a brief explanation of how BACnet MSTP works. This will be somewhere between an “ELI5” and something approaching a Coles notes. FOr a technical description, I would suggest picking up the BACnet Specification, or at least checking  the BACnet Website.

A BACnet MSTP (BCMSTP from now on) consists of at minimum a Coordinator, a Master and a pair of wires connecting them.

A Coordinator, as the name implies, coordinates all activity on the MSTP trunk. It keeps track of all communication statistics, as well as correcting any disruptions in the communication. Typically the coordinator also manages any communication with external devices or a larger IT network. Coordinators are normally larger devices running bona fide operating system.  An example of a coordinator would be a Johnson Controls NAE , which runs Windows XP Embedded (no I am  being serious) or Tridium JACE, which run RIM’s QNX OS.

A Master is any device on the BNMSTP network that can talk and share information. In the context of Building Automation, a Master is a device that has sensor inputs and outputs for controlling equipment. The Master encodes real world conditions such as temperature, humidity, current draw, pressure and shares that information with other Masters on the trunk. The Master also has outputs for controlling mechanical or electrical equipment, such as fans, heaters or boilers. Masters can typically be loaded with software for controlling this equipment on its own through programming.  Masters are often smaller 16 or 32 bit microcontroller devices. Some examples of Masters would be the Johnson Controls FEC, or the Reliable Controls Mach Pro

The BACnet MSTP Trunk should look something like this, where Node and Master are interchangeable for our purposes. For the time being, ignore the Server, we’ll get to that later.d

 

The Communication Process

Unlike the chaotic and haphazard communication of its UDP cousin, MSTP communication is quite an orderly affair.  Communication happens in a predictable, almost deterministic way.

There are some ground rules for MSTP to keep in mind

1)Each master or node on the network has an address between 1 and 254. The Coordinator (also known as a Supervisor) has address 0.

2)Communication packets on the MSTP bus are defined as frames. There are 7 defined frame types which are described below.

Frame Types

Frame # Frame Type Description
0 Token Pass Pass the token to another master
1 Poll for Master Sends out Probes looking for a new master not yet identified
2 Reply to Poll for Master Responds to frame type 1.
3 Test Request Diagnostic Use
4 Test Response Diagnostic Use
5 Data Expecting Reply This frame contains data the requires a response from the destination. Used to request status information
6 Data Not Expecting Reply This frame contains data that does not require a response. Used to respond to requests in frame type 5.
7 Reply Postponed Used to respond to frame type 5 if the master is too busy

Each master on the network keeps a few specific pieces of information recorded.

MyAddress = the masters address.

NextMaster = the next masters address in the bus, defaults to 0 on startup.

MaxAddress = the highest address number allowed on this network. This is set in programming. Lets assume its 64 for this example.

Communication Flow

A simplified exchange would look something like this.

In the beginning all devices come on line. The network is unmapped, and none of the masters are aware of each other yet. The coordinator begins sending out polls for a master starting at address 1 until a master responds.

The coordinator continues sending out polls to incrementing addresses until a response is received. This tells the coordinator who the next master in the network is.

The token is passed to the next address. Since this master does not know who the next master is, it starts polling for the next master. This process continues from one master to the next as the network is mapped.

Eventually the token is passed to the last master on the network. This master will start polling for the next master up until the Max Master is reached. This signifies to the master that it is the last in line and it passes the token back to Address 0, the coordinator.  Now that the network is mapped, the masters can start sharing information about devices on the network

In order to request some piece of information, one master sends a Data Expecting Reply frame to another. Encoded in the packet is the specific instance number of the point the master wants to know about and what aspect of that point (ie present value, units, name etc). The host master sends back the response in a Data Not Expecting Reply frame. We’ll discuss the technical specifics of how data is encoded in a later post.

This is a pretty quick and dirty explanation of how BACnet MSTP works, but it should shed enough light to make the process a little more clear. I hope to expand on the technical details a bit more in the future.

Daedalus

Overview

Daedalus is a device I built in 2010 as my final project to complete my Bachelors degree at BCIT. It is a BACnet MSTP device that allowed me to communicate with an MSTP trunk and pull information from devices on that trunk very quickly.

During that time I was working as a controls technician, working on building automation systems. The tool set I had to troubleshoot and monitor devices on an MSTP trunk were well designed but significantly flawed. These tools would interrogate an MSTP host for every input/output point it had, as well as any software points programmed. On medium to larger hosts, this could take minutes to update and get new readings. This caused significant problems when I was just looking for a single point, or trying to tune a PID loop and needed fast results.

The goal of Daedalus would be to overcome this flaw and allow me to directly interrogate a single or small group of points much faster. Daedalus would physically attach to the RS485 communication lines of an MSTP trunk and communicate as if it were a host on that trunk. Daedalus had a Bluetooth link that would communicate to a user interface running on  a laptop.

Unfortunately I don’t have as much detailed information on this project as I would like, as it was nearly 10 years ago, but I’ll share what details I have.

Details – Daedalus

The software behind Daedalus is a preemptive multitasking real time kernel, which runs on an HCS12 microprocessor. The kernel, written in C/C++ was designed by David Quarbach, to whom all credit is due. On top of this kernel are several drivers to communicate both with the BACnet MSTP trunk, and to a Bluetooth transmitter. There is also a CLI for interfacing with the device directly over serial.

The limited BACnet stack Daedalus uses was written by me, and implements the minimum functions in order to maintain communication on an MSTP trunk, and poll other devices for status information of their inputs or outputs.

Daedalus Version 1

Daedalus went through several evolutionary phases, some rougher than others.

A short lived Version 2

This was one of the last iterations of the hardware design. The final version included a modular plug to plug into the MSTP trunk.

Version 3 – Final

As you can see, many of these components are modular packages from Sparkfun. However the HCS12 chip itself had to be landed on breakout board from Dangerous Prototypes, which is an excellent company to do business with. This was the first time I had to work with landing an SMT chip, and that was an experience. Not having any reflow tools, I had to do my work with a hot air station.

Dont worry, I cleaned up the solder job after the initial landing

 Details – User Interface

The user interface was written in C/C++ and provided basic control over Daedalus. The UI, which was based on ncurses, allowed the user to start/stop the information gathering process, specify the target to monitor, as well as collect diagnostic information on the MSTP trunk itself

I grew up watching Tron, and this is what I was told the future would look like

Results

Daedalus was a great success for me. Not only was I able to monitor devices on an MSTP trunk much faster than with my existing tool set, but it taught me a great deal about embedded RTOS systems, and the BACnet protocol itself. I was able to use Daedalus in my work for a while after the project was complete, and it was a great help.

So why the name? Well that’s my Wife’s fault. According to Greek mythology, Daedalus built the Labyrinth of Crete, which imprisoned the Minotaur. He has several other accomplishments to his name and is considered one of the first Engineers in Greek mythos. I’ve always had a romantic attraction to his stories, having wanted to be an engineer all my life. So when I needed a name for this project, my wife who has a deep love for all things mythology, made the suggestion. Since then, most of my projects carry a name of a greek or roman mythological figure.