Autosar OS Part-2

Hello Readers,
My name is Santosha S Chikkur, 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 AUTOSAR OS Part-2

OSEK OS. Task management

Task concept

• Complex software can be divided into parts that work according to their real-time requirements.These parts can be implemented by means of tasks.
• The OS provides concurrent and asynchronous execution of tasks.
• The timer organizes the task execution order.

Two different task concepts:

• Basic tasks
• Extended Tasks

OSEK OS. Task management
Basic Tasks

Basic Tasks only release the processor, if

• they terminate, or
• The OSEK operating system transitions to a task with higher priority or.
• an interrupt occurs which causes the processor to switch to an ISR.

Basic tasks have no waiting state.

Extended Tasks

• Extended tasks are allowed to use the operating system's WaitEvent call, which can cause a wait state.
• The waiting state allows the processor to be released and to be reassigned to a lower-priority task without the need to terminate the running extended task.
• In view of the OS, management of extended tasks is more complex than management of basic tasks and requires more system resources.

Task state Transition

Task Activation

A task can be activated (moved from a suspended state to a standby state) by:

• the OS, at system start-up
• another task (service calls: ActivateTask, ChainTask)
• an ISR (service call: ActivateTask)
• an alarm expiration
• a schedule table expiry point (AUTOSAR extension)
• OsRestartTask (AUTOSAR extension) An extended task is moved from standby to standby (released) by setting an event.

Scheduling Policy
Full preemptive scheduling
A Task may be rescheduled at any instruction. The scheduling will put the running Task into ready state, as soon as a higher-priority task has got ready.

Non-preemptive scheduling
A task with this policy may be rescheduled only via one of the explicitly defined system services (explicit points of rescheduling): TerminateTask(), ChainTask(), Schedule (), or WaiEvent().

Mixed preemptive scheduling
When preemptive and non-preemptive tasks are mixed in the same system, the resulting policy is called "mixed preemptive" scheduling.

Groups of tasks
The OS allows tasks to combine aspects of preemptive and nonpreemptive scheduling by defining groups of tasks. For tasks that have the same or lower priority as the highest priority within a group, the tasks within the group behave like non-preemptable tasks: rescheduling will only take place at the points of rescheduling.

OSEK OS. Interrupt processing

The functions for processing an interrupt (Interrupt Service Routine: ISR) are subdivided into two ISR categories:

• ISR category 1
  The ISR does not utilize an operating system service. When the ISR terminates, processing resumes exactly from the instruction where the interrupt occurred,i.e. the interrupt has no influence on task management.
  ISRs of this category have the least overhead.

• ISR category 2
  The ISR may call several OS APIs (ActivateTask() for example).
  Rescheduling happens at the conclusion of ISR Category 2 when the intercept mission is halted and there are no other active suspensions.

OSEK OS. ISR categories

OSEK OS. Event mechanism

• It is a means of synchronization
• It only provided for extended tasks
• The OSEK OS provides the following services: SetEvent(), WaitEvent(), GetEvent(), and ClearEvent(). Events are objects managed by the OS. They are not independent objects but are assigned to extended tasks. Each extended task has a definite number of events. Events can be used to communicate binary information to the extended task to which they are assigned.

This example explains event synchronization in case of full preemptive scheduling. The extended task T1 has the higher priority.

This example explains event synchronization in the case of non-preemptive scheduling. The extended task T1 has the higher priority.
Rescheduling does not take place immediately after the event has been set.

OSEK OS. Resource management

Resource management is used to coordinate concurrent accesses of several tasks/ISRs with different priorities to shared resources.
Resource management ensures that

• two tasks/ISRs cannot occupy the same resource at the same time.
• priority inversion can not occur.
• deadlock does not occur using these resources.
• tasks accessing resources never enter a waiting state.

OSEK Priority Ceiling Protocol

• At the system generation, each resource has its own ceiling priority that is statically assigned. Maximum priority is set to at least the highest priority of all tasks accessing the resource or resources associated with that resource. The highest priority is lower than the lowest priority of all tasks not using the resource that have priorities higher than the highest priority of all tasks using the resource. - If a task requires a resource and its current priority is lower than the resource ceiling priority, the task priority is raised to the resource ceiling priority.

• If a task needs a resource and its current priority is lower than the resource's ceiling priority, the task's priority is increased to the ceiling.

• If the task releases the resource, the priority of this task is reset to the priority that was dynamically assigned before requiring that resource.

• OSEK Priority Ceiling Protocol may be extended for interrupt levels.

EXAMPLE
This example explains resource assignment with a priority ceiling between preemptable tasks:

• T0 has the highest, and T4 the lowest priority
• T1 and T4 want to access the same resource
• high-priority T1 waits for a shorter time than the maximum duration of resource occupation by T4.

OSEK Priority Ceiling Protocol with extensions for interrupt levels

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.