Hello Readers,
My name is Aravind B. N., and I work at Luxoft India as a Junior Software Developer. Luxoft has given me several opportunities to work on various projects, which has inspired me to discuss the important processes involved in learning the Autosar Basic s/w and Runtime Environment (RTE).
Introduction
Before going to the topic, let's know the simple basic concept of the AutoSAR layers.
Application layer:
The Application Layer is responsible, for executing the application functionality of the Electronic Control Unit. It comprises software components.
Service Layer:
The Service Layer offers a variety of background services, such, as memory management and bus communication services. Additionally, the operating system is included within this layer.
ECU Abstraction Layer [ECUAL]:
The Electronic Control Unit (ECU) Abstraction Layer provides a consistent way to access all the features of an Electronic Control Unit, including communication, memory and I/O. This applies regardless of whether these functionalities are integrated within the microcontroller or implemented through peripheral components.
Microcontroller Abstraction Layer [MCAL]:
The Microcontroller Abstraction Layer consists of drivers that are specifically designed to interface with the microcontroller's memory, communication and I/O functionalities.
Complex Device Drivers [CDD]
The Complex Drivers contain the drivers for the soecific properties of a microcontroller or Electronic Control Unit (e.g. complex peripheral devices) which are not standardized in AUTOSAR. They comprise functions for sensor evaluation and controller monitoring with
direct access to the microcontroller.
Basic Software:
An AUTOSAR system is described using Software Components, which are connected through the VFB (or ECU RTEs). This abstraction may give the impression that AUTOSAR Basic Software solely focuses on communication. However, this is not true.
AUTOSAR Basic Software also offers Electronic Control Unit services such, as state management (ECU state and control of communication channels) diagnostic services, watchdog services, operating system functionality and management of nonvolatile memory. Even input/output (IO) is included within the scope of AUTOSAR standardization.
Semiconductor manufacturers play a role in the standardization of the topic, input and output. They supply the low-level software layer (MCAL). As a result of this standardization certain issues that were previously handled by Electronic Control Unit suppliers now fall under the responsibility of software suppliers.
The graphics (as shown in the above figure), on the demonstrate the software architecture of MICROSAR, which's the Vector implementation of the AUTOSAR Std.
The Basic Software's attributes
Software components can only adopt abstraction if the necessary mechanisms are available, from the Basic Software (BSW). To achieve this the BSW complements the Runtime Environment (RTE) by providing these mechanisms. This is especially evident in terms of the communication stack and operating system which are closely intertwined with the RTE and its functioning.
For instance the BSW is responsible for generating events and supplying timers for the RTE. It also facilitates data transfer across Electronic Control Unit boundaries through communication buses. As for executing Runnable Entities within software components both flow control and system state management fall under the purview of software. Additionally it offers synchronization primitives to ensure access, by processes.
Runtime Environment:
Optimal Configuration Overview
The efficient Run Time Environment (RTE) is required to implement the communication and call mechanisms described in the Software Components. When formal descriptions of the SWCs are available it becomes possible to analyze the software design and derive, generate and optimize the runtime environment.
The formalized description of a software design includes information, about how a Runnable Entity's called within its context and how it interacts with parts of the same SWC or another SWC. By considering constraints, like the configuration of the software decisions can be made regarding the optimal implementation of a function call.
To effectively manage the system, we need to make decisions, about.
Choosing a method to prevent access, from running entities if necessary.
Deciding on the method of making calls.
Direct calls (like a macro or C function call)
Calls triggered by an RTE Event in conjunction, with the operating system.Determining the type of write or read access.
Accessing a Calling an API of the Basic Software.
Calls can be made either directly like a macro or C function call or through an RTE Event triggered alongside the operating system.
We also need to consider the type of read or write access required. This could involve accessing a variable or making API calls in the Basic Software. It's important to consider the semantics of access types and how they are implemented.
The specific configuration will determine the impact of these decisions, on performance.
Generally the generator, in the runtime environment should minimize its reliance, on OS events and alarms. By configuring the system appropriately valuable resources can be. Execution time can be reduced. To achieve this it is important to comprehend the impact of design choices made during the software components design phase.
Basic S/w Dependencies on original equipment manufacturers
One characteristic of AUTOSAR software is its modular nature. This modularization occurs both horizontally dividing it into task areas or clusters and vertically splitting it into abstraction levels or layers. AUTOSAR allows for levels of granularity, in the Basic Software, known as Implementation Conformance Classes (ICC). This flexibility enables the combination or clustering of BSW modules ranging from a software consisting of just one module to a comprehensive basic software covering all functionalities.
It's important to note that AUTOSAR Basic Software is not necessarily specific to an Original Equipment Manufacturer. However there are aspects where the BSW stacks of Original Equipment Manufacturer's typically differ.
For instance these stacks may vary in terms of the number and task areas allocated to BSW modules that're not part of the standard AUTOSAR. Additionally there might be extensions, in the form of Software Components added to the AUTOSAR Basic Software stack.
In the structure of the Basic Software there are variations, in the following areas;
- Diagnostic Event. Diagnostic Communication Manager
- Handling of communication channels
- Network management
- Gateway functionality for communication
- Specific services like encryption modules and proprietary transport protocols
When it comes to configuring the Basic Software there are also differences in work processes among Original Equipment Manufacturer's;
- The way Original Equipment Manufacturer requirements are provided (such as.dbc file, ECU Extract of System Description or separate SWC descriptions)
- Diagnostics layout and parameter setting (using ODX, CANdela file, etc.)
- General requirements, like build configuration capability of the communication stack and delivery of libraries to suppliers
The graphics (as shown in the top figure), on the demonstrate the software architecture of MICROSAR, which's the Vector implementation of the AUTOSAR Std's.
Basic Software Origins
Suppliers have approaches when it comes to handling the software among Original Equipment Manufacturers.
For instance there are models where the Original Equipment Manufacturer has already obtained the rights to the hardware components of the fundamental software, from a specific software producer. In situations the supplier only needs to acquire the hardware components. On the hand in some cases the Original Equipment Manufacturer supplies the supplier with pre integrated basic software packages, for various target platforms without any cost involved.
In some cases the Original Equipment Manufacturer specifies the functionality of the software modules, for other models. However they leave the implementation and integration of the Electronic Control Unit up, to the supplier. The supplier then has the flexibility to procure these modules from software producers. Integrate them into a comprehensive basic software package on their own.
Some major suppliers have developed their versions of AUTOSAR software and therefore also serve as software producers for these, in house developments. Depending on the relationship, with the Original Equipment Manufacturer there may be negotiations needed regarding the utilization of this software.
Top comments (0)