EP1514180A2 - Reaktionszeit-beschränkung eines software-prozesses - Google Patents
Reaktionszeit-beschränkung eines software-prozessesInfo
- Publication number
- EP1514180A2 EP1514180A2 EP03739445A EP03739445A EP1514180A2 EP 1514180 A2 EP1514180 A2 EP 1514180A2 EP 03739445 A EP03739445 A EP 03739445A EP 03739445 A EP03739445 A EP 03739445A EP 1514180 A2 EP1514180 A2 EP 1514180A2
- Authority
- EP
- European Patent Office
- Prior art keywords
- software process
- result
- execution
- response time
- interrupt
- Prior art date
- Legal status (The legal status 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 status listed.)
- Withdrawn
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/4812—Task transfer initiation or dispatching by interrupt, e.g. masked
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0715—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a system implementing multitasking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
- G06F11/3419—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment by assessing time
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
- G06F11/348—Circuit details, i.e. tracer hardware
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
- G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0751—Error or fault detection not based on redundancy
- G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
- G06F11/0757—Error or fault detection not based on redundancy by exceeding limits by exceeding a time limit, i.e. time-out, e.g. watchdogs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0793—Remedial or corrective actions
Definitions
- the invention relates to a method and a device by means of which the reaction time of a software process is limited to a predetermined maximum reaction time.
- a software process is understood to be a process that is carried out by a data processing device and produces an end result.
- the data processing device is, for example, a workstation computer, a controller or a control device in a motor vehicle, it comprises at least one processor for executing program commands.
- Such a software process for example, calculates output signals as a function of input signals, activates or deactivates devices, generates an output on a peripheral device, e.g. B. a printer or a screen, or reads data from a file or from a data bus in a temporary memory of the process.
- a peripheral device e.g. B. a printer or a screen
- reads data from a file or from a data bus in a temporary memory of the process e.g. B.
- Such a software process causes a predefined reaction to a triggering event, for example the occurrence of a device error or a request for the immediate termination of all currently unimportant further software processes and other sequences on the data processing device.
- a triggering event for example the occurrence of a device error or a request for the immediate termination of all currently unimportant further software processes and other sequences on the data processing device.
- This sudden event mostly acts from the outside and suddenly on the data processing device.
- An example of an event that does not act from outside is a division by zero It is preferably responded to by an exception handling program, but not by an interrupt handling program.
- a software process triggered by an interrupt signal is referred to below as an interrupt handling program (interrupt program, "interrupt service routine", ISR).
- An interrupt handling program is typically assigned to each of the interrupt signals provided.
- the latency of a software process is understood to mean the time period between the event that triggers the software process and the start of the execution of the software process.
- the latency is the time between the arrival of the interrupt signal at the data processing device and the start of the interrupt handling program associated with the interrupt signal.
- the time between the start and end of the execution of the software process is called the execution time.
- the sum of latency and execution time is called the response time of the software process.
- Responsive systems are understood to be real-time capable systems which produce a result (“response”) after the predetermined maximum reaction time has elapsed.
- a method and a facility are desired in order to make a software process a component of a responsive system.
- DE 3243760 C2 discloses a device for monitoring a program run with the aid of a time monitoring device.
- the time monitoring device triggers a graduated reaction when a predetermined first time period has passed without a message from a processor about the complete processing of the program having arrived.
- a signal is generated that triggers an interruption in the execution of the program (software interrupt) and starts the program again or continues at a defined point.
- a hardware reset is triggered, which causes the program sequence to be restarted.
- the Processor switched inactive and / or an alarm is triggered.
- DE 4446286 Cl discloses a responsive and thus real-time capable and fault-tolerant system with function blocks.
- a maximum processing time is assigned to each function block.
- a module for scheduling (“timing module") determines the maximum response time of the system to an input signal. Even before starting up a system that is constructed with such function blocks, its maximum response time can be predicted.
- DE 4329872 AI discloses a monitoring device for a processor that executes a software program.
- the processor can be switched from active mode to a sleep mode and vice versa.
- the execution of the program is stopped after an interruption as a result of switching to the sleep mode and later switching to the active mode Continued from where execution was interrupted.
- the monitoring device sends an interrupt signal to the processor in order to switch it to the active mode.
- a trigger signal informs you of the continuation of the program execution. If the execution of the program has not ended after a predetermined period of time, the execution is aborted and the processor is restarted (“reset”). This monitoring device also cannot predict which result the program will produce if its execution is exceeded due to the Period is canceled.
- DE 3544079 C2 a method for processing interrupt signals is known, from DE 3544079 AI a computer with at least one predefined interrupt handling program (interrupt program). As soon as an interrupt signal is registered, the main program currently running is interrupted and the interrupt handling program is started instead. Further requests by additional interrupt signals are blocked for a defined period of time, i. H. other interrupt handling programs e.g. B. from the same source of interrupt signals cannot be executed in the defined period. After the time period has elapsed, the requests are unlocked by interrupt signals. A method with these steps is described in claim 1 of DE 3544079 C2. The blocking for a defined period of time is implemented in DE 3544079 C2 with the aid of a time counter which is started together with the interrupt handling program. According to one embodiment, it is provided that further requests are deleted by additional interrupt signals that arrive during the time period.
- interrupt program interrupt program
- US 5,257,357 discloses a data processing device with multiple modules that produce interrupt signals.
- a selection logic receives interrupt signals as input signals and can assign changed priorities to the interrupt signals, depending on the corresponding adaptation signals. Using this selection logic, a user can assign a higher priority to certain interrupt signals.
- a processing logic generates a vector of interrupt signals from the changed signals if necessary.
- B. is sent to a processor for execution of interrupt handling programs. This relieves the processor of having to identify interrupt signals itself and to differentiate or classify them in terms of their priorities. It is not disclosed how the processing of a first interrupt handling program with lower priority is continued when a second signal with higher priority arrives and therefore the first interrupt handling program is interrupted or aborted.
- DE 19927657 AI discloses a method to prevent the uncontrolled spread of software errors and to enable the execution of several software processes independently of one another on one processor.
- a program memory is divided into individual memory areas. Individual memory modules are permanently assigned to these memory areas; the assignment cannot be changed even in the event of an error.
- the program modules are assigned fixed maximum execution times, compliance with which is monitored. The running program cannot influence the time monitoring even in the event of an error. In the event of an error, an interrupt signal generated then triggers an emergency program (interrupt service routine) for error handling.
- the method disclosed in DE 19927657 AI requires fixed maximum processing times for the program modules to be predetermined and stored in an allocation table. This requires a good knowledge of the program modules, their mode of operation and the expected execution time.
- EP 0717361 A2 discloses a procedure for making the response time of an interrupt handling program predictable. A number of possible events are identified in advance that can delay the execution of an interrupt handler. With the help of two timers, two periodically recurring time intervals are realized: a first time interval in which the execution of an interrupt handling program can be delayed by events, and a second time interval in which the interrupt handling program is executed without interruption. During the second time interval, all incoming events that can delay execution are prevented and are only permitted again after the interrupt handling program has been completely executed.
- EP 0717361 A2 guarantees compliance with a maximum response time only in the second time interval, but not during the entire working time of the data processing device.
- all potentially delayed events must be identified in advance. This is associated with effort. If an event is overlooked If it occurs or occurs unexpectedly or in a different form or incompletely, the desired effect may not occur.
- No. 6,085,218 discloses a method for monitoring the execution time of a software process in a multi-process execution environment. Those execution periods in which a single processor executes the software process are counted. Their lengths depend on the cycle time of the processor. If the number of execution periods reaches a predetermined upper limit, it is preferred the execution of the software process is interrupted. The counting of the execution periods is interrupted if an interrupt signal triggers an interrupt handling program with higher priority. Preferably the number of execution periods reached is stored and the execution of the software process is continued, after the interrupt handling program has been completely executed.
- the invention is based on the object of ensuring that the software process ends at the latest after a predetermined reaction time and also produces a result in the event of an interruption which is useful despite the interruption. Furthermore, ensuring that little additional effort is required.
- the object is achieved by a method according to claim 1 and an apparatus according to claim 17 or claim 18.
- the invention guarantees that the execution of the software process is ended under all circumstances after the maximum response time. Even if the management of the software process is interrupted, it still produces a predictable and possibly the best possible end result.
- Real-time methods according to the state of the art often require complex calculations based on the worst case scenario (worst-case calculations). In addition to the effort for the necessary modeling and the calculations, it is disadvantageous that the guaranteed response time is often very long.
- the method according to the invention does not require worst case calculations. It is sufficient to determine the reaction times of the sub-processes if there are no interruptions.
- the invention guarantees a shorter response time within which the end result is achieved when the software process is fully executed or the result of the selected sub-process. The method is therefore suitable for responsive systems.
- Another advantage of the invention becomes apparent when the maximum response time has expired without the software process having been carried out completely to the end.
- methods according to the prior art either produce no result at all, continue execution at a later point in time or only start to produce an approximate result or an intermediate result at this point in time. This determination is time-consuming, and especially after the maximum reaction time has elapsed, there is hardly any computing time available.
- a timer for monitoring the maximum response time continues to run. If the maximum response time of the software process is exceeded as a result of the execution of the interrupt handling program, the result of the sub-process selected according to the invention is automatically used as the end result without special treatment. This interrupt handling does not need to be considered when implementing the software process.
- the response time of the interrupt handling program is not added to the response time of the software process if the interrupt handling program has a higher priority than the software process.
- a timer for monitoring the maximum response time is stopped. In this case the maximum response time of the software process can be exceeded. This is permitted in some applications.
- Another advantage of the invention is that these two different behaviors, namely termination or continuation when the time is exceeded due to an accident, can simply be Interrupt treatment program, can be configured very easily, namely z. B. by appropriate configuration of the monitoring timer.
- the end result is, for example, iterative, i. H. gradually, provided by the software process (claim 5).
- Each sub-process produces an approximate result for the end result.
- the subprocess that was the last to be completely executed before the termination is selected.
- the approximate result of this sub-process is used as the end result of the software process in the event of termination.
- the approximate result of each sub-process differs from the end result by at most a predetermined limit, e.g. B. 1 mm, and each approximate result is closer to the final result than the previous one.
- a predetermined limit e.g. B. 1 mm
- each process preferably uses the result of the previously executed subprocess, that is to say the predecessor subprocess, as the input value.
- the subprocess preferably produces a better approximation result than the predecessor subprocess, i. H. one with less deviation from the end result.
- the calculated approximation results are stored in succession in the same memory (claim 6). An approximation result overwrites that of the previously calculated approximation result. After an abort, this memory is read out and its content is used as the end result (claim 20).
- This configuration is fault tolerant, e.g. B. against sudden failures of a processor that executes the subprocesses and requires only a single additional memory.
- a standard value for the end result of the software process is preferably determined in advance or a quick value to be carried out rendering action, e.g. B. switching off devices or terminating other software processes.
- This default value is, for example, a constant or a value which can be calculated quickly and which depends on a parameter determined before the start of the software process.
- the standard value can be a preferred value, a starting value for an iteration or a sensible presetting.
- a standard value determination subprocess comprises triggering the action to be carried out quickly or determining this standard value, for example by quickly calculating or reading out a memory in which the constant is stored.
- this standard value determination subprocess is the first This embodiment has the advantage that, as a rule, a result of a sub-process is obtained very quickly, namely when the determination of the standard value or triggering of the action requires little time compared to the execution time of other sub-processes at a very early early termination of the software process yielded a good end result.
- This configuration is particularly advantageous if, in addition to the maximum reaction time, a maximum emergency reaction time is also specified. While the maximum response time is the period of time until the software process is fully executed, the maximum emergency response time describes the latency plus the period of time in which at least one first emergency response is completed.
- the sub-process of determining the standard value is preferably defined as an emergency reaction in such a way that it is completed within the maximum emergency reaction time.
- the embodiment according to claim 11, however, provides that the first sub-process is executed when the software process is terminated because the maximum response time has almost passed.
- the termination is carried out in time so that the first subprocess can be carried out after the termination.
- the first delivers Subprocess the default value that is used as the end result of the software process.
- Compliance with the maximum response time can be monitored with hardware or software.
- at least one hardware component is used (claim 2), e.g. B. uses a realizable by simple hardware components timer (claim 21).
- the invention then has the additional advantage that the monitoring requires little additional hardware.
- the implementation by hardware is the preferred way to ensure that the entire response time is actually monitored and limited and not just the execution time.
- the period begins with the arrival of a signal that triggers the software process, e.g. B. an interrupt signal.
- a signal that triggers the software process e.g. B. an interrupt signal.
- the response time is monitored with the aid of commands from an operating system, a certain time delay passes until the operating system has registered the request for triggering the software process and has added it to its list of priorities. This time delay cannot be monitored and therefore taken into account and limited.
- the triggered software process only starts the time span, only the execution time, but not the latency, can be monitored and limited.
- the latency can e.g. B. can be unpredictably long due to the appearance of other software processes with higher priority.
- FIG. 1 shows the structure of an engine control unit that calculates the ignition timing
- Fig. 2. the structure of a monitoring device for interrupt handling.
- the invention is first explained using the example of an engine control unit 10.
- This engine control unit 10 calculates the time of the ignition again during each revolution, that is to say during each complete work cycle of the engine. Choosing the right ignition point lowers gasoline consumption and pollutant emissions. The correct ignition timing thus carries u. U. to meet legal requirements with regard to environmental compatibility, and increases the economy of the motor vehicle and thus the competitiveness of the manufacturer.
- Prior art methods only recalculate the ignition timing during each revolution up to a specific, predetermined engine speed. If the engine speed rises above the specified limit, the ignition timing is only recalculated every second revolution. The last calculated value is reused for the intermediate revolutions. This will u. The optimal ignition timing may not have been met. If the limit for the engine speed is too low, a new calculation is not carried out, although computing time is still available. If an excessively large limit is specified, the calculation must u. U. canceled because computing time is no longer available.
- Fig. 1 shows a structure of an engine control device 10 in which the invention is applied.
- the engine control unit 10 includes an execution processor 20 which, among other things, determines the ignition timing again during each revolution.
- the calculation of the ignition timing essentially consists in the fact that a calculation program is executed.
- the executing software process thus includes the execution of this calculation program. gramms.
- the calculation program is stored in a first program memory 40 for calculation programs.
- the engine control unit 10 also includes a result memory 70, which is a data memory in which the end result, that is to say the calculated ignition timing, is stored.
- This result memory 70 is divided into two partial data memories.
- the calculated end result is stored in the first partial data memory 71.
- the end result of the calculation during the previous revolution, that is to say the last ignition point used, is stored in the second data sub-memory 72.
- the execution processor 20 executes the subprocesses one after the other. Each sub-process produces a result after its execution. The execution processor 20 writes this result in the first partial data memory 71, a previously stored result preferably being overwritten.
- the execution processor 20 preferably determines the correct ignition timing iteratively, ie step by step.
- the first subprocess calculate a starting value for the iteration. This starting value is e.g. B. a generally valid preferred value or the end result of the previous calculation, ie the last ignition point.
- Each calculation step is a sub-process of the software process. The calculation steps and thus the sub-processes are carried out one after the other. Each calculation step produces a result that is more precise than the result of the previous calculation step. For the execution of a calculation step - except for that of the first calculation step - the result of the previous calculation step is preferably used.
- the starting value calculated by the first subprocess can be used as an input variable. In Fig.
- first program memory 40 for calculation programs a first program partial memory 41 for the first partial process, by means of which the starting value is calculated, and a second program partial memory 42 for the calculation step, which is carried out several times, are shown.
- the result of each calculation step is stored in the first partial data memory 71.
- the software process itself comprises an abort criterion, e.g. B. Number of calculation steps.
- the end result namely the ignition point
- the result memory 70 is used for subsequent work steps of the engine control unit 10.
- These subsequent work steps and the devices for them are not shown in FIG. 1.
- the execution of the software process always completely takes up the predetermined reaction time and is only interrupted by the monitoring device 30 in the manner described below.
- the monitoring device 30 ensures that the predetermined reaction time is observed.
- the monitoring device comprises a timer.
- a counter of the timing element is set to a predefined value.
- the start of the latency is e.g. B. the time at which the engine control unit 10 generates the command to calculate the ignition timing.
- the predefined value is preferably inversely proportional to the engine speed.
- the z. B. generates a system clock 200 of the engine control unit 10, the counter is reduced by a value of 1.
- the work of the timer is interrupted as soon as the execution of the software process has been completed and the calculated end result has been stored in the first partial data memory.
- the export Processor 20 sends a corresponding end signal to the monitoring device.
- the monitoring device triggers an interrupt treatment when the counter reaches the value 0. To do this, calls an interrupt handling program, which is stored in a second program memory 50 for interrupt handling programs.
- This interrupt treatment program preferably first decides how the value now used as the ignition point is calculated. For this, a decision is preferably made between the following alternatives:
- the result of the subprocess that was carried out last is used as the current ignition point. This result is stored in the first partial data memory 71 of the result memory 70.
- the previous ignition timing is determined and reused as the current ignition timing.
- a preferred value for the ignition timing is determined and used as the current ignition timing.
- the execution processor 20 transmits an intermediate signal to the monitoring device, as soon as he has executed a predetermined number of sub-processes and has saved the result of the sub-process executed as the last in the first data sub-memory 71.
- the intermediate signal is transmitted as soon as the execution processor 20 has executed the first partial process and stored the starting value in the first data partial memory 71 or as soon as it has executed the third partial process and thus calculated the starting value and then carried out two calculation steps.
- this intermediate signal arrives at the monitoring device before the interruption treatment has been started, the result stored in the first data sub-memory 71 is used as the end result, i.e. as the current ignition point, otherwise the result stored in the second data sub-memory 72, i.e. the previous ignition timing.
- the intermediate signal is not present, a decision is made as to whether the previous ignition point is to be reused or a preferred value is instead determined and used as the current ignition point. This decision can depend on whether there have been significant environmental conditions, e.g. B. have changed the engine speed or not.
- the software process whose response time is limited is itself an interrupt service routine (Interrupt Service Routine) that is assigned to a predefined interrupt signal type (interrupt request).
- the interrupt signal type is one of M predefined interrupt signal types, where M is a natural number.
- the M interrupt signal types are preferably distinguished from one another by the identifier.
- One of M interrupt handling programs is also assigned to each interrupt signal type. An interrupt signal of the same type can arrive several times at different times.
- Each interrupt handling program preferably comprises a standard value determination subprocess, which determines a standard value as described above or triggers an action to be carried out quickly.
- a maximum emergency response time is preferably additionally specified for each interrupt treatment program.
- the standard value determination subprocess is designed so that it can be carried out within the maximum emergency response time.
- a minimum repetition time or a maximum repetition frequency are preferably specified for each interrupt handling program. The minimum repetition time is the reciprocal of the maximum repetition frequency.
- UBP_1, ..., UBP_M be the M predefined interrupt handling programs.
- NRZ (UBP_1) / WZ (UBP_1) + ... + NRZ (UBP_N) / WZ (UBPJST) must not exceed a predetermined upper limit. This limit often has the value T * In 2, In denotes the natural logarithm.
- T preferably denotes the total available computing time of the processor. It is also possible to use T itself as the upper barrier.
- Each interrupt handler program therefore has one of N priorities.
- the assigned priority preferably depends on the meaning of the interrupt handling program and the maximum emergency response time - the lower the maximum emergency response time, the higher the priority.
- a further development of the embodiment provides for assigning different priorities to individual sub-processes of an interruption treatment program.
- Receive necessary subprocesses e.g. B. the priority of the interrupt signal, other sub-processes a lower priority.
- the interrupt handling programs are divided into sub-processes according to the invention.
- One of these is the standard value determination subprocess.
- the individual sub-processes are preferably defined in such a way that their execution cannot be interrupted or interrupted by interrupt signals.
- FIG. 2 shows an example of the structure of a monitoring device 30 that limits the response time of interrupt handling programs.
- the interrupt handling programs are executed by an execution processor 20.
- the execution processor 20 has read access to at least one program memory 50 ' for the interrupt handling programs.
- the interrupt handling programs are in turn subdivided into sub-processes according to the invention, which are preferably executed one after the other.
- the source program for each sub-process is stored in a separate program sub-memory so that sub-processes cannot overwrite program sub-memories or data memories of other sub-processes.
- the result of each sub-process is saved by the Processor as described above in a result memory 70, which is not shown in Fig. 2.
- This monitoring device 30 also controls the chronological order in which the incoming interrupt signals are processed. It preferably comprises an interrupt request processor 100, a memory 110 for interrupt signals, M blocking timers 130 and M response time timers 140. All 2 * M timers are connected to the interrupt signal processor 100; only the connection between the interrupt signal processor 100 and two timers is shown in FIG.
- a blocking timer 130 and a response time timer 140 are provided for each of the M interrupt signal types. These 2 * M timers preferably operate as described above. Up to 2 * M different time periods can be specified and can be changed by simply changing a timer.
- the blocking timer 130. i for the interrupt signal type i blocks the execution of an interrupt signal of the type i for a predefined blocking time and thus ensures that two interrupt signals of the same type are processed at most with a predetermined repetition frequency, but not more often. In other words, it is ensured that between two calls to the interrupt handling program for type i, at least one predetermined repetition time elapses as the blocking time.
- the reciprocal value is the maximum repetition frequency.
- the blocking timer 130. i is either in the “lock_save” state or in the “lock_nignify” state, otherwise in the “let through” state.
- the three states are, for example, with the aid of a counter and an additional 1-bit register
- the counter is converted to one of the states “lock_save” or “lock ren_ignor Schl "is set to a predefined value greater than 0 and is reduced by 1 in each case in a system cycle specified by a system clock 200. If the counter assumes the value 0, the blocking timer 130.i is in the” let through “state.
- the 1-bit register distinguishes between the states "lock_save” or "lock_ignore”.
- the response time timer 140. i for the interrupt signal type i limits the latency plus the execution time of an interrupt signal type i to a predefined maximum response time. If the execution processor 20 executes the interrupt handling program assigned to type i and the predetermined time period for the reaction time has not yet elapsed, the reaction time timer 140. i is in the “active” state, otherwise in the “inactive” state.
- the interrupt signal processor 100 preferably comprises a priority memory 120, in which the highest priority of all interrupt handling programs that the execution processor 20 is currently executing is stored.
- the interrupt signal processor 100 identifies the type of this interrupt signal and the priority assigned to the type and carries out at least one of the following steps:
- the interrupt signal processor 100 makes the following case distinctions:
- the blocking timer 130. i for the type i is in the “block_save” state, it stores the type i identified by the identifier and the time of arrival of the interrupt signal in the interrupt signal memory 110.
- the interrupt signal processor 100 determines by read access to the priority memory 120 whether the execution processor 20 is currently executing an interrupt handling program that has a priority that is higher than or equal to type I. If this is the case, it in turn stores the identifier and the time of arrival in the interrupt signal memory 110. Otherwise, it forwards the interrupt signal to the execution processor 20. This executes this associated interrupt handling program for type i.
- the interrupt signal processor 100 forwards the interrupt signal, it causes the execution processor 20 to interrupt all interrupt handling programs with a lower priority and to do so first for type i.
- Interrupt signal processor 100 continues to update the two timers for type i and priority memory 120 as needed.
- the interruption signal of type i arrives, it puts the blocking timer 130. i for the type i in the "block_ignore” state.
- the blocking timer 130. i starts measuring the specified blocking time.
- the execution processor 20 then sends When it starts executing the interrupt handling program for type i, a corresponding signal is sent to the interrupt signal processor 100.
- the processor then transfers the blocking timer 130.i for the type i from the "lock_ignore" state to the "lock_store” state ".
- the specified blocking time which is monitored by the blocking timer 130.i, it is transferred from the state" block_save “to the state” let through ". If the blocking time expires before the execution of the interrupt handling program has started, this becomes Lock timer 130.
- the interrupt signal processor 100 continues to bring the response time timer 140. i into the “active” state immediately after the arrival of the interrupt signal.
- the response time timer 140. i then begins to monitor the response time. If the execution processor 20 is within the predetermined range maximum response time, the interrupt handling program completely executes, it sends a corresponding signal to the interrupt signal processor 100. This transfers the response time timer 140. i for the type i into the "inactive" mode. If the timer registers that the specified maximum reaction time has expired and that it is still in the "active” state, it then sends a corresponding signal to the interrupt signal processor 100. The processor then changes it to the “inactive” state and sends a corresponding signal to the execution processor 20.
- the execution processor 20 then terminates the execution of the interrupt handling program for type i and begins a predefined interrupt treatment after termination
- the execution processor 20 preferably reads for this purpose a program memory 150 for termination treatments, which, as described above, can consist of determining a preferred value or the result of the last executed subprocess , which is stored in the result memory 70, to be used as the end result of the interrupt handling program for type i.
- the interrupt signal processor 100 updates the priority memory 120 and selects the one with the highest priority from the interrupt signals stored in the interrupt signal memory 110.
- the one with the earliest arrival time is selected from among several with the same priority.
- the entry for the selected interrupt signal is removed from interrupt signal memory 110 and the decisions and operations described above are performed for the selected interrupt signal.
- the interrupt signal is forwarded to the execution processor 20 or stored again in the interrupt signal memory 110. The latter can occur in particular when a higher priority interrupt signal is processed. If necessary, the states of the two assigned timers are updated.
- the interrupt signal processor 100 can be configured in two different ways: If the execution of an interrupt handling program is interrupted because a higher priority interrupt signal is preferred. is acted, either the response time timer 140. i is stopped, or it continues to run. In the first case, the response time of the interrupt handling program is extended for the duration of the further interrupt handling program of higher priority, in the second case not. In the first case, the interrupt signal processor 100 interrupts the work of the response time timer 140. i, in the second case it does not. This makes it easy to switch between these two ways of working.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Debugging And Monitoring (AREA)
Abstract
Die Erfindung betrifft ein Verfahren und eine Vorrichtung, durch welche die Reaktonszeit eines Software-Prozesses auf eine vorgegebene maximale Reaktionszeit beschränkt wird. Unter Reaktonszeit wird die Summe aus Latenszzeit (Zeitspanne zwischen auslösendem Ereignis und Start des Prozesses) und Ausführungszeit verstanden. Der Software-Prozeβ ist beispielsweise ein Unterbrechungsbehandlungs-Programm, das durch ein Unterbrechungssignal (Interrupt) ausgelöst wird. Erfindungsgemäβ ist der Software-Prozeβ in mehrere Teilprozesse unterteilt, die jeweils ein Ergebnis liefern. Wird der Software-Prozeβ abgebrochen, weil die maximale Reaktonszeit erreicht ist, so wird als Endergebnis des Prozesses das Ergebnis eines zuvor ausgewählten Teilprozesses verwendet. Dieser Teilprozeβ ist beispielsweise der als letzter vollständig ausgeführte.
Description
Reaktionszeit-Beschränkung eines Software-Prozesses
Die Erfindung betrifft ein Verfahren und eine Vorrichtung, durch welche die Reaktionszeit eines Software-Prozesses auf eine vorgegebene maximale Reaktionszeit beschränkt wird.
Unter einem Software-Prozeß wird ein Vorgang verstanden, der von einer datenverarbeitenden Vorrichtung ausgeführt wird und ein Endergebnis erbringt. Die datenverarbeitende Vorrichtung ist beispielsweise ein Arbeitsplatzrechner, ein Regler oder ein Steuergerät in einem Kraftfahrzeug, sie umfaßt mindestens einen Prozessor zur Ausführung von Programmbefehlen. Ein solcher Software-Prozeß berechnet beispielsweise Ausgangssignale in Abhängigkeit von Eingangssignalen, aktiviert oder deaktiviert Geräte, erzeugt eine Ausgabe auf einem Peripheriegerät, z. B. einem Drucker oder einen Bildschirm, oder liest Daten aus einer Datei oder von einem Datenbus in einen temporären Speicher des Prozesses ein. Beim Ablauf eines Software- Programms werden oft mehrere Software-Prozesse gestartet. Der Software-Prozeß kann gemeinsam mit anderen Software-Prozessen in einem mehrprozeßfähigen Betriebssystem, z. B. UNIX, und/oder einer mehrprozeßfähigen AbiaufUmgebung, z. B. Java, ausgeführt werden. Eine solche Abarbeitung mehrerer Prozesse wird oft als „preemptive multi-tasking" bezeichnet. Manche derartigen Software-Prozesse heißen dann „processes", andere „threads". Als Oberbegriff für „processes" und „threads" wird manchmal „tasks" verwendet. Der Begriff „Software-Prozeß" umfaßt im folgenden „processes", „threads" und „tasks".
Eine besondere Art von Software-Prozessen wird durch bestimmte Unterbrechungssignale, oft „interrupt reguests", IRQs oder kurz Interrupts genannt, ausgelöst. Ein solcher Software- Prozeß bewirkt eine vordefinierte Reaktion auf ein auslösendes Ereignis, z. B. Auftreten eines Gerätefehlers oder eine Anforderung zum sofortigen Abbruch aller aktuell unwichtigen weiteren Software-Prozesse und sonstigen Abläufe auf der datenverarbeitenden Vorrichtung. Dieses plötzliche Ereignis wirkt meistens von außen und plötzlich auf die datenverarbeitende Vorrichtung ein. Ein Beispiel für ein Ereignis, das nicht von außen einwirkt, ist eine Division durch Null - auf sie wird bevorzugt durch ein Ausnahmebehandlungs- , aber nicht durch ein Unterbrechungsbehandlungs-Programm reagiert. Ein durch ein Unterbrechungssignal ausgelöster Software-Prozeß wird im folgenden als Unterbrechungsbehandlungs-Programm (Interrupt-Programm, „interrupt Service routine", ISR) bezeichnet. Typischerweise ist jedem der vorgesehenen Unterbrechungssignale ein Unterbrechungsbehandlungs-Programm zugeordnet .
Unter der Latenzzeit eines Software-Prozesses wird die Zeitspanne verstanden, die zwischen dem Ereignis, das den Software-Prozeß auslöst, und dem Beginn der Ausführung des Software-Prozesses verstanden. Im Falle eines Unterbrechungsbehandlungs-Programms ist die Latenzzeit die Zeitspanne zwischen Eintreffen des Unterbrechungssignals bei der datenverarbeitenden Vorrichtung und dem Start des Unterbrechungsbehandlungs-Programms, das dem Unterbrechungssignal zugeordnet ist. Die Zeitspanne zwischen Beginn und Ende der Ausführung des Software-Prozesses wird als Ausführungszeit bezeichnet. Die Summe aus Latenzzeit und Ausführungszeit wird als Reaktionszeit des Software-Prozesses bezeichnet. Bei bekannter Arbeitsgeschwindigkeit der datenverarbeitenden Vorrichtung und Aufbau des Software-Prozesses läßt sich eine obere Schranke für die Reaktionszeit des Prozesses für den Fall angeben, daß die Ausführung nicht z. B. durch unvorhergesehene Ereignisse unterbrochen wird.
Jedoch ist in der Praxis jederzeit mit derartigen Ereignissen zu rechnen, die bei bekannten Vorrichtungen und Verfahren die Reaktionszeit in nicht vorhersehbarer Weise verlängern oder dazu führen, daß der Software-Prozeß ohne Ergebnis abgebrochen wird. Insbesondere bei sicherheitskritischen Anwendungen, z. B. in Verkehrsmitteln oder bei der Überwachung von Fertigungsprozessen, wird verlangt, daß die datenverarbeitende Vorrichtung bestimmte Software-Prozesse in Echtzeit („real-time") ausführen kann. Diese Anforderung bedeutet, daß die Reaktionszeit eines Software-Prozesses eine vorgegebene obere Schranke auch dann nicht übersteigt, wenn unvorhergesehene Ereignisse auftreten. Diese vorgegebene obere Schranke wird im folgenden als maximale Reaktionszeit bezeichnet. Die Einhaltung der maximalen Reaktionszeit ist insbesondere dann wichtig, wenn der Software-Prozeß ein Unterbrechungsbehandlungs-Programm ist, mit dem auf ein Unterbrechungssignal als Folge eines sicherheitskritischen plötzlich aufgetretenen Ereignisses reagiert wird.
Unter responsiven Systemen werden echtzeitf hige Systeme verstanden, die nach Ablauf der vorgegebenen maximalen Reaktionszeit ein Ergebnis („response") erbringen. Gewünscht werden insbesondere ein Verfahren und eine Einrichtung, um einen Software-Prozeß zu einem Bestandteil eines responsiven Systems zu machen.
Aus DE 3243760 C2 ist eine Einrichtung zur Überwachung eines Programmlaufs mit Hilfe einer Zeitüberwachungseinrichtung bekannt . Die Zeitüberwachungseinrichtung löst eine abgestufte Reaktion aus, wenn eine vorgegebene erste Zeitspanne verstrichen ist, ohne daß eine Meldung von einem Prozessor über die vollständige Abarbeitung des Programms eingetroffen ist. Zuerst wird ein Signal generiert, das eine Unterbrechung der Ausführung des Programms (Software-Interrupt) auslöst und das Programm erneut startet oder an einer definierten Stelle fortsetzt. Nach Ablauf einer zweiten Zeitspanne wird ein Hardware-Reset ausgelöst, der einen Neustart des Programmablaufs bewirkt. Nach Ablauf einer dritten Zeitspanne wird der
Prozessor inaktiv geschaltet, und/oder ein Alarm wird ausgelöst .
In DE 3243760 C2 wird nicht offenbart, welches Ergebnis das Programm nach Auslösen einer der möglichen abgestuften Reaktionen erbringt. Wird ein Neustart ausgelöst, so liefert der abgebrochene Programmlauf überhaupt kein definiertes Ergebnis. Möglich ist, daß die Abarbeitung an einer definierten Stelle des Programms fortgesetzt wird. Bei dieser Ausgestaltung kann keine maximale Reaktionszeit des Programms garantiert werden.
In DE 4446286 Cl wird ein responsives und damit echtzeitfähi- ges und fehlertolerantes System mit Funktionsbausteinen offenbart. Jedem Funktionsbaustein ist eine maximale Bearbeitungszeit zugeordnet. Ein Modul für zeitliche Planung („Ti- ming-Modul") bestimmt die maximale Reaktionszeit des Systems auf ein Eingangssignal. Bereits vor Inbetriebnahme eines Systems, das mit derartigen Funktionsbausteinen aufgebaut ist, läßt sich dessen maximale Reaktionszeit vorhersagen.
Nicht offenbart wird in DE 4446286 Cl, wie die Einhaltung dieser Reaktionszeit auch im Fall von Störungen und sonstigen unvorhergesehenen Ereignissen eingehalten wird. Solche Ereignisse, z. B. Ausfall eines Prozesses, können nämlich dazu führen, daß ein Funktionsbaustein nicht wie spezifiziert binnen der zugeordneten maximalen Bearbeitungszeit ein Ergebnis liefert und andere Funktionsbausteine, die dieses Ergebnis benötigen, ihre Arbeit nicht beginnen -können. Aber gerade sicherheitskritische Systeme müssen auch bei einem Ausfall binnen einer vorgegebenen Reaktionszeit ein brauchbares Ergebnis liefern.
In DE 4329872 AI wird eine Überwachungseinrichtung für einen Prozessor, der ein Software-Programm ausführt, offenbart. Der Prozessor kann vom Aktiv-Modus in einen Ruhe-Modus und umgekehrt umgeschaltet werden. Die Ausführung des Programms wird nach einer Unterbrechung infolge Umschaltens in den Ruhe- Modus und späterer Umschaltung in den Aktiv-Modus an der
Stelle fortgesetzt, an der die Ausführung unterbrochen wurde. Die Überwachungseinrichtung sendet ein Unterbrechungssignal an den Prozessor, um diesen in den Aktiv-Modus umzuschalten. Sie wird durch ein Trigger-Signal über die Fortsetzung der Programm-Ausführung informiert. Falls die Ausführung des Programms nicht nach einer vorgegebenen Zeitspanne beendet ist, wird die Ausführung abgebrochen und der Prozessor erneut gestartet („Reset") . Auch durch diese Überwachungseinrichtung kann nicht vorhergesagt werden, welches Ergebnis das Programm dann erbringt, wenn dessen Ausführung infolge Überschreitens der Zeitspanne abgebrochen wird.
Aus DE 3544079 C2 ist ein Verfahren zur Verarbeitung von Unterbrechungssignalen bekannt, aus DE 3544079 AI ein Rechner mit mindestens einem vordefinierten Unterbrechungsbehandlungs-Programm (Interrupt-Programm) . Sobald ein Unterbrechungssignal registriert wird, wird das gerade ablaufende Hauptprogramm unterbrochen und statt dessen das Unterbrechungsbehandlungs-Programm gestartet. Weitere Anforderungen durch zusätzliche Unterbrechungssignale werden für eine definierte Zeitspanne gesperrt, d. h. weitere Unterbrechungsbehandlungs-Programme z. B. von derselben Quelle von Unterbrechungssignalen können im definierten Zeitraum nicht ausgeführt werden. Nach Ablauf der Zeitspanne wird die Sperrung der Anforderungen durch Unterbrechungssignale aufgehoben. Ein Verfahren mit diesen Schritten wird im Anspruch 1 von DE 3544079 C2 beschrieben. Die Sperrung für eine definierte Zeitspanne wird in DE 3544079 C2 mit Hilfe eines Zeitzählers realisiert, der gemeinsam mit dem Unterbrechungsbehandlungs- Programm gestartet wird. Gemäß einer Ausgestaltung ist vorgesehen, daß weitere Anforderungen durch zusätzliche Unterbrechungssignale, die während der Zeitspanne eintreffen, gelöscht werden.
Durch das in DE 3544079 C2 offenbarte Verfahren wird sichergestellt, daß in der vorgegebenen Zeitspanne kein weiteres Unterbrechungssignal dazu führen kann, daß die Ausführung des Unterbrechungsbehandlungs-Programms unterbrochen oder verzö-
gert wird. Nicht sichergestellt werden kann aber, daß das Unterbrechungsbehandlungs-Programm nach Ablauf der Zeitspanne mit einem brauchbaren Ergebnis beendet wird.
In US 5,257,357 wird eine datenverarbeitende Vorrichtung mit mehreren Modulen offenbart, die Unterbrechungssignale produzieren. Eine Auswahllogik erhält Unterbrechungssignale als Eingangssignale und vermag den Unterbrechungssignalen geänderte Prioritäten zuzuordnen, und zwar in Abhängigkeit von entsprechenden Anpassungs-Signalen. Ein Benutzer kann mit Hilfe dieser Auswahllogik bestimmten Unterbrechungssignalen eine höhere Priorität zuordnen. Eine Verarbeitungslogik erzeugt aus den bei Bedarf veränderten Signalen einen Vektor von Unterbrechungssignalen, der z. B. an einen Prozessor zur Ausführung von Unterbrechungsbehandlungs-Programmen gesandt wird. Dadurch wird der Prozessor davon entlastet, selber Unterbrechungssignale zu identifizieren und hinsichtlich ihrer Prioritäten zu unterscheiden oder zu klassifizieren. Nicht offengelegt wird, wie die Bearbeitung eines ersten Unterbrechungsbehandlungs-Programms mit niedrigerer Priorität fortgesetzt wird, wenn ein zweites Signal mit höherer Priorität eintrifft und deswegen das erste Unterbrechungsbehandlungs- Programm unterbrochen oder abgebrochen wird.
In DE 19927657 AI wird ein Verfahren offenbart, um die unkontrollierte Ausbreitung von Softwarefehlern zu verhindern und den Ablauf mehrerer Software-Prozesse unabhängig voneinander auf einem Prozessor zu ermöglichen. Gemäß dem offenbarten Verfahren wird ein Programmspeicher in einzelne Speicherbereiche unterteilt. Diesen Speicherbereichen werden fest einzelne Speichermodule zugeordnet, die Zuordnung läßt sich auch im Fehlerfall nicht ändern. Den Programm-Modulen werden feste maximale Ausführungszeiten zugeordnet, deren Einhaltung überwacht wird. Das laufende Programm kann weiterhin die Zeit- überwachung auch im Fehlerfall nicht beeinflussen. Im Fehlerfall löst ein dann erzeugtes Unterbrechungssignal ein Notprogramm (Interrupt Service Routine) für die Fehlerbehandlung aus .
Das in DE 19927657 AI offenbarte Verfahren erfordert, feste maximale Verarbeitungszeiten für die Programm-Module vorab festzulegen und in einer Zuordnungstabelle abzuspeichern. Dies erfordert eine gute Kenntnis der Programm- odule, ihrer Wirkungsweise und der zu erwartenden Ausführungszeit. Weiterhin sind zusätzliche Speicher- und Rechenkapazitäten für die Zuordnungstabelle und deren Auswertung bereitzustellen. Offenbart wird weiterhin eine Reaktion auf das Auftreten eines internen Fehlers im Software-Prozeß, z. B. auf ein Überschreiten eines verfügbaren Speicherbereichs, auf eine Endlosschleife oder auf eine Division durch 0. Hingegen wird nicht offenbart, wie die Reaktionszeit des Software-Prozesses beim Auftreten äußerer Ereignisse, also solchen, die nicht durch die Ausführung des Software-Prozesses selber verursacht werden, eingehalten wird.
In EP 0717361 A2 wird eine Vorgehensweise offenbart, um die Reaktionszeit eines Unterbrechungsbehandlungs-Programms vorhersagbar zu machen. Eine Menge von möglichen Ereignissen wird vorab identifiziert, welche die Ausführung eines Unterbrechungsbehandlungs-Programms verzögern können. Mit Hilfe von zwei Zeitgliedern werden zwei periodisch wiederkehrende Zeitintervalle realisiert: ein erstes Zeitintervall, in dem die Ausführung eines Unterbrechungsbehandlungs-Programms durch Ereignisse verzögert werden kann, und ein zweites Zeitinterwall, in der das Unterbrechungsbehandlungs-Programm unterbrechungsfrei ausgeführt wird. Während des zweiten Zeitin- tervalls werden alle eintreffenden Ereignisse, welche die Ausführung verzögern können, unterbunden und erst nach vollständiger Ausführung des Unterbrechungsbehandlungs-Programms wieder zugelassen.
Die in EP 0717361 A2 offenbarte Vorgehensweise garantiert die Einhaltung einer maximalen Reaktionszeit nur im zweiten Zeitintervall, nicht aber während der gesamten Arbeitszeit der datenverarbeitenden Vorrichtung. Außerdem müssen vorab alle möglicherweise verzögernden Ereignisse identifiziert werden. Dies ist mit Aufwand verbunden. Falls ein Ereignis übersehen
wird oder unvorhergesehen oder in abweichender Form oder unvollständig auftritt, tritt der gewünschte Effekt möglicherweise nicht ein.
In US 6,085,218 wird ein Verfahren offenbart, um in einer Mehrprozeß-Ablaufumgebung die Ausfuhrungszeit eines Software- Prozesses zu überwachen. Diejenigen Ausführungs-Zeitspannen („execution cycles") , in denen ein einzelner Prozessor den Software-Prozeß ausführt, werden gezählt. Deren Längen hängen von der Taktzeit des Prozessors ab. Wenn die Anzahl der Ausfuhrungs-Zeitspannen eine vorgegeben obere Schranke erreicht, wird vorzugsweise die Ausführung des Software-Prozesses abgebrochen. Die Zählung der Ausfuhrungs-Zeitspannen wird unterbrochen, wenn ein Unterbrechungssignal ein Unterbrechungsbehandlungs-Programm mit höherer Priorität auslöst. Vorzugsweise wird die erreichte Anzahl von Ausfuhrungs-Zeitspannen gespeichert, und die Ausführung des Software-Prozesses wird fortgesetzt, nachdem das Unterbrechungsbehandlungs-Programm vollständig ausgeführt wurde.
Nicht offenbart wird in US 6,085,218, mit welchem Resultat des Software-Prozesses gearbeitet wird, wenn dessen Ausführung z. B. wegen Erreichens der vorgegebenen oberen Schranke abgebrochen wird. Es bleibt nur der Ausweg, ohne ein Resultat des Software-Prozesses zu arbeiten, was oft unbefriedigend ist oder zu nicht vorhersagbaren Ergebnissen eines übergeordneten Software-Systems führen kann.
Der Erfindung liegt die Aufgabe zugrunde sicherzustellen, daß der Software-Prozeß spätestens nach einer vorgegebenen Reaktionszeit endet und auch bei einem Abbruch ein Ergebnis erbringt, das trotz des Abbruchs brauchbar ist. Weiterhin soll die Sicherstellung wenig zusätzlichen Aufwand erfordern.
Die Aufgabe wird durch ein Verfahren nach Anspruch 1 und eine Vorrichtung nach Anspruch 17 oder Anspruch 18 gelöst.
Durch die Erfindung wird garantiert, daß die Ausführung des Software-Prozesses unter allen Umständen nach Ablauf der maximalen Reaktionszeit beendet ist. Auch dann, wenn die Aus-
führung des Software-Prozesses abgebrochen wird, erbringt er noch ein vorhersagbares und unter den Umständen bestmögliches Endergebnis .
Echtzeitfähige Verfahren nach dem Stand der Technik erfordern oft aufwendige Berechnungen, bei denen vom ungünstigsten Fall ausgegangen wird (Worst-Case-Berechnungen) . Neben dem Aufwand für die erforderliche Modellbildung und die Berechnungen ist hierbei von Nachteil, daß die garantierte Reaktionszeit oft sehr hoch ist. Das erfindungsgemäße Verfahren erfordert keine Worst-Case-Berechnungen. Es genügt, die Reaktionszeiten der Teilprozesse beim Ausbleiben von Unterbrechungen zu bestimmen. Die Erfindung garantiert eine kürzere Reaktionszeit, innerhalb derer das Endergebnis bei vollständiger Ausführung des Software-Prozesses oder das Ergebnis des ausgewählten Teilprozesses erbracht wird. Deshalb ist das Verfahren für responsive Systeme geeignet.
Weiterhin ist es dank der Erfindung nicht erforderlich, eigens zur Einhaltung der vorgegebenen maximalen Reaktionszeit die datenverarbeitende Vorrichtung erheblich überzudimensionieren und z. B. zusätzliche Prozessoren für Unterbrechungs- behandlungen vorzusehen.
Ein weiterer Vorteil der Erfindung macht sich bemerkbar, wenn die maximale Reaktionszeit abgelaufen ist, ohne daß der Software-Prozeß vollständig bis zum Ende ausgeführt worden ist. Verfahren nach dem Stande der Technik erbringen in dieser Situation entweder gar kein Ergebnis, setzen die Ausführung zu einem späteren Zeitpunkt fort oder beginnen erst zu diesem Zeitpunkt damit, ein Näherungsergebnis oder ein Zwischenergebnis zu erbringen. Diese Bestimmung ist zeitaufwendig, und gerade nach Ablauf der maximalen Reaktionszeit steht kaum Rechenzeit zur Verfügung.
Im Gegensatz zu bekannten Verfahren und Vorrichtungen ist es dank der Erfindung zwar möglich, aber nicht erforderlich, die Ausführung weiterer gleichartiger Software-Prozesse für eine definierte Zeitspanne zu sperren.
Die Erfindung spart weiterhin Arbeitsaufwand bei der Implementierung sowie Rechenaufwand für die Ausführung des Software-Prozesses und für Kommunikation mit anderen Prozessen ein. Im Software-Prozeß selber brauchen weniger oder gar keine Sonderbehandlungen und Reaktionen auf externe Ereignisse vorhergesehen zu sein, und entsprechende Bedingungen und Fallunterscheidungen brauchen zur Ausfuhrungszeit nicht geprüft zu werden. Vielmehr wird in einer bevorzugten Ausführungsform (Anspruch 14) automatisch auf externe Ereignisse effizient reagiert. Bestimmte Ereignisse lösen vordefinierte Unterbrechungssignale mit zugeordneten Unterbrechungsbehandlungs-Programmen aus. Tritt während der Ausführung des Software-Prozesses ein solches Ereignis ein, so wird der Software-Prozeß unterbrochen und das dem Ereignis zugeordnete Unterbrechungsbehandlungs-Programm gestartet. Die Reaktionszeit des Unterbrechungsbehandlungs-Programms wird zur Reaktionszeit des Software-Prozesses addiert. Ein Zeitglied für die Ü- berwachung der maximalen Reaktionszeit läuft weiter. Wird die maximale Reaktionszeit des Software-Prozesses infolge der Ausführung des Unterbrechungsbehandlungs-Programms überschritten, so wird automatisch und ohne Sonderbehandlung das Ergebnis des erfindungsgemäß ausgewählten Teilprozesses als Endergebnis verwendet. Diese Unterbrechungsbehandlung braucht weiterhin nicht bei der Implementierung des Software- Prozesses berücksichtigt zu werden.
In einer alternativen Ausfuhrungsform wird die Reaktionszeit des Unterbrechungsbehandlungs-Programms dann nicht zur Reaktionszeit des Software-Prozesses addiert, wenn das Unterbrechungsbehandlungs-Programm eine höhere Priorität als der Software-Prozeß hat. Ein Zeitglied für die Überwachung der maximalen Reaktionszeit wird angehalten. In diesem Fall kann die maximale Reaktionszeit des Software-Prozesses überschritten werden. In manchen Anwendungen ist dies zulässig. Ein weiterer Vorzug der Erfindung ist es, daß man einfach diese beiden unterschiedlichen Verhaltensweisen, nämlich Abbruch o- der Fortsetzung bei Zeitüberschreitung infolge eines Un-
terbrechungsbehandlungs-Programms, sehr einfach konfigurieren kann, nämlich z. B. durch entsprechende Konfiguration des ü- berwachenden Zeitgliedes.
Bei der Ausführung des Software-Prozesses wird das Endergebnis beispielsweise iterativ, d. h. schrittweise, durch den Software-Prozeß erbracht (Anspruch 5) . Jeder Teilprozeß erbringt ein Näherungsergebnis für das Endergebnis. Nach einem Abbruch wird derjenige Teilprozeß ausgewählt, der als letzter vor dem Abbruch vollständig ausgeführt wurde. Das Näherungsergebnis dieses Teilprozesses wird im Falle des Abbruchs als Endergebnis des Software-Prozesses verwendet. Beispielsweise unterscheidet sich das Näherungsergebnis jedes Teilprozesses vom Endergebnis um höchstens eine vorgegebene Schranke, z. B. 1 mm, und jedes Näherungsergebnis liegt näher am Endergebnis als das vorige. Bei dieser Ausgestaltung ist automatisch und ohne zusätzlichen Aufwand eine obere Schranke für die Abweichung zwischen dem Näherungsergebnis nach Abbruch und dem Endergebnis, das bei vollständiger Ausführung des Software- Prozesses berechnet worden wäre, bekannt.
Insbesondere bei iterativer Erbringung des Endergebnisses verwendet vorzugsweise jeder Prozeß das Ergebnis des zuvor ausgeführten Teilprozesses, also des Vorgänger-Teilprozesses, als Eingangswert. Der Teilprozeß erbringt bevorzugt ein besseres Näherungsergebnis als der Vorgänger-Teilprozeß, d. h. eine mit geringerer Abweichung zum Endergebnis. In einer Ausführungsform werden die berechneten Näherungsergebnisse nacheinander in demselben Speicher abgespeichert (Anspruch 6) . Ein Näherungsergebnis überschreibt dabei das des zuvor berechneten Näherungsergebnisses. Nach einem Abbruch wird dieser Speicher ausgelesen, und sein Inhalt wird als Endergebnis verwendet (Anspruch 20) . Diese Ausgestaltung ist fehlertolerant z. B. gegen plötzliche Ausfälle eines Prozessors, der die Teilprozesse ausführt, und erfordert nur einen einzigen zusätzlichen Speicher.
Vorzugsweise wird vorab ein Standardwert für das Endergebnis des Software-Prozesses bestimmt oder eine schnell durchzufüh-
renden Handlung, z. B. Abschalten von Geräten oder Beenden weiterer Software-Prozesse, ausgeführt. Dieser Standardwert („default value") ist beispielsweise eine Konstante oder ein schnell zu berechnender Wert, der von einem vor dem Start des Software-Prozesses feststehenden Parameter abhängt. Der Standardwert kann ein Vorzugswert, ein Startwert für eine Iteration oder eine sinnvolle Voreinstellung sein. Gemäß Anspruch 7 umfaßt ein Standardwert-Ermittlungs-Teilprozeß das Auslösen der schnell durchzuführenden Handlung oder die Ermittlung dieses Standardwertes, beispielsweise durch schnelle Berechnung oder Auslesen eines Speichers, in dem die Konstante abgespeichert ist. Beispielsweise wird dieser Standard- wert-Ermittlungs-Teilprozeß als erster ausgeführt (Anspruch 9) . Diese Ausfuhrungsform hat den Vorzug, daß in der Regel sehr schnell ein Ergebnis eines Teilprozesses vorliegt, nämlich dann, wenn die Ermittlung des Standardwertes bzw. Auslösen der Handlung wenig Zeit im Vergleich zur Ausführungszeit anderer Teilprozesse erfordert. Dadurch wird auch bei einem sehr frühzeitigen Abbruch des Software-Prozesses ein gutes Endergebnis erbracht. Diese Ausgestaltung ist insbesondere dann von Vorteil, wenn neben der maximalen Reaktionszeit zusätzlich eine maximale Notreaktionszeit vorgegeben ist. Während die maximale Reaktionszeit die Zeitspanne bis zur vollständigen Ausführung des Software-Prozesses ist, beschreibt die maximale Notreaktionszeit die Latenzzeit zuzüglich der Zeitspanne, in der mindestens eine erste Notreaktion vollständig ausgeführt ist. Vorzugsweise wird der Standard- wert-Ermittlungs-Teilprozeß als Notreaktion so definiert, daß er innerhalb der maximalen Notreaktionszeit abgeschlossen ist .
Die Ausfuhrungsform nach Anspruch 11 sieht hingegen vor, daß der erste Teilprozeß dann ausgeführt wird, wenn der Software- Prozeß abgebrochen wird, weil die maximale Reaktionszeit beinahe verstrichen ist. Der Abbruch wird noch so rechtzeitig durchgeführt, daß nach dem Abbruch der erste Teilprozeß ausgeführt werden kann. Nach dem Abbruch liefert der erste
Teilprozeß den Standardwert, der als Endergebnis des Software-Prozesses verwendet wird.
Die Einhaltung der maximalen Reaktionszeit kann mit Hardware oder Software überwacht werden. Bevorzugt wird mindestens ein Hardware-Bauteil verwendet (Anspruch 2), z. B. ein durch einfache Hardware-Komponenten realisierbares Zeitglied verwendet (Anspruch 21) . Die Erfindung hat dann den zusätzlichen Vorzug, daß die Überwachung wenig zusätzliche Hardware erfordert .
Die Realisierung durch Hardware, insbesondere durch ein Zeitglied, ist der bevorzugte Weg, um sicherzustellen, daß tatsächlich die gesamte Reaktionszeit überwacht und begrenzt wird und nicht etwa nur die Ausfuhrungszeit . Bevorzugt beginnt die Zeitspanne mit dem Eintreffen eines Signals, das den Software-Prozeß auslöst, z. B. eines UnterbrechungsSignals. Falls die Reaktionszeit hingegen mit Hilfe von Befehlen eines Betriebssystems überwacht wird, so vergeht ein gewisser Zeitverzug, bis das Betriebssystem die Anforderung nach Auslösen des Software-Prozesses registriert und in seine Prioritätenliste aufgenommen hat . Dieser Zeitverzug kann nicht ü- berwacht und damit berücksichtigt und begrenzt werden. Falls erst der ausgelöste Software-Prozeß die Zeitspanne beginnen läßt, läßt sich nur die Ausführungszeit, nicht aber die Latenzzeit, überwachen und begrenzen. Die Latenzzeit kann z. B. durch das Auftreten anderer Software-Prozesse mit höherer Priorität unvorhersehbar lang sein.
Im folgenden wird die Erfindung anhand von zwei in den Zeichnungen dargestellten Ausführungsbeispielen erläutert; dabei veranschaulichen:
Fig. 1. den Aufbau eines Motorsteuergeräts, das den Zündzeitpunkt berechnet;
Fig. 2. den Aufbau einer Überwachungseinrichtung für eine Unterbrechungsbehandlung.
Die Erfindung wird zunächst am Beispiel eines Motorsteuergeräts 10 erläutert. Dieses Motorsteuergerät 10 berechnet während jeder Umdrehung, also während jedes vollständigen Arbeitstaktes des Motors, erneut den Zeitpunkt der Zündung. Den richtigen Zündzeitpunkt zu treffen senkt den Benzinverbrauch und den Ausstoß an Schadstoffen. Der richtige Zündzeitpunkt trägt damit u. U. dazu bei, gesetzliche Auflagen hinsichtlich der Umweltverträglichkeit zu erfüllen, und steigert die Wirtschaftlichkeit des Kraftfahrzeuges und damit die Wettbewerbsfähigkeit des Herstellers.
Verfahren nach dem Stand der Technik berechnen nur bis zu einer bestimmten, vorgegebenen Motor-Drehzahl den Zündzeitpunkt während jeder Umdrehung neu. Steigt die Motor-Drehzahl über die vorgegebene Grenze, wird nur noch während jeder zweiten Umdrehung der Zündzeitpunkt erneut berechnet. Für die dazwischenliegenden Umdrehungen wird der zuletzt berechnete Wert wiederverwendet. Dadurch wird u. U. der optimale Zündzeitpunkt nicht getroffen. Wird eine zu niedrige Schranke für die Motor-Drehzahl vorgegeben, so wird eine erneute Berechnung nicht durchgeführt, obwohl noch Rechenzeit zur Verfügung steht. Wird eine zu große Schranke vorgegeben, so muß die Berechnung u. U. abgebrochen werden, weil keine Rechenzeit mehr zur Verfügung steht .
Fig. 1. zeigt einen Aufbau eines Motorsteuergeräts 10, in dem die Erfindung angewendet wird. Das Motorsteuergerät 10 umfaßt einen Ausführungs-Prozessor 20, der u. a. während jeder Umdrehung den Zündzeitpunkt erneut bestimmt. Die hierfür erforderlichen Daten über den aktuellen Zustand des Fahrzeugs, z. B. die Motordrehzahl und die Fahrgeschwindigkeit, beschafft der Ausführungs-Prozessor 20 sich bei Bedarf aus einem internen Datenspeicher 80 oder über eine Schnittstelle 90 zu einem Datenbus im Fahrzeug, der das Motorsteuergerät 10 u. a. mit weiteren Steuergeräten verbindet . Die Berechnung des Zündzeitpunkts besteht im wesentlichen daraus, daß ein Berechnungsprogramm ausgeführt wird. Der ausführende Software- Prozeß umfaßt also die Ausführung dieses Berechnungspro-
gramms . Das Berechnungsprogramm ist in einem ersten Programmspeicher 40 für Berechnungsprogramme abgespeichert.
In Fig. 1. sind Daten- und Signalflüsse durch dünne Pfeile und schreibende oder Stelleingriffe durch dicke Pfeile dargestellt.
Weiterhin umfaßt das Motorsteuergerät 10 einen Ergebnisspeicher 70, das ist ein Datenspeicher, in dem das Endergebnis, also der berechnete Zündzeitpunkt, abgespeichert wird. Dieser Ergebnisspeicher 70 ist in zwei Daten-Teilspeicher unterteilt. Im ersten Daten-Teilspeicher 71 wird das berechnete Endergebnis abgespeichert. Im zweiten Daten-Teilspeicher 72 ist das Endergebnis der Berechnung während der vorigen Umdrehung, also der zuletzt verwendete Zündzeitpunkt, abgespeichert .
Der Ausführungs-Prozessor 20 führt nacheinander die Teilprozesse aus. Jeder Teilprozeß erbringt nach seiner Ausführung ein Ergebnis. Dieses Ergebnis schreibt der Ausführungs- Prozessor 20 in den ersten Daten-Teilspeicher 71, wobei ein zuvor abgespeichertes Ergebnis bevorzugt überschrieben wird.
Der Ausfuhrungs-Prozessor 20 bestimmt vorzugsweise iterativ, d. h. schrittweise, den richtigen Zündzeitpunkt. Der erste Teilprozeß berechnen einen Startwert für die Iteration. Dieser Startwert ist z. B. ein allgemeingültiger Vorzugswert o- der auch das Endergebnis der vorigen Berechnung, also der letzte Zündzeitpunkt. Jeder Berechnungsschritt ist ein Teilprozeß des Software-Prozesses. Die Berechnungsschritte und damit die Teilprozesse werden nacheinander ausgeführt . Jeder Berechnungsschritt erbringt ein Ergebnis, das genauer als das Ergebnis des vorigen Berechnungsschrittes ist. Für die Ausführung eines Berechnungsschrittes - außer für die des ersten Berechnungsschrittes - wird bevorzugt das Ergebnis des vorigen Berechnungsschrittes verwendet. Für den ersten Berechnungsschritt kann der vom ersten Teilprozeß berechnete Startwert als Eingangsgröße verwendet werden. In Fig. 1. sind
im ersten Programmspeicher 40 für Berechnungsprogramme ein erster Programm-Teilspeicher 41 für den ersten Teilprozeß, durch den der Startwert berechnet wird, und ein zweiter Programm-Teilspeicher 42 für den Berechnungsschritt, der mehrfach ausgeführt wird, dargestellt. Das Ergebnis jedes Berechnungsschrittes wird im ersten Daten-Teilspeicher 71 abgespeichert .
Vorzugsweise umfaßt der Software-Prozeß selber ein Abbruchkriterium, z. B. Anzahl der Berechnungsschritte. Am Ende der Berechnung ist das Endergebnis, nämlich der Zündzeitpunkt, im Ergebnisspeicher 70 abgespeichert und wird für nachfolgende Arbeitsschritte des Motorsteuergeräts 10 verwendet. Diese nachfolgenden Arbeitsschritte und die Vorrichtungen für diese sind in Fig. 1. nicht dargestellt. Möglich ist aber auch, daß die Ausführung des Software-Prozesses stets die vorgegebene Reaktionszeit vollständig beansprucht und erst durch die Ü- berwachungseinrichtung 30 auf die Weise abgebrochen wird, die im folgenden beschrieben wird.
Die Überwachungseinrichtung 30 sorgt erfindungsgemäß dafür, daß die vorgegebene Reaktionszeit eingehalten wird. Die Überwachungseinrichtung umfaßt ein Zeitglied. In dem Moment, zu dem die Latenzzeit für die Berechnung des Zündzeitpunktes beginnt, wird ein Zähler des Zeitgliedes auf einen vordefinierten Wert gesetzt. Der Beginn der Latenzzeit ist z. B. der Zeitpunkt, zu dem das Motorsteuergerät 10 den Befehl zum Berechnen des Zündzeitpunktes erzeugt . Der vordefinierte Wert ist bevorzugt umgekehrt proportional zur Motor-Drehzahl. Bevorzugt mit jedem Takt, den z. B. eine Systemuhr 200 des Motorsteuergeräts 10 erzeugt, wird der Zähler um einen Wert von 1 verkleinert. Die Arbeit des Zeitgliedes wird abgebrochen, sobald die Ausführung des Software-Prozesses abgeschlossen und das berechnete Endergebnis im ersten Teil-Datenspeicher abgespeichert ist. Bevorzugt übermittelt der Ausfuhrungs-
Prozessor 20 hierfür ein entsprechendes Ende-Signal an die Ü- berwachungseinrichtung .
In dem Moment, in dem der Zähler des Zeitgliedes den Wert 0 erreicht, ohne daß die Überwachungseinrichtung das Ende- Signal vom Ausführungs-Prozessor 20 erhalten hat, steht fest, daß die vorgegebene Zeitspanne verstrichen ist. Dies kann z. B. deshalb eingetreten sein, weil andere Prozesse mit höherer Priorität einen erheblichen Anteil der Rechenzeit des Ausfuhrungs-Prozessors 20 beanspruchten oder weil vorgesehen ist, daß der Teilprozeß die vorgegebene Reaktionszeit vollständig ausnutzt. Erfindungsgemäß löst die Überwachungseinrichtung dann, wenn der Zähler den Wert 0 erreicht, eine Unterbrechungsbehandlung aus. Hierfür ruft die ein Unterbrechungsbehandlungs-Programm auf, das in einem zweiten Programmspeicher 50 für Unterbrechungsbehandlungs-Programme abgespeichert ist.
Dieses Unterbrechungsbehandlungs-Programm entscheidet bevorzugt zuerst, auf welche Weise der nunmehr als Zündzeitpunkt verwendete Wert berechnet wird. Hierfür wird bevorzugt eine Entscheidung zwischen folgenden Alternativen getroffen:
Das Ergebnis des Teilprozesses, der als letzter ausgeführt wurde, wird als aktueller Zündzeitpunkt verwendet. Dieses Ergebnis ist im ersten Teil-Datenspeicher 71 des Ergebnisspeichers 70 abgespeichert.
Der vorige Zündzeitpunkt wird bestimmt und als aktueller Zündzeitpunkt wiederverwendet.
Ein Vorzugswert für den Zündzeitpunkt wird bestimmt und als aktueller Zündzeitpunkt verwendet.
Bereits bei der Konstruktion des Motorsteuergeräts 10 kann vorgesehen sein, daß stets eine dieser drei Alternativen ausgeführt wird. Bevorzugt wird die Entscheidung aber erst zum Zeitpunkt der Unterbrechungsbehandlung getroffen. Eine Aus- führungsform sieht vor, daß der Ausführungs-Prozessor 20 ein Zwischen-Signal an die Überwachungseinrichtung übermittelt,
sobald er eine vorab festgelegte Anzahl von Teilprozessen ausgeführt hat und das Ergebnis des als letzten ausgeführten Teilprozesses in den ersten Daten-Teilspeicher 71 abgespeichert hat. Beispielsweise wird das Zwischen-Signal übermittelt, sobald der Ausfuhrungs-Prozessor 20 den ersten Teilprozeß ausgeführt und den Startwert in den ersten Daten- Teilspeicher 71 abgespeichert hat oder sobald er den dritten Teilprozeß ausgeführt und damit den Startwert berechnet und anschließend zwei Berechnungsschritte ausgeführt hat. Falls dieses Zwischen-Signal bei der Überwachungseinrichtung eingetroffen ist, bevor die Unterbrechungsbehandlung begonnen wurde, so wird das im ersten Daten-Teilspeicher 71 abgespeicherte Ergebnis als Endergebnis, also als aktueller Zündzeitpunkt, verwendet, ansonsten das im zweiten Daten-Teilspeicher 72 abgespeicherte Ergebnis, also der vorige Zündzeitpunkt. Eine Fortbildung dieser Ausfuhrungsform sieht vor, daß dann, wenn das Zwischen-Signal nicht vorliegt, eine Entscheidung gefällt wird, ob der vorige Zündzeitpunkt wiederverwendet wird oder statt dessen ein Vorzugswert bestimmt und als aktueller Zündzeitpunkt verwendet wird. Diese Entscheidung kann davon abhängen, ob sich seit der Berechnung des vorigen Zündzeitpunktes wesentliche Umgebungsbedingungen, z. B. die Motordrehzahl , geändert haben oder nicht .
Alle diese Ausfuhrungsformen sehen vor, daß schnell und auf vorhersagbare Weise ein brauchbarer Zündzeitpunkt berechnet wird. Im Berechnungsprogramm für den Zündzeitpunkt brauchen externe Ereignisse, welche die Berechnung des Zündzeitpunktes verzögern können, nicht berücksichtigt zu werden. Weiterhin braucht im Berechnungsprogramm nicht die Wiederverwendung des vorigen Zündzeitpunktes bei hohen Motor-Drehzahlen oder bei hoher Prozessor-Belastung vorgesehen zu werden.
Beim zweiten Ausführungsbeispiel ist der Software-Prozeß, dessen Reaktionszeit begrenzt wird, selber ein Unterbrechungsbehandlungs-Programm (Interrupt Service Routine) , das
einem vordefinierten Unterbrechungssignal-Typ (Interrupt Re- quest) zugeordnet ist. Der Unterbrechungssignal-Typ ist eines von M vordefinierten Unterbrechungssignal-Typen, wobei M eine natürliche Zahl ist. Bevorzugt durch die Kennung werden die M Unterbrechungssignal-Typen voneinander unterschieden. Jedem Unterbrechungssignal-Typ ist weiterhin eines von M Unterbrechungsbehandlungs-Programmen zugeordnet. Ein Unterbrechungs- signal desselben Typs kann mehrmals zu verschiedenen Zeitpunkten eintreffen.
Bevorzugt umfaßt jedes Unterbrechungsbehandlungs-Programm je einen Standardwert-Ermittlungs-Teilprozeß, der einen Standardwert wie oben beschrieben ermittelt oder eine schnell durchzuführende Handlung auslöst. Vorzugsweise ist für jedes Unterbrechungsbehandlungs-Programm zusätzlich eine maximale Notreaktionszeit vorgegeben. Der Standardwert-Ermittlungs- Teilprozeß wird so ausgelegt, daß er innerhalb der maximalen Notreaktionszeit ausgeführt werden kann. Weiterhin sind bevorzugt für jedes Unterbrechungsbehandlungs-Programm eine minimale Wiederholzeit oder eine maximale Wiederholfrequenz vorgegeben. Die minimale Wiederholzeit ist der reziproke Wert der maximalen Wiederholfrequenz.
Bevorzugt wird vorab die im folgenden beschriebene Prüfung durchgeführt. Seien UBP_1, ... , UBP_M die M vordefinierten Unterbrechungsbehandlungs-Programme. Seien NRZ(UBP_i) und WZ(UBP_i) die maximale Notreaktionszeit bzw. die minimale Wiederholzeit von UBP_i (i=l,...,N). Diese Zeiten werden vorzugsweise als Vielfache einer vorgegebenen Bezugs- Zeiteinheit, z. B. des Reziproken des Prozessor- oder Systemtakts, angegeben. Dann darf NRZ(UBP_1) / WZ(UBP_1) + ... + NRZ (UBP_N) / WZ (UBPJST) eine vorgegebene obere Schranke nicht übersteigen. Oft hat diese Schranke den Wert T * In 2 , In bezeichnet hierbei den natürlichen Logarithmus. T bezeichnet hierbei vorzugsweise
die gesamte verfügbare Rechenzeit des Prozessors. Möglich ist auch, T selber als obere Schranke zu verwenden.
Jedem Unterbrechungssignal-Typ ist eine von N verschiedenen Prioritäten zugeordnet, wobei N <= M ebenfalls eine natürliche Zahl ist. Damit hat auch jedes Unterbrechungsbehandlungs- Programm eine von N Prioritäten. Vorzugsweise hängt die zugeordnete Priorität von der Bedeutung des Unterbrechungsbehandlungs-Programms und der maximalen Notreaktionszeit ab - je geringer die maximale Notreaktionszeit, desto höher die Priorität .
In einer Fortbildung der Ausfuhrungsform ist vorgesehen, einzelnen Teilprozessen eines Unterbrechungsbehandlungs- Programms unterschiedliche Prioritäten zuzuordnen. Notwendige Teilprozesse erhalten z. B. die Priorität des Unterbrechungs- signals, weitere Teilprozesse eine niedrigere Priorität.
Die Unterbrechungsbehandlungs-Programme werden erfindungsgemäß in Teilprozesse unterteilt. Einer davon ist der Standard- wert-Ermittlungs-Teilprozeß. Die einzelnen Teilprozesse werden bevorzugt so definiert, daß ihre Ausführung nicht durch Unterbrechungssignale unterbrochen oder abgebrochen werden kann.
Fig. 2. zeigt beispielhaft den Aufbau einer Überwachungseinrichtung 30, die die Reaktionszeit von Unterbrechungsbehandlungs-Programmen begrenzt. Die Unterbrechungsbehandlungs- Programme werden von einem Ausführungs-Prozessor 20 ausgeführt. Hierfür greift der Ausfuhrungs-Prozessor 20 lesend auf mindestens einen Programmspeicher 50' für die Unterbrechungsbehandlungs-Programme zu. Die Unterbrechungsbehandlungs- Programme sind wiederum erfindungsgemäß in Teilprozesse unterteilt, die bevorzugt jeweils nacheinander ausgeführt werden. Beispielsweise ist das Quellprogramm für jeden Teilprozeß in einem separaten Programm-Teilspeicher so abgespeichert, daß Teilprozesse nicht Programm-Teilspeicher oder Datenspeicher anderer Teilprozesse überschreiben können. Das Ergebnis jedes Teilprozesses speichert der Ausfuhrungs-
Prozessor wie oben beschrieben in einem Ergebnisspeicher 70 ab, der in Fig. 2. nicht gezeigt wird.
Die erfindungsgemäße Einhaltung der vorgegebenen Reaktionszeit wird durch eine Überwachungseinrichtung 30 überwacht. Diese Überwachungseinrichtung 30 steuert weiterhin die zeitliche Reihenfolge, in der die eintreffenden Unterbrechungs- Signale abgearbeitet werden. Sie umfaßt bevorzugt einen Unterbrechungssignal-Prozessor 100 (Interrupt Request Controller) , einen Speicher 110 für Unterbrechungssignale, M Sperr- Zeitglieder 130 und M Reaktionszeit-Zeitglieder 140. Alle 2*M Zeitglieder sind mit dem Unterbrechungssignal-Prozessor 100 verbunden; in Fig. 2. ist nur die Verbindung zwischen dem Unterbrechungssignal-Prozessor 100 und zwei Zeitgliedern gezeigt .
Für jeden der M Unterbrechungssignal-Typen sind je ein Sperr- Zeitglied 130 und ein Reaktionszeit-Zeitglied 140 vorgesehen. Bevorzugt arbeiten diese 2*M Zeitglieder so wie oben beschrieben. Bis zu 2*M verschiedene Zeitspannen können vorgegeben sein und durch bloße Änderung eines Zeitgliedes verändert werden.
Das Sperr-Zeitglied 130. i für den Unterbrechungssignal-Typ i sperrt die Ausführung eines Unterbrechungssignals des Typs i für eine vordefinierte Sperrzeit und stellt damit sicher, daß zwei Unterbrechungssignale gleichen Typs höchstens mit einer vorgegebenen Wiederholfrequenz abgearbeitet werden, aber nicht häufiger. Anders formuliert: Sichergestellt wird, daß zwischen zwei Aufrufen des Unterbrechungsbehandlungs- Programms für den Typ i mindestens eine vorgegebene Wiederholungszeit als Sperrzeit verstreicht. Der reziproke Wert ist die maximale Wiederholfrequenz . Während dieser Zeitspanne ist das Sperr-Zeitglied 130. i entweder im Zustand „sper- ren_speichern" oder im Zustand „sperren_ignorieren", ansonsten im Zustand „durchlassen". Die drei Zustände werden beispielsweise mit Hilfe eines Zählers und eines zusätzlichen 1- Bit-Registers realisiert. Der Zähler wird bei Überführung in einen der Zustände „sperren_speichern" oder „sper-
ren_ignorieren" auf einen vordefinierten Wert größer 0 gesetzt und wird in einem durch eine Systemuhr 200 vorgegebenen Systemtakt jeweils um 1 verringert. Wenn der Zähler den Wert 0 annimmt, ist das Sperr-Zeitglied 130. i im Zustand „durchlassen". Durch das 1-Bit-Register werden die Zustände „sper- ren_speichern" oder „sperren_ignorieren" unterschieden.
Das Reaktionszeit-Zeitglied 140. i für den Unterbrechungssignal-Typ i begrenzt die Latenzzeit zuzüglich der Ausführungszeit eines UnterbrechungsSignals des Typs i auf eine vordefinierte maximale Reaktionszeit. Wenn der Ausfuhrungs-Prozessor 20 das dem Typ i zugeordnete Unterbrechungsbehandlungs- Programm ausführt und die vorgegebene Zeitspanne für die Reaktionszeit noch nicht verstrichen ist, ist das Reaktionszeit-Zeitglied 140. i in Zustand „aktiv", ansonsten im Zustand „inaktiv" .
Weiterhin umfaßt der Unterbrechungssignal-Prozessor 100 bevorzugt einen Prioritäts-Speicher 120, in dem die höchste Priorität aller Unterbrechungsbehandlungs-Programme, die der Ausführungs-Prozessor 20 aktuell ausführt, abgespeichert ist.
Wenn ein Unterbrechungssignal z. B. an einer Schnittstelle 80 zum Datenbus eintrifft, identifiziert der Unterbrechungssignal-Prozessor 100 den Typ dieses Unterbrechungssignals und die dem Typ zugeordnete Priorität und führt mindestens einen der folgenden Schritte durch:
Er leitet das Unterbrechungssignal an den Ausführungs- Prozessor 20 weiter.
Er unterbricht Unterbrechungsbehandlungs-Programme, die der Ausführungs-Prozessor 20 gerade ausführt.
Er speichert die Kennung und den Eintreffens-Zeitpunkt des UnterbrechungsSignals in dem Unterbrechungssignal-Speicher 110 ab.
Er ignoriert das Unterbrechungssignal .
Welchen oder welche dieser vier Schritte der Unterbrechungs- signal-Prozessor 100 durchführt, hängt von der Priorität des
UnterbrechungsSignals und von den aktuellen Zuständen der beiden Zeitglieder, die für den Unterbrechungssignal-Typ vorgesehen sind, ab.
Seien i der Typ des Unterbrechungssignals und j die dem Typ i zugeordnete Priorität . Folgende Fallunterscheidungen nimmt der Unterbrechungssignal-Prozessor 100 vor:
- Wenn das Sperr-Zeitglied 130. i für den Typ i sich im Zustand „sperren_ignorieren" befindet, ignoriert er das Unterbrechungssignal .
- Wenn das Sperr-Zeitglied 130. i für den Typ i sich im Zustand „sperren_speichern" befindet, speichert er den durch die Kennung gekennzeichneten Typ i und den Eintreffens- Zeitpunkt des Unterbrechungssignals im Unterbrechungssignal-Speicher 110 ab.
Wenn das Sperr-Zeitglied 130. i für den Typ i sich im Zustand „durchlassen" befindet, stellt der Unterbrechungssignal-Prozessor 100 durch Lesezugriff auf den Prioritäts- Speicher 120 fest, ob der Ausfuhrungs-Prozessor 20 aktuell ein Unterbrechungsbehandlungs-Programm ausführt, das eine Priorität besitzt, die höher oder gleich die des Typs i ist. Ist dies der Fall, speichert er wiederum Kennung und Eintreffens-Zeitpunkt im Unterbrechungssignal-Speicher 110 ab. Ansonsten leitet er das Unterbrechungssignal an den Ausführungs-Prozessor 20 weiter. Dieser führt das zugeordnete Unterbrechungsbehandlungs-Programm für den Typ i aus.
Falls der Unterbrechungssignal-Prozessor 100 das Unterbrechungssignal weiterleitet, veranlaßt er gleichzeitig, daß der Ausfuhrungs-Prozessor 20 alle Unterbrechungsbehandlungs-Programme mit einer niedrigeren Priorität unterbricht und zuerst das für den Typ i ausführt .
Diese Ausführung führt dazu, daß ein Unterbrechungssignal mit der Priorität j stets vor einem mit einer Priorität k (k > j ) bevorzugt behandelt wird. Zwei Unterbrechungssignale gleicher Priorität werden in der zeitlichen Reihenfolge ihres Eintreffens behandelt .
Der Unterbrechungssignal-Prozessor 100 aktualisiert bei Bedarf weiterhin die beiden Zeitglieder für den Typ i und den Prioritäts-Speicher 120.
Unmittelbar nach Eintreffen des Unterbrechungssignals vom Typ i bringt er das Sperr-Zeitglied 130. i für den Typ i in den Zustand „sperren_ignorieren" . Das Sperr-Zeitglied 130. i beginnt mit der Messung der vorgegebenen Sperrzeit. Der Ausfuhrungs-Prozessor 20 sendet dann, wenn er mit der Ausführung des Unterbrechungsbehandlungs-Programms für den Typ i beginnt, ein entsprechendes Signal an den Unterbrechungssignal- Prozessor 100. Dieser überführt daraufhin das Sperr-Zeitglied 130.i für den Typ i vom Zustand „sperren_ignorieren" in den Zustand „sperren_speichern" . Nach Ablauf der vorgegebenen und durch das Sperr-Zeitglied 130. i überwachten Sperrzeit wird es vom Zustand „sperren_speichern" in den Zustand „durchlassen" überführt. Läuft die Sperrzeit ab, bevor die Ausführung des Unterbrechungsbehandlungs-Programms begonnen hat, so wird das Sperr-Zeitglied 130. i vom Zustand „sperren_ignorieren" in den Zustand „sperren_speichern" überführt und nach Beendigung des Unterbrechungsbehandlungs-Programms in den Zustand „durchlassen". Diese Ausgestaltung führt dazu, daß weitere Unterbrechungssignale des Typs i in der Latenzzeit des Unterbrechungsbehandlungs-Programms für den Typ i ignoriert und in der Ausführungszeit abgespeichert werden.
Der Unterbrechungssignal-Prozessor 100 bringt weiterhin unmittelbar nach Eintreffen des UnterbrechungsSignals das Reaktionszeit-Zeitglied 140. i in den Zustand „aktiv". Das Reaktionszeit-Zeitglied 140. i beginnt daraufhin mit der Überwachung der Reaktionszeit. Falls der Ausführungs-Prozessor 20 innerhalb der vorgegebenen maximalen Reaktionszeit das Unterbrechungsbehandlungs-Programm vollständig ausführt, sendet er ein entsprechendes Signal an den Unterbrechungssignal- Prozessor 100. Dieser überführt das Reaktionszeit-Zeitglied 140. i für den Typ i in den Modus „inaktiv". Falls das Zeitglied registriert, daß die vorgegebene maximale Reaktionszeit abgelaufen ist und es sich noch im Zustand „aktiv" befindet,
so sendet es ein entsprechendes Signal an den Unterbrechungs- signal-Prozessor 100. Dieser überführt es daraufhin in den Zustand „inaktiv" und sendet ein entsprechendes Signal an den Ausfuhrungs-Prozessor 20. Der Ausfuhrungs-Prozessor 20 bricht daraufhin die Ausführung des Unterbrechungsbehandlungs- Programms für den Typ i und beginnt eine vordefinierte Unterbrechungsbehandlung nach Abbruch. Bevorzugt greift der Ausfuhrungs-Prozessor 20 hierfür lesend auf einen Programmspeicher 150 für Abbruchbehandlungen zu. Diese kann wie oben beschrieben daraus bestehen, einen Vorzugswert zu ermitteln o- der das Ergebnis des zuletzt ausgeführten Teilprozesses, das im Ergebnisspeicher 70 abgespeichert ist, als Endergebnis des Unterbrechungsbehandlungs-Programms für den Typ i zu verwenden.
Sobald der Unterbrechungssignal-Prozessor 100 registriert, daß ein Unterbrechungsbehandlungs-Programm vollständig ausgeführt wurde oder dessen maximale Reaktionszeit abgelaufen ist, aktualisiert er den Prioritäts-Speicher 120 und wählt unter den im Unterbrechungssignal-Speicher 110 abgespeicherten Unterbrechungssignalen das mit der höchsten Priorität aus. Unter mehreren mit gleicher Priorität wird das mit dem frühesten Eintreffens-Zeitpunkt ausgewählt. Der Eintrag für das ausgewählte Unterbrechungssignal wird aus dem Unterbrechungssignal-Speicher 110 entfernt, und die oben beschriebenen Entscheidungen und Arbeitsschritte werden für das ausgewählte Unterbrechungssignal ausgeführt. Das Unterbrechungs- signal wird an den Ausführungs-Prozessor 20 weitergeleitet o- der wieder in den Unterbrechungssignal-Speicher 110 abgespeichert. Letzteres kann insbesondere dann geschehen, wenn ein Unterbrechungssignal höherer Priorität abgearbeitet wird. Bei Bedarf werden weiterhin die Zustände der beiden zugeordneten Zeitglieder aktualisiert.
Der Unterbrechungssignal-Prozessor 100 kann auf zwei verschiedene Weisen konfiguriert werden: Falls die Ausführung eines Unterbrechungsbehandlungs-Programms unterbrochen wird, weil ein Unterbrechungssignal höherer Priorität bevorzugt be-
handelt wird, so wird entweder das Reaktionszeit-Zeitglied 140. i angehalten, oder es läuft weiter. Im ersten Fall verlängert sich die Reaktionszeit des Unterbrechungsbehandlungs- Programms für die Dauer des weiteren Unterbrechungsbehandlungs-Programms höherer Priorität, im zweiten Fall nicht. Im ersten Fall unterbricht der Unterbrechungssignal-Prozessor 100 die Arbeit des Reaktionszeit-Zeitgliedes 140. i, im zweiten Fall nicht. Der Wechsel zwischen diesen beiden Arbeitsweisen kann dadurch auf einfache Weise realisiert werden.
Bezugszeichenliste
10 Motorsteuergerät
20 Ausfuhrungs-Prozessor
30 Überwachungseinrichtung
40 Programmspeicher für Berechnungsprogramme
41 Programm-Teilspeicher für den Startwert
42 Programm-Teilspeicher für einen Berechnungsschritt
50 Programmspeicher für Unterbrechungsbehandlungs -Programme
60 Reaktionszeit-Zeitglied
70 Ergebnisspeieher
71 erster Daten-Teilspeicher für aktuelles Ergebnis
72 zweiter Daten-Teilspeicher für voriges Endergebnis
80 Interner Datenspeicher
90 Schnittstelle zum Datenbus
100 Unterbrechungssignal-Prozessor
110 Speicher für UnterbrechungsSignale
120 Prioritäts-Speicher
130 Sperr-Zeitglied
140 Reaktionszeit-Zeitglied
150 Programmspeicher für Abbruchbehandlungen
200 Systemuhr
Claims
1. Verfahren zur Beschränkung der Reaktionszeit eines Software-Prozesses auf eine vorgegebene maximale Reaktionszeit, wobei
- durch die Ausführung des Software-Prozesses ein Endergebnis erbracht wird
- und die Ausführung des Software-Prozesses spätestens dann abgebrochen wird, wenn sie nach Ablauf der maximalen Reaktionszeit nicht beendet ist, d a d u r c h g e k e n n z e i c h n e t , daß die Ausführung des Software-Prozesses die Ausführung von Teilprozessen umfaßt, wobei jeder dieser Teilprozesse nach seiner Ausführung ein Ergebnis erbringt,
- und bei Abbruch der Ausführung des Software-Prozesses ein Teilprozeß ausgewählt und dessen Ergebnis als Endergebnis des Software-Prozesses verwendet wird.
2. Verfahren nach Anspruch 1, d a d u r c h g e k e n n z e i c h n e t , daß die Reaktionszeit des Software-Prozesses durch ein Bauteil überwacht wird, welches beim Auslösen des Software-Prozesses aktiviert wird.
3. Verfahren nach Anspruch 1 oder Anspruch 2 , d a d u r c h g e k e nn z e i c h n e t , daß bei Abbruch nur diejenigen Teilprozesse auswählbar sind, die bei Abbruch der Ausführung des Software-Prozesses vollständig ausgeführt sind.
4. Verfahren nach einem der Ansprüche 1 bis 3, d a d u r c h g e k e n n z e i c h n e t , daß die Teilprozesse nacheinander in einer bestimmten Reihenfolge ausgeführt werden und nach einem Abbruch derjenige Teilprozeß ausgewählt wird, der als letzter vollständig ausgeführt wurde.
5. Verfahren nach Anspruch 4, d a d u r c h g e k e n n z e i c h n e t , daß das Endergebnis iterativ durch den Software-Prozeß erbracht wird und jeder Teilprozeß ein Näherungsergebnis für das Endergebnis erbringt.
6. Verfahren nach Anspruch 4 oder Anspruch 5 , d a d u r c h g e k e n n z e i c h n e t , daß das Ergebnis jedes Teilprozesses abgespeichert wird, wobei das Ergebnis eines Vorgänger-Teilprozesses durch das Ergebnis eines Nachfolger-Teilprozesses überschrieben wird.
7. Verfahren nach einem der Ansprüche 1 bis 6, d a d u r c h g e k e n n z e i c h n e t , daß mindestens einer der Teilprozesse ein Standardwert- Ermittlungs-Teilprozeß ist, durch den
- ein Standardwert für das Endergebnis des Software- Prozesses ermittelt wird oder eine Handlung ausgelöst wird.
8. Verfahren nach Anspruch 7, d a d u r c h g e k e n n z e i c h n e t , daß bei Abbruch des Sof ware-Prozesses der Standardwert- Ermittlungs-Teilprozeß ausgewählt wird.
9. Verfahren nach Anspruch 7 , d a d u r c h g e k e n n z e i c h n e t , daß die Ausführung des Software-Prozesses mit der Ausführung des Standardwert-Ermittlungs-Teilprozesses beginnt.
10. Verfahren nach einem der Ansprüche 7 bis 9, d a d u r c h g e k e n n z e i c h n e t , daß der Standardwert-Er ittlungs-Teilprozeß eine Reaktionszeit hat, die nicht länger als eine vorgegebene maximale Notreaktionszeit ist.
11. Verfahren nach Anspruch 10, d a d u r c h g e k e n n z e i c h n e t , daß die Ausführung des Software-Prozesses spätestens dann abgebrochen wird, wenn die maximale Reaktionszeit bis auf die maximale Not- reaktionszeit verstrichen ist, und der Standardwert-Ermittlungs-Teilprozeß nach Abbruch des Software-Prozesses ausgeführt wird.
12. Verfahren nach einem der Ansprüche 1 bis 11, d a d u r c h g e k e n n z e i c h n e t , daß der Software-Prozeß ein Unterbrechungsbehandlungs- Programm ist, das durch ein Unterbrechungssignal ausgelöst wurde.
13. Verfahren nach Anspruch 12 , d a d u r c h g e k e n n z e i c h n e t , daß nach einem ersten Auslösen des Unterbrechungsbehandlungs-Programms ein erneutes Auslösen für eine vorgegebene Zeitspanne unterbunden wird.
14. Verfahren nach einem der Ansprüche 1 bis 13, d a d u r c h g e k e n n z e i c h n e t ,
- der Software-Prozeß in einem Mehrprozessorsystem ausgeführt wird, das unterschiedliche Prioritäten für Software-Prozesse berücksichtigt, dem Software-Prozeß eine Priorität zugeordnet ist,
- ein Ereignis einen weiteren Software-Prozeß auslöst, dem weiteren Software-Prozeß eine Priorität zugeordnet ist, die höher als die des Software-Prozesses ist, - und die Ausführung des Software-Prozesses nach Auftreten des auslösenden Ereignisses unterbrochen wird.
15. Verfahren nach Anspruch 14, d a d u r c h g e k e n n z e i c h n e t , daß die Zeitspanne, während der die Ausführung des Software-Prozesses unterbrochen ist, zu der Reaktionszeit des Software-Prozesses hinzugerechnet wird.
16. Verfahren nach Anspruch 14 oder Anspruch 15, d a d u r c h g e k e n n z e i c h n e t , daß
- der weitere Software-Prozeß ein Unterbrechungsbehandlungs-Programm
- und das auslösende Ereignis ein Unterbrechungssignal ist .
17. Vorrichtung zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 16, mit einem Mittel zur Überwachung der Reaktionszeit des Software-Prozesses,
- mit einem Mittel zur Ausführung von Teilprozessen,
- mit einem Mittel zur Auswahl eines ausgeführten Teil- prozesses
- und mit einem Mittel zur Erbringung eines Ergebnisses des ausgewählten Teilprozesses.
18. Vorrichtung zur Ausführung eines Software-Prozesses, der ein Endergebnis erbringt, wobei die Vorrichtung
- einen Prozessor (20) zum Ausführen des Software- Prozesses
- und eine Überwachungseinrichtung (30) zur Überwachung der Reaktionszeit des Software-Prozesses umfaßt und wobei die Überwachungseinrichtung (30) mindestens dann die Ausführung des Software-Prozesses abbricht und die Ausführung eines Unterbrechungsbehandlungs-Programms auslöst, wenn die Ausführung des Software-Prozesses nach Ablauf einer vorgegebenen maximalen Reaktionszeit nicht beendet ist, d a d u r c h g e k e n n z e i c h n e t , daß
- der Prozessor (20) bei der Ausführung des Software- Prozesses Teilprozesse ausführt, wobei jeder dieser Teilprozesse nach seiner Ausführung ein Ergebnis erbringt,
- das Unterbrechungsbehandlungs-Programm einen dieser Teilprozesse auswählt
- und die Vorrichtung das Ergebnis des ausgewählten Teil- Prozesses als Endergebnis verwendet.
19. Vorrichtung nach Anspruch 18, d a d u r c h g e k e n n z e i c h n e t , daß der Prozessor das Endergebnis iterativ erbringt und jedes Ergebnis eines Teilprozesses ein Näherungsergebnis für das Endergebnis ist.
20. Vorrichtung nach Anspruch 19, d a d u r c h g e k e n n z e i c h n e t , daß
- die Vorrichtung einen Ergebnisspeieher (70) umfaßt, der Prozessor das Ergebnis jedes Teilprozesses in diesen Ergebnisspeicher (70) abspeichert
- und das Unterbrechungsbehandlungs-Programm den Inhalt dieses Ergebnisspeichers (70) ausliest.
21. Vorrichtung nach einem der Ansprüche 18 bis 20, d a d u r c h g e k e n n z e i c h n e t , daß die Überwachungseinrichtung (30) ein Zeitglied (60, 140) umfaßt, das nach Verstreichen der maximalen Reaktionszeit ein Signal erzeugt .
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE10206865 | 2002-02-18 | ||
DE10206865A DE10206865C1 (de) | 2002-02-18 | 2002-02-18 | Reaktionszeit-Beschränkung eines Software-Prozesses |
PCT/EP2003/000721 WO2003069424A2 (de) | 2002-02-18 | 2003-01-24 | Reaktionszeit-beschränkung eines software-prozesses |
Publications (1)
Publication Number | Publication Date |
---|---|
EP1514180A2 true EP1514180A2 (de) | 2005-03-16 |
Family
ID=7713860
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP03739445A Withdrawn EP1514180A2 (de) | 2002-02-18 | 2003-01-24 | Reaktionszeit-beschränkung eines software-prozesses |
Country Status (4)
Country | Link |
---|---|
US (1) | US20050160425A1 (de) |
EP (1) | EP1514180A2 (de) |
DE (1) | DE10206865C1 (de) |
WO (1) | WO2003069424A2 (de) |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050289558A1 (en) * | 2004-06-08 | 2005-12-29 | Daniel Illowsky | Device interoperability runtime establishing event serialization and synchronization amongst a plurality of separate processing units and method for coordinating control data and operations |
JP4541054B2 (ja) * | 2004-07-09 | 2010-09-08 | 株式会社リコー | レンズ鏡胴及び撮影装置 |
DE102004035097A1 (de) * | 2004-07-20 | 2006-02-09 | Endress + Hauser Gmbh + Co. Kg | Elektronisches Gerät und Verfahren zur Durchführung mehrerer Prozesse mit dem elektronischen Gerät |
FR2884628A1 (fr) * | 2005-04-18 | 2006-10-20 | St Microelectronics Sa | Procede de traitement d'interruptions non securisees par un processeur operant dans le mode securise, processeur associe. |
DE102005046072B4 (de) * | 2005-09-27 | 2009-04-02 | Daimler Ag | Verfahren und Vorichtung zur Prozeßregelung |
US8025034B2 (en) * | 2007-01-05 | 2011-09-27 | Ford Global Technologies, Llc | Interval phasing for valve timing |
US8019899B2 (en) * | 2008-08-28 | 2011-09-13 | Yahoo! Inc. | Delivering partially processed results based on system metrics in network content delivery systems |
GB2517493A (en) * | 2013-08-23 | 2015-02-25 | Advanced Risc Mach Ltd | Handling access attributes for data accesses |
US10013280B2 (en) * | 2013-09-30 | 2018-07-03 | Dell Products, Lp | System and method for host-assisted background media scan (BMS) |
GB2522477B (en) * | 2014-01-28 | 2020-06-17 | Advanced Risc Mach Ltd | Speculative interrupt signalling |
CN114765976A (zh) * | 2019-12-04 | 2022-07-19 | 三菱电机株式会社 | 车辆控制装置 |
DE102020203420B4 (de) * | 2020-01-15 | 2021-11-04 | Volkswagen Aktiengesellschaft | Verfahren und Vorrichtung zum Rekonfigurieren eines automatisiert fahrenden Fahrzeugs in einem Fehlerfall |
Family Cites Families (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE3243760C2 (de) * | 1982-11-26 | 1989-04-27 | Brown, Boveri & Cie Ag, 6800 Mannheim | Einrichtung zur Funktionsüberwachung eines Prozessors |
DE3544079C2 (de) * | 1985-12-13 | 1998-07-30 | Bosch Gmbh Robert | Verfahren zur Verarbeitung von Interrupt-Signalen |
US4894846A (en) * | 1988-06-30 | 1990-01-16 | Digital Equipment Corporation | Method for maintaining a correct time in a distributed processing system |
US5257357A (en) * | 1991-01-22 | 1993-10-26 | Motorola, Inc. | Method and apparatus for implementing a priority adjustment of an interrupt in a data processor |
JP2520544B2 (ja) * | 1991-09-26 | 1996-07-31 | インターナショナル・ビジネス・マシーンズ・コーポレイション | タスクのオ―バ―ラン状態を監視する方法及びタスク実行サイクルのオ―バ―ランを検出する装置 |
DE4329872C2 (de) * | 1993-09-03 | 1998-01-22 | Siemens Ag | Überwachungsschaltung für Mikroprozessoren |
US5535380A (en) * | 1994-12-16 | 1996-07-09 | International Business Machines Corporation | System to reduce latency for real time interrupts |
US6182203B1 (en) * | 1997-01-24 | 2001-01-30 | Texas Instruments Incorporated | Microprocessor |
US6081665A (en) * | 1997-12-19 | 2000-06-27 | Newmonics Inc. | Method for efficient soft real-time execution of portable byte code computer programs |
FI108478B (fi) * | 1998-01-21 | 2002-01-31 | Nokia Corp | Sulautettu jõrjestelmõ |
DE19927657A1 (de) * | 1999-06-17 | 2001-01-04 | Daimler Chrysler Ag | Partitionierung und Überwachung von softwaregesteuerten Systemen |
EP1243987B1 (de) * | 2001-03-19 | 2011-10-05 | Siemens Enterprise Communications GmbH & Co. KG | Verfahren und Anordnung zur Steuerung der Ausführung von Teilaufgaben eines Prozesses |
-
2002
- 2002-02-18 DE DE10206865A patent/DE10206865C1/de not_active Expired - Fee Related
-
2003
- 2003-01-24 US US10/504,931 patent/US20050160425A1/en not_active Abandoned
- 2003-01-24 EP EP03739445A patent/EP1514180A2/de not_active Withdrawn
- 2003-01-24 WO PCT/EP2003/000721 patent/WO2003069424A2/de not_active Application Discontinuation
Non-Patent Citations (1)
Title |
---|
See references of WO03069424A2 * |
Also Published As
Publication number | Publication date |
---|---|
WO2003069424A2 (de) | 2003-08-21 |
DE10206865C1 (de) | 2003-05-15 |
WO2003069424A3 (de) | 2004-12-29 |
US20050160425A1 (en) | 2005-07-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP0635784B1 (de) | Multiprozessorsystem | |
EP0655682B1 (de) | Recheneinheit mit mehreren ausführbaren Tasks | |
DE60008267T2 (de) | Verfahren zum planen von zeitverteilten anwendungen in einem rechnerbetriebssystem | |
DE19648422C2 (de) | Verfahren und Vorrichtung zum Implementieren eines echtzeitfähigen Steuerprogramms in einem nicht-echtzeitfähigen Betriebsprogramm | |
DE60127857T2 (de) | Sicherheitsverfahren mit deterministischer echtzeit-ausführung von multitask-anwendungen des steuer- und befehlstyps mit fehlereingrenzung | |
DE10231668B4 (de) | Multitaskingbetriebssystem zur Verringerung des Stromverbrauchs und elektronische Steuerung im Fahrzeug, die selbiges benutzt | |
DE4410775C2 (de) | Steuergerät und Arbeitsverfahren eines Betriebssystems für dieses Steuergerät | |
DE102005048037A1 (de) | Verfahren zur Steuerung/Regelung wenigstens einer Task | |
DE19500957A1 (de) | Verfahren zur Steuerung von technischen Vorgängen oder Prozessen | |
WO2011061046A1 (de) | Parallelisierte programmsteuerung | |
DE68924810T2 (de) | Zeitgeberkanal für die Verwendung in einem Mehrkanal-Zeitsystem. | |
DE2210704A1 (de) | Verfahren und Vorrichtung zur Datenverarbeitung | |
DE69222468T2 (de) | Vorrichtung zur Steigerung der Leistung eines einer Multiprozessorstruktur mit einer möglicherweise hohen Anzahl von Prozessoren zugeordneten Echtzeitsteuerprogrammkerns | |
EP1514180A2 (de) | Reaktionszeit-beschränkung eines software-prozesses | |
DE102004054571B4 (de) | Verfahren zur Verteilung von Rechenzeit in einem Rechnersystem | |
DE68919018T2 (de) | Zeitgeberkanal mit Übereinstimmungserkennungsmerkmalen. | |
EP0764906A2 (de) | Verfahren zum Betreiben eines durch ein Realzeit-Betriebssystem gesteuerten Realzeit-Computersystems | |
EP0799441B1 (de) | Verfahren zur steuerung von technischen vorgängen | |
DE102007051803A1 (de) | Verfahren und Vorrichtung zur Datenverarbeitung | |
WO2015086357A1 (de) | Verfahren zur beeinflussung eines steuerprogramms eines steuergeräts | |
DE102004059972B4 (de) | Thread-Scheduling-Verfahren, und Thread-List-Scheduler-Vorrichtung | |
WO1990002996A1 (de) | Betriebsprogramm für eine datenverarbeitungsanlage | |
DE10110444A1 (de) | Verfahren und Vorrichtung zum Ermitteln der Auslastung eines Rechengeräts | |
EP2126700B1 (de) | Steuerung des laufzeitverhaltens von prozessen | |
EP0584512A1 (de) | Verfahren zum zeitlichen Überwachen einer Programmabarbeitung |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20040730 |
|
AK | Designated contracting states |
Kind code of ref document: A2 Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT SE SI SK TR |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN |
|
18W | Application withdrawn |
Effective date: 20061024 |