November 2016 |
[an error occurred while processing this directive] |
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 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:
In short, this means to make a product that is open to
anyone, anything and everywhere, plus being future proof.
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.
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.
Firstly, 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
[an error occurred while processing this directive]
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]