CN117640704A - 服务器、软件更新***及更新方法、非暂时性存储介质 - Google Patents

Abstract

本发明涉及服务器、软件更新***、软件更新方法、非暂时性存储介质，该服务器包括：请求部，构成为能够向搭载于车辆的第1终端和能够由上述车辆的用户携带的第2终端请求是否同意搭载于上述车辆的控制装置的软件的更新所涉及的处理的回复；和受理部，构成为在接受到来自上述第1终端的上述回复和来自上述第2终端的上述回复双方作为对上述请求的响应的情况下，使来自上述第2终端的回复无效，使来自上述第1终端的回复有效。

Description

服务器、软件更新***及更新方法、非暂时性存储介质

技术领域

本公开涉及服务器、软件更新***、软件更新方法以及非暂时性存储介质。

背景技术

在日本特开2017－149323中公开了一种通过OTA(Over The Air：空中下载)来更新被搭载于车辆的控制装置的软件的技术。

日本特开2017－149323中记载的服务器向智能手机请求是否同意软件的更新的回复，若从智能手机接受到同意的回复，则执行新的软件(软件的更新版)的下载。智能手机相当于能够由车辆的用户携带的终端(以下，亦称为“便携终端”)。

然而，作为用于进行上述回复的HMI(Human Machine Interface)，便携终端未必最好。例如，当乘车中的用户在车辆的驾驶的间歇进行用于上述回复的操作的情况下，与操作便携终端相比，存在操作被搭载于车辆的终端(以下，亦称为“车载终端”)的误操作少的趋势。基于误操作执行用户不希望的软件更新所涉及的处理(例如下载)会大幅破坏用户的便利性。另一方面，若将用于进行上述回复的HMI限定为车载终端，则当用户未乘车时无法进行OTA下的上述回复。该情况下，也会导致用户的便利性的降低。

发明内容

本公开提供在软件更新中既确保足够的用户的便利性、又抑制因误操作而执行用户不希望的软件更新所涉及的处理的技术。

本发明的第一方式所涉及的服务器具备请求部和受理部。请求部构成为向搭载于车辆的第1终端和能够由车辆的用户携带的第2终端请求是否同意搭载于车辆的控制装置的软件的更新所涉及的处理的回复。受理部构成为在接受到来自第1终端的回复和来自第2终端的回复双方作为对上述请求的响应的情况下，使来自第2终端的回复无效，使来自第1终端的回复有效。

上述服务器向车载终端(第1终端)和便携终端(第2终端)请求是否同意搭载于车辆的控制装置的软件的更新所涉及的处理的回复。因此，用户能够为了上述回复而选择使用车载终端与便携终端中的哪一个。由此，容易确保足够的用户的便利性。另外，在从车载终端和便携终端双方接受到对于上述请求的回复的情况下，上述服务器使来自便携终端的回复无效，使来自车载终端的回复有效。在车载终端和便携终端双方进行了回复的情况下，便携终端涉及的回复是基于误操作的回复的可能性高。鉴于此，通过使来自便携终端的回复无效，使来自车载终端的回复有效，能够抑制因误操作而执行用户不希望的软件更新所涉及的处理。

在上述方式中，受理部可以构成为决定受理对于请求的回复的受理期间。受理部可以构成为当受理部在受理期间内接受到来自第1终端的回复和来自第2终端的回复双方的情况下，基于来自第1终端的回复来决定是否下载软件。

根据上述结构，在软件更新中，能够既确保足够的用户的便利性、又抑制因误操作而执行用户不希望的下载。例如，用户在误操作了便携终端的情况下，通过在受理期间内使用车载终端来进行正确的回复，能够使基于误操作的回复无效化。

在上述方式中，受理部可以构成为当受理部在受理期间内接受到来自第1终端的回复的情况下，不等待受理期间的经过就基于来自第1终端的回复来决定是否下载软件。受理部可以构成为当受理部在受理期间内接受到来自第2终端的回复且受理部未接受到来自第1终端的回复而经过了受理期间的情况下，基于来自第2终端的回复来决定是否下载软件。

根据上述结构，从第1终端涉及的回复至下载开始为止的时滞(响应延迟)变小。另外，在未接受到来自第1终端的回复而从第2终端接受到回复的情况下，服务器能够基于来自第2终端的回复来决定是否下载软件。由此，用户的便利性提高。

在上述方式中，受理部可以构成为当受理部在受理期间内从位于车辆之外的第2终端接受到回复的情况下，不等待受理期间的经过就基于来自第2终端的回复来决定是否下载软件。

根据上述结构，从第2终端涉及的回复至下载开始为止的时滞(响应延迟)变小。在进行了回复的第2终端存在于车外的情况下，用户位于车外的可能性高，搭载于车辆的终端***作的可能性低。

在上述方式中，受理部可以构成为基于软件的更新的内容来决定受理期间。受理部可以构成为在从第1终端以及第2终端的任一个均未接受到回复而经过了受理期间的情况下，不下载软件。

根据上述结构，在没有回复的状态下经过了受理期间的情况下，不下载软件。由此，即便用户不进行拒绝的回复亦可。另外，通过服务器根据软件的更新的内容来决定受理期间，容易使受理期间成为适当的长度。例如在被推荐早期更新的软件的更新中，服务器可以延长受理期间而使用户容易同意。

本发明的第二方式所涉及的软件更新***具备：车辆；第1终端，被搭载于车辆；第2终端，能够由车辆的用户携带；以及服务器。服务器构成为向第1终端和第2终端请求是否同意搭载于车辆的控制装置的软件的更新所涉及的处理的回复。第1终端和第2终端分别构成为向用户催促对于上述请求表示同意和拒绝中的哪一个的操作。第1终端和第2终端分别构成为在由用户进行了上述操作的情况下，对于服务器进行与该操作相应的回复。服务器构成为在接受到来自第1终端的回复和来自第2终端的回复双方的情况下，使来自第2终端的回复无效，使来自第1终端的回复有效。

通过上述软件更新***，也与上述的服务器同样，能够在软件更新中既确保足够的用户的便利性、又抑制因误操作而执行用户不希望的软件更新所涉及的处理。

本发明的第三方式所涉及的软件更新方法由计算机执行。软件更新方法包括：向搭载于车辆的第1终端和能够由车辆的用户携带的第2终端请求是否同意搭载于车辆的控制装置的软件的更新所涉及的处理的回复；和在接受到从来自第1终端的回复和来自第2终端的回复双方作为对该请求的响应的情况下，使来自第2终端的回复无效，使来自第1终端的回复有效。

通过上述软件更新方法，也与上述的服务器同样，在软件更新中能够既确保足够的用户的便利性、又抑制因误操作而执行用户不希望的软件更新所涉及的处理。

本发明的第四方式所涉及的非暂时性存储介质存储有能够由计算机执行且使计算机执行软件更新方法的程序。在某个方式中，提供一种具备存储有上述程序的存储装置和执行存储于存储装置的程序的处理器的计算机装置。在其他方式中，提供一种分发上述程序的计算机装置。

根据本公开，在软件更新中，能够既确保足够的用户的便利性、又抑制因误操作而执行用户不希望的软件更新所涉及的处理。

附图说明

以下，参照附图对本发明的示例性实施例的特征、优点、技术及工业重要性进行说明，在附图中相同的附图标记表示相同的构成要素，其中：

图1是表示本公开的实施方式所涉及的软件更新***的构成的图。

图2是用于对本公开的实施方式所涉及的软件更新方法的概要进行说明的图。

图3是用于对本公开的实施方式所涉及的软件更新方法中的同意请求进行说明的图。

图4是表示本公开的实施方式所涉及的软件更新方法的处理步骤的流程图。

图5是表示图4所示的处理的变形例的图。

具体实施方式

参照附图对本公开的实施方式详细地进行说明。图中，对相同或者相当部分标注相同的附图标记并不重复其说明。

图1是表示该实施方式所涉及的软件更新***的构成的图。参照图1，该软件更新***包括车辆100、便携终端200以及OTA中心500。

车辆100例如是不具备内燃机的电动汽车(BEV)。车辆100具备OTA管理器10、多个ECU(仅图示ECU20)、启动开关50、驾驶装置61、ADS(Autonomous Driving System)62以及HMI(Human Machine Interface)70。OTA管理器10、多个ECU、驾驶装置61、ADS62以及HMI70分别从未图示的电源(例如车载电池)接受电力的供给。“ECU”是指电子控制装置(Electronic Control Unit)。“OTA”是“Over The Air”的简称。

启动开关50是用于供用户启动车辆***(车辆100的控制***)的开关，例如设置于车辆100的车厢内。一般，启动开关亦被称为“电源开关”或者“点火开关”等。通过用户操作启动开关50，来切换车辆***的接通(工作)/断开(停止)。通过启动开关50被接通操作，使得停止状态的车辆***(包括OTA管理器10以及ECU20)启动，车辆***成为工作状态(以下，亦称为“IG接通”)。另外，在车辆***工作时，若启动开关50被断开操作，则车辆***成为停止状态(以下，亦称为“IG断开”)。

启动开关50的接通操作是用于将车辆100的状态从IG断开切换为IG接通的操作。若用户对启动开关50进行接通操作，则启动请求被分别输入至OTA管理器10和多个ECU。即，OTA管理器10和多个ECU分别受理来自用户的启动请求。另一方面，启动开关50的断开操作是用于将车辆100的状态从IG接通切换为IG断开的操作。若用户对启动开关50进行了断开操作，则关机请求OTA被分别输入至管理器10和多个ECU。即，OTA管理器10与多个ECU分别受理来自用户的关机请求(shutdown request)。但是，在行驶中的车辆100中，启动开关50的断开操作被禁止。

HMI70包括输入装置以及显示装置。HMI70可以包括作为输入装置以及显示装置发挥功能的触摸面板显示器。HMI70可以包括信息显示器或者指示器(tell-tale)作为显示装置。HMI70可以包括转向开关作为输入装置。另外，IVI(In-Vehicle Infotainment)***、仪表面板以及抬头显示器中的至少1个可以作为HMI70发挥功能。

OTA中心500是提供基于OTA技术的车辆软件更新服务的服务器。OTA中心500构成为从该中心经由通信划分来实施远程的车载ECU软件更新。OTA管理器10管理车辆内信息，接受活动，管理软件更新时序。OTA管理器10内置有计算机，作为车载诊断装置发挥功能。OTA管理器10控制具有OTA功能的各ECU。在车辆100中，OTA管理器10以及ECU20分别具有OTA功能。虽然图1中未示出，但是车辆100除了ECU20以外，还具备具有OTA功能的ECU。另外，车辆100可以还具备不具有OTA功能的ECU(未图示)。OTA管理器10与各ECU经由通信总线连接，构成为相互能够实现有线通信。通信方式不特别限定，例如可以是CAN(Controller AreaNetwork)或者Ethernet(注册商标)。搭载于车辆100的各ECU(ECU20等)内置有具备至少1个处理器和至少1个存储器的计算机。各ECU可以以主微机以及副微机那样的方式具备多个微机(微型计算机)。车辆100所具备的ECU的数量任意。

车辆100是构成为可自动驾驶的自动驾驶车辆。该实施方式所涉及的车辆100构成为能够执行有人行驶和无人行驶双方。车辆100构成为能够无人自主行驶，但也能够通过用户的手动驾驶来行驶(有人行驶)。另外，车辆100还能够在有人行驶中执行自动驾驶(例如自动巡航控制)。自动驾驶的等级可以为完全自动驾驶(等级5)，也可以为有条件的自动驾驶(例如等级4)。

ECU20构成为控制驾驶装置61。驾驶装置61包括加速装置、制动装置以及转向操纵装置。加速装置例如包括使车辆100的驱动轮旋转的电动发电机(以下，表述为“MG”)、驱动MG的PCU(Power Control Unit)、以及将用于驱动MG的电力供给至PCU的电池。MG作为车辆100的行驶用马达发挥功能。制动装置例如包括设置于车辆100的各车轮的制动装置和驱动制动装置的促动器。转向操纵装置例如包括EPS(Electric Power Steering)和驱动EPS的促动器。

ADS62包括识别车辆100的外部环境的识别用传感器(例如照相机、毫米波雷达、光学雷达中的至少1个)，基于由识别用传感器依次取得的信息来执行自动驾驶所涉及的处理。具体而言，ADS62与ECU20协作来生成与车辆100的外部环境相应的行驶计划(表示今后的车辆100的举动的信息)。而且，ADS62为了使车辆100根据该行驶计划行驶而向ECU20请求驾驶装置61所包括的各种促动器的控制。

其中，在该实施方式中，ADS62被内置于车辆100。然而并不局限于此，ADS62也可以是相对于车辆100可装卸的自动驾驶套件。自动驾驶套件的传感器单元(包括识别用传感器)可以被安装于车辆100的车顶。

便携终端200构成为能够由车辆100的用户携带。在该实施方式中，作为便携终端200，采用具备触摸面板显示器的智能手机。智能手机内置有计算机。但并不局限于此，作为便携终端200，能够采用车辆100的用户可携带的任意的终端。例如，也能够采用笔记本电脑、平板终端、便携式游戏机、可穿戴设备(智能手表、智能眼镜、智能手套等)等作为便携终端200。

在便携终端200安装有用于利用OTA中心500提供的服务的应用软件(以下，称为“移动应用”)。通过移动应用，便携终端200的识别信息(终端ID)与车辆100的识别信息(车辆ID)建立关联被登记至OTA中心500。便携终端200能够通过移动应用来与OTA中心500进行信息的交换。便携终端200可以作为远程进行车辆100的门的上锁解锁的电子钥匙发挥功能。另外，便携终端200可以实现与启动开关50同样的作用。便携终端200可以根据来自用户的操作(接通操作/断开操作)来远程切换车辆***的状态(IG接通/IG断开)。根据这样的便携终端200，用户在车外也能够切换车辆***的状态。

OTA管理器10、便携终端200、OTA中心500分别具备处理器110、210、510、存储器120、220、520以及通信模块130、230、530。处理器110、210、510例如分别包括CPU(CentralProcessing Unit)。存储器120、220、520例如分别包括闪存那样的非易失性存储器。

通信模块130构成为与车辆外部的装置进行通信。通信模块130可以包括进行无线通信的TCU(Telematics Control Unit)以及/或者DCM(Data Communication Module)。并且，通信模块130可以包括与车辆外部的装置进行有线通信的通信I/F(接口)。OTA管理器10可以经由未图示的DLC(Data Link Connector)与扫描工具(进行有线软件更新的专用工具)进行有线通信。

通信模块130、230分别通过无线通信来访问通信网络NW。通信模块530通过有线与通信网络NW连接，经由通信网络NW分别与多个车辆(包括车辆100)和多个便携终端(包括便携终端200)进行通信。通信网络NW例如是由因特网和无线基站构建的广域网络。通信网络NW可以包括移动电话网。OTA管理器10和便携终端200分别通过无线通信来与OTA中心500进行通信。OTA管理器10、便携终端200以及OTA中心500经由通信网络NW相互通信。

图2是用于对该实施方式所涉及的软件更新方法的概要进行说明的图。参照图1和图2，软件更新(更详细而言是利用了OTA的车辆软件的更新)所涉及的处理按照构成同步、活动通知和同意应用、下载、安装、激活以及软件更新完成通知那样的步骤来进行。

车辆100以车辆***IG接通(例如启动开关50或者便携终端200被接通操作)为契机来开始构成同步。车辆100涉及的构成同步处理包括将车辆构成信息发送至OTA中心500。车辆构成信息例如包括车辆100所包括的每个ECU的硬件信息(表示硬件的产品编号、ECU的识别符等的信息)以及软件信息(表示软件的产品编号等的信息)。车辆构成信息可以还包括每个认可对象的RXSWIN。RXSWIN是能够确定构成功能型式认可的软件的识别编号。

OTA中心500若从车辆100接收到上述车辆构成信息，则对在当前时刻发生的活动(软件的更新)进行确认。而且，若存在能够应用于车辆100的活动，则OTA中心500在上述车辆构成信息接收的响应中向OTA管理器10和便携终端200分别发送同意请求信号，该同意请求信号请求是否同意该活动所涉及的新的软件(软件的更新版)的下载的回复。上述同意请求信号包括与该活动相关的信息(活动信息)。活动信息例如可以包括活动属性信息(表示软件更新的目的、以及因更新而有可能影响的车辆的功能等的信息)、活动对象车辆的列表、与活动对象ECU相关的信息(例如更新前后的软件信息)以及与更新前后对用户的通知相关的信息中的至少1个。其中，所通知的活动可能是新发生的活动，也可能是以前未应用的活动。以下，将上述同意请求信号的发送亦称为“活动通知”。

图3是用于对该实施方式所涉及的软件更新方法中的活动通知(同意请求)进行说明的图。在该实施方式中，搭载于车辆100的OTA管理器10以及HMI70协作来作为本公开所涉及的“第1终端(车载终端)”的一个例子发挥功能。

参照图3，OTA中心500对于OTA管理器10和便携终端200分别进行活动通知。接受到活动通知的OTA管理器10和便携终端200分别向用户催促对于活动通知(同意请求信号)表示同意和拒绝中的哪个的操作。而且，在由用户进行了上述操作的情况下，OTA管理器10和便携终端200分别对于OTA中心500进行与该操作相应的回复。

具体而言，若OTA管理器10接受到活动通知，则HMI70显示画面Sc1。若便携终端200接受到活动通知，则便携终端200(触摸面板显示器)显示画面Sc2。画面Sc1、Sc2例如分别显示“发现了新的软件。是否应用于该车？”那样的消息，向用户请求表示是否同意新的软件的下载的操作。

画面Sc1、Sc2分别包括受理“同意”的操作的应用按钮M11、M21、确认按钮M12、M22、以及受理“拒绝”的操作的不应用按钮M13、M23。若应用按钮M11***作，则OTA管理器10对于OTA中心500进行“同意”的回复。若不应用按钮M13***作，则OTA管理器10对于OTA中心500进行“拒绝”的回复。以下，将在画面Sc1中操作应用按钮M11和不应用按钮M13中的任一个称为“第1操作”。另一方面，在画面Sc2中，若应用按钮M21***作，则便携终端200对于OTA中心500进行“同意”的回复。若不应用按钮M23***作，则便携终端200对于OTA中心500进行“拒绝”的回复。以下，将在画面Sc2中操作应用按钮M21和不应用按钮M23中的任一个称为“第2操作”。第1操作以及第2操作分别表示用户对于活动通知(同意请求)的意思(同意/拒绝中的任一个)。

若在进行上述的第1操作、第2操作之前操作了确认按钮M12、M22，则HMI70、便携终端200分别显示活动的内容(活动信息的至少一部分)。因此，用户能够在掌握了活动的内容之后决定是否同意该活动所涉及的新的软件的下载。

详细情况将后述，但该实施方式所涉及的OTA中心500在向OTA管理器10和便携终端200分别发送了上述同意请求信号之后，决定受理对于该同意请求信号的回复的期间(以下，称为“受理期间”)(参照图4)。而且，OTA中心500仅在受理期间内从OTA管理器10和便携终端200中的任一方接受到回复的情况下，使该回复有效。另外，OTA中心500当在受理期间内从OTA管理器10和便携终端200双方接受到回复的情况下，使来自便携终端200的回复(基于第2操作的回复)无效，使来自OTA管理器10的回复(基于第1操作的回复)有效。当OTA中心500在受理期间内接受到表示“同意”的回复(有效的回复)的情况下，软件更新所涉及的处理迁移至下载阶段。另一方面，当OTA中心500在受理期间内未接受到表示“同意”的回复(有效的回复)的情况下，软件更新所涉及的处理结束而不进入至下载阶段。

再次参照图1和图2，OTA中心500以及车辆100例如通过以下说明的步骤执行下载所涉及的处理。以下，将进行了上述的表示“同意”的有效的回复的终端(车载终端或者便携终端200)称为“同意终端”。

OTA管理器10向OTA中心500请求包括新的软件的分发数据包。而且，OTA管理器10与OTA中心500进行无线通信来执行该分发数据包的下载(接收以及保存)。分发数据包可以除了新的软件(例如成为活动的对象的每个ECU的更新数据集)以外，还包括数据包属性信息(表示更新划分、分发数据包中的更新数据数、各ECU的安装顺序等的信息)、以及更新数据属性信息(目标ECU的识别符、用于验证更新数据的合法性的验证用数据等)。目标ECU是成为软件更新对象的ECU。例如，可以是目标ECU为ECU20、被更新的软件为自动驾驶控制程序。

通过上述的下载所涉及的处理，在OTA管理器10所具备的存储装置(例如存储器120)保存上述分发数据包。在下载中，同意终端向用户报告下载的进展。在下载完成后，OTA管理器10验证所下载的分发数据包的真实性。而且，若验证的结果为“正常”，OTA管理器10将软件更新状态(下载完成)通知给OTA中心500。进行该通知意味着下载成功。

若下载成功，则车辆100执行安装。具体而言，OTA管理器10向至少1个目标ECU(例如ECU20)请求该目标ECU的状态以及DTC(Diagnostic Trouble Code)的输出。OTA管理器10基于目标ECU的状态以及DTC来按每个目标ECU判断可否执行安装。而且，OTA管理器10向可执行安装的目标ECU转送新的软件(更新数据)。接收到更新数据的目标ECU执行该更新数据的安装(向非易失性存储器的写入)。在安装中，同意终端向用户报告安装的进展。

若从OTA管理器10向目标ECU的上述更新数据的转送完成，则目标ECU将转送完成通知发送至OTA管理器10。而且，接受到转送完成通知的OTA管理器10向目标ECU请求完全性验证。接受到该请求的目标ECU使用完全性验证数据(验证用数据)来进行验证，并将该验证结果向OTA管理器10发送。OTA管理器10保存每个目标ECU的验证结果(安装的完成/失败/中止)。若全部的目标ECU的完全性验证完成且全部的验证结果为“正常”，则OTA管理器10将软件更新状态(安装完成)通知给OTA中心500。进行该通知意味着安装成功。

若紧接着下载安装也成功，则车辆100成为待激活状态。然后，若对启动开关50或者便携终端200进行了断开操作，则OTA管理器10使同意终端显示规定的消息，向用户请求表示“同意”和“拒绝”中的任一方的输入。而且，若用户对于同意终端进行了表示“同意”的输入，则OTA管理器10执行激活(所安装的软件的有效化)。另一方面，若用户对于同意终端进行了表示“拒绝”的输入，则OTA管理器10不执行激活而中止软件更新所涉及的处理，车辆***被关机。

若激活完成后的构成确认成功，则OTA管理器10使同意终端显示软件更新的结果。同意终端显示例如表示更新的成功的软件更新完成画面。然后，OTA管理器10将软件更新状态(软件更新完成)通知给OTA中心500。进行该通知意味着OTA软件更新成功。若进行了该通知，则车辆100的控制***关机，成为IG断开。然后，若对启动开关50或者便携终端200进行了接通操作，则车辆***成为IG接通。由此，更新程序(新的版本的软件)在目标ECU启动。

图4是表示该实施方式所涉及的软件更新方法的处理步骤的流程图。若对象车辆涉及的构成同步处理完成，则由OTA中心500执行该流程图所示的处理。对象车辆例如是图1所示的车辆100。若对象车辆涉及的构成同步处理完成，则OTA中心500从该对象车辆接收上述的车辆构成信息，针对该对象车辆开始以下说明的图4所示的一系列处理。在该实施方式中，OTA中心500相当于本公开所涉及的“服务器”的一个例子。在该实施方式中，图1所示的处理器510作为本公开所涉及的“请求部”以及“受理部”的一个例子发挥功能。通过1个以上的处理器读取存储于1个以上的存储器的程序并执行来实现下述的流程图。流程图中的“S”是指步骤。

参照图1～图3以及图4，在S11中，OTA中心500判断是否存在能够应用于对象车辆的活动(新的或者未应用的软件更新)。当不存在能够应用于对象车辆的活动的情况下(在S11中为“否”)，图4所示的一系列处理结束。

当存在能够应用于对象车辆的活动的情况下(在S11中为“是”)，在接下来的S12中，OTA中心500将上述的同意请求信号向OTA管理器10和便携终端200分别发送。接着，OTA中心500在S13中决定上述的受理期间(受理对于同意请求信号的回复的期间)。OTA中心500例如基于活动的内容(软件的更新的内容)来决定受理期间。更详细而言，OTA中心500使受理期间在同意请求信号请求被推荐早期更新的软件(例如与安全性相关的软件)的更新处理的同意的情况下比在同意请求信号请求通常的软件(紧急性低的软件)的更新处理的同意的情况下长。由此，用户容易同意。或者，OTA中心500可以基于对象车辆的状况来决定受理期间。例如，当用户处于对象车辆的驻车驾驶(用于驻车的驾驶)中时，OTA中心500可以延长受理期间以便用户能够在驻车驾驶完成之后回复。但并不局限于此，受理期间也可以是预先决定的固定的期间。

在接下来的S14中，OTA中心500判断是否经过了在S13中决定的受理期间。在未经过受理期间的期间(在S14中为“否”)，OTA中心500受理分别来自OTA管理器10和便携终端200的回复。而且，若经过了受理期间(在S14中为“是”)，则OTA中心500判断在受理期间内是否接受到对于上述同意请求信号的回复(S15)。而且，在OTA中心500从OTA管理器10和便携终端200中的任一个均未接受到回复而经过了受理期间的情况下(在S15中为“否”)，OTA中心500在S22中将不下载软件这一内容分别通知给OTA管理器10和便携终端200之后，使图4所示的一系列处理结束。该情况下，OTA中心500不下载上述活动所涉及的新的软件。

当OTA中心500在受理期间内从OTA管理器10和便携终端200中的至少一方接受到回复的情况下(在S15中为“是”)，OTA中心500在S16中判断是否在受理期间内从OTA管理器10接受到回复(基于第1操作的回复)。当OTA中心500在受理期间内未从OTA管理器10接受到回复的情况下，在S16中判断为“否”，处理进入至S19。在S16中判断为“否”意味着OTA中心500仅从便携终端200接受到回复。该情况下，来自便携终端200的回复有效。

另一方面，若在S16中判断为“是”，则OTA中心500在S17中判断是否在受理期间内从便携终端200接受到回复(基于第2操作的回复)。当OTA中心500在受理期间内未从便携终端200接受到回复的情况下，在S17中判断为“否”，处理进入至S19。在S17中判断为“否”意味着OTA中心500仅从OTA管理器10接受到回复。该情况下，来自OTA管理器10的回复有效。

并且，若在S16、S17双方中判断为“是”，则OTA中心500在S18中使来自便携终端200的回复无效，使来自OTA管理器10的回复有效。然后，处理进入至S19。在S16、S17双方中判断为“是”意味着OTA中心500从OTA管理器10和便携终端200双方接受到回复。

在S19中，OTA中心500基于有效的回复来决定是否下载上述活动所涉及的新的软件。当在有效的回复表示“拒绝”的情况下(在S19中为“否”)，处理进入至上述的S22。该情况下，不执行下载。另一方面，在有效的回复表示“同意”的情况下(在S19中为“是”)，OTA中心500在S21中使软件更新所涉及的处理进入至下载阶段。由此，开始上述活动所涉及的新的软件的下载。若执行了S21的处理，则图4所示的一系列处理结束。其中，关于下载开始后的处理已经叙述(参照图2)。

如以上说明那样，该实施方式所涉及的软件更新方法包括图4所示的处理。即，OTA中心500(服务器)向搭载于车辆100的OTA管理器10(第1终端)和能够由车辆100的用户携带的便携终端200(第2终端)请求是否同意搭载于车辆100的ECU(控制装置)的软件的更新所涉及的处理(例如下载)的回复(S12)。另外，OTA中心500在根据该请求而从OTA管理器10和便携终端200双方接受到回复的情况下(在S16、S17双方中为“是”)，使来自便携终端200的回复无效，使来自OTA管理器10的回复有效(S18)。

根据上述方法，用户能够为了上述回复而选择使用车辆100的车载终端(HMI70)和便携终端200中的哪一个。由此，容易确保足够的用户的便利性。另外，OTA中心500在从车辆100的车载终端(OTA管理器10)和便携终端200双方接受到对于上述请求的回复的情况下，使来自便携终端200的回复无效，使来自车载终端的回复有效。当车载终端和便携终端200双方进行了回复的情况下，便携终端200涉及的回复是基于误操作的回复的可能性高。鉴于此，通过使来自便携终端200的回复无效，使来自车载终端的回复有效，能够抑制因误操作而执行用户不希望的软件更新所涉及的处理。

图4所示的处理能够适当地变更。例如，OTA中心500可以执行图5所示的处理来代替图4所示处理。图5是表示图4所示的处理的变形例的图。

参照图1～图3以及图5，OTA中心500在S31～S33中分别执行依照图4的S11～S13的处理。然后，在S34中，与图4的S16同样，OTA中心500判断是否在受理期间内从OTA管理器10接受到回复(基于第1操作的回复)。若在S34中判断为“否”，则在S35中，与图4的S17同样，OTA中心500判断是否在受理期间内从便携终端200接受到回复(基于第2操作的回复)。若在S35中也判断为“否”，则OTA中心500在S371中判断是否经过了在S33中决定的受理期间。而且，若在S371中也判断为“否”，则处理返回至S34。在S34、S35、S371全部判断为“否”的期间，反复进行S34、S35、S371。

在OTA中心500从OTA管理器10和便携终端200中的任一个均未接受到回复而经过了受理期间的情况下(在S371中为“是”)，OTA中心500在S42中将不下载软件这一内容分别通知给OTA管理器10和便携终端200之后，使图5所示的一系列处理结束。

当OTA中心500在受理期间内未接受到来自OTA管理器10的回复而接受到便携终端200的回复的情况下(在S35中为“是”)，OTA中心500在S36中判断便携终端200是否存在于车辆100之外。OTA中心500例如可以从车辆100以及便携终端200分别接收位置信息，并基于它们的位置信息来判断便携终端200是否存在于车辆100之外。或者，OTA中心500可以从便携终端200接收表示便携终端200是否存在于车辆100内的信号，并基于该信号来判断便携终端200是否存在于车辆100之外。在便携终端200存在于车辆100之外的情况下(在S36中为“是”)，处理进入至S39。该情况下，来自便携终端200的回复有效。

在便携终端200不存在于车辆100之外的情况下(在S36中为“否”)，OTA中心500在S372中判断是否经过了在S33中决定的受理期间。而且，若在S372中判断为“否”，则处理返回至S34。另一方面，若在S372中判断为“是”，则处理进入至S39。该情况下，来自便携终端200的回复有效。

当OTA中心500在受理期间内接受到来自OTA管理器10的回复的情况下(在S34中为“是”)，处理进入至S38。该情况下，来自OTA管理器10的回复有效。OTA中心500若在受理期间内从便携终端200也接受到回复，则在S38中，使来自便携终端200的回复无效。然后，处理进入至S39。

在S39中，与图4的S19同样，OTA中心500基于有效的回复来决定是否下载上述活动所涉及的新的软件。在有效的回复表示“拒绝”的情况下(在S39中为“否”)，处理进入至上述的S42。该情况下，不执行下载。另一方面，在有效的回复表示“同意”的情况下(在S39中为“是”)，OTA中心500在S41中使软件更新所涉及的处理进入至下载阶段。由此，开始上述活动所涉及的新的软件的下载。若执行了S41的处理，则图5所示的一系列处理结束。

在上述变形例所涉及的软件更新***中，当OTA中心500在受理期间内接受到来自车辆100的车载终端(OTA管理器10)的回复的情况下(在S34中为“是”)，OTA中心500不等待受理期间的经过就基于来自车载终端的回复来决定是否下载软件(S39)。由此，从基于车辆100的车载终端的回复至下载开始为止的时滞(响应延迟)变小。当OTA中心500在受理期间内接受到来自便携终端200的回复且OTA中心500未接受到来自车辆100的车载终端的回复而经过了受理期间的情况下(在S372中为“是”)，OTA中心500基于来自便携终端200的回复来决定是否下载软件(S39)。当OTA中心500在受理期间内接受到来自位于车辆100之外的便携终端200的回复的情况下(在S36中为“是”)，OTA中心500不等待受理期间的经过就基于来自便携终端200的回复来决定是否下载软件(S39)。由此，从基于便携终端200的回复至下载开始为止的时滞(响应延迟)变小。在进行了回复的便携终端200存在于车外的情况下，用户位于车外的可能性高，搭载于车辆100的终端(例如HMI70)***作的可能性低。

在上述实施方式中，采用本地部署(on-premises)服务器作为OTA中心500(参照图1)。然而并不局限于此，也可以通过云计算来在云上安装OTA中心500的功能(例如，软件更新所涉及的功能)。即，OTA中心500也可以是云服务器。被更新的软件并不局限于上述的自动驾驶控制程序那样的驾驶辅助***的控制程序，而是任意的。不需要车辆构成为可自动驾驶。

车辆也可以是BEV以外的xEV(电动车)。车辆可以是具备内燃机(例如汽油发动机、生物燃料发动机或者氢发动机)的PHEV(插电混合动力车)或者HEV(混合动力车)。车辆并不局限于4个轮的乘用车，也可以是巴士或者卡车，也可以是3个轮的xEV。车载电池可以构成为能够接触充电，也可以构成为能够在驻车中或者行驶中非接触充电(无线充电)，也可以构成为能够更换电池。车辆也可以具备太阳能面板。车辆也可以具备飞行功能。车辆也可以是MaaS(Mobility as a Service：出行即服务)车辆。MaaS车辆是MaaS企业管理的车辆。车辆也可以是根据用户的使用目的而被定制的多目的车辆。车辆也可以是移动店铺车辆、无人驾驶出租车、无人输送车(AGV)或者农业机械。车辆也可以是无人或者1人乘坐的小型BEV(例如最后一英里用的BEV或者电动轮椅)。

上述的各种变形例可以任意组合来实施。

应该认为本次公开的实施方式在全部的点上是例示而非限制性的。本发明的范围并不是上述的实施方式的说明而由本申请请求保护的范围示出，意在包括与本申请请求保护的范围均等的含义以及范围内的全部变更。

Claims (8)

1.一种服务器，其特征在于，包括：

请求部，构成为能够向搭载于车辆的第1终端和能够由所述车辆的用户携带的第2终端请求是否同意搭载于所述车辆的控制装置的软件的更新所涉及的处理的回复；和

受理部，构成为在接受来自所述第1终端的所述回复和来自所述第2终端的所述回复双方作为对所述请求的响应的情况下，使来自所述第2终端的回复无效，使来自所述第1终端的回复有效。

2.根据权利要求1所述的服务器，其特征在于，

所述受理部构成为决定受理对于所述请求的所述回复的受理期间，

所述受理部构成为当所述受理部在所述受理期间内接受到来自所述第1终端的所述回复和来自所述第2终端的所述回复双方的情况下，基于来自所述第1终端的所述回复来决定是否下载所述软件。

3.根据权利要求2所述的服务器，其特征在于，

所述受理部构成为当所述受理部在所述受理期间内接受到来自所述第1终端的所述回复的情况下，不等待所述受理期间的经过就基于来自所述第1终端的所述回复来决定是否下载所述软件，

所述受理部构成为当所述受理部在所述受理期间内接受到来自所述第2终端的所述回复且所述受理部未接受到来自所述第1终端的所述回复而经过了所述受理期间的情况下，基于来自所述第2终端的所述回复来决定是否下载所述软件。

4.根据权利要求3所述的服务器，其特征在于，

所述受理部构成为当所述受理部在所述受理期间内从位于所述车辆之外的所述第2终端接受到所述回复的情况下，不等待所述受理期间的经过就基于来自所述第2终端的所述回复来决定是否下载所述软件。

5.根据权利要求2～4中任一项所述的服务器，其特征在于，

所述受理部构成为基于所述软件的更新的内容来决定所述受理期间，

所述受理部构成为在从所述第1终端以及所述第2终端中的任一个均未接受到所述回复而经过了所述受理期间的情况下，不下载所述软件。

6.一种软件更新***，其特征在于，包括：

车辆；

第1终端，搭载于所述车辆；

第2终端，能够由所述车辆的用户携带；以及

服务器，

所述服务器构成为向所述第1终端和所述第2终端请求是否同意搭载于所述车辆的控制装置的软件的更新所涉及的处理的回复，

所述第1终端和所述第2终端分别构成为向用户催促对于所述请求表示同意和拒绝中的哪一个的操作，

所述第1终端和所述第2终端分别构成为在由所述用户进行了所述操作的情况下，对于所述服务器进行与该操作相应的回复，

所述服务器构成为在接受到来自所述第1终端的所述回复和来自所述第2终端的所述回复双方的情况下，使来自所述第2终端的回复无效，使来自所述第1终端的回复有效。

7.一种软件更新方法，由计算机执行，其特征在于，包括：

向搭载于车辆的第1终端和能够由所述车辆的用户携带的第2终端请求是否同意搭载于所述车辆的控制装置的软件的更新所涉及的处理的回复；和

在接受到来自所述第1终端的回复和来自所述第2终端的回复双方作为对所述请求的响应的情况下，使来自所述第2终端的回复无效，使来自所述第1终端的回复有效。

8.一种非暂时性存储介质，其特征在于，

存储有能够由计算机执行且使计算机执行权利要求7所述的软件更新方法的命令。