DE102014216381A1 - Control device and operating method for this - Google Patents

Abstract

The invention relates to a method for operating a control unit (100), in particular for a motor vehicle, wherein the control unit (100) has at least one execution unit (110, 120), preferably at least two execution units (112, 122) designed in particular for executing task programs, wherein a first task program (112) and a second task program (122) are executed at least temporarily, characterized in that the first task program (112) sends a notification (B) to an execution unit (120) executing the second task program (122) wherein the notification (B) signals to the second task program (122) and / or the execution unit (120) executing the second task program (122) that the first task program (112) is ready to receive data from the second task program (122) ,

Description

State of the art

The invention relates to a method for operating a control device, in particular for a motor vehicle, wherein the control device has at least one, preferably at least two, especially designed for execution of task programs execution units, wherein at least temporarily a first task and a second task are performed.

The invention further relates to a control device, in particular for a motor vehicle.

A patent publication in this field is the DE 102 29 520 A1 ,

Disclosure of the invention

It is an object of the present invention to improve a method and a control device of the type mentioned in that an increased utility is given.

This object is achieved in the method of the type mentioned in that the first task sends a notification to an execution unit that executes the second task, the notification the second task and / or executing the second task execution unit signals that the first Task is ready to receive data from the second task.

According to one embodiment, each of the execution units may be a physical or virtual core of a computing unit, such as a computer. a microprocessor or a so-called CPU (central processing unit) or a digital signal processor (DSP) act. The task programs, also referred to as "tasks", may all be executed on the same execution unit according to one embodiment. However, a distribution of the task programs to different execution units is preferred. The task programs can be controlled, for example, in a manner known per se by an operating system which can likewise run on the computer. In particular, the operating system can make a resource allocation of the arithmetic unit to the task programs.

By means of the approach according to the invention, synchronization is advantageously enabled in such a way that a task program which has data to send to another task program is informed by the other task program about a (earliest) possible reception time. As a result, the time of data transmission can be kept flexible or adapted to the current utilization of the task programs involved, and in particular in the case of many data exchange tasks with each other, an unnecessarily high utilization of a memory or bus system, which is used for data exchange, to special Intervals are avoided. Another advantage of the invention is scalability. The principle according to the invention can be applied to control units with arithmetic units, which have a large number of cores, that is, execution units, while maintaining a reproducible and deterministic behavior.

In a preferred embodiment, it is provided that the first task program sends the notification when a predeterminable number of calculations of the first task program, in particular all calculations of the first task program, have been carried out for a current time slot assigned to the first task program. This ensures that the receiving first task is really ready to receive data.

In a further preferred embodiment, it is provided that the first task program sends the notification at the end of a current time slot assigned to the first task program.

In a preferred embodiment, it is provided that data from a memory area assigned to the second task program is transferred to a memory area allocated to the first task program, when the first task program has previously sent a corresponding notification to the execution unit executing the second task program, and the second task program all Has performed calculations for a current time slot associated with the second task.

In a preferred embodiment it is provided that a third task program is executed in order to transfer data from a memory area assigned to the second task program to a memory area allocated to the first task program. This variant enables a simple implementation of the invention using operating systems that are particularly available in the automotive sector. Furthermore, the task of sending or transmitting data to the first task program can largely be taken over by the third task program, so that the second task program does not have to have the corresponding functionality.

In a further preferred embodiment, it is provided that the first task program and the second task program have different cycle times, wherein a cycle time of the first task program is greater than the cycle time of the second task program, and wherein data from a memory area associated with the second task program in one of the first task allocated memory area within that cycle of the second task program, which is temporally in the range of a cycle end of the first task program.

In a further preferred embodiment, it is provided that the first and second task programs are executed on the same execution unit or on different execution units. The execution of at least one task program on a further computing unit, which is connected to a computing unit of the control device according to the invention e.g. Connected via a network is also conceivable. According to a variant of the invention, the principle according to the invention is also particularly advantageously applicable to arithmetic units which (only) have an execution unit designed to execute task programs.

As a further solution of the object of the present invention, a control device, in particular for a motor vehicle, specified, wherein the control unit at least one, preferably at least two, in particular designed for execution of task programs execution units, wherein at least temporarily a first task and a second task executable are characterized in that the first task program is adapted to send a notification to an execution unit executing the second task program, the notification signaling the second task program and / or the second task program executing execution unit that the first task program is ready To receive data from the second task.

Further advantageous embodiments are defined by the dependent claims.

Hereinafter, exemplary embodiments of the invention will be explained with reference to the drawings. In the drawing shows:

1 schematically a block diagram of a control device according to an embodiment, and

2 schematically a flowchart according to an embodiment.

1 schematically shows a block diagram of a controller 100 according to one embodiment. The control unit 100 has at least one non-mapped computing unit such as a microprocessor or a so-called. CPU (central processing unit) or a digital signal processor (DSP), which in turn each have one or more execution units, such as calculation cores, which are designed to task programs ( English: "tasks").

Present are in 1 by way of example a first execution unit 110 and a second execution unit 120 displayed. Using the execution units 110 . 120 and the tasks performed on them 112 . 122 can the controller 100 Receive input data E, eg physical measured quantities, process them and / or output them as output data A. In the present case receives the second task 122 the input data E, and the first task 112 For example, outputs output data A to an external unit (not shown).

A data connection 130 enables the data exchange between the execution units 110 . 120 or the task programs 112 . 122 , Here is the data connection 130 through an in 1 indicated to the right arrow to indicate the general direction of the information flow related to the input data E and output data A. Nevertheless, it is the data connection 130 preferably a bidirectional data connection.

In addition to the task programs 112 . 122 On the first and / or second execution unit also other task programs 140 be executed.

According to the invention, it is provided that the first task program 112 a notification B to the execution unit 120 sends the second task 122 executing the notification B, the second task 122 and / or the second task 122 executing execution unit 120 signals that the first task 112 is ready to get data from the second task 122 to recieve. According to one embodiment, the notification B may also be via the data connection 130 be transmitted.

By the approach according to the invention is advantageously a synchronization allows such that a task 122 which data to another task 112 has to send through the other task 112 is informed about a (earliest) possible reception time. As a result, the time of data transmission can be kept flexible or to the current utilization of the participating task programs 112 . 122 and, particularly in the case of many data interchanging task programs, unnecessarily high utilization of a memory or bus system used for data exchange can be avoided at specific intervals. Furthermore, a simple scalability of the overall system 100 in terms of execution units 110 . 120 and task programs.

2 schematically shows a flowchart according to an embodiment, the data exchange between the task programs 112 . 122 of the control unit 100 out 1 following the principle of the invention illustrated. This is exemplified by the first task 112 as receiving task ("Receiver Task 112 ") and the second task 122 as sending task program ("Sender-Task 122 "), although in other embodiments the data flow direction (sender-> receiver) may also be reversed.

On the time scale t, a start time t0 is specified, to which both task programs 112 . 122 start a new operating cycle. For the following description it is assumed that the first task 112 ( 1 ) Time slots ZS1 ( 2 ) of 10 ms (milliseconds), also compare with the curly brace 112 ' marked lower area of the 2 , The first cycle of the first task 112 From time t0, therefore, until the time t2, the second operating cycle of the first task program extends 112 extends between times t2, t4, etc. The interval or cycle boundaries between successive time slots are indicated by rectangles R1.

How out 2 , Area 112 ' , it can be seen, requires the first task 112 but not always the full cycle time or length of the assigned time slot of 10 ms in the present case. Rather, it is a processing of all tasks of the first task 112 in the first operating cycle already at the time t01, and a processing of all tasks of the first task 112 in the second cycle of operation already at the time t21. In other words, in the first operation cycle, a time interval t2-t01 exists between the end of the execution of the first task program 112 and the interval limit R1, in which no activity of the task 112 is present and thus for the entire cycle time of 10 ms reserved computing resources of the execution unit 110 remain unused.

Analogous to the first task 112 are the second task 122 ( 1 ) also time slots ZS2, ZS2 '( 2 ) of constant length, in this case 5 ms assigned, compare also with the curly bracket 122 ' marked vertical middle area of the 2 , The first cycle of the second task 112 From time t0, therefore, until the time t1, the second operating cycle of the second task program extends 112 extends between times t1, t2, etc. The interval or cycle boundaries between successive time slots of the second task 122 are indicated by rectangles R2.

How out 2 , Area 122 ' , it can be seen, requires the second task 122 but not always the full cycle time or length of the allocated time slot of 5 ms in the present case. Rather, it is a processing of all tasks of the second task 122 in the first operating cycle already at the time t02, and a processing of all tasks of the second task 122 in the second cycle of operation already at the time t11.

In addition to the areas 112 ' . 122 ' indicating the activity of each task 112 . 122 is in 2 another usage scheme 114 one of the first task 112 assigned first memory area and a usage scheme 124 one of the second task 122 assigned to the second memory area.

In the second memory area 124 the sender task 122 (second task) are according to an embodiment of the transmitter task 122 for example based on the input quantities E ( 1 ) calculated quantities which are sent to the receiver task 112 (first task) should be transferred. The transfer 14a . 14b the data from the sender task 122 to the receiver task 112 takes place according to one embodiment, when the transmitter task 122 has completed the calculation of the output data G, and at the same time the receiver task 112 with the processing of the data received in the previous cycle 15 is done.

According to one embodiment, the recipient task sends 112 a notification B to the execution unit 120 the sender task 122 as soon as the calculations have been completed within one execution, ie at the latest at the end of the cycle of the receiver task 112 , see. Time t01 in 2 ,

In a preferred embodiment it can be provided that a third task 140 , hereinafter also referred to as "notification task" executed, in this case, for example, of the second task 122 executing execution unit 120 to get data from a second task 122 (Transmitter Task) associated memory area 124 in a first task 112 (Receiver task) associated memory area 114 transferred to. In particular, this third task 140 be activated by the notification B.

In today's automotive industry standard operating systems, the notification task 140 eg in a list of activated tasks of the execution unit 120 with the same priority ("ready queue") and executed as soon as no other task with higher priority has to be executed and the tasks previously entered in the same list have been terminated As described above, the sender and receiver task 122 . 112 be executed on the same or on different cores.

In one embodiment, the transmission of the data G to the first task 112 (Receiver task) within the execution of the notification task 140 or at the end of the sender task 122 , depending on which event occurs later.

Provided the notification B before the termination of the sender task 122 in one embodiment, the data transmission 14a then at the end of the transmitter task 122 take place, ie after the time t11. In this case, for example, the sender task 122 itself the data transmission 14a initiate or execute. Unless the notification B 'occurs after the sender task 122b In one embodiment, the notification task 140 the transmission 14b the data to the receiver task 112 initiate or execute.

When exactly the notification task 140 in relation to the sender task 122 in one embodiment depends on the priorities of the two tasks. If both tasks 122 . 140 have the same priority is excluded that the tasks 122 . 140 can interrupt each other and the notification task 140 can be either before or after the sender task 122 depending on when the notification B, B 'in relation to the execution of the transmitter task 122 he follows.

In a further advantageous embodiment, it is provided that the first task program 112 and the second task 122 have different cycle times ZS1, ZS2, wherein a cycle time ZS1 of the first task 112 is greater than the cycle time ZS2 of the second task 122 , and where data from one of the second task 122 allocated memory area 124 in a first task 112 allocated memory area 114 within cycle ZS2 'of the second task 122 which is temporally in the range of a cycle end of the first task 112 lies.

In an advantageous embodiment, an algorithm is provided which ensures that the transmission of the data G from the sender 122 to the recipient 112 exactly once per slower cycle ZS1 or time interval takes place. Through a counter mechanism within transmitter or receiver task 122 . 112 ensures that only the last execution 1220 . 2 , the "faster" task 122 within the time interval ZS1 of the slower task 112 a data transfer 14a (for example, by notifying B when the recipient task 112 has the higher activation rate) or executes (if the sender task 122 is activated more often). For this purpose, a counter is incremented at the end of the faster task. If the count equals the ratio of slower sample time to faster sample time, data transfer is allowed and the counter is reset to zero.

In the example of 2 has the sender task 122 the higher activation rate of 5 ms compared to 10 ms in the receiver task 112 , Therefore, according to one embodiment, only every other execution 1220 . 1222 a data transfer 14a . 14b performed, but not in the versions 1219 . 1221 , This advantageously ensures a deterministic behavior in the sense of the "Logical Execution Time".

The following program examples show schematically how further statements according to the principle of the invention using the example of a communication from the transmitter task 122 (hereafter: "s") to the receiver task 112 (in the following short: "r") can be implemented:

On the execution unit 110 Recipient 112 at the end of the receiver task "r", eg at the time t21, program code similar to the following is inserted, assuming in the sense of a general representation of more than one transmitter task:

It can be seen that for all task programs ("tasks") from which data is received, a counter ("counter_r") first checks whether data is to be received in the current time step. This only affects the transmitter tasks with a slower sampling rate, otherwise the counter can be omitted. In the example in 2 needs the receiver task 112 no counter, because in each time step or cycle results of the faster transmitter task 122 or the constant counter _r _max is set to the value "1" for this communication relationship In both cases, notification of the sender is performed by activating the task "notify" in each time step.

On the execution unit (arithmetic unit) of the transmitter task "s" is now immediately or later, the task "notify" (corresponding to the notification task described above 140 ) carried out:

First, setting the logic variable "receiver_ready" 22 announced on the sender side that the receiver is ready to receive data, for example after receiving the notification B according to the invention at the time t01. If the sender is already ready to send the data, a function "copydata" is executed, which reads the data from the memory area 124 the transmitter "s" in the memory area of the receiver "r" communicates, the type of data transmission from the computer architecture of the computing unit of the control unit 100 ( 1 ) is dependent. In the simplest case, it is a simple copy to another memory area, but the data can also be sent via communication channels as a message and / or other known mechanisms of data transmission. After completion of the data transfer, the states of sender and receiver are reset to "not ready" as initialization for the next interval.

At the end of the transmitter task 122 "S" is executed in one embodiment program code similar to the following:

It can be seen that for all other tasks ("r") to which data is being sent, a counter (counter_s) will first check to see if data should be sent in that time step, which only affects the lower-sample receiver tasks , otherwise the counter can be omitted 2 the constant counter s_max has the value 2, because only every second execution of the sender task 122 "S" data to the receiver 112 to be sent.

With appropriate meter reading 23 the counter is reset and by setting "sender_ready" 21 announced that the sender "s" is willing to send data to the receiver "r". If the recipient of the communication relationship has already been marked as "ready" (ie if the task 140 "Notify" has already been executed in this interval), the transmission of the data G to the receiver is started by calling the "copydata" function.

It can be seen in the embodiments described above that the transmission of the data G to be communicated either in the task 140 "Notify" or in the sender task 122 itself is executed, depending on which task is executed last, relative to the receiver task 112 , However, according to one embodiment, the described counter mechanism ensures that the transmission is performed exactly once per interval of the slower task.

Previously, it was assumed that the task "notify" and the sender task have the same priority from the operating system's point of view, are executed in the order of their activation and do not interrupt each other, and if this assumption is incorrect, additional protection mechanisms can be added to the program Code to ensure consistent values for the states "sender_ready" and "receiver_ready." Mechanisms of the operating system of the computing unit of the control unit known to those skilled in the art 100 can advantageously be ensured that only one of the two software units concerned (ie sender task 112 "S" and notification task 140 "Notify") may enter the area protected by a "protection". At the end of the transmitter task 122 In this case, "s" is inserted according to one embodiment, program code similar to the following:

The program code of the notification task 140 In this case, "notify" can look like one of the following:

According to one embodiment, the protection mechanism acts locally on only one execution unit ("core-local") and is thereby implemented in a resource-saving manner (for example, by temporarily preventing task switching). In order to keep the time during which access protection is active short, according to one embodiment, the execution of the copy action is controlled by a logical variable "copy_s" or "copy_n", so that the copying action can take place outside the protected area. If it can not be ensured that the communication is always completed at the latest when the intervals between sender and receiver end, measures for error detection and error handling can be provided according to one embodiment. The start of the program execution of sender and receiver task can then be e.g. be delayed in the subsequent interval until the communication from the previous interval is completed. The technical solution for the treatment of such errors is not part of this invention.

• • Sender 122 und Empfänger 112 der Kommunikationsbeziehung 130 können auf dem gleichen Rechenkern, auf unterschiedlichen Rechenkernen oder auf einer anderen Recheneinheit in einem vernetzten System („System-on-Chip") ausgeführt werden.
• • Die zu kommunizierenden Daten können aus dem Speicherbereich des Senders 122 in den Speicherbereich des Empfängers 112 kopiert werden oder als Nachricht an den Empfänger gesendet werden.
• • Die Benachrichtigung B vom Empfänger 112 zum Sender 122 kann dann erfolgen, wenn innerhalb einer Ausführung der Empfänger-Task nicht mehr auf die Eingangsdaten zugegriffen wird, also zu einem Zeitpunkt bereits vor Beendigung der Empfänger-Task.
• • Das Senden der Daten kann bereits dann erfolgen, wenn die Sender-Task 122 alle zu sendenden Daten im Speicher 124 abgelegt hat, also bereits vor dem Ende der Sende-Task, vorausgesetzt dass die Benachrichtigung B der Empfänger-Task bereits eingetroffen ist.
• • Falls der Empfänger 122 Zugriff auf den Arbeitsspeicher des Senders 112 hat, kann die Kommunikation alternativ vom Empfänger 122 gesteuert und durchgeführt werden. In diesem Fall kann der Sender 122 den Empfänger 112 benachrichtigen, wenn die Daten bereitstehen. Der Programm-Code sieht ähnlich aus wie oben beschrieben, es müssen nur jeweils Sender und Empfänger vertauscht werden. Die Benachrichtigungs-Task 140 kann in diesem Fall auf der Ausführungseinheit 110 des Empfängers 112 ausgeführt werden.
• • Falls einer der Kommunikationspartner 112, 122 Zugriff auf den Speicher 114, 124 des anderen Partners hat, kann dieser direkt nacheinander eine Kommunikation in beide Richtungen durchführen. Das bedeutet, die Funktion „copydata" aus den vorstehend beschriebenen Programmbeispielen kann nicht nur die Daten von einem Sender zu einem Empfänger senden, sondern auch die Ausgabedaten des Empfängers auslesen und in den Speicherbereich des Senders kopieren. Dadurch wird die Anzahl der Benachrichtigungs-Tasks halbiert, soweit eine Kommunikation in beide Richtungen erforderlich ist.

Further advantageous embodiments are characterized by the following aspects, which can also be combined with one another and / or with the abovementioned embodiments:

• • Sender 122 and receiver 112 the communication relationship 130 can be executed on the same processor, on different cores or on another processor in a networked system ("system-on-chip").
• • The data to be communicated may be from the memory area of the transmitter 122 in the memory area of the receiver 112 be copied or sent as a message to the recipient.
• • The notification B from the recipient 112 to the transmitter 122 This can be done if the input data is no longer accessed within an execution of the receiver task, that is, at a time already before the receiver task is ended.
• • Sending the data can already be done when the sender task 122 all data to be sent in memory 124 has already filed before the end of the send task, provided that the notification B of the receiver task has already arrived.
• • If the recipient 122 Access to the memory of the transmitter 112 Alternatively, the communication may be from the recipient 122 be controlled and performed. In this case, the transmitter 122 the recipient 112 notify when the data is ready. The program code looks similar to the one described above, only the transmitter and the receiver have to be swapped. The notification task 140 can in this case on the execution unit 110 Recipient 112 be executed.
• • If one of the communication partners 112 . 122 Access to the memory 114 . 124 of the other partner, he can directly communicate one after the other in both directions. This means that the "copydata" function from the program examples described above can not only send the data from a sender to a receiver, but also read out the receiver's output data and copy it to the memory area of the sender, thereby halving the number of notification tasks if communication in both directions is required.

The advantages of the principle according to the invention are summarized below.

• 1. Conventional methods such as out DE 102 29 520 A1 can be extended using the principle of the invention so that they can also be used for computing units with multiple cores (eg multi-core processors), while maintaining a deterministic and reproducible behavior and ensuring data consistency. The concept of "Logical Execution Time" is suitable for this.
• 2. The principle according to the invention supports software units (tasks) controlled by an operating system whose activation rates (eg 5 ms, 10 ms) are in a preferably fixed, integer ratio to one another ( 2 ). There may also be several tasks with the same activation rate. In addition, other tasks may be present in the system with other than the above activation rates, but with which then can be communicated in a different way than described in this invention.
• 3. The procedure loads the communication channels 130 (eg buses) less than the communication known from conventional systems, for example, which always takes place exactly at the interval limits R1, R2 ( 2 ).
• 4. The process comes with a smaller number of memories for those between the software units 112 . 122 communicated data G as the conventional methods.
• 5. The procedure is "wait-free", meaning that none of the communication partners' execution is temporarily blocked, for example, to ensure the consistency of shared storage areas, which can reduce the available processing power of the execution units 110 . 120 be better used.
• 6. The method can be implemented without extending the operating systems commonly used today in the automotive domain (e.g., AUTOSAR-OS).
• 7. The method can be used for computing units with memory areas that can be shared by different processor cores (such as multi-core processors with "shared memory" available for real-time use in the automotive domain) and for processors that can only be used by sending Messages via communication channels ("message passing") can communicate with each other ("network-on-chip").

QUOTES INCLUDE IN THE DESCRIPTION

This list of the documents listed by the applicant has been generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited patent literature

• DE 10229520 A1 [0003, 0054]

Claims (9)

Method for operating a control device ( 100 ), in particular for a motor vehicle, wherein the control device ( 100 ) at least one, preferably at least two, in particular for the execution of task programs ( 112 . 122 ) trained execution units ( 110 . 120 ), wherein at least at times a first task program ( 112 ) and a second task program ( 122 ), characterized in that the first task ( 112 ) a notification (B) to an execution unit ( 120 ), which is the second task ( 122 ), the notification (B) being the second task ( 122 ) and / or the second task ( 122 ) executing execution unit ( 120 ) signals that the first task ( 112 ) is ready to retrieve data from the second task ( 122 ) to recieve. Method according to one of the preceding claims, wherein the first task program ( 112 ) the notification (B) then sends, if a predefinable number of calculations of the first task ( 112 ), in particular all calculations of the first program ( 112 ), for a first task ( 112 ) associated with the current time slot (ZS1) have been executed. Method according to one of the preceding claims, wherein the first task program ( 112 ) the notification (B) at the end of a first task ( 112 ) associated with the current time slot (ZS1). Method according to one of the preceding claims, wherein data from one of the second task program ( 122 ) associated memory area ( 124 ) into a first task ( 112 ) associated memory area ( 114 ) when the first task ( 112 ) previously sent a notification (B) to the second task ( 122 ) executing execution unit ( 120 ) and if the second task ( 122 ) all calculations for a second task ( 122 ) has executed the assigned current time slot (ZS2). Method according to one of the preceding claims, wherein a third task program ( 140 ) is executed to retrieve data from a second task ( 122 ) associated memory area ( 124 ) into a first task ( 112 ) associated memory area ( 114 ) transferred to. Method according to one of the preceding claims, wherein the first task program ( 112 ) and the second task ( 122 ) have different cycle times (ZS1, ZS2), wherein a cycle time (ZS1) of the first task program (ZS1) 112 ) is greater than the cycle time (ZS2) of the second task ( 122 ), and where data from a second task ( 122 ) associated memory area ( 124 ) into a first task ( 112 ) associated memory area ( 114 ) within the cycle (ZS2 ') of the second program ( 122 ), which is timed in the range of one cycle end of the first task program ( 112 ) lies. Method according to one of the preceding claims, wherein the first and second task programs ( 112 . 122 ) on the same execution unit ( 112 ; 122 ) or on different execution units ( 112 . 122 ). Control unit ( 100 ), in particular for a motor vehicle, wherein the control device ( 100 ) at least one, preferably at least two, in particular for the execution of task programs ( 112 . 122 ) trained execution units ( 110 . 120 ), wherein at least at times a first task program ( 112 ) and a second task program ( 122 ) are executable, characterized in that the first task ( 112 ) is adapted to send a notification (B) to an execution unit ( 120 ), which is the second task ( 122 ), the notification (B) being the second task ( 122 ) and / or the second task ( 122 ) executing execution unit ( 120 ) signals that the first task ( 112 ) is ready to retrieve data from the second task ( 122 ) to recieve. Control unit ( 100 ) according to claim 8, wherein the control device ( 100 ) is designed for carrying out the method according to one of claims 1 to 7.

Images