A new trend in automotive software: AUTOSAR concept Catalin-Virgil Briciu * , Ioan Filip * and Franz Heininger. ** * “Politehnica” University of Timisoara/ Faculty of Automation and Computer Science, Timisoara, Romania ** Continental Automotive Germany/Interior Body and Security, Regensburg, Germany briciucatalin@yahoo.com , ioan.filip@aut.upt.ro , Franz.Heiniger@continental-corporation.com Abstract—This article sheds light on one important aspect of the automotive industry: the AUTomotive Open System ARchitecture (AUTOSAR) concept that is the basis for development of the new modules inside of the automotive systems and represents the newest worldwide automotive trend. First part of the article presents the reasons why such a standard is needed and mandatory in the current financial and technical contexts. The second part presents the vision and the architecture of the concept. For a better understanding of the theoretical aspects presented above, last part of the article presents a lower complexity example about the way in which AUTOSAR modules shall be designed and the working method. I. INTRODUCTION We are living in the modern era where the time and money are getting more important in all field of activities. This includes also the software development domain, in particular automotive field, because the OEMs want to add more functionality in existing platforms or new platforms that includes these functionalities, but realized with the same financial and temporal constraints. More functionality implies a growing complexity of the developed software, a large number of the variants for the same car platform through the same or separated Electronic Control Units (ECUs). To be able to develop the new systems in the same period of time as their predecessors it is necessary to hire new peoples on the project or to work with the more experienced developers to add more value to the project. Both variants suppose that the development costs are increasing, so the first prerequisite is not fully fulfilled. These are just two main reasons for which a new concept should have to be introduced. A major problem [1][2][3] of the developed software or hardware modules in the automotive industry is a poor reusability (e.g. SW must be rewritten from scratch when the HW is changed or a change in the ECU functionality requires at least SW change in other modules) because of the high dependency between the OEMs and suppliers and the fact that embedded systems do not support the full HW abstraction or limited modularity. For this, AUTOSAR consortium introduced in 2004 a new concept in automotive programming paradigm: AUTOSAR development method. This was an important milestone in the development of modern automotive technology. This concept “realizes” that decoupling the basic software from the application modules and the transition from customer specific basic software modules to standard basic software modules and applications modules described through uniform interfaces are prerequisites for running functional code on different HW platforms. II. AUTOSAR ARCHITECTURE The major difference between AUTOSAR and the other embedded programming paradigms is the fact that the concept allows, in fact is mandatory, to divide the functionality from the entire ECU into standardized layers and components. In addition, this divide operation implies also defining the standard interfaces through the modules or different SW components. The benefits added by this standardization refers to scalability to different vehicle and platform variants, integration of functional modules from multiplies suppliers, consideration of availability of safety requirements and reusable SW components and applications. It is important to mention that AUTOSAR is a public architecture, but to be used in commercial purposes needs a paid certificate from the consortium board. Without certificate, in all other cases, the software companies cannot sell the software packages under the AUTOSAR brand. Currently, the architecture of the embedded systems is not completely modular and a change in HW modules affects for sure not only the hardware abstraction modules but the other software modules, which shall be changed in this case. Figure 1. Current situation in the automotive programming