AUTOSAR Feasibility and Producibility

AUTOSAR feasibility and producibility

Feasibility and producibility in AUTomotive Open System Architecture (AUTOSAR) development refer to analyses performed by engineers or developers. The goal is to determine whether a particular project can or should be pursued and whether AUTOSAR is the toolset and framework it should be developed within. These studies are often multi-phase and often seek to answer questions about the technical feasibility of a proposed project and the estimated risks and cost-to-benefit ratio that the project entails.

Before the advent of AUTOSAR’s standardization and reusability/scalability requirements, software components for electronic control units (ECUs) were often completely rewritten from scratch for both new iterations and scaling efforts. AUTOSAR as a programming standard and framework makes reiteration of a program, or scaling a project up or down, much more feasible. AUTOSAR-compliant products are therefore also more producible. Communication between vehicle-network nodes, the integration of a customer’s specific individual requirements, and the ability to accelerate ECU code development are some of the most salient features of the AUTOSAR framework.

Contents

• Inter-and-intra-ECU communication across all nodes of a vehicle network
• Easy integration of customer-specific functional software module components
• Opportunities for accelerated development
• Summary

Inter-and-intra-ECU communication across all nodes of a vehicle network

Communication and data exchange, whether between ECUs or within a single ECU, is prescribed by the architecture and construction of an AUTOSAR-compliant ECU program.

AUTOSAR’s architecture is defined by layering, abstraction, and modularity.

Abstraction is the mechanism for separating and hiding lower-level details of these distinct layers. Abstraction leaves only the APIs, or Application Program Interfaces, exposed. APIs provide for regulated, explicitly defined communication between layers, modules, and ECUs. Layering is the concept of creating distinction between levels of abstraction within an ECU. Modularity is a “divide-and-conquer” approach to design and development, whether in automotive software or anything else. Modularity takes a large complex system and divides it into smaller component parts called modules, which can be developed independently. In AUTOSAR, this involves breaking down ECU programs into discrete packets of code that can easily be repurposed, re-scaled, and reused.

Intra-ECU communication is when data is exchanged between software components that are running on the same ECU. When there is communication between a software component located in one ECU and a software component located in a different ECU, this data exchange is called Inter-ECU communication. This is much the same distinction as between the terms internet and intranet. We must differentiate whether data is moving within a single control unit or between separate control units.

Note that these software component modules can be any component located on the ECU, whether an application, service, sensor, or other type of software component. Communication mechanisms such as inter-and-intra-ECU communication are only dedicated to data exchange between software components and ECUs within the same vehicle; this article does not cover vehicle-to-vehicle or vehicle-to-infrastructure communication.

What controls inter-and-intra-ECU communication?

The Runtime Environment (RTE), acting as middleware, handles much of the communication within an AUTOSAR program, whether within or between software components. The RTE implements Virtual Function Bus operations, whether as defined “function calls” or via an underlying bus through the Communication Stack.

• The Runtime Environment (RTE) is one of the three main layers found in Classic AUTOSAR. Along with the RTE, Classic AUTOSAR comprises an Application Layer and a Basic Software Layer (with sub-layers). If the Virtual Function Bus is an “interconnection concept,” independent from physical infrastructure, the RTE is the actual representation of it.
• The Virtual Function Bus (VFB) is a software interconnection mechanism. The VFB provides “a virtual infrastructure that is independent of any actual underlying infrastructure and provides all services required for a virtual interaction between AUTOSAR components¹.”
• AUTOSAR’s Communication Stack is the mechanism on the programming framework of each ECU that implements AUTOSAR-defined interfaces to send and receive messages between ECUs.

These three components work together to provide the communication required between ECUs, as well as the communication between the separate modular software components operating on each individual ECU.

What are the “nodes” in a vehicle’s communication network?

The nodes are the separate devices within a vehicle’s communication network. Nodes are both located on the network and connected to one another by the network. The network in turn comprises the nodes. The nodes are all the ECUs or any device connected to the network with communication software embedded in the hardware. For modern vehicles, this network is called a Controller Area Network (CAN).

When we speak of nodes in a communication network in automotive, we mean all the ECUs in the vehicle. Each ECU is its own network node. Controllers (ECUs) used to be connected only via wiring harnesses. As the quantity and complexity of ECUs have increased drastically over the past roughly twenty years, the wiring required to maintain communication and function throughout the vehicle has also become increasingly complex. With AUTOSAR and the CAN bus system, developers, suppliers, and manufacturers can begin to decrease the complexity of the wiring harnesses required throughout the vehicle. This makes the entire communication network on the vehicle more robust, due to its relative simplicity, as well as making the network more easily producible.

Easy integration of customer-specific functional software module components

AUTOSAR allows for the extension and scaling of software modules, as well as integrating modular software components that perform specific customer-required functions. This comes from the flexibility of both the AUTOSAR Classic and, especially, Adaptive AUTOSAR programming frameworks.

Because of the layered and abstracted nature of AUTOSAR-compliant ECU program architecture, custom function-specific modular software components can be added easily without disrupting the communicability of the entire vehicle network. Custom-function modules must utilize AUTOSAR-defined interface types prescribed for the specific type of software component.

The ease of integration for these functions demonstrates the feasibility of adopting the AUTOSAR platform and standard into an organization’s development process, as well as how adopting AUTOSAR can make the programming and ECUs in an organization’s existing product line, more producible.

Opportunities for accelerated development

One point which should be made clear, when discussing the differences between Classic AUTOSAR and Adaptive AUTOSAR, is that Classic AUTOSAR, while an earlier version of the standard and the programming framework, is not a “lesser” version. Classic AUTOSAR is exactly the right solution for many types of ECUs found within modern vehicles in production today.

However, Classic AUTOSAR is not the optimal choice for programming ECUs which use multiple-cored processors, for example, for data or graphics. Classic AUTOSAR can make use of the higher transfer speeds and greater bandwidth afforded by the fairly recent adoption of ethernet in the Controller Area Network. However, the Classic architecture, essentially unchanged since its 2006 release, was designed and optimized for legacy in-vehicle communication technologies. This makes it “difficult to fully utilize and benefit from the capability of Ethernet-based communications²” when using Classic AUTOSAR.

Because of its built-in dynamic flexibility, Adaptive AUTOSAR can make full use of newer automotive technology like automotive ethernet and high-power computing. These areas where Classic AUTOSAR is no longer the best-suited, are where Adaptive AUTOSAR can fill in the gaps. Adaptive AUTOSAR has greater flexibility, for example, in core scheduling: it can dynamically assign tasks to cores for balanced loading, based on usage. AUTOSAR Classic, by contrast, has a static task scheduling algorithm and typically loads one core to near-max capacity before scheduling overflow tasks to another core within a processor.

This added capacity and flexibility makes Adaptive AUTOSAR the better choice for programmers and developers working to develop ECUs in higher-order functions like Advanced Driver Assistance Systems (ADAS), as well as the environment perception and vehicle connectivity systems they rely on. These more complex functions tend to require high-performance computing, with multiple cores and multi-core graphics or data processing units, to interpret and act on information in real time. These more complex functions also take greater advantage of the bandwidth and much higher data transfer speed (compared to CAN bus or other legacy communication) granted by automotive ethernet layers within wiring harnesses.

Having the Adaptive AUTOSAR standard and programming framework for these newer, higher-powered, and more complex ECUs and the features that they enable is a great aid to developers and programmers, in almost exactly the same way that Classic AUTOSAR is a great aid in developing and programming for the ECUs that it was intended to service. Both the Classic and Adaptive AUTOSAR frameworks aid in the development of code for ECUs.

Summary

When performing assessments regarding a proposed project’s likelihood of success, or how easily it might be produced, the preceding facts regarding the features and relative merits of Classic and Adaptive AUTOSAR should be of great value.

Adopting AUTOSAR’s standardized architecture and development toolset can increase the speed of code development, especially in later iterations as multiple tools can be saved to the AUTOSAR library, and reused or scaled to match the new iteration’s needs.

The configuration management, interoperability of the platform, and third-party tools allow for precise integration of customer-specific features into an organization’s AUTOSAR-compliant product.

Adopting AUTOSAR’s standardized architecture and large library of available tools will increase the feasibility and producibility of any proposed ECU program development your organization is considering.

1. Nico Naumann. “AUTOSAR Runtime Environment and Virtual Function Bus.” 2009. https://hpi.de/fileadmin/user_upload/fachgebiete/giese/Ausarbeitungen_AUTOSAR0809/NicoNaumann_RTE_VFB.pdf
2. AUTOSAR.com. “Explanation of Adaptive Platform Design.” 2011. https://www.autosar.org/fileadmin/standards/R22-11/AP/AUTOSAR_EXP_PlatformDesign.pdf