http://www.fieldserver.com/products/appnotes/009_bacnetprotocols.asp

http://www.fieldserver.com/docs/pdf/AN009.pdf

Here’s the real story.

BACnet/IP is the correct term, NOT BACnet IP.

BACnet/IP has nothing to do with TCP/IP and does not make use of TCP/IP in any way. BACnet/IP uses UDP/IP for its transport. When using BACnet/IP although it is overwhelmingly most common to use an Ethernet MAC layer it is not required. There are many examples such as 802.11, VPN technology and other types of WAN that are not Ethernet but work just fine with BACnet/IP. The whole point of BACnet/IP is to isolate BACnet from such dependency.

Other “correct” terms:

• BACnet over 8802-3 Ethernet or more simply BACnet 8802-3
• BACnet over ARCNET or ARC156K
• BACnet over MS/TP

The slashes and capitalization are important

MS/TP means “Master-Slave / Token Passing”<

There is no good vs. bad issue regarding BACnet/IP and BACnet 8802-3. These are just different approaches for different circumstances and in many cases one is just as good as the other. BACnet 8802-3 makes use of a "raw Ethernet" MAC layer using the 8802-3 form of Ethernet packet rather than the older but widely used "DIX or Ethernet II" form. The 8802-3 form used with BACnet includes an ISO8802-2 UI frame that adds 3 octets of overhead. This is where the magic number 1497 octets comes from: 1500 octet Ethernet payload minus 3 octets of 8802-2 UI frame header. The remainder of the message is a BACnet NPDU. When IP (as in TCP/IP and UDP/IP) transports are used on Ethernet it is possible to also use 8802-3/8802-2 to transport them. However, this is rarely done and most systems instead use the older DIX frame with 0x0800 frame type (IP). The payload is an IP header and its payload. In the case of BACnet/IP the IP header is followed by a UDP header, then a BACnet BVLL header THEN the very same NPDU that would appear in a BACnet 8802-3 frame. So BACnet/IP is considerably larger overhead than BACnet 8802-3, although this doesn't really have a speed impact. The IP header (20 octets) and UDP header (8 octets) and BVLL header (4 octets) take away 32 octets from the 1500 available leaving actually 1468 octets. BACnet/IP allows the NPDU to be as large as 1497 though which will cause fragmentation and actually generate two packets although this is invisible to the sending software.

If the whole Ethernet network is one logical segment connected by Ethernet hubs and/or switches, then BACnet 8802-3 is preferable because it is lower overhead and can make full use of the maximum packet sizes without fragmenting.

If you are also using IP based devices on the same infrastructure AND they share the same IP subnet, or ALL of the BACnet/IP devices share the same IP subnet, then BACnet/IP is nearly as good but slightly slower.

If there are any IP routers in place that divide the infrastructure into two or more IP subnets AND ANY of the BACnet devices are separated from the other BACnet devices by an IP router AND the IP router doesn't have Ethernet bridging capability, then BACnet/IP is preferable because of the need to bridge BACnet 8802-3 segments together which is not necessary with BACnet/IP, However, when there are multiple IP subnets AND there are BACnet/IP devices on more than one of those subnets, there is a need for broadcast management across the subnets.

This can be solved one of two ways:

1. Have a BBMD on each BACnet/IP subnet
or
2. Have at least one BBMD (on one of the subnets) that supports Foreign Device Registration AND use BACnet/IP devices on the other subnets that can register as Foreign Devices. This can be tricky because:

• Not all subnets necessarily have BBMDs
• Not all BBMDs support Foreign Device registration, and may be limited in number if they do
• Not all BACnet/IP devices support registering as Foreign Devices

Bottom line:
BACnet 8802-3 is simpler and more efficient for “non-IP router” infrastructures

BACnet/IP is better when there are any IP routers in the infrastructure

but, using BACnet/IP with multiple subnets has more complex configuration and BBMD requirements.

Since all I wanted to do was to access the image from Google images’ reference, I had no user name or password. Clicking Cancel or X box closing, simply redisplayed the popup. In fact I was unable to close the browser, except finally by using task manager to croak the whole IE process. This is very unfriendly and earns the <LAME> stamp for this week.

We started answering a line of questioning about the MS/TP properties in the Device object, such as Max_Info_Frames, and how these should NOT appear in the Device object in their case because the device was not homed on MS/TP. However, since their device was a router also this caused some issues when they were preparing a BTL Checklist based on this table:

Since (according to the table) neither choice for C1 and C2 applies to this device, it therefore can’t claim that it is an MS/TP master. This is silly because of course any of its MS/TP ports are MS/TP masters, but they don’t have an explicit device object.

This is one of the many reasons why BTL tests are too rigid.

Their device is both a router, and a controller. Because it has an application entity (AE) with a device object, BACnet requires that the AE have a “home” meaning a unique network and MAC where the device object lives.

They’ve chosen to home the AE on the Ethernet port, and that’s fine.

Because they have 3 MSTP ports, each one could potentially have different settings for Max_Master and Max_Info_Frames so unless there is a device object for each one of those networks there is no way to make those parameters unique for each port AND readable/writable through BACnet unless they make proprietary properties in their Ethernet-homed device object.

So there are four ways to go:

1. Claim the device is a router, then fight with BTL about the fact that you are a valid master node on each of the three MSTP networks but without a BACnet-visible property for Max_Master and Max_Info_Frames.
2. Make proprietary properties for Max_Master and Max_Info_Frames in your device object for each of the three MSTP ports (six proprietary properties), Then argue with BTL that this means you are a configurable C2 and writable C1.
3. Change your device to be homed on one of the MSTP ports, add the  Max_Master and Max_Info_Frames properties to the device object and force each port to use the same settings (yuck).
4. Make unique device objects for each port (four device objects) with four device instance numbers and put configurable MSTP properties in each device object. This is nasty for you though because you would have to support device object behavior on all four ports.

My choice would be (2). I would argue to BTL that the standard is weak in anticipating this kind of application, and in fact that there are several proposals before the SSPC to deal with multi-port MSTP devices.

I have no wish to fuel any old enmities, but perhaps my perspective can help to unite our thinking in the same direction. The goal in this case is to find methods that allow building owners to invest in automation and controls systems that can serve them for long periods of time and realize return on their investments. At the same time, these purchases should also support the reduction of costs in other related areas such as training, maintenance, energy use, system integration and interoperability, unified operations, etc. 

These are not new ideas. In my own case I have worked for 25 years to help get different people’s views to come together on these points, and happily through many people’s efforts this has been a huge success in many applications all over the world. After a long period of discussion and debate, and then a long period of development under an open consensus process supervised by ASHRAE, a standard method for building automation system interoperability was created, and you all are familiar with this standard called BACnet which was initially released in 1995.By 2001, BACnet had also become an INTERNATIONAL standard through ISO.Today, millions of BACnet-based systems and devices are installed and available in every country. 

In 2000 Mssr. Mansour expressed his legitimate concerns about the future of the standard, and we should not fault him today for those views. Fortunately, each of his concerns has had a favorable outcome for BACnet, and it may be beneficial to list those concerns again here: 

“nobody can resist but joining the club of future ….It is a nice dream , yet still a dream.”

Today interoperability between BACnet-based devices is no dream, but a daily reality for millions of BACnet devices and systems. No other method exists that is an international standard, and also so widely adopted worldwide for BAS as BACnet. 

“…let us … try to identify interoperability ? we have two basic questions :1) do we want Honeywell Controllers to speak to Johnson Controllers , Siemens Controllers , Sauter Controllers , Invensys Controllers in the same installation ?” 

Most definitely YES. This is routine and easy in most instances to do with BACnet.It is rarely true that a system designer intentionally mixes parts and pieces of different vendor’s components in the same subsystem. Of course this usually would be unnecessary. But the issue is that in order to have the flexibility to evolve, change, and switch to alternative vendors or sources of supply, it is important to NOT be locked-in to proprietary technology that makes this impossible or very costly. Since BAS systems must be designed for longer term operation, many facilities will have the need to change, and interoperability technology makes this possible. 

” or 2) do we want Honeywell Controllers to speak to Schindler Elevators ,   XXX Generators , YYY Boilers , ZZZ Chillers ,..etc.” 

Most definitely YES. Again this is regular and routine for BACnet. Since 2000, many new companies have joined in supporting BACnet and new companies announce BACnet products nearly every month.  

Again, the intent is not always to require integration across system types (elevators talking to HVAC for example) but it is nice to be able to do this when it IS desirable. Obvious high energy using systems such as HVAC and Lighting have many opportunities for energy savings when they can perform interoperable activities easily. This lowers operating costs aswell as system design costs. 

“for the first question what will be the benefit to end user to have a mix  of products for which he has to stock larger amounts of spares and to  pay more for the cost of maintenance and training”

I think this is the wrong question. If the owner is forced to have multiple vendors because of procurement issues, bad service, failed contracts with vendors or any of the many reasons possible, what kind of strategy can insulate the owner from these costly investment failures? What kind of technology can provide flexibility for procurement, integration, AND the opportunity for energy saving strategies? What kind of technology can actually ease the training and maintenance costs of supporting multiple vendors?

The answer is that BACnet can provide all of these benefits and more, right now.The use of true international consensus standardization assures a large degree of the investment is secured against obsolescence, and accidental or intentional vendor failure. Using common standardized technology such as BACnet means that much of the training and maintenance is also standard across vendors, resulting in net savings, and providing leverage not only to training investments, but also access to a wider base of trained people.

“…for the second question …what is the case for non HVAC equipment manufacturers ? are they going to adapt BACnet and why not any other well established industrial standard protocols like MODBUS .”

The answer is YES, and we see many other kinds of equipment vendors adopting BACnet in response to the growing number of systems and owners who want BACnet interoperability from related equipment. Lighting, Access Control, Fire/LifeSafety, sensors, VFD, electrical/motor, lifts control, etc.

There are some companies, historically, that have used MODBUS because their markets overlap with industrial controls where MODBUS is more common. These systems (industrial, boiler control, etc.) tend to be smaller with highly centralized control. This is quite different from modern decentralized DDC systems. So the centralized master/slave approach of MODBUS is at a significant disadvantage in typical BAS applications. The other problem with MODBUS is that its concept for data access is “memory file” oriented which places the burden of understanding and structuring information on the controller that is asking for data. In a centralized system, where the big brain is in one location, that is less of an issue. For decentralized BAS systems that is a design and maintenance disaster.  

“BACnet capabilities could be a plus , but how many of the large control companies  in the world today have native BACnet controllers?”

All of them.

Regarding Sabry’s comments about Sauter controllers, I don’t know that it is constructive to make judgments about what a vendor’s real agenda might be, based on their apparent design choices. I think it’s more helpful to owners if we can illuminate best practices for interoperability and point to practices that may not be in their best interest. 

As you know, BACnet does not impose any particular hierarchy onto BAS systems so that a designer can make a BACnet system that is “flat” or structured into many tiers in a hierarchy of small controllers, larger supervisory controllers, workstations and so forth.  Regrettably some vendors have chosen to draw the line at some point in their hierarchy and say that below the line they will continue to use their own proprietary methods of communications, and above the line they will support BACnet.

I think Sabry’s point is that it is in the best interest of the owner that this line is pushed to the lowest practical point in the hierarchy. This gives the owner the most flexibility to add new components or to replace individual elements or subsystems should the need arise in the future. It also gives the maximum amount of access to information and control influence at lower levels of the system.

Yes, of course, this is not ALWAYS REQUIRED. But it is a desirable quality and for the most part this is free when BACnet is used. If an owner allows proprietary portions of the system, they must realize that these portions potentially will always be “owned” by that vendor who may not be so kind in the future.  As a result, it is an advantage to the owner to have, or to specify, this “native BACnet” capability at all principal levels of the automation system hierarchy at least down to the smallest controllers. Mssr. Mansour is correct, this kind of requirement “eliminates” some vendors. So would “requirements” for proper insurance, quality control, fuses, insulation and other “optional features.” 

Having said all this, one must not be unduly harsh in analyzing the technology approach to bringing BACnet to specific products. Much has been said about BACnet “gateways” and this is a complex topic with many important fine points that owners or specifiers do not care to know. The important issues are network architecture. If a vendor makes a controller that is BACnet on one side, and “internally” it is something proprietary, that’s OK. as long as the box you buy from this vendor has a BACnet connection, as far as you are concerned it’s a BACnet box. However, when that box has other connections to external devices, that is when you must ask the question: why aren’t those connections ALSO using BACnet? If the connections are for simple sensors, then well OK that’s not so important. But if those connections go to smaller “sub-controllers” then in effect you aren’t buying just this box, you are really buying the whole collection of the box and all of the sub-controllers as well.

This approach is generally not good for owners, because it is the “line” and below the line everything is not standardized.

Some vendors have both BACnet controllers AND proprietary controllers in their product line. An owner has to be careful when asking for BACnet that they are getting BACnet EVERYWHERE that they want it. For example sometimes a vendor will provide all proprietary controllers with a single BACnet “gateway” controller in the system. So other BACnet devices must talk through the gateway in order to interact with any of the proprietary devices. This may make it very hard or impossible to replace one or more proprietary controllers in the future with equivalent BACnet devices from other vendors.

From “m.mansour” <mansoor@gega.net>
Subject: BACnet Forum
Date: Tue, 5 Dec 2000 02:42:05 +0200
To: BACnet-Arabia Forum
Dear Sirs,
It was very intersting to recieve arguments and comments and exchange ideas,problems,solutions and point of views among several participants at this wide scale.To say the least , nobody can resist but joining the club of future , with all these futuristic ideas of open systems and standard protocoles , It is like dreaming of one language on the planet earth , or even one common currency , or one big country on the earth shared and used by everybody on it.It is a nice dream , yet still a dream. But before inventing a problem and try to find a sloution , let us start from the basics and try to identify interoperability ? we have two basic questions :
1) do we want Honeywell Controllers to speak to Johnson Controllers , Siemens Controllers , Sauter Controllers , Invensys Controllers in the same installation ? or
2) do we want Honeywell Controllers to speak to Schindler Elevators , XXX Generators , YYY Boilers , ZZZ Chillers ,..etc.

For the first question what will be the benifit to end user to have a mix of products for which he has to stock larger amounts of spares and to pay more for the cost of maintenance and training . nevertheless in buildings with different sources of controls accumulated over many years of operation problem is solved either by using one system with a mixture of field devices or interfaces between two systems at a higher level without the need to have a “native” single protocole for controllers .
For the second question if HVAC equipment manufacturers have some sort of communication with each other and ASHRAE to encourge interoperability ,what is the case for non HVAC equipment manufacturers ? are they going to adapt BACnet and why not any other well established industrial standard protocoles like MODBUS. BACnet could be the future , we appriciate efforts done in the direction of improving HVAC industry but it should not be used today commercially to eleminate some vendors specially when the word “native BACnet” is used in tender specifications ? BACnet capabilities could be a plus , but how many of the large control companies in the world today have native BACnet controllers?
Regards
Mohamed Mansour

The numbers aren’t magic, but they aren’t intuitive either.

The 1497 number (for 8802-3 Ethernet) comes from a max 8802-3 payload of 1500 minus 3 octets for the 8802-2 UI frame header.

The MAXAPDU size of 1476 comes from the maximum sized NPDU header subtracted from this value:

version            1
control             1
dnet                 2
dlen                  1
dadr                 6 worst case for 8802-3
snet                 2
slen                  1
sadr                 6 worst case for 8802-3
hopcount         1
total                 21
1497-21 = 1476

So really the MAXAPDU is the MAC layer payload size - 21. For ARCNET that’s 501-21 = 480, same for MSTP and PTP.

The NPDU is a MAC layer payload containing a BACnet network layer header and APDU. An APDU contains an application layer header plus parameters.

This is a picture of the NPDU fields, not all of which are present at the same time.

However, I think the most serious issue for CRT users is “flickering” which in the past was caused by a refresh rate of 60Hz (or in Europe/ME 50Hz) for refreshing the screen. Slight differences in the circuitry for the CRT can cause a minute delay that introduces a phase difference between the refreshing of the screen and ambient lighting powered by the same AC source. When fluorescent lighting is used, this phase difference produces “zero beating” much like two musical instruments being tuned together.

When their frequencies are close but not the same a secondary pulsing harmonic can be heard. For the CRT this appears as a slight flickering (darkening and lightening alternately) which is especially noticeable on light (e.g. white) background areas. This modulation causes involuntary eye twitching as the eyes attempt to follow the “motion” which can lead to eye strain and headaches.

Today, nearly all CRT monitors and video adapters are capable of much higher refresh rates (e.g. 85Hz) which most importantly are not close to 50/60Hz. These don’t exhibit flicker even when used with fluorescent lighting. So the “headache” claims about CRTs are very much a thing of the past. Regrettably many people don’t take the time to make this simple adjustment to their monitor/adapter settings and so they see flicker anyway.

I was recently asked to comment on this white paper on LCD vs. CRT. It is clearly written by someone wanting to promote LCDs. Many of its points are valid, but I would differ in several points:

1. Visual Performance: CRT is slower than LCD
This is completely false. Until very recently, typical LCD screens had a 25ms response time. That’s 40Hz or 40 refreshes per second. The CRT I am writing this on is 120Hz, or 3 times faster by my arithmetic.

We are just now seeing some LCDs with active pulse technology that claim 3ms response time, but sadly these are not available in 1600×1200 resolution yet. For now this is an overstated claim.

2. CRT is prone to flicker
Not if the adapter and monitor use 70Hz or better refresh. At 85Hz I think you would need instruments even to detect it.

3. Image brightness is uneven in CRTs
That’s not been my experience. LCDs rely on fluorescent backlighting for brightness and there is often uneveness in their images especially in larger displays.

4. Image Sharpness: lower in CRT
That depends entirely on the pitch in the CRT mask. Typical LCDs use a much coarser pitch than top grade CRTs. Unless you are buying really low end CRTs it is typical to have 0.22mm or smaller pitch in a nice CRT. That’s much finer than the most expensive LCDs. Properly converged CRTs with fine pitch are at least as crisp as LCDs with equivalent resolution.

5. Specular screen glare: possible in CRTs
True, but again better monitors use a glare filter. This is far less of an issue than off-axis distortion and loss of brightness that is common for LCDs but not at all an issue for CRTs. This is especially bad on the vertical axis in LCDs.

The main reason I haven’t switched to using dual 1600×1200 LCDs is that in the configuration I use (two bent at an angle) there are important color changes in LCDs that don’t occur in CRTs.

So, don’t get me wrong. LCDs are great and have many advantages including size/weight/heat and so forth. But for quality of color rendering and fineness of image, they are not yet on a par with CRT technology. In 17” 1280×1024 sizes though there are many good choices.

Instructions:

1. Bring the coconut cream to a boil in a large saucepan.
2. Add the chicken, potatoes, onion, peanuts and salt, and simmer for 20 minutes.
3. Remove a ladleful of coconut cream from the pan, and pour it into a frying pan. Add the masaman curry paste. Stir until the mixture thickens.
4. Pour the curry over the chicken. Add the fish sauce, tamarind juice and sugar and stir well. Simmer for a further 15 minutes.
5. Serve with plain rice or bread. Cucumber sauce is also a popular accompaniment.

Instructions:

1. Coarsely chop the chilies and soak in water for 10 minutes. Drain.
2. Dry-fry the cumin and coriander seeds, cardamom pods and cloves over medium heat for 1-2 minutes until they are aromatic and slightly browned.
3. Saute the chilies, garlic and shallots in the oil until lightly browned.
4. Pound the spices in the following order:
   • garlic, shallots and chilies
   • coriander, cardamom pods, cumin, cloves and peppercorns
   • lemon grass, galangal, bergamot, coriander roots
5. Place the shrimp paste on a piece of foil and cook it over a flame or burner for 1-2 minutes, or in a hot oven (220 degrees) until the outside is slightly burnt. Mix the shrimp paste with all the above ingredients plus the sugar, salt and tamarind juice to form a fine paste.

Instructions:

1. Peel and grate three potatoes.
2. Peel and chop ½ onion. Mix with the potatoes.
3. Melt together in a pan, 15 ml. margarine, with 7.5 ml cooking oil, at 350 degrees.
4. Spread the potatoes and onions evenly in the bottom of the skillet. Sprinkle with salt and pepper if you wish.
5. Reduce the heat in the pan to 300 degrees, and cook for 7-8 minutes.
6. Carefully turn the potato cake over, and add 15 ml. more margarine then cook until golden or satisfying for your taste.
7. Serve immediately.

Instructions:

1. Mix together the garlic, chilies, fish sauce, salt and black pepper, then marinate the beef in this mixture for 5 minutes.
2. Fry the basil leaves in the oil until they become transparent. Drain and put to one side.
3. Remove most of the oil, leaving about 45 ml in the pan. Turn up the heat, add the meat and stir –fry for 2-3 minutes.
4. When the meat is almost cooked, stir in half the fried basil leaves. Remove from heat immediately and sprinkle the meat with the remaining basil leaves. Serve with plain rice.