Risk Reduction in IoT Projects

IoT Projects involve a number of elements that really need to fit and ideally be optimised to produce the best business result.

There is seldom any doubt that more information may result in better management however the ROI depends on what will be learned and done and exactly the investment required is to operationalise the information acquisition. 

Common risks stem from:

• Allowing off the shelf devices to determine your solution (or worse still your requirements) — as the exact match of sensors, qualities of service, configuration capabilities, diagnostics, etc. may not exist. An off the shelf device may notionally do what is needed but they often come with an overhead (i.e. the off the shelf devices might be overspecified and not optimised) 

• Expecting subject matter experts or business users to say exactly what information they want, with what accuracy, how often, with what reliability and to explain what they will do with, and what value it will be  

• things will be overspecified e.g. 5 nines delivered and paid for when 2 nines is completely adequate (and an order of magnitude cheaper) e.g. reliability, accuracy, etc. satellites, relays, adaptive spreading factor, etc.

• Relying on compelling slide deck presentations (that everyone interprets as addressing their needs) that duck the devil in the details so that what is implemented is too expensive, too poor a fit, etc.

• Assuming that knowledge of traditional enterprise IT technologies and practices will work in a domain where hardware, network and operating systems (firmware) can all be bespoke.

• Expecting network utilities not to seek capture and allowing them to convince you you should use a cellular network model instead of a wifi network model (as some once did with wifi).

Many people want to pretend that these things can all be worked out in the abstract but as with so many things in life, often a simple experimental ‘suck it and see’ approach makes sense and everyone is educated on the journey. 

These experiments only make sense if there is a guaranteed path to scaling and operationalisation.  A proof of concept not based on a long-term approach won't help validate the true costs. Essentially, thinking an agile approach can be applied to producing an end to end solution is mistaken. 

It is natural for people in large organisations to make decisions based on what seems safe, what is convenient, received wisdom, fringe benefits (e.g. corporate hospitality).  Often, over the long term, these decisions lead to:

• an order of magnitude higher operational costs e.g. when you lock into a proprietary network utility rather than your own private or hybrid network

• an order of magnitude higher establishment costs i.e. because you choose to use technologies or partners that are not specifically set up to enable bespoke solutions within the required financial and operational envelope.

We would suggest that people accept that there are both known unknowns and unknown unknowns and make a small investment to learn through doing.

Keeping in contact | moving devices

We deal with entities that are moving (e.g. animals, farm equipment, etc.). We want to ensure they remain in contact with people or systems monitoring or controlling them. We need to do this using the least energy and airtime possible while meeting the needs of each entity.

Many things influence the quality of a device’s reception e.g. distance, gateway characteristics, device population (e.g. congestion), topography, obstructions, etc. so our users’ networks may be dynamic i.e. gateways and relays being added, antennas adjusted, etc. to extend coverage or capacity. 

Entities can be in different states or situations so how long it is OK for an entity to be out of contact may vary by individual and change over time. Some users may need to be able to control energy use for each individual. With some animals, people or equipment in some situations  (e.g. the animal is unwell or the equipment near sensitive environmental zones)  users can accept missing a many messages in other cases they can not.

There are a number of approaches that can be used. For stationary devices in static networks people may rely on ADR. In other cases people may use our Adaptive Broadcast Energy (ABE) feature to allow specific devices to respond more quickly.  People may also use manual overrides to control configurations.

What the user does

For any entity, a user can define:

• if ADR is enabled — energy use is then determined automatically based on simple system wide parameters (and ABE and Manual control is not available)

• if ABE is enabled — energy use is controlled by device (and Manual control is not available). The parameters are:

Missed message limit — how many Messages can be missed (minutes) too Loud Period — how long to accept messages using too much energy/air time to communicate

What the solution does:

The solution automatically:

• Reduces the energy/air time device uses if it is using more than needed.

• Increases the energy/air time a device uses if too many messages are missed.

• Alerts a user if a device:

• is off line for more than a user defined period

• has been dropped i.e. is detached from entity

• is at a strange angle e.g. does not seem to be seated correctly

• is outside the areas it is meant to be in (wandering, escaped, etc.)

An example — sick or wayward horse

The horse is well within GW range.
The horse moves to the edge of range.
The horse moves out of range so the device increases energy used to ensure connection,
The horse is well within range.
The horse moves closer and no longer needs to use as much energy to communicate.
The device is asked to reduce its energy use to conserve battery and on air time.