From ErikaWiki

Revision as of 14:26, 10 September 2014 by Eguidieri (Talk | contribs)
Jump to: navigation, search


Multicore Autosar OS Support

ERIKA support multicore environments a way before than the first Autosar Multicore OS Release. So it happened that the historical ERIKA multicore support addresses some of the same requiremets of AUTOSAR Multicore OS with a completely different policy.

In detail all the primitives calls on other core, with traditional implementation, called Remote Notifications or RN, are done asynchronously with a fire and forget policy. This approach reduce latency to minimun, but, on the other hand, don't give the opportunity to check for errors in the call site.

Autosar, that take into account a way more code consistency and reliability than efficiency, requires that all the primitives calls on others cores are synchronous giving the opportunity to caller code to correctly handle errors.

To implements Autosar OS requirements a completly new multicore dispatcher have been implemented. This have been called ERIKA Autosar RPC (Remote Procedure Call).

Both traditional and the new dispatcher are available for Infineon AURIX and Freescale PowerPC (MPC5777C). You can switch between them in OIL with the REMOTENOTIFICATION oil field.


Enable traditional Remote Notification dispatcher. It's the default value, so you don't need to write this.


Enable the new AUTOSAR Remote Procedure Call dispatcher.

Currently with the new RPC dispatcher you can execute on remote cores all the following primitives:

  • ActivateTask
  • ChainTask (Terminate local TASK but can schedule on remote core)
  • GetTaskState
  • SetEvent
  • GetAlarmBase
  • GetAlarm
  • SetRelAlarm
  • SetAbsAlarm
  • CancelAlarm
  • GetCounterValue
  • GetElapsedValue
  • ShutdownOS ( with new ShutdownAllCores API )

So in addition to TASK and EVENT primitives, the new muticore dispatcher support Counters and Alarms as required by Autosar specifications. Multicore awareness have been added to ShutdownOS to fulfill multicore AUTOSAR shutdown sequence.

New Multicore API

AUTOSAR expect a master/slaves multicore enviroment that naturally fit AURIX architecture. New API to start and stops slave cores specified in AUTOSAR v4.0 rev 3.0 have been added:

  • StartCore: This function starts the core specified by the parameter CoreID. The OUT parameter allows the caller to check whether the operation was successful or not. If a core is started by means of this function StartOS shall be called on the core. It is not supported to call this function after StartOS().
  • StartNonAutosarCore: The function starts the core specified by the parameter CoreID. It is allowed to call this function after StartOS(). The OUT parameter allows the caller to check whether the operation was successful or not. It is not allowed to call StartOS on cores activated by StartNonAutosarCore.
  • GetNumberOfActivatedCores: returns the number of cores activated by the StartCore function. This function might be a macro
  • GetCoreID: The function returns a unique core identifier.
  • ShutdownAllCores : After this service the OS on all AUTOSAR cores is shut down. Allowed at TASK level and ISR level and also internally by the OS. The function will never return. The function will force other cores into a shutdown.

New Spinlocks API

Support for AUTOSAR Spinlock API have been added. OIL implementation have been extended to support Spinlocks configuration.

There's two spinlocks behaviour modes: SINGLE and ORDERED. If SINGLE mode is configured a core get an error if, holding a spinlock, try to get access to another one. If ORDERED mode is configurated the core get this error only if it try to get spinlocks out of the order (see AUTOSAR documentation paragraph 7.9.29 The spinlock mechanism).

To configure spinlocks in SINGLE mode, just don't provide any order:

 SPINLOCK spinlock_1 {  };
 SPINLOCK spinlock_2 {  };
 SPINLOCK spinlock_3 {  };

To configure spinlocks in ORDERED mode provide a complete ordering:

 SPINLOCK spinlock_1 { NEXT_SPINLOCK=spinlock_2; };
 SPINLOCK spinlock_2 { NEXT_SPINLOCK=spinlock_3; };
 SPINLOCK spinlock_3 {  };

Provided AUTOSAR API to interact with Spinlocks are:

  • GetSpinlock : Tries to occupy a spin-lock variable. If the function returns, either the lock is successfully taken or an error has occurred. The spinlock mechanism is an active polling mechanism. The function does not cause a de-scheduling.
  • ReleaseSpinlock: Releases a spinlock variable that was occupied before. Before terminating a TASK all spinlock variables that have been occupied with GetSpinlock() shall be released. Before calling WaitEVENT all Spinlocks shall be released.
  • TryToGetSpinlock: Has the same functionality as GetSpinlock with the difference that if the spinlock is already occupied by a TASK on a different core the function sets the OUT parameter to TRYTOGETSPINLOCK_NOSUCCESS and returns with E_OK.

Two spinlocks implementation are provided. The trivial one that does not guarentee upper bond wait, but that can implement the try-to-get behaviour. And the queued one that prevent from starvation queuing requests, but cannot implement try-to-get behaviour (TryToGetSpinlock API is mapped into GetSpinlock).

To enable queued spinlocks just add to the OIL:


IMPORTANT: QUEUED spinlocks are not available for Erika on PowerPC.

Autosar Schedule Tables

Autosar Specification add to OSEK Alarms, another activities schedulator called Schedule Tables. It is possible to implement a statically defined activities schedulator, that activate TASKs and set EVENTs, using an OSEK counter and a series of auto started alarms. In the simple case, this can be achieved by specifying that the alarms are not modified once started. Run-time modifications can only be made if relative synchronization between alarms can be guaranteed.This typically means modifying the alarms while associated counter tick interrupts are disabled. Schedule Tables address the synchronization issue by providing an encapsulation of a statically defined set of expiry points. Each expiry point defines:

  • One or more actions that must occur when it is processed where an action is the activation of a task or the setting of an event.
  • An offset in ticks from the start of the schedule table.

Each schedule table has a duration in ticks. The duration is measured from zero and defines the modulus of the schedule table.

At runtime, the Operating System module will iterate over the schedule table, processing each expiry point in turn. The iteration is driven by an OSEK counter. It therefore follows that the properties of the counter have an impact on what is possible to configure on the schedule table.

Schedule Table APIs

All the Schedule Table API not related to the schedule table syncronization are implemented (see Schedule Table Synchronization).

  • StartScheduleTableRel( ScheduleTableType ScheduleTableID, TickType Offset ): This service starts the processing of a schedule table at "Offset" relative to the "Now" value on the underlying counter.
  • StartScheduleTableAbs( ScheduleTableType ScheduleTableID, TickType Start ): This service starts the processing of a schedule table at an absolute value "Start" on the underlying counter.
  • StopScheduleTable( ScheduleTableType ScheduleTableID ): This service cancels the processing of a schedule table immediately at any point while the schedule table is running.
  • GetScheduleTableStatus( ScheduleTableType ScheduleTableID, ScheduleTableStatusRefType ScheduleStatus ): This service queries the state of a schedule table (also with respect to synchronization).
  • NextScheduleTable(ScheduleTableType ScheduleTableID_From, ScheduleTableType ScheduleTableID_To): This service switches the processing from one schedule table to another schedule table.

Schedule Table OIL Configuration


Schedule Table Synchronization

The absolute time at which the Initial Expiry Point on a schedule table is processed is under user control. However, if the schedule table repeats then it is not guaranteed that the absolute count value at which the initial expiry point was first processed is the same count value at which it is subsequently processed. This is because the duration of the schedule table need not be equal to the counter modulus. In many cases it may be important that schedule table expiry points are processed at specific absolute values of the underlying counter. This is called synchronization. Typical use-cases include:

  • Synchronization of expiry points to degrees of angular rotation for motor management
  • Synchronizing the computation to a global (network) time base.

Note that in AUTOSAR, the Operating System does not provide a global (network) time source because

  • 1. A global time may not be needed in many cases
  • 2. Other AUTOSAR modules, most notably FlexRay, provide this independently to the Operating System
  • 3. If the Operating System is required to synchronize to multiple global (network) time sources (for example when building a gateway between two time-triggered networks) the Operating System cannot be the source of a unique global time. AUTOSAR OS provides support for synchronization in two ways:
  • 1. Implicit Synchronization – The counter driving the schedule table is the counter with which synchronization is required. This is typically how synchronization with time-triggered networking technologies (e.g. FlexRay, TTP) is achieved – the underlying hardware manages network time synchronization and simply presents time as an output/compare timer interface to the Operating System.
  • 2. Explicit Synchronization – The schedule table is driven by an Operating System counter which is not the counter with which synchronization is required. The Operating System provides additional functionality to keep schedule table processing driven by the Operating System counter synchronized with the synchronization counter. This is typically how synchronization with periodically broadcast global times works.

[b]N.B.[/b] Explicity synchronization is not fully supported yet. ([b]SyncScheduleTable[/b] have been implemented but not yet tested. [b]StartScheduleTableSynchron[/b] and [b]SetScheduleTableAsync[/b] are not implemented at all).

Autosar OSApplication and Protection Support

AUTOSAR specifications introduce [b]OSApplications[/b] as entities containers (TASKs, ISR2s, COUNTERs, ALARMS), that could resemble to processes (without memory virtualization), on top of which construct OS protection mechanism


Note on Autosar Scalabilty Classes

TODO which construct OS Protections Mechaninsm

Personal tools