How Much Does it Cost to Design an Embedded Controller For Industrial Equipment?

The emphasis of this article is on the prototyping of the embedded controller.  When I say “embedded controller” in this context, it doesn’t mean that it actually has to control anything, but it will most likely have outputs. It could simply be monitoring signals to convey useful information to another piece of the system or system of systems.

What’s out of scope for this discussion?

• Manufacturing costs: while production volume should absolutely be taken into consideration for off-the-shelf vs custom component selection, I won’t focus on the manufacturing end of the product development process; rather I’ll focus on the prototype development costs. Of course, designing with production in mind (not just volumes, but DFA& DFM as applicable as well) is still critical.
• The post-production maintenance, obsolescence, and customer support aspects are not part of this discussion either.
• The front end research: in other words, an idea exists, but hasn’t been prototyped or proven out yet, or if it has, it’s been a lab-equipment-based proof-of-concept hack job.

Example Embedded Controller Costs:

I’m going to throw the caution flag here.  Examples are tricky. We like them because they are very tangible. They’re also very dangerous because they are so situational and make many assumptions. Your particular scenario may vary significantly, but we’ve got to start somewhere, right?  It’s worth noting that the labor costs below are fully loaded (salary, benefits, overhead, etc).  So with those caveats, I offer you the following two examples of embedded controller design costs.

Example 1 (circa 2017): Relatively Straightforward Embedded Controller

Example 2 (circa 2017): Relatively Complex Embedded Controller

Key Cost Drivers:

• Re-use libraries: these include both hardware components (e.g. a particular signal conditioning sub-circuit) and software components (e.g. a particular communication protocol interface).
• Off-the-shelf hardware availability: generally when a component can be purchased (that meets the designs requirements), it will be cheaper to buy than to design from scratch.

Cost Breakdown:

Estimates for engineering costs are challenging. The main reason is because something is being created from nothing, and there are a lot of components (software and hardware) that have to work together in harmony (protocols, algorithms, physical interfaces, power consumption, heat dissipation) in order for the embedded controller to perform as desired.

Much of the ability to generate reasonable cost estimates comes from leveraging past experience solving similar problems. Being able to recognize the differences in hardware and software platforms and requirements, allows seasoned engineers to quickly estimate the amount of work required.

The other cost estimation technique often utilized is bottom-up cost estimation. This is where you start from extremely low-level components that can be estimated, and sum the parts to come up with a final tally. When I say low-level components, I mean down to the level of something like:

• An algorithm, like an FFT, or maybe even lower level like a butterfly element
• GUI elements, like a plotting function
• A circuit board sub-circuit, like a particular SMPS

Combining past experience with bottom-up cost estimation is pretty typical in the engineering world.

The biggest challenge/unknown from a costing standpoint is generally estimation of integration and debug of the prototype. This is where the various components that were developed and simulated all have to start working together.

The costs that people don’t like to think about:

Embedded designers are more apt to want to focus on the creation aspect of the core design (e.g. coding on the software/firmware side, and circuit design on the hardware side), and less likely to want to pay as much attention to costs associated with tasks such as:

• Requirements – developing and managing requirements isn’t free, but it can cost you even more by not paying attention to them.
• Project management – hardcore developers often hate project management, often seeing it as superfluous. On the smallest of projects, project management can be handled individually. Otherwise, at a minimum, it’s a necessary evil, and if done well, it can make the development team’s life better by helping them not get overloaded, helping clear roadblocks, and providing clear goals.
• Risk mitigation – If nothing ever goes wrong with any of your projects, I’d be grateful if you’d get in touch with me and explain your magic.
• Documentation – This can get out of hand for sure. Keep it to a minimum. The three best reasons to document in my mind are: (1) to help you design in the first place (2) to help teach someone else whatever they need to know (3) to help you remember what you did a year or more later. If none of these criteria are met, you may want to second-guess your effort.
• Integration – Integration/interfacing of things is becoming more and more prevalent. Just always remember that whenever you create a new component, you need to interface with it somehow, and you should allocate time for this.
• Debugging – I wrote an article on this topic to help with the debugging process.
• Hardware re-spins – It is possible to design a custom circuit board well enough on the first shot that a re-spin is not needed;it’s just highly unlikely. I wouldn’t recommend planning for it.
• Certifications – You may not require certification for your prototype, but you probably want to start thinking about it so you don’t design yourself into a corner.

Next Steps:

Presumably if you’ve made it to this point in the article, you’re likely either:

• Overloaded and just need some additional resources to get the job done.
• Relatively new to the embedded world and are considering pulling in some outside resources to help.
• Curious about alternative ways of doing things.

If you’re interested in scoping the cost of an embedded controller for your application, you can reach out to us here.  If you’re interested in understanding how we can help, go here.  If you want to see the sorts of requirements you should be thinking about, go here.  If you’d like to get a feel for the engineering labor costs to develop the prototype embedded controller for scenarios that are able to utilize off-the-shelf hardware, see our engineering prototype cost calculator.