Autosar OS PART-1
Tags: architecture, tutorial, softwaredevelopment, software
Published: 2023-11-13 05:56:32

Hello Readers,
My name is Santosha S Chikkur, and I work at Luxoft India as a Junior Software Developer. Luxoft has given me several opportunity to work on various projects, which has inspired me to learn the essential processes involved in developing an AUTOSAR Modulеs and Add-Ons in AUTOSAR OS Part-1

**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**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/b4tnsls3jpvtn9tsn3fx.png)

**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).


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ich6fswt3moxjtp5z4qh.png)

**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**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7uoqp19en55b2j97mxbb.png)

**OSEK OS. Processing Levels**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4c8z4bk60rs22v1w4zqa.png)

**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
1. Interrupts have precedence over tasks.
2. The interrupt processing level consists of one or more interrupt priority.
3. ISRs have a statically assigned interrupt priority level
4. 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**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/h4ohuy0a5nn7qr2rykzx.png)

**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.


This will be continued in the next article, including examples.
Please let me know in the comments below if you have any questions.
Thanks for reading.