Darrel Baker

“How much does it cost to build one of these?” It depends…

When an aerospace customer needs a new printed circuit assembly built for a legacy system, invariably their first question is “how much will it cost?” Building a new assembly can be relatively straightforward—or impossible—to accomplish. It depends. Is it build-to-print? Assuming the engineering dataset is complete, and you can wrestle it to the ground, build-to-print can be cost-effective. Reverse engineering, or reproducing the engineering data set and getting regulatory acceptance, is by far the costlier path. Here I’ll address some of the challenges of build-to-print for legacy circuits.



Click to view the Build-to-Print Flowchart

Click to view the Build-to-Print Flowchart

New Old Stock. The first consideration is whether the components called out in the drawing package are still available. And make sure the available stock is actually new, as in never been used, because refurbished old stock will not pass muster. If the components aren’t available, in many cases the drawing package may have notes about acceptable substitutions for parts. If these aren’t available either, you’ll have to find a cross-referenced part or build new original parts.

Cross-Referencing Old to New Parts. In some cases, the component industry has already provided the acceptable engineering data to cross reference old components to new. For example, resistor manufacturers have already produced the necessary engineering information for industry to accept modern metal film resistors in place of legacy carbon composition.

New Original Parts. For out-of-stock active components, the original dies may exist and can be used to produce new components in the original package. Rochester Electronics is good example of a firm that can produce new parts from original dies, or in some cases produce new dies from the engineering dataset. While the cost of a short run of parts may be high, it still may be cheaper than a significant redesign in order to accommodate current generation parts.

Component Certificates. What is the strategy for components that lack OEM certificates? Unfortunately, many NOS parts don’t have the original manufacturer certificates. In this case a certificate can usually be produced by a component testing lab. In some conditions, environmentally testing the printed circuit assembly utilizing these components may be an acceptable alternative and more representative validation of its intended use.

Minimum Order Quantities (MOQ). Even though there may be new old stock available, and you can get certificates produced, it may have unacceptable minimum quantities. If so, you’re back to cross-referencing or building new original parts.

PCB Fabrication. In some cases, Gerber files do not exist and film is all that’s available. Is the PCB film in serviceable quality? Even so, old film probably isn’t compatible with current fab equipment. You’ll have to digitize the film to produce usable Gerber files for fabrication of the PCB. You’ll also want to check the fabrication processes called out in the drawing package. For example, is the conformal coating process called for in the drawing still in use today? If not, you’ll have to use current accepted fabrication processes and get a waiver from the DER (Designated Engineering Representative).

Surface Finishes. Here’s an additional challenge. Modern component finishes are almost universally Pb-free. So tin whisker mitigation strategies should be employed as it introduces a failure mode not anticipated in the original design engineering activities. One solution can be re-plating Pb-free component pin surfaces with tin lead.

Test and Burn-In. Most printed circuit assemblies originally required a functional test fixture designed and built by the OEM for functional testing of completed PCAs. If this equipment exists and is in serviceable condition, testing can be accomplished in straight forward manner. Otherwise the drawing package for the test fixture must be acquired and the fixture built.

So how much will it cost to produce a legacy PCA? It depends… on how successfully these build-to-print challenges can be addressed. If you can’t wrestle build-to-print to the ground, you may end up taking the reverse engineering path. I’ll address those challenges next time.

Richard Lundin

I had a conversation with a potential client several months ago about doing a redesign of their newly introduced product. Since they were not reengaging the initial design firm, I asked why. Their reasoning in short was that the product did not behave as they expected it to under changing conditions external to their product, and thought the design firm should have designed for that. I asked what the product specification called for under those circumstances and was asked “what is a product specification?” That answer said it all; the process went wrong at the beginning.

That’s not to say that starting with a napkin sketch won’t work, but a clear and detailed product specification is the mainstay of a successful product design. It saves development time, money, and can ultimately serve as a guide for marketing by pointing out how the product or device differs from competitor versions, or the company’s past models. Within the product specification the client and the design company agree on what a perfect iteration of the product will look like, what it can withstand from an environmental standpoint, how it will perform under ideal conditions, and how it will perform when conditions are less than ideal.

Use case discussions are invaluable in identifying how a new product should behave when the customer uses it as envisioned and more importantly, when they do not. If it’s a connected device, what happens when the connection is lost, for what period of time, and how does that effect power management if that’s a critical design element? A well thought out product specification will not only capture initial design goals, it will help reduce unexpected outcomes in the design.

In short, a product specification paves the way for a focused design effort that is cost effective and efficient. Pay for the product specification. You’ll spend a lot less time re-working a design you thought was ready for release.

Barbara Stilwell Baker

Mixed-discipline teams are key to complex product development. I wrote about this more than twenty years ago, and it’s still true today.

In my behind-the-scenes role at Stilwell Baker, I don’t often go to customer’s sites. But recently I had the opportunity to join the field trial for a new prototype we’re developing. This project is what we call a “rescue.” Our customer’s previous attempt to develop this product (with another company) failed because they didn’t have the diverse expertise necessary for a complex design.

This is a great project for Stilwell Baker because of the diverse skill sets and deep technical knowledge required to resolve the design issues. The high voltage and digital control circuitry required a complex blend of hardware, firmware, and mechanical engineering all working concurrently in support of each other to meet the product goal.

I watched with curiosity and pride as our engineers melded seamlessly with the customer’s field service technicians. We applied solid theoretical knowledge; while they brought the real world application. They asked how far we could go; we told them the limits as defined by safety standards. They showed us challenges they face in the field, and we changed the firmware to accommodate their needs. Throughout the field trial I enjoyed the warm camaraderie and good-natured teasing:

Customer: what output would you expect in a different installation?
Fred: I’ve done those calculations. I’ll send you a report.
Customer: Aw, we don’t want a report—give us a guess. Why can’t engineers just guess?! C’mon, Fred, guess!

 The benefit of deploying a mixed-discipline team of principal and senior engineers to solve a complex series of problems is a field trial that couldn’t have gone much better. By the Customer’s measure, our prototype exceeded their most optimistic expectations. For Stilwell Baker, the prototype performed as designed—and the minor issues raised were already addressed and designed into the pilot units!

Customer: Did you really expect the prototype unit to perform this well in this demanding installation?
Fred: Well, yeah!

Richard Lundin

Problems that stem from using a single-source supply chain combined with the lack of Intellectual Property (IP) ownership were recurring themes during my visit to a U.S. Military depot last month. During a half hour briefing I attended, the brass made two things clear to department heads and visiting suppliers. First and foremost was a clear directive to buy the IP rights when paying for development of an engineered product or a weapons system. The second was to obtain more than one source for a service or part.

Sole sourcing without purchasing the IP saved money for the military in the late 20th century. But the decision has come back to haunt them. They are paying millions for reverse engineering because they don’t have access to the IP, or the production files of aging devices and systems that they still need.

Private industry could take a lesson from this U.S. government epiphany; get a second source for those parts before you need them, and make sure you own the IP. Although you will probably source a low volume part through a single supplier, identifying and qualifying an alternative manufacturing chain could save your business in the long run.

I have talked with a number of private companies over the last few years that, for one reason or another, have added a third variable to the single sourcing dilemma. These not-so-small companies have single-sourced their product engineering and production management to companies that are actually just one or two people working part time out of a garage. I’ve also learned that the decision to use a mom & pop shop is generally driven by cost. While this may save money initially, and let me lean heavily on the may, it also leaves your company vulnerable from a product availability standpoint. How long can your company do business without the product you now source from those nice folks: a month, a quarter, or a year?

If you own the production files and IP, you can begin manufacturing with a new resource fairly rapidly depending on parts availability and the complexity of the printed circuit board. Yes, you will pay more for a professional engineering group, their expertise, and resources. The IP rights will cost as well, but in the long term your company will have the flexibility to manage your critical supply chain and meet your customers’ needs.

Brian Terhune

Outsourcing product development can make any OEM nervous. All of us with experience in the field have seen first-hand what happens when outsourcing goes wrong—higher costs and time-to-market delays reduce sales volume, lower profitability, and shorten product life cycle.

In a perfect world, OEM project managers communicate their general product requirements to the development partner and establish a collaborative relationship with them. Both parties work together to define the exact requirements for the new product, and the development partner demonstrates the capability to execute.

But this thirty-thousand-foot view makes outsourcing product development sound easier than it really is. In the real world, projects stall due to a myriad of problems such as:

  • Vague or conflicting product requirements
  • Design solutions that fail to perform as expected
  • Processes that don’t include validation and functional testing

Understanding why outsourcing problems arise—and knowing how to prevent them—takes experience. This article will focus on recognizing the underlying issues that cause development problems and look at ways to mitigate the risks.

Remove the Guesswork, Remove the Risk

Product development issues manifest in many ways, and a few of the more common examples include: System interfaces aren’t well defined. Firmware features are improperly implemented. Components or subsystems do not meet required performance. Any of these can result in additional development cost or increased time to market.


To avoid problems in the first place, begin by recognizing vulnerability in three key areas:

  1. Product requirements
  2. Technology application
  3. Development practices

When you evaluate prospective product development resources with these three areas in mind, you improve your chances of finding a partner able to deliver the right product for you.

1.      Understand and Agree on Product Requirements

There can be no ambiguity when it comes to product requirements. It’s critical that you first agree, in detail, what it is your development team will design. They must be able to leverage experience and challenge your product requirements when appropriate. For example, if you have a requirement that will create issues with electromagnetic interference (EMI), you want a development partner able to suggest a design change that will eliminate the problem.

Identifying issues like this empowers the development team to dig deeper. Sure, they’ll document the overall architecture, but they’ll also team with you to evaluate expectations for individual components, environmental requirements, types of testing, and required certifications. Good communication eliminates the unknown and puts everyone on the same page, working toward the same goals.

Unknowns create uncertainty about costs, deadlines, and functionality. If you do not define and agree on product requirements, how can you be sure your development partner possesses capabilities necessary to complete the project on time and on budget? How do you know when you’re done?

The Product Development Balancing Act

When an OEM requests new product features after agreement on the detailed requirements has been reached, the product development team must perform a balancing act. It needs to weigh the benefits of the new feature against the potential impact on cost, timing, testing, production, and profitability of the product. You want a development partner brave enough to communicate the realities of these changes to you.

When the development team works with the OEM to establish definite, detailed product requirements and specifications at the outset, it removes the guesswork—and therefore risks—associated with change requests.

2.      No Substitute for Technology Expertise

In electronic engineering and manufacturing, technology is not one-size-fits-all. A given technology or component can work well for one product and fail miserably elsewhere. The result depends on a number of factors, including environments, tolerances, and functional requirements.

Product requirements often call out specific services instead of features. If, for example, you specify Wi-Fi instead of wireless connectivity as a feature, your development partner should make sure that is what you really want. To do that, the development team must ask the right questions.

What do you need to transmit? Is it just a few characters of text? Will the product be used in an environment where Wi-Fi is the most reliably available form of connectivity? How will it impact the energy requirements? Often, applying the right technology begins with questions about what drives the real product requirements.

3.      Good Process is the Foundation for Smooth Development

Process is the keystone of smooth product development. Good process creates opportunities for innovation, cost/benefit analysis, and product life cycle planning. Process that focuses on measured results keeps stakeholders aligned to common goals.

No project is without its speed bumps, but process can minimize their impact or help avoid them altogether. Good process provides clear detail on every element of development. From product specification and engineering, to validation, functional test, and manufacturing, sound process will mitigate inherent product development risks.

When you need to outsource product development, seek a process-driven partner who will work with you to maximize features, minimize cost, and race your product to market. Be sure they use a documented and repeatable development process, and have a track record for delivering end products that meet the needs of their customers.

Product Development Outsourcing Done Right

Product development outsourcing doesn’t have to be nerve wracking. It can do just what it’s supposed to—deliver the right product that meets requirements, contain costs, and keep inhouse resources focused on core competencies.

To make sound outsourcing decisions, identify the functions and features, all of the must-haves, your new product requires. Then find a product development partner able to marshal the right technologies for each stage of development and use a proven process to ensure timely, cost-effective delivery.

A collaborative outsourcing partner will dig deep in an effort to excavate all of the product requirements, bravely communicate the realities of feature creep, and show you the scars of their experience—demonstrating they have done this before. With a partner that applies the right capabilities, technologies, and process, you may find yourself in a near-perfect world after all.

Brian Terhune
M2M Communication

M2M Communication

While the term M2M (Machine 2 Machine) may be new to some people, it is becoming a larger part of our lives every day. Given that Stilwell Baker receives many inquiries related to electronic product development, it is interesting that M2M is no longer an option; it has morphed into a requirement. Because of this, it’s the perfect time for a three part blog series on the background of M2M evolution, where it exists today, and potentially where it will be in the near term.

An early example of M2M communication would be the technology that allows wired systems to communicate with various devices. For example, a SCADA (Supervisory Control And Data Acquisition) system that monitors pressure in an industrial facility and alerts a central computer if the pressure is out of limits. M2M communication has evolved as wireless technology and has eliminated the need for hard wire connections, thus reducing cost and system installation time. Now a sensor communicates through a wireless network to the central computer. But the evolution didn’t stop there; the one-to-one communication was superseded by a system of networks that transmits data throughout the company and its partners. When a fault is detected, the maintenance company is automatically notified and dispatched for field repair potentially reducing facility downtime. Finally,  provide the infrastructure for individuals to communicate with their personal appliances (home security, heating and cooling, consumer electronics, automobiles, etc.) and the M2M market really starts to get interesting.

The infrastructure required to support today’s M2M market is vastly different than earlier configurations. Each sensor or remote device must be fitted with a cellular module. The device needs to be on a cellular network, hence a Mobile Network Operator (MNO) is needed (Verizon, AT&T for example). Module selection is also dependent on whether or not the MNO will allow them to operate on their network. In other works, the module must pass certification testing (in addition to PTCRB & FCC certification) that shows it will operate as intended on their respective network. Security of the devices and the network is another aspect that needs to be incorporated into the end-to-end solution in order to protect the M2M implementation. Custom software applications may also be required to connect the remote device to the central server of a business.

M2M wireless networks are already in use in various areas. According to a 2011 Pyramid Research report, M2M applications can be broken down by seven general industries: Automotive,  Transportation, Utilities/Energy,  Security, Financial/Retail, Health Care, and Public Safety. On-Star is one example of a well-known M2M implementation within the automotive industry. Other initial implementations include fleet management or asset tracking. When you use your credit card to purchase a product or at the parking meter, you are using M2M.

Part two of the blog series will focus on where we are today with M2M and detailed considerations regarding implementation and infrastructure.

Earlier this month Lee Teschler, editor of Machine Design magazine, visited with Darrel Baker and Rick Lundin about their experiences with outsourced electronic development projects gone wrong.

Read Lee’s March 18 blog post on their conversation.

Darrel Baker

Since its release last June, the Tesla Model S has accumulated a significant collection of industry recognitions, including multiple 2013 Car of the Year awards. I had a chance to test drive one recently, and can say from firsthand experience that these accolades are well deserved. This isn’t just an amazing electric car; it’s an impressive car that happens to be electric. From an engineering standpoint, it also represents a radical push for innovation. Take a look at this list of some of the patents filed by Tesla since 2008—over 250 active ones related to the development of the Model S alone, and more are still pending.Tesla Model S test drive

The Model S represents as much a paradigm shift in automotive engineering as it does in our collective opinion of EVs. Though most of Tesla’s technological innovations remain invisible to car buyers, there are a few noteworthy components that are readily apparent once you take a test drive. One of the larger issues facing EV manufacturers is what to do with the battery; they’re heavy, and their positioning within the chassis can greatly affect performance. Tesla’s solution to the problem was to create a planar battery pack, and fit it along the bottom of the chassis, lowering the CG moment of the vehicle and increasing handling performance. Moreover, the 416 hp electric motor is capable of generating 443 lb-ft of torque available at any time, for any reason, meaning the car’s acceleration is far superior to an internal combustion engine (ICE). The same torque is available across the entire rpm range of the motor, so it doesn’t matter if you are at a standstill or at 60 mph. Additionally, the car has a  coefficient of drag similar to a Ford GT, and can hit 60 mph in four seconds. I’m a BMW enthusiast, and in my test drive, the Model S ripped through corners and handled an emergency lane change like a sports sedan half its size.

Perhaps even more impressively, the battery – an issue-turned-asset for Tesla – is field replaceable. Owners can swap the base 40 kW-h battery pack for an upgraded 85 kW-h setup if they feel so inclined. The simple fact that this integral and inspired design element is customizable by the consumer represents an impressive degree of engineering on Tesla’s behalf. This is clearly a driver’s car. The interior boasts a 17” touchscreen that allows the operator to extensively modify the driving experience by changing steering modes, regenerative braking, and even an adjustable air suspension that automatically changes ride height depending on conditions.

The next big challenge to be confronted by this new American manufacturer is range anxiety. People remain skeptical of EVs because of their alleged inability to match the driving distances of ICEs. As Tesla begins to design new vehicles with composite frames, continues improving battery technology, and refutes sensationalists in the press (ahem John Broder), the young company will continue to lead the vehicular march towards a cleaner future with a much smaller carbon footprint. Even now, Tesla is developing an EV with a $30k price point to broaden the possibility of ownership to the Prius crowd.

The Model S is a huge step in the right direction. Beyond the landmark strides in tech and engineering, it’s a cool car. The EV stigma disappears in the four seconds it takes to hit freeway speeds. As a result, in the next decade—maybe even the next five years—we may feel the same way about ICEs as we feel now about cathode ray tubes: how quaint.

Darrel Baker

Here’s an interesting article on Engineering Design Challenges from Product Design and Development.

I agree. Controlling costs has risen in importance for our product development customers. Probably a function of the growth of global sourcing solutions.

Engineers in the Stilwell Baker lab


Happy New Year!

We are starting 2013 in our new Lake Oswego facility and the engineers are enjoying the lab. It’s a large space, designed specifically for use as a development lab, and best of all, it’s located close to the engineers’ desks.

Two thermal chambers help us quickly identify and fix potential product issues at extreme hot or cold temperatures. The chambers have 7.7 and 12.3 cubic feet internal space, and the computer programmable controllers safely run them in our temperature test range from -60 degree C to +125 degree C (-76 degree F to +260 degree F). We have already detected two design issues at below -20oC that have resulted in design improvements, thereby preventing field failures.

The lab has plenty of standard tools, but my favorite tool is a 16-channel logic analyzer from Salae called Logic 16. The hardware is very small since it acts as a front end for software running on a PC, Mac, or Linux computer connected through USB. The software includes multiple protocol analyzers such as SPI, I2C, and CAN that greatly simplify BUS analysis. It has some limitations (e.g. samples 2 channels at 100MHz, but all 16 channels at only 12.5MHz), but it can capture 10 billion samples and works great for the majority of our designs.

Our work in the lab will help us bring your design to market quickly and efficiently. Be sure to ask for a tour when you visit the office.

Best wishes for the New Year!