Over the years IoT market has been flooded with various solutions, devices, and inventions. Many companies have been trying their hand at developing their own piece of hardware. Nowadays it’s fairly easy to develop a desired product that works, but it is much harder to keep updating it and making it relevant on the market the whole time.
While the first development process is pretty straightforward, updating the IoT device brings various challenges. Some are easy to resolve, like replacing a defective part or adding sensors to provide more customer data. Others are harder, such as post-update data type conflicts or high power consumption when battery changes aren’t possible.
These challenges can be avoided, but it requires proper planning and forward thinking beforehand. All stages of development are important, and approaching any of them should be done respectfully. But it’s not that easy for a new company to know about every possible problem that comes with updating the product, and they often make the same mistakes.
Why is evolving IoT device harder than setting up new ones?
When it comes to IoT device, every change can bring bugs, incompatibility, or even a problem with a lack of power. After all, experience is one of the keys to success, and it needs to be earned.
When designing from scratch, the primary challenge is simply making the device work. You can solve this by redesigning, sourcing different parts, or replacing the board. And such changes are easy because there is no compatibility problem at this point. The device is not yet published, so changing the communication protocol won’t harm anyone.
On the other hand, if a product has been on the market and is now receiving an update, there are many things that need to be considered. Compatibility is one of them. It’s not a good idea to change the MQTT protocol to CoAP, because it simply offers something else. Existing customers may be unable or unwilling to change infrastructure for a single device update. Furthermore, while design flaws are endless, many are avoidable by following a “common mistakes” checklist.
Choosing IoT communication protocols
While this decision is often made while creating the first version of the IoT device, it shouldn’t be changed afterwards. But not every device connects to an external system at the start. Some products can show the potential to collect data after releasing the first version. Then updating it with a communication protocol is not an easy challenge. First of all, there has to be a question of where the product is used. Also, the power consumption and method of operation have to be considered.Using the most advanced communication protocol isn’t always best just because it offers more features. Since protocols must remain consistent through future updates, defining the device’s long-term direction is crucial. This can’t be rushed, and if done correctly, it will save a lot of trouble in the future.
Edge vs Cloud
This step is really important as it can define the category of the IoT device. And while it is possible, and not really that rare, for companies to move towards cloud solutions, it is not always the best idea. Hardware choices depend on whether the previous device version already used specific connection protocols. If data operations require low computing power, using the cloud may be overkill and increase latency.
On the other hand, if the device is set to be a small-sized one, edge solutions can cause a problem of overheating. More powerful computing components need a better cooling system, but these often make the device bigger, which can be a problem.
Also, if the product is set to run on Zigbee, for example, the customer needs a gateway, and if they haven’t got one, they will look to purchase one from the same place as the device, so such products should be in the offer as well.
Designing without an OTA (Over-the-Air) update
The one thing that can make a solid product marked as a bad one is a bug. And even the best testers can sometimes overlook some of them, just because they test the product in a way it is intended to be used. But the users are unpredictable and can try many things that wouldn’t come to mind in the development process. But luckily the bugs can be fixed with an update. The problem emerges when there are no ways to do an OTA.
It’s not desirable to have a team of technicians who go from one client to another and do the updates locally on each device. Of course, there are some exceptions, especially when the product is set in a localisation where security has to be top-notch, or that operates on an intranet. Then it is often stated in terms that such updates, done by hand, have to be done.
The biggest flaw occurs when the device has an internet connection but is incapable of receiving an update. There is either no connection tunnel directly to the developers or no platform that allows users to do the update themselves. Or to do an update, a certain level of understanding of the technology is necessary. If the product is for engineers or technicians, then it can be omitted, but if it is for a wide variety of customers, then it can simply surpass their abilities.
Ignoring security
This is often an overlooked mistake, as people tend to care more about security after something bad happens. It’s foolish to think that security comes with secondary importance. But sadly, that is often the case. Security must be a priority when devices handle private owner data or sensitive technical information. This protection cannot be overlooked, as it is mandatory for any modern update. Security breaches do more than break customer trust; they often carry serious legal consequences. Even without legal issues, a company’s reputation crumbles quickly if an updated device has vulnerabilities.
There is also a matter of devices that are managed by the system to which they are connected. If no authentication or blockade works after connecting to one external device, then all it takes for another person to have control over the IoT product is just to connect to it. That may sound ridiculous, but it can really be an oversight. Especially when, in between the updates, only some options triggered remotely are added.
Overlooking battery life
This may come from a wide range of updates. For example, the battery life has been calculated in an idle state. Or maybe not even idle, but with a small system load. Or at room temperature, when a device can be used outside. Battery life can shorten fairly quickly under circumstances in which the device is used. And when new components are added, they can make the battery usage exponentially higher.
Nowadays, people tend to have more products that need to be charged daily or every two to three days. They also often come with different chargers, so when they have to buy another device, they don’t want to make more space for another electrical outlet. The amount of power that is needed to recharge such a product also becomes a concern.
Alternatively, using a replaceable battery requires a quick, tool-free method for swapping or destroying the device. If an update makes the original battery insufficient, a larger replacement might become necessary. However, switching to a replaceable battery often requires a complete device redesign. This ensures the hardware meets the specific power and access requirements mentioned earlier.
Component obsolescence
One way of upgrading the device is to add some new attachable components. The problem that it brings is the obsolete components of the main product. Some older tech used inside might be good enough to run the whole system, but might create a bottleneck when they have to work with something new attached to them.
Another problem that might be overlooked while designing an updated version of an older device is the availability of the components that haven’t changed. They might still be efficient enough to make everything run quite smoothly, so they weren’t changed. But when the project has been set for production, it turns out that they are no longer made. This delays the process by a high amount of time, as now the research for a new part that is compatible, fitting and for the same amount of money has to be conducted.
Law, regulation, and compliance
When looking at the regulations while designing a first product is easy, making changes to it under the influence of changed regulations can become a real problem. Sometimes, the only way to adjust a device to the new rules means complete redesign. If the regulations concern power consumption or the amount of noise some devices can make in the desired environment, then it’s hard to talk about adding some new functionalities. When the previous versions are not meeting such requirements in the first place.
The best practice here is not to make an IoT device that barely meets the requirements of present regulations or laws. Instead, always include a safety margin for future changes. This margin allows time to develop optimized versions while continuing to sell existing stock under new laws.
Another challenge comes from extending distribution. While the first version of the device was created for a local market, an updated one may be set internationally. This brings various countries’ laws into the discussion, which cannot be skipped. Neglecting this can lead to countries closing their markets or high financial penalties if it turns out the device hasn’t met local requirements.
It is generally good to keep up with all planned changes in regulations; even if they don’t make it through completely, some elements could still be applied. MedTech is a sector where regulations are strict and cannot be overlooked. There can’t be any concerns about the legality of the developed devices. There are specific tests that must be completed to let a new product be used in a wide market. If the device doesn’t meet them and is not compliant, the consequences for the company are severe.
Conclusion
While there are many various challenges when it comes to designing an updated version of an IoT device, they can be overcome. All it takes is to simply remember them. They are connected to each other in most cases. It’s easy to forget about one because the other has been resolved. But it’s always better to simply do a checklist or once again go through it to be certain than to have a problem later on.
Money is time and wasting time is never profitable. Also even the best idea can be ruined by a small oversight. Everyone wants their device to be the best but the line between the best and total flop is thin and only good planning and caution can prevent it from crossing it.
