Automotive Software Engineering: The Race to Hire Embedded Software Engineers

Zachariah Peterson
|  Created: August 19, 2019  |  Updated: August 20, 2020

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 Author

About Author

Zachariah Peterson has an extensive technical background in academia and industry. He currently provides research, design, and marketing services to companies in the electronics industry. Prior to working in the PCB industry, he taught at Portland State University and conducted research on random laser theory, materials, and stability. His background in scientific research spans topics in nanoparticle lasers, electronic and optoelectronic semiconductor devices, environmental sensors, and stochastics. His work has been published in over a dozen peer-reviewed journals and conference proceedings, and he has written 2000+ technical articles on PCB design for a number of companies. He is a member of IEEE Photonics Society, IEEE Electronics Packaging Society, American Physical Society, and the Printed Circuit Engineering Association (PCEA). He previously served as a voting member on the INCITS Quantum Computing Technical Advisory Committee working on technical standards for quantum electronics, and he currently serves on the IEEE P3186 Working Group focused on Port Interface Representing Photonic Signals Using SPICE-class Circuit Simulators.

Related Resources

Related Technical Documentation

Back to Home