My name is Sharana Basava, and I work at Luxoft India as a junior software engineer. I have had multiple opportunities to work on different projects at Luxoft, which has motivated me to talk about the crucial steps in creating a Automotive standard.

continuation of Triggering of Runnable Entities

->Mode Switch Triggered Runnables
AUTOSAR defines the Mode Switch Event to trigger a runnable entity on either entering or exiting of a specific mode of a mode declaration group· The Mode Switch Event can only trigger a runnable entity at its entry point· Consequently, there exists no API to set up a wait point for a Mode Switch Event·

->Mode Switched Acknowledge Triggered Runnables
AUTOSAR defines the Mode Switched Acknowledge Event to signal a successful mode transition· The Mode Switched Acknowledge Event can either trigger the execution of a runnable entity or continue a runnable, which is waiting at a wait point for the mode transition status· Only intra ECU communication is supported·

->Operation Invocation Triggered Runnables
The Operation Invoked Event is defined by AUTOSAR to always trigger the execution of a runnable entity· The signature of server runnable depends on the parameters defined at the C/S port· The return value depends on application errors being assigned to the operation that the runnable represents· The parameter list contains input input/output and output parameters· Input parameters for primitive data type are passed by value· Input parameters for composite data types and all input/output and output parameters independent whether they are primitive or composite types are passed by reference· The string data type is handled like a
composite type·

Multicore support
Similar to the mapping of SWCs to partitions with different memory access rights, the RTE also supports the mapping of SWCs to partitions on different cores for parallel execution·

->Partitioning of SWCs
The mapping of SWCs to cores happens with the help of OS Applications like in the memory protection use case· The user has to assign runnables to tasks and tasks to OS Applications in order to map SWCs to partitions· The OS Applications can then be assigned to one of the cores of the ECU· SWCs can only be assigned to a single OS Application· This means that
all runnables of a SWC need to be mapped to tasks within the same OS Application· If a SWC contains only server runnables that are not mapped to a task, the SWC can be mapped with the help of an ECUC partition·

BSW Access in Partitioned systems
When the SWCs are assigned to different OS Applications, only the SWCs that are assigned to the BSW OS Application can access the BSW directly· SWCs that are assigned to other cores or partitions do not always have the required access rights· The same is true for runnable entities that are directly called by the BSW through client/server interfaces· The RTE can transparently provide proxy code for such BSW accesses but the user needs to map the Send Signal proxy and the server runnables to tasks in which they can be executed·

Inter-ECU Communication
IOCs or additional global RTE variables are automatically inserted by the RTE generator when data needs to be sent from a partition without BSW to another ECU· This is required because the COM APIs cannot be called directly in this case· Instead, the RTE provides the schedulable entitiy Rte Com Send Signal Proxy Periodic for the partition that contains the BSW COM module, which periodically calls the COM APIs when a partition without BSW transmitted data· If the COM is instantiated on multiple partitions for parallel use, then such a schedulable entity Rte Com Send Signal Proxy Periodic is provided on each partition that contains the COM module· In this case the Rte Optimization Mode attribute must be set to RUNTIME as the optimization mode MEMORY would require spinlocks for all bitfield accesses, which would cause too much overhead· Each schedulable entity Rte Com Send Signal Proxy Periodic should be mapped to the same task as the corresponding Com Main Function Tx with a lower position in task so that it can update the signals before they are transmitted by the COM· Rte Com Send Signal Proxy Periodic will be scheduled with the same cycle time as Com Main Function Tx· For this, the RTE generator reads the period from the COM configuration· For the reception of signals no special handling is required· The RTE will automatically forward the received data to the appropriate partition in the COM notifications·

Client Server Communication
Client server calls between SWCs in different partitions are also possible·In order to execute the server runnable in another partition, the server runnable needs to be mapped to a task· The RTE will then make the server arguments available in the partition of the server runnable, execute the server runnable in the context of its task and return the results to the calling partition.Direct client server calls to servers on other cores are not possible because this would enforce that the server is executed in the context of the client core· This would lead to data consistency problems for RTE APIs that only provide buffer pointers like Rte Pim· The RTE cannot use IOCs for these APIs because the actual buffer update is done by the application code. You can instruct the RTE to generate a context switch. You can decide this over the task mapping of a function trigger· If you consider RTE calls which originate from the same partition as the server runnable, a context switch into the task of the server runnable may not be required. Performing a task switch would mean an additional overhead which can be avoided. Therefore, it is also possible to configure an additional server port prototype for clients which are local to the server partition. The triggers from both server ports can then trigger the same server runnable· However, only the trigger from the port that is connected to foreign partitions needs to be mapped onto a task. As a consequence, the RTE can implement calls from partition local clients as efficient direct function calls.Please take into account, that this is only allowed when the server runnable is not invoked concurrently or marked as “can be invoked concurrently”· In addition, you can use Exclusive Areas to protect the runnable against concurrent access problems·