The world is full of bright and creative ideas for innovative and useful products. Brilliant engineers and marketers are eager to bring these products customers who will purchase them and appreciate the way they enhance their lives. Today, these products are increasingly based on microprocessors or microcontrollers (MCUs) with creative combinations of peripherals and unique software. 

How is it, then, that so many innovative concepts fail to make it from an excited meeting room to an actual profit-making product? It turns out that there are reasons for this that can be identified and avoided to achieve success.

To begin with, it might seem straightforward to decide “what” to build based on market research and user input, especially for smaller companies that have a close relationship with their customers and a familiarity with specialized areas. 

But the “what” (a gizmo that does x) is often too general a concept when getting down to an actual device that interacts with the real world and costs actual dollars. Getting to the “what” does involve market research and input, but it also relies on an engineering team that knows what is involved technically as well as hard-nosed financial analysis to see what that path of possibility will cost. And since all projects contain certain unknowns, management must be flexible to deal with changes in plans and “gotchas” along the way — and have the ability to find the best way through implementing the maze of functions and components that are necessary for the device but not central to its application.

Smaller companies may be limited by their resources and willingness to take risks, and stick to areas they know when expanding their offerings – they can take advantage of less direct competition to support development and incremental improvement in their products. Larger companies, however, often opt for prototyping so that they can have a team look at a working early model to analyze it and understand it to make changes and work out bugs. Both approaches can be successful, but both are also subject to failure due to inattention to certain obstacles and mistaken assumptions about implementation.

To get started, it can be useful to filter a collection of ideas by subjecting them to a process called stage-gate to the considerations of market research, development and financial constraints to come out with the best contenders (Figure 1).  Although it isn’t used often, stage-gating can be very useful for smaller companies that might struggle a more rigorous approach.

Once such an idea has been selected it is time to get started on real development and avoid the pitfalls that lie along the way.

A Fictional Smart Device and Its Development Requirements

To demonstrate the issues many companies experience during product development, consider a hypothetical company working in an area where they already have some experience.

On entering the product specification stage (where the “what” has been selected in terms of a product specification aimed at a specific set of end users), the “what” turns out to have two aspects. These could be described as specifications of “what” it is supposed to do and “what” it is going to actually be as a physical device – or, in other words, what to do and how to get there.

The company settles on a small wearable device that includes a set of sensors to monitor body and environmental conditions, provides information and/or alarms to the user, and stores data in the cloud (Figure 2). It is billed as a first-of-its-kind device to be sold in volume and will use a Bluetooth 5 radio to connect to a smartphone containing one or more related apps. In turn, the smartphone communicates with cloud-based AI or data management apps, making the wearable an IoT device.

The wearable spends a good deal of time disconnected from the cloud, sensing, preprocessing, storing data, and providing immediate responses. Its local processing performance is limited by constraints on power consumption and the need for security and data storage (Figure 3).

So far, so good. From this specification comes a number of requirements, including:

• Hardware that can support both embedded processing and Bluetooth 5
• A suite of proven, reliable sensors
• Sensor fusion algorithms capable of combining multiple sensor outputs into a single result (Figure 4)
• Enough program memory for device software and firmware, as well as additional memory for storing data locally until it can be transmitted
• A USB interface and firmware over-the-air (FOTA) update capabilities for diagnostics, maintenance, and service
• A battery that provides sufficient capacity and adequate charging capability within a size and weight envelope that can be accommodated by the final design

Filling these requirements warrants careful consideration, and it is here that failures often begin.

Potholes on the Road to Success

Continuing our hypothetical example, a developer might decide that Wi-Fi is a better option than the USB service interface – except for the fact that Wi-Fi draws so much power that the device would require a bigger battery and more hardware support that result in more size, weight, and higher overall cost. It is far less costly and time consuming to avoid this mistake altogether rather than start down the path and have to turn back.

This caution is required in the selection of other hardware, too, especially the processor. A low-power microcontroller that can handle the limited programming and complexity of the device is preferable to a microprocessor that can simply be overkill in terms of size and power consumption. Finding parts with integrated functions can also go a long way to reducing cost, time to market, and dead ends in the development process, as an MCU with integrated Bluetooth 5 saves space and power versus using a discrete Bluetooth chip.

And, by all means, select parts that are known, pre-qualified, and, when appropriate, come with reliable driver software (such as sensors).

While prototyping is of course an important part of the development process, try to select an evaluation board with your selected processor rather than some embedded Linux board. The former can get you to a working, flexible design much more easily, but also give you a better idea of how components will come together in the final packaging.

Are versions of the MCU available that can be put into a very small package? Where will the battery and interfaces be located on/in the wearable device? Considering these questions early in the process helps avoid roadblocks that kill time to market, add huge costs, and ultimately kill products.

Finding the Safe Road for Software

One aspect of design that is rarely appreciated up front is the scope and volume of software required. There is, of course, the software that will run on the device (which is a topic unto itself), but also the applications (yes, Android and iOS versions) that will run on the smartphone, and cloud software that will be needed to improve the usability of the device. Decisions will need to be made on the development approach, look, and feel to make all of this software as reliable and consistent as possible. 

Super Loops, Spaghetti Code, and Real-Time Operating Systems

Developing software for an embedded processor can be a hazardous path if not plotted carefully. The temptation to write all the code from scratch can be deadly. For one thing, that entails coding all the support for peripherals, security, a file system, real-time clock, and more. That alone costs huge amounts of time, and means inevitable errors and debugging. Even then, it’s likely that the software will have bugs that remain undetected after deployment.

A frequent corollary to “writing it all from scratch” is the “super loop” approach. In a super loop, writing from scratch continues in the form of a single control loop that continuously polls the different peripherals for data and processes (Figure 4). Such a loop is easy to understand in its simplest form, but can quickly turn into a pile of spaghetti and become impossible to comprehend or maintain as it grows in functionality. Starting on this path will only take you further down it, and lead to developmental and financial disaster.

While platform-based development is almost a given for edge devices (i.e., the smartphone) and the cloud, it must be actively sought out, evaluated, and selected for embedded devices. From the start, this means using a real-time operating system (RTOS) that is specifically targeted at the MCU architecture used in the project (Figure 5). Using an RTOS delivers an instant platform that runs on the MCU and services interrupts from the peripherals as needed, offers ready-made I/O, and other basic functions. This alone supplies huge amounts of ready-made, tested, and often certified code onto which you can add unique functionality (value add). It also shortens time to market and assures code correctness at that level, which can be considered secure, tested, already integrated, complete, and efficient, overcoming all the limitations of the super loop approach.

An RTOS also enables more easy prototyping. In the sensor fusion example mentioned earlier, prototyping will help the developers understand what sensors are needed, which algorithms work best combining sensor outputs into a single quantity, and how well the chosen processor (presumably with fast multiply/accumulate (MAC) operation performance) is able to filter noise from the sensors. An RTOS with rich support for peripherals and prototyping boards based on a range of processors makes a powerful platform for full-on prototyping and development. A well-chosen RTOS can offer pre-tested device drivers; security functions; a file system; and support for a wide range of sensors, cameras, and radios.

Frameworks for Phones

When it comes to the edge devices (here, smartphones, but in other cases maybe PCs) there are also well-known operating systems such as Android and iOS, as well as robust programming languages and tools for smartphone development. One possible pitfall is divergence between functionality and user experience (such as user interface, etc.) on the two types of phones. Here, frameworks are available to help coordinate development.

Still, the cost of developing phone applications can be easily underestimated. Given that most products target both Android and iPhones, the decision to use a framework on the phone can be a tough one.  If separate development is done, an almost identical look and feel can be achieved but development cost and maintenance costs will be greater. With a framework, both applications can be maintained together, likely reducing costs but creating less flexible user interfaces.

Cloud Platforms Abstract Challenges, But Not All of Them

Fortunately, platforms such as IBM Watson IoT and Microsoft Azure offer a solid environment for developing cloud applications. They provide cloud/edge/device connectivity options, data management tools, and artificial intelligence (AI) frameworks that can analyze vast amounts of data and refine applications running on devices and edge systems (Figure 6).

Developing cloud software and the cloud platform itself can also be expensive. A rich environment and advanced cloud processing may require significant development, especially if the application requires sophisticated learning algorithms. 

AI requires a lot of raw, real-world data, which needs to be gathered, pre-processed to eliminate noise and clean the signals, processed again by deep-learning neural networks, and finally run either in the backend or moved to the edge.  Such AI processing can improve your product greatly, but is more difficult than you might think if you lack experience in algorithm development and/or are unfamiliar with using digital signal processing to clean the signals.  All of this is often underestimated in terms of time, risk, and total effort.  Start with simple analysis and grow your successes.

Time Saved is Money Earned

Without doubt, the most expensive aspect of product development is time — time taken re-engineering designs, testing components that could have been purchased pre-tested off-the-shelf, and fixing errors and bad decisions.

Market share is worth 10X to 1000X more than total development cost, and therefore time to market, quality, and reliability are more important than the comparatively little you save by engineering components in house.

One path to capturing market share as quickly as possible is by selecting an RTOS with the peripheral support and flexibility you need, as well as a processor that can make your product a true success.

Kim Rowe is CEO of RoweBots.