车载设备软件的批量升级方法及装置与流程

1.本发明涉及车辆通信技术领域，特别涉及一种车载设备软件的批量升级方法及装置。


背景技术：

2.动车组车载设备装车交付后，在之后的整个生命周期中，无论是因为用户需求的变更，业务功能的增加还是自身软件存在的bug等原因，都需要进行自身软件的升级。
3.通常，各车载设备的供应商在交付各自的设备时，都会单独交付一个软件升级专属工具，用户只需要通过该工具就能实现上述维护功能，这种方式从使用角度来说无可厚非，但是，动车组的车载设备种类繁多，涉及到的厂家和供应商也都不尽相同，导致软件升级工具的数量非常多，并且每种升级工具的升级流程、操作步骤和方法都不尽相同，对于维护人员来说，若逐一进行升级，操作复杂，容易出错。
4.应该注意，上面对背景技术的介绍只是为了方便对本技术的技术方案进行清楚、完整的说明，并方便本领域技术人员的理解而阐述的。不能仅仅因为这些方案在本技术的背景技术部分进行了阐述而认为上述技术方案为本领域技术人员所公知。


技术实现要素：

5.为了克服现有技术的上述缺陷，本发明实施例中提供了一种车载设备软件的批量升级方法及装置，其能够简单高效的实现全车所有车载设备软件的升级。
6.本发明实施例的具体技术方案是：
7.一种车载设备软件的批量升级方法，所述车载设备软件配置有与目标车辆的其它车载设备软件相同的升级协议，所述批量升级方法基于所述升级协议执行以下步骤：
8.响应于接收到的批量升级请求，获取所述车载设备软件的升级包；
9.响应于接收到的所述升级包，对所述升级包进行验证；
10.响应于所述升级包验证通过，对所述升级包进行安装。
11.优选地，所述获取所述车载设备软件的升级包，包括：
12.获取所述车载设备软件的升级文件以得到升级包，所述升级包为单一压缩包文件，所述升级包的打包方式如下：将所述升级文件和安装脚本进行打包，得到的内层压缩包；将所述内层压缩包和配置说明文件进行打包，得到外层压缩包作为所述升级包，其中，所述配置说明文件包括所述内层压缩包的验证信息；
13.将所述升级包存储至存储端。
14.优选地，所述配置说明文件包括公钥和签名信息；
15.所述响应于接收到的所述升级包，对所述升级包进行验证，包括：
16.采用所述公钥对所述签名信息进行解密，得到第一摘要信息；
17.采用预设加密算法对所述内层压缩包进行摘要运算，得到第二摘要信息；
18.将所述第一摘要信息与所述第二摘要信息进行比较，若二者相同，则验证通过。
19.优选地，所述公钥由所述车载设备软件厂商的私钥生成；
20.采用所述私钥对所述摘要信息进行椭圆曲线数字签名，得到所述签名信息。
21.优选地，所述批量升级请求包括多个所述车载设备软件的升级包所存储的存储端的ip地址和所述升级包的存储路径；
22.所述响应于接收到的批量升级请求，获取所述车载设备软件的升级包，包括：
23.向所述存储端发送升级包下载请求，所述升级包下载请求包括所述存储端的ip地址和所述升级包的存储路径；
24.从所述存储端下载所述升级包。
25.优选地，所述批量升级方法还包括：
26.响应于用户端发送的车载设备发现请求，向所述用户端发送所述目标车辆的所有车载设备的设备信息，其中，所述设备信息包括所述车载设备的硬件信息和车载设备软件的信息。
27.优选地，所述目标车辆为单编车组，基于ssdp协议向所述用户端发送所述单编车组的所有车载设备的设备信息；
28.或者，
29.所述目标车辆为重联车组，基于ssdp协议和ttdp协议向所述用户端发送所述重联车组的所有车载设备的设备信息。
30.优选地，所述响应于所述升级包验证通过，对所述升级包进行安装，包括：
31.将所述升级包存储至与所述车载设备软件加载运行的第一存储分区不同的第二存储分区；
32.响应于所述升级包存储至所述第二存储分区并且升级安装成功，将所述车载设备软件加载运行的分区更改为所述第二存储分区；
33.响应于所述升级包存储至所述第二存储分区失败或者升级安装失败，仍将所述第一存储分区作为所述车载设备软件加载运行的分区。
34.优选地，所述批量升级方法还包括：
35.响应于用户端发送的所述批量升级请求，向所述用户端发送升级请求回复；
36.响应于所述用户端发送的升级进度查询请求，向所述用户端发送所述升级包的下载进度回复；
37.响应于所述用户端发送的升级进度查询请求，向所述用户端发送所述升级包的验证结果；
38.响应于所述用户端发送的升级进度查询请求，向所述用户端发送所述升级包的安装进度回复。
39.一种车载设备软件的批量升级方法，包括：
40.用户端发送车载设备发现请求，其中，所述车载设备发现请求是获取目标车辆的所有车载设备的设备信息的请求，所述设备信息包括所述车载设备的ip地址和车载设备软件信息；
41.所述车载设备响应于用户端发送的车载设备发现请求，向所述用户端发送所述目标车辆的所有车载设备的设备信息，其中，所述设备信息包括所述车载设备的硬件信息和车载设备软件的信息；
42.所述用户端获取所述目标车辆的所有车载设备的设备信息，根据所述设备信息，确定需要升级的车载设备软件；。
43.所述用户端发送批量升级请求，其中，所述升级请求是对目标车辆的多个车载设备软件进行升级的请求，多个所述车载设备软件配置有相同的升级协议，所述升级协议包括：
44.所述车载设备响应于接收到的所述批量升级请求，获取所述车载设备软件的升级包；
45.所述车载设备响应于接收到的所述升级包，对所述升级包进行验证；
46.所述车载设备响应于所述升级包验证通过，对所述升级包进行安装。
47.一种车载设备软件的批量升级装置，所述车载设备软件的批量升级装置中配置有与目标车辆的其它车载设备软件相同的升级协议，所述车载设备软件的批量升级装置包括：
48.升级包获取模块，用于响应于接收到的批量升级请求，获取所述车载设备软件的升级包；
49.验证模块，用于响应于接收到的所述升级包，对所述升级包进行验证；
50.安装模块，用于响应于所述升级包验证通过，对所述升级包进行安装。
51.本技术可以取得如下有益效果：
52.本技术中的车载设备软件的批量升级方法及装置针对现行动车组车载软件升级架构进行了优化设计，统一了所有车载设备软件的升级协议，在保证安全可靠的前提下，可以简单高效的实现全车软件一键升级的操作。本技术相比于传统方法可以极大的降低现场操作人员的学习成本，减小操作复杂度，从而避免传统升级方式因为繁琐的操作流程带来的操作失误导致升级失败的风险。
附图说明
53.在此描述的附图仅用于解释目的，而不意图以任何方式来限制本发明公开的范围。另外，图中的各部件的形状和比例尺寸等仅为示意性的，用于帮助对本发明的理解，并不是具体限定本发明各部件的形状和比例尺寸。本领域的技术人员在本发明的教导下，可以根据具体情况选择各种可能的形状和比例尺寸来实施本发明。
54.图1为本发明在实施例中车载设备一侧的流程图。
55.图2为本发明实施例中批量升级方法的交互示意图。
56.图3为本发明实施例中车载设备的车载设备软件升级过程示意图。
57.图4为本发明实施例中车载设备软件的发布流程和签名校验流程示意图。
58.图5为本发明实施例中车载设备软件双存储分区安装示意图。
59.图6为本发明实施例中发现所有车载设备的流程示意图。
60.图7为本发明实施例中车载设备软件的批量升级装置的结构示意图。
具体实施方式
61.结合附图和本发明具体实施方式的描述，能够更加清楚地了解本发明的细节。但是，在此描述的本发明的具体实施方式，仅用于解释本发明的目的，而不能以任何方式理解
成是对本发明的限制。在本发明的教导下，技术人员可以构想基于本发明的任意可能的变形，这些都应被视为属于本发明的范围。
62.不同厂商的车载设备一般都采用自己私有的协议进行软件升级，从而导致全车设备的升级方法和升级协议都不尽相同，这样一方面给全车的网络安全策略部署造成较多的开销，另一方面对于全车设备软件的批量升级也会造成较大的困难，不仅增加了维护功能的使用复杂度，增加了现场维护出错的概率，而且即使是把每种工具软件整合到一起，而不在维护界面和维护协议上进行统一，对于维护人员而言仍然需要较高的学习成本。为了能够简单高效的实现全车所有车载设备软件的升级，在本技术中提出了一种车载设备软件的批量升级方法，图1为本发明在实施例中车载设备一侧的流程图，如图1所示，该车载设备软件的批量升级方法可以应用于车载设备一侧，车载设备上安装有车载设备软件。
63.目前不同厂商的车载设备一般都采用私有协议进行软件升级，从而导致全车设备的升级方法和升级协议都不尽相同，一方面给全车的网络安全策略部署造成较多的开销，另一方面对于全车设备软件的批量升级也会造成较大的困难。针对上述问题，车载设备软件配置有与目标车辆的其它车载设备软件相同的升级协议，也就是说，目标车辆可以为单编车组或者重联动车组，该车载设备可以与单编车组或者重联动车组中其它车载设备上的车载设备软件具有相同的升级协议。
64.所述批量升级方法基于所述升级协议可以执行以下步骤：
65.s101：响应于用户端发送的车载设备发现请求，向所述用户端发送所述目标车辆的所有车载设备的设备信息，其中，所述设备信息包括所述车载设备的硬件信息和车载设备软件的信息。
66.通常车载设备维护功能的数据传输物理接口都是基于自身的以太网接口，因为要通过以太网接口进行维护就必须要ip地址，目前大多数厂商给出的实现所有维护功能的第一步都是要用户预输ip地址，虽然通常车载设备ip地址的规划和分配都是采用固定规划的方式，然而不同的动车组项目上不同的设备类型，以及相同的设备类型不同的部署位置，ip地址都是不尽相同的，那么现场售后用户在执行维护工作时势必就要记忆大量的ip地址对应关系，且不能出错，很明显这种方式会对售后用户产生巨大的困扰，增加他们的使用负担，从而增加现场维护出错的风险。
67.为了解决上述问题，在本技术中用户可以通过ptu软件接入车载tcms后，图6为本发明实施例中发现所有车载设备的流程示意图，如图6所示，可通过ptu软件向当前单编车组和/或重联编组的所有车载设备发送车载设备发现请求，其中，所述车载设备发现请求是获取目标车辆的所有车载设备的设备信息的请求，所述设备信息包括所述车载设备的ip地址和车载设备软件信息。车载设备响应于用户端发送的车载设备发现请求，向所述用户端(ptu软件)发送所述目标车辆的所有车载设备的设备信息，其中，所述设备信息包括所述车载设备的硬件信息和车载设备软件的信息，例如包括设备类型，位置信息，ip地址，硬件序列号，软件版本，硬件版本等信息。用户通过ptu软件便能一键发现单编车组和/或重联编组的所有车载设备的软硬件版本信息，根据该信息用户可以确定哪些车载设备软件需要进行后续的升级操作。
68.对于所述目标车辆为单编车组，基于ssdp协议向所述用户端发送所述单编动车组的所有车载设备的设备信息，ptu软件一侧也是基于ssdp协议向当前单编车组发送车载设
备发现请求。基于ssdp协议的车载设备发现请求是基于udp的广播请求报文，所有车载设备会监听该广播情况，当收到ptu发出的ssdp协议的车载设备发现请求后会以单播报文进行回复表征自己的存在。
69.对于所述目标车辆为重联车组，基于ssdp协议和ttdp协议向所述用户端发送所述重联车组的所有车载设备的设备信息。其中，ttdp协议具体可以为iec61375-2-5标准规定ttdp协议。例如，ptu软件在以太网编组网(ecn)中的ip地址为10.1.0.10。通过ssdp协议在以太网编组网(ecn)将车载设备发现请求发送出去，在车载设备发现请求的报文中包括目的ip地址和源ip地址，在报文的数据内容中还可以包括跨域组地址。编组网中的etbn交换机会将ptu软件发出的车载设备发现请求的报文中数据内容中的跨域组地址修改成具有自己的etbn交换机ip地址信息和ptu软件在该以太网编组网(ecn)的ip信息的跨域组地址。例如自己的etbn交换机ip地址信息的前三位为10.128.64，ptu软件在该以太网编组网(ecn)的ip信息的最后位为10,因此，编组网中的etbn交换机将ptu软件发出的车载设备发现请求的报文中数据内容中的跨域组地址修改为10.128.61.10，并且将车载设备发现请求广播至重联车组的实时以太网etb，重联车组的实时以太网etb能够通过发现请求的报文中数据内容中的跨域组地址识别出具体ptu软件所在的以太网编组网(ecn)中具体的位置。重联车的以太网etb将车载设备发现请求广播至重联车组的其它列动车组的以太网编组网(ecn)中的etbn交换机中，当其它列动车组中的车载设备会监听该车载设备发现请求的广播情况，当发现车载设备发现请求后会以单播报文进行回复表征自己的存在。此时，其它列动车组的以太网编组网(ecn)会将该车载设备回复的设备信息的报文中的数据内容中的跨域组地址进行修改，修改成具有该列动车组ip信息和该车载设备在该列动车组下的ip信息的一个跨域组地址。例如，该列动车组ip地址为10.128.128.1，其前三位为10.128.128，而该车载设备在该列动车组下的ip地址为10.1.0.20，其最后一位为20，两者组成一个新的ip地址，为10.128.128.20。这样用户端即udp软件接收到该车载设备回复的设备信息的报文时就可以通过跨域组地址知晓该车载设备为哪列动车组的哪个车载设备。
70.s102：响应于接收到的批量升级请求，获取所述车载设备软件的升级包。
71.当需要对车载设备的车载设备软件进行批量升级前，图3为本发明实施例中车载设备的车载设备软件升级过程示意图，如图3所示，所有车载设备的升级状态均处于初始状态，即升级等待状态，等待ptu的升级指令。
72.当需要对车载设备的车载设备软件进行批量升级时，图2为本发明实施例中批量升级方法的交互示意图，如图2所示，用户可以发起升级操作，例如通过ptu软件向目标车辆中指定的一个或多个或者所有车载设备的车载设备软件发送单个升级请求或者批量升级请求，可以以升级命令报文的形式；目标车辆上的车载设备的车载设备软件接收ptu软件发送的批量升级请求，如果判断出自身当然处于等待升级状态和是指定的车载设备，则接受升级请求，进而响应于接收到的批量升级请求，获取所述车载设备软件的升级包。为了响应于接收到的批量升级请求，车载设备可以向ptu软件发送一个与批量升级请求相对应的升级请求回复，可以以报文的形式，以使ptu软件确定车载设备软件接收到了批量升级请求，同时表示接收此次升级操作。单个升级请求或者批量升级请求中可以包括有restapi协议报文，其可以携带多个所述车载设备软件的升级包所存储的存储端的ip地址，如tftp服务器地址，升级包的存储路径，升级软件包签名文件，升级软件包大小，升级软件包期望版本
等信息作为http协议参数。如果判断出自身不满足条件，则可以拒绝该次升级请求。
73.在ptu软件和车载设备进行控制交互的过程中，本技术可以采用目前在移动互联网领域广泛应用的http协议的restapi作为ptu和车载设备控制交互的接口协议，相比于采用私有定义的tcp或udp二进制传输控制协议，具有弹性高，扩展性好，调试方便等优点，也可快速方便的适配b/s架构的升级体系。升级过程中使用的所有交互命令统一采用rest风格url编码，协议封装统一采用标准的http get/post请求，协议回复报文均采用标准的http协议状态码，回复协议载荷部分均采用统一的json文档定义格式。
74.在车载设备软件获取所述车载设备软件的升级包的过程中，车载设备可以向车载设备软件存储端以tftp请求报文的形式发送升级包下载请求(升级请求报文携带有车载设备软件存储端的ip地址和升级包的存储路径)，所述升级包下载请求包括所述存储端的ip地址和所述升级包的存储路径，之后开始从车载设备软件存储端下载自己相对应的升级包。这个传输过程严格遵循tftp传输协议。软件升级包的以太网传输协议采用tftp协议，相比于传统的ftp文件传输协议，它具有简单轻量的优点，并且占用系统资源极小，也能很好适用于那些软硬件资源较为紧缺的车载设备。为了实现tftp客户端传输协议将车载设备软件的升级包从车载设备软件存储服务器下载至本地，车载设备软件存储服务器需部署实现tftp服务器守护进程。
75.在所述车载设备软件的升级包传输下载过程中，如图2所示，ptu可以周期性的向车载设备发送升级进度查询请求，具体可以以升级进度查询报文的形式，从而进行车载设备软件升级状态的查询，车载设备收到后可以向用户端(ptu)发送所述升级包的下载进度回复，具体可以以报文的形式，可以包括升级包传输状态，升级进度百分比，以及错误码等信息。现场用户可清晰的观察到设备的升级进度。如果传输期间遭遇网络故障或者交换机故障导致传输中断，可通过错误码信息反馈给ptu。所有车载设备需实现相应的restapi服务守护进程，响应和回复ptu发送的所有restapi命令报文。
76.在车载设备获取所述车载设备软件的升级包的步骤中，可以包括以下步骤：
77.获取所述车载设备软件的升级文件以得到升级包，所述升级包为单一压缩包文件，所述升级包的打包方式如下：将所述升级文件和安装脚本进行打包，得到的内层压缩包；将所述内层压缩包和配置说明文件进行打包，得到外层压缩包作为所述升级包，其中，所述配置说明文件包括所述内层压缩包的验证信息。
78.上述验证信息中可以包括软件包的公钥和签名信息，配置说明文件还可以包括目标机软件包名，软件包大小，期望版本信息，软件包的签名摘要等信息。内层压缩包可以为车载设备实际运行需要的软件资源清单和安装脚本，软件资源清单通常可以包含若干可执行程序，动态链接库，配置文件，网页资源等，安装脚本用于负责完成将目标机软件资源从临时路径拷贝至各种软件资源在目标机系统的实际运行路径。
79.将所述升级包存储至存储端。
80.s103：响应于接收到的所述升级包，对所述升级包进行验证。
81.目前大多数车载设备的对外发布的软件升级包缺乏严谨的签名校验机制，某些车载设备甚至完全没有。例如，目前绝大多数车载设备的对外发布软件包仅采用软件包的md5校验方法，即车载设备厂商发布软件包的同时，在单独提供该软件包的md5校验值,软件升级操作发起时将升级包和md5校验值同时发送至待升级的目标机系统，由目标机系统接收
完毕后，将收到的软件升级包重新进行md5值计算，将计算结果和客户端发送的md5值进行比较，如果相等则认为是合法的软件升级包，否则认为是非法软件升级包，提示客户端拒绝升级。但是md5的伪造成本很低，非法用户很容易篡改软件包然后重新进行md5计算封装，此时目标机则无法识别到该软件包被篡改过，仍然会认为该升级包是一个合法升级包进行升级安装，这样会对车载设备的业务功能产生不可预知的不良影响。
82.图4为本发明实施例中车载设备软件的发布流程和签名校验流程示意图，如图4所示，在响应于接收到的所述升级包，对所述升级包进行验证时，包括：
83.采用所述公钥对所述签名信息进行解密，得到第一摘要信息。
84.在上述步骤中，如图4所示，所述公钥由所述车载设备软件厂商的私钥生成。车载设备的软件厂商可以使用例如secp256k1算法生成私钥，该过程在整个产品开发生命周期中只生成1次，并且该私钥仅在开发环境使用，不可对外泄露和发布。使用该私钥生成相对应对应的公钥，公钥文件无需加密和保护，可持久化存储在车载设备目标机上或者车载设备软件的软件升级包一同发送至车载设备中的目标机，用于升级包的合法性验证。在车载设备的软件厂商侧，可以将车载设备软件的升级包使用预设加密算法生成摘要信息，例如可选用hash加密算法，具体如sha-256加密算法，再使用私钥对摘要信息进行数字签名，得到签名信息。使用私钥对摘要信息进行数字签名时，可以采用所述私钥对所述摘要信息进行椭圆曲线数字签名。该签名信息也需随同升级包和公钥一同发送至车载设备。
85.本技术采用提出采用目前在信息安全领域广泛应用的ecdsa(椭圆曲线数字签名)非对称加密算法进行车载设备软件包的签名和校验机制，目前非对称加密算法种类较多，常见的主要包括rsa,dsa,ecdsa。之所以选用ecdsa基于以下几点原因：传统的dsa签名算法在随机数生成技术方面存在重大缺陷；ecdsa是当下最新、最安全的数字签名算法。在不知道私钥的情况下伪造ecdsa签名根本是不可能实现的。ecdsa已广泛应用于加密货币(比如比特币)和安全消息传递等各种应用中，也已经过大量的安全实践验证。目前已用大量的开源软件库实现了ecdsa签名算法，可方便的实现车载系统的快速移植。ecdsa的实现相比于rsa和rsa达到同样的安全性能仅需更少的软硬件资源，特别适合在车载嵌入式系统上应用。
86.在车载设备接收到车载设备软件的升级包后，车载设备一侧采用公钥对所述签名信息进行解密，得到第一摘要信息。
87.采用预设加密算法对所述内层压缩包进行摘要运算，得到第二摘要信息。
88.在该步骤中，在车载设备接收到车载设备软件的升级包后，采用预设加密算法对所述内层压缩包进行摘要运算，例如可选用hash加密算法，具体如sha-256加密算法，从而得到第二摘要信息。
89.将所述第一摘要信息与所述第二摘要信息进行比较，若二者相同，则验证通过；否则则认为签名校验失败。
90.在该步骤中，升级包传输完成后，可以通过之前的步骤签名信息验证环节，反馈ptu的状态为签名验证过程，并且签名信息验证完毕后，响应于所述用户端发送的升级进度查询请求，可以向所述用户端发送所述升级包的验证结果，以反馈ptu签名验证是否通过，用户端则获取获取所述升级包的验证结果，以使用户知晓升级包的验证结果。签名验证通过后方可进行升级包的安装环节，如解压内层压缩包，运行update文件进行安装等。如果反
馈ptu签名验证未通过，ptu会提示用户签名信息验证失败，结束本次升级过程。
91.s104：响应于所述升级包验证通过，对所述升级包进行安装。
92.在签名验证通过后方进行升级包的安装环节中，若升级包安装失败，也可以反馈ptu，安装失败的信息，以等待ptu是否重新加载的命令。在升级包的安装过程中，响应于所述用户端发送的升级进度查询请求，可以向所述用户端发送所述升级包的安装进度回复。用户端则获取所述升级包的安装进度回复，以使用户知晓升级包的安装进度。
93.由于目前绝大多数车载设备的目标机文件系统或者固件存储flash上并未提供双应用或者双系统镜像的存储机制。对应仅需升级应用程序的车载设备，在安装过程中由于意外掉电或者其它某些异常原因有可能导致部分应用资源被安装替换，部分资源没有被安装替换，从而导致车载设备的车载设备软件进入一个即非升级前的状态，也非升级后的状态。对于车载交换机等需要升级内核系统的车载设备，如果在擦写flash的过程中意外失电，则会导致车载设备永远无法正常启动。
94.为了解决上述问题，在对所述升级包进行安装的过程中，图5为本发明实施例中车载设备软件双存储分区安装示意图，如图5所示，将所述升级包存储至与所述车载设备软件加载运行的第一存储分区不同的第二存储分区。响应于所述升级包存储至所述第二存储分区并且升级安装成功，将所述车载设备软件加载运行的分区更改为所述第二存储分区。响应于所述升级包存储至所述第二存储分区失败或者升级安装失败，仍将所述第一存储分区作为所述车载设备软件加载运行的分区。
95.具体而言，车载设备的目标机文件系统能够提供第一存储分区和第二存储分区的双分区存储升级包，第一存储分区可以为a平面，第二存储分区可以为b平面，并用全局变量保存当前运行的车载设备软件是从a平面加载运行还是从b平面加载运行。如果车载设备软件当前是从a平面加载运行，则updater文件可以将升级包中软件资源安装释放至b平面，反之释放至a平面。安装释放升级成功后再更改a/b平面全局变量。之后，在车载设备软件启动运行时先判断a/b平面全局变量，决定从哪个平面加载车载设备软件运行。通过上述方式，在安装升级包过程中，如果遭遇意外失电或其它异常原因，导致安装失败，且该平面上的车载设备软件无法正常运行，由于a/b平面标记更改完成，可以继续以未安装升级包的平面运行车载设备软件，这样可以确保系统重新上电后仍然能恢复成升级操作前的版本状态，实现车载设备的正常运行。
96.作为可行的，在a平面或者b平面中的其中一个安装升级包成功以后，车载设备软件启动运行以升级后的该面的车载设备软件启动，之后如果运行顺利，另一平面可以将升级包复制至自身平面以进行安装升级。
97.在本技术中还提出了一种车载设备软件的批量升级方法，可以包括：
98.用户端发送车载设备发现请求，其中，所述车载设备发现请求是获取目标车辆的所有车载设备的设备信息的请求，所述设备信息包括所述车载设备的ip地址和车载设备软件信息。
99.所述车载设备响应于用户端发送的车载设备发现请求，向所述用户端发送所述目标车辆的所有车载设备的设备信息，其中，所述设备信息包括所述车载设备的硬件信息和车载设备软件的信息。
100.所述用户端获取所述目标车辆的所有车载设备的设备信息，根据所述设备信息，
确定需要升级的车载设备软件。
101.所述用户端发送批量升级请求，其中，所述升级请求是对目标车辆的多个车载设备软件进行升级的请求，多个所述车载设备软件配置有相同的升级协议。
102.所述车载设备响应于接收到的所述批量升级请求，获取所述车载设备软件的升级包。
103.所述车载设备响应于接收到的所述升级包，对所述升级包进行验证。
104.所述车载设备响应于所述升级包验证通过，对所述升级包进行安装。
105.在本技术中还提出了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如上述方法的步骤。
106.在本技术中还提出了一种车载设备软件的批量升级装置，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述方法的步骤。
107.在本技术中还提出了一种车载设备软件的批量升级装置，所述车载设备软件的批量升级装置中配置有与目标车辆的其它车载设备软件相同的升级协议，图7为本发明实施例中车载设备软件的批量升级装置的结构示意图，如图7所示，所述车载设备软件的批量升级装置包括：
108.升级包获取模块100，用于响应于接收到的批量升级请求，获取所述车载设备软件的升级包。升级包获取模块具体可以用于获取所述车载设备软件的升级文件以得到升级包，所述升级包为单一压缩包文件，所述升级包的打包方式如下：将所述升级文件和安装脚本进行打包，得到的内层压缩包；将所述内层压缩包和配置说明文件进行打包，得到外层压缩包作为所述升级包，其中，所述配置说明文件包括所述内层压缩包的验证信息；将所述升级包存储至存储端。升级包获取模块还可以用于向所述存储端发送升级包下载请求，所述升级包下载请求包括所述存储端的ip地址和所述升级包的存储路径；从所述存储端下载所述升级包。
109.验证模块200，用于响应于接收到的所述升级包，对所述升级包进行验证。所述配置说明文件包括公钥和签名信息。验证模块具体用于采用所述公钥对所述签名信息进行解密，得到第一摘要信息；采用预设加密算法对所述内层压缩包进行摘要运算，得到第二摘要信息；将所述第一摘要信息与所述第二摘要信息进行比较，若二者相同，则验证通过。
110.安装模块300，用于响应于所述升级包验证通过，对所述升级包进行安装。作为可行的，安装模块用于将所述升级包存储至与所述车载设备软件加载运行的第一存储分区不同的第二存储分区；响应于所述升级包存储至所述第二存储分区并且升级安装成功，将所述车载设备软件加载运行的分区更改为所述第二存储分区；响应于所述升级包存储至所述第二存储分区失败或者升级安装失败，仍将所述第一存储分区作为所述车载设备软件加载运行的分区。
111.本技术中的车载设备软件的批量升级方法及装置可以具有以下有点：
112.第一、本技术统一了所有车载设备软件的升级协议，能够简单高效的实现全车软件一键升级的操作，极大的提高现场维护人员的操作体验并且节省工作时间。
113.第二、本技术实现了单编车组车载设备和重联车组车载设备的自动发现机制，无需现场维护人员记忆所有设备的ip地址，极大的提高了现场维护人员的操作效率。
114.第三、采用数字签名机制对车载设备软件的升级包进行验证，以确保所有待升级车载设备软件不被非法篡改。
115.第四、采用第一存储分区/第一存储分区的双分区机制进行目标机软件包的存储和加载，确保因异常导致升级失败车载设备软件能完整回退至升级前的状态。
116.本技术中的车载设备软件的批量升级方法及装置针对现行动车组车载软件升级架构进行了优化设计，在保证安全可靠的前提下，可以简单高效的完成车载设备软件的升级工作。本技术相比于传统方法可以极大的降低现场操作人员的学习成本，减小操作复杂度，从而避免传统升级方式因为繁琐的操作流程带来的操作失误导致升级失败的风险。
117.本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
118.上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。
119.为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本技术时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
120.通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本技术可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。该计算机软件产品可以包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例或者实施例的某些部分所述的方法。该计算机软件产品可以存储在内存中，内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括短暂电脑可读媒体(transitory media)，如调制的数据信号和载波。
121.本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
122.本技术可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络pc、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。
123.本技术可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本技术，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
124.虽然通过实施例描绘了本技术，本领域普通技术人员知道，本技术有许多变形和变化而不脱离本技术的精神，希望所附的权利要求包括这些变形和变化而不脱离本技术的精神。