What a firmware curriculum would look like
Using social media, firmware engineers come together to design a firmware curriculum for embedded systems engineering students.
This problem is unlikely to be resolved any time soon. The price points for MCUs and FPGAs continue to drop, as do the form factors of these devices. As the information revolution accelerates, we're seeing dramatic growth in wireless and device interconnectivity, and, as result, wireless device users are increasingly demanding the ability to stay constantly connected while mobile.
With complexity of systems and code increasing, it's critical that we as an industry address this training issue directly and drive the adjustments to firmware engineering education necessary to meet the demand while maintaining design integrity and quality.
To gather insights and information on this topic, I've taken advantage of the communications speed and flexibility of LinkedIn, one of the Internet's leading professional networks. Through several of LinkedIn's firmware-related groups, I have led multiple discussion threads and created several surveys to raise a number of critical questions. What exactly is firmware? Has it ever been precisely defined or pinned down? Has the demand for firmware engineers genuinely increased? Will this high demand last? What areas today are experiencing the greatest growth? Is a full-fledged degree in firmware engineering critical? Would a minor course of study or a certification program be sufficient? Who are these creatures we fondly call "bit-heads." Where do they come from? Where should they come from?
I also used more classic techniques for collecting information, including my own 20+ years of firmware development experience, as well as input of some of my colleagues from the academic, entrepreneurial, and business arenas. My expert advisers included Dr. Marvin Schwartz and Robert Bowser (see sidebar below for bios).
The result of my research is a curriculum (shown in Table 1) that I freely admit is only a starting point, subject to critical feedback and debate. I came up with list of coursework via a combination of feedback from my LinkedIn group, my interview with Dr. Schwartz (especially the Art of Computer Programming portion of the curriculum), and my general knowledge from my years of experience in this field. Some IEEE members suggested I work on developing a curriculum with a team of other firmware engineers. I'm building a team that will eventually petition IEEE to complete the curriculum. We currently have 15 colleagues who have expressed interested in building this curriculum.
Here are some of the findings I've gathered to the questions I asked the group and advisors.
What is firmware?
Defining firmware is no small task. The IEEE defines firmware thus: The combination of hardware devices and computer instructions and data that reside as read-only software on that device . . . the confusion around this term has led some to suggest that it be avoided altogether.
Firmware has also been defined as the fixed, usually rather small programs and/or data structures that internally control various electronic devices. When definitions use words such as usually, often, small, and avoid, it's a good indication we need to go back to the basics to define the term.
I posed this question to the Firmware group on LinkedIn, both in discussion threads and in survey form. After weeks of online debate, no clear definition emerged on which the majority of engineers responding could agree.
With that in mind, let me share some of my findings that I feel may help in building a foundation. After much discussion and attempts to define the term, I decided to create a poll using the definitions that had found the greatest support in the discussion threads. Among the 148 firmware engineers who participated, the most popular definition, with 81% acceptance, was the one provided by Arthur Sittler (a firmware engineer from the LinkedIn group): Firmware is programming stored in nonvolatile storage that the end user is not generally expected to change at run time.
This focus on persistence and storage has been nearly constant in all the discussions I have had. The only notable exception was provided by Robert Gezelter, who made a compelling argument: The storage mechanism is a thin reed to grasp for classification . . . The etymology of "firmware" is, in essence, "software embedded in hardware." FPGA configuration information is part of that continuum, as are many other realizations of hardware-dependent encoding.
Dr. Schwartz had no awareness of my survey or the online discussion and was not a member of the Firmware group at the time of our discussion. I will not attempt piecing a definition together from their contributions, but suffice it to say that constancy, hardware dependency, and device programming are probable elements.
If firmware engineers are not receiving formal education specific to the field, what is the most common degree that they hold? Answering this question will give us some guidance on the prevailing skills a firmware engineer should have. Again, I drew upon the wisdom of the Firmware group to help answer this question, shown in Table 2.
Clearly, the majority of firmware engineers come out of the field of electrical engineering and a large minority comes from the computer disciplines (namely computer engineering and science).
Using social media to create local meet-ups for engineers
Say social media and engineers typically cringe. Or do they?
Firmware engineer Bob Scaccia and members of the Firmware group that Scaccia initiated on LinkedIn are embracing the professional social media site to organize in person meet-ups and online discussions about technical and not-so-technical topics relevant to embedded systems firmware development. Scaccia, who moderates and keeps the discussions going on the site, used the LinkedIn group specifically to organize a local firmware group in his home state of Ohio. "Our group here in Northeast Ohio has 190 members," he said. "We’ve met several times, and I’ve arranged to have speakers attend and provide some training."
To further the profession, Scaccia has also started a firmware-community website called Firmware Planet (www.firmwareplanet.com) where he has set up a consultants’ and contractors’ database. Firmware practitioners will be able to upload information about their expertise and connect with other firmware engineers and customers. Scaccia says the consultants registry has about 100 members.
--Susan Rambo, managing editor, ESD
As will be discussed later, Dr. Schwartz made it very clear that the art of programming would play a very crucial role in a firmware curriculum. But he also agrees with most other engineers that it would start with electrical engineering and end with computer science.
As mentioned previously, the demand for firmware engineers is growing. Of those polled, the majority saw either steady demand or growth. About one in ten found reported demand was dropping.
In my dealings with those who have a business-level exposure to the demand, there is very clear growth in the demand and businesses are struggling to find appropriate talent to match. I would argue this demand is not temporary and must be addressed with both long-term and short-term solutions that elevate and educate engineers in firmware design and development.
So far we have developed an argument for what firmware is, who firmware engineers are, and why there is a need to develop educational options that will educate and elevate engineers and students of engineering.
But what are our options? How can we address the short-term demand crisis and long-term need for talent? Interestingly, the debate in the discussion boards on LinkedIn presented a different story than my polling results.
I found that a certification program generated some very stern and negative knee-jerk reactions in my discussion threads. Many have found that certification programs have been designed to create profit for those who create them rather than educate and elevate the talent pool.
But when I put this to a poll, I received a very different profile. By a great majority, the idea of certification developed by the right people and for the right reasons received resounding approval. A certification program successfully implemented would go a long way towards meeting the short-term demand for talent.
I believe that a firmware certification program would provide courses and curricula that would allow an electrical engineer to develop the software skills necessary to be an effective firmware engineer while leveraging the his or her electrical engineering background. A master's level program of study in firmware might be an alternative to a certification program. Robert Bowser, senior director with Steris Systems, notes,"Certifications always elevate the work force and the profession. Certifications help companies understand the level of understanding (in a somewhat measured way). In a job search situation, a hiring manager can focus more on other fit parameters if they are not spending a lot of time evaluating technical competence, making a better hire and a more effective industry."
The creation of a bachelor's program did not receive strongly negative or positive responses. With that said, the primary argument against a bachelors degree program was that it might encourage further fragmentation of disciplines.
I'm firmly convinced that a degree in firmware engineering is a necessity. The next logical step in our technological evolution will include massive connectivity of devices for the purpose of data analysis on a scale unimaginable from our present vantage point.
I see a multitude of devices that perform some purposeful action having firmware as part of their basic composition. All these devices can and will be connected in a massive wired and wireless infrastructure for the purpose of improving the human condition. We have seen how being connected socially has improved the human condition. The next logical step is the device.
With that said, the skills taught to a computer scientist are not sufficient due to the obvious lack of electrical engineering competency and the fact that computer science is taught from a completely different vantage point than what is required for firmware development. Schwartz notes, "Computer science doesn't even begin to explain to you how computers work . . . In a firmware world I would absolutely start with how computers work and assembly language. . . . I can see a full curriculum." He went on to say, "I think there is a need for a major. I think there are a number of skills a firmware engineer needs that are not being taught either in electrical engineering or in computer science."
Back to the curriculum
Dr. Schwartz went on to note that "Agile design methodologies welcome change instead of avoiding it. In firmware, it is the complete opposite. You need to have very high reliability in what I think of as firmware because you can't afford to go and update it all . . . Take a ISO 9000 rather than an Agile approach. You would want to be able to look at certain sets of requirements for a system and easily estimate whether it's possible with the resources you are given. People try to do ‘the impossible' and fail."
Now that we have addressed the prerequisites, let's start building a curriculum. Comment on this article on below to put in your two cents for a firmware curriculum.
Bob Scaccia is a principal firmware consultant with over 25 years experience in embedded systems development. He is the founder and leader of Firmware Engineers of Northeast Ohio group and is also the chair of the IEEE Computer Society for the Cleveland IEEE Section. He has a BS degree in electrical engineering and is working toward an MBA. For more information about Bob, go to www.usafirmware.com or contact him at firstname.lastname@example.org.
Related content: "Struggle continues to plug embedded programming gap" by George Leopold, 5/3/2012
This content is provided courtesy of Embedded.com and Embedded Systems Design magazine.
See more content from Embedded Systems Design and Embedded Systems Programming magazines in the magazine archive.
This material was first printed in May 2012 Embedded Systems Design magazine.
Sign up for subscriptions and newsletters.
Copyright © 2012
UBM--All rights reserved.