Post Page Advertisement [Top]

Here are some basic characteristics that AUTOSAR OS should have 
  • Should be configured statically(meaning the priority and properties of the tasks , stack size . etc.. are fixed at build time)
  • Real time responsiveness
  • provides priority based scheduling
  • provides protection features like memory , timing protection etc..
  • should run on low-end controllers and without external resources

With the exception of Telematic/Infotainment systems other ECU OSes conform to these characteristics .


Prior to AUTOSAR , OSEK standards was widely used in automotive field for OS. OSEK OS is an event-triggered operating system. Event triggering gives freedom for the selection of the events to drive scheduling at run-time, for example angular rotation, local time source, global time source, error occurrence etc. 

For these reasons the core functionality of the AUTOSAR OS was derived from OSEK OS. In particular OSEK OS provides the following features to support concepts in AUTOSAR:

  • fixed priority-based scheduling
  • facilities for handling interrupts
  • only interrupts with higher priority than tasks
  • some protection against incorrect use of OS services
  • a startup interface through StartOS() and the StartupHook()
  • a shutdown interface through ShutdownOS() and the ShutdownHook()
Application and Tasks

The OS scheduler manages tasks as basic units. A task acts as a container for specific functionalities of an application. An application can be subdivided into several tasks. AUTOSAR distinguishes two types of tasks. Basic Tasks can enter the states suspended, ready and running. Extended Tasks additionally have a waiting state. Furthermore, tasks can be defined as preemptive or non-preemptive. Once running, the latter can only be rescheduled in a very restricted set of cases. Tasks are assigned static priorities, which cannot be changed by the user at run-time. Only in the particular case of resource accesses ( Priority Ceiling Protocol ) the operating system can temporarily assign a higher priority to a task.

Tasks in-turn can execute AUTOSAR runnables

Task trigger Mechanisms

Tasks can be triggered using different ways like alarms or schedule tables


Periodic events/tasks are triggered using Alarms. An alarm mechanism consist of a counter and an action (or actions) to perform when a particular counter value is reached. Each counter in your system can have any number of alarms attached to it. An alarm is said to have expired when the value of a counter equals the value of an alarm attached to the counter. On expiry, OS will perform the action associated with the alarm

Alarms can be configured to expire once. An alarm that expires once is called a single-shot alarm. An alarm can also be specified to expire on a periodic basis. This type of alarm is called a cyclic alarm. Alarm on expiry can do one of the following actions

  • Activate a task
  • Raise an event.
  • Execute a callback function
  • Increment a counter
Schedule tables

With alarms if we want to activate multiple tasks , then we have to multiple alarms corresponding to each task.In addition if you want to trigger tasks with specific time delay between them , then it gets complicated with alarms because for synchronization we need to use the same counter for the alarms that triggers the required tasks and interruption during startup can add some unintended offset in the needed delay.To avoid this , we could use schedule table in these cases

Schedule tables are an extension of the alarm concept. Like an alarm, a schedule table is linked to a counter. It is composed of a set of expiry points, whose corresponding counter value is relative to the activation of the schedule table. When an expiry point is reached, one or more actions (task activation or event setting) are taken. A schedule table can be defined to be single-shot or cyclic. A schedule table describes completely the activation points of all the tasks of the system. When a task is activated, it runs until it completes


Category 1 Interrupts 

Category 1 interrupts do not interact with OS. They should always be the highest priority interrupts in your application. It is up to you to configure the hardware correctly, to write the handler and to return from the interrupt. The handler executes at or above the priority level of OS components. 

Category 2 Interrupts 

With Category 2 interrupts, the interrupt vector points to internal OS code. When the interrupt is raised,OS executes the internal code and then calls the handler that you have supplied. Execution starts at the specified entry point of the ISR and continues until the entry function returns. When the entry function returns, OS executes another small section of internal code and then returns from the interrupt

1 comment:

Bottom Ad [Post Page]