CN117793084A - 移动终端、软件分发系统 - Google Patents

Abstract

本申请涉及移动终端、软件分发系统，该移动终端包括：存储部；接收部，构成为从车辆接收被搭载于上述车辆的单库型的计算机的更新前的软件；以及发送部，构成为在使上述存储部存储了接收到的上述更新前的软件之后将从服务器取得的更新用软件向上述车辆发送。

Description

移动终端、软件分发系统

技术领域

本公开涉及移动终端以及软件分发系统。

背景技术

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

车辆能够通过与OTA中心进行无线通信来从OTA中心下载车载ECU的新的软件。而且，在车辆中，目标ECU(软件更新对象的ECU)能够通过依次执行安装、激活来更新软件。

典型的车载ECU具备1个以上的微型计算机(以下，也称为“微机”)。车载ECU内的典型的微机大致分为双库微机(dual-bank microcomputer)和单库微机(single-bankmicrocomputer)。

在双库微机中，由2个存储器形成2个库。在双库微机中，在激活失败了的情况下能够恢复(回滚)至原版本的软件。具体而言，维持在现用面(active bank)保留原版本的软件不变，在写入面写入新的版本的软件。而且，在写入面的激活失败了的情况下，利用保留在现用面的原版本的软件来执行回滚。

在单库微机中，由1个存储器形成1个库。而且，在单库微机中，在1个库中进行软件的覆盖。因此，不保留原版本的软件。在单库微机中，可能产生在激活失败了的情况下无法恢复(回滚)至原版本的软件这一课题。

鉴于此，虽然也考虑将单库微机变更为双库微机、在单库微机的库内设置用于回滚的存储部、在单库微机外接设置用于回滚的非易失性存储器(例如闪速存储器)，但这些设计变更会导致车载ECU的大幅的成本上升。

当下普及的车辆具备大量的单库微机，单库微机的软件更新大多在销售店(经销商)进行。然而，针对单库微机，也存在想要利用OTA技术来根据车辆用户的判断简单地执行软件更新这一需求。

发明内容

本公开提供针对被搭载于车辆的单库型的计算机也能够进行基于OTA技术的恰当的软件更新的移动终端以及软件分发系统。

本公开的第1方式所涉及的移动终端如下所示。

(第1项)一种移动终端，包括：存储部；接收部，构成为从车辆接收被搭载于上述车辆的单库型的计算机的更新前的软件；以及发送部，构成为在使上述存储部存储了接收到的上述更新前的软件之后将从服务器取得的更新用软件向上述车辆发送。

上述服务器能够作为分发软件的OTA(Over The Air)中心来发挥功能。上述移动终端能够对车辆与OTA中心的通信进行中介。在包括这些服务器、车辆以及移动终端的系统中，能够利用移动终端的存储部来使被搭载于车辆的目标ECU(软件更新对象的ECU)内的单库型的计算机虚拟地作为双库式的计算机发挥功能。根据具有上述构成的移动终端，在单库型的计算机的软件更新(例如激活)失败了的情况下，上述车辆能够使用保存于移动终端的存储部的更新前的软件来进行回滚。由此，针对被搭载于车辆的单库型的计算机也能够进行基于OTA技术的恰当的软件更新。

其中，移动终端是能够由用户携带的终端。作为移动终端的例子，可举出平板终端、智能手机、可穿戴设备。

上述第1项所记载的移动终端能够具有以下所示的第2项～第5项中任一项所记载的构成。

(第2项)在上述方式的基础上，移动终端还包括：取得部，构成为取得上述更新前的软件的版本信息；和判断部，构成为在上述单库型的计算机的软件更新中对上述存储部是否具有用于保存上述更新前的软件的空闲容量进行判断，其中，上述移动终端构成为：在上述判断部判断为上述存储部具有用于保存上述更新前的软件的上述空闲容量的情况下，上述接收部从上述车辆接收上述更新前的软件，在使上述存储部存储了上述更新前的软件之后，上述发送部将从上述服务器取得的上述更新用软件向上述车辆发送，在上述判断部判断为上述存储部不具有用于保存上述更新前的软件的上述空闲容量的情况下，上述取得部取得上述更新前的软件的上述版本信息，在使上述存储部存储了上述版本信息之后，上述发送部将从上述服务器取得的上述更新用软件向上述车辆发送。

根据具有上述构成的移动终端，能够根据存储部的空闲容量(即，存储部可存储的数据量)来恰当地保存用于回滚的数据(详细而言是更新前的软件或者其版本信息)。

(第3项)在上述方式的基础上，移动终端还包括更新部，该更新部构成为在上述单库型的计算机的软件更新中，搁置该软件更新直至在上述存储部确保了用于保存上述更新前的软件的空闲容量为止，当在上述存储部确保了用于保存上述更新前的软件的上述空闲容量之后，允许上述单库型的计算机的软件更新。

根据上述结构，容易恰当地进行单库型的计算机的软件更新。

(第4项)在上述方式的基础上，移动终端还包括报告部，该报告部构成为在上述单库型的计算机的软件更新中，当用于保存上述更新前的软件的上述存储部的上述空闲容量不足的情况下进行规定的报告。

根据上述结构，用户容易掌握状况。

(第5项)在上述方式的基础上，移动终端的特征在于，上述接收部构成为通过无线通信来从上述服务器取得上述更新用软件，上述发送部构成为通过无线通信来将上述更新用软件向上述车辆发送。

根据上述构成，用户的便利性提高。

本公开的第2方式所涉及的移动终端如下所示。

(第6项)一种移动终端，包括：存储部；取得部，构成为取得被搭载于车辆的单库型的计算机的更新前的软件的版本信息；以及发送部，构成为在使上述存储部存储了上述更新前的软件的上述版本信息之后，将从服务器取得的更新用软件向上述车辆发送。

根据具有上述构成的移动终端，在上述车辆的单库型的计算机的软件更新失败了的情况下，移动终端能够基于保存于存储部的更新前的软件的版本信息例如从服务器取得更新前的软件。而且，车辆能够从移动终端接收更新前的软件，并使用该更新前的软件进行单库型的计算机的回滚。

本公开的第3方式所涉及的软件分发系统如下所示。

(第7项)一种软件分发系统，包括：第1项～第6项中任一项所记载的移动终端；上述车辆；以及上述服务器，其中，上述车辆具备管理软件更新的时序的控制装置，上述控制装置构成为：使用从上述移动终端接受到的上述更新用软件来执行上述单库型的计算机的软件更新，在该软件更新失败了的情况下，从上述移动终端接受上述更新前的软件，使用上述更新前的软件来执行回滚。

根据上述的软件分发系统，容易在车辆侧管理软件更新。

(第8项)在上述方式的基础上，软件分发系统的特征在于，上述单库型的计算机是进行上述车辆的行驶控制的计算机。

根据上述构成，在与行驶控制相关的软件的更新失败的情况下，恢复(能够回滚)至更新前的软件。车辆能够利用更新前的软件而与以前同样地行驶。因此，用户能够安心。

根据本公开，针对被搭载于车辆的单库型的计算机也能够进行基于OTA技术的恰当的软件更新。

附图说明

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

图1是表示本公开的实施方式所涉及的软件分发系统的简要结构的图。

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

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

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

图5是用于对图4所示的处理中的目标ECU所具备的双库微机的激活(回滚)处理进行说明的图。

图6是用于对图4所示的处理中的目标ECU所具备的单库微机的激活(回滚)处理的第1例进行说明的图。

图7是用于对图4所示的处理中的目标ECU所具备的单库微机的激活(回滚)处理的第2例进行说明的图。

图8是表示图3所示的处理的第1变形例的流程图。

图9是表示图3所示的处理的第2变形例的流程图。

具体实施方式

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

图1是表示该实施方式所涉及的软件分发系统的构成的图。参照图1，该软件分发系统包括车辆100、移动终端300以及OTA中心500。其中，“OTA”是“Over The Air”的简称。

车辆100是不具备内燃机的电动汽车(BEV)。该实施方式所涉及的车辆100不具有OTA访问功能(与OTA中心500直接进行无线通信的功能)，若不经由其他通信装置(即，不是车辆100自身所具备的通信装置的通信装置)则无法与OTA中心500通信。具体而言，车辆100经由移动终端300来与OTA中心500进行无线通信。其中，车辆100是应用以下说明的软件分发系统的车辆的一个例子，也可以在其他车辆应用软件分发系统。

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

移动终端300具备处理器310、存储器320以及通信模块330。处理器310例如包括CPU(Central Processing Unit)。处理器的数量并不局限于1个。处理器的数量可以为2个以上。存储器320例如包括闪存那样的非易失性存储器。存储器的数量不并不局限于1个。存储器的数量可以为2个以上。通信模块330包括用于与OTA中心500直接进行无线通信的通信I/F(接口)。另外，通信模块330还包括用于与车辆100直接进行无线通信的通信I/F。移动终端300对车辆100与OTA中心500的通信进行中介。例如，通过移动终端300根据来自车辆100的请求而指定OTA中心500的地址并访问通信网络NW，由此车辆100(ECU110)能够经由移动终端300(通信模块330)来与OTA中心500通信。由此，建立了车辆100与OTA中心500之间的无线通信。

在移动终端300安装有用于利用OTA中心500提供的服务的应用软件(以下，称为“移动应用”)。通过移动应用，移动终端300的识别信息(终端ID)被与车辆100的识别信息(车辆ID)建立关联而登记于OTA中心500。另外，移动终端300能够通过移动应用来与OTA中心500进行信息的交换。

OTA中心500是提供基于OTA技术的车辆软件更新服务的服务器。OTA中心500构成为从该中心经由通信划分来实施远程的车载ECU软件更新。OTA中心500分发车载ECU的软件。其中，“ECU”是指电子控制装置(Electronic Control Unit)。

OTA中心500具备处理器510、存储器520以及通信模块530。处理器510例如包括CPU。存储器520例如包括闪存那样的非易失性存储器。通信模块530通过有线与通信网络NW连接，经由通信网络NW与多个移动终端(包括移动终端300)通信。通信网络NW例如是由因特网和无线基站构建的广域网络。通信网络NW可以包括移动电话网。

在OTA中心500预先登记有从OTA中心500接受车辆软件更新服务的各车辆(包括车辆100)的识别信息(车辆ID)。OTA中心500的存储装置(例如，存储器520)根据车辆ID来区别存储与各车辆相关的信息(以下，也称为“车辆信息”)。车辆信息例如包括各车辆的规格和各车辆的通信地址(关于车辆100，是指移动终端300的通信地址)。

车辆100具备多个ECU(包括ECU110、121、122)。车辆100所具备的ECU的数量任意。各车载ECU内置有具备至少1个处理器和至少1个存储器的计算机。各车载ECU可以以主微机以及副微机那样的形态具备多个微机(微型计算机)。在车辆100中，ECU彼此经由通信总线连接，构成为可有线通信。此外，ECU间的通信方式不特别限定，例如也可以是CAN(Controller Area Network)或者Ethernet(注册商标)。

ECU110具备处理器111以及存储器112。处理器111例如包括CPU。存储器112例如包括闪存那样的非易失性存储器。车辆100还具备通信装置190。ECU110通过通信装置190与车辆外部的装置进行通信。通信装置190包括用于与移动终端300直接进行无线通信的通信I/F(接口)。通信装置190与移动终端300可以进行无线LAN(Local Area Network)、NFC(NearField Communication)或者Bluetooth(注册商标)那样的近距离通信。通信装置190可以与存在于车内或者车辆周边的范围内的移动终端300直接通信。在车辆100的停车中，车内或者车外的移动终端300与ECU110可以经由通信装置190相互进行信息的交换。另外，在车辆100的行驶中，车内的移动终端300与ECU110可以经由通信装置190相互进行信息的交换。ECU110通过如上述那样向移动终端300请求与OTA中心500的通信，能够经由移动终端300与OTA中心500通信。

如上述那样，车辆100的ECU110构成为能够经由移动终端300与OTA中心500无线通信。在停车中与行驶中，车辆100均能够与OTA中心500通信。ECU110管理车辆内信息，接受活动，管理软件更新时序。

此外，车辆100与移动终端300的通信方式并不局限于上述近距离通信。车辆100与移动终端300也可以构成为即便相互远离也能够通信。另外，通信装置190可以还包括用于与未图示的扫描工具(进行有线软件更新的专用工具)进行有线通信的通信I/F。ECU110也可以经由通信装置190与和未图示的车内的DLC(Data Link Connector)连接了的扫描工具进行有线通信。

车辆100是构成为可自动驾驶的自动驾驶车辆。更详细而言，车辆100构成为能够执行有人行驶与无人行驶两方。车辆100构成为可无人自主行驶，但也能够通过用户的手动驾驶来行驶(有人行驶)。另外，车辆100也能够在有人行驶中执行自动驾驶(例如自动巡航控制)。自动驾驶的等级可以是完全自动驾驶(等级5)，也可以是带条件的自动驾驶(例如，等级4)。

车辆100还具备驾驶装置130和ADS(Autonomous Driving System)140。在车辆100中，构成为ECU121控制驾驶装置130。

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

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

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

车辆100还具备启动开关150和HMI(Human Machine Interface)170。

启动开关150是用于供用户使车辆系统(车辆100的控制系统)启动的开关，例如被设置于车厢内。一般，启动开关被称为“电源开关”或者“点火开关”等。用户通过操作启动开关150来切换车辆系统(包括被搭载于车辆的各ECU)的接通(工作)/断开(停止)。停止状态的车辆系统通过启动开关150被接通操作而启动，车辆系统成为工作状态(以下，也称为“IG接通”)。另外，在车辆系统正工作时，若启动开关150被断开操作，则车辆系统成为停止状态(以下，也称为“IG断开”)。

启动开关150的接通操作是用于将车辆的状态从IG断开切换为IG接通的操作。若用户对启动开关150进行了接通操作，则启动请求被输入至各车载ECU。即，各车载ECU受理来自用户的启动请求。另一方面，启动开关150的断开操作是用于将车辆的状态从IG接通切换为IG断开的操作。若用户对启动开关150进行了断开操作，则关闭(shutdown)请求被输入至各车载ECU，车辆100成为等待关闭状态。这样，各车载ECU受理来自用户的关闭请求。但是，在行驶中的车辆中，启动开关150的断开操作被禁止。

HMI170包括输入装置以及显示装置。HMI170可以包括作为输入装置以及显示装置发挥功能的触摸面板显示器。HMI170可以包括信息显示器或者转向指示器(tell tail)作为显示装置。HMI170可以包括转向开关作为输入装置。另外，IVI(In-VehicleInfotainment)系统、仪表面板、抬头显示器中的至少1个可以作为HMI170发挥功能。HMI170可以包括汽车导航系统的输入装置以及显示装置。

图2是用于对该实施方式所涉及的软件更新方法的概要进行说明的图。参照图1和图2，软件更新(更详细而言是利用了OTA的车辆软件的更新)所涉及的处理按照构成同步、活动通知和应用同意、下载、安装、激活、软件更新完成通知那样的步骤来进行。以下说明的处理由OTA中心500和接受来自OTA中心500的软件分发的各车辆(包括车辆100)执行。接受来自OTA中心500的分发的车辆的数量可以为50台左右，也可以为100台以上小于1000台，还可以为1000台以上。

每当经过预先设定的时间时，IG接通状态的车辆100便反复执行构成同步。另外，IG接通状态的车辆100在从OTA中心500接受到构成同步的请求的情况下也执行构成同步。车辆100(ECU110)涉及的构成同步处理包括将车辆构成信息向OTA中心500发送。车辆构成信息例如包括车辆100所包括的每个ECU的硬件信息(表示硬件的产品编号、ECU的识别符等的信息)以及软件信息(表示软件的产品编号等的信息)。在该实施方式中，车辆构成信息还包括每个认可对象的RXSWIN。RXSWIN是能够对构成功能型式认可的软件进行确定的识别编号。

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

车辆100若接受到活动通知(同意请求信号)，则向用户请求是否同意该活动的应用的输入。具体而言，车辆100例如使车载HMI(例如HMI170)显示“发现了新的软件。是否应用于该车？”那样的消息，来向用户请求表示“同意”和“拒绝”中的任一方的输入。而且，若用户对于车载HMI进行了表示“同意”的输入，则车辆100执行以下说明的下载所涉及的处理。另一方面，若用户对于车载HMI进行了表示“拒绝”的输入，则车辆100不执行下载所涉及的处理。该情况下，OTA中心500不使软件更新所涉及的处理进入至下载阶段而结束。

在该实施方式中，OTA中心500和车辆100(ECU110)按照以下说明的步骤执行下载所涉及的处理。

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

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

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

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

若紧接着下载安装也成功，则车辆100成为待激活状态。然后，若对车辆100的启动开关150进行了断开操作，则ECU110使车载HMI显示激活同意画面，向用户请求表示“同意”和“拒绝”中的某一方的输入。激活同意画面可以显示车辆100的限制事项(例如，在一定时间无法使用车辆、或者过大电流设备的动作被限制)。激活同意画面可以向用户请求将车辆100维持为非行驶状态(例如等待关闭状态、驻车挡固定、或者电动驻车制动器工作)直至激活完成为止。激活同意画面可以显示催促用户确认车辆100的状态的消息。

而且，若用户对于激活同意画面进行了表示“同意”的输入，则ECU110向各目标ECU请求激活(所安装的软件的有效化)。另一方面，若用户对于激活同意画面进行了表示“拒绝”的输入，则ECU110不执行激活而中止软件更新所涉及的处理，车辆系统被关闭。

目标ECU根据来自ECU110的请求而执行激活。在具备多个微机(例如主微机以及副微机)的目标ECU中，目标ECU内的副微机可以通过目标ECU内的主微机所具有的Flash重写功能进行重写。或者，目标ECU内的各微机可以与ECU110直接通信来进行重写。

各目标ECU将激活的结果(成功/失败)通知给ECU110。虽然详细内容将后述，但当在目标ECU中激活失败了的情况下，执行软件的回滚。另一方面，若在目标ECU中激活成功，则例如在目标ECU内的全部微机(更新对象)的重写完成的时刻，这些微机同步进行复位启动(自我复位)，启动更新后的软件。在自我复位完成后，目标ECU成为等待来自ECU110的关闭请求的状态。这样的状态的目标ECU能够继续与ECU110的诊断通信。

ECU110若从目标ECU接受到激活成功的通知，则向目标ECU请求更新后的软件的识别信息(ECU Software ID)。而且，ECU110对从目标ECU接受到的识别信息与活动信息所包括的更新后的软件的识别信息是否相互一致进行确认(构成的确认)。若构成的确认成功(即，若软件的识别信息一致)，则ECU110更新RXSWIN。RXSWIN被更新意味着激活成功。

若针对全部的目标ECU激活成功，则ECU110将软件更新状态(软件更新完成)经由移动终端300通知给OTA中心500。进行该通知意味着OTA软件更新成功。另外，ECU110也可以使车载HMI显示软件更新的结果。车载HMI显示例如表示更新的成功的软件更新完成画面。若进行了上述软件更新完成的通知，则ECU110向各目标ECU进行关闭请求，车辆100的控制系统被关闭。由此，车辆100成为IG断开。然后，若对车辆100的启动开关150进行了接通操作，则车辆系统成为IG接通。由此，在目标ECU中更新程序(新的版本的软件)启动。其中，被更新的软件任意而不局限于上述的自动驾驶控制程序那样的驾驶辅助系统的控制程序。例如，OTA中心500可以分发与娱乐相关的软件。

需要说明的是，车载ECU内的典型的微机(微型计算机)大致被分为双库微机(双库式的微型计算机)和单库微机(单库型的微型计算机)。在双库微机中，由于维持在现用面保留旧软件(原版本的软件)不变，在写入面写入新软件(新的版本的软件)，所以在激活失败的情况下，能够利用保留在现用面的旧软件来将写入面恢复(回滚)至旧软件。与此相对，在单库微机中，在1个库中进行软件的覆盖。因此，旧软件不保留。在单库微机中，可能产生在激活失败了的情况下无法恢复(回滚)至旧软件这一课题。

鉴于此，该实施方式所涉及的软件分发系统执行以下说明的图3以及图4所示的处理，针对被搭载于车辆的单库型的计算机也能够进行基于OTA技术的恰当的软件更新。

在该实施方式所涉及的软件分发系统中，成为软件更新的对象(以下，简称为“更新对象”)的微机是目标ECU所具备的单库微机和双库微机中的至少一方。虽然详细内容将后述，但在车辆100中，ECU121内置有单库微机，ECU122内置有双库微机。在目标ECU中更新对象的激活失败了的情况下，执行更新对象的回滚。特别对于相互协作来执行控制的多个微机，被要求使软件的版本一致。在这些微机中，同时执行软件的版本升级(软件更新)，当在这些微机中的任一个激活失败了的情况下，针对全部微机执行恢复至旧软件的处理(回滚处理)。

图3是表示该实施方式所涉及的软件更新方法的处理步骤的第1流程图。若成为上述的构成同步的执行时机(例如，若构成同步的执行条件成立)，则通过移动终端300以及车辆100执行该流程图所示的一系列处理。在该实施方式中，图1所示的处理器310作为本公开所涉及的“接收部”、“发送部”、“取得部”以及“判断部”的一个例子发挥功能，图1所示的存储器320作为本公开所涉及的“存储部”的一个例子发挥功能。流程图中的“S”是指步骤。通过1个以上的处理器读入存储于1个以上的存储器的程序并执行来实现下述的流程图。

参照图1、图2以及图3，S11～S17的一系列处理由移动终端300执行。S31～S36的一系列处理由车辆100执行。在S31中，ECU110经由移动终端300执行构成同步(图2)。移动终端300在S11中对车辆100与OTA中心500之间的构成同步进行中介。在存在可应用于车辆100的活动的情况下，ECU110在S32中从OTA中心500经由移动终端300接受活动通知(图2)。移动终端300在S12中对从OTA中心500向车辆100的活动通知进行中介。而且，若针对活动的应用由用户对于车载HMI进行了表示“同意”的输入，则处理进入至S13、S33。此外，在不存在可应用于车辆100的活动的情况和用户针对活动的应用进行了表示“拒绝”的输入的情况各自中，结束图3所示的一系列处理。然后，若成为构成同步的执行时机，则再次开始图3所示的一系列处理。

在S13中，移动终端300判断更新对象(成为软件更新的对象的计算机)是否为单库微机。更新对象是目标ECU所包括的微型计算机。移动终端300可以从车辆100(ECU110)取得更新对象的信息。或者，移动终端300可以从活动信息(S12)提取更新对象的信息。在更新对象为单库微机的情况下(在S13中为“是”)，移动终端300在S14中确认存储器320的空闲容量，判断在存储器320是否存在用于保存更新对象的旧软件(即，在更新对象的现用面存储的更新前的软件)的空闲容量。移动终端300可以从车辆100(ECU110)取得更新对象的旧软件(主体)的数据大小。或者，移动终端300可以从活动信息(S12)提取更新前的软件的信息。

在存储器320具有用于保存更新对象的旧软件的空闲容量的情况下(在S14中为“是”)，移动终端300在S15中向车辆100请求更新对象的旧软件(主体)。以下，将该请求(S15)也称为“第1请求”。

车辆100(ECU110)在从用户接受到表示上述的“同意”的输入之后，在S33中等待来自移动终端300的上述第1请求。具体而言，在S33中，ECU110判断从用户进行表示“同意”的输入起在规定时间以内从移动终端300是否接受到第1请求。当在S14中判断为“是”的情况下，在经过上述规定时间之前，移动终端300对于车辆100执行第1请求，在S33中判断为“是”。该情况下，ECU110在接着的S34中将更新对象的旧软件(主体)向移动终端300发送。而且，移动终端300将从车辆100接收到的旧软件(主体)保存于存储器320。然后，处理进入至S17、S35。另一方面，当在S14中判断为“否”的情况下，车辆100不接受第1请求地经过上述规定时间，在S33中判断为“否”。该情况下，不执行S34的处理，处理进入至S35。

在存储器320不具有用于保存更新对象的旧软件的空闲容量的情况下(在S14中为“否”)，移动终端300在S16中将更新对象的旧软件的版本信息保存于存储器320。旧软件的版本信息的数据大小与旧软件主体的数据大小相比非常小。移动终端300可以从车辆100(ECU110)取得更新对象的旧软件的版本信息。或者，移动终端300也可以从活动信息(S12)提取更新对象的旧软件的版本信息。

在S15或者S16中，若更新对象的旧软件主体或者旧软件版本信息被保存于存储器320，则处理进入至S17。在S17中，移动终端300通过无线通信从OTA中心500接收更新对象的新软件(新的版本的软件主体)，并将接收到的新软件通过无线通信向车辆100发送。

在S35中，车辆100(ECU110)判断是否从移动终端300接收到上述新软件(S17)。而且，若车辆100从移动终端300接收到新软件(在S35中为“是”)，则ECU110在S36中执行新软件的下载以及安装(图2)。具体而言，ECU110经由移动终端300执行更新对象的新软件的下载(图2)。移动终端300在S17中对从OTA中心500向车辆100的下载进行中介。而且，若下载成功，则新软件被写入(安装)至更新对象。

在更新对象包括多个微机(计算机)的情况下，按每个更新对象执行S13～S17以及S33～S36的处理。在更新对象为单库微机的情况下(在S13中为“是”)，移动终端300如上述那样在S15或者S16中使存储器320存储更新对象的旧软件或者其版本信息，然后在S17中，将从OTA中心500取得的新软件(更新用软件)向车辆100发送。另一方面，在更新对象为双库微机的情况下(在S13中为“否”)，不进行S14～S16的处理，执行S17的处理。而且，由于不进行S15的处理，所以在S33中判断为“否”。

在针对全部的更新对象完成了新软件的下载以及安装之后，若规定的激活开始条件成立，则处理进入至图4的S21、S41。例如，若激活开始条件成立，则ECU110向各目标ECU请求激活。而且，开始以下说明的图4所示的一系列处理。图4是表示该实施方式所涉及的软件更新方法的处理步骤的第2流程图。

参照图1、图2以及图4，在S41中，车辆100的目标ECU根据来自ECU110的请求而执行更新对象的激活(图2)。ECU110例如判断车辆100是否处于可激活的状态，在判断为车辆100处于可激活的状态(例如等待关闭状态)的情况下，向目标ECU请求更新对象的激活。

在紧接着的S42中，目标ECU判断更新对象的激活是否成功。在更新对象的激活失败了的情况下(在S42中为“否”)，目标ECU将激活失败通知给ECU110。接受到通知的ECU110向目标ECU请求更新对象的回滚。并且，ECU110向具备与该更新对象协作的微机(即，以与该更新对象相同的版本的软件进行动作的微机)的ECU请求该微机的回滚。然后，处理进入至S44。

在更新对象的激活成功了的情况下(在S42中为“是”)，目标ECU在S43中进而判断与该更新对象协作的微机是否激活失败。目标ECU可以基于来自ECU110的上述回滚请求的有无来判断与该更新对象协作的微机是否激活失败。在与该更新对象协作的任一微机激活失败的情况下(在S43中为“是”)，处理进入至S44。

在S44中，目标ECU判断更新对象是否为单库微机。在更新对象为单库微机的情况下(在S44中为“是”)，车辆100(目标ECU)在S45中向移动终端300请求更新对象的旧软件(主体)。以下，将该请求(S45)也称为“第2请求”。

在上述的下载完成后，移动终端300在S21中等待来自车辆100的上述第2请求。具体而言，在S21中，移动终端300判断从下载完成起在规定时间以内是否从车辆100接受到第2请求。当在S44中判断为“是”的情况下，在经过上述规定时间之前车辆100对于移动终端300执行第2请求。由此，在S21中判断为“是”，处理进入至S22。另一方面，当在S44中判断为“否”的情况下，移动终端300不接受第2请求地经过上述规定时间，在S21中判断为“否”。该情况下，不执行S22～S24的处理，处理进入至S25。

在S22中，移动终端300判断移动终端300是否保有更新对象的旧软件(主体)。在执行了图3的S15的处理的情况下，在S22中判断为“是”，处理进入至S24。该情况下，移动终端300在紧接着的S24中将存储于存储器320的更新对象的旧软件(主体)向车辆100(目标ECU)发送。然后，处理进入至S25。

在未执行图3的S15的处理的情况下(即，在执行了图3的S16的处理的情况下)，在S22中判断为“否”，处理进入至S23。在S23中，移动终端300基于存储于存储器320的更新对象的旧软件的版本信息(图3的S16)来从OTA中心500取得更新对象的旧软件(主体)。该情况下，移动终端300在紧接着的S24中将从OTA中心500取得的更新对象的旧软件(主体)向车辆100(目标ECU)发送。然后，处理进入至S25。

在更新对象为单库微机的情况下(在S44中为“是”)，车辆100接收上述更新对象的旧软件(S24)。由此，车辆100的目标ECU在S46中使用从移动终端300接收到的上述更新对象的旧软件(主体)来执行更新对象的回滚处理(恢复至旧软件的处理)。目标ECU从移动终端300接收更新对象的旧软件(主体)，并利用接收到的旧软件(主体)将更新对象的库(单库)恢复至更新前的状态。

在更新对象为双库微机的情况下(在S44中为“否”)，车辆100不从移动终端300接收上述更新对象的旧软件(S24)地车辆100的目标ECU在S46中执行更新对象的回滚处理。

图5是用于对ECU122所具备的双库微机的激活(回滚)处理进行说明的图。以下，对ECU122为目标ECU且双库微机MC2为更新对象的例子进行说明。

参照图5，ECU122具备具有2个库(第1库以及第2库)的双库微机MC2。具体而言，双库微机MC2具备2个存储器(例如闪速存储器)，各存储器在微机内形成有库。例如，在第1库为现用面的情况下，第2库成为写入面。在现用面(第1库)存储有旧软件。在写入面(第2库)，通过上述的下载处理以及安装处理(图3的S36)被写入新软件。然后，ECU122(目标ECU)在图4的S41中将双库微机MC2的写入面切换(激活)为现用面。在ECU122对双库微机MC2的激活成功且ECU122未从ECU110接受到回滚请求的情况下，ECU122在进行了自我复位之后，成为等待来自ECU110的关闭请求的状态。该情况下，存储旧软件的第1库成为写入面，被写入了新软件的第2库成为现用面。即，双库微机MC2利用新软件(更新后的程序)进行启动。另一方面，在ECU122从ECU110接受到回滚请求的情况下，ECU122执行双库微机MC2的回滚处理(图4的S46)。该情况下，存储旧软件的第1库恢复至现用面，第2库成为写入面。另外，在写入面写入旧软件。然后，双库微机MC2利用旧软件(更新前的程序)进行启动。

图6是用于对ECU121所具备的单库微机的激活(回滚)处理的第1例进行说明的图。以下，对ECU121是目标ECU且单库微机MC1为更新对象的例子进行说明。并且，在该例子中，存储器320具有用于在下载时保存单库微机MC1的更新前的软件(主体)的空闲容量。

参照图6，ECU121具备具有1个库(单库)的单库微机MC1。具体而言，单库微机MC1具备1个存储器(例如闪速存储器)，该存储器在微机内形成有库。单库微机MC1相当于进行车辆100的行驶控制的计算机。例如，在通常动作时，库成为现用面。在软件更新前，在库中存储有旧软件。在软件更新时，库成为写入面。而且，通过上述的下载处理以及安装处理(图3的S36)在库中写入新软件。其中，在写入前，旧软件(更新前的软件)被保存于移动终端300的存储器320(图3的S15)。

然后，ECU121(目标ECU)在图4的S41中将单库微机MC1的写入面切换(激活)为现用面。在ECU121对单库微机MC1的激活成功且ECU121未从ECU110接受到回滚请求的情况下，ECU121在进行了自我复位(self-reset)之后成为等待来自ECU110的关闭请求的状态。该情况下，被写入了新软件的库成为现用面。即，单库微机MC1利用新软件(更新后的程序)进行启动。另一方面，在ECU121从ECU110接受到回滚请求的情况下，ECU121执行单库微机MC1的回滚处理(图4的S44～S46)。具体而言，ECU121从移动终端300(存储器320)接收旧软件(主体)，来在单库微机MC1的库中写入旧软件。然后，被写入了旧软件的库成为现用面。该情况下，单库微机MC1以旧软件(更新前的程序)启动。

图7是用于对ECU121所具备的单库微机的激活(回滚)处理的第2例进行说明的图。以下，对ECU121为目标ECU且单库微机MC1为更新对象的例子进行说明。但在该例子中，存储器320不具有在下载时用于保存单库微机MC1的更新前的软件(主体)的空闲容量。

参照图7，在该例子中，也是在软件更新时单库微机MC1的库成为写入面，通过上述的下载处理以及安装处理(图3的S36)在该库写入新软件。但在该例子中，在写入前旧软件的版本信息而非旧软件主体被保存于移动终端300的存储器320(图3的S16)。

然后，ECU121(目标ECU)在图4的S41中将单库微机MC1的写入面切换(激活)为现用面。在ECU121对单库微机MC1的激活成功且ECU121未从ECU110接受到回滚请求的情况下，ECU121在进行了自我复位之后成为等待来自ECU110的关闭请求的状态。该情况下，被写入了新软件的库成为现用面。即，单库微机MC1利用新软件(更新后的程序)进行启动。另一方面，在ECU121从ECU110接受到回滚请求的情况下，ECU121执行单库微机MC1的回滚处理(图4的S44～S46)。具体而言，ECU121向移动终端300请求旧软件(图4的S45)。而且，移动终端300根据来自ECU121的请求而从OTA中心500取得存储于存储器320的上述版本信息所表示的版本的软件(主体)，并将所取得的软件(主体)向车辆100(ECU121)发送。ECU121从移动终端300接收旧软件(主体)，并在单库微机MC1的库写入旧软件。然后，被写入了旧软件的库成为现用面。该情况下，单库微机MC1利用旧软件(更新前的程序)进行启动。

再次参照图1、图2以及图4，在S46中，目标ECU如上述那样执行更新对象的回滚处理。当在激活中发生某些故障而更新对象的激活失败时，目标ECU可以使用更新前的日志文件(写入日志信息的文件)来将更新对象恢复至正常的状态。若所请求的回滚完成，则目标ECU对于ECU110通知回滚完成。ECU110若接受到回滚完成的通知，则向目标ECU请求更新前的软件的识别信息(ECU Software ID)。而且，ECU110对从目标ECU接受到的识别信息与活动信息所包括的更新前的软件的识别信息是否相互一致进行确认(构成的确认)。这里的构成的确认成功(即，软件的识别信息一致)意味着回滚成功。在软件的识别信息不一致的情况下，ECU110可以向目标ECU请求回滚的重新进行。

在回滚成功了的情况下，处理进入至S47。另外，在更新对象的激活成功(在S42中为“是”)且与更新对象协作的任一微机均未激活失败的情况下(在S43中为“否”)，处理也进入至S47。在更新对象包括多个微机(计算机)的情况下，按每个更新对象执行S41～S46以及S21～S24的处理。而且，若针对全部的更新对象激活或者回滚成功，则车辆100(ECU110)在S47中对于移动终端300进行结束通知。而且，若执行了S47的处理，则车辆100涉及的S31～S47的一系列处理结束。

在S25中，移动终端300判断是否接收到来自车辆100的上述结束通知(S47)。在移动终端300未接收到上述结束通知的情况下(在S25中为“否”)，处理返回至S21。而且，若移动终端300接收到上述结束通知(在S25中为“是”)，则移动终端300涉及的S11～S25的一系列处理结束。

如以上说明那样，该实施方式所涉及的软件分发系统具备移动终端300、车辆100以及OTA中心500(服务器)。另外，移动终端300具备处理器310和存储器320(存储部)。而且，处理器310构成为能够执行：从车辆100接收被搭载于车辆100的单库型的计算机的更新前的软件(图3的S15)；和在使存储器320存储接收到的更新前的软件(图3的S15)之后，将从OTA中心500取得的更新用软件向车辆100发送(图3的S17)。

根据具有上述构成的移动终端300，在车辆100对单库型的计算机(例如，图6所示的单库微机MC1)的软件更新(例如激活)失败了的情况下，能够使用保存于移动终端300的存储器320的更新前的软件来进行回滚。由此，除了被搭载于车辆100的双库式的计算机之外，针对单库型的计算机也能够进行基于OTA技术的恰当的软件更新。

另外，移动终端300的处理器310构成为能够执行：取得更新前的软件的版本信息的步骤(图3的S16)；和在单库型的计算机的软件更新中对存储器320(存储部)是否具有用于保存更新前的软件的空闲容量进行判断(图3的S14)。而且，处理器310在判断为存储器320具有用于保存更新前的软件的空闲容量的情况下(在图3的S14中为“是”)，从车辆100接收更新前的软件(图3的S15)，使存储器320存储该更新前的软件(图3的S15)，然后将从OTA中心500取得的更新用软件向车辆100发送(图3的S17)。另外，处理器310在判断为存储器320不具有用于保存更新前的软件的空闲容量的情况下(在图3的S14中为“否”)，取得更新前的软件的版本信息(图3的S16)，使存储器320存储该版本信息(图3的S16)，然后将从OTA中心500取得的更新用软件向车辆100发送(图3的S17)。

根据具有上述构成的移动终端300，能够根据存储器320的空闲容量来恰当地保存用于回滚的数据(详细而言是更新前的软件或者其版本信息)。在存储器320的空闲容量充分大的情况下，通过将更新前的软件本身预先保存于存储器320，能够尽早执行回滚。

该实施方式所涉及的车辆100具备管理软件更新的时序的ECU110(控制装置)。ECU110构成为使用从移动终端300接受到的更新用软件来执行单库型的计算机的软件更新(图3的S36以及图4的S41)，在该软件更新失败了的情况下，从移动终端300接受更新前的软件，使用更新前的软件来执行回滚(图4的S44～S46)。根据具有这样的构成的车辆100，容易在车辆侧管理软件更新。

上述图3以及图4所示的处理能够适当地变更。例如，在上述实施方式中，在S13(图3)、S44(图4)中对更新对象是否为单库微机进行了判断。然而，根据车辆，有时搭载内置有具有用于回滚的存储部的单库微机的ECU。在向这样的车辆分发软件的系统中，可以在S13(图3)、S44(图4)中对更新对象是否是不具有用于回滚的存储部的单库微机进行判断。即，即便更新对象是单库微机，在更新对象具有用于回滚的存储部的情况下，也可以在S13(图3)、S44(图4)各自中判断为“否”。作为具有用于回滚的存储部的单库微机的例子，可举出在库内设置有用于回滚的存储部的单库微机、外接设置有用于回滚的存储部(非易失性存储器)的单库微机。这样的单库微机能够以依照双库微机的方式进行回滚。

图8是表示图3所示的处理的第1变形例的流程图。在该变形例中，图1所示的处理器310作为本公开所涉及的“接收部”、“发送部”、“更新部”以及“报告部”的一个例子发挥功能，图1所示的存储器320作为本公开所涉及的“存储部”的一个例子发挥功能。

参照图1、图2以及图8，在该变形例中，当在S33中判断为“否”的情况下处理不推进，当在S33中判断为“否”的期间，反复进行S33的判断。另外，采用S16A来代替S16(图3)。在存储器320不具有用于保存更新对象的旧软件(主体)的空闲容量的情况下(在S14中为“否”)，移动终端300在S16A中进行规定的报告。具体而言，移动终端300例如显示画面Sc1。画面Sc1显示催促用户增加存储器320的空闲容量的消息。用户能够通过操作移动终端300来停止在移动终端300正启动的不需要的应用、删除存储于存储器320的不需要的数据而增加存储器320的空闲容量。在用于保存旧软件(主体)的存储器320的空闲容量不足的期间(在S14中为“否”)，反复进行S14以及S16A，移动终端300持续显示画面Sc1(S16A)。而且，用户若根据画面Sc1的请求而将空闲容量增加至存储器320的空闲容量变得充分(在S14中为“是”)，则移动终端300在S15中向车辆100请求更新对象的旧软件(主体)(第1请求)。由此，在S33中判断为“是”，车辆100(ECU110)在S34中将更新对象的旧软件(主体)向移动终端300发送。

在上述的第1变形例中，移动终端300反复进行S14、S16A的处理，直至移动终端300的处理器310在存储器320(存储部)确保了用于在单库型的计算机的软件更新中保存更新前的软件的空闲容量为止(在S14中为“否”)。由此，在车辆100侧反复进行S33。因此，该软件更新被搁置。而且，当在存储器320确保了用于保存更新前的软件的空闲容量之后(在S14中为“是”)，移动终端300通过第1请求(S15)来允许单库型的计算机的软件更新。由此，车辆100侧的处理进入至S34，执行单库型的计算机的软件更新。通过上述那样的处理，可抑制软件更新在无法回滚的状况下推进。另外，处理器310构成为当在单库型的计算机的软件更新中用于保存更新前的软件的存储器320(存储部)的空闲容量不足的情况下(在S14中为“否”)，进行规定的报告(S16A)。通过这样的报告处理，用户容易掌握状况。

此外，在上述的第1变形例中，由于在图4的S22中始终判断为“是”，所以可以省略图4的S22以及S23，当在S21中判断为“是”的情况下，处理进入至S24。

图9是表示图3所示的处理的第2变形例的流程图。在该变形例中，图1所示的处理器310作为本公开所涉及的“发送部”以及“取得部”的一个例子发挥功能，图1所示的存储器320作为本公开所涉及的“存储部”的一个例子发挥功能。

参照图1、图2以及图9，在该变形例中，没有S14、S15、S33以及S34(图3)。若在S13中判断为“是”，则移动终端300在S16中仅将更新对象的旧软件的版本信息保存于存储器320。移动终端300可以从车辆100取得更新对象的旧软件的版本信息。或者，移动终端300可以从活动信息(S12)提取更新对象的旧软件的版本信息。通过上述S16的处理，若更新对象的旧软件的版本信息被保存于存储器320，则处理进入至S17。

在上述的第2变形例所涉及的软件分发系统中，移动终端300具备处理器310和存储器320(存储部)。而且，处理器310构成为能够执行：取得被搭载于车辆100的单库型的计算机的更新前的软件的版本信息(S16)；和在使存储器320存储(S16)该版本信息之后将从OTA中心500(服务器)取得的更新用软件向车辆100发送(S17)。

根据具有上述构成的移动终端300，在车辆100对单库型的计算机的软件更新失败了的情况下，移动终端300能够基于预先保存于存储器320的更新前的软件的版本信息来从OTA中心500取得更新前的软件。而且，车辆100能够从移动终端300接收更新前的软件，使用该更新前的软件来进行单库型的计算机的回滚。其中，在上述的第2变形例中，由于在图4的S22中始终判断为“否”，所以可以省略图4的S22，当在S21中判断为“是”的情况下，处理进入至S23。

移动终端300的接收部、发送部、取得部、判断部、更新部以及报告部可以由专用的硬件(电子电路)而非软件具现化。另外，在上述实施方式中，采用内部部署服务器作为OTA中心500(参照图1)。然而并不局限于此，也可以通过云计算在云上安装OTA中心500的功能(例如，软件分发所涉及的功能)。即，OTA中心500也可以是云服务器。

车辆可以具备具有OTA访问功能的OTA管理器。车辆可以包括进行与OTA中心的无线通信的TCU(Telematics Control Unit)以及/或者DCM(Data Communication Module)。车辆构成为可自动驾驶并不是必须的。车辆也可以是BEV以外的xEV(电动车)。车辆可以具备内燃机(例如汽油发动机、生物燃料发动机或者氢发动机)。车辆并不局限于4轮的乘用车，也可以是巴士或者卡车，也可以是3轮的xEV。车辆可以具备飞行功能。车辆可以是在MaaS(Mobility as a Service)中利用的车辆。车辆也可以是根据用户的使用目的而定制的多目的车辆。车辆也可以是移动店铺车辆、自动驾驶出租车(robotaxi)、无人搬运车(AGV)或者农业机械。车辆也可以是无人或者1人乘坐的小型BEV(例如最后一英里用的BEV、电动轮椅或者电动滑板车)。

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

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

Claims (8)

1.一种移动终端，其特征在于，包括：

存储部；

接收部，构成为从车辆接收被搭载于所述车辆的单库型的计算机的更新前的软件；以及

发送部，构成为在使所述存储部存储了接收到的所述更新前的软件之后将从服务器取得的更新用软件向所述车辆发送。

2.根据权利要求1所述的移动终端，其特征在于，还包括：

取得部，构成为取得所述更新前的软件的版本信息；和

判断部，构成为在所述单库型的计算机的软件更新中对所述存储部是否具有用于保存所述更新前的软件的空闲容量进行判断，

其中，所述移动终端构成为：

在所述判断部判断为所述存储部具有用于保存所述更新前的软件的所述空闲容量的情况下，所述接收部从所述车辆接收所述更新前的软件，在使所述存储部存储了所述更新前的软件之后，所述发送部将从所述服务器取得的所述更新用软件向所述车辆发送，

在所述判断部判断为所述存储部不具有用于保存所述更新前的软件的所述空闲容量的情况下，所述取得部取得所述更新前的软件的所述版本信息，在使所述存储部存储了所述版本信息之后，所述发送部将从所述服务器取得的所述更新用软件向所述车辆发送。

3.根据权利要求1所述的移动终端，其特征在于，

还包括更新部，该更新部构成为：在所述单库型的计算机的软件更新中，搁置该软件更新直至在所述存储部确保了用于保存所述更新前的软件的空闲容量为止，当在所述存储部确保了用于保存所述更新前的软件的所述空闲容量之后，允许所述单库型的计算机的软件更新。

4.根据权利要求3所述的移动终端，其特征在于，

还包括报告部，该报告部构成为在所述单库型的计算机的软件更新中，当用于保存所述更新前的软件的所述存储部的所述空闲容量不足的情况下进行规定的报告。

5.根据权利要求1所述的移动终端，其特征在于，

所述接收部构成为通过无线通信来从所述服务器取得所述更新用软件，

所述发送部构成为通过无线通信来将所述更新用软件向所述车辆发送。

6.一种移动终端，其特征在于，包括：

存储部；

取得部，构成为取得被搭载于车辆的单库型的计算机的更新前的软件的版本信息；以及

发送部，构成为在使所述存储部存储了所述更新前的软件的所述版本信息之后将从服务器取得的更新用软件向所述车辆发送。

7.一种软件分发系统，其特征在于，

包括权利要求1～6中任一项所述的移动终端、所述车辆以及所述服务器，

其中，

所述车辆具备构成为管理软件更新的时序的控制装置，

所述控制装置构成为：

使用从所述移动终端接受到的所述更新用软件来执行所述单库型的计算机的软件更新，

在该软件更新失败了的情况下，从所述移动终端接受所述更新前的软件，使用所述更新前的软件来执行回滚。

8.根据权利要求7所述的软件分发系统，其特征在于，

所述单库型的计算机是进行所述车辆的行驶控制的计算机。