The Race to Hire Embedded Software Engineers in the Automotive Industry

August 20, 2019 Zachariah Peterson

Newspaper with help wanted for embedded software engineer

Embedded software engineers will take a new place of prominence in the automotive industry

The current economic climate in the US is humming along and has been primarily driven by growth in the tech sector. Everything from consumer electronics, SaaS, and advanced manufacturing are helping drive growth. The electronics portion of the automotive industry is not typically seen as sitting at the cutting edge of new technology, until you look to the near future. Autonomous vehicles and the connectivity they require are creating many new opportunities for embedded software engineers.

Just take a look at internet jobs sites; compared to entry level software jobs at established and startup companies, embedded software engineers can command a higher starting salary than their software company counterparts. The next generation of embedded software engineers will require a more intimate understanding of electronics than their counterparts in the computer software industry. The complexity of automotive systems requires these engineers to work as part of a larger hardware team, which will require adapting workflows from the software industry to hardware design.

 

The Role of Automotive Embedded Software Engineers

Like software engineers, embedded engineers write, test, and debug code, although embedded software engineers work largely with hardware. In general, this involves developing or configuring a custom operating that is system unique to the product’s hardware architecture. In the automotive space, an embedded engineer may focus on the software that runs the infotainment system, runs an ECU, or any other number of tasks.

Although it may seem unexpected to laypeople, your car actually contains more firmware than a typical computer or smartphone. Cars on the market today contain dozens of ECUs, each with its own firmware. The level of programming complexity involved in a single ECU can be much greater than that used in most computer software packages and websites, yet the software has a high level of specificity due to the hardware it occupies. Embedded programmers are generally not needed in the proof-of-concept phase of product development; automotive layout engineers and embedded software engineers need to integrate all the required components from a proof-of-concept and the embedded software into a single system.

Although embedded software engineers are sorely needed in the automotive industry, this is a field that is easier to enter than in the past. Peripherals in these systems are being standardized, and the younger engineers can easily acquire the education required to excel in this area. However, product development cycles and product lifecycles are shorter than in the past. This has caused hardware engineering teams to start adopting workflows from the software industry to help them keep up with the shorter product lifecycles.

Driver using a car infotainment system

Infotainment systems are just one of many systems that require programming

 

Agile Development for Automotive Embedded Software Engineers

The complexity inherent in autonomous and connected vehicles requires faster development cycles that span across the mass of electronics and embedded software for these systems. Because hardware and embedded software engineers can no longer effectively work in their own siloes, the two sides of product development must adapt to a new workflow that ensures proper communication and collaboration. There are many lessons to be learned from the software industry on this front.

Agile development methods are already broadly accepted as effective for helping a team adapt to change during development. Overall, this hastens product development by allowing teams to identify and address potential design problems earlier in the development process. In a typical linear development process, testing occurs at a specified time during development, creating and increasing the risk of more frequent and more extensive redesigns.

On the hardware side, problems like signal and power integrity, component obsolescence, and supply chain interruptions can trigger a redesign. Waiting until the end of a development process ultimately increases the extent of a redesign should it arise. Obsolescence can also trigger an extensive redesign when a product is upgraded to a newer model.

These potential problems can be addressed by breaking a system into hierarchical subsystems. However, as the complexity of automotive products is only expected to increase, changes in one subsystem can quickly affect all downstream subsystems. It makes more sense in terms of time and productivity to address potential redesigns and component replacements throughout the design process as this limits the extent of redesigns across multiple subsystems. These same ideas apply equally to software for embedded systems in new vehicles.

MCU on a red PCB

This system will require some level of programming by an embedded software engineer

 

Most in the automotive software industry are already familiar with the ASPICE model. Those who are more familiar with agile development processes will likely contest that the ASPICE process should not be referenced in the context of agile software development. The ASPICE model is based on the V-model and is a way to visualize the relationship between a development process and a verification process. As more automotive software projects become more complex, developers that understand the ASPICE model and agile methodologies will become even more valuable to the automotive industry.

Collaboration is Key

Just like mechanical enclosure designers and board layout engineers can benefit from working together in a single environment, PCB layout engineers and embedded software engineers can also benefit from using collaborative features within their PCB design software. Component obsolescence can require selection of a replacement component from a completely different manufacturer, which can require massive changes to software architecture. In the event this type of problem is identified during a design sprint, the required redesign can be quickly communicated to the embedded software designers, which reduces the extent and severity of any required redesign.

Quickly identifying any design changes requires supply chain visibility, rules verification features, and simulation packages. On the electrical side, results from rule checks and simulations inform design changes that can improve signal integrity, power integrity, and manufacturability. Major changes on the electrical side (for example, to an ECU) need to be quickly visible to the embedded software team, allowing them to accommodate to the required electrical and component changes.

Results from simulations inform three aspects of design modification: swapping components and changing your layout. Performing simulations of your device at the schematic and component level help you determine whether the components you have chosen will provide the electrical performance specified in your design requirements. You can then quickly replace components as needed, or you can modify your electronics schematic to solve any signal integrity problems.

The unified design interface in Altium Designer® can now be integrated with the data management and collaboration features in Altium Concord Pro™, providing embedded software engineers and PCB designers with a complete tool set for agile development. The underlying rules-driven design engine provides the verification and productivity features required for streamlined agile development. This integrated platform also includes TASKING tools that can be quickly adapted to automotive software development.

Contact us or download a free trial of Altium Designer and Altium Concord Pro. You’ll have access to the industry’s best routing, layout, simulation, and MCAD collaboration tools in a single program. Talk to an Altium expert today to learn more.

About the Author

Zachariah Peterson


Zachariah Peterson has an extensive technical background in academia and industry. Prior to working in the PCB industry, he taught at Portland State University. He conducted his Physics M.S. research on chemisorptive gas sensors and his Applied Physics Ph.D. research on random laser theory and stability.

His background in scientific research spans topics in nanoparticle lasers, electronic and optoelectronic semiconductor devices, environmental systems, and financial analytics. His work has been published in several peer-reviewed journals and conference proceedings, and he has written hundreds of technical blogs on PCB design for a number of companies.

More Content by Zachariah Peterson
Previous Article
First Prize Winner at Intel International Science and Engineering Fair
First Prize Winner at Intel International Science and Engineering Fair

Intel ISEF 2019’s first prize winner in Environmental Engineering Priotr Lazarek gives a firsthand account ...

Next Article
Design and Analysis of Chirped Automotive Radar Systems
Design and Analysis of Chirped Automotive Radar Systems

When designing your next automotive radar system, check out this overview and list of layout guidelines.