A Multi-Core Basic Software as Key Enabler ofApplication Software Distribution

Andre GobelContinental Automotive GmbH,

P.O. Box 100943D-93009 Regensburg

GermanyEmail: andre.goebel@continental-corporation.com

Denis ClarazContinental Automotive France SAS

1, av. Paul Ourliac, BP 114931100 Toulouse

FranceEmail: denis.claraz@continental-corporation.com

Abstract—In the last 20 years, functional evolution in theautomotive Powertrain has been motivated by three mainpillars: low CO2 emissions, low particle emissions and increaseof torque throughput. In addition to these permanent objectives(e.g. Euro 7 standard), new constraints are rising up, likeintegrated transmission systems, electrification, autonomousdriving, connectivity as well as changed domain architectures.

Finally, new complexities have to be handled, which requiretoday 6 times as much computation power as 15 years ago, when32 bits controllers were introduced (e.g. former Motorola MPC563 @ 40MHz). This demand is answered by the introductionof multi-core micro-controller architectures designed for theautomotive environment. And the trend of requiring additionalcomputation power will continue in the future where onemight step forward towards more powerful multi-core or evenmany core systems. But the development of powerful hardwarearchitectures does not release software architecture fromcareful usage of system resources. This is because a multi-coresystem can be used in an efficient way only if a high rate ofparallelization can be achieved according to Amdahl’s law[8].

Even if AUTOSAR [4] allows a partitioning of softwarecomponents (SWC) across cores, it does simply not consider amulti-core basic software (BSW) until today. Instead it phrasesjust concept ideas not realized in the standard. So it is thetask of this paper to give an overview about the possibilitiesof the AUTOSAR standard and to sketch an alternate solutionbased on the AUTOSAR foundation offering a distributableBSW across cores which allows a distribution of not only aSWC but even the individual runnables of it. It will explainhow the BSW itself is distributed, and how the access to theperipherals from different cores is made possible. Furthermorea concept of core abstraction will be described, allowing toshare even the same task architecture between projects based ondifferent micro-controllers. Consequently, the paper will proposea qualification of the BSW into 3 multi-core conformance classes.

The principles described in this contribution are applied inthe daily work in our Powertrain projects, and are already inproduction since 2016 for a central Powertrain controller ofa German OEM, and since 2017 for an engine system of afrench OEM. At the date of publication, other engine systemsapplications and hybrid systems based on this concept are inproduction, and further ones are planned for 2018.

Index Terms—Multi-core, Real-time system, AUTOSAR, Au-tomotive, Embedded software, BSW, Basic software, CPU-Load,Powertrain

I. MULTI-CORE NEEDS IN THE POWERTRAIN DOMAIN

A. Introduction

After introduction of the first 32bit automotive micro-controllers (e.g. Motorola MPC555, MPC563, InfineonTricore TC1796) the hardware (HW) vendors answered to thegrowing computation needs with increasing clock frequencies,optimized architectures and dual controller solutions. Thusthe power supplies and cooling efforts were similarly growingand the only way out was the introduction of dual-core anda bit later multi-core micro-controller architectures whichoffered the desired computation power basing on lowerfrequencies (e.g. Infineon Aurix TC2xx). In addition thehardware technology went down towards 40nm. In furtherevolution steps the HW architectures got optimized, but stillneeds to be optimized for the future again in order to react tothe increasing computation demands one can see in a forecastto the next decade of Powertrain applications. So it can beestimated already today that the needed computation powerin 2022 will be at least doubled compared to today.Nevertheless, multi-core architectures do not provideautomatically a gain of performance, particularly for highlycoupled systems with strong HW interaction as well as hardreal-time requirements. It might even be counter-productive,if it is not properly handled. So it is essential for the effectiveusage of these architectures to achieve freely distributableApplication SWC along cores by single runnables what hasalready been presented in a previous ERTS2 edition [6]. Butfor that a real multi-core BSW is required as a key enabler.Besides the main focus on efficiency, a maximum freedomin the allocation of the ASW runnables is required, knowingthat many of them need an access to the HW peripherals. Ofcourse, locking other cores while accessing the peripheral isnot an option, like enforcing all ASW components with HWinterface to be integrated on one and the same core.

B. The layered Architecture

A classical embedded software (SW), as it is defined forexample by the AUTOSAR standard, is typically split intofour main parts as shown in Figure 1:

• The high level applicative SW (ASW) which is designedin a way that it can be easily reused across systemplatforms, and across project configurations, e.g. for 4, 6cylinders, gasoline, diesel or electric engines. The ASWis named as SWC according to AUTOSAR.

• A runtime environment (RTE) which enables the inter-facing in between SWC and BSW modules.

• The BSW which enables the re-usability of ASW acrossdifferent HW platforms. For that, the BSW gives accessto the core services and peripherals, abstracting differentmicro-controllers as well as connected peripherals suchas ASICs and FPGAs of different vendors.

• The micro-controller hardware which is connected by theBSW towards RTE and application.

Figure 1. The ICC3 AUTOSAR BSW

C. Running Multi-Core-Ready Applications

From application point of view, it is a valid wish to runthe software on the system independently whether it is asingle or multi-core implementation. Anyway, it is not possibleto fix a distribution from the beginning of the project, tillthe start of production, for various reasons. And it is evenless possible to force a common core distribution betweendifferent projects using different HWs, following differentschedules, but nevertheless sharing common SWCs. To reach

Figure 2. Real Time Partitioning

this goal, the SWCs are designed independently of any coreassociation (but slightly prepared compared to legacy single

core context), and a new process cares about the challengingmulti-core issues such as increased scheduling complexity(parallelism, chaining, synchronization), increased integrationcomplexity (1500 runnables to be integrated in 100 containers)and concurrent accesses to shared resources.On the one side, the concurrent accesses to shared memory,has been solved in the Powertrain domain of Continental bythe introduction of an adequate and optimized process basedon an automatic protection, new architectural concepts (likee.g. core synchronized transitions) and protecting the SW bythe use of buffers [6]. So a slightly prepared software canbe freely distributed across cores, tasks, as well as multiplecontexts.On the other side, the concurrent accesses to the shared HWperipherals is ensured by a well prepared BSW. This meansin effect, the ASW will be free to access HW resources frommany different places, in one or the other direction (inputcapture, output control) or sometimes a mixture of both.

D. Distributing Application and Basic SoftwareFor efficient use of single, multi or even many core system it

requires a powerful and flexible BSW which provides commu-nication, diagnosis and input/output features to the applicationand which is scalable to all kinds of core configurations. In asimplified view the BSW connects the ASW to the hardwareto allow a re-use of the ASW on different hardware platforms.

Figure 3. A possible but inefficient Solution

In case the BSW is not well prepared for multi-core, andis accessible only from one core, one can easily end-upin a situation, where all ASW runnables which directly orindirectly access to a BSW interface and through it to a HWresource have to be located on the same core, where theBSW resides. This results in a long calculation chain andin strong integration constraints on the ASW runnables asalready described in the introduction and shown in Figure 3.Furthermore, as many recurrences are required, like describedin Figure 2, this may result in difficult interleaving situations.To avoid such inefficient situation, a real prepared BSW isrequired. But before defining this ideal multi-core BSW, oneneeds to understand the boundary conditions defined by theAUTOSAR standard. In addition the available micro-controllerarchitectures along the used platform have to be considered.

II. FROM AUTOSAR TO A MULTI-CORE BSW

A. AUTOSAR versus Multi-Core

Originally AUTOSAR [1] was developed for single corecontrol units, even if the standard considered to combinesuch ECUs with a bus system in between. Each controlunit is defined to contain exactly one application runningon one operating system (OS) instance. The first extensionof the AUTOSAR standard concerning multi core was onlysupporting the distribution of the ASW to different cores.Thereby at least one OS-Application is allocated to one coreand all items of a software component (runnables, non volatiledata blocks, exclusive areas) need to be solely implementedwith OS resources belonging to exactly this OS-Application.The communication in between should be done using theruntime-environment RTE / Inter OS Communication (IOC)and the BSW was assumed to run on a single core while allaccesses shall be performed exactly by this core. The IOC isdefined for that use case as highly generic mechanism offeringa superset of functionality to cover all possible use cases.In a second evolution step [2] the AUTOSAR standard sup-ports additionally the distribution of the BSW to differentcores. With this extension, the Schedule Manager part of theRTE provides features for the cross core inter and intra BSWmodule communication. Additionally the MemMap specifica-tion [5] contained in the AUTOSAR standard from version4.2.2 [3] onwards allows an allocation of symbols on differentcores. This is an important prerequisite for a multi-core BSW.A drawback of this second evolution was the low profoundnessof standardization. On the one hand this supports variousvendor specific extensions but on the other hand it drasticallydecreases the interoperability and performance of BSW fromdifferent vendors in a multi-core ECU.The biggest problem remaining in the AUTOSAR BSW ar-chitecture is the synchronous architecture which leads to aninterface design where it is expected that the called operationsact immediately returning the final status. Instead multi-corerequires asynchronous operation to avoid blocking of coreswhat is contradictive to the synchronous interface architectureof AUTOSAR. As a conclusion a rework of the interfacestowards asynchronous interfaces with according status opera-tions or feedback signals would be required.

B. Capabilities of a pure AUTOSAR Implementation

Looking at the AUTOSAR standard there is a RTE definedto connect application and BSW to allow a mapping ofinterfaces in between the layers and even OS-Applications.This allows to distribute ASW to different control units to usethe available computation power across the car in an efficientway as shown in Figure 4. But what is looking very promisingon car level might tempt one to apply it inside a multi-core micro-controller. But even if this is technically possiblefrom AUTOSAR perspective by using one OS-Application percore, this shows various drawbacks such as high CPU loadconsumption, memory overhead or unnecessary blocking ofcores or interrupts. Especially when considering a duplicated

Figure 4. Software Distribution across Control Units using AUTOSAR

Figure 5. Software Distribution across Cores using pure AUTOSAR

BSW (see Figure 5) one would cause access conflicts to thehardware as the BSW is simply existing twice. The CPU loadwould mainly be influenced in this scenario by the load on thebus system at the intersection of the individual cores towardsthe hardware resources.

To overcome this situation one would need to split the

Figure 6. Software Distribution across Cores using AUTOSAR RTE

BSW into parts which are assigned to cores with individualOS-Applications still using the RTE provided communicationaccording to Figure 6. This means, that the transfer of requeststo the right core towards the BSW would be done using theRTE invoking IOC. This avoids access conflicts on the periph-eral side, but still causes a high communication overhead inbetween the cores. A better alternative would be one of the

following ideas:• Transfer the application call chain to the core where the

BSW resides (see Figure 3)• Transfer the call on BSW level as an implementation

variant of the AUTOSAR BSW distribution specificationThe conclusions out of both approaches are on the one handthat the first idea is contradictive in terms of CPU loaddistribution across cores, causing high task response timesuntil execution chains can be completed. On the other hand thesecond idea could not be exactly implemented as the standarddescribes. This is because AUTOSAR requires an identicalbehaviour of the almost synchronous interface operationsindependent of the listed call scenarios below:

• call on a single core system• call from the same core than the one the BSW resides• call from a different core than the one the BSW resides

As a consequence, the synchronous operations defined in thestandard would block several cores when getting called, whatagain has a high influence on the CPU load. As an example,a simple operation of the AUTOSAR PWM driver shall beused, namely Pwm SetDutyCycle(), what is specified in tableTable I.

Table IAUTOSAR PWM SETDUTYCYCLE OPERATION

Service Name: Pwm SetDutyCycleReference: SWS Pwm 00097

Syntax: Pwm SetDutyCycle(Pwm ChannelType ChannelNumber,

uint16 DutyCycle)Sync/Async: SynchronousRe-entrancy: Re-entrant for different channel numbersDescription: Service sets the duty cycle of the PWM channel.

Following the AUTOSAR specification it is mandatory toimplement the operation as synchronous. That leads to thedrawback that one needs to implement a blocking wait to thePwm SetDutyCycle().As shown in Figure 7, the ASW is allocated on Core 1 andneeds to trigger a PWM output, using a distributed BSW.The ASW calls the according Pwm SetDutyCycle() operation,which then needs to transfer the control flow to core 2, whichis in the given example the BSW core. The operation on core1 then waits for completing the triggered action on the BSWcore which receives and processes the request in parallel. Af-terwards an according status will be set to notify the interfaceoperation on core 1 that the operation is finished which thencan unlock the ”blocking wait” and continues to operate. Thedrawback is obvious as two cores are blocked and no parallelexecution can take place at this time. This is especially difficultin co-operative or partly pre-emptive task environments whichare typically used in Powertrain applications. Only pre-emptiveenvironments using extended tasks could help here paying theprice with a high CPU load and memory overhead for theadditional operating system features reducing the ”symptoms”(instead of the root cause) of the blocking wait. Furthermore,extended tasks and therefore wait states, are not an option for

robustness reasons. Instead it is better to solve the root causeby generally preventing ”blocking waits” by the architecturedefinition even if the implementation then does not comply tothe AUTOSAR standard any more.

Figure 7. Blocking Behaviour of AUTOSAR PWM

C. The ideal Basic Software

Keeping the vision of distributing the application byrunnable to different cores one needs to have an ideal BSWwhich can be called from any core without taking care onwhich core it is really running on. This for sure needs tobe done without duplicating the BSW according to Figure 5but instead creating a BSW which offers interfaces on anycore implementing a kernel on a single core only. In between

Figure 8. Access to the ideal Basic Software

the interfaces and the kernel the control and data flow canbe realized using a module specific implementation foran optimal core resource consumption. Thus the BSW isreachable by any core without the need of routing the transferby the RTE and bypassing the OS-Application approach.That is as shown in Figure 8. For that purpose it is first ofall important to identify which BSW modules have to bereachable across cores and which ones can remain as singlecore module following the AUTOSAR defined architectureas shown in Figure 9 . This is important as some BSW

modules might be finally offered on one core only as theseare acting on hardware peripherals which have to be accessedexclusively. For all BSW modules identified as multi-core

Figure 9. Core Scope of BSW Modules

relevant one needs to decide for an according implementationbehind the user interface which ensures a suitable crosscore communication. For that purpose, a set of genericlibraries is offered which provides a generic implementationof according multi-core mechanisms to the BSW modules.But for what kind of implementation one shall decide? Andwhat paradigms shall be used as basis for the design choice?

1) The first BSW paradigm - A Blockade Free BSW:Generally an ideal realization requires that the BSW runnablescan be triggered asynchronously to avoid any kind of spin-lock situations. So, all synchronous operation calls need tobe considered as a simple buffer access. All asynchronousoperation calls need to be treated as requests to be queuedto the kernel and all blocking synchronized operation callsneed to be migrated towards asynchronous operations withan according feedback signal. Out of that considerations thefollowing two generic design patters are derived:

• Direct data (or peripheral) access for synchronous readingand writing of data

• Passing control (and data) flow for asynchronous actionswith optional feedback

While the first design pattern for direct data access shallbe applied especially for BSW drivers providing or writingatomic data such as ADC or DIO, what is shown in theAdc ReadGroup() example Figure 10. It can also be appliedfor drivers writing non atomic data such as SPI where acollision during the write and read is very unlikely. For the SPIcase it might be required to introduce a semaphore to avoiddata inconsistency in the unlikely case of a collision.

The second design pattern for passing control and dataflow with optional feedback is ideal for solving the PWMimplementation issue (see Figure 7) as it decouples the ASWcontrol flow from the driver operation performing the finaloutput as shown in Figure 11. As a precondition the ASWSWC calling the Pwm SetDutycycle() shall not perform anaction which depends on the finished PWM output. In otherwords the application shall not expect that the PWM operation

Figure 10. Direct Data Access using Adc ReadGroup()

is synchronously finished. If the application instead needs to benotified about the finished PWM output an according feedbacksignal needs to be used which can be generated at the PWMedge the value is transferred to the output peripheral. Thisfeedback signal would then start a system event (task) on adefined core according to Figure 12.

Figure 11. Pwm SetDutyCycle() as Fire & Forget

Figure 12. Pwm SetDutyCycle as Fire & Reply

2) The second BSW paradigm - An optimal cross CoreCommunication: This paradigm requires to implement thedesign patterns out of the first paradigm to realize a man-agement of data and control flow across cores. The multi-coremechanisms and design patterns derived have to be carefullyused as too much protection can again have a negative impacton the overall CPU load and memory consumption. So any

multi-core pattern shall be used in a minimal scope only (e.g.just protecting a minimal amount of C instruction inside afunction). Furthermore the implementation of the multi-coremechanisms shall cover a small set of use cases only tobe optimized for exactly one purpose to gain much betterperformance than globally designed mechanisms like IOC. Asa consequence a set of multiple design patterns and libraryimplementations is required to cover the required use cases ofa multi-core BSW.So, as one typical example, a hardware optimized messagepassing mechanism, named ”MEPA” is available in the Pow-ertrain platform as alternate to generic mechanisms such as theAUTOSAR IOC. MEPA offers the following send operations:

• Transfer a control flow to another core• Transfer a control flow extended by a simple 32bit

variable• Transfer a control flow extended with a pointer to a user

specific data packageOn receiver side one can either:

• Trigger an interrupt containing the receiver code• Trigger a system event (task)• Poll the event in a recurrent time grid

Thereby the order of incoming messages is kept and so theinputs are serialized. Furthermore the channels are individualfor each BSW module, means there exists at least onechannel per BSW module. Implementing all user operationson receiver side on the same interrupt or task level one canfurthermore save efforts for re-entrancy protection as thetasks or interrupts can not interrupt themselves. So disablinginterrupts is simply not required any more.

D. BSW Design for Multi-Core

To map the right functionality on the right core, the BSWhas to be analysed following the AUTOSAR stack approachin order to identify which of the BSW modules are interfacingto other clusters or ASW software components. Additionally,it needs to be analysed, which BSW modules are used insidean AUTOSAR stack only. For that purpose the considerationsshown in Figure 9 shall be re-used. Doing that, it needs to berespected that clusters or even parts of a functional stack shallbe distributable across cores. Out of the analysis the followingBSW multi-core types can be derived:

• Type 1: BSW modules with interfaces available on anycore and one kernel on a single core (e.g. DEM, FIM,MCAL drivers)

• Type 2: BSW modules with a distributed kernel executedper core (e.g. DIO, exception handler, interrupt driver,watchdog)

• Type 3: BSW modules available on a single core only(e.g. flash driver), the interfaces are not globally available

The transfer of data and control flow in between the BSWinterfaces and cores is realized according to the multi-coreparadigms inside the relevant BSW modules or at least insidethe BSW stack. So any kind of control flow transfer is realized

Figure 13. BSW Multi-Core approach

as trigger with optional feedback, and any simple data transferis realized as a kind of atomic (not interruptible) access assketched in Figure 13. According to that, it is possible thatany user can call the BSW directly without taking care aboutthe core on which it is finally executed.

E. BSW Examples

Before giving a set of examples related to the previouslydefined BSW multi-core types it has to be considered thatthere is no 1:1 mapping in between a function stack orcluster to exactly one multi-core type. Instead it is typically acombination of multiple types. So it is important to design thefunction stack or cluster in a way that all interfaces towardsother BSW function stacks, BSW clusters or SWC complyto type 1 and 2. Instead type 3 shall be used inside thefunction stack or cluster only. Finally the following threetypical examples shall be given:

1) Example 1 - Memory Stack - Type 1 and Type 3: TheMemory Stack (MEM) is required for any kind of memoryreprogramming. The non-volatile memory manager (NVM)especially cares about the storage of data for usage during thefollowing driving cycles. The NVM interfaces are required atany core and are provided as global (shared) code. Instead thekernel is in local scope of core 1. The used modules suchas FEE and FLS are available on this core exclusively. Thisensures that the data flash consistency can be managed onNVM kernel level. The NVM architecture shown in Figure 14visualizes the usage of the MEPA service which is used totransfer the incoming requests of the consumers to the NVMkernel. The requests then are polled by the kernel in a definedrecurrence, e.g. for writing ”on the fly data” to the data flash.If desired the consumer can be notified about the finishedrequest by using a MEPA callback, which this time triggersan according feedback task.

2) Example 2 - Communication Stack - Type 1 and Type 3:The communication stack provides communication servicestowards the application, where the COM interfaces for inter-system-communication need to be provided on any core. Thekernel implementation and even specific networks such as

Figure 14. Memory Stack - NVM Architecture (simplified)

CAN, Ethernet or Flexray are realized on individual cores.The motivation for this is a load distribution of the differentnetworks across cores. As shown in figure Figure 15 the centralpart is the PDU router which is generated per core, routingthe messages in between the different networks, the COMas user interface and the diagnostic communication manager(DCM). The PDU router consists finally of core individuallocal implementations using the MEPA service in betweento cross the core boundaries. The network stacks (e.g. CAN,Flexray, Ethernet) are provided as core local implementationsnot accessible by other cores as the only interface existstowards the PDU router. The DCM is also connected to thePDU router, but allocated on the same core than the networkused for diagnostic communication. This is to reduce theamount of messages and so the CPU load consumption ofinterrupts which would be required to transfer the calls acrosscore boundaries. The COM module is available as global(shared) code which is scheduled per core with an individualmessage configuration. So finally the messages are routed viaPDU router and COM to the correct SWC.

Figure 15. COM Stack Architecture (simplified)

3) Example 3 - MCAL - Type 2 and Type 3: The MCAL(Micro Controller Abstraction Layer) provides basic functionssuch as ADC, PWM, Digital I/O etc. which have to provideinterfaces to any core (see Figure 16). The ADC module

is implemented providing user interfaces as global (shared)code which can be executed on any core providing accessto the acquired ADC values. The ADC kernel instead isprovided core local and called by a task to recurrently triggerthe auto-scan conversion. The PWM instead is implementedbasing on MEPA, similarly to the NVM shown in example1 and is already sketched in the chapter ”The first BSWparadigm - A Blockade Free BSW”. The DIO driver is aspecial case, as the overhead of implementing any multicore implementation would cause much more CPU resourceoverhead as the resulting bus conflicts in case of concurrentaccesses in between the cores. So each core calls a global(shared) code of the DIO module which then directly accessesthe hardware peripheral, as the peripheral can be accessed inan atomic way.

Figure 16. MCAL Peripheral Driver Example (simplified)

III. CORE ABSTRACTION AND MULTI-CORECONFORMANCE CLASSES

A. Abstracting Cores

To make the BSW and application more independent afurther valuable step is to introduce a core abstraction ap-proach that allows a core clustering to separate calculationdomains, e.g. for the purpose of integrating different productsto one box, as engine and transmission control, or to separatecomputation clusters depending on the HW implementation.Furthermore it helps the ASW and BSW developers to thinkindependent of the core which is typically linked to a hard-ware implementation as the same core number could have adifferent meaning and available features on a different HW. Todistinguish and identify the cores, the core abstraction definesan own naming scheme consisting of two characters. The firstcharacter defines the calculation domain with the values ’A’to ’Z’, while the second character defines the abstract corenumber from ’0’ to ’9’. Typically a multi-core micro-controllerconsists of one domain ’A’, with e.g. 3 cores, but there mightbe future architectures providing several domains, like causedby a hardware bridge in between two groups of cores.As a typical example of today’s multi-core architectures threeabstract cores are integrated in one calculation domain withaccording attributes what are:

• A0 - Safe Core with safe and unsafe partitions for safetyrelated ASW and BSW

• A1 - Unsafe communication core• A2 - Unsafe alternate core

The application and BSW is assigned to the cores basing onaffinities to e.g. distribute the BSW load or to ensure thatsafety software is calculated on a lock-step CPU. On theASW side, this abstraction concept allows to share the samearchitecture (task system) between projects using differentcontrollers, where for example, not all cores have the samelevel of safety. With the core abstraction one can assign SWCand BSW modules already on platform level and manage ageneric project architecture. This enables a good overviewabout the correctness of ASW and BSW mapping in a givenproject.The abstract definition now needs to be transferred to the realproject HW by assigning abstract to physical cores such asshown in the example below for an Infineon TC29x:

• A0 - mapped to core 1 as this core has a lock-step featurerequired for safety implementations

• A1 - mapped to core 0• A2 - mapped to core 2

The core abstraction can be used furthermore when integratingseveral different applications to a multi or many core systemsuch as a combination of a transmission and engine systemusing for example a calculation domain A and B. So a flexiblemean is provided to develop ASW and HW independent BSWservices independent of the physical hardware.

B. AUTOSAR Implementation-Conformance-Classes (ICC)

As a starting point of the definition of multi-core confor-mance classes for BSW the AUTOSAR defined implemen-tation conformance classes (ICC) shall be used, which aredefined as follows:

• In an ICC1 BSW, only the interfaces to the SWC (routedvia RTE) are defined. The internal architecture is up tothe vendor.

• In an ICC2 BSW, the architecture down to the functionstacks and their interfaces is defined, what allows anexchange of internal solutions with a 3rd party.

• In an ICC3 BSW, the architecture is defined down tothe implementation of a BSW module what allows anexchange on module level. There is no freedom ofimplementation.

While the ICC3 level allows more flexibility for the OEMin the selection of SW vendors to have a maximumexchangeability between different software vendors, ICC1allows more freedom of implementation, and therefore moreoptimization possibilities for the BSW supplier. For functionaldomains, with tight real time constraints, the ICC2 approachis a good balance between these contradictive requirementsof performance vs. modularity.

C. Multi-Core Conformance Classes

Similarly to the ICC classification, a proposal of multi-coreconformance classification (MCC) is made: It corresponds todifferent implementation levels of multi-core concepts, fromlow to high level of achievement. The objective here is not onmodularity / re-usability point of view like the implementationconformance classes (ICC), but rather on the efficiency andabstraction, for the ”customers” of the BSW layer (e.g. ASWSWC, BSW Complex Device Drivers (CDD)) towards theirmulti-core constraints. Basically, if the AUTOSAR approach ismotivated by a better reuse and exchange of SW-components,across OEMs, across suppliers, across ECUs as well as acrossdomains it is not acceptable that these components have anycore related configuration. For instance, it is not acceptablethat a SWC has any requirement vs. a given core identifier orarchitecture. Even for pure internal reuse across projects of thesame domain (e.g. engine control), it must be possible that acomponent is reusable between a low end system based on adual core (e.g. Infineon Aurix TC26x) and a high end systembased on a 6 core controller (e.g. Infineon Aurix TC39x).As in a functional domain like engine control, the functionsare highly coupled, ahead of the individual components, onealso needs to share the same overall ASW architecture acrossthese different platforms: The coupling, and therefore theintegration constraints between the functions are independentof the underlying HW and BSW.Therefore, the following levels are defined:

1) MCC1 - Core specific BSW: The complete BSW isallocated on one Core, and accessible only there. An operatingsystem (OS) and some basic services are nevertheless availableon the other cores, so that ASW can already be scheduled onthese other cores, under the condition that it does not useBSW services. Depending on the typology of the application,this could be an acceptable constraint or not. For applicationshighly decoupled with the HW, with limited and localizedBSW interfaces, relaxed real time control, but high compu-tation power need, this MCC1 level might be sufficient. Whenmany different and coupled functions are interfacing the BSW(for inputs, outputs, diagnosis, etc...), this is more difficult, andleads to a lot of chaining across cores (Figure 3), as the BSW”affinity” conflicts with the ”sequence constraints” betweenfunctions. Obviously, this ends-up in a strong constraint onthe ASW integration, and an inefficient SW.A phase concept has been developed (see Figure 17), which

Figure 17. Phases in a 10ms Task

standardizes sequences and fix acquisition and commandphases [7]. It could fit to such MCC1 architecture, but it is

more a functional view, and in reality exchanges with the BSWare distributed over the complete sequence. But note that therecould be a MCC1 case, where only one core, out of all coresof the controller, can be used by the ASW. This might be anintermediate step in the introduction of multi-core, or even anarchitectural choice, when a high end controller is used fore.g. increased ROM demands rather than computation power.

Figure 18. Distribution of a Calculation Sequence on a MCC1 BSW

2) MCC2 - Distributable BSW: The BSW can bedistributed across cores, and the BSW interfaces are availableon all cores. In this case, the ASW components can belocated on any core, reaching to a high level of flexibility:Typically, an ASW component controlling a PWM doesnot need to be integrated on the same core, where thePWM driver is integrated. Furthermore, two different ASWcomponents controlling two different valves through PWMsdo not need to be integrated on the same core, althoughthey are addressing the same driver and the same HW. The

Figure 19. MCC2 BSW with Focus on Functional Coupling excluding BSW

driver takes care of the possible conflicts. With such a MCC2BSW, the freedom for ASW runnables integration is high,and one can concentrate on the pure functional and data flowconstraints. Of course, the level of freedom one can achievehere, depends on the underlying cross core communicationoverhead (e.g. buffering, interaction, locking, synchronization,...) or an acceptable asynchronism. For the majority of cases,like PWM commands, ADC inputs, and many more, thisoverhead, or asynchronism is fully acceptable. For someothers, not. For the more complex real time functions likethe acquisition of the engine speed (precision required in atime resolution of a few microseconds), the decoupling isnot affordable. For other functions the link to the HW is notmotivated by the real-time constraints, but by the availabilityof some HW feature on a given core: such as cores equippedwith a double precision floating point unit, cores withlock-step (checker) capability for safety implementations etc.

3) MCC3 - Abstracted BSW: The BSW provides an ab-straction of the cores, which eases the handling of diversitybetween cores, and controllers. For instance, even in thesame controller family (e.g. Infineon Aurix), the cores arenot equivalent (not full symmetric architecture): one core is

usually more suited to access the HW peripherals, one is moresuited to computation, not all may reach the same frequency,have the same performance index. It ends up in a situationwhere the best location for the BSW interrupts is core 0for one controller, but core 1 for another controller of thesame family. Similarly, safety relevant functions which haveto be executed under the control of a checker core have to belocated on core 0 on one controller, but core 1 on another one.The consequence of such situation (i.e. diversity of controllerarchitectures) is a variety of ASW architectures, as the coreallocation of the ASW functions finally might get influencedby the controller architecture. Therefore, to reduce this effect,a core abstraction concept as shown before allows to share thesame ASW Architecture (i.e. task system) for different projectsbased on different controllers. Abstract cores (SW cores) aredecoupled from real physical cores (HW cores), and a mappingis established between them.Out of the defined MCC one can easily apply the definition

Figure 20. MCC3 BSW with Core Abstraction for free Core Distribution

to the AUTOSAR architecture following the listed rules:• MCC1 is applied to all BSW modules which are intended

for the purpose of raw access to memory devices such asflash drivers, memory tests etc. So it is required that oneinterface level above performs the core abstraction.

• MCC2 is applied to BSW which needs to access HWperipherals or core registers and therefore needs to knowon which core it is operating such as typical MCALdrivers. Call-outs and interrupts need to be configuredto the correct physical core.

• MCC3 is applied to BSW which does not access HWand so does not need to know on which core it isintegrated to. Call-outs and interrupts are routed to theaccording core defined by the core abstraction set-up ofthe project.

Figure Figure 21 shows the assignment of MCC to theAUTOSAR architecture.

D. Achievements with Core Abstraction and MCC

Of course, the shown ideas of core abstraction and multi-core conformance classes (MCC) is standardized in our orga-nization, but may be adapted to answer a particular projectrequest. This approach allows also to handle the diversityacross HW families and controller suppliers. The same prin-ciple applies for all new families, and allows an extension toupcoming hardware architectures with 6 or even more cores.As an ultimate goal of the core abstraction, it is intended thatthe ASW is more and more integrated according to recurrence

Figure 21. AUTOSAR Architecture with assigned MCC

constraints (see Figure 2) and sequence constraints (see Fig-ure 17), more and more independently of core considerations.”Meta”-containers are defined, which contain a chain of tasksexecuted in sequence and on different cores. In some rarecases, core affinities can be specified which may influencethe targeted task (core). In this exceptional case, an affinityversus a specific feature of the core is specified, not to aspecial core identifier (which may not apply on a differentcontroller). For instance, affinity to an active checker core, toa double precision FPU, etc. may be specified.

IV. SUMMARY AND OUTLOOK

A. Conclusion

Using efficiently multi-core micro-controllers one can notdirectly apply the AUTOSAR standard to all ASW SWCs andBSW modules. This is because the standard does not allowa proper distribution of software across cores what woulddecrease the degree of parallelization according to Amdahl’slaw[8]. But to distribute the software one needs first an ASWwhich allows a core distribution by SWC runnable to keepcalculation chains, and second a BSW which is accessibleon all cores with an identical interface behaviour. This BSWarchitecture replaces several synchronous operations by asyn-chronous ones exactly at the point the core boundary needsto be crossed. Doing this the BSW also takes care aboutserialization of requests coming from runnable sequencesof different cores which could request concurrent access tothe BSW. The price for that is to leave the ICC2 interfacecompliance which then needs to be resolved by a kind ofinterface abstraction if the exact AUTOSAR behaviour isdemanded by the user software, e.g. in case of 3rd party orOEM solutions. At the end, both kinds of software can befound inside the Powertrain platform of Continental used incurrent products which are already used in series productionof several OEMs with well balanced ECUs regarding coreresource consumption according to Figure 22.

Besides the final implementation and the performanceoptimal solution it is important to provide an architecturewhich is understandable and re-usable. For that purposethe core abstraction is introduced to stop the thinking incertain cores but instead understanding the needs a software

Figure 22. Core Performance of current Projects

has towards the system it is running on, which are mainlyfunctionally driven. So it is obvious to introduce so called”Multi-Core Conformance Classes” (MCC) to be assigned toBSW modules or stacks what indicates to the ”customers”of the BSW what the BSW is able to offer in terms ofmulti-core compliance. Such is especially interesting assometimes 3rd party BSW solutions have to be applied whichare - unfortunately - mostly usable on single cores only. Soone can easily equip the AUTOSAR architecture with a MCCtag to describe the needs and multi-core compliance of agiven platform.

B. Future Steps

Unfortunately today there still exists a restricted visionof what can be done with multi-core micro-controller andsoftware architectures. Thus only a few software vendorsacting in the domain of Powertrain including the ones offeringshared services such as operating systems and communicationsolutions provide according multi-core solutions to the market.Therefore it is highly appreciated that the AUTOSAR consor-tium launched a work group in the work package architecture(WP-A) with the goal to rework the multi-core distribution ofBSW (WP-A MCBD) where the concepts of a real multi-coreimplementation shall be brought up to the standard. This shallbe done by driving the standard introducing the ideas sketchedwithin this paper.

REFERENCES

[1] AUTOSAR. Release 3.0. In http://www.autosar.org.[2] AUTOSAR. Release 4.0.3. In http://www.autosar.org.[3] AUTOSAR. Release 4.2.2. In http://www.autosar.org.[4] AUTOSAR. Release 4.3. In http://www.autosar.org.[5] AUTOSAR. Specification of memory mapping rev 4.2.2. In

http://www.autosar.org.[6] Denis Claraz, Franck Grimal, Thierry Ledier, Ralph Mader, and Gerhard

Wirrer. Introducing multi-core at automotive engine systems. In ERTS2,2014.

[7] Denis Claraz, Stefan Kuntz, Ulrich Margull, Michael Niemetz, andGerhard Wirrer. Deterministic Execution Sequence in Component BasedMulti-Contributor Powertrain Control Systems. In ERTSS 2012, 2012.

[8] Wikipedia. Amdahls law. In https://en.wikipedia.org, 2017.