Lately, a lot of people have asked me on how to build an IoT product. So, I ended up writing this blog post covering the basics of IoT product development.
I will try to cover the following here:
- Critical components that make up your IoT hardware
- What makes these components function together
- How to get it built?
- Where people get IoT hardware development wrong?
Note that this is just an easy read to make you familiar with what IoT product development incorporates, but isn’t an actual representation of hardware product development process. If you want to go through that, I am writing another blog post that will have it in details. But nonetheless, this blog lays some really concrete guidelines that are otherwise extremely difficult to place without making the blog too technical.
Practically speaking, this simple to understand process has been extremely help in my meetings with CXOs that don’t understand embedded very well. And the process is pretty simple. All we will do is to place hardware components on a board as we build our understanding of IoT.
So, let’s start your journey towards IoT product development!
Step #1 of building an IoT product – What’s your foundation?
First of all, let’s think about a place where you need to place all of your electronic components. This should look something like this
So, this is a board on top of which you are going to place all of your electronics, your sensors, you memory, other components, etc. We will try to avoid any tech jargon to prevent it from getting over complicated.
Step #2: Add a Microcontroller or a Microprocessor here
For any hardware device to function, it needs to be able to understand electronic signals, allow you to program it, and be able to carry out smart operations (functions/features/etc, whatever you call it).
In rare cases you would actually need a microprocessor. Most of the time you would be fine using a Microcontroller. I am going to write a blog post on Microcontroller vs Microprocessor very soon detailing how to select between a Microprocessor and a Microcontroller. But assuming that only 1% of all IoT products actually require a microprocessor, we would go with a microcontroller here.
Here’s how your product looks now with microcontroller placed at the core
As a core of your product, they account for 99% of all the functionalities your IoT product carries out. Amazing isn’t it?
On a side note: I’ve seen people trying to build industrial products dedicated for operation and monitoring of motors with microcontrollers and microprocessors.
That’s not a good practice. We can’t control motors with microcontroller or microprocessors. In such situations I would actually prefer using DSP or ASIC or FPGA modules that can actually deliver the performance that’s needed to connect instruments like motors.
Remember the fatal Uber self driving car incident? The root cause of that wasn’t a faulty logic, but disabled DSPs on Toyota replaced with microprocessors that weren’t fast enough.
Step #3: Adding a sensor or an actuator to your IoT product
In the last step, you figured out what type of processing unit you really need in your IoT hardware. Great so far!
Now, it is time to find out sensors that will sense your environment (or whatever you are planning them to do), and will communicate what they sense to your processing unit. There are a few more things involved, but for the sake of simplicity, this is extremely easy to understand.
And, I think this should be a common knowledge.
I mean, all a sensor really does is to send information in a format like
X20 B55 C22 …
This is what your processing unit takes in and applies a series of transformation to change the information from raw to a more processed form (the one that we read).
Once you place a sensory unit on the above board, you now have a sensory unit, a processing unit and a board to place all of them on it
But, there’s more to it.
This processing unit will require a software to run itself on it. That’s the real magical sauce that drives electronics – the firmware!
We will take a good look at Firmware in the later sections of this blog post, but let’s get back to assembling our hardware right now.
Step #4: Adding wireless connectivity
This in my opinion is one of the most critical part of IoT hardware development, often something that gets taken very lightly as well.
If you are not from this background, you might find it a bit difficult to be involved in this part by what vendors, manufacturers and consultants would suggest you. Most likely, the pace of ideation to production in IoT is often responsible for product owners to take it for granted.
Wireless could go very costly, very wrong at the same time.
When you are adding wireless IoT protocol modules to your hardware you have two options:
- Pick up an off the shelf module
- Or, go and make your own custom radios
No one option is superior than other. I feel like saying that is a slap on the readers face as I find it extremely vague to draw any conclusions.
So, let’s simplify it with a comparison table
|Criteria||Custom RF Engineering||Using a packaged Radio Module|
|High upfront costs||Low upfront costs|
|Increased licensing costs||Licensing costs are low|
|Risky RF engineering is required. Technology supervision and consulting is required here||Can be safely offloaded to manufacturing vendor. They won’t have anything to do with it. The package will be used as it is and can delivery optimal without much RF related oversight|
|Certain use cases would demand custom engineering as manufacturers wouldn’t have considered when they built radio modules||These modules are designed to deliver average performance for most of the environments
|Exceeding average RF benchmarks requires custom RF development||Cannot exceed optimal results, you’ll get less than what datasheet says
|Antenna design and optimization is under your complete control||Antenna design has already been done, you can extend it a bit. But not much can be done here
|Need to create a customized software stack for this. The prepackaged code might need a lot of customization||Manufacturers of these modules usually are built with an entire ecosystem to support quicker integration with the hardware.
|Hardware BOM cost optimization is possible. As the RF engineering is done, economies of scale makes it extremely easy for you to take control of your hardware costs in future.||Hardware BOM cost optimization isn’t an option. You only get what you can bargain with the module manufacturer
But there’s more to module selection or custom RF engineering than that. For example, I would certainly want to look at the quality and range of the wireless solution I am building. From my experience this is the first thing that would fail your solution.
Note: Beware if you ever speak to a hardware manufacturer or a hardware design and development shop that says “The range would be 270m” and doesn’t provide any additional details.
Any range related claim for wireless communication has to be backed by 2 parameters:
- Antenna design
- Packet loss
The simplest and the most practical explanation of how range related claims can be measured with antenna design is your home’s Wifi. Your Wifi router is an amazing hardware piece, has external antennas to make sure that you get good reception in all directions.
But, if you move away from your Wifi (to a spot where you can see Wifi signal go down a bar or two), you will end up finding that the reception is not smooth enough on your mobile phone. For a few angles it would be as good as 100% signal, but for others it could go down to 20% of the signal strength. Now, think about a small device with embedded antenna, how good do you think a range related claim of “270 m” would stand this test?
If you want to experience this, download this app and see the results for yourself.
Packet loss data
Packet loss happens when the information that you are sending from your IoT hardware fails to reach its destination. When I usually get into IoT sensor network development, I always focus on creating packet loss reports that details with range of transmission. Believe me, when you combine antenna design considerations with packet loss data, then and only then you can say “Hey! You get this range with this design”.
This is a very simple but very important assessment for your IoT hardware development, I would recommend doing this with as much details as possible. Those above two factors and reports are solely listed just to make sure that you can be involved with the project even if you are not from embedded technology background.
So, we now have sensory unit, a processing unit, a wireless unit and a board to place all of them on it. Great progress if you have managed to read it so far.
Step #5: Your storage options for IoT hardware?
Storage options vary by what type of information you are looking to store and how you are looking to store them as well. I won’t go more deep into the subject but will walk you through the memory selection criterias that we have:
- Volatility – How long can you retain this data?
- MTP and OTP – Costs would vary when you go for MTP or OTP, with OTP being cost effective
- Flash memory – They bring in high degree of readout speed
- External Flash memory – They are low cost USB based external storage modules
There are others like DRAM, eMMC and UFS. But I am assuming that you are building a simpler microcontroller based product, so we won’t go through them.
Step #6: Power source
You have a couple of choices here on how to power your IoT product. I have written a very detailed blog post around this topic that you can read and understand power requirements and design considerations for your IoT device in extreme depths.
One thing that I pay close attention to while I am doing power related design work is that I tend to look at discharge profiles for batteries that are into consideration.
The next step in this analysis would be to calculate how long would your battery last by calculating the number of hours my device is going to be awake. If it is going to have sleep cycles, I would calculate the amount of energy I can save by keeping it in sleep states and what energy it would consume to spawn back into wake up state.
This leads to a near perfect calculation of battery consumption by device in wake up and sleep states.
An extremely complicated part of this assessment is to calculate how much battery would your wireless module is going to consume. This would require an entire book, but in a previous blog post I listed energy consumption specific to major IoT protocols.
Step #7: Input, output and debugging
What type of I/O type capabilities do you expect your device to have? This will be decided by the final features of your board.
A lot of product managers and IoT decision makers fail to consider this before building their hardware specs, only to realize later that their hardware can only talk in a certain way. I’ve seen some use cases where the IoT product came out with RS232 ports. That’s like an embedded device from 1990s. And, the thing is that it doesn’t has to be that difficult for you to be able to identify USB protocols, PLC integrations, etc.
Understand what physical connectivity options you need to ensure that your product remains agile, and the cost of upgradation in future remains low.
Step #8: Do you need Real Time Operating System?
There are two types of IoT hardware systems, one that should always work, others that should work. The difference between both of them is of reliability. You expect your airbags to always work, but you don’t expect the same from a non critical consumer IoT product.
Real time systems are specifically built to work 100%, if they don’t, they won’t be reliable. And the way we build these systems is by looking at whether the functionality should happen 100% of the time, or is 99.1% success is an acceptable rate here.
Step #9: Firmware development and everything that goes inside of it
Firmware development is something that a lot of people entering this field are not that familiar with. When you write a software that helps hardware components talk to each other, that’s called firmware.
There’s an entire history of firmware that I can get into, but that would be irrelevant to what I am going to walk you through here. I will save it for another future blog post.
But, let me give you a few examples that will get you a bit familiarized with how firmwares work.
Do you know how telephone lines work?
First a command called “AT” command is sent, after which an acknowledgement is received and then information is pushed through this telephone line. That is pretty much how we still communicate with hardware devices. Only thing that has changed these days is the fact that we don’t have write a lot of code on this front anymore, we have libraries that we can package into our solution and use it.
Something extremely similar happens when you put together electronic components. They pass on messages to each other, these messages are what makes your firmware. And this builds the foundation of your firmware. But here’s a list of things that firmware do in a typical IoT hardware:
- Handles real time/non real time information
- Builds interrupts
- Manages the storage your have
- Handles both digital and analog components
- Acts as a communicating interface
- Handles any mathematical calculation that needs to be done
- Handles error and generates logs
- Helps you with hardware troubleshooting and debugging
Great! So, you know now what your firmware is going to do on your IoT hardware. But IoT is extremely fragmented, and requires deep evaluation of hardware and software technology before you start firmware development.
I personally would start by establishing the choice of type and platform on which I am going to build my firmware.
Choice for firmware development
Firmware development can be done in three different ways:
- Build from scratch – If you are building an AI Robot
- Use Linux type distribution, would require significant know how of embedded technologies
- Use something even more finished like Android
A lot that have been working with hardware product engineering company like ours from last 10 years often find Android to be a very unorthodox choice. But if you have been reading what Google has done so far, it is pretty amazing. Even if you put that aside, Android makes it pretty easy for you to customize it, and build a firmware on top of it. A lot of IoT based predictive maintenance elevator systems in place these days are built on top of Android. It is quite amazing what they’ve been able to achieve without having to spending additional thousands hours on costly product development.
Define Firmware Architecture
I won’t go into firmware languages as now, but you would definitely want to keep a firmware language that gives you ease of management and testing for your IoT product.
If you are new to technology, you could possibly think of writing any software or firmware as a set of instruction in a file and then running it. That used be done way way back. That’s no longer a way in which modern softwares are run.
When we plan a firmware development, during the early stages (before we’ve written even a single line of code):
- We have a few concerns
- We have testability at the core
- We have to plan for performance
- We have to plan for easy maintenance and quick bux fixes without a major firmware overhaul
- We have code readability concerns – Everyone should be able to identify what a particular code piece does
In another blog post where I covered IoT hardware testing in details I gave an example of firmware testing. Let’s take the same example here. If you look closely, you would find that the hardware will have the following firmware modules in it
- BLE antenna
- Temperature sensor
- Humidity sensor
- Voltage regulator
- Data handling modules
- Integrity check modules
- Log aggregation modules
- OTA update module
This would look something like shown in the diagram below
The reason why I prefer to write firmwares in this way is because:
- I can independently diagnose what how well these parts of firmware are performing
- I can easily fix and update parts without having to break the entire firmware. And if you don’t create your firmware in a modular way, you are more likely to break something once you push updated firmware versions.
- It gets easy to maintain the entire firmware
- Modules have a single purpose, single responsibility. Hence if anyone other than your original developer wants to update the code, it would be easy for them to do so.
Applying filters for getting accurate sensor readings
When we extract information from sensors, we just don’t get a magical number like 100 F from a sensor. Instead what we get is human unreadable and often requires adjusting. But that’s not all what happens to you sensors, a motor running nearby could interfere with your sensor’s reading as well.
Applying Kalman filter
Fortunately in electronics industry we have been tackling such problems since last 2-3 decades. In such cases where we see anomalies get passed as real sensory values, we apply filters. On of the most commonly used filter is a Kalman filter where you can rely on last known sensory values to filter out any information that seems like an anomaly.
Here’s a representation of what a Kalman Filter looks like
Log creation and aggregation
While building your hardware do not underestimate the power of logs. They are an incredibly powerful tool for diagnosis and product quality refinement. If I had to personally diagnose a problem that could be anywhere between a hardware, wireless network and a cloud, I would end up wasting considerable time.
The thing about IoT product development is that you would end up diagnosing a lot more. Be it with your IoT prototypes or with your first, second batch of custom built hardware – testing and diagnosis is a norm.
Firmware testing and debugging
Testing is one of the most important factor that contributes towards a high quality IoT hardware. I am currently writing a detailed blog post on this, so, subscribe if you want to receive my blog post on QA guide for hardware startups that goes into extreme details of testing and debugging firmware.
Step #9: Generating BOM
Once you are done with listing all components a BOM is generated. This is one of the most critical part of your IoT product development.
Step #10: Layout and trace lines
Trace lines connect your components placed on your board to each other. If your IoT product is a bit simpler, you can simply get away with following these simpler rules:
- No two trace lines should be close enough to cause a short circuit
- Trace lines should have enough Copper (or whatever you are using) to make sure that it can withstand thermal stress
- They don’t cross each other
The third rule is so obvious, but for IoT product development scenarios where there’s no computer aided manufacturing, they are often a thing to come across.
If the you think your IoT product has a really high frequency of communication within some specific components, consider the following:
Minimize Skew – If this seems like something difficult to understand, think of two lines on an athletics track, the line closer to the centre has a smaller length. There are often two similar trace lines running in parallel often shorter in length, and here it causes something called Impedance. Not effectively dealing with this can generate opposition/resistance of a current flow to your components.
We usually apply specific design patterns to tackle these. The image below shows this best
There are two other trace level optimizations that we do in our circuits, check the images below for Delay optimization and Reduced signal reflections.
Step #11: IoT product dimensions and layout
We haven’t spoken about this, but PCBs can be multi layer as well. Even with just 10-13 components the effective surface area of your PCB can go as high as 10cm x 10 cm for best electrical characteristics and interference free product.
Imagine if each and every hardware around you is more than 10 cm x 10 cm. There was a time when this was a normal dimension for most hardware that we used to see(remember when TV remotes emerged from being just a clicker?).
What we do in this case is to split the components into multiple layers instead. This greatly reduces the overall size of your hardware product, but I would warn against the complexity and hardware design challenges it brings to the table.
Step #12: Testing your PCB
Once you have a PCB design ready with a firmware that performs exceptionally you should refrain from jumping into mass production just now.
You should rather order 20 manufactured PCBs in the first batch and 20 more in another batch after first batch’s testing and optimization.
After firmware testing you should test the following:
- RF communication
- Electrical characteristics
- Mechanical testing
- Thermal testing
- Water proofing
- Trace quality assessment
- And, Thread quality
Once you are through these testing phases you are almost done with PCB testing.
And, thats it! We are done understanding how to build an IoT hardware product. If you are looking for the exact IoT product development process that most go through, you should read through my IoT hardware product development blog post.
This alternative way of understanding has been extremely instrumental for people that are completely new to hardware development cycles and makes it extremely easy for everyone to understand.
If you have any feedback, or if you want to know something that I haven’t covered in this blog post, feel free to drop me an email at firstname.lastname@example.org.