Patent Application
20160314031
The present teachings relate to controller functionality.
Failure faults in controllers require fast responses to correct the fault to continue operations, particularly critical and safety operations. A frame overrun occurs when the processing delay of a signal exceeds its sampling period on the controller and is identified as a controller fault. Under such conditions, the system will either try to shut down to prevent undesired behavior related to the belated control command or reset the controller in hope to recover from the fault.
Under a shut down condition, the controller is shut down and the feature is no longer available while the fault is occurring; however, if the feature is a critical operation, then a shut down condition would not be a preferable option as the feature is required for continued operation of the vehicle.
Under a reset condition, the system must await until the controller resets itself. In a reset condition, there is a duration of time where the controller functionality is unavailable. Functionality of the controller being unavailable during any duration of time with respect to critical/safety features is unwanted, as even in a fail condition, the controller should be fail-operational. Therefore, there needs to be a method to continue functionality during frame overrun to continue operations.
An advantage of an embodiment is an uninterrupted operation of features controlled by a controller during a frame overrun condition. The technique identifies the task affecting the frame overrun the most from the plurality of tasks and reallocates functions within the task to other tasks for while the frame overrun condition having a slower cycle time than the task causing the overrun condition. As a result, the task causing the frame overrun condition is allowed to correct itself by completing functions within its expected working cycle since some of its respective functions are being temporarily executed within other tasks running at a slower rates allowing this respective task to maintain its expected working cycle. Tasks will continue to reallocate functions until the frame overrun condition is corrected. After correction, each task will be restored to its original configuration.
An embodiment contemplates a method of adaptively reconfiguring controller functions during a frame overrun. A frame overrun condition is detected. A respective task from a plurality of tasks is identified as a largest contributor to the frame overrun. A mitigation mode associated with the identified task is identified to correct the frame overrun. Functions within the identified task are reallocated to a second task until the frame overrun condition is corrected. The reallocated functions within the respective task are identified as a function of the identified mode.
A frame overrun is a condition when the controller 12 experiences the processing time longer than the data refreshing period and cannot process the incoming data at the rate the data is being supplied to the controller 12. This may occur when operating conditions of the vehicle (e.g., engine speed) lead to control computation increases thereby increasing in the number of reads demanded by the controller which may push other lower priority computations experiencing longer processing delay be beyond as the processing capability of the controller 12 is reached. The condition may also occur when temperature of a processor heats up within the controller 12 and the processing capabilities decrease. Under either condition, the controller 12 either shuts down, resets itself, or times out where functions are dropped within a respective task. Under such conditions, functionality of the feature is either permanently or temporarily lost. For example, if a frame overrun occurs where the function within the task affects an acceleration of a vehicle, then an acceleration demand by the driver may be ignored if the function is one that is dropped by the task due to the frame overrun. This can lead to customer dissatisfaction or bringing the vehicle in for service since the driver is under the assumption that the vehicle is not operating properly.
In step 21, the controller measures the task response time and determines whether a frame overrun is occurring in the controller. A task response time is defined as the time duration between the start of the task and the end of the task including all interferences such as interrupts, scheduler locking, preemption by other higher priority tasks etc. Frame overrun is determined by comparing the task response time and the period of the respective task. A task execution time is defined as the duration of time that task completes its operation without faults and interferences. A predetermined expected execution time is assigned to each task to compute workload increases. In normal execution, the task response time may vary, but should not exceed the task period.
To alleviate nuisance count overruns where the actual response time exceeds the task period by only a small number of times, thresholds are utilized. A threshold can be used to filter some measurement noises. In utilizing a threshold, a predetermined number of allowed frame overruns is assigned to each task. The threshold is preferably an integer expressing how many times a frame overruns after which the frame overrun must corrected. Alternatively, a non-integer may be used. Every time a frame overrun is detected, a count is increased for that task as a frame overrun. For some control functions, a lower amount of frame overruns are allowed due to oversampling; however when the threshold is reached, the workload must be adjusted to maintain stable control.
In step 22, the overrun count is updated based on whether the conditions are satisfied in step 21 for updating the overrun count.
In step 23, a determination is made as to whether the overrun count is greater than a count threshold. If the overall count is greater than the count threshold, then the routine proceeds to step 24. If the determination is made that the overrun count threshold is not exceeded, then the routine returns to step 20 were the controller continues to monitor for a frame overrun.
In step 24, workload efficacy is determined for each task for identifying the task introducing a largest increase of the execution time among each of the tasks. The direction is to identify the task causing the most significant increase in its execution time among all the tasks and reallocate some of its functions to other tasks running at a lower rates until the frame overrun disappears. To accomplish this, a workload factor is determined for each task. The workload factor is determined by the following formula:
where current_execution_timei is the actual execution time for task (i) and expected_execution_time is the predetermined execution expected for task (i).
A respective workload factor is identified for each respective task in the form of a percentage. A category is assigned to a task representing the level of the workload factor of that task. For example, for the calculated workload factor of task Tsk1 that falls within a range of 0-2%, the assigned category is “C1_Tsk1”; if the workload factor is within a range of 2%-7%, then the category is “C2_Tsk1”. Similarly, if the calculated workload factor for task Tsk2 is within a range of 0%-6%, then the assigned category is “C1_Tsk2”. It should be understood that the ranges as described herein are exemplary and both the ranges and assigned categories may be configured differently.
After each of the workload factors are calculated and assigned a category, a table is created that identifies the category assigned to each workload factor for each task. The table also associates a controller runtime mitigation mode for each category. The mitigation mode indicates how the functions will be distributed into different tasks. The table is illustrated as follows:
In step 25, the task with the highest workload factor is identified. The workload factor is then used to determine the category. This will uniquely identify a single entry in Table 1, which will lead to the target mitigation mode for the controller to run. As shown in the table 1, if a workload increase of 6% associated with task Tsk1 is identified as having the largest execution time change leading to the frame overrun, the category is then determined as C2_Tsk1, and therefore, the mode M21 is identified as the mitigation mode of the controller.
In step 26, based on the identified mode, associated tasks are identified which will run respective functions, also known as runnables. Based the associated tasks that will be executed for the respective mode, functions are reallocated by executing functions in respective tasks and inhibiting functions from being executed in other tasks.
A frame overrun detection module 52 reviews data from both the expected workload table 50 and the current workload table 51 and identifies the respective task causing the frame overrun as described above.
A mode selection module 53 receives input from the expected workload table 50, the current workload table 51, a mode selection table 54, and the frame overrun detection module 52, and determines what mode the routine should enter for correcting the frame overrun.
In block 55, the selected mode is identified and the respective target task or tasks 56 are selected to execute for reallocating functions to other tasks for relieving the frame overrun. The target task identified will have a slower cycle time (execution time) which provides more time than the original task for receiving and processing the data. For example, if the task causing the frame overrun reads and process data every 5 msec, then the target task may read and process data every 10 msec. As a result, data is only obtained every 10 msec which not only reduces the amount of data received by the processor over a duration of time, but allows processor more time to process data that includes data from re-allocated functions.
Based on the selected mode, one or more tasks 56 are executed. The tasks include conditional operands which determine which functions should be executed and which functions should be inhibited from execution with the task. Below illustrates an exemplary task causing the frame overrun:
The following is an example of the target task that is being used to reduce the frame overrun:
In the above examples, task Tsk1 is causing the frame overrun which indicates that the current processor cannot handle the amount of data being processed under the current scheme and mode M11 is identified by the mode selection module as the mode utilized to correct the fame overrun. As shown in the original task Tsk2, functions R15 and R16 are always executed unless mode M11 is enabled. Therefore, if a frame overrun is occurring caused by task Tsk1, then mode M11 is enabled and certain functions need are alleviated in task Tsk1 in order for the task to correct the frame overrun; otherwise, the task will continue to operate in a frame overrun mode. As a result, functions R15 and R16 are shifted to another task (e.g. Tsk2) which has a slower cycle time in comparison to task Tsk1.
As shown in task Tsk2, functions R15 and R16 are executed only if mode M11 is selected. That is, when mode M11 is not enabled, task Tsk2 will not execute functions R15 and R16; however, when mode M11 is enabled, task Tsk2 will execute functions R15 and R16 that were temporarily dropped from task Tsk1. This allows functions R15 and R16 which were executed every 5 msec to be executed every 10 msec. As a result, instead of dropping functions R15 and R16 completely, functions R15 and R16 are executed as part of another task at a slower cycle time which allows the functions to still be executed and allows the frame overrun associated with task Tsk1 to correct itself since it temporarily has less functions to execute.
It should also be noted that in task Tsk2, in order take on extra workload of functions R15 and R16, functions R22 and R23 are not executed in task Tsk2 while mode M11 is enabled. These respective functions are re-allocated to another task, for example Tsk3, so that task Tsk2 does not get behind and cause a frame overrun due to the additional workload of functions R15 and R16. Therefore, as opposed to dropping functions R22 and R23, these functions are re-allocated to another task Tsk3 operating at a cycle time slower than task Tsk2. If the frame overrun has not corrected itself, Tsk3 may re-allocate functions to a next slower cycle time task. This will continue until the frame overrun is corrected with respect to the task originally causing the frame overrun which is task Tsk1.
Once the frame overrun is corrected, the system will restore itself to the original configuration. As are result, the respective mode will be deselected, and each task will operate according to the original configuration prior to the frame overrun. The task structure is defined offline through analysis during the design stages of the controller. As a result, all re-allocation of functions to another task is preconceived and is thoroughly analyzed prior to implementation in the controller. The table below illustrates an example of reallocation table that illustrates the affected mode, the affected task (task_source), the respective functions in the task that are affected in the reallocation (runnables), and the target task (task_target) that the affected functions will be re-allocated to:
Referring again to
In step 28, a determination is made whether the frame overrun is corrected. If the frame overrun is not corrected, then a return is made to step 27 to continue to re-allocate functions among tasks based on the identified mode. If the determination is made in step 28 that the overrun is not corrected, then the routine proceeds to step 29 where the system is restored to its original configuration when no frame overrun is present. Restoration to its original configuration is performed by deselecting the respective mode chosen to correct the frame overrun. As a result, the re-allocation scheme is enabled and configured based on a respective mode identified by the mode selection module. The conditions set forth in each task are predetermined at design time, and the determination of which functions to execute or not execute in each task is set forth by the mode currently enabled.
That advantage described herein is an execution scheme that is predetermined for re-allocating functions within a controller for correcting frame overrun without having to drop functions permanently. The functions are reallocated but rather re-allocating functions to a different cycle time to alleviate workloads within a respective task causing the frame overrun, which allows the task to catch up to its current workload. The re-allocation of functions to a next slower cycle time should not be noticeable to user of the system such as a driver of a vehicle, since the functions are still executed, but just executed temporarily at a next slower time interval.
While certain embodiments of the present invention have been described in detail, those familiar with the art to which this invention relates will recognize various alternative designs and embodiments for practicing the invention as defined by the following claims.
