Make a Modbus Device be BACnet.

Suppose a mature Modbus device which one wants to be BACnet. The device has a clear and static Modbus register map and uses standard Modbus throughout. One mostly wants the device to make its data available via BACnet and other web services to clients and participate in the Internet of Things wave.
The device is not completely static. Future revisions are expected and these want to easily integrate into new systems. The device is not solitary. It must function and thrive withing a system of its peers or devices from other vendors.

• Cimetrics B6130 Modbus to BACnet IP can be added to mature project and works great. Exactly where most start.
• Cimetrics B6131 module for a new unit works great. Exactly where most end up. Think of the B6130 as the development kit for B6131.

B613x has all the following concurrently and transparently at run time - probably have to see this to completely absorb the implications:

• BACnet/IP (we also have a BACnet MSTP RS485 version if you use a Lantronix/Gridconnect xPico).
• Modbus TCP.
• Web GUI.

Features of existing B613x base:

• Excellent long track record Cimetrics BACnet stack.
• Defaults designed to make installs and device additions or reconfigurations easy and painless for first time or advanced users, of 1-100 units,  as system, or within other systems.
• Quick time to market, with levels of effort tailored to OEM and end-user needs.
• JIT supply chain with Ethernet firmware load.

Wrote and blogged before about making a small device BACnet via Modbus.

And got some questions about how to test BACnet... There are a couple of generic templates in the B613x kit (even before the template creator) which would allow one to "peek" around a generic Modbus device.

For testing the BACnet side externally, usually Cimetrics' clients use BACnet Explorer or BACnet OPC server. Demo versions in each case can be found by going to the Documentation tab (roughly mid page) (usually 20-40 MB).

Lantronix and Internet of Things - IoT.

Related to recent blog entries on Internet of Things - IoT tools, Ethernet internal bus, and Serial Coprocessing. Mariano Goluboff at Lantronix has a great article on using xPico interface with various IoT tools. Lantronix + dweet + freeboard.

Lantronix has already shown commitment to IoT: Lantronix IoT

Lantronix blog has good stuff: http://www.lantronix.com/blog/

Recent of note in Lantronix blog:  SOEST , SLB  and Google Analytics

Ethernet as an Internal Bus for Internet of Things, IoT, Embedded Devices.

Ethernet and TCPIP are already regularly used as internal buses in large NAS systems. What about taking this model to embedded devices for IoT?

Backplane = Ethernet hub/switch - ala D-link GO-SW-5E (5VDC powered - roughly $15)  (or even a Mikrotik 750 router)

CPU with direct Ethernet = SoC ARM or x86 based compute and database engine - Intel based (Galileo, Minnowboard), Beagle Bone, 86duino, Raspberry Pi...

Bus controllers = Lantronix xPico classic.

The last part is the key piece. It can even in some cases be the CPU too. Platform specification for IoT often gets into nitty gritty I/O capabilities. This sometimes diverges into onboard or outboard coprocessors like TI Sitara's PRU, serially connected Atmel or PIC microcontrollers, special function chips like advanced application specific UARTs or communications units (think oddities like ARCNET, HomePNA, unusual RF, etc.)... and sometimes even to FPGAs. Usually these pathways take one to very specific/special specifications.

Ethernet is a natural actually - having:

• Isolation.
• Variable bandwidth.
• Wide "driver" support.
• TCPIP support - for web GUI and standard protocols/frameworks like XML, REST and layerable security and filtering.
• Various forms of pre-existing transparent, web configurable, "driver-less", pass-through devices.

Ethernet was formerly too expensive. Look at the price of xPico. And Ethernet suffers from being thought of as a LAN bus (distances of 1-100M). Instead think of it like CAN, I2C or SPI.
 
Bus power? One can go:

• Power over Ethernet 802.3af on the high end.
• Passive Power over Ethernet (with 3V-12V over short distances).
• 5V - USB being the current best flavor of 5VDC - Common EPS.

Alternatively, think of the xPico as a replacement for a PLX PCI9030 or a PLX PEX8112
or various forms of "bridge as IP cores" to be fabbed on demand. Without the fabbing, minimums, BGA assembly, and so forth.

Serial Bridges... Preparing for the Internet of Things (IoT).

Many embedded applications come down to I/O with "lesser" serial bus on one side (sensors via I2C or SPI or something straightforward like Modbus) via an intelligent agent which then interacts with a "greater" serial bus on the other side (like to a stateful serial protocol like BACnet MSTP, Profibus, ARCNET or even Modbus or USB). This is the essence of a serial bridge.

Most embedded developers pick a micro controller they are familiar with and go directly to work building their bridge.

What if one instead envisioned first how such a bridge could communicate via the Internet of Things?
That is to say - What if one envisioned a TCPIP and web interface from the start?
The web interface would be used for
- startup and configuration (minimizing dip switches and other UI hardware)
- ongoing status (minimizing indicators and hardware UI)
- "dip in" protocols to watch data flow - like RESTful interfaces (MTConnect, Sunspec and others), Modbus TCP and various XML schemas, or even simple .CSV data log files.

Basically one minimally needs two serial interfaces and a TCPIP (Ethernet or Wifi) interface.
[Wifi is a tiny bit harder to auto-configure - but not impossible].

The big problem was always price for TCPIP. And this was usually made worse by the fact that the TCPIP part was an after-thought or add-on - which had to be engineered /into/ the bridge. So what about taking a (cheap) TCPIP intrinsic part and using it "incidentally" as a serial bridge?

The Lantronix xPico is an embodiment of such a bridge, and a particularly "right sized" and economical version. Small ARMs and some recent x86 (Vortex86, Intel and VIA) are getting close,
but none have the sharp focus of the xPico... it being a child of a programme for TCPIP to serial bridging, which just recently branched into multiple serial. There are other small TCPIP UI systems with possible multiple serial... like Moxa and Digi. It is just that the price, tools and possibilities seem uniquely congruent with the xPico.

Only issue with xPico is actually humanly getting access to the two serials via the Hirose. The DKs have this... but also a bunch of excess. Ended up making a breakout DIP40 for prototype work... and working to a policy of keeping all useful pins exposed in viae or test points. See previous blog on breakout pins and APIs.
 
http://albertputnam.blogspot.com/2013/12/new-devices-just-give-us-pins-and-apis.html