JP7409567B2 - Automotive computer control method and vehicle electronic control device - Google Patents

Description

Cross-reference of related applications

This international application claims priority based on Japanese Patent Application No. 2021-114366, which was filed with the Japan Patent Office on July 9, 2021. The entire contents are incorporated by reference into this international application.

The present disclosure relates to a method of controlling a vehicle computer and a vehicle electronic control device.

Patent Document 1 below describes a vehicle-use device that determines whether or not an abnormality has occurred in a program that is being executed, and switches the processing order of the program from a normal control scheduling pattern to a safety control scheduling pattern when an abnormality occurs in the program. An electronic control device is disclosed.

Patent No. 5446477

In Patent Document 1, a safety monitoring program detects an abnormality in a program including a normal control program, but after detecting the abnormality, the schedule is switched to a safety control scheduling pattern. However, the time-partitioned program that is the source of program execution after switching usually includes threads that monitor the control program, but does not include threads that originally perform functions (for example, non-functional safety requirements). It is presumed that this is not the case. As a result, it is inferred that after switching to the safety control schedule pattern, all functions, including the original functions in which no abnormality has occurred, are under degenerate control.

As a result of the inventor's detailed study, although this configuration allows safety control to be executed with priority, threads that are not prioritized in the safety control schedule may not be able to complete for a long time, and threads that are not prioritized in the safety control schedule, especially non-functional safety requirements. The problem was found that the threads were likely to be adversely affected.

More specifically, the technique disclosed in Patent Document 1 partitions threads for non-functional safety requirements and threads for functional safety requirements when an abnormality is detected in the safety monitoring program. By focusing the functional safety design only on the functional safety thread, the company aims to reduce the cost of system design. On the other hand, there is no mention of the real-time performance of non-functionally safe threads after switching to the safety control scheduling pattern. Furthermore, claim 1 of the above-mentioned Patent Document 1 states that the normal control program is excluded in the time partition after shifting to the safety control scheduling pattern. This can also be interpreted as degeneracy processing.

One aspect of the present disclosure is to provide a threaded vehicle computer control method or vehicle electronic control device in which all threads are likely to be executed within a specified time.

One aspect of the present disclosure provides an automotive computer control executed by a vehicle computer capable of executing a functional safety thread and at least one non-functional safety thread in parallel processing based on priorities defined in advance by a scheduler. It's a method. The functional safety thread represents a thread that calculates values related to vehicle safety. Furthermore, non-functionally safe threads refer to threads other than functionally safe threads.

In a method for controlling an automobile computer, an abnormality in a functional safety thread is detected, and when an abnormality in the functional safety thread is detected, the scheduler is changed to change the priority order.

According to such a control method, the priority order for thread execution can be changed only when an abnormality occurs in the functional safety thread. The safety mechanism of the functional safety thread detects an abnormality and executes the abnormal action.Even if the thread is waiting for execution because another thread is running, the safety mechanism of the functional safety thread can change the relative execution priority of both threads to ensure functional safety. This makes it easier to complete processing within an allowable time that ensures safety. In addition, it is possible to reduce as much as possible the chances of degenerating the original functions of non-functionally safe threads.

In other words, when changing the scheduler to switch to the schedule when an abnormality is detected, it is possible to execute the specified processing of the non-functional safety requirements after the specified processing of the thread of the functional safety requirements is executed. Scheduling that avoids degeneracy becomes possible. Therefore, it is possible to provide a configuration in which all threads are likely to be executed within the specified time.

FIG. 1 is a block diagram showing the configuration of a vehicle control system. FIG. 3 is a functional block diagram of a control calculation section. 3 is a flowchart of thread execution control processing. 12 is a flowchart of the first half of thread execution priority determination processing. 12 is a flowchart of the second half of thread execution priority determination processing. It is an explanatory diagram showing an example of a priority order rule. It is a timing chart which shows a 1st example of operation. It is a timing chart which shows a 2nd example of operation. 12 is a flowchart of the first half of the scheduler execution process during normal operation. 12 is a flowchart of the second half of the scheduler execution process during normal operation. 12 is a flowchart of the first half of the scheduler execution process during an abnormality. 12 is a flowchart of the second half of the scheduler execution process during an abnormality. It is a flowchart of the first half of the abnormality scheduler AN[1] execution process. It is a flowchart of the latter half of the abnormality scheduler AN[1] execution process. It is a flowchart of the first half of the abnormality scheduler AN[2] execution process. It is a flowchart of the latter half of the abnormality scheduler AN[2] execution process.

[1. Summary of this disclosure]
[1-1. background]
In the CASE (Connected, Autonomous, Shared & Services, Electric) and Maas (Mobility as a Service) society, more complex systems with three-way requirements such as functional safety, security, and SOTIF (Safety of the Intended Functionality) are required. Among these, it is necessary to consider the interaction of various requirements and exclusive control. In this case, it is meaningful to design an architecture that improves marketability by placing the functional safety of the system first, considering the balance between performance, convenience, and cost, and considering the differentiation of systems and products.

In particular, there are scalable and connected systems that utilize OTA (Over The Air) and 5G technologies. In a connected system, it is expected that the applications installed in the system will change sequentially between the SOP (Start Of Production) of the software installed in the vehicle and the life cycle after the SOP. It is inefficient and uneconomical to redo the program execution verification from the beginning each time there is a change, for example, each time an updated program is applied to the originally implemented software. Furthermore, this trend is expected to become more pronounced in software lifecycles that take security incident countermeasures into consideration.

Furthermore, in the future, many AIs that are said to be illogical will be implemented in vehicles. Ensuring functional safety, which emphasizes logic and proof once a system abnormality occurs, requires a system architecture that is highly robust against system abnormalities, component failures, security incidents, performance limits, or misuse. Ru.

[1-2. Challenges in implementing functional safety elements]
In the future, it is likely that domainization (eg, decentralization) and integration will be attempted to be optimized for each segment of the vehicle in various applications implemented in vehicles. At this time, there is a need to divide the integrated application into processes and ultimately control the schedule in a pseudo-parallel manner of threads that share CPU cores (hereinafter simply referred to as cores), memory, or input/output groups. It is essential. This situation is similar to control by an OS task manager implemented in PC software.

In the case of implementing functional safety elements, safety goals (SG) are set when an abnormality occurs in a component (hereinafter referred to as an element) for realizing a vehicle function (hereinafter referred to as an item). Set. Then, a safety mechanism (SM) is added to execute the safety goal within a permissible time (FTTI: Fault Tolerant Time Interval) while ensuring that there is no interference with elements other than functional safety. This procedure can be implemented even in systems where security or SOTIF is required. In this disclosure, in order to ensure the execution of a functionally safe SM, even when core processing of other threads that share a CPU core compete, a dynamic scheduling design method is utilized to ensure the execution of a functionally safe SM. Provide a design architecture that supports

[1-3. Effects of adopting architecture in this disclosure]
On the other hand, in conventional soft scheduling, time-trigger control (including periodic control, for example) or partitioning of each thread and interrupt control using kernel privileges are generally performed. In either case, scheduling directly associated with functional safety safety requirement specifications (for example, FTTI, etc.) is not dispatched.

In a typical automotive software process, the internal operating state of the assumed application is covered and verified down to the thread level, and it is implemented and released at the time of SOP without harmful bugs. In addition, typical embedded implementations of functional safety elements expect redundant reset control from other devices only when a serious runtime error occurs for software continuity (eg, watchdog reset). For other application program functional diagnostic abnormalities (for example, diagnostic diagnosis of sensors, loads, and internal functional components), task schedules are designed taking into consideration the worst execution time and execution cycle combinations of each task. Task schedule design includes, for example, priority setting, deadline monitoring, and the like.

In this case, as described above, after the SOP, it is checked at each specification change point whether an application that connects to a system that was not initially expected has an impact on the originally designed time schedule. Therefore, if necessary, it becomes necessary to make design changes to the architecture itself. In addition, in order to avoid this possibility as much as possible, specifications are adopted that are more on the safe side in the event of a system abnormality, and as a result, there is a concern that the vehicle will require excessive degeneracy control and its marketability will deteriorate.

Therefore, in this disclosure, even in the unexpected case where an unanticipated event enters from the world connected to the vehicle after the SOP, an architecture that prioritizes the processing of the functional safety safety mechanism (SM) in the event of a system abnormality is proposed. I will provide a. Unanticipated events include the addition of an application that was not initially expected, the connection of an application by an end user that was not expected by the product seller, or the occurrence of an incident. It also includes unexpected disturbances (for example, network abnormality, AI module deadlock, etc.).

According to the architecture of the present disclosure, it is possible to easily change the design and verify the software program changed over OTA. In addition, by relaxing vehicle degeneracy control as a safety requirement specification to ensure functional safety in the event of a system abnormality, it is expected that product appeal will be improved. Another advantage is that if an experienced designer establishes the architecture during base development, subsequent software maintenance can be easily done by a relatively inexperienced designer who can develop highly reliable branches. be. As a result, a more reusable and robust software life cycle can be created with less man-hours.

[2. Correspondence between the configuration of the embodiment and the configuration of the present disclosure]
In the embodiment, the processing executed by the control calculation unit 11 corresponds to the method for controlling an automobile computer in the present disclosure. Furthermore, in the embodiment, among the processes executed by the control calculation unit 11, the processes of S130, S150, and S170 correspond to the functions of the abnormality detection unit in the present disclosure, and the processes of S10, S20, S30, and S180 are This corresponds to the function of the order changing unit in the present disclosure.

[3. Embodiment]
Embodiments of the present disclosure will be described below with reference to the drawings.

[3-1. composition]
A vehicle control system 1 shown in FIG. 1 is mounted on a vehicle such as a passenger car, and includes an ECU 10. The ECU 10 is an electronic control device, and in particular, in this embodiment, is an electronic control device for a vehicle.

The vehicle control system 1 may include sensors 21 and various actuators 22. Further, the vehicle control system 1 may be configured to be able to communicate with a cloud server 23 outside the vehicle. The ECU 10, sensors 21, various actuators 22, and cloud server 23 are configured to be able to communicate with each other via the communication bus 5 or a wireless network (not shown). Note that the ECU 10 includes a power supply circuit and a watchdog timer 36, which will be described later.

The ECU 10 includes a control calculation section 11, an input/output section 12, and a memory 13. Further, the ECU 10 includes a vehicle application function 16 as part of the functions executed by the control calculation unit 11. Note that in the program that implements the vehicle application function 16, related threads are partitioned according to non-functional safety functional requirements and functional safety functional requirements.

The control calculation unit 11 is configured as, for example, a CPU. The control calculation unit 11 implements various functions such as the vehicle application function 16 by executing programs stored in the memory 13. The various functions executed by the control calculation unit 11 include processing using the control method of the automobile computer. The control calculation unit 11 executes multiple threads in a time-sharing manner using pseudo-parallel processing. Hereinafter, multiple threads will be referred to as a thread group.

The control calculation unit 11 implements various functions such as abnormality detection, abnormality treatment to ensure safety in response to abnormality detection, runtime error detection of the thread itself, and abnormality treatment in response to runtime error detection. Perform the calculation for.

The input/output section 12 is configured as a communication module that performs communication using, for example, the communication bus 5, and performs input/output control of data input/output to the ECU 10.

As shown in FIG. 2, the vehicle application function 16 includes an inter-core control thread control section 32, an intra-core control thread control section (functional safety requirements) 33 (hereinafter referred to as the functional requirements section 33), an intra-core control thread control section ( Non-Functional Safety Requirements) 34 (hereinafter referred to as Non-Functional Requirements Section 34).

The inter-core control thread control unit 32 has the following functions. That is,
(A1) A function to dispatch the core, memory 13, input/output unit 12, and runtime, specifically, a function as a dynamic scheduler (for example, it may perform thread control in cooperation with MMU/MPU),
(A2) A function to arbitrate threads executed by each core program (for example, an application), in detail, including processes such as starting, degenerating, ignoring, self-resetting, and external reset of the core program,
(A3) A function to output a watchdog signal to the power supply circuit and watchdog timer 36;
(A4) A function of instructing the functional requirements section 33 and the non-functional requirements section 34 to allocate resources and schedules;
Equipped with.

Each function of the inter-core control thread control section 32 is realized by the ECU 10 executing a program.

Next, the functional requirements unit 33 handles threads related to functional safety requirements (hereinafter referred to as functional safety threads). The functional safety thread represents a thread that calculates values related to vehicle safety (for example, values related to vehicle acceleration/deceleration, steering, etc.).

The functional requirements section 33 has the following functions. That is,
(B1) Memory 13, input/output unit 12, function to dispatch runtime, specifically function as a dynamic scheduler (for example, may perform thread control in cooperation with MMU/MPU),
(B2) A function that changes the scheduler to relatively raise the execution priority of the thread in which the abnormality has occurred;
(B3) For the inter-core control thread control unit 32, control execution priorities such as core occupancy time rate, safety mechanism requirements, FTTI, Automotive Safety Integrity Level (hereinafter referred to as ASIL), deadline information, etc. Ability to send sources to
Equipped with.

Each function of the functional requirement section 33 is realized by the ECU 10 executing a program.

Next, the non-functional requirements unit 34 handles non-functionally safe threads that are threads other than functionally safe threads. The non-functional requirement section 34 has the following functions. That is,
(C1) Memory 13, input/output unit 12, a function to dispatch runtime, in detail, a function as a dynamic scheduler (for example, thread control may be performed in cooperation with MMU/MPU),
(C2) A function that changes the scheduler to suspend running threads and relatively lower the execution priority of waiting threads;
(C3) A function of transmitting an information source for controlling execution priority such as core occupation time rate to the inter-core control thread control unit 32;
Equipped with.

Each function of the non-functional requirement section 34 is realized by the ECU 10 executing a program.

Note that the inter-core control thread control unit 32, functional requirements unit 33, and non-functional requirements unit 34 cannot continue execution when an abnormality occurs that would lead to a violation of the safety goal (SG) of functional safety. A notification is sent, and the notification that execution cannot be continued is shared between each.

[3-2. process]
[3-2-1. Thread execution control processing]
Next, the thread execution control process executed by the control calculation unit 11, particularly the inter-core control thread control unit 32, will be described using the flowchart of FIG. The thread execution control process is a process of acquiring thread execution priority tables set in each of the functional requirement section 33 and the non-functional requirement section 34, and executing processes in the order based on these tables. The thread execution control process is executed, for example, at a preset period.

In the thread execution control process, first, in S10, the control calculation unit 11 imports the thread execution priority table determined and rewritten by the functional requirement unit 33. The thread execution priority table is set according to the priority rules shown in FIG. Note that the priority rules will be described later.

Subsequently, in S20, the control calculation unit 11 imports the thread execution priority table determined and rewritten by the non-functional requirement unit 34. Subsequently, in S30, the control calculation unit 11 uses the function of the inter-core control thread control unit 32 to update the dispatch content of the core of the thread to be executed and the dynamic scheduler, and to update the dispatch content of the thread to be executed, and to update the dispatch content of the thread to be executed by each core program (for example, an application). Arbitrate threads.

In the dispatch content update, the control calculation unit 11 assigns the hardware resources to be used (for example, cores, memory 13, input/output unit 12) to the dynamic scheduler selected for each core based on thread execution information of each core. , runtime). Note that the inter-core control thread control unit 32 functions like a task manager in a typical personal computer.

Furthermore, in thread arbitration, the control calculation unit 11 effectively utilizes cores with low core utilization rates. Further, the control calculation unit 11 ensures non-interference so that the memory 13 and the input/output unit 12 shared between different programs of each core do not compete with each other. Specifically, the control calculation unit 11 coordinates with the dynamic scheduler of each core to arbitrate the memory 13, read/write attributes, runtime, etc.

Note that the control calculation unit 11 executes processes such as starting, degenerating, ignoring, self-resetting, and externally resetting the core program. Thereafter, the thread execution control process of FIG. 3 ends.

[3-2-2. Thread execution control processing]
Next, the thread execution priority determination process executed by the control calculation unit 11 will be described using the flowcharts of FIGS. 4A and 4B. The thread execution priority determination process uses the functions of the functional requirements section 33 and the non-functional requirements section 34 to select an appropriate schedule depending on the presence or absence of an abnormality in the functional safety thread, and causes the inter-core control thread control section 32 to This process requests the use of the selected schedule. The thread execution control process is executed, for example, at preset intervals. Note that if the control calculation unit 11 includes a plurality of cores, this process is executed for each core. Further, this process is executed with functional safety (hereinafter referred to as "constant SM") described as a constant periodic interrupt shown in FIG.

In the thread execution control process, first, in S110, the control calculation unit 11 determines whether there is a thread group waiting for execution to be executed by a scheduler timer interrupt. The scheduler timer interrupt includes being executed when an abnormality is detected in the functional safety thread. An abnormality in a functional safety thread is not only the detection of an abnormality in the function of a functional safety thread, but also includes, for example, an event in which a functional safety thread does not terminate normally within a specified time (i.e., a deadline), an event that causes an execution error, etc. do.

When the control calculation unit 11 determines in S110 that there is no interrupt thread group waiting for execution, the process proceeds to S120, executes the interrupt timer process, and then executes the thread execution priority determination process of FIGS. 4A and 4B. finish.

On the other hand, if the control calculation unit 11 determines in S110 that there is a scheduler timer interrupt thread group waiting for execution, the process moves to S130 and determines whether the abnormality in the functional safety thread is such that the execution of the thread group cannot be continued. Determine whether That is, it is determined whether or not the safety goal of functional safety (hereinafter referred to as SG) is violated. Whether or not the abnormality makes it impossible to continue the execution of the thread group is determined, for example, based on whether the type of abnormality is previously associated with an abnormality that makes it impossible to continue the execution of the thread group.

If the control calculation unit 11 determines in S130 that there is an abnormality that makes it impossible to continue the execution of the thread group, the process proceeds to S140, requests the inter-core control thread control unit 32 to control the execution of the thread group, and prevents system degradation. Implement controls. Here, for example, an interrupt thread prepared in advance, which is a functionally safe thread implemented under kernel interrupt control, may be implemented. After ensuring functional safety in this way, the thread execution priority determination process shown in FIGS. 4A and 4B ends.

On the other hand, if the control calculation unit 11 determines in S130 that there is an abnormality that allows the execution of the thread group to continue, the process proceeds to S150 and determines whether or not there is a thread group waiting for execution of an event interrupt to an IO port or the like. judge. Event interrupts here exclude forced interrupts by hardware.

If the control calculation unit 11 determines in S150 that there is a thread group of event interrupts waiting for execution, the process proceeds to S160, performs software maskable forced interrupt processing, and then proceeds to S170.

On the other hand, if the control calculation unit 11 determines in S150 that there is no event interrupt thread group waiting for execution, it skips S160 and proceeds to S170. Subsequently, in S170, the control calculation unit 11 detects an abnormality in the functional safety requirements and determines whether or not it is waiting for abnormality treatment. Waiting for abnormality treatment refers to a state in which the treatment for the abnormality has not been completed after the abnormality has been detected.

If the control calculation unit 11 detects an abnormality in the functional safety requirements in S170 and determines that it is waiting for abnormality treatment, the process proceeds to S180. In S180, the execution priority schedule of the thread waiting for execution is changed depending on whether the setting of the safety mechanism requirements for functional safety is to give priority to the remaining time for FTTI or to give priority to the safety level. That is, among the execution priority tables described later, one of the tables corresponding to an abnormality, ie, abnormality AN, FTTI priority rewriting AN[1], and ASIL priority rewriting AN[2], is selected.

This schedule change requires temporary suspension of non-functional safety requirements and priority execution of abnormalities in functional safety requirements. This request is realized by requesting the inter-core control thread control unit 32 to control the execution of the thread group. This request implements kernel interrupt control and early implements a functional safety thread (ie, an interrupt thread in this disclosure). After S180, the thread execution priority determination process of FIGS. 4A and 4B ends.

On the other hand, if the control calculation unit 11 determines in S170 that an abnormality of functional safety requirements has not been detected or that the abnormality treatment of functional safety requirements is not pending, the process proceeds to S190. In S190, the schedule for when all of the functional safety safety mechanisms are determined to be normal is selected, and the inter-core control thread control unit 32 is requested to control the execution of the thread group. That is, if no abnormality has occurred, or if the treatment after the abnormality has been completed, normal time N, which is a table corresponding to normal time, is selected from among the execution priority tables described later.

Subsequently, in S200, the control calculation unit 11 detects an abnormality in the non-functional safety requirements and determines whether or not it is waiting for abnormality treatment. If the control calculation unit 11 determines in S200 that an abnormality in the non-functional safety requirements has not been detected or that a non-functional safety requirement abnormality treatment is not pending, the process proceeds to S210.

In S210, the control calculation unit 11 requests the inter-core control thread control unit 32 to control the execution of a group of threads for processing non-functional safety requirements, thereby ensuring the continuation of processing of basic functions (e.g., corresponding to the original functions described above). do. At this time, the processing order is the same as when no abnormality in the functional safety thread is detected, so there is no deterioration in marketability. After S210, the thread execution priority determination process of FIGS. 4A and 4B ends.

On the other hand, if the control calculation unit 11 detects an abnormality in the non-functional safety requirements in S200 and determines that the abnormality treatment is pending, the control calculation unit 11 moves to S220, and controls the inter-core control thread regarding the abnormality treatment in the non-functional safety requirements. A request is made to the unit 32 to control the execution of the thread group. Thereafter, the thread execution priority determination process of FIGS. 4A and 4B ends.

[3-2-3. Priority rules]
Here, the priority order rules will be explained using FIG. 5. The priority rule is a correspondence relationship between a plurality of schedules that the functional requirements unit 33 and the non-functional requirements unit 34 can select in the thread execution priority determination process of FIGS. 4A and 4B, and the execution priority of each thread for each schedule. shows. The schedule is hereinafter also referred to as a thread execution priority table or simply a table.

As a plurality of tables, for example, normal state N, abnormal state AN, FTTI priority rewriting AN[1], and ASIL priority rewriting AN[2] are prepared. These tables have in common that the execution priorities are listed so that the initial diagnosis thread, the software maskable hardware interrupt thread, and the execution period interrupt thread are executed in this order. However, a plurality of threads are associated with each execution cycle interrupt thread, and the execution priority of each thread within the execution cycle interrupt thread is set to be different for each table.

For example, when the functional safety thread is normal and there is no abnormality, the table labeled "Normal time N" is selected. In this table, the priorities of non-functional safety threads 01 and 02, which are associated with non-functional safety requirements of the application thread layer, are the priorities of functional safety threads m1, n1, and n2, which are associated with functional safety requirements. is set higher than.

Further, if there is an abnormality in the functional safety thread, for example, a table labeled "AN at abnormality" is selected. In this table, the priorities of the functionally safe threads m1, n1, and n2 are set higher than the priorities of the non-functionally safe threads 01, 02.

In addition, if there is an abnormality in the functional safety thread, FTTI priority rewrite AN[1] or ASIL priority rewrite AN[2] may be selected depending on the situation.

Note that the priority order rules may be arbitrarily rewritten. For example, by using an automatic program from a formal design specification to implement executable code in flash memory, we can create a system that rewrites parts that may undergo design changes during the lifecycle according to the functional specification. It is also possible to construct. In particular, each table may be dynamically rewritten according to the FTTI of each thread waiting to be executed.

[3-2-4. First operation example]
A first example of operation in the configuration of this embodiment will be described using FIG. 6. This operation example is an example of a thread execution procedure when an abnormality is simultaneously detected for thread m1 and thread n1 in which all SM processing is not completed within the execution cycle of thread 01, which has a higher priority than the functional safety SM. shows. The first operation example is a scheduling example in which the remaining execution time with respect to FTTI, which is a functional safety requirement, is compared, and threads that should be processed earlier in terms of functional safety are given higher priority and processed.

In other words, when an abnormality in the functional safety thread is detected, the control calculation unit 11 adjusts the schedule in the FTTI so that the execution priority of the functional safety thread is relatively higher than the execution priority of the non-functional safety thread. Make changes. At this time, for the functional safety thread (that is, the interrupt thread) to be executed preferentially, a table is selected such that the waiting time limit is less than the FTTI.

Note that in FIG. 6, arrows indicate timings at which the timer interrupts of the three threads are synchronized. In this way, when three threads are waiting for execution, the thread with the highest priority is executed first.

As the table mentioned above, FTTI priority rewriting AN[1] is selected. Note that if the runtime of each thread exceeds its corresponding waiting time timer (that is, the limit waiting time in the present disclosure), the degeneracy process is set to be executed.

After execution of thread 01, an abnormality is detected in thread m1 and thread n1. At this time, if there is no change in the execution priority, the threads are executed in the order of threads 01, m1, and n1, as shown by the dotted line in FIG. Assuming that thread 01, which is executed first, is extended for some reason, if threads m1 and n1 perform abnormal handling (i.e. interrupt threads) and FTTI is set for each, the order of this thread will be changed. In this case, thread n1 does not meet the requirements of FTTI.

Therefore, when the thread m1 and the thread n1 detect an abnormality, the execution priority of the thread 01 is lowered by the scheduler than the thread m1 and the thread n1. Note that the thread 01 is set to have a higher execution priority than the thread m1 and the thread n1 when the functional safety abnormality detection function (SM) is normal.

As a result, as shown by the solid line in FIG. 6, thread n1 and thread m1 can be processed in the order of thread 01, and the specified abnormality handling of thread n1 and thread m1 is completed. will be delayed until In other words, the execution of thread 01 is delayed until the abnormality handling thread specified in the schedule is completed, and after the abnormality handling of the thread within the predetermined schedule is completed, the execution of thread 01 is started. At this time, the execution of thread 01 is not necessarily delayed until all the abnormalities are completed. Note that it is preferable that thread 01 be scheduled so as not to exceed the normal deadline monitoring timer.

[3-2-5. Second operation example]
In the first operation example, both functional safety requirements and non-functional safety requirements are described on the assumption that each related thread is controlled under the management of the same scheduler. That is, the thread execution order is managed mainly by using the scheduler function provided in the inter-core control thread control unit 32. However, as shown in the second operation example of FIG. 7, the scheduler that controls threads related to non-functional safety requirements and the scheduler that controls threads related to functional safety requirements may be made independent. That is, the inter-core control thread control unit 32 manages the thread execution order by using the scheduler function of the functional requirements unit 33 and the scheduler function of the non-functional requirements unit 34, respectively, and mediating these functions.

In this configuration, threads related to all functional safety requirements are aggregated under the management of each scheduler, and the execution of the functional safety safety mechanism is configured to be protected from any exclusive infringement factors and ensure safety. be able to. In this case, it is desirable that the inter-core control thread control unit 32 including the scheduler be configured to meet the functional safety requirements of the highest ASIL.

With such a configuration, non-functional safety requirements and functional safety requirements are guaranteed to have no interference from a design structure. Therefore, it becomes easier to design a structure to appropriately dispatch multi-threaded resources by focusing only on the ASIL difference of each thread in the functional safety requirements and the priority on the FTTI runtime.

In other words, functional safety requirements and non-functional safety requirements are reliably partitioned, increasing software reusability. As a result, it is possible to achieve both savings in architectural changes and verification man-hours required to comply with functional safety in the software life cycle, and improvement in the robustness of the implemented software. Note that the multi-thread resources include, for example, the memory 13, the schedule, and the input/output unit 12.

Further, the configuration of the second operation example is designed as follows, for example.

In order to guarantee FTTI for various functional safety requirements, the minimum interrupt cycle of the aggregated group of functional safety-related threads is scheduled based on the maximum allowable interrupt interval (that is, the interval that can guarantee FTTI even if the processing is delayed the most). For example, when periodic threads of 2, 4, 8, and 16 ms are aggregated, 2 ms is designed as a timer interrupt independent from the general OS.

The interrupt prohibition time in threads related to non-functional safety requirements is designed to be sufficiently shorter than 2 ms to ensure a 2 ms cycle interrupt.

[3-2-6. Normal scheduler execution processing]
The normal scheduler execution process executed by the control calculation unit 11 will be described using the flowcharts of FIGS. 8A and 8B. The normal scheduler execution process is a process that is executed according to the table of normal times N in a situation where no abnormality occurs in the functional safety thread. The normal scheduler execution process is executed, for example, at every preset period.

In the normal scheduler execution process, first, in S310, the control calculation unit 11 determines whether or not it is waiting for execution of an execution cycle interrupt, here, (minimum time interval)X (2 to the 0th power). If the control calculation unit 11 determines in S310 that the execution period interrupt is not waiting for execution, the process proceeds to S410.

On the other hand, if it is determined in S310 that the control calculation unit 11 is waiting for execution of the execution cycle interrupt (minimum time interval) Determine whether or not.

For example, if the control calculation unit 11 determines in S320 that the non-functionally safe thread 01 is waiting for execution, the process proceeds to S330, and a kernel call is made to dispatch the non-functionally safe thread 01 and execute the thread. Execute. At this time, even if a thread with a lower priority than the current thread is being executed, that thread is temporarily suspended (ie, preempted) to give priority to the execution of the current thread. Thereafter, the normal scheduler execution process of FIGS. 8A and 8B is ended.

On the other hand, if the control calculation unit 11 determines in S320 that the non-functionally safe thread 01 is not waiting for execution, the process proceeds to S340, and determines whether the non-functionally safe thread 02 is waiting for execution.

If the control calculation unit 11 determines in S340 that the non-functionally safe thread 02 is waiting for execution, the process proceeds to S350, and executes a kernel call to dispatch the non-functionally safe thread 02 and execute this thread. do. On the other hand, if the control calculation unit 11 determines in S340 that the non-functionally safe thread 02 is not waiting for execution, the process moves to S410.

Subsequently, in S410, the control calculation unit 11 determines whether the execution period interrupt (minimum time interval) X (2 to the power of m) is waiting for execution. If the control calculation unit 11 determines in S410 that the execution period interrupt is not waiting for execution, the process proceeds to S510.

On the other hand, if it is determined in S410 that the control calculation unit 11 is waiting for execution of the execution cycle interrupt, the process proceeds to S420, and determines whether or not it is waiting for execution of the functional safety thread m1.

When the control calculation unit 11 determines in S420 that the functional safety thread m1 is waiting for execution, the process proceeds to S430, and executes a kernel call to dispatch the functional safety thread m1 and execute the thread. Thereafter, the normal scheduler execution process of FIGS. 8A and 8B is ended.

On the other hand, if the control calculation unit 11 determines in S420 that the functional safety thread m1 is not waiting for execution, the process proceeds to S510.

In S510, the control calculation unit 11 determines whether the execution period interrupt (minimum time interval) X (2 to the n power) is waiting for execution. If the control calculation unit 11 determines in S510 that the execution period interrupt is not waiting for execution, it ends the normal scheduler execution processing of FIGS. 8A and 8B.

On the other hand, if the control calculation unit 11 determines in S510 that it is waiting for execution of an execution cycle interrupt, the process proceeds to S520, and determines whether or not it is waiting for execution of the functional safety thread n1.

When the control calculation unit 11 determines in S520 that the functional safety thread n1 is waiting for execution, the process proceeds to S530, and executes a kernel call to dispatch the functional safety thread n1 and execute the thread. At this time, even if a thread with a lower priority than this thread is running, it is temporarily suspended and priority is given to the execution of this thread. Thereafter, the normal scheduler execution process of FIGS. 8A and 8B is ended.

On the other hand, if the control calculation unit 11 determines in S520 that the functional safety thread n1 is not waiting for execution, the process proceeds to S540, and determines whether the functional safety thread n2 is waiting for execution.

When the control calculation unit 11 determines in S540 that the functional safety thread n2 is waiting for execution, the process proceeds to S550, and executes a kernel call to dispatch the functional safety thread n2 and execute the thread. Thereafter, the normal scheduler execution process of FIGS. 8A and 8B is ended.

On the other hand, if the control calculation unit 11 determines in S540 that the functional safety thread n2 is not waiting for execution, it ends the normal scheduler execution process of FIGS. 8A and 8B.

[3-2-7. Scheduler execution process in case of abnormality]
The abnormal scheduler execution process executed by the control calculation unit 11 will be described using flowcharts in FIGS. 9A, 9B, 10A, 10B, 11A, and 11B (hereinafter referred to as FIGS. 9A to 11B). In the abnormal scheduler execution process shown in FIGS. 9A to 11B, the thread execution order is changed to be different from the normal scheduler execution process according to the priority order rule. Note that the execution process of the abnormality scheduler AN[1] shown in FIGS. 10A and 10B corresponds to the process when FTTI priority rewriting AN[1] is selected. Further, the execution process of the abnormality scheduler AN[2] shown in FIGS. 11A and 11B corresponds to the process when ASIL priority rewriting AN[2] is selected. In other words, the abnormality scheduler AN[1] shown in FIGS. 10A and 10B and the abnormality scheduler AN[2] shown in FIGS. 11A and 11B correspond to the "scheduler selection table" shown in FIG. 5, respectively.

In the execution processing of the abnormal scheduler AN shown in FIGS. 9A and 9B, the processing from S410 to S550 is executed before the processing from S310 to S350. In the execution process of the abnormality scheduler AN[1] shown in FIGS. 10A and 10B, first, the process of S510 is executed, and then the processes of S540 to S550, S520 to S530, S410 to S430, and S310 to S350 are executed in this order. be done.

In the execution process of the abnormality scheduler AN[2] shown in FIGS. 11A and 11B, the processes are executed in the order of S510 to S550, S410 to S430, and S310 to S350.

[3-3. effect]
According to the first embodiment described in detail above, the following effects are achieved.

(3a) One aspect of the present disclosure is a vehicle computer (for example, a control calculation unit 11) capable of executing a functional safety thread and at least one non-functional safety thread in parallel processing based on priorities defined in advance by a scheduler. This is a method for controlling an automobile computer executed in a car. Parallel processing may include scheduling including parallel processing using multiple cores, and pseudo-parallel processing using time sharing using a certain core. The functional safety thread represents a thread that calculates values related to vehicle safety. Furthermore, non-functionally safe threads refer to threads other than functionally safe threads.

In a method for controlling an automobile computer, an abnormality in a functional safety thread is detected, and when an abnormality in the functional safety thread is detected, the scheduler is changed to change the execution priority of the thread.

According to such a control method, the priority order for thread execution can be changed only when an abnormality occurs in the functional safety thread. Therefore, while the functional safety thread is determining normality, scheduling that prioritizes the original functions of the vehicle is possible.

In other words, the situation in which the priority order is changed is limited to when an abnormality occurs in a functional safety thread, making it easy to design a schedule in which all threads are likely to be executed within the waiting time limit.

More specifically, according to the configuration that controls the execution priority of threads, the priority table of the scheduler is relatively rewritten. Therefore, even if the safety mechanism described above detects an abnormality and the thread that executes the abnormality action is waiting for execution because another thread is running, the relative execution priority of both threads is changed and the thread is able to function. Processing can be completed reliably within the allowable time that ensures safety. In addition, it is possible to reduce as much as possible the chances of degenerating the original functions of non-functionally safe threads.

In other words, in the present configuration, when the functional safety thread detects an abnormality, the prescribed functional safety requirements are processed with the highest priority, and the original functions (non-functional safety requirements) that are not directly related to the cause of the abnormality are degenerated as much as possible. can be avoided. In addition, it is possible to realize schedule design that ensures real-time performance.

Note that the functional safety thread may implement, for example, functional safety requirement specifications. In this case, it is the minimum execution unit that defines the execution priority when the original functions and safety mechanisms are implemented as software modules in semiconductor memory. Hardware resources are linked in a time-sharing manner. Functional safety requirements specifications generally refer to safety objectives and safety mechanisms (for example, fail-safe mechanisms and FTTI) that are defined by technical safety requirements (TSR) and technical safety concepts (TSC). may be defined. Note that the TSR is a technical specification that requests what safety protection functions are required to ensure safety when a system abnormality occurs. Furthermore, the TSC is a technical specification that describes how to realize the safety protection functions.

(3b) In one aspect of the present disclosure, when an abnormality is detected, execution of the non-functional safety thread is suspended until a preset abnormality treatment is completed. The execution of non-functionally safe threads is controlled by the kernel, with the priority of related threads being executed only during the period updated by the dynamic scheduler, or the execution of functionally safe threads that should be executed, or interrupt threads that are executed at abnormal times. Suspended until completed. Note that execution of the non-functionally safe thread does not suspend the non-functionally safe thread until all abnormal handling is completed.

According to this method, the execution of the non-functional safety thread is suspended until the abnormality handling is completed, so the prescribed abnormality handling is executed with the highest priority, and after the prescribed abnormality handling is completed, the suspended non-functional safety thread is It is possible to return to thread execution.

(3c) In one aspect of the present disclosure, the estimated time from when an abnormality is detected until a dangerous event occurs in a vehicle is referred to as FTTI (Fault Tolerant Time Interval). When an abnormality is detected, the FTTI changes the schedule so that the execution priority of the functional safety thread is relatively higher than the execution priority of the non-functional safety thread.

According to such a method, a non-functionally safe thread can be temporarily suspended in consideration of FTTI.

(3d) In one aspect of the present disclosure, kernel interrupt control is used to detect whether or not there is an abnormality in the functional safety thread, and if an abnormality is detected, the schedule is changed.

According to such a method, since kernel interrupt control is implemented, it is possible to promptly deal with an abnormality.

(3e) In one aspect of the present disclosure, a functional safety mechanism (SM) that diagnoses whether or not an abnormality in a functional safety thread is detected is implemented as a thread, and a scheduler is activated depending on whether or not an abnormality is detected. Determine whether a change is necessary and switch the scheduler.

According to such a method, it is possible to determine whether or not to change the scheduler, and to switch the scheduler when it is necessary to change the scheduler. Note that the determination of whether or not the scheduler needs to be switched is preferably performed at an appropriate timing that allows the scheduler to be switched in time.

Further, as a main control method for scheduler switching, as shown in FIG. 5, a method of arranging functional safety constant SMs for all periodic interrupts (for example, arranging them for the shortest periodic interrupt) can be adopted. Alternatively, a method can be adopted in which the functional safety SM is woken up by a HW interrupt handler.

(3f) In one aspect of the present disclosure, at least an interrupt thread implemented under kernel interrupt control has a waiting time limit that represents the upper limit of the time from receiving an instruction to be executed until the thread is executed. is set. The interrupt thread limit latency is set to be less than the FTTI.

According to such a method, the interrupt thread can be executed before the FTTI, so the interrupt thread can be executed more safely.

(3g) In one aspect of the present disclosure, the interrupt thread, the functionally safe thread, and the non-functionally safe thread have a waiting time limit that represents the upper limit of the time from when the thread receives an instruction to be executed until the thread is executed. is set. If the waiting time limit (Twait_NSR) of a thread other than the interrupt thread exceeds before the interrupt thread is executed (before Twait_SR is exceeded), the system corresponding to the other thread is degraded. When the system is degenerated, for example, a restriction mode that restricts some of the original functions, a shift control mode that requests manual operation by the driver, etc. may be implemented when an automatic driving system abnormality occurs.

According to this method, when other threads such as non-functionally safe threads cannot be executed within the waiting time limit, the system corresponding to the other threads is degraded, so that the vehicle can be operated more safely and conveniently. can be controlled.

(3h) In one aspect of the present disclosure, an abnormality may be detected in a plurality of functional safety threads. An interrupt thread is executed for each thread that detects an abnormality, and at this time, the execution priority of the interrupt thread is increased in descending order of the remaining time relative to the limit waiting time (i.e., the execution priority of the interrupt thread is change the contents of the scheduler so that it is higher.

According to such a method, when a plurality of interrupt threads are executed in response to detection of an abnormality in a plurality of functional safety threads, the interrupt threads can be executed in descending order of remaining time relative to the limit waiting time. Therefore, it is possible to prevent a situation in which any of the interrupt threads is not executed within the waiting time limit.

(3i) One aspect of the present disclosure provides a vehicle electronic control device (this invention) capable of executing at least one functional safety thread and at least one non-functional safety thread in parallel processing based on priorities defined in advance by a scheduler. This is the control calculation unit 11) in the disclosure.

The abnormality detection unit is configured to detect an abnormality in the functional safety thread. The order change unit changes the scheduler and changes the priority order when an abnormality is detected in the functional safety thread and abnormality treatment is required.

According to such a configuration, the priority order for thread execution can be changed only when an abnormality occurs in the functional safety thread.

(3j) In particular, a vehicle electronic control device can configure a system in which a plurality of cores are implemented and threads share hardware resources such as cores and memory in a time-sharing manner using a scheduler. In such systems, when the safety mechanism of the functional safety thread detects an abnormality, it is possible to temporarily suspend execution of other threads and complete the abnormality treatment within the system allowable time, or to use a core with sufficient time. It becomes possible to preferentially use memory resources.

According to such a configuration, it is possible to further reduce the potential cases in which the execution time becomes critical for the system as a whole, that is, situations in which threads do not finish within the permissible time frequently occur, and a highly robust system can be achieved. It becomes possible to construct. In addition, with regard to ensuring the safety of the entire system, by designing a system with sufficient execution time, it is easy to improve marketability by reducing the need for degenerate design of system functions and ensuring the original functions of the system. Become.

[4. Other embodiments]
Although the embodiments of the present disclosure have been described above, the present disclosure is not limited to the above-described embodiments and can be implemented with various modifications.

(4a) In the above embodiment, an FTTI is associated with each functional safety thread, but the present invention is not limited to this. For example, instead of or in addition to FTTI, each functional safety thread may be associated with an Automotive Safety Integrity Level (ASIL). In this case, an abnormality is detected in multiple functional safety threads, and an interrupt thread is executed for each thread that detects the abnormality. At this time, the execution priority of the interrupt thread is increased in descending order of automotive safety level. You may change the contents of the scheduler as shown below. For example, the control calculation unit 11 may dynamically rewrite the abnormality scheduler AN[2] shown in FIG. 5 so that each thread is executed in descending order of vehicle safety level.

According to this method, threads are executed in descending order of vehicle safety level, so threads that should be executed with higher priority can be executed with priority.

(4b) Although the above embodiment does not mention the arrangement of each component 11, 12, 13, 16 that constitutes the ECU 10, for example, the actual device of each component 11, 12, 13, 16 is 1 It can be configured with one or more SOCs (System On Chips).

Further, for example, in each function of the vehicle application function 16 shown in FIG. 2, the functions within the dashed line section 31 are realized by one SOC that implements the OS, and the functions outside the dashed line section 31 are realized by a different SOC from the above-mentioned SOC. May be realized. That is, the functions of the inter-core control thread control unit 32 and the functional requirements unit 33 may be realized by one SOC that implements the OS, and the functions of the non-functional requirements unit 34 may be realized by a different SOC from the above-mentioned SOC. .

According to such a configuration, overhead can be reduced and real-time performance can be improved.

(4c) The control calculation unit 11 and its method described in the present disclosure are provided by configuring a processor and memory programmed to execute one or more functions embodied by a computer program. It may also be realized by a dedicated computer. Alternatively, the control calculation unit 11 and the techniques described in this disclosure may be implemented by a dedicated computer provided by a processor configured with one or more dedicated hardware logic circuits. Alternatively, the control calculation unit 11 and its method described in the present disclosure may be implemented using a processor configured with a processor and memory programmed to execute one or more functions, and one or more hardware logic circuits. It may also be implemented by one or more dedicated computers configured in combination. The computer program may also be stored as instructions executed by a computer on a computer-readable non-transitory tangible storage medium. The method of realizing the functions of each part included in the control calculation unit 11 does not necessarily need to include software, and all the functions may be realized using one or more pieces of hardware.

(4d) A plurality of functions of one component in the above embodiment may be realized by a plurality of components, and a function of one component may be realized by a plurality of components. . Further, a plurality of functions possessed by a plurality of constituent elements may be realized by one constituent element, or one function realized by a plurality of constituent elements may be realized by one constituent element. Further, a part of the configuration of the above embodiment may be omitted. Further, at least a part of the configuration of the above embodiment may be added to or replaced with the configuration of other embodiments.

(4e) In addition to the vehicle control system 1 described above, devices such as a vehicle control device that are components of the vehicle control system 1, a program for making a computer function as the device, and non-removable devices such as a semiconductor memory in which this program is recorded. The present disclosure can also be implemented in various forms, such as in various methods, including a transitional physical storage medium and a method for controlling an automobile computer.

Claims (11)

At least one functional safety thread representing a thread that calculates values related to vehicle safety, such as acceleration, deceleration, and steering of the vehicle, and at least one non-functional safety thread representing a thread other than the functional safety thread. A method for controlling a vehicle computer executed by a vehicle computer (11) capable of executing parallel processing based on priorities defined by a scheduler, the method comprising:
detecting an abnormality in the functional safety thread;
A method for controlling an automobile computer, comprising changing the priority order by changing the scheduler when an abnormality in the functional safety thread is detected. A method for controlling an automobile computer according to claim 1, comprising :
The estimated time from when the abnormality is detected to when a dangerous event occurs in the vehicle is defined as FTTI (Fault Tolerant Time Interval), and when the abnormality is detected, execution priority is given to the functional safety thread within the FTTI. A method for controlling an automobile computer, comprising changing a schedule so that the execution priority of the non-functional safety thread is relatively higher than the execution priority of the non-functional safety thread. A method for controlling an automobile computer according to claim 1 or 2, comprising:
A method for controlling an automobile computer, wherein when the abnormality is detected, execution of the non-functional safety thread is suspended until a preset abnormality treatment is completed. A method for controlling an automobile computer according to claim 2, comprising:
A method for controlling a computer for an automobile, using kernel interrupt control, detecting whether or not there is an abnormality in the functional safety thread, and changing the schedule when the abnormality is detected. A method for controlling an automobile computer according to claim 4,
A functional safety mechanism for diagnosing whether or not an abnormality in the functional safety thread is detected is implemented as a thread, and depending on whether or not the abnormality is detected, it is determined whether or not to change the scheduler. A method of controlling an automobile computer that performs switching. A method for controlling an automobile computer according to claim 4 or 5, comprising:
At least the interrupt thread executed under the interrupt control of the kernel is set with a waiting time limit representing the upper limit of the time from receiving an instruction to be executed until the thread is executed;
The limit waiting time of the interrupt thread is set to be less than the FTTI. 7. A method for controlling an automobile computer according to claim 6,
The interrupt thread, the functional safety thread, and the non-functional safety thread have the waiting time limit set,
A method for controlling an automobile computer, comprising: degenerating a system corresponding to a thread other than the interrupt thread when the time until the interrupt thread is executed exceeds a waiting time limit of a thread other than the interrupt thread. A method for controlling an automobile computer according to claim 6 or 7,
Detects abnormalities in multiple functional safety threads,
The interrupt thread is executed for each thread that detects the abnormality, and at this time, the contents of the scheduler are changed so that the execution priority of the interrupt threads is increased in descending order of remaining time relative to the limit waiting time. computer control method. A method for controlling an automobile computer according to any one of claims 6 to 8,
An automobile safety level is associated with each interrupt thread,
Detects abnormalities in multiple functional safety threads,
The interrupt thread is executed for each thread that detects the abnormality, and at this time, the contents of the scheduler are changed so that the execution priority of the interrupt threads is increased in descending order of the vehicle safety level. How to control a computer. At least one functional safety thread representing a thread that calculates values related to vehicle safety, such as acceleration, deceleration, and steering of the vehicle, and at least one non-functional safety thread representing a thread other than the functional safety thread. A vehicle electronic control device (10) capable of executing parallel processing based on priorities defined by a scheduler,
an abnormality detection unit (S130, S150, S170) configured to detect an abnormality in the functional safety thread;
An electronic control device for a vehicle, comprising: an order changing unit (S10, S20, S30, S180) that changes the scheduler and changes the priority order when an abnormality in the functional safety thread is detected. A vehicle electronic control device (10) according to claim 10 ,
The order changing unit sets the estimated time from when the abnormality is detected to when a dangerous event occurs in the vehicle as an FTTI (Fault Tolerant Time Interval), and when the abnormality is detected, the FTTI A vehicle electronic control device configured to change a schedule such that the execution priority of the functional safety thread is relatively higher than the execution priority of the non-functional safety thread.

Images