AutomatedBuildings.com Article -

[an error occurred while processing this directive] [Place this link in body of article]

Don't forget to change the page title (Page Properties) and the Date at the top.

Making a device BACnet depends on how big or small the device is. What is its service use case? What resources (people, software, hardware – in prototype and production) are available to make your device BACnet? What is the potential market/volume for the device?

Cimetrics traditionally has started this conversation by offering a BACnet protocol stack and tools (BACstac). This typically is a good option for large organizations making thousands to millions of devices in a market demanding BACnet. With an engineering department behind one, one can decide on an approach and architecture and implement an entire system, including devices, with BACnet inside. But this is often a many person, many year, and many thousands of dollars project. But this is ultimately the most flexible way to get BACnet in a device.

Many requests are from smaller manufacturers and they shy away from the resource investment for such a large scale endeavor. They want to get started with BACnet with little investment/risk. Their “size” is small processors and maybe at most a hundred data points – usually more like ten - and a very simple I/O driven state machine for their process. There is a slate of options for them.

Often the customer is really asking for “modern” network infrastructure BACnet (that is BACnet over TCP/IP over Ethernet – sometimes even with 802.3af Power over Ethernet). For RS485 MSTP BACnet – which is often the needed interface for low level sensing interfaces, but not the most accessible and interoperable for all use cases – one can get some very good open source toolkits for some very good microprocessors and make BACnet MSTP devices with a handful of useful I/O and a functional state machine. There are fine offerings from many in this area… including a couple of nice open source options… like this BACnet kit.

Given MSTP one has options open to later go to an architecture with BACnet/IP. You can use a BACnet MSTP to BACnet/IP router (like a Cimetrics B6000). This is essentially configuration free except for TCP/IP addresses and BACnet network and performance parameters. There is no mapping in this architecture. The end device holds the object map and presents it via MSTP which is merely BACnet routed to TCP/IP.

An alternative to routing is to use a BACnet MSTP to BACnet/IP proxy. This is like a router but with even less configuration (more plug and play if you will) but with a restriction to one or two fixed/mapped devices. An MSTP to BACnet/IP router can be used to access a whole network of MSTP devices. A proxy makes specific devices available as a single BACnet/IP device (or a collection of BACnet IP virtual devices) on a BACnet/IP network

Both of the above pre-suppose BACnet MSTP, or a willingness to develop to MSTP. Some have the resources for this, but the very small or resource constrained do not. This kind of customer often moves to the next two questions….

Cimetrics offers the B6090 EasyBAC kit for BACnet/IP. EasyBAC allows one to write to a BACnet state machine API that will be driven by your embedded device’s processor to make BACnet data exchange possible. It is a specific Cimetrics communication protocol and API which must be learned, implemented in, and driven by the embedded device, usually in addition to protocols and services already available in that device.

This often leads back to a full BACnet protocol stack and Cimetrics consulting/engineering services, but it can also go a different direction if you already have your data presented in well defined protocol. It in fact can motivate a very solid intermediate position without high level protocols.

Modbus has a long history of use in industrial controls and has breadth of applicability form small controllers on serial networks, to very large TCP/IP systems.

Cimetrics offers the B6030 BACnet/IP to Modbus device. It has predefined internal templates which bring out Modbus registers and represent them as BACnet Objects.

It can handle an entire Modbus RS485 RTU network and can map up to four Modbus devices (each with a different template). It is almost zero engineering and requires almost no onsite configuration (apart from setting up the device IP address and setting the target Modbus device IDs). BUT it does require an internal template preset inside the conversion device. Cimetrics has an extensive set of templates pre-built for most standard/fixed Modbus building automation devices, and can engineer such templates from publically available Modbus register documentation for a fee.

The customer often says… We like the processor driven or Modbus templatized approaches, but would like permanent programming to incorporate device defaults or corporate logo. And can one build them in lots of hundreds turnkey – so that one just solders “BACnet chips” in?

Cimetrics can develop such specific OEM customizations after a template has been developed. With our relationships with Lantronix and Gridconnect we can offer turnkey solutions for batches. Lantronix and Gridconnect are among our favorites for small processors for TCP/IP and serial protocols

Some customers find even the above too costly. Or they are unwilling to use external engineering resources. They want simple, but they want in house engineering. They want easy and cheap and good. (There is an old engineering adage about that desire…). They have a point though. If they do relatively small volumes, and want to test the waters with BACnet, then even getting a template engineered might be deeper than they want to go.

There is another option for those going that small and DIY. It is essentially a small gateway offering. Here we have to get a bit more specific, and lay groundwork for a simple architecture. If one is that constrained then assumptions of smallness and simplicity must be borne clearly in mind.

We find that the smallness constraints lead to a device which communicates via Modbus RTU over RS485. There are other direct sensor buses like I2C and SPI and CAN which also have their place as automation protocols, but in building automation, the size and scope of the network model presented by Modbus and its network model matches needs well. Modbus is easy to implement. Some of the tiniest processors, like those from Microchip and Atmel, can easily deal with Modbus. Not that some tiny processors cannot also do BACnet MSTP, but the codebase and learning curve and accessibility of openly available tools allied with Modbus are hard to ignore. Further there is often an immediate direct to market pathway for a Modbus server itself.

Get sensors and I/O to an internal bus and then make a basecamp at Modbus RTU RS485. From Modbus RTU one can of course go with a Modbus templatized approach outlined above to get to BACnet MSTP or BACnet/IP and even SNMP, XML, REST and Modbus TCP in parallel. The variety therein makes a third party engineering arrangement viable (to get best practices/models from someone who has been there and done that).

One is still firm on DIY? Then you can get a variety of excellent gateways between Modbus RTU and Modbus TCP to BACnet/IP and others. There are some excellent offerings from many in this area. Some excellent methodologies based on standard spreadsheet inputs or Java code machines come to mind.

But we found that there was a mismatch in magnitude between those looking to just make a few I/O points from the simplest Modbus device with ten points into BACnet, and those who could cope with instructions for Excel spreadsheet driven machines and Java machines configured with XML. Such small entities were not prepared to learn the differences between BACnet data types or why BACnet units are as they are or how BACnet status works.

We envisioned an even simpler “gateway”. We envisioned setting a simplest basis in Modbus RTU device knowledge and thence to capture all possible manipulations to BACnet in a few canned (and constrained) ‘conversion operations’. The operations would be available in a finite list. Units would be selected from a list. Simple bounds/rules checking would be applied to names and descriptions. Complex algorithmic conversion would simply not be offered… as it implies a larger use case which requires a larger tool.

This vision is captured in the forth-coming Cimetrics B6130. New variants are in the roadmap which will take Modbus RTU and convert to BACnet MSTP.

Finally the user often rejoins that this is “almost” perfect except that they want to have their own branding (or elimination of Cimetrics branding) and they dislike the universal nature of setup (one must still say which Modbus IDs at which to point).

Cimetrics can sweep this aside and set defaults for Modbus parameters and change/add logos and branding. The customer then need only provide to the end user/customer/site the B6130 and a template file. The template file creation tool need not even arrive in end use hands. And template files can be factory pre-installed after being customer (DIY) engineered. The logo and Modbus default engineering is done once - bought and paid for. Then the only ongoing cost is the unit price from Cimetrics or distributors like Gridconnect or Lantronix or….

Our goal in this vision for facilitating small devices was to get data to flow more easily to a myriad of clients. It was to get bigger amounts of data (from many small devices) for the enterprise … well modeled big data. We believe in this pathway.

Sensors and I/O via right sized local buses like I2C to state machines in small processors that communicate via Modbus and are thence augmented with object attributes and models and made available to TCP/IP networks where they can manifest as REST and XML data sources useful to multiple consumers in the enterprise.

[an error occurred while processing this directive]
[Click Banner To Learn More]

Events	Want Ads
Our Sponsors	Resources