In a system, where the Application Software (ASW) is distributed, there are several ways to distribute the Basic Software (BSW). They offer a trade-off between simplicity and local access to data:
- Centralized BSW - the BSW is in one partition. Access to the BSW is routed through the RTE, which takes care of data consistency. This is a good starting point for many projects.
- Master/Satellite - provide application SW-Cs with local access to selected BSW services (especially ServiceSoftwareComponents, like WdgM, Dem, Fim, etc. which cause high runtime usage, are frequently called, require low latency). Avoid cross-partition routing via the RTE.
- Multi-Master - optimize load balancing between cores. Since a significant part of the CPU load is usually in the Com stack, it makes sense to distribute vertical slices of the Com stack to different cores. For example, Ethernet on Core A, everything else on Core B. Or CAN1-4 on Core C, other CANs on Core A. This offers a good complexity / performance tradeoff.
How to find the right strategy
- Decide on your architectural drivers. Examples: maximum performance; independent development; ease of update; etc.
- Distribute your ASW accordingly
- If your project has very little ASW (such as a gateway ECU), start by designing the distribution of your communication load
- Start with a centralized BSW
- If bottlenecks occur, check if the Com Stack can be distributed to match the ASW distribution (e.g. if CAN2 is only used by ASW on Core 3, then this part of the Com Stack can be moved to Core 3)
- Start by distributing the receive main function (Rx),
- transmit main function can introduce latencies, so it should either be scheduled synchronous to the bus or with a fast period (e.g. 1ms)
- avoid distribution in a gateway use case, since this adds latency
- If other modules are performance critical, distribute those as well
Commonly used distribution strategies
Centralized BSW
The complete basic software is on a single core. Accesses from the application software are routed via the RTE. The Inter-OS-Application Communication (IOC) mechanism is used to cross partition boundaries.
- Advantages
- Simple to use
- No additional configuration required
- Disadvantages
- Crossing partition boundaries reduces runtime performance
- Core load not well distributed
Optimization: Com Main Function per Task
In any of the shown distribution scenarios, the Com Main Function can be split into task specific main functions, which run in the same task as the sending/receiving application software. This offers big runtime benefits, because each main function handles fewer PDUs and runs at the frequency at which the data is required or provided by the ASW.
Master / Satellite - Provide local access to BSW services
The next step is to provide local access to selected BSW services in other cores and/or partitions, which AUTOSAR supports via the Master / Satellite approach. The main benefit of this is to reduce the access time from the ASW by avoiding expensive cross-partition calls via the RTE. The below example shows the case where NvM has a satellite per partition.
One of the questions when configuring master / satellite for a project is how many satellites should be configured. Each satellite brings some overhead, so one approach is to have a satellite per core. This already allows to keep data close to the core that it is used on, reducing access times. However, there is still the need to cross the partitions. The example below shows the approach for Dem with one satellite per core.
Multi-Master - Optimize load balancing
Since communication is often a significant part of the runtime / processor load, the Com stack is a good place to start distributing the basic software.
Our measurements showed that the main processing loads are usually above the Pdu Router (PduR), therefore our Com stack supports a PDU based distribution.
This means the Com stack is instantiated multiple times. The Rte must then call a Com instance inside the correct partition context. However, in some cases, it cannot know what the correct context would be. As an example, let’s assume there is a Com stack in OsAppA and OsAppD, and a SW-C in OsAppD sends a signal. Now there are two options: the Rte could call the Com stack in OsAppD, or use IOC to transfer the data to OsAppA and call the Com stack in OsAppA. For these kinds of signal paths, the Rte cannot make the decision. Therefore, ETAS uses a generated software component called RTE AdderAdapter. It splits the signal’s path into two parts: one that uses IOC and one that calls the ComStack inside the same partition.
For the cross-core communication in the Com Stack, ETAS has implemented an optimized solution called xCoreCdd.
Distributing the control path - e.g. network management, bus error handling, full com / no com, etc. - is not foreseen by AUTOSAR and brings very little benefit, so this has to run on the main core.
Often, the main BSW core has a high CPU load and becomes a bottleneck. A quick way to move a part of that load at once is to move a complete Bus to another core. This is also supported by the ETAS stack, and the image below shows a Com stack that is distributed by bus. A complete bus (here: Eth) is moved to a separate core.
How to distribute the BSW
There are two closely related aspects to distributing the BSW: which context does the BSW function run in (ideally: same as the caller), and where is the data stored (ideally: in RAM that has fast access for that context / core).
EventToTask Mapping
The main way to fix how a BSW module is executed at runtime is the EventToTask Mapping. This implicitly creates a link from the Service to an OsApplication and an EcucPartition.
ServiceSwComponent Mapping
If a BSW module has a ServiceSwComponent, then it can be directly mapped to an EcucPartition
Com Stack (including LdCom)
On the system level, the Signal / SignalGroup is distributed by a SenderReceiverToSignalMapping / SenderReceiverToSignalGroupMapping, which implicitly also distributes the underlying Pdu. On the EcuC level (configuration side), the Ecuc Pdu is mapped to an EcucPartition via EcucPduDefaultPartitionRef / EcucPduDedicatedPartition. In the case of Com, there is also a main function (Rx/Tx) per partition.
EcucPartitionRef (NvM, Dem)
Several modules allow assigning configuration elements to partitions. For example, NvM Blocks can be assigned to an EcucPartition via the NvMBlockEcucPartitionRef. For Dem, there is a vendor specific parameter DemRbEventEcucPartitionRef
These then also typically have a parameter for the main partition (NvMMasterEcucPartitionRef, DemRbMasterEcucPartitionRef)