At first sight, it seems that the development of ‘hardware’ products hardly differs from the Internet of Things devices. But it differs a lot.
Alex, the R&D Director of nao.design, shares his thoughts on whether there is a convenient and simple methodology for creating an IoT device.
After more than a decade of working at different companies that produced cell phones and smartphones, I developed a specific attitude toward IoT. The Internet of Things appeared simple and easy. I stuck with this attitude until my first IoT product. Originally we planned to spend six months taking it to mass production, but ultimately the project lasted eleven months. The delay and the challenges behind it led me to reflect on the process and search for answers: how do IoT devices differ from other hardware? Are there any tried-and-tested development approaches and methods? Sorting out various techniques, I have concluded that IoT is a system of systems that requires a corresponding methodology.
“System of systems is an integration of systems networked together for a certain period to achieve a specific higher goal within the framework of an integral system, with each system being independent and operable.” Djamshidi, 2009
An IoT product has its own specific features:
1. Absence of a single product owner or someone responsible for the entire system.
2. A device must add value — no one will pay for a device or a subscription for a service if:
• a device or a service does not function properly;
• it does not bring value to the user’s life or work;
• it makes the user constantly think of and care for the device; or
• it doesn’t integrate smoothly into the user’s everyday life.
3. Complexity, the cost of an error, and dependencies have increased several-fold compared to other electronics.
For example, if a sensor embedded in a gyroscope in DevKit does not operate properly, we will receive incorrect information on a product’s position in space at the output.
4. More stringent safety requirements + multiple industry-specific requirements and standards.
5. Multidisciplinarity.
The development involves representatives of different disciplines, from computer engineers to UX engineers, and teams need to interact with each other.
As we already found out, we deal with the system of systems. Considering its complexity, a product team should have a new team member – a system engineer who will control all the systems and the interactions between them. Moreover, there should be product owners for separate subsystems (cloud, hardware, applications, etc.)
Another approach assumes the selection of a particular methodology, according to which information is shared, risks are assessed, and decisions are made. Using the same methodology in communications with the client is crucial so that you speak a common language. At the same time, it is important not to dwell upon technical details and to communicate information as simply as possible.
Industrial Internet Architecture framework
comprehensively describes various teams' interactions. The core problem is that it doesn’t cover some subject-specific domains, and doesn't have a focus on design. Plus within this framework, it is pretty hard to talk with the client using the available terminology.
MBSE, Model-Based System Engineering
This comprehensive and well-developed methodology poses a particular technical difficulty to non-IT experts. It involves recommended bonds in the form of UMD + TODEF and other highly field-specific applications, which are hard to use, as far as the external client is concerned.
IoT Decision Framework
This is a comparably simple and accessible framework. It was first described by Daniel Elizalde, a prominent professional in the IoT Product Development field who also writes about the Industrial Internet of Things (IIoT).
The primary objective is to decompose key components and identify particular domains' impact on significant elements. Moreover, the framework draft can be adapted to one’s needs.
For example, an author has not distinguished the ID/MD stages, i.e. the development of industrial design and that of a mechanical structure as parts of the entire development. Therefore, I have set out these stages as separate items.
Below is a product’s development cycle.
Providing a higher-level presentation of this cycle, we will have the following outline:
The first stage involves research, i.e. product analysis, competition analysis, feature analysis, and workup. At this stage, developers must assess how they will produce this device. They may assemble it from scratch, purchase the hardware and some modules, or enter a partnership. Suppose these competing approaches are ‘Build vs. Buy vs. Partner.’
To choose the correct method, answer the following questions:
If you want to launch a product in the shortest term, let’s say, within several months, you should look for a ready-made solution. However, if you are contemplating full-fledged development, it will take six to ten months.
The market availability of ready-made solutions with sought-for functions is also essential. There are good reasons to feel nervous if your device has no rivals. It means that your research and competition analysis was conducted negligently or your niche is not that attractive. In this case, it’s worth reconsidering the viability of your idea.
If you want to own a product and all its intellectual property, e.g., firmware source codes, tooling, software source codes, etc., it is better to create a product from scratch.
Let’s use the example of a plant watering sensor. This is a simple device with numerous consumer models.
ID/MD: The device's design will likely be a significant novelty.
Hardware: The board is quite simple, and all operating principles are well-known, with nothing new invented.
Firmware: Firmware has been well-established due to countless releases and updates, and all hard knocks have already been taken.
Communications: In terms of data transmission, a device is likely to work with Habr, so it can continuously report on soil moisture levels. Here, there is nothing new.
Cloud: Still, there is something to strive for, and using Chinese proprietary cloud services is not desirable.
User experience can be improved by transferring data handling to one of the larger cloud providers.
Apps: In most cases, proprietary sensor applications don’t have enhanced functionality or user-friendly interfaces; hence, this is another area for UX improvement.
Based on the analysis conducted, in industrial design, cloud services, and applications, we should build up processes on our own or in partnership with prominent third-party vendors.
Now, let’s return to the production cycle again. Here, a decision-making matrix is added. Ideally, significant decisions should be made parallel to developing a product strategy, as there is much overlapping.
This is what a matrix looks like
Decision-making areas itemize each component. Namely, UX, data, business, technology and security.
The improvement of UX is the primary goal when launching a new device.
We must build up a customized model and persona to understand the user's needs. This term came to hardware from design. The user description contains a clear account of what objectives the user achieves when using your device.
Now let’s see how UX influences the decision-making process at each development stage, using a heart rate bracelet as an example.
ID/MD design:
Hardware:
Firmware:
A list of requirements for firmware can be continued, based on key objectives and conditions of use.
Communications:
Cloud:
Apps:
When enterprises are concerned, before proceeding to product development, a clear understanding of the following needs to be gained:
.jpg)
A short comment regarding the ID/MD/Hardware expenses: all of them are compulsory if you want to create your own product. The only optional item is a design patent. Many opt not to spend several thousand dollars. We advocate patenting since IP theft has become commonplace.
Below is an illustration showing how to monetize your IoT device.
.jpg)
Below is the breakdown of the “Data” and “Technology” areas of decision-making.
In conclusion, let’s briefly summarize what was written:
1. An early and comprehensive study of the project significantly reduces risks at later stages;
2. IoT is all about partnerships. You should not reinvent the wheel if you doubt whether you will be able to surpass existing solutions in terms of functionality and cost.
This applies to hardware and software modules;
3. Prepare a working scenario for when the device's performance is minimally dependent on the network, third-party services, and cloud;
4. Begin with the worst-case scenario. Many risks start from a complete termination of the service by your partner to failure of the cloud infrastructure from your side. In this case, the device must perform the main functionality offline. Unfortunately, this is impossible for all categories of devices. However, you should strive to achieve this when possible;
5. Ideally, your team should have a product owner for each subsystem (HW, SW, ID / MD) and the system's owner. The latter should be able to assess how changes within one subsystem impact others.
