Once upon a time (seven years ago) I answered a question on Stack Overflow. Then Stephane suggested I turn that answer into a blog post. Great idea! This post dives deeper into the original question: “Is it possible to fragment this field (embedded software and firmware) into sub-fields?”

This post represents a detailed and updated response to my original Stack Overflow answer. I hope this post provides guidance and useful information to the “tenderfoots” in the audience.

To experienced embedded system engineers reading this post: please comment and note any of your favorite specialties I have overlooked.

Assembly Language Specialist

Every embedded software engineer must know C. Furthermore, I would recommend that every embedded software engineer dig into C++. Yet some engineers must understand and become experts in assembly language. These are the engineers called upon to port a RTOS to a new microcontroller or to squeeze every drop of performance from a cost-constrained embedded system. A highly skilled assembly language specialist could potentially save a company millions of dollars in recurring expenses by simply optimizing an application to a smaller/cheaper revision of a microcontroller – a valuable skill indeed. That being said, I personally have written minimal assembly code through the years, primarily delving into assembly code when the application required access to specific specialized CPU instructions, such as the ARM NEON instruction set. If an engineer loves the idea of counting every CPU cycle and understanding every detail of their target microcontroller’s CPU architecture, then this is a great specialty to explore.

Device Driver Specialist

The engineer that specializes in device drivers must be comfortable living between a standard desktop operating system and/or RTOS and the target hardware to be controlled by the application software. This specialist must be comfortable with laboratory tools such as oscilloscopes or logic analyzers. They must be able to think in hex and understand the critical nature of timing related to the target hardware. This engineer reads device data sheets for fun at night and is excited about creating the perfect driver for a new device. Additionally, they love to study the nuances of an acronym soup of buses, interconnects, and memory access systems: I2C, SPI, USB, UARTs, DMA, PCI, MMU, and related technologies.

DSP Specialist

Digital Signal Processing seems to be its own sub-specialty of embedded, although perhaps a software engineer may not fully understand the exact algorithm details and may only be implementing what a system or electrical engineer requires. However, understanding sampling rate theory, FFTs, and foundational elements from digital signal processing theory is handy and likely required. This specialist must be aware of timing and the target hardware's restrictions (sampling rate, noise, bits per sample, etc.) An embedded software engineer specializing in DSP software must also understand the target DSP’s architecture and especially the DSP’s specialized instructions for parallel execution and/or optimization of common DSP algorithms. This specialist should know at least one of the common modeling environments for DSP algorithms: MATLAB, SciLab, Python (with Numpy, Scipi, etc), among others.

Control Theory Specialist

Conceptually the same as our DSP Specialist. This specialist is familiar with various families of motors, sensors, and other controllers handled by a microcontroller. This specialist should understand a Bode plot, some Laplace transforms or two, and higher math skills. This specialist likely operates in a robotics industry or creates software for guided missiles, counter-measures, or perhaps even counter-counter measures.

Although I passed my required control theory class in college, I know the least about this specialty. Comments appreciated!

Networking and IoT Specialist

In my original answer seven years ago I referred to this as a “Networking Specialist.” Today, with self-contained maker style modules incorporating a microcontroller with Wi-Fi and/or Bluetooth helping to create the explosion of the Internet of Things (IoT) and its associated buzz word, we certainly must now add “IoT” to this description. The networking and IoT specialist should match the skillset expected in a PC networking specialist: sockets, routers, access points, TCP/IP, HTTP, WebSockets, JSON, the OSI model, DNS, DHCP, Wi-Fi, and more. This engineer must then add the additional knowledge of how to apply those skills within a resource constrained embedded systems environment. This specialist should know how to spin up a test server on their local network or perhaps on AWS or Azure, enabling a test endpoint to aid in the development of the target embedded device while the final production backend is in development or unavailable. To bring maximum value: fully understand the AWS and Azure IoT offerings, understanding the pros and cons of the various supported offerings and associated networking application level protocols: HTTP, WebSockets, MQTT, AMQP, TLS, among others. This is a HOT domain at this time.

Device and Network Security Specialist

This specialty was added after the original post thanks to helpful reader comments. This specialist is likely the same person as our IoT specialist. Yet, perhaps not, as security concerns may extend beyond the IoT. For example: how secure is the firmware? Does the MCU/SoC support a secure boot process? How does the device update process validate and approve software updates? Does the device allow network connections? Is the device running embedded Linux, and if so, how easy is it for a hacker to access a Linux shell? Will sensitive end-customer data be exposed in any manner, perhaps using HTTP instead of HTTPS, or a standard TCP socket instead of TLS? These are the many concerns of a security specialist. This person should probably understand the difference between AES128, Triple DES, Blowfish, and other encryption algorithms. In the modern era of connectivity and professional hackers, this specialist will always be learning and adapting to the latest security challenges.

User Interface (UI) Specialist

Due to the now dominant influence of advanced cell phones in nearly everyone’s daily life, many embedded systems now include dynamic and rich user interfaces. The software frameworks and development challenges involved in creating a high quality user interface are a specialty unto itself. Take the challenges faced by all smart phone app developers (user experience, performance, ease of use, responsiveness, etc.) and then add in all the challenges of a resource constrained embedded system. Then an engineer will have a nearly complete picture of the problem domains involved when tackling the software for an embedded system’s user interface. For example, challenges might include: understanding graphics hardware capabilities and limitations, selecting or designing a user interface software framework appropriate to the device requirements, designing and writing code to manage resources such as bitmaps and layouts, internationalization issues, string translations, a multitude of string encodings, and never-ending product variations. And many of these challenges are subject to the whims of marketing and graphic designers – the only constant will be change! The engineer focused on this domain will be faced with plenty of challenges to keep an active intellect happy!

Embedded Software/Systems Architecture

I am not sure how I missed this specialty in my original answer, as this was my primary focus and responsibility when I authored the response on Stack Overflow. This position and specialty normally applies to larger projects with engineering teams exceeding approximately six members. The embedded software and/or systems architect will have many responsibilities, perhaps including: overall software design, systems design, requirements gathering, design documentation, tasking descriptions, maintaining and improving coding standards, team leadership, setting or leading internal technical standards, resolving team member technical disputes, mentoring, interfacing with external engineering partners or design teams, and contributing to project planning. It is a great job. Be prepared to travel, as the architect will spend more time than other engineers gathering information and requirements from distant partners and customers. The architect generally must be a “near-expert” in at least two or perhaps three of the other specialties listed in this post. The architect is constantly balancing practical real-world issues with theoretical software design concepts. The architect must listen carefully to the team implementing his designs. The white board is the architect’s friend and Word and Visio are common tools for communicating and documenting the architecture. Personal tip: the architect should assign themselves a software module to code and maintain within the team’s system. This will keep the architect’s hands dirty and help the architect feel the team’s pain points. Lead and help fix those pain points and the team will quickly grow into a world class software development team.

Industry

Additionally, as a tenderfoot, be aware that every industry is a specialization unto itself. Consumer Electronics, Military, Avionics, Robotics, Industrial Machines, Medical Devices, etc. Each industry tackles a unique set of product requirements, works with different government agencies, and may live or die with unique business and financing environments. For example, if an engineer decides to enter into a career with a defense department related industry, their job may very well be eliminated due to the vote of a single politician. Conversely, a healthy engineering team may be slashed to the bones due to the intense competitive nature of the consumer electronics industry. Know and understand your target industry and always be prepared for change.

And with that I am ready to wrap up this post. I look forward to comments and additional ideas on this topic. I especially hope this post was useful to the ‘tenderfoots’ in our audience.