In-vehicle electronic devices

The in-vehicle electronic device optimally reallocates computing resources among ECUs by dynamically monitoring and distributing alternative programs, addressing performance and safety degradation in vehicle control systems.

JP7733816B2Active Publication Date: 2025-09-03ASTEMO LTD
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
JP2024517666
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Filing Date
2022-04-26
Publication Date
2025-09-03
Estimated Expiration
2042-04-26

AI Technical Summary

Technical Problem

Conventional vehicle control systems with multiple ECUs face limitations in fully utilizing computing alternatives during function reconfiguration due to the association of only one alternative program with one function, leading to potential performance degradation and reduced safety.

Method used

An in-vehicle electronic device with a communication unit and control unit that dynamically monitors and distributes alternative programs to suitable ECUs based on their capability, ensuring optimal function substitution during abnormalities.

Benefits of technology

Prevents unnecessary reduction in vehicle performance and safety by identifying and executing computing units with optimal substitution capabilities, thereby maintaining vehicle comfort and safety.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007733816000001
    Figure 0007733816000001
  • Figure 0007733816000002
    Figure 0007733816000002
  • Figure 0007733816000003
    Figure 0007733816000003
Patent Text Reader

Abstract

This in-vehicle electronic device is connected with a plurality of computation units installed in a vehicle, and comprises: a communication unit that communicates with the plurality of computation units; and a control unit that, when a malfunction has occurred in one of the plurality of computation units, issues a substitutive control instruction to a different computation unit. The control unit acquires substitution capability information indicating whether, when a malfunction has occurred in a first computation unit among the plurality of computation units, a different computation unit can take over the execution content of the first computation unit.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present invention relates to an in-vehicle electronic device. [Background technology]

[0002] Vehicles are equipped with an ECU (Electronic Control Unit), which is one of the on-board electronic devices that controls various parts inside the vehicle. In recent years, vehicle control systems generally consist of multiple ECUs. If an abnormality occurs in this ECU, a function reconfiguration technique is known that substitutes the function with another ECU.

[0003] Patent Document 1 describes a technology that prevents a decrease in safety due to the sudden stop of functions where continuity is important, such as autonomous driving, by sending an alternative program to an alternative control device before a failure occurs in order to improve the immediacy of function reconfiguration. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 2017-092835 Summary of the Invention [Problem to be solved by the invention]

[0005] As mentioned above, modern vehicle control systems are made up of multiple ECUs, and the ECUs themselves often have multiple processors. Therefore, even if an abnormality occurs in one ECU, other ECUs often have the computing power to take over, and by reconfiguring the functions, they can take over the functions realized by the failed ECU.

[0006] However, as described in Patent Document 1, in conventional technology, only one alternative program or degenerate program is associated with one function, which means that the computing alternative capacity cannot be fully utilized, and the function or performance after the occurrence of an abnormality is more limited than necessary.

[0007] For this reason, there has been a demand for an in-vehicle electronic device that can suppress performance degradation after function reconfiguration. [Means for solving the problem]

[0008] In order to solve the above problems, for example, the configurations described in the claims are adopted. The present application includes multiple means for solving the above-mentioned problems, and one example thereof is an on-board electronic device connected to multiple calculation units mounted on a vehicle, which includes a communication unit that communicates with the multiple calculation units, and a control unit that issues instructions for alternative control to a second calculation unit when an abnormality occurs in one of the multiple calculation units. When an abnormality occurs in a first calculation unit, which is one of the plurality of calculation units, the control unit acquires alternative capability information indicating whether the second calculation unit can substitute for the execution content of the first calculation unit. Then, based on the acquired alternative capability information, the function level of the alternative execution content of the first calculation unit is determined. Here, when an abnormality occurs in the first calculation unit while controlling the automatic driving of the vehicle, the control unit immediately distributes an emergency alternative program that safely stops the vehicle from a specific memory to the second calculation unit, and after the second calculation unit executes the distributed emergency alternative program, it acquires alternative capability information and executes a process to determine the functional level of the alternative execution content, and distributes an alternative program that is compatible with the alternative capability of the second calculation unit from the specific memory to the second calculation unit and executes it. [Effects of the Invention]

[0009] According to the present invention, by dynamically monitoring the substitutability of a computing unit such as an ECU, it is possible to identify and execute a computing unit that is optimal for substituting a function. Therefore, even if an abnormality occurs in a computing unit, it is possible to prevent the comfort of the vehicle from being reduced more than necessary. Problems, configurations, and effects other than those described above will become apparent from the following description of the embodiments. [Brief explanation of the drawings]

[0010] [Figure 1] 1 is a block diagram showing an example of the configuration of an alternative control decision device as an on-vehicle electronic device according to a first embodiment of the present invention. [Figure 2]1 is a diagram showing an overview of a vehicle system having a vehicle control system according to a first embodiment of the present invention. [Figure 3] 1 is a configuration diagram showing an example of a network to which an in-vehicle electronic device according to a first embodiment of the present invention is connected; [Figure 4] FIG. 3 is a diagram showing an example of the configuration of an alternative program data table according to the first embodiment of the present invention. [Figure 5] FIG. 3 is a diagram showing an example of the configuration of an alternative capability data table according to the first embodiment of the present invention. [Figure 6] 5 is a flowchart showing an example of processing performed by a control unit according to the first embodiment of the present invention. [Figure 7] 10 is a flowchart showing an example of a process for determining a function level and a delivery destination of a control unit according to the first embodiment of the present invention. [Figure 8] 5 is a flowchart showing an example of processing performed in a communication unit according to the first embodiment of the present invention. [Figure 9] 4 is a processing sequence of function reconfiguration according to the first embodiment of the present invention. [Figure 10] FIG. 10 is a diagram showing the correspondence between operation modes and alternative program function levels according to a second embodiment of the present invention. [Figure 11] 10 is a flowchart showing an example of a process for determining a function level and a distribution destination according to the second embodiment of the present invention. [Figure 12] 10 is a flowchart showing an example of processing performed in a communication unit according to a second embodiment of the present invention. [Figure 13] 10 is a processing sequence of function reconfiguration according to the third embodiment of the present invention. [Figure 14] 10 is a flowchart showing an example of processing performed by a control unit according to a third embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0011] The following describes embodiments of the present invention in order. Note that each embodiment described below is a preferred example, and the present invention is not limited to each embodiment described below. The configuration of each part can be appropriately added, changed, or deleted without departing from the spirit of the present invention.

[0012] In the following embodiments, the present invention is applied to a vehicle control system. Systems installed in vehicles generally have limited resources, unlike information processing systems installed in buildings, such as servers. Resources here refer to the number and performance of central processing units (CPUs), memory capacity, and so on.

[0013] Due to resource limitations, vehicle control systems must stop vehicle functions or significantly degrade performance when an abnormality occurs, raising concerns about reduced safety and comfort.The vehicle control system according to a first embodiment of the present invention uses the configuration and processing described below to prevent, for example, reduced safety and comfort when an abnormality occurs.

[0014] <First embodiment> An in-vehicle electronic device according to a first embodiment of the present invention will be described below with reference to FIGS. FIG. 1 is a block diagram showing an alternative control decision device 1 constituting an on-vehicle electronic device according to a first embodiment. The alternative control decision device 1 includes a processor 2, a memory 3, a non-volatile memory 4, and an I / O (Input / Output) device 5. The processor 2 to the I / O device 5 are connected via an interconnect 6, and data is exchanged between them.

[0015] The I / O device 5 transmits and receives data via the network link 10 to and from other devices connected by the network link 10. As the network link 10, for example, a Controller Area Network (CAN), CANFD (CAN with Flexible Data-rate, Ethernet: registered trademark), or the like is used.

[0016] An OS (Operating System) 7, a control unit 8, a communication unit 9, an alternative program data table 11, and an alternative capability data table 12 are loaded into the memory 3 and executed and referenced by the processor 2. In the following explanation, for convenience, each unit will be described as the subject of processing, but the actual subject of processing is the processor 2. The control unit 8 and the communication unit 9 are software that runs on the OS 7.

[0017] The alternative control decision device 1 configured as above exchanges information about the occurrence of an abnormality in the ECU 13 (FIG. 3) and information about the alternative capability of the ECU 13 with the vehicle control system 20 connected by the network link 10 via the communication unit 9. The exchanged information is written to the alternative capability data table 12, and the occurrence of an abnormality is notified to the control unit 8 via the communication unit 9. The control unit 8 reads and writes the alternative program data table 11 and the alternative capability data table 12, and determines the appropriate level of the alternative program and the ECU 13 to which the program will be distributed. The control unit 8 then distributes the alternative program to the determined ECU 13. The alternative control decision device 1 may be configured as a dedicated device, or one of the ECUs 13 described later may have the function of the alternative control decision device 1.

[0018] FIG. 2 shows an overview of a vehicle system 17 having a vehicle control system according to this embodiment. The vehicle system 17 has a vehicle control system 20 inside an automobile or the like. The vehicle control system 20 here is configured by, for example, an in-vehicle network and an ECU.

[0019] The communication device 18 performs wireless communication with the outside of the vehicle system 17. For example, the communication device 18 performs communication using protocols such as mobile phone communication, wireless LAN (Local Area Network), WAN (Wide Area Network), and C2X (Car to X: vehicle-to-vehicle or vehicle-to-infrastructure communication). Alternatively, the communication device 18 performs communication using a GPS (Global Positioning System).

[0020] By performing these communications, the communication device 18 performs wireless communication such as acquiring or transmitting information about the outside world (infrastructure, other vehicles, maps) or information about the vehicle itself. Alternatively, the communication device 18 may have a diagnostic terminal (OBD), an Ethernet terminal, and a terminal for an external recording medium (for example, a USB memory, a memory card, etc.), and may communicate with the vehicle control system 20.

[0021] Furthermore, vehicle system 17 has a vehicle control system 19 separate from vehicle control system 20. Vehicle control systems 19 and 20 may be configured as networks using the same protocol, or may be configured as networks using different protocols.

[0022] Furthermore, a driving device 15 and a recognition device 16 are connected to the vehicle control system 20 . The drive unit 15 is composed of actuators and the like that drive mechanical and electrical devices that control vehicle motion under the control of the vehicle control system 20. Here, the mechanical and electrical devices that control vehicle motion include, for example, the engine, transmission, wheels, brakes, steering device, and the like. The recognition device 16 is composed of external sensors such as a camera, radar, LIDAR, and ultrasonic sensor, and a dynamic system sensor that recognizes the state (motion state, position information, acceleration, wheel speed, etc.) of the vehicle system 17. These sensors that make up the recognition device 16 acquire information input from the outside world and generate external world recognition information, which will be described later.

[0023] FIG. 3 shows an example of the configuration of a vehicle control system 20 according to this embodiment. The devices on the in-vehicle network are connected to a network link 10. The network link 10 is connected to a plurality of ECUs 13, a gateway (hereinafter referred to as GW) 14, and an alternative control decision device 1. A drive unit 15 and a recognition unit 16 are connected to each ECU 13 according to the ECU 13's location. The ECU 13 controls the drive unit 15 and the recognition unit 16, and acquires information from the drive unit 15 and the recognition unit 16. The ECU 13 also transmits and receives data to and from the network link 10. Furthermore, the ECU 13 may be connected to another network link other than the network link 10, and may transmit and receive data to and from the other network link. Each ECU 13 has a built-in CPU, which is a calculation unit, and various processes are executed under the control of the CPU.

[0024] A gateway (hereinafter, GW) 14 connects a plurality of network links 10 and transmits and receives data to and from each of the network links. The GW 14 may also be connected to a network link other than the network link 10.

[0025] 4 shows an example of the configuration of the alternative program data table 11 provided in the alternative control decision device 1. The CPUs described below refer to CPUs that are calculation units built into the ECUs 13. The alternative program data table 11 is created for each program for which alternative processing is assumed. Each field of the alternative program data table 11 registers a program storage destination pointer for each function level, as well as CPU alternative capabilities, free ROM (Read Only Memory) capacity, and free RAM (Random Access Memory) capacity, which are conditions for selecting a function level. Here, the free ROM capacity and free RAM capacity refer to the free capacity of the ROM and RAM connected to the CPU. Note that the free ROM capacity and free RAM capacity mentioned here include not only the free capacity of memory elements called ROM or RAM, but also the capacity of other memories, such as the free capacity of the area where programs and the like are stored (free ROM capacity) or the free capacity of the work area used for calculations and control (free RAM capacity).

[0026] In the example of Figure 4, different program storage destination pointers P0 to P5 are shown for each of the six function levels, function levels 0 to 5. The minimum values ​​of CPU alternative capacity, free ROM capacity, and free RAM capacity that correspond to each function level are set for function levels 1 to 5. Function level 0 is when the CPU alternative capacity, free ROM capacity, and free RAM capacity do not correspond to function levels 1 to 5. Here, an example is given in which the function level corresponds to three items, CPU alternative capacity, ROM free space, and RAM free space, but the alternative program data table 11 may also correspond to at least one of the CPU alternative capacity, ROM free space, and RAM free space, and the function level.

[0027] The six levels of function levels, 0 to 5, can be considered to provide more advanced driving assistance as the function level increases. For example, function level 0 is a function level that allows only manual driving without driving assistance, function level 1 is a function level that provides driving assistance to avoid collisions by detecting people and vehicles, and function level 2 is a function level that adds to function level 1 by providing driving assistance to keep the vehicle in its lane.

[0028] FIG. 5 shows the configuration of the alternative capability data table 12 provided in the alternative control decision device 1. As shown in FIG. The status, performance, CPU usage rate, free ROM capacity, free RAM capacity, and operable function level of each CPU are recorded in each field of the alternative capability data table 12. Fig. 5 shows the status, performance, CPU usage rate, free ROM capacity, free RAM capacity, and operable function level of each CPU for five CPUs with CPU identifiers 0 to 4.

[0029] Of these alternative capability data, the performance, free ROM capacity, and free RAM capacity may be determined as values ​​entered at the time of design. The CPU utilization reflects the alternative capability information acquired from each control device. The operable level is determined by the control unit 8 by referring to the data in each of the other fields and the alternative program data table. In Figure 5, the status of the CPU with identifier 0 is abnormal (failure, etc.), and the performance, CPU usage rate, free ROM capacity, free RAM capacity, and operable function level are not applicable (N / A). If the CPU with identifier 0 is in an operable state but is abnormal, the extent to which it can operate at the operable function level is shown. 5 are normal, and the fields for performance, CPU usage rate, free ROM capacity, and free RAM capacity are set to their respective values. The operable function levels of the CPUs with identifiers 1 to 4 are set by the process shown in the flowchart of FIG. 7, which will be described later.

[0030] FIG. 6 is a flowchart showing the processing performed by the control unit 8 of the alternative control decision device 1. The process in the control unit 8 is started when the control unit 8 is notified of the occurrence of an abnormality from data received by the communication unit 9, and is executed as follows. First, the control unit 8 compares the alternative capability data table 12 with the alternative program data table 11, and determines the function level of the alternative program and its distribution destination (step S101). Next, the control unit 8 acquires the alternative program determined in step S101 from the nonvolatile memory 4 (step S102). Then, the control unit 8 distributes the alternative program acquired in step S102 to the distribution destination determined in step S101 (step S103).

[0031] FIG. 7 is a flowchart showing the details of the process of determining the function level and delivery destination in step S101 of the flowchart in FIG. 6, among the processes performed by the control unit 8 of the alternative control decision device 1. First, the control unit 8 starts a loop of the CPU identifiers in the alternative capability data table 12 (step S201). Then, the control unit 8 determines whether the value in the status field of the CPU selected in step S201 matches a value indicating normality (step S202). If the value in the status field of the CPU matches a value indicating normality, the control unit 8 proceeds to step S203 (step S202: Yes), and if they do not match (step S202: No), the control unit 8 updates the loop of step S201.

[0032] If the CPU status field is normal (step S202: Yes), the control unit 8 determines the highest function level that satisfies the conditions among the function levels on the alternative program data table 11 based on the value of the alternative capability data table 12 of the selected CPU (step S203).

[0033] Then, the control unit 8 records the function level obtained in step S203 in the operable function level field on the alternative capability data table 12 of the selected CPU (step S204). The processing of steps S202 to S204 is executed in a loop for the CPUs of all identifiers, and when the loop for the CPUs of all identifiers is completed (step S205), the process proceeds to step S206. In step S206, the control unit 8 outputs the CPU identifier having the largest value in the operable function level field of the alternative capability data table 12 and its operable function level.

[0034] FIG. 8 is a flowchart showing the processing performed by the communication unit 9 of the alternative control decision device 1. First, the communication unit 9 detects the occurrence of an abnormality in any of the ECUs 13 (step S301). When the occurrence of an abnormality is detected, the communication unit 9 acquires the alternative capability information of each ECU 13 connected via the network (step S302). Next, the communication unit 9 updates the alternative capability data table 12 based on the acquired alternative capability information (step S303). Then, the communication unit 9 notifies the control unit 8 of the occurrence of the abnormality, and causes the control unit 8 to start processing (step S304).

[0035] FIG. 9 shows a processing sequence of the function reconfiguration by the alternative control decision device 1. First, an abnormality occurs in the first ECU 13a (step S911). The abnormality here includes not only a failure of the first ECU 13a but also various other malfunctions such as a malfunction of a device such as a sensor connected to the first ECU 13a. A sensor malfunction may be a malfunction of the sensor itself, or the sensor may not be able to perform proper measurement due to factors such as weather. The first ECU 13a in which the abnormality has occurred notifies the alternative control decision device 1 of the occurrence of the abnormality (fault) (step S912). The alternative control decision device 1, which has received the notification of the occurrence of the abnormality, requests alternative capability information from another ECU (second ECU) 13b (step S913).

[0036] The second ECU 13b that has received the request for the alternative capability information transmits the alternative capability information to the alternative control decision device 1, and the alternative control decision device 1 acquires the alternative capability information (step S914). Next, the alternative control decision device 1 acquires an alternative program from the nonvolatile memory 4 (step S915). This alternative program replaces the program that has been executed by the first ECU 13a that has been notified of the occurrence of the abnormality in step S912. Then, the alternative control decision device 1 distributes the alternative program to the second ECU 13b (step S916). The second ECU 13b stores the delivered alternative program and immediately executes the alternative program.

[0037] As described above, according to this embodiment, when an abnormality occurs in an ECU, processing is transferred to another ECU, thereby preventing vehicle comfort from being reduced more than necessary. Here, by acquiring alternative capability information indicating whether another ECU can take over when an abnormality occurs, dynamic alternative capabilities can be grasped. Note that ECU abnormalities here include various abnormalities such as ECU failure, failure of a sensor connected to the ECU, sensor malfunction due to weather, etc.

[0038] According to this embodiment, when transferring processing to another ECU, an appropriate program can be sent depending on the situation by sending a program for performing alternative calculations to a calculation unit that has the capacity to perform the alternative calculations. In other words, if the destination ECU has sufficient alternative (surplus) capacity, an alternative program with the exact same functions as the program being executed in the abnormal ECU can be stored in the destination ECU. Then, the other ECU can be substituted without any functional limitations. On the other hand, if there are limitations on the capabilities and functions of the alternative program depending on the replacement (redundant) capabilities of the ECU to which the system is migrated, some restrictions will be imposed, but depending on the capabilities of the alternative program, it is possible to prevent the vehicle's comfort from being reduced more than necessary. In this case, by using the function level, which is the level of vehicle control, as an indicator of substitution capability, the degree to which vehicle control can be substituted can be appropriately indicated by the function level. In addition, this function level can be easily determined by preparing an alternative program data table 11 as shown in Figure 4 and determining it by referring to this data table 11.

[0039] Furthermore, based on the substitution capabilities of each ECU, it is possible to identify which ECU (its calculation unit) should be substituted, and then send a substitution program to the identified ECU to perform substitution, thereby selecting the most suitable ECU to be substituted. Furthermore, by preparing the alternative program in the memory 3 within the alternative control decision device 1, the alternative program can be quickly transmitted from the alternative control decision device 1. Furthermore, as set in the alternative program data table 11 shown in Figure 4, by performing calculations to determine the alternative (surplus) capacity of the ECU to be migrated depending on the functional level, which is the vehicle's operating mode, the required level of alternative capacity can be easily determined.

[0040] <Second embodiment> Next, an on-vehicle electronic device according to a second embodiment of the present invention will be described with reference to Figures 10 to 12. In the second embodiment, the configuration of the alternative control decision device 1, the configuration of the vehicle system having the vehicle control system, and the network configuration to which the on-vehicle electronic device is connected are the same as those in the first embodiment. In the second embodiment, the details of the process for determining the delivery destination when an abnormality occurs differ from those in the first embodiment.

[0041] FIG. 10 is a diagram showing an operation mode / alternative program function level correspondence table according to the second embodiment of the present invention. The operation mode / alternative program function level correspondence table shown in FIG. 10 is the correspondence table referenced in step S101 of the flowchart in FIG. 6 of the first embodiment.

[0042] When designing the software to be implemented in each ECU, the processing load for each operating mode is calculated in advance, the operable level of each alternative program candidate is determined, and data showing the correspondence between them is implemented. The operating modes available here are, for example, four types: automated driving mode for general roads, automated driving mode for expressways (motorway only), driving mode with ACC (adaptive cruise control), and manual driving mode. ACC is a driving mode in which the vehicle follows the vehicle in front at a speed below a set speed. For each operation mode, there are three programs, Program A, Program B, and Program C, and the function level is set to one of six levels from 0 to 5.

[0043] FIG. 11 is a flowchart showing an example of a process for determining a function level and a delivery destination according to the second embodiment. The control unit 8 refers to the operation mode / alternative program function level correspondence table shown in Fig. 10 and outputs the CPU identifier and function level of the CPU with the highest function level of the program to be substituted among the CPUs (step S401). That is, the control unit 8 calculates the substitution capability of each CPU according to the operation mode of the vehicle and outputs the CPU identifier and function level of the program with the highest function level to be substituted. The operation mode of each CPU uses the value transmitted from the communication unit 9.

[0044] FIG. 12 is a flowchart showing an example of processing performed by the communication unit 9. First, the communication unit 9 detects the occurrence of an abnormality in any of the ECUs 13 (step S501). When the occurrence of an abnormality is detected, the communication unit 9 acquires the operation mode information of each CPU (step S502). Then, the communication unit 9 notifies the control unit 8 of the operation mode of each CPU and the occurrence of the abnormality, and starts processing (step S503). Other configurations and processes in the second embodiment are the same as those explained in the first embodiment.

[0045] According to the second embodiment of the present invention, the execution time of the processor that was occupied by calculating the alternative capacity in the first embodiment can be eliminated, and therefore, a quicker function transfer is possible when an abnormality occurs. That is, an alternative program can be selected and transmitted according to the determined function level, and the alternative program can be determined easily by the function level.

[0046] <Third embodiment> Next, an on-vehicle electronic device according to a third embodiment of the present invention will be described with reference to Figures 13 and 14. In the third embodiment, the configuration of the alternative control decision device 1, the configuration of the vehicle system having the vehicle control system, and the network configuration to which the on-vehicle electronic device is connected are the same as those in the first embodiment. In the third embodiment, the details of the function reconfiguration process differ from those in the first embodiment.

[0047] FIG. 13 shows a processing sequence of the function reconfiguration according to the third embodiment. First, an abnormality occurs in the first ECU 13a (step S911). The first ECU 13a in which the abnormality has occurred notifies the alternative control decision device 1 of the occurrence of the abnormality (step S912). The alternative control decision device 1, which has received the notification of the occurrence of the abnormality, acquires an emergency alternative program from the non-volatile memory 4 (step S921). An example of the emergency alternative program is a program that controls the vehicle to safely stop on a roadside or the like when an abnormality occurs while the first ECU 13a is controlling the autonomous driving.

[0048] The alternative control decision device 1 distributes the emergency alternative program acquired in step S921 to the second ECU 13b (step S922). The second ECU 13b stores the distributed emergency alternative program and immediately executes it. Then, the alternative control decision device 1 requests alternative capability information from other ECUs such as the second ECU 13b (step S923). The ECU (such as the second ECU 13b) that has received the request for alternative capability information transmits the alternative capability information to the alternative control decision device 1, and the alternative control decision device 1 acquires the alternative capability information (step S924). Next, the alternative control decision device 1 acquires an alternative program suited to the alternative capability from the nonvolatile memory 4 (step S925). Then, the alternative control decision device 1 distributes the obtained alternative program to the ECU (here, the second ECU 13b) (step S926). The second ECU 13b stores the delivered alternative program and immediately executes the alternative program.

[0049] FIG. 14 is a flowchart showing an example of processing performed by the control unit 8 according to the third embodiment. First, when the control unit 8 is notified of an abnormality, it acquires an emergency substitute program from the nonvolatile memory 4 (step S601). Then, the control unit 8 distributes the emergency substitute program acquired in step S601 to another ECU (second ECU 13b) (step S602).

[0050] Thereafter, the processes of steps S101, S102, and S103 of the flowchart in Fig. 6 described in the first embodiment are performed. That is, the control unit 8 compares the alternative capability data table 12 with the alternative program data table 11, and determines the function level of the alternative program and its distribution destination (step S101). Then, the control unit 8 acquires the alternative program determined in step S101 from the non-volatile memory 4 (step S102). Furthermore, the control unit 8 distributes the alternative program acquired in step S102 to the distribution destination determined in step S101 (step S103). Other configurations and processes in the third embodiment are the same as those explained in the first embodiment.

[0051] According to the third embodiment described above, an alternative program can be distributed at a stage before the alternative capabilities of each ECU are investigated when an abnormality occurs. This allows a minimum level of function transfer to be completed quickly before the alternative capability information of each ECU is acquired when an abnormality occurs. This makes it possible to prevent the vehicle from falling into a dangerous state between the acquisition of the alternative capability information, the determination of the function level, and the determination of the alternative program distribution destination.

[0052] <Modification> It should be noted that the present invention is not limited to the above-described embodiments, but includes various modifications. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to those having all of the described configurations.

[0053] In addition, the block diagrams in Figures 2, 3, and 4 show only the control lines and information lines that are considered necessary for explanation, and do not necessarily show all the control lines and information lines in the product. In reality, it can be assumed that almost all components are interconnected.

[0054] Information such as programs, tables, files, etc. that realize the functions performed by the alternative control decision device 1 can be stored in a memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC card, SD card, or DVD.

[0055] Furthermore, in each of the above-described embodiments, as shown in the sequence diagrams of Figures 9 and 13, an alternative capacity request is made to another calculation unit in response to the occurrence of an abnormality (occurrence of a malfunction), but the alternative control decision device 1 may also acquire alternative capacity information before the occurrence of a malfunction. In other words, the alternative control decision device 1 may acquire alternative capability information of the CPU (computing unit) of each ECU connected via the in-vehicle network at any time (regularly or irregularly) regardless of the occurrence of a malfunction, so as to be able to deal with abnormalities. However, as explained in each of the above-mentioned embodiments, when a notification of an abnormality (malfunction) is received, the alternative control decision device performs processing to consider alternative control, so that alternative control only needs to be considered when a malfunction occurs.As long as a malfunction does not occur, there is no need for the alternative control decision device to perform unnecessary processing, thereby reducing the processing burden on the in-vehicle network.

[0056] Furthermore, in each of the above-described embodiments, the present invention is applied to an in-vehicle network in which ECUs each having a built-in CPU, which is a calculation unit, are connected via a network, but the present invention can also be applied to devices that have a built-in calculation unit other than a CPU. [Explanation of symbols]

[0057] 1...alternative control decision device, 2...processor, 3...memory, 4...non-volatile memory, 5...I / O device, 6...interconnect, 8...control unit, 9...communication unit, 10...network link, 11...alternative program data table, 12...alternative capability data table, 13, 13a, 13b...ECU, 14...gateway, 15...drive unit, 16...recognition device, 17...vehicle system, 18...communication device, 19, 20...vehicle control system

Claims

1. An in-vehicle electronic device connected to a plurality of calculation units mounted on a vehicle, a communication unit that communicates with the plurality of calculation units; a control unit that issues an instruction to perform alternative control to a second calculation unit when an abnormality occurs in a first calculation unit that is one of the plurality of calculation units, the control unit, when an abnormality occurs in the first calculation unit, acquires alternative capability information indicating whether the second calculation unit can substitute for the execution content of the first calculation unit, and determines a function level of the alternative execution content of the first calculation unit based on the acquired alternative capability information; When an abnormality occurs in the first calculation unit while controlling the automatic driving of the vehicle, the control unit immediately distributes an emergency substitute program for safely stopping the vehicle from a specific memory to the second calculation unit, and after causing the second calculation unit to execute the distributed emergency substitute program, acquires the alternative capability information and executes a process for determining a functional level of the alternative execution content, and distributes an alternative program suited to the alternative capability of the second calculation unit from the specific memory to the second calculation unit and executes it. In-vehicle electronic equipment.

2. The function level is a level of the control content of the vehicle. The in-vehicle electronic device according to claim 1 .

3. The control unit has a data table for determining the function level in accordance with the alternative capability information. The in-vehicle electronic device according to claim 2 .

4. the control unit identifies a second calculation unit that can substitute for the execution unit of the first calculation unit based on the alternative capability information; a substitute program for the execution program of the first calculation unit to the second calculation unit via the communication unit; The in-vehicle electronic device according to claim 3 .

5. The control unit transmits an alternative program for the first calculation unit to the second calculation unit according to the level of the data table. The vehicle-mounted electronic device according to claim 4.

6. The control unit determines a functional level that can be substituted according to at least one of the substituting capability, the free ROM capacity, and the free RAM capacity for each of the calculation units stored in the data table. The in-vehicle electronic device according to claim 3 .

Citation Information

Patent Citations

  • Fail-safe system in integrated control of vehicle

    JP2002221075A

  • Vehicular control device

    JP2004291943A

  • Processor and vehicle control system

    JP2017092835A

  • Automatic driving control device

    JP2021178560A