Reply to Thread

Just a few more things to point out:
VTS Testing site

"It is not practical to do comprehensive testing of BACnet functionality in any product, so the BTL testing coverage policy is a compromise that reflects our desire to test the most commonly used parts of a productÕs BACnet software while keeping the testing fees reasonable." Why?

"Many consulting engineers are aware of the potential benefits of using an open network protocol in building control systems, but some have been skeptical that BACnet would deliver real interoperability between different manufacturers' products. The development of the testing standard for BACnet and the launch of the BTL product testing program are improving the interoperability between products, therefore reducing the risk of specifying BACnet." Reality

Testing for compliance to a standard will not uncover all possible interoperability problems that could occur between devices on a job site, but it is likely to reveal many potential interoperability problems. We believe that a combination of compliance testing and direct interoperability testing between manufacturers is more likely to result in a high level of interoperability on job sites. ... LON people don't have to worry about the network part, just the application. http://www.lonmark.org

"The launching of the BTL product-listing program is likely to have a significant impact on the building controls industry. Controls specifiers will likely give preference to BTL-listed products. Only four companies have BTL-listed products so far, but now that those listings have been published, we expect that many other companies will submit applications for BACnet product testing in the near future. This is somewhat similar to Lonmark, although there are much more manufacturers making Lonmark compatible devices than BTL listed.

Floating - Interesting observations.

I'm not overly fond of plugins - but it gets the job done.

I'll never be a GC fan. That box represents where the existing vendor retains control. The reason for it is to keep together complete subsystems. (for reasons both good and bad. Even Steve Tom agrees with me there -which really should be another post.)

Full Ethernet in every controller I think is not only really expensive, but also problematic. Maybe somebody could shed light on IPV6, but 4 is not good for a device level network.

I see more development coming similar to Loytec. They have that chipset that goes either LON or BACnet. From there you will be hearing the term OPC more often.

I really think that a bit of a downfall of BACnet is that other mechanisms easily supplant it at higher bandwidths and LON does really well against implementation at the device level. That's why you see the LON guys going with Tridium or dropping ilon100's all over standalone or with Quark, Dotvision, Axeda, etc... They have their device level down tight with an OSI 7 layer model and then they move on.

I see it this way--- either BACnet comes out with open network configuration toolset standards or they face problems.

I know BACnet has a ways to go still but I think that tools such as VTS, BACnet4linux, and SCADA Engine's RDK help to advance it.

I also agree that there needs to be a common setup tool with plug-ins. I don't expect that it would be open source and would gladly pay for it (Even the plug-ins if they are reasonably priced).

Why can't the GC's be a software only that run on a PC? The peer-to-peer step would be a big one also. I really hope that we are headed to full Ethernet in every controller.

And to think that 15 years ago this kind of conversation was just a dream.

Digital- Perhaps you would agree that if a full Ethernet stack wasn't so expensive to implement at the device level that we wouldn't be talking about BACnet and LON as much.

A quote: "For a very low cost, the LonTalk protocol provides an implemented, debugged, maintained, and proven protocol. It implements functionality of the full 7 layer OSI protocol standard. Most of the competing standards only implement a portion of the OSI stack. Commonly, layers 1,2, 3 and 7 are implemented in most standards. While this might be ok for a small static application, it is rarely sufficient for dynamic networks. By leaving out those middle layers, you leave out important services necessary for the growth of a network. Services such as duplicate packet detection, packet routing, sender authentication etc are now left as an exercise for the reader."

Hence the need for GC's. (?)

I understand device manager. With LNS the manufacturer's own configuration plugins are utilized. The owner can have the complete toolset for devices.

Many of the functions of the GC I get directly in the controllers themselves or can purchase stand alone schedulers, etc.... I personally find this a hardware block to device freedom on the network holding the old vendor in. Also, this architecture does not lend itself to adding the occasional card access controller anywhere in the network at a later time, etc.... Buildings are not static.

The owner of the building knows if he has that LNS database and infrastructure that (he) is free to do interact with his network with multiple vendors. These vendors can also interact and manage the devices from the other vendors. No recreation time and re-discovery is necessary. In many instances, contacting "Company A" for support is not necessary.

I also find the LON powerline communication slick. Especially that random wave 'transformer hopping router' that they apparently have developed to get around electrical transformers.

I understand the apparent problems people have with paying out some licensing. (microsoft/linux) At the AHR show I think you will see more manufacturers not using the Neuron.... See Loytec

Anyway, I don't know if BACnet can reach the overall vendor freedom of LNS. (I am speaking from the customer perspective)

Originally posted by sysint
[B]

Could you explain how the extra layers are a benefit and how are you using them?

I use the layers just like most others... I don't overly care except for the application. I just like some of the convenience... .

Good enough, I agree the extra overhead would be a nice feature. However is it really needed? Bacnet communicates over all the newest technology as well as Lon. The reason Bacnet doesn’t use 7 layers is because its not needed for its intent. I will tell you though I am impressed by the fact Lon can communicate over transmission lines. This impression will lead me to answering your next questions.

From Polarsoft
BACnet makes extensive use of existing international and national standards for data link and physical layers. In each case where a unique-to-BACnet component appears, it is justified because of the lack of any suitable standard for that component.

Well, an answer for you.
Perhaps BACnet needs (can use) Lontalk for this. Or, maybe each vendor has their own way to implement the data link and physical layers. Maybe you could explain this.
Maybe you could explain why there is no common network toolset available for BACnet? Since you can analyze packet data why isn't there a common open source (free) network tool available? Or, how about one I'm willing to pay for?
Also, explain why BACnet vendors use these GC's all over the place? Why do you need them?

Wow, that’s a lot of question’s Sysint. I’ll do my best to answer them in the order you asked.
1. This is basically a reply to your quote from Polarsoft. In accordance with Bacnet standards a Bacnet device communicates over Ethernet, MS/TP, PTP, Arcnet, and Lon. Here is the link http://www.echelon.com/solutions/bui...BacNetComp.pdf Interesting enough this is found in the Lon white papers. I encourage you to read about it on page 8. In the quote from Polarsoft it was mentioned as a unique component. I believe the component that is being talked about is the communication protocol. For example My CSI system’s, which are a proprietary system, are communicating to my Bacnet front end. In this situation CSI doesn’t support Bacnet so the use of gateways is required. This is an example of a unique component or at least the way I understood it.
2. About the common network Toolset Bacnet front ends have what is called device manager. This is the only toolset I need to communicate with a device for all practical purposes. Once I plug a bacnet device on the network and do a device scan on the front end I can see and communicate with that device. Bacnet uses AI,AV,AO,BI,BV,and BO as part of these standards. Using these points I can command valves, change set points, set schedules, alarms, and so forth.
3. GC’s all over the place. Global controllers are used for a lot of reason’s first off GC’s are used to manage the network not to be confused with the workstation (BOWS). Most Bacnet devices will be unitary controller’s that communicate on the MS/TP LAN (IE, vav controllers, ahu controllers, rtu’s,). Well the MS/TP LAN can realistically hold 64 devices. Each Global controller will let me have 4 MS/TP LAN’s from that one device that’s a total of 256 devices. Most unitary controllers don’t have an Ethernet jack on them only an MS/TP and PTP. A global controller routes that MS/TP message to an Ethernet cable that will put it on the Wan so to speak. Global controllers also manage alarms, schedules, trend data, priority writes, as well as route messages from one controller to the other.

Before you do, keep in mind I've been here posting awhile and most know my backround. Maybe you should consider sharing your backround so everyone knows where you are coming from. And, to be fair, I'd request that from Lonboy as well if he treaded down the path you are going.

Well, your post count does command some sort of respect in my eyes. As well we have on several occasions talked about the pros and cons of each system using an open-minded dialogue. I will share my background with you in PM at my leisure since I enjoy my anonymity on the Internet.

Could you explain how the extra layers are a benefit and how are you using them?

I use the layers just like most others... I don't overly care except for the application. I just like some of the convenience...

From Polarsoft
BACnet makes extensive use of existing international and national standards for data link and physical layers. In each case where a unique-to-BACnet componet appears, it is justified because of the lack of any suitable standard for that component.

Well, an answer for you.

Perhaps BACnet needs (can use) Lontalk for this. Or, maybe each vendor has their own way to implement the data link and physical layers. Maybe you could explain this.

Maybe you could explain why there is no common network toolset available for BACnet? Since you can analyze packet data why isn't there a common open source (free) network tool available? Or, how about one I'm willing to pay for?

Also, explain why BACnet vendors use these GC's all over the place? Why do you need them?

Before you do, keep in mind I've been here posting awhile and most know my backround. Maybe you should consider sharing your backround so everyone knows where you are coming from. And, to be fair, I'd request that from Lonboy as well if he treaded down the path you are going.

Originally posted by sysint
I haven't went over all documentation but I didn't see whereby this could do packet analyzation.

Yeah, It is a packet analyzer. i think this one was specifically built for manufacturers and not end users.Here is the
Newest VST for bacnet[/B] A couple times a year Bacnet manufactures get together and have whats called a "plugfest" . Basically alot of manufacters get together and integrate their new products and test for interoperability.However there are a few enduser,system integrator's,and manufacters products out there that will do the same and even more. Polarsoft is one of the company's that offer these networking Tools Also Sysint, Bacnet I believe is only a four layer OSI. Could you explain how the extra layers are a benefit and how are you using them? Here is a brief
Explaination of Bacnet OSI layers [/B]
Also why we are on the subject something has been bothering me. The National Institute of Standards and Technologies (NIST) has picked Bacnet as thier standard protocol for building communications. I know the army corps picked Lon is this a case of one hand not knowing what the other is doing ? Here we have two major Fed agencies not supporting one another!

No disrespect taken.

Good question. I am unaware of anyone making an open source analyzer. Not to say you couldn't do it.

I haven't went over all documentation but I didn't see whereby this could do packet analyzation.

I will look it over more completely.

I understand that Lon is a more robust protocol and devices don't need to be tested for functionality.

I think you missed my point that this is an open source test tool and kind of a protocol analyzer and can be used for much more than just testing devices for functionality.

Correct me if I am wrong here but I don't think there is any open source tools that can be used to checkout a Lon network.

BTW there is no disrespect intended I just thought that this is a useful program with a very nice price.

LON is a full 7 layer OSI protocol.

You don't need to "determine functionality" even across different mediums such as Ethernet, fiber, RF, etc...

If you want to look at standards go to http://www.lonmark.org and you will see functional profiles of devices with the minimum named points and functions.

IE - nvoSpaceTemp, etc.. would be consistent in SCC profiles

You put a device on a Lonworks network and it just works. It's data will be available for use. It does not have to be determined or tested it can communicate.

sourceforge.net/projects/vts/

Check it out!!, Hey Sysint, where's the Lon version?