From ErikaWiki

Revision as of 10:13, 12 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.

N.B. The best place to start to understand how schedule tables API works is: tricore/infineon_TriBoard-TC2X5_V2.0/Schedule Tables/Schedule Table example

Schedule Table OIL Configuration

This is an OIL example to how configure a Schedule Table with OIL

   COUNTER = system_timer;
   DURATION = 400;
     START_VALUE = 0;
     EXPIRE_VALUE = 100;
     ACTION = SETEVENT { TASK = Task1; EVENT = ButtonEvent; };
     EXPIRE_VALUE = 300;
     ACTION = SETEVENT { TASK = Task1; EVENT = TimerEvent; };

Following the SCHEDULETABLE field explaination

  • COUNTER: The Schedule Table driving counter
  • DURATION: The Schedule Table duration (in counter ticks), MUST be greater or equal to the last EXPIRE_POINT.EXPIRE_VALUE
  • REPEATING: Flag if the Schedule Table is one shot or have to be restarted when it terminated (after DURATION ticks).
  • AUTOSTART: Flag if the Schedule Table have to be started automatically during StartOs, in which way TYPE: (ABSOLUTE, RELATIVE) and with wich Start Value of the counter (or Offset if the TYPE is RELATIVE). In ERIKA where, all the counters are software the two autostartig type generate the same result.
  • EXPIRE_POINT: List of EXPIRY_POINT that represent the Schedule Table, any of which is composed by an EXPIRE_VALUE in ticks (when the expiry points happens) a list of ACTIONS (equals to ALARMs Actions) and by a flag that enable synchronization not yet supported (SYNC_ADJUSTMENT. Only FALSE value is supported, that is the default so the field can be omitted).

LOCAL_TO_GLOBAL_TIME_SYNCHRONIZATION: Flag that enable External Syncronization, not supported yet. (Only FALSE value is supported, that is the default so the field can be omitted).

N.B. The best place to start to understand how schedule tables OIL configuration works is: tricore/infineon_TriBoard-TC2X5_V2.0/Schedule Tables/Schedule Table example

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.

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

Autosar OSApplication and Protection Support

AUTOSAR specifications introduce OS-Applications as entities containers (TASKs, ISR2s, COUNTERs, ALARMS, Schedule Tables), that could resemble to processes (without memory virtualization).

The Operating System module is responsible for scheduling the available processing resource between the OS-Applications that share the processor. If OS-Application(s) are used, all TASKs, ISRs, COUNTERs, ALARMs and Schedule tables must belong to an OS-Application. All objects which belong to the same OS-Application have access to each other. The right to access objects from other OS-Applications may be granted during configuration. An event is accessible if the TASK for which the EVENT can be set is accessible. Access means that these Operating System objects are allowed as parameters to API services.

The above are the foundamentals of Service Protection.

There are two classes of OS-Application:

  • 1 Trusted OS-Applications: Are allowed to run with monitoring or protection features disabled at runtime. They may have unrestricted access to memory, the Operating System module’s API, and NEED NOT have their timing behaviour enforced at runtime. They are allowed to run in privileged mode when supported by the processor.
  • 2 Non-Trusted OS-Applications: Are not allowed to run with monitoring or protection features disabled at runtime. They have restricted access to memory, restricted access to the Operating System module’s API and have their timing behaviour enforced at runtime. They are not allowed to run in privileged mode when supported by the processor.

Operating System module itself is a TRUSTED OS-Application.

The running OS-Application is defined as the OS-Application to which the currently running Task or ISR belongs. In case of a hook routine the Task or ISR which caused the call of the hook routine defines the running OS-Application.

There are services offered by the AUTOSAR OS which give the caller information about the access rights and the membership of objects and memory variables. These services are intended to be used in case of an inter-OS-Application call for checking access rights and arguments.

OS-Applications have a state which defines the scope of accessability of its Operating System objects from other OS-Applications. Each OS-Application is always in one of the following states:

  • Active and accessible (APPLICATION_ACCESSIBLE): Operating System objects may be accessed from other OS-Applications. This is the default state at startup.
  • Currently in restart phase (APPLICATION_RESTART): Operating System objects can not be accessed from other OS-Applications. State is valid until the OSApplication calls AllowAccess().
  • Terminated and not accessible (APPLICATION_TERMINATED): Operating System objects can not be accessed from other OS-Applications. State will not change.

Protection is only possible for Operating System managed objects. This means that:

  • It is not possible to provide protection during runtime of Category 1 ISRs, because the operating system is not aware of any Category 1 ISRs being invoked. Therefore, if any protection is required, Category 1 ISRs have to be avoided. If Category 1 interrupts AND OS-Applications are used together then all Category 1 ISR must belong to a trusted OS-Application.
  • It is not possible to provide protection between functions called from the body of the same Task/Category 2 ISR.

Autosar specify four protection features:

  • Service Protection: Protect the Object Access (TASK, ALARMs, Schedule Table, Resources) between OS-Application, if the permission is not explicitly granted.
  • Memory Protection: Protect Global Data and Stacks of an OS-Application from possible corruption by Non-Trusted OS-Application.
  • Stack Monitoring: On processors that do not provide any memory protection hardware it may still be necessary to provide a “best effort with available resources” scheme for detectable classes of memory faults. Stack monitoring will identify where a task or ISR has exceeded a specified stack usage at context switch time.
  • Timing Protection: A timing fault in a real-time system occurs when a task or interrupt misses its deadline at runtime. Autosar OS supply a mechanism based on budget that let the software understand which TASK or ISR2 is causing a deadline missing

OS-Application API & OIL Configuration

The OS-Applications life-cycle is controlled by two APIs TerminateApplication and AllowAccess. TerminateApplication stops OS-Applications' active and ready instances of TASKs and ISR2s and won't schedule them more as long as the application is possibly restarted, plus make all the its objects inaccessible, this means, for example, that won't be possible to read a counter or set an alarm of the given OS-Application.

This is useful to stop a faulty portion of the firmware (this usually can happens automatically when ProtectionHook is configured) or to change the configuration of the application it self in case of, for example, power saving mode.

When TerminateApplication is called with RESTART as restart option just one istance of a pre-configured terminated OS-Application's TASK is activated and schedulated. This and only this TASK can put OS-Application's data in a consitent configuration and then call AllowAccess API to actually Restart the OS-Application.

Following the list of the API that directly interact with OS-Application.

  • EE_as_TerminateApplication( ApplicationType Application, RestartType RestartOption ): Restart OS-Application "Application", if RestartOption is equal to RESTART, or completly terminate it, if RestartOption is equal to NO_RESTART. Restart an OS-Application is a termination with the automatic schedulation of OIL APPLICATION.RESTARTTASK that can reset OS-Application to a consistent status and call AllowAccess to actually restart the application. So only OS-Application that have OIL APPLICATION.RESTARTTASK field configurated can be effectively restarted.
  • EE_as_AllowAccess( void ): Can be called only by an OS-Application Restarting TASK and only when the OS-Application is effectively restarting, to reset OS-Application status to accessibile.

The OIL configuartion container:

N.B. Remember that if OS-Application are used EVERY SINGLE OBJECT have to belong to an OS-Application, but RESOURCEs, EVENTs and those that impicitly belong to OS, like SYSTEM_TIMER COUNTER.

   TASK    = App1Task1;
   TASK    = App1Task2;
   TASK    = App1Task3;
   COUNTER = App1Counter1;
   COUNTER = App1Counter2;
   ALARM   = App1Alarm1;
   ALARM   = App1Alarm2;
   SCHEDULETABLE = App1ScheduleTable;
   SCHEDULETABLE = App1ScheduleTable;
   //MEMORY_SIZE = 0x1000;
   IRQ_STACK_SIZE = 256;
   RESTARTTASK = App1Task3;

TRUSTED: Flag if the OS-Application is Trusted or not. BE AWARE TO REDUCE TO MINIMUM THE USE OF TRUSTED OS-APPLICATIONS, BECAUSE THEY BYPASS MEMORY PROTECTION (if enabled). TASK: List of all the TASKs that belong to the OS-Application. COUNTER: List of all the COUNTERs that belong to the OS-Application. ALARM: List of all the COUNTERs that belong to the OS-Application. SCHEDULETABLE: List of all the SCHEDULETABLEs that belong to the OS-Application. MEMORY_SIZE: This Parameter is an ERIKA's extension to AUTOSAR. When this parameter is set enable an ASSERTION test in ELF linkin tha assure that the RAM used by the application (DATA + STACKs) is less or equal of MEMORY_SIZE. SHARED_STACK_SIZE: Stack's size for all the OS-Application's TASKs configured to share the stack (Container TASK field STACK = SHARED). IRQ_STACK_SIZE: Stack's size for all the OS-Application's ISR2s.

TODO TRUSTED Function Configuration.

Service Protection


Note that Resource objects do not belong to any OS-Application, but access to them must be explicitely granted. (The same principle applies to spinlocks in Multi-Core systems)

Note on Autosar Scalabilty Classes

TODO which construct OS Protections Mechaninsm

Personal tools