Coleman’s Core

Day 3

January 24, 2010 – 7:51 am

Today is the third day of BACnet meetings in Orlando, FL. Today is the first of two days devoted for the main SSPC 135 meeting.

The morning of these meetings is usually a little “slow”, and I say that with all due respect. However, getting everyone on the same page with the network setup, then introductions, review of the agenda and minutes from the last meeting, waiting for folks to get coffee, etc. takes up quite a bit of time. Then we dive into various updates from liaisons to other SPCs with ASHRAE as well various “sister” organizations such as IEIEJ. After that, we hear from the various working groups (essentially “focused” subcommittees) about their work. These activities usually take up the 8 AM to 11 AM time slot.

Today, there were a few interesting developments in the working group portion of the meeting.

1. The SSPC formed a new WG, the Elevator Working Group (officially dubbed “EL-WG”). The goal of this group will be to find ways to implement BACnet in the elevator world. It turns out that in the elevator world, they use several proprietary protocols that are structurally similar to BACnet. Our friend “BACnet Bill” Swan will be heading this working group. Congratulations, Bill!
2. This is the first ASHRAE meeting for the IT and SG working groups. The goal of the IT-WG is to find and address areas where BACnet can be integrated with the Information Technology field. The goal of the SG-WG is to find a way to integrate the Smart Grid initiative with BACnet (or vice versa).
3. OK, this one is a cheap plug. Roland Laird from Reliable Controls has decided to step down as convener of the IP-WG. It was officially announced today that at the end of these meetings, yours truly will be the new convener of this group. The goal of this working group is to oversee the use of BACnet over IP networks (BACnet/IP). Roland has been the convener of this group for as long as I’ve been involved with BACnet. There have been several improvements to the BACnet/IP data link layer under Roland’s watch, and I can only hope to fill his shoes.

We spent the time leading up to lunch discussing a clarification concerning the modification_date property of the File object. The question was what the value should contain in the event that the device cannot determine the time from its local_time property. The only way that this can happen is if the device doesn’t “know” how to calculate the current time. Some embedded devices do not contain a real-time clock and are unable to determine the actual local time without the clock being “set”. They may be able to sync their time via some external source such as NTP or the BACnet time synchronization services and keep time (accurately or inaccurately) rom that point, though. However, at boot time, the OS does not know what the actual time is. Consider the case where the battery on a PC motherboard dies. At that point, the BIOS clock is unable to save the time across reboots. So, the PC is unable to determine what time it is from the hardware clock. In this case, when my program gets the current date and time from the OS, it will report its epoch time. Of course, I can set the time to whatever I want.

This is analogous to when an alarm clock is first plugged in. It resets it’s time to 12:00, but after a minute goes by, it’s 12:01. It’s wrong, but the clock still tracks time.

The point of all this is that a device has some default time, and in operating systems this is referred to as the epoch time. Really, this is the point in time when the clock is all zeroes. In BACnet, this date is 00:00:00 on Monday, 1-January-1900.

The question is what should the value should the modification_date property contain when the internal “clock” is in this state. If, for example, you device creates a file at startup then that file object’s modification date must contain the date and time that the file was created. So, my assertion is that in this scenario the property value should either be 00:00:00 1-January-1900 or the epoch date and time reported by the OS.

After lunch and well into the afternoon, we spent our time discussing various addenda. But, that’s a story for another time.

Coffee helps me clear the fog. If you've found any of the posts on this blog helpful, I could always use more coffee.