The ability to update software easily and frequently is a positive advancement. However, for products that are safety-critical even for a short period of time, running buggy software could be devastating.
If you had asked me 10 to 20 years ago what an embedded software engineer’s responsibilities and skill sets are, I would have given a clear, specific, standard answer. Fast-forward to today, and the umbrella under which the embedded software landscape exists has significantly expanded. This expansion influences the programming languages being used, the complexity of operating systems, the options to support the internet of things (IoT) requirements and quality processes throughout the software development life cycle (SDLC).
Advancing along with technology
I have found that as a firmware or embedded engineer, it is necessary for me to keep up with the latest technology, even as a manager. Currently, the mindset for continuous learning is even more critical, as all industries add connectivity requirements.
For example, take a software design with core functionality for a control algorithm with features such as input/output handling, diagnostics and a display. To stay up to date, this device will require more advanced features that were less common in the past. An onboard embedded database system is needed to organize and store data to ease access, instead of simply storing it manually in the electrically erasable programmable read-only memory (EEPROM).
Connecting systems, size and tools
The lower cost of memory, more powerful microcontrollers in smaller package sizes and the stability of embedded-specific distributions have driven Linux to become a popular option for embedded products with the use of a real-time Kernel. Embedded engineers may have used Unix machines in the past for their development environment, but now they need to become familiar with the advanced features that C++ and the Linux Operating System can offer their product design, versus a smaller footprint real-time operating system (RTOS).
Flexible embedded engineering teams will be knowledgeable about the “size spectrum” for embedded systems. This ranges from small bare-metal, round-robin architecture, all the way up to large multi-core and multi-threaded architecture that borders on a fully developed PC system — again entering the IT realm.
The tools used today for the SDLC is another area where the traditional role of IT and embedded software has come together. Tools can be configured in a way that allows: automatic checking of review status when a source code file is checked, automatic build, automatic regression tests and then automatic logging of failures in the bug tracking tool. The setup of these tools goes beyond basic system administrations and requires knowledge of automated test-scripting, executable build files, and build servers — along with understanding the agile process. This role is considered part of DevOps and requires both IT and software engineering knowledge.
Striking the balance between speed and quality
Throughout my time in the industry, I have been a part of software groups that struggle to find the balance between fast software releases — due to the pressures of a competitive market — and the need to be diligent with robust quality checks, especially when it comes to functional safety. PC and web applications tend to get frequent updates, due to the ease of rolling out new software, while embedded products traditionally require release processes that are more measured and formal. This circumstance could include formal code reviews, unit testing, regression system testing, etc.
I find that these two philosophies bump up against each other, due to the prevalence of over-the-air programming. On the one hand, the ability to update software easily and frequently is a positive advancement for the embedded realm. However, engineers and managers must remember that for products that are safety-critical even for a short period of time, running buggy software could be devastating.
This outcome is especially true for an embedded device interacting with other hardware modules, communication buses, sensors, and sometimes in extreme environments. In this realm, software quality needs to go beyond traditional IT and include all processes as part of the SDLC.
Stressing processes and best practices
EASi’s current multidisciplinary team of software engineers is ready to execute on our customer projects that requires a cohesive mix of firmware, low-level embedded C, application-level Linux-based C++, web application software and DevOps backgrounds. We continue to stress that the traditional engineering definition of quality is not independent of source code creation or limited to just testing; it includes the processes and best practices that all team members follow throughout the SDLC.
Want to know more about trends in embedded software and information technology? Contact EASi now.