INTRODUCTION TO AUTOSAR OS

Hello Readers,

My name is Rajesh M, 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 learn the essential processes involved in developing AUTOSAR Modulеs and Add-Ons in Introduction to Autosar OS.

INTRODUCTION

The Automotive Open System Architecture (AUTOSAR) consortium is a collaborative effort among major players in the automotive manufacturing sector. Its goal is to establish a universal and open software architecture to address upcoming challenges in automotive development.

AUTOSAR Software Architecture

The Layers
AUTOSAR Software
The AUTOSAR Software consists of AUTOSAR software components that are mapped on the ECU. The AUTOSAR Runtime Environment serves as the intermediary for all communication between AUTOSAR Software Components and Atomic Software Components.
AUTOSAR Runtime Environment
The RTE offers a communication abstraction to AUTOSAR Software Components connected to it by providing the same interface and services regardless of the use of inter-ECU communication channels like CAN or LIN, FlexRay, MOST, etc.) or communication stays intra-ECU. The RTE provides an actual representation of the virtual concepts of the VFB for one specific ECU.
AUTOSAR Basic Software
Basic Software (BSW) is the standardized software layer, which provides services to the AUTOSAR Software Components and is necessary to run the functional part of the software.

Interface Definitions in AUTOSAR

AUTOSAR distinguishes between three types of interfaces:

AUTOSAR Interface
It is a generic interface, which is derived from the ports of any SOFTWARE COMPONENT (SWC). The RTE provides AUTOSAR interfaces, which act as connections between SWCs or between an SWC and the ECU firmware. This interface is application-specific and is generated together with the RTE.

Standardized AUTOSAR Interface
It is a special AUTOSAR interface predefined by the AUTOSAR standard. SWCs use these interfaces to access AUTOSAR services provided by BSW modules in the Service Layer.

Standardized Interface
It is an interface predefined by the AUTOSAR standard as an API in C language. It is used between BSW modules in an ECU, between the RTE and the OS etc.

BSW: Standardized and ECU specific modules

• Services (diagnostic protocols, NVRAM management, etc.)
• Communication (e.g. CAN, LIN, FlexRay), Network management
• Operating System
• ECU abstraction
• Microcontroller Abstraction DIO, ADC, PWM, EEPROM, Flash, WDT, SPI, I2C etc ..
• Complex driver (CDD)

AUTOSAR OS basic features the OS

• has predictable and documented behavior
• is configured and scaled statically
• supports implementations capable of running on ROM
• supports portability of application tasks.
• is amenable to reasoning of real-time performance
• provides a priority-based scheduling
• provides protection functions (memory, timing, etc.) at runtime
• works with cheaper drivers and without external resources
• AUTOSAR OS

The standard OSEK OS (Open System and the corresponding interfaces for Automotive electronics) (ISO 17356-3) is used as the basis for the AUTOSAR OS. OSEK OS is a mature specification and implementations are used in millions of ECUs worldwide.
The AUTOSAR consortium reuses the OSEK specifications
Certain features introduced by AUTOSAR OS require restrictions on the use of existing OSEK OS features or extensions to existing OSEK OS features.

AUTOSAR additions are segmented in Scalability Classes (SC).

Scalability Classes
AUTOSAR additions are segmented in Scalability Classes (SC).

AUTOSAR OS Add-ons

• Schedule Tables
• Timing Protection
• Memory Protection

• Scalability classes

• SC1 the OS implemented per the OSEK/VDX-OS standard and extended to include schedule tables

• SC2 the OS with time synchronization and monitoring of the time behavior of individual tasks and interrupt service routines

• SC3 the OS with memory protection mechanisms on MCUs with suitable hardware support

• SC4 combines scalability classes SC2 and SC3

• Multi-Core

The AUTOSAR standard (since v4.0) specifies some extensions that allow to use AUTOSAR OS on Multi-Core microprocessors.

The Multi-Core OS in AUTOSAR does not function as a virtual ECU concept. Instead, it should be viewed as an operating system that shares the same configuration and most of the code while operating on distinct data structures for each core.

SC1

• OSEK OS
• Schedule Table

OSEK OS

OSEK OS. Processing Levels

OSEK OS. Processing Levels
The OS handles two types of entities which are competing for the CPU:

• ISRs
• Tasks

OSEK defines three processing levels:

• Interrupt level
• Interrupts have precedence over tasks.
• The interrupt processing level consists of one or more interrupt priority.
• ISRs have a statically assigned interrupt priority level
• Assignment of ISRs to interrupt priority level is dependent on implementation and HW).
• Logical level for scheduler Assigning a priority to the scheduler is simply a conceptual idea that can be put into practice without the direct utilization of priorities.
• Task level. The priority of the task is statically determined by the user.

OSEK OS. Conformance classes

OSEK OS. Conformance classes

• BCC1 Basic functions only, limited to one activation request per task and one task priority, while all tasks have different priorities.
• BCC2 Similar to BCC1, more than one task is possible per priority, and multiple task activation requests are allowed.
• ECC1 Like BCC1, plus extended tasks.
• ECC2 Like ECC1 is allowed for basic tasks, as well as more than one task per priority and multiple task activation requests.

Conclusion

AUTOSAR OS is a real-time operating system (RTOS) designed specifically for automotive applications. It is based on the OSEK OS standard and includes several additional functions such as schedule tables, time protection and memory protection. AUTOSAR OS is available in four scalable classes (SC1, SC2, SC3 and SC4) that offer different levels of functionality. AUTOSAR OS is also available for multi-core microprocessors.