5 AUTOSAR Expectations vs. Reality

5 AUTOSAR Expectations vs. Reality

The automotive industry has been increasingly focusing product innovation on software development rather than hardware design. Software growth leads to more complex software. With multiple suppliers playing the field, there’s not much space at a vehicle level to utilize resources from different controllers. This has driven original equipment manufacturers (OEMs) to shorten the amount of time it takes to get their products to market. One way to make these goals a reality is by adopting the AUTOSAR methodology.

The adoption of AUTomotive Open System ARchitecture (AUTOSAR) as the software architecture for on-road vehicles has increased drastically over the past years. Most of the major OEMs have made it a requirement for new developments. With the push for its utilization came the need for learning and adapting the development teams to it. After having years of experience with various customers, including OEMs, and tier 1 and tier 2 suppliers, we have seen various cases where the expectation of our customers does not meet the reality of the implementation of AUTOSAR. This article presents a few examples that we have encountered and discusses what might be behind those findings.

Expectation 1: It should be easy to port existing code to AUTOSAR

To implement a proper AUTOSAR architecture, care should be taken when using Complex Device Drivers (CDD files). It might be tempting to adapt existing code using CDD files, but this strategy should not be used throughout the project otherwise, the implementation will not be taking advantage of some of the most important benefits of using AUTOSAR, such as reusability and portability.

While the CDD files are important to implement additional functionalities that are not offered by AUTOSAR, such as a complex control algorithm that is implemented using a model-based design (MBD) tool, they should be used to model a function outside of the normal AUTOSAR Basic Software, especially for hardware that is not directly supported by AUTOSAR, such as light emitting diodes (LED) drivers, Three Phase Gate drivers, Universal Asynchronous Receiver/Transmitter (UART), and I2C.

It is crucial not to rush, especially during the initial phases of the development. It is important to invest the necessary time in developing a software architecture that follows AUTOSAR architecture. By doing this, the advantages of using AUTOSAR will increase significantly, and the portability issues are minimized.

Expectation 2: If I configure my application and generate the code, it should be sufficient; minimal need to test

Some companies might believe that the code generated after the configuration is done is reliable and requires minimal to no testing at all. A few important factors need to be considered to trust the generated code and reduce the number of tests.

A key factor is the maturity of the development tool being used. Over our experience with AUTOSAR development, we have found issues related to the tools, especially if the version that is being used is new and might still present a few bugs. Choosing the version recommended by the microcontroller supplier aids in minimizing the errors that might be generated by the tool.

It is also important to apply skilled personnel for the key tasks to lead the team and to make sure that the tools are used appropriately according to the limitations.

In summary, it is important to make sure that the team knows the limitations and what can or cannot be done. The generated code should be verified and functionality should always be tested.

Expectation 3: AUTOSAR is designed for reusability

AUTOSAR architecture is designed to allow the reuse of software components in various applications, increasing flexibility and reducing the cost of development if the software is properly architected.

The challenge, in a real-world application, is that some OEMs might enforce the utilization of their own architecture or software components. In those cases, the reuse of previously developed software components by the supplier might be reduced. The main challenge, in this case, is to integrate the architecture provided by the OEM with the existing components and architecture.

Once again, the skills of the resources utilized, the previous experience, and the ability to understand the needs of each specific project are key factors to reduce the development time and increase the quality.

Expectation 4: The portability to another family of microcontrollers will be easy

The portability to a different family of microcontrollers is facilitated with an AUTOSAR architecture, but it still requires an in-depth knowledge of the differences between the microcontrollers. It is necessary to understand the limitations and the need for adapting the previously developed code. Many configurations are still required and need to be done very carefully to achieve a successful transition from one application to another family of microcontrollers.

From our previous experience with this task, it is important to not underestimate the complexity involved in this task and to apply experienced personnel to minimize the chances of errors and reduce the time for adapting the code.

Expectation 5: Using a multi-core processor will not add much complexity to the development

In order to meet the requirement for additional processing power, a solution has been to use multi-core processors. One problem related to that is that the additional complexity needs to be taken into consideration in order to maximize the advantages of using a multi-core processor. Examples of the additional complexity are the scheduling of the tasks, extra communication buses, handling communication between the cores, and handling the internal memory.

This additional complexity is often underestimated. The architecture needs to be reassessed and updated in order to fully take advantage of the additional processing power.

Conclusion

Most of the perceived limitations in the use of AUOTSAR are not related to the tool itself but to the lack of knowledge and experience of how to make the best of AUTOSAR. Some of the main factors that we believe are key factors to maximizing the advantages of using AUTOSAR are:

• Valuing the initial effort to develop a software architecture that is truly AUTOSAR driven, not focused on maximizing the reuse of legacy code.
• Choosing the right development tools is crucial for the success of the team. Once a tool is chosen, it is very important to understand its limitations and details of configuration. The developers must understand what they are doing and which tests are needed.
• The use of experienced personnel is critical in all phases, from the conceptual architecture phase to its implementation and testing. It is important to deploy a team that has the necessary experience to successfully implement a solution, minimizing the risks of cost and schedule overrun.

LHP has years of experience in the use of AUTOSAR for embedded software applications with a team of solution architects and experienced software developers. Our team can be used for consultancy, hands-on implementation, or even training existing teams.

Contact our team today! 

Further reading and references

• The Top Five Considerations When Migrating to AUTOSAR-Based Software Development