Designing An Industrial Embedded Controller – Important Costs To Consider – Part 2

This article is a continuation of part 1. If you’ve not already read part 1, please start here. As a re-cap, last time we covered the following costs:

1. Requirements
2. Project management
3. Risk mitigation
4. Documentation

The emphasis of this article is on the prototyping of the embedded controller.

Let’s jump right back into it:

Cost 5: Interfacing –

Just always remember that whenever you create a new component, you need to interface with it somehow, and you should allocate time and effort for this. Consider low coupling and open standards whenever feasible.

Here’s why you should care: 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. We’ve got a webcast on interfacing to help.

Cost 6: 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.

Here’s why you should care: 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. I wrote an article to help with the debugging process.

Cost 7: 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.

Here’s why you should care: 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.

Cost 8: 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.

Here’s why you should care: 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 2-3 people, the variations can make or break a project. I’d recommend either being aware of who will be on the project team in the planning phase, or if that’s not possible, be conservative with your estimates.

Cost 9: People/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.

Here’s why you should care: 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.

So what now?

If you’d like more useful info on industrial embedded systems, check out our resources page.  If you’d like help scoping the cost of your industrial embedded controller, you can reach out to us here.  If you don’t have the time or the manpower to develop your own embedded solution, check out VERDI.