Looking at jumping on the IoT bandwagon? Whether you have a concrete use case addressing an unambiguous business need or just are curious about how this (not so) new technology can help improve your operations, the first step is the same as any other project: figure out what you need.
Sounds simple right? This post aims to clarify what that actually means for IoT and is the first in a series aiming to shed light on how IoT deployments happen, from idea stage all the way through to value generation.
Here, we’ll cover the top 5 requirement categories for an IoT project: Location, Cost, Data, Deployment and Management. We’ll look at how each of them translates into tech speak and what the implications are of the choices made at this stage.
Scale and Security, whilst important, have been omitted from this list for brevity. Chances are they are already at the front of your mind and as such need no further highlighting.
A final note before we begin to those who have already dipped their toes into the IoT bathwater and been burnt. I can only suggest you examine your requirements again as this is the single most important step in ensuring a successful deployment. Technology, at best, does only what it is designed to do…
The top 5 requirement categories for an IoT project
Location
Perhaps the simplest and most important requirement for most projects. Where and how devices are deployed will likely drive most of your other hardware requirements and often significantly narrow down your options.
In almost all cases, it will be a significant factor in device cost. Luckily, location requirements for IoT can generally be given as a combination of just two factors: geographic coverage and mobility.
Here’s some examples:
| Geographic Coverage | Static | Mobile |
| Local | Monitoring room temperature throughout a building | Tracking high value items through manufacturing stages |
| National | Smart meters | Tracking of shipments to distributors |
| Global | Environmental Sensors | Tracking of high value international shipments |
Now to translate these categories into general requirements:
Local – Static & Mobile
You can use pretty much any communication technology here. Your primary driver is likely cost and ease of deployment.
Global & National – Static
Things get a little trickier when you start looking at coverage across entire countries. Communication technology will need careful consideration based on the deployment (availability of WiFi, LPWAN, etc) but your devices can either be powered externally or be as big as they need to be (no battery concerns). Once set up, reliability shouldn’t be an issue.
National – Mobile
Here we will assume mobile means a device that might go anywhere. Connectivity becomes one of your most important requirements in that you no longer have the option to just add more gateways or move the device closer to a window.
As with anything you move, device size and battery life are important too.
Global – Mobile
Similar to the above, but in addition to mobility, signal and reliability – you’ll need to navigate the minefield that is global connectivity and certifications.
In the next post, we’ll cover how to pick the right connectivity for your IoT project based on location and other factors. For now however, the aim is simply to help you get a clear picture of your requirements.
Cost
Quite often people will leave this part till last: this is a mistake. Picking a technology and evaluating it only to discover later that the cost outweighs the value generated is at best a waste of time and at worst a huge drain on company resources. Working backwards and trying to find a product that matches your pilot device’s specification at a fraction of the cost rarely works out well.
But how do you determine what the target cost should be? Depending on your IoT project and application, you typically have one of two options: start with the value of the data or work backward from what you or customers are willing to pay.
Value based cost targets for IoT
Starting from a value generation point of view is generally the best option, but it is also the hardest. You will need a thorough understanding of what your business goals are (e.g., decrease costs by 10 percent) and how those targets will be achieved with additional data (e.g., reduce the number of callouts by 10 percent with pre-emptive actions)
Affordability based IoT costs
The more common approach is to start with what your company is willing to pay for the data to be collected. This often simply means pushing the value estimation task onto your customers. They know how much they want to pay for the information generated by the data you will be collecting. So all you need to do is take that number, subtract your margin and voila! You have your target cost.
In most other cases, you’ve simply been given a budget to work with. Whilst this isn’t the optimal strategy, it does help narrow down your options quickly. An important note here however – you should rarely do “Budget divided by number of desired items = target cost”.
Instead focus on Budget & Location (step 1). Since location largely drives per device cost, your budget will instead drive the percentage of coverage.
More often than not, you can assume that randomly sampling 10 percent of your data is still going to provide valuable insights. It won’t catch every edge case, but it’s almost always a great first step and will help you understand the value of the data collected.
Data
In a world of cloud systems and smartphones that are charged daily it’s often easy to say “I want it all!” but with IoT project you (currently) need to be careful about what you ask for. Many data sources have real costs associated with them, if not purely due to the price of additional sensors, then because of the extra bytes required in every transmission.
With data and IoT project – and arguably other systems – you’ll want to take a long hard look at what you actually need, what might be useful in future and what you realistically don’t need. For example, do you actually need temperature updates every minute? Is that data already being recorded somewhere else? Would alerts when a threshold is crossed be sufficient?
This final question is also a good basic example of “on device” logic, or Edge Computing. As part of your data strategy and requirements, you’ll want to look at both collection and transmission of data. Collecting data and discarding all but the interesting stuff at source is hard to get right and possibly something you’ll want to leave until later in your IoT project, but it will help reduce data costs and, more importantly, ensure that your IoT data actually gets used!
Your requirements here could look something like the table below. (The example is cattle monitoring)
| Dataset | Minimum | Ideal | Business Value |
| Location | Inside / Outside an area | 1m accuracy every 10min | Prevent loss of livestock.Analyse patterns: identify preferred grazing spots, identify sick animals |
| Temperature | Threshold crossed alerts | 0.5C accuracy every 60s | Ideal: Training data for AI to identify sick or pregnant animals Minimum: Using the trained AI, we only need to transmit outliers |
| Motion | Moving yes/no | 6-axis acceleration + 3 axis compass @ 10Hz | Identify sick animalsAnimal profiling: “FitBit for cattle” could reveal interesting genetic information |
You could break out columns for accuracy and frequency but at this stage what we’re really trying to do is crystalise “needs” and “wants”.
The table is somewhat freeform in this example and the ideal column is highly unrealistic once you factor in cost and battery life requirements for a cattle tag; nonetheless it has already helped identify crossover between location and motion. Perhaps we can achieve our desired outcome with just one of those sensors, or by the fusion of two minimum requirements?
Deployment
One of the major roadblocks to successful IoT projects is reliably deploying at scale. You’ll need to consider how your newly purchased devices are going to fit into existing business processes and what new systems will need to be put in place to manage them effectively.
Consider wooden pallet tracking. These are low value items (if you ignore what they are transporting) and therefore your target device cost is likely to be low.
The devices need to be mounted securely and not get in the way during day-to-day operations.
With 4-way entry pallets that doesn’t leave many options. Your device will likely need to be much smaller than you first imagined. Simplistically: low-cost devices + small form factor + (multi-)national deployment = short battery life.
Not ideal if you’ve priced your devices based on a 5-year life… Luckily, wood pallets need regular maintenance: this gives ample opportunity for “hands-on” time with the devices – something not always common in IoT.
Without delving into all the possible solutions, here’s some food for thought that may apply to more than just pallets:
- Charging devices takes time. You’ll want to be able to swap out devices or change batteries without impacting maintenance turnaround times
- Devices can be switched out routinely every maintenance cycle, on a predetermined schedule or once the battery level is critical. In all cases you’ll need to make linking and unlinking devices and assets seamless. (RFID / NFC / barcodes can help here)
- As with mobile phones, batteries are typically the first thing to fail. Can you extend device lifetime (and reduce electronic waste) by replacing batteries rather than entire devices?
Management
As with all business assets, IoT devices and their data need to be managed. Your management requirements may not directly impact device choice, but they may help when choosing a platform.
A non-exhaustive template for management requirements might look like:
- Remote Provisioning / Deprovisioning
- 3 user types: admin, maintenance & view only
- Data export in Excel format for import into system X
- Automatic deactivation of faulty devices
- Automatic alerts for X, Y & Z, triggering actions A, B & C
If your requirements can’t be met with off the shelf platforms that is only a minor stumbling block. With APIs now being near enough ubiquitous, chances are the management system you need can be built in house at a relatively low cost.
And that was the last of our 5 most important requirements for IoT projects. Hopefully, you now should have a clearer idea of how to approach your next IoT deployment. Whilst your particular use case might warrant a different approach to requirement building, the key takeaway is that IoT, being multi-disciplinary by nature, requires a system level view before worrying about things such as communication technology, petabytes or AI/ML.
