Motorola accelerates NPI for its entire line of mobile phones

Motorola Mobility has been on the front line of innovation in the new product development process for decades. Designing and manufacturing multiple new phones every year on short timelines has necessitated a new round of innovation. With a focus on accelerating and reducing unnecessary inefficiencies in their development process, Motorola has partnered closely with Instrumental to become more competitive while continuing to deliver high quality products to their customers.

Motorola was an early pioneer in mobile – starting first with radios and the first generation of cellular phones – and has continued to be a leader in quality for their ambitious line of smartphones and tablets. The New Product Introduction (NPI) process developed at Motorola has been replicated and imitated at consumer electronics organizations around the world, and remains core to Motorola’s ability to continually bring great products to market at a rapid pace.

One of the core missions of the development process is to find small but critical issues as fast as possible.

For the last two decades, the industry standard for new issue discovery has been to send the design engineering team to the factory during development builds. For hours each day, engineers patrol the hundred meter assembly line trying to be in the right place at the right time to catch new issues. Once an issue is discovered (and a typical consumer electronic product may have tens or hundreds), a serious amount of effort is required to assess and address it. That effort involves late night phone conferences, requests for information via email, trips to the factory to put in days on the ground, extensive experiments, and in the most extreme cases, daily executive meetings to provide updates and visibility. Not to mention a lot of time and money.

As a leader in the consumer electronics space who set the foundation for today’s best practices in NPI, Motorola believed Instrumental technology was an opportunity to eliminate the cost and inefficiency of finding and resolving issues in development, while delivering an even better end product to their customers. With Instrumental, they sought to discover issues faster, strengthen quality control on the line, and streamline their issue response to deliver new products on demanding schedule timelines.

The first Motorola program that used Instrumental was a new mobile phone with an aggressively short schedule. The Motorola engineering team and Instrumental worked together to identify a handful of states of assembly that would show all of the key components of the product as it was built up. Less than three weeks later, Instrumental team members deployed the array of Instrumental inspection stations – which contained cameras, tunable lighting, and customized fixtures – onto Motorola’s development line in China. The setup, calibration, and training for all stations took only two days.

Instrumental is deployed at key stages of assembly to check for both known and unknown issues. These locations are places where traditional vision and human inspectors typically cannot provide value. Setup took less than two days.

On the first day of the DVT build, the Instrumental stations collected images of each unit running down the line. These images covered both sides of the PCB assembly, the bare enclosure, two stages of building into the enclosure, and many images of the exterior of the finished product. As soon as these images were collected, they were uploaded to Instrumental’s database, and immediately available in the Instrumental web application to Motorola engineers around the world. This complete data record is a key differentiator between Instrumental and traditional industrial vision systems, where the applications must be incredibly specific and the data remains trapped on the local machine in the factory, unavailable to the team.

The ability for every engineer on the team to see the complete data record of every unit built in our web application is a core differentiator of Instrumental.

As soon as the first 30 units from the build were available in the application, Motorola engineers could use Instrumental’s machine-learning algorithms to quickly and efficiently find new defects that they weren’t previously aware of. Instead of standing on the assembly line for hours, moving amongst a hundred assembly steps trying to be in the right place at the right time to identify something new, engineers could do a search of all of the units in seconds. Once a defect was found, with a few clicks, an engineer could setup an enduring Monitor, or test, that would check every subsequent unit for the same failure mode, and automatically sort the failures into neat collections where defect rates and trends are calculated in real-time.

The machine-learning methods that drive Instrumental technology also enable each Monitor to learn the difference between a typical and an anomalous unit. This makes it possible (and incredibly easy) to set up tests that can find unforeseen defects automatically– something traditional industrial vision systems cannot do.

Over the ensuing year as new development programs adopted Instrumental, Motorola engineers partnered closely with Instrumental to beta-test several new powerful features. At the end of the first program, Motorola was the first Instrumental customer to use Intercept – a version of Monitor that provides real-time pass or fail judgements directly on the line. Intercept uses edge-computing to enable judgements to be produced in seconds. Making any kind of test, Instrumental or otherwise, go live on the line is a nerve-wracking proposition: what if the test has a lot of false failures? Pre-validation of new tests is super easy with Instrumental. By leveraging the complete data record of every unit built, it’s possible to validate a test against historical data. This lets an engineer not only understand the false failure rate, but the even more elusive false pass rate. Over the next twelve months, the Motorola team evaluated several improved versions of Intercept, as the computation cycle time was reduced from seven seconds in the beta to less than two seconds today.

Motorola now uses an array of Instrumental stations on all of their mobile phone programs to monitor production at key stages of assembly. Leveraging Instrumental’s detection algorithms and the easy-to-use database of all images collected, Motorola can more quickly identify when and where issues arise. They can continually iterate on their process so that known and unknown manufacturing issues are resolved efficiently, and they can monitor those resolutions remotely with access to real-time trend data. With Instrumental’s web application, Motorola engineers are able to easily track failure rate trends and evaluate program-level risks – something that wasn’t possible before. With unprecedented visibility and traceability on their development lines, Motorola engineers spend less time figuring out what to fix, freeing them up to focus on implementing solutions that will delight their customers. As Wayne Morrison, Principal Staff Mechanical Engineer, put it, “[Instrumental] enables you to work smarter. Instead of doing disassembly, you can spend your time solving problems.”

Cell phone antennas can be very sensitive to all sorts of variation. Connectivity problems can occur when the antenna’s coax cable isn’t properly routed or grounded at regular intervals. Instrumental installed mirrors in this Station so that algorithms can check both the cable routing and the cable grounding.

Instrumental has inspected every development and pre-production unit on seven Motorola mobile phone products, with more planned. Instrumental’s machine-learning algorithms regularly identify dozens of unique and new issues on each program, and when combined with known issues the Motorola team is tracking, results in tens of live Intercept tests. Since these algorithms are so easy to use and to validate, Motorola usually has its first Intercept test running on a new program within a week of deployment.

Motorola highlights the following as the top benefits they receive from Instrumental:

Accelerated Failure Analysis

Motorola’s engineering team has praised Instrumental for making the failure analysis process faster and more efficient. Before Instrumental, failure analysis involved flying engineers or even entire teams to the factory or shipping units from the factory back to the engineers, both of which are slow and costly. Instead of tearing down units, which can sometimes obscure or damage the very evidence that engineers are looking for, engineers can use Instrumental to see the images taken of those units as they were built. Motorola shared with Instrumental that occasionally, there will be an important issue that is elusive – requiring a special experiment of 100 or even 500 units might be built – which consumes a lot of precious development time as well as expense. The camera lens design issue described in the previous section is an example of a type of issue that may have necessitated a costly experiment process. Instead, the optical engineer was able to quickly discover the root cause of the issue on his own. Dave Konczal, Director of NPI at Motorola said, “Instrumental reduces the number of experimental builds needed to validate our products during development – leading to a more streamlined development process.”

Faster Time to Stability in Ramp

While the US-based engineering team is responsible for developing the product, the China-based manufacturing team is responsible for taking the design and producing high quality products for customers. The transition from development to production is a stress test of all of the work the development team has done in the previous months. According to Lyon Wang, Director of Engineering and New Product Introductions at Motorola, “Programs that used Instrumental during development ramped faster than products that did not use it.” By finding issues early in development and relentlessly tracking them from build to build, the products have matured faster, resulting in significant cost savings in the early days of production on each program. He also mentioned that immediate feedback helps operators get up to speed faster because they can learn from their mistakes.