CN112953775B - 一种车机升级系统及方法 - Google Patents

一种车机升级系统及方法 Download PDF

Info

Publication number
CN112953775B
CN112953775B CN202110214348.0A CN202110214348A CN112953775B CN 112953775 B CN112953775 B CN 112953775B CN 202110214348 A CN202110214348 A CN 202110214348A CN 112953775 B CN112953775 B CN 112953775B
Authority
CN
China
Prior art keywords
mpu
mcu
upgrading
mode
protocol
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.)
Active
Application number
CN202110214348.0A
Other languages
English (en)
Other versions
CN112953775A (zh
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.)
Ecarx Hubei Tech Co Ltd
Original Assignee
Ecarx Hubei Tech Co 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 Ecarx Hubei Tech Co Ltd filed Critical Ecarx Hubei Tech Co Ltd
Priority to CN202110214348.0A priority Critical patent/CN112953775B/zh
Publication of CN112953775A publication Critical patent/CN112953775A/zh
Application granted granted Critical
Publication of CN112953775B publication Critical patent/CN112953775B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/656—Updates while running
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/26—Special purpose or proprietary protocols or architectures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40208—Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215—Controller Area Network CAN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40208—Bus networks characterized by the use of a particular bus standard
    • H04L2012/40241—Flexray

Abstract

本发明实施例提供了一种车机升级系统及方法，涉及车联网技术领域，可以提高IHU的升级效率。在本发明实施例中，车机升级系统系统包括网关和安装在车辆中的信息娱乐主机IHU；IHU包括微处理器MPU和微控制单元MCU；MCU与MPU之间基于网际协议控制协议IPCP通信连接；MCU与网关之间基于FlexRay、控制器局域网络CAN或者基于网络诊断通信Doip协议通信连接；MPU与网关之间基于Doip协议通信连接。车机升级系统还包括诊断仪，诊断仪与网关之间基于Doip协议通信连接；或，车机升级系统还包括云服务器，云服务器与MPU之间基于移动通信协议通信连接。

Description

一种车机升级系统及方法
技术领域
本发明涉及车联网技术领域，特别是涉及一种车机升级系统及方法。
背景技术
随着智能座舱技术的发展，越来越多应用集成在信息娱乐主机(InfotainmentHead Unit，IHU)中，能够为用户提供多媒体数据播放、辅助驾驶、车辆定位和车身控制等功能。IHU中包括微控制单元(Microcontroller Unit，MCU)和微处理器(MicroprocessorUnit，MPU)。对IHU的升级包括对MCU和/或MPU升级，对IHU的升级也可以称为车机升级。
在诊断升级方案中，升级MPU时，诊断仪与MPU之间的通信需要经过MCU转发，诊断仪与MCU利用控制器局域网络(Controller Area Network，CAN)协议通信，而CAN协议传输带宽小，且MCU处理速度慢，导致MPU的升级效率低，进而使得IHU的升级效率低。
发明内容
本发明实施例的目的在于提供一种车机升级系统及方法，以实现提高IHU的升级效率。具体技术方案如下：
第一方面，本发明实施例提供了一种车机升级系统，所述系统包括网关和安装在车辆中的信息娱乐主机IHU；所述IHU包括微处理器MPU和微控制单元MCU；
所述MCU与所述MPU之间基于网际协议控制协议IPCP通信连接；
所述MCU与所述网关之间基于FlexRay、控制器局域网络CAN或者基于网络诊断通信Doip协议通信连接；
所述MPU与所述网关之间基于Doip协议通信连接；
所述系统还包括诊断仪，所述诊断仪与所述网关之间基于Doip协议通信连接；
或，所述系统还包括云服务器，所述云服务器与所述MPU之间基于移动通信协议通信连接。
第二方面，本发明实施例提供了一种车机升级方法，基于第一方面所述的车机升级系统，应用于所述车机升级系统中的诊断仪，所述方法包括：
基于网络诊断通信Doip协议经过所述网关向所述MCU发送切换指令，所述切换指令用于指示所述MCU将所述MPU的系统模式切换为Recovery模式，所述Recovery模式支持Doip协议；
在确定所述MPU将自身的系统模式切换为所述Recovery模式成功时，基于Doip协议经过网关向所述MPU发送状态查询请求；
基于Doip协议经过网关接收所述MPU发送的状态响应信息，所述状态响应信息包括所述MPU的运行状态；
基于所述MPU的运行状态，确定所述MPU是否满足预设升级条件；
在确定所述MPU满足所述预设升级条件时，基于Doip协议经过网关向所述MPU发送MPU升级包，以使得所述MPU利用所述MPU升级包进行升级。
可选的，所述车辆中还包括电子控制单元ECU节点；所述方法还包括：
向所述MCU和所述ECU节点分别发送状态查询请求；
分别接收所述MCU和所述ECU节点发送的携带运行状态的状态响应信息；
所述基于所述MPU的运行状态，确定所述MPU是否满足预设升级条件，包括：
基于所述MPU、所述MCU和所述ECU节点的运行状态，确定所述MPU是否满足所述预设升级条件。
可选的，所述方法还包括：
若确定所述MPU满足所述预设升级条件，且自身存储有所述MPU升级包，则基于Doip协议经过网关向所述MPU发送第二模式切换请求，所述第二模式切换请求用于请求将所述MPU从默认会话模式切换为编程模式，所述MPU在编程模式下允许外部设备向所述MPU写入数据；
在确定所述MPU从默认会话模式切换为所述编程模式时，执行所述基于Doip协议经过网关向所述MPU发送MPU升级包的步骤。
可选的，所述方法还包括：
若确定所述MPU满足所述预设升级条件，且自身存储有MCU升级包，则经过网关向所述MCU发送第三模式切换请求，所述第三模式切换请求用于请求将所述MCU从默认会话模式切换为编程模式，所述MCU在编程模式下允许外部设备向所述MCU写入数据；
在确定所述MCU从默认会话模式切换为所述编程模式时，经过网关向所述MCU发送所述MCU升级包，以使得所述MCU利用所述MCU升级包进行升级。
可选的，所述方法还包括：
若接收到所述MCU发送的延时等待请求，则等待预设等待时长；所述延时等待请求用于请求所述诊断仪等待预设等待时长；
若在延时等待时长未达到所述预设等待时长之前，接收到所述MCU发送的切换成功响应，则执行基于Doip协议经过网关向所述MPU发送状态查询请求的步骤；所述切换成功响应用于表示所述MPU将自身的系统模式切换为所述Recovery模式成功；
若在延时等待时长达到所述预设等待时长时，未接收到所述MCU发送的切换成功响应，则确定所述MPU将自身的系统模式切换为所述Recovery模式失败，停止升级；
若接收到所述MCU发送的切换失败响应，则确定所述MPU将自身的系统模式切换为所述Recovery模式失败，停止升级，所述切换失败响应用于表示所述MPU将自身的系统模式切换为所述Recovery模式失败。
可选的，所述方法还包括：
若在基于Doip协议发送状态查询请求后的超时判定时长内，未接收到所述MPU基于Doip协议发送的状态响应信息，则在达到所述超时判定时长的时刻开始计时；
若在计时时长未达到预设超时偏差时长之前，接收到所述MPU基于Doip协议发送的状态响应信息，则执行所述基于所述MPU的运行状态，确定所述MPU是否满足预设升级条件的步骤；
若在计时时长达到所述预设超时偏差时长时，未接收到所述MPU基于Doip协议发送的状态响应信息，则停止升级。
第三方面，本发明实施例提供了一种车机升级方法，基于第一方面所述的车机升级系统，应用于所述车机升级系统中的网关，所述方法包括：
基于网络诊断通信Doip协议接收所述MPU发送的检测请求，所述检测请求用于请求检测所述MPU是否满足预设升级条件；所述检测请求为MPU从所述云服务器获取MPU升级包、且将自身的系统模式切换为Recovery模式时，向所述网关发送的请求，所述Recovery模式支持Doip协议；
基于Doip协议向所述MPU发送状态查询请求；
基于Doip协议接收所述MPU发送的状态响应信息，所述状态响应信息包括所述MPU的运行状态；
基于所述MPU的运行状态，确定所述MPU是否满足所述预设升级条件；
基于Doip协议向所述MPU发送检测响应，所述检测响应用于表示所述MPU是否满足所述预设升级条件，以使得MPU在所述MPU满足所述预设升级条件时，利用所述MPU升级包进行升级。
可选的，所述IHU还包括微控制单元MCU，所述车辆中还包括电子控制单元ECU节点；所述方法还包括：
向所述MCU和所述ECU节点分别发送状态查询请求；
分别接收所述MCU和所述ECU节点发送的携带运行状态的状态响应信息；
所述基于所述MPU的运行状态，确定所述MPU是否满足所述预设升级条件，包括：
基于所述MPU、所述MCU和所述ECU节点的运行状态，确定所述MPU是否满足所述预设升级条件。
可选的，所述IHU还包括微控制单元MCU；在所述基于Doip协议向所述MPU发送检测响应之后，所述方法还包括：
基于Doip协议接收所述MPU发送的MCU升级包；
向所述MCU发送第三模式切换请求，所述第三模式切换请求用于请求将所述MCU从默认会话模式切换为编程模式，所述MCU在编程模式下允许外部设备向所述MCU写入数据；
在确定所述MCU从默认会话模式切换为所述编程模式时，向所述MCU发送所述MCU升级包，以使得所述MCU利用所述MCU升级包进行升级。
可选的，所述方法还包括：
若在基于Doip协议向所述MPU发送状态查询请求后的超时判定时长内，未接收到所述MPU基于Doip协议发送的状态响应信息，则在达到所述超时判定时长的时刻开始计时；
若在计时时长未达到预设超时偏差时长之前，接收到所述MPU基于Doip协议发送的状态响应信息，则执行所述基于所述MPU的运行状态，确定所述MPU是否满足所述预设升级条件的步骤；
若在计时时长达到所述预设超时偏差时长时，未接收到所述MPU基于Doip协议发送的状态响应信息，则停止升级。
第四方面，本发明实施例提供了一种电子设备，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；
存储器，用于存放计算机程序；
处理器，用于执行存储器上所存放的程序时，实现上述任一车机升级方法的步骤。
第五方面，本发明实施例提供了一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现上述任一车机升级方法的步骤。
第六方面，本发明实施例提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述任一车机升级方法的步骤。
本发明实施例提供的车机升级系统及方法中，MPU可以基于Doip协议与网关通信，并进行升级。由于MPU可以基于Doip协议与网关直接通信，通信时不用经过MCU，而且Doip协议是以太网通信协议，传输带宽大，因此提高了MPU的升级效率，进而提高了IHU的升级效率。
当然，实施本发明的任一产品或方法并不一定需要同时达到以上所述的所有优点。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的实施例。
图1a为本发明实施例提供的一种车机升级系统结构示意图；
图1b为本发明实施例提供的另一种车机升级系统结构示意图；
图2为本发明实施例提供的一种车机升级方法流程图；
图3为本发明实施例提供的另一种车机升级系统结构示意图；
图4为本发明实施例提供的一种握手过程的信令图；
图5为本发明实施例提供的另一种车机升级方法流程图；
图6为本发明实施例提供的另一种车机升级系统结构示意图；
图7为本发明实施例提供的一种车机升级过程的信令图；
图8为本发明实施例提供的另一种车机升级过程的信令图；
图9为本发明实施例提供的一种电子设备的结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
首先对本发明实施例涉及的模块进行说明。
信息娱乐主机(Infotainment Head Unit，IHU)安装在车辆中，IHU中包括：微处理器(MicroProcessor Unit，MPU)和微控制单元(Microcontroller Unit，MCU)。其中，MPU采用操作系统(Linux)内核，MPU基于Linux内核运行安卓操作系统(Android OS)，Android OS是一种分时操作系统，在标准系统模式下不满足支持基于网络诊断通信协议(Diagnosticcommunication over Internet Protocol，Doip)实时响应的要求。MCU采用晶振时钟，通常响应外部信号的时长为1～2毫秒，支持汽车开放系统架构操作系统(Automotive OpenSystem Architecture Operation System，Autosar OS)，满足Doip协议实时响应的要求。MCU可用于处理整车端发送过来的信号。
为了IHU的升级效率，本发明实施例提供了一种车机升级系统，如图1a或者图1b所示，该系统包括：安装在车辆中的IHU 11和网关12。其中，IHU 11包括MPU 111和MCU 112。
MCU 112与MPU 111之间基于网际协议控制协议(Internet Protocol ControlProtocol，IPCP)通信连接。
MCU 112与网关12之间基于FlexRay、控制器局域网络(Controller AreaNetwork，CAN)或者Doip协议通信连接，其中，FlexRay是一种汽车内部网络通讯协议。
MPU 111与网关12之间基于Doip协议通信连接。
如图1a所示，车机升级系统还可以包括诊断仪13。诊断仪13与网关12之间基于Doip协议通信连接。
或者，如图1b所示，车机升级系统还可以包括：云服务器14。其中，云服务器14与MPU 111之间基于移动通信协议通信连接。本发明实施例中的移动通信协议可以为第四代移动通信技术(the 4th generation mobile communication technolog，4G)，或者第五代移动通信技术(5th-Generation，5G)，或者还可以为移动设备可支持的其他通信协议。
在本发明实施例中，由于MPU与网关之间可以基于Doip协议通信连接，解决了相关技术中由于MPU不满足实时响应的要求而不能与外界通信的问题，使得MPU可直接与外界通信而不需要MCU的转发，而且Doip协议是以太网通信协议，传输带宽大，因此提高了MPU的升级效率，进而提高了IHU的升级效率。
本发明实施例可以应用在诊断仪升级场景，此时本发明实施例提供的车机升级方法基于图1a所示的车机升级系统，车机升级方法可以应用于图1a所示的车机升级系统中的诊断仪，如图2所示，该方法包括如下步骤。
步骤201，基于Doip协议，诊断仪经过网关向MCU发送切换指令。
其中，切换指令用于指示MCU将MPU的系统模式切换为Recovery模式，Recovery模式支持Doip协议。
在诊断仪升级场景下，网关用于转发诊断仪与MPU，或者转发诊断仪与MCU之间传输的消息。一种实施方式中，诊断仪可以基于Doip协议向网关发送切换指令，网关接收到切换指令后，基于FlexRay、CAN或者Doip协议向MCU转发切换指令。
在本发明实施例中，可以在安卓系统的Recovery分区中植入Doip协议栈，其中，植入的协议栈是指根据DOIP协议制定的实现DOIP诊断通信和响应外部各种服务指令，使得MPU在Recovery模式下可以响应各种doip服务指令，满足Doip协议实时响应的要求。
步骤202，诊断仪在确定MPU将自身的系统模式切换为Recovery模式成功时，基于Doip协议，诊断仪经过网关向MPU发送状态查询请求。
步骤203，基于Doip协议，诊断仪经过网关接收MPU发送的状态响应信息。其中，状态响应信息包括MPU的运行状态。例如，MPU的运行状态可以为正常状态或者异常状态。
步骤204，诊断仪基于MPU的运行状态，确定MPU是否满足预设升级条件。
一种实施方式中，可以判断MPU的运行状态是否为正常状态。若是，则确定MPU满足预设升级条件；若否，则确定MPU不满足预设升级条件。
步骤205，在确定MPU满足预设升级条件时，基于Doip协议，诊断仪经过网关向MPU发送MPU升级包，以使得MPU利用MPU升级包进行升级。
本发明实施例提供的车机升级方法中，MPU可以在切换为Recovery模式后，基于Doip协议经过网关与诊断仪通信，并进行升级。由于MPU可以基于Doip协议与诊断仪通信，通信时不用经过MCU，而且Doip协议是以太网通信协议，传输带宽大，因此提高了MPU的升级效率，进而提高了IHU的升级效率。
在本发明实施例中，在上述步骤201诊断仪经过网关向MCU发送切换指令之后，MCU可以基于IPCP协议向MPU发送第一模式切换请求。
如图3所示，在本发明实施例中，IHU 11中还可以包括以太网交换机113。MPU与诊断仪之间的通信可以经过以太网交换机以及网关。以太网交换机和网关在转发MPU与诊断仪之间传输的数据包时基于Doip协议。MCU与诊断仪之间的通信可以经过以太网交换机和网关，通过以太网交换机连接网关，使得车机只需一个对外的以太网接口，其他的通讯信号都可以通过网关中转，减少了硬件接口设计的复杂程度。
由于MPU在常规状态下运行安卓标准模式，不能实时响应外部指令，而与诊断仪通信需要满足实时通信要求，因此MPU在安卓标准模式下不能与诊断仪通信。但MPU可以与MCU通过IPCP协议通信。因此诊断仪可以先通过网关和以太网交换机，向MCU发送切换指令，使得MCU通知MPU将自身的系统模式切换为Recovery模式，使MPU在Recovery模式下满足实时响应要求。
可选的，诊断仪发送的切换指令为统一诊断服务(Unified DiagnosticServices，UDS)中0X31 01例程1，其中，0X31 01表示例程控制服务，例程1表示MCU请求将MPU的系统模式切换为Recovery模式，即指示MCU调用例程1，以将MPU的系统模式切换为Recovery模式。
一种实施方式中，MCU可以在接收到切换指令后，基于IPCP协议调用框架层(Framework，FWK)的Doip_Recovery接口，向MPU发送第一模式切换请求。
在本发明实施例中，MCU和FWK之间预先定义接口参数Doip_Recovery，其中，Doip_Recovery＝0表示默认模式，Doip_Recovery＝1表示Recovery模式。MCU基于IPCP协议向MPU发送Doip_Recovery＝1。MPU在接收到Doip_Recovery＝1后，将自身的系统模式切换至Recovery模式并重启。若MPU切换Recovery模式并重启成功，则向MCU发送一响应信号Doip_Recovery_Response＝1，表示切换成功；若MPU切换Recovery模式并重启失败，则向MCU发送响应信号Doip_Recovery_Response＝0，表示切换失败。
MPU在常规模式下不能与诊断仪通信，诊断仪利用MCU请求MPU切换系统模式至Recovery模式后，在Recovery模式下MPU可以与诊断仪基于Doip协议通信。
通常MPU将安卓标准模式切换为Recovery模式需耗时18秒(second，s)，而与诊断仪通信所基于的Doip协议通讯时超时判定时长为50毫秒(millisecond，ms)，从诊断仪向MCU发送切换指令，到MCU在检测到MPU切换成功后再向诊断仪发送响应消息所经历的时长超过超时判定时长，因此需要请求诊断仪延时等待MPU切换模式，避免认定通讯超时。诊断仪延时等待方式包括如下步骤。
步骤一，若诊断仪接收到MCU发送的延时等待请求，则等待预设等待时长。其中，延时等待请求用于请求诊断仪等待预设等待时长。
在本发明实施例中，MCU若在发送第一模式切换请求后的第一指定时长内，未接收到MPU发送的切换成功消息，则每隔预设时间间隔向诊断仪发送延时等待请求，直至接收到MPU发送的切换成功消息时，向诊断仪发送切换成功响应，切换成功响应用于表示MPU将自身的系统模式切换为Recovery模式成功，预设时间间隔小于预设等待时长。示例性的，延时等待请求为UDS服务中0X78 78指令，表示请求延时等待5s。
在本发明实施例中，第一指定时长小于诊断仪的超时判定时长。示例性的，第一指定时长为10ms，超时判断时长为50ms，预设等待时长为5s，预设时间间隔为2s。例如，MCU在发送第一模式切换请求后的10ms内，未接收到切换成功消息，则向诊断仪发送延时等待请求，以请求诊断仪延时等待5s，并每间隔2s向诊断仪发送一次延时等待请求，直至接收到MPU发送的切换成功消息。
可选的，MCU可以通过UDS服务中0X31 03指令向MPU询问模式切换结果。0X31 03指令用于询问当前系统模式。
MCU若在发送第一模式切换请求后的第二指定时长内，未接收到MPU发送的切换成功消息，则向诊断仪发送切换失败响应。其中，切换失败响应用于表示MPU 111将自身的系统模式切换为Recovery模式失败，第二指定时长大于第一指定时长。第二指定时长大于MPU将自身的系统模式切换为Recovery模式并重启所消耗的时长。示例性的，第二指定时长为25s。MPU将自身的系统模式切换为Recovery模式失败的原因可以是MPU 111出现故障，不符合升级要求。
步骤二，若诊断仪在延时等待时长未达到预设等待时长之前，接收到MCU发送的切换成功响应，则执行上述步骤202。其中，切换成功响应用于表示MPU将自身的系统模式切换为Recovery模式成功。
步骤三，若诊断仪在延时等待时长达到预设等待时长时，未接收到MCU发送的切换成功响应，则确定MPU将自身的系统模式切换为Recovery模式失败，停止升级。
步骤四，若诊断仪接收到MCU发送的切换失败响应，则确定MPU将自身的系统模式切换为Recovery模式失败，停止升级。其中，切换失败响应用于表示MPU将自身的系统模式切换为Recovery模式失败。
在本发明实施例中，FWK可以根据MCU传递给MPU的接口参数Doip_Recovery，创建优先级最高的线程，以优先分配系统资源处理Doip诊断服务，即优先分配系统资源给MPU切换为Recovery模式。当MPU接收到诊断仪发送的指令而产生输入/输出(input/output，I/O)中断时，MPU的Linux系统可以从用户态切换至内核态，以优先响应诊断仪发送的指令。
本发明实施例设置的延时等待机制，可以使得诊断仪延时等待MPU切换Recovery模式，避免由于MPU切换Recovery模式消耗时长大于诊断仪超时判定时长而导致的MCU与诊断仪之间的通讯中断。
在本发明实施例中，诊断仪需要检测车辆是否满足预设升级条件。在MPU成功切换Recovery模式后，诊断仪需要检测MPU是否满足预设升级条件。如图3所示，该车辆中还包括电子控制单元(Electronic Control Unit，ECU)节点16。ECU节点与网关之间可以基于FlexRay、CAN或者Doip协议通信。在本发明实施例中，ECU节点的数量不限于图3所示的数量。在MPU成功切换Recovery模式后，诊断仪还需要检测ECU节点是否满足预设升级条件。
诊断仪在确定MPU将自身的系统模式切换为Recovery模式成功时，还可以向MCU和ECU节点分别发送状态查询请求，并分别接收MCU和ECU节点发送的携带运行状态的状态响应信息。
一种实施方式中，诊断仪可以基于Doip协议通过网关广播状态查询请求，分别接收MPU、MCU和ECU节点发送的携带运行状态的状态响应信息，并基于MPU、MCU和ECU节点的运行状态，确定MPU是否满足预设升级条件。在本发明实施例中，确定MPU是否满足升级条件即确定MPU所在车辆是否满足升级条件。
可选的，可以在诊断仪中预先记录为MPU、MCU和ECU节点的网际协议(InternetProtocol，IP)地址。诊断仪可以使用UDS服务中0X31 01服务调用例程2。其中，例程2用于确定车辆是否满足升级条件。确定MPU、MCU和ECU节点的IP地址，并基于查找到的IP地址，经过网关广播状态查询请求。MPU、MCU和ECU节点发送的状态响应信息中，分别携带自身的运行状态。
可选的，预设升级条件包括但不限于：蓄电池当前剩余电量超过预设电量阈值、车辆包括的节点在线、车速大小为0。其中，车辆包括的节点为MPU、MCU和ECU节点，若诊断仪未接收到车辆包括的某个节点的状态响应信息，则说明该节点不在线，反之则表示该节点在线，可以只对在线的节点进行升级，不在线的节点不能进行升级。
本发明实施例中的诊断仪能够检测车辆是否满足升级条件，减少升级失败的可能性。
在本发明实施例中，在诊断仪检测到MPU满足升级条件时，可以向MPU刷写MPU升级包。具体的，诊断仪若确定MPU满足预设升级条件，且自身存储有MPU升级包，则基于Doip协议经过网关向MPU发送第二模式切换请求。
在本发明实施例中，可以预先在诊断仪中部署升级包，升级包中包括：MPU升级包、MCU升级包和ECU升级包中的任意一种或多种。在此基础上，诊断仪在确定该MPU满足预设升级条件且自身存储有MPU升级包时，查找MPU的IP地址，并利用查找到的IP地址基于Doip协议经过网关向MPU发送第二模式切换请求。
其中，第二模式切换请求用于请求将MPU从默认会话模式切换为编程模式，MPU在编程模式下允许外部设备向MPU写入数据。示例性的，第二模式切换请求可以为统一诊断服务(Unified Diagnostic Services，UDS)的0X10 02指令，表示请求MPU进入编程模式。
示例性的，第二模式切换请求的报文数据如表一所示。
表一
Figure BDA0002952593290000131
在本发明实施例中，MPU在接收到第二模式切换请求时，将自身从默认会话模式切换为编程模式。
可选的，MPU在成功切换至编程模式后，向诊断仪发送切换响应，以通知诊断仪，MPU已切换至编程模式。诊断仪在接收到切换响应后，可以调用UDS服务中0X27服务，以与MPU进行握手验证，诊断仪与MPU的握手验证过程如图4所示。
步骤401，诊断仪基于Doip协议向MPU请求种子，其中，所述种子为两个字节(byte)的16进制数。
步骤402，MPU基于Doip协议向诊断仪发送种子。
步骤403，诊断仪基于MPU发送的种子，依据预设加密算法计算秘钥。
步骤404，诊断仪基于Doip协议向MPU发送秘钥。
步骤405，MPU基于Doip协议接收诊断仪发送的秘钥，并对比接收到的秘钥与正确秘钥是否相同。若相同，则通过握手验证；若不相同，则握手验证失败。
步骤406，在通过握手验证时，MPU基于Doip协议向诊断仪发送解锁消息，以通知诊断仪握手成功。
在本发明实施例中，如图3所示，诊断仪与MPU之间的通信均经过网关和以太网交换机。
由于诊断仪与MPU通过握手验证后，诊断仪才可向MPU写入升级包，以防未经许可的设备向MPU刷写数据而导致MPU损坏。
握手验证通过后，诊断仪可以使用UDS服务中0X34服务向MPU发送请求下载消息，以请求MPU下载升级包。MPU在接收到请求下载消息后，判断是否满足下载条件，并在满足下载条件时，向诊断仪发送针对请求下载消息的下载响应消息，以通知诊断仪当前满足下载条件。
其中，下载条件包括但不限于：升级包大小未超出存储块(Block)分区的存储范围、MPU处于编程模式、MPU当前不在发送数据。
诊断仪在接收到下载响应消息后，向MPU发送UDS服务中0X36指令，以询问MPU是否进行数据传输，在确定进行数据传输时，向MPU发送MPU升级包。在MPU升级包发送完成后，向MPU发送UDS服务中0X37指令，以向MPU请求退出数据传输服务，在确定退出数据传输服务后，终止数据传输。
诊断仪在终止数据传输后，向MPU发送UDS服务中0X31 01指令调用例程3，例程3用于升级并重启，以通知MPU调用例程3，以重启加载(BootLoader)MPU升级包，使得MPU调用升级包数据接口完成升级。
在本发明实施例中，若MPU重启后正常加载桌面内容，则MPU确定升级成功；若MPU重启后无法正常加载桌面内容，如黑屏，则MPU确定升级失败。
诊断仪在通知MPU重启加载MPU升级包后，可以向MCU发送UDS服务中0x31 03指令，以请求MCU询问MPU是否升级成功。并在确定MPU未升级成功时，返回执行向MCU发送切换指令的步骤，或者向指定账户发送提示信息，以提示登录指定账户的用户MPU升级失败。
在诊断仪中包括MCU升级包时，诊断仪可以指示MCU升级，包括如下步骤。
步骤1，若确定MPU满足预设升级条件，且自身存储有MCU升级包，则经过网关向MCU发送第三模式切换请求。其中，第三模式切换请求用于请求将MCU从默认会话模式切换为编程模式，MCU在编程模式下允许外部设备向MCU写入数据。
在本发明实施例中，MCU接收到第三模式切换请求时，将自身从默认会话模式切换为编程模式。
步骤2，在确定MCU从默认会话模式切换为编程模式时，经过网关向MCU发送MCU升级包，以使得MCU利用MCU升级包进行升级。
MCU的升级过程与MPU类似，同样需要经过握手验证、升级包传输、重启加载，具体描述可参见MPU升级方式，此处不再赘述。同样的，车辆包括的ECU节点的升级方式与MCU的升级方式相同。
MPU升级包大小一般远大于MCU升级包以及ECU升级包大小，例如，MPU升级包大小为2吉字节(Gigabyte，GB)，MCU升级包大小为10兆字节(Megabytes，MB)，ECU节点的升级包大小为600MB。而相关技术中MPU升级包需要由诊断仪先发送给MCU，再由MCU转发至MPU，由于MCU与诊断仪通信基于CAN，CAN传输带宽窄，且MCU处理速度慢，使得MPU升级包的传输时间长，升级效率低。
而在本发明实施例中，MPU可以基于Doip协议从诊断仪中获取MPU升级包，不需要MCU转发，MPU处理速度快，且Doip协议带宽宽，使得MPU升级包传输速度快，提高了MPU的升级效率。示例性的，以MPU升级包大小为2G，基于Doip协议的以太网带宽为100兆比特每秒(megabits per second，Mbps)，负载为50％为例，诊断仪向MPU传输MPU升级包的理论时长t＝2*1024*1024*1024*8/50*1000*1000≈5.8分钟。考虑到诊断仪与MPU通信时需要经过以太网交换机和网关的转发，MPU从诊断仪发送到MPU的预估耗时为10分钟，耗时较短，满足升级要求。
在本发明实施例中，还可以在诊断仪中设置会话实时保证机制，包括：若在基于Doip协议发送状态查询请求后的超时判定时长内，未接收到MPU基于Doip协议发送的状态响应信息，则在达到超时判定时长的时刻开始计时；若在计时时长未达到预设超时偏差时长之前，接收到MPU基于Doip协议发送的状态响应信息，则执行上述步骤204；若在计时时长达到预设超时偏差时长时，未接收到MPU基于Doip协议发送的状态响应信息，则停止升级。
其中，超时判定时长为诊断仪与外部设备通信所基于的Doip协议的超时判定时长。例如，超时判定时长为50ms。预设超时偏差时长可以为1000ms。
MPU与诊断仪之间的通信均可以按照上述会话实时保证机制，不限于在请求状态和响应状态时。例如，MPU与诊断仪在握手验证时也可以采用。
由于MPU在处理诊断仪请求时，需要耗费的时间较长，而且虽然处理诊断服务的线程优先级最高，然而设置最高优先级是为诊断服务分配更长的时间片，占用更多的系统资源，但无法保证系统资源的实时占用，使得MPU处理诊断仪请求的时长可能超过诊断仪的超时判定时长。本发明实施例设置超时偏差时长可以减少由于MPU处理诊断仪请求时间较长而导致的诊断仪与MPU的通信中断。
本发明实施例可以应用于无线技术(Over-the-AirTechnology，OTA)升级的场景中，此时本发明实施例提供的车机升级方法基于如图1b所示的车机升级系统，车机升级方法可以应用于车机升级系统中的网关，如图5所示，包括如下步骤。
步骤501，基于Doip协议，网关接收MPU发送的检测请求。
其中，检测请求用于请求检测MPU是否满足预设升级条件；检测请求为MPU从云服务器获取MPU升级包、且将自身的系统模式切换为Recovery模式时，向网关发送的请求；Recovery模式支持Doip协议。
步骤502，基于Doip协议，网关向MPU发送状态查询请求。
步骤503，基于Doip协议，网关接收MPU发送的状态响应信息。其中，状态响应信息包括MPU的运行状态。
步骤504，网关基于MPU的运行状态，确定MPU是否满足预设升级条件。
步骤505，基于Doip协议，网关向MPU发送检测响应。其中，检测响应用于表示MPU是否满足预设升级条件，以使得MPU在MPU满足预设升级条件时，利用MPU升级包进行升级。
在本发明实施例中，OTA升级场景中检测MPU是否满足升级条件的方式与诊断仪升级场景中检测MPU是否满足升级条件的方式相同，可参考上述相关描述，此处不再赘述。
由于网关与MPU可以基于Doip协议通信，通信时不需要经过MCU转发，而且Doip协议是以太网通信协议，传输带宽大，因此提高了MPU的升级效率，进而提高了IHU的升级效率。
在本发明实施例中，在上述步骤501之前，MPU从云服务器获取升级包的方式包括以下步骤：
步骤(一)，云服务器向MPU发送升级通知消息。其中，升级通知消息用于表示云服务器中存在升级包，升级通知消息还可以提示升级内容。
在本发明实施例中，云服务器为汽车远程服务提供商(Telematics ServiceProvider，TSP)云端的服务器。可以预先在云服务器中部署升级包，在云服务器中部署的升级包包括：MPU升级包、MCU升级包和ECU节点升级包中的任意一种或多种。
步骤(二)，MPU接收到升级通知消息后，将通知消息包括的内容展示在人机界面(Human Machine Interface，HMI)。例如，在HMI界面展示可下载的升级包信息。
可选的，HMI界面中还可以展示下载按钮和暂不下载按钮，以使得用户在HMI界面上点击下载按钮触发下载指令，或者点击暂不下载按钮触发暂不下载的指令。
步骤(三)，MPU响应于用户触发的下载指令，基于移动通信协议从云服务器下载升级包。
本发明实施例中的移动通信协议可以为4G协议或者5G协议。例如，MPU在接收到用户触发的下载指令时，通过内置的4G芯片，基于4G协议从云服务器下载升级包。
步骤(四)，MPU下载升级包后，在HMI中展示升级按钮，在检测到用户点击升级按钮后，调用OTA_Recovery接口，将自身的系统模式切换为Recovery模式。
相关技术中通过在车辆中安装远程通信箱(Telematics BOX，TBOX)，由TBOX基于通用串行总线(Universal Serial Bus，USB)从升级包存储设备中获取升级包，在车辆中额外安装TBOX增加了整车成本。而本发明实施例可以由MPU直接从云服务器中获取升级包，不需要在车辆中安装TBOX，因此降低了整车成本。
在OTA升级场景中，如图6所示，本发明实施例中的IHU 11还包括MCU 112，车辆中还包括ECU节点16。网关在接收到检测请求后，还可以向MCU和ECU节点分别发送状态查询请求，并分别接收MCU和ECU节点发送的携带运行状态的状态响应信息。
一种实施方式中，网关可以基于Doip协议广播状态查询请求，分别接收MPU、MCU和ECU节点发送的携带运行状态的状态响应信息。然后基于MPU、MCU和ECU节点的运行状态，确定MPU是否满足预设升级条件。在本发明实施例中，确定MPU是否满足升级状态即确定MPU所在车辆是否满足升级条件。
可选的，检测请求可以为UDS服务中0X31 01指令，使得网关在接收到检测请求后调用例程2，以广播状态查询请求。
可选的，本发明实施例中，还可以在网关中设置延时等待机制，包括：在接收到检测请求后的第一指定时长内，若未确定MPU是否满足升级条件，则每隔预设时间间隔向MPU发送延时等待请求，以请求MPU等待预设等待时长，直至确定MPU是否满足升级条件完成后，向MPU发送检测响应。检测响应可以为UDS服务中0X71 01指令，表示车辆是否满足升级条件的结果。
MPU根据检测响应确定MPU满足升级条件，且从云服务器获取到MPU升级包时，调用MPU升级包进行升级并重启。其中，MPU升级包的存储格式可以为img格式。
在本发明实施例中，如图6所示，IHU 11中还包括以太网交换机113。MPU与网关之间的通信可以经过以太网交换机。以太网交换机在转发MPU与网关之间传输的数据包时可以基于Doip协议。MCU与网关之间可以基于FlexRay、CAN或者Doip协议直接通信，或者也可以基于Doip协议经过以太网交换机通信。使得车机只需一个对外的以太网接口，其他的通讯信号都可以通过网关中转，减少了硬件接口设计的复杂程度。
本发明实施例中的MPU可以通过控制网关进行升级条件判断，而且MPU与网关之间的通信可以基于Doip协议，因此传输效率高。
在本发明实施例中，云服务器中可以部署MCU升级包，在MPU从云服务器中获取到MCU升级包时，本发明实施例中网关还可以控制MCU升级，包括如下步骤。
步骤(1)，网关基于Doip协议接收MPU发送的MCU升级包。
MPU在接收到网关发送的检测响应确定MPU满足升级条件，且从云服务器获取到MCU升级包时，可以基于Doip协议向网关发送MCU升级包。
步骤(2)，网关向MCU发送第三模式切换请求。其中，第三模式切换请求用于请求将MCU从默认会话模式切换为编程模式，MCU在编程模式下允许外部设备向MCU写入数据。以使得MCU接收到第三模式切换请求时，将自身从默认会话模式切换为编程模式。
步骤(3)，网关在确定MCU从默认会话模式切换为编程模式时，向MCU发送MCU升级包，以使得MCU利用MCU升级包进行升级。
网关向MCU发送MCU升级包时可以利用UDS服务中0X34、0X36和0X37指令。具体方式与诊断仪升级场景的方式类似，可以参考诊断仪升级方案中诊断仪向MPU发送升级包的过程，此处不再赘述。
可选的，云服务器中还可以部署ECU节点升级包，在MPU从云服务器中获取ECU节点升级包且确定车辆满足升级条件时，本发明实施例中的网关还可以控制ECU节点升级，包括：网关基于Doip协议接收MPU发送的ECU节点升级包。然后网关向ECU节点发送第四模式切换请求。其中，第四模式切换请求用于请求将ECU节点从默认会话模式切换为编程模式，ECU节点在编程模式下允许外部设备向ECU节点写入数据。以使得ECU节点接收到第四模式切换请求时，将自身从默认会话模式切换为编程模式。网关在确定ECU节点从默认会话模式切换为编程模式时，向ECU节点发送ECU节点升级包，以使得ECU节点利用ECU节点升级包进行升级。
网关对ECU节点升级的过程与对MCU升级的过程相同，具体升级过程可以参考MCU升级过程，此处不再赘述。
在本发明实施例中，还可以在网关中设置会话实时保证机制，包括：若在基于Doip协议向MPU发送状态查询请求后的超时判定时长内，未接收到MPU基于Doip协议发送的状态响应信息，则在达到超时判定时长的时刻开始计时。若在计时时长未达到预设超时偏差时长之前，接收到MPU基于Doip协议发送的状态响应信息，则执行基于MPU的运行状态，确定MPU是否满足预设升级条件的步骤。若在计时时长达到预设超时偏差时长时，未接收到MPU基于Doip协议发送的状态响应信息，则停止升级。
OTA升级场景下网关中的会话保证机制与诊断仪升级场景下在诊断仪中的会话保证机制相同，可参考上述描述，此处不再赘述。
相比于MPU直接从U盘中获取升级包的方式，由于U盘中的数据容易受到外部病毒影响，因此该方法安全性较差。本发明实施例可以从云服务器或者诊断仪中获取升级包，不需要从U盘中获取，因此提高了车机升级的安全性。
以下从整体角度对本发明实施例在诊断仪升级场景下，MPU和MCU的升级过程进行说明，如图7所示，该方法包括如下步骤。
步骤701，诊断仪向MCU发送切换指令。
步骤702，MCU接收切换指令，并基于IPCP协议向MPU发送第一模式切换请求。
步骤703，MPU基于第一模式切换请求将自身的系统模式切换为Recovery模式。
步骤704，诊断仪基于Doip协议广播状态查询请求。
步骤705，MPU、MCU和ECU节点分别向诊断仪发送携带自身运行状态的状态响应信息。
步骤706，诊断仪分别接收MPU、MCU和ECU节点发送的状态响应信息，并基于MPU、MCU和ECU节点的运行状态，确定车辆是否满足预设升级条件。
步骤707，诊断仪在确定车辆满足预设升级条件，且自身存储有MPU升级包时，基于Doip协议向MPU发送第二模式切换请求。
步骤708，MPU接收第二模式切换请求，将自身从默认会话模式切换为编程模式。
步骤709，MPU获取诊断仪基于Doip协议发送的MPU升级包。
MPU从诊断仪获取MPU升级包时可以利用UDS服务中0X34、0X36和0X37指令。具体方式可参考上述诊断仪向MPU传输MPU升级包的过程，此处不再赘述。
步骤710，MPU利用MPU升级包进行升级。
步骤711，诊断仪在确定车辆满足预设升级条件，且自身存储有MCU升级包时，向MCU发送第三模式切换请求。
步骤712，MCU接收第三模式切换请求，将自身从默认会话模式切换为编程模式。
步骤713，MCU获取诊断仪发送的MCU升级包。
MCU从诊断仪获取MCU升级包时可以利用UDS服务中0X34、0X36和0X37指令。具体方式可参考上述诊断仪向MCU传输MCU升级包的过程，此处不再赘述。
步骤714，MCU利用MCU升级包进行升级。
步骤707至步骤710，与步骤711至步骤714可以同时执行，也可以先后执行，本发明实施例对此不作具体限定。
以下从整体角度对本发明实施例在OTA升级场景下，MPU和MCU的升级过程进行说明，如图8所示，该方法包括如下步骤。
步骤801，云服务器向MPU发送升级通知消息。
步骤802，MPU响应于用户触发的升级指令，基于移动通信协议从云服务器下载升级包。其中，升级包中包括MPU升级包和/或MCU升级包。
步骤803，MPU将自身的系统模式切换为Recovery模式。
其中，MPU在接收到用户触发的升级指令时，可以先下载升级包再切换至Recovery模式，也可以先切换至Recovery模式再下载升级包。
步骤804，MPU基于Doip协议向网关发送检测请求。
步骤805，网关基于Doip协议接收检测请求，并基于Doip协议广播状态查询请求。
步骤806，MPU、MCU和ECU节点分别向网关发送携带自身运行状态的状态响应信息。
步骤807，网关分别接收MPU、MCU和ECU节点发送的状态响应信息，并基于MPU、MCU和ECU节点的运行状态，确定车辆是否满足预设升级条件。
步骤808，网关基于Doip协议向MPU发送检测响应。
步骤809，MPU基于Doip协议接收检测响应，并基于检测响应确定车辆是否满足升级条件。
步骤810，MPU在车辆满足预设升级条件时，利用MPU升级包进行升级。
步骤811，MPU在车辆满足预设升级条件时，基于Doip协议向网关发送MCU升级包。
步骤812，网关基于Doip协议接收MCU升级包，并向MCU发送第三模式切换请求。
步骤813，MCU接收第三模式切换请求，将自身从默认会话模式切换为编程模式。
步骤814，MCU获取网关发送的MCU升级包。
MCU从网关获取MCU升级包时可以利用UDS服务中0X34、0X36和0X37指令。具体方式可参考上述网关向MCU传输MCU升级包的过程，此处不再赘述。
步骤815，MCU利用MCU升级包进行升级。
在本发明实施例中，可以先执行步骤810再执行步骤811至步骤815，或者先执行步骤811至步骤815再执行步骤810，或者可以同时执行步骤810与步骤811至步骤815，本发明实施例对此不作具体限定。
本发明实施例还提供了一种电子设备，如图9所示，包括处理器901、通信接口902、存储器903和通信总线904，其中，处理器901，通信接口902，存储器903通过通信总线904完成相互间的通信，
存储器903，用于存放计算机程序；
处理器901，用于执行存储器903上所存放的程序时，实现上述方法实施例中的方法步骤。
上述电子设备提到的通信总线可以是外设部件互连标准(Peripheral ComponentInterconnect，PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture，EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
通信接口用于上述电子设备与其他设备之间的通信。
存储器可以包括随机存取存储器(Random Access Memory，RAM)，也可以包括非易失性存储器(Non-Volatile Memory，NVM)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。
上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital SignalProcessor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
在本发明提供的又一实施例中，还提供了一种计算机可读存储介质，该计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现上述任一车机升级方法的步骤。
在本发明提供的又一实施例中，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述实施例中任一车机升级方法。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。
需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
以上所述仅为本发明的较佳实施例，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。

Claims (6)

1.一种车机升级方法，其特征在于，应用于车机升级系统中的诊断仪，所述车机升级系统还包括网关和安装在车辆中的信息娱乐主机IHU；所述IHU包括微处理器MPU和微控制单元MCU；
所述MCU与所述MPU之间基于网际协议控制协议IPCP通信连接；
所述MCU与所述网关之间基于FlexRay、控制器局域网络CAN或者基于网络诊断通信Doip协议通信连接；
所述MPU与所述网关之间基于Doip协议通信连接；所述MPU基于Linux内核运行安卓操作系统Android OS；
所述诊断仪与所述网关之间基于Doip协议通信连接；
所述方法包括：
基于网络诊断通信Doip协议经过所述网关向所述MCU发送切换指令，所述切换指令用于指示所述MCU将所述MPU的系统模式切换为Recovery模式，所述Recovery模式支持Doip协议；
在确定所述MPU将自身的系统模式切换为所述Recovery模式成功时，基于Doip协议经过网关向所述MPU发送状态查询请求；
基于Doip协议经过网关接收所述MPU发送的状态响应信息，所述状态响应信息包括所述MPU的运行状态；
基于所述MPU的运行状态，确定所述MPU是否满足预设升级条件；
在确定所述MPU满足所述预设升级条件时，基于Doip协议经过网关向所述MPU发送MPU升级包，以使得所述MPU利用所述MPU升级包进行升级；
所述车辆中还包括电子控制单元ECU节点；所述方法还包括：
向所述MCU和所述ECU节点分别发送状态查询请求；
分别接收所述MCU和所述ECU节点发送的携带运行状态的状态响应信息；
所述基于所述MPU的运行状态，确定所述MPU是否满足预设升级条件，包括：
基于所述MPU、所述MCU和所述ECU节点的运行状态，确定所述MPU是否满足所述预设升级条件；
若在基于Doip协议发送状态查询请求后的超时判定时长内，未接收到所述MPU基于Doip协议发送的状态响应信息，则在达到所述超时判定时长的时刻开始计时；
若在计时时长未达到预设超时偏差时长之前，接收到所述MPU基于Doip协议发送的状态响应信息，则执行所述基于所述MPU的运行状态，确定所述MPU是否满足预设升级条件的步骤；
若在计时时长达到所述预设超时偏差时长时，未接收到所述MPU基于Doip协议发送的状态响应信息，则停止升级。
2.根据权利要求1所述的方法，其特征在于，所述方法还包括：
若确定所述MPU满足所述预设升级条件，且自身存储有所述MPU升级包，则基于Doip协议经过网关向所述MPU发送第二模式切换请求，所述第二模式切换请求用于请求将所述MPU从默认会话模式切换为编程模式，所述MPU在编程模式下允许外部设备向所述MPU写入数据；
在确定所述MPU从默认会话模式切换为所述编程模式时，执行所述基于Doip协议经过网关向所述MPU发送MPU升级包的步骤。
3.根据权利要求1所述的方法，其特征在于，所述方法还包括：
若确定所述MPU满足所述预设升级条件，且自身存储有MCU升级包，则经过网关向所述MCU发送第三模式切换请求，所述第三模式切换请求用于请求将所述MCU从默认会话模式切换为编程模式，所述MCU在编程模式下允许外部设备向所述MCU写入数据；
在确定所述MCU从默认会话模式切换为所述编程模式时，经过网关向所述MCU发送所述MCU升级包，以使得所述MCU利用所述MCU升级包进行升级。
4.根据权利要求1所述的方法，其特征在于，所述方法还包括：
若接收到所述MCU发送的延时等待请求，则等待预设等待时长；所述延时等待请求用于请求所述诊断仪等待预设等待时长；
若在延时等待时长未达到所述预设等待时长之前，接收到所述MCU发送的切换成功响应，则执行基于Doip协议经过网关向所述MPU发送状态查询请求的步骤；所述切换成功响应用于表示所述MPU将自身的系统模式切换为所述Recovery模式成功；
若在延时等待时长达到所述预设等待时长时，未接收到所述MCU发送的切换成功响应，则确定所述MPU将自身的系统模式切换为所述Recovery模式失败，停止升级；
若接收到所述MCU发送的切换失败响应，则确定所述MPU将自身的系统模式切换为所述Recovery模式失败，停止升级，所述切换失败响应用于表示所述MPU将自身的系统模式切换为所述Recovery模式失败。
5.一种车机升级方法，其特征在于，应用于车机升级系统中的网关，所述车机升级系统还包括安装在车辆中的信息娱乐主机IHU和云服务器；所述IHU包括微处理器MPU和微控制单元MCU；
所述MCU与所述MPU之间基于网际协议控制协议IPCP通信连接；
所述MCU与所述网关之间基于FlexRay、控制器局域网络CAN或者基于网络诊断通信Doip协议通信连接；
所述MPU与所述网关之间基于Doip协议通信连接；所述MPU基于Linux内核运行安卓操作系统Android OS；
所述云服务器与所述MPU之间基于移动通信协议通信连接；
所述方法包括：
基于网络诊断通信Doip协议接收所述MPU发送的检测请求，所述检测请求用于请求检测所述MPU是否满足预设升级条件；所述检测请求为MPU从所述云服务器获取MPU升级包、且将自身的系统模式切换为Recovery模式时，向所述网关发送的请求，所述Recovery模式支持Doip协议；
基于Doip协议向所述MPU发送状态查询请求；
基于Doip协议接收所述MPU发送的状态响应信息，所述状态响应信息包括所述MPU的运行状态；
基于所述MPU的运行状态，确定所述MPU是否满足所述预设升级条件；
基于Doip协议向所述MPU发送检测响应，所述检测响应用于表示所述MPU是否满足所述预设升级条件，以使得MPU在所述MPU满足所述预设升级条件时，利用所述MPU升级包进行升级；
所述IHU还包括微控制单元MCU，所述车辆中还包括电子控制单元ECU节点；所述方法还包括：
向所述MCU和所述ECU节点分别发送状态查询请求；
分别接收所述MCU和所述ECU节点发送的携带运行状态的状态响应信息；
所述基于所述MPU的运行状态，确定所述MPU是否满足所述预设升级条件，包括：
基于所述MPU、所述MCU和所述ECU节点的运行状态，确定所述MPU是否满足所述预设升级条件；
若在基于Doip协议向所述MPU发送状态查询请求后的超时判定时长内，未接收到所述MPU基于Doip协议发送的状态响应信息，则在达到所述超时判定时长的时刻开始计时；
若在计时时长未达到预设超时偏差时长之前，接收到所述MPU基于Doip协议发送的状态响应信息，则执行所述基于所述MPU的运行状态，确定所述MPU是否满足所述预设升级条件的步骤；
若在计时时长达到所述预设超时偏差时长时，未接收到所述MPU基于Doip协议发送的状态响应信息，则停止升级。
6.根据权利要求5所述的方法，其特征在于，所述IHU还包括微控制单元MCU；在所述基于Doip协议向所述MPU发送检测响应之后，所述方法还包括：
基于Doip协议接收所述MPU发送的MCU升级包；
向所述MCU发送第三模式切换请求，所述第三模式切换请求用于请求将所述MCU从默认会话模式切换为编程模式，所述MCU在编程模式下允许外部设备向所述MCU写入数据；
在确定所述MCU从默认会话模式切换为所述编程模式时，向所述MCU发送所述MCU升级包，以使得所述MCU利用所述MCU升级包进行升级。
CN202110214348.0A 2021-02-25 2021-02-25 一种车机升级系统及方法 Active CN112953775B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110214348.0A CN112953775B (zh) 2021-02-25 2021-02-25 一种车机升级系统及方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110214348.0A CN112953775B (zh) 2021-02-25 2021-02-25 一种车机升级系统及方法

Publications (2)

Publication Number Publication Date
CN112953775A CN112953775A (zh) 2021-06-11
CN112953775B true CN112953775B (zh) 2023-03-24

Family

ID=76246297

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110214348.0A Active CN112953775B (zh) 2021-02-25 2021-02-25 一种车机升级系统及方法

Country Status (1)

Country Link
CN (1) CN112953775B (zh)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113727299B (zh) * 2021-07-15 2024-03-08 江铃汽车股份有限公司 一种握手认证方法、装置、可读存储介质及车辆
CN113590162B (zh) * 2021-08-24 2024-03-08 北京经纬恒润科技股份有限公司 数据的升级方法及系统
CN114374679A (zh) * 2022-01-11 2022-04-19 深圳市赛格车圣科技有限公司 一种tbox利用doip升级车载设备的方法
CN114253251A (zh) * 2022-01-20 2022-03-29 深圳市元征科技股份有限公司 车辆远程诊断方法、装置、设备连接器及存储介质
CN115346287A (zh) * 2022-07-18 2022-11-15 北京经纬恒润科技股份有限公司 信息配置方法及装置
CN116841578B (zh) * 2023-05-19 2024-03-26 国汽朴津智能科技(安庆)有限公司 一种移动机器人的远程升级方法及系统
CN117596318A (zh) * 2024-01-18 2024-02-23 北京集度科技有限公司 车辆的定时管理装置和方法、电子设备及计算机程序产品

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112055066A (zh) * 2020-08-28 2020-12-08 深圳市元征科技股份有限公司 通信方法、装置、诊断设备及计算机可读存储介质

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107450518A (zh) * 2017-08-16 2017-12-08 北京车和家信息技术有限责任公司 一种基于车载以太网构架的程序升级装置及其控制方法
WO2019168907A1 (en) * 2018-02-27 2019-09-06 Excelfore Corporation Broker-based bus protocol and multi-client architecture
CN109669442B (zh) * 2018-12-25 2022-02-22 深圳市元征科技股份有限公司 一种协议转换方法及转换装置
CN111385191B (zh) * 2018-12-28 2022-03-15 联合汽车电子有限公司 车载互联网关、车辆ota升级系统和方法、计算机存储介质
CN110474961B (zh) * 2019-07-14 2022-05-06 江苏开沃汽车有限公司 纯电乘用车基于can总线实现多路远程ota升级方法
CN111061499B (zh) * 2019-12-31 2023-06-13 上海赫千电子科技有限公司 一种基于文件系统的ecu更新方法及系统
CN111897546B (zh) * 2020-06-30 2022-08-02 吉利汽车研究院（宁波）有限公司 一种车辆软件刷写方法、系统、设备及存储介质
CN111917842A (zh) * 2020-07-16 2020-11-10 无锡华普微电子有限公司 一种汽车仪表的ota升级方法、系统及汽车仪表系统

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112055066A (zh) * 2020-08-28 2020-12-08 深圳市元征科技股份有限公司 通信方法、装置、诊断设备及计算机可读存储介质

Also Published As

Publication number Publication date
CN112953775A (zh) 2021-06-11

Similar Documents

Publication Publication Date Title
CN112953775B (zh) 一种车机升级系统及方法
CN108833122B (zh) 车载通信控制器的唤醒方法、装置及存储介质
EP3404872B1 (en) Device control method, network device, and network system
US20030121032A1 (en) Method and system for remotely updating function of household device
CN105677433A (zh) 服务器程序热升级的方法及装置
WO2015051647A1 (zh) 一种固件的升级方法和系统、上位机和光模块
US9537818B2 (en) Enhanced DHCP method
CN109040295B (zh) 异常断线的确定方法及装置、终端及存储介质
CN110012527B (zh) 唤醒方法及电子设备
WO2012094853A1 (zh) 终端软件的安装方法、装置和系统
CN103650401A (zh) 一种移动终端内部通信方法
CN115016805A (zh) 一种车辆系统升级方法、装置、系统、设备和介质
CN111078266A (zh) 低耦合增量升级语音软件的客户端处理方法及装置、服务端处理方法
EP3796693B1 (en) Method, apparatus, terminal and storage medium for sending measurement report
CN103442041A (zh) 嵌入式设备固件升级的方法、装置及其系统
CN113396600B (zh) 信息验证方法、装置、设备及存储介质
CN112203170B (zh) 一种光网络单元的升级方法、装置、介质及设备
JP4123946B2 (ja) 時刻同期システム
CN115431896A (zh) 控制方法、装置、电子设备、存储介质、车机系统及车辆
JPH10327212A (ja) ネットワーク接続制御システムおよび記憶媒体
KR20150076723A (ko) 차량 부팅 방법 및 차량 부팅 장치
JP2022538080A (ja) 車両の車載バス上のコンピュータと対話する方法
CN108600044B (zh) 一种接口状态获取方法、装置及设备
WO2019085347A1 (zh) 电视机系统软件的升级方法及装置
CN114936043B (zh) 一种池化异构资源启动方法、装置、设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
TA01 Transfer of patent application right

Effective date of registration: 20220322

Address after: 430051 No. b1336, chuanggu startup area, taizihu cultural Digital Creative Industry Park, No. 18, Shenlong Avenue, Wuhan Economic and Technological Development Zone, Hubei Province

Applicant after: Yikatong (Hubei) Technology Co.,Ltd.

Address before: 430056 building B (qdxx-f7b), No.7 building, qiedixiexin science and Technology Innovation Park, South taizihu innovation Valley, Wuhan Economic and Technological Development Zone, Hubei Province

Applicant before: HUBEI ECARX TECHNOLOGY Co.,Ltd.

TA01 Transfer of patent application right
GR01 Patent grant
GR01 Patent grant