Infographic | AUTOSAR Migration

Written by Dr. Steven Fraser | Aug 11, 2020 2:12:07 PM

As we are all well aware, the automotive industry worldwide is rapidly moving toward the 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.

As an AUTOSAR consulting company, we at LHP have worked with a number of automotive companies that have effectively made the transition to 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

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 interact with the low-level drivers and provide 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 that 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 a 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.

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 a declining benefit to investing development money and energy in something that does not differentiate the product or add to the company's 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 is 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 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 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 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, and 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, and 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 reconfigurability, 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 tool 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 on the vendor’s own roadmap, and cutting-edge users acting as beta testers for the Session Initiation Protocol (SIP) releases.

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 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 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, 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 the 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 a 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.