Why Use AUTOSAR for Embedded Software?

Every software engineer knows there are strengths and weaknesses to every programming language/architecture. Trade offs must be made to improve certain aspects of the system. AUTOSAR is no different. The key is finding the right tool for the job by determining which aspects you need more of and which you don’t. During my time working with AUTOSAR, I’ve found some aspects that AUTOSAR does well and some that it doesn’t. I’ll start with a brief overview of what AUTOSAR is and then jump into the nitty-gritty.

For those who don’t know, AUTomotive Open System ARchitecture (AUTOSAR) is a worldwide automotive development partnership. This software has become increasingly popular over the last decade and is used by many major automotive manufacturing companies. The popularity stems from the architecture of the software, which allows for more scalability and transferability of applications.

So what does AUTOSAR do well? As mentioned above, the software is more transferable. This means software can be easily shared between different vehicle systems largely independent of the system’s underlying hardware, which AUTOSAR improved by standardizing component interaction. In the past, and still today, most component software is developed according to the hardware it will be programed on. AUTOSAR reduces this constraint by implementing a standardized interface between application software and its hardware to allow for hardware independent component software (reference Figure 1.1). The standardized interface allows application software to communicate by utilizing a Virtual Function Bus (VFB). This VFB acts as a medium managing the communication between components. This allows application software to abstract out the communication specific. This abstraction of software is what allows it to be placed on varying systems.

Figure 1.1 – Comparison of Application Software with and without AUTOSAR. [1]

AUTOSAR also does well at making software more scalable. This is important if you are creating systems that have the potential to change and grow. Scalability allows software to adapt and grow without a major overhaul of the current system. AUTOSAR improved scalability by standardizing port interfaces. This helps to reduce confusion when dealing with large systems with hundreds of components. The components only need to know their inputs and outputs, similar to creating a function, without needing to know the functionality of other components. By using standardized interfaces, AUSTOSAR was able to create auto generating software platforms used to connect components. For example, the platforms I have used for AUTOSAR development are DaVinci Developer and DaVinci Configurator.

AUTOSAR partnered with MathWorks to allow for model based software development (MBSD) using Simulink. Simulink provides a graphical user interface (GUI) for developers to implement logs and tags for AUTOSAR code generation. I have found that MBSD is better for engineers who are not programmers that also work on the system. This gives them a visual representation of the system which allows them to more easily debug or alter the design as necessary.

The only downfall I have found using AUTOSAR is the workflow. The projects I’ve worked on have required several development environments working together making the workflow complex. Some of the tools needed were PREEvision, DaVinci Developer and Configurator, Simulink, Green Hills MULTI, Microsoft Visual Studio, and other Vector tools for testing. All these tools work together to create model shells, connect ports, create and define data types, generate code, test software, and much more. I found using this many environments to be a hassle at times and at points hindered the speed of development. Also, most of these tools require a license to use which increases the budget for application development.

When it’s all said and done, the time that is saved from making software more transferable and scalable will more than make up for the cost of using the software and the complexity of the workflow. It also saves time by providing an easy to read system model for personnel who aren’t familiar with coding languages. Overall, I feel the benefits of using AUTOSAR outweigh the drawbacks and I encourage you to check into it further for your future projects.

Sources:

  1. leonliuxue. (2015-08-12). Automotive Security. http://www.cnblogs.com/leonliuxue/p/4723222.html
Russell Rook

About Russell Rook

Russell is a Software Engineering Intern with DISTek. He has experience developing and testing embedded software through Model Based Software Development (MBSD), AUTOSAR, and C. He will graduate from University of Northern Iowa in the Fall of 2017 with a B.S. in Computer Science.

Share this post with your friends.........
Facebooktwittergoogle_plusredditpinterestlinkedinmail

Follow DISTek......
Facebooktwittergoogle_pluslinkedinyoutube