DE102014103139B4 - Parallelized execution of single-core control software on multi-core vehicle control units - Google Patents

Abstract

The invention relates to a method for porting legacy control software (100) developed for a control unit (102) with a single arithmetic core (C0) to a vehicle control unit (103) having at least two arithmetic cores (C1, C2, C3). , The old control software (100) contains tasks (T-1, T-8, T-Cr) with one or more expiration parts (R_i) as well as an execution order (106) for the tasks. Priority constraints (PC1, PC2, PC3) are identified for write and read accesses to common persistent storage variables (Va, Vb) and weak priority constraints (PC2, PCx, PCy) are identified according to predetermined classification rules (109). An execution plan (105) for the execution of the legacy control software on the two or more cores (C1, C2, C3) is generated, with parallelization of expiration parts (R_11, R_81) with weak priority constraints (PC2). For each weak priority constraint (PC2), the associated persistent storage variable (Va) is stored in a separately managed database (108) that allows wait-free read and write access.

Description

The work leading to this invention has been funded under the Grant Agreement No. 287519 under the Seventh Framework Program of the European Union (FP7 / 2007-2013).

The invention relates to a method for porting Alt-control programs, which are designed for execution on a single-core (single-core), on a vehicle control unit (ECU) with at least two cores (multi-core).

So far, no satisfactory methods for implementing single-core control software on multi-core ECUs for automotive use are known, so that a parallelization of tasks is largely dispensed with and extensive parts of the legacy control software often run on only one of the multiple cores.

In practice, there are procedures for the parallelized execution of single-core developed Alt software on multi-core computers from other applications, especially in the field of PC software. However, these methods are unsuitable for the parallelized execution of control software of vehicles because they do not meet the specific real-time and safety requirements. In automotive software also exists due to cyclical execution no fixed start or end time, as is typical in PC programs, which also prevents the application of the previously known methods.

• • Basicevic, I. et al.: An Approach to Parallelization of Legacy Software. In: Proceedings of the 2009 First IEEE Eastern European Conference on the Engineering of Computer Based Systems, 2009, S. 42–48; und
• • Yohei Kanehagi et al.: Parallelization of Automotive Engine Control Software On Embedded Multi-core Processor Using OSCAR Compiler. In: Cool Chips XVI (COOL Chips), 2013, S. 1–3.

General information on the parallelization of single-core legacy software to multi-core systems can be found, for example, in:

• • Basicevic, I. et al .: An Approach to Parallelization of Legacy Software. In: Proceedings of the 2009 First IEEE Eastern European Conference on the Engineering of Computer Based Systems, 2009, pp. 42-48; and
• • Yohei Kanehagi et al .: Parallelization of Automotive Engine Control Software On Embedded Multi-core Processor Using OSCAR Compiler. In: Cool Chips XVI (COOL Chips), 2013, pp. 1-3.

It is an object of the present invention to provide a method for the parallelized execution of (single-core) old control software on a control unit having at least two computing cores, with which an increase in efficiency can be achieved. Furthermore, a software product is to be demonstrated, which performs the method. The invention solves this problem by the features of the independent claims.

Vehicle control software has some peculiarities that distinguish it from other software applications. For example, loops or recursions rarely occur to avoid high computational delays. If loops or recursive function calls are included in the legacy control software, their maximum execution count and / or recursion depth is limited. In order to exchange data between different tasks and / or their instances, common memory variables are defined that can be accessed by the various program sections.

The legacy control software typically includes a plurality of tasks (task sections). These tasks perform various tasks, such as the determination of current measured values and vehicle parameters, their conversion into control values and possibly the activation of actuators of the vehicle. The tasks are usually grouped together in software components. They are executed after an interrupt (periodically controlled), after an event (controlled by events) or directly through the operating system (OS controlled). The tasks thus have different forms of triggers.

The methods according to the present disclosure are preferably applied to legacy control software that includes AUTOSAR components. AUTOSAR components define interfaces (ports) for communication. Components contain drainage components (so-called runnables), which communicate with each other through these interfaces (sender-receiver, client-server). Tasks are configured, with runnables assigned to the tasks (runnable-to-task mapping).

The tasks access both volatile and persistent storage variables. Volatile memory variables are usually inaccessible to other tasks, only relate to inner computational values of a task and are released again at the end of a single execution, i. at the end of the runtime of an instance of a task.

Persistent memory variables are retained over the run times of several task executions and, if necessary, for the entire runtime of the control software in the memory. The value of a persistent storage variable may change repeatedly. Multiple accesses from different tasks to a shared memory variable can occur. Alternatively or additionally, repeated accesses from different instances of the same task to a common memory variable can take place. When executing the legacy control software on a single-core controller, the accesses are inevitably sequential.

The tasks and / or their instances can perform read and / or write accesses. In the case of memory variables that are used for measurements or operating parameters on the vehicle, there is usually exactly one task that performs a write access (producer) and one or more other tasks that execute read accesses (consumers).

In the old control software developed for single-core systems, most tasks are started by period triggers (the so-called clock / a system clock) and executed until their processing is completed, whereby intermediate preemption (in computer science also as suppression termed - English: Preemption) can extend the total processing time (see below).

As a rule, a basic clock is defined for the execution of the periodically started tasks, whereby the tasks are started every nth period trigger. The basic clock is basically freely selectable. Purely by way of example, it is assumed below that the basic clock is 1 ms. It could also be shorter or longer.

Depending on the relevance of a task, a very different periodicity may be provided. The periodicity is usually defined as a multiple of the basic clock. As periodicity may be provided correspondingly repetition frequencies of less than 1 ms to several seconds.

It can also be provided in the old control software tasks that are started event-based. These tasks therefore have an event trigger. An event-based triggering can be carried out in particular as a function of a current crank angle value.

Frequently, an execution order of the tasks is explicitly defined in the legacy control software. The execution order determines which task is to be processed next in case of a (release) collision. In the following, release collision is understood to be a momentary state in which more than one task is simultaneously pending execution. Different variants for the occurrence of collisions are explained below.

The execution order can be in any representation. As a rule, priorities or priorities are assigned to the tasks as parameters. Alternatively or additionally, one or more ranking lists can be defined, in each of which the relationship between a first and a second task is determined, which of these has priority. Alternatively, other means of establishing an execution order may be used.

Within the duration of a basic clock, a single-core control unit can have several tasks to execute, resulting in an internal collision within the basic clock duration. Then, these tasks are executed in sequence according to the predetermined order, i. it starts with the highest priority or highest rank task and then continues to the next lower priority or next lower rank task.

If the last task at the beginning of the next cycle has not yet been processed, a deadlock-type collision can occur.

When executing the old control software on a single processor, only a single task can be executed at any one time. To ensure that high-priority tasks (especially for cross-stroke collisions) are processed without any loss of time, single-core ECUs are usually preceded by task sequencing (so-called "preemptive sequencing"). The preemption may be done using the execution order, or using a separately defined preemptive ranking (displacement ranking).

When two or more tasks are competing for execution, a decision is made as to which task receives immediate priority based on its ranking. For example, if a low priority task is being executed, and before it is processed, a higher priority task is (re) released for execution, then the high priority task preempts (ie displaces) the low priority task. This means that execution of the low-priority task is interrupted until the higher-priority task has been executed and fully executed. Only then will the processing of the low prioritized task continue. In other words, in an inbound collision or inter-frame collision on a Singe-Core controller, the highest-priority task is immediately processed by the processor while the other tasks are paused. Pre-emption can be multi-level, creating multiple levels of interruption.

Within each task, one or more expiration parts (English: Runnables) are present in the old control software. These expiration parts can be explicitly defined or determined by analysis. The expiry parts are forcibly executed one after the other on a single-core control unit, ie sequentially.

The sequencing of the tasks and the expiration parts contained therein is largely defined in the legacy control software and results, for example, from the source code. There is a macro-sequencing and a micro-sequencing. The macro-sequencing follows from the control flow of the tasks among each other and results implicitly from the execution of the tasks according to the given execution and / or preemptive ranking (see above). Micro-sequencing is dictated by the calling order of the expiration parts within a task.

There are compelling dependencies that are taken into account in the development of vehicle control software for establishing micro and macro sequencing to ensure that a directed data flow is maintained over time. This data flow must always start from sensor data and end with the output of actuator data. It is therefore a sensor-to-actuator sequencing. It may also be referred to as producer-to-consumer sequencing, where a producer is a thread that writes a piece of data used by other threads and a consumer is one of those other threads that accesses the piece of data. If this sequencing were violated, it could lead to access to not yet generated measured values, to negative feedback in the control loops or to indeterminate system states on the single-core control units. From sensor to actuator sequencing can be reconstructed from the micro and macro sequencing included in the code.

The micro and the macro sequencing for the execution of a legacy control software on a single-core control unit can be determined analytically if necessary. For example, the micro-sequencing (control flow) may be extracted automatically using a program code compiler.

The macro sequencing can be reconstructed based on the assigned time triggers and task priorities.

In the method according to the invention, the expiration parts of the various tasks are executed as far as possible in parallel on the two or more calculation cores. The control flow and directed data flow, i. Macro sequencing and micro-sequencing of the legacy control software should be maintained to the extent required to meet the external requirements of the control software, particularly with regard to robustness, predictability of behavior, and timing characteristics. For this purpose, the communication (data transfer) between the expiration parts is analyzed.

Priority restrictions on write and read accesses from the expiration parts to shared persistent storage variables in the legacy control software are determined. This determination can basically be done in any way. It is preferably provided that within a task the control flow is determined by means of a compiler. Priority constraints are extracted from the control flow along with the analytically determined memory accesses. To simplify the method, it may be provided that only data flow dependencies (from write-to-read expiration parts) lead to priority restrictions.

Based on predetermined classification rules, weak and strong priority constraints are identified within the identified priority constraints. Above all, the precedence restrictions classified as weak are decisive. The classification rules make such priority Determines restrictions that have only a negligible effect on the robustness and / or predictability of the control software.

An execution plan is created for the execution of the legacy control software on the two or more cores of the (multi-core) vehicle control unit, which provides for a parallelization (also) for those run-off parts between which there is a weak priority constraint. The creation of the execution plan can be done in any way. According to a preferred embodiment, list-based scheduling is used. The task parts are first sorted into a list, with the priority constraints defining order over the list. Then the task parts are distributed to free processors according to the order in the list. It may be provided that the expiration parts of the legacy control software are distributed to new or different defined tasks. In other words, an adapted runnable-to-task mapping can be generated.

Additionally, for each weak priority constraint, an associated persistent storage variable is established in a separately managed database. It is advantageous if the database allows wait-free read and write access.

In other words, the exchange of current communication data pertaining to a weak priority restriction, which is carried out sequentially on a single-core control unit (ie first write current data, then read the current data or first produce, then consume current data), separated and replaced by the use of a (slightly) older buffered data value.

This parallelization of expiration parts under buffering and changing the seniority of the exchanged data leads to a drastic increase in the parallelization. In comparison to an unchanged retention of the communication relationships between the expiration parts, considerably more expiration parts can be executed at respective earlier times on parallel calculation cores. Consequently, the computing power of the multi-core controller can be used much more efficiently, so that simpler hardware can be used and / or the power consumption of the controller is reduced.

Using appropriate classification rules for the precedence relationships ensures that only appropriate expiration parts are parallelized.

The method according to the invention can be carried out for porting the legacy control software into an adapted control software with a customized multi-core execution plan in any software environment. Above all, the design in a development environment or on the multi-core control device itself come into consideration. The adapted software can be generated in the multi-core vehicle control unit itself or recorded in this and executed there. The porting and possibly the recording can be done in particular by a software product, which executes the porting method automatically. The software product can take over the legacy control software as an input product and output a parallelized control software that can be transferred to the multi-core vehicle control unit. If necessary, information about the structure and / or structure of the single-core control device and / or the multi-core vehicle control device and the respective configurations during porting can be taken into account and processed by the software product.

A task is to be understood in the following as a separately executable task section. Such a task section may, for example, relate to the generation of an updated measured value, such as, for example, the determination of a pressure or temperature value. Furthermore, a task section may relate to the further processing of a measurement or control value for a control task, for example, the determination of a desired value from a map or the specification of a timing for the control of a fuel injector.

An expiration part is a separately executable program element within a task. A expiration part contains a sequence of instructions which can be called by the runtime environment (RTE, in particular an AUTOSAR RTE). For example, these may be separately declared functions that perform individual subtasks within the task.

System-critical tasks or the measurement value update for particularly important parameters can be executed in tasks / expiration parts with a short periodicity, for example as 1ms tasks or 2ms tasks. It can also be provided significantly shorter repetition. Less critical tasks or measured value updates for only sluggishly changing physical sizes can be significant at one longer periodicity, for example as 8ms tasks, 128ms tasks or 1024ms tasks or expiration parts.

The tasks triggered by events, in particular by the achievement of predetermined crank angle positions, usually have the highest priorities in the control software for vehicles. They are often required for engine management and include, for example, control tasks for the fuel delivery system and fuel injection.

By the classification rules, expiration parts are found in the legacy control software, the producer and consumer of a data element exchanged between them, whereby the communication between producer and consumer is asynchronous and where producer and consumer have a distinctly different execution characteristic in the single-core execution plan. If the development specifications valid for vehicle control software are adhered to, communication components that are communicatively connected to one another only occur in program structures which have a non-time-critical data flow profile, for example, outside of closed control loops or direct links of control statements. Accordingly, in such schedules, it is likely that transforming the associated data flow by changing the seniority of a data item read by a consumer for further processing is highly likely to have no adverse effect on the robustness or external control result of the software Parallelization of these drain parts can be exploited to increase efficiency. This is even more the case if the producer expiration part is executed at a very high execution frequency, ie at intervals of 10 ms or less.

The invention is illustrated by way of example and schematically in the drawings. Show it:

1 : A schematic representation of the porting of legacy control software to a multi-core vehicle controller;

2 : Examples of tasks with contained expiration parts, forms of triggers, and an execution order;

3 : Schematic representations of a control flow and a data flow for the in 2 presented tasks;

4 u. 5 : Execution plans for processing legacy control software on a single-core and a multi-core controller;

6 : A data flow between two tasks with different types of triggers

7 u. 8th : Examples of the classification of weak priority constraints.

The invention relates to a method for the parallelized execution of legacy control software ( 100 ) required for a control unit ( 102 ) is developed with a single arithmetic-logic core (C0) on a vehicle control unit ( 103 ) with at least two computing cores (C1, C2, C3, C4), which in 1 is illustrated. The old control software ( 100 ) will be prepared with a new implementation plan ( 105 ) (Multi-Core Schedule) for execution on the multi-core vehicle control unit ( 103 ) ported. If necessary. For example, adaptations of the source code known from the prior art may be performed in order to provide parallelized control software ( 101 ) to create. In particular, the partitioning of the old control software ( 100 ) under separation of the included tasks and expiration parts.

1 shows the porting procedure in a schematic view. The method can be used, in particular, for legacy control software that is based on an AUTOSAR standard for a single-core control unit ( 102 ) has been developed on the multi-core vehicle control unit ( 103 ). Such legacy control software is particularly well suited for porting, since in the AUTOSAR standards strict specifications for the data exchange, ie the communication, between tasks and the scheduling parts contained in the tasks are specified. The AUTOSAR Virtual Function Bus (VFB) can be used for finding privilege restrictions and applying the classification rules ( 109 ) are analyzed in an automated manner to determine communication ports, transceiver data exchange, and associated persistent storage variables. The classification rules preferably evaluate formal structures in the legacy control software. Accordingly, there is no need to know what physical or logical content a persistent storage variable has, for which a priority constraint is determined and, if so, as is weakly identified. This enables a fully automated implementation of the porting method for a wide variety of forms of legacy control software ( 100 ).

Furthermore, it is assumed that the old control software ( 100 ) is an AUTOSAR-compliant application with a plurality of tasks (T-1, T-8, T-Cr), some of which are executed at a respective predetermined periodicity (eg P = 1ms, P = 8ms). Other tasks (T-Cr) can be started on an event-based basis, in particular as a function of specific crank angle positions of the vehicle engine. For the tasks, an execution ranking ( 106 ) in the form of assigned priority values and / or leaderboards.

Parallelization of expiration parts in the old AUTOSAR control software can be performed especially for priority constraints on asynchronous communication operations. In particular, this includes a transmitter-receiver communication, if it provides for the storage of a data element at a write time by the transmitter (producer expiry part) in a shared persistent storage variable (Va, Vb) and this data element is received from the receiver (consumer). Expiration part) is read out at a different reading time, wherein the reading time occurs relative to the writing time with a non or varying specified time delay. In other words, a parallelization of expiration parts is provided for such precedence restrictions in which a read time asynchronously follows a write time.

A parallelization of such a producer expiration part with one or more consumer expiration parts provides that they are executed in parallel on two different cores (C1, C2, C3) - and not, as provided in the data flow on the single-core control device, one after the other. Due to the temporal parallelization of the consumer expiration part is thus activated to a temporally forward shifted starting point. At the same time, the seniority of the data read by the consumer expiration part is transformed such that not the value currently generated by the current instance of the producer expiration part but a cached value of the last preceding instance of the producer expiration part is used. To enable this, the shared persistent storage variable is stored in a separately managed database ( 108 ), which allows parallel read and write access. The access to the persistent storage variable is preferably waiting time-free, so that no write or read delays arise in the parallelized expiration parts. Furthermore, a parallelization is only carried out for those expiration parts for which, according to the classification rules ( 109 ) a weak priority restriction has been identified.

2 shows by way of example a legacy control software ( 100 ) with three tasks. Task (T-1) is executed at a periodicity (P) of 1 ms, ie very frequently. This task includes a plurality of expiration parts (R_11, R_12, R_13) containing various instructions that are executed according to the calling order ( 107 ) were processed sequentially on a single-core control unit.

The task (T-8) also contains a plurality of expiration parts (R_81, R_82, R_83) with a predetermined calling order and is executed at a periodicity (P) of 8 ms.

The task (T-Cr) includes expiration parts (R_Cr1, R_Cr2, R_Cr3) and is event-based, executed here when certain crank angle positions occur.

The tasks (T-1, T-8, T-Cr) are assigned priorities (prio) that make up the execution order ( 106 ) and / or a preemptive ranking for execution on the single-core controller.

Through an analysis of the execution order ( 106 ) as well as the calling order ( 107 ), the regular control flow (cf. 3 , left), from which the (macro- and micro-) sequencing of the processing of the individual expiration parts (R_11 to R_83) results.

By analyzing the communication defined in the source code between the expiration parts and / or the envisaged write and read accesses from the expiration parts (R_11 to R_83) to shared persistent storage variables (Va, Vb), the data flow between the expiration parts can be ascertained 3 , shown on the right.

Expiration part (R_11) in task (T-1) determines a measured value (M1) and writes it to the common persistent storage variable (Va) each time it is executed. Thus, the expiration part (R_11) is a producer with respect to the common storage variable (Va). The expiration parts (R_12 and R_81) have a read access to the common persistent storage variable (Va) to generate the control values (A, B) using the data stored therein. They are consumers in terms of the memory variable (Va).

The process variable (R_82) acquires another measured value (M2) and stores it in another common persistent memory variable (Vb). These are read-accessed by the expiration part (R_83) to generate another control value (D). The expiration part (R_Cr1) contained in the event-based executed task (T-Cr) also accesses this persistent storage variable (Vb) to generate another control value (E).

From the right part of 3 It can be seen that there are priority restrictions (PC1, PC2, PC3, PC4) between the operating parts accessing a shared persistent storage variable (Va, Vb) and writing there, which are represented here by the data flow direction (from sensor to-actuator sequencing) are shown.

A parallelized execution of such expiration parts linked together by precedence restrictions can potentially lead to indefinite system states. This is to be expected, for example, when data elements in a consumer expiration part are used in conditional statements (for example if or while loops) or within closed control loops, and a time-critical data flow profile exists between producer and consumer. So only those expiration parts should be parallelized, in which even with a change in the data flow, no relevant impairment is to be expected in terms of the control result, which consequently have no signs of time criticality.

This is achieved by determining the ascertained priority restrictions (PC1 to PC4) according to predetermined classification rules ( 109 ) are divided into strong and weak priority constraints.

The classification rules can be stored as automatable instructions in the form of software and executed by an automated porting program, which the Alt-control software ( 100 ) and a parallelized control software ( 101 ) with a newly created multi-core execution plan ( 105 ).

4 and 5 show a single-core execution plan ( 104 ) and a multi-core execution plan ( 105 ) in an exemplary comparison representation.

In the in 4 single core flowchart ( 104 ) all tasks (T-1, T-8 and T-Cr) are executed according to the given execution order ( 106 ) (Priorities) are executed sequentially on the arithmetic kernel (C0). If two tasks (T-1, T-8) are competing for execution within one basic clock (here, for example, at t = 0 and t = 8), the higher-priority task (T-1, priority: 0) is executed first. After its complete processing, the processing of the lower-priority task (T-8, priority: -) then follows.

The event-based tasks (T-Cr) are usually started immediately after the occurrence of a triggering event (Cr-Event). If a preemption is provided (see above), a high priority task may interrupt the execution of a lower priority task (not shown here).

In the in 5 illustrated multi-core execution plan ( 105 ), all expiration parts within the tasks (T-1, T-8, T-Cr) are parallelized as far as possible, ie distributed to different calculation cores (C1, C2, C3, C4) and executed in parallel. A parallelization readily takes place for those expiration parts between which there are no priority restrictions, that is to say, which do not exchange any data elements among one another and thus essentially execute independent processing operations. Such expiration portions (R_11, R_12 and R_81, R_82) between which strong priority constraints (PC1, PC3) have been identified are executed sequentially and typically on the same arithmetic unit (C1, C3).

Expiration parts (R_11, R_81), between which a weak priority restriction (PC2) has been identified, are also executed in parallel, whereby an adapted data flow (X) is provided between these expiration parts (R_11, R_81) or their instances.

6 shows a special case of a data flow between two expiration parts (R_11, R_Cr1) from two tasks (T-1, T-Cr) with different forms of triggers (period trigger vs. event trigger). Again, this is asynchronous communication. In this case, the periodically executed expiration item produces (R_11) a data item stored in a shared persistent storage variable (Vx) and consumed by the event-based expiration portion (R_Cr1) on each execution. On the other hand, the expiration part (R_Cr1) produces another data item which is stored in a storage variable (Vy) and consumed by the expiration part (R_11). There is thus a mutual dependence between these expiration parts (R_11 and R_Cr1) in the form of bidirectional restrictions (PCx, PCy). Through the porting method according to the invention, also such mutual priority restrictions between two expiration parts started by different forms of triggers can be parallelized, and preemption between these expiration parts can be dispensed with - provided that the precedence restrictions (PCx, PCy ) are classified as weak.

7 and 8th clarify two preferred classification rules to evaluate a priority constraint as weak. In 7 According to the single-core execution plan, a producer expiration part (R_11) is executed at a high frequency, here for example a periodicity (P = 1 ms), whereby a write access to a shared persistent storage variable takes place each time. A consuming expiration part (R_51) is significantly less frequently executed, here with a periodicity (P = 5ms). In the single-core execution plan, the execution of the expiration portion (R_51) would occur sequentially after execution of the expiration portion (R_11) to maintain the from sensor to actuator data flow. The priority restriction existing between these expiration parts (R_11, R_51) is classified as weak because the periodicity of the producer expiration part (R_11) is an X-fold, here a 5 times, the periodicity of the consumer expiration part (R_51). The classification rule may be generally formulated such that a priority constraint between two expiration parts is classified as weak if the periodicity (P) of one expiration part is more than X times the periodicity (P) of the other expiration part, where X is a predetermined one Limit is. The threshold value X may preferably be a factor of 3 or greater.

The very different frequency of execution of the two expiration parts belonging to the weak priority restriction represents a strong indication that there is no critical connection between the associated control methods, so that a transformation of the data flow between these expiration parts with high probability has no influence on the robustness and the has external control result.

8th illustrates another preferred classification rule. 8th shows a single-core execution plan for two process variables (R_11, R_Cr), which are started by different forms of triggers (period trigger versus event trigger), in analogy to 6 and over a slightly longer time frame. It can be seen that the execution of the expiration part (R_Cr) is completely independent of the timing of the expiration part (R_11). Again, this is an indication that there are no critical communications between these expiration parts. Furthermore, the expiration part (R_11) is executed at a high frequency, here with a periodicity of (P = 1 ms).

The associated classification rule may be generally formulated such that a precedence constraint (PCx, PCy) between two expiration parts is classified as weak if the expiration parts (R_11, R_Cr) are started by different forms of triggers (period trigger versus event trigger) become.

Another preferred classification rule is that a precedence constraint between two expiration parts is classified as weak if the periodicity of one task is not a natural multiple of the periodicity of the other task. An example of this would be if a first task is executed every 20ms and a second task every 1024ms, or when the periodicities are 20ms versus 48ms. Such tasks or the expiration parts contained therein can not have a synchronized control behavior among each other, so that a parallelized execution (which is only comparatively rare anyway, namely with each occurrence of a least common multiple of the periodicities), will not have any negative effects.

The technical implementation of the method according to the invention can be done in different ways. The legacy control software may already contain a clear definition of tasks, their expiration parts, execution orders, and invocation orders. Alternatively or additionally, these features may be determined by analysis and possibly reverse modeling of the legacy control software. In this case, provision can be made, in particular, for the legacy control software to be partitioned, whereby the tasks and expiration parts contained are separated and, for each expiration part, all write and read accesses to persistent storage variables are determined.

A priority restriction for the access to a shared persistent storage variable between two expiration parts can be determined, in particular, if a write access in the legacy control software has to be made by a producer expiration part before a read access by a consumer expiration part.

In practice there are different possibilities for creating a separately managed database ( 108 ) known. In particular, such a database can be created and managed in a random access memory (RAM) that is accessible by all participating processor cores (C1-C4).

A wait time-free access to a persistent memory variable stored there can preferably be achieved by applying for each memory variable a main memory value and at least one buffer memory value, wherein a buffer memory value is read-accessable while a write access to the main memory value takes place , Thus, in such a case, a consumer expiration portion executing on a first arithmetic core (C1) may read-access a last value in the buffer storage value, while at the same time a parallely executed producer expiration portion stores a new updated value in the main buffer. Memory value writes. The content of the buffer memory value may preferably be adjusted after each write access to the updated value of the associated main memory value. Alignment can be done in any way, for example by copying cell contents and / or changing memory addresses / pointers.

Alternatively or additionally, the separately managed database ( 108 ) provide a single memory cell with atomic access for a persistent storage variable. By a single memory cell may be meant a single physical cell. Accesses are always atomic, ie they are executed by the processor in a single clock step. Inconsistencies due to simultaneous writing and reading of a variable do not occur.

However, there are data types that occupy more than one memory cell (64-bit integer to 32-bit architecture). In this case, atomic access can be guaranteed / protected by additional mechanisms. LIST OF REFERENCE NUMBERS 100 Old-control software Legacy control software 101 Parallelized control software Parallelized control software 102 Single-core control unit Single-core control unit 103 Multi-core control unit Multi-core control unit 104 Execution plan (single-core) Schedule (single-core) 105 execution plan Schedule (Multi-Core) 106 Execution Ranking Execution order 107 Calling sequence Calling order 108 Separately managed database Separately managed data base 109 classification rules Classification rules C ... solver (Processor-) Core I / O Input / output Input / output X Adapted data flow Adapted data flow T-1 1ms task (periodic) 1ms task (periodical) T-8 8ms task (periodic) 8ms task (periodical) T-Cr Cr-Task (Cr-triggered) Cr-Task (Cr-triggered) r_i the end part runnable PCi Precedence constraint Precedence constraint M1 reading Measured value M2 reading Measured value Va Persistent storage variable Persistent storage variable Vb Persistent storage variable Persistent storage variable A control value Control value B control value Control value D control value Control value e control value Control value P periodicity periodicity

Claims (8)

Method for automated porting and parallelization of legacy control software ( 100 ) required for a control unit ( 102 ) is developed with a single arithmetic core (C0), to a vehicle control unit ( 103 ) having at least two computing cores (C1, C2, C3), the method being executed in any software environment and comprising at least the following steps: determining a plurality of tasks (T-1, T-8, T-Cr), wherein some of the tasks (T-1, T-8, T-Cr) are to be executed at a respectively predetermined periodicity (P), and an execution order ( 106 ) is provided for the tasks, and within each task (T-1, T-8, T-Cr) one or more expiration parts (R_i) each having a predetermined call order ( 107 ), - determining whether there is a write access (producer) and another task a read access (consumer), PC2, PCx, PCy), wherein a priority restriction is classified as weak if: - a flow part from a producer task to a shared memory variable (Va, Vb) is write only and another flow part from a consumer task is shared Memory variable read only accesses and there is a data flow dependency from the write to the read expiration part, and if - the periodicity (P) of the expiration part from the producer task, more than X times the periodicity (P) of the expiration part of the consumer task , where X is a predetermined limit value of 3 or greater, OR - the periodicity (P) of the expiration part from the producer task ni It is a natural multiple of the periodicity (P) of the expiration part of the consumer task (P = 5ms vs.. P = 1024ms), OR - the expiration parts (R_11, R_Cr) are started with different forms of triggers (period triggers, event triggers), - creation of an execution plan ( 105 ) for the execution of the legacy control software on the two or more cores (C1, C2, C3) with parallelization of expiration parts (R_11, R_81) with weak priority constraints (PC2), - for each weak priority constraint (PC2) storage associated persistent storage variables (Va) in a separately managed database ( 108 ). A method according to claim 1, characterized in that the legacy control software is partitioned using the following steps: - separating the tasks contained in the legacy control software (T-1, T-8, T-Cr) and expiration parts (R_i), - For each expiration part (R_i), determining all write and read accesses to persistent storage variables (Va, Vb). Method according to one of the preceding claims, characterized in that the separately managed database ( 108 ) allows wait-free read and write access. Method according to one of the preceding claims, characterized in that in the separately managed database ( 108 ) for a persistent memory variable, a main memory value and at least one buffer memory value are applied, wherein a buffer memory value is read-accessible while a write access to the main memory value takes place. A method according to claim 4, characterized in that after a write access the content of a buffer memory value is adjusted to the updated value of the associated main memory value. Method according to one of the preceding claims, that the separately managed database ( 108 ) for a persistent storage variable (Va, Vb) provides a single memory cell with atomic access. Software product for porting legacy control software ( 100 ) required for a control unit ( 102 ) is developed with a single arithmetic core (C0) into a parallelized control software ( 101 ) on a vehicle control unit ( 103 ) is executable with at least two arithmetic cores (C1, C2, C3), characterized in that the software product executes a method according to one of the preceding claims. Software product according to claim 8, characterized in that the software product is designed to use as input product the legacy control software ( 100 ) and the parallelized control software ( 101 ), which is on the vehicle control device ( 103 ) is transferable.

Images