WO2023281766A1

WO2023281766A1 - Automotive computer control method and vehicular electronic control device

Info

Publication number: WO2023281766A1
Application number: PCT/JP2021/045351
Authority: WO
Inventors: 宏治今井
Original assignee: 株式会社デンソー
Priority date: 2021-07-09
Filing date: 2021-12-09
Publication date: 2023-01-12
Also published as: JP7409567B2; JPWO2023281766A1

Abstract

This automotive computer control method is executed by a vehicular computer (11) that is capable of executing, by using parallel processing based on priorities pre-defined by a scheduler, at least one functional safety thread representing a thread for calculating a value related to vehicle safety and at least one non-functional safety thread representing a thread other than said functional safety thread, and the method involves: detecting abnormality in a functional safety thread; and, upon detection of the abnormality in the functional safety thread, changing the scheduler and alter the priorities.

Description

Automotive computer control method and vehicle electronic control device

Cross-reference to related applications

This international application claims priority based on Japanese Patent Application No. 2021-114366 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 computer for a vehicle and an electronic control device for a vehicle.

Patent Document 1 below describes a vehicle application that determines whether or not an abnormality has occurred in a program 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 controller is disclosed.

Japanese Patent No. 5446477

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

As a result of the inventor's detailed study, although safety control can be executed with priority in this configuration, non-prioritized threads, especially non-functional safety requirements, such as the non-prioritized threads being unable to complete for a long time in the safety control schedule A problem was found that the thread is likely to be adversely affected.

More specifically, the technology of Patent Document 1 partitions non-functional safety requirement threads and functional safety requirement threads when an abnormality is detected in the safety monitoring program. And by focusing only on the functional safety thread in functional safety design, we aim to reduce the cost of system design. On the other hand, no mention is made of the real-time nature of non-functionally safe threads after switching to the safety control scheduling pattern. In addition, claim 1 of the above Patent Document 1 states that the normal control program is excluded in the time partition after shifting to the safety control scheduling pattern. It can also be interpreted as degenerate processing.

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

One aspect of the present disclosure is control of a vehicle computer executed by a vehicle computer capable of executing a functional safety thread and at least one non-functional safety thread in parallel based on a pre-defined scheduler priority. The method. A functional safety thread represents a thread that computes safety-related values for the vehicle. Also, a non-functionally safe thread represents a thread other than a functionally safe thread.

In the automotive computer control method, an abnormality in the functional safety thread is detected, and when an abnormality in the functional safety thread is detected, the scheduler is changed to change the priority.

According to this control method, the priority of thread execution can be changed only when an abnormality occurs in the functional safety thread. Even if the safety mechanism of the functional safety thread detects an abnormality and the thread that executes the abnormal action is waiting for execution because another thread is running, the relative execution priority of both threads is changed to achieve functional safety. It is possible to make it easier to complete the processing within the allowable time that ensures the safety of the system. In addition, it is possible to minimize the chances of degenerating the original functions of non-functionally safe threads.

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

1 is a block diagram showing the configuration of a vehicle control system; FIG. 3 is a functional block diagram of a control calculation unit; FIG. 8 is a flowchart of thread execution control processing; FIG. 10 is a flowchart of the first half of thread execution priority determination processing; FIG. FIG. 11 is a flowchart of the second half of thread execution priority determination processing; FIG. FIG. 4 is an explanatory diagram showing an example of priority rules; 4 is a timing chart showing a first operation example; 9 is a timing chart showing a second operation example; FIG. 11 is a flowchart of the first half of normal scheduler execution processing; FIG. FIG. 11 is a flowchart of the second half of normal scheduler execution processing; FIG. FIG. 10 is a flowchart of the first half of the scheduler execution process in the event of an abnormality; FIG. FIG. 10 is a flowchart of the second half of the scheduler execution process in the event of an abnormality; FIG. FIG. 13 is a flowchart of the first half of the execution process of the scheduler AN[1] in abnormal conditions; FIG. FIG. 13 is a flowchart of the second half of the abnormal scheduler AN[1] execution process; FIG. FIG. 10 is a flowchart of the first half of the abnormal scheduler AN[2] execution process; FIG. FIG. 13 is a flowchart of the second half of the abnormal scheduler AN[2] execution process; FIG.

[1. Overview of the present disclosure]
[1-1. background]
In the CASE (Connected, Autonomous, Shared & Services, Electric) and Maas (Mobility as a Service) societies, more complex systems with various requirements such as functional safety, security, and SOTIF (Safety of the Intended Functionality) become a triad. In doing so, it is necessary to consider the interaction of various requirements and exclusive control. In doing so, it is meaningful to think about the differentiation of systems and products by considering the balance between performance, convenience, and cost, and designing an architecture that improves marketability, with the functional safety of the system as the first priority.

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

In addition, many AIs that are said to be illogical will be implemented in vehicles in the future. Functional safety, which emphasizes logic and proof when a system malfunction occurs, requires a highly robust system architecture even in the event of system malfunction, component failure, security incident, performance limit, or misuse. be.

[1-2. Issues in implementing functional safety elements]
In the future, it is expected that various applications installed in vehicles will try to optimize domainization (for example, decentralization) and integration for each segment of the vehicle. In this case, there is a need to divide the integrated application into processes, and finally to schedule and control threads sharing a CPU core (hereinafter simply referred to as a core), memory, or an input/output group in a pseudo-parallel manner. It is essential. This situation is similar to the control of the OS task manager implemented in PC software.

In the case of implementing functional safety elements, safety goals (SG: Safety Goals) are set when an abnormality occurs in a component (hereafter, element) to realize a vehicle function (hereafter, item). set. Then, a safety mechanism (SM) is added, and the safety goal is executed within the allowable time (FTTI: Fault Tolerant Time Interval) while ensuring that there is no interference with elements other than functional safety. This procedure can be implemented without exception in systems requiring security or SOTIF. In the present disclosure, in order to ensure execution of functionally safe SM, even when core processing of other threads sharing the CPU core competes, a dynamic scheduling design method is utilized to execute functionally safe SM. Provide a collateral design architecture.

[1-3. Effect of adopting architecture in the present disclosure]
On the other hand, in conventional soft scheduling, it is common to perform time-trigger control (including periodic control, for example) or partition each thread and perform interrupt control with kernel privilege. Neither case dispatches scheduling that is directly associated with the safety requirement specification of functional safety (eg, FTTI, etc.).

In the general automotive software process, the internal operating state of the assumed application is covered and verified up to the thread level, and is implemented and released at the time of SOP without harmful bugs. Also, typical embedded implementations of functional safety elements expect redundant reset control from other devices only when serious runtime errors occur in software continuation (eg, watchdog reset). Then, for functional diagnosis abnormalities of other application programs (for example, diagnostic diagnosis of sensors, loads, and internal functional components), a task schedule is designed in consideration of the worst execution time of each task and combinations of execution cycles. Task schedule design includes, for example, priority setting, deadline monitoring, and the like.

In this case, as described above, after the SOP, we will check each time the specifications change to see if the application that leads to the system that was not initially expected will affect the originally designed time schedule. Therefore, it is necessary to change the design of the architecture itself, if necessary. Also, in order to avoid this possibility as much as possible, specifications that are more on the safe side are adopted when the system is abnormal, and as a result, there is a concern that the degeneration control will be excessive as a vehicle and the marketability will decrease.

Therefore, in the present disclosure, an architecture that prioritizes the processing of the safety mechanism (SM) of functional safety in the event of an abnormality in the system even in the event that an unexpected event enters from the world connected to the vehicle after SOP. I will provide a. Unanticipated events include application additions that were not originally anticipated, application connections by end users that were not anticipated by the product seller, and incidents that occurred. It also includes unexpected disturbances (for example, network anomalies, AI module deadlocks, etc.).

According to the architecture of the present disclosure, it is possible to simplify design changes and verifications of OTA-modified software programs. In addition, by loosening the degeneracy control of the vehicle as a safety requirement specification for ensuring functional safety in the event of system failure, the effect of improving marketability can be expected. In addition, if a highly experienced designer establishes the architecture in the base development, there is an advantage that subsequent software maintenance can be easily performed by a relatively inexperienced designer with highly reliable branch development. be. As a result, a more reusable and robust software lifecycle can be built 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 control method of the automobile computer in the present disclosure. 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 It corresponds to the function of the order changing unit in the present disclosure.

[3. embodiment]
Hereinafter, embodiments of the present disclosure will be described with reference to the drawings.

[3-1. Constitution]
A vehicle control system 1 shown in FIG. 1 is mounted in a vehicle such as a passenger car, for example, and includes an ECU 10 . The ECU 10 is an electronic control unit, particularly an electronic control unit for a vehicle in this embodiment.

The vehicle control system 1 may include sensors 21 and various actuators 22. Further, the vehicle control system 1 may be configured to communicate with the cloud server 23 outside the vehicle. The ECU 10, the sensors 21, various actuators 22, and the cloud server 23 are configured to be able to communicate with each other via the communication bus 5, a wireless network (not shown), or the like. 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 unit 11, an input/output unit 12, and a memory 13. The ECU 10 also includes a vehicle application function 16 as part of the functions executed by the control calculation unit 11 . In the program that implements the vehicle application function 16, related threads are partitioned according to the non-functional safety functional requirements and the 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 a vehicle application function 16 by executing programs stored in the memory 13 . Various functions executed by the control calculation unit 11 include processing using the control method of the automobile computer. The control calculation unit 11 performs pseudo-parallel processing on a plurality of threads in a time-sharing manner. A plurality of threads is hereinafter referred to as a thread group.

Note that the control calculation unit 11 implements various functions such as abnormality detection, abnormality treatment for ensuring safety in response to the abnormality detection, run-time error detection of the thread itself, and abnormality treatment for dealing with the run-time error detection. perform the operation for

The input/output unit 12 is configured, for example, as a communication module that performs communication using the communication bus 5 or the like, and controls input/output of data input/output to/from the ECU 10 .

The vehicle application function 16 includes, as shown in FIG. non-functional safety requirements) 34 (hereinafter referred to as non-functional requirement part 34).

The inter-core control thread control unit 32 has the following functions. i.e.
(A1) Core, memory 13, input/output unit 12, function of dispatching runtime, more specifically, function as a dynamic scheduler (for example, thread control may be performed in cooperation with MMU/MPU),
(A2) A function to arbitrate threads executed by each core program (e.g., application), in particular, core program startup, degeneration, ignore, self-reset, external reset, etc.
(A3) a function of outputting 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;
Prepare.

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

Next, the functional requirements section 33 handles threads related to functional safety requirements (hereinafter referred to as functional safety threads). A 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 requirement part 33 has the following functions. i.e.
(B1) Function of dispatching memory 13, input/output unit 12, and runtime, more specifically, function as a dynamic scheduler (for example, thread control may be performed in cooperation with MMU/MPU);
(B2) A function of changing the scheduler so as to relatively raise the execution priority of the thread in which the error occurred;
(B3) Control execution priority of core occupancy rate, safety mechanism requirements, FTTI, Automotive Safety Integrity Level (ASIL), deadline information, etc. for the inter-core control thread control unit 32. the ability to send sources of information to
Prepare.

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

Next, the non-functional requirements part 34 handles non-functional safety threads, which are threads other than functional safety threads. The non-functional requirement part 34 has the following functions. i.e.
(C1) Function of dispatching memory 13, input/output unit 12, runtime, more specifically, function as a dynamic scheduler (for example, thread control may be performed in cooperation with MMU/MPU);
(C2) A function of changing the scheduler so as to interrupt a thread in execution and relatively lower the execution priority of a thread waiting to be executed;
(C3) a function of transmitting an information source for controlling the execution priority such as the core occupancy rate to the inter-core control thread control unit 32;
Prepare.

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

Note that the inter-core control thread control unit 32, the functional requirement unit 33, and the non-functional requirement unit 34 cannot continue execution when an abnormality occurs such that the continuation of thread execution violates the safety goal (SG) of functional safety. Notifications are sent, and execution continuation impossibility notifications are shared by each.

[3-2. process]
[3-2-1. Thread execution control processing]
Next, the thread execution control processing 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 obtaining the thread execution priority tables set in the functional requirement part 33 and the non-functional requirement part 34 and executing the processes in the order based on these tables. The thread execution control process is performed, for example, at preset intervals.

In the thread execution control process, first, in S10, the control calculation unit 11 takes in the thread execution priority table determined and rewritten by the function 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 takes in 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 contents of the core of the thread to be executed and the dynamic scheduler, and execute each core program (for example, an application). Arbitrate threads.

In the dispatch content update, the control calculation unit 11 updates the hardware resources to be used (for example, the core, the memory 13, the input/output unit 12 , runtime) allocation review. The inter-core control thread control unit 32 functions like a task manager in a general personal computer.

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

It should be noted that the control calculation unit 11 performs processing such as core program activation, degeneracy, ignoring, self-resetting, and external resetting. After that, 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 with reference to the flowcharts of FIGS. 4A and 4B. The thread execution priority determination process uses the functions of the functional requirement section 33 and the non-functional requirement section 34 to select an appropriate schedule according to the presence or absence of an abnormality in the functional safety thread, and the inter-core control thread control section 32: This is the process of requesting to use the selected schedule. The thread execution control process is performed, for example, at preset intervals. It should be noted that if the control calculation unit 11 has a plurality of cores, this processing is executed for each core. Further, this process is executed in functional safety (hereinafter referred to as constant SM) described as constant periodic interrupts shown in FIG.

In the thread execution control process, first, at S110, the control calculation unit 11 determines whether or not there is a thread group waiting to be executed by a scheduler timer interrupt. A scheduler timer interrupt is included that takes place when an anomaly is detected in the functional safety thread. Abnormality of the functional safety thread includes not only the detection of abnormalities in the function of the functional safety thread, but also events such as the failure of the functional safety thread to terminate normally within the specified time (i.e. deadline), and the occurrence of execution errors. do.

When the control operation unit 11 determines in S110 that there is no execution waiting for the interrupt thread group, the control operation unit 11 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 operation unit 11 determines in S110 that there is a wait for the execution of the thread group of the scheduler timer interrupt, it proceeds to S130 to determine whether the abnormality of the functional safety thread is an abnormality that prevents the thread group from continuing execution. determine whether That is, it is determined whether or not the safety goal (hereinafter referred to as SG) of functional safety is violated. Whether or not there is an abnormality that prevents the execution of the thread group from continuing is determined, for example, by determining whether or not the type of abnormality is associated in advance with an abnormality that prevents the execution of the thread group from continuing.

If the control operation unit 11 determines in S130 that there is an abnormality in which the execution of the thread group cannot be continued, the control operation unit 11 proceeds to S140, requests the inter-core control thread control unit 32 to control the execution of the thread group, and degenerates the system. Enforce controls. Here, for example, an interrupt thread prepared in advance, which is a functional safety thread that is executed under the interrupt control of the kernel, may be executed. After ensuring the functional safety in this way, the thread execution priority determination process of FIGS. 4A and 4B is terminated.

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

When the control calculation unit 11 determines in S150 that there is an event interrupt thread group waiting to be executed, it 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 to be executed, 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 an abnormality treatment. Abnormality action waiting means a state in which the action against the abnormality has not been completed after the detection of the abnormality.

When the control calculation unit 11 detects an abnormality in the functional safety requirements in S170 and determines that it is waiting for an abnormality treatment, it proceeds to S180. In S180, the execution priority schedule of threads waiting for execution is changed depending on whether the setting of the safety mechanism requirements for functional safety prioritizes the remaining time for FTTI or prioritizes the safety level. That is, any one of the abnormal time AN, FTTI priority rewrite AN[1], and ASIL priority rewrite AN[2], which is a table corresponding to an abnormality, is selected from the execution priority table described later.

This schedule change requires the temporary suspension of non-functional safety requirements and the handling of abnormalities in functional safety requirements to be prioritized. This request is realized by requesting the inter-core control thread control unit 32 to control the execution of the thread group. This request causes the kernel's interrupt control to be enforced and the functional safety thread (ie, the interrupt thread in this disclosure) to be enforced early. 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 the functional safety requirements is not detected or that an abnormality action of the functional safety requirements is not awaited, the process proceeds to S190. In S190, for the safety mechanism of the functional safety, the schedule for the normal determination is selected, and the inter-core control thread control unit 32 is requested to execute control of the thread group. In other words, when no abnormality has occurred, or when the treatment after the occurrence of an abnormality has been completed, normal time N, which is a table corresponding to normal time, is selected from the execution priority table, which will be described later.

Subsequently, in S200, the control calculation unit 11 detects an abnormality in the non-functional safety requirements and determines whether or not to wait for an abnormality treatment. If the control calculation unit 11 determines in S200 that no non-functional safety requirement abnormality has been detected or is not waiting for non-functional safety requirement abnormality treatment, 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 the thread group for the processing of the non-functional safety requirements, and guarantees the continuation of the processing of the basic function (for example, corresponding to the original function described above). do. At this time, since the processing order is the same as when no abnormalities in functional safety threads are detected, there is no loss of 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 of the non-functional safety requirements in S200 and determines that the abnormality is waiting for an abnormality treatment, the control operation unit 11 proceeds to S220 and performs inter-core control thread control for the abnormality treatment of the non-functional safety requirements. It requests the execution control of the thread group to the unit 32 . After that, the thread execution priority determination process of FIGS. 4A and 4B ends.

[3-2-3. Priority rule]
Here, priority rules will be described with reference to FIG. The priority rule is a correspondence relationship between a plurality of schedules that can be selected by the functional requirement section 33 and the non-functional requirement section 34 in the thread execution priority determination process of FIGS. 4A and 4B and the execution priority of each thread for each schedule. indicates The schedule will hereinafter be referred to as a thread execution priority table, or simply as a table.

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

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

Also, if there is an abnormality in the functional safety thread, for example, a table labeled "Abnormal AN" is selected. In this table, the priority of the functional safety threads m1, n1, n2 is set higher than the priority of the non-functional safety threads 01, 02.

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

It should be noted that the priority rules may be arbitrarily rewritable. For example, by using an automatic program from a formal design specification and implementing an executable code in flash memory, it is possible to rewrite parts that may be changed in the life cycle according to the functional specification. It is also possible to construct In particular, each table may be dynamically rewritten according to the FTTI for each thread waiting to be executed.

[3-2-4. First operation example]
A first operation example in the configuration of this embodiment will be described with reference to FIG. This operation example is an example of a thread execution procedure when an abnormality is simultaneously detected for thread m1 and thread n1 for which all SM processes are not completed within the execution cycle of thread 01, which has a higher priority than the functional safety SM. indicate. The first operation example is a scheduling example in which the remaining execution time is compared with FTTI, which is a functional safety requirement, and the priority of the thread that should be treated earlier from the functional safety point of view is increased.

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

In FIG. 6, the arrows indicate the timing at which the timer interrupts of the three threads are synchronized. Thus, when three threads are waiting for execution, the thread with the highest priority is executed first.

FTTI priority rewriting AN[1] is selected as the table described above. It should be noted that if the runtime of each thread exceeds its corresponding latency timer (that is, the limit latency in the present disclosure), it is set to execute degeneracy processing.

After execution of thread 01, an abnormality is detected in thread m1 and thread n1. At this time, if there is no change in execution priority, threads 01, m1, and n1 are executed in this order, as indicated by the dotted line in FIG. Assuming that thread 01, which runs first, has been extended for some reason, if an abnormal action (that is, an interrupt thread) is performed in threads m1 and n1 and FTTI is set for each, the order of this thread is , thread n1 does not meet the requirements of FTTI.

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

As a result, as shown by the solid line in FIG. 6, the thread n1 and the thread m1 can be processed in the order of the thread 01, and the execution of the thread 01 completes the specified error handling for the thread n1 and the thread m1. is delayed until In other words, the execution of the thread 01 is delayed until the error handling thread specified in the schedule is completed, and the thread 01 is executed after the error handling of the thread within the predetermined schedule is completed. At this time, the execution of the thread 01 is not necessarily delayed until all abnormal measures are completed. Note that thread 01 is preferably scheduled so as not to exceed the normal deadline watchdog timer.

[3-2-5. Second operation example]
In the first operation example, the description is based on the premise that each related thread is controlled under the control of the same scheduler for both the functional safety requirement and the non-functional safety requirement. In other words, the execution order of the threads is managed mainly using the scheduler function of the inter-core control thread control unit 32 . However, as shown in the second operation example of FIG. 7, the scheduler controlling threads related to non-functional safety requirements and the scheduler controlling threads related to functional safety requirements may be independent. That is, the inter-core control thread control unit 32 uses the scheduler function of the functional requirement unit 33 and the scheduler function of the non-functional requirement unit 34 to arbitrate between them, thereby managing the thread execution order.

In this configuration, under the control of individual schedulers, threads related to all functional safety requirements are aggregated to protect the execution of the safety mechanism of functional safety from any exclusive infringement factor and ensure safety. be able to. In this case, the inter-core control thread control unit 32 including the scheduler is desirably configured as the highest ASIL functional safety requirement.

With this configuration, the design structure ensures that non-functional safety requirements and functional safety requirements do not interfere. Therefore, it is possible to more easily design a structure that appropriately dispatches multithreaded resources by focusing only on the difference in ASIL of each thread within 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 improve the robustness of the implemented software while saving the architecture change and verification man-hours for conforming to functional safety in the software life cycle. The memory 13, the schedule, and the input/output unit 12 correspond to multithread resources, for example.

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

　In order to guarantee the FTTI of various functional safety requirements, the minimum interrupt cycle of the aggregated functional safety-related thread group is scheduled from the maximum allowable interrupt interval (that is, the interval at which the FTTI can be guaranteed even if the process 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 disabled time in threads related to non-functional safety requirements should be sufficiently shorter than 2ms with a margin, and the design should ensure 2ms periodic interrupts.

[3-2-6. Normal time scheduler execution process]
The normal scheduler execution processing executed by the control calculation unit 11 will be described with reference to the flowcharts of FIGS. 8A and 8B. The normal time scheduler execution process is a process that is executed according to the normal time N table under the condition that no abnormality has occurred in the functional safety thread. The normal scheduler execution process is performed, for example, at each preset cycle.

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

On the other hand, if the control calculation unit 11 determines in S310 that it is waiting for the execution of the execution cycle interrupt (minimum time interval) X (2 raised to the 0th power), it proceeds to S320 and waits for the execution of the non-functional safety thread 01. It is determined whether or not.

For example, when the control operation unit 11 determines in S320 that the non-functional safety thread 01 is waiting for execution, the control operation unit 11 shifts to S330, dispatches the non-functional safety thread 01, and executes a kernel call to execute this thread. to run. At this time, even if a thread with a lower priority than the current thread is running, the thread is temporarily interrupted (that is, preempted) to give priority to the execution of the current thread. After that, the normal time scheduler execution processing of FIGS. 8A and 8B ends.

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

If the control operation unit 11 determines in S340 that the non-functional safety thread 02 is waiting for execution, it proceeds to S350, dispatches the non-functional safety thread 02, and executes a kernel call to execute this thread. do. On the other hand, when the control calculation unit 11 determines in S340 that the non-functional safety thread 02 is not waiting for execution, the process proceeds to S410.

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

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

If the control calculation unit 11 determines in S420 that the functional safety thread m1 is waiting for execution, it proceeds to S430, dispatches the functional safety thread m1, and executes a kernel call to execute this thread. After that, the normal time scheduler execution processing of FIGS. 8A and 8B ends.

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

The control calculation unit 11 determines in S510 whether or not execution of an execution cycle interrupt (minimum time interval) X (2 to the nth power) is waiting. If the control calculation unit 11 determines in S510 that the execution of the execution cycle interrupt is not waiting, 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 the execution cycle interrupt, it proceeds to S520 and determines whether it is waiting for execution of the functional safety thread n1.

If the control calculation unit 11 determines in S520 that the functional safety thread n1 is waiting for execution, it proceeds to S530, dispatches the functional safety thread n1, and executes a kernel call to execute this thread. At this time, even if a thread with a lower priority than the current thread is running, the current thread is temporarily interrupted and given priority to the current thread. After that, the normal time scheduler execution processing of FIGS. 8A and 8B ends.

On the other hand, if the control calculation unit 11 determines in S520 that the functional safety thread n1 is not waiting for execution, it proceeds to S540 and determines whether or not 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, it proceeds to S550, dispatches the functional safety thread n2, and executes a kernel call to execute this thread. After that, the normal time scheduler execution processing of FIGS. 8A and 8B ends.

On the other hand, when 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 processing in FIGS. 8A and 8B.

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

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

In the execution processing of the abnormal scheduler AN[2] shown in FIGS. 11A and 11B, the processing is performed in the order of S510-S550, S410-S430, and S310-S350.

[3-3. effect]
According to 1st Embodiment detailed above, there exist the following effects.

(3a) One aspect of the present disclosure is a vehicular computer (for example, the 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. It is a control method of an automobile computer executed in. Parallel processing can include scheduling including parallel processing by multiple cores, and quasi-parallel processing by time division by a certain core. A functional safety thread represents a thread that computes safety-related values for the vehicle. Also, a non-functionally safe thread represents a thread other than a functionally safe thread.

In the automotive computer control method, an abnormality in the functional safety thread is detected, and when an abnormality in the functional safety thread is detected, the scheduler is changed to change the thread execution priority.

According to this control method, the priority of thread execution can be changed only when an abnormality occurs in the functional safety thread. Therefore, while the functional safety thread is making a normal determination, it is possible to schedule the original functions of the vehicle with priority.

In other words, since the situation in which the priority is changed is limited to the case where an abnormality occurs in the functional safety thread, it becomes easier to design a schedule that makes it easier for all threads to be executed within the limit waiting time.

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

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

　The functional safety thread may, for example, realize the functional safety requirement specifications. It is the minimum execution unit that defines the execution priority when the original function and safety mechanism in this case are made into a software module and implemented in semiconductor memory. Hardware resources are linked by time division. In addition, functional safety requirement specifications mean that safety goals and safety mechanisms (for example, fail-safe mechanisms and FTTI) are generally may be defined. Note that the TSR is a technical specification for requesting what kind of safety protection function is necessary to ensure safety when an abnormality occurs in the system. Also, the TSC is a technical specification that summarizes how to realize the safety protection function.

(3b) In one aspect of the present disclosure, when an anomaly is detected, execution of the non-functional safety thread is suspended until a preset anomaly action is completed. Execution of non-functionally safe threads only executes for periods updated by the dynamic scheduler. The priority of related threads is controlled by the kernel. Suspended until completed. Note that execution of the non-functional safety thread does not suspend the non-functional safety thread until all fault actions are completed.

According to this method, execution of the non-functional safety thread is suspended until the error handling is completed. It is possible to return to thread execution.

(3c) In one aspect of the present disclosure, the estimated time from detection of an abnormality to occurrence of a dangerous event in the vehicle is FTTI (Fault Tolerant Time Interval). If an anomaly is detected, a rescheduling is implemented within the FTTI so that the execution priority of the functional safety threads is relatively higher than the execution priority of the non-functional safety threads.

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

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

According to this method, since kernel interrupt control is implemented, it is possible to deal with anomalies immediately.

(3e) In one aspect of the present disclosure, a functional safety mechanism (SM) for diagnosing whether an abnormality of the functional safety thread is detected is implemented as a thread, and the scheduler is executed according to whether an abnormality is detected. Determines whether or not a change is necessary, and switches the scheduler.

According to such a method, it is possible to determine whether the scheduler needs to be changed, and to switch the scheduler when the scheduler needs to be changed. It should be noted that the determination of whether or not to switch the scheduler is preferably performed at an appropriate timing in which the scheduler can be switched in time.

Also, as a main control method for scheduler switching, as shown in FIG. 5, a method of assigning the functional safety always SM to all periodic interrupts (for example, assigning it to the shortest periodic interrupt) can be adopted. Alternatively, it is possible to employ a method in which the HW interrupt handler wakes up the functionally safe SM.

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

According to this 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, an interrupt thread, a functional safety thread, and a non-functional safety thread have a latency limit that represents an upper bound on the amount of time from when an instruction to execute is received until the thread is executed. is set. If the limit waiting time (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 degenerated. In the degeneration of the system, for example, a restriction mode that restricts a part of the original functions, and a shift control mode that requires manual operation by the driver in the event of an automatic operation system failure, or the like can be implemented.

According to this method, when other threads such as non-functional safety threads cannot be executed within the limit waiting time, the system corresponding to the other threads is degenerated, so that the vehicle can be operated with both safety and convenience. can be controlled.

(3h) In one aspect of the present disclosure, anomalies may be detected in multiple 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 threads is increased in ascending order of the time remaining with respect to the limit waiting time (i.e., the execution priority of the interrupt threads change the contents of the scheduler (so that the

According to this method, when multiple interrupt threads are executed in response to detection of an abnormality in multiple functional safety threads, the interrupt threads can be executed in ascending order of the remaining time with respect to the limit waiting time. Therefore, it is possible to prevent any of the interrupt threads from being executed within the limit waiting time.

(3i) One aspect of the present disclosure is a vehicle electronic control device (this This is the control calculation unit 11) in the disclosure.

The anomaly detection unit is configured to detect an anomaly in the functional safety thread. The sequence changing unit changes the priority by changing the scheduler when an abnormality is detected in the functional safety thread and an abnormality handling is required.

With such a configuration, the priority of thread execution can be changed only when an abnormality occurs in the functional safety thread.

(3j) In particular, the vehicle electronic control unit can configure a system in which a plurality of cores are mounted and threads share hardware resources such as cores and memory in a time-sharing manner by a scheduler. In such a system, when the safety mechanism of the functional safety thread detects an error, the execution of other threads is temporarily suspended to complete the error handling within the system allowable time, or and memory resources can be preferentially used.

With such a configuration, the execution time of the entire system becomes critical, in other words, it is possible to reduce potential cases where threads do not finish within the allowable time. can be constructed. In addition, regarding the security of the entire system, it is easy to improve marketability by reducing the need for degenerate design of system functions and securing the original functions of the system by designing the system with a margin of execution time. 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 in various modifications.

(4a) In the above embodiment, the 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 a plurality of functional safety threads, an interrupt thread is executed for each thread in which an abnormality is detected, and at this time, the execution priority of the interrupt thread is increased in descending order of vehicle safety level. You may change the contents of the scheduler in the same way. For example, the control calculation unit 11 may dynamically rewrite the abnormal scheduler AN[2] shown in FIG. 5 so that each thread is executed in descending order of vehicle safety standard level.

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

(4b) In the above embodiment, no reference is made to the arrangement of the

components

11, 12, 13, 16 that make up the ECU 10. For example, the actual devices of the

components

11, 12, 13, 16 are one It can consist of one or more SOCs (System On Chips).

Also, for example, each function of the vehicle application function 16 shown in FIG. may be implemented. That is, the functions of the inter-core control thread control unit 32 and the functional requirement unit 33 may be implemented in one SOC that implements the OS, and the functions of the non-functional requirement unit 34 may be implemented in an SOC different from the SOC. .

With such a configuration, it is possible to reduce overhead and improve real-time performance.

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

(4d) A plurality of functions possessed by one component in the above embodiment may be realized by a plurality of components, or a function possessed by one component may be realized by a plurality of components. . Also, a plurality of functions possessed by a plurality of components may be realized by a single component, or a function realized by a plurality of components may be realized by a single component. Also, part of the configuration of the above embodiment may be omitted. Moreover, at least part of the configuration of the above embodiment may be added or replaced with respect to the configuration of the other above embodiment.

(4e) In addition to the vehicle control system 1 described above, a device such as a vehicle control device that is a component of the vehicle control system 1, a program for causing a computer to function as the device, a semiconductor memory that stores the program, etc. The present disclosure can also be implemented in various forms, such as a transitional material recording medium, various methods including a control method for an automobile computer, and the like.

Claims

at least one functional safety thread representing threads that compute safety-related values of the vehicle, and at least one non-functional safety thread representing threads other than said functional safety thread, in parallel processing based on pre-defined priorities in a scheduler; A method of controlling a vehicle computer executed in an executable vehicle computer (11), comprising:
detecting an abnormality in the functional safety thread;
A control method for an automobile computer, wherein when an abnormality of the functional safety thread is detected, the scheduler is changed to change the priority.
A control method for an automotive computer according to claim 1,
A control method for an automotive computer, wherein, when the abnormality is detected, the execution of the non-functional safety thread is suspended until a preset abnormality treatment is completed.
A control method for an automobile computer according to claim 1 or claim 2,
Estimated time from the detection of the abnormality to the occurrence of a dangerous event in the vehicle is FTTI (Fault Tolerant Time Interval), and when the abnormality is detected, the execution priority of the functional safety thread in the FTTI relatively higher than the execution priority of the non-functional safety thread.
A control method for an automotive computer according to claim 3,
A control method for an automobile computer, wherein the interrupt control of the kernel is used to detect whether or not there is an abnormality in the functional safety thread, and when the abnormality is detected, the schedule is changed.
A control method for an automotive computer according to claim 4,
A functional safety mechanism for diagnosing whether or not an abnormality is detected in the functional safety thread is implemented as a thread, and whether or not the scheduler needs to be changed is determined according to whether or not the abnormality is detected, and the scheduler A control method for an automotive computer.
A control method for an automobile computer according to claim 4 or claim 5,
At least the interrupt thread executed by the interrupt control of the kernel is set with a limit waiting time representing the upper limit of the time from receiving an instruction to be executed until the thread is executed,
The threshold latency of the interrupt thread is set to be less than the FTTI. A control method for an automotive computer.
A control method for an automotive computer according to claim 6,
the limit waiting time is set for the interrupt thread, the functional safety thread, and the non-functional safety thread;
A control method for an automobile computer, wherein a system corresponding to a thread other than the interrupt thread is degenerated when the time until the interrupt thread is executed exceeds the limit waiting time of the thread other than the interrupt thread.
A control method for an automobile computer according to claim 6 or claim 7,
Detect anomalies in multiple functional safety threads,
The interrupt thread is executed for each thread that detects the abnormality, and at this time, the content of the scheduler is changed so that the execution priority of the interrupt thread is increased in ascending order of the remaining time with respect to the limit waiting time. computer control method.
A control method for an automobile computer according to any one of claims 6 to 8,
an automobile safety standard level is associated with each interrupt thread;
Detect anomalies 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 thread is increased in order of the vehicle safety level level. Computer control method.
at least one functional safety thread representing threads that compute safety-related values of the vehicle, and at least one non-functional safety thread representing threads other than said functional safety thread, in parallel processing based on pre-defined priorities in a scheduler; An executable vehicle electronic controller (10) comprising:
an abnormality detection unit (S130, S150, S170) configured to detect an abnormality in the functional safety thread;
An electronic control unit for a vehicle, comprising: an order change unit (S10, S20, S30, S180) that changes the priority by changing the scheduler when an abnormality in the functional safety thread is detected.