How to Create an IoT Device: Simple Rules for Hardware Startups

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.” Djamshidi, 2009

Main criteria of IoT as a system of systems

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

5. Multidisciplinarity.

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

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.

Methodology Selection

Industrial Internet Architecture framework

Source: Industrial Internet Consortium

MBSE, Model-Based System Engineering

IoT Decision Framework

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.

Source: Daniel Elizalde’s blog. The picture has been modified by the author

The “Build VS Buy VS Partner” concept

Hardware Product Development Cycle / notAnotherOne

Providing a higher-level presentation of this cycle, we will have the following outline:

Product development planning / notAnotherOne

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’

  • 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.

Preliminary analysis of IoT product / notAnotherOne

Let’s use the example of a plant watering sensor. This is a simple device with numerous consumer models.

ID/MD: The design of the device is likely to be a 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

IoT Decision Matrix in the Product Development Cycle / notAnotherOne

This is how a matrix looks like:

Source: Daniel Elizalde’s blog. The picture has been modified by the author

Each component is itemized by decision-making areas. Namely, UX, data, business, technology, and security.

UX in a decision-making matrix

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.

ID/MD design:

  • A casing and a strap shall be made of hypoallergenic rubber;
  • Variable colors;
  • Dust and moisture protection.

Hardware:

  • Pulse rate and blood oxidation measurement;
  • Lightweight for convenient wearing on the wrist;
  • Measurement results displayed on the screen;
  • At least one week of battery power capacity.

Firmware:

  • Real-time data processing;
  • Easy setting.

A list of requirements for firmware can be continued, based on key objectives and conditions of use.

Communications:

  • Continuous connectivity, preventing pulse rate or blood oxidation changes being missed.
  • Other devices ensure connectivity without the use of a smartphone.

Cloud:

  • 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.

Apps:

  • 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

  • What we will earn, i.e. monetization;
  • What we will spend. Here, it is worth paying attention to the ‘Buy VS Build VS Partner’ model.
IoT product development expenditures / notAnotherOne

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 monetize your IoT device.

Methods to monetize your IoT device / notAnotherOne

Below you can see the breakdown of the “Data” and “Technology” areas of decision-making.

Data in the decision-making matrix

Data in the decision-making matrix / notAnotherOne

Technology in a decision-making matrix

Technology in IoT Decision 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.

We help to transform IDEAS IN2 PRODUCTS. Industrial design, manufacturing, and passion for innovation. http://notanotherone.com/