What Does the Foreseeable Future of an AUTOSAR Engineer Look Like?

Taking a look at the Tesla Model 3, you clearly see that size and power are not the consumer draw. Power on an electric vehicle (EV) is far more efficient since it gets power directly from the battery into the wheel motors (minus the power conversion), but that does not seem of the same importance in this era. Over time the needs and desires of the consumer change. Raw straight-line power with an unambiguously loud V8 engine is not really a consumer focus. The main attraction for Tesla seems to be fuel economy (i.e., zero fuel) and user experience. User experience is so high on that list that it dwarfs all other categories. From the touch-screen interface to the “zero maintenance,” the consumer is basically spoiled and lured into a lifestyle that makes access to transportation a seamless, effortless luxury he will eventually not be able to live without (e.g., iPhone). Autonomy will take this to an entirely new level. The 1957 Chevrolet was arguably the most popular car in America at one time. It came with a top-of-the-line V8 engine, a lower stance, a wide grill, and tail fins among other features. The consumer was clearly looking for size, power, and styling.

Advancements in technology such as increased capability in microprocessors, such as multiple cores, enable developers to increase the number of user experience features and performance enhancements of a vehicle. With the increase in user experience features comes an exponential increase in software development. The graph below shows a progression in code size over the last few decades. Software accounts for 80 percent of product innovation. That will likely keep increasing as autonomous driving evolves.

Standardization – AUTOSAR

Just as past original equipment manufacturers (OEMs) once standardized on nuts, bolts, brackets, radios, suspensions, etc., software must now standardize to create an environment that can support the exponential increase in code size and complexity. Software development costs currently account for a large portion of all development costs. When autonomous driving takes hold, with functional safety required, software development costs will rise to unsustainable levels.

AUTOSAR is a worldwide-development partnership of vehicle manufacturers, suppliers, service providers, and companies from the automotive, electronics, semiconductor, and software industries aimed at achieving exactly the standardization needed for the future of mobility. The main motivations are described below in more detail. 

A vehicle consists of hundreds of millions of lines of code, and that number will only increase over time. User experience, autonomy, and functional safety will drive that complexity through the next decade at least. If the OEMs can standardize the platform for software development and manage their suppliers to that standard interface and platform, it has tremendous implications for the overall development lifecycle. When you consider the names on the AUTOSAR partner list, it becomes clear that this is a major need and that AUTOSAR standardization WILL happen.

AUTOSAR Partners as of 2017

The AUTOSAR Engineer

AUTOSAR presents a significant paradigm shift in the automotive world for software development. In the past, other shifts of similar magnitudes occurred for similar reasons that impacted the careers of the automotive embedded engineer.

Model-Based Software Development

In the 1990s, as automotive electronics fully took hold, the demand for embedded software engineers grew significantly. Engineers went from a career of being software coders to having to learn model-based design (MBD). The skills needed changed. Some drivers for MBD were to ensure quality, increase reuse, and decrease development time.

Model-based design provides an efficient methodology for establishing a common framework for communication throughout the design process. Developing model-based implied you were:

1.   Modeling a plant
2.   Modeling the controller for the plant
3.   Simulating the plant and controller
4.   Taking that simulated controller and translating that into real-world code

For the embedded software and controls engineers this created an entirely new career path that could take many forms. Some examples with descriptions are listed below:

1. Simulation controls engineer – Develops plant models. Plant models represent the physical systems; translating the physics into mathematics and coding that into a tool. This could be a number of mechanical or electrical systems with varying levels of complexity (engines, brakes, steering, etc.).
2. Embedded controls engineer – Develops a physical model that represents the controller itself including things like timing, communications, memory, and component interactions.
3. System integration engineer – Takes the plant and controller model and validates the control laws through simulation before taking it to a vehicle.
4. Embedded software engineer – Integrates the simulated and modeled code into the target controller. Includes coding specific to the firmware.
5. Tools engineers – With new tools used for simulation comes the need to optimize and automate and manage those tools.
6.  Workflow process engineers – Integrate this process described above into a full product development lifecycle.
7.  Software test engineers – Verify and validates the code against requirements or standards.

This process has been standard in many industries for decades now. The tools (predominantly MATLAB® and Simulink®) are commonly used by most major manufacturers of vehicles and a large majority of suppliers.

The AUTOSAR Shift

AUTOSAR presents a very similar shift and will change the paradigm for engineers, but at the same time, presents new opportunities. At least in the near term, there will be no shortage of need for engineers who understand AUTOSAR. Just like with MBD, the roles will be quite varying, and some new ones will be created. An engineer could spend a career on any of the items described in the pyramid below. An engineer could also grow and span across these roles. In a small organization, that is likely to be the case. In a large organization, the scale of the development and size of the team dictates a different structure.

1.     AUTOSAR Engineer – Application software (SW) engineers
2.     AUTOSAR Engineer – Run-time environment (RTE)
3.     AUTOSAR Engineer – Basic software (BSW) development
4.     AUTOSAR Engineer – Software integration
5.     AUTOSAR Engineer – User interfaces and design tools

Roles and responsibilities in an AUTOSAR environment

Summary

The sophistication of automotive hardware has begun to exceed the capability of in-house proprietary operating systems and, as with the PC and smartphone industries before it, a professional operating system and development environment is necessary for continued growth. In the automotive space, that platform is AUTOSAR. AUTOSAR is not proprietary like iOS. Its design is specified by an industry consortium of major OEMs and Tier suppliers.

The adoption of a worldwide industry-standard platform for automotive software development means that as time goes by, more and more of the electronic components on production vehicles will be required to support AUTOSAR for integration onto the vehicle network. For engineers this is a major opportunity for career growth, and at the same time a risk of obsolescence if the knowledge is not gained. The foreseeable future for an AUTOSAR engineer is very bright indeed!  

Interested in learning more about AUTOSAR for your organization? Contact our team today! 

Further reading and references

• What is Adaptive Autosar
• The Top Five Considerations When Migrating to AUTOSAR-based Software Development