Site-logo

Chris Guest Profile ImageChris Guest
Founder & CEO, LightBug
LinkedIn

Chris Guest is Founder and CEO of LightBug, a manufacturer of GPS Trackers. He has considerable experience as a software developer, product designer, and electronics firmware engineer, starting out at 14 developing GPS tracking technologies with his father.

Are you looking at jumping on the IoT bandwagon? Whether you have a concrete use case addressing a specific business need or are just 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? This post aims to clarify what that actually means for IoT, from the idea stage 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 the implications 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 started an IoT project and been burnt: I can only suggest you examine your requirements again. This is the single most important step in ensuring a successful deployment. Technology, at best, does only what it is designed to do.

1. Location

Location is perhaps the simplest and most important requirement for most projects. Where and how you deploy your IoT devices 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 are some examples:

 

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'll 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.

You can read about how to pick the right connectivity for your IoT project in this post, but for now, the aim is to help you get a clear picture of your requirements.

2. Cost

Quite often, people will leave cost considerations 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 application, you typically have one of two options: start with the value of the data or work backwards 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 your business goals (e.g., decrease costs by 10%) and how those targets will be achieved with additional data (e.g., reduce the number of call-outs by 10% 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 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'll 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 be 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, i.e. only covering a portion of your fleet and extrapolating data from that subset. 

More often than not, you can assume that randomly sampling 10% 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.

3. 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, 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 - 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 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).

 

Minimum

Ideal

Business value

Location

Inside / Outside an area

1m accuracy every 10min

1. Prevent loss of livestock
2. 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

1. Identify sick animals
2. Animal 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?

4. 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. Basically: 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 which may apply to more than just pallets:

  • Charging devices takes time: you’ll want to be able to swap devices out 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. But 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?

5. 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 and 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

It’s only a minor stumbling block if your requirements can’t be met with off the shelf platforms. With APIs now basically ubiquitous, chances are the management system you need can be built in house at a relatively low cost.

Now your IoT project is off to a good start

And that was the last of our five most important requirements for IoT projects. You should now 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 like communication technology, petabytes or AI/ML.

Now that you’ve figured out what you need, I’d recommend you consider the best IoT connectivity option for your IoT project. You can find a detailed description of how to do that in this blog post: Top 5 things to consider when choosing IoT connectivity

If you have an interesting problem that needs solving, feel free to reach out via LightBug’s website or contact me on LinkedIn!