Don’t Launch Late! Four Ways to Reduce Risk in Connected Device Development
Launching nine to 12 months late can cost a project up to 50 percent of its potential revenues. Here’s how we reduce technical risks to keep connected device development on track.
Don’t Launch Late! Four Ways to Reduce Risk in Connected Device Development
One of the biggest challenges associated with connected device development is getting to market on time. According to PMI’s Pulse of the Profession 2019, as many as 40 to 60 percent of Internet of Things (IoT) projects fail to meet their launch date, and the impact of falling behind can be extreme.
Launching nine to 12 months late can cost a project up to 50 percent of its potential revenues. Being late to the market gives competitors more time to move in, so it can lead to a smaller market share. And often, when a team starts to fall behind, they become so focused on prioritizing technical risks that they lose sight of customer needs.
Launching nine to 12 months late can cost a project up to 50 percent of its potential revenues.
So how do we reduce technical risks to keep connected device development on track? How do we provide the time required to develop customer-driven features?
Delve, we focus on these four areas:
1: Consider Connectivity Part Selection
Your first opportunity to reduce technical risk is during part selection in the initial development phase. You’ll need to decide how your IoT device will connect and consider whether you will benefit from using a pre-certified RF module or a chip-down design.
When to Use a Pre-Certified RF Module
An RF module (short for radio-frequency module) is a sub-assembly within a PCBA (printed circuit board assembly). It comes with the required circuits and components for transmission and/or reception of RF energy, like WiFi or Bluetooth.
If you don’t have a lot of RF experience and need to get to market quickly, pre-certified RF modules can help shorten development time. They reduce certification costs and come with an FCC ID.
Generally, we recommend using pre-certified RF modules if time to market is important to the success of the product; you expect annual volumes less than 15,000; and/or you don’t have the time or expertise to manage additional supply chain logistics. This approach allows you to focus your energy on strengthening the product instead of improving the RF performance.
When to Choose Chip-Down Design
If you have RF experience, you might consider chip-down design, which offers antenna flexibility and reduced unit cost. The tradeoff is that the chip-down approach requires more time for development. You’ll have to sort out the supply chain, and you’ll have to build in at least four to six weeks to get approved for an FCC ID.
Should You Design or Buy That Component?
More often than not, designing your cool new product relies on some new widget - but you’re not sure if you should design your own or buy one from a supplier. Six tests offer a straightforward framework for deciding whether you should design or buy that component.
We suggest chip-down design if your annual volumes are greater than 15,000, or if the need for reduced cost of goods outweighs time to market. Typically chip-down design requires an additional six to 12 months to launch, but in the long term, you might see a benefit to having more control over the design process and reduced unit costs.
When To Choose the Blended Approach
To make things a bit more complicated, you could also opt for a blended approach.
If you’re trying to get to market quickly but you also expect a high annual volume, you might consider an initial first run using a pre-certified RF module. Then, you can build a second generation device with the chip-down approach.
This way, you capture both the time-to-market and long-term cost of goods benefits.
2: Prioritize Development Testing
Once you’ve selected your parts, it’s important to test early and often — even if you’re using a pre-certified RF module. Development testing will help inform design decisions and reduce the risk of product launch delays. The earlier you fail a test, the earlier you can learn from it and adapt.
What you don’t want is to push off hardware testing. In connected device development, most hardware changes are going to take four to six weeks, and then you’ll have to schedule additional testing. Before you know it, you’re already three months behind schedule.
The earlier you fail a test, the earlier you can learn from it and adapt.
Does this sound familiar?: “We’ve only made minor changes — what could go wrong?” Or, “The module is already certified; we don’t need to be concerned.”
Don’t fall into this trap of letting overconfidence drive decision-making around critical testing that could potentially have large scheduling impacts. Don’t gamble by delaying tests to maintain design schedules.
Early on, identify tests with higher impacts on your schedule. People often overlook environmental and FCC testing, as well as the certifications required to sell in different global markets. Ask yourself, what is the impact of not passing a test? Can you afford another costly hardware iteration? Do you have time to secure a spot at a testing facility if you need to retest?
Need for Speed: Approaches to picking up the pace of development
There are several methodologies available to speed up the development process. Which best fits your needs?
We recommend scheduling critical pre-screen testing for at-risk testing activities. This will help you front-load learnings, allow you to include design changes into planned iterations, and avoid costly launch impacts.
Bottom line: If a test might require a hardware change, it should be prioritized.
3: Architect Provisioning Early
In connected device development, it’s important to lay out your path to connectivity early. Architecting the touchpoints and handshakes at an early stage can reduce headaches as components march toward production. How are you going to get your device connected? WiFi, Bluetooth, LoRa, Cellular? And what are the security implications of that connection?
How will your device verify that the server it’s communicating with is correct? And how will the server know the device is who it claims to be?
Architecting the touchpoints and handshakes at an early stage can reduce headaches as components march toward production.
Options include CA certificates, X.509 certificates, and private keys. You’ll have to sort out where, how, and when those certificates are flashed to your device. Will you need hardware components, like EEPROM or ECC608, to securely store certificates? Or will you use cloud-based storage options like AWS Key Management Service?
Keep the factory’s capabilities in mind, too. Does your factory have the connectivity and bandwidth to flash certificates to your device? A lot of factories, even in the U.S., experience outages. Are you able to react if the factory goes offline?
4: Plan for Production Testing
It’s a good idea to integrate production testing into your manufacturing plan to ensure product quality throughout the entire life cycle. The earlier you catch problems in the production cycle, the earlier you can rework issues and the cheaper it is to fix them.
You’ll want to define a control plan that fits the product’s volume and technical risks. There are three testing fixtures to plan for in connected device development: in-circuit testing (ICT), functional circuit test (FCT), and final test.
In-Circuit Testing (PCBA)
ICT is your PCBA-level testing, and it’s often referred to as “bed of nails.” This is your first line of defense, as it prevents you from sending bad goods into your pipeline.
Ideally, ICT can be done at the vendor’s location to avoid the cost of shipping components back and forth. One thing to keep in mind is that you don’t want to put test points everywhere. Too many can impact RF circuits and sensors, but you’ll need enough coverage to find errors.
Functional Circuit Test (Sub-Assemblies)
The functional circuit test (FCT) is meant to test your sub-assemblies and ensure that core features work as expected. It will likely be your least expensive test to implement.
FCT does require firmware to test electro-mechanical interfaces, but you’re only going to test high-risk functions. You might have multiple FCTs on a production line, but if you have a low-volume, you might be able to get away with FCT as your final test.
Final Test (Final Assembly)
Your final test puts the bow on the finished product. It will ensure that the product is programmed and feature-ready. Here you’ll load customer-facing firmware and complete the serialization process.This is a better fit for higher-volume product lines, given that it’s more expensive to implement.
Balancing Volume and Technical Risks
When you’re planning your production tests, consider the project’s volume and complexity.
Low-complexity, low-volume products can often use FCTs to control quality. High-volume products or products with complex supply chains should implement ICTs, FCTs and final tests. High-complexity, low-volume products could use ICTs and FCTs.
Product Engineering Services at Delve
From concept to manufacturing, our engineering services can get your products to market.
Plan to Mitigate Risks
You can reduce long-term costs and delays by carefully planning how you’ll connect your IoT device and by prioritizing development and production testing.
A solid development and manufacturing plan may require a little more work upfront, but that cost is always less than the impact of delayed products and unsatisfied customers.
Learn more about Product Development Engineering Services from Delve.
