S4 has grown and evolved over time by listening carefully to our partners and learning from the experiences of others by participating in a number of on-line forums and the BACnet organizations. This is a perfect example, and I thought it was important to share it with our readers. David Fisher of PolarSoft responded to a number of questions posted on the BACnet-L list. We are republishing his comments with permission.
For many years S4 struggled with the stigma of being a gateway product. David’s message helps to explain why that situation existed. We overcame the negative stigma by educating our partners that the S4 Open Appliances are much more than simple protocol converters (gateways in their basic form). Yes, the S4 products are gateways. But we add a lot of value beyond the basics. And, we are up front with our partners in encouraging them to position the S4 products as enabling technology to transition buildings to “Native BACnet” technology or to act as a long term on site agent for providing access to the data locked inside proprietary systems, enabling the use of current generation BACnet value added applications for analytics, energy audits, retro-commissioning, continuous commissioning, and other activities that add value without ripping and replacing the legacy systems.
Here is the original request that David responded to.
Von: bounce-121578436-44297615@list.cornell.edu [mailto:bounce-121578436-44297615@list.cornell.edu] Im Auftrag von Sabry An-Naggar
Gesendet: Sonntag, 4. Juni 2017 13:00
An: BACnet-L Cornell Univ New York
Cc: David Fisher; Ahmad Sabry An-Naggar; Jim Herdeman; Mahmoud Sabry; omarrmahmood@gmail.com
Betreff: Native BACnet Protocol and the Four Layers
Dear Ladies and Gentlemen:
I'm looking for the following two descriptions:-
1-The specs and description for the four layers of a BMS/BAS system.
2- Description for the "native BACnet protocol"
Thank you very much indeed
Sincerely
Sabry An-Naggar
Project Manager & BMS Expert
There are other responses on the BACnet-L list and I invite you to go there and view the entire conversation if you have interest. BACnet-L is a valuable asset for the BACnet community http://www.bacnet.org/Contact/BACnet-L.htm. We edited David’s response to focus only on the original questions posed by Sabry An-Naggar. Here is what David had to say.
As the person who coined this term, I can assure you that the term definitely has meaning. I’ll be happy to relate the history of this, since you’ve asked.
In the beginning there were obviously only a small number of early adopters of BACnet.
A big obstacle was that established companies, who were heavily invested in what today we would call “proprietary” means of communications, were very resistant to the idea of providing products that used
BACnet directly. Instead their first attempts at support for BACnet involved the use of “gateways” that translated their proprietary communications into BACnet ideas and methods. These tended to be expensive devices that provided sometimes little actual BACnet functionality, and hid many product features behind the gateway.
However, in promoting these new products, these same vendors touted their “BACnet support”.
Even in the best circumstances, for example when the BACnet feature set of a gateway was similar to what a “non-gateway” BACnet device could provide, the gateway was a bottleneck, single point of failure, etc. So it became useful and important to be able to distinguish between a “real” BACnet device and a BACnet gateway. Why make the distinction if the BACnet side functionality was “similar”? The reason then, and still, is that these ideas are not equivalent. Buyers who accept gateway devices are still permanently locked-in to the proprietary devices behind the gateway, and will not gain the benefits of purchasing expansion and competitive bidding, let alone performance, that devices using BACnet directly can provide. Many consultants and owners were initially frustrated by these intentional “marketing slogans” claiming that “they had BACnet.”
I coined the term “native BACnet device” as a way of describing a device that implements BACnet as its primary, if not exclusive, means of communications - no gateway required.
Further the distinction did not apply to a single device attempting to proxy on behalf of many other physical devices, but was atomic to the native BACnet device itself. A system consisting only of such native BACnet devices was called a native BACnet system.
Frank (one of the other contributors to the full discussion) is right that this definition was never added to the BACnet standard itself, but was in common use within the SPC/SSPC for many years. However flawed the term might be, it is definitively better than saying nothing at all.
I'm looking for the … Description for the "native BACnet protocol”
A device that implements BACnet as its primary, if not exclusive, means of communications - no gateway required.
It is one of many characteristics that one should know about, or specify for, a BACnet device that one wishes to buy or sell. Any single one of those characteristics by itself is “misleading”.
For example, if I have a device containing 100 points, but only one of those points can provide alarm detection and reporting, then I say that the device “provides BACnet alarming”, well that’s true but misleading. Obviously one needs to consider all of the device characteristics not just one or two in isolation. The characteristic is just a fact.
1-The specs and description for the four layers of a BMS/BAS system.
Sabry in this question you have unintentionally asked something ambiguous.
Which “layers” are we talking about? Referring you back to the BACnet standard isn’t a very helpful answer, because it presumes that you are asking about layers of the BACnet protocol. Maybe you are asking about conceptual layers in the typical hierarchy of a BAS system e.g. management, system, controller, fieldbus. BUT, I think instead you are looking for a better description of the concept and purpose behind BACnet’s Collapsed Architecture, as shown in Figure 4-2 in the BACnet standard.
Physical Layer
In the OSI model, the physical means of signaling and wiring, as well as the means for conveying “octets” from one place to another, is called the physical layer. A physical layer standard, such as EIA-485, defines first of all how signals (0 and 1) are conveyed. There are obviously many ways to represent
0 and 1: on-off voltage, voltage level A and voltage level B, presence/absence of a carrier tone, light pulses on and off, etc. Even given the physics of a particular medium, e.g. copper wire for carrying the signal, there are other characteristics like wire gauge, maximum length, voltages, connectors etc.
Data Link Layer
Regardless of how the physical signals work, there is a need to organize these 0s and 1s into octets, and to organize sequences of octets into messages. There are many schemes for doing this. The Data Link Layer specifies one of many possible schemes for organization of messages, and for arbitrating how devices share the use of the signaling medium, much the way that traffic lights control the use of roadway intersections by multiple cars.
As a side note, the physical and data link schemes are often grouped together under a sort-of larger category called medium access control, or MAC Layer. So although the OSI model splits these apart, BACnet actually leans more toward the MAC layer idea even though it’s presented in OSI style in BACnet clause 4. This is an important idea because many of BACnet’s MAC layers are not really unique data link+physical combinations, but instead make use of whole other protocols such as LonTalk, UDP/IP and Zigbee, as “virtual” MAC layers. BACnet/IP, for example, packages BACnet NPUs into the payload of a UDP/IP+ BACnet virtual link layer (BVLL). This UDP/IP portion is itself a 7 layer OSI protocol with its own data link and physical characteristics. I think it’s most convenient to think of BACnet’s MAC layers as a means of sending a bag of X octets from one place to another.
Network Layer
The problem with sending a bag of octets to some destination, is that the destination may not be directly connected to the same wires or medium that the sender is connected to. Like human postal mail, the delivery usually involves the transfer of messages from one carrier (e.g. the postman) to another (e.g. the mail truck) to another (the post office in the destination city) until the final destination is reached. The BACnet network layer provides this functionality.
Application Layer
The mail system doesn’t care what is in your message. It could be a letter to your brother, photos for your family, a job application etc. But when you open the letter of course those differences matter. In BACnet there are a large number of different kinds of “letters” that we can send to provide different functions: e.g. reading a property of an object, sending an alarm message, reading a trend log, changing a setpoint etc. This is what BACnet’s application layer provides: standard types of messages (services). Of course some devices do more than others (have more services).
The actual device
Your device might be a VAV box controller, or a lighting controller, or a sensor. It has some mission to accomplish, e.g. control the VAV box. It uses BACnet as a way of providing services to other devices, and interacting with other devices. Commonly we call this “the application” meaning the program(s) that make use of BACnet to convey messages relevant to the program. That’s also in a sense a “layer” but for the most part it is not defined in BACnet. I say for the most part because keep in mind that some BACnet services and object types have implied behaviors that are defined in BACnet.
PolarSoft has been one of the core supporters of and driving forces behind the BACnet standard since its inception. See their company page for the details http://www.polarsoft.biz/company.html. If you would like more information about PolarSoft you can contact David Fisher at PolarSoft.
David Fisher
PolarSoft® Inc.
914 South Aiken Ave
Pittsburgh PA 15232-2212
dfisher@polarsoft.biz
www.polarsoft.biz
412-683-2018
412-683-5228 fax