Grams CO 2 per kilometer, normalized to NEDC US-LDV

Introducing Multi-Core at Automotive Engine Systems D. Claraz 1 , F. Grimal 1 , T. Leydier 2 , R. Mader 3, G. Wirrer 3 1: Continental Automotive France SAS, 1, av. Paul Ourliac, BP 1149, Toulouse -France 2: Virtualised Reeled, 4, rue du romarin -31650 Saint Orens de Gameville -France 3: Continental Automotive Germany AG, Siemensstr.12, Regensburg -Germany 1. Introduction / Motivation (why multi-core)

With the introduction of the new Euro 6, and Euro 7 emission standards for passenger cars, the combustion process of Engine Management Systems needs to be controlled with an increased precision.

In addition, new vehicle architectures are introduced (increased integration of functions inside an Engine Management System), as well as new SW architectures concepts like AUTOSAR or the support of ISO26262. All these evolutions result in an increased need for computation power.

To face this challenge, the increase of the CPU frequency (today up to 300 MHz), which has widely been used in the past, is not anymore an option, due to power dissipation limitations. Therefore, the solution emerging on the market now, and promoted by our microcontroller suppliers, is the use of Multi-Core technology. In a first part, we will describe the challenges we have to face to make a legacy engine systems SW Multi-Core compatible.

In a second part, we will give some elements of the solution we have developed.

In a last part, we will give a status on where we are concretely.

Originally, our plan was to introduce the Multi-Core approach together with our new AUTOSAR-based architecture concept EMS3-PowerSAR ® . But the migration of a full project to this new PowerSAR ® architecture is not possible in a short time frame, and we foresee that our next projects will have to deal with a mixture of different architectures.

Then, since December 2011, we focus on a short term solution to make our EMS2 "legacy" SW platform Multi-Core compatible. This is called EMS2-MCR ("Multi-Core Ready").

EMS2-MCR is based on a PowerSAR ® / AUTOSAR BSW layer, on which the migrated legacy ASW is integrated, together with components of the new ASW PowerSAR ® architecture. Our objective was to distribute a legacy project on a 3-Cores ECU, and run a demonstrator-engine by end of 2012/beginning of 2013.

Challenges a. Methodological challenges

The methodological challenges are multiple:

-Backward compatibility: Our SW-development process is highly reuseoriented ("reuse by reference"), based on a concept of reusable aggregates stored in generic libraries, and developed by generic teams. Customer projects, managed by customer-oriented teams, select solutions from these generic libraries, and configure them for their own context (configuring being different than modifying).

Such an approach requires that the generic library is an "asset" common to all projects, and means that the functions are developed and maintained once, in the generic teams. Consequently, our first objective is to ensure that a function migrated to the new EMS2-MCR context must be still reusable as it is in a classical EMS2 single core context (for instance w/o RTE), as all projects will not migrate simultaneously on the new HW platform. Furthermore, the effort to maintain 2 parallel branches of the same function (one Single Core branch and one Multi-Core branch) would be too high: duplication of teams, of competence, … -Independence vs. Core allocation: The design of the function must not take any assumption about its own and other's core allocation. This is due to the fact that we are not able to define, once forever, the distribution of the functions on the Cores. The distribution will change over the time, due to new incoming constraints, due to our gain of experience, ISO-26262 considerations, load balancing, RAM consumption, customer requests, diversity of projects (single core projects dual core projects, triple core projects reusing the same functionality), diversity and evolution of the HW (1 to 3 cores today, 5, 6 or more in the future?), …

-Automatic protection of code:

The problem of concurrent access to resources, a classical problem in real time systems, gets a special high degree of complexity with Multi-Core, as intercore communication does not care of task priorities: A low priority task on Core 1 can "disturb" a high priority task on Core 2, and vice versa.

During the last decade, the protection of the code has been ensured at Continental Engine Systems by the essence of our scheduling scheme: cooperative scheduling ensures a nearly free of charge data consistency. Only in few cases, preemptive scheduling is used, which requires special attention for the developers, in term of data handling.

But the correct handling of race conditions is in general error prone, and requires additional effort, thus increasing development time & cost.

Last but not least, the same function might be integrated differently in different projects with different architectures, and still needs to be properly protected. A manual and a priori protection cannot comply with a big diversity of architectures.

-Efficiency of the protection: Considering the particularity of Engine Systemshigh coupling between the control functions -the efficiency of the solution gets high importance.

Basically, the resources to protect here are data, and they must be protected in an efficient way: The air mass entering the combustion chamber is consumed more than 6.000 times a second, while the engine rotation speed (rpm) is used 30.000 times a second, and in more than 300 different modules. In total an Engine System Software has to deal with 20.000 variables in around 600.000 of lines of code.

Different concepts are introduced to handle such situation in an efficient way. For instance, a standard approach of buffering data at a beginning of a task, or disabling interrupts at each access point, similar to what AUTOSAR implicit & explicit communication [START_REF]AUTOSAR 4.1.1 Specification of RTE -AUTOSAR_SWS_RTE 3[END_REF] proposes is not an option here.

-Improved integration: The difficulties linked to integration in the Enegine System domain have already been adressed, in a single core context [START_REF] Claraz | Engine management software dynamic architecture versus integration[END_REF]. The introduction of Multi-Core inevitably increases the complexity of the architecture. A project with 30 operating system tasks in Single Core will get up to 70 to 80 tasks in the future, or even more depending on the number of cores.

New integration constraints and artefacts will raise up, which will be defined at function level, to be considered at integration level. Different projects will follow different criteria for the distribution of the SW across cores. The total control of integration and architecture will be necessary for the control of data protection.

-Human factor / applicability: The solution should be understandable, and usable by the whole organization in a short time-period. We cannot make every developer an expert of Multi-Core architecture. The tools and methods should be easy to use. Finally, the migration to the new concept should be fast and supported.

b. Migration

As already mentioned, our purpose is to migrate our SW library to the new Multi-Core Standard. As this migration is done while all projects are in development, we need to ensure that there is no regression introduced with the migration. A default single core behaviour shall be ensured.

In order to speed-up the migration of hundred thousands of lines of code, a tool has been developed, which takes the legacy SW, and introduces the necessary material in the code to make it multi-core compatible. The basic cases, most frequent, are treated automatically, while the more complicated ones need to be treated manually. In all cases, a review of the migrated code is done by the function experts. This has required an exhaustive identification of the use cases, in the code, quite a challenge knowing that some of the SW modules are more than 10 years old, and taking into account that architecture rules, coding rules might evolve with time.

Complex code structures, complex design patterns have been considered, and their applicability in a MultiCore context have been studied. For some of them, new patterns have been introduced. For instance, the classical « double buffering » pattern has been replaced by exclusive areas, as it does not apply in all cases of core distribution.

c. Technical challenges

Which distribution?

The first question to answer when we switch from single core to multi core (e.g. 3 cores) is the distribution strategy: Do we have a dynamic, or a static distribution? What is the rationale to distribute this or that Aggregate on this or that Core?

As the objective of the migration to multi-core is to gain CPU load, the basic question is to define which policy is the best to reach a balanced load. Angle vs. Time computations? Short deadlines vs. long deadlines? Vehicle functions vs. engine functions? ASIL modules vs. QM modules?

A first approach would be a functional approach: The distribution over the cores is defined by the functional partitioning. For instance, all inlet related functions on 1 st core, all setpoints related functions on 2 nd core, and all exhaust related functions on 3 rd core.

Another topology could be based on the dynamic architecture of the SW: all engine-angle related aggregates (a clear specificity of combustion engines) on one core, all pure time dependant aggregates on another core.

A third approach could be based on the speed / deadlines of functions: Short deadlines on the first core, middle deadlines on the 2 nd core, and long deadlines distributed on the 3 rd core.

Each of these topologies has advantages and drawbacks. Due to the strong coupling of the functions (another clear specificity of combustion engines), they are not easy to apply, in particular when computation sequences matter. In effect, a classical 10ms Task might gather up to 150 Runnables which in many cases need to be executed in a well defined sequence. Therefore, the distribution of such task over 3 different cores can be done, only if the execution order is kept.

At the end, the code distribution is a multidimensional problem, and the allocation will be a balance between the buffering effort, the sequence needs, the customer request, etc... We foresee that we will need a high flexibility, and we will not be able to ensure for a long time that this or that function will always be mapped to Core 1.

Finally, the objective is to distribute the CPU load in an equilibrated way across the cores.

Therefore, we target a distribution based on runnables, rather than modules, or even compositions. At integration time, the project will have the possibility to move one runnable from one core to another, taking into account its own policy.

Split of components?

Another question we faced concerns the ability to split SW-Components on different cores, something today not authorized by AUTOSAR.

As most of the SW-Components are not monolithic in terms of dynamic architecture, they need to be integrated in different Tasks / Integration containers.

If we mix this status with the need to ensure a correct sequence between runnables, we see that it shall be possible to locate different runnables of the same component on different cores, depending on the integration Task.

Moreover, complex cases like multi-rate data (data produced at different rates, e.g. top dead centre and 10ms), or even multi-rate executables needs to be supported. This includes executables called by different tasks on the same core, or even on different cores.

Scheduling strategy

A last question concerns the Task scheduling: Is a dual core architecture a simple duplication of the simple core architecture? By evidence, no, because the complexity of the whole system would not be controllable : A typical single core project contains up to 30 OS Tasks, plus some 20 containers for system transitions, which means around 50 integration containers, where individual runnables need to be plugged. A simple duplication of these containers on each core would lead to a high complexity, and probably an unfeasible system, in term of deadline fulfilment.

So, an adequate architecture is set-up, with new concepts. For instance, for a given rate, some tasks might be either parallelized, or chained. Both techniques have advantages and drawbacks.

d. Starting point : Legacy SW

A classical approach, when introducing a new technology like MultiCore would be to start from a white page, design all functions new, and even take some assumptions concerning their Core allocation. But, the corresponding effort and delay would be too high, and as already mentioned, a fixed allocation does not fulfil our needs. Therefore, our starting point is a legacy SW. But what does it mean exactly?

A typical legacy Engine Systems SW project is built of around 2.000 SW modules (1.300 for asw), more than 8.000 executables, and 1.500 of them to be integrated in a task. Around 150.000 data access points need to be considered for data access protection.

In term of mechanisms, ahead of the multi-rate data and executables already mentioned, the reality of a legacy SW is a complex call structure sometimes reaching more than 10 nested call levels, with indirect calls, with complex data types, etc… One typical topic is the « consolidation » of the data and control flow in such « non flat » architecture.

Another difficulty, inherent to legacy-SW is the mixture of formats: AUTOSAR files mixed up with legacy files, and/or with object code from our OEMs.

Solution : Integration & Protection

In this chapter, we will show the main principles of the solution developed to integrate runnables and to protect data in the EMS2-MCR SW, satisfying the above constraints. As a prerequisite, the legacy code had to be prepared to be MCR, which means (roughly) the replacement of all direct accesses to global variables by GET/SET APIs, to allow their protection by an adequate process.

a. Concepts

This solution is organized around 2 main axes: Integration and Protection.

i. Runnable Integration

Runnable integration gets a higher degree of complexity in multi core context, compared to a single core context: -The total number of tasks and integration containers is largely increased compared to single core (even if not multiplied by the number of cores) -The criteria to choose between one and the other task on one or the other core might be more complex (multi-dimensional problem)

In addition, we want to benefit from the "new" platform to improve our integration process.

So, the solution to this problem has 2 facets:

At Component or Composition level, integration constraints are specified: System Events (stimulus), , Phases [START_REF] Claraz | Deterministic Execution Sequence in Component Based Multi-Contributor Powertrain Control Systems[END_REF], Timing properties (periods, deadlines …), Sequence Needs, Core Affinity Needs are defined, using a component modelling tool, CoMod.

On project side, these constraints are reused by a runnable integration tool, RunIn, enabling the integration of Runnables at the correct position in the correct Task. Conflicts are shown and can be solved by the integrator. Runtime of Runnables can be imported in order to properly balance the computations across the cores. Additional constraints can be defined at integration time as well.

ii. Data access Protection Data protection in Multi-Core context becomes also much more complex, compared to the "automatically protected" mode of Single Core Cooperative context. We remind here, that cooperative scheduling is widely used at Continental, as it has the following benefits: First of all, in most of the cases, it is largely sufficient to answer to our Deadline constraints. Secondly, it is resource efficient, as there are very limited context switches. And last but not least, it provides us a data protection "free of charge": no particular design constraint, no tool is needed to ensure data protection. Computations simply do not interrupt each other.

With Multi-Core now, as any task on any Core can disturb any other task on any other Core, the situation is quite different.

Two kinds of problems are identified: stability (an information gets a stable value across 2 different Runnables), and coherency (2 information are coherently acquired at a certain point in time). One cornerstone of our strategy is that only those artefacts which require protection will be protected.

We choose this strategy because we estimate the cost of protecting everything too high, due, once again, to the high coupling and complexity of Engine Systems. In addition, an unnecessary buffering may have negative impacts on the SW behaviour, and not only on the resource consumption point of view.

So, the component modelling tool, CoMod, supports the specification of so-called "Consistency Needs". To be noted that this concept of Consistency Needs has been promoted and then introduced in AUTOSAR (and available in 4.1.1).

At project side, these constraints are taken into account by the integration tool. RunIn analyses the project and computes all required protection, taking into account the complete call and data graph, the specified ConsistencyNeeds and the project architecture. It generates all necessary C and ARXML files for the further SW build.

Fig. 5: Data protection by Buffering

The strategy chosen to protect the data is based on a buffering concept: When a variable is accessed in one Executable, if we identify a race condition, and if a protection is required for this variable, then it is copied into a buffer, and the Executable works on this local copy. If the Executable modifies the data, the modification is done on the buffer, and the value of the buffer is copied in the global variable later on.

The principle is similar to the AUTOSAR concept of implicit communication.

Fig. 6: Buffering concept

To enable this, in the migrated code, special access APIs have been introduced, which allow an eventual re-direction. Depending on the conditions, the GET and SET macros will be redirected to buffers. Fill and flush routines are added to the Runnable scheduling, in order to initialize the Buffers, and to copy back the value in the global memory.

In order to minimize the buffer consumption, the same Buffer can be reused across different runnables, for different data, in the same task. This is part of our optimization process.

The Code patching strategy, similar to what is done by a classical RTE, presents several advantages compared to the object file patching strategy, also used at automotive engine systems. Some of these advantages are:

-It can be used early in the process, in particular before the sw Build. Therefore, the integration choices can be influenced by the Buffering results. -The output can be verified easily -The process is independent of any compiler version, or compiler option -It is an open solution which easily supports complex use cases, like multi-rate executables b. Architecture control One element of the strategy is to identify and control properly the project architecture. The tasks and integration containers, their allocation to the cores, their timing properties, and their priorities have to be defined, as they are important factors for the integration, as well as for the protection. For the data protection, for instance, the interactions between the tasks have to be identified (direction, type, …). The resulting buffering and copy routines will depend on it.

Fig. 8: Task configuration

In order to ensure that the theoretical view on the architecture, used for integration and protection, is consistent with the real implementation in the ECU, different configurations are generated in a seamless environment: typically RTE and OS configurations, as well as all the required « glue code ». One last element of the architecture control, particularly important in a strong reuse context, is the introduction of a Reference Architecture, which is used as well by the Function Developers when the specify their integration needs, as well as the projects when they build their project architecture. The Reference Architecture is managed in a centralized way, and defines the main choices of the new multi core platform.

c. Need specification

On the developer's side, 2 types of Needs can be specified: Protection Needs and Integration Needs.

Based on an analysis of the data & control flow of its module, the function developer is able to specify the coherency or stability needs. Roughly either he specifies 2 (or more) variables which have to be read in a coherent way in one Runnable. Or he specifies 2 (or more) Runnables which need to get the same value for a given variable. This represents a new kind of activity for the developers, which means not only a new task, but a new kind of topic, of concept he has to think of. Concerning the integration, for each of its Runnables, the developer specifies the required timing and integration properties. In order to avoid a big variety of needs, a set of standard System Events is provided through a Reference Architecture.

The developer has only to select the one of interest, as well as the Phase the Runnable corresponds to. Doing this, he defines a « RunnableEvent », which is a similar concept than the AUTOSAR concept of RteEvent (with the notable difference that no invokation mechanism is specified here, which gives more flexibility on how to solve this invokation).

Fig. 12: A Runnable Event (Integration Need)

d. Integration & Protection

The integration and protection process takes as input the previously defined project architecture, the specified Needs of the individual modules, and the SW cartography. This last element consists in resolving for the whole SW all data accesses. All types of accesses have to be identified (arrays, pointers, structures, …), as well as their multiplicity and consolidation.

The previously defined RunnableEvents are used by the integrator to select the right task for each runnable. The specified Phase and Sequence constraints are used to define the position in the task. In case a mistake is done, the integrator is informed by special warnings. When all Runnables are integrated, the protection process is launched. The tool takes into account all parameters, and defines which variables need to be protected, how, and at which point in the task. In addition to these 3 elements, various configurations are generated, which ensure a perfect fit between model and real implementation in the ECU.

Status

Since we started to develop this approach, in December 2011, most of the 1.300 Sw-modules have been migrated, in the scope of a first pilot (gasoline) project. A new (diesel) project is currently started, which will reuse partly the already migrated aggregates, and which will require new migrations.

The migrated aggregates are reused in the running single core projects, w/o noted bad effects: That demonstrates their backward compatibility.

In the first pilot project, more than 400 consistency needs and 2700 RunnableEvents are specified.

When applied, together with complementary automatic protection strategies, near to 2.000 buffers are used to buffer around 8.000 accesses (out of 130.000). The measured overhead is in the range of 6% of CPU load, distributed over the 3 cores, which is an acceptable value.

The first distribution applied on our pilot shows the following results, in term of CPU load evolution: Concerning real customer projects, a first project with a premium german OEM started to use this method by beginning of 2013 (SOP End 2014, 200ku/year). This first project is split over 3 cores, and uses preemptive scheduling. With the same OEM, we start another project, which also uses 3

cores, but with a different distribution of the SW. Another project with another German premium OEM is also started based on our pilot, also distributed on the 3 cores. Finally, another project for a US OEM will use also this technology, but in a limited way, by using only 2 cores.

Conclusion

Ahead of a simple Tool Suite, the EMS2-MCR solution is a methodology based on a series of new EMS3--PowerSAR ® concepts implemented coherently across the process: Reference Architecture, System Events, Synchronized Transitions, Phases, Runnable Events, Consistency Needs, Sequence Needs, Core Affinity Need etc ... These concepts, originally planned to be used within an AUTOSAR-based platform, have been quickly tailored and applied on a legacy non-AUTOSAR Platform. This has been made possible by an abstraction of our needed concepts vs. AUTOSAR. These concepts, and the method and tools supporting them are now at common use at Continental, and different Customer projects are already developped following this new standard.

But, this is the beginning of the story, and we need to improve and enrich the solution. For instance, the integration process has to be re-considered due to Multi-Core needs. Schedulability, SW distribution, ASIL introduction, shared development, validation, are on our table for the coming year.

Of particular importance will be the integration of AUTOSAR SW-Components in our framework. The questions will be about the mixture between Legacy non-AUTOSAR SW and AUTOSAR SW, the efficiency of the RTE (and therfore, which use?), the introduction of the new concepts (Consistency Needs, ...), and advanced integration means. One question on the static integration, is for instance the needed adaptation of external AUTOSAR components: even if the component uses the same version of the standard, like we do, is it sufficient to integrate the component w/o problem, or are there some adaptations necessary?

Fig. 1 :

 1 Fig. 1: Evolution of Emission standards (Sources: European Commission, EPA)

Fig. 2 :

 2 Fig. 2: Evolution of cpu freq vs. Power dissipation

Fig. 3 :

 3 Fig. 3: Example of design pattern valid for preemptive single core, but not applicable on multicore A last point to consider in the migration has been the training of all the function developers to the new standard. More than 200 developers have been trained in the last 2 years, not only on the code migration but on the whole MultiCore concept, which means new methods, architecture, and associated tools. On the project side, Project Architects have also been trained to these new concepts.

Fig. 4 :

 4 Fig. 4: Stability & Coherency issues Here again, our solution has 2 facets: At component development time, protection constraints are specified, and at project integration time, the constraints are used to protect the SW.

Fig. 7 :

 7 Fig. 7: Migrated code.

Fig. 9 :

 9 Fig. 9: Project Architecture

Fig. 11 :

 11 Fig. 11: A Coherency Need

Fig. 13 :

 13 Fig. 13: Integration of RunnablesIn the above picture, we see the Runnables integrated in a task, and their respective Phases.

Fig. 14 :

 14 Fig. 14: Data protection by Buffering Ahead of the simple graphical view, all the necessary files for the build process are generated:

Fig. 15 :

 15 Fig. 15: Fill and Flush routines inserted in tasks Then, the bodies of the copy routines are produced:

Fig. 18 :

 18 Fig. 18: Core-wise CPU load (as function of engine rotation speed) after distribution Most of our engineers are getting trained to the concepts of multi core, and are able to specify Protection and Integration Needs, while the project Teams are able to cope with the new architectural artefacts, and integration means.