Educating Embedded Engineers

One of the biggest problems affecting the embedded systems industry is a shortage of properly skilled firmware developers. I spoke of this in a recent video interview.

Embedded software developers need some skills taught to Electrical Engineers and others taught to Computer Scientists. They also need practical hands-on experience. Unfortunately, even the best of the Computer Engineering programs at Universities fail to deliver the right mix for embedded work.

The demand for such skilled help is growing rapidly--with the latest estimates put at over 4 billion embedded products manufactured per year.

Fellow Embedded Guru Mike Anderson wrote a nice piece about all this for an IEEE-USA publication called "Today's Engineer." I happened across Mike's article in print, but you can find it online by the title "Help Wanted: Embedded Engineers."

I Are an Engineer

Here's a mocked up fun t-shirt I wish I owned...


EngineerTee.tiff

Educating Engineers

Engineering is a fast-moving field. Even embedded systems design, which is known to use decades old tools, sees new processors and new peripherals and higher speeds and new languages and new techniques arrive continuously.

Unlike the medical profession, which requires continuing education to keep pace with changes in the knowledge base, engineers generally stop learning formally once they obtain a University degree. There is no such thing as Continuing Engineering Education credits.

Symptoms of the resulting intellectual stasis include not only a failure to keep up with evolving best practices, but also the perpetual desire of businesses to hire younger, freshly-educated engineers whether here or abroad.

If we as engineers are to continue to deliver value commensurate with our growing salaries, we must dedicate ourselves to the kind of perpetual learning required in other professions. Only then will the trend toward the use of more fresh-out and offshore engineers be slowed.

What do you think?

The Limits of Knowledge

The practice of engineering has often been likened to a form of art. It is, I think, the art of making scientific tradeoffs. As scientists with a practical, rather than academic or theoretical, focus, we are often challenged to build things on the basis of information at or very near the boundaries of what is known to man.

In virtually all endeavors of engineers, there are unknowns, subtleties, and complexities over which we exercise limited control. The cost, in engineering time and resources, to fully comprehend everything about a system is in some cases unbounded; such a thorough analysis is generally at least cost prohibitive. If the product works, we can’t often afford to do much more than ship it and move on to the next project.

Just as tradeoffs are made in the area of features or implementation techniques, so too must tradeoffs be made in the area of knowledge. It is rarely possible to build a saleable product (that will also earn our employer profits) while at the same time completely understanding all of the possible implications of our numerous design and implementation decisions.

Simply put: components fail. And when individual components fail they can take even carefully-designed systems down with them. Such system failures do sometimes also take the lives of their operators or other people. Catastrophes like this are unfortunate—and bound to increase as people rely increasingly on technological solutions to everyday problems.

The designers of each system must decide how much time and money to spend investigating the dark corners. Those designing pacemakers and airplanes, for example, are responsible to shine the light of knowledge brightly in all corners of their designs; whereas the designers of stereos and televisions can leave a great deal more to chance.

There are, of course, areas of engineering that suffer from the need for thorough analysis but are not profit driven. Manned missions to space, such as those conducted by NASA, are of this nature. Tremendous efforts are made by the engineers working at NASA to understand all of the complexities and potential failure points of the Space Shuttles. Unfortunately, there is likely an unbounded amount of work to be done; these systems have millions of individual components and operate in unforgiving and poorly understood environments. And there’s only limited time to show results.

As the losses of the Challenger and Columbia have demonstrated, sometimes it is a part of a design that is thought to be reasonably well understood that is actually the most dangerous. In both cases, very similar past failures had been observed, documented, and discussed by engineers—yet the true problem and the danger it posed was not fully comprehended until after each catastrophe struck.

I don’t blame the engineers at NASA for the loss of either shuttle; in both cases they knew there was a problem but had too many other, seemingly more important, concerns. I’m willing to let NASA administrators and their overseers decide if managerial mistakes were made and, if so, how to correct them. But all engineers everywhere should learn from NASA’s mission failures: What is the true source of the problem in your system? What danger does it pose? How can you overcome organizational challenges to see the proper solution through?

Reality Bites

The analog world is a messier place than most engineers like to admit. When we work exclusively on the digital, either in hardware or software, it’s possible to forget that the analog never quite behaves the same way twice. I was reminded of this the hard way when trying to model the behavior of a mechanical brake for a piece of precision physical therapy equipment.

A brake is nothing more than a couple of slabs of metal connected to a shaft: one fixed slab presses on the other, thus limiting the movement of the other (and thereby the shaft). The amount of force applied during braking can be controlled fairly precisely in such a system via an electrical signal (e.g., PWM). However, the resulting torque on the shaft is very difficult to accurately predict. In the real world, friction and other physical effects count for a lot: individual brakes have large frictional differences; they also heat up as they are used, which changes their surface characteristics; and the surfaces wear with use as well.

Trying to build a software model for all this such that we could always control the amount of torque required to “slip” any brake to within the required +/- 0.5 lb-in turned out to be an elusive goal. Even if you have all the variables at your disposal, it’s unlikely the analog world will cooperate to produce a consistent result time after time. (Even when we controlled all the variables in our system, we still found variations in the slip torque up to ten times greater than our required precision.) The development of a closed loop control algorithm for the electrical signal driving the brake, based on the torque applied by the user and the shaft’s velocity at each instant, was in the end a far more rational use of engineering time.

The digital is merely a model for the analog; and models are never perfect.

Keeping these crucial lessons in mind, we learn to solve such difficult problems by designing the software to adapt to the real world as it changes. Then all the designers need know at the outset is the range of permissible values and what decision to make at each.

Artificial intelligence takes this approach to its extreme. Far from enabling robots to laugh and cry, artificial intelligence is simply a system for making dynamic decisions. The system is provided a database of known facts; it learns other facts as it operates. By the application of a priori rules, decisions can be made based on the current environment.

We should also recognize that when we simulate a complex system, imperfections in the model are accepted as a tradeoff. Some systems, like airplanes or helicopters, are simply too expensive or dangerous to be used during the early stages of software development. The purpose of the model, then, is to get designers through those early stages, until the software is “safe” to test on the real hardware. Such a model, therefore, need not always be 100% correct.

We can deal with differences between the digital and the analog world best by staying aware of the differences. If we close our eyes to these differences, our systems may fail to adapt correctly to the real world around them.