At first sight, it seems that the development of ‘hardware’ products hardly differs from that of Internet of Things devices. But it differs a lot.
Alex Pyshkin, the R&D Director of notAnotherOne, 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 engaged in the production of cell phones and smartphones, I developed a specific attitude towards 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 to take 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 come to the conclusion that IoT is a system of systems and it requires a corresponding methodology.
“System of systems is an integration of systems networked together for a certain period of time to achieve a specific higher goal within the framework of an integral system; with each system being independent and operable.”
Main criteria of IoT as a system of systems
An IoT product has its own specific features:
- Absence of a single product owner or someone responsible for the entire system.
- 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 as compared to other electronics.
For example, if a sensor embedded in a gyroscope in DevKit does not operate properly, at the output we will receive incorrect information on a product’s position in space.
4. More stringent safety requirements + multiple industry-specific requirements and standards.
The development involves representatives of different disciplines, from computer engineers to UX engineers, and teams need to interact with each other.
How to avoid typical failures during product development
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. It is crucial to use the same methodology in communications with the client, 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
This framework comprehensively describes the interaction between various teams. 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 quite hard to talk with the client using the available terminology.
MBSE, Model-Based System Engineering
This is also a quite comprehensive and well-developed methodology, which poses, however, a certain 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 easy 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 to identify the impact of particular domains on major elements. What is more, the framework draft can be adapted to one’s own 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 a separate item.
The “Build VS Buy VS Partner” concept
Below is the full cycle of a product’s development.
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, it is important for developers to assess how they will produce this device. They may assemble it from scratch, purchase the hardware and some modules, or enter into a partnership. Let’s conditionally call these competing approaches ‘Build vs. Buy vs. Partner.’
Decision-making matrix for ‘Build vs. Buy vs. Partner’
In order to choose the right approach, you should answer the following questions:
- For what parts exactly can your company bring value?
- Targeted business model: how are you going to earn money using this device?
- Available resources: manpower, expertise, funding, etc.
- Time to market: how quickly do you want to launch your device?
- Availability of ready-made solutions in the market.
- Intellectual property requirements.
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 important. If your device doesn’t have any rivals, there are good reasons to feel nervous. 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 the intellectual property associated with it, 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: Design of the device is likely to be the major novelty.
Hardware: Board is quite simple, and all operating principles are well-known, with nothing new invented.
Firmware: Firmware has been well-established as a result of 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 that it is capable of continuously reporting on soil moisture levels. Here, there is nothing new.
Cloud: Still, there is something to strive for, and it is not desirable to use Chinese proprietary cloud services. User experience can be improved by transferring data handling to one of the larger cloud providers.
Apps: In most cases, proprietary applications for sensors don’t have enhanced functionality or user-friendly interfaces; hence, this is another area for UX improvement.
Based on the analysis conducted, we may conclude that in the fields of industrial design, cloud services, and applications, we should build up processes either on our own or in partnership with large third-party vendors.
Decision-making matrix in the production cycle
Now, let’s once again return to the production cycle. Here, a decision-making matrix is added. Ideally, main decisions should be made parallel to the development of a product strategy as there is much overlapping.
This is how a matrix looks like:
Each component is itemized by decision-making areas. Namely, UX, data, business, technology and security.
UX in a decision-making matrix
The improvement of UX is the primary goal when launching a new device.
In order to understand the user’s needs, we have to build up a customized model and user persona. This term came to hardware from design. The user description contains a clear account of what objectives are achieved by the user 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.
- A casing and a strap shall be made of hypoallergenic rubber;
- Variable colors;
- Dust and moisture protection.
- Pulse rate and blood oxidation measurement;
- Light weight for convenient wearing on wrist;
- Measurement results displayed on the screen;
- At least one week of battery power capacity.
- Real-time data processing;
- Easy setting.
A list of requirements for firmware can be continued, based on key objectives and conditions of use.
- Continuous connectivity, preventing pulse rate or blood oxidation changes being missed.
- Other devices ensure connectivity without the use of a smartphone.
- Integration with third-party platforms, e.g., API of healthcare services;
- Data privacy;
- Storage of historical data, e.g. data is stored for up to a month.
- Applications for the main operating systems Android/iOS and
- Basic chart-plotting functions, a list of contacts for sending historical data.
Business in the decision-making matrix
When businesses are concerned, before proceeding to product development, a clear understanding of the following needs to be gained:
- What we will earn , i.e. monetisation;
- What we will spend. Here, it is worth paying attention to the ‘Buy VS Build VS Partner’ model.
Just 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 monetise your IoT device.
Below you can see the breakdown of the “Data” and “Technology” areas of decision-making.
Data in the decision-making matrix
Technology in a decision-making matrix
In conclusion, let’s briefly summarise 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/or 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. There are many risks starting 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 to realize 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 owner of the system. The latter should be able to assess how changes within one subsystem impact others.