WO2023209820A1 - 車載電子装置 - Google Patents

車載電子装置 Download PDF

Info

Publication number
WO2023209820A1
WO2023209820A1 PCT/JP2022/018940 JP2022018940W WO2023209820A1 WO 2023209820 A1 WO2023209820 A1 WO 2023209820A1 JP 2022018940 W JP2022018940 W JP 2022018940W WO 2023209820 A1 WO2023209820 A1 WO 2023209820A1
Authority
WO
WIPO (PCT)
Prior art keywords
alternative
vehicle
calculation unit
electronic device
control unit
Prior art date
Application number
PCT/JP2022/018940
Other languages
English (en)
French (fr)
Inventor
亮輔 林
Original Assignee
日立Astemo株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日立Astemo株式会社 filed Critical 日立Astemo株式会社
Priority to PCT/JP2022/018940 priority Critical patent/WO2023209820A1/ja
Publication of WO2023209820A1 publication Critical patent/WO2023209820A1/ja

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements

Definitions

  • the present invention relates to an on-vehicle electronic device.
  • a vehicle is equipped with an ECU (Electronic Control Unit), which is one of the in-vehicle electronic devices, and the ECU controls various parts inside the vehicle.
  • ECU Electronic Control Unit
  • vehicle control systems are generally configured with a plurality of ECUs.
  • a function reconfiguration technique is known in which when an abnormality occurs in this ECU, the function is replaced by another ECU.
  • Patent Document 1 states that in order to improve the immediacy of functional reconfiguration, an alternative program is sent to an alternative control device before a failure occurs, thereby emphasizing continuity, as typified by automatic driving. A technique is described to prevent a decrease in safety due to sudden stoppage of functions.
  • Patent Document 1 in the conventional technology, only one alternative program or degenerate program is associated with one function. As a result, the calculation substitution ability cannot be fully utilized, and the function or performance after an abnormality occurs is more limited than necessary.
  • the present application includes a plurality of means for solving the above problems, and one example is an in-vehicle electronic device that is connected to a plurality of calculation units mounted on a vehicle, and that communicates with the plurality of calculation units. and a control section that issues an instruction for alternative control to the second computing section when an abnormality occurs in any one of the plurality of computing sections.
  • the control unit has a substitution capability that indicates whether the execution content of the first calculation unit can be replaced by the second calculation unit. Get information.
  • the present invention by dynamically monitoring the replacement capability of a calculation unit such as an ECU, it is possible to identify and execute the most suitable calculation unit for function replacement. Therefore, even if an abnormality occurs in the arithmetic unit or the like, it is possible to prevent the comfort of the vehicle from decreasing more than necessary. Problems, configurations, and effects other than those described above will be made clear by the following description of the embodiments.
  • FIG. 7 is a flowchart illustrating an example of processing performed by the control unit according to the first embodiment of the present invention.
  • 7 is a flowchart illustrating an example of processing for determining the functional level and distribution destination of the control unit according to the first embodiment of the present invention.
  • 7 is a flowchart illustrating an example of processing performed by the communication unit according to the first embodiment of the present invention.
  • 3 is a processing sequence of functional reconfiguration according to the first embodiment of the present invention.
  • FIG. 7 is a diagram showing correspondence between operation modes and alternative program function levels according to a second embodiment of the present invention.
  • 12 is a flowchart illustrating an example of processing for determining a function level and a distribution destination according to the second embodiment of the present invention.
  • the present invention is applied to a vehicle control system.
  • Systems installed in vehicles generally have limited resources, unlike information processing systems such as servers installed in buildings. Resources here refer to the number and performance of CPUs (Central Processing Units), memory capacity, etc.
  • CPUs Central Processing Units
  • memory capacity etc.
  • the vehicle control system according to the first embodiment of the present invention is configured to prevent a decrease in safety and comfort when an abnormality occurs, for example, by the configuration and processing described below. .
  • FIG. 1 is a block diagram showing an alternative control determination device 1 constituting an in-vehicle electronic device according to a first embodiment.
  • the alternative control determination device 1 includes a processor 2 , a memory 3 , a nonvolatile memory 4 , and an I/O (Input/Output) device 5 . These processors 2 to I/O devices 5 are connected via an interconnect 6 to exchange data.
  • the I/O device 5 sends and receives data to and from other devices connected to the network link 10 via the network link 10.
  • the network link 10 for example, CAN (Controller Area Network), CAN FD (CAN with Flexible Data-rate, Ethernet: registered trademark), etc. are used.
  • 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 are executed and referenced by the processor 2.
  • OS Operating System
  • 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 are executed and referenced by the processor 2.
  • each unit will be described as the main body of processing, but the actual main body of each process is the processor 2.
  • the control unit 8 and the communication unit 9 are software that runs on the OS 7.
  • abnormality occurrence information of the ECU 13 (FIG. 3) and information of alternative capabilities of the ECU 13 are transmitted to the vehicle control system 20 connected by the network link 10 via the communication unit 9. interact.
  • the exchanged information is written into the alternative capability data table 12, and the control unit 8 is notified of the occurrence of an abnormality 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 it will be distributed. Then, the control unit 8 distributes the alternative program to the determined ECU 13.
  • the alternative control determination 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 determination device 1.
  • FIG. 2 is an overview of a vehicle system 17 having a vehicle control system according to this embodiment.
  • the vehicle system 17 includes a vehicle control system 20 inside an automobile or the like.
  • the vehicle control system 20 here includes, for example, an in-vehicle network and an ECU.
  • the communication device 18 performs wireless communication with the outside of the vehicle system 17.
  • 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).
  • the communication device 18 performs communication using GPS (Global Positioning System).
  • the communication device 18 By performing these communications, the communication device 18 performs wireless communication such as acquiring or transmitting information about the outside world (infrastructure, other cars, maps) or information about the own vehicle.
  • the communication device 18 has 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 communicates with the vehicle control system 20.
  • OBD diagnostic terminal
  • Ethernet terminal for example, a USB memory, a memory card, etc.
  • vehicle system 17 has a vehicle control system 19 that is separate from the vehicle control system 20.
  • vehicle control systems 19 and 20 may be configured with networks using the same protocol, or may be configured with networks using different protocols.
  • a drive device 15 and a recognition device 16 are connected to the vehicle control system 20.
  • the drive device 15 is comprised of actuators and the like that drive mechanical and electrical devices that control vehicle motion under the control of the vehicle control system 20 .
  • the mechanical and electrical devices that control vehicle motion include, for example, an engine, transmission, wheels, brakes, steering device, and the like.
  • the recognition device 16 includes external sensors such as a camera, radar, LIDAR, and ultrasonic sensor, and dynamic sensors that recognize the state of the vehicle system 17 (motion state, position information, acceleration, wheel speed, etc.). The sensors forming these recognition devices 16 acquire information input from the outside world and generate outside world recognition information, which will be described later.
  • FIG. 3 shows a configuration example of the vehicle control system 20 according to this embodiment.
  • a network link 10 connects each device on the in-vehicle network.
  • a plurality of ECUs 13 , a gateway (hereinafter referred to as GW) 14 , and an alternative control determination device 1 are connected to the network link 10 .
  • a drive device 15 and a recognition device 16 are connected to each ECU 13 according to the ECU 13 at each position.
  • the ECU 13 controls the drive device 15 and the recognition device 16, and also acquires information from the drive device 15 and the recognition device 16. Further, the ECU 13 transmits and receives data to and from the network link 10.
  • the ECU 13 may be connected to another network link other than the network link 10 and may perform data transmission and reception with the other network link.
  • Each ECU 13 has a built-in CPU, which is an arithmetic unit, and various processes are executed under the control of the CPU.
  • a gateway (hereinafter referred to as GW) 14 connects a plurality of network links 10 and sends and receives data to and from each network link. Another network link other than the network link 10 may be connected to the GW 14.
  • FIG. 4 shows an example of the configuration of the alternative program data table 11 provided in the alternative control determination device 1.
  • the CPUs described below each refer to a CPU that is a calculation unit built into the ECU 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 includes a program storage pointer for each function level, CPU alternative capacity, ROM (Read Only Memory) free space, and RAM (Random Access Memory) free space, which are the conditions for selecting a function level. is registered.
  • the ROM free capacity and RAM free capacity are the free capacities of the ROM and RAM connected to the CPU.
  • ROM free space and RAM free space mentioned here refer to the free space of a memory element called ROM or RAM, the free space of an area where programs are stored (ROM free space), or the space used for calculations and control. If it is the free capacity of the work area to be used (RAM free capacity), it also includes the capacity of other memories.
  • function level 0 is a function level that only allows manual driving without driving support
  • function level 1 is a function level that detects people and vehicles, etc. and provides driving support to avoid collisions
  • function level 2 is a function level that allows only manual driving without driving support.
  • FIG. 5 shows the configuration of the alternative capability data table 12 provided in the alternative control determination device 1.
  • the status, performance, CPU usage rate, ROM free space, RAM free space, and operable function level of each CPU are recorded.
  • FIG. 5 shows the status, performance, CPU usage rate, ROM free space, RAM free space, and operable function level for each of the five CPUs with CPU identifiers 0 to 4.
  • values input at the time of design may be determined for performance, ROM free space, and RAM free space.
  • the CPU usage rate reflects the alternative capacity information obtained from each control device.
  • the operable level is determined by the control unit 8 with reference to data in other fields and the alternative program data table.
  • the state of the CPU with identifier 0 is abnormal (failure, etc.), and the performance, CPU usage rate, ROM free space, RAM free space, 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. Further, the states of the CPUs with identifiers 1 to 4 in FIG.
  • FIG. 6 is a flowchart showing the processing performed by the control unit 8 of the alternative control determination device 1.
  • the processing in the control unit 8 is started when the control unit 8 is notified of the occurrence of an abnormality from the data received by the communication unit 9, and is executed as follows.
  • the control unit 8 compares the alternative capability data table 12 and the alternative program data table 11, and determines the functional level of the alternative program and its distribution destination (step S101).
  • the control unit 8 acquires the alternative program determined in step S101 from the nonvolatile memory 4 (step S102).
  • the control unit 8 distributes the alternative program acquired in step S102 to the distribution destination determined in step S101 (step S103).
  • FIG. 7 is a flowchart showing details of the process of determining the function level and distribution destination in step S101 of the flowchart of FIG. 6, among the processes performed by the control unit 8 of the alternative control determination device 1.
  • the control unit 8 starts a loop of CPU identifiers in the alternative capability data table 12 (step S201). Then, the control unit 8 determines whether the value of the status field of the CPU selected in step S201 matches the value indicating normality (step S202). If the value of the CPU status field matches the value indicating normality, the process advances to step S203 (step S202: Yes), and if they do not match (step S202: No), the loop of step S201 is updated.
  • control unit 8 selects the best program that satisfies the conditions at each function level on the alternative program data table 11 based on the values in the alternative capability data table 12 of the selected CPU. A high functional level is determined (step S203).
  • step S204 the control unit 8 records the functional level obtained in step S203 in the operable functional 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 of the CPUs of all identifiers is completed (step S205), the process moves to step S206.
  • 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.
  • FIG. 8 is a flowchart showing the processing performed by the communication unit 9 of the alternative control determination device 1.
  • the communication unit 9 detects the occurrence of an abnormality in one of the ECUs 13 (step S301).
  • the communication unit 9 acquires alternative capability information of each ECU 13 connected via the network (step S302).
  • the communication unit 9 updates the alternative ability data table 12 based on the obtained alternative ability information (step S303).
  • 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).
  • FIG. 9 shows a processing sequence of functional reconfiguration by the alternative control determination device 1.
  • an abnormality occurs in the first ECU 13a (step S911).
  • the abnormality here includes not only the case where the first ECU 13a breaks down but also the occurrence of various malfunctions such as the case where a device such as a sensor connected to the first ECU 13a is defective. In addition to a defect in the sensor itself, the sensor may not be able to measure properly due to factors such as the weather.
  • the first ECU 13a in which the abnormality has occurred notifies the alternative control determination device 1 of the occurrence of the abnormality (occurrence of malfunction) (step S912).
  • the alternative control determination device 1 which has received the abnormality occurrence, requests alternative capability information from another ECU (second ECU) 13b (step S913).
  • the second ECU 13b which has received the request for alternative capability information, transmits the alternative capability information to the alternative control determination device 1, and the alternative control determination device 1 acquires the alternative capability information (step S914).
  • the alternative control determination device 1 obtains the alternative program from the nonvolatile memory 4 (step S915). This alternative program replaces the program that was being executed in the first ECU 13a that was notified of the occurrence of the abnormality in step S912. Then, the alternative control determination device 1 distributes the alternative program to the second ECU 13b (step S916).
  • the second ECU 13b stores the distributed alternative program and immediately executes the alternative program.
  • the abnormality of the ECU here includes various abnormalities such as a failure of a sensor connected to the ECU, a malfunction of a sensor due to weather, etc., in addition to a failure of the ECU.
  • a program for performing alternative calculations is sent to a calculation unit that satisfies alternative capabilities, and an appropriate program is sent depending on the situation. become able to. That is, if the destination ECU has sufficient replacement (surplus) capacity, an alternative program with exactly the same function as the program being executed by the ECU in which the abnormality has occurred can be stored in the destination ECU. Then, it can be replaced with another ECU without functional limitations. On the other hand, if there is a limit to the ability or function of the replacement program depending on the replacement (surplus) ability of the destination ECU, there will be a certain degree of restriction, but depending on the ability of the replacement program, the vehicle It is possible to prevent the comfort level from decreasing more than necessary.
  • the functional level which is the level of the control content of the vehicle
  • the functional level can be easily determined by preparing an alternative program data table 11 as shown in FIG. 4 and referring to this data table 11.
  • each ECU it is possible to identify which ECU (its calculation unit) should be used as a replacement, and to send a replacement program to the identified ECU to replace it.
  • the most suitable ECU can be selected and replaced.
  • the alternative program can be quickly transmitted from the alternative control determining device 1.
  • the alternative program data table 11 shown in FIG. It is easy to determine whether a degree of replacement ability is required.
  • an in-vehicle electronic device according to a second embodiment of the present invention will be described with reference to FIGS. 10 to 12.
  • the configuration of the alternative control determination device 1 the configuration of the vehicle system having the vehicle control system, and the network configuration to which the in-vehicle electronic device is connected are the same as those in the first embodiment. be.
  • the second embodiment differs from the first embodiment in details of the process for determining a distribution destination in the event of an abnormality.
  • 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 referred to in step S101 of the flowchart of FIG. 6 of the first embodiment.
  • each operating mode When designing software to be installed in each ECU, the processing load of each operating mode is calculated in advance, the operable level of each alternative program candidate is determined, and data indicating the correspondence relationship between them is implemented.
  • ACC is a driving mode in which the vehicle follows the vehicle in front at a speed below a set speed. Then, for each of the three operating modes, program A, program B, and program C, the function level is set in six levels from 0 to 5.
  • FIG. 11 is a flowchart illustrating an example of a process for determining a function level and a distribution destination according to the second embodiment.
  • the control unit 8 refers to the operation mode/substitute program function level correspondence table shown in FIG. 10, and outputs the CPU identifier and function level of the program to be substituted with the highest function level among the CPUs (step S401). In other words, the control unit 8 calculates the substitute capability of each CPU according to the operating mode of the vehicle, and outputs the CPU identifier and the function level of which the substitute program has the highest function level.
  • the operating mode of each CPU uses the value transmitted from the communication unit 9.
  • FIG. 12 is a flowchart showing an example of processing performed by the communication unit 9.
  • the communication unit 9 detects the occurrence of an abnormality in one of the ECUs 13 (step S501).
  • the communication unit 9 acquires operation mode information of each CPU (step S502).
  • the communication unit 9 notifies the control unit 8 of the operation mode of each CPU and the occurrence of an abnormality, and starts processing (step S503).
  • Other configurations and processing in the second embodiment are the same as those described in the first embodiment.
  • the execution time of the processor that was occupied by the calculation of the alternative capacity in the first embodiment can be saved, so it is possible to more quickly transfer functions in the event of an abnormality.
  • an alternative program can be selected and transmitted according to the determined functional level, and the alternative program is determined based on the functional level, making it easy to determine the alternative program.
  • FIGS. 13 and 14 an in-vehicle electronic device according to a third embodiment of the present invention will be described with reference to FIGS. 13 and 14.
  • the configuration of the alternative control determination device 1 the configuration of the vehicle system having the vehicle control system, and the network configuration to which the in-vehicle electronic device is connected are the same as those in the first embodiment. be.
  • the third embodiment differs from the first embodiment in details of the function reconfiguration process.
  • FIG. 14 is a flowchart showing an example of processing performed by the control unit 8 according to the third embodiment.
  • the control unit 8 acquires an emergency alternative program from the nonvolatile memory 4 (step S601). Then, the control unit 8 distributes the emergency alternative program acquired in step S601 to another ECU (second ECU 13b) (step S602).
  • steps S101, S102, and S103 in the flowchart of FIG. 6 described in the first embodiment are performed. That is, the control unit 8 compares the alternative capability data table 12 and the alternative program data table 11, and determines the functional 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 nonvolatile memory 4 (step S102). Further, 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 processing in the third embodiment are the same as those described in the first embodiment.
  • a substitute program can be distributed at a stage before investigating the substitute capability of each ECU when an abnormality occurs.
  • the minimum function transition is quickly completed before acquiring the alternative capability information of each ECU. Then, it becomes possible to prevent the vehicle from falling into a dangerous state during the acquisition of the alternative capability information, the determination of the functional level, and the determination of the alternative program distribution destination.
  • Information such as programs, tables, files, etc. that realize the functions performed by the alternative control determination device 1 is stored in a memory, a recording device such as a hard disk, an SSD (Solid State Drive), or a recording medium such as an IC card, SD card, or DVD. can be placed in a memory, a recording device such as a hard disk, an SSD (Solid State Drive), or a recording medium such as an IC card, SD card, or DVD. can be placed in
  • an alternative capability request is made to another calculation unit in response to the occurrence of an abnormality (occurrence of a malfunction).
  • the alternative control determination device 1 may acquire alternative capability information before the occurrence of a malfunction. That is, the alternative control determination device 1 acquires information on the alternative capability of the CPU (computing unit) of each ECU connected to the in-vehicle network at any time (regularly or irregularly) regardless of the occurrence of a malfunction, and You may want to be able to deal with it at times.
  • the alternative control determination device when receiving a notification of an abnormality occurrence (failure occurrence), performs processing to consider alternative control, so that the It is only necessary to consider alternative control, and as long as no malfunction occurs, there is no need to have the alternative control determination device perform extra processing, and the processing load on the in-vehicle network can be reduced.
  • the application is applied to an in-vehicle network in which an ECU with a built-in CPU as a calculation unit is connected via a network, but the present invention can also be applied to a device with a built-in calculation unit other than a CPU. It is.
  • SYMBOLS 1...Alternative control determination device, 2...Processor, 3...Memory, 4...Nonvolatile 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 device, 16... Recognition device, 17... Vehicle system, 18... Communication device, 19, 20... Vehicle control system

Landscapes

  • Engineering & Computer Science (AREA)
  • Mechanical Engineering (AREA)
  • Arrangements For Transmission Of Measured Signals (AREA)

Abstract

車両に搭載された複数の演算部と接続される車載電子装置であって、複数の演算部と通信を行う通信部と、複数の演算部の何れかで異常が発生した場合に他の演算部へ代替制御の指示を出す制御部とを備える。制御部は、複数の演算部の内の第一の演算部で異常が発生した際に、他の演算部から第一の演算部の実行内容を代替可能か示す代替能力情報を取得する。

Description

車載電子装置
　本発明は、車載電子装置に関する。
　車両には、車載電子装置の一つであるＥＣＵ（Electronic Control Unit:電子制御ユニット）が搭載され、ＥＣＵが車内の各部を制御している。近年の車両制御システムは、複数のＥＣＵで構成されるのが一般的である。
　このＥＣＵに異常が発生した場合、別のＥＣＵで機能を代替する機能再構成技術が知られている。
　特許文献１には、機能再構成の即時性を向上させるために、故障発生前に代替プログラムを代替用制御装置に送信しておくことで、自動運転に代表される、連続性が重視される機能の突然の停止による安全性低下を防止する技術が記載されている。
特開２０１７－０９２８３５号公報
　上述したように、近年の車両制御システムは複数のＥＣＵで構成されており、さらにＥＣＵ自体にも複数のプロセッサが搭載されていることが多い。そのため、ひとつのＥＣＵに異常が発生した場合でも、他のＥＣＵに演算代替能力がある場合が多く、機能再構成を行うことにより、故障したＥＣＵで実現されていた機能を肩代わりすることができる。
　しかしながら、特許文献１に記載されるように、従来の技術では、ひとつの機能に対して、ひとつの代替プログラムもしくは縮退プログラムが対応付けられているのみであった。そのため、演算代替能力を十分活かすことができず、必要以上に異常発生後の機能もしくは性能が制限されていた。
　このため、機能再構成後の性能低下を抑制することができる車載電子装置が望まれていた。
　上記課題を解決するために、例えば請求の範囲に記載の構成を採用する。
　本願は、上記課題を解決する手段を複数含んでいるが、その一例を挙げるならば、車両に搭載された複数の演算部と接続される車載電子装置であって、複数の演算部と通信を行う通信部と、複数の演算部の何れかで異常が発生した場合に第二の演算部へ代替制御の指示を出す制御部と、を備える。
　そして、制御部は、複数の演算部の一つである第一の演算部にて異常が発生した際に、第一の演算部の実行内容を第二の演算部で代替可能か示す代替能力情報を取得する。
　本発明によれば、ＥＣＵなどの演算部の代替能力を動的にモニタすることで、機能の代替に最適な演算部を特定して実行することができる。このため、演算部などに異常が発生した場合でも、車両の快適性が必要以上に低下することを防ぐことが可能となる。
　上記した以外の課題、構成および効果は、以下の実施形態の説明により明らかにされる。
本発明の第１の実施の形態例に係る車載電子装置としての代替制御判断装置の構成の一例を示すブロック図である。 本発明の第１の実施の形態例に係る車両制御システムを有する車両システムの概要を示す図である。 本発明の第１の実施の形態例に係る車載電子装置が接続されたネットワーク例を示す構成図である。 本発明の第１の実施の形態例に係る代替プログラムデータテーブルの構成の一例を示す図である。 本発明の第１の実施の形態例に係る代替能力データテーブルの構成の一例を示す図である。 本発明の第１の実施の形態例に係る制御部で行われる処理の一例を示すフローチャートである。 本発明の第１の実施の形態例に係る制御部の機能レベルと配信先の決定の処理の一例を示すフローチャートである。 本発明の第１の実施の形態例に係る通信部で行われる処理の一例を示すフローチャートである。 本発明の第１の実施の形態例に係る機能再構成の処理シーケンスである。 本発明の第２の実施の形態例に係る動作モード／代替プログラム機能レベル対応を示す図である。 本発明の第２の実施の形態例に係る機能レベルと配信先の決定の処理の一例を示すフローチャートである。 本発明の第２の実施の形態例に係る通信部で行われる処理の一例を示すフローチャートである。 本発明の第３の実施形態例に係る機能再構成の処理シーケンスである。 本発明の第３の実施形態例に係る制御部で行われる処理の一例を示すフローチャートである。
　以下、本発明の実施の形態例を順に説明する。なお、以下に説明する各実施の形態例は、好適な例を示すものであり、本発明は以下に説明する各実施の形態例に限定されるものではなく、本発明の趣旨を逸脱しない範囲で、各部の構成などを適宜追加、変更、削除などして実施することができる。
　以下の各実施の形態例では、本発明を車両制御システムに適用した場合を示す。一般的に車両に搭載されるシステムは、サーバなどの建物内に設置された情報処理システムと異なり、リソースが制限されていることが多い。ここでのリソースとは、ＣＰＵ（Central Processing Unit）の数や性能、メモリ搭載容量などを意味する。
　リソースが制限されていることで、車両制御システムは、異常発生時に車両の機能を停止もしくは性能を著しく低下させなければならず、安全性および快適性の低下に懸念があった。ここで、本発明の第１の実施形態例に係る車両制御システムは、以下に説明する構成および処理により、例えば、異常発生時の安全性および快適性の低下を防止するようにしたものである。
＜第１の実施の形態例＞
　以下、本発明の第１の実施の形態例の車載電子装置を、図１～図９を参照して説明する。
　図１は、第１の実施の形態例に係る車載電子装置を構成する代替制御判断装置１を示すブロック図である。
　代替制御判断装置１は、プロセッサ２と、メモリ３と、不揮発性メモリ４と、Ｉ／Ｏ（Input/Output）デバイス５とを含む。これらのプロセッサ２～Ｉ／Ｏデバイス５は、インターコネクト６を介して接続され、データのやり取りが行われる。
　Ｉ／Ｏデバイス５は、ネットワークリンク１０を介して、ネットワークリンク１０で接続された他の機器とデータの送受信を行う。ネットワークリンク１０としては、例えば、ＣＡＮ(Controller Area Network)、ＣＡＮＦＤ(CAN with Flexible Data-rate、Ethernet:登録商標)等が使用される。
　メモリ３には、ＯＳ(Operating System)７と、制御部８と、通信部９と、代替プログラムデータテーブル１１と、代替能力データテーブル１２とがロードされ、プロセッサ２によって実行および参照される。以下の説明では、便宜上、各部を処理の動作主体として説明するが、各処理の実際の動作主体はプロセッサ２である。
　制御部８と、通信部９は、ＯＳ７上で稼働するソフトウェアである。
　このように構成される代替制御判断装置１では、通信部９を介して、ネットワークリンク１０で接続された車両制御システム２０と、ＥＣＵ１３（図３）の異常発生情報や、ＥＣＵ１３の代替能力情報をやり取りする。やり取りした情報は、代替能力データテーブル１２に書き込まれ、通信部９経由で制御部８に異常発生が通知される。制御部８は、代替プログラムデータテーブル１１と代替能力データテーブル１２の読み書きを行い、適切な代替プログラムのレベルとその配信先となるＥＣＵ１３を決定する。そして、制御部８は、決定したＥＣＵ１３に代替プログラムを配信する。
　なお、代替制御判断装置１は、専用の装置として構成してもよいが、後述するＥＣＵ１３の一つが、代替制御判断装置１としての機能を備えるようにしてもよい。
　図２は、本実施形態例に係る車両制御システムを有する車両システム１７の概要である。
　車両システム１７は、自動車など内部に車両制御システム２０を有する。ここでの車両制御システム２０は、例えば車載ネットワークとＥＣＵにより構成される。
　通信装置１８は、車両システム１７の外部と無線通信を行う。例えば通信装置１８は、携帯電話の通信、無線ＬＡＮ(Local Area Network)、ＷＡＮ(Wide Area Network)、Ｃ２Ｘ(Car to X:車両対車両または車両対インフラ通信)等のプロトコルを使用した通信を行う。あるいは通信装置１８は、ＧＰＳ(Global Positioning System)を用いた通信を行う。
　通信装置１８がこれらの通信を行うことで、外界（インフラ、他車、地図）の情報または自車に関する情報を取得または送信などの無線通信を実施する。
　あるいは通信装置１８は、診断端子（ＯＢＤ）やEthernet端子、外部記録媒体（例えばＵＳＢメモリ、メモリカード等）の端子を有し、車両制御システム２０と通信を実施する。
　また、車両システム１７は、車両制御システム２０とは別の車両制御システム１９を有する。車両制御システム１９、２０は、同一のプロトコルを用いたネットワークで構成する場合と、それぞれ異なるプロトコルを用いたネットワークで構成する場合のいずれでもよい。
　また、車両制御システム２０には、駆動装置１５と、認識装置１６とが接続されている。
　駆動装置１５は、車両制御システム２０の制御に従い、車両運動を制御する機械および電気装置の駆動を行うアクチュエータ等から構成される。ここで、車両運動を制御する機械および電気装置としては、例えばエンジン、トランスミッション、ホイール、ブレーキ、操舵装置等が含まれる。
　認識装置１６は、カメラ、レーダ、ＬＩＤＡＲ、超音波センサなどの外界センサ、および、車両システム１７の状態（運動状態、位置情報、加速度、車輪速度等）を認識する力学系センサにより構成される。これらの認識装置１６を構成するセンサは、外界から入力される情報を取得し、後述する外界認識情報を生成する。
　図３は、本実施の形態例に係る車両制御システム２０の構成例を示している。
　ネットワークリンク１０は、車載ネットワーク上の各装置を接続している。ネットワークリンク１０には、複数のＥＣＵ１３と、ゲートウェイ（以下ＧＷ）１４と、代替制御判断装置１とが接続されている。
　それぞれのＥＣＵ１３には、それぞれの位置のＥＣＵ１３に応じて駆動装置１５や認識装置１６が接続されている。そして、ＥＣＵ１３は、駆動装置１５や認識装置１６を制御するとともに、駆動装置１５および認識装置１６からの情報取得を行う。また、ＥＣＵ１３はネットワークリンク１０へのデータ送受信を行う。さらに、ＥＣＵ１３は、ネットワークリンク１０以外の別ネットワークリンクが接続されて、その別ネットワークリンクとのデータ送受信を行う場合もある。それぞれのＥＣＵ１３には、演算部であるＣＰＵが内蔵され、ＣＰＵの制御により各種処理が実行される。
　ゲートウェイ（以下ＧＷ）１４は、複数のネットワークリンク１０を接続し、それぞれのネットワークリンクとデータの送受信を行う。ＧＷ１４には、ネットワークリンク１０以外の別ネットワークリンクが接続される場合もある。
　図４は、代替制御判断装置１に設けられた代替プログラムデータテーブル１１の構成の一例を示している。以下に説明するＣＰＵは、それぞれＥＣＵ１３に内蔵された演算部であるＣＰＵを示す。
　代替プログラムデータテーブル１１は、代替処理を想定するプログラムごとに作成される。代替プログラムデータテーブル１１の各フィールドには、機能レベルごとのプログラム格納先ポインタと、機能レベル選択時の条件となるＣＰＵ代替能力、ＲＯＭ（Read Only Memory）空き容量、ＲＡＭ（Random Access Memory）空き容量が登録されている。ここで、ＲＯＭ空き容量とＲＡＭ空き容量は、ＣＰＵに接続されたＲＯＭとＲＡＭの空き容量である。
　なお、ここで述べるＲＯＭ空き容量やＲＡＭ空き容量は、ＲＯＭまたはＲＡＭと称されるメモリ素子の空き容量の他、プログラムなどが格納される領域の空き容量（ＲＯＭ空き容量）、または演算や制御に使用されるワーク領域の空き容量（ＲＡＭ空き容量）であれば、他のメモリの容量も含む。
　図４の例では、機能レベルとして、機能レベル０～５の６段階の機能レベルごとに、それぞれ別のプログラム格納先ポインタＰ０～Ｐ５が示されている。そして、機能レベル１～５として、それぞれの機能レベルに該当するＣＰＵ代替能力、ＲＯＭ空き容量、ＲＡＭ空き容量の最小値が設定されている。機能レベル０は、ＣＰＵ代替能力、ＲＯＭ空き容量、ＲＡＭ空き容量がこれらの機能レベル１～５に該当しない場合である。
　なお、ここでは、ＣＰＵ代替能力、ＲＯＭ空き容量、ＲＡＭ空き容量の３つと機能レベルとを対応させた例としたが、代替プログラムデータテーブル１１は、ＣＰＵ代替能力、ＲＯＭ空き容量、ＲＡＭ空き容量の少なくとも１つと機能レベルとを対応させたものとしてもよい。
　機能レベル０～５の６段階としては、機能レベルが高くなるに従って高度な運転支援を行うことが考えられる。例えば機能レベル０は、運転支援なしの手動運転のみを許容する機能レベル、機能レベル１は人や車両などを検知して衝突を回避する運転支援を行う機能レベル、機能レベル２は機能レベル１に加えて車線を維持する運転支援を行う機能レベルなどとする。
　図５は、代替制御判断装置１に設けられた代替能力データテーブル１２の構成を示している。
　代替能力データテーブル１２の各フィールドには、ＣＰＵごとの状態、性能、ＣＰＵ使用率、ＲＯＭ空き容量、ＲＡＭ空き容量、動作可能機能レベルが記録される。図５では、ＣＰＵ識別子０～４の５つのＣＰＵについて、ＣＰＵごとの状態、性能、ＣＰＵ使用率、ＲＯＭ空き容量、ＲＡＭ空き容量、動作可能機能レベルを示す。
　これらの代替能力データのうち、性能、ＲＯＭ空き容量、ＲＡＭ空き容量については、設計時に入力される値を決定してもよい。ＣＰＵ使用率は、各制御装置から取得する代替能力情報を反映する。動作可能レベルは、制御部８が他の各フィールドのデータと、代替プログラムデータテーブルを参照して決定される。
　図５では、識別子０のＣＰＵの状態が異常（故障など）であり、性能、ＣＰＵ使用率、ＲＯＭ空き容量、ＲＡＭ空き容量、動作可能機能レベルは、該当なし（Ｎ／Ａ）となっている。識別子０のＣＰＵが動作できる状態で異常の場合には、動作可能機能レベルでどの程度動作できるかが示される。
　また、図５の識別子１～４のＣＰＵの状態は正常であり、性能、ＣＰＵ使用率、ＲＯＭ空き容量、ＲＡＭ空き容量の各フィールドには、それぞれの値が設定されている。識別子１～４のＣＰＵの動作可能機能レベルは、後述する図７のフローチャートに示す処理で設定される。
　図６は、代替制御判断装置１の制御部８で行われる処理を示すフローチャートである。
　制御部８における処理は、通信部９が受信したデータから、制御部８に異常発生が通知されることで開始され、以下のように実行される。
　まず、制御部８は、代替能力データテーブル１２と、代替プログラムデータテーブル１１とを比較し、代替プログラムの機能レベルとその配信先を決定する（ステップＳ１０１）。
　次に、制御部８は、ステップＳ１０１で決定した代替プログラムを不揮発性メモリ４から取得する（ステップＳ１０２）。
　そして、制御部８は、ステップＳ１０２で取得した代替プログラムを、ステップＳ１０１で決定した配信先に配信する（ステップＳ１０３）。
　図７は、代替制御判断装置１の制御部８が行う処理の内で、図６のフローチャートのステップＳ１０１の機能レベルおよび配信先の決定の処理の詳細を示すフローチャートである。
　まず、制御部８は、代替能力データテーブル１２のＣＰＵ識別子のループを開始する（ステップＳ２０１）。
　そして、制御部８は、ステップＳ２０１で選択したＣＰＵの状態フィールドの値が正常を示す値と一致するかどうか判定する（ステップＳ２０２）。ＣＰＵの状態フィールドの値が正常を示す値と一致する場合は、ステップＳ２０３へ進み（ステップＳ２０２：Ｙｅｓ）、一致しない場合は（ステップＳ２０２：Ｎｏ）、ステップＳ２０１のループを更新する。
　ＣＰＵの状態フィールドが正常の場合（ステップＳ２０２：Ｙｅｓ）、制御部８は、選択したＣＰＵの代替能力データテーブル１２の値を基に、代替プログラムデータテーブル１１上の各機能レベルにおいて条件を満たす最も高い機能レベルを求める（ステップＳ２０３）。
　そして、制御部８は、ステップＳ２０３で求めた機能レベルを、選択したＣＰＵの代替能力データテーブル１２上の動作可能機能レベルフィールドに記録する（ステップＳ２０４）。
　このステップＳ２０２～Ｓ２０４の処理が、すべての識別子のＣＰＵについてループで実行され、すべての識別子のＣＰＵのループが終了すると（ステップＳ２０５）、ステップＳ２０６に移る。
　ステップＳ２０６では、制御部８は、代替能力データテーブル１２の動作可能機能レベルフィールドの値が最も大きいＣＰＵ識別子とその動作可能機能レベルを出力する。
　図８は、代替制御判断装置１の通信部９で行われる処理を示すフローチャートである。
　まず、通信部９は、いずれかのＥＣＵ１３での異常発生を検知する（ステップＳ３０１）。
　異常発生を検知すると、通信部９は、ネットワークで接続されている各ＥＣＵ１３の代替能力情報を取得する（ステップＳ３０２）。
　次に、通信部９は、取得した代替能力情報を基に代替能力データテーブル１２を更新する（ステップＳ３０３）。
　そして、通信部９は、制御部８に異常発生を通知し、制御部８での処理を開始させる（ステップＳ３０４）。
　図９は、代替制御判断装置１による機能再構成の処理シーケンスを示す。
　まず、第１のＥＣＵ１３ａにおいて異常が発生する（ステップＳ９１１）。ここでの異常は、第１のＥＣＵ１３ａが故障する場合の他、第１のＥＣＵ１３ａに接続されたセンサなどの機器が不良の場合などの様々な不具合の発生も含まれる。センサの不良としては、センサ自身の不良の他、天候などの要因でセンサが適正に計測できない場合もある。
　この異常が発生した第１のＥＣＵ１３ａから、代替制御判断装置１に異常発生(不具合発生)が通知される（ステップＳ９１２）。
　異常発生を受信した代替制御判断装置１は、別のＥＣＵ（第２のＥＣＵ）１３ｂに代替能力情報を要求する（ステップＳ９１３）。
　代替能力情報の要求を受信した第２のＥＣＵ１３ｂは、代替制御判断装置１に代替能力情報を送信し、代替制御判断装置１が代替能力情報を取得する（ステップＳ９１４）。
　次に、代替制御判断装置１は、不揮発性メモリ４から代替プログラムを取得する（ステップＳ９１５）。この代替プログラムは、ステップＳ９１２で異常発生が通知された第１のＥＣＵ１３ａで実行されていたプログラムを代替するものである。
　そして、代替制御判断装置１は、第２のＥＣＵ１３ｂに代替プログラムを配信する（ステップＳ９１６）。
　第２のＥＣＵ１３ｂでは、配信された代替プログラムを格納して、その代替プログラムを直ちに実行する。
　以上説明したように、本実施の形態例によれば、あるＥＣＵに異常が発生した場合に、他のＥＣＵに処理を移行することで、車両の快適性が必要以上に低下することを防ぐことが可能となる。ここで、ここで、異常発生時に他のＥＣＵで代替可能か示す代替能力情報を取得するようにしたことで、動的な代替能力を把握することができる。なお、ここでのＥＣＵの異常とは、ＥＣＵの故障の他、ＥＣＵに接続されたセンサの故障や、天候等によるセンサの機能不全などの様々な異常が含まれる。
　他のＥＣＵに処理を移行する際には、本実施の形態例によると、代替能力を満たす演算部へ代替演算をするためのプログラムを送信することにより、その時々に応じて適切なプログラムを送信できるようになる。すなわち、移行先のＥＣＵの代替（余剰）能力が十分にある場合には、異常発生したＥＣＵで実行中のプログラムと全く同じ機能の代替プログラムが移行先のＥＣＵに格納することができる。そして、機能制限がない状態で他のＥＣＵに代替させることができる。
　これに対して、移行先のＥＣＵの代替（余剰）能力に応じて、代替プログラムの能力や機能に制限がある場合には、ある程度の制限が行われるが、代替プログラムの能力に応じて、車両の快適性が必要以上に低下することを防ぐことできる。
　この場合、代替能力を示すものとして、車両の制御内容のレベルである機能レベルとしたことで、機能レベルで車両の制御がどの程度まで代替できるかが適切に示せるようになる。また、この機能レベルは、図４に示すような代替プログラムデータテーブル１１を用意して、このデータテーブル１１を参照して決定することで、簡単に機能レベルを決定できるようになる。
　また、各ＥＣＵの代替能力に基づいて、どのＥＣＵ（の演算部）に代替させればよいかを特定して、その特定したＥＣＵに代替プログラムを送信して代替させることで、代替させるのに最も適したＥＣＵを選んで代替させることができる。
　また、代替プログラムは、代替制御判断装置１内のメモリ３に用意することで、代替制御判断装置１から迅速に代替プログラムを送信できるようになる。
　さらに、図４に示すような代替プログラムデータテーブル１１で設定したように、車両の動作モードである機能レベルに応じて、移行先のＥＣＵの代替（余剰）能力を求める演算を行うことで、どの程度の代替能力が必要か簡単に決まる。
＜第２の実施の形態例＞
　次に、本発明の第２の実施の形態例の車載電子装置を、図１０～図１２を参照して説明する。第２の実施の形態例では、代替制御判断装置１の構成、車両制御システムを有する車両システムの構成、および車載電子装置が接続されたネットワーク構成については、第１の実施の形態例と同じである。
　そして、第２の実施の形態例では、異常時に配信先を決定する処理の詳細が、第１の実施の形態例と相違する。
　図１０は、本発明の第２の実施の形態例に係る動作モード／代替プログラム機能レベル対応テーブルを示す図である。
　この図１０に示す動作モード／代替プログラム機能レベル対応テーブルは、第１の実施の形態例の図６のフローチャートのステップＳ１０１で参照される対応テーブルである。
　各ＥＣＵに実装されるソフトウェアの設計時には、あらかじめ各動作モードの処理負荷を計算しておき、各代替プログラム候補の動作可能レベルを求め、それらの対応関係を示すデータが実装される。
　ここでの動作モードとしては、たとえば、一般道路の自動運転モード、高速道路（自動車専用道路）の自動運転モード、ＡＣＣ（アダプティブ・クルーズ・コントロール）時の運転モード、手動運転モードの４種類が用意される。なお、ＡＣＣは、設定された速度以下で前の車両に追随して走行する運転モードである。
　そして、それぞれの動作モードについて、プログラムＡ、プログラムＢ、プログラムＣの３つについて、機能レベルが０から５までの６段階に設定される。
　図１１は、第２の実施の形態例に係る機能レベルと配信先の決定の処理の一例を示すフローチャートである。
　制御部８は、図１０に示す動作モード／代替プログラム機能レベル対応テーブルを参照し、各ＣＰＵのうち、代替するプログラムの機能レベルがもっとも高いＣＰＵ識別子と機能レベルを出力する（ステップＳ４０１）。つまり、制御部８は、車両の動作モードに応じて、各ＣＰＵの代替能力の演算を行って、その代替するプログラムの機能レベルがもっとも高いＣＰＵ識別子と機能レベルを出力する。各ＣＰＵの動作モードは、通信部９から送信された値を用いる。
　図１２は、通信部９で行われる処理の一例を示すフローチャートである。
　まず、通信部９は、いずれかのＥＣＵ１３での異常発生を検知する（ステップＳ５０１）。
　異常発生を検知すると、通信部９は、各ＣＰＵの動作モード情報を取得する（ステップＳ５０２）。
　そして、通信部９は、制御部８に各ＣＰＵの動作モードと異常発生とを通知し、処理を開始させる（ステップＳ５０３）。
　第２の実施の形態例におけるその他の構成や処理は、第１の実施の形態例で説明したものと同じである。
　本発明の第２の実施の形態例によれば、第１の実施の形態例において代替能力の算出が占有していたプロセッサの実行時間を省けるため、異常発生時により迅速な機能移行が可能となる。ずなわち、決定した機能レベルに応じて、代替プログラムを選定して送信することができ、代替プログラムが機能レベルで決まり、代替プログラムが簡単に決まるようになる。
＜第３の実施の形態例＞
　次に、本発明の第３の実施の形態例の車載電子装置を、図１３～図１４を参照して説明する。第３の実施の形態例でも、代替制御判断装置１の構成、車両制御システムを有する車両システムの構成、および車載電子装置が接続されたネットワーク構成については、第１の実施の形態例と同じである。
　そして、第３の実施の形態例では、機能再構成の処理の詳細が、第１の実施の形態例と相違する。
　図１３は、第３の実施の形態例に係る機能再構成の処理シーケンスである。
　まず、第１のＥＣＵ１３ａにおいて異常が発生する（ステップＳ９１１）。
　この異常が発生した第１のＥＣＵ１３ａから、代替制御判断装置１に異常発生が通知される（ステップＳ９１２）。
　異常発生を受信した代替制御判断装置１は、不揮発性メモリ４から緊急用代替プログラムを取得する（ステップＳ９２１）。緊急用代替プログラムの一例としては、たとえば第１のＥＣＵ１３ａが自動運転の制御を行った状況で異常が発生した場合に、車両を路側帯などに安全に停止させる制御を行うプログラムが考えられる。
　代替制御判断装置１は、ステップＳ９２１で取得した緊急用代替プログラムを、第２のＥＣＵ１３ｂに配信する（ステップＳ９２２）。第２のＥＣＵ１３ｂは、配信された緊急用代替プログラムを格納して、直ちに実行する。
　その上で、代替制御判断装置１は、第２のＥＣＵ１３ｂなどの他のＥＣＵに代替能力情報を要求する（ステップＳ９２３）。
　代替能力情報の要求を受信したＥＣＵ（第２のＥＣＵ１３ｂなど）は、代替制御判断装置１に代替能力情報を送信し、代替制御判断装置１は代替能力情報を取得する（ステップＳ９２４）。
　次に、代替制御判断装置１は、不揮発性メモリ４から代替能力に適合した代替プログラムを取得する（ステップＳ９２５）。
　そして、代替制御判断装置１は、ＥＣＵ（ここでは第２のＥＣＵ１３ｂ）に取得した代替プログラムを配信する（ステップＳ９２６）。
　第２のＥＣＵ１３ｂは、配信された代替プログラムを格納して、その代替プログラムを直ちに実行する。
　図１４は、第３の実施の形態例に係る制御部８で行われる処理の一例を示すフローチャートである。
　まず、制御部８は、異常が通知されると、不揮発性メモリ４から緊急用代替プログラムを取得する（ステップＳ６０１）。そして、制御部８は、ステップＳ６０１で取得した緊急用代替プログラムを、別のＥＣＵ（第２のＥＣＵ１３ｂ）に配信する（ステップＳ６０２）。
　以後は、第１の実施の形態例で説明した図６のフローチャートのステップＳ１０１，Ｓ１０２，Ｓ１０３の処理が行われる。すなわち、制御部８は、代替能力データテーブル１２と、代替プログラムデータテーブル１１とを比較し、代替プログラムの機能レベルとその配信先を決定する（ステップＳ１０１）。そして、制御部８は、ステップＳ１０１で決定した代替プログラムを不揮発性メモリ４から取得する（ステップＳ１０２）。さらに、制御部８は、ステップＳ１０２で取得した代替プログラムを、ステップＳ１０１で決定した配信先に配信する（ステップＳ１０３）。
　第３の実施の形態例におけるその他の構成や処理は、第１の実施の形態例で説明したものと同じである。
　以上説明した第３の実施の形態例によれば、異常発生時に各ＥＣＵの代替能力を調査する前の段階で代替プログラムを配信できる。これにより、異常発生時に各ＥＣＵの代替能力情報を取得する前に、迅速な最低限度の機能移行が完了する。そして、代替能力情報取得と機能レベルの決定および代替プログラム配信先の決定の間に、車両が危険な状態に陥ることを防ぐことが可能になる。
＜変形例＞
　なお、本発明は、上述した各実施の形態例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施の形態例は、本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。
　また、図２、図２、図３のブロック図では、制御線や情報線は説明上必要と考えられるものだけを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
　代替制御判断装置１が行う機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ(Solid State Drive)等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
　また、上述した各実施の形態例では、図９や図１３に示すシーケンス図に示すように、異常発生（不具合発生）に伴って、別の演算部に代替能力要求を行うようにしたが、代替制御判断装置１では、不具合発生前から代替能力情報を取得してもよい。
　すなわち、代替制御判断装置１は、不具合発生とは無関係に随時（定期的または不定期に）、車載ネットワークで接続された各ＥＣＵのＣＰＵ（演算部）の代替能力情報を取得しておき、異常時に対処できるようにしてもよい。
　但し、上述した各実施の形態例で説明したように、異常発生（不具合発生）の通知を受信した際に、代替制御判断装置は代替制御を検討する処理を行うことで、不具合発生時のみに代替制御を検討すればよく、不具合が発生しない限りは、代替制御判断装置に余計な処理を実行させる必要がなく、車載ネットワークでの処理負担を軽減できる。
　また、上述した各実施の形態例では、演算部であるＣＰＵを内蔵したＥＣＵをネットワークで接続した車載ネットワークに適用したが、本発明は、ＣＰＵ以外の演算部を内蔵した装置にも適用が可能である。
　１…代替制御判断装置、２…プロセッサ、３…メモリ、４…不揮発性メモリ、５…Ｉ／Ｏデバイス、６…インターコネクト、８…制御部、９…通信部、１０…ネットワークリンク、１１…代替プログラムデータテーブル、１２…代替能力データテーブル、１３，１３ａ，１３ｂ…ＥＣＵ、１４…ゲートウェイ、１５…駆動装置、１６…認識装置、１７…車両システム、１８…通信装置、１９，２０…車両制御システム

Claims (11)

  1. 　車両に搭載された複数の演算部と接続される車載電子装置であって、
    　前記複数の演算部と通信を行う通信部と、
    　前記複数の演算部の一つである第一の演算部で異常が発生した場合に、第二の演算部へ代替制御の指示を出す制御部と、を備え、
    　前記制御部は、前記第一の演算部にて異常が発生した際に、前記第一の演算部の実行内容を前記第二の演算部で代替可能か示す代替能力情報を取得する
    　車載電子装置。
  2. 　前記制御部は取得した前記代替能力情報に基づき、前記第一の演算部の代替実行内容の機能レベルを決定する
    　請求項１に記載の車載電子装置。
  3. 　前記機能レベルは、前記車両の制御内容のレベルである
    　請求項２に記載の車載電子装置。
  4. 　前記制御部は、前記代替能力情報に応じて前記機能レベルを決定するデータテーブルを有する
    　請求項３に記載の車載電子装置。
  5. 　前記制御部は、前記代替能力情報に基づき、前記第一の演算部の実行部を代替可能な第二の演算部を特定し、
    　前記通信部を介して前記第二の演算部へ前記第一の演算部の実行プログラムを代替する代替プログラムを送信する
    　請求項４に記載の車載電子装置。
  6. 　前記制御部は、前記データテーブルのレベルに応じ、前記第二の演算部へ前記第一の演算部の代替プログラムを送信する
    　請求項５に記載の車載電子装置。
  7. 　前記代替プログラムは予め車載されたストレージに格納され、前記機能レベルの確定後に前記制御部が代替プログラムを前記ストレージより取得する
    　請求項５に記載の車載電子装置。
  8. 　前記制御部は、前記車両の動作モードに応じて、代替能力の演算を行う
    　請求項５に記載の車載電子装置。
  9. 　前記制御部は、前記車両の走行状況を踏まえ、最初に低い機能レベルに設定した状態で前記代替プログラムを取得して前記第二の演算部へ実行させ、その後、前記走行状況を踏まえたレベルの代替プログラムを再取得し前記第二の演算部へ実行させる
    　請求項６に記載の車載電子装置。
  10. 　前記制御部は、前記データテーブルに格納された、前記演算部ごとの代替能力、ＲＯＭ空き容量、ＲＡＭ空き容量の少なくとも１つに応じて代替できる機能レベルを決定する
    　請求項４に記載の車載電子装置。
  11. 　前記第一の演算部から不具合発生通知を受信した際に、前記制御部は前記代替制御を検討する
    　請求項１に記載の車載電子装置。
PCT/JP2022/018940 2022-04-26 2022-04-26 車載電子装置 WO2023209820A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/018940 WO2023209820A1 (ja) 2022-04-26 2022-04-26 車載電子装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/018940 WO2023209820A1 (ja) 2022-04-26 2022-04-26 車載電子装置

Publications (1)

Publication Number Publication Date
WO2023209820A1 true WO2023209820A1 (ja) 2023-11-02

Family

ID=88518309

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/018940 WO2023209820A1 (ja) 2022-04-26 2022-04-26 車載電子装置

Country Status (1)

Country Link
WO (1) WO2023209820A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002221075A (ja) * 2001-01-25 2002-08-09 Denso Corp 車両統合制御におけるフェイルセーフシステム
JP2004291943A (ja) * 2003-03-28 2004-10-21 Denso Corp 車両用制御装置
JP2021178560A (ja) * 2020-05-13 2021-11-18 日野自動車株式会社 自動運転制御装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002221075A (ja) * 2001-01-25 2002-08-09 Denso Corp 車両統合制御におけるフェイルセーフシステム
JP2004291943A (ja) * 2003-03-28 2004-10-21 Denso Corp 車両用制御装置
JP2021178560A (ja) * 2020-05-13 2021-11-18 日野自動車株式会社 自動運転制御装置

Similar Documents

Publication Publication Date Title
US10730518B2 (en) On-board recording system
KR102617639B1 (ko) 차량내 통신 시스템 및 방법, 및 디바이스
CN112004730B (zh) 车辆控制装置
JP4410661B2 (ja) 分散制御システム
US20190340116A1 (en) Shared backup unit and control system
CN110709932B (zh) 记录控制装置
CN110447015B (zh) 用于冗余执行运行功能的车载控制装置及相应的机动车
JP6620891B2 (ja) 中継装置、中継方法、およびコンピュータプログラム
JP7176488B2 (ja) データ保存装置、及びデータ保存プログラム
JP2010027062A (ja) 分散制御システム
US8150578B2 (en) Vehicle electronic system and vehicle
WO2023209820A1 (ja) 車載電子装置
JP7447905B2 (ja) モビリティ制御システム、方法、および、プログラム
US20220283798A1 (en) Mobility control system, method, and program
CN113631430B (zh) 车载计算机、计算机执行方法及计算机程序
US20220171613A1 (en) Electronic control unit, software update method, software update program product and electronic control system
US11659037B2 (en) Control communication system
KR20140066357A (ko) 다중 ｍｃｕ 환경에서의 펌웨어 업데이트 방법 및 이를 이용한 전자제어장치
JP5601306B2 (ja) 車両ネットワークの通信管理装置
JP2019172261A (ja) 制御装置、制御システム、及び制御プログラム
JP2020188407A (ja) 電子制御装置および移動体制御システム
CN114868372B (zh) 具有集中式存储的汽车网络
US20240078128A1 (en) Control device, control system, and control method
JP6556281B1 (ja) 制御システム
WO2023084567A1 (ja) 車両用制御装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22940100

Country of ref document: EP

Kind code of ref document: A1