IoT solutions usually need to be learning solutions

 The value in LoRaWAN solutions comes from allowing people to take actions to address issues with things or control things. In many cases while people know what they want to achieve in a business sense they often can not initially be as precise about: exactly what data they need, at what frequency, with what accuracy, with what fidelity; how that data is best converted into meaningful information that can be used by business or non-technical people, to affect what they actually do. 

So systems need to be set up initially to learn about these things and then continually be refined to achieve an optimal solution. This will often require evolving sensors, devices, fittings, on device logic/AI, device messages, network components, back end systems logic, scoring, thresholds, etc. It is effectively an agile and iterative process but it needs to take place across: hardware, firmware and software.

Too frequently people try too early to fix an aspect of the system and then work around that as a fixed constraint. What is needed initially is a solution that can capture information and allow it to be analysed in a range of ways e.g. using basic instrumentation, analyticals tools and allowing the application of data science to filter, aggregate, compare, correlate, interpolate, extrapolate etc. and compare calculated values (actual and predicted) against observed data.

What is learned will allow one to understand how to calibrate sensors (modes, frequency, thresholds etc.), configure devices, develop interpretations, present information, identify incidents that require people's attention.

This has important implications for the overall process and sequencing of solution design and development.  Usually a highly iterative approach will make sense with cycles of: user experience and improvements in data analytics and devices (and within that iterations focused on improving the data, analytics, device). So the systems will be usually be developed as follows:

• Get an initial system operative 

• common business objects and associations that provide initially an information  harness or context for readings and controls. 

• gather data from real world entities in real world environments

• share access to information with expert users

• Analyse the data, rules, sensor parameters, etc and convert data into meaningful information e.g. accurate, reliable, credible etc. 

• diagnose the cause of inconsistencies between what we know of the real world and what the solution says

• use the diagnosis to recalibrate and reconfigure the solution

• Polish user experience so users can get the value they seek in the way they want it

• Operationalise the system

To achieve this evolution, avoid stranded pilots and minimise wasted effort and cost, it is critical that the platform on which the solution is built is end to end and configurable at all points.

LoRaWAN in a box overview

 Many see opportunities to better look after and control their remote assets. Making this viable requires significantly reducing the costs, complexity, risk, time, etc. and obviating the need for expertise in a raft of technologies across several domains (electronics, firmware, networking, etc.) most people don't have (or want). People also need confidence they can scale without commensurately scaling costs (e.g. because some rapacious Telco has a lock-in) and integrate it into a suite of other applications. 

LXC-in-a-box allows you to get readings from devices and to control devices out of the box. It allows PoCs to move quickly to Pilots and then on to production solutions that integrate into an enterprise's ecosystem. 

It doesn't pretend you can build a highly optimised large scale solution codelessly and it doesn't require you to try and pretend a generic Swiss-army device a) does precisely what you need; or b) will be the lowest cost component for you needs. Rather it allows you to choose any link in the technology value chain and optimise it. You can do that optimisation when it suits you. 

The advantages to the typical user are that LXC is:

• simple — works end to end on day one. You require no knowledge of, or investment in, technologies for: network (including LoRaWAN), electronics, firmware, etc.

• low risk — all the little steps that have to work together to get remote sensors and controllers to actually solve business problems in the field for real users in a production environment are done.

• scalable — it supports thousands of devices, millions of messages.

• cost effective and efficient — extremely low initial cost and excellent cost visibility.

• customisable and optimisable — you can reduce: equipment costs, size, energy demands or add extra capabilities; you can extend the network; you can optimise and simplify the user experience (data interpretation, analytics, alerts)

• learning — automatically continuously learns about coverage, congestion, what is normal, etc.

• proven — production systems use it for: animals, assets, environment,control, etc.

• integratable — you can integrate it with other systems via basic APIs. 

• extendable — you can add new sensors, devices, readings, scoring, logic, etc. 

When you get ‘LXC in a box’ you get OTB an end to end system (device, gateway, web system, phone app) and you can see information about your thing(s): what is measured, what is normal etc. Your thing(s) are organised in groups, associated with users, teams, properties, places, areas, etc. Your device(s) can be configured and controlled and there are a range of automated alerts.

We think it is THE answer to getting from the trough of disillusionment or the valley of despair to the slope of enlightenment and the plateaux of productivity. 

LoRaWAN enables us all to make the world better

I am motivated by making the world a better place. The emergence of LoRaWAN and the availability of increasingly smaller, cheaper and more efficient sensors and electronics provides new ways of improving the environment and the life of animals.  On-device AI allows exponentially more data to be captured, analysed and processed. Satellites, relays and meshes enabled hybridised networks that can deliver coverage exactly where it is needed for the least cost. Consequently many things are becoming possible at lower costs that will allow the health and wellbeing of animals, plants and equipment to be monitored with increasing fidelity. The knowledge gained can provide both immediate and longer term value.  

What sets us apart from many is that we focus end-to-end. We believe that only by optimising each element in the LoRaWAN technology value chain will you get an optimal solution. This covers devices (electronics, enclosures, fittings) to the firmware, to the network architecture (terrestrial, satellite, relay, mesh, etc) to the systems (logic, UI, etc). We aim to enable rapid iteration across this end-to-end spectrum i.e. adding sensors, updating messages, changing the rules and what a user sees on their phone in days of effort (not weeks or months).

Many try to apply a hobbyist approach and build unique LoRaWAN solutions with a ‘plug and play’ approach with off the shelf components, no-code systems etc. While that may quickly produce a PoC and even a Pilot it is not a strategy that we think will lead very directly, or affordably, to a fully optimised solution. It also doesn't effectively engage the end users or those seeking the value effectively enough i.e. too many variables are assumed to be fixed constraints (e.g. size, cost, messages, etc.).

One really needs to understand the materiality of the data and what exactly is required to allow decisions to be made. The goal must be to optimise LoRaWAN devices to do exactly what is needed and no more (to be sure there are no unnecessary components that can increase costs or complexity). One also needs to ensure devices do just what is essential to achieve the specific value sought while ensuring qualities of service (e.g. message rates, device life, etc.). By enabling dynamic control and visibility, users can monitor and adjust the state and behaviour of the devices, sensors, etc. so they live within their energy and bandwidth budgets.

We hide most of the complexity of LoRaWAN to ensure a simple user, and engineering, experience.  We have established a modular end-to-end technology framework that deals with many of the complex problems and many of the common business objects. We then enable solutions to be built on top of that framework that can do precisely what is required (hardware, firmware, network, software) for a specific scenario.  It has taken a great deal of work, experience and experimentation to find the right balance between achieving reuse and allowing specialisation.

 

Coverage challenges for LoRaWAN IoT solutions

 One of the great advantages of LoRaWAN solutions is that one can avoid the rapacious charging and network lock-ins that Telcos have traditionally made an art form of. Some of us are old enough to remember paying Telcos a dollar a txt message (i.e. for a service of so little truly marginal cost to them they were often unable to calculate a txt message's cost precisely; and that eventually reduced in cost by three or four orders of magnitude or made entirely free). 

Another great advantage of LoRaWAN is that one can use existing networks where they are available (at a fair price) from a network utility and extend the network to places only you require at your time, convenience and cost. It is hard for a network utility to extend its network for a single user. Telco's are also focused on providing 5 nines quality of service while for the vast majority of IoT solutions, 2-3 nines is adequate and the marginal cost of extending this to get an extra 2-3 nines can not be economically justified.

If you have thousands, hundreds or, or possibly just tens, of devices in well-defined areas with no LoRaWAN current coverage it will often make sense for you to add in your own gateways i.e. otherwise you will pay pennies for each device each month and those pennies will add up.

There are several mechanisms for extending LoRaWAN coverage and they each have their pros and cons e.g. gateways (which will require backhaul and power); relays (which can handle a small number of devices at the edge of a network); direct to satellite solutions (which will have latency and cost constraints); Mesh gateways (which require using proprietary protocols).  We have been working with all of these and think they all have roles to play.

When looking at extending a LoRaWAN network, you need to know exactly what coverage you need i.e. to know exactly where you need coverage and what qualities of service you need (based on device populations). If you are at the edge of coverage for a mobile phone you can perhaps move a few meters to get better coverage. Things can't do this if they are fixed and don't know how to do this if they are mobile. So you need to know as well as you can the areas and places that coverage is needed at.

All the LoRaWAN solutions we create allow coverage to be collated and mapped.  We also dynamically track network congestion and outages. The areas and places which are surveyed to assess coverage are an expression of network requirements. These features allow both monitoring of current performance and predictive assessment of potential future gaps or issues e.g. we can see an area is becoming congested before that level of congestion materially affects the utility of the system. Our coverage measurement approach is network agnostic and will work with a mix of public and private gateways.

Our approach for extending LoRaWAN networks is predicated on as precise an understanding of the requirements as possible and a continuous assessment of the current state. 

Why has IoT failed to live up to the hype.

There is a huge potential for solutions that monitor and control things using LoRaWAN.  

Many LoRaWAN projects fail to proceed past PoC. If you want to address the problem it is helpful to understand the cause

To date adoption has been hampered by a few things: 

• emerging enabling technologies — which is now largely resolved and standards e.g. relays
• telco mindset in early adoptions — "field of dreams" build a network and they will come; and “all you need is off the shelf device” and that will deliver the value you need. 
• the inevitable failure of “inane agile” — when there are many elements and skills required in a complex solution. 
• one size fits all IoT platforms — undifferentiated IoT platforms that don't address the specific challenges of any particular technology.

New approaches and platform address the last two issues and provide a basic templated approach that can expand to a full scale implementation.

Lorawan NWAS / LNS market: AWS, TTN, Chirpstack, ThingPark

 Our LoRaWAN Core platform (LSC) is based on serverless AWS. 

Over the last four to five years we have had experience connecting devices from multiple NWAS/LNS e.g. ThingPark,  TTN, Chirpstack, etc.

It is going to be very interesting to see how the LoRaWAN NWAS develops. 

Analysis and modelling

Modelling consists of doing the analysis and recording the results in a model of some kind, whereas analysis can be considered to consists of doing the analysis and recording the results in narrative form or picture of some kind.

If the analysis is done soundly it represents 90%+ of the effort of modelling (which just becomes the activity of recording analysis). 

Design is an extended form of analysis where imagination and inventiveness is incorporated. 

The underlying thinking for analysis and design is often best supported by manual (vs computer) techniques e.g. paper, whiteboard, etc. As false precision early in thinking reduces mental plasticity through and runs the risk of cognitive dissonance impairing the quality of analysis (Cf. Rorschach tests, and note Kahneman's observation that "System 1" doesn't present the options it considered or the source data once it has formed a view based on inputs).

Modelling ensures that the analysis/design is done corrected, is recorded, and can be examined and updated. It makes it more obvious when analysis/design is incomplete.

Why then do people have the impression that doing analysis/design and recording in documents is far faster than modelling? It is because they do half baked job of and the method of presentations doesn't make it obvious. Often in fact it encourages partial analysis because the "analyst" has formed conclusions (based on prejudice e.g. what worked last time, what would suit them) and good analysis could undermine these conclusions. 

When analysis is represented narratively, unless the narrator is very skilled and extremely assiduous, the relationships between data is often not recorded explicitly and the chain or sequence of connections cannot be seen or understood. The multiple perspectives a model provides can not be used to assess finding from different angle.

Narrative form may be fine for the analyst, where it usually acts as an aide-mémoire, and the relationships (to the extent they are known) may exist in their heads. It is not OK for the person for whom the analysis is done. It usually requires oral interrogatives to determine a full understanding, and more usually this shows that thinking has not been robust.

As Box said ""All models are wrong, but some are useful". No analysis is perfect, and perhaps none is ever fully complete. What is needed is to ensure that the analysis and models are sufficient to achieve the goal.