Focus
The focus of this article is on small and medium-sized companies, i.e., those with less than 500 employees. It is geared toward companies in the industrial market that manufacture systems or sub-systems that are generally expensive—in the range of $4,000 to $200,000 per unit—and have lower production volumes, from about 10 to 1,000 units per year.
Emphasis 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 (it could, but isn't required), 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.
Fig. 1: Emphasis on Development Phase
What is beyond the scope of this discussion?
- Front-end research: in other words, an idea already exists, but it hasn't been prototyped or proven out yet, or if it has, it's been a lab-equipment-based proof-of-concept hack job.
- Manufacturing costs: while production volume should absolutely be taken into consideration for off-the-shelf versus custom component selection, we won't focus on the manufacturing end of the product development process; rather focus on the development costs. Of course, designing with production in mind (not just volumes, but DFA & DFM as well) is still critical.
- The post-production maintenance, obsolescence, and customer support aspects are not part of this discussion.
Next page
Costs People Don't Like To Think About
Estimates for engineering development costs are challenging, and I mean really challenging. The main reason is because something is being created from nothing, and there are a lot of components, including software and hardware, that have to work together in harmony, like protocols, algorithms, physical interfaces, power consumption, and heat dissipation, in order for the embedded controller to perform as desired.
The majority of costs that engineers don't like to think about are areas that are generally considered less fun, but that doesn't make them any less valuable. 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 the nine identified below.
Fig. 2: Nine costs that engineers don't like to think about when developing embedded systems
Requirements
Many of the more formal methods for requirements generation and management may be overkill for some industries, and sometimes people get out of hand with requirements, but that's not a good reason not to do anything at all. Consider developing a minimum set of requirements for your scenario.
You should care because requirements are the core of communicating what your industrial embedded system will become. Often the objective with requirements is getting one person to convey and organize information that's in their head with others.
Developing and managing requirements isn't free, but it can cost you even more by not paying attention to them. Not having requirements could create the need for a board re-spin, or could cause processor overloading. Requirements ultimately transform into what you design and test against. What you test against ultimately is what you judge success or failure against.
Next page
Project Management
Hardcore developers often hate project management, seeing it as superfluous. On the smallest of projects, project management can be handled individually. Otherwise, at a minimum, it's a necessary evil.
You need to take care because project management can make the development team's life better by helping you not get overloaded, clear roadblocks, and by 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. Otherwise, you should understand the likelihood and severity of your main risk items.
Understanding your main risk items can help you come up with backup plans if a risk item occurs. At a minimum, risk assessment can be used as a tool to set expectations with the team, management, and your customer.
Documentation
There are a few people out there that enjoy documenting. For the rest of us that don't enjoy it, it's worth noting that it can get out of hand. Just documenting because you're supposed to, is not a very good reason in my mind. Keep it to a minimum.
The three most helpful reasons to document in my mind are:
- to help you design in the first place
- to help teach someone else whatever they need to know
- to help you remember what you did a year or more later.
If none of these criteria are met, second-guess your effort.
Interfacing
Just always remember that whenever you create a new component, you need to interface with it somehow. You should allocate time and effort for this. Consider low coupling and open standards whenever feasible.
Interfacing with other components, sub-systems, or systems is becoming more and more prevalent. It offers benefits along the lines of the whole being greater than the sum of the parts.
Next page
Debugging
Debugging often has negative connotations associated with it because engineers might think that it means they messed something up that they shouldn't have, and now they have to fix it in a hurry. This is the wrong way to think about it. While it does generally mean that something was coded, designed, or interfaced incorrectly, these imperfections should be expected.
Debugging doesn't have to be a stressful thing if you are prepared. It can actually be one of the more fun parts of the development process. It's both a puzzle to solve and a learning experience.
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. However, it's just highly unlikely and I wouldn't recommend planning for it.
If you plan for a re-spin, or maybe even more depending on your scenario, and you don't need it, you come out ahead of the game from a cost and schedule standpoint. If you don't plan on it and you need it, life gets very unhappy very quickly.
Employee Performance Variation
People don't like to talk about this, but not everyone works at the same speed, and sometimes at quite sizable deltas. If you take the average engineer at a given level of skill, I'd say most people work within about ±25%'ish of that range, but I've seen people that I'd say performed as much as ±50% faster/slower than that average.
If the project team is large enough, say with 10 people or more, these variations tend to average themselves out. But with small teams of two to three people, the variations can make or break a project. Be aware of who will be on the project team in the planning phase, or if that's not possible, be conservative with your estimates.
People And Team Issues
Many engineers thrive off of solving technical and analytical problems and are more apt to view people-oriented problems as superfluous. The challenge here is that for problems of any significant complexity, people need to organize into teams, which creates a necessary new class of problems to address.
Friction between team members that don't get along can create project inefficiencies, generally stemming from a lack of communication, or can even de-rail high-stress moments such as demonstrations.
About the Author
David LaVine is the Marketing Manager & Solutions Architect at Viewpoint Systems. He holds a BS in Electrical Engineering from Rensselaer Polytechnic Institute and an MS in Electrical and Computer Engineering from Georgia Tech. He has been with Viewpoint Systems since 2013.
Now I need your help:
This discussion was focused on the costs that people don’t like to think about. I’m considering creating a more holistic (and fairly in-depth) report on cost estimation for embedded design. What I want to know is whether there is enough interest in this topic for me to put the time in to create such a report. If you’re interested, please let me know here. If I get enough interest, I’ll develop the report and send it out to those interested.
Where you might head from here:
If you enjoyed this article and would like more useful info, sign up for our blog here.
If you’d like help scoping the cost of your industrial embedded controller, you can reach out to us here.
Related Stories
Inspur and Altera Launch Speech Recognition FPGA Solution with OpenCL
Universal Input Reference Design Provides Accuracy and Flexibility for Industrial Sensors
PCIe Card Records 16-Channel 960H Video with H.264 Encoding at Full-Frame Rate and Resolution