Tweet

November 2016
Article
AutomatedBuildings.com

[an error occurred while processing this directive]
(Click Message to Learn More)


Standardisation and Openness Revolution for IOT

We concluded that something needed to be done and that nothing short of a Revolution was needed to change this world, to make it better and more open.
Throstur Jonsson

Throstur Jonsson
Founder,
Rational Network

GO-IoT

Articles
Interviews
Releases
New Products
Reviews
[an error occurred while processing this directive]
Editorial
Events
Sponsors
Site Search
Newsletters
[an error occurred while processing this directive]
Archives
Past Issues
Home
Editors
eDucation
[an error occurred while processing this directive]
Training
Links
Software
Subscribe
[an error occurred while processing this directive]

Introduction

We are in a time of enormous change, due in no small part to the avalanche of innovation that is the Internet of Things (IoT).

With new sensors and actuators being released at a whirlwind speed within the Internet of Things (IoT), it is bordering on a modern Wild West, where there is a virtual stampede to grab a stake early. It is a time when both start-up businesses and big name players are fighting to secure their niche in the new market.

The lack of standardisation is rapidly becoming a major issue and many proprietary solutions appearing in the same market segment are unable to interact or communicate with each other, which is not ideal.

New technological innovations are often designed as totally closed ‘Sensor to Cloud’ solutions in an effort to grab the whole value chain from sensor to ‘outer space’ and to exclude others from entering the chain.  This locks the customer in with the vendor of the solution, regardless of whether it meets the actual requirements of the customer in full. This won’t have any immediate effects in the short term, but can be dire in the long term making it difficult, if not impossible to switch from a vendor to another. Agility and flexibility is the key for the. One has to understand the past, in order to not repeat the same mistakes in the future.

The Problem - Vendor lock in effects and few compatible alternatives

At Rational Network, we were originally focused on cloud based Energy Management solutions for buildings, with the intention of getting meter reading data into a central server where it could be converted to valuable user information. – That was our only target and was where we had placed the focus for our business as a professional software specialist firm. Soon enough though, we realised that all was not well in Paradise.

We had used sensor and logger hardware from selected third parties only to find that the different hardware was not compatible. Time after time, we searched for intelligent per-breaker or per-wire energy sensors and other smart sensor solutions – specifically those that were passed on some open standards, which would enable us to write the software once, rather than needing to tailor make for each separate solution. There were a variety of clever solutions that might have fit our brief perfectly, but for the fact that third party access to any part of their sensor to cloud value chain was not allowed. They wanted to be the sole provider of everything from Energy Analysis software right down to the sensor, meaning that the customers would have to accept the entire package on a ‘take it all from us, or leave it’ basis. This was a major brick wall for us.

We were also facing the lack of flexibility that came with the sensor/control hardware. ‘You need this hardware for that solution, but that hardware for this solution, then in order for this and that to communicate, you need to add other hardware, gateways etc.’ The result is an increase in solution costs, a much longer learning curve for installers and solution managers, and ultimately a much higher inventory cost.

In 2012 after a long, very frustrating period trying to overcome the issues described above, we concluded that something needed to be done and that nothing short of a Revolution was needed to change this world, to make it better and more open. The customer should be able to have more freedom and the ability to reduce its cost of installation, shortening its ROI.

The Solution – A modular hardware and open standard based software

Here at Rational Network we became focused on opening the market and making it work with the other technologies, giving the customer more freedom, lower costs and a shorter return on investment.

Our initial experiments showed us that the latest low cost development boards introduced to the maker-space and education markets might be a good base upon which to build (Raspberry Pi, TI Beaglebone, etc.).

However being a software team, we soon found out that these boards were not suited for creating industrial grade hardware.

Finally, after nearly four years of hard work, we are unleashing our product line GO-IoT.

Our six fundamental goals were:

  1. One type of hardware for different IoT applications, adapted by software (firmware) to each of them.
  2. Modular hardware. Only what is needed ‘in the box’ for each IoT installation should be ‘in the box’, nothing more, nothing less.
  3. Fit within a standard DIN-Rail box.
  4. Software (firmware) based on widely accepted standards only, allowing interaction with hardware and software from other vendors.
  5. Open source as much hardware and software as possible to maximise attraction of IoT/IIoT makers and start-ups.
  6. Support yesterday’s sensor/actuator technology as well as that of today and tomorrow – in one box.

In short, this means to make a product that is open to anyone, anything and everywhere, plus being future proof.

Dingo IoT Backbone

To fulfill goals 1- 3, we designed the DINGO IoT BACKBONE as a 4-layer industrial grade IoT computer with well-defined connector interface between all 4 hardware layers. At each layer the customer can select between different hardware modules, depending on the needs of each IoT application. In addition, our use of open source for the “User Interface” and Base Board layers, means that customers are free to implement their own variants and plug-in modules (layer 4).

We designed the DINGO BACKBONE such that it could fit in a standard DIN-Rail box (EN 60715 TH35) because we know that hardware enclosures can become quite a hurdle. This enables box selection from multiple vendors, and guarantees easy installation in cabinets.

Simplified Schematics

 Fig. 2. Simplified Schematics of DINGO BACKBONE hardware and software.

Goal 4 was quite a challenge, as there are many software “standards” out there. As a result, we selected the BACnet standard as our first shot for the DINGO software stack.

However we realize that there exist other device –communication standards and even proprietary solutions, which some customers might prefer over BACnet (for example Google Weave). Therefore we took special care isolating that part of the software that would be common to most standard or proprietary implementations different from BACnet.

This is the “Peripheral Manager” (PM) shown in the schematics above. The PM is the bottom software layer responsible for communicating with all kinds of peripherals, like GPIOs, I2C, PWM, CAN, Modbus, M-bus, 1-Wire, etc.

The PM frees us and other developers from the tedious task of low level peripheral software development. This makes it possible to adapt to other standards than BACnet with minimum effort.

Our BACnet/IoT implementation is designed with a special focus on IoT, not only Building Automation, but also in fields such as Home Automation, Street-lighting, Smart-Grid, etc.

BACnet/IoTFirstly, our BACnet server is simple to configure, regardless of sensors and actuators connected to the DINGO BACKBONE together with the need for Trend Logging, Control Apps, etc.

Secondly, we added a ‘Virtual Router’, which enables the installer to group information from multiple sensors and actuators into virtual BACnet devices. This means that a single BACKBONE appears as multiple BACnet devices on the BACnet network. This leads to better understandable network of multiple IoT devices rather than having one big flat structure of sensors and actuators.

Thirdly, we took into consideration support for ultra-narrow-band technologies like Narrow band Power-line Communication (N-PLC), whose bandwidth is too low to support native BACnet communication. Our PINGO technology is a good example, where devices can communicate on the existing power-lines in buildings and streets, for long distances. PINGO has become very popular by our current Scandinavian customers, because of easy installation and robustness.

Finally, we made the decision to implement the cutting edge BACnet/WS (Web Services) technology, which enables standard based Cloud connectivity to BACnet.

When it comes to Cloud connectivity, the previously mentioned lack of standardisation becomes obvious. For example, we have experienced demand for connectivity to the well-known Watson IoT platform from IBM. That cloud connectivity demands implementation of the open source MQTT protocol. Upon examination, we soon realized that the MQTT was essentially a subset of BACnet/WS. That has enabled us to create a very thin software layer between MQTT and BACnet/WS, where the MQTT payload is actually the BACnet/WS data-stream.

This can probably be done for other Cloud IoT protocols as the BACnet/WS is very extensive.

Goal 6 was reached by supporting widely used yesterday’s device-protocols like Modbus and 1-Wire within the above described Peripheral Manager (PM). That is also true for today’s technologies like M-Bus and possibly ZigBee.

When it comes to tomorrow technologies like sub-1GHz wireless low power native BACnet sensors and actuators we support those with hardware plug-in modules like our WINGO plug-in, and native implementation of the BACnet stack, for those low resource sensors and actuators.

Conclusion

The Go-IoT product line (including DINGO, PINGO and WINGO) is a hardware and software solution for IoT, where the customer simply picks whichever modules are required for their specific ‘Sensor to Cloud’ IoT solution. This leaves room for flexibility to mix those modules, with solutions from other vendors which can then be configured by open standards or even a proprietary solution.

Fortunately, the IoT world is gradually moving towards more open standards and agility. However we strongly believe that companies need to realize the importance of future agility and flexibility during vendor justification process. With GO-IoT we want to help customers not become stuck a couple of years from now based on decisions made today.


About the Author

Throstur Jonsson has 30 years’ experience in mathematical- and control- software solutions. Career projects include hydro power-plants simulator, energy management systems, street lighting system and remote monitoring of solar panels, etc. Throstur is one of the founders of Rational Network, the company behind go-iot.io

footer

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

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]

Events

Want Ads

Our Sponsors

Resources