WO2023030736A1 - Verfahren und vorrichtung zum bearbeiten von zumindest einer ersten und einer zweiten rechenoperation in einer recheneinheit - Google Patents

Verfahren und vorrichtung zum bearbeiten von zumindest einer ersten und einer zweiten rechenoperation in einer recheneinheit Download PDF

Info

Publication number
WO2023030736A1
WO2023030736A1 PCT/EP2022/069756 EP2022069756W WO2023030736A1 WO 2023030736 A1 WO2023030736 A1 WO 2023030736A1 EP 2022069756 W EP2022069756 W EP 2022069756W WO 2023030736 A1 WO2023030736 A1 WO 2023030736A1
Authority
WO
WIPO (PCT)
Prior art keywords
arithmetic operation
time interval
arithmetic
processing
time
Prior art date
Application number
PCT/EP2022/069756
Other languages
English (en)
French (fr)
Inventor
Andreas Achtzehn
Original Assignee
Robert Bosch Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch Gmbh filed Critical Robert Bosch Gmbh
Priority to EP22753614.1A priority Critical patent/EP4396678A1/de
Priority to CN202280072334.2A priority patent/CN118159946A/zh
Publication of WO2023030736A1 publication Critical patent/WO2023030736A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/48—Indexing scheme relating to G06F9/48
    • G06F2209/485—Resource constraint
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/504—Resource capping
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/506—Constraint

Definitions

  • the invention is based on a device or a method according to the species of the independent claims.
  • the subject matter of the present invention is also a computer program.
  • Systems with real-time requirements use special methods of resource allocation (scheduling, especially for the CPU) to ensure that tasks are completed within a deterministic, i.e. known and guaranteed, time period.
  • some scheduling methods set budgets within which the Tasks should be completed.
  • the purpose of budgeting in addition to ensuring that the budgeted task has enough resources (particularly time on a CPU), is to prevent the potential interference (negative impact) between tasks due to unexpected overuse of the resource. This is to ensure that a task doesn't use so many resources that another task can no longer be completed.
  • a method for processing at least a first and a second arithmetic operation in a computing unit is presented, a first time interval being provided for processing the first arithmetic operation in the arithmetic unit and a time interval different from the first for processing the second arithmetic operation in the computing unit Time interval different second time interval is provided, the method having the following steps:
  • An arithmetic operation can be understood as a task to be solved numerically.
  • an arithmetic unit can be understood as a processor or controller that can be programmed to process or execute corresponding arithmetic operations. In this way, different processing rules can be executed as arithmetic operations.
  • a time interval can be understood to mean a time slot that is provided for processing an arithmetic operation.
  • a time slot scheme can be used during operation of the arithmetic unit, in which several arithmetic operations can be carried out one after the other in the arithmetic unit with a chronological offset, the individual Arithmetic operations are initially performed in different time slots.
  • a completion time can be understood to mean a time at which the second arithmetic operation was completed in the second time interval.
  • the processing of the second arithmetic operation does not take up the entire duration of the second time interval, so that the arithmetic unit would no longer process an arithmetic operation in the second time interval from the time of completion to the end of the second time interval.
  • the approach presented here is based on the knowledge that, for the most efficient possible utilization of the computing power available in the computing unit, there should be as few time periods as possible in which the computing unit is not performing any computing operations.
  • it is proposed to have a different arithmetic operation than the second arithmetic operation (here the first arithmetic operation) carried out in a section of the second time interval from the completion time to the end of the second time interval and thereby to dissolve a very rigid time slot scheme, in which individual arithmetic operations may only be carried out in the time slots or time intervals reserved for them.
  • the approach presented here thus enables a significantly more continuous utilization of the computing unit, which leads to faster processing of the individual computing operations.
  • One embodiment of the approach proposed here is particularly favorable, in which a step of storing an interim result of the first arithmetic operation is provided after the first time interval has elapsed, if the first arithmetic operation could not be completed in the first time interval, with the step of executing from the time of completion first arithmetic operation is processed further starting from the intermediate result.
  • an intermediate result can also be understood to mean, for example, a state of the memory in which a processing specification for the first arithmetic operation is stored.
  • Such an embodiment of the approach proposed here offers the advantage of efficient processing of the first arithmetic operation in several time segments, since the storage of the intermediate result (and a subsequent loading of this intermediate result at the time of completion in the second time interval) an interruption of the processing of the first arithmetic operation that is as error-free as possible can be implemented.
  • the first arithmetic operation therefore did not have to be restarted, but can instead fall back on calculation results that were determined in the arithmetic unit in the first time interval.
  • an auxiliary time interval can also be provided in the computing unit, in which at least part of the first and/or second arithmetic operation can be processed, with the processing of the second arithmetic operation and/or the first arithmetic operation after processing continues without interruption in the auxiliary time interval after the second time interval has elapsed, in particular if processing of the second arithmetic operation and/or the first arithmetic operation has not yet been completed after the second time interval has elapsed.
  • An auxiliary time interval can be understood to mean a time interval in which no arithmetic operation is provided for processing.
  • Such an auxiliary time interval can be used to carry out calculations of corresponding arithmetic operations which have not yet been completed.
  • Such an embodiment of the approach proposed here offers the advantage of the uninterrupted further processing of the second arithmetic operation in the auxiliary time interval, which advantageously follows the second time interval, a complex and time-consuming loading of the arithmetic unit with a processing rule and / or between results of a previously executed arithmetic operation to avoid.
  • Another favorable embodiment of the approach proposed here is one in which at least one further arithmetic operation is also processed in the arithmetic unit, with an assignment step being provided in which the first, second and/or further arithmetic operation is assigned processing information that Represents information about a completed processing of the relevant arithmetic operation at a previous time.
  • the execution step the arithmetic operation to be executed as the first arithmetic operation is selected taking into account the processing information for processing in the second time interval becomes.
  • Processing information can be understood as information or a status that provides an indication of the degree of processing of the arithmetic operation, a priority of the arithmetic operation in relation to at least one other arithmetic operation, a frequency with which the corresponding arithmetic operation is processed on the arithmetic unit or the like.
  • Such an embodiment of the approach proposed here offers the advantage of being able to make a very efficient selection of an arithmetic operation, for example as the first arithmetic operation, by taking the processing information into account, so that, for example, arithmetic operations that are more important, less processed or to be performed more frequently can be processed with higher priority in the arithmetic unit.
  • the processing information can be determined in the assignment step, taking into account complete processing of the relevant arithmetic operation at least at a previous point in time.
  • that arithmetic operation that was completely processed at a previous point in time can be assigned processing information that represents a lower prioritization for a renewed processing of the arithmetic operation in question at a subsequent point in time.
  • Such an embodiment of the approach proposed here offers the advantage of primarily working arithmetic operations in free portions of time intervals, which experience has shown to require a longer processing time. In this way, efficient and rapid processing of all of the arithmetic operations to be carried out can advantageously be achieved.
  • the processing information for the first, second and/or further arithmetic operation can be determined using a frequency of previous processing of the relevant arithmetic operation.
  • Such an embodiment offers the advantage of allowing arithmetic operations to be carried out particularly frequently to work in advance in order, for example, to quickly and reliably provide processing values of sensor data that are required at short notice and frequently to be able to ask. In this way, even safety-critical arithmetic operations or algorithms can be processed reliably by the arithmetic unit.
  • the further arithmetic operation can also be carried out in the step of execution in the second time interval and/or the auxiliary time interval if the first arithmetic operation is carried out in the second time interval and/or the auxiliary time interval. or the auxiliary time interval has been completed.
  • Such an embodiment offers the advantage of being able to perform more than one arithmetic operation in the remaining portion of the second time interval and/or the auxiliary interval, so that as many arithmetic operations as possible that have not yet been completed can be processed while avoiding a rigid time slot scheme.
  • the arithmetic operation to be carried out as the first arithmetic operation can be carried out using a result of a random number generator if the as a possible first arithmetic operation machining information associated with the arithmetic operations to be selected are equal within a tolerance range.
  • a particularly flexible configuration for the processing of arithmetic operations in a computing unit can be achieved in that, in the assignment step, the processing information assigned to the arithmetic operations is processed using an expected execution time until the processing of the arithmetic operation in question is completed in of the computing unit is determined.
  • that arithmetic operation can be selected as the first arithmetic operation whose processing information has a longest execution time period until the processing of the relevant Arithmetic operation in the arithmetic unit corresponds. In this way, for example, too frequent and time-consuming reloading of the memory or processor of the arithmetic unit with algorithms or between results of the respective arithmetic operations can be avoided.
  • the steps of the method can also be repeated cyclically, it being possible for different calculation rules to be used as the first calculation operation or different calculation rules as the second calculation operation in the repeatedly executed steps.
  • Such an embodiment offers the advantage of being able to execute different algorithms or processing rules for a wide variety of purposes as a first and/or second arithmetic operation on the computing unit, so that the available numerical performance of the computing unit can be used as optimally as possible.
  • the steps of the method can also be carried out repeatedly according to a further embodiment of the approach presented here, with a step of the method being carried out before the repeatedly carried out steps of the method Changing a time length of the first and / or second time interval is performed.
  • An embodiment of the approach proposed here is also advantageous in which, in the step of changing, the time length of the first and/or second time interval is changed at a later point in time depending on the completion of the first arithmetic operation in the first time interval and/or the completion of the second arithmetic operation is changed at a previous time.
  • Such an embodiment offers the advantage of being able to use time interval lengths that are optimal in terms of time for the corresponding arithmetic operations and thus being able to complete the corresponding arithmetic operations as far as possible within the respectively assigned time interval.
  • This method can be implemented, for example, in software or hardware or in a mixed form of software and hardware, for example in a control unit.
  • the approach presented here also creates a device that is designed to carry out, control or implement the steps of a variant of a method presented here in corresponding devices.
  • the object on which the invention is based can also be achieved quickly and efficiently by this embodiment variant of the invention in the form of a device.
  • the device can have at least one computing unit for processing signals or data, at least one memory unit for storing signals or data, at least one interface to a sensor or an actuator for reading in sensor signals from the sensor or for outputting data or control signals to the Have actuator and / or at least one communication interface for reading or outputting data that are embedded in a communication protocol.
  • the arithmetic unit can be, for example, a signal processor, a microcontroller or the like, with the memory unit being able to be a flash memory, an EEPROM or a magnetic memory unit.
  • the communication interface can be designed to read in or output data wirelessly and/or by wire, wherein a communication interface that can read in or output wire-bound data can, for example, read this data electrically or optically from a corresponding data transmission line or can output it to a corresponding data transmission line.
  • a device can be understood to mean an electrical device that processes sensor signals and, depending thereon, outputs control and/or data signals.
  • the device can have an interface that can be configured as hardware and/or software.
  • the interfaces can be part of a so-called system ASIC, for example, which contains a wide variety of functions of the device.
  • the interfaces it is also possible for the interfaces to have their own integrated circuits or at least in part to consist of discrete components consist.
  • the interfaces can be software modules which are present, for example, on a microcontroller alongside other software modules.
  • a computer program product or computer program with program code which can be stored on a machine-readable carrier or storage medium such as a semiconductor memory, a hard disk memory or an optical memory and for carrying out, implementing and/or controlling the steps of the method according to one of the embodiments described above, is also advantageous used, especially when the program product or program is run on a computer or device.
  • FIG. 1 shows a schematic representation of a vehicle in which a device 105 according to an exemplary embodiment of the approach presented here is installed;
  • FIG. 2 shows a schematic representation of the time course t when processing arithmetic operations according to an exemplary embodiment of the approach presented here;
  • FIG. 3 shows a block diagram representation of a device for processing according to an embodiment
  • FIG. 4 shows a flowchart of a method according to an embodiment.
  • FIG. 1 shows a schematic representation of a vehicle 100 in which a device 105 according to an exemplary embodiment of the approach presented here is installed. Furthermore, one or more sensors 110a and 110b are also installed in vehicle 100, for example, which transmit their sensor data 115a and 115b to a computing unit 120, in which these sensor data 115 a and 115 b are processed and, for example, a control signal 125 is formed, which Vehicle module 130 drives.
  • the vehicle module 130 can, for example, be a driver assistance system or a safety system of the vehicle 100, for example an airbag system or an ABS system.
  • the sensor data 115a or 115b are linked or processed in a wide variety of ways in the arithmetic unit 120, which is often designed as a microprocessor or control, with a corresponding arithmetic operation such as a first arithmetic operation 135a, a second arithmetic operation 135b and/or a third arithmetic operation 135c is to be executed as a corresponding task in the arithmetic unit 120.
  • Efficient processing of the corresponding arithmetic operations 135a, 135b and 135c is required in the arithmetic unit 120 precisely for rapid processing of algorithms which are often time- and safety-critical for the driving safety of the vehicle 100.
  • the temporal execution or processing of the corresponding arithmetic operations 135a, 135b and/or 135c in arithmetic logic unit 120 is controlled by an exemplary embodiment of device 105 for processing at least a first arithmetic operation 130a and a second arithmetic operation 135b in the arithmetic logic unit 120 made.
  • the device 105 for processing at least a first 135a and a second 135b arithmetic operation in a computing unit 120 has a unit 140 for recognizing and a unit 145 for executing the first arithmetic operation 135a in the second time interval after a completion time.
  • the device 105 is designed for processing in order to process the first arithmetic operation in the arithmetic unit in a first time interval and the second arithmetic operation in the arithmetic unit to process in a second time interval different from the first time interval.
  • unit 140 for detection it is detected that the second arithmetic operation was completed in the second time interval at the time of completion before an end of the second time interval.
  • the memories and/or the processor are loaded with the data or corresponding processing specifications in order to execute the relevant arithmetic operation 135a, 135b or 135c in the arithmetic unit 120.
  • FIG. 2 shows a schematic representation of the course of time t when processing arithmetic operations according to an exemplary embodiment of the approach presented here.
  • a cycle time To contains several sub-cycles So, Si, . . . , SN ⁇ I.
  • Si a first time interval tfi X ,i is provided for processing the first arithmetic operation 135a
  • a second time interval tfi X ,2 is provided for processing the second arithmetic operation 135b.
  • an auxiliary time interval 200 is also provided, which lasts the duration after the end of the second time interval tfi X ,2 until the end of the first sub-cycle So.
  • any arithmetic operations can be executed in the arithmetic unit 120 in the auxiliary time interval 200, so that in this auxiliary time interval, for example, both the first arithmetic operation 130a and the second arithmetic operation 135b or the further arithmetic operation 135c can be executed.
  • the device 105 for processing is designed to load the memory or processor of the arithmetic unit 120 with data in such a way that the first arithmetic operation 135a can be carried out in the first time interval.
  • the processing of the first arithmetic operation 135a has not yet been completed at the end of the first time interval and must therefore be interrupted.
  • an intermediate result 210 is stored, for example, in a memory (not shown in the figures) of the arithmetic unit or device 105, with this intermediate result being a preliminary calculation result of the first arithmetic operation and/or a Memory/register occupancy of the memory or registers of the processor of the arithmetic unit 120 formed or represented, so that the first arithmetic operation 135a can be resumed as error-free as possible at a later point in time.
  • the second arithmetic operation 135b is now first carried out.
  • the calculation of the second arithmetic operation 135b is completed at a completion time 220, which is before the end of the second time interval, so that the processing unit 120 in that time segment of the second time interval between the completion time 220 and the end of the second time interval is no longer needed to carry out the second arithmetic operation 135b and is available for other tasks.
  • the memory or processor of the arithmetic unit 120 can now be reloaded with the data of the intermediate result 210 and the first arithmetic operation 135a can be continued.
  • the most efficient use possible of the numerical power available in the arithmetic unit 120 can be used for rapid processing of the arithmetic operations 135 .
  • that arithmetic operation here the first arithmetic operation 135a
  • that arithmetic operation can also be processed in the subsequent auxiliary time interval 200, so that a time-consuming change of the data or processing instructions stored in the arithmetic unit 120 is avoided as far as possible and thus a further acceleration of the processing of the arithmetic operations 135 can be reached.
  • the arithmetic unit 120 can be unused in the remaining time span of the auxiliary time interval 200 .
  • the further arithmetic operation 135c can of course also be carried out in this remaining time period of the auxiliary time interval 200, although this is not shown explicitly in FIG.
  • An analogous procedure for controlling the execution or processing of arithmetic operations in the arithmetic unit 120 can also be illustrated with reference to the subcycle Si.
  • the first arithmetic operation 135a is now processed in the first time interval and at the completion time 220 ended before the first time interval ended.
  • the second arithmetic operation 135b can now be started directly in the first time interval, which is then also processed without interruption in the second time interval following the first time interval and even directly in the auxiliary time interval 200. In this way, very efficient control of the processing of the arithmetic operations in the arithmetic unit 120 can be made possible.
  • the arithmetic unit 120 can again remain unused in this or the further arithmetic operation 135c can be processed.
  • FIG. 3 shows a block diagram representation of a device 105 for processing according to an embodiment.
  • the device 105 for processing comprises unit 140 for recognition and unit 145 for execution.
  • unit 140 for recognition it is recognized, for example, that an arithmetic operation such as the first arithmetic operation 135a, the second arithmetic operation 135b and/or the further arithmetic operation 135c has been completed or reserved for execution in a subsequent time slot, with this result now being assigned to unit 145 is sent to run.
  • Execution unit 145 now acts as a unit for planning a free time budget of arithmetic unit 120, i.e.
  • arithmetic operation for planning which arithmetic operation is to be executed from a completion time 220 to the end of the respective time interval and/or in the auxiliary time interval 200. For this purpose, it is first recorded in a calculation operation completion statistics counter unit 300 which calculation operation was completed and how often. A result of this unit 300, which represents processing information 305, is subsequently transferred to a logic unit 310, which selects the next arithmetic operation. Optionally, the result or the processing information 305 of this unit 300 is fed to a further logic unit 320, which can determine how long or what time interval a subsequent execution of a corresponding arithmetic operation is assigned.
  • a processed piece of processing information 305' from the logic unit 310 and also from the further logic unit 320 is then assigned to an arithmetic operation Supplied to planning actuator 330, which occupies corresponding registers or memory in arithmetic unit 120 in order to be able to carry out a correspondingly selected arithmetic operation to be carried out in arithmetic unit 120.
  • the arithmetic operation planning actuator 330 informs a check logic 340 for checking that processing of an arithmetic operation has been completed, whether or which arithmetic operation was loaded in the arithmetic logic unit 120 .
  • the processing of the arithmetic operation in the arithmetic unit 120 is monitored by the test logic 340 .
  • the unit 300 which logs the execution of the corresponding arithmetic operation in the arithmetic unit 120 and provides corresponding information for a new cycle of processing a Arithmetic operation on the arithmetic unit 120 to the logic unit 310 or the further logic unit 320 supplies.
  • FIG. 4 shows a flow chart of an exemplary embodiment of a method 400 for processing at least a first and a second computing operation in a computing unit.
  • a first time interval is provided for processing the first arithmetic operation in the processing unit and a second time interval different from the first time interval is provided for processing the second arithmetic operation in the processing unit.
  • the method 400 includes a step 410 of recognizing that the second arithmetic operation in the second time interval was completed at a completion time before an end of the second time interval.
  • the method 400 includes a step 420 of executing the first arithmetic operation in the second time interval after the completion time.
  • the method 400 includes a step 410 of recognizing that the first arithmetic operation in the first time interval was completed at a completion time before an end of the first time interval. Finally, the method 400 includes a step 420 of performing the second arithmetic operation in the first time interval after the completion time.
  • the approach presented here can be summarized, supplemented or continued in other words.
  • the one presented here The approach can be understood as a cycle-optimized soft real-time scheduler for the assignment of a computing unit with various computing operations.
  • systems with real-time requirements are characterized by the fact that a large number of tasks are of a cyclical nature, e.g. B. the recurring calculation of object data based on sensor data that is regularly fed in externally.
  • a task can be completed in each cycle, but that the task can be completed completely a certain number of times in a larger time interval.
  • the task starts anew, for example, e.g. B. because new sensor data is available.
  • budget planning represents a particular challenge Practice the budgets are chosen too large. As a result, all tasks are processed to the end with a high degree of certainty in each cycle. In order to still ensure efficient use of resources, unused portions of the budget are made available to other tasks to ensure "workload preservation". However, since the initial system design already provided for a high probability of completion of the tasks, this surplus remains unused. The pure redistribution of excess budget is only partially successful in order to enable a system design that is more appropriate for the tasks (e.g. by choosing a weaker CPU).
  • Soft real-time requirements are defined in this context as the conclusion (completion) of a recurring resource-using task (task or arithmetic operation), which, for example, should be completely completed a certain number of times in a certain time interval.
  • a task has an unknown dynamic runtime td yn until completion (time), which depends on external factors (e.g. number of available sensor data).
  • the focus of the approach presented here is (success criterion of the soft-realtime scheduler as device 105) that the task or arithmetic operation is successfully completed within a time interval To, for example, at least N m times.
  • the duration of the inner intervals or sub-cycles Sj is z. B. determined by the availability of new data packets, such as sensor data packets.
  • a basic idea of the approach presented here is the determination of a fixed runtime budget tfi X per execution of the task per time interval Si, which is smaller than the dynamic runtime td yn with a non-negligible statistical probability.
  • the runtime budget is the guaranteed budget that the task will receive in any case.
  • a correspondingly large dimensioning of tfi X to cover all realizations of td yn is inefficient.
  • One focus of the approach presented here is the selection of the tasks or arithmetic operations that are executed again within the remaining time budget potentially covering their dynamic runtime requirements td yn .
  • a counting statistic and algorithm is proposed, for example, which prioritizes the task in which the probability within the interval To of not running to the end at least N m times is the highest.
  • the decision algorithm proposed here can be adapted on a use-case basis.
  • the approach presented here can initially be intended for the scheduling of a computer unit or CPU, but can also be used for other shared resources.
  • the proposed scheduler decides on the distribution unused remaining running time within a time interval Si. For example, it only takes into account the tasks or arithmetic operations that have not yet been completed, ie that have completely used up their budget without completing the task.
  • the scheduler can recognize this, for example, from the fact that the tasks were each preempted, ie that the task was forcibly replaced by another task on the CPU or processing unit 120 as part of the exhaustion of the runtime budget.
  • FIG. 3 which here represents a special form of the device 105 for processing.
  • More complex statistics e.g. B. a gradual increment / decrement or the use of a sliding window are possible.
  • the counter is either reset or decremented. The latter would have advantages in cyclic load scenarios.
  • a selection based on the counting statistics can now be made in different ways, for example.
  • the following procedure can therefore be selected for the assignment of the registers and memories of the arithmetic unit 120, with the numerical steps indicating the sequence, for example, and letters indicating the alternatives.
  • values in parentheses refer to a reference to the previous one: la.
  • the task that has the highest counter value is always selected. pounds A task is selected with a probability weighted according to the statistics, ie tasks with higher counter values are selected with a higher probability.
  • the task that is to run or be executed on the arithmetic unit 120 is selected by a random number generator.
  • a further logic unit 320 it can be determined, for example, how long or what time interval a subsequent execution of a corresponding arithmetic operation is assigned [task run duration budget logic].
  • the duration of the execution can be decided as follows:
  • the selected task is allowed to run until it is completed, and its counter value is decremented.
  • the selected task is only run for a fixed extended period.
  • the length of the period is chosen according to the weighting in the execution statistics, for example. For example, it is possible to let a task run longer if it has not completed the task in the past despite the free budget scheduler.
  • a check logic 340 for checking a completed processing of an arithmetic operation [task completion check logic], for example after the end of the extended execution, the task statistics can be recognized, updated in the arithmetic operation completion statistics counter unit 300 and the next task can be selected. This is repeated until either all tasks for that time interval have completed successfully or the time interval has elapsed.
  • a procedure presented here has potential, for example, to be used in a vehicle computer with tasks in the ADAS environment. Dynamic loads often occur in such a system, e.g. B. due to the different complexity of the vehicle environment.
  • processes allow a soft-realtime realization, in which tasks, up to an acceptance limit, may show deadline violations.
  • the mixture of hard and soft real-time systems is a new technical task field that only arose with the appearance of tasks with dynamic input variables (e.g. the number of objects to be recognized in an environmental sensor system). Although it is possible to operate systems with mixed tasks, there with corresponding (inefficient) provision of computing power to allow renormalization to a hard real-time system.
  • an embodiment includes an "and/or" link between a first feature and a second feature, this should be read in such a way that the embodiment according to one embodiment includes both the first feature and the second feature and according to a further embodiment either only that having the first feature or only the second feature.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Complex Calculations (AREA)

Abstract

Die Erfindung betrifft ein Verfahren (400) zum Bearbeiten von zumindest einer ersten (135a) und einer zweiten (135b) Rechenoperation in einer Recheneinheit (120), wobei zum Bearbeiten der ersten Rechenoperation (135a) in der Recheneinheit (120) ein erstes Zeitintervall (tfix,1) vorgesehen ist und zum Bearbeiten der zweiten Rechenoperation (135b) in der Recheneinheit (120) ein von dem ersten Zeitintervall (tfix,1) unterschiedliches zweites Zeitintervall (tfix,2) vorgesehen ist. Das Verfahren (400) umfasst einen Schritt des Erkennens (410), dass die zweite Rechenoperation (135b) im zweiten Zeitintervall (tfix,2) zu einem Abschlusszeitpunkt (220) vor einem Ende des zweiten Zeitintervalls (tfix,2) abgeschlossen wurde. Ferner umfasst das Verfahren (400) einen Schritt des Ausführens (420) der ersten Rechenoperation (135a) in dem zweiten Zeitintervall (tfix,2) nach dem Abschlusszeitpunkt (220). Zusätzlich oder alternativ umfasst das Verfahren (400) einen Schritt (410) des Erkennens, dass die erste Rechenoperation (135a) im ersten Zeitintervall (tfix,1) zu einem Abschlusszeitpunkt (220) vor einem Ende des ersten Zeitintervalls (tfix,1) abgeschlossen wurde und einen Schritt (420) des Ausführens der zweiten Rechenoperation (135b) in dem ersten Zeitintervall (tfix,1) nach dem Abschlusszeitpunkt (220).

Description

Beschreibung
Titel
Verfahren und Vorrichtung zum Bearbeiten von zumindest einer ersten und einer zweiten Rechenoperation in einer Recheneinheit
Stand der Technik
Die Erfindung geht von einer Vorrichtung oder einem Verfahren nach Gattung der unabhängigen Ansprüche aus. Gegenstand der vorliegenden Erfindung ist auch ein Computerprogramm.
Systeme mit Echtzeitanforderungen nutzen besondere Verfahren der Ressourcenzuweisung (Scheduling, insbesondere für die CPU, um sicherzustellen, dass Aufgaben innerhalb eines deterministischen, d. h. bekannten und garantierten, Zeitraums abgeschlossen werden. Um Ressourcen Verfügbarkeit zu garantieren, werden in einigen Schedulingverfahren Budgets festgelegt, innerhalb derer die Aufgaben abgeschlossen werden sollten. Die Budgetfestlegung dient neben der Sicherstellung, dass die budgetierte Aufgabe genug Ressourcen (insbesondere Zeit auf einer CPU) zur Verfügung hat, auch dazu, die potenzielle Interferenz (negative Beeinflussung) zwischen Aufgaben durch unerwartete exzessivere Nutzung der Ressource zu verhindern. So soll sichergestellt werden, dass eine Aufgabe nicht so viele Ressourcen nutzt, dass eine andere Aufgabe nicht mehr abgeschlossen werden kann.
Offenbarung der Erfindung
Vor diesem Hintergrund werden mit dem hier vorgestellten Ansatz ein Verfahren, weiterhin eine Vorrichtung, die dieses Verfahren verwendet, sowie schließlich ein entsprechendes Computerprogramm gemäß den Hauptansprüchen vorgestellt. Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen der im unabhängigen Anspruch angegebenen Vorrichtung möglich.
Mit dem hier vorgestellten Ansatz wird ein Verfahren zum Bearbeiten von zumindest einer ersten und einer zweiten Rechenoperation in einer Recheneinheit vorgestellt, wobei zum Bearbeiten der ersten Rechenoperation in der Recheneinheit ein erstes Zeitintervall vorgesehen ist und zum Bearbeiten der zweiten Rechenoperation in der Recheneinheit ein von dem ersten Zeitintervall unterschiedliches zweites Zeitintervall vorgesehen ist, wobei das Verfahren die folgenden Schritte aufweist:
Erkennen, dass die zweite Rechenoperation im zweiten Zeitintervall zu einem Abschlusszeitpunkt vor einem Ende des zweiten Zeitintervalls abgeschlossen wurde; und
Ausführen der ersten Rechenoperation in dem zweiten Zeitintervall nach dem Abschlusszeitpunkt; und/oder
Erkennen, dass die erste Rechenoperation im ersten Zeitintervall zu einem Abschlusszeitpunkt vor einem Ende des ersten Zeitintervalls abgeschlossen wurde; und
Ausführen der zweiten Rechenoperation in dem ersten Zeitintervall nach dem Abschlusszeitpunkt.
Unter einer Rechenoperation kann eine numerisch zu lösende Aufgabe oder ein Task verstanden werden. Eine Recheneinheit kann in der hier vorliegenden Beschreibung als ein Prozessor oder Controller verstanden werden, der zur Bearbeitung oder Ausführung von entsprechenden Rechenoperationen programmiert werden kann. Auf diese Weise können unterschiedliche Verarbeitungsvorschriften als Rechenoperationen ausgeführt werden. Unter einem Zeitintervall kann ein Zeitschlitz verstanden werden, der für die Bearbeitung einer Rechenoperation vorgesehen ist. Insofern kann beim Betrieb der Recheneinheit ein Zeitschlitz-Schema verwendet werden, bei der abwechselnd mehrere Rechenoperationen in der Recheneinheit zeitlich versetzt nacheinander ausgeführt werden können, wobei die einzelnen Rechenoperationen initial in unterschiedlichen Zeitschlitz ausgeführt werden. Unter einem Abschlusszeitpunkt kann ein Zeitpunkt verstanden werden, zudem die zweite Rechenoperation im zweiten Zeitintervall abgeschlossen wurde. Insofern nimmt die Bearbeitung der zweiten Rechenoperation nicht die gesamte Zeitdauer des zweiten Zeitintervalls in Anspruch, sodass die Recheneinheit im zweiten Zeitintervall vom Abschlusszeitpunkt bis zum Ende des zweiten Zeitintervalls keine Bearbeitung einer Rechenoperation mehr ausführen würde.
Der hier vorgestellte Ansatz basiert auf der Erkenntnis, dass für eine möglichst effiziente Ausnutzung der in der Recheneinheit zur Verfügung stehenden Rechenleistung möglichst keine Zeitspannen auftreten sollten, in der die Recheneinheit keine Rechenoperation ausführt. Insofern wird gemäß dem hier vorgestellten Ansatz vorgeschlagen, eine andere Rechenoperation als die zweite Rechenoperation (hier die erste Rechenoperation) in einem Abschnitt des zweiten Zeitintervalls ab dem Abschlusszeitpunkt bis zum Ende des zweiten Zeitintervalls ausführen zu lassen und hierdurch ein sehr starres Zeitschlitz- Schema aufzulösen, bei dem einzelne Rechenoperationen nur in den für sie reservierten Zeitschlitz oder Zeitintervallen ausgeführt werden dürfen. Der hier vorgestellte Ansatz ermöglicht damit eine deutlich kontinuierlichere Auslastung der Recheneinheit, was zu einer schnelleren Abarbeitung der einzelnen Rechenoperationen führt.
Besonders günstig ist eine Ausführungsform des hier vorgeschlagenen Ansatzes, bei der ein Schritt des Abspeicherns eines Zwischenergebnisses der ersten Rechenoperation nach Ablauf des ersten Zeitintervalls vorgesehen ist, wenn die erste Rechenoperation im ersten Zeitintervall nicht abgeschlossen werden konnte, wobei im Schritt des Ausführens ab dem Abschlusszeitpunkt die erste Rechenoperation ausgehend vom Zwischenergebnis weiterbearbeitet wird. Unter einem Zwischenergebnis kann dabei neben einem Berechnung Ergebnis der ersten Rechenoperation beispielsweise auch ein Zustand des Speichers verstanden werden, indem eine Verarbeitungsvorschrift für die erste Rechenoperation abgelegt ist. Eine solche Ausführungsform des hier vorgeschlagenen Ansatzes bietet den Vorteil einer effizienten Bearbeitung der ersten Rechenoperation in mehreren zeitlichen Abschnitten, da durch die Abspeicherung des Zwischenergebnisses (und einem nachfolgenden Laden dieses Zwischenergebnisses zum Abschlusszeitpunkt im zweiten Zeitintervall) eine möglichst fehlerfreie Unterbrechung der Abarbeitung der ersten Rechenoperation realisiert werden kann. Die erste Rechenoperation musste daher nicht erneut gestartet werden, sondern kann auf Berechnungsergebnisse zurückgreifen, die im ersten Zeitintervall in der Recheneinheit ermittelt wurden.
Gemäß einer weiteren Ausführungsform des hier vorgeschlagenen Ansatzes kann ferner ein Hilfszeitintervall in der Recheneinheit vorgesehen sein, in welchem zumindest ein Teil der ersten und/oder zweiten Rechenoperation bearbeitbar ist, wobei im Schritt des Ausführens die Bearbeitung der zweiten Rechenoperation und/oder die erste Rechenoperation nach einem Ablauf des zweiten Zeitintervalls im Hilfszeitintervall unterbrechungsfrei weiterbearbeitet wird, insbesondere wenn eine Bearbeitung der zweiten Rechenoperation und/oder der ersten Rechenoperation nach Ablauf des zweiten Zeitintervalls noch nicht abgeschlossen worden ist. Unter einem Hilfszeitintervall kann ein Zeitintervall verstanden werden, in welchem keine Rechenoperation zur Bearbeitung vorgesehen ist. Vielmehr kann ein solches Hilfszeitintervall dazu verwendet werden, Berechnungen von entsprechenden Rechenoperationen auszuführen, welche noch nicht abgeschlossen sind. Eine solche Ausführungsform des hier vorgeschlagenen Ansatzes bietet den Vorteil, durch die unterbrechungsfreie Weiterbearbeitung der zweiten Rechenoperation im Hilfszeitintervall, welches sich günstiger Weise an das zweite Zeitintervall anschließt, ein aufwendiges und zeitintensives Laden der Recheneinheit mit einer Verarbeitungsvorschrift und/oder zwischen Ergebnissen einer zuvor ausgeführten Rechenoperation zu vermeiden.
Günstig ist weiterhin eine Ausführungsform des hier vorgeschlagenen Ansatzes, bei der ferner zumindest eine weitere Rechenoperation in der Recheneinheit bearbeitet wird, wobei ein Schritt des Zuordnens vorgesehen ist, in dem der ersten, zweiten und/oder weiteren Rechenoperation je eine Bearbeitungsinformation zugeordnet wird, die eine Information über eine erfolgte Bearbeitung der betreffenden Rechenoperation zu einem vorangegangenen Zeitpunkt repräsentiert. Dabei wird im Schritt des Ausführens die als erste Rechenoperation auszuführende Rechenoperation unter Berücksichtigung der Bearbeitungsinformation zum Bearbeiten in dem zweiten Zeitintervall ausgewählt wird. Unter einer Bearbeitungsinformation kann eine Information oder ein Zustand verstanden werden, der einen Hinweis über einen Grad der Abarbeitung der Rechenoperation, eine Priorität der Rechenoperation in Bezug auf zumindest eine andere Rechenoperation, eine Häufigkeit der Bearbeitung der entsprechenden Rechenoperation auf der Recheneinheit oder dergleichen abbildet. Eine solche Ausführungsform des hier vorgeschlagenen Ansatzes bietet den Vorteil, durch die Berücksichtigung der Bearbeitungsinformation eine sehr effiziente Auswahl einer Rechenoperation beispielsweise als erste Rechenoperation treffen zu können, sodass beispielsweise wichtigere, gering abgearbeitete oder häufiger auszuführende Rechenoperationen mit höher Priorität in der Recheneinheit bearbeitet werden können.
Gemäß einer weiteren Ausführungsform des hier vorgeschlagenen Ansatzes kann im Schritt des Zuordnens die Bearbeitungsinformation unter Berücksichtigung einer vollständigen Bearbeitung der betreffenden Rechenoperation zu zumindest einem vorangegangenen Zeitpunkt ermittelt werden. Speziell kann dabei derjenigen Rechenoperation, die zu einem vorausgegangenen Zeitpunkt vollständig abgearbeitet wurde, eine Bearbeitungsinformation, zugewiesen werden, die eine geringere Priorisierung für eine erneute Bearbeitung der betreffenden Rechenoperation in einem nachfolgenden Zeitpunkt repräsentiert. Eine solche Ausführungsform des hier vorgeschlagenen Ansatzes bietet den Vorteil, vornehmlich Rechenoperationen in freien Anteilen von Zeitintervallen zu arbeiten, die erfahrungsgemäß eine längere Bearbeitungszeit in Anspruch nehmen. Auf diese Weise kann vorteilhaft eine effiziente und schnelle Bearbeitung der Gesamtheit der auszuführenden Rechenoperationen erreicht werden.
Ferner kann entsprechend einer weiteren Ausführungsform des hier vorgeschlagenen Ansatzes im Schritt des Zuordnens die Bearbeitungsinformation für die erste, zweiten und/oder weitere Rechenoperation unter Verwendung einer Häufigkeit einer bisherigen Bearbeitung der betreffenden Rechenoperation ermittelt werden. Eine solche Ausführungsform bietet den Vorteil, besonders häufig auszuführende Rechenoperationen präjudiziert arbeiten zu lassen, um beispielsweise kurzfristig und häufig benötigte Verarbeitungswerte von Sensordaten schnell und zuverlässig zur Verfügung stellen zu können. Auf diese Weise können auch sicherheitskritische Rechenoperationen oder Algorithmen zuverlässig von der Recheneinheit bearbeitet werden.
Um eine in der Recheneinheit zur Verfügung stehende numerische Leistung effizient nutzen zu können, kann auch gemäß einer weiteren Ausführungsform im Schritt des Ausführens in dem zweiten Zeitintervall und/oder dem Hilfszeitintervall die weitere Rechenoperation ausgeführt werden, wenn die erste Rechenoperation in dem zweiten Zeitintervall und/oder dem Hilfszeitintervall abgeschlossen wurde. Eine solche Ausführungsform bietet den Vorteil, mehr als eine Rechenoperation im verbleibenden Anteil des zweiten Zeitintervalls und/oder des Hilfsintervalls ausführen zu können, sodass möglichst viele noch nicht abgeschlossene Rechenoperationen unter Vermeidung eines starren Zeitschlitz-Schemas abgearbeitet werden können.
Um eine aufwendige Entscheidung der als nächstes konkret auszuführenden Rechenoperation bei nahezu gleichen Voraussetzungen oder Entscheidungskriterien zu vermeiden, kann gemäß einer weiteren Ausführungsform im Schritt des Ausführens die als erste Rechenoperation auszuführende Rechenoperation unter Verwendung eines Ergebnisses eines Zufallsgenerators ausgeführt wird, wenn die den als mögliche erste Rechenoperation auszuwählenden Rechenoperationen zugeordneten Bearbeitungsinformationen innerhalb eines Toleranzbereichs gleich sind.
Eine besonders flexible Ausgestaltung für die Bearbeitung von Rechenoperationen in einer Recheneinheit kann gemäß einer weiteren Ausführungsform des hier vorgestellten Ansatzes dadurch erreicht werden, dass im Schritt des Zuordnens die den Rechenoperationen zugeordneten Bearbeitungsinformationen unter Verwendung einer erwarteten Ausführungszeitdauer bis zu einem Abschluss der Bearbeitung der betreffenden Rechenoperation in der Recheneinheit ermittelt wird. Insbesondere kann im Schritt des Ausführens diejenige Rechenoperation als erste Rechenoperation ausgewählt werden, deren Bearbeitungsinformation einer längsten Ausführungszeitdauer bis zu einem Abschluss der Bearbeitung der betreffenden Rechenoperation in der Recheneinheit entspricht. Auf diese Weise kann beispielsweise eine zu häufige und zeitintensive Neu-Ladung des Speichers oder Prozessors der Recheneinheit mit Algorithmen oder zwischen Ergebnissen der jeweiligen Rechenoperationen vermieden werden.
Auch können gemäß einer weiteren Ausführungsform des hier vorgeschlagenen Ansatzes die Schritte des Verfahrens zyklisch wiederholt ausgeführt werden, wobei in den wiederholt ausgeführten Schritten als erste Rechenoperation unterschiedliche Rechenvorschriften oder als zweite Rechenoperation unterschiedliche Rechenvorschriften verwendet werden können. Eine solche Ausführungsform bietet den Vorteil, verschiedene Algorithmen oder Verarbeitungsvorschriften für unterschiedlichste Zwecke als erste und/oder zweite Rechenoperation auf der Recheneinheit ausführen zu können, sodass die zur Verfügung stehenden numerische Leistungsfähigkeit der Recheneinheit möglichst optimal genutzt werden kann.
Um beispielsweise auch zu vermeiden, dass eine Rechenoperation in einem Zeitintervall kurz vor einem Abschluss der Bearbeitung abgebrochen wird, können auch gemäß einer weiteren Ausführungsform des hier vorgestellten Ansatzes die Schritte des Verfahrens wiederholt ausgeführt werden, wobei vor den wiederholt ausgeführten Schritten des Verfahrens ein Schritt des Veränderns einer zeitlichen Länge des ersten und/oder zweiten Zeitintervalls ausgeführt wird.
Von Vorteil ist ferner eine Ausführungsform des hier vorgeschlagenen Ansatzes, bei der im Schritt des Veränderns die zeitliche Länge des ersten und/oder zweiten Zeitintervalls zu einem späteren Zeitpunkt in Abhängigkeit von einem Abschluss der ersten Rechenoperation im ersten Zeitintervall und/oder einem Abschluss der zweiten Rechenoperation in einem vorangegangenen Zeitpunkt verändert wird. Eine solche Ausführungsform bietet den Vorteil, für die entsprechenden Rechenoperationen zeitlich optimale Zeitintervalllängen verwenden zu können und somit die entsprechenden Rechenoperationen auch möglichst innerhalb des jeweils zugeordneten Zeitintervall abschließen zu können. Dieses Verfahren kann beispielsweise in Software oder Hardware oder in einer Mischform aus Software und Hardware beispielsweise in einem Steuergerät implementiert sein.
Der hier vorgestellte Ansatz schafft ferner eine Vorrichtung, die ausgebildet ist, um die Schritte einer Variante eines hier vorgestellten Verfahrens in entsprechenden Einrichtungen durchzuführen, anzusteuern bzw. umzusetzen. Auch durch diese Ausführungsvariante der Erfindung in Form einer Vorrichtung kann die der Erfindung zugrundeliegende Aufgabe schnell und effizient gelöst werden.
Hierzu kann die Vorrichtung zumindest eine Recheneinheit zum Verarbeiten von Signalen oder Daten, zumindest eine Speichereinheit zum Speichern von Signalen oder Daten, zumindest eine Schnittstelle zu einem Sensor oder einem Aktor zum Einlesen von Sensorsignalen von dem Sensor oder zum Ausgeben von Daten- oder Steuersignalen an den Aktor und/oder zumindest eine Kommunikationsschnittstelle zum Einlesen oder Ausgeben von Daten aufweisen, die in ein Kommunikationsprotokoll eingebettet sind. Die Recheneinheit kann beispielsweise ein Signalprozessor, ein Mikrocontroller oder dergleichen sein, wobei die Speichereinheit ein Flash-Speicher, ein EEPROM oder eine magnetische Speichereinheit sein kann. Die Kommunikationsschnittstelle kann ausgebildet sein, um Daten drahtlos und/oder leitungsgebunden einzulesen oder auszugeben, wobei eine Kommunikationsschnittstelle, die leitungsgebundene Daten einlesen oder ausgeben kann, diese Daten beispielsweise elektrisch oder optisch aus einer entsprechenden Datenübertragungsleitung einlesen oder in eine entsprechende Datenübertragungsleitung ausgeben kann.
Unter einer Vorrichtung kann vorliegend ein elektrisches Gerät verstanden werden, das Sensorsignale verarbeitet und in Abhängigkeit davon Steuer- und/oder Datensignale ausgibt. Die Vorrichtung kann eine Schnittstelle aufweisen, die hard- und/oder softwaremäßig ausgebildet sein kann. Bei einer hardwaremäßigen Ausbildung können die Schnittstellen beispielsweise Teil eines sogenannten System-ASICs sein, der verschiedenste Funktionen der Vorrichtung beinhaltet. Es ist jedoch auch möglich, dass die Schnittstellen eigene, integrierte Schaltkreise sind oder zumindest teilweise aus diskreten Bauelementen bestehen. Bei einer softwaremäßigen Ausbildung können die Schnittstellen Softwaremodule sein, die beispielsweise auf einem Mikrocontroller neben anderen Softwaremodulen vorhanden sind.
Von Vorteil ist auch ein Computerprogrammprodukt oder Computerprogramm mit Programmcode, der auf einem maschinenlesbaren Träger oder Speichermedium wie einem Halbleiterspeicher, einem Festplattenspeicher oder einem optischen Speicher gespeichert sein kann und zur Durchführung, Umsetzung und/oder Ansteuerung der Schritte des Verfahrens nach einer der vorstehend beschriebenen Ausführungsformen verwendet wird, insbesondere wenn das Programmprodukt oder Programm auf einem Computer oder einer Vorrichtung ausgeführt wird.
Ausführungsbeispiele des hier vorgestellten Ansatzes sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:
Fig. 1 ein eine schematische Darstellung eines Fahrzeugs, in welchem eine Vorrichtung 105 gemäß eines Ausführungsbeispiels hier vorgestellten Ansatzes verbaut ist;
Fig. 2 eine schematische Darstellung des Zeitverlaufs t bei der Bearbeitung von Rechenoperationen entsprechend einem Ausführungsbeispiel des hier vorgestellten Ansatzes;
Fig. 3 eine Blockschaltbilddarstellung einer Vorrichtung zum Bearbeiten gemäß einem Ausführungsbeispiel; und
Fig. 4 ein Ablaufdiagramm eines Verfahrens gemäß einem Ausführungsbeispiel.
In der nachfolgenden Beschreibung günstiger Ausführungsbeispiele der vorliegenden Erfindung werden für die in den verschiedenen Figuren dargestellten und ähnlich wirkenden Elemente gleiche oder ähnliche Bezugszeichen verwendet, wobei auf eine wiederholte Beschreibung dieser Elemente verzichtet wird. Figur 1 zeigt eine schematische Darstellung eines Fahrzeugs 100, in welchem eine Vorrichtung 105 gemäß eines Ausführungsbeispiels hier vorgestellten Ansatzes verbaut ist. Ferner sind im Fahrzeug 100 beispielsweise noch ein oder mehrere Sensoren 110a und 110b verbaut, welche ihre Sensordaten 115a bzw. 115b an eine Recheneinheit 120 übertragen, in der diese Sensordaten 115 a und 115 b verarbeitet werden und beispielsweise ein Steuersignal 125 gebildet wird, welches ein Fahrzeugmodul 130 ansteuert. Das Fahrzeugmodul 130 kann beispielsweise ein Fahrerassistenzsystem oder ein Sicherheitssystem des Fahrzeugs 100, beispielsweise einen Airbag-System oder ein ABS-System sein.
Um nun das Steuersignal 125 korrekt zu ermitteln, werden in der Recheneinheit 120, die oftmals als Mikroprozessor oder Kontrolle ausgestaltet ist, die Sensordaten 115a bzw. 115b in unterschiedlichster Weise verknüpft oder verarbeitet, wobei für jede solche Verknüpfung oder Verarbeitung eine entsprechende Rechenoperation wie beispielsweise eine erste Rechenoperation 135a, eine zweite Rechenoperation 135b und/oder eine dritte Rechenoperation 135c als entsprechender Task in der Recheneinheit 120 ausgeführt werden soll. Gerade für eine schnelle Abarbeitung von oftmals für die Fahrsicherheit des Fahrzeugs 100 zeit- und sicherheitskritischen Algorithmen ist in der Recheneinheit 120 eine effiziente Bearbeitung der entsprechenden Rechenoperationen 135a, 135b und 135c erforderlich. Eine Steuerung der zeitlichen Ausführung oder Bearbeitung der entsprechenden Rechenoperationen 135a, 135b und/oder 135c in der Recheneinheit 120 wird hierbei entsprechend dem hier vorgestellten Ansatz durch ein Ausführungsbeispiel der Vorrichtung 105 zum Bearbeiten von zumindest einer ersten Rechenoperation 130a und einer zweiten Rechenoperationen 135b in der Recheneinheit 120 vorgenommen.
Um diese Aufgabe zu erfüllen, weist die Vorrichtung 105 zum Bearbeiten von zumindest einer ersten 135a und einer zweiten 135b Rechenoperation in einer Recheneinheit 120 eine Einheit 140 zum Erkennen und eine Einheit 145 zum Ausführen der ersten Rechenoperation 135a in dem zweiten Zeitintervall nach einem Abschlusszeitpunkt. Hierbei ist die Vorrichtung 105 um Bearbeiten ausgebildet, um die erste Rechenoperation in der Recheneinheit in einem ersten Zeitintervall zu bearbeiten und die zweite Rechenoperation in der Recheneinheit in einem von dem ersten Zeitintervall unterschiedlichen zweiten Zeitintervall zu bearbeiten. In der Einheit 140 zum Erkennen wird erkannt, dass die zweite Rechenoperation im zweiten Zeitintervall zu dem Abschlusszeitpunkt vor einem Ende des zweiten Zeitintervalls abgeschlossen wurde. In der Einheit 145 zum Ausführen werden die Speicher und/oder der Prozessor mit den Daten bzw. entsprechenden Verarbeitungsvorschriften geladen, um die jeweils betreffende Rechenoperation 135a, 135b bzw. 135c in der Recheneinheit 120 auszuführen.
Figur 2 zeigt eine schematische Darstellung des Zeitverlaufs t bei der Bearbeitung von Rechenoperationen entsprechend einem Ausführungsbeispiel des hier vorgestellten Ansatzes. Hierbei ist zu erkennen, dass in einer Zykluszeit To mehrere Unterzyklen So, Si, ..., SN -I enthalten sind. In jedem dieser Unterzyklen So, Si, ..., SN -I sind nun wieder Zeitintervalle für die Bearbeitung der einzelnen Rechenoperationen vorgesehen. Beispielsweise ist ein erstes Zeitintervall tfiX,i für die Bearbeitung der ersten Rechenoperation 135a vorgesehen, während ein zweites Zeitintervall tfiX,2 für die Bearbeitung der zweiten Rechenoperation 135b vorgesehen ist. In diesem Ausführungsbeispiel ist ferner ein Hilfszeitintervall 200 vorgesehen, welches die zeitliche Dauer nach Ende des zweiten Zeitintervalls tfiX,2 bis zum zeitlichen Ende des ersten Unterzyklus So dauert. Im Hilfszeitintervall 200 können je nach Dringlichkeit oder Erfordernis beliebige Rechenoperationen in der Recheneinheit 120 ausgeführt werden, sodass in diesem Hilfszeitintervall beispielsweise sowohl die erste Rechenoperation 130a als auch die zweite Rechenoperation 135b oder die weitere Rechenoperation 135c ausgeführt werden können.
Die Vorrichtung 105 zum Bearbeiten ist und ausgebildet, um die Speicher bzw. Prozessor der Recheneinheit 120 derart mit Daten zu laden, dass im ersten Zeitintervall die erste Rechenoperation 135a ausgeführt werden kann. Wie aus der Darstellung aus Figur 2 ersichtlich ist, ist die Bearbeitung der ersten Rechenoperation 135a zum Ende des ersten Zeitintervalls noch nicht abgeschlossen und muss somit unterbrochen werden. Für diesen Fall wird nun ein Zwischenergebnis 210 beispielsweise in einem in den Figuren nicht dargestellten Speicher der Recheneinheit oder der Vorrichtung 105 abgespeichert, wobei dieses Zwischenergebnis beispielsweise einerseits ein vorläufiges Berechnungsergebnis der ersten Rechenoperation und/oder eine Speicher-/Registerbelegung des Speichers oder von Registern des Prozessors der Recheneinheit 120 gebildet oder repräsentiert, damit die erste Rechenoperation 135a zu einem späteren Zeitpunkt möglichst fehlerfrei wieder aufgenommen werden kann. In dem an das erste Zeitintervall anschließenden zweiten Zeitintervall wird nun zunächst die zweite Rechenoperation 135b ausgeführt. Wie in der Abbildung aus Figur 2 zu erkennen ist, wird jedoch zu einem Abschlusszeitpunkt 220, der vor dem Ende des zweiten Zeitintervalls liegt, die Berechnung der zweiten Rechenoperation 135b abgeschlossen, sodass die Recheneinheit 120 in demjenigen Zeitabschnitt des zweiten Zeitintervalls zwischen dem Abschlusszeitpunkt 220 und dem Ende des zweiten Zeitintervalls nicht mehr für die Durchführung der zweiten Rechenoperation 135b benötigt wird und für andere Aufgaben zur Verfügung steht. Gemäß dem hier vorgestellten Ansatz kann nun der Speicher bzw. Prozessor der Recheneinheit 120 wieder mit den Daten des Zwischenergebnisses 210 geladen und die erste Rechenoperation 135a weitergeführt werden. Hierdurch kann eine möglichst effiziente Nutzung der in der Recheneinheit 120 zur Verfügung stehenden numerischen Leistung für eine schnelle Abarbeitung der Rechenoperationen 135 genutzt werden. Weiterhin kann auch beispielsweise nach Abschluss des zweiten Zeitintervalls im anschließenden Hilfszeitintervall 200 diejenige Rechenoperation (hier die erste Rechenoperation 135a) bearbeitet werden, sodass ein zeitintensiver Wechsel der in der Recheneinheit 120 abgelegten Daten bzw. Verarbeitungsvorschriften möglichst vermieden und somit eine weitere Beschleunigung der Abarbeitung der Rechenoperationen 135 erreicht werden kann.
Sollte nun keine weitere Rechenoperation zur Bearbeitung anstehen, kann die Recheneinheit 120 in der verbleibenden Zeitspanne des Hilfszeitintervall 200 unbenutzt sein. Alternativ kann natürlich auch beispielsweise die weitere Rechenoperation 135c in dieser verbleibenden Zeitspanne des Hilfszeitintervall 200 ausgeführt werden, was jedoch in der Figur 2 nicht explizit dargestellt ist.
Eine analoge Vorgehensweise der Steuerung der Ausführung oder Bearbeitung von Rechenoperationen in der Recheneinheit 120 kann auch mit Bezug zum Unterzyklus Si dargestellt werden. Diesem Fall wird nun im ersten Zeitintervall die erste Rechenoperation 135a bearbeitet und zum Abschlusszeitpunkt 220 beendet, bevor das erste Zeitintervall beendet ist. Für die möglichst effiziente Nutzung der Recheneinheit 120 kann nun direkt im ersten Zeitintervall bereits die zweite Rechenoperation 135b gestartet werden, die dann auch im auf das erste Zeitintervall folgenden zweiten Zeitintervall und sogar direkt im Hilfszeitintervall 200 unterbrechungsfrei weiterbearbeitet wird. Auf diese Weise kann sehr effiziente Steuerung der Bearbeitung der Rechenoperationen in der Recheneinheit 120 ermöglicht werden.
Sollte wiederum im Hilfszeitintervall 200 kein Bedarf mehr für eine Bearbeitung sowohl der ersten Rechenoperation 135a als auch der zweiten Rechenoperation 135b mehr bestehen, kann auch in diesem wieder die Recheneinheit 120 unbenutzt bleiben oder die weitere Rechenoperation 135c bearbeitet werden.
Figur 3 zeigt eine Blockschaltbilddarstellung einer Vorrichtung 105 zum Bearbeiten gemäß einem Ausführungsbeispiel. Die Vorrichtung 105 zum Bearbeiten umfasst hierbei Einheit 140 zum Erkennen sowie die Einheit 145 zum Ausführen. In der Einheit 140 zum Erkennen wird beispielsweise erkannt, dass eine Rechenoperation wie beispielsweise die erste Rechenoperation 135a, die zweite Rechenoperation 135b und/oder die weitere Rechenoperation 135c fertiggestellt oder vorreserviert für die Ausführung in einem folgenden Zeitschlitz ist, wobei dieses Ergebnis nun der Einheit 145 zum Ausführen übertragen wird. Die Einheit 145 zum Ausführen wirkt nun wie eine Einheit zum Planen eines freien Zeitbudgets der Recheneinheit 120, also zum Planen welche Rechenoperation ab einem Abschlusszeitpunkt 220 bis zum Ende des jeweiligen Zeitintervalls und/oder im Hilfszeitintervall 200 ausgeführt werden soll. Hierzu wird zunächst in einer Rechenoperation- Fertigstellungsstatistikzählereinheit 300 erfasst, welche Rechenoperation wie häufig abgeschlossen wurde. Ein Ergebnis dieser Einheit 300, welches eine Bearbeitungsinformation 305 darstellt, wird nachfolgend in eine Logikeinheit 310 übertragen, welche die nächste Rechenoperation auswählt. Optional wird das Ergebnis bzw. die Bearbeitungsinformation 305 dieser Einheit 300 einer weiteren Logikeinheit 320 zugeführt, welche ermitteln kann, wie lange bzw. welches Zeitintervall einer nachfolgenden Ausführung einer entsprechenden Rechenoperation zugewiesen wird. Eine verarbeitete Bearbeitungsinformation 305‘ aus der Logikeinheit 310 als auch der weiteren Logikeinheit 320 wird dann einem Rechenoperation- Planungsaktuator 330 zugeführt, welche entsprechende Register oder Speicher in der Recheneinheit 120 belegt, um eine entsprechend ausgewählte auszuführende Rechenoperation in der Recheneinheit 120 durchführen zu können. Zugleich wird von dem Rechenoperation-Planungsaktuator 330 einer Prüflogik 340 zur Überprüfung einer fertiggestellten Bearbeitung einer Rechenoperation mitgeteilt, ob bzw. welche Rechenoperation in der Recheneinheit 120 geladen wurde. Zugleich wird durch die Prüflogik 340 die Abarbeitung der Rechenoperation in der Recheneinheit 120 überwacht. Wird in der Prüflogik 340 festgestellt, dass die in der Recheneinheit 120 auszuführende Rechenoperationen fertig gestellt ist, wird dieses Ergebnis wiederum der Einheit 300 mitgeteilt, welche die Ausführung der entsprechenden Rechenoperation in der Recheneinheit 120 protokolliert und eine entsprechende Information für einen neuen Zyklus der Bearbeitung einer Rechenoperation auf der Recheneinheit 120 an die Logikeinheit 310 bzw. die weitere Logikeinheit 320 liefert.
Figur 4 zeigt ein Ablaufdiagramm eines Ausführungsbeispiels eines Verfahrens 400 zum Bearbeiten von zumindest einer ersten und einer zweiten Rechenoperation in einer Recheneinheit. Dabei sind zum Bearbeiten der ersten Rechenoperation in der Recheneinheit ein erstes Zeitintervall vorgesehen und zum Bearbeiten der zweiten Rechenoperation in der Recheneinheit ein von dem ersten Zeitintervall unterschiedliches zweites Zeitintervall vorgesehen. Das Verfahren 400 umfasst einen Schritt 410 des Erkennens, dass die zweite Rechenoperation im zweiten Zeitintervall zu einem Abschlusszeitpunkt vor einem Ende des zweiten Zeitintervalls abgeschlossen wurde. Ferner umfasst das Verfahren 400 einen Schritt 420 des Ausführens der ersten Rechenoperation in dem zweiten Zeitintervall nach dem Abschlusszeitpunkt. Zusätzlich oder alternativ umfasst das Verfahren 400 einen Schritt 410 des Erkennens, dass die erste Rechenoperation im ersten Zeitintervall zu einem Abschlusszeitpunkt vor einem Ende des ersten Zeitintervalls abgeschlossen wurde. Schließlich umfasst das Verfahren 400 einen Schritt 420 des Ausführens der zweiten Rechenoperation in dem ersten Zeitintervall nach dem Abschlusszeitpunkt.
Nachfolgend kann der hier vorgestellte Ansatz nochmals mit anderen Worten zusammengefasst bzw. ergänzt oder weitergeführt werden. Der hier vorgestellte Ansatz kann als Cycle-optimierter Soft- Real-Time Scheduler für die Belegung einer Recheneinheit mit verschiedenen Rechenoperationen aufgefasst werden.
Vorauszuschicken wäre hierbei, dass sich Systeme mit Echtzeitanforderungen dadurch auszeichnen, dass eine Vielzahl von Aufgaben zyklischer Natur ist, z. B. die wiederkehrende Berechnung von Objektdaten auf Basis von Sensordaten, die regelmäßig extern eingespeist werden. Dabei ist in einem soft-real-time- Systeme regelmäßig auch nicht relevant, dass eine Aufgabe in jedem Zyklus abgeschlossen werden kann, sondern, dass die Aufgabe in einem größeren Zeitintervall eine bestimmte Anzahl von Malen komplett abgeschlossen werden kann. In jedem Zyklus startet dabei die Aufgabe beispielsweise von neuem, z. B. weil neue Sensordaten verfügbar sind.
Da die Laufzeit der einzelnen Aufgabe externen Einflüssen unterliegen kann (z. B. gegeben durch die Komplexität einer zu bearbeitenden Szene), stellt die Budgetplanung eine besondere Herausforderung dar. Regelmäßig werden worst- case-Abschätzungen gemacht, die jedoch dazu führen, dass in der Praxis die Budgets zu groß gewählt werden. Dadurch werden in jedem Zyklus alle Aufgaben mit hoher Sicherheit komplett zu Ende bearbeitet. Um trotzdem eine effiziente Ressourcennutzung zu gewährleisten, werden nicht genutzte Budgetanteile zur Sicherstellung einer „work load preservation“ anderen Aufgaben zur Verfügung gestellt. Da die initiale Systemauslegung aber bereits eine hohe Abschlusswahrscheinlichkeit der Aufgaben vorgesehen hat, bleibt dieser Überschuss ungenutzt. Die reine Umverteilung von Überschussbudget ist so nur eingeschränkt erfolgreich, um eine den Aufgaben angemessenere Systemauslegung (z. B. durch Wahl einer schwächeren CPU) zu ermöglichen.
Ein Grundgedanke des hier vorgestellten Vorschlags kann darin gesehen werden, dass der hier vorgestellte Ansatz die effiziente Umverteilung von ungenutzten geteilten Ressourcen zur Erfüllung von Soft-Realtime- Anforderungen ermöglicht. Soft- Realtime- Anforderungen sind in diesem Kontext definiert als der Abschluss (completion) einer wiederkehrenden Ressourcennutzenden Aufgabe (Task bzw.- Rechenoperation), die beispielsweise in einem bestimmten Zeitintervall eine bestimmte Anzahl von Malen komplett abgeschlossen werden sollte. Ein Task hat dabei eine unbekannte dynamische Laufzeit tdyn bis zum Abschluss(zeitpunkt), die von äußeren Faktoren abhängt (z. B. Anzahl verfügbarer Sensordaten). Dabei liegt der Fokus des hier vorgestellten Ansatzes darauf (Erfolgskriterium des soft-realtime Schedulers als Vorrichtung 105), dass die Aufgabe bzw. Rechenoperation innerhalb eines Zeitintervalls To beispielsweise mindestens Nmin mal erfolgreich abgeschlossen wird. Der Zeitraum To wird in N >=Nmin Zeitintervalle (bzw. Unterzyklen) mit Dauer Si,o< =i< N eingeteilt, innerhalb derer der Task jeweils komplett von Anfang bis Ende ausgeführt werden soll. Die Dauer der inneren Intervalle bzw. Unterzyklen Sj ist dabei z. B. von der Verfügbarkeit neuer Datenpakete, beispielsweise Sensordatenpakete, bestimmt. Es gibt generell mehrere Tasks bzw. Rechenoperationen im jeweiligen Intervall, die um die Ressourcenzuweisung konkurrieren.
Ein Grundgedanke des hier vorgestellten Ansatzes ist die Festlegung eines fixen Laufzeitbudgets tfiX pro Ausführung des Tasks pro Zeitintervall Si, welches mit einer nicht vernachlässigbaren statistischen Wahrscheinlichkeit kleiner als die dynamische Laufzeit tdyn ist. Das Laufzeitbudget ist dabei das Garantiebudget, das der Task auf jeden Fall erhalten wird. Eine entsprechend große Dimensionierung von tfiX um alle Realisierungen von tdyn abzudecken ist ineffizient.
Ist der Task bis zur Erschöpfung des Laufzeitbudgets tfiX nicht abgeschlossen, wird sein Zustand (beispielsweise in der Form des Zwischenergebnisses 210) erhalten. Darauffolgend wird ein anderer Task bzw. eine andere Rechenoperation 135b mit verbleibendem Budget ausgeführt (Preemption). Pro Zeitintervall gibt es mehrere ausführbereite Tasks, die jeweils bis zur Grenze ihres fixen Laufzeitbudget die geteilte Ressource nutzen können. Wenn alle Tasks entweder abgeschlossen sind oder ihr Budget verbraucht haben, entscheidet eine Zentralinstanz (free-budget scheduler als Vorrichtung 105) über die Verteilung des verbliebenen Zeitbudgets innerhalb des Zeitintervalls bzw. Unterzyklus Si. Generell gilt, dass Si>ltfix,j. Ein Schwerpunkt des hier vorgestellten Ansatzes liegt auf der Wahl der Tasks bzw. Rechenoperationen, die im verbliebenen Zeitbudget wieder zur Ausführung gebracht werden um potenziell ihren dynamischen Laufzeitbedarf tdyn zu decken. Dazu wird beispielsweise eine Counting-Statistik und Algorithmus vorgeschlagen, der priorisiert den Task auswählt, bei dem die Wahrscheinlichkeit innerhalb des Intervalls To nicht mindestens Nmin mal zu Ende zu laufen, am höchsten ist.
Als Vorteile des hier vorgestellten Ansatzes können mehrere Aspekte angegeben werden.
1. Der hier vorgestellte Ansatz ist dazu geeignet, Langzeitqualitätskriterien für Scheduler bzw. die Vorrichtung 105 (Mindestzahl von kompletten Ausführungen eines Tasks bzw. einer Rechenoperation) explizit zu berücksichtigen.
2. Der hier vorgestellte Ansatz ermöglicht eine effiziente Ressourcenauslastung (work preservation), da innerhalb eines Zyklus die geteilte Ressource voll genutzt werden kann.
3. Der hier vorgestellte Ansatz ist besonders geeignet für zyklische Tasks mit wechselnder Load bzw. (numerischer) Last, wie sie z. B. bei Sensorfusionsaufgaben im hoch automatisierten Fahren vorkommen.
4. Der hier vorgestellte Ansatz kann mit anderen Scheduling-Mechanismen innerhalb der einzelnen Unterzeitintervalle kombiniert werden, z. B. um die Reaktionszeit bzw. response time (Zeit bis zum Abschluss der Rechenoperation bzw. zur Completion) zu verbessern.
5. Der hier vorgeschlagene Entscheidungsalgorithmus kann use-case-basiert angepasst werden.
6. Der hier vorgestellte Ansatz kann initial für das Scheduling einer Rechnereinheit bzw. CPU vorgesehen sein, kann jedoch auch für andere geteilte Ressourcen angewendet werden.
Speziell in Figur 2 ist ein Ausführungsbeispiel für eine Verteilung des freien Budgets auf Basis der Task Completion näher beschrieben. Der vorgeschlagene Scheduler entscheidet gemäß einem Ausführungsbeispiel über die Verteilung ungenutzter verbleibender Laufzeit innerhalb eines Zeitintervalls Si. Dabei berücksichtigt er beispielsweise nur die Tasks bzw. Rechenoperationen, die noch nicht abgeschlossen wurden, d. h. die ihr Budget vollständig verbraucht haben ohne die Aufgabe zu beenden. Der Scheduler kann dies beispielsweise daran erkennen, dass die Tasks jeweils preemptiert wurden, d. h., dass im Rahmen der Erschöpfung des Laufzeitbudgets der Task zwangsweise durch einen anderen Task auf der CPU bzw. Recheneinheit 120 ersetzt wurde.
Speziell mit Bezug zur Figur 3 werden einzelne Komponenten des „Free Budget Schedulers“ näher erläutert, der hier eine spezielle Form der Vorrichtung 105 zum Bearbeiten darstellt.
Zunächst wird beispielsweise in einer Rechenoperation- Fertigstellungsstatistikzählereinheit 300 [task completion statistics counter] eine einfache Counting-Statistik inkrementiert für jeden nicht zu Ende gelaufenen Task (= Rechenoperation) einen taskspezifischen Ganzzahlzähler. Wird der Task nun ausgewählt und kann durch Nutzung des Restbudgets im Zeitintervall Si seine Aufgabe abschließen, wird die Counting-Statistik dekrementiert.
Komplexere Statistiken, die z. B. ein graduelles Inkrementieren / Dekrementieren oder die Anwendung eines sliding windows berücksichtigen, sind möglich. Für Tasks, die innerhalb ihres fixen Laufzeitbudgets abgeschlossen werden, wird beispielsweise der Zähler entweder zurückgesetzt oder dekrementiert. Letzteres hätte Vorteile bei zyklischen Lastszenarios.
In einer Logikeinheit 310, welche die nächste Rechenoperation auswählt [next task selection logic], kann beispielsweise eine Auswahl aufgrund der Counting- Statistik nun auf verschiedene Weisen erfolgen. Es können daher in dieser Logikeinheit folgende Vorgehensweise für die Belegung der Register und Speicher der Recheneinheit 120 ausgewählt werden, wobei die numerischen Schritte beispielsweise die Reihenfolge, Buchstaben die Alternativen angeben. Werte in Klammern beziehen sich beispielsweise auf eine Referenz zum vorherigen: la. Es wird grundsätzlich der Task gewählt, der den höchsten Counterwert hat. lb. Es wird mit einer gemäß der Statistik gewichteten Wahrscheinlichkeit ein Task gewählt, d. h. Tasks mit höheren Counterwerten werden mit höherer Wahrscheinlichkeit gewählt.
2a (la). Haben zwei oder mehr Tasks den gleichen Counterwert, wird durch einen Zufallszahlengenerator der Task gewählt, der auf der Recheneinheit 120 laufen bzw. ausgeführt werden soll.
2b (la). Haben zwei oder mehr Tasks den gleichen Counterwert, wird der Task gewählt, der am längsten (im Sinne der Zeitintervalle S) nicht erfolgreich abgeschlossen werden konnte. Gilt dies für mehre Tasks, kann (2a) oder (2c) angewendet werden.
2c (la). Haben zwei oder mehr Tasks den gleichen Counterwert, wird der erste Task gemäß der Reihenfolge in der Liste der Counting-Statistik gewählt. Diese Option kann allerdings zu suboptimalen Ergebnissen unter den Randbedingungen korrelierter Überschreitungen der fixen Laufzeitbudgets führen.
In einer weiteren Logikeinheit 320 kann beispielsweise ermitteln werden, wie lange bzw. welches Zeitintervall einer nachfolgenden Ausführung einer entsprechenden Rechenoperation zugewiesen wird [task run duration budget logic]. Es kann somit beispielsweise über die Dauer der Ausführung wir folgt entschieden werden:
3a. Der ausgewählte Task wird bis zur Completion also bis zum Abschlusszeitpunkt laufen gelassen und sein Counterwert dekrementiert.
3b. Der ausgewählte Task wird nur für eine fixe erweiterte Periode laufen gelassen. Die Länge der Periode wird dabei beispielsweise gemäß der Gewichtung in der Ausführungsstatistik gewählt. Beispielsweise ist es möglich, einen Task länger laufen zu lassen, sollte er in der Vergangenheit trotz des free budget schedulers die Aufgabe nicht abgeschlossen haben. In einer Prüflogik 340 zur Überprüfung einer fertiggestellten Bearbeitung einer Rechenoperation [task completion check logic] kann beispielsweise nach Ende der erweiterten Ausführung die Taskstatistik erkannt, in der Rechenoperation- Fertigstellungsstatistikzählereinheit 300 aktualisiert und der nächste Task ausgewählt werden. Dies wird so lange wiederholt bis entweder alle Tasks für dieses Zeitintervall erfolgreich abgeschlossen wurden oder das Zeitintervall verstrichen ist.
Denkbar sind ferner auch mögliche Alternativen des hier vorgestellten Ansatzes. Beispielsweise können Erweiterungen wie folgt vorgesehen werden:
1. Ersetze „Tasks“ durch „Task Container“, d. h. mehrere Tasks werden zu einem task container zusammengefasst. Sie teilen sich das gleiche Laufzeitbudget und werden gleichermaßen bei der Auswahl behandelt. Die innere Logik der Container, d. h. welchem Task des Task Containers die Ressource zugewiesen wird, ist im Rahmen eines containerspezifischen Schedulers zu entscheiden.
2. Partitionierung des freien Budgets. Weitere Einschränkungen können bei der Auswahl der Tasks und ihrer Nutzung des verbleibenden Budgets gemacht werden. So kann festgelegt werden, dass ein Task nur das nicht genutzte Budget eines/einer Gruppe anderer Tasks verwenden kann. Diese Verschränkung erhöht die gegenseitige FFIs von tasks mit unterschiedlichen Garantieanforderungen.
3. Sollte es bei einzelnen Tasks zu einer kritischen Zahl von missed-completions kommen, ist im Rahmen eines Slot- Stealings vorstellbar, das Laufzeitbudget von anderen Tasks, die bisher durchgehend ihre Deadlines eingehalten halten einmalig zu verletzen und damit eine completion des kritischen Tasks zu erlauben. Diese Variante geht allerdings davon aus, dass Tasks als hard (keine Verletzung ist akzeptabel) und soft realtime (s.o.) im Scheduler kategorisiert werden können.
Eine hier vorgestellte Vorgehensweise hat beispielsweise Potenzial, in einem Vehicle Computer mit Aufgaben im ADAS-Umfeld eingesetzt zu werden. In einem solchen System treten häufig dynamische Lasten auf, z. B. aufgrund der unterschiedlichen Komplexität des Fahrzeugumfelds. Die vorgesehenen Prozesse erlauben aber eine soft-realtime Realisierung, bei der Tasks, bis zu einer Akzeptanzgrenze, deadline-Verletzungen aufweisen dürfen.
Dabei können folgende Aspekte zum Tragen kommen:
(a) Es ist keine Mischung von Tasks mit harten Echtzeitanforderungen und weichen Echtzeitanforderungen vorzusehen.
(b) Es braucht nicht garantiert zu werden, dass Tasks zu einem bestimmten Zeitpunkt begonnen werden.
(c) Es kann über die Zeit zu einer Desynchronisierung von abhängigen Tasks in verteilten Systemen kommen.
In diesem Sinne ist der hier vorgestellte Ansatz eine neue Lösung für ein bestehendes Problem. Die Mischung von harten und weichen Echtzeitsystemen ist ein neues technisches Aufgabenfeld, das erst mit der Erscheinung von Aufgaben mit dynamischen Inputgrößen (z. B. bei der Zahl der zu erkennenden Objekte bei einer Umfeldsensorik) entstanden sind. Es ist zwar zwar möglich, Systeme mit Misch-Aufgaben zu betreiben, dort aber mit entsprechend (ineffizientem) Vorhalten von Rechenleistung, um eine Renormalisierung zu einem harten Echtzeitsystem zu erlauben.
Daraus abgeleitet ist zumindest davon auszugehen
(a) dass dies keine triviale Aufgabe zu sein scheint, da es ja Stand auch noch keine Lösungen gibt; und
(b) dies ein neues Feld mit entsprechend geringen vorbekannten Lösungen ist, so dass auch grundlegend neue Ansätze einen gewissen Wert haben.
Umfasst ein Ausführungsbeispiel eine „und/oder“-Verknüpfung zwischen einem ersten Merkmal und einem zweiten Merkmal, so ist dies so zu lesen, dass das Ausführungsbeispiel gemäß einer Ausführungsform sowohl das erste Merkmal als auch das zweite Merkmal und gemäß einer weiteren Ausführungsform entweder nur das erste Merkmal oder nur das zweite Merkmal aufweist.

Claims

- 22 - Ansprüche
1. Verfahren (400) zum Bearbeiten von zumindest einer ersten (135a) und einer zweiten (135b) Rechenoperation (135) in einer Recheneinheit (120), wobei zum Bearbeiten der ersten Rechenoperation (135a) in der Recheneinheit (120) ein erstes Zeitintervall (tfiX,i) vorgesehen ist und zum Bearbeiten der zweiten Rechenoperation (135b) in der Recheneinheit (120) ein von dem ersten Zeitintervall (tfiX,i) unterschiedliches zweites Zeitintervall (tfix.s) vorgesehen ist, wobei das Verfahren (400) die folgenden Schritte aufweist:
Erkennen (410), dass die zweite Rechenoperation (135b) im zweiten Zeitintervall (tfix.s) zu einem Abschlusszeitpunkt (220) vor einem Ende des zweiten Zeitintervalls (tfjX,2) abgeschlossen wurde; und Ausführen (420) der ersten Rechenoperation (135a) in dem zweiten Zeitintervall (tfiX,2) nach dem Abschlusszeitpunkt (220); und/oder
Erkennen, dass die erste Rechenoperation (135a) im ersten Zeitintervall (tfiX,i) zu einem Abschlusszeitpunkt (220) vor einem Ende des ersten Zeitintervalls (tfiX,i) abgeschlossen wurde; und Ausführen der zweiten Rechenoperation (135b) in dem ersten Zeitintervall (tfiX,i) nach dem Abschlusszeitpunkt (220).
2. Verfahren (400) gemäß Anspruch 1, mit einem Schritt des Abspeicherns eines Zwischenergebnisses (210) der ersten Rechenoperation (135a) nach Ablauf des ersten Zeitintervalls (tfjX,i), wenn die erste Rechenoperation (135a) im ersten Zeitintervall (tfiX,i) nicht abgeschlossen werden konnte, wobei im Schritt (420) des Ausführens ab dem Abschlusszeitpunkt (220) die erste Rechenoperation (135a) ausgehend vom Zwischenergebnis (210) weiterbearbeitet wird. Verfahren (400) gemäß einem der vorangegangenen Ansprüche, wobei ferner ein Hilfszeitintervall (200) in der Recheneinheit (120) vorgesehen ist, in welchem zumindest ein Teil der ersten (135a) und/oder zweiten (135b) Rechenoperation bearbeitbar ist, wobei im Schritt (420) des Ausführens die Bearbeitung der zweiten Rechenoperation (135b) und/oder die erste Rechenoperation (135a) nach einem Ablauf des zweiten Zeitintervalls (tfjX,2) im Hilfszeitintervall (200) unterbrechungsfrei weiterbearbeitet wird, insbesondere wenn eine Bearbeitung der zweiten Rechenoperation (135b) und/oder der ersten Rechenoperation (135a) nach Ablauf des zweiten Zeitintervalls (tfjX,2) noch nicht abgeschlossen worden ist. Verfahren (400) gemäß einem der vorangegangenen Ansprüche, bei dem ferner zumindest eine weitere Rechenoperation (135c) in der Recheneinheit (120) bearbeitet wird, wobei ein Schritt des Zuordnens vorgesehen ist, in dem der ersten (135a), zweiten (135b) und/oder weiteren Rechenoperation (135c) je eine Bearbeitungsinformation (305, 305‘) zugeordnet wird, die eine Information über eine erfolgte Bearbeitung der betreffenden Rechenoperation (135) zu einem vorangegangenen Zeitpunkt repräsentiert, wobei im Schritt (420) des Ausführens die als erste Rechenoperation (135a) auszuführende Rechenoperation (135) unter Berücksichtigung der Bearbeitungsinformation (305, 305‘) zum Bearbeiten in dem zweiten Zeitintervall (tfiX,i) ausgewählt wird. Verfahren (400) gemäß Anspruch 4, bei dem im Schritt des Zuordnens die Bearbeitungsinformation (305, 305‘) unter Berücksichtigung einer vollständigen Bearbeitung der betreffenden Rechenoperation (135) zu zumindest einem vorangegangenen Zeitpunkt ermittelt wird, insbesondere wobei derjenigen Rechenoperation (135), die zu einem vorausgegangenen Zeitpunkt vollständig abgearbeitet wurde, eine Bearbeitungsinformation (305, 305‘) zugewiesen wird, die eine geringere Priorisierung für eine erneute Bearbeitung der betreffenden Rechenoperation (135) in einem nachfolgende Zeitpunkt repräsentiert. Verfahren (400) gemäß einem der Ansprüche 4 oder 5, wobei im Schritt des Zuordnens die Bearbeitungsinformation (305, 305‘) für die erste (135a), zweiten (135b) und/oder weitere Rechenoperation (135c) unter Verwendung einer Häufigkeit einer bisherigen Bearbeitung der betreffenden Rechenoperation (135) ermittelt wird. Verfahren (400) gemäß einem der Ansprüche 4 bis 6, wobei im Schritt (420) des Ausführens in dem zweiten Zeitintervall (tfix.s) und/oder dem Hilfszeitintervall (200) die weitere Rechenoperation (135c) ausgeführt wird, wenn die erste Rechenoperation (135a) in dem zweiten Zeitintervall (tfix.s) und/oder dem Hilfszeitintervall (200) abgeschlossen wurde. Verfahren (400) gemäß einem der Ansprüche 4 bis 7, wobei im Schritt (420) des Ausführens die als erste Rechenoperation (135a) auszuführende Rechenoperation (135) unter Verwendung eines Ergebnisses eines Zufallsgenerators ausgeführt wird, wenn die den als mögliche erste Rechenoperation (135a) auszuwählenden Rechenoperationen zugeordneten Bearbeitungsinformationen (305, 305‘) innerhalb eines Toleranzbereichs gleich sind. Verfahren (400) gemäß einem der Ansprüche 4 bis 8, bei im Schritt des Zuordnens die den Rechenoperationen (135) zugeordneten Bearbeitungsinformationen (305, 305‘) unter Verwendung einer erwarteten Ausführungszeitdauer bis zu einem Abschluss (210) der Bearbeitung der betreffenden Rechenoperation (135) in der Recheneinheit (120) ermittelt wird, insbesondere wobei im Schritt (420) des Ausführens diejenige Rechenoperation (135) als erste Rechenoperation (135a) ausgewühlt wird, deren Bearbeitungsinformation einer längsten Ausführungszeitdauer bis zu einem Abschluss der Bearbeitung der betreffenden Rechenoperation (135) in der Recheneinheit (120) entspricht. Verfahren (400) gemäß einem der vorangegangenen Ansprüche, bei dem die Schritte (410, 420) des Verfahren (400) zyklisch wiederholt ausgeführt werden, wobei in den wiederholt ausgeführten Schritten als erste Rechenoperation (135a) unterschiedliche Rechenvorschriften oder - 25 - als zweite Rechenoperation (135b) unterschiedliche Rechenvorschriften verwendet werden können. Verfahren (400) gemäß einem der vorangegangenen Ansprüche, bei dem die Schritte (410, 420) des Verfahrens (400) wiederholt ausgeführt werden, wobei vor den wiederholt ausgeführten Schritten (410, 420) des Verfahrens (400) ein Schritt des Veränderns einer zeitlichen Länge des ersten (tfiX,i) und/oder zweiten (tfix.s) Zeitintervalls ausgeführt wird. Verfahren (400) gemäß Anspruch 11, bei dem im Schritt des Veränderns die zeitliche Länge des ersten (tfiX,i) und/oder zweiten (tfix.s) Zeitintervalls in Abhängigkeit von einem Abschluss der ersten Rechenoperation (135a) im ersten Zeitintervall (tfjX,i) und/oder einem Abschluss der zweiten Rechenoperation (135b) verändert wird. Vorrichtung (105), die eingerichtet ist, um die Schritte (410, 420) des Verfahrens (400) gemäß einem der vorangegangenen Ansprüche in entsprechenden Einheiten (140, 145) auszuführen und/oder anzusteuern. Computerprogramm, das dazu eingerichtet ist, die Schritte (410, 420) des Verfahrens (400) gemäß einem der vorangegangenen Ansprüche auszuführen und/oder anzusteuern. Maschinenlesbares Speichermedium, auf dem das Computerprogramm nach Anspruch 14 gespeichert ist.
PCT/EP2022/069756 2021-08-31 2022-07-14 Verfahren und vorrichtung zum bearbeiten von zumindest einer ersten und einer zweiten rechenoperation in einer recheneinheit WO2023030736A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP22753614.1A EP4396678A1 (de) 2021-08-31 2022-07-14 Verfahren und vorrichtung zum bearbeiten von zumindest einer ersten und einer zweiten rechenoperation in einer recheneinheit
CN202280072334.2A CN118159946A (zh) 2021-08-31 2022-07-14 用于在计算单元中至少处理第一和第二计算运算的方法和设备

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102021209509.7A DE102021209509A1 (de) 2021-08-31 2021-08-31 Verfahren und Vorrichtung zum Bearbeiten von zumindest einer ersten und einer zweiten Rechenoperation in einer Recheneinheit
DE102021209509.7 2021-08-31

Publications (1)

Publication Number Publication Date
WO2023030736A1 true WO2023030736A1 (de) 2023-03-09

Family

ID=82850085

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2022/069756 WO2023030736A1 (de) 2021-08-31 2022-07-14 Verfahren und vorrichtung zum bearbeiten von zumindest einer ersten und einer zweiten rechenoperation in einer recheneinheit

Country Status (4)

Country Link
EP (1) EP4396678A1 (de)
CN (1) CN118159946A (de)
DE (1) DE102021209509A1 (de)
WO (1) WO2023030736A1 (de)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6189022B1 (en) * 1997-08-20 2001-02-13 Honeywell International Inc. Slack scheduling for improved response times of period transformed processes
US20030101084A1 (en) * 2001-11-19 2003-05-29 Otero Perez Clara Maria Method and system for allocating a budget surplus to a task
US20160364267A1 (en) * 2015-06-11 2016-12-15 Honeywell International Inc. Systems and methods for scheduling tasks using sliding time windows

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6189022B1 (en) * 1997-08-20 2001-02-13 Honeywell International Inc. Slack scheduling for improved response times of period transformed processes
US20030101084A1 (en) * 2001-11-19 2003-05-29 Otero Perez Clara Maria Method and system for allocating a budget surplus to a task
US20160364267A1 (en) * 2015-06-11 2016-12-15 Honeywell International Inc. Systems and methods for scheduling tasks using sliding time windows

Also Published As

Publication number Publication date
CN118159946A (zh) 2024-06-07
EP4396678A1 (de) 2024-07-10
DE102021209509A1 (de) 2023-03-02

Similar Documents

Publication Publication Date Title
DE102006010400B4 (de) Verfahren zur Erstellung eines optimierten Ablaufplans für ein zeitgesteuertes verteiltes Rechnersystem
DE4410775C2 (de) Steuergerät und Arbeitsverfahren eines Betriebssystems für dieses Steuergerät
DE102014103139B4 (de) Parallelisierte Ausführung von Single-Core Steuerungssoftware auf Multi-Core Fahrzeugsteuergeräten
DE102007051803A1 (de) Verfahren und Vorrichtung zur Datenverarbeitung
EP4012516A1 (de) Ausführungsumgebung für eine speicherprogrammierbare steuerung
WO2011063869A1 (de) Verfahren zum ermöglichen einer sequentiellen, nicht blockierenden abarbeitung von anweisungen in nebenläufigen tasks in einer steuereinrichtung
EP3861440A1 (de) Verfahren zur datenverarbeitung und speicherprogrammierbare steuerung
DE102015100566A1 (de) Verfahren und leichter Mechanismus für gemischte kritische Anwendungen
EP4396678A1 (de) Verfahren und vorrichtung zum bearbeiten von zumindest einer ersten und einer zweiten rechenoperation in einer recheneinheit
DE102008019287B4 (de) Verfahren zum automatischen Erzeugen eines Zeitschemas für über einen zeitgesteuerten gemeinsamen Datenbus kommunizierende verteilte Anwendungen oder Prozesse eines digitalen Netzwerks
DE102018104193A1 (de) Grafik-Engine-Ressourcenverwaltung und -Zuweisungssystem
DE102019219260A1 (de) Verfahren zum Betreiben einer Recheneinheit
DE102018205390A1 (de) Verfahren und Vorrichtung zur Fehlerbehandlung in einer Kommunikation zwischen verteilten Software Komponenten
DE102020205720A1 (de) Computerimplementiertes Verfahren und Vorrichtung zur Planung von Ressourcen
DE69710780T2 (de) Unabhängige, entfernte ein-/ausgabesteuervorrichtung
EP3332305B1 (de) Verfahren und vorrichtung zum bereitstellen eines taktes für eine elektronische schaltung und prozessorvorrichtung
DE112018003505T5 (de) Zugriffssteuereinrichtung
DE102007051201A1 (de) Koordinierte Dual-Interface-Kommunikation
DE102016219721A1 (de) Parallelisierungsverfahren, parallelisierungswerkzeug und fahrzeugverbaute einrichtung
DE102014105109A1 (de) Verfahren und Vorrichtung zum Erzeugen und Abarbeiten von Testfällen
DE102023104360A1 (de) Verfahren und Optimierungsagent zum Optimieren eines Systems mit mehreren neuronalen Netzen
DE102022209700A1 (de) Gerät mit ausschließlicher Zuordnung von Ressourcen an neuronale Netze
DE102017124105A1 (de) Verfahren zur Portierung einer Single-Core Steuerungssoftware auf ein Multi-Core Steuergerät oder zur Optimierung einer Multi-Core Steuerungssoftware
EP2780804B1 (de) Verfahren zur steuerung der programmausführung
DE102021117739B4 (de) Verwaltung von Zugriffen mehrerer Applikationen auf einen Datenspeicher

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22753614

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2022753614

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2022753614

Country of ref document: EP

Effective date: 20240402

WWE Wipo information: entry into national phase

Ref document number: 202280072334.2

Country of ref document: CN