WO2022153591A1 - 車両制御装置、車両システム、更新システム - Google Patents

車両制御装置、車両システム、更新システム Download PDF

Info

Publication number
WO2022153591A1
WO2022153591A1 PCT/JP2021/032908 JP2021032908W WO2022153591A1 WO 2022153591 A1 WO2022153591 A1 WO 2022153591A1 JP 2021032908 W JP2021032908 W JP 2021032908W WO 2022153591 A1 WO2022153591 A1 WO 2022153591A1
Authority
WO
WIPO (PCT)
Prior art keywords
program
vehicle
control device
data
vehicle control
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/JP2021/032908
Other languages
English (en)
French (fr)
Inventor
哲也 山田
幹雄 片岡
圭汰 仲澤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Astemo Ltd
Original Assignee
Hitachi Astemo Ltd
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 Hitachi Astemo Ltd filed Critical Hitachi Astemo Ltd
Priority to DE112021005187.3T priority Critical patent/DE112021005187T5/de
Priority to US18/253,790 priority patent/US12585452B2/en
Publication of WO2022153591A1 publication Critical patent/WO2022153591A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/079—Root cause analysis, i.e. error or fault diagnosis
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station

Definitions

  • the present invention relates to a technique for updating a program executed by a vehicle control device that controls the operation of a vehicle.
  • the vehicle control device (Electronic Control Unit: ECU) that controls the vehicle is interconnected in the in-vehicle network.
  • ECU Electronic Control Unit
  • FOTA Wireless On The Air
  • Examples of transmitting data from the center to the vehicle include FOTA (Firmware On The Air) that updates the ECU program, update of map data of car navigation, music data distribution, and the like.
  • An example of transmitting data from a vehicle to a center is to upload vehicle parts diagnostic information to the center, contact the dealer with the diagnostic information on the center side, and replace vehicle parts (parts management).
  • Patent Document 1 describes an example in which the traveling status of a vehicle is collected in the vehicle and the collected log is uploaded to the center.
  • the vehicle collection function is changed by distributing a data collection program from the center to the vehicle.
  • the log collection conditions, the log collection frequency, the upload transmission frequency, and the like can be changed.
  • information that has not been collected by the vehicle can be transmitted to the center by adding the application function of the ECU by OTA.
  • This allows the vehicle to collect these logs, send them to the center, and the center to analyze the information, for example, in applications such as the route information of a courier company and the operation information of each customer of a taxi. ..
  • the function required for the application to output the new information may be insufficient.
  • both the ECU in which the application is mounted and another ECU in which the data collection function is mounted are updated by the OTA.
  • the present invention has been made in view of the above problems, and it is possible to easily manage the software state of the ECU and to match the management information of the software state in each of the vehicle and the center to create an ECU application and a data collection program.
  • the purpose is to provide program update technology that can be updated in cooperation.
  • the vehicle control device aggregates the first update state of the first program executed by the vehicle control device and the second update state of the second program executed by the second vehicle control device into the update server.
  • the update version program corresponding to the first update state and the update version program corresponding to the second update state are received from the update server and the update process is executed.
  • the vehicle control device According to the vehicle control device according to the present invention, it is possible to collectively manage the update status of the software installed in each vehicle control device. Furthermore, the application program corresponding to the update status and the data collection program can be linked and updated.
  • FIG. It is a system block diagram of the update system which concerns on Embodiment 1.
  • FIG. It is a block diagram of the vehicle system included in the vehicle 1. It is a flowchart explaining the procedure which ECU 13 collects data from each ECU. An example of config data 1382 is shown. It is a figure explaining the procedure of creating the config data 1382. It is a block diagram of the data center 2. It is a flowchart explaining the procedure which a data center 2 updates a collection program 1371 and an arithmetic program.
  • FIG. 1 is a system configuration diagram of the update system according to the first embodiment.
  • the update system is a system that updates a program executed by the ECU mounted on the vehicle 1.
  • the update system is configured so that the vehicle 1, the data center 2, and the mobile phone 3 can communicate with each other via the base station 4.
  • the driver of the vehicle 1 can customize the data items to be collected on the vehicle 1 via the mobile phone 3.
  • the data center 2 is composed of, for example, a server computer.
  • the driver specifies which data of the vehicle 1 to collect on the mobile phone 3 for applications such as marketing and telematics insurance.
  • the collection service unit 21 aggregates the data collection items specified on the mobile phone 3.
  • the collection service unit 21 passes the collection requirements corresponding to the collection items to the OTA service unit 23.
  • the OTA service unit 23 analyzes the collection requirements and creates a data collection program and an ECU application (hereinafter referred to as an arithmetic program) corresponding to the vehicle type of the vehicle 1 from the OTA program database 24.
  • the OTA service unit 23 distributes the created program to the vehicle 1 by OTA.
  • the log 22 is data collected from the vehicle, and this log is provided and utilized for marketing and telematics insurance service applications.
  • the vehicle 1 has a communication unit 12 (TCU), an ECU 13, and an ECU 14 mounted on the in-vehicle network 11.
  • the ECU 13 can collect various data of the vehicle 1 by the collection function unit 131.
  • the ECU 14 implements an arithmetic program that implements applications such as infotainment and car navigation.
  • the program executed by each ECU is updated by the OTA function of the data center 2.
  • the ECU 14 calculates travel route information under certain conditions and outputs it on the in-vehicle network 11.
  • the ECU 13 records the travel route information every minute and transmits it to the data center 2 every three hours.
  • the in-vehicle network 11 is a communication network such as a CAN (Control Area Network) bus.
  • FIG. 2 is a configuration diagram of a vehicle system included in the vehicle 1.
  • the vehicle system is configured by connecting a communication unit 12, an ECU 13, an ECU 14, an ECU 15, an ECU 16 and the like on an in-vehicle network 11 (for example, a CAN network).
  • an in-vehicle network 11 for example, a CAN network
  • the ECU 13 collects the software update status of each ECU and also collects data items representing the status of the vehicle 1.
  • the ECU 13 includes an interface unit 132 and a collection function unit 131.
  • the interface unit 132 is a communication interface that communicates with another device via the in-vehicle network 11.
  • the collection function unit 131 includes the following.
  • the collection unit 1331 collects data on the in-vehicle network 11.
  • the collection log 1332 is a collection of data collected by the collection unit 1331.
  • the calculation unit 1341 processes and calculates the log collected by the collection unit 1331 based on a specific format and conditions.
  • the log 1342 is a collection of calculation results by the calculation unit 1341, and is data to be transmitted to the data center 2.
  • the output unit 135 outputs the log 1342 at a specific frequency and cycle, and the RAM (Random Access Memory) 136 temporarily stores the data.
  • the non-volatile ROM (Read Only Memory) 137 stores programs and data even after the power of the ECU 13 is cut off.
  • the non-volatile ROM 137 stores the collection program 1371 and the arithmetic program 1372.
  • the collection program 1371 is a program that implements a collection method and a data output method.
  • the arithmetic program 1372 is a program that implements data format conversion, arithmetic procedures, and the like.
  • the configuration data 1382 (hereinafter abbreviated as config data 1382) describes an update state such as a software version of all ECUs in the vehicle 1.
  • the diagnostic management unit 1381 collects config data 1382 from each ECU.
  • the collected log, log, and config data are stored in a means for storing the data as non-volatile data so that the contents are retained even after the power of the ECU 13 is cut off, such as an SD card.
  • the ECU 14 includes an interface unit 141 with the in-vehicle network 11, a calculation unit 142, a RAM 143, a non-volatile ROM 144, and a diagnostic unit 145.
  • the non-volatile ROM 144 stores an arithmetic program 1441 that implements an application provided by the ECU 14.
  • the diagnosis unit 145 aggregates failures and information in the ECU 14 and responds in response to a failure command.
  • the diagnostic management unit 1381 also has the same function as the diagnostic unit 145.
  • the ROM provided in each ECU shall be a double bank.
  • the double bank is a mechanism in which two program areas are prepared, one surface is activated and used, the remaining one surface is rewritten by OTA, and then the effective surface is switched.
  • the arithmetic programs 1372 and 1441 and the collection program 1371 are omitted in FIG. 2, but have a double bank configuration.
  • FIG. 3 is a flowchart illustrating a procedure in which the ECU 13 collects data from each ECU.
  • Each of the ECU 14, the ECU 15, and the ECU 16 executes an arithmetic program mounted on the ECU 14, and outputs the arithmetic result (processing result) to the in-vehicle network 11 (S11).
  • the collection unit 1331 collects data on the in-vehicle network 11 by executing the collection program 1371 and accumulates the collection log 1332 (S12).
  • the calculation unit 1341 executes the calculation program 1372 to perform format conversion and calculation on the collection log 1332, and generates the log 1342 (S13).
  • the output unit 135 transmits the log 1342 to the data center 2 at the transmission frequency described in the collection rule (S14).
  • Each of the ECUs 13 to 16 is provided with a calculation unit (calculation program).
  • a calculation unit calculation program.
  • the software in the vehicle 1 is centrally managed by the ECU 13.
  • the config data 1382 is data that holds the centralized management information.
  • FIG. 4 shows an example of config data 1382.
  • FIG. 4 holds an ECU hard ID, a program ID, a CAN database number, a free CAN ID, and a free ROM capacity.
  • CAN ID may be consumed by outputting new CAN data items depending on the function.
  • the free ROM capacity consumed by updating the program also fluctuates. Therefore, in FIG. 4, it was decided to retain the free CANID and the free ROM capacity. Based on these data items, it is possible to determine whether or not a new program can be installed.
  • FIG. 5 is a diagram illustrating a procedure for creating config data 1382.
  • the diagnostic management unit 1381 includes a diagnostic CAN command map 1383 that describes diagnostic commands for inquiring the software update status to all ECUs (ECUs 14 to 16 in FIG. 5) in the vehicle 1.
  • the diagnostic management unit 1381 sequentially issues diagnostic commands 1384 on the in-vehicle network 11 based on the diagnostic CAN command map 1383.
  • the diagnosis unit 145 of the target ECU (for example, ECU 14) creates software configuration information as shown in FIG. 4 in the same manner as the failure information, and returns the software configuration information to the ECU 13 as a response to the diagnosis command 1384.
  • the diagnostic management unit 1381 can similarly create config data 1382 by collecting software configuration information from all ECUs.
  • the content of the diagnostic command may differ for each ECU, so it may be defined for each ECU.
  • the destination information of each ECU may be described together with the diagnostic command.
  • the diagnostic command does not necessarily have to be newly developed in order to implement the present invention, and a command for inquiring about the software version, free ROM space, etc. may be diverted in the existing failure diagnosis procedure.
  • the conventional diagnostic command is for diagnosing each ECU individually
  • the diagnostic command in the present invention is used not only for the conventional diagnosis but also for collecting config data 1382. Is different.
  • FIG. 6 is a configuration diagram of the data center 2.
  • the data center 2 includes a communication unit 25, a collection service unit 21, and an OTA service unit 23 that communicate with other devices via the base station 4.
  • the collection service unit 21 specifies the requirements required by the function of collecting the data items based on the data collection items specified by the driver on the mobile phone 3.
  • the collection service unit 21 includes a collection server unit 211, a customer database 212, a vehicle model function database 213, a collection requirement unit 214, a log analysis unit 215, and an analysis result 216.
  • the customer database 212 manages the basic information of the customer (driver using the mobile phone 3 in FIG. 1) and the collection items set in the past.
  • the vehicle type function database 213 holds a unique collection function ID for both the data items that can be collected as standard for each vehicle type and the data items that can be collected by expansion.
  • the collection server unit 211 operates as a WEB server accessed by the collection application 31 of the mobile phone 3.
  • the driver specifies the vehicle type of the vehicle 1 on the mobile phone 3 and inquires the data center 2 about the data items that can be collected.
  • the collection server unit 211 refers to the vehicle type function database 213 in response to a request from the mobile phone 3 and responds with a list of data items that can be collected by the vehicle 1 as standard and data items that can be collected by expansion.
  • the driver specifies the data items to be collected in the vehicle 1 on the mobile phone 3.
  • the collection requirement unit 214 acquires a collection function ID capable of collecting data items specified by the driver from the vehicle model function database 213.
  • the collection requirement unit 214 outputs the collection function ID to the OTA service unit 23 together with the customer ID and the vehicle model ID of the driver stored in the customer database 212.
  • the log 22 is a collection of log data transferred from the vehicle.
  • the log analysis unit 215 analyzes the log 22 and outputs the analysis result 216.
  • the analysis result 216 can be passed to a service that requires customer analysis, such as a marketing service or a telematic insurance service, and the analysis result 216 can be utilized in those services.
  • the OTA service department 23 distributes the updated version program to the vehicle 1.
  • the OTA service unit 23 includes a collection request analysis unit 231, a config data 232, a vehicle ECU software database 233, an OTA program generation unit 234, an OTA program database 24, a customer database 236, and an OTA distribution unit 237.
  • the config data 232 is the config data 1382 held by the vehicle 1 received from the vehicle 1.
  • the vehicle ECU software database 233 holds data items that can be collected for each software version of each ECU included in the vehicle 1.
  • the collection program 1371 retains collectable data items for each version of the collection program 1371.
  • data items that can be output to the in-vehicle network 11 are stored for each version of the calculation program.
  • the collection request analysis unit 231 identifies a function capable of collecting data items desired by the driver based on the collection function ID received from the collection service unit 21.
  • the collection request analysis unit 231 can collect the data items desired by the driver based on the collection function ID and the program ID of each ECU held by the config data 232 (both the collection program 1371 and the calculation program). ),
  • the program ID is acquired from the vehicle ECU software database 233.
  • the collection request analysis unit 231 outputs the acquired ID of each program to the OTA program generation unit 234.
  • the OTA program database 24 holds each version of the program (both the collection program 1371 and the arithmetic program). Each version of each program is uniquely identified by the program ID.
  • the program is not necessarily a complete program, but may be a module or the like that implements a specific function or the like.
  • the OTA program generation unit 234 acquires an updated version of each program by referring to the OTA program database 24 using the ID of the collection program 1371 and the ID of the arithmetic program of each ECU as the program ID, and updates the update.
  • the version is used to generate a program to be delivered to vehicle 1 by OTA.
  • the OTA program database 24 holds a program module, the program to be distributed to the vehicle 1 may be generated by combining the modules.
  • the customer database 236 holds security information (for example, an electronic signature) for each driver.
  • the OTA distribution unit 237 refers to the customer database 236, adds a security mechanism corresponding to the driver of the vehicle 1, and then distributes the program generated by the OTA program generation unit 234 to the vehicle 1.
  • FIG. 7 is a flowchart illustrating a procedure in which the data center 2 updates the collection program 1371 and the arithmetic program. Each step of FIG. 7 will be described below.
  • FIG. 7 Step S701
  • the driver of the vehicle 1 uses the collection application 31 of the mobile phone 3 to specify data items to be collected by the vehicle 1. Collection conditions such as collection time intervals can also be specified.
  • Collection conditions such as collection time intervals can also be specified.
  • the data items and collection conditions are collectively referred to as collection conditions below.
  • the collection server unit 211 acquires collection conditions from the mobile phone 3.
  • the collection requirement unit 214 identifies a collection function ID capable of collecting the data item specified by the collection condition, and outputs the customer information and the collection function ID to the OTA service unit 23.
  • Steps S703 to S704 The collection request analysis unit 231 identifies the vehicle 1 from the customer information and requests the vehicle 1 to transfer the config data 1382 to the data center 2 (S703).
  • the collection function unit 131 transfers the latest config data 1382 in the vehicle 1 to the data center 2 (S704). As a result, the config data 1382 held by the vehicle 1 and the config data 232 held by the data center 2 match.
  • the collection request analysis unit 231 acquires the program ID of the collection program 1371 and the program ID of the calculation program of each ECU from the vehicle ECU software database 233 based on the collection function ID and the config data 232.
  • the collection request analysis unit 231 transmits these program IDs to the OTA program generation unit 234.
  • the OTA program generation unit 234 creates a program (updated version of each program) to be distributed by OTA by referring to the OTA program database 24 based on the program ID of the collection program 1371 and the program ID of the arithmetic program of each ECU. ..
  • the OTA program may be an all-area update or a differential update.
  • Step S707 The OTA distribution unit 237 simultaneously distributes the updated version of the collection program 1371 and the calculation program of each ECU to the vehicle 1 by the OTA function.
  • FIG. 7 Step S708
  • Each ECU in the vehicle 1 updates its software by using the updated version program distributed by the OTA function.
  • the collection function unit 131 updates the config data 1382.
  • the diagnostic management unit 1381 periodically updates the config data 1382 separately from this step.
  • Steps S709 to S710 The collection function unit 131 transmits the collected log to the collection server unit 211 (S709).
  • the log analysis unit 215 analyzes the collected logs and accumulates the analysis results (S710).
  • the ECU 13 collects config data 1382 that describes the update state of the program included in each ECU, and acquires an updated version program corresponding to each update state described in the config data 1382 from the data center 2. Then update the program with the updated program. Other ECUs also update the calculation program by the updated version program received from the same data center 2. Appropriate program updates are realized by managing software states such as software versions of all ECUs mounted on the vehicle 1 and free ROM space in the vehicle 1 and the data center 2 in a consistent manner. Further, when the software state of all the ECUs is collectively managed by the ECU 13, the calculation program of each ECU and the collection program 1371 of the ECU 13 can be generated in cooperation with each other.
  • the ECU 13 issues a diagnostic command 1384 on the in-vehicle network 11 based on the diagnostic CAN command map 1383, and the ECU that receives the diagnostic command 1384 returns the software status as a response to this.
  • the software state of each ECU can be aggregated as config data 1382 on the ECU 13.
  • the collection program 1371 determines at least one of the frequency of collecting data from each ECU, the data items to be collected, and the frequency of transmitting the collected data to the data center 2. It is configured so that it can be changed for each version of. As a result, the user can freely customize the data collection process performed in the vehicle 1. For example, it is possible to cancel the function suppressed in the current ECU included in the vehicle 1 or add a new function, and then add a collection condition linked to the function. By customizing and acquiring the information of the vehicle 1, various information about the vehicle 1 can be utilized in an external service such as a telematics insurance service or a marketing service.
  • an external service such as a telematics insurance service or a marketing service.
  • the user of the vehicle 1 customizes the data collection items via the mobile phone 3, and the data center 2 can collect the customized data items. Is generated and transmitted to the vehicle 1.
  • the user can freely customize the data items to be collected on the vehicle 1 while updating the calculation program of each ECU included in the vehicle 1 and the collection program 1371 in cooperation with each other.
  • Collection program 1371 and calculation program on any one ECU (Update example 2) Collection program 1371 and calculation program on ECU 13 (Update example 3) Collection program 1371 (Update example 4) Collection program 1371 and calculation program on any two or more ECUs (a part of the ECU on vehicle 1)
  • Each ECU can suppress the program update when the program cannot be updated, for example, when the free space of the ROM is insufficient.
  • the vehicle 1 notifies the data center 2 to that effect.
  • the OTA service unit 23 can notify the user of the mobile phone 3 to that effect via the collection service unit 21.
  • the present invention is not limited to the above embodiment, and includes various modifications.
  • the above-described embodiment has been described in detail in order to explain the present invention in an easy-to-understand manner, and is not necessarily limited to the one including all the described configurations.
  • the collection program 1371 is updated for the ECU 13, and the calculation program is updated in conjunction with the other ECU (example: ECU 14).
  • the format of the data items to be collected may be changed by updating the arithmetic programs of other ECUs, so it is necessary to change the processing such as format conversion by the arithmetic program 1372.
  • the arithmetic program 1372 may be updated in conjunction with the collection program 1371 and each arithmetic program.
  • the diagnostic management unit 1381 collects the config data 1382 from the ECU 14, and the collection unit 1331 and the collection program 1371 collect various data items (vehicle data) of the vehicle 1. May be aggregated as one program.
  • one program may be implemented as the collection function unit 131, and the program may collect config data 1382 and vehicle data. That is, if the ECU 13 executes these processes, the division of roles between the programs may be arbitrary.
  • the data item collected by the collection function unit 131 is not limited to the software state of the ECU included in the vehicle 1, and may be any data item representing the state of the vehicle 1.
  • data representing the state of a device such as a sensor or an actuator controlled by the target ECU can be collected from the target ECU.
  • information such as the traveling route of the vehicle 1 can be collected from the car navigation ECU, and information on the driver's preference can be collected from the infotainment ECU.
  • At least one of the calculation program and the collection program 1371 may be different for each vehicle type (manufacturer, model number, etc.) of the vehicle 1.
  • the data items and the like that can be collected for each vehicle type should be defined in the vehicle type function database 213, and the vehicle ECU software database 233 should be configured so that the program ID corresponding to the collection function ID differs for each vehicle type. Just do it.
  • the data items that can be collected may differ depending on the vehicle type of the vehicle 1.
  • constraints on data collection may be defined, such as data items that cannot be collected at the same time.
  • This constraint condition may be defined in, for example, the vehicle type function database 213.
  • the data center 2 when the data center 2 distributes the updated program of each ECU to the vehicle 1, the data center 2 may directly distribute the updated program to each ECU, or the data center 2 distributes only the destination ECU.
  • the gateway device in the vehicle 1 may receive the updated version program of each ECU. In the latter case, the updated program will be distributed to each ECU via the gateway device.
  • the ECU that collects various data of the vehicle 1 may be a control device that controls any function of the vehicle 1, and does not necessarily have a role of controlling the other ECUs. It does not have to be an ECU.
  • each arithmetic function unit included in each ECU or data center 2 can be configured by hardware such as a circuit device that implements these functions, or software that implements these functions is used as an arithmetic unit. Can also be configured by executing. It can also be configured with a combination of hardware and software.
  • the collection unit 1331, the calculation unit 1341, the diagnosis management unit 1381, the collection service unit 21, and the OTA service unit 23 can be configured by hardware, software, or a combination thereof.
  • the functional unit that stores data eg, collection log 1332, log 1342, config data 1382, log 22, each DB
  • Vehicle 11 In-vehicle network 12: TCU 13: ECU 131: Collection function unit 1331: Collection unit 1341: Calculation unit 135: Output unit 136: RAM 1371: Collection program 1372: Arithmetic program 1381: Diagnosis management unit 1382: Config data 14: ECU 142: Arithmetic unit 145: Diagnosis unit 1441: Arithmetic program 2: Data center 21: Collection service unit 22: Log 23: OTA service unit 24: OTA program database 3: Mobile phone 4: Base station

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Quality & Reliability (AREA)
  • Stored Programmes (AREA)
  • Control Of Driving Devices And Active Controlling Of Vehicle (AREA)

Abstract

本発明は、ＥＣＵのソフトウェア状態を容易に管理するとともに、車両とセンタそれぞれにおけるソフトウェア状態の管理情報を一致させてＥＣＵアプリケーションとデータ収集プログラムを連携して更新することができる、プログラム更新技術を提供することを目的とする。本発明に係る車両制御装置は、前記車両制御装置が実行する第１プログラムの第１更新状態と、第２車両制御装置が実行する第２プログラムの第２更新状態とを集約して更新サーバへ送信し、前記第１更新状態に対応する更新版プログラムと前記第２更新状態に対応する更新版プログラムを前記更新サーバから受信して更新処理を実施する（図１）。

Description

車両制御装置、車両システム、更新システム
　本発明は、車両の動作を制御する車両制御装置が実行するプログラムを更新する技術に関する。
　車両を制御する車両制御装置（Ｅｌｅｃｔｒｏｎｉｃ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ：ＥＣＵ）は、車内ネットワークにおいて相互接続されている。車内ネットワークを構成する車両システムは、通信網に接続され、車両とセンタが双方向にデータやプログラムを送受信することが、近年は一般的になっている。センタから車両へデータを送信する例として、ＥＣＵプログラムを更新するＦＯＴＡ（Ｆｉｒｍｗａｒｅ　Ｏｎ　Ｔｈｅ　Ａｉｒ）、カーナビゲーションの地図データの更新、音楽データ配信などがある。車両からセンタへデータを送信する例としては、車両の部品診断情報をセンタへアップロードし、センタ側でその診断情報をディーラに連絡し、車両の部品を交換する（部品管理）などがある。
　下記特許文献１は、車両の走行状況を車両内で収集し、収集したログをセンタにアップロードする例を記載している。同文献においては、センタから車両に対してデータ収集プログラムを配信することにより、車両の収集機能を変更する。これにより同文献においては、ログの収集条件、ログの収集頻度、アップロードの送信頻度、などを変えることができる。
　車両からの情報収集が進んでいくと、現行の車両の機能が収集できない情報も収集する要求が高まってくる。例えば、カーナビ情報やインフォテイメント情報をマーケティングに活用することが考えられる。カーナビの経路情報や、聞いている音楽の再生回数など、通常は収集できない情報を集めるためには、車両が備えるデータ収集機能をアップデートする必要がある。例えばデータ収集対象となるＥＣＵのアプリケーション機能をＯＴＡによって追加し、演算結果をＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）に出力させることにより、所望のデータを収集することができる。
　すなわち、これまで車両が収集していなかった情報であっても、ＥＣＵのアプリケーション機能をＯＴＡによって追加することにより、センタに送信することができる。これにより、例えば宅配運送業者のルート情報やタクシーの顧客毎運行情報のような用途においても同様に車両がこれらのログを収集し、センタに送信し、センタがこれらの情報を分析することができる。
特開２０１８－０５５１９１号公報
　車両から新たな情報を収集する際、アプリケーションがその新たな情報を出力するために必要な機能が不足する場合がある。このとき、車両が新たな情報を収集するために、データ収集プログラムを更新するだけでなく、同時にアプリケーション機能追加のための演算プログラムを更新する必要がある。このとき、アプリケーションが搭載されるＥＣＵと、データ収集機能が搭載される別のＥＣＵの両方を、ＯＴＡによって更新することとなる。
　このように、車両から収集するデータ項目がＯＴＡによるカスタマイズによって進んでくると、車両が搭載している各ＥＣＵのソフトウェアの状態が容易に把握できなくなる。そこで、車両が搭載しているＥＣＵのソフトウェアのバージョンやＲＯＭ空き容量などのようなソフトウェア状態を容易に管理することができる技術が求められる。
　センタにおいて、データ収集プログラムとＥＣＵアプリケーションをＯＴＡによって更新する場合、これらの更新を連携させる必要がある。そこで、車両とセンタそれぞれにおいてソフトウェア状態の管理情報が一致するように管理し、それを用いて、ＥＣＵアプリケーションとデータ収集プログラムとを連携して更新することが求められる。
　本発明は、上記のような課題に鑑みてなされたものであり、ＥＣＵのソフトウェア状態を容易に管理するとともに、車両とセンタそれぞれにおけるソフトウェア状態の管理情報を一致させてＥＣＵアプリケーションとデータ収集プログラムを連携して更新することができる、プログラム更新技術を提供することを目的とする。
　本発明に係る車両制御装置は、前記車両制御装置が実行する第１プログラムの第１更新状態と、第２車両制御装置が実行する第２プログラムの第２更新状態とを集約して更新サーバへ送信し、前記第１更新状態に対応する更新版プログラムと前記第２更新状態に対応する更新版プログラムを前記更新サーバから受信して更新処理を実施する。
　本発明に係る車両制御装置によれば、各車両制御装置が搭載しているソフトウェアの更新状態を一括管理することができる。さらに、更新状態に対応するアプリケーションプログラムとデータ収集プログラムを連携して更新することができる。
実施形態１に係る更新システムのシステム構成図である。 車両１が備える車両システムの構成図である。 ＥＣＵ１３が各ＥＣＵからデータを収集する手順を説明するフローチャートである。 コンフィグデータ１３８２の例を示す。 コンフィグデータ１３８２を作成する手順を説明する図である。 データセンタ２の構成図である。 データセンタ２が収集プログラム１３７１と演算プログラムを更新する手順を説明するフローチャートである。
＜実施の形態１＞
　本発明の実施形態１では、車両内のデータを収集し、センタにそのデータログをアップロードすることを想定する。本実施形態１に係る更新システムは、ＥＣＵアプリケーションにおいて必要な機能が不足する場合、データ収集プログラムとアプリケーションを連携して更新する手段を提供する。
　図１は、本実施形態１に係る更新システムのシステム構成図である。更新システムは、車両１が搭載しているＥＣＵが実行するプログラムを更新するシステムである。更新システムは、車両１、データセンタ２、携帯電話３が、基地局４を介して互いに通信することができるように構成されている。車両１のドライバは、携帯電話３を介して、車両１上で収集するデータ項目をカスタマイズすることができる。データセンタ２は、例えばサーバコンピュータによって構成される。
　ドライバは携帯電話３上で、マーケティングやテレマティック保険などの用途向けに、車両１のどのデータを収集するかを指定する。データセンタ２側において、収集サービス部２１は、携帯電話３上で指定されたデータ収集項目を集約する。収集サービス部２１は、収集項目に対応する収集要件をＯＴＡサービス部２３に渡す。ＯＴＡサービス部２３は、収集要件を分析し、ＯＴＡプログラムデータベース２４から車両１の車種に対応するデータ収集プログラムとＥＣＵアプリケーション（以下では演算プログラムと呼ぶ）を作成する。ＯＴＡサービス部２３は、作成したプログラムを車両１に対してＯＴＡによって配信する。ログ２２は、車両から収集したデータであり、このログをマーケティングやテレマティック保険サービスアプリケーションに提供し、活用される。
　車両１は、車内ネットワーク１１上に、通信ユニット１２（ＴＣＵ）、ＥＣＵ１３、ＥＣＵ１４を搭載している。ＥＣＵ１３は、収集機能部１３１によって車両１の各種データを収集することができる。ＥＣＵ１４は、例えばインフォテインメントやカーナビゲーションなどのアプリケーションを実装した演算プログラムを実施する。各ＥＣＵが実行するプログラムは、データセンタ２のＯＴＡ機能によって更新される。例えば、ＥＣＵ１４はある条件下における走行経路情報を計算して車内ネットワーク１１上に出力する。ＥＣＵ１３はその走行経路情報を１分毎に記録し、３時間ごとにデータセンタ２へ送信する。車内ネットワーク１１は、例えばＣＡＮ（Ｃｏｎｔｒｏｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）バスなどの通信ネットワークである。
　図２は、車両１が備える車両システムの構成図である。車両システムは、車内ネットワーク１１（例えばＣＡＮネットワーク）上に、通信ユニット１２、ＥＣＵ１３、ＥＣＵ１４、ＥＣＵ１５、ＥＣＵ１６などが接続されることによって構成されている。
　ＥＣＵ１３は、各ＥＣＵのソフトウェアの更新状態を収集するとともに、車両１の状態を表すデータ項目を収集する。ＥＣＵ１３は、インターフェース部１３２、収集機能部１３１を備える。インターフェース部１３２は、車内ネットワーク１１を介して他装置と通信する通信インターフェースである。収集機能部１３１は、以下を備える。
　収集部１３３１は、車内ネットワーク１１上のデータを収集する。収集ログ１３３２は、収集部１３３１が収集したデータを蓄積したものである。演算部１３４１は、収集部１３３１が収集したログを特定のフォーマットや条件に基づき加工・演算する。ログ１３４２は、演算部１３４１による演算結果を蓄積したものであり、データセンタ２に対して送信するデータである。出力部１３５は、特定の頻度や周期でログ１３４２を出力する、ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）１３６はデータを一時保存する。不揮発ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）１３７は、ＥＣＵ１３の電源遮断後もプログラムやデータを保存する。不揮発ＲＯＭ１３７は、収集プログラム１３７１と演算プログラム１３７２を格納する。収集プログラム１３７１は、収集方法やデータ出力方法を実装したプログラムである。演算プログラム１３７２は、データのフォーマット変換や演算手順などを実装したプログラムである。コンフィグレーションデータ１３８２（以下コンフィグデータ１３８２と略す）は、車両１内の全ＥＣＵのソフトウェアのバージョン等の更新状態を記述している。診断管理部１３８１は、コンフィグデータ１３８２を各ＥＣＵから収集する。収集ログ、ログ、コンフィグデータはＳＤカードなどＥＣＵ１３の電源遮断後にも内容が保持されるように、不揮発データとしてデータを格納する手段に保存される。
　ＥＣＵ１４は、車内ネットワーク１１とのインターフェース部１４１、演算部１４２、ＲＡＭ１４３、不揮発ＲＯＭ１４４、診断部１４５を備える。不揮発ＲＯＭ１４４は、ＥＣＵ１４が提供するアプリケーションを実装した演算プログラム１４４１を格納する。診断部１４５は、ＥＣＵ１４内の故障や情報を集約し、故障コマンドに対応して応答する。診断管理部１３８１も診断部１４５と同様の機能を備える。
　ＯＴＡによってプログラムを更新するに際して、各ＥＣＵが備えるＲＯＭはダブルバンクとする。ダブルバンクとは、プログラム領域を２面用意しておき、１面を有効化し、使用しておき、残りの１面をＯＴＡによって書き換え、その後、有効面を切り替える仕組みである。実施形態１では、演算プログラム１３７２と１４４１、収集プログラム１３７１は、図２では省略しているが、ダブルバンク構成である。
　図３は、ＥＣＵ１３が各ＥＣＵからデータを収集する手順を説明するフローチャートである。ＥＣＵ１４、ＥＣＵ１５、ＥＣＵ１６はそれぞれ自身が搭載している演算プログラムを実行し、その演算結果（処理結果）を車内ネットワーク１１に出力する（Ｓ１１）。ＥＣＵ１３において、収集部１３３１は収集プログラム１３７１を実行することによって車内ネットワーク１１上のデータを収集して収集ログ１３３２を蓄積する（Ｓ１２）。ＥＣＵ１３において、演算部１３４１は演算プログラム１３７２を実行することにより、収集ログ１３３２に対してフォーマット変換や演算を実施し、ログ１３４２を生成する（Ｓ１３）。ＥＣＵ１３において、出力部１３５は、収集ルールに記載された送信頻度で、ログ１３４２をデータセンタ２に対して送信する（Ｓ１４）。
　ＥＣＵ１３～１６は、いずれも演算部（演算プログラム）を備えている。ＥＣＵ１４～１６に対して機能を追加する（収集するデータ項目を変更する）際には、これらのＥＣＵの演算プログラムを変更する必要がある。収集するデータ項目を変更せず、フォーマット変更などの加工演算のみを変更する場合は、ＥＣＵ１３内の演算プログラムを変更すれば足りる。
　収集機能部１３１が備える既存の収集機能に対して新たな収集機能を追加する（例えば収集するデータ項目を追加する）場合、収集プログラム１３７１だけでなく、収集対象のＥＣＵの演算プログラムを更新することが必要になる場合がある。例えば収集すべきデータ項目を出力するために、演算プログラムが新たな機能を必要とする場合がこれに相当する。このように各ＥＣＵの演算プログラムが車両１のカスタマイズによって更新される場合、車両１の全ＥＣＵのソフトウェアの更新状態を正しく把握しておかないと、ＥＣＵハードウェア構成に合わない不適切なプログラムによって各プログラムが更新される懸念がある。あるいは、収集プログラム１３７１を更新するとともに各ＥＣＵの演算プログラムを更新する際に、収集プログラム１３７１と演算プログラムとの間で整合していない更新版プログラムが更新される懸念がある。そこで本実施形態１においては、車両１内のソフトウェアをＥＣＵ１３によって一元管理することとした。コンフィグデータ１３８２はその一元管理情報を保持するデータである。
　図４は、コンフィグデータ１３８２の例を示す。図４は、ＥＣＵのハードＩＤ、プログラムＩＤ、ＣＡＮデータベース番号、空きＣＡＮＩＤ、空きＲＯＭ容量を保持している。ＥＣＵのマイコンに複数のアプリケーションが搭載されている場合は、複数のプログラムＩＤが記載される。ＥＣＵソフトウェアのカスタマイズが進むと、機能によっては新たなＣＡＮデータ項目を出力することによってＣＡＮＩＤを消費する場合がある。あるいは、プログラム更新によって消費する空きＲＯＭ容量も変動する。そこで図４においては、空きＣＡＮＩＤ、空きＲＯＭ容量も保持することとした。これらのデータ項目によって、新たなプログラムを搭載することができるか否かを判定することができる。
　図５は、コンフィグデータ１３８２を作成する手順を説明する図である。診断管理部１３８１は、車両１内の全ＥＣＵ（図５ではＥＣＵ１４～１６）に対してそれぞれソフトウェアの更新状態を問い合わせるための診断コマンドを記述した診断ＣＡＮコマンドマップ１３８３を備える。診断管理部１３８１は、診断ＣＡＮコマンドマップ１３８３に基づき、車内ネットワーク１１上に診断コマンド１３８４を順番に発行する。ターゲットＥＣＵ（例えばＥＣＵ１４）の診断部１４５は、故障の情報と同様に、図４のようなソフトウェア構成情報を作成し、診断コマンド１３８４に対するレスポンスとしてそのソフトウェア構成情報をＥＣＵ１３に返す。診断管理部１３８１は、同様に全ＥＣＵからソフトウェア構成情報を集めることにより、コンフィグデータ１３８２を作成することができる。
　診断コマンドの内容は、ＥＣＵごとに異なる場合もあるので、ＥＣＵごとに定義してもよい。診断コマンドとともに各ＥＣＵの宛先情報を記述してもよい。診断コマンドは必ずしも本発明を実装するために新たに開発する必要はなく、既存の故障診断手順のなかでソフトウェアバージョンやＲＯＭ空き容量などを問い合わせるコマンドを流用してもよい。ただし従来の診断コマンドは各ＥＣＵを個別に診断するためのものであるのに対し、本発明における診断コマンドは従来の診断だけでなく、これをコンフィグデータ１３８２収集のためにも用いる点が従来とは異なる。
　図６は、データセンタ２の構成図である。データセンタ２は、基地局４を介して他装置と通信する通信部２５、収集サービス部２１、ＯＴＡサービス部２３を備える。
　収集サービス部２１は、ドライバが携帯電話３上で指定したデータ収集項目に基づき、そのデータ項目を収集する機能が必要とする要件を特定する。収集サービス部２１は、収集サーバ部２１１、顧客データベース２１２、車種機能データベース２１３、収集要件部２１４、ログ分析部２１５、分析結果２１６を備える。
　顧客データベース２１２は、顧客（図１においては携帯電話３を使用するドライバ）の基本情報と過去に設定した収集項目を管理する。車種機能データベース２１３は、車種ごとに標準で収集可能なデータ項目と拡張によって収集可能なデータ項目の両方について、ユニークな収集機能ＩＤを保持している。
　収集サーバ部２１１は、携帯電話３の収集アプリケーション３１がアクセスするＷＥＢサーバとして動作する。ドライバは、携帯電話３上で車両１の車種を指定して、収集可能なデータ項目をデータセンタ２へ照会する。収集サーバ部２１１は、携帯電話３からのリクエストに応じて車種機能データベース２１３を参照し、車両１が標準で収集可能なデータ項目と拡張によって収集可能なデータ項目の一覧を応答する。ドライバは、車両１において収集したいデータ項目を携帯電話３上で指定する。
　収集要件部２１４は、ドライバが指定したデータ項目を収集することができる収集機能ＩＤを車種機能データベース２１３から取得する。収集要件部２１４は、収集機能ＩＤを顧客データベース２１２が格納しているそのドライバの顧客ＩＤおよび車種ＩＤと併せてＯＴＡサービス部２３へ出力する。
　ログ２２は、車両から転送されてきたログデータを蓄積したものである。ログ分析部２１５は、ログ２２を分析し、分析結果２１６を出力する。例えばマーケティングサービスやテレマティック保険サービスなどの顧客分析を必要とするサービスへ分析結果２１６を渡し、それらのサービスにおいて分析結果２１６を活用することができる。
　ＯＴＡサービス部２３は、車両１に対して更新版プログラムを配信する。ＯＴＡサービス部２３は、収集要求分析部２３１、コンフィグデータ２３２、車両ＥＣＵソフトデータベース２３３、ＯＴＡプログラム生成部２３４、ＯＴＡプログラムデータベース２４、顧客データベース２３６、ＯＴＡ配信部２３７、を備える。
　コンフィグデータ２３２は、車両１が保持しているコンフィグデータ１３８２を車両１から受け取ったものである。車両ＥＣＵソフトデータベース２３３は、車両１が備える各ＥＣＵのソフトウェアバージョンごとに、収集できるデータ項目を保持している。収集プログラム１３７１については、収集可能なデータ項目を、収集プログラム１３７１のバージョンごとに保持している。各ＥＣＵが備える演算プログラムについては、車内ネットワーク１１へ出力することができるデータ項目を、演算プログラムのバージョンごとに保持している。
　収集要求分析部２３１は、収集サービス部２１から受け取った収集機能ＩＤに基づき、ドライバが望むデータ項目を収集可能な機能を特定する。収集要求分析部２３１は、収集機能ＩＤと、コンフィグデータ２３２が保持している各ＥＣＵのプログラムＩＤなどとに基づき、ドライバが望むデータ項目を収集可能なプログラムバージョン（収集プログラム１３７１と演算プログラムの双方）としてプログラムＩＤを、車両ＥＣＵソフトデータベース２３３から取得する。収集要求分析部２３１は、取得した各プログラムのＩＤを、ＯＴＡプログラム生成部２３４へ出力する。
　ＯＴＡプログラムデータベース２４は、プログラム（収集プログラム１３７１と演算プログラムの双方）の各バージョンを保持している。各プログラムの各バージョンは、プログラムＩＤによって一意に識別されている。プログラムは必ずしも単体で完結したものに限らず、特定の関数などを実装したモジュールなどであってもよい。
　ＯＴＡプログラム生成部２３４は、プログラムＩＤとして収集プログラム１３７１のＩＤと、各ＥＣＵの演算プログラムのＩＤとを用いて、ＯＴＡプログラムデータベース２４を参照することにより、各プログラムの更新バージョンを取得し、その更新バージョンを用いて、ＯＴＡによって車両１へ配信するプログラムを生成する。ＯＴＡプログラムデータベース２４がプログラムモジュールを保持している場合は、モジュールを結合することによって、車両１へ配信するプログラムを生成してもよい。
　顧客データベース２３６は、ドライバごとのセキュリティ情報（例えば電子署名など）を保持している。ＯＴＡ配信部２３７は、顧客データベース２３６を参照し、車両１のドライバに対応するセキュリティ機構を付加した上で、ＯＴＡプログラム生成部２３４が生成したプログラムを車両１へ配信する。
　図７は、データセンタ２が収集プログラム１３７１と演算プログラムを更新する手順を説明するフローチャートである。以下図７の各ステップについて説明する。
（図７：ステップＳ７０１）
　車両１のドライバは、携帯電話３の収集アプリケーション３１を用いて、車両１が収集すべきデータ項目を指定する。収集時間間隔などの収集条件を併せて指定することもできる。データ項目と収集条件を併せて以下では収集条件と呼ぶ。
（図７：ステップＳ７０２）
　収集サーバ部２１１は、携帯電話３から収集条件を取得する。収集要件部２１４は、収集条件が指定するデータ項目を収集することができる収集機能ＩＤを特定し、顧客情報と収集機能ＩＤをＯＴＡサービス部２３へ出力する。
（図７：ステップＳ７０３～Ｓ７０４）
　収集要求分析部２３１は、顧客情報から車両１を特定し、コンフィグデータ１３８２をデータセンタ２へ転送するように車両１に対して要求する（Ｓ７０３）。収集機能部１３１は、車両１内の最新のコンフィグデータ１３８２をデータセンタ２に転送する（Ｓ７０４）。これにより、車両１が保持しているコンフィグデータ１３８２とデータセンタ２が保持しているコンフィグデータ２３２が一致する。
（図７：ステップＳ７０５）
　収集要求分析部２３１は、収集機能ＩＤとコンフィグデータ２３２に基づき、収集プログラム１３７１のプログラムＩＤと、各ＥＣＵの演算プログラムのプログラムＩＤを、車両ＥＣＵソフトデータベース２３３から取得する。収集要求分析部２３１は、これらのプログラムＩＤをＯＴＡプログラム生成部２３４に送信する。
（図７：ステップＳ７０６）
　ＯＴＡプログラム生成部２３４は、収集プログラム１３７１のプログラムＩＤと各ＥＣＵの演算プログラムのプログラムＩＤを元に、ＯＴＡプログラムデータベース２４を参照することにより、ＯＴＡ配信するプログラム（各プログラムの更新版）を作成する。ＯＴＡプログラムは全領域更新でもよいし、差分更新でもよい。
（図７：ステップＳ７０７）
　ＯＴＡ配信部２３７は、収集プログラム１３７１と各ＥＣＵの演算プログラムそれぞれの更新バージョンを、ＯＴＡ機能によって車両１へ同時配信する。
（図７：ステップＳ７０８）
　車両１内の各ＥＣＵは、ＯＴＡ機能によって配信された更新版プログラムを用いてそれぞれのソフトウェアを更新する。収集機能部１３１は、コンフィグデータ１３８２を更新する。診断管理部１３８１は、本ステップとは別に、定期的にコンフィグデータ１３８２を更新する。
（図７：ステップＳ７０９～Ｓ７１０）
　収集機能部１３１は、収集したログを収集サーバ部２１１に送信する（Ｓ７０９）。ログ分析部２１５は、収集したログを分析し、分析結果を蓄積する（Ｓ７１０）。
＜実施の形態１：まとめ＞
　本実施形態１に係るＥＣＵ１３は、各ＥＣＵが備えるプログラムの更新状態を記述したコンフィグデータ１３８２を収集し、コンフィグデータ１３８２が記述している各更新状態に対応する更新版プログラムをデータセンタ２から取得してその更新版プログラムによってプログラムを更新する。その他のＥＣＵも同様のデータセンタ２から受け取った更新版プログラムによって演算プログラムを更新する。車両１が搭載する全ＥＣＵのソフトウェアバージョンやＲＯＭ空き容量などのソフトウェア状態を、車両１とデータセンタ２それぞれにおいて一致させて管理することによって、適切なプログラム更新を実現している。さらに、全ＥＣＵのソフトウェア状態をＥＣＵ１３が統括的に管理することにより、各ＥＣＵの演算プログラムとＥＣＵ１３の収集プログラム１３７１を連携して生成することができる。
　本実施形態１に係るＥＣＵ１３は、診断ＣＡＮコマンドマップ１３８３に基づき、車内ネットワーク１１上に診断コマンド１３８４を発行し、診断コマンド１３８４を受け取ったＥＣＵはこれに対するレスポンスとしてソフトウェア状態を返信する。これにより、各ＥＣＵのソフトウェア状態をＥＣＵ１３上のコンフィグデータ１３８２として集約することができる。
　本実施形態１に係るＥＣＵ１３において、収集プログラム１３７１は、各ＥＣＵからデータを収集する頻度、収集するデータ項目、または収集したデータをデータセンタ２へ送信する頻度のうち少なくともいずれかを、収集プログラム１３７１のバージョンごとに変更することができるように構成されている。これにより、車両１において実施するデータ収集処理をユーザが自由にカスタマイズすることができる。例えば車両１が備える現行のＥＣＵにおいて抑止されている機能の解除や、新規機能の追加の上で、それに連携した収集条件を追加することができる。車両１の情報をカスタマイズして取得することにより、例えばテレマティック保険サービスやマーケティングサービスなどの外部サービスにおいて、車両１に関する様々な情報を活用することができる。
　本実施形態１に係る更新システムにおいて、車両１のユーザは携帯電話３を介してデータ収集項目をカスタマイズし、データセンタ２はそのカスタマイズされたデータ項目を収集することができる演算プログラムと収集プログラム１３７１を生成して車両１へ送信する。これにより、車両１が備える各ＥＣＵの演算プログラムと収集プログラム１３７１を連携して更新しつつ、ユーザは車両１上で収集するデータ項目を自由にカスタマイズすることができる。
＜実施の形態２＞
　実施形態１において、各ＥＣＵの演算プログラムと収集プログラム１３７１を連携して更新することを説明した。これらは必ずしも同時に更新する必要はなく、以下のいずれかを更新してもよい。
（更新例１）収集プログラム１３７１といずれか１つのＥＣＵ上の演算プログラム
（更新例２）収集プログラム１３７１とＥＣＵ１３上の演算プログラム
（更新例３）収集プログラム１３７１
（更新例４）収集プログラム１３７１といずれか２以上（車両１上のＥＣＵのうち一部）のＥＣＵ上の演算プログラム
　各ＥＣＵは、例えばＲＯＭの空き容量が不足する場合など、プログラムを更新することができない場合は、プログラム更新を抑止することもできる。更新抑止した場合はその旨を車両１からデータセンタ２へ通知する。さらにＯＴＡサービス部２３から収集サービス部２１を介して、携帯電話３のユーザへその旨を通知することもできる。
＜本発明の変形例について＞
　本発明は上記実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、上記実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換えることが可能であり、また、ある実施形態の構成に他の実施形態の構成を加えることも可能である。また、各実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
　以上の実施形態において、ＥＣＵ１３については収集プログラム１３７１を更新するとともに、他のＥＣＵ（例：ＥＣＵ１４）については演算プログラムをこれと連動して更新することを説明した。実際のシステムにおいては、他のＥＣＵの演算プログラムが更新されることにより、収集するデータ項目のフォーマットなども変更される場合があるので、演算プログラム１３７２によるフォーマット変換などの処理も変更する必要が生じる可能性がある。したがって収集プログラム１３７１と各演算プログラムに連動して演算プログラム１３７２を更新してもよい。
　以上の実施形態において、診断管理部１３８１がコンフィグデータ１３８２をＥＣＵ１４から収集し、収集部１３３１と収集プログラム１３７１が車両１の各種データ項目（車両データ）を収集することを説明したが、これらの処理は１つのプログラムとして集約してもよい。例えば収集機能部１３１として１つのプログラムを実装し、そのプログラムがコンフィグデータ１３８２と車両データを収集してもよい。すなわち、ＥＣＵ１３がこれらの処理を実行するのであれば、プログラム間の役割分担は任意でよい。
　以上の実施形態において、収集機能部１３１が収集するデータ項目は、車両１が備えるＥＣＵのソフトウェア状態に限らず、車両１の状態を表す任意のデータ項目であってもよい。例えばターゲットＥＣＵが制御するセンサやアクチュエータなどの機器の状態を表すデータをそのターゲットＥＣＵから収集することができる。その他、例示したようにカーナビゲーションＥＣＵから車両１の走行経路などの情報を収集することもできるし、インフォテイメントＥＣＵからドライバの嗜好に関する情報を収集することもできる。
　以上の実施形態において、車両１の車種（メーカ、型番、など）ごとに演算プログラムまたは収集プログラム１３７１のうち少なくともいずれかが異なっていてもよい。この場合は車種機能データベース２１３において、車種ごとに収集可能なデータ項目等を定義しておき、その収集機能ＩＤに対応するプログラムＩＤが車種ごとに異なるように車両ＥＣＵソフトデータベース２３３を構成しておけばよい。
　以上の実施形態において、収集可能なデータ項目が車両１の車種ごとに異なっていてもよい。さらに、同時に収集することができないデータ項目などのように、データ収集に関する制約条件を定義してもよい。この制約条件は、例えば車種機能データベース２１３内に定義しておけばよい。制約条件にかかるデータ項目をユーザが携帯電話３上で選択した場合は、収集サーバ部２１１を介してその旨を携帯電話３へ返信してもよいし、そのようなデータ項目を初めから選択できないように構成した選択画面を収集サーバ部２１１から携帯電話３へ提供してもよい。
　以上の実施形態において、データセンタ２が各ＥＣＵの更新版プログラムを車両１へ配信する際には、データセンタ２から各ＥＣＵ宛に直接配信してもよいし、データセンタ２は宛先ＥＣＵのみを指定した上で車両１内のゲートウェイ装置が各ＥＣＵの更新版プログラムを受け取ってもよい。後者の場合はゲートウェイ装置を経由して各ＥＣＵに対して更新版プログラムが配信されることになる。
　以上の実施形態において、車両１の各種データを収集するＥＣＵ（実施形態におけるＥＣＵ１３）は、車両１のいずれかの機能を制御する制御装置であればよく、必ずしも他のＥＣＵを統括する役割を有するＥＣＵでなくともよい。
　以上の実施形態において、各ＥＣＵやデータセンタ２が備える各演算機能部は、これらの機能を実装した回路デバイスなどのハードウェアによって構成することもできるし、これらの機能を実装したソフトウェアを演算装置が実行することによって構成することもできる。ハードウェアとソフトウェアの組み合わせによって構成することもできる。例えば収集部１３３１、演算部１３４１、診断管理部１３８１、収集サービス部２１、ＯＴＡサービス部２３は、ハードウェア、ソフトウェア、これらの組み合わせによって構成することができる。これら機能部のうちデータを蓄積する機能部（例：収集ログ１３３２、ログ１３４２、コンフィグデータ１３８２、ログ２２、各ＤＢ）は、演算機能部の一部として構成してもよいし、データ部分のみを演算機能部から切り離して実装してもよい。
１：車両
１１：車内ネットワーク
１２：ＴＣＵ
１３：ＥＣＵ
１３１：収集機能部
１３３１：収集部
１３４１：演算部
１３５：出力部
１３６：ＲＡＭ
１３７１：収集プログラム
１３７２：演算プログラム
１３８１：診断管理部
１３８２：コンフィグデータ
１４：ＥＣＵ
１４２：演算部
１４５：診断部
１４４１：演算プログラム
２：データセンタ
２１：収集サービス部
２２：ログ
２３：ＯＴＡサービス部
２４：ＯＴＡプログラムデータベース
３：携帯電話
４：基地局

Claims (12)

  1. 　車両の動作を制御する車両制御装置であって、
    　前記車両制御装置が提供する機能を実装したプログラムを格納するプログラム記憶部、
    　前記プログラムを実行する演算部、
    　前記プログラムの更新状態を表すコンフィグレーションデータを格納するコンフィグレーションデータ記憶部、
    　を備え、
    　前記プログラム記憶部は、前記プログラムとして、
    　　前記車両制御装置が提供する演算機能を実装した演算プログラム、
    　　前記車両が搭載している第２車両制御装置から前記第２車両制御装置が実装している第２プログラムの更新状態を表す第２プログラム更新状態データを収集する処理を実装した収集プログラム、
    　を格納しており、
    　前記演算部は、前記コンフィグレーションデータと前記第２プログラム更新状態データを集約して、前記プログラムの更新版を配信するサーバに対して送信し、
    　前記演算部は、前記コンフィグレーションデータに対応する前記プログラムの更新版を前記サーバから受信し、
    　前記演算部は、前記サーバから受信した前記プログラムの更新版によって、前記プログラム記憶部が格納している前記プログラムを更新する
    　ことを特徴とする車両制御装置。
  2. 　前記車両制御装置はさらに、前記第２車両制御装置が故障しているか否かを診断するために用いる診断コマンドと前記診断コマンドの宛先情報を記述した診断コマンドマップを備え、
    　前記収集プログラムは、前記診断コマンドマップにしたがって前記第２車両制御装置に対して前記診断コマンドを送信することにより前記第２プログラム更新状態データを要求するステップを、前記演算部に実行させ、
    　前記収集プログラムは、前記診断コマンドに対する応答を前記第２プログラム更新状態データとして前記コンフィグレーションデータへ集約するステップを、前記演算部に実行させる
    　ことを特徴とする請求項１記載の車両制御装置。
  3. 　前記収集プログラムは、前記車両の状態を表す車両データを収集するステップを、前記演算部に実行させ、
    　前記収集プログラムは、前記収集した前記車両データを前記サーバに対して送信するステップを、前記演算部に実行させる
    　ことを特徴とする請求項１記載の車両制御装置。
  4. 　前記収集プログラムは、前記車両データを収集する頻度、前記車両データとして収集する項目、および前記車両データを前記サーバに対して送信する頻度を実装しており、
    　前記演算部は、前記プログラムの更新版によって、前記収集プログラムのうち、前記車両データを収集する頻度、前記車両データとして収集する項目、または前記車両データを前記サーバに対して送信する頻度の少なくともいずれかを更新する
    　ことを特徴とする請求項３記載の車両制御装置。
  5. 　請求項１記載の車両制御装置、
    　前記車両が搭載している第２車両制御装置、
    　を備え、
    　前記第２車両制御装置は、前記コンフィグレーションデータに対応する前記第２プログラムの更新版を前記サーバから受信し、
    　前記第２車両制御装置は、前記サーバから受信した前記第２プログラムの更新版によって、前記第２プログラムを更新する
    　ことを特徴とする車両システム。
  6. 　前記収集プログラムは、前記車両の状態を表す車両データとして収集する項目を規定しており、
    　前記第２プログラムは、前記車両データを提供するステップを実装しており、
    　前記演算部は、前記プログラムの更新版によって、前記収集プログラムのうち、前記車両データとして収集する項目を更新し、
    　前記第２車両制御装置は、前記プログラムの更新版によって更新された前記項目を提供するステップを実装するように、前記第２プログラムの更新版によって前記第２プログラムを更新する
    　ことを特徴とする請求項５記載の車両システム。
  7. 　車両が搭載している車両制御装置が実行するプログラムを更新する更新システムであって、
    　請求項５記載の車両システム、
    　前記プログラムの更新版を前記車両制御装置に対して送信するとともにと前記第２プログラムの更新版を前記第２車両制御装置に対して送信するサーバ、
    　を有することを特徴とする更新システム。
  8. 　前記収集プログラムは、前記車両の状態を表す車両データを収集するステップを、前記演算部に実行させるように構成されており、
    　前記サーバは、前記車両データとして収集する項目を指定する項目リクエストをユーザ端末から受信し、
    　前記サーバは、前記項目リクエストが指定する項目を前記車両データとして収集するステップを実装した前記収集プログラムを、前記プログラムの更新版として前記車両制御装置に対して送信する
    　ことを特徴とする請求項７記載の更新システム。
  9. 　前記サーバは、前記項目リクエストを受信すると、前記コンフィグレーションデータを送信するように要求するコンフィグレーションデータリクエストを前記車両制御装置に対して送信し、
    　前記サーバは、前記コンフィグレーションデータリクエストに応答して前記車両制御装置から受信した前記コンフィグレーションデータを用いて、前記プログラムの更新状態を特定し、
    　前記サーバは、前記特定した前記プログラムの更新状態と、前記項目リクエストが指定する項目とにしたがって、前記項目リクエストが指定する項目を前記車両データとして収集するステップを実装した前記収集プログラムを生成し、
    　前記サーバは、前記生成した前記収集プログラムを、前記プログラムの更新版として前記車両制御装置に対して送信する
    　ことを特徴とする請求項８記載の更新システム。
  10. 　前記サーバは、前記コンフィグレーションデータリクエストに応答して前記車両制御装置から受信した前記コンフィグレーションデータを用いて、前記第２プログラムの更新状態を特定し、
    　前記サーバは、前記特定した前記第２プログラムの更新状態と、前記項目リクエストが指定する項目とにしたがって、前記項目リクエストが指定する項目を前記車両データとして提供するステップを実装した前記第２プログラムを生成し、
    　前記サーバは、前記生成した前記第２プログラムを、前記第２プログラムの更新版として前記第２車両制御装置に対して送信する
    　ことを特徴とする請求項９記載の更新システム。
  11. 　前記サーバは、前記収集プログラムが収集することができる前記項目の組み合わせごとに前記収集プログラムの更新版を格納するデータベースを備え、
    　前記サーバは、前記項目リクエストが指定する前記項目を全て収集することができる前記収集プログラムの更新版を前記データベースから取得し、
    　前記サーバは、前記取得した前記収集プログラムの更新版を、前記プログラムの更新版として前記車両制御装置に対して送信する
    　ことを特徴とする請求項８記載の更新システム。
  12. 　前記サーバは、前記プログラムの更新版と併せて、前記第２プログラムの更新版を前記第２車両制御装置に対して送信し、
    　前記第２車両制御装置は、前記受信した前記第２プログラムの更新版によって前記第２プログラムを更新することにより、前記車両制御装置における前記プログラムの更新と連動して、前記第２プログラムを更新する
    　ことを特徴とする請求項７記載の更新システム。
PCT/JP2021/032908 2021-01-12 2021-09-07 車両制御装置、車両システム、更新システム Ceased WO2022153591A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE112021005187.3T DE112021005187T5 (de) 2021-01-12 2021-09-07 Fahrzeugsteuervorrichtung, fahrzeugsystem und aktualisierungssystem
US18/253,790 US12585452B2 (en) 2021-01-12 2021-09-07 Vehicle control device, vehicle system and update system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021-002608 2021-01-12
JP2021002608A JP7550060B2 (ja) 2021-01-12 2021-01-12 車両制御装置、車両システム、更新システム

Publications (1)

Publication Number Publication Date
WO2022153591A1 true WO2022153591A1 (ja) 2022-07-21

Family

ID=82447078

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/032908 Ceased WO2022153591A1 (ja) 2021-01-12 2021-09-07 車両制御装置、車両システム、更新システム

Country Status (4)

Country Link
US (1) US12585452B2 (ja)
JP (1) JP7550060B2 (ja)
DE (1) DE112021005187T5 (ja)
WO (1) WO2022153591A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPWO2024095632A1 (ja) * 2022-11-02 2024-05-10
CN121263783A (zh) 2023-05-26 2026-01-02 日产自动车株式会社 电子控制装置和电子控制方法
US12632329B1 (en) * 2024-12-30 2026-05-19 Harman Becker Automotive Systems, Inc. Systems and methods for artificial intelligence-based analysis of over-the-air client logs

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010282385A (ja) * 2009-06-04 2010-12-16 Fujitsu Ten Ltd 情報処理システム
JP2011148398A (ja) * 2010-01-21 2011-08-04 Denso Corp 車両用プログラム更新システム
JP2019036251A (ja) * 2017-08-21 2019-03-07 株式会社東芝 更新制御装置、ソフトウェア更新システムおよび更新制御方法
WO2020111090A1 (ja) * 2018-11-28 2020-06-04 株式会社オートネットワーク技術研究所 監視装置、監視プログラム及び監視方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101459493B1 (ko) * 2013-10-08 2014-11-07 현대자동차 주식회사 차량 전자 제어 장치 및 차량 제어방법
JP2018055191A (ja) 2016-09-26 2018-04-05 株式会社日立製作所 データ収集システム
US20190102158A1 (en) * 2017-09-29 2019-04-04 GM Global Technology Operations LLC System and method for providing software updates in assembly line and dealership lot environments
DE102017220526A1 (de) * 2017-11-17 2019-05-23 Bayerische Motoren Werke Aktiengesellschaft Verfahren und Vorrichtung zur Aktualisierung von Software

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010282385A (ja) * 2009-06-04 2010-12-16 Fujitsu Ten Ltd 情報処理システム
JP2011148398A (ja) * 2010-01-21 2011-08-04 Denso Corp 車両用プログラム更新システム
JP2019036251A (ja) * 2017-08-21 2019-03-07 株式会社東芝 更新制御装置、ソフトウェア更新システムおよび更新制御方法
WO2020111090A1 (ja) * 2018-11-28 2020-06-04 株式会社オートネットワーク技術研究所 監視装置、監視プログラム及び監視方法

Also Published As

Publication number Publication date
JP7550060B2 (ja) 2024-09-12
JP2022107913A (ja) 2022-07-25
US20230418587A1 (en) 2023-12-28
US12585452B2 (en) 2026-03-24
DE112021005187T5 (de) 2023-09-14

Similar Documents

Publication Publication Date Title
EP3557849B1 (en) Software management system and control method for software management system
JP7550060B2 (ja) 車両制御装置、車両システム、更新システム
US10652335B2 (en) Dynamically presenting vehicle sensor data via mobile gateway proximity network
JP7571621B2 (ja) センター装置及び車載電子制御装置
US8190322B2 (en) Autonomous vehicle maintenance and repair system
US20210397433A1 (en) On-board update device, update processing program, program update method, and on-board update system
JP7439720B2 (ja) 更新データを配信するサーバ、方法及びプログラム
US20210117177A1 (en) On-board update device, update process method, and update process program
JP2022020439A (ja) サーバ、更新管理方法、更新管理プログラム、ソフトウェア更新装置、サーバ及びソフトウェア更新装置を備えるシステム
CN106708988A (zh) 一种城市轨道交通电子地图共享方法及系统
JP2019191742A (ja) 車載更新装置、車載更新システム、更新処理方法及び更新処理プログラム
US20250165246A1 (en) Center, distribution control method, and non-transitory storage medium
CA3069995A1 (en) Configurable management system for a vehicle and method of use
JP7677034B2 (ja) 車両用のシステム、センタ、方法、及びプログラム
CN112579121B (zh) 一种数据处理的方法和装置
US8732286B2 (en) Health management systems with shadow modules
CN117714277B (zh) 一种基于云原生的多集群网关及其工作方法
CN114840264A (zh) 配置数据管理方法、配置数据管理装置和车辆管理系统
CN103688243B (zh) 用于机动车的控制装置、编程装置和编程系统
JP7781007B2 (ja) 情報処理方法、通信システムおよび情報処理プログラム
JP7666194B2 (ja) 車両用のシステム、センタ、方法、及びプログラム
CN117827251A (zh) 一种车辆ecu版本升级方法、系统及相关设备
WO2023223819A1 (ja) 情報処理方法、通信システムおよび情報処理プログラム
US20230052810A1 (en) Control apparatus, control system, and method for determining function or operation of control apparatus
CN118451733A (zh) 车辆通信系统以及车载侧系统

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: 21919483

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 18253790

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 112021005187

Country of ref document: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21919483

Country of ref document: EP

Kind code of ref document: A1

WWG Wipo information: grant in national office

Ref document number: 18253790

Country of ref document: US