“The Priority Matrix shows that many IoT technologies are 5 years from mainstream adoption. However only one innovation profile will reach maturity in 2 years, indoor location for assets.
So why is ‘indoor location for assets’ more likely to achieve mainstream adoption sooner than other technologies? It’s because there are clear benefits for most companies and off-the-shelf software such as our BeaconRTLS™ is already available.
Our work with companies shows they are nevertheless cautious. Companies are taking time to understand the competing asset tracking technologies and are performing, sometimes lengthy, trials to determine how new systems will integrate with existing systems. They are considering the implications of SAAS vs on-premise solutions, the availability of second-sourced beacon hardware and the compromises of accuracy vs system complexity and cost.
We have two new beacons in stock in the INGICS range:
The iGS04 is a new keyring/keyfob style beacon only 6mm thin. It advertises continuously and the button is used to change a value in the advertising data.
The iGS01 is similar to our other iGS beacons except it has no sensors other than the being able to detect the button press.
These Bluetooth beacons are not iBeacon nor Eddystone beacons. The advertising data is instead wholly used for sensor data. You will need an (your own) app or gateway to scan and obtain the advertising data.
The traditional IoT strategy of sending all data up to the cloud for analysis doesn’t work well for some sensing scenarios. The combination of lots of sensors and/or frequent updates leads to lots of data being sent to the server, sometimes needlessly. The server and onward systems usually only need to now about abnormal situations. The data burden manifests itself as lots of traffic, lots of stored data, lots of complex processing and significant, unnecessary costs.
The processing of data and creating of ongoing alerts by a server can also imply longer delays that can be too long or unreliable for some time-critical scenarios. The opposite, doing all or the majority of processing near the sensing is called ‘Edge’ computing. Some people think that edge computing might one day become more normal as it’s realised that the cloud paradigm doesn’t scale technically or financially. We have been working with edge devices for a while now and can now formally announce a new edge device with some unique features.
Another problem with IoT is every scenario is different, with different inputs and outputs. Most organisations start by looking for a packaged, ready-made solution to their IoT problem that usually doesn’t exist. They tend to end up creating a custom coded solution. Instead, with SensorCognition™ we use pre-created modules that we ‘wire’ together, using data, to create your solution. We configure rather than code. This speeds up solution creation, providing greater adaptability to requirements changes and ultimately allows us to spend more time on your solution and less time solving programming problems.
However, the main reason for creating SensorCognition™ has been to provide for easier machine learning of sensor data. Machine learning is a two stage process. First data is collected, cleaned and fed into the ‘learning’ stage to create models. Crudely speaking, these models represent patterns that have been detected in the data to DETECT, CLASSIFY, PREDICT. During the production or ‘inference’ stage, new data is fed through the models to gain real-time insights. It’s important to clean the new data in exactly the same way as was done with the learning stage otherwise the models don’t work. The traditional method of data scientists manually cleaning data prior to creating models isn’t easily transferable to using those same models in production. SensorCognition™ provides a way of collecting sensor data for learning and inference with a common way of cleaning it, all without using a cloud server.
Sensor data and machine learning isn’t much use unless your solution can communicate with the outside world. SensorCognition™ modules allow us to combine inputs such as MQTT, HTTP, WebSocket, TCP, UDP, Twitter, email, files and RSS. SensorCognition™ can also have a web user interface, accessible on the same local network, with buttons, charts, colour pickers, date pickers, dropdowns, forms, gauges, notifications, sliders, switches, labels (text), play audio or text to speech and use arbitrary HTML/Javascript to view data from other places. SensorCognition™ processes the above inputs and provides output to files, MQTT, HTTP(S), Websocket, TCP, UDP, Email, Twitter, FTP, Slack, Kafka. It can also run external processes and Javascript if needed.
With SensorCognition™ we have created a general purpose device that can process sensor data using machine learning to provide for business-changing Internet of Things (IoT) and ‘Industry 4.0’ machine learning applications. This technology is available as a component of BeaconZone Solutions.
The article describes what they call a ‘Semantic Web of Things for Industry 4.0 (SWeTI) platform’. Although it’s very useful, it’s less of a platform in the software sense and more of an ecosystem or model.
The platform describes usecases, tools and techniques for smart applications. Using this model, BeaconZone operates in the Device, Edge and Data Analytic layers. We provide for smart devices and tools, gateways, storage, machine learning (ML) and analytics.
The Nordic blog has an informative post on How IoT-Based Predictive Maintenance Can Reduce Costs. It explains how connected sensors can save maintenance costs through reduced downtime. The post provides some examples from the power industry and explains how the same techniques can be used in the tools, retail, distribution and physical infrastructure industries.
As the post mentions, the challenge is how to scale this up. We are told IoT is the solution. Here at BeaconZone, we don’t believe IoT is always the solution, especially where there’s a requirement for higher sensor sampling frequencies. There’s too much data, too much data transfer and too much server processing. It really doesn’t scale. Apart from the waste and cost of these resources, the latency of triggering events based on the data is too high. Instead, look to so called ‘edge’ or ‘fog’ computing where more processing is done nearer the sensors and only pertinent data is sent to other systems.
Haltian has a useful IoT protocols comparison. It provides a comparison of TE Cat 1, LTE Cat M1, EC-GSM-IoT, NB-Io, Zigbee, SigFox, LoRa, Google Thread, Bluetooth LE and Wirepas Mesh.
Haltian say “It’s is a question of selecting the best-suited option for each use-case at hand”. One thing they don’t say is that the protocols are not mutually exclusive. For example, it’s increasingly the case that more than one protocol is used, one for short on-site distances and another for intra-site communication. WiFi/Ethernet also aren’t mentioned which are often a component of IoT solutions.
Vodafone have an informative new report, the Internet of Things (IoT) Barometer. It’s a survey of 1,430 companies worldwide into their use of IoT.
IoT adoption is increasing now that companies are buying more cost-effective, off the-shelf solutions rather than building their own from scratch:
74% of adopters believe that within five years, companies that haven’t adopted IoT will have fallen behind their competition.
Adoption is across all sectors:
“95% of adopters are already seeing benefits. Over half (52%) say that the returns have been significant and 79% say IoT is enabling positive outcomes that would be impossible without it.”
They are commodity rather than proprietary items and hence very low cost compared to legacy industrial sensors.
No soldering or wiring up is required.
They are easy to interface, for example, to Bluetooth gateways and smartphones.
They can participate in Bluetooth Mesh to communicate over large areas.
They detect a variety of quantities such as movement (accelerometer), temperature, humidity, air pressure, light and magnetism (hall effect), proximity, heart rate, fall detection, smoke, gas and water leak.
They are proven. For example, some of our temperature sensors are used to monitor airline cargo.
Software exists, such as BeaconServer™ such that you don’t need to write any software.