As we are all well aware, the automotive industry worldwide is rapidly moving toward the AUTomotive Open System ARchitecture (AUTOSAR) tool and integration environment for the development of embedded software. In many ways this is a long overdue maturation of the industry from the early days of company-specific operating systems and software development environments which were lacking in scalability and interoperability. This move also mirrors the earlier transition of desktop software development from the splintered early days to the universal UNIX® and Microsoft Windows development environments of today. As a result, suppliers large and small across all automotive domains are thinking about migrating their own software development environments to AUTOSAR, often without a very clear understanding of what steps that entails and the impact that migration has on the entire software development organization.

AUTOSAR- Complete Webinar Series

As a consulting company, we at LHP have worked with a number of automotive companies that have effectively made the transition to an AUTOSAR development. Based on this experience, we have identified the top five considerations that will facilitate the transition by helping to establish clear goals and plan effectively for the unavoidable impacts that will have to be managed in order to achieve a successful transition.

The Top Five Considerations

AUTOSAR Infographic


1. Set your organization’s goals for the migration based on a realistic expectation of what you expect to achieve from the effort.

The term AUTOSAR is very often misunderstood, particularly by an organization that has no direct experience with AUTOSAR, or when experience comes from having worked with AUTOSAR in a different organizational context.

    • Many people associate AUTOSAR with a set of Basic Software Modules (BSWM) that interacts with the low-level drivers and provides middleware functions such as communications, diagnostic management, task scheduling, mode management, etc. – the sort of platform software that would formally have been developed by a low-level (non-application) software development team.
    • For a Tier 1 component developer, AUTOSAR usually means a set of professional tools for software architectural design at the level of the software application. Gone are the Excel® spreadsheets and Visio® charts, replaced by Unified Modeling Language™ (UML®)-style graphic designs that automatically generate the component interfaces and manage data structures.
    • In the context of an original equipment manufacturer (OEM), AUTOSAR can be a vehicle-level design tool for managing EE interfaces and allowing for early prototyping of the vehicle architecture against a virtual function bus, and then extracting that vehicle design to a multitude of suppliers with the responsibility for implementing the functions laid out in the vehicle-level interfaces.

AUTOSAR is not one size fits all. For a small product footprint there may be very limited benefit to adopting all of the implications of AUTOSAR when only the external interfaces need to be compliant to OEM requirements. AUTOSAR offers many different granularities (Implementation Conformance Classes) of the stack up to a monolithic basic software. For products which may be too constrained to entirely migrate to the AUTOSAR platform, it is possible to implement an AUTOSAR front end with a non-AUTOSAR backend based on more advanced Portable Operating System Interface Operating System (POSIX OS), or a less sophisticated OS for time-sensitive data processing such as a demand-side platform (DSP). Decide how your organization plans to use AUTOSAR, based on its unique product and development environment.

AUTOSAR- Complete Webinar Series


2. Choose an approach to AUTOSAR that is appropriate to the company objectives and that is in line with the product and organizational needs.

It is often the case that the driving force behind AUTOSAR adoption is the customer requirements for component integration, and that may very well be the only consideration for the migration. But the customer requirement can be an impetus to re-evaluate the current organization, and consider the adoption of other elements of the AUTOSAR ecosystem including the platform software, architectural design tools, and other parts of the ecosystem tools for virtual analysis and software validation.

As platform features become more complex, there is a declining benefit from the custom development of features that are required only to support the application software; features such as cryptographic protection mechanisms for cybersecurity of the vehicle interfaces, multi-core hardware support with the associated protections for the data integrity, and new features such as Controller Area Network with Flexible Data-Rate (CAN FD) and Ethernet. As these functions become standardized by AUTOSAR there is declining benefit to investing development money and energy in something that does not differentiate the product or add to the company intellectual property (IP).

Similarly, the rise of functional safety in automotive software development requires a more systematic approach to the architectural design of the software, distinct from the functional implementation. A well-developed migration to AUTOSAR can help to solve this problem as well, in addition to other process requirements for safety, cybersecurity, and software quality.

3.Understand the full impact of AUTOSAR across the entire software development workflow.

AUTOSAR methodology imposes some significant constraints on the software development workflow because it impacts the software development, integration, and software release processes. Since the AUTOSAR tools are designed against the AUTOSAR specification they provide little flexibility for the organization to deviate from these workflow constraints. A sampling of some of these constraints are as follows:

  • AUTOSAR is designed to have maximum deployment flexibility at the component-design level of the process. Application components are independent of the underlying hardware and Basic Software (BSW) services; they are also independent of their architectural deployment. For example, in one application any two components could be deployed to the same engine control unit (ECU), and in another application, they could be deployed on different ECUs. At the time that the component is designed there is no assumption as to the source of input’s signals/events or the destination for output signals/events. This delays the signal mapping until later in the process. While this provides great flexibility for reusing the same component in multiple applications without change (and without component retest), it places a heavy burden on the integrator who may not have the detailed knowledge of the data dependencies and requirements.
  • AUTOSAR tools add many additional steps (and a hardware dongle) to the software development and integration process, which can make it much more difficult to produce engineering builds for test and validation prior to software delivery. In a poorly designed process, the Software Integration team can become a significant bottleneck in the organization, providing only periodic integration builds for test, and driving a process whereby software changes are delivered to an integration stream without having been first integration tested by the developer in a private sandbox, compounding integration issues when the combined integration build is released.
  • Interfaces in AUTOSAR have many more parts to them than most legacy architectures, which means that the management of the inter-component (and inter-team) resources must be carefully managed and controlled. Because the various parts of the interface can be spread across multiple AUTOSAR Extensible Markup Language (ARXML) files, managing changes through file-based configuration management systems can become difficult.
  • AUTOSAR tools are the only environment where the full system architecture is visible, and that includes interface data elements and client server definitions. This environment does not integrate well with the development environment, be it model-based design (MBD) – Simulink – or code based. Since the AUTOSAR tools and skills may not be available to all developers in the organization, this can become a roadblock to collaboration and full system visibility.
  • AUTOSAR adds additional file-based resources which must be managed by the development process. Each component version will have at least one ARXML architectural description file, at least one software code or model file, additional files for intra-component data definition, possibly a test harness and unit test results. These artifacts must be managed and delivered as a combined package (you cannot mix versions between architecture, implementation, data files), which causes additional complexity in the software delivery and integration process.
  • AUTOSAR specifies the properties of all BSW services, and it is not possible to deviate from this without modifying the standard AUTOSAR code and deviating from the published standard. For example, every configurable element in the BSW is specified as compile, link, or runtime configurability, and this can impose serious constraints on the variant management strategy when a user is used to supporting multiple variants with the same software release.
  • A stated goal of AUTOSAR is to commoditize the lower-level platform software development into a smaller group of tools vendors, while allowing application developers to focus their development on their own core intellectual property. In practice however, the tools vendors will prioritize resources to the highest-volume hardware, which can leave smaller players with more customized hardware in a dependent position to the vendor’s own roadmap, and cutting-edge users acting as beta testers for the Session Initiation Protocol (SIP) releases.

Guide: Why ISO 26262 is only the beginning to a safer autonomous vehicle. Download now!

4. Plan for the organizational and resource changes that will be required.

AUTOSAR defines the framework of the software architecture to structure the software development and a flexible deployment architecture. This flexibility comes with the cost of additional formal roles which may not currently exist within the organization.

One of those roles is the software architect, whose role is to manage the allocation of requirements to software components, but also to define the software interfaces and the creation of multiple architectural views of the software structure and organization. With an AUTOSAR application, architectural changes can only be made through the AUTOSAR tools, and changes between components must be coordinated. It is sometimes impractical to provide the AUTOSAR tools and training to all developers in a large organization, and funneling changes through an architect can become a significant bottleneck in the process.

Another important role is the software integrator, whose job is to integrate the software components and ensure that all the interfaces are properly connected in a variety of different product configurations. AUTOSAR requires many more steps in order to produce a software build, including AUTOSAR integration and generation of the runtime environment (RTE) for the specified integration architecture.

Depending on the complexity of the organization, it may be possible to distribute the role of software architect using a less formal approach, or in a larger organization a better solution is to automate the common tasks of the architect, including adding, creating and connecting interfaces, task scheduling and RTE generation.

For the platform software, AUTOSAR uses a configure-versus-build philosophy, which eliminates much of the need for platform software development. Furthermore, the AUTOSAR BSW developers become much more portable across product lines because the layered AUTOSAR architecture makes the platform configuration independent of the application software.

5.Develop a roadmap for transition of the existing software base with realistic milestones and measurable indicators.

While AUTOSAR employs industry-standard features for software development, it also defines its own flavor for the defining and handling of software resources that can have significant differences with many legacy software systems. Thus, porting of a legacy software system can require a significant redesign of the structure of the code, and likely involves management of many more resources and imposes more constraints than the organization is accustomed to. AUTOSAR also employs a very flexible deployment architecture whereby all the interface code is auto-generated from the architectural description.

The migration of the code base to AUTOSAR can be facilitated by effectively planning the re-architecture against established principles, and with the development of customized style guides and process rules.

Some of the major architectural constraints and considerations of an AUTOSAR application are as follows:

  • In an AUTOSAR application there is a clear separation of software execution control from the functional software design.
  • In AUTOSAR there is a clear delineation between application and BSW components.
  • Component and runnable interfaces are strongly typed to facilitate the portability of the components across the product line.
  • AUTOSAR utilizes a flexible deployment architecture, whereby the tools automatically generate the interface code, based on the architectural description of the software design.
  • Software components are readily portable across ECU modules as well as across cores on a single ECU.
  • AUTOSAR allows memory partitioning to support the separation of concerns and design for mixed Automotive Safety Integrity Level (ASIL) safety systems.
  • AUTOSAR provides a variety of variant management strategies.
  • Variation can be at the integration or component level.
  • Variation can be functional variation or architectural variation.
  • Variation can be at compile, link or runtime.

By clearly defining the expectations from the transition to AUTOSAR, as well as properly anticipating all of the steps and potential pitfalls in the migration, the organization will achieve a better end result, and stay in line with the global corporate strategy and expectations.

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



Further reading and references

Written by Dr. Steven Fraser

Dr. Steven Fraser is the Solution Architect for Model-Based Design (MBD) and Automotive Open System Architecture (AUTOSAR) at LHP. He was one of the initial employees when LHP opened their headquarters in Columbus, Indiana in 2001 and has primarily worked from LHP’s Detroit office since 2015. Steve is engaged as a consultant with a variety of projects in the development of advanced controls and OBD diagnostics in the automotive industry. Steve has been responsible for the development of first generation Diesel after-treatment control systems and diagnostics for the Diesel Particulate Filter (DPF), Nitrogen Adsorption Catalyst (NAC), and Selective Catalyst Reduction (SCR). He is also engaged in embedded software architecture design and test methodology including use of UML and AUTOSAR tools, workflow process design and optimization utilizing modern ALM toolsets, advanced physics and performance modeling including combustion modeling, development of IEEE standard and proprietary communication protocols. Steve is a Functional Safety Certified Automotive Engineer (FSCAE) and trains engineers at numerous companies for the FSCAE certification exam. Before coming to LHP, Steve had worked for 12 years in a variety of industries including satellite and terrestrial communication systems, robotics, and simulation modeling of large gas turbine power generation systems. Steve helped lead the development of a new software architecture for a multi-platform operating system and engine control application that received industry awards and continued to be used for over twenty years. He is also experienced with patent and trade marks consultation. Various international journals, conferences and symposiums have published Steve’s articles and he is the lead author for the LHP white paper, The Benefits of Model-Based Design. Steve received his Bachelor of Engineering, Masters of Applied Science, and Ph. D in Control Systems Engineering from Concordia University in Montreal, Canada. He also earned a Bachelor of Common Law / Civil Law from McGill University in Montreal, Canada, specializing in Intellectual Property and Commercial Law.