WO2022172498A1 - 車載型コンピュータシステムおよび自動運転支援システム - Google Patents

車載型コンピュータシステムおよび自動運転支援システム Download PDF

Info

Publication number
WO2022172498A1
WO2022172498A1 PCT/JP2021/033760 JP2021033760W WO2022172498A1 WO 2022172498 A1 WO2022172498 A1 WO 2022172498A1 JP 2021033760 W JP2021033760 W JP 2021033760W WO 2022172498 A1 WO2022172498 A1 WO 2022172498A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
ecu
computer system
program
management means
Prior art date
Application number
PCT/JP2021/033760
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 DE112021006067.8T priority Critical patent/DE112021006067T5/de
Priority to CN202180090860.7A priority patent/CN116762058A/zh
Publication of WO2022172498A1 publication Critical patent/WO2022172498A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy
    • G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
    • G06F11/0757—Error or fault detection not based on redundancy by exceeding limits by exceeding a time limit, i.e. time-out, e.g. watchdogs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/142—Reconfiguring to eliminate the error
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3055—Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0796—Safety measures, i.e. ensuring safe condition in the event of error, e.g. for controlling element

Definitions

  • the present invention relates to an in-vehicle computer system and an automatic driving support system.
  • Patent Document 1 describes a vehicle program rewriting system.
  • the center device indicates update data of a plurality of update target devices, target device IDs, and whether the program storage memory of the target device is single-sided or multi-sided, and performs update and rollback of the target device.
  • Specification data and update data generated by matching the ID, memory configuration, and address for the target device to a predetermined data structure, based on the memory configuration and the address for reading the update data referred to when , and delivers it to the vehicle-side system in response to notification from the vehicle-side system.
  • the vehicle-side system refers to the received delivery package to determine whether writing to the memory is possible while the vehicle is running, controls the program update of the target device, and if there is a cancellation on the way, rolls based on the memory configuration. control the back.
  • the present invention was made in order to solve such problems, and aims to provide a technology that can add new functions by updating the program of the in-vehicle computer system.
  • An example of an in-vehicle computer system includes: An in-vehicle computer system capable of communicating with a computer outside the vehicle, the vehicle-mounted computer system comprises a plurality of ECUs, each ECU communicating with at least one other ECU via a communication bus;
  • the in-vehicle computer system comprises: For the ECU, measuring means for measuring an ECU state; estimating means for estimating a vehicle state based on the ECU state and the connection configuration of the communication bus; a management means for acquiring an update program and an execution condition of the update program; with The management means selects the first ECU to execute the update program based on the vehicle state and the execution condition, The first ECU executes the update program, The management means determines whether or not an output delay constraint of the update program is satisfied, The management means terminates execution of a redundancy program redundant to the update program.
  • An example of an automatic driving support system according to the present invention includes the vehicle-mounted computer system described above and the computer outside the vehicle.
  • This specification includes the disclosure content of Japanese Patent Application No. 2021-021914, which is the basis of priority of this application.
  • new functions can be added by updating the program of the vehicle-mounted computer system.
  • FIG. 4 is a conceptual diagram of the operation of adding a new function to the vehicle-mounted computer system according to the first embodiment; 4 is an example of a sensor used in the vehicle-mounted computer system according to the first embodiment; 4 is an example of an architecture of an in-vehicle computer system according to the first embodiment; 4 is an example of a functional block configuration of an in-vehicle computer system according to the first embodiment; 4 is an example of program arrangement for a plurality of ECUs in the vehicle-mounted computer system according to the first embodiment; 4 is a part of a flow chart showing an operation example of the in-vehicle computer system according to the first embodiment; 4 is a part of a flow chart showing an operation example of the in-vehicle computer system according to the first embodiment; 4 is a part of a flow chart showing an operation example of the in-vehicle computer system according to the first embodiment; 4 is an operation example in which
  • FIG. 1 shows examples of various modules arranged in an automatic driving support system including an in-vehicle computer system according to Embodiment 1 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 may implement or derive onboard EE and network resources. can.
  • 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-mounted computer system according to Example 1 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 EE 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-mounted computer system 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-mounted computer system can use the autonomous driving capability of the smart infrastructure to reduce in-vehicle power consumption.
  • the vehicle-mounted computer system according to the first embodiment is mounted, for example, in a vehicle having an automatic driving function.
  • a vehicle having an automatic driving function is not limited to 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 an in-vehicle computer system according to the first embodiment.
  • This automatic driving support system includes an in-vehicle computer system and a computer outside the vehicle.
  • Self-driving vehicles can be set to an automatic mode and can automatically drive the vehicle along predetermined driving scenarios with or without assistance from a safe driver.
  • the on-board computer system 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, and 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 functions. It includes a malfunction monitoring system 114 and a powertrain system 115 .
  • Self-driving vehicles can run in either manual mode, fully automatic mode, or semi-automatic mode.
  • 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 an autonomous driving environment including an in-vehicle computer system according to the first embodiment.
  • This example relates to smart highways.
  • the smart highway comprises roadside units 201 and 208 and smart infrastructure 203 and 206 to monitor driving scenarios.
  • the smart infrastructures 203 and 206 can communicate with the cloud server 207.
  • Smart infrastructures 203 and 206 can process driving scenario information obtained by perception sensors.
  • Cloud server 207 processes smart highway driving scenarios to derive driving behaviors necessary for safe navigation of vehicles 202 , 204 , 205 and 209 .
  • Smart infrastructures 203 and 206 can communicate with each vehicle and cloud server 207 either directly or via a roadside unit.
  • Each vehicle is capable of fully or semi-automated operation and is capable of communicating with roadside units, smart infrastructure and other vehicles.
  • Each vehicle can use driving scenario recognition and driving behavior information for safe driving.
  • the automated driving environment further includes a road surface 211 (strictly speaking, a computer arranged with respect to the road surface and may be embedded in the road; hereinafter the same applies to the “road surface”) and a satellite 212 .
  • the vehicle-mounted computer system according to the first embodiment can be installed in these vehicles 202, 204, 205 and 209, for example.
  • An on-board computer system can communicate with a computer outside the vehicle. Examples of off-vehicle computers include roadside units 201 and 208, smart infrastructure 203 and 206, cloud server 207, road surface 211, satellite 212, and the like.
  • FIG. 3 is a conceptual diagram of the operation of adding a new function to the AD/ADAS compatible vehicle according to the first embodiment.
  • Vehicles 307 to 309 are equipped with the vehicle-mounted computer system according to the first embodiment.
  • Vehicles 307-309 are low-cost entry or mid-range vehicles that meet SAE standards L1-L2+ and have autonomous driving capabilities.
  • Vehicles 307-309 are traveling on a smart highway that can provide the driving behaviors necessary to safely navigate the smart highway.
  • the vehicles 307-309 comply with SAE standards L2+ to L5 by communicating with computers outside the vehicle (eg roadside unit 301, smart infrastructure 302 and 303, road surface 304, cloud server 305, satellite 306, etc.).
  • computers outside the vehicle eg roadside unit 301, smart infrastructure 302 and 303, road surface 304, cloud server 305, satellite 306, etc.
  • the application integrator 310 can operate on the onboard computer system and integrate autonomous driving applications provided by smart highways into the onboard computer system to extend the capabilities of the onboard computer system.
  • FIG. 4 shows an example of sensors used in the vehicle-mounted computer system according to the first embodiment.
  • An on-board computer system can include various sensors 403-408. Each sensor provides the information necessary for various standard L1 (401) and standard L2 (402) functions of the on-board computer system. The abbreviations of each standard are explained in 409.
  • FIG. 5 shows an example of the architecture of the vehicle-mounted computer system according to the first embodiment. If the autonomous driving level is standard L1 and L2, the safety is “fail safe” and the architecture is standard 1oo1D. If the autonomous driving level is standard L3-L5, the safety is “fail operational” and the architecture is standard 1oo2D.
  • the vehicle-mounted computer system can cover all AD/ADAS levels of the SAE standards.
  • the in-vehicle computer system can utilize driving scenario recognition and driving behavior capabilities for enhancing the vehicle's autonomous driving capabilities.
  • FIG. 6 is an example of the functional block configuration of the vehicle-mounted computer system according to the first embodiment.
  • Vehicle 602 can communicate with cloud server 601, roadside device 603, and the like.
  • An in-vehicle computer system 604 installed in a vehicle 602 includes an on-board device 605, environmental sensors 606 (camera, radar, LiDAR, sonar, etc.), vehicle sensors 607 (GNSS, IMU, odometry, etc.), AD/ADAS Application 608 , monitoring means 609 , powertrain application 610 , body control application 611 , chassis control application 612 , actuators 613 (brake, throttle, steering, etc.), infotainment means 614 , map means 615 . (Environment location means, etc.).
  • the in-vehicle computer system 604 can be configured in various in-vehicle EE environments. For example, unified domain architectures, hybrid zone domain architectures, zone architectures, etc. are possible.
  • FIG. 7 is an example of program arrangement for a plurality of ECUs in the vehicle-mounted computer system according to the first embodiment.
  • the vehicle-mounted computer system includes ECU1 to ECU5 (701 to 705). Each ECU can communicate with at least one other ECU via communication buses 706-710.
  • each ECU has a processor and storage means.
  • a processor can function as a computing means and execute a program.
  • the storage means may store programs. When the processor executes this program, the ECU functions as various means described below, thereby realizing the functions described in this embodiment of the vehicle-mounted computer system.
  • the in-vehicle computer system is equipped with a measurement means VLASE (Vehicle Local Area State Estimator) that measures the ECU state of the ECU.
  • the measuring means VLASE is implemented, for example, by the ECU executing a predetermined VLASE program.
  • the measuring means VLASE are arranged in ECU1, ECU2, ECU4 and ECU5.
  • the ECU status includes information indicating the program being executed in the ECU.
  • ECU 1 runs the recognition program
  • ECU 2 runs the planning program
  • ECU 3 is the master ECU
  • ECU 4 runs the actuator control program
  • ECU 5 runs the display program.
  • the ECU status may include processor load, memory usage, and communication bus usage in the ECU.
  • the vehicle-mounted computer system is equipped with an estimating means VASEM for estimating the vehicle state.
  • the estimating means VASEM is arranged in ECU3 (704).
  • the estimating means VASEM (Vehicle Architecture State Estimator Master) estimates the vehicle state based on the ECU state and the connection configuration of the communication bus.
  • the vehicle state is information obtained by combining, for example, the ECU state and the connection configuration of the communication bus.
  • the estimating means VASEM is arranged in the ECU4.
  • the ECU 3 (704) may also be provided with the measuring means VLASE.
  • the estimating means VASEM may have the functionality of the measuring means VLASE.
  • the connection configuration of the communication buses includes information indicating which ECUs are connected to which ECUs by each communication bus.
  • ECU1 and ECU2 are connected via communication bus 1 (708).
  • ECU2 and ECU3 are connected via communication bus 3 (710).
  • ECU1 and ECU3 are connected via communication bus 2 (707).
  • the ECU2 and the ECU4 are connected via a communication bus 4 (709).
  • the ECU 3 and the ECU 5 are connected via a communication bus 5 (706).
  • the ECU 1 and the ECU 4 are not directly connected by a communication bus, and must be connected via the communication bus 1, the ECU 2, and the communication bus 4.
  • Such information representing the connection configuration of the communication bus may be actively generated by the estimating means VASEM through measurement or the like, or may be stored in advance in the storage means of each ECU.
  • the in-vehicle computer system is equipped with a management means DRIM (Dynamic Reconfiguration Indicator Master).
  • the management means DRIM is arranged in ECU3 (704).
  • the management means DRIM acquires the update program and the execution conditions of the update program. A specific example of the execution condition will be described later with reference to FIG.
  • the in-vehicle computer system has an execution means DRIC (Dynamic Reconfiguration Indicator Client).
  • the execution means DRIC are arranged in ECU1, ECU2, ECU4 and ECU5.
  • the executing means DRIC causes the ECU to execute or terminate a specific program.
  • the executing means DRIC of the ECU 2 causes the ECU 2 to execute the planning program.
  • the execution means DRIC may perform a process called program installation.
  • execution means DRIC may also be arranged in the ECU 3 (704).
  • management means DRIM may comprise the functionality of the execution means DRIC.
  • FIGS. 8A and 8B are flowcharts showing an operation example of the vehicle-mounted computer system according to the first embodiment.
  • the management means DRIM acquires the update program and its execution conditions (step 801).
  • the update program and its execution conditions can be obtained through any route, but may be stored in advance in storage means of any ECU, or may be obtained from a computer outside the vehicle, for example.
  • the measuring means VLASE measures the ECU state for each ECU (step 802).
  • the measuring means VLASE sends the measured ECU states to the estimating means VASEM.
  • the ECU status can include information indicative of the programs running on the ECU, and can include processor load, memory usage, communication bus usage, etc. on the ECU.
  • the estimating means VASEM estimates the vehicle state (step 803) and notifies the vehicle state to the managing means DRIM.
  • the management means DRIM determines the resources to allocate to the update program (step 804).
  • Resources include, for example, processor load, memory usage and communication bus usage.
  • a method of determining resources to be allocated can be appropriately designed by those skilled in the art. For example, information indicating the amount of resources required in association with an update program may be obtained. Also, the amount of resources to be allocated may be changed according to the resources available in the vehicle-mounted computer system.
  • a redundant program means a program that is redundant with respect to the update program. For example, if an update program includes all the functionality of a planning program, the planning program is redundant to that update program.
  • a person skilled in the art can appropriately design a method for determining which program is a redundant program for a given update program. For example, an ID may be assigned to each program, and the ID of the redundant program may be associated with the update program in advance. In that case, the redundant program can be specified by obtaining the ID of the redundant program together with the update program in step 801 .
  • the in-vehicle computer system may determine that a program that outputs the same type of data (for example, data for the same display device) as the update program is a redundant program.
  • a method for determining the time required for execution start and execution end can be appropriately designed by a person skilled in the art. For example, it may be determined according to the size of each program, or the time may be associated with each program and stored in the storage means in advance. In addition, it may be calculated or modified based on various other information.
  • the management means DRIM determines whether or not the time required to start executing the update program and finish executing the redundant program satisfies a predetermined safety standard (step 806). For example, it is determined whether or not it will be completed within a predetermined reference time.
  • a predetermined safety standard For example, it is determined whether or not it will be completed within a predetermined reference time.
  • the safety criteria in step 806 may be fixed, may be criteria associated with each program, or may be criteria that change according to other conditions.
  • the reference may change depending on the vehicle speed at that time. For example, when the vehicle is stopped or running at low speed (during parking operation, etc.), even if the period in which the functions of each program are not exhibited is longer, it is not considered to affect safety, so the reference time should be set longer than the initial value. However, when driving at high speeds (driving on highways, etc.), long periods in which the functions of each program are not exhibited affect safety, so it is necessary to complete the process in a short time, so the reference time is the initial value shorter.
  • step 806 if the required time satisfies the safety standards, the in-vehicle computer system updates the program (step 807).
  • the management means DRIM selects an ECU (first ECU, hereinafter referred to as "target ECU") to execute the update program based on the vehicle state and the update program execution conditions. Then, the update program and update request are transmitted to the selected target ECU. The target ECU receiving these starts executing the update program by the function of the executing means DRIC.
  • the management means DRIM terminates the execution of the redundancy program. That is, a request to terminate the redundant program is transmitted to the ECU (target ECU or another ECU) executing the redundant program. The ECU that has received the termination request terminates execution of the redundant program by the function of the execution means DRIC. This reduces consumption of unnecessary resources.
  • the execution means DRIC may store information (program ID, program code, etc.) necessary for resuming the execution of the redundant program later.
  • the measuring means VLASE measures the ECU state after the processing by the executing means DRIC in step 807 and transmits it to the estimating means VASEM (step 808).
  • the estimating means VASEM estimates the vehicle state based on the updated ECU state, etc., and notifies the vehicle state to the managing means DRIM (step 809).
  • the management means DRIM determines whether or not the update program output delay constraint is satisfied (step 810).
  • a specific example of output delay constraints and determination processing will be described later with reference to FIG.
  • step 810 if the output delay constraint of the update program is satisfied, the target ECU continues executing the update program, thereby causing the on-board computer system to operate in the new ADAS mode (step 811).
  • the executing means DRIC (not necessarily the target ECU) monitors the managing means DRIM and if it detects a fault in the managing means DRIM, the redundant program (i.e. the managing means DRIM terminates execution in step 807). program) is executed again (step 813). In this way, the execution of the redundant program illegally terminated by the faulty management means DRIM can be resumed.
  • the redundant program i.e. the managing means DRIM terminates execution in step 807). program
  • program is executed again (step 813). In this way, the execution of the redundant program illegally terminated by the faulty management means DRIM can be resumed.
  • a person skilled in the art can appropriately design the selection method of the ECU that executes the redundant program. For example, it is possible to select the ECU that executed the redundant program last.
  • step 810 if the update program output delay constraint is not satisfied, the vehicle-mounted computer system executes a predetermined safety process.
  • the vehicle-mounted computer system operates in a secure ADAS mode (step 812).
  • Specific contents of the safety ADAS mode can be appropriately designed by those skilled in the art.
  • the maximum vehicle speed during automated driving is limited to a value smaller than the maximum value during normal operation, thereby controlling the vehicle so that it can drive safely even when the output delay constraint is not satisfied.
  • the vehicle-mounted computer system After the redundant program is restarted in step 813 or after step 812, the vehicle-mounted computer system returns to the previous state (step 814).
  • a method for determining the state to be restored (backup or checkpoint) and specific processing for restoration can be appropriately designed by those skilled in the art. For example, redundancy programs and other application programs can be recovered or reinstalled and a system reboot can be performed.
  • step 806 if the time required to start executing the update program and finish executing the redundancy program does not meet the predetermined safety criteria, the on-board computer system safely stops the vehicle. It is determined whether or not it is possible (step 815).
  • the specific contents of this determination can be appropriately designed by those skilled in the art based on known automatic driving technology and the like. For example, it can be determined based on the road on which the vehicle is traveling, the surrounding conditions, the vehicle speed, and the like.
  • the vehicle-mounted computer system executes the processing of steps 807 to 814 in FIG. 8B after safely stopping the vehicle.
  • the onboard computer system either operates in the safe ADAS mode or continues to operate in the current AD/ADAS mode (step 816). In this case, the update program will not be executed.
  • FIG. 9 shows an operation example in which a new function is added to the vehicle-mounted computer system according to the first embodiment.
  • FIG. 10 shows an example of information used in the vehicle-mounted computer system according to the first embodiment.
  • ECU2 (903) is executing the planning program.
  • This client application is an update program and the planned program becomes a redundant program for the client application. That is, as shown, the client application is turned ON and the planning program is turned OFF.
  • Input/output constraints 1001 related to client applications are defined in advance.
  • Input/output constraints 1001 represent at least part of execution conditions and include input delay constraints and output delay constraints.
  • Input delay constraints include, for example, data size and maximum allowable delay.
  • the input delay constraint is that an image of 1 Mbyte size (e.g. raw image from camera) must be input to the client application within 50 ms after generation (e.g. output from camera).
  • the output delay constraint includes, for example, data size and maximum allowable output period.
  • the output delay constraint is that two types of control information (control information A and B) each have a size of 10 bytes and must be output from the client application at a cycle of 50 ms or less. is.
  • step 807 the target ECU is selected using the execution conditions of the update program and the connection configuration of the communication bus.
  • the update program execution condition includes, for example, an input delay constraint (and may further include an output delay constraint).
  • the connection configuration of the communication bus is represented by an input delay table 1002, for example.
  • the top row represents the input delay with respect to the camera image (generated in ECU1).
  • Each column represents the input delay from ECU1 to each ECU.
  • the input delay from ECU1 to ECU1 is 0 because they are the same ECU. Since this is within 50ms, executing the client application on ECU1 satisfies the input delay constraint. Therefore, the ECU 1 can be used as a target ECU.
  • the input delay from ECU1 to ECU2 is 10 s when passing through communication bus 1 (CAN). Since this exceeds 50 ms, when the client application is executed by the ECU 2 and communication is performed via the communication bus 1, the input delay constraint is not satisfied. On the other hand, the input delay from ECU1 to ECU2 is 20 ms when passing through communication bus 2 (Ethernet (registered trademark)) and communication bus 3 (Ethernet). Since this is within 50 ms, when the ECU 2 executes the client application, communication via the communication buses 2 and 3 satisfies the input delay constraint. Therefore, the ECU 2 can be the target ECU only when using a specific communication route.
  • the management means DRIM notifies each ECU of the information transmission route of the client application, and each ECU transmits and receives information accordingly.
  • the ECU state may be used as a criterion for determining which ECU is selected as the target ECU. For example, for each ECU, a total load may be calculated based on the processor load, memory usage, and communication bus usage, and the ECU with the lowest total load may be selected as the target ECU.
  • a method (function, etc.) for calculating the total load can be appropriately designed by those skilled in the art. For example, the total load may be obtained by multiplying the processor load, memory usage, and communication bus usage by weights. Such determination processing enables selection of an appropriate target ECU.
  • the input delay table 1002 can be generated based on the communication time table 1003, for example.
  • the communication time table represents the time required for communication processing via each communication bus for each data size.
  • the input delay table 1002 may be pre-created and stored.
  • input delay table 1002 may be obtained in association with an update program.
  • the control design 1004 shows an overview of the input/output of the client application.
  • a recognition program generates a camera image
  • the camera image is input to a client application
  • the client application generates output information based on the camera image
  • the output information is input to the operation program and the display program.
  • the output determination example 1005 shows the achievement status of the output delay constraint when the ECU 2 is the target ECU (measured by the management means DRIM in step 801).
  • both the control information A and B are output from the ECU 2 with a period of 50 ms. Since all periods are within 50 ms, it is determined that the output delay constraint is satisfied.
  • the output determination example 1006 shows the state of the output delay in the ECU 3 when the ECU 2 is the target ECU. An operation program is being executed in the ECU 3, the control information A is unnecessary, and the output cycle of the control information B is 100 ms.
  • an output determination example 1007 shows the state of output delay in the ECU 5 when the ECU 2 is the target ECU.
  • a display program is being executed in the ECU 3, the output cycle of the control information A is 10.2 seconds, and the control information A is unnecessary.
  • FIG. 11 shows an example of the relationship between the management means DRIM and the execution means DRIC in the first embodiment.
  • the management means DRIM stores the update program in RAM (random access memory).
  • the management means DRIM transmits a heartbeat signal to each execution means DRIC (more specifically, each ECU realizing each execution means DRIC) at a predetermined cycle.
  • Each execution means DRIC detects the failure of the management means DRIM based on the lack of heartbeat signals.
  • "lack of heartbeat signal” means, for example, that the heartbeat signal is not received at a predetermined timing, or that the time from the reception of a heartbeat signal to the reception of the next heartbeat signal is a predetermined amount of time. It means that the threshold has been exceeded.
  • each executing means DRIC When each executing means DRIC detects a failure of the managing means DRIM, it ignores signals received from the managing means DRIM after the detection. Further, each execution means DRIC transmits fault information to other execution means DRIC when detecting a fault in the management means DRIM. Each enforcing means DRIC ignores signals received from the managing means DRIM after receiving the fault information. In this way, when a failure occurs in the management means DRIM, malfunction of the in-vehicle computer system due to erroneous control information transmitted thereafter is suppressed.
  • the output delay constraint represents the output period, but as a modification, it may represent the allowable delay.
  • the output delay constraint is that two types of control information (control information A and B) each have a size of 10 bytes and must be output from the client application within 50 ms. may be
  • new functions can be added by updating the program of the vehicle-mounted computer system.
  • input/output constraint (input delay constraint and output delay constraint) 1002...Input delay table 1003...Communication time table 1004...Control design 1005-1007...Output judgment example
  • DRIC...Execution means
  • DRIM...Management means
  • VASEM...Estimation means
  • VLASE...Measurement means All publications, patents and references cited in this specification The patent application is hereby incorporated by reference in its entirety.

Abstract

車載型コンピュータシステムのプログラム更新によって新たな機能を追加できる技術を提供する。　車載型コンピュータシステムは複数のＥＣＵを備える。各ＥＣＵは通信バスを介して少なくとも１つの他のＥＣＵと通信可能である。車載型コンピュータシステムは、ＥＣＵについて、ＥＣＵ状態を測定する測定手段と、ＥＣＵ状態と、通信バスの接続構成とに基づき、車両状態を推定する推定手段と、更新プログラムと、更新プログラムの実行条件とを取得する、管理手段と、を備える。管理手段は、車両状態と、実行条件とに基づいて、更新プログラムを実行すべき第１ＥＣＵを選択する。第１ＥＣＵは、更新プログラムを実行する。管理手段は、更新プログラムの出力遅延制約が満たされているか否かを判定する。管理手段は、更新プログラムに対して冗長な冗長プログラムの実行を終了させる。

Description

車載型コンピュータシステムおよび自動運転支援システム
　本発明は、車載型コンピュータシステムおよび自動運転支援システムに関する。
　車載型コンピュータシステムにおいて、ＯＴＡ（Over The Air）技術等を用いて電子制御装置の更新またはアップグレードを行うことが可能である。
　たとえば特許文献１には、車両用プログラム書換えシステムが記載されている。特許文献1に記載される構成では、センター装置は、複数の更新対象装置の更新データ、対象装置ＩＤ及び対象装置のプログラム格納メモリが１面か複数面かを示し、対象装置の更新及びロールバックの際に参照されるメモリ構成と更新データを読み出すためのアドレスとに基づき、対象装置に対するＩＤ、メモリ構成及びアドレスを予め定められた所定のデータ構造に合わせて生成された諸元データと更新データとを含む配信パッケージを記憶し、車両側システムからの通知に応じてそれを車両側システムへ配信する。車両側システムは、受信した配信パッケージを参照して車両の走行中にメモリへの書込みが可能か否か判断し、対象装置のプログラム更新を制御し、途中でキャンセルがあるとメモリ構成に基づきロールバックを制御する。
特開２０２０－０２７６６９号公報
　しかしながら、従来の技術では、車載型コンピュータシステムのプログラム更新によって新たな機能を追加することが困難であるという課題があった。
　特許文献１の構成では、車載の中央ユニットおよび分散ユニットが新たな機能を統合するようには設計されておらず、また、スマートインフラストラクチャに基づく自動運転（ＡＤ）または先進運転支援システム（ＡＤＡＳ）アプリケーションを統合するようにも設計されていない。特許文献１の構成は、ファームウェアまたはバージョン更新を扱うのみであり、機能を更新することはできない。このため、特許文献１の構成では、プログラム更新によって新たな機能を追加することができない。
　本発明はこのような課題を解決するためになされたものであり、車載型コンピュータシステムのプログラム更新によって新たな機能を追加できる技術を提供することを目的とする。
　本発明に係る車載型コンピュータシステムの一例は、
　車外のコンピュータと通信可能な、車載型コンピュータシステムであって、
　前記車載型コンピュータシステムは複数のＥＣＵを備え、各ＥＣＵは通信バスを介して少なくとも１つの他のＥＣＵと通信可能であり、
　前記車載型コンピュータシステムは、
　前記ＥＣＵについて、ＥＣＵ状態を測定する測定手段と、
　前記ＥＣＵ状態と、前記通信バスの接続構成とに基づき、車両状態を推定する推定手段と、
　更新プログラムと、前記更新プログラムの実行条件とを取得する、管理手段と、
を備え、
　前記管理手段は、前記車両状態と、前記実行条件とに基づいて、前記更新プログラムを実行すべき第１ＥＣＵを選択し、
　前記第１ＥＣＵは、前記更新プログラムを実行し、
　前記管理手段は、前記更新プログラムの出力遅延制約が満たされているか否かを判定し、
　前記管理手段は、前記更新プログラムに対して冗長な冗長プログラムの実行を終了させる。
　本発明に係る自動運転支援システムの一例は、上述の車載型コンピュータシステムと、前記車外のコンピュータとを備える。
　本明細書は本願の優先権の基礎となる日本国特許出願番号2021-021914号の開示内容を包含する。
　本発明に係る車載型コンピュータシステムおよび自動運転支援システムによれば、車載型コンピュータシステムのプログラム更新によって新たな機能を追加することができる。
本発明の実施例１に係る車載型コンピュータシステムを含む自動運転支援システムに配置される様々なモジュールの例。 実施例１に係る車載型コンピュータシステムを含む自動運転環境の例。 実施例１に係る車載型コンピュータシステムに新たな機能を追加する動作の概念図。 実施例１に係る車載型コンピュータシステムに用いられるセンサの例。 実施例１に係る車載型コンピュータシステムのアーキテクチャの例。 実施例１に係る車載型コンピュータシステムの機能ブロック構成の例。 実施例１に係る車載型コンピュータシステムにおいて、複数のＥＣＵに対するプログラムの配置例。 実施例１における車載型コンピュータシステムの動作例を示すフローチャートの一部。 実施例１における車載型コンピュータシステムの動作例を示すフローチャートの一部。 実施例１における車載型コンピュータシステムに新たな機能が追加される動作例。 実施例１における車載型コンピュータシステムにおいて用いられる情報の例。 実施例１における管理手段ＤＲＩＭと実行手段ＤＲＩＣとの関係の例。
　以下、本発明の実施例を添付図面に基づいて説明する。以下は例示であり、本発明を限定するものではない。
実施例１．
　図１は、本発明の実施例１に係る車載型コンピュータシステムを含む自動運転支援システムに配置される様々なモジュールの例を示す。実施例１は、車両の自律運転機能を拡張するための、スマートインフラストラクチャ、コネクテッドサービス、クラウドベース自律運転アプリケーションを、車載型ＡＤ／ＡＤＡＳプログラムに統合することができる。
　ＡＤとはたとえば自動運転（Autonomous Driving）を意味し、ＡＤＡＳとはたとえば先進運転支援システム（Advanced Driver Assistance System）を意味する。本明細書において、プログラムとは、たとえばアプリケーションプログラムを意味するがこれに限らない。
　車載の電気電子（ＥＥ）資源の最適な利用のために、および、安全な統合および車載型ＡＤ／ＡＤＡＳ拡張モード遷移のために、車両は車内のＥＥ資源およびネットワーク資源を実行または導出することができる。
　同様に、車両は、環境条件、環境認識アルゴリズム、最適スループット要件、等の動的動作運転設計ドメインの知識ベースを有してもよい。
　スマートインフラストラクチャ、コネクテッドサービス、クラウドベース自律運転アプリケーションの資源要件および資源可用性に基づき、実施例１に係る車載型コンピュータシステムは、要求される資源を安全および最適スループットのために割り当てることができる。
　また、アプリケーション要件に基づき、アプリケーションデータのリルーティングおよびスケジューリングも実行される。
　自動運転車両は、車両制御システム（たとえばＡＤ／ＡＤＡＳシステム）を用いて制御される。車両制御システムは、ゾーンベースまたはドメインベースのＥＥアーキテクチャにおいて構成される、複数の環境認識センサ、車両センサ、ローカリゼーションセンサ、アクチュエータ（ブレーキ、ステアリング、スロットル、パワートレイン等）、等を含む。
　車両制御システムは、互いに通信する複数のモジュールを含む。複数のモジュールを協働させることが有益である。また、各モジュールは、センサデータ、認識データ、計画データ、アプリケーション状態データ、等を要求する複数のプログラムを含む場合がある。モジュールまたはプログラムは、１つ以上の資源要件と、クリティカルな運転シナリオおよび車両制御システム状態における優先度とを有する場合がある。これらのタスクを協働させるには、利用可能な資源の状態に応じて、各タスク／サービスの優先度およびデッドラインを適応させることが有益である。
　たとえば、スマートインフラストラクチャまたは路側機クラウドベースリモートサーバと通信可能な車両が、車両制御を支援または完全にテイクオーバできるスマートハイウェイを走行している場合には、車両の自動運転機能を拡張することができる。
　クライアントアプリケーションの資源要件によっては、実施例１に係る機能ブロックは、安全なモード遷移のために、クライアントアプリケーションを車載型ＡＤ／ＡＤＡＳアプリケーションに統合することができる。
　たとえば、スマートハイウェイが、ハンズフリースーパークルーズおよび車線変更機能を提供可能なハイウェイパイロットラインアプリケーションを提供する場合がある。そのようなシナリオでは、車載側のハンズオン／オフＡＣＣ（適応的クルーズ制御）（半自律運転車両）およびＬＫＡ（車線維持支援）は終了可能である。しかしながら、ＡＥＢ（自動緊急ブレーキ）衝突回避アプリケーション等の安全クリティカルなアプリケーションは、クライアントアプリケーションと協働する必要がある。
　このクライアントアプリケーションと、車載型ＡＤ／ＡＤＡＳ安全アプリケーションとの組み合わせでは、リアルタイム／ソフトタイムの遅延制約が厳しくなる場合がある。そのようなシナリオでは、実施例１に係る車載型コンピュータシステムは、アプリケーションデータのスケジューリングおよびリルーティングも行うことができる。
　別の例として、レーダー、ＬｉＤＡＲ、カメラ、等を用いる車両検出は、それぞれ異なるネットワーク帯域幅要件を有する。デッドラインに対してレーダーのネットワーク帯域幅が要求するデータサイズは、カメラの場合に比較してはるかに小さい場合がある。車載型ＡＤ／ＡＤＡＳアプリケーションにスマートインフラストラクチャのクライアントアプリケーションを追加する場合には、ＡＤ／ＡＤＡＳアプリケーションを最小資源要件モードで実行することができる。
　同様に、自動駐車および最適な電力利用も可能である。フェールオペレーショナルな車両制御システムを装備した高度な自動運転車両では、実施例１に係る車載型コンピュータシステムは、スマートインフラストラクチャの自律運転能力を利用して、車内の電力消費を抑制することができる。
　実施例１に係る車載型コンピュータシステムは、たとえば自動運転機能を有する自動車に搭載されるが、「車載型」とは移動可能な装置に搭載されることを意味し、とくに自動車に搭載されるものに限らない。他の例として、バス、トラック、建設機械、地上型ロボット、倉庫ロボット、飛行機、ヘリコプター、ボート、船舶、農場機械、サービスロボット、列車、ゴルフカート、等にも搭載可能である。
　図１は、実施例１に係る車載型コンピュータシステムを含む自動運転支援システムに配置され得る様々なモジュールの例を示す。この自動運転支援システムは、車載型コンピュータシステムと、車外のコンピュータとを含んで構成される。自動運転車両は、自動モードに設定することができ、安全ドライバーからの支援を得て、または支援なしで、所定の運転シナリオに沿って自動的に車両を運転することができる。
　車載型コンピュータシステムは、環境認識センサシステム１０１と、環境認識システム１０２（運転シナリオに関する情報を収集する）と、計画システム１０３と、無線通信システム１０４と、物理ネットワーク通信システム１０５と、作用システム１０６と、車体・シャーシ制御システム１０７と、インフォテインメントシステム１０８と、ヒューマンマシンインタフェースシステム１０９と、ドライバー監視システム１１０と、車両制御システム１１１と、Ｖ２Ｘシステム１１２と、ドライバーインテンション１１３と、車両診断および機能不全監視システム１１４と、パワートレインシステム１１５とを含む。
　自動運転車両は、手動モード、全自動モード、半自動モードのいずれかで走行可能である。車両は、図１のモジュールをすべて備える必要はなく、一部のモジュールが省略されていてもよい。
　自動運転車両は、さらに、エンジン、車輪、ハンドル（ステアリングホイール）、トランスミッション、等を備えてもよく、車両制御システムがこれらを制御してもよい。自動運転車両は、さらに、各モジュールが互いに通信することを可能にする物理ネットワーク（有線ネットワーク）または無線ネットワークを備えてもよい。ネットワークは冗長であってもよい。
　図２は、実施例１に係る車載型コンピュータシステムを含む自動運転環境の例を示す。この例はスマートハイウェイに関連する。スマートハイウェイは、路側機２０１および２０８と、スマートインフラストラクチャ２０３および２０６とを備え、運転シナリオを監視することができる。
　スマートインフラストラクチャ２０３および２０６は、クラウドサーバ２０７と通信することができる。スマートインフラストラクチャ２０３および２０６は、認識センサにより取得された運転シナリオ情報を処理することができる。クラウドサーバ２０７は、スマートハイウェイ運転シナリオを処理して、車両２０２、２０４、２０５および２０９の安全なナビゲーションに必要な運転挙動を導出する。
　スマートインフラストラクチャ２０３および２０６は、各車両およびクラウドサーバ２０７と、直接的に、または路側機を介して、通信可能である。各車両は、全自動または半自動運転が可能であり、また、路側機、スマートインフラストラクチャおよび他の車両との通信が可能である。各車両は、安全な走行のために、運転シナリオ認識および運転挙動情報を用いることができる。自動運転環境は、さらに、路面２１１（厳密には路面に関して配置されるコンピュータであり、道路に埋め込まれていてもよい。以下「路面」について同じ）および人工衛星２１２を含む。
　実施例１に係る車載型コンピュータシステムは、たとえばこれらの車両２０２、２０４、２０５および２０９に搭載することができる。車載型コンピュータシステムは、車外のコンピュータと通信可能である。車外のコンピュータの例として、路側機２０１および２０８、スマートインフラストラクチャ２０３および２０６、クラウドサーバ２０７、路面２１１、人工衛星２１２、等が挙げられる。
　図３は、実施例１に係るＡＤ／ＡＤＡＳ対応車両に新たな機能を追加する動作の概念図である。車両３０７～３０９に、実施例１に係る車載型コンピュータシステムが搭載されている。車両３０７～３０９は、ＳＡＥ規格Ｌ１～Ｌ２＋に適合し、自律運転機能を有する低コストエントリ車両またはミッドレンジ車両である。
　車両３０７～３０９は、スマートハイウェイを安全にナビゲートするのに必要な運転挙動を提供できるスマートハイウェイを走行している。この場合には、車外のコンピュータ（たとえば路側機３０１、スマートインフラストラクチャ３０２および３０３、路面３０４、クラウドサーバ３０５、人工衛星３０６、等）と通信することにより、車両３０７～３０９をＳＡＥ規格Ｌ２＋～Ｌ５に拡張することができる。
　このような動作は、アプリケーションインテグレータ３１０によって実現することができる。アプリケーションインテグレータ３１０は、車載型コンピュータシステム上で動作することができ、スマートハイウェイによって提供される自律運転アプリケーションを、車載型コンピュータシステムに統合して、車載型コンピュータシステムの能力を拡張することができる。
　図４は、実施例１に係る車載型コンピュータシステムに用いられるセンサの例を示す。車載型コンピュータシステムは、様々なセンサ４０３～４０８を備えることができる。各センサは、車載型コンピュータシステムの、規格Ｌ１（４０１）および規格Ｌ２（４０２）様々な機能に必要な情報を提供する。なお、各規格の略語の説明は４０９に示す。
　自律運転能力を拡張すると、ＡＤ／ＡＤＡＳアプリケーションの資源コストは増大する。実施例１によれば、スマートインフラストラクチャ、クラウドサーバ、コネクテッドサービス、等を用いて、ＳＡＥ規格Ｌ１の能力を拡張することができる。
　図５は、実施例１に係る車載型コンピュータシステムのアーキテクチャの例を示す。自動運転レベルが規格Ｌ１およびＬ２の場合には、安全性は「フェールセーフ」であり、アーキテクチャは規格１ｏｏ１Ｄである。自動運転レベルが規格Ｌ３～Ｌ５の場合には、安全性は「フェールオペレーショナル」であり、アーキテクチャは規格１ｏｏ２Ｄである。
　自動運転のレベルが向上すると、計算コストは増大する。実施例１に係る車載型コンピュータシステムは、ＳＡＥ規格のＡＤ／ＡＤＡＳレベルをすべてカバー可能である。車載型コンピュータシステムは、スマートインフラストラクチャ、クラウドサーバ、自律運転アプリケーション、等を利用して、車両の自律運転能力拡張のために、運転シナリオ認識および運転挙動能力を利用することができる。
　図６は、実施例１に係る車載型コンピュータシステムの機能ブロック構成の例である。車両６０２は、クラウドサーバ６０１および路側機６０３等と通信可能である。車両６０２に搭載される車載型コンピュータシステム６０４は、オンボード装置６０５と、環境センサ６０６（カメラ、レーダー、ＬｉＤＡＲ、ソナー等）と、車両センサ６０７（ＧＮＳＳ、ＩＭＵ、オドメトリ等）と、ＡＤ／ＡＤＡＳアプリケーション６０８と、監視手段６０９と、パワートレインアプリケーション６１０と、車体制御アプリケーション６１１と、シャーシ制御アプリケーション６１２と、アクチュエータ６１３（ブレーキ、スロットル、操舵、等）と、インフォテインメント手段６１４と、地図手段６１５（環境位置手段等）とを備える。
　車載型コンピュータシステム６０４は、様々な車内ＥＥ環境において構成可能である。たとえば、統合ドメインアーキテクチャ、ハイブリッドゾーン・ドメインアーキテクチャ、ゾーンアーキテクチャ、等が可能である。
　図７は、実施例１に係る車載型コンピュータシステムにおいて、複数のＥＣＵに対するプログラムの配置例である。車載型コンピュータシステムは、ＥＣＵ１～ＥＣＵ５（７０１～７０５）を備える。各ＥＣＵは、通信バス７０６～７１０を介して、少なくとも１つの他のＥＣＵと通信可能である。
　とくに図示しないが、各ＥＣＵはプロセッサおよび記憶手段を備える。プロセッサは演算手段として機能し、プログラムを実行することができる。記憶手段はプログラムを記憶してもよい。プロセッサがこのプログラムを実行することにより、ＥＣＵは以下に説明する様々な手段として機能し、これによって、車載型コンピュータシステムは本実施例において説明される機能を実現する。
　車載型コンピュータシステムは、ＥＣＵについてＥＣＵ状態を測定する測定手段ＶＬＡＳＥ（Vehicle Local Area State Estimator）を備える。測定手段ＶＬＡＳＥは、たとえばＥＣＵが所定のＶＬＡＳＥプログラムを実行することによって実現される。図７の例では、測定手段ＶＬＡＳＥはＥＣＵ１、ＥＣＵ２、ＥＣＵ４、ＥＣＵ５に配置されている。
　ＥＣＵ状態は、当該ＥＣＵにおいて実行中のプログラムを示す情報を含む。たとえば、ＥＣＵ１は認識プログラムを実行し、ＥＣＵ２は計画プログラムを実行し、ＥＣＵ３はマスターＥＣＵであり、ＥＣＵ４はアクチュエータ制御プログラムを実行し、ＥＣＵ５は表示プログラムを実行する。
　また、ＥＣＵ状態は、当該ＥＣＵにおけるプロセッサ負荷、メモリ使用量、および通信バス使用量を含んでもよい。
　車載型コンピュータシステムは、車両状態を推定する推定手段ＶＡＳＥＭを備える。図７の例では、推定手段ＶＡＳＥＭはＥＣＵ３（７０４）に配置されている。
　推定手段ＶＡＳＥＭ（Vehicle Architecture State Estimator Master）は、ＥＣＵ状態と、通信バスの接続構成とに基づき、車両状態を推定する。車両状態は、たとえばＥＣＵ状態および通信バスの接続構成を組み合わせた情報である。図７の例では、推定手段ＶＡＳＥＭはＥＣＵ４に配置されている。
　なお、ＥＣＵ３（７０４）にも測定手段ＶＬＡＳＥが配置されてもよい。または、推定手段ＶＡＳＥＭが測定手段ＶＬＡＳＥの機能を備えてもよい。
　通信バスの接続構成は、各通信バスがどのＥＣＵとどのＥＣＵとを接続しているかを示す情報を含む。たとえば、ＥＣＵ１とＥＣＵ２とは通信バス１（７０８）を介して接続されている。ＥＣＵ２とＥＣＵ３とは通信バス３（７１０）を介して接続されている。ＥＣＵ１とＥＣＵ３とは通信バス２（７０７）を介して接続されている。ＥＣＵ２とＥＣＵ４とは通信バス４（７０９）を介して接続されている。ＥＣＵ３とＥＣＵ５とは通信バス５（７０６）を介して接続されている。
　また、たとえば、ＥＣＵ１とＥＣＵ４とは直接的に通信バスによっては接続されておらず、通信バス１、ＥＣＵ２、通信バス４を介する必要がある。このような通信バスの接続構成を表す情報は、推定手段ＶＡＳＥＭが測定等により能動的に生成してもよいし、事前に各ＥＣＵの記憶手段に記憶されていてもよい。
　車載型コンピュータシステムは、管理手段ＤＲＩＭ（Dynamic Reconfiguration Indicator Master）を備える。図７の例では、管理手段ＤＲＩＭはＥＣＵ３（７０４）に配置されている。管理手段ＤＲＩＭは、更新プログラムと、更新プログラムの実行条件とを取得する。実行条件の具体例は、図１０に関連して後述する。
　車載型コンピュータシステムは、実行手段ＤＲＩＣ（Dynamic Reconfiguration Indicator Client）を備える。図７の例では、実行手段ＤＲＩＣはＥＣＵ１、ＥＣＵ２、ＥＣＵ４、ＥＣＵ５に配置されている。実行手段ＤＲＩＣは、ＥＣＵに特定のプログラムを実行させ、または終了させる。たとえばＥＣＵ２の実行手段ＤＲＩＣは、ＥＣＵ２に計画プログラムを実行させる。実行手段ＤＲＩＣは、プログラムのインストールと呼ばれる処理を行うものであってもよい。
　なお、ＥＣＵ３（７０４）にも実行手段ＤＲＩＣが配置されていてもよい。または、管理手段ＤＲＩＭが実行手段ＤＲＩＣの機能を備えていてもよい。
　図８Ａおよび図８Ｂは、実施例１における車載型コンピュータシステムの動作例を示すフローチャートである。まず管理手段ＤＲＩＭは、更新プログラムおよびその実行条件を取得する（ステップ８０１）。更新プログラムおよびその実行条件は、任意の経路で取得することができるが、たとえば事前にいずれかのＥＣＵの記憶手段に記憶しておいてもよいし、車外のコンピュータから取得してもよい。
　次に、測定手段ＶＬＡＳＥが、各ＥＣＵについてＥＣＵ状態を測定する（ステップ８０２）。測定手段ＶＬＡＳＥは、測定したＥＣＵ状態を、推定手段ＶＡＳＥＭに送信する。上述のように、ＥＣＵ状態は、当該ＥＣＵにおいて実行中のプログラムを示す情報を含むことができ、また、当該ＥＣＵにおけるプロセッサ負荷、メモリ使用量、および通信バス使用量、等を含むことができる。
　次に、推定手段ＶＡＳＥＭは、車両状態を推定し（ステップ８０３）、管理手段ＤＲＩＭに車両状態を通知する。
　次に、管理手段ＤＲＩＭは、更新プログラムに割り当てる資源を決定する（ステップ８０４）。資源は、たとえばプロセッサ負荷、メモリ使用量および通信バス使用量を含む。割り当てる資源の決定方法は、当業者が適宜設計可能である。たとえば更新プログラムに関連付けて必要な資源の量を示す情報を取得してもよい。また、車載型コンピュータシステムにおいて利用可能な資源に応じて、割り当てる資源の量を変化させてもよい。
　次に、管理手段ＤＲＩＭは、更新プログラムの実行開始（またはインストール）と、冗長プログラムの実行終了とに必要な時間を決定する（ステップ８０５）。冗長プログラムとは、更新プログラムに対して冗長なプログラムを意味する。たとえば、ある更新プログラムが、計画プログラムの機能をすべて含んでいる場合には、計画プログラムは、その更新プログラムに対する冗長プログラムとなる。
　ある更新プログラムについて、どのプログラムが冗長プログラムとなるかの決定方法は、当業者が適宜設計可能である。たとえば各プログラムにＩＤを付与しておき、あらかじめ更新プログラムに冗長プログラムのＩＤを関連付けておいてもよい。その場合には、ステップ８０１において更新プログラムとともに冗長プログラムのＩＤを取得することによって、冗長プログラムを特定することができる。または、車載型コンピュータシステムは、更新プログラムと同一種類のデータ（たとえば同一の表示装置に対するデータ）を出力するプログラムを、冗長プログラムであると決定してもよい。
　また、実行開始および実行終了に必要な時間の決定方法は、当業者が適宜設計可能である。たとえば各プログラムのサイズに応じて決定してもよいし、各プログラムに当該時間を関連付けて事前に記憶手段に記憶しておいてもよい。さらに、他に様々な情報に基づいて計算または修正されてもよい。
　次に、管理手段ＤＲＩＭは、更新プログラムの実行開始および冗長プログラムの実行終了に必要な時間が、所定の安全基準を満たすか否かを判定する（ステップ８０６）。たとえば、所定の基準時間以内に完了するか否かを判定する。更新プログラムの実行開始処理中および冗長プログラムの実行終了処理中には、各プログラムの機能が発揮されない期間が存在するため、この期間が車両の安全な制御に影響を及ぼすか否かを判断することが有益である。
　ステップ８０６の安全基準は、固定であってもよいし、各プログラムに関連付けられた基準であってもよいし、他の条件に応じて変化する基準であってもよい。たとえばその時点の車速に応じて基準が変化してもよい。たとえば、停車中または低速走行時（駐車動作の実行中等）には、各プログラムの機能が発揮されない期間が多少長くとも安全に影響を及ぼさないと考えられるので、基準時間を初期値より長くすることができるが、高速走行時（高速道路の走行中等）には各プログラムの機能が発揮されない期間が長くなると安全に影響するため、短時間で処理を完了する必要があり、したがって基準時間は初期値より短くなる。
　ステップ８０６において、必要な時間が安全基準を満たす場合には、車載型コンピュータシステムはプログラムの更新を行う（ステップ８０７）。たとえば、管理手段ＤＲＩＭが、車両状態と、更新プログラムの実行条件とに基づいて、更新プログラムを実行すべきＥＣＵ（第１ＥＣＵ。以下、「ターゲットＥＣＵ」という）を選択する。そして、選択されたターゲットＥＣＵに、更新プログラムおよび更新要求を送信する。これらを受信したターゲットＥＣＵは、実行手段ＤＲＩＣの機能により更新プログラムの実行を開始する。
　また、管理手段ＤＲＩＭは、冗長プログラムの実行を終了させる。すなわち、冗長プログラムを実行しているＥＣＵ（ターゲットＥＣＵまたは他のＥＣＵ）に、当該冗長プログラムの終了要求を送信する。終了要求を受信したＥＣＵは、実行手段ＤＲＩＣの機能により冗長プログラムの実行を終了する。これによって、不要な資源の消費が抑制される。ここで、実行手段ＤＲＩＣは、当該冗長プログラムの実行を後に再開させるために必要な情報（プログラムＩＤまたはプログラムコード等）を記憶してもよい。
　次に、測定手段ＶＬＡＳＥは、ステップ８０７における実行手段ＤＲＩＣの処理後のＥＣＵ状態を測定し、推定手段ＶＡＳＥＭに送信する（ステップ８０８）。
　次に、推定手段ＶＡＳＥＭは、更新されたＥＣＵ状態等に基づいて車両状態を推定し、管理手段ＤＲＩＭに車両状態を通知する（ステップ８０９）。
　次に、管理手段ＤＲＩＭは、更新プログラムの出力遅延制約が満たされているか否かを判定する（ステップ８１０）。出力遅延制約および判定処理の具体例は、図１０に関連して後述する。
　ステップ８１０において、更新プログラムの出力遅延制約が満たされている場合には、ターゲットＥＣＵは更新プログラムの実行を継続し、これによって、車載型コンピュータシステムは新たなＡＤＡＳモードで動作する（ステップ８１１）。
　ステップ８１１の後、実行手段ＤＲＩＣ（ターゲットＥＣＵに限らない）は、管理手段ＤＲＩＭを監視し、管理手段ＤＲＩＭの障害を検出した場合に、冗長プログラム（すなわち、管理手段ＤＲＩＭがステップ８０７において実行を終了させたプログラム）を再度実行させる（ステップ８１３）。このようにすると、障害となった管理手段ＤＲＩＭが不正に終了させた冗長プログラムの実行を再開することができる。なお、冗長プログラムを実行するＥＣＵの選択方法は、当業者が適宜設計可能であるが、たとえば当該冗長プログラムを最後に実行していたＥＣＵとすることができる。
　一方、ステップ８１０において、更新プログラムの出力遅延制約が満たされていない場合には、車載型コンピュータシステムは所定の安全処理を実行する。本実施例では、安全ＡＤＡＳモードで動作する（ステップ８１２）。安全ＡＤＡＳモードの具体的内容は、当業者が適宜設計可能である。たとえば、自動運転中の車速の最大値を、通常時の最大値よりも小さい値に制限し、これによって、出力遅延制約が満たされない場合でも安全な運転ができるように車両を制御する。
　ステップ８１３において冗長プログラムが再度実行開始された後、または、ステップ８１２の後には、車載型コンピュータシステムは以前の状態に復帰する（ステップ８１４）。ここで、復帰すべき状態（バックアップまたはチェックポイント）の決定方法および復帰のための具体的処理は、当業者が適宜設計することができる。たとえば、冗長プログラムおよび他のアプリケーションプログラムを回復または再インストールし、システムの再起動を行うことができる。
　上述のステップ８０６（図８Ａ）において、更新プログラムの実行開始および冗長プログラムの実行終了に必要な時間が、所定の安全基準を満たさない場合には、車載型コンピュータシステムは、車両を安全に停車させることが可能か否かを判定する（ステップ８１５）。この判定の具体的な内容は、公知の自動運転技術等に基づき、当業者が適宜設計可能である。たとえば、車両が走行している道路、周囲の状況、車速、等に基づいて判定することができる。
　車両を安全に停車させることが可能な場合には、車載型コンピュータシステムは、車両を安全に停車させた後に、図８Ｂのステップ８０７～８１４の処理を実行する。一方、車両を安全に停車させることが可能でない場合には、車載型コンピュータシステムは安全ＡＤＡＳモードで動作するか、または、その時点のＡＤ／ＡＤＡＳモードで継続的に動作する（ステップ８１６）。この場合には、更新プログラムは実行されない。
　図９および図１０を用いて、更新プログラムおよび冗長プログラムに関する判定処理の例を説明する。図９は、実施例１における車載型コンピュータシステムに新たな機能が追加される動作例である。図１０は、実施例１における車載型コンピュータシステムにおいて用いられる情報の例を示す。
　図９に示すように、ＥＣＵ２（９０３）が計画プログラムを実行している。ここで、計画プログラムの機能を含む、より高度なクライアントアプリケーションが車載型コンピュータシステムに入力された場合を想定する。このクライアントアプリケーションは更新プログラムであり、計画プログラムはクライアントアプリケーションに対する冗長プログラムとなる。すなわち、図示のように、クライアントアプリケーションをＯＮとし、計画プログラムがＯＦＦとすることを試みる。
　図１０に示すように、クライアントアプリケーションに関する入出力制約１００１が予め定義されている。入出力制約１００１は、実行条件の少なくとも一部を表し、入力遅延制約および出力遅延制約を含む。入力遅延制約は、たとえばデータサイズおよび最大許容遅延を含む。図１０の例では、入力遅延制約は、１Ｍバイトのサイズの画像（たとえばカメラからの生画像）が、生成後（たとえばカメラからの出力後）、５０ｍｓ以内に、クライアントアプリケーションに入力されなければならない、というものである。
　出力遅延制約は、たとえばデータサイズおよび最大許容出力周期を含む。図１０の例では、出力遅延制約は、２種類の制御情報（制御情報ＡおよびＢ）について、それぞれ１０バイトのサイズのデータが、クライアントアプリケーションから５０ｍｓ以内の周期で出力されなければならない、というものである。
　ステップ８０７におけるターゲットＥＣＵの選択処理の具体例を、以下に説明する。本例において、ステップ８０７では、更新プログラムの実行条件および通信バスの接続構成を用いてターゲットＥＣＵを選択する。更新プログラムの実行条件は、たとえば入力遅延制約を含む（さらに出力遅延制約を含んでもよい）。
　通信バスの接続構成は、たとえば入力遅延表１００２によって表される。入力遅延表１００２において、最上行は、カメラ画像（ＥＣＵ１において生成される）に関する入力遅延を表す。各列は、ＥＣＵ１から各ＥＣＵまでの入力遅延を表す。
　ＥＣＵ１からＥＣＵ１までの入力遅延は、同一ＥＣＵであるため０である。これは５０ｍｓ以内であるため、ＥＣＵ１でクライアントアプリケーションを実行すると入力遅延制約が満たされる。このため、ＥＣＵ１はターゲットＥＣＵとすることができる。
　ＥＣＵ１からＥＣＵ２までの入力遅延は、通信バス１（ＣＡＮ）を経由する場合には１０ｓである。これは５０ｍｓを超えるため、ＥＣＵ２でクライアントアプリケーションを実行する場合に、通信バス１経由で通信を行うと入力遅延制約が満たされない。一方、ＥＣＵ１からＥＣＵ２までの入力遅延は、通信バス２（イーサネット（登録商標））および通信バス３（イーサネット）を経由する場合には２０ｍｓである。これは５０ｍｓ以内であるため、ＥＣＵ２でクライアントアプリケーションを実行する場合に、通信バス２および３経由で通信を行うと入力遅延制約が満たされる。このため、ＥＣＵ２は、特定の通信ルートを用いる場合に限り、ターゲットＥＣＵとすることができる。
　他のＥＣＵに係る入力遅延についても同様であるため説明を省略するが、ＥＣＵ３およびＥＣＵ５は、特定の通信ルートを用いる場合に限りターゲットＥＣＵとすることができ、ＥＣＵ４はいずれの通信ルートでも入力遅延制約が満たされないためターゲットＥＣＵとすることができない。このような判定処理により、適切なターゲットＥＣＵおよび通信ルートの選択が可能になる。
　なお、通信ルートを限定する場合の具体的処理は、当業者が適宜設計することができる。たとえば、管理手段ＤＲＩＭは各ＥＣＵに対してクライアントアプリケーションの情報の伝送ルートを通知し、各ＥＣＵはこれに従って情報の送受信を行う。
　この例のように、複数のＥＣＵをターゲットＥＣＵとすることができる場合には、どのＥＣＵをターゲットとして選択するかの判定基準として、ＥＣＵ状態を用いてもよい。たとえば、各ＥＣＵについて、プロセッサ負荷、メモリ使用量、および通信バス使用量に基づいて総合負荷を算出し、この総合負荷が最も低いＥＣＵをターゲットＥＣＵとして選択してもよい。総合負荷を算出する方法（関数等）は、当業者が適宜設計可能である。たとえばプロセッサ負荷、メモリ使用量、および通信バス使用量にそれぞれ重みを乗算したものの総和を総合負荷としてもよい。このような判定処理により、適切なターゲットＥＣＵの選択が可能になる。
　入力遅延表１００２は、たとえば通信時間表１００３に基づいて生成することができる。通信時間表は、データサイズごとに、各通信バスを介する通信処理に要する時間を表す。または、入力遅延表１００２は、事前に作成され記憶されていてもよい。または、入力遅延表１００２は、更新プログラムに関連付けて取得されてもよい。
　制御設計１００４は、クライアントアプリケーションの入出力の概要を示す。認識プログラムがカメラ画像を生成し、カメラ画像がクライアントアプリケーションに入力され、クライアントアプリケーションはカメラ画像に基づいて出力情報を生成し、この出力情報が操作プログラムおよび表示プログラムに入力される。
　出力判定例１００５は、ＥＣＵ２をターゲットＥＣＵとした場合の出力遅延制約の達成状況（ステップ８０１において、管理手段ＤＲＩＭによって測定される）を示す。この例では、制御情報ＡおよびＢ双方がＥＣＵ２から５０ｍｓの周期で出力されている。周期がいずれも５０ｍｓ以内であるため、出力遅延制約は満たされていると判定される。
　なお、出力判定例１００６は、ＥＣＵ２をターゲットＥＣＵとした場合の、ＥＣＵ３における出力遅延の状況を示す。ＥＣＵ３では操作プログラムが実行されており、制御情報Ａは不要であり、制御情報Ｂの出力周期は１００ｍｓである。
　同様に、出力判定例１００７は、ＥＣＵ２をターゲットＥＣＵとした場合の、ＥＣＵ５における出力遅延の状況を示す。ＥＣＵ３では表示プログラムが実行されており、制御情報Ａの出力周期は１０．２ｓであり、制御情報Ａは不要である。
　図１１は、実施例１における管理手段ＤＲＩＭと実行手段ＤＲＩＣとの関係の例を示す。管理手段ＤＲＩＭは、更新プログラムをＲＡＭ（ランダムアクセスメモリ）に記憶する。また、管理手段ＤＲＩＭは、所定の周期で、ハートビート信号を各実行手段ＤＲＩＣ（より具体的には、各実行手段ＤＲＩＣを実現している各ＥＣＵ）に送信する。
　各実行手段ＤＲＩＣは、ハートビート信号の欠如に基づき、管理手段ＤＲＩＭの障害を検出する。ここで「ハートビート信号の欠如」とは、たとえばハートビート信号が所定のタイミングで受信されないこと、または、あるハートビート信号を受信してから次のハートビート信号を受信するまでの時間が所定の閾値を超えたことを意味する。
　各実行手段ＤＲＩＣは、管理手段ＤＲＩＭの障害を検出した場合に、検出以降に管理手段ＤＲＩＭから受信した信号を無視する。また、各実行手段ＤＲＩＣは、管理手段ＤＲＩＭの障害を検知した場合に、他の実行手段ＤＲＩＣに障害情報を送信する。各実行手段ＤＲＩＣは、障害情報を受信した場合に、受信以降に管理手段ＤＲＩＭから受信した信号を無視する。このようにすると、管理手段ＤＲＩＭに障害が発生した場合に、それ以降に送信される誤った制御情報による車載型コンピュータシステムの誤動作が抑制される。
　なお、図１０の例において、出力遅延制約は出力周期を表すが、変形例として、許容遅延を表してもよい。たとえば、図１０の例では、出力遅延制約は、２種類の制御情報（制御情報ＡおよびＢ）について、それぞれ１０バイトのサイズのデータが、クライアントアプリケーションから５０ｍｓ以内に出力されなければならない、というものであってもよい。
　以上説明するように、実施例１に係る車載型コンピュータシステム、および、これを含む自動運転支援システムによれば、車載型コンピュータシステムのプログラム更新によって新たな機能を追加することができる。
　上記は例であり、当業者は添付の特許請求の範囲から逸脱することなく適切な変形を加えることができる。
　１０１…環境認識センサシステム
　１０２…環境認識システム
　１０３…計画システム
　１０４…無線通信システム
　１０５…物理ネットワーク通信システム
　１０６…作用システム
　１０７…車体・シャーシ制御システム
　１０８…インフォテインメントシステム
　１０９…ヒューマンマシンインタフェースシステム
　１１０…ドライバー監視システム
　１１１…車両制御システム
　１１２…Ｖ２Ｘシステム
　１１３…ドライバーインテンション
　１１４…機能不全監視システム
　１１５…パワートレインシステム
　２０１，２０８…路側機（車外のコンピュータ）
　２０２，２０４，２０５，２０９…車両
　２０３，２０６…スマートインフラストラクチャ（車外のコンピュータ）
　２０７…クラウドサーバ（車外のコンピュータ）
　２１１…路面（車外のコンピュータ）
　２１２…人工衛星（車外のコンピュータ）
　３０１…路側機（車外のコンピュータ）
　３０２，３０３…スマートインフラストラクチャ（車外のコンピュータ）
　３０４…路面（車外のコンピュータ）
　３０５…クラウドサーバ（車外のコンピュータ）
　３０６…人工衛星（車外のコンピュータ）
　３０７～３０９…車両
　３１０…アプリケーションインテグレータ
　４０１…規格Ｌ１
　４０２…規格Ｌ２
　４０３～４０８…センサ
　４０９…略語
　６０１…クラウドサーバ
　６０２…車両
　６０３…路側機
　６０４…車載型コンピュータシステム
　６０５…オンボード装置
　６０６…環境センサ
　６０７…車両センサ
　６０８…ＡＤ／ＡＤＡＳアプリケーション
　６０９…監視手段
　６１０…パワートレインアプリケーション
　６１１…車体制御アプリケーション
　６１２…シャーシ制御アプリケーション
　６１３…アクチュエータ
　６１４…インフォテインメント手段
　６１５…地図手段
　７０１～７０５　ＥＣＵ
　７０６～７１０…通信バス
　９０１，９０３，９０４，９０９，９１１　ＥＣＵ
　９０５～９０８，９１０…通信バス
　１００１…入出力制約（入力遅延制約および出力遅延制約）
　１００２…入力遅延表
　１００３…通信時間表
　１００４…制御設計
　１００５～１００７…出力判定例
　ＤＲＩＣ…実行手段
　ＤＲＩＭ…管理手段
　ＶＡＳＥＭ…推定手段
　ＶＬＡＳＥ…測定手段
　本明細書で引用した全ての刊行物、特許および特許出願はそのまま引用により本明細書に組み入れられるものとする。

Claims (10)

  1. 　車外のコンピュータと通信可能な、車載型コンピュータシステムであって、
    　前記車載型コンピュータシステムは複数のＥＣＵを備え、各ＥＣＵは通信バスを介して少なくとも１つの他のＥＣＵと通信可能であり、
    　前記車載型コンピュータシステムは、
    　前記ＥＣＵについて、ＥＣＵ状態を測定する測定手段と、
    　前記ＥＣＵ状態と、前記通信バスの接続構成とに基づき、車両状態を推定する推定手段と、
    　更新プログラムと、前記更新プログラムの実行条件とを取得する、管理手段と、
    を備え、
    　前記管理手段は、前記車両状態と、前記実行条件とに基づいて、前記更新プログラムを実行すべき第１ＥＣＵを選択し、
    　前記第１ＥＣＵは、前記更新プログラムを実行し、
    　前記管理手段は、前記更新プログラムの出力遅延制約が満たされているか否かを判定し、
    　前記管理手段は、前記更新プログラムに対して冗長な冗長プログラムの実行を終了させる、
    車載型コンピュータシステム。
  2. 　前記ＥＣＵは、前記管理手段の障害を検出した場合に、前記管理手段が実行を終了させた前記冗長プログラムを実行させる、請求項１に記載の車載型コンピュータシステム。
  3. 　前記管理手段は、前記更新プログラムをＲＡＭに記憶し、ハートビート信号を各前記ＥＣＵに送信し、
    　各前記ＥＣＵは、前記ハートビート信号の欠如に基づき、前記管理手段の障害を検出し、
    　各前記ＥＣＵは、前記障害を検出した場合に、検出以降に前記管理手段から受信した信号を無視し、
    　各前記ＥＣＵは、前記障害を検知した場合に、他の前記ＥＣＵに障害情報を送信し、
    　各前記ＥＣＵは、前記障害情報を受信した場合に、受信以降に前記管理手段から受信した信号を無視する、
    請求項１に記載の車載型コンピュータシステム。
  4. 　前記ＥＣＵ状態は、当該ＥＣＵにおいて実行中のプログラムを示す情報を含む、請求項１に記載の車載型コンピュータシステム。
  5. 　前記ＥＣＵ状態は、当該ＥＣＵにおけるプロセッサ負荷、メモリ使用量、および通信バス使用量を含む、請求項１に記載の車載型コンピュータシステム。
  6. 　前記更新プログラムの前記実行条件は、前記更新プログラムの入力遅延制約を含む、請求項１に記載の車載型コンピュータシステム。
  7. 　前記更新プログラムの前記出力遅延制約が満たされていない場合に、前記車載型コンピュータシステムは所定の安全処理を実行する、請求項１に記載の車載型コンピュータシステム。
  8. 　前記管理手段は、前記更新プログラムの実行開始および前記冗長プログラムの実行終了に必要な時間が、所定の安全基準を満たすか否かを判定する、請求項１に記載の車載型コンピュータシステム。
  9. 　前記安全基準は車速に応じて変化する、請求項８に記載の車載型コンピュータシステム。
  10. 　請求項１に記載の車載型コンピュータシステムと、前記車外のコンピュータとを備える、自動運転支援システム。
PCT/JP2021/033760 2021-02-15 2021-09-14 車載型コンピュータシステムおよび自動運転支援システム WO2022172498A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE112021006067.8T DE112021006067T5 (de) 2021-02-15 2021-09-14 Bordcomputersystem und assistenzsystem für autonomes fahren
CN202180090860.7A CN116762058A (zh) 2021-02-15 2021-09-14 车载型计算机系统和自动驾驶辅助系统

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021-021914 2021-02-15
JP2021021914A JP2022124258A (ja) 2021-02-15 2021-02-15 車載型コンピュータシステムおよび自動運転支援システム

Publications (1)

Publication Number Publication Date
WO2022172498A1 true WO2022172498A1 (ja) 2022-08-18

Family

ID=82837629

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/033760 WO2022172498A1 (ja) 2021-02-15 2021-09-14 車載型コンピュータシステムおよび自動運転支援システム

Country Status (4)

Country Link
JP (1) JP2022124258A (ja)
CN (1) CN116762058A (ja)
DE (1) DE112021006067T5 (ja)
WO (1) WO2022172498A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018081470A (ja) * 2016-11-16 2018-05-24 三菱電機株式会社 プログラムの更新制御システムおよびプログラムの更新制御方法
WO2018198783A1 (ja) * 2017-04-27 2018-11-01 日立オートモティブシステムズ株式会社 車両制御システム検証手法および検証装置および制御装置
JP2019026250A (ja) * 2017-07-25 2019-02-21 トヨタ自動車株式会社 車両のａｄａｓ機能を更新する方法
WO2020095645A1 (ja) * 2018-11-06 2020-05-14 株式会社オートネットワーク技術研究所 プログラム更新システム及び更新処理プログラム

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10678454B2 (en) 2018-08-10 2020-06-09 Denso Corporation Vehicle information communication system
JP2021021914A (ja) 2019-07-30 2021-02-18 怡利電子工業股▲ふん▼有限公司 裸眼３ｄ反射型拡散片ヘッドアップディスプレイ装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018081470A (ja) * 2016-11-16 2018-05-24 三菱電機株式会社 プログラムの更新制御システムおよびプログラムの更新制御方法
WO2018198783A1 (ja) * 2017-04-27 2018-11-01 日立オートモティブシステムズ株式会社 車両制御システム検証手法および検証装置および制御装置
JP2019026250A (ja) * 2017-07-25 2019-02-21 トヨタ自動車株式会社 車両のａｄａｓ機能を更新する方法
WO2020095645A1 (ja) * 2018-11-06 2020-05-14 株式会社オートネットワーク技術研究所 プログラム更新システム及び更新処理プログラム

Also Published As

Publication number Publication date
CN116762058A (zh) 2023-09-15
DE112021006067T5 (de) 2023-09-07
JP2022124258A (ja) 2022-08-25

Similar Documents

Publication Publication Date Title
CN109421630B (zh) 用于监测自主车辆的健康的控制器架构
EP3379417B1 (en) Processing device and vehicle control system
WO2017064944A1 (ja) 自動運転システム、自動運転制御方法、データｅｃｕおよび自動運転ｅｃｕ
US20200135032A1 (en) Systems and methods for managing communications between vehicles
US20190066406A1 (en) Method and apparatus for monitoring a vehicle
CN113895448B (zh) 域控制器间的协同交互控制架构及其控制方法
KR101802858B1 (ko) 자동차용 통합데이터 처리 제어 시스템 및 방법
CN111008121A (zh) 车辆软件检查
US20210237750A1 (en) System for controlling a self-driving vehicle
JP6918873B2 (ja) 車両運行状態監視方法、装置、及び機器
CN114162068B (zh) 车辆智能驾驶功能的管理方法、装置以及车辆
US20210197812A1 (en) Vehicle control apparatus, vehicle, and vehicle control method
US11318953B2 (en) Fault-tolerant embedded automotive applications through cloud computing
WO2022172498A1 (ja) 車載型コンピュータシステムおよび自動運転支援システム
US20230394443A1 (en) Vehicle management system
CN113272195A (zh) 用于智能网联车辆的控制系统及控制方法
WO2022259655A1 (ja) 車両制御装置および車両制御システム
JP6421403B1 (ja) 車載計算装置、車両およびシステム
WO2021256014A1 (ja) 車両制御システム
Kron et al. Motion control solutions for automated driving systems at BMW
US20230267770A1 (en) Vehicle and autonomous driving kit
US11604679B2 (en) Dynamic workload shifting within a connected vehicle
US20230143376A1 (en) Vehicle platform and vehicle control interface box
US20230271628A1 (en) Distributed processing of vehicle sensor data
WO2024043011A1 (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: 21925746

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 112021006067

Country of ref document: DE

Ref document number: 202180090860.7

Country of ref document: CN

122 Ep: pct application non-entry in european phase

Ref document number: 21925746

Country of ref document: EP

Kind code of ref document: A1