Thursday, December 17, 2009

Basic BACnet: packet delivery

I've had quite a difficult time getting back to the blog, what with a big internal project, Smart Grid work, and other after-hours activities chiseling away at my time this week. In part too it's because I underestimated the work ahead, so I will break some of the "Basic BACnet" sections into smaller pieces.

We'll start with the BACnet protocol stack, which is fairly complex inside but at a non-technical level can be described fairly simply.

BACnet Stack
A BACnet device can be defined as having two elements. The uppermost is the "application", which is the functionality of the device whether it's a simple thermometer (represented by the gray part in the figure), a complex controller, a workstation, or whatever else. The lower portion is the protocol stack, whose function is to take information issued by an application in one device and deliver it to an application in some other device.

An analogy can be made with the a process of a medieval lord (let's call him Sir Aldfrid) sending an important message to another lord (Sir Bertwald), elsewhere in the realm.

Sir Aldfrid calls for his scribe, dictates a letter to be sent to Sir Bertwald. The scribe converts it to Latin, the language understood by all scribes everywhere, and writes it down on paper.

The scribe the hands the letter to a secretary who makes a copy of the letter (just in case), puts it in an envelope, makes a note about when and where the letter was sent, and hands the envelope to the cartographer.

The cartographer then decides from his maps which direction (or roads) should be used, selects a courier to carry the message, and hands him the envelope and a map. (Couriers are not very bright.)

When the courier arrives at the destination castle, he hands the envelope to the cartographer there, who hands it to the secretary.

The secretary gives a note to the cartographer to give to the courier to carry back to the original castle so they know the letter is delivered and the copy can be destroyed. (If the return note is not received within a specified number of days, a copy of the original letter will be re-sent.) The secretary opens the envelope and hands the letter to the scribe, who will read it to Sir Bertwald, translating from Latin to the local language.

In American postal parlance, this letter was sent "registered, return receipt requested," and each actor in this scenario represents a layer of the BACnet protocol stack. The lord represents the communicating application, the scribe converts the message to or from BACnet, the secretary tries to make sure the message is delivered or informs the sender of a message that it has been received, the cartographer directs the message across the proper routes, and the courier carries the actual packet over the roads (networks).

And that's it!

Well, almost. There are variations of this situation, to wit:

1. Sir Bertwald is to return a letter with the courier. In this case Sir Bertwald's secretary doesn't make a copy of the return letter, he just places it in the envelope and hands it to the cartographer.

2. Sir Aldfrid doesn't need a reply. In this case Sir Aldfrid's secretary doesn't make a copy, he just places the letter in the envelope and hands it to the cartographer.

3. The letter is to be sent to all lords (broadcast), with no reply expected. This is very similar to #2 except the message is carried or copied to everyone.

The example presented here consists of one single network. If there are multiple networks (i.e. the courier has to pass through several realms, going on horseback, by boat, or on foot depending upon the realm) the picture is quite a bit more complicated but the process is pretty much invisible except to BACnet implementers or when some realm (BACnet router) isn't following the rules.

1 comment:

  1. That's a great explanation. I wish I read it when I was learning about BACnet!