WO2024095463A1 - 車載診断装置およびプログラム更新方法 - Google Patents

車載診断装置およびプログラム更新方法 Download PDF

Info

Publication number
WO2024095463A1
WO2024095463A1 PCT/JP2022/041198 JP2022041198W WO2024095463A1 WO 2024095463 A1 WO2024095463 A1 WO 2024095463A1 JP 2022041198 W JP2022041198 W JP 2022041198W WO 2024095463 A1 WO2024095463 A1 WO 2024095463A1
Authority
WO
WIPO (PCT)
Prior art keywords
update
software programs
time
vehicle
return time
Prior art date
Application number
PCT/JP2022/041198
Other languages
English (en)
French (fr)
Inventor
晃宏 眞田
翼 森田
哲也 東野
Original Assignee
三菱電機株式会社
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 三菱電機株式会社 filed Critical 三菱電機株式会社
Priority to PCT/JP2022/041198 priority Critical patent/WO2024095463A1/ja
Publication of WO2024095463A1 publication Critical patent/WO2024095463A1/ja

Links

Images

Classifications

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

Definitions

  • This application relates to an on-board diagnostic device and a program update method.
  • the present application has been made to solve the problems described above, and aims to provide an on-board diagnostic device and a program update method that can select and update software programs according to the needs of the vehicle user before executing the software program update.
  • the on-board diagnostic device disclosed in this application is for updating multiple software programs used in a vehicle, and is characterized by including an update allowable time acquisition unit that acquires an update allowable time for updating the software programs before starting to update the software programs, an update schedule creation unit that selects software programs that can be updated within the acquired update allowable time and creates an update schedule, and an update control unit that performs updates based on the created update schedule.
  • the on-board diagnostic device disclosed in this application allows a software program to be selected and updated according to the needs of the vehicle user before the software program update is performed.
  • FIG. 1 is a functional block diagram of an on-board diagnostic device according to a first embodiment
  • 2 is a diagram illustrating an example of hardware of a gateway device and a microcomputer in an ECU of the on-board diagnostic device according to the first embodiment
  • FIG. 2 is a functional block diagram relating to a program update to be performed in the gateway device according to the first embodiment
  • 4 is a functional block diagram of an update allowable time acquisition unit according to the first embodiment
  • FIG. 4 is a flowchart illustrating a program update operation of the on-board diagnostic device according to the first embodiment
  • 5 is a flowchart showing an operation of an update allowable time acquisition unit according to the first embodiment
  • FIG. 4 is a diagram illustrating a list of update information according to the first embodiment.
  • FIG. 5 is a flowchart showing an operation of an update schedule creating unit according to the first embodiment
  • 5 is a flowchart showing an operation of an update priority determination unit according to the first embodiment
  • FIG. 11 is a diagram for explaining Example 2 according to the first embodiment.
  • FIG. 13 is a diagram for explaining Example 8 according to the first embodiment.
  • Embodiment 1. 1 is a functional block diagram of an on-board diagnostic device according to embodiment 1.
  • an in-vehicle system 1 mounted on a vehicle a file server 2, a web server 3, and a mobile terminal 4 carried by a vehicle user and connectable to the web server 3 are connected to each other.
  • the file server 2 and web server 3 are connected to a network, and the file server 2 and web server 3 are capable of sending and receiving data to the in-vehicle system 1 via a communication interface (I/F) 5 and a communication I/F 6, respectively.
  • the file server 2 stores program update files and has a program management function for sending update files to the ECUs 7a1 to 7an (n is a natural number) of the in-vehicle system 1 that require updating.
  • the external vehicle network 30 is, for example, a mobile communication network such as a 4G or 5G line, an Internet network, a wireless LAN, or any other communication network.
  • the in-vehicle system 1 includes a gateway device 8, in-vehicle LAN buses 9a1-9am (m is a natural number) connected to the gateway device 8, and a DCM (Data Communication Module) 10 connected to the buses 9a1-9am, or ECUs 7a1-7an.
  • the DCM 10 is for wireless communication with the communication I/Fs 5 and 6 and the mobile terminal 4.
  • the buses 9a1-9am are constructed as multiple networks with different or the same communication protocols.
  • the driving network is assigned to bus 9a1, the multimedia network to bus 9a2, and so on.
  • ECUs 7a1-7an are connected to each bus. Note that in the figure, only one ECU is connected to each bus, but in reality, multiple ECUs are connected.
  • multiple ECUs are connected to bus 9a1 of the driving network, such as an engine ECU with various functions for controlling the engine, a brake ECU with various functions for controlling the brakes, and a power steering ECU that controls the power steering.
  • multiple ECUs are connected to the buses of the other networks.
  • a vehicle speed sensor, a throttle opening sensor, an accelerator pedal opening sensor, and so on are connected to the engine ECU, and a brake pedal sensor is connected to the brake ECU.
  • a brake pedal sensor is connected to the brake ECU.
  • FIG. 2 shows an example of the hardware of the gateway device 8 and the microcomputer in the ECUs 7a1-7an. It is composed of a processor 100 and a storage device 200.
  • the storage device includes a volatile storage device such as a random access memory and a non-volatile auxiliary storage device such as a flash memory. Also, instead of the flash memory, a hard disk auxiliary storage device may be included.
  • the processor 100 executes each function described below by executing a program input from the storage device 200. In this case, the program is input from the auxiliary storage device to the processor 100 via the volatile storage device. Also, the processor 100 may output data such as the results of calculations to the volatile storage device of the storage device 200, or may store data in the auxiliary storage device via the volatile storage device.
  • the programs input to each of the ECUs 7a1-7an need to be updated in order to repair defects, upgrade, add new functions, etc.
  • FIG. 3 is a functional block diagram of the software (SW) program update of the update target 15 executed in the gateway device 8.
  • the update allowable time acquisition unit 11 has a return time estimation unit 11a, a return time acquisition unit 11b, and a quick charge determination unit 11c, and acquires the update allowable time.
  • the update schedule creation unit 12 creates an update schedule based on the update allowable time acquired by the update allowable time acquisition unit 11.
  • the update priority determination unit 13 determines the priority of the update program of the update target 15 based on the update priority information, and transmits the determination result to the update schedule creation unit 12.
  • the program update schedule created by the update schedule creation unit 12 is sent to the update control unit 14, and the SW program of the update target is updated based on the program update schedule.
  • the update target 15 is described as each SW program in the ECUs 7a1 to 7an, XXSW, YYSW, ZZSW, and XYSW, but is not limited thereto.
  • FIG. 5 is a flow chart explaining the overall operation of a SW program update.
  • Update permission (step S51) is given by the vehicle user, and if the vehicle user does not permit the update, the flow ends (step S52). If the vehicle user permits the update, as described above, the update permissible time acquisition unit 11 acquires the update permissible time (step S53), and based on this, the update schedule creation unit 12 creates an update schedule (step S54), and the update control unit 14 starts updating the SW program to be updated based on the created update schedule (step S55).
  • FIG. 6 is a flowchart showing the operation of the update allowable time acquisition unit 11 described in the functional block diagram of FIG. 4.
  • the rapid charging determination unit 11c determines whether the vehicle is undergoing rapid charging or not (step S61). If the vehicle is an electric vehicle, there are two types of charging: rapid charging and normal charging. If rapid charging is in progress, the maximum charging time for one charge is 30 minutes. For this reason, the return time is set to 30 minutes (step S62). However, if the charging target % is reached within 30 minutes, that time is set as the return time (step S62).
  • the return time is input by the return time acquisition unit 11b.
  • the time input by the vehicle user via the mobile terminal 4 as the return time is set (step S63).
  • a list of update information for example, as shown in FIG. 7, may be presented to the vehicle user on the display 4a of the mobile terminal 4.
  • items in the list of update information may include the update software (SW) name, update time, update priority information, and the number of update waits (see FIG. 11).
  • Input may be made by voice, touch input, or the like. Input may also be made using an HMI (Human Machine Interface) other than the mobile terminal 4. For example, a personal computer keyboard, mouse, etc. may be used.
  • HMI Human Machine Interface
  • the return time estimation unit 11a automatically sets a return time estimated from the current location and the vehicle user's behavioral patterns (step S64).
  • SW name indicates the software in ECUs 7a1 to 7an. For ease of explanation, only four are listed here, but there may be as many software as there are ECUs, and two or more pieces of software may be executed on one ECU.
  • Update time indicates the time it takes to update the software, and update priority information is displayed in three priority levels - high, medium, and low - taking into account the urgency of the update and the period during which updates have not been performed, but is not limited to these.
  • the combination of these items may be changed as appropriate depending on the needs of the vehicle user.
  • the vehicle user can confirm the program update time and can change the return time as appropriate.
  • the list of update information in FIG. 7 may be communicated to the vehicle user by displaying it on a monitor, an audio notification through a speaker, or the like.
  • FIG. 8 is a flowchart showing the operation of the update schedule creation unit 12.
  • the update schedule creation unit 12 operates based on input from the update allowable time acquisition unit 11.
  • the update schedule may be created by the vehicle user selecting the SW programs to be updated by referring to the list of update information in FIG. 7 described above (step S81), or, if the vehicle user does not select the update targets, the update schedule may be created according to the determination of the update priority determination unit 13 described below (step S82).
  • FIG 9 is a flowchart showing the operation of the update priority determination unit 13. If the list of update information described in Figure 7 does not include update priority information, it sends a message to that effect to the update schedule creation unit 12.
  • the update schedule creation unit refers only to the update time, sets the specified time provided by the return time estimation unit 11a or the return time acquisition unit 11b as the update allowable time, and creates an update schedule so that it falls within this time (step S91).
  • the update priority information is included, it refers to the update priority of each software program, selects a combination of update times for the software programs, and creates an update schedule (steps S92, S93). At this time, if there are overlapping priorities in the update priority information, it creates an update schedule taking into account the number of update waits (step S92).
  • the update schedule is created by the update allowable time acquisition unit 11, the update schedule creation unit 12, and the update priority determination unit 13, and specifically, the update operation is performed as in the following examples by combining the steps described in the above flowchart. Note that representative examples 2 and 8 are shown in Figures 10 and 11.
  • Example 1 (1) When the vehicle is parked, the vehicle user is notified that an update is available by displaying or an audio message on the mobile terminal 4 or the HMI in the vehicle. (2) The vehicle user permits the update by operating the portable terminal 4 or the HMI. (3) Since the vehicle is undergoing rapid charging, the vehicle user selects SW programs to be updated within a 30-minute range from a list of update information displayed on the mobile terminal 4 or the HMI in the vehicle, and creates an update schedule.
  • Example 2 (1) and (2) are the same as in Example 1. (3)
  • the vehicle is in a quick charge state, and the update schedule creation unit 12 refers only to the update time within a range of 30 minutes, selects SW programs to be updated, and creates an update schedule as shown in Fig. 10.
  • Fig. 10 there are two combinations of SW that can be updated within 30 minutes, the combination of YYSW and XXSW and the combination of XYSW and XXSW, and the combination of XYSW and XXSW (total of 28 minutes) is selected so as to be closer to 30 minutes.
  • Example 3 (1) and (2) are the same as in Example 1. (3) The vehicle is undergoing rapid refueling, and within a 30-minute range, the update schedule creation unit 12 creates an update schedule by referring to the update time as well as the update priority information determined by the update priority determination unit 13. Since there is no overlapping priority in the update priority information, an update schedule is selected according to the priority level of the update priority information.
  • Example 4 (1) and (2) are the same as in Example 1. (3) The vehicle is undergoing rapid refueling, and within a range of 30 minutes, the update schedule creation unit 12 creates an update schedule by referring to the update priority information determined by the update priority determination unit 13 in addition to the update time. Since there are overlapping levels of priority in the update priority information, the update schedule is created by further taking into consideration the number of update waits.
  • Example 5 (1) and (2) are the same as in Example 1. (3)
  • the vehicle user sets the return time before moving the vehicle, and selects the SW programs to be updated from a list of update information displayed on the mobile terminal 4 or the HMI in the vehicle to create an update schedule.
  • Example 6 (1) and (2) are the same as in Example 1. (3)
  • the vehicle user sets the return time. Within this range of the return time, the update schedule creation unit 12 refers only to the update time, selects the SW programs to be updated, and creates an update schedule.
  • Example 7 (1) and (2) are the same as in Example 1.
  • (3) The vehicle user sets the return time. Within this range of the return time, the update schedule creation unit 12 creates an update schedule by referring to the update time as well as the update priority information determined by the update priority determination unit 13. Since there is no overlapping priority in the update priority information, an update schedule is selected according to the priority level of the update priority information.
  • Example 8 (1) and (2) are the same as in Example 1.
  • (3) The vehicle user sets the return time (30 minutes in this example) by manually inputting, by voice input, or the like using the mobile terminal 4 or the vehicle's HMI.
  • the update schedule creation unit 12 creates an update schedule by referring to the update priority information determined by the update priority determination unit 13 in addition to the update time. At this time, as shown in Fig.
  • XXSW, YYSW, and XYSW overlap in the update priority stage of "medium", so YYSW that has been on update standby twice is selected in consideration of the number of times of update standby, and XXSW that can be updated in the time obtained by subtracting the update time of YYSW from 30 minutes is selected, and an update schedule is created.
  • Example 9 (1) and (2) are the same as in Example 1. (3) Since the vehicle user does not set a return time, an estimated return time is set by the return time estimation unit 11a. Within the range of the set return time, the vehicle user selects SW programs to be updated from a list of update information displayed on the mobile terminal 4 or the HMI in the vehicle, and creates an update schedule.
  • Example 10 (1) and (2) are the same as in Example 1. (3) Since the vehicle user does not set a return time, the return time estimation unit 11a sets an estimated return time. Within this range of return time, the update schedule creation unit 12 refers only to the update time, selects the SW program to be updated, and creates an update schedule.
  • Example 11 (1) and (2) are the same as in Example 1. (3) Since the vehicle user does not set a return time, the return time is set by the return time estimation unit 11a. Within this range of return time, the update schedule creation unit 12 creates an update schedule by referring to the update time and the update priority information determined by the update priority determination unit 13. Since there is no overlapping priority in the update priority information, an update schedule is selected according to the priority level of the update priority information.
  • Example 12 (1) and (2) are the same as in Example 1. (3) Since the vehicle user does not set a return time, the return time is set by the return time estimation unit 11a. Within this range of return time, the update schedule creation unit 12 creates an update schedule by referring to the update priority information determined by the update priority determination unit 13 in addition to the update time. Since there are overlapping priorities in the update priority information, the update schedule is created by further taking into consideration the update wait count.
  • a vehicle user who did not set a return time may check the created update schedule and delay the return time.
  • the vehicle user may select a SW program to update from a list of update information during the delayed time from the created update schedule, or the update schedule creation unit 12 may create an update schedule again.
  • this embodiment has the following advantages, and allows the user of the vehicle to select a program update according to his or her needs before the program is rewritten.
  • (A) Providing the return time estimation unit 11a in the update allowable time acquisition unit 11 allows the vehicle user to estimate the return time, and software updates can be performed without impairing the convenience of the vehicle user. Furthermore, providing the return time acquisition unit 11b allows the vehicle user to set the return time as desired, and software updates can be performed without waste. And, having the quick charge determination unit 11c, the return time estimation unit 11a, the return time acquisition unit 11b, and multiple return time acquisition methods allows the return time to be acquired without impairing the convenience of the user.
  • the return time estimation unit 11a By having the return time estimation unit 11a, the return time can be estimated from the vehicle side without any input from the vehicle user, which leads to an improved user experience.
  • the update schedule creation unit 12 By providing the update schedule creation unit 12, the occurrence rate of update rollbacks can be reduced, making it possible to perform updates safely for both the vehicle and the vehicle user.
  • the update schedule creation unit 12 can automatically create an update schedule, and can efficiently perform program updates that fit within the acquired return time.
  • the updates By allowing the user to select inputs for creating an update schedule, the updates can be performed in order starting from the SW programs that are most necessary for the vehicle user.
  • the update priority determination unit 13 can perform updates based on update priorities, and SW programs that have not been updated for a long time can be given priority for update.
  • 1 In-vehicle system
  • 2 File server
  • 3 Web server
  • 4 Mobile terminal
  • 5 Communication interface
  • 7a1 ECU
  • 8 Gateway device
  • 9a1 Bus
  • 10 DCM
  • 100 Processor
  • 200 Storage device.

Landscapes

  • Engineering & Computer Science (AREA)
  • Mechanical Engineering (AREA)
  • Stored Programmes (AREA)

Abstract

車両内で使用されている複数のソフトウェアプログラムを更新するための車載診断装置において、ソフトウェアプログラムの更新を開始する前にソフトウェアプログラムを更新するための更新許容時間を取得する更新許容時間取得部（１１）、取得した更新許容時間内で更新可能なソフトウェアプログラムを選択して更新スケジュールを作成する更新スケジュール作成部（１２）、作成した更新スケジュールに基づいて更新を行う更新制御部（１４）、を備え、ソフトウェアプログラムの書換えの実行前に車両ユーザのニーズに応じたプログラムの更新を選択できる。

Description

車載診断装置およびプログラム更新方法
　本願は、車載診断装置およびプログラム更新方法に関する。
　無線通信技術を用いて車内ネットワークを経由して電子制御装置（Electronic Control Unit：ＥＣＵ）などのプログラムを更新することが可能である。しかし、車両ユーザがプログラムを更新途中にも拘わらず、車両を運転操作してしまいプログラムの書換え処理が中断し、プログラムの更新が不十分なままとなり車両が意図しない挙動をしてしまう虞がある。このための対策のひとつとして、プログラム更新中の場合に車両ユーザに運転できない旨の情報を携帯端末などの表示により報知する車両用装置が知られている（例えば、特許文献１参照）。
特許第６４１４５６８号公報
　しかしながら、従来の車両用装置では、プログラムの書換えのために必要な時間が、プログラムの書換えを実行した後の進捗状況の表示で把握することはできるが、プログラムの書換えの実行前に書換え完了の予測時間を知ることができない。さらに、運転待機時間が短い時間しかない場合、緊急度の高いプログラムのみを選択して更新したいという車両ユーザのニーズに応えることができないという問題点があった。
　本願は、上述のような課題を解決するためになされたもので、ソフトウェアプログラムの更新の実行前に車両ユーザのニーズに応じたソフトウェアプログラムを選択して更新できる車載診断装置およびプログラム更新方法を提供することを目的とする。
　本願に開示される車載診断装置は、車両内で使用されている複数のソフトウェアプログラムを更新するためのものであって、ソフトウェアプログラムの更新を開始する前にソフトウェアプログラムを更新するための更新許容時間を取得する更新許容時間取得部、取得した更新許容時間内で更新可能なソフトウェアプログラムを選択して更新スケジュールを作成する更新スケジュール作成部、作成した更新スケジュールに基づいて更新を行う更新制御部、を備えたことを特徴とする。
　　本願に開示される車載診断装置によれば、ソフトウェアプログラムの更新の実行前に車両ユーザのニーズに応じたソフトウェアプログラムを選択して更新できる。
実施の形態１に係る車載診断装置の機能ブロック図である。 実施の形態１に係る車載診断装置のゲートウェイ装置及びＥＣＵ内のマイコンのハードウェアの一例を示す図である。 実施の形態１に係るゲートウェイ装置内で実行される更新対象のプログラム更新に関する機能ブロック図である。 実施の形態１に係る更新許容時間取得部の機能ブロック図である。 実施の形態１に係る車載診断装置のプログラム更新の動作を説明するフローチャートである。 実施の形態１に係る更新許容時間取得部の動作を示すフローチャートである。 実施の形態１に係る更新情報の一覧を説明する図である。 実施の形態１に係る更新スケジュール作成部の動作を示すフローチャートである。 実施の形態１に係る更新優先度判定部の動作を示すフローチャートである。 実施の形態１に係る実施例２を説明する図である。 実施の形態１に係る実施例８を説明する図である。
　以下、本願に係る車載診断装置の好適な実施の形態について、図面を参照して説明する。なお、同一内容および相当部については同一符号を配し、その詳しい説明は省略する。
実施の形態１．
　図１は実施の形態１に係る車載診断装置の機能ブロック図である。図において、車両に搭載される車両内システム１、ファイルサーバ２、ウェブサーバ３、車両ユーザにより所持されウェブサーバ３に接続可能な携帯端末４が接続されている。
　ファイルサーバ２とウェブサーバ３とはネットワーク接続されるとともにファイルサーバ２とウェブサーバ３はそれぞれ通信インタフェース（Ｉ／Ｆ）５、通信Ｉ／Ｆ６を経由して車両内システム１と送受信可能である。ファイルサーバ２にはプログラム更新用ファイルが蓄積され、更新を要する車両内システム１のＥＣＵ７ａ１～７ａｎ（ｎは自然数）に更新用ファイルを送信するプログラム管理機能を備えている。車外ネットワーク３０は、例えば４Ｇ、５Ｇ回線などの移動通信網、インターネット網、無線ＬＡＮなどの各種通信ネットワークである。
　車両内システム１は、ゲートウェイ装置８、ゲートウェイ装置８に接続される車載ＬＡＮのバス９ａ１～９ａｍ（ｍは自然数）、バス９ａ１～９ａｍに接続されるＤＣＭ（Data Communication Module）１０、またはＥＣＵ７ａ１～７ａｎを備えている。ＤＣＭ１０は通信Ｉ／Ｆ５、６および携帯端末４と無線を介して通信するためのものである。
　バス９ａ１～９aｍは、互いに通信プロトコルが異なるまたは同一となる複数のネットワークに構築されており、例えば走行系ネットワークはバス９ａ１、マルチメディア系ネットワークはバス９ａ２などネットワークごと割り当てられており、それぞれのバスにＥＣＵ７ａ１～７ａｎが接続されている。なお、図中、各バスに１つのＥＣＵしか接続されていないが、実際には複数のＥＣＵが接続されている。例えば走行系ネットワークのバス９ａ１には、エンジンを制御するための各種機能を備えるエンジンＥＣＵ、ブレーキを制御する各種機能を備えるブレーキＥＣＵ、パワーステアリングを制御するパワステＥＣＵなど複数のＥＣＵが接続されている。他のネットワークのバスも同様に複数のＥＣＵが接続されている。エンジンＥＣＵには、車速センサ、スロットル開度センサ、アクセルペダル開度センサなどが接続され、ブレーキＥＣＵには、ブレーキペダルセンサが接続されている。以下の説明では、説明の簡略化のため、それぞれのバス９ａ１～９ａｍに１つのＥＣＵ７ａ１～７ａｎが接続されている状態で説明を行う。
　ゲートウェイ装置８、及びＥＣＵ７ａ１～７ａｎ内のマイコンのハードウェアの一例を図２に示す。プロセッサ１００と記憶装置２００から構成され、図示していないが、記憶装置はランダムアクセスメモリ等の揮発性記憶装置と、フラッシュメモリ等の不揮発性の補助記憶装置とを具備する。また、フラッシュメモリの代わりにハードディスクの補助記憶装置を具備してもよい。プロセッサ１００は、記憶装置２００から入力されたプログラムを実行することにより、以後に述べるそれぞれの機能を実行する。この場合、補助記憶装置から揮発性記憶装置を介してプロセッサ１００にプログラムが入力される。また、プロセッサ１００は、演算結果等のデータを記憶装置２００の揮発性記憶装置に出力してもよいし、揮発性記憶装置を介して補助記憶装置にデータを保存してもよい。それぞれのＥＣＵ７ａ１～７ａｎに入力されるプログラムは不具合の改修、バージョンアップ、新たな機能の追加などのために更新が必要となる。
　図３は、ゲートウェイ装置８内で実行される更新対象１５のソフトウェア（ＳＷ）プログラム更新に関する機能ブロック図である。更新許容時間取得部１１は、図４で示すように、帰車時間推定部１１ａ、帰車時間取得部１１ｂ、急速充電判定部１１ｃを有し、更新許容時間を取得する。更新スケジュール作成部１２は、更新許容時間取得部１１で取得された更新許容時間に基づいて更新スケジュールを作成する。更新優先度判定部１３は更新スケジュール作成部１２からの問い合わせに応じ、更新優先度情報を元に、更新対象１５の更新プログラムの優先度を判定し、判定結果を更新スケジュール作成部１２に送信する。更新スケジュール作成部１２で作成されたプログラム更新スケジュールは、更新制御部１４に送られ、プログラム更新スケジュールに基づいて更新対象のＳＷプログラムが更新される。更新対象１５は、本実施の形態では、ＥＣＵ７ａ１～７ａｎ内の各ＳＷプログラム、ＸＸＳＷ、ＹＹＳＷ、ＺＺＳＷ、ＸＹＳＷとして説明するが、これに限るものではない。
　図５は、ＳＷプログラム更新の全体動作を説明するフローチャートである。更新許可（ステップＳ５１）は車両ユーザによって行われ、車両ユーザが更新を許可しない場合、フローは終了する（ステップＳ５２）。車両ユーザが更新を許可した場合、上述したように、更新許容時間取得部１１で更新許容時間を取得し（ステップＳ５３）、これを元に更新スケジュール作成部１２で更新スケジュールを作成し（ステップＳ５４）、作成した更新スケジュールに基づいて更新制御部１４が更新対象のＳＷプログラムの更新を開始する（ステップＳ５５）。
　図６は、図４の機能ブロック図で説明した更新許容時間取得部１１の動作を示したフローチャートである。まず、車両が急速充電中であるか否かを急速充電判定部１１ｃで判定する（ステップＳ６１）。車両が電気自動車の場合、充電には急速充電と普通充電の２通りがある。急速充電中の場合、１回の充電時間は３０分が上限となっている。このため、帰車時間を３０分と設定する（ステップＳ６２）。ただし、充電目標％に３０分以内に到達する場合、その時間を帰車時間として設定する（ステップＳ６２）。
　急速充電中でない場合、帰車時間の入力を帰車時間取得部１１ｂにより行う。例えば、車両ユーザが帰車時間を携帯端末４により入力した時間を設定する（ステップＳ６３）。帰車時間の入力に際し、車両ユーザに、例えば図７に示す更新情報の一覧を携帯端末４の表示器４ａに提示してもよい。更新情報の一覧の項目の一例として、更新ソフトウェア（ＳＷ）名、更新時間、更新優先度情報、更新待機回数（図１１参照）などを含んでもよい。入力は、音声、タッチ入力などで行ってもよい。また携帯端末４以外のＨＭＩ（Human Machine Interface）を使って入力してもよい。例えば、パソコンのキーボード、マウス等でもよい。
　車両ユーザから帰車時間が設定されなかった場合、帰車時間推定部１１ａにより、現在地、車両ユーザの行動パターンから推測される帰車時間を自動で設定する（ステップＳ６４）。
　更新情報の一覧の項目のうち、ＳＷ名は、ＥＣＵ７ａ１～７ａｎ内のソフトウェアを示す。ここでは説明の便宜のため、４つのみを記載しているが、ＥＣＵの数だけソフトウェアが存在し、１つのＥＣＵで２つ以上のソフトウェアが実行されていてもよい。更新時間は、ソフトウェアを更新するまでにかかる時間、更新優先度情報は、更新の緊急度、更新をしていない期間などを勘案して、高、中、低の３つの段階の優先度で表示されているがこれに限るものではない。
　これら項目の組合せは車両ユーザのニーズにより適宜組合せを変更してもよい。このような更新情報の一覧を車両ユーザが確認することでプログラムの更新時間を確認でき、帰車時間の変更を適宜行うことができる。図７の更新情報の一覧は、モニタへの表示、スピーカによる音声報知などを利用することで車両ユーザに伝達してもよい。
　図８は、更新スケジュール作成部１２の動作を示すフローチャートである。更新スケジュール作成部１２は、更新許容時間取得部１１からの入力に基づいて動作する。更新スケジュールは上述した図７の更新情報の一覧を参照して車両ユーザが更新対象のＳＷプログラムを選択して更新スケジュールを作成してもよく（ステップＳ８１）、車両ユーザが更新対象を選択しない場合、後述する更新優先度判定部１３の判定に従って更新スケジュールを作成してもよい（ステップＳ８２）。
　図９は、更新優先度判定部１３の動作を示すフローチャートである。図７で説明した更新情報の一覧に更新優先度情報を含まない場合、更新スケジュール作成部１２にその旨を送信する。更新スケジュール作成部は更新時間のみを参照し帰車時間推定部１１ａまたは帰車時間取得部１１ｂより提供された指定時間を更新許容時間とし、この時間内に収まるように更新スケジュールを作成する（ステップＳ９１）。更新優先度情報を含む場合、各ソフトウェアプログラムの更新優先度を参照してソフトウェアプログラムの更新時間の組合せを選択し、更新スケジュールを作成する（ステップＳ９２、Ｓ９３）。この時、更新優先度情報に被る優先度が存在する場合、更新待機回数を考慮して更新スケジュールを作成する（ステップＳ９２）。
　以上のように、更新スケジュールの作成は、更新許容時間取得部１１、更新スケジュール作成部１２、更新優先度判定部１３により、上述のフローチャートで説明したステップの組合せにより、具体的には以下の実施例のような更新動作を実行する。なお、代表的な実施例２および実施例８を図１０、図１１に示している。
[実施例１]
（１）車両を駐車した際に、車両から更新がある旨を携帯端末４あるいは車両内のＨＭＩに表示または音声で報知することで、車両ユーザに通知する。
（２）車両ユーザは携帯端末４またはＨＭＩを操作することにより更新を許可する。
（３）車両は急速充電中のため、３０分の範囲で携帯端末４あるいは車両内のＨＭＩに表示された更新情報の一覧から車両ユーザが更新対象のＳＷプログラムを選択して更新スケジュールを作成する。
[実施例２]
（１）、（２）は実施例１と同じ。
（３）車両は急速充電中で、３０分の範囲で、更新スケジュール作成部１２が更新時間のみを参照し、更新対象のＳＷプログラムを選択して図１０に示すように更新スケジュールを作成する。図１０においては、３０分以内で更新可能なＳＷの組合せとして、ＹＹＳＷとＸＸＳＷの組合せ、ＸＹＳＷとＸＸＳＷの組合せの２通りがあるが、３０分により近くなるようにＸＹＳＷとＸＸＳＷの組合せ（合計２８分）を選択している。
[実施例３]
（１）、（２）は実施例１と同じ。
（３）車両は急速充填中で、３０分の範囲で、更新スケジュール作成部１２が、更新時間に加え、更新優先度判定部１３で判定された更新優先度情報を参照して更新スケジュールを作成する。更新優先度情報に被る優先度が存在しないため、更新優先度情報の優先度の段階に従い更新スケジュールを選択する。
[実施例４]
（１）、（２）は実施例１と同じ。
（３）車両は急速充填中で、３０分の範囲で、更新スケジュール作成部１２が更新時間に加え、更新優先度判定部１３で判定された更新優先度情報を参照して更新スケジュールを作成する。更新優先度情報に被る段階の優先度が存在するため、更新待機回数をさらに考慮して更新スケジュールを作成する。
[実施例５]
（１）、（２）は実施例１と同じ。
（３）車両ユーザが車両の移動を行うまでの帰車時間を設定するとともに、携帯端末４あるいは車両内のＨＭＩに表示された更新情報の一覧から車両ユーザが更新対象のＳＷプログラムを選択して更新スケジュールを作成する。
[実施例６]
（１）、（２）は実施例１と同じ。
（３）車両ユーザが帰車時間を設定する。この帰車時間の範囲で更新スケジュール作成部１２が更新時間のみを参照し、更新対象のＳＷプログラムを選択して更新スケジュールを作成する。
[実施例７]
（１）、（２）は実施例１と同じ。
（３）車両ユーザが帰車時間を設定する。この帰車時間の範囲で更新スケジュール作成部１２が、更新時間に加え、更新優先度判定部１３で判定された更新優先度情報を参照して更新スケジュールを作成する。更新優先度情報に被る優先度が存在しないため、更新優先度情報の優先度の段階に従い更新スケジュールを選択する。
[実施例８]
（１）、（２）は実施例１と同じ。
（３）車両ユーザが携帯端末４あるいは車両のＨＭＩを使い手入力、音声入力などで帰車時間（ここでは３０分）を設定する。設定した帰車時間の範囲で更新スケジュール作成部１２が、更新時間に加え、更新優先度判定部１３で判定された更新優先度情報を参照して更新スケジュールを作成する。この時、図１１に示すように、更新対象のソフトウェアの内、ＸＸＳＷ、ＹＹＳＷおよびＸＹＳＷは更新優先度の段階が「中」と被るので、更新待機回数を考慮して、２回更新待機を行っているＹＹＳＷを選択し、ＹＹＳＷの更新時間を３０分から差し引いた時間で更新できるＸＸＳＷを選択して更新スケジュールを作成する。
[実施例９]
（１）、（２）は実施例１と同じ。
（３）車両ユーザが帰車時間を設定しないので、帰車時間推定部１１ａにより推定した帰車時間を設定する。この設定された帰車時間の範囲で携帯端末４あるいは車両内のＨＭＩに表示された更新情報の一覧から車両ユーザが更新対象のＳＷプログラムを選択して更新スケジュールを作成する。
[実施例１０]
（１）、（２）は実施例１と同じ。
（３）車両ユーザが帰車時間を設定しないので、帰車時間推定部１１ａにより推定した帰車時間を設定する。この帰車時間の範囲で更新スケジュール作成部１２が更新時間のみを参照し、更新対象のＳＷプログラムを選択して更新スケジュールを作成する。
[実施例１１]
（１）、（２）は実施例１と同じ。
（３）車両ユーザが帰車時間を設定しないので、帰車時間推定部１１ａにより帰車時間を設定する。この帰車時間の範囲で更新スケジュール作成部１２が、更新時間に加え、更新優先度判定部１３で判定された更新優先度情報を参照して更新スケジュールを作成する。更新優先度情報に被る優先度が存在しないため、更新優先度情報の優先度の段階に従い更新スケジュールを選択する。
[実施例１２]
（１）、（２）は実施例１と同じ。
（３）車両ユーザが帰車時間を設定しないので、帰車時間推定部１１ａにより帰車時間を設定する。この帰車時間の範囲で更新スケジュール作成部１２が、更新時間に加え、更新優先度判定部１３で判定された更新優先度情報を参照して更新スケジュールを作成する。更新優先度情報に被る段階の優先度が存在するため、更新待機回数をさらに考慮して更新スケジュールを作成する。
　上述した実施例は一例であり、車両ユーザの環境、その時々の状況に応じて、それぞれの実施例を組合わせたり、新たな動作が加えられたりする。例えば実施例１０～１２において、帰車時間を設定しなかった車両ユーザが作成された更新スケジュールを確認して帰車時間を遅らせるようなことがある。この場合は、作成された更新スケジュールから遅らせた時間の間に車両ユーザが更新情報の一覧から更新するＳＷプログラムを選択する場合もあるし、再度、更新スケジュール作成部１２により更新スケジュールが作成される場合もある。
　以上のように本実施の形態によれば次のようなメリットがあり、プログラムの書換えの実行前に車両ユーザのニーズに応じたプログラムの更新を選択できる。
（ア）更新許容時間取得部１１に帰車時間推定部１１ａを備えたことにより帰車時間推定を行うことができ、車両ユーザの利便性を損ねずソフトウェア更新が行える。さらに、帰車時間取得部１１ｂを備えることにより車両ユーザが任意に帰車時間を設定可能で無駄のないソフトウェア更新が行える。そして、急速充電判定部１１ｃ、帰車時間推定部１１ａ、帰車時間取得部１１ｂ、複数の帰車時間取得方法を有することにより、ユーザの利便性を損ねず帰車時間取得を行うことができる。
（イ）また、帰車時間推定部１１ａを有することにより車両ユーザの入力なしで車両側から帰車時間の推定を行うことができ、ユーザエクスペリエンス向上に繋がる。
（ウ）更新スケジュール作成部１２を備えたことにより更新のロールバック発生率を下げ、車両にも車両ユーザにも安全に更新を行うことができる。
（エ）更新スケジュール作成部１２により、更新スケジュールを自動で作成することができ、取得した帰車時間内に収まるプログラムの更新を効率的に行うことができる。
（オ）更新スケジュール作成にユーザ入力を選択できることにより車両ユーザにとって必要の高い更新対象のＳＷプログラムから順に更新を行うことができる。
（カ）更新優先度判定部１３により更新優先度に基づいて更新を行うことができ、長時間更新が行えていない更新対象のＳＷプログラムを優先して更新を行うことができる。
　本願は、例示的な実施の形態が記載されているが、実施の形態に記載された様々な特徴、態様、及び機能は特定の実施の形態の適用に限られるのではなく、単独で、または様々な組合せで実施の形態に適用可能である。
　従って、例示されていない無数の変形例が、本願明細書に開示される技術の範囲内において想定される。例えば、少なくとも１つの構成要素を変形する場合、追加する場合または省略する場合が含まれるものとする。
　１：車両内システム、２：ファイルサーバ、３：ウェブサーバ、４：携帯端末、５、６：通信インタフェース、７ａ１：ＥＣＵ、８：ゲートウェイ装置、９ａ１：バス、１０：ＤＣＭ、１００：プロセッサ、２００：記憶装置。

Claims (10)

  1. 　車両内で使用されている複数のソフトウェアプログラムを更新するための車載診断装置において、前記ソフトウェアプログラムの更新を開始する前に前記ソフトウェアプログラムを更新するための更新許容時間を取得する更新許容時間取得部、取得した前記更新許容時間内で更新可能なソフトウェアプログラムを選択して更新スケジュールを作成する更新スケジュール作成部、作成した更新スケジュールに基づいて更新を行う更新制御部、を備えた車載診断装置。
  2. 　前記更新許容時間取得部は、車両が急速充電を行っているか否かを判定する急速充電判定部、車両ユーザが次に前記車両の移動を行うまでの帰車時間を入力する帰車時間取得部、車両ユーザが次に車両の移動を行う帰車時間を推定する帰車時間推定部、を有し、いずれかの出力に基づいて前記更新許容時間を決定することを特徴とする請求項１に記載の車載診断装置。
  3. 　前記急速充電判定部の出力に基づいて前記更新許容時間を決定する場合、急速充電が終了するまでの時間内となるように複数のソフトウェアプログラムの更新時間を組合せて更新スケジュールを作成することを特徴とする請求項２に記載の車載診断装置。
  4. 　前記帰車時間取得部の出力に基づいて前記更新許容時間を決定する場合、入力された帰車時間内となるように複数のソフトウェアプログラムの更新時間を組合せて更新スケジュールを作成することを特徴とする請求項２に記載の車載診断装置。
  5. 　前記帰車時間推定部の出力に基づいて前記更新許容時間を決定する場合、推定された前記帰車時間内となるように複数のソフトウェアプログラムの更新時間を組合せて更新スケジュールを作成することを特徴とする請求項２に記載の車載診断装置。
  6. 　前記帰車時間取得部は携帯端末または車両に搭載されたＨＭＩを通して前記帰車時間が入力されることを特徴とする請求項４に記載の車載診断装置。
  7. 　前記帰車時間取得部に前記帰車時間を入力する場合、更新する前記ソフトウェアプログラムの名前、前記ソフトウェアプログラムの更新時間、および更新ソフトウェアプログラムの更新優先度の一覧を前記携帯端末または前記ＨＭＩに表示することを特徴とする請求項６に記載の車載診断装置。
  8. 　複数のソフトウェアプログラムの更新時間を組合わせて更新スケジュールを作成する場合、更新優先度判定部で判定した各ソフトウェアプログラムの更新優先度を参照して前記ソフトウェアプログラムの更新時間の組合せを選択することを特徴とする請求項１から７のいずれか１項に記載の車載診断装置。
  9. 前記更新優先度は段階別に設定されており、更新優先度が同じものが複数存在する場合は、前記各ソフトウェアプログラムの更新待機回数が最も多いソフトウェアプログラムを選択して組合わせることを特徴とする請求項８に記載の車載診断装置。
  10. 　車両内で使用されている複数のソフトウェアプログラムを更新する車載診断方法において、前記ソフトウェアプログラムの更新を開始する前に前記ソフトウェアプログラムを更新するための更新許容時間を取得し、取得した前記更新許容時間内で更新可能なソフトウェアプログラムを選択して更新スケジュールを作成し、作成した更新スケジュールに基づいて更新を行うプログラム更新方法。
PCT/JP2022/041198 2022-11-04 2022-11-04 車載診断装置およびプログラム更新方法 WO2024095463A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/041198 WO2024095463A1 (ja) 2022-11-04 2022-11-04 車載診断装置およびプログラム更新方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/041198 WO2024095463A1 (ja) 2022-11-04 2022-11-04 車載診断装置およびプログラム更新方法

Publications (1)

Publication Number Publication Date
WO2024095463A1 true WO2024095463A1 (ja) 2024-05-10

Family

ID=90929955

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/041198 WO2024095463A1 (ja) 2022-11-04 2022-11-04 車載診断装置およびプログラム更新方法

Country Status (1)

Country Link
WO (1) WO2024095463A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011161778A1 (ja) * 2010-06-23 2011-12-29 トヨタ自動車株式会社 プログラム更新装置
JP2015127887A (ja) * 2013-12-27 2015-07-09 キヤノン株式会社 画像形成装置、その制御方法とプログラム
WO2020203023A1 (ja) * 2019-03-29 2020-10-08 マツダ株式会社 自動車用演算装置
JP2021047637A (ja) * 2019-09-18 2021-03-25 日立オートモティブシステムズ株式会社 プログラム更新装置及びプログラム更新方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011161778A1 (ja) * 2010-06-23 2011-12-29 トヨタ自動車株式会社 プログラム更新装置
JP2015127887A (ja) * 2013-12-27 2015-07-09 キヤノン株式会社 画像形成装置、その制御方法とプログラム
WO2020203023A1 (ja) * 2019-03-29 2020-10-08 マツダ株式会社 自動車用演算装置
JP2021047637A (ja) * 2019-09-18 2021-03-25 日立オートモティブシステムズ株式会社 プログラム更新装置及びプログラム更新方法

Similar Documents

Publication Publication Date Title
US7660799B2 (en) Remote desktop system
CN113424255A (zh) 引导车辆客户端设备使用设备上的功能
CN1961307A (zh) 用于渐进式安装软件应用程序的系统和方法以及api
CN111399884A (zh) 一种车辆组件的升级方法、装置及电子设备
US20080256510A1 (en) Method And System For Generating Automatically Distributable Clients Of Application Servers
CN110114761B (zh) 软件更新装置和软件更新系统
US20070169129A1 (en) Automated application configuration using device-provided data
CN101211272A (zh) 动态虚拟机生成
CN101689169B (zh) 分布式操作系统中外部硬件装置的管理
JP2001249907A (ja) 起動処理方式
JPWO2008114454A1 (ja) 更新システム、プログラム実行装置及びコンピュータプログラム
JPH10177473A (ja) コンピュータ・プログラムのインストール方法及びシステム
US8301773B2 (en) Server management program, server management method, and server management apparatus
Axelsson et al. On the conceptual design of a dynamic component model for reconfigurable AUTOSAR systems
CN111527389A (zh) 一种车辆诊断方法及一种车辆诊断设备和存储介质
CN114637598A (zh) 车辆控制器及其操作系统的调度方法
CN115167831A (zh) 基于autosar的软件集成方法、设备和使用方法
JP2000509524A (ja) 実行時変更伝達を制御する方法および装置
WO2024095463A1 (ja) 車載診断装置およびプログラム更新方法
JP2012043161A (ja) プリンタドライバ更新プログラムおよびプリンタドライバ更新方法
JP2009163602A (ja) 設計システム用配信システム、設計システム配信サーバ、及びクライアントシステム
US20090177755A1 (en) Script serving apparatus and method
JP4753623B2 (ja) 車両制御用プログラム及び車両用電子制御装置
CN114356555A (zh) 编程方法及相关装置
CN115220861A (zh) 虚拟客户机管理方法、装置、介质和设备