Overview

An Exclusive Area is a piece of code that must only be entered by one task at a time. This is also called a critical section. The exclusive area is protected by a lock. Before entering the exclusive area, the first task takes the lock, it then holds it until it leaves the section. At that point it releases the lock. As long as the first task holds the lock, no other task can take it and no other task can enter the exclusive area. This is also referred to as a mutual exclusion (mutex).

The Exclusive Area is defined by the software implementation (by the BSW or ASW developer). This defines that a lock should be used. But the type of lock and the concrete lock to be used, called the Exclusive Area Implementation, has to be defined by the integrator.

Locking mechanisms

There are several different ways a lock can be implemented, with different performance tradeoffs. To be able to optimize the runtime behavior of an embedded system (especially its reaction time), AUTOSAR offers several different locks (called Exclusive Area Implementation Mechanism), see RteExclusiveAreaImplMechanism in the RTE Specification (AUTOSAR_CP_SWS_RTE.pdf ). The most important types are:

OsResource (OS_RESOURCE)

An OsResource is a lock that works on a single core. It is an Os feature that raises the priority of the currently running task in such a way that none of the other tasks, which want to use the same OsResource, can run. For more details see the RTA-OS User Guide, chapter 6 Resources., which can be found in your RTA-CAR installation under RTA-CAR_<version>\RTA-OS_<version>\Documents

Only prevents code on the same core from entering the exclusive area.

Interrupt Disable (ALL_INTERRUPT_BLOCKING, OS_INTERRUPT_BLOCKING)

Code is either executed because it was scheduled, or because an interrupt was triggered. Scheduling is also based on interrupts, so disabling interrupts ensures no conflicting code can be executed. Since this disables all interrupts on one core, this increases the reaction time of the system.

Only prevents code on the same core from entering the exclusive area.

Spinlock (OS_SPINLOCK)

The idea behind a spinlock is that one core takes a lock, and everyone else waits in a loop until they can take the lock. This waiting in a loop is called busy waiting or spinning, hence the name spinlock. Spinlocks can be costly in terms of runtime performance both in terms of calling CPU core runtime and on other system HW resources (such as memory bandwidth, interconnect etc).

Also prevents code on other cores from entering the exclusive area

Deadlocks

A deadlock is a kind of conflict between multiple tasks. The simplest case is: take two tasks taskA and taskB that want to acquire two locks lock_1 and lock_2 in different orders. taskA wants to acquire lock_1 and then lock_2, taskB wants to acquire lock_2 and then lock_1. In this case, it's possible that taskA holds lock_1 and taskB holds lock_2. taskA now cannot proceed, because it waits for lock_2. Meanwhile, taskB waits for lock_1, which taskA holds. But taskA will only release lock_1 after taskB to releases lock_2. No task can proceed, the system is deadlocked. In an embedded system, this then usually is detected by a watchdog and triggers a system reset.

Nesting order, Nestable, NoNest and Commonable

Acquiring a lock while holding another lock is called lock nesting, and the order of acquisition is called nesting order. It's easy to see that the simple example can be solved if both tasks acquire locks in the same order. If taskA acquires lock_1 and then lock_2, and taskB acquires lock_1 and then lock_2, no deadlock occurs.

A lock that supports nesting (getting another lock while holding this lock) is called nestable. Since the locking order is critical to avoid deadlocks, the order of locks has to be configured via the configuration parameter OsSpinlockSuccessor.

Another way to avoid deadlocks is to avoid nesting. An exclusive area that does not call any code that would require a lock is sometimes called NoNest. On the other hand, a commonable lock can follow any lock without being on its list of successors. It in turn can only be followed by a lock that has no successors and is not commonable. So it's not possible to get a different commonable lock while already holding a commonable lock.

Configuring the Exclusive Area Implementation

MCAL has to be configured separately

Please note that, this guide does not cover the microcontroller abstraction layer (MCAL), as it is not part of the RTA-CAR project, and in many cases configured using separate tooling.

Configuration for projects using SchM headers (RTA-CAR <= 12.6.0)

The lock usage is configured in header files located in src\bsw\<BSW-Module-Name>\integration. The easiest way to find them is to use the File Navigator and filter by Cfg_SchM:

Open the various header files and add the lock implementation. For example for BswM_Cfg_SchM.h:

LOCAL_INLINE void SchM_Enter_BswM(void)
{
	GetSpinlock(CommonSpinlock);
}
LOCAL_INLINE void SchM_Exit_BswM(void)
{
    ReleaseSpinlock(CommonSpinlock);
}

The name of the spinlock in the argument has to match the configured name (in this example the lock is called CommonSpinlock). It is defined in Os_Cfg.h, the GetSpinlock function is defined in Os.h. Usually, it's not required to include them from the Cfg_SchM.h file, because they are included earlier.

Configuration for projects using Rte approach (RTA-CAR >= 12.7.0)

Starting with RTA-CAR 12.7, it is possible to let Rtegen generate the Exclusive Area Implementation. This workflow typically requires the user to run BSW, RTE and OS generators, to generate the RteBswExclusiveAreaImpl subcontainer and the input for the exclusive area analysis tool, before proceeding with the configuration in this section. However, there is a limitation in this workflow due to incorrect input validation which requires a few extra steps to achieve the desired result, please see the limitation section at the end of this article for more information.

Important: The generation requires setting the new parameter RteBswEnforceExclusiveAreaApisGeneration to true:

Exclusive Area Configuration Editor

Which implementation Rtegen generates is configured in the Rte Ecuc. The parameters are RteBswModuleInstance/RteBswExclusiveAreaImpl (for exclusive areas defined in the BSW) and RteSwComponentInstance/RteExclusiveAreaImplementation (ASW). To simplify this configuration, it is recommended to use the new Exclusive Area Configuration Editor. It can be started via the MultiCore Editor (as well as the RTE Editor):

If there are problems in the Rte configuration, a message is shown:

In many cases, these errors are not critical and it's possible to continue with the configuration.

The Exclusive Area Configuration Editor can be found under "Entity To Task Mapping" (1) on the sub tab "Exclusive Area and Impl. Mechanism Config" (2):

The Exclusive Area Configuration Editor opens. It shows all Exclusive Areas defined in the project, grouped by component (BSW module or ASW SW-C):

It allows selecting the implementation mechanism for every Exclusive Area, by double clicking on the relevant entry in the column "Implementation Mechanism Name". This opens a dialog that allows selecting the implementation mechanism:

The option "Create / Assign Implementation Mechanism" can be used to assign the same implementation mechanism to multiple entries. It can also be used to configure new OsResources and OsSpinlocks.

Implementation Mechanism Assignment Analysis

Which exclusive area should be used depends on the access pattern in the project. This is why we introduced a static analysis tool called Implementation Mechanism Assignment Analysis. It determines the call pattern and recommends an Exclusive Area implementation. 

Before running the tool, it is required to set the Rte configuration parameter RteBswEnforceExclusiveAreaApisGeneration to true and to run the build steps "Generate BSW", "Generate RTE" and "Generate OS".

The tool can be started via "Run Implementation Mechanism Assignment Analysis" - "Complete Analysis". Depending on the size of the project, the analysis can take some time (for a small project about 10 seconds, in bigger projects around 20 minutes).

The result is shown in a new window, where a concrete implementation for each Exclusive Area can be selected. "OK" means that the currently chosen implementation is strong enough. "WEAK" means that a stronger implementation is required, "STRONG" means that a weaker implementation would be enough.

Finding a strategy

In general, it's advisable to start with a simple and slow but reliable strategy - using a single spinlock, and then optimize based on the needs of the project. This requires measuring timing and performance metrics across all CPU cores, paying special attention to latency in communication-critical paths.

Single Spinlock

Start with a single, nestable and commonable spinlock to synchronize all components, including the Ethernet stack, CAN stack, PduR, and other communication-related modules.

This approach is very simple to configure but will result in the worst system performance.

Create a Commonable, Nestable OsSpinlock

Open the Os Editor, navigate to Spinlock, right click and select New:

Right click on the newly created Spinlock and rename it to an expressive name (in this example: CommonSpinlock):

Click on the renamed spinlock and select the lock method - see the Os Reference Manual, chapter 11.4.7 "Container: OsSpinlock" for the different values of OsSpinlockLockMethod:

Click in Applications and select the OsApplications from which this lock will be entered. In this case, since this is the default lock used everywhere, we select all OsApplications that are configured in the project:

Performance Analysis

Steps:

• Create a trace of the system execution, ideally based on a worst case scenario (e.g. by sending a lot of traffic from simulated bus nodes)
• Check which exclusive areas spend the most time waiting for spinlocks
• Determine which core(s) are most affected by synchronization delays, latency issues etc
• Determine the OS tasks and Runnables affected. Identify the most likely components that may contribute to delays.
• Group the components in “stacks”, groups of components that work together for a certain feature set. Examples:
  • COM Stack: Com services component and communication bus specific sub-stacks: CAN, FlexRay, LIN, Ethernet etc
  • Mem stack: includes the memory services
  • Diagnostic services
  • Applications

Incrementaly adding Spinlocks

Introduce additional spinlocks where necessary:

• Identify communication components or code paths that are significantly impacted by performance issues.
• Add a spinlock for the performance relevant component group (stack) and use it for all ExclusiveAreas used by it
  • Non-nestable spinlocks have a lower locking overhead than nestable spinlocks. Therefore, where possible, prefer non-nestable spinlocks over nestable spinlocks. The ExclusiveAreas in ETAS RTA-CAR follow a naming convention, the suffix "NoNest" indicates that no nesting takes place (i.e. no other exclusive area is entered from this exclusive area).
• If the component group is still affected by performance issues, add additional finer-grained spinlocks (for example in the Com stack, add a spinlock for all ExclusiveAreas used by one Bus).

Limitation - Configuring EcuCRbLegacySchMInUse Without RteBswExclusiveAreaImpl Instances

Overview

The limitation in RTA-CAR Common stack configuration prevents users from setting EcuCRbLegacySchMInUse = False when RteBswExclusiveAreaImpl instances are not configured. This issue arises due to current validation rules in BSW CodeGen, which will not be fixed in version 12.7.0. The described workaround is required until a resolution is implemented in a future release.

Details

1. Behavior:
   • Expected: Users should configure EcuCRbLegacySchMInUse = False without pre-configuring RteBswExclusiveAreaImpl.
   • Actual: A validation error prevents this configuration, despite RteBswExclusiveAreaImpl being unavailable until after running BSW CodeGen and exclusive area analysis.
2. Validation Rules:
   • Rule 1: EcuCRbLegacySchMInUse = False cannot be set when RteBswExclusiveAreaImpl is not configured.
   • Rule 2: EcuCRbLegacySchMInUse = True or Null (not configured) is not allowed if RteBswExclusiveAreaImpl is configured (this rule is valid).

Workaround (Alternate Workflow)

Users must follow the workflow below to bypass the limitation if they want to use the new locking mechanism, in order to generate the exclusive area implementation with the new approach using RTA-RTE:

1. Enable EcuCRbLegacySchMInUse = True initially (avoiding validation errors).
2. Run BSW CodeGen to generate BSWMD and SWCD outputs.
3. Generate RTE and OS, providing input for the exclusive area analysis tool.
4. Run the exclusive area analysis tool and configure RteBswExclusiveAreaImpl.
5. Set EcuCRbLegacySchMInUse = False and re-run BSW CodeGen.
6. Re-run RTEGen to generate SchM_Enter and SchM_Exit methods.

Steps 1 and 5 highlight the limitation, this will be patched in the upcoming releases. Following the exact steps above is the recommended approach for RTA-CAR 12.7.0.