WO2022259655A1 - 車両制御装置および車両制御システム - Google Patents

車両制御装置および車両制御システム Download PDF

Info

Publication number
WO2022259655A1
WO2022259655A1 PCT/JP2022/009299 JP2022009299W WO2022259655A1 WO 2022259655 A1 WO2022259655 A1 WO 2022259655A1 JP 2022009299 W JP2022009299 W JP 2022009299W WO 2022259655 A1 WO2022259655 A1 WO 2022259655A1
Authority
WO
WIPO (PCT)
Prior art keywords
safety
vehicle control
ecu
client
control device
Prior art date
Application number
PCT/JP2022/009299
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 DE112022001622.1T priority Critical patent/DE112022001622T8/de
Publication of WO2022259655A1 publication Critical patent/WO2022259655A1/ja

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/02—Ensuring safety in case of control system failures, e.g. by diagnosing, circumventing or fixing failures
    • B60W50/029—Adapting to failures or work around with other constraints, e.g. circumvention by avoiding use of failed parts
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/02—Ensuring safety in case of control system failures, e.g. by diagnosing, circumventing or fixing failures
    • B60W50/0205—Diagnosing or detecting failures; Failure detection models
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W2050/0001—Details of the control system
    • B60W2050/0002—Automatic control, details of type of controller or control system architecture
    • B60W2050/0004—In digital systems, e.g. discrete-time systems involving sampling
    • B60W2050/0006—Digital architecture hierarchy

Definitions

  • the present invention relates to a vehicle control device and a vehicle control system.
  • the vehicle server and zone gateway are configured using an ECU (electronic control unit). If one of the ECUs fails, another ECU may perform the function that the failed ECU had previously performed.
  • Patent Literature 1 describes an example of such technology.
  • Patent Document 1 the primary unit, secondary unit, and backup unit must all be equipped with the same hardware resources for fault mitigation, which maximizes resource requirements.
  • the present invention was made to solve such problems, and aims to provide a technology that can further reduce system costs in fault mitigation.
  • a vehicle control device includes: A vehicle control device comprising a master ECU and one or more client ECUs, When the master ECU detects a failure in any of the client ECUs, the master ECU generates a safety process list based on a predetermined failure operation pattern and transmits the safety process list to each of the client ECUs.
  • a vehicle control system includes a plurality of vehicle control devices described above. This specification includes the disclosure of Japanese Patent Application No. 2021-096584, which is the basis of priority of this application.
  • FIG. 1 shows examples of various modules arranged in an automatic driving support system including a vehicle control device according to a first embodiment of the present invention.
  • Example 1 can integrate smart infrastructure, connected services, and cloud-based autonomous driving applications into in-vehicle AD/ADAS programs to extend the vehicle's autonomous driving capabilities.
  • AD means, for example, Autonomous Driving
  • ADAS means, for example, Advanced Driver Assistance System
  • a program means, for example, an application program, but is not limited to this.
  • the vehicle implements or implements on-board E/E and network resources. can be derived.
  • the vehicle may have a knowledge base of dynamic motion driving design domains such as environmental conditions, environment recognition algorithms, optimal throughput requirements, and so on.
  • the vehicle control device can allocate required resources for safety and optimal throughput.
  • Application data rerouting and scheduling are also performed based on application requirements.
  • a vehicle control system includes multiple environmental awareness sensors, vehicle sensors, localization sensors, actuators (brake, steering, throttle, powertrain, etc.), etc., organized in a zone-based or domain-based E/E architecture.
  • a vehicle control system includes multiple modules that communicate with each other. It is beneficial to have multiple modules working together. Also, each module may include multiple programs that require sensor data, perception data, planning data, application state data, and the like. A module or program may have one or more resource requirements and priorities in critical driving scenarios and vehicle control system conditions. To make these tasks work together, it is beneficial to adapt the priority and deadline of each task/service according to the state of available resources.
  • vehicles that can communicate with smart infrastructure or roadside cloud-based remote servers can extend the autonomous driving capabilities of vehicles when they are traveling on smart highways that can assist vehicle control or take over entirely. .
  • the functional block according to the first embodiment can integrate the client application into the onboard AD/ADAS application for safe mode transitions.
  • a smart highway may offer a highway pilot line application that can provide hands-free super cruise and lane change functionality.
  • on-board hands-on/off ACC adaptive cruise control
  • LKA lane keeping assist
  • safety critical applications such as AEB (Automatic Emergency Braking) collision avoidance applications need to cooperate with client applications.
  • the vehicle control device can also schedule and reroute application data.
  • vehicle detection using radar, LiDAR, cameras, etc. each have different network bandwidth requirements.
  • the data size requirements of radar network bandwidth for deadlines can be much smaller than those of cameras.
  • the AD/ADAS application can be run in minimum resource requirement mode.
  • the vehicle control device can use the autonomous driving capability of smart infrastructure to reduce power consumption in the vehicle.
  • the vehicle control device is mounted on a vehicle having an automatic driving function, for example, but it is not limited to being mounted on a vehicle.
  • vehicle having an automatic driving function for example, but it is not limited to being mounted on a vehicle.
  • Other examples include buses, trucks, construction machines, ground robots, warehouse robots, airplanes, helicopters, boats, ships, farm machines, service robots, trains, golf carts, and the like.
  • FIG. 1 shows examples of various modules that can be arranged in an automatic driving support system including the vehicle control device according to the first embodiment.
  • This automatic driving support system includes a vehicle control device (including, for example, an in-vehicle computer system) and a computer outside the vehicle.
  • Self-driving vehicles can be set to an automatic mode (normal mode) and can automatically drive the vehicle along predetermined driving scenarios with or without assistance from a safe driver.
  • the vehicle controller includes an environment awareness sensor system 101, an environment awareness system 102 (which collects information about driving scenarios), a planning system 103, a wireless communication system 104, a physical network communication system 105, an action system 106, Body and Chassis Control System 107, Infotainment System 108, Human Machine Interface System 109, Driver Monitoring System 110, Vehicle Control System 111, V2X System 112, Driver Intention 113, Vehicle Diagnostics and Malfunctions It includes a monitoring system 114 and a powertrain system 115 .
  • Autonomous vehicles can run in either manual mode, fully automatic mode, or semi-automatic mode as normal operation modes.
  • the vehicle need not have all the modules in FIG. 1, and some modules may be omitted.
  • An autonomous vehicle may further include an engine, wheels, steering wheel, transmission, etc., and may be controlled by a vehicle control system.
  • An autonomous vehicle may further comprise a physical network (wired network) or a wireless network that allows each module to communicate with each other. The network may be redundant.
  • FIG. 2 shows an example of architecture possible in the vehicle control device according to the first embodiment.
  • the vehicle control device includes a sensor 201, a ZCU (zone control device) 202, and a DVCU 203, for example.
  • Sensor 201 is, for example, a smart sensor.
  • DVCU 203 functions, for example, as a vehicle server and zone gateway.
  • Each of ZCU 202 and DVCU 203 includes one or more ECUs (electronic control units).
  • DVCU 203 Only a single DVCU 203 is provided for low AD (automatic driving) grades (SAE standards L1 to L2). In the intermediate AD grades (SAE standards L2+ to L3), two DVCUs 203 are provided. In high AD grades (SAE standards L4-L5), three DVCUs 203 are provided. Also, the same DVCU 203 can be reused for multiple AD grades. That is, when updating the AD grade of the vehicle control device, the hardware of the DVCU 203 that has been used until then can be used continuously.
  • all DVCUs 203 can have the same software configuration. That is, a program executed by any DVCU 203 can be executed by any other DVCU 203 . However, one program does not need to be executed by multiple DVCUs 203 at the same time.
  • the output from each sensor can be processed by any DVCU 203, increasing the availability of the vehicle control device.
  • a single vehicle may be equipped with a plurality of vehicle control devices. These vehicle control devices may constitute one vehicle control system.
  • the vehicle control system includes a plurality of vehicle control devices according to the first embodiment.
  • each module shown in FIG. 1 may configure a vehicle control device, and all modules may be integrated to configure a vehicle control system. In this way, the fault mitigation unit can be designed more freely.
  • FIG. 3 shows an example of a failure operation mode (fail operational mode) according to the first embodiment.
  • the vehicle is driving on a highway in normal operating mode. If an error (eg an ECU failure) is detected while driving, driving continues in the fault mode of operation until the vehicle reaches a predetermined safe stop position.
  • an error eg an ECU failure
  • FIG. 3(b) if an error is detected during the execution of the automatic stop operation, driving continues in the fault operation mode until the vehicle reaches the predetermined safe stop position.
  • FIG. 4 shows an example of the configuration of the vehicle control device according to the first embodiment.
  • This configuration is an example of a hybrid zone architecture with multiple DVCUs.
  • the vehicle control device includes a first DVCU 401 , a second DVCU 402 and a third DVCU 403 .
  • Each DVCU comprises one or more ECUs.
  • the ECU has a hardware configuration as a known computer, and includes, for example, an arithmetic device and a memory device.
  • the arithmetic device includes, for example, a processor
  • the storage device includes, for example, a storage medium such as a semiconductor memory device. Some or all of the storage media may be non-transitory storage media.
  • One of the DVCUs has a master ECU, and the other DVCUs have client ECUs (one or more client ECUs in total).
  • the second DVCU 402 has a master ECU and stores a failure operation pattern 404 .
  • the first DVCU 401 has a client ECU and can store a safety processing list 405 .
  • the third DVCU 403 may have a client ECU and store a safety process list 406 .
  • the DVCU may be an integrated unit that functions as a vehicle server and zone gateway. That is, at least one of the master ECU and client ECU may be an integrated ECU that functions as a vehicle server and zone gateway. In this way, an integrated vehicle E/E architecture can be realized with one DVCU.
  • the vehicle control device may be configured to support multiple automated driving grades. For example, by reusing one or more ECUs, multiple autonomous driving grades can be supported as shown in FIG. By doing so, the versatility of the vehicle control device is enhanced.
  • At least one of the client ECUs may be a submaster ECU.
  • the sub-master ECU takes over the operation of the master ECU when the master ECU fails.
  • each DVCU may store a program (not shown). By the processor executing this program, the ECU may perform the functions described in this embodiment.
  • the vehicle control device also has another ECU 407 and is connected to the sensor 408 .
  • Sensor 408 is, for example, a smart sensor.
  • Sensor 408 also outputs, for example, environment perception data.
  • the vehicle control device is capable of advanced environment recognition processing.
  • the first DVCU 401, the second DVCU 402, the third DVCU 403 and the ECU 407 are communicably connected directly or via another DVCU.
  • each DVCU (including master ECU and client ECU) is configured by the same systems-on-a-chip microcomputer 409 .
  • the entire system can be constructed compactly, but it is also possible not to construct it on the same systems-on-a-chip microcomputer.
  • Each DVCU also executes a fault allocation program and/or a runtime fault mitigation program. Details of the on-failure allocation program are described below in connection with FIG. Details of the runtime fault mitigation program are described below in connection with FIG.
  • FIG. 5 shows another example of the configuration of the vehicle control device according to the first embodiment. This example is a pure zone architecture and the vehicle controller does not have the ECU 407 of FIG.
  • FIG. 6 shows an example of the operation of the vehicle control device according to the first embodiment.
  • a first DVCU 601, a second DVCU 602, a third DVCU 603, and an ADAS 604 are provided.
  • ADAS 604 also includes an ECU.
  • First DVCU 601, second DVCU 602, third DVCU 603, and ADAS 604 can communicate with each other.
  • Both the second DVCU 602 and the third DVCU 603 may be responsible for powertrain and chassis control.
  • the vehicle control device executes multiple safety processes (safety mechanisms).
  • Safety processing forms part of the AD/ADAS functionality, for example. Further, the safety processing is processing for making the vehicle run safely, and the safety processing is executed by executing a program by the ECU.
  • Safety processing SM1 is, for example, sensor data fusion processing (for example, processing for acquiring outputs from a plurality of sensors and performing comprehensive environmental recognition), and safety processing SM2 is, for example, trajectory processing (for example, controlling accelerator, brake, steering, etc.). process). Specific examples of safety processing are not limited to those described above.
  • FIGS. 6 (a) to (d) show different failure scenarios.
  • ADAS 604 normally performs both safety processes SM1 and SM2.
  • the safety processing SM1 is transferred to the second DVCU 602 and the safety processing SM2 is transferred to the third DVCU 603 by cooperation of the master ECU and the client ECU.
  • Specific operations of each ECU (including a transfer destination determination method) at this time will be described later with reference to FIGS. 8 and 11 and the like.
  • the second DVCU normally executes safety processing SM1
  • the third DVCU 603 executes safety processing SM2.
  • first DVCU 601 fails, no safety process relocation occurs because neither safety process SM1 nor SM2 is being executed in first DVCU 601 .
  • the second DVCU normally executes safety processing SM1
  • the third DVCU 603 executes safety processing SM2.
  • the safety process SM1 is transferred to the ADAS 604 through cooperation between the master ECU and the client ECU.
  • Security process SM2 is not transferred.
  • the second DVCU normally executes safety processing SM1
  • the third DVCU 603 executes safety processing SM2.
  • the safety process SM2 is transferred to the ADAS 604 through cooperation between the master ECU and the client ECU.
  • Security process SM1 is not transferred.
  • FIG. 7 shows another example of the operation of the vehicle control device according to the first embodiment.
  • This example is a pure zone architecture and the vehicle controller does not have the ADAS 604 of FIG.
  • a safety process SM3 is also executed.
  • Safety processing SM3 is, for example, ACC (adaptive cruise control) processing.
  • the second DVCU normally executes safety processing SM1
  • the third DVCU 603 executes safety processing SM2 and SM3.
  • the safety process SM1 is transferred to the first DVCU 601 through cooperation between the master ECU and the client ECU. Security processes SM2 and SM3 are not transferred.
  • the safety processing SM2 is transferred to the 1st DVCU 601 and the safety processing SM3 is transferred to the 2nd DVCU 602 through the cooperation of the master ECU and the client ECU.
  • each ECU can execute not only the safety processing normally executed by itself, but also the safety processing normally executed by other ECUs.
  • the versatility of each ECU will be enhanced, which is preferable.
  • Each safety process can be distributed and executed according to the situation, and one ECU does not need to execute all the safety processes at the same time.
  • FIG. 8 shows an example of a flowchart according to the first embodiment. This flow chart describes the operation of the on-failure allocation program. This flowchart is executed by the master ECU and the client ECU executing their corresponding failure allocation modules (failure allocation programs).
  • the master ECU can detect failures in any of the client ECUs.
  • the master ECU monitors the client ECUs, and when detecting a failure in any of the client ECUs, determines whether or not there is an unprocessed failure operation pattern (S1).
  • S1 unprocessed failure operation pattern
  • the master ECU If there is an unprocessed failure operation pattern (for example, immediately after a client ECU failure is detected), the master ECU generates a safety process list based on the failure operation pattern and transmits it to each client ECU (S2). .
  • FIG. 10 shows an example of a failure operation pattern according to the first embodiment.
  • FIG. 10(a) shows an operation pattern at the time of failure, and includes information for identifying the ECU that has failed, information for identifying the operation mode at the time of failure when the ECU has failed, and information for identifying the operation mode at the time of failure, and It is associated with information identifying another ECU to which safety processing is transferred.
  • Such failure behavior patterns can be defined in advance (eg, at the design stage).
  • the storage device of the master ECU stores this failure operation pattern.
  • safety processing SM1 is transferred to the client ECU of the first DVCU, and safety processing SM2 is transferred to the client ECU of the second DVCU.
  • the failure operation pattern is configured such that each safety process is executed by a client ECU having a memory capacity capable of executing the safety process. For example, in the design stage, if all the software that the client ECU executes in the normal operation mode and all the safety processes that may be executed at the same time are executed at the same time, the memory capacity of the client ECU is reduced. Failure operation patterns can be designed so that there is no shortage of
  • the failure operation pattern is configured so that the same safety processing is not executed by multiple client ECUs.
  • the safety processes assigned to the first DVCU and the second DVCU are different from each other.
  • the same safety process is not allocated to a plurality of client ECUs, i.e., if the same safety process is not stored in the storage devices (for example, main storage devices) of a plurality of client ECUs at the same time, hardware resources are consumed. It is suitable because it can be reduced.
  • FIG. 10(b) shows the execution start time limit, which represents the time limit (execution start time limit) until execution of each safety process is started in the transfer destination client ECU.
  • execution start deadline can be defined in advance (for example, at the design stage).
  • the storage device of the master ECU stores this execution start time limit.
  • the safety process list sent to each client ECU includes one or more safety processes to be started in each client ECU and an execution start time limit corresponding to each safety process. For example, in the example of FIG. 10, if the ECU in charge of the AD fails, the ECU of the first DVCU should start executing the safety process SM1, and the execution start time limit is A safe process list is sent stating that it is 100 ms. Similarly, a safety process list is sent to the ECU of the second DVCU indicating that the safety process SM2 should be started and that the execution start time limit is 100 ms.
  • the execution start deadline measurement start timing can be designed as appropriate. For example, it may be the time when the master ECU detected the failure, the time when the master ECU sent the safety process list, or other time.
  • the client ECU switches the operation mode from the normal operation mode to the failure operation mode (for example, the one described with reference to FIG. 3) in response to receiving the safety process list.
  • the master ECU may switch the operation mode from the normal operation mode to the failure operation mode when transmitting the safety process list.
  • the client ECU excludes safety processes that are already being executed from among the safety processes included in the safety process list (S3).
  • the “processed object” here means an object to be processed in S4 and S5, which will be described later. Such an exclusion prevents redundant execution of safety processing, and makes it possible to effectively use ECUs with low hardware resources.
  • the client ECU determines whether or not there is unexecuted safety processing (S4). If all safety processes included in the safety process list have already started execution, the process returns to S1.
  • the client ECU starts executing that safety process (S5). At this time, the client ECU starts executing each safety process by the corresponding execution start time limit. For each of the instructed safety processes, the client ECU, after starting execution of the safety process, transmits a notification indicating that the start of execution of the safety process has been completed (safety process execution start completion notification) to the master ECU. You may After that, the process returns to S1.
  • FIG. 9 shows an example of the operation of the vehicle control device according to the first embodiment realized by the processing shown in FIG. FIG. 9(a) shows the normal operation mode.
  • the vehicle control device has a first DVCU 901 , a second DVCU 902 , a third DVCU 903 , an ECU 907 and a sensor 908 .
  • the second DVCU 902 has a master ECU and stores a failure operation pattern 904 .
  • a first DVCU 901 and a third DVCU 903 comprise client ECUs.
  • FIG. 9(b) shows the failure operation mode.
  • the second DVCU 902 (strictly speaking, the master ECU) detects the failure of the ECU 907 and sends a safety processing list 905 to the first DVCU 901 and a safety processing list 906 to the third DVCU 903 .
  • the first DVCU 901 stores a safe process list 905 and the third DVCU 903 stores a safe process list 906 .
  • First DVCU 901 and third DVCU 903 execute safety processing according to safety processing lists 905 and 906, respectively.
  • the safety processing can be transferred according to the hardware resources of each ECU by appropriately designing the failure operation pattern. does not occur, it is possible to further improve the utilization efficiency of hardware resources in the ECU replacement operation when a failure occurs.
  • the processing in FIG. 8 may not be executed if the master ECU fails. If any of the client ECUs is a sub-master ECU, the sub-master ECU may be configured to execute the process of FIG. 8 instead of the master ECU. That is, the sub-master ECU may generate a safety process list and transmit it to each of the other client ECUs when it detects a failure in the master ECU. With such a configuration, failures in all ECUs including the master ECU can be dealt with.
  • FIG. 11 shows another example of the flowchart according to the first embodiment.
  • This flow chart describes the operation of the runtime fault mitigation program. This flow chart is executed by the master ECU and the client ECU executing their respective fault mitigation modules (failure mitigation programs).
  • the master ECU determines whether or not it has detected a failure in the client ECU (S11). If no failure is detected, S11 is repeated. When a failure is detected, a failure operation pattern is selected according to the client ECU that has failed (S12). For example, in the example of FIG. 10, when the ECU in charge of AD becomes faulty, the fault operation pattern corresponding to the fault operation mode "1" is selected.
  • the master ECU creates a safety process list according to the selected failure operation pattern and transmits it to each client ECU (S13). This process is performed, for example, in the same manner as S2 in FIG.
  • the master ECU switches the operation mode from the normal operation mode to the failure operation mode (S14).
  • the client ECU may switch the driving operation mode from the normal operation mode to the failure operation mode in response to receiving the safety processing list.
  • each client ECU starts executing safety processing by executing the processing of S3 to S5 in FIG. 8, and transmits a safety processing execution start completion notification to the master ECU.
  • the master ECU waits for and receives a safety process execution start completion notification from each client ECU (S15).
  • the master ECU determines whether or not a safety process execution start completion notification has been received by the corresponding execution start time limit for all safety processes (S16). For all safety processes, if the safety process execution start completion notification is received by the corresponding execution start deadline, the master ECU continues operation in the failure operation mode (S17), and ends the process of FIG. do.
  • the operation mode of the vehicle control device is changed to failure operation.
  • Mode is switched to failure safe mode (fail safe mode) (S18).
  • a person skilled in the art can appropriately design the specific operation contents of the failure safety mode based on known technology, etc., but for example, the driver may be requested to take over driving. In this way, even if the execution of the safety process is not properly started, a safe response can be taken.
  • FIG. 12 shows an example of a backup storage method according to the first embodiment.
  • the vehicle controller may include a storage device that stores a backup of all software (including each safety process) executed by the master ECU and client ECUs.
  • FIG. 12(a) shows the centralized method.
  • the vehicle control device has a storage device 1203 .
  • Storage device 1203 is accessible from all of master ECU 1201 and client ECU 1202 .
  • Storage device 1203 stores copies of binary files (files in executable format) for all software executed by master ECU 1201 and client ECU 1202 (including safety processes SM1 and SM2).
  • FIG. 12(b) shows the distribution method.
  • the vehicle control device distributes and stores copies of binary files of all software executed by master ECU 1201 and client ECU 1202 in respective storage devices (eg, main storage devices) of master ECU 1201 and client ECU 1202 .
  • the master ECU 1201 normally executes the safety process SM1, and can further execute the safety process SM2 in the failure operation mode.
  • Safety processing list 402 Second DVCU 403 3rd DVCU 404 Operation pattern at failure 405 Safety processing list 406
  • Safety processing list 407 ECU 408...Sensor 409...Systems-on-a-chip type microcomputer 601...First DVCU 602 Second DVCU 603 3rd DVCU 604 ADAS 901... 1st DVCU 902 Second DVCU 903... 3rd DVCU 904 Operation pattern at failure 905 Safety processing list 906 Safety processing list 907 ECU 908...Sensor SM1...Safety process SM2...Safety process SM3...Safety process 1201...Master ECU 1202... Client ECU 1203 ... Storage Devices All publications, patents and patent applications cited in this specification are hereby incorporated by reference in their entirety.

Landscapes

  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Human Computer Interaction (AREA)
  • Transportation (AREA)
  • Mechanical Engineering (AREA)
  • Control Of Driving Devices And Active Controlling Of Vehicle (AREA)
  • Traffic Control Systems (AREA)
  • Safety Devices In Control Systems (AREA)
  • Hardware Redundancy (AREA)

Abstract

障害緩和においてシステムコストをより低減できる車両制御装置および車両制御システムを提供することを目的とする。　車両制御装置は、マスターＥＣＵと、１つ以上のクライアントＥＣＵとを備える。前記マスターＥＣＵは、前記クライアントＥＣＵのいずれかの障害を検知した場合に、所定の障害時動作パターンに基づいて安全処理リストを生成して各前記クライアントＥＣＵに送信し、前記安全処理リストは、１つ以上の安全処理と、各安全処理に対応する実行開始期限とを含み、各前記クライアントＥＣＵは、前記安全処理リストを受信することに応じて、動作モードを通常モードから障害時動作モードに切り替えるとともに、各安全処理を、対応する実行開始期限までに実行開始し、前記障害時動作パターンは、各安全処理が、その安全処理を実行可能なメモリ容量を有するクライアントＥＣＵによって実行されるように構成され、前記障害時動作パターンは、同一の安全処理が複数のクライアントＥＣＵによっては実行されないように構成される。

Description

車両制御装置および車両制御システム
　本発明は車両制御装置および車両制御システムに関する。
　車内Ｅ／Ｅ（電気電子）システムにおいて、車両サーバおよびゾーンゲートウェイを用いたアーキテクチャが公知である。このアーキテクチャにより、エンジン、シャーシ、車体、快適性、先進運転支援システム（ＡＤＡＳ）、自動運転（ＡＤ）、等をカバーする広範なアプリケーションが実行される。
　車両サーバおよびゾーンゲートウェイは、ＥＣＵ（電子制御装置）を用いて構成される。ＥＣＵのいずれかが障害となった場合に、その障害ＥＣＵがそれまで実行していた機能を、別のＥＣＵが実行する場合がある。特許文献１には、このような技術の例が記載される。
米国特許第９５６３５２３号明細書
　しかしながら、従来の技術では、システムコストが高いという課題があった。
　たとえば特許文献１では、障害緩和のために主ユニット、副ユニットおよびバックアップユニットがすべて同一のハードウェア資源を備える必要があり、資源要求が最大となる。
　本発明はこのような課題を解決するためになされたものであり、障害緩和においてシステムコストをより低減できる技術を提供することを目的とする。
　本発明に係る車両制御装置は、
　マスターＥＣＵと、１つ以上のクライアントＥＣＵとを備える車両制御装置であって、
　前記マスターＥＣＵは、前記クライアントＥＣＵのいずれかの障害を検知した場合に、所定の障害時動作パターンに基づいて安全処理リストを生成して各前記クライアントＥＣＵに送信し、前記安全処理リストは、１つ以上の安全処理と、各安全処理に対応する実行開始期限とを含み、
　各前記クライアントＥＣＵは、前記安全処理リストを受信することに応じて、動作モードを通常モードから障害時動作モードに切り替えるとともに、各安全処理を、対応する実行開始期限までに実行開始し、
　前記障害時動作パターンは、各安全処理が、その安全処理を実行可能なメモリ容量を有するクライアントＥＣＵによって実行されるように構成され、
　前記障害時動作パターンは、同一の安全処理が複数のクライアントＥＣＵによっては実行されないように構成される。
　本発明に係る車両制御システムは、上述の車両制御装置を複数備える。
　本明細書は本願の優先権の基礎となる日本国特許出願番号2021-096584号の開示内容を包含する。
　本発明によれば、障害発生時のＥＣＵ代替動作においてハードウェア資源の利用効率をより高くすることができる。
本発明の実施例１に係る車両制御装置を含む自動運転支援システムに配置される様々なモジュールの例。 実施例１に係る車両制御装置において可能なアーキテクチャの例。 実施例１に係る障害時動作モードの例。 実施例１に係る車両制御装置の構成の例。 実施例１に係る車両制御装置の構成の例。 実施例１に係る車両制御装置の動作の例。 実施例１に係る車両制御装置の動作の例。 実施例１に係るフローチャートの例。 実施例１に係る車両制御装置の動作の例。 実施例１に係る障害時動作パターンの例。 実施例１に係るフローチャートの例。 実施例１に係るバックアップ記憶方式の例。
　以下、本発明の実施例を添付図面に基づいて説明する。以下は例示であり、本発明を限定するものではない。
［実施例１］
　図１は、本発明の実施例１に係る車両制御装置を含む自動運転支援システムに配置される様々なモジュールの例を示す。実施例１は、車両の自律運転機能を拡張するための、スマートインフラストラクチャ、コネクテッドサービス、クラウドベース自律運転アプリケーションを、車載型ＡＤ／ＡＤＡＳプログラムに統合することができる。
　ＡＤとはたとえば自動運転（Autonomous Driving）を意味し、ＡＤＡＳとはたとえば先進運転支援システム（Advanced Driver Assistance System）を意味する。本明細書において、プログラムとは、たとえばアプリケーションプログラムを意味するがこれに限らない。
　車載の電気電子（Ｅ／Ｅ）資源の最適な利用のために、および、安全な統合および車載型ＡＤ／ＡＤＡＳ拡張モード遷移のために、車両は車内のＥ／Ｅ資源およびネットワーク資源を実行または導出することができる。
　同様に、車両は、環境条件、環境認識アルゴリズム、最適スループット要件、等の動的動作運転設計ドメインの知識ベースを有してもよい。
　スマートインフラストラクチャ、コネクテッドサービス、クラウドベース自律運転アプリケーションの資源要件および資源可用性に基づき、実施例１に係る車両制御装置は、要求される資源を安全および最適スループットのために割り当てることができる。
　また、アプリケーション要件に基づき、アプリケーションデータのリルーティングおよびスケジューリングも実行される。
　自動運転車両は、車両制御システム（たとえばＡＤ／ＡＤＡＳシステム）を用いて制御される。車両制御システムは、ゾーンベースまたはドメインベースのＥ／Ｅアーキテクチャにおいて構成される、複数の環境認識センサ、車両センサ、ローカリゼーションセンサ、アクチュエータ（ブレーキ、ステアリング、スロットル、パワートレイン等）、等を含む。
　車両制御システムは、互いに通信する複数のモジュールを含む。複数のモジュールを協働させることが有益である。また、各モジュールは、センサデータ、認識データ、計画データ、アプリケーション状態データ、等を要求する複数のプログラムを含む場合がある。モジュールまたはプログラムは、１つ以上の資源要件と、クリティカルな運転シナリオおよび車両制御システム状態における優先度とを有する場合がある。これらのタスクを協働させるには、利用可能な資源の状態に応じて、各タスク／サービスの優先度およびデッドラインを適応させることが有益である。
　たとえば、スマートインフラストラクチャまたは路側機クラウドベースリモートサーバと通信可能な車両が、車両制御を支援または完全にテイクオーバできるスマートハイウェイを走行している場合には、車両の自動運転機能を拡張することができる。
　クライアントアプリケーションの資源要件によっては、実施例１に係る機能ブロックは、安全なモード遷移のために、クライアントアプリケーションを車載型ＡＤ／ＡＤＡＳアプリケーションに統合することができる。
　たとえば、スマートハイウェイが、ハンズフリースーパークルーズおよび車線変更機能を提供可能なハイウェイパイロットラインアプリケーションを提供する場合がある。そのようなシナリオでは、車載側のハンズオン／オフＡＣＣ（適応的クルーズ制御）（半自律運転車両）およびＬＫＡ（車線維持支援）は終了可能である。しかしながら、ＡＥＢ（自動緊急ブレーキ）衝突回避アプリケーション等の安全クリティカルなアプリケーションは、クライアントアプリケーションと協働する必要がある。
　このクライアントアプリケーションと、車載型ＡＤ／ＡＤＡＳ安全アプリケーションとの組み合わせでは、リアルタイム／ソフトタイムの遅延制約が厳しくなる場合がある。そのようなシナリオでは、実施例１に係る車両制御装置は、アプリケーションデータのスケジューリングおよびリルーティングも行うことができる。
　別の例として、レーダー、ＬｉＤＡＲ、カメラ、等を用いる車両検出は、それぞれ異なるネットワーク帯域幅要件を有する。デッドラインに対してレーダーのネットワーク帯域幅が要求するデータサイズは、カメラの場合に比較してはるかに小さい場合がある。車載型ＡＤ／ＡＤＡＳアプリケーションにスマートインフラストラクチャのクライアントアプリケーションを追加する場合には、ＡＤ／ＡＤＡＳアプリケーションを最小資源要件モードで実行することができる。
　同様に、自動停車および最適な電力利用も可能である。フェールオペレーショナルな車両制御システムを装備した高度な自動運転車両では、実施例１に係る車両制御装置は、スマートインフラストラクチャの自律運転能力を利用して、車内の電力消費を抑制することができる。
　実施例１に係る車両制御装置は、たとえば自動運転機能を有する自動車に搭載されるが、自動車に搭載されるものに限らない。他の例として、バス、トラック、建設機械、地上型ロボット、倉庫ロボット、飛行機、ヘリコプター、ボート、船舶、農場機械、サービスロボット、列車、ゴルフカート、等にも搭載可能である。
　図１は、実施例１に係る車両制御装置を含む自動運転支援システムに配置され得る様々なモジュールの例を示す。この自動運転支援システムは、車両制御装置（たとえば車載型コンピュータシステムを含む）と、車外のコンピュータとを含んで構成される。自動運転車両は、自動モード（通常モード）に設定することができ、安全ドライバーからの支援を得て、または支援なしで、所定の運転シナリオに沿って自動的に車両を運転することができる。
　車両制御装置は、環境認識センサシステム１０１と、環境認識システム１０２（運転シナリオに関する情報を収集する）と、計画システム１０３と、無線通信システム１０４と、物理ネットワーク通信システム１０５と、作用システム１０６と、車体・シャーシ制御システム１０７と、インフォテインメントシステム１０８と、ヒューマンマシンインタフェースシステム１０９と、ドライバー監視システム１１０と、車両制御システム１１１と、Ｖ２Ｘシステム１１２と、ドライバーインテンション１１３と、車両診断および機能不全監視システム１１４と、パワートレインシステム１１５とを含む。
　自動運転車両は、通常動作モードとして、手動モード、全自動モード、半自動モードのいずれかで走行可能である。車両は、図１のモジュールをすべて備える必要はなく、一部のモジュールが省略されていてもよい。
　自動運転車両は、さらに、エンジン、車輪、ハンドル（ステアリングホイール）、トランスミッション、等を備えてもよく、車両制御システムがこれらを制御してもよい。自動運転車両は、さらに、各モジュールが互いに通信することを可能にする物理ネットワーク（有線ネットワーク）または無線ネットワークを備えてもよい。ネットワークは冗長であってもよい。
　図２は、実施例１に係る車両制御装置において可能なアーキテクチャの例を示す。車両制御装置は、たとえばセンサ２０１と、ＺＣＵ（ゾーン制御装置）２０２と、ＤＶＣＵ２０３とを備える。センサ２０１はたとえばスマートセンサである。ＤＶＣＵ２０３は、たとえば車両サーバおよびゾーンゲートウェイとして機能する。ＺＣＵ２０２およびＤＶＣＵ２０３は、いずれも１つ以上のＥＣＵ（電子制御装置）を備える。
　低ＡＤ（自動運転）グレード（ＳＡＥ規格Ｌ１～Ｌ２）では、単一のＤＶＣＵ２０３のみが設けられる。中間ＡＤグレード（ＳＡＥ規格Ｌ２＋～Ｌ３）では、２つのＤＶＣＵ２０３が設けられる。高ＡＤグレード（ＳＡＥ規格Ｌ４～Ｌ５）では、３つのＤＶＣＵ２０３が設けられる。また、複数のＡＤグレードについて、同一のＤＶＣＵ２０３を再利用することができる。すなわち、車両制御装置のＡＤグレードを更新する際に、それまで使用していたＤＶＣＵ２０３のハードウェアを継続して使用することができる。
　実施例１では、すべてのＤＶＣＵ２０３のソフトウェア構成を同一とすることができる。すなわち、いずれかのＤＶＣＵ２０３が実行するプログラムは、他のＤＶＣＵ２０３いずれによっても実行することができる。ただし、１つのプログラムが同時に複数のＤＶＣＵ２０３で実行される必要はない。
　このような構成によれば、各センサからの出力がいずれのＤＶＣＵ２０３によっても処理可能となり、車両制御装置の可用性が高まる。
　１台の車両に、複数の車両制御装置が搭載されてもよい。これらの車両制御装置は、１つの車両制御システムを構成してもよい。その場合には、車両制御システムは、実施例１に係る車両制御装置を複数備える。たとえば、図１に示すモジュールがそれぞれ車両制御装置を構成し、すべてのモジュールが統合されて車両制御システムを構成してもよい。このようにすると、障害緩和の単位をより自由に設計することができる。
　図３は、実施例１に係る障害時動作モード（フェールオペレーショナルモード）の例を示す。図３（ａ）のシナリオでは、車両が通常動作モードで高速道路を走行している。走行中にエラー（たとえばＥＣＵの障害）が検出された場合に、車両が所定の安全停車位置に到着するまで、障害時動作モードにおいて運転が継続される。図３（ｂ）のシナリオでは、自動停車動作の実行中にエラーが検出された場合に、車両が所定の安全停車位置に到着するまで、障害時動作モードにおいて運転が継続される。
　通常動作モードおよび障害時動作モードにおける車両制御装置（とくに各ＥＣＵ）の具体的な動作は、当業者公知技術等に基づいて適宜設計可能である。
　これらの障害時動作モードにおいて、ＥＣＵの可用性が低いと、高レベルの自動運転が継続できなくなる可能性がある。このため、ＥＣＵの可用性を高め、障害緩和ができるようにすると好適である。
　図４は、実施例１に係る車両制御装置の構成の一例を示す。この構成は、複数のＤＶＣＵを備えるハイブリッドゾーンアーキテクチャの例である。車両制御装置は、第１ＤＶＣＵ４０１と、第２ＤＶＣＵ４０２と、第３ＤＶＣＵ４０３とを備える。各ＤＶＣＵは１つ以上のＥＣＵを備える。
　ＥＣＵは公知のコンピュータとしてのハードウェア構成を有し、たとえば演算装置および記憶装置を備える。演算装置はたとえばプロセッサを含み、記憶装置はたとえば半導体メモリ装置等の記憶媒体を含む。記憶媒体の一部または全部が、過渡的でない(non-transitory)記憶媒体であってもよい。
　ＤＶＣＵのうち１つはマスターＥＣＵを備え、他のＤＶＣＵはクライアントＥＣＵを備える（クライアントＥＣＵは合計で１つ以上である）。図４の例では、第２ＤＶＣＵ４０２がマスターＥＣＵを備え、障害時動作パターン４０４を記憶する。第１ＤＶＣＵ４０１はクライアントＥＣＵを備え、安全処理リスト４０５を記憶することができる。同様に、第３ＤＶＣＵ４０３はクライアントＥＣＵを備え、安全処理リスト４０６を記憶することができる。
　ＤＶＣＵは、車両サーバおよびゾーンゲートウェイとして機能する統合ユニットであってもよい。すなわち、マスターＥＣＵおよびクライアントＥＣＵの少なくとも１つは、車両サーバおよびゾーンゲートウェイとして機能する統合ＥＣＵであってもよい。このようにすると、１つのＤＶＣＵで統合された車両Ｅ／Ｅアーキテクチャを実現することができる。
　また、車両制御装置は、複数の自動運転グレードに対応するよう構成されてもよい。たとえば、１つ以上のＥＣＵを再利用することにより、図２のように複数の自動運転グレードに対応することができる。このようにすると、車両制御装置の汎用性が高まる。
　クライアントＥＣＵのうち少なくとも１つ（この例では第１ＤＶＣＵ４０１のＥＣＵ）は、サブマスターＥＣＵであってもよい。サブマスターＥＣＵは、マスターＥＣＵが障害となった場合に、マスターＥＣＵの動作を代替する。
　各ＤＶＣＵの記憶装置は、図示しないプログラムを記憶してもよい。プロセッサがこのプログラムを実行することにより、ＥＣＵは本実施形態において説明される機能を実行してもよい。
　また、車両制御装置は、別のＥＣＵ４０７を備え、センサ４０８に接続される。センサ４０８はたとえばスマートセンサである。また、センサ４０８は、たとえば環境認知データを出力する。このような構成によれば、車両制御装置は高度な環境認知処理が可能である。
　第１ＤＶＣＵ４０１、第２ＤＶＣＵ４０２、第３ＤＶＣＵ４０３およびＥＣＵ４０７は、直接的に、または他のＤＶＣＵを介して、通信可能に接続される。
　図４の例では、各ＤＶＣＵ（マスターＥＣＵおよびクライアントＥＣＵを含む）は、すべて同一のシステムズ・オン・ア・チップ式マイクロコンピュータ４０９によって構成される。このようにするとシステム全体をコンパクトに構成することができるが、同一のシステムズ・オン・ア・チップ式マイクロコンピュータに構成しないことも可能である。
　また、各ＤＶＣＵは、障害時アロケーションプログラムおよび／またはランタイム障害緩和プログラムを実行する。障害時アロケーションプログラムの詳細は図８に関連して後述する。ランタイム障害緩和プログラムの詳細は図１１に関連して後述する。
　図５は、実施例１に係る車両制御装置の構成の別の一例を示す。この例は純粋なゾーンアーキテクチャであり、車両制御装置は図４のＥＣＵ４０７を備えない。
　図６は、実施例１に係る車両制御装置の動作の一例を示す。第１ＤＶＣＵ６０１、第２ＤＶＣＵ６０２、第３ＤＶＣＵ６０３、およびＡＤＡＳ６０４が設けられる。ＡＤＡＳ６０４もまたＥＣＵを備える。第１ＤＶＣＵ６０１、第２ＤＶＣＵ６０２、第３ＤＶＣＵ６０３、およびＡＤＡＳ６０４は、互いに通信可能である。第２ＤＶＣＵ６０２および第３ＤＶＣＵ６０３は、いずれも、パワートレインおよびシャーシ制御を担当してもよい。
　車両制御装置は、複数の安全処理（セーフティメカニズム）を実行する。安全処理は、たとえばＡＤ／ＡＤＡＳ機能の一部を構成する。また、安全処理は車両を安全に走行させるための処理であり、ＥＣＵがプログラムを実行することによって安全処理が実行される。
　図６の例では、安全処理ＳＭ１およびＳＭ２が実行される。安全処理ＳＭ１はたとえばセンサデータ融合処理（たとえば複数のセンサからの出力を取得して総合的な環境認知を行う処理）であり、安全処理ＳＭ２はたとえば軌跡処理（たとえばアクセル、ブレーキ、操舵等を制御する処理）である。安全処理の具体例は上述のものに限らない。
　図６（ａ）～（ｄ）は、それぞれ異なる障害シナリオを示す。図６（ａ）のシナリオでは、通常時にはＡＤＡＳ６０４が安全処理ＳＭ１およびＳＭ２の双方を実行する。ＡＤＡＳ６０４に障害が発生した場合には、マスターＥＣＵおよびクライアントＥＣＵの協働により、安全処理ＳＭ１は第２ＤＶＣＵ６０２に移転し、安全処理ＳＭ２は第３ＤＶＣＵ６０３に移転する。この際の具体的な各ＥＣＵの動作（移転先の決定方法を含む）は、図８および図１１等に関連して後述する。
　図６（ｂ）のシナリオでは、通常時には第２ＤＶＣＵが安全処理ＳＭ１を実行し、第３ＤＶＣＵ６０３が安全処理ＳＭ２を実行する。第１ＤＶＣＵ６０１に障害が発生した場合、第１ＤＶＣＵ６０１では安全処理ＳＭ１およびＳＭ２のいずれも実行されていないので、安全処理の移転は発生しない。
　図６（ｃ）のシナリオでは、通常時には第２ＤＶＣＵが安全処理ＳＭ１を実行し、第３ＤＶＣＵ６０３が安全処理ＳＭ２を実行する。第２ＤＶＣＵ６０２に障害が発生した場合には、マスターＥＣＵおよびクライアントＥＣＵの協働により、安全処理ＳＭ１はＡＤＡＳ６０４に移転する。安全処理ＳＭ２は移転しない。
　図６（ｄ）のシナリオでは、通常時には第２ＤＶＣＵが安全処理ＳＭ１を実行し、第３ＤＶＣＵ６０３が安全処理ＳＭ２を実行する。第３ＤＶＣＵ６０３に障害が発生した場合には、マスターＥＣＵおよびクライアントＥＣＵの協働により、安全処理ＳＭ２はＡＤＡＳ６０４に移転する。安全処理ＳＭ１は移転しない。
　図７は、実施例１に係る車両制御装置の動作の別の一例を示す。この例は純粋なゾーンアーキテクチャであり、車両制御装置は図６のＡＤＡＳ６０４を備えない。図７の例では、さらに安全処理ＳＭ３が実行される。安全処理ＳＭ３はたとえばＡＣＣ（適応的クルーズ制御）処理である。
　図７（ａ）～（ｃ）のシナリオにおいて、通常時には第２ＤＶＣＵが安全処理ＳＭ１を実行し、第３ＤＶＣＵ６０３が安全処理ＳＭ２およびＳＭ３を実行する。
　図７（ａ）のシナリオにおいて、第１ＤＶＣＵ６０１に障害が発生した場合、第１ＤＶＣＵ６０１では安全処理ＳＭ１～ＳＭ３のいずれも実行されていないので、安全処理の移転は発生しない。
　図７（ｂ）のシナリオにおいて、第２ＤＶＣＵ６０２に障害が発生した場合には、マスターＥＣＵおよびクライアントＥＣＵの協働により、安全処理ＳＭ１は第１ＤＶＣＵ６０１に移転する。安全処理ＳＭ２およびＳＭ３は移転しない。
　図７（ｃ）のシナリオにおいて、第３ＤＶＣＵ６０３に障害が発生した場合には、マスターＥＣＵおよびクライアントＥＣＵの協働により、安全処理ＳＭ２は第１ＤＶＣＵ６０１に移転し、安全処理ＳＭ３は第２ＤＶＣＵ６０２に移転する。
　図６および図７に示すように、各ＥＣＵは、自身が通常実行する安全処理に限らず、他のＥＣＵが通常実行する安全処理も、実行可能である。とくに、マスターＥＣＵおよびクライアントＥＣＵのいずれもが、すべての安全処理を実行可能であるように構成すると、各ＥＣＵの汎用性が高まり好適である。なお、各安全処理は、状況に応じて分散実行することができ、１つのＥＣＵがすべての安全処理を同時に実行する必要はない。
　図８は、実施例１に係るフローチャートの一例を示す。このフローチャートは、障害時アロケーションプログラムの動作を説明する。このフローチャートは、マスターＥＣＵおよびクライアントＥＣＵが、それぞれ対応する障害時アロケーションモジュール（障害時アロケーションプログラム）を実行することにより実行される。
　マスターＥＣＵは、クライアントＥＣＵのいずれかの障害を検知することができる。マスターＥＣＵは、クライアントＥＣＵを監視し、クライアントＥＣＵのいずれかの障害を検知した場合に、未処理の障害時動作パターンがあるか否かを判定する（Ｓ１）。所定の障害時動作パターンの例は、図１０等を用いて後述する。
　未処理の障害時動作パターンがなければ（すなわち、障害時動作パターンがないか、または検知された障害時動作パターンがすべて図８のフローチャートに従って処理済みであれば）、図８の処理は終了される。
　未処理の障害時動作パターンがあれば（たとえばクライアントＥＣＵの障害が検知された直後）、マスターＥＣＵは、障害時動作パターンに基づいて安全処理リストを生成し、各クライアントＥＣＵに送信する（Ｓ２）。
　図１０に、実施例１に係る障害時動作パターンの例を示す。図１０（ａ）は障害時動作パターンを示し、障害となったＥＣＵを識別する情報と、当該ＥＣＵが障害となった場合の障害時動作モードを識別する情報と、当該ＥＣＵで実行されていた安全処理の移転先となる別のＥＣＵを識別する情報とを関連付ける。このような障害時動作パターンは、事前に（たとえば設計段階において）定義することができる。マスターＥＣＵの記憶装置は、この障害時動作パターンを記憶する。
　たとえば、ＡＤを担当するクライアントＥＣＵが障害となった場合には、安全処理ＳＭ１は第１ＤＶＣＵのクライアントＥＣＵに移転し、安全処理ＳＭ２は第２ＤＶＣＵのクライアントＥＣＵに移転する。
　障害時動作パターンは、各安全処理が、その安全処理を実行可能なメモリ容量を有するクライアントＥＣＵによって実行されるように構成される。たとえば、設計段階において、各クライアントＥＣＵについて、そのクライアントＥＣＵが通常動作モードにおいて実行するすべてのソフトウェアに加え、同時に実行する可能性のある安全処理をすべて同時に実行した場合に、そのクライアントＥＣＵのメモリ容量が不足しないように、障害時動作パターンを設計することができる。
　また、障害時動作パターンは、同一の安全処理が複数のクライアントＥＣＵによっては実行されないように構成される。たとえば図１０の例では、第１ＤＶＣＵおよび第２ＤＶＣＵに割り当てられる安全処理は互いに異なっている。とくに、同一の安全処理が複数のクライアントＥＣＵにアロケーションされないように、すなわち、同一の安全処理が複数のクライアントＥＣＵの記憶装置（たとえば主記憶装置）に同時には記憶されないようにすると、ハードウェア資源が低減でき好適である。
　図１０（ｂ）は実行開始期限を示し、各安全処理が移転先のクライアントＥＣＵにおいて実行開始されるまでの期限（実行開始期限）を表す。このような実行開始期限は、事前に（たとえば設計段階において）定義することができる。マスターＥＣＵの記憶装置は、この実行開始期限を記憶する。
　各クライアントＥＣＵに送信される安全処理リストは、各クライアントＥＣＵにおいて実行開始すべき１つ以上の安全処理と、各安全処理に対応する実行開始期限とを含む。たとえば、図１０の例において、ＡＤを担当するＥＣＵが障害となった場合には、第１ＤＶＣＵのＥＣＵに対して、安全処理ＳＭ１の実行を開始すべきであるということと、その実行開始期限は１００ｍｓであるということとを示す安全処理リストが送信される。同様に、第２ＤＶＣＵのＥＣＵに対して、安全処理ＳＭ２の実行を開始すべきであるということと、その実行開始期限は１００ｍｓであるということとを示す安全処理リストが送信される。
　実行開始期限の計測開始タイミングは適宜設計可能である。たとえば、マスターＥＣＵが障害を検知した時刻としてもよいし、マスターＥＣＵが安全処理リストを送信した時刻としてもよいし、他の時刻としてもよい。
　クライアントＥＣＵは、安全処理リストを受信することに応じて、動作モードを通常動作モードから障害時動作モード（たとえば図３に関連して説明したもの）に切り替える。なお、マスターＥＣＵも同様に、安全処理リストの送信に際して、動作モードを通常動作モードから障害時動作モードに切り替えてもよい。
　そして、クライアントＥＣＵは、安全処理リストに含まれる安全処理のうち、すでに実行中であるものを処理対象から除外する（Ｓ３）。「処理対象」とは、ここでは後述のＳ４およびＳ５の処理の対象となるものを意味する。このような除外により、安全処理の重複実行が防止され、低ハードウェア資源のＥＣＵを有効に利用することができる。
　次に、クライアントＥＣＵは、未実行の安全処理があるか否かを判定する（Ｓ４）。安全処理リストに含まれる安全処理がすべて実行開始済みであれば、処理はＳ１に戻る。
　未実行の安全処理があれば、クライアントＥＣＵはその安全処理の実行を開始する（Ｓ５）。この際、クライアントＥＣＵは、各安全処理を、対応する実行開始期限までに実行開始する。クライアントＥＣＵは、指示された安全処理のそれぞれについて、その安全処理の実行を開始した後に、その安全処理の実行開始が完了したことを示す通知（安全処理実行開始完了通知）を、マスターＥＣＵに送信してもよい。その後、処理はＳ１に戻る。
　図９は、図８のような処理によって実現される、実施例１に係る車両制御装置の動作の一例を示す。図９（ａ）は通常動作モードを示す。車両制御装置は第１ＤＶＣＵ９０１、第２ＤＶＣＵ９０２、第３ＤＶＣＵ９０３、ＥＣＵ９０７、センサ９０８を備える。第２ＤＶＣＵ９０２はマスターＥＣＵを備え、障害時動作パターン９０４を記憶する。第１ＤＶＣＵ９０１および第３ＤＶＣＵ９０３はクライアントＥＣＵを備える。
　この例では、ＥＣＵ９０７が障害となったとする。図９（ｂ）は障害時動作モードを示す。第２ＤＶＣＵ９０２（厳密にはマスターＥＣＵ）は、ＥＣＵ９０７の障害を検知し、安全処理リスト９０５を第１ＤＶＣＵ９０１に送信し、安全処理リスト９０６を第３ＤＶＣＵ９０３に送信する。第１ＤＶＣＵ９０１は安全処理リスト９０５を記憶し、第３ＤＶＣＵ９０３は安全処理リスト９０６を記憶する。第１ＤＶＣＵ９０１および第３ＤＶＣＵ９０３は、それぞれ安全処理リスト９０５および９０６に従って安全処理を実行する。
　このように、実施例１に係る車両制御装置によれば、障害時動作パターンを適切に設計することにより、安全処理を各ＥＣＵのハードウェア資源に応じて移転させることができ、また、安全処理の重複が発生しないので、障害発生時のＥＣＵ代替動作においてハードウェア資源の利用効率をより高くすることができる。
　なお、図８の処理は、マスターＥＣＵが障害となった場合には実行できない可能性がある。クライアントＥＣＵのいずれかがサブマスターＥＣＵである場合には、サブマスターＥＣＵがマスターＥＣＵに代わって図８の処理を実行するように構成してもよい。すなわち、サブマスターＥＣＵは、マスターＥＣＵの障害を検知した場合に、安全処理リストを生成して他の各クライアントＥＣＵに送信してもよい。このような構成によれば、マスターＥＣＵを含むすべてのＥＣＵの障害に対応することができる。
　図１１は、実施例１に係るフローチャートの別の一例を示す。このフローチャートは、ランタイム障害緩和プログラムの動作を説明する。このフローチャートは、マスターＥＣＵおよびクライアントＥＣＵが、それぞれ対応する障害緩和モジュール（障害緩和プログラム）を実行することにより実行される。
　マスターＥＣＵは、クライアントＥＣＵの障害を検知したか否かを判定する（Ｓ１１）。障害を検知していない場合、Ｓ１１を繰り返す。障害を検知した場合に、障害となったクライアントＥＣＵに応じて障害時動作パターンを選択する（Ｓ１２）。たとえば図１０の例において、ＡＤを担当するＥＣＵが障害となった場合には、障害時動作モード「１」に対応する障害時動作パターンが選択される。
　次に、マスターＥＣＵは、選択した障害時動作パターンに従って安全処理リストを作成し、各クライアントＥＣＵに送信する（Ｓ１３）。この処理は、たとえば図８のＳ２と同様に行われる。次に、マスターＥＣＵは、動作モードを通常動作モードから障害時動作モードに切り替える（Ｓ１４）。なお、クライアントＥＣＵも同様に、安全処理リストを受信することに応じて、運転動作モードを通常動作モードから障害時動作モードに切り替えてもよい。
　図１１には示さないが、各クライアントＥＣＵは、図８のＳ３～Ｓ５の処理を実行することにより、安全処理の実行を開始し、安全処理実行開始完了通知をマスターＥＣＵに送信する。マスターＥＣＵは、各クライアントＥＣＵからの安全処理実行開始完了通知を待機し、これを受信する（Ｓ１５）。
　マスターＥＣＵは、すべての安全処理について、対応する実行開始期限までに、安全処理実行開始完了通知を受信したか否かを判定する（Ｓ１６）。すべての安全処理について、対応する実行開始期限までに、安全処理実行開始完了通知を受信した場合には、マスターＥＣＵは、障害時動作モードで動作を継続し（Ｓ１７）、図１１の処理を終了する。
　そうでない場合（すなわち、いずれかの安全処理について、対応する実行開始期限までに安全処理実行開始完了通知を受信しなかった場合。これは、いずれかの安全処理について、安全処理実行開始完了通知を受信しなかった場合、および、いずれかの安全処理について、安全処理実行開始完了通知の受信が、対応する実行開始期限を過ぎた場合を含む）には、車両制御装置の動作モードを障害時動作モードから障害時安全モード（フェールセーフモード）に切り替える（Ｓ１８）。
　障害時安全モードの具体的な動作内容は、当業者が公知技術等に基づいて適宜設計可能であるが、たとえば、搭乗者に対する運転のテイクオーバ要請を行ってもよい。このようにすると、安全処理の実行開始が適切に行われなかった場合でも安全な対応をとることができる。
　図１２は、実施例１に係るバックアップ記憶方式の例を示す。車両制御装置は、マスターＥＣＵおよびクライアントＥＣＵによって実行されるすべてのソフトウェア（各安全処理を含む）のバックアップを記憶する記憶装置を備えてもよい。
　図１２（ａ）は集中方式を示す。車両制御装置は、記憶装置１２０３を備える。記憶装置１２０３は、マスターＥＣＵ１２０１およびクライアントＥＣＵ１２０２のすべてからアクセス可能である。記憶装置１２０３は、マスターＥＣＵ１２０１およびクライアントＥＣＵ１２０２によって実行されるすべてのソフトウェア（安全処理ＳＭ１およびＳＭ２を含む）について、バイナリファイル（実行可能形式のファイル）のコピーを記憶する。
　図１２（ｂ）は分散方式を示す。車両制御装置は、マスターＥＣＵ１２０１およびクライアントＥＣＵ１２０２によって実行されるすべてのソフトウェアについて、バイナリファイルのコピーを、マスターＥＣＵ１２０１およびクライアントＥＣＵ１２０２のそれぞれの記憶装置（たとえば主記憶装置）に分散させて記憶する。この例では、通常時にはマスターＥＣＵ１２０１は安全処理ＳＭ１を実行しており、障害時動作モードにおいてさらに安全処理ＳＭ２を実行することができる。
　１０１…環境認識センサシステム
　１０２…環境認識システム
　１０３…計画システム
　１０４…無線通信システム
　１０５…物理ネットワーク通信システム
　１０６…作用システム
　１０７…車体・シャーシ制御システム
　１０８…インフォテインメントシステム
　１０９…ヒューマンマシンインタフェースシステム
　１１０…ドライバー監視システム
　１１１…車両制御システム
　１１２…Ｖ２Ｘシステム
　１１３…ドライバーインテンション
　１１４…機能不全監視システム
　１１５…パワートレインシステム
　２０１…センサ
　２０２…ＺＣＵ
　２０３…ＤＶＣＵ
　４０１…第１ＤＶＣＵ
　４０２…第２ＤＶＣＵ
　４０３…第３ＤＶＣＵ
　４０４…障害時動作パターン
　４０５…安全処理リスト
　４０６…安全処理リスト
　４０７…ＥＣＵ
　４０８…センサ
　４０９…システムズ・オン・ア・チップ式マイクロコンピュータ
　６０１…第１ＤＶＣＵ
　６０２…第２ＤＶＣＵ
　６０３…第３ＤＶＣＵ
　６０４…ＡＤＡＳ
　９０１…第１ＤＶＣＵ
　９０２…第２ＤＶＣＵ
　９０３…第３ＤＶＣＵ
　９０４…障害時動作パターン
　９０５…安全処理リスト
　９０６…安全処理リスト
　９０７…ＥＣＵ
　９０８…センサ
　ＳＭ１…安全処理
　ＳＭ２…安全処理
　ＳＭ３…安全処理
　１２０１…マスターＥＣＵ
　１２０２…クライアントＥＣＵ
　１２０３…記憶装置
　本明細書で引用した全ての刊行物、特許および特許出願はそのまま引用により本明細書に組み入れられるものとする。

Claims (11)

  1. 　マスターＥＣＵと、１つ以上のクライアントＥＣＵとを備える車両制御装置であって、
    　前記マスターＥＣＵは、前記クライアントＥＣＵのいずれかの障害を検知した場合に、所定の障害時動作パターンに基づいて安全処理リストを生成して各前記クライアントＥＣＵに送信し、前記安全処理リストは、１つ以上の安全処理と、各安全処理に対応する実行開始期限とを含み、
    　各前記クライアントＥＣＵは、前記安全処理リストを受信することに応じて、動作モードを通常モードから障害時動作モードに切り替えるとともに、各安全処理を、対応する実行開始期限までに実行開始し、
    　前記障害時動作パターンは、各安全処理が、その安全処理を実行可能なメモリ容量を有するクライアントＥＣＵによって実行されるように構成され、
    　前記障害時動作パターンは、同一の安全処理が複数のクライアントＥＣＵによっては実行されないように構成される、
    車両制御装置。
  2. 　各前記クライアントＥＣＵは、各安全処理について、その安全処理の実行を開始した後に、安全処理実行開始完了通知を前記マスターＥＣＵに送信し、
    　前記マスターＥＣＵは、すべての安全処理について対応する実行開始期限までに前記安全処理実行開始完了通知を受信した場合には、前記障害時動作モードにおける動作を継続し、いずれかの安全処理について対応する実行開始期限までに前記安全処理実行開始完了通知を受信しなかった場合には、動作モードを障害時安全モードに切り替える、
    請求項１に記載の車両制御装置。
  3. 　前記マスターＥＣＵおよび各前記クライアントＥＣＵは、すべて同一のシステムズ・オン・ア・チップ式マイクロコンピュータによって構成される、請求項１に記載の車両制御装置。
  4. 　前記１つ以上のクライアントＥＣＵのうち少なくとも１つは、サブマスターＥＣＵであり、
    　前記サブマスターＥＣＵは、前記マスターＥＣＵの障害を検知した場合に、前記安全処理リストを生成して他の各クライアントＥＣＵに送信する、
    請求項１に記載の車両制御装置。
  5. 　請求項１に記載の車両制御装置を複数備える、車両制御システム。
  6. 　前記マスターＥＣＵおよび前記クライアントＥＣＵの少なくとも１つは、車両サーバおよびゾーンゲートウェイとして機能する統合ＥＣＵである、
    請求項１に記載の車両制御装置。
  7. 　前記車両制御装置は、複数の自動運転グレードに対応する、
    請求項６に記載の車両制御装置。
  8. 　前記車両制御装置は、環境認知データを出力するスマートセンサに接続される、
    請求項１に記載の車両制御装置。
  9. 　前記マスターＥＣＵおよび前記１つ以上のクライアントＥＣＵは、いずれも、すべての前記安全処理を実行可能であるように構成される、
    請求項１に記載の車両制御装置。
  10. 　前記車両制御装置は、前記マスターＥＣＵおよび前記１つ以上のクライアントＥＣＵによって実行されるすべてのソフトウェアのバックアップを記憶する記憶装置を備える、
    請求項１に記載の車両制御装置。
  11. 　前記車両制御装置は、前記マスターＥＣＵおよび前記１つ以上のクライアントＥＣＵによって実行されるすべてのソフトウェアについて、バイナリファイルのコピーを、前記マスターＥＣＵおよび前記１つ以上のクライアントＥＣＵのすべてからアクセス可能な記憶装置に記憶するか、または、前記マスターＥＣＵおよび前記１つ以上のクライアントＥＣＵのそれぞれの記憶装置に分散させて記憶する、
    請求項１に記載の車両制御装置。
PCT/JP2022/009299 2021-06-09 2022-03-04 車両制御装置および車両制御システム WO2022259655A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE112022001622.1T DE112022001622T8 (de) 2021-06-09 2022-03-04 Fahrzeugsteuervorrichtung und fahrzeugsteuersystem

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021-096584 2021-06-09
JP2021096584A JP2022188500A (ja) 2021-06-09 2021-06-09 車両制御装置および車両制御システム

Publications (1)

Publication Number Publication Date
WO2022259655A1 true WO2022259655A1 (ja) 2022-12-15

Family

ID=84425819

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/009299 WO2022259655A1 (ja) 2021-06-09 2022-03-04 車両制御装置および車両制御システム

Country Status (3)

Country Link
JP (1) JP2022188500A (ja)
DE (1) DE112022001622T8 (ja)
WO (1) WO2022259655A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160306720A1 (en) * 2015-04-16 2016-10-20 GM Global Technology Operations LLC Architecture for scalable fault tolerance in integrated fail-silent and fail-operational systems
JP2019111866A (ja) * 2017-12-21 2019-07-11 トヨタ自動車株式会社 自動運転システム
JP2021031052A (ja) * 2019-08-15 2021-03-01 ベイジン バイドゥ ネットコム サイエンス アンド テクノロジー カンパニー リミテッド 自動運転車両及び自動運転車両用のシステム

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7360925B2 (ja) 2019-12-16 2023-10-13 株式会社日立製作所 分析システム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160306720A1 (en) * 2015-04-16 2016-10-20 GM Global Technology Operations LLC Architecture for scalable fault tolerance in integrated fail-silent and fail-operational systems
JP2019111866A (ja) * 2017-12-21 2019-07-11 トヨタ自動車株式会社 自動運転システム
JP2021031052A (ja) * 2019-08-15 2021-03-01 ベイジン バイドゥ ネットコム サイエンス アンド テクノロジー カンパニー リミテッド 自動運転車両及び自動運転車両用のシステム

Also Published As

Publication number Publication date
JP2022188500A (ja) 2022-12-21
DE112022001622T5 (de) 2024-01-04
DE112022001622T8 (de) 2024-01-25

Similar Documents

Publication Publication Date Title
US11608075B2 (en) Information processing apparatus
KR100767074B1 (ko) 차량제어시스템의 고장감지장치
US11951963B2 (en) Apparatus for controlling autonomous vehicle brake
WO2017086087A1 (ja) 処理装置および車両制御システム
CN110325423B (zh) 车辆用控制系统及控制方法
WO2018237121A9 (en) METHOD OF USING A SINGLE CONTROLLER (ECU) FOR AN INDEPENDENT FAILURE-RESPONSIVE / FAILURE-INDEPENDENT DRIVING SYSTEM
CN112429012B (zh) 汽车电控系统、自动驾驶控制方法及汽车
JP6504065B2 (ja) 車両用制御システム
CN114650940A (zh) 用于控制车辆的自动驾驶运行的设备
KR20170041466A (ko) 자동차용 통합데이터 처리 제어 시스템 및 방법
CN114348027B (zh) 车辆控制方法、装置、平台及存储介质
WO2022259655A1 (ja) 車両制御装置および車両制御システム
CN113010185A (zh) 使软件动态地分布在车辆的控制系统中的方法及控制系统
WO2020129911A1 (ja) 統括ｅｃｕ、制御方法、制御システム及びプログラム
WO2022172498A1 (ja) 車載型コンピュータシステムおよび自動運転支援システム
WO2021256014A1 (ja) 車両制御システム
US20230075731A1 (en) System for monitoring an event chain including components for carrying out at least one semiautomated driving function of a motor vehicle and method for operating the system
CN113272195A (zh) 用于智能网联车辆的控制系统及控制方法
US20230156117A1 (en) Method for operating a management program
JP2020196333A (ja) 車両システム
US11884260B2 (en) Vehicle control device
US20220315018A1 (en) Control apparatus, manager, electronic control unit, system, control method, non-transitory computer-readable storage medium storing program, and vehicle
US20240174259A1 (en) Vehicle controls supporting multiple ads ecus
JP2022009422A (ja) 制御装置、マネージャ、システム、制御方法、プログラム及び車両
JP2022009421A (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: 22819845

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 18560584

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 112022001622

Country of ref document: DE