WHAT ARE THE DISTINCTIONS BETWEEN SOFTWARE AND FIRMWARE?

Products have evolved to their current form by repeatedly adding ever more flexible and intelligent modifications. From skilled craftsmen to mass production, to electronics, to software and firmware, each step added new capabilities and value that would have otherwise been impossible.

Today’s core product development team typically consists of Mechanical, Electrical, and Software/Firmware Engineers because each discipline brings essential capabilities to the task. The best results are realized when products are designed, and the development processes are structured, to leverage each discipline’s strengths. These strengths however are not leveraged if the design and development tasks are not performed correctly. What are the guidelines for a good development approach? How does developing Firmware differ from developing Software? What does it mean to do it correctly?

Making Good Firmware

Given that Firmware is Software at heart we can start there, cover some Software essentials, and then move on to Firmware and the additional knowledge and effort Firmware requires.

Software Engineering is a bit of a contentious subject. Lacking a standard, formal test to show competence at Software, it is argued that it is not a real Engineering discipline. Perhaps this alone captures one of the most difficult aspects of Software. Since you cannot touch or even see it how do you know if it’s any good? Or whether it is doing the right thing?

But engineering is engineering, regardless of the particular discipline. Engineering means to apply a structured and scientific approach to building something. Software Engineering, then, means to apply a formal rigor to all phases of the software lifecycle.

While it is possible to add a brace or bracket to a mechanical design to address a design shortcoming, Software has no such complement. There is no way to add 10% more Software to improve its stiffness or performance margin. For example, in electrical engineering a 2-Watt component will handle two times the heat of the same 1-Watt component. In mechanical engineering, the stiffness of a part can be improved by increasing the thickness. Generally, with Software, you either designed and built margin in ¹, or it doesn’t exist. There is no way in software to double the lines of code to make something better. It would probably make things worse. And it gets difficult and expensive to add it on later. In Software development this means the up-front work matters most.

In this sense, good Software is like any other Engineering endeavor: good requirements, good architecture, and good design are paramount to a successful result.

An essential difference between Hardware (Mechanical and Electrical) and Software Engineering is the debug cycle: Test, Debug, and Fix. The lead time to fix a Hardware issue is often measured in weeks. ASICs have spectacular prices and lead times for mask changes and fabrication! While rapid prototyping has improved the lead time for mechanical parts, once specific materials or tools are required for fabrication, the lead time rises. Software can be a matter of minutes to recompile and try another version. This aspect of software means that it is also frequently used for analyzing and debugging Hardware issues.

The long lead times to change physical components vs. a quick change to Software drives product architectures to consist of modular electromechanical subsystems that implement the overall control and behavior in Software. A physical retrofit to a fielded product might be difficult or impossible, but a firmware or software update can fix a problem or add features to extend the life of a product.

Different Grades of Software

I like to group Software in to four different grades. The Software produced by each reflects the focus and effort of its class. Likewise, the Software cost and schedule are directly tied to each grade. They are:

1. Perfect World
2. Consumer
3. Industrial or Commercial
4. Medical, Military, or Aerospace

Perfect World

One of the best examples of Perfect World programming is MapQuest or Google Maps directions. Those half dozen steps are nothing other than a program or algorithm for reaching point B from point A. Google can spit those directions out in a split second.

Such it is with Perfect World software. Many times, those not familiar with Software Engineering will exclaim “How hard could it be? I can tell you exactly what the algorithm is.” Yet if you followed those instructions literally, as a computer would, you could cause harm to yourself or others. Perfect World software assumes that a competent driver with proper equipment will fill in for the huge gaps. Weather, accidents, speed limits, traffic lights, other traffic, random animals, or children on bikes are just a start to the issues NOT addressed by this approach.

Consumer Grade

One step up from Perfect World is Consumer software. We have all experienced it, apps on your phone or the latest Wonderware on your PC. It is long on features and sparkles but way short on stability and robustness. An example of Consumer grade Software is an application that auto-saves your work rather than solves the root cause problem – crashing and losing your work, again.

In car terms, our half dozen lines of code swelled to a couple hundred lines to give us 37 skins, 90 radio and video stations with advertisements, and it will mostly stay between the lines, while attempting to manage the speed limit and obey traffic signals – maybe…

Industrial or Commercial Grade

This is Consumer Grade software upside down. Robustness, stability, and data integrity are everything. Features and glitter take a backseat to proper function. This Software is hardened against all kinds of bad things, like flakey communications, corrupt data, hardware failures, software failures, etc.

Software directions grow to a couple thousand lines of code, but it handles weather, potholes, other traffic, and alternate routes in addition to getting us to point B.

Medical, Military, or Aerospace Grade

This is like much like Industrial or Commercial Grade Software. In general, I have not seen it result in more code, but rather utilize hardened and regimented processes for making such Software.  If you need any convincing that good Software comes from proper processes, this should be it. When lives matter, proper processes are documented and compliance is regulated.

In the car software example, it is still about a couple thousand lines of code, but it comes with a guarantee to get us to point B, has backup systems, is able to run on a flat tire, and has multiple vehicles that all ensure that we’ll get there.

So, What Is Firmware?

Firmware Engineering differs from Software in a couple ways. One is its environment. Software tends to be loaded on a general-purpose system when you need it and it exits when you are done.  For Firmware, loading usually means flipping a power switch. It is always there. Firmware also never terminates. (If it does, it’s called ‘bricking’, where the product has just been rendered useless and may be unrecoverable.) Generally, it runs in a spartan environment, no graphics or monitor, maybe a few buttons, but no keyboard. The processors in embedded systems often run in 10’s or 100’s of Megahertz, not multiple Gigahertz. Memory is also typically kilobytes, not Gigabytes.

Another way Firmware is different is that it tends to be tied very tightly to a specific task and the Hardware it runs on. Because Firmware determines so much of a product’s behavior and features, the Firmware Engineer needs to understand the Hardware subsystems in great detail. Hardware dependencies like bandwidth, timing, blocking, and buffering all come in to play. Firmware must manage and choreograph Hardware resources as effectively and efficiently as possible.

This not only makes Firmware different from Software, but Firmware Engineers are different as well. In addition to being competent at crafting good Software, the Firmware Engineer needs to have a good working knowledge of electronics and potentially mechanical systems, control theory, real time operations, etc. and be able to do all these in a very resource constrained environment.

Software and Firmware Conclusion

Firmware is an essential element of many modern products and continues to become more ubiquitous. Its flexibility and relative ease of updates makes it ideal to develop a product quickly and address issues or add features, perhaps in the field.

Good Firmware takes all the same skills as good Software but runs in a harsh and sparse environment that also requires good electronics and mechanical knowledge and a solid grasp of the product’s features. These all make Firmware typically more expensive than Software development.

My father frequently mentioned “Champagne taste on a beer budget” while I was growing up. (I’m sure there was a message in there somewhere!) Hat tip to my Dad, my favorite Engineering version of that is:

“Good Engineering is expensive.
Bad Engineering is unaffordable.”

The right people, doing the right job the right way is the shortest path to success. The best Engineering makes the difficult or impossible disappear to the user. No one will ever understand the amount of work it took to make that happen. But everyone will notice when you make it cheap.

1 “Why is software so expensive?” An explanation to the hardware designer. Edsger W. Dijkstra