Model based software design lecture notes

AUTOSAR Introduction

The goal of these lectures is to understand the idea behind AUTOSAR and why automotive is pushing toward this direction.

AUTOSAR is an open architecture for the software to be deployed inside embedded control units (suspension control, powertrain control unit and so on).

The philosophy behind AUTOSAR is shown in the following figure, where the main players are reported:

• General OEM: car manufacturers, the ones that ask for a certain product.
• Generic Tier 1: ECU suppliers

Since general OEM want to deploy electronic components, but they have no time and enough knowledge, they rely on ECU suppliers (tier 1). Tier 1 provide sub-assembly with mechatronic components and software. Behind a single ECU there are a lot of parts both on software side and hardware side. The main purpose of AUTOSAR is to spread the idea of using standard components for both categories.

In addition to hardware and software, there are tools and services industries that provide tools.

The solution is to implement AUTOSAR, which stands for Automotive Open System Architecture. AUTOSAR is a standardized software architecture that allows for the development of automotive software components that can be easily integrated and reused across different vehicle platforms.

AUTOSAR provides a layered approach to software development, with each layer responsible for specific functionalities. This allows for modularity and flexibility in the development process, as well as easier maintenance and updates.

In addition, AUTOSAR promotes the use of standardized interfaces and communication protocols, ensuring compatibility and interoperability between different software components and hardware devices.

By adopting AUTOSAR, automotive companies can reduce development time and costs, as they can leverage existing software components and collaborate with other companies in the industry. Tier 1 suppliers, such as semiconductor companies, play a crucial role in this ecosystem, providing the necessary hardware and software drivers to connect the different layers of the AUTOSAR architecture.

In conclusion, AUTOSAR offers an efficient and cost-effective solution to the challenges faced by the automotive industry, allowing for faster development, easier integration, and improved collaboration among different stakeholders.

An off-the-shelf production (like a lego).

Architecture description

Hardware: it provides certain features, for instance there are some sensors, some ADC or DAC chains, microcontrollers exc.

Basic software: intended to provide a standardized set of services that AUTOSAR specify. (learn by heart).

Application: the application that this architecture is intended to perform will use the standardized services to accomplish the desired tasks. Such application is decoupled from the hardware platform.

The advantage lies in the standardized word: if the basic software is standardized, we can decouple the process of application development and hardware development, because the application is based on the basic software, but if it is standardized, it is known in advance, therefore, the developer already knows which are the "functions" to call. The application is developed in parallel to the hardware platform, knowing in advance that some services (able to access the platform), will be available.

Furthermore, it is possible to test the application without having the actual platform: since the services are known, a software could be used to simulate the presence of the real platform. Such software will be used to simply simulate the execution of the services. The development of the application is performed in parallel with the development of the platform, they are concurrent, not sequential. Moreover, in this new scenario we can ask a company to provide only the hardware and the basic software, whereas another company to deploy the application, because the interface is standard. The OEM could better control the cost for developing the platform by assigning to possibly competitors the realization of these components. The tier 1 will have a broader market since the basic software (the interface) is standard, everyone uses the same interface.

When modelling an ECU, we have two pieces: the software components (top boxes) and the hardware components (bottom boxes, the ECUs). Such components

are deployed separately and concurrently.

Application developer: he receives a certain request from the OEM. He neglects the details of the hardware platform. He deals with abstract components: the AUTOSAR services that will interface with the hardware. Each component of the top boxes (software component) describes a software operation (actuation of some actuator, controllers and so on) and it can be developed in different ways (hand-written, auto generated, bought from companies…). Each software component is able to interact with the others by means of protocols. Such communication will be performed on the hardware obviously, but at the application layer, there will be only a virtual functional bus that specifies only that there is a connection (not how practically it is deployed).

Hardware developer: he needs to establish the power needed to accomplish the tasks. According to AUTOSAR, there could be many different ECUs, not only one to run the application, moreover, they could come

from many different suppliers. The hardware developer could simply merge different specific ECUs.

Once the two components are prepared (application and platform), it is necessary to merge them together. AUTOSAR provides the tool chain to establish which software (top boxes) must interact with any of the ECUs present in the platform, knowing which the capability of the single ECU and the queries of the software are. 65

Let's imagine buying some ECUs and deploying only one from the scratch. While developing the application we do not take care about this information, we do not care about the fact that different ECUs will have to cooperate, we only know that there is a communication. Such communication is specified in the tool chain: AUTOSAR will take care about the software to allow the cooperation between ECUs. When the software component 3 is asking for a service for the software component 1, the implementation of the software component 3 will ask the runtime environment ECU 2 to generate

bus transfer on a connection, that will be taken by the runtime environment ECU 1, which will forward the request to the software component 1.

To recap: when modelling with the virtual functional bus, the elements of our application are called software components. Such components interact through abstract interfaces (protocols). The transport mechanism is not defined at the virtual functional bus (only the fact that a communication is present is defined). When we move forward to the platform, we define where the single software component will be allocated in the single ECU. At that time the implementation of the communication is decided; such implementation depend on the mapping, if the communication is inside the single ECU we do not need to access the network, we can use a global variable (shared memory).

Another important advantage is that the application is generic and can be used in different scenarios: let's say we have a vehicle with one ECU dedicated to each software and another

vehicle with only one hugeECU: the application is the same, because only the mapping is changed, but such mapping is not inside the application, it is handled by the central software. The advantage of this approach is that it provides a very high portability, we can focus our resources on the application and not on the portability. Software components are defined as atomic, since they cannot be partitioned on many ECUs, they must stay on a single ECU (one ECU can manage multiple software components though).

VFB: logical interconnections between software components (we do not know how the connection work, we only know that a connection is present).

RTE: code generated once the mapping between the software components and ECU is known. It implements the mechanism that the VFB uses to communicate.

BSW: it provides the services to enable the usage of the software components.

AUTOSAR classic: microcontroller, powertrain, body and comfort ecc.

AUTOSAR adaptive: specification intended for enabling

AUTOSAR for virtual machines. 67The application is sitting on the RTE, that is placed on the basic software which is before the hardware. 68Let’s start from the bottom: the microcontroller has some memory, some I/O ports, some A/D converterexc. The application layer does not want to have all the details about the hardware, therefore there mustbe an abstraction layer. Such abstraction is provided by the red block, it is sending a result, which containsonly the useful part for the application. The silicon vendors develop a piece of code dedicated to AUTOSARimplementation: the driver. The driver takes care about the information to pass (software) fromhardware.The green box ECU abstraction layer is responsible for the decoupling of the application from the specificcomponent in the ECU that is implementing that functionality. Such component could be within themicrocontroller, or a peripheral outside the microcontroller. The communication must be enabled, butwe do not care about the

place where the hardware is, we only care about the result. Such layer abstracts the physical location of the hardware providing that service (inside or outside the microcontroller).

Complex drivers: try to provide services that are not standard (for custom hardware, chip for controlling the injectors in a gasoline application).

System services are general purpose services that are hardware independent (think about the operating system, it does not depend on the hardware).

RTE: mechanism to implement the communication that are defined in the virtual functional bus. This is when the theoretical connection becomes a real connection.

Example: let's imagine we have an ECU that is in charge of getting two analog values (temperature and pressure). Two sensors are providing two voltages that must be converted in understandable values; therefore, they must be connected to an ADC line. Unfortunately, there is a problem: the microcontroller we own, has only one ADC channel of 12 bit (ADC0). Then, as

the pressure has to be sensed with a greater accuracy, we have to put in our ECU another component, an ADC with more bit (14) dedicated to the ADC conversion. ADC1 must be connected with the microcontroller, since it must provide the information to the microcontroller which is the only component running software. The connection is made by a special interface: SPI. To allow the communication we must have software functions that allow the actual hardware communication. Such functions are operating the single component that we have in our 69 hardware. These functions are referred to with the generic term “driver”. They program and operate hardware components (for instance ADC0 only reads, whereas SPI reads and writes). Each component must have a driver: ADC0 and SPI are peripherals inside the microcontroller, so the drivers that takes care of programming those resources will be placed in the microcontroller abstraction layer.

The ADC0 and ADC1 information must be available on the top level.