WO2022193096A1 - 基于空中下载技术ota的通信方法和装置 - Google Patents

基于空中下载技术ota的通信方法和装置 Download PDF

Info

Publication number
WO2022193096A1
WO2022193096A1 PCT/CN2021/080863 CN2021080863W WO2022193096A1 WO 2022193096 A1 WO2022193096 A1 WO 2022193096A1 CN 2021080863 W CN2021080863 W CN 2021080863W WO 2022193096 A1 WO2022193096 A1 WO 2022193096A1
Authority
WO
WIPO (PCT)
Prior art keywords
software version
version information
software
identification code
information
Prior art date
Application number
PCT/CN2021/080863
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/CN2021/080863 priority Critical patent/WO2022193096A1/zh
Priority to CN202180000506.0A priority patent/CN113168317A/zh
Priority to JP2023556732A priority patent/JP2024510237A/ja
Priority to EP21930692.5A priority patent/EP4307734A4/en
Publication of WO2022193096A1 publication Critical patent/WO2022193096A1/zh

Links

Images

Classifications

    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • 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
    • 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/085—Retrieval of network configuration; Tracking network configuration history
    • H04L41/0859—Retrieval of network configuration; Tracking network configuration history by keeping history of different configuration generations or by rolling back to previous configuration versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network

Definitions

  • the present application relates to the field of communication technologies, and in particular, to a communication method and device based on the over-the-air technology OTA.
  • OTA over-the-air technology
  • OTA brings convenience to people, it also brings challenges to the access of cars.
  • access can be understood as the process of going through a series of safety or emission related tests before the car is put on the market to meet the requirements of relevant standards.
  • using OTA to update the car software may change the access parameters of the car after it goes on the market. For example, after upgrading the battery management software of the car through OTA, the cruising range of the car may be increased, making it inconsistent with the cruising range measured at the time of admission, and the data tested when the car is admitted may be invalid and need to be re-tested. . Therefore, the software version upgraded through OTA is inconsistent with the software version at the time of admission, which brings certain challenges to the development of OTA.
  • the embodiments of the present application provide a communication method and device based on the over-the-air download technology OTA, which can ensure the normal upgrade of the car software during the maintenance of the OTA and the process of installing the software, thereby maintaining the safety of the vehicle.
  • an embodiment of the present application provides an OTA-based communication method, including: obtaining first information and second information; the first information includes first software version information and/or a first identification code; the second information includes a mapping; the first mapping includes the association relationship between the second software version information and the second identification code; the identification code is used to indicate the authority information of the software version; according to the first information and the second information, verify the first software version information and the first software version information The consistency of the corresponding second software version information is mapped.
  • the matching relationship between the identification codes in the first information and the second information and the software version can be used to verify the consistency of the first information and the second information, so as to realize the maintenance of the OTA and the process of installing the software.
  • the software version is consistent with the identification code, thereby ensuring the normal upgrade of the car software and maintaining the safety of the vehicle.
  • verifying the consistency of the first software version information and the second software version information corresponding to the first mapping includes: in the first software The version information is inconsistent with the second software version information, and/or when the first identification code is inconsistent with the second identification code, it is determined that the first software version information is inconsistent with the second software version information; or, when the first software version information is inconsistent If the information is consistent with the second software version information, and/or the first identification code is consistent with the second identification code, it is determined that the first software version information is consistent with the second software version information.
  • the cloud or the on-board terminal can be used to verify the consistency of the first software version information and the second software version information, and further, by maintaining the consistency of the software version and the identification code on the on-board terminal and/or in the cloud, it is possible to prevent the software version and/or the Or the identification code has been tampered with, to ensure the normal upgrade of the car software upgraded through OTA.
  • the method further includes: updating the first software version information and/or the first identification code when the first software version information is inconsistent with the second software version information; or , in the case that the first software version information is consistent with the second software version information, update the first software version information and/or the first identification code.
  • the cloud and the car end can maintain the consistency of the software version information and/or identification code on the car end, and the mapping relationship with the cloud device, eliminating the need for software version upgrade through OTA and access time. If the software version of the car is inconsistent, ensure the normal upgrade of the car software.
  • the method before updating the first software version and/or the first identification code, further includes: sending a first task to the first vehicle; the first task is used to instruct to update the first software version and/or the first identification code. software version information and/or a first identification code; wherein, in the case that the first software version information is inconsistent with the second software version information, the first task includes the first mapping; or, when the first software version information and the second software version information are inconsistent If the software version information is consistent, the first task includes the second mapping; the second mapping includes the association relationship between the third software version information and the third identification code; the third software version information is different from the second software version information, and/or , the third identification code is different from the second identification code.
  • the matching relationship between the software version information and the identification code can be guaranteed during the OTA software upgrade process, and based on the consistency of the software version and the identification code in the vehicle and/or the cloud, the software version and the access code upgraded through OTA can be eliminated. If there are inconsistencies in the software version at the time, the normal upgrade of the car software is guaranteed.
  • the method further includes: sending a first software package to the first vehicle; the first software package is used to update software version information corresponding to the first vehicle; wherein, in the first software When the version information is inconsistent with the second software version information, the first software package includes the second identification code; or, when the first software version information is consistent with the second software version information, the first software package includes a third identification code code.
  • the matching relationship between the software version information and the identification code can be guaranteed during the OTA software upgrade process, and based on the consistency of the software version and the identification code in the vehicle and/or the cloud, the software version and the access code upgraded through OTA can be eliminated. If there are inconsistencies in the software version at the time, the normal upgrade of the car software is guaranteed.
  • the method further includes: in the case that the first software version information is inconsistent with the second software version information, sending the first software version to the server and/or the display device of the first vehicle information, the first identification code and/or alarm information; the alarm information is used to indicate that the identification code and/or software version information of the first vehicle is inconsistent with the mapping relationship of the server.
  • the cloud device and/or the display device of the first vehicle can be processed in time based on the alarm information sent by the vehicle terminal, thereby further ensuring the normal upgrade of the car software.
  • updating the first software version information and/or the first identification code includes: receiving a first task from a server, where the first task is used to instruct to update the first software version information and/or the first identification code; wherein, when the first software version information is inconsistent with the second software version information, the first task includes the first mapping; or, when the first software version information is consistent with the second software version information Under the circumstance, the first task includes the second mapping; the second mapping includes the association relationship between the third software version information and the third identification code; the third software version information is different from the second software version information, and/or, the third identification code The code is different from the second identification code.
  • the matching relationship between the software version information and the identification code can be guaranteed during the OTA software upgrade process, and based on the consistency of the software version and the identification code in the vehicle and/or the cloud, the software version and the access code upgraded through OTA can be eliminated. If there are inconsistencies in the software version at the time, the normal upgrade of the car software is guaranteed.
  • the method further includes: receiving a first software package from a server; the first software package is used to update software version information corresponding to the first vehicle; wherein, in the first software version information In the case of inconsistency with the second software version information, the first software package includes the second identification code; or, in the case in which the first software version information is consistent with the second software version information, the first software package includes the third identification code.
  • the matching relationship between the software version information and the identification code can be guaranteed during the OTA software upgrade process, and based on the consistency of the software version and the identification code in the vehicle and/or the cloud, the software version and the access code upgraded through OTA can be eliminated. If there are inconsistencies in the software version at the time, the normal upgrade of the car software is guaranteed.
  • the first vehicle includes a plurality of electronic control units related to the first software package, and updating the software in the first vehicle according to the first software package includes: updating N
  • the electronic control unit sends the first software package corresponding to each electronic control unit; N is a positive integer; receives N software installation results from N electronic control units; when the N software installation results are any one or more installation failures Next, roll back the vehicle software version and identification code of the first vehicle.
  • the matching relationship between the software version information and the identification code can be guaranteed during the OTA software upgrade process, and based on the consistency of the software version and the identification code in the vehicle and/or the cloud, the software version and the access code upgraded through OTA can be eliminated. If there are inconsistencies in the software version at the time, the normal upgrade of the car software is guaranteed.
  • the warning information from the first vehicle is received; the warning information is displayed.
  • the identification code includes the first regulation-related software identification code RXSWIN.
  • RXSWIN the first regulation-related software identification code
  • the matching relationship between RXSWIN and software version can be used to ensure the consistency of RXSWIN and software version in the process of OTA maintenance and software installation, and to ensure the normal upgrade of automotive software.
  • the alarm information used in the system to indicate that the software version information is inconsistent with the identification code can be intuitively displayed to the user through the user interface, which is convenient for the user to carry out subsequent processing in a timely manner, and further ensures the normal upgrade of the automobile software.
  • an embodiment of the present application provides an OTA-based communication device, a communication unit, configured to obtain first information and second information; the first information includes first software version information and/or a first identification code; the second The information includes a first mapping; the first mapping includes an association relationship between the second software version information and the second identification code; the identification code is used to indicate the authority information of the software version; the processing unit is further configured to, according to the first information and the second information, Verify the consistency of the first software version information with the second software version information corresponding to the first mapping.
  • the processing unit is specifically configured to: when the first software version information is inconsistent with the second software version information, and/or the first identification code is inconsistent with the second identification code In this case, it is determined that the first software version information is inconsistent with the second software version information; or, in the case that the first software version information is consistent with the second software version information, and/or the first identification code is consistent with the second identification code , and determine that the first software version information is consistent with the second software version information.
  • the processing unit is further configured to: update the first software version information and/or the first identifier when the first software version information is inconsistent with the second software version information or, if the first software version information is consistent with the second software version information, update the first software version information and/or the first identification code.
  • the communication unit is specifically configured to: send the first task to the first vehicle; the first task is used to instruct to update the first software version information and/or the first identification code; Wherein, when the first software version information is inconsistent with the second software version information, the first task includes the first mapping; when the first software version information is consistent with the second software version information, the first task includes the second mapping; the second mapping includes the association relationship between the third software version information and the third identification code; the third software version information is different from the second software version information, and/or the third identification code is different from the second identification code.
  • the communication unit is further configured to: send the first software package to the first vehicle; the first software package is used to update the software version information corresponding to the first vehicle; wherein, in When the first software version information is inconsistent with the second software version information, the first software package includes the second identification code; or, when the first software version information is consistent with the second software version information, the first software package includes third identification code.
  • the communication unit is further configured to: in the case that the first software version information is inconsistent with the second software version information, send to the server and/or the display device of the first vehicle The first software version information, the first identification code and/or the warning information; the warning information is used to indicate that the identification code and/or software version information of the vehicle is inconsistent with the mapping relationship of the server.
  • the communication unit is specifically configured to: receive a first task from the server, where the first task is used to instruct to update the first software version information and/or the first identification code; wherein , in the case that the first software version information is inconsistent with the second software version information, the first task includes the first mapping; or, in the case that the first software version information is consistent with the second software version information, the first task includes the first task.
  • the communication unit is further configured to: receive the first software package from the server; the first software package is used to update the software version information corresponding to the first vehicle; wherein, in the first software package When the first software version information is inconsistent with the second software version information, the first software package includes the second identification code; or, when the first software version information is consistent with the second software version information, the first software package includes the first software package.
  • the communication unit is further configured to: receive the first software package from the server; the first software package is used to update the software version information corresponding to the first vehicle; wherein, in the first software package When the first software version information is inconsistent with the second software version information, the first software package includes the second identification code; or, when the first software version information is consistent with the second software version information, the first software package includes the first software package.
  • the communication unit is specifically used to send the first software package corresponding to each electronic control unit to the N electronic control units; N is a positive integer; the communication unit is specifically used to receive N software installation results from N electronic control units; the processing unit is specifically configured to roll back the entire vehicle software version and identification code of the first vehicle when the N software installation results are any one or more installation failures .
  • the communication unit is specifically used for receiving the warning information from the first vehicle; the display unit is specifically used for displaying the warning information.
  • the identification code includes the first regulation-related software identification code RXSWIN.
  • embodiments of the present application provide a computer-readable storage medium, in which a computer program or instruction is stored, and when the computer program or instruction is run on a computer, the computer is made to execute the first aspect and the third The OTA-based communication method described in any one of the possible implementations of the aspect.
  • an embodiment of the present application provides an OTA-based communication device, the device includes a processor and a memory, the memory stores an instruction, and when the instruction is executed by the processor, any one of the first aspect and the first aspect is implemented
  • the OTA-based communication method described in this possible implementation is not limited to a processor and a memory.
  • the present application provides a chip or a chip system, the chip or chip system includes at least one processor and a communication interface, the communication interface and the at least one processor are interconnected by a line, and the at least one processor is used for running a computer program or instruction,
  • the OTA-based communication method described in any one of the first aspect and any possible implementation manner of the first aspect is implemented.
  • the communication interface in the chip can be an input/output interface, a pin or a circuit, etc.
  • the chip or chip system described above in this application further includes at least one memory, where instructions are stored in the at least one memory.
  • the memory may be a storage unit inside the chip, such as a register, a cache, etc., or a storage unit of the chip (eg, a read-only memory, a random access memory, etc.).
  • an embodiment of the present application provides a computer program product that, when the computer program product runs on one or more processors, implements the first aspect and any one of the possible implementation manners described in the first aspect. Methods.
  • FIG. 1 is a schematic diagram of the correspondence between a RXSWIN and a software version provided by an embodiment of the present application;
  • FIG. 2 is a schematic diagram of a first application scenario provided by an embodiment of the present application
  • FIG. 3 is a schematic diagram of a system architecture for software update in a vehicle provided by an embodiment of the present application.
  • FIG. 4 is a schematic diagram of a second application scenario provided by an embodiment of the present application.
  • FIG. 5 is a schematic diagram of a third application scenario provided by an embodiment of the present application.
  • FIG. 6 is a schematic flowchart of an OTA-based communication method provided by an embodiment of the present application.
  • FIG. 7 is a schematic flowchart of a cloud maintaining the consistency of an identification code and software version information according to an embodiment of the present application
  • FIG. 8 is a schematic flowchart of the consistency between the vehicle-end maintenance identification code and software version information provided by an embodiment of the present application.
  • FIG. 9 is a schematic diagram of an interface for displaying alarm information according to an embodiment of the present application.
  • FIG. 10 is a schematic flowchart of a cloud performing consistency judgment according to an embodiment of the present application.
  • FIG. 11 is a schematic flowchart of updating software provided by an embodiment of the present application.
  • FIG. 12 is a schematic flowchart of a cloud delivering a software package to a vehicle according to an embodiment of the present application
  • FIG. 13 is a schematic flowchart of a vehicle-end installation software package provided by an embodiment of the present application.
  • FIG. 14 is a schematic flowchart of another vehicle-end installation software package provided by an embodiment of the present application.
  • FIG. 15 is a schematic structural diagram of an OTA-based communication device provided by an embodiment of the application.
  • 16 is a schematic diagram of a hardware structure of a control device provided by an embodiment of the application.
  • FIG. 17 is a schematic structural diagram of a chip provided by an embodiment of the present application.
  • words such as “first” and “second” are used to distinguish the same or similar items with basically the same function and effect.
  • the first identification code and the second identification code are used to distinguish different identification codes, and the sequence of the identification codes is not limited.
  • the words “first”, “second” and the like do not limit the quantity and execution order, and the words “first”, “second” and the like are not necessarily different.
  • At least one means one or more
  • plural means two or more.
  • And/or which describes the association relationship of the associated objects, indicates that there can be three kinds of relationships, for example, A and/or B, which can indicate: the existence of A alone, the existence of A and B at the same time, and the existence of B alone, where A, B can be singular or plural.
  • the character “/” generally indicates that the associated objects are an “or” relationship.
  • At least one item(s) below” or similar expressions thereof refer to any combination of these items, including any combination of single item(s) or plural items(s).
  • At least one (a) of a, b, or c may represent: a, b, c, a and b, a and c, b and c, or a, b and c, where a, b, c can be single or multiple.
  • OTA Advanced Driver Assistance Systems
  • access can be understood as the process of going through a series of safety or emission related tests before the car is put on the market to meet the requirements of relevant standards.
  • the automobile is a special product because the defects of the automobile may cause significant personal and property damage.
  • the car Before a car is put on the market, it needs to go through an admission test, and when it passes the admission, the car can be allowed to enter the market.
  • an automobile product When an automobile product is applied for and approved, it can record and announce the entry information of the automobile to the society.
  • the car after the announcement can be allowed to sell.
  • the announcement may include basic information such as the wheelbase, weight or displacement of the vehicle, and may also include information on technical characteristic parameters such as cruising range or maximum speed.
  • the regulatory department can regularly check the relevant parameters of automobile products and compare them with the announcement information. Require car manufacturers to rectify or require car manufacturers to implement measures such as suspension of production.
  • the car software can be updated via OTA, however, the update process may change the test parameters when the software is admitted.
  • the cruising range of the car may be increased, making it inconsistent with the cruising range measured at the time of admission, and the data tested when the car is admitted is invalid and needs to be re-tested. Therefore, the software version upgraded through OTA is inconsistent with the software version at the time of admission, which brings certain challenges to the development of OTA.
  • the United Nations World Vehicle Regulations Harmonization Forum under the United Nations Economic Commission for Europe (the united nations economic commission for europe, UNECE) established an OTA working group to discuss the incorporation of OTA into the access supervision system.
  • RXSWIN regulatory-Related Software Identification Number
  • the RXSWIN can record the relationship between software version and access, and its role is to record and trace the software and software upgrades that have an impact on access from the perspective of access regulations, so that access regulators can manage automotive software upgrades.
  • the change of RXSWIN can represent the change of admission caused by software upgrade.
  • FIG. 1 is a schematic diagram of a corresponding relationship between an RXSWIN and a software version according to an embodiment of the present application.
  • the initial RXSWIN and its corresponding software version can be configured during admission, for example, the initial RXSWIN is R79 110.
  • the software version corresponding to R79 110 may include: the software version corresponding to the power steering electronic control unit (ECU) is v1.0; the software version corresponding to the body stability ECU is v2.0; the corresponding software version of the vehicle control ECU is v2.0; The software version is v1.0.
  • ECU power steering electronic control unit
  • the software When the software is upgraded by means of OTA, it can be upgraded to a schematic diagram of the corresponding relationship between the upgraded RXSWIN and the software version as shown in b in Figure 1 .
  • the software version information associated with RXSWIN can be changed, but RXSWIN remains unchanged.
  • the software version corresponding to the R79 110 may include: the software version corresponding to the power steering ECU is v1.1; the software version corresponding to the body stability ECU is v2.2; the software version corresponding to the vehicle control ECU is v1.0.
  • the software When the software is further upgraded by means of OTA, it can be upgraded to a schematic diagram of the matching relationship between the RXSWIN and the software version after the software upgrade that affects the admission, as shown in c in FIG. 1 .
  • the software version information associated with RXSWIN changes, and RXSWIN changes.
  • RXSWIN was changed from R79 110 to R79 111.
  • the software version corresponding to R79 111 may include: the software version corresponding to the power steering ECU is v2.0; the software version corresponding to the body stability ECU is v2.2; the software version corresponding to the vehicle control ECU is v1.0.
  • the OTA upgrade makes the software version corresponding to the power steering ECU upgrade from the original v1.1 to v2.0, and the upgrade of the power steering ECU leads to the change of the test parameters corresponding to the software during admission, so the RXSWIN is changed from R79 110 to R79 111, the RXSWIN is used to identify that the OTA upgrade affects the admission parameters.
  • RXSWIN can be applied to OTA-based software upgrades to represent the corresponding relationship with software versions.
  • the consistency of the RXSWIN and software versions between the vehicle and the cloud cannot be guaranteed, and the inconsistency between the software version upgraded through OTA and the software version at the time of admission cannot be well resolved. This makes it difficult to maintain safe upgrades of automotive software.
  • the embodiments of the present application provide an OTA-based communication method and device, which can acquire first information and second information in the process of OTA maintenance and software installation, and use the first information and the second information in the process.
  • the matching relationship between the identification code and the software version based on the matching relationship between the identification code and the software version, the consistency of the first information and the second information can be verified, and then the consistency between the software version and the identification code can be maintained by maintaining the vehicle end and/or the cloud. , to eliminate the inconsistency between the software version upgraded through OTA and the software version at the time of admission, and ensure the normal upgrade of automotive software.
  • the identification code can be RXSWIN.
  • an OTA-based communication method provided by the embodiments of the present application can be applied to the maintenance and upgrade scenarios of various types of vehicles over OTA. Consistency of software versions, or in scenarios such as downloading or updating software in vehicles. Wherein, the number of the vehicle terminal and/or cloud device can be one or more.
  • the vehicle end (or the vehicle or the vehicle end device) may be any form of vehicle for software upgrade, or any form of vehicle auxiliary equipment (eg, vehicle charging pile, etc.), which is not specifically limited in the embodiments of the present application.
  • vehicle auxiliary equipment eg, vehicle charging pile, etc.
  • the cloud can be an OTA server for delivering vehicle upgrade packages, or a proxy server.
  • the proxy server can be a server serving the fleet.
  • the proxy server can first establish secure communication through two-way authentication with the OTA server. After that, the proxy server sends the hardware and software information of the vehicle to the OTA server. After the OTA server generates the vehicle upgrade package , the vehicle upgrade package can be delivered to the proxy server. It is understandable that the OTA server can also divide the vehicle upgrade package into blocks and deliver it to multiple proxy servers.
  • the cloud can also be a software client server for updating software, a fleet server or any other possible server that has acquired and updated software from the software client server.
  • the cloud may also be any form of vehicle, any form of vehicle auxiliary equipment (such as a vehicle charging pile, etc.), or a mobile terminal (such as a mobile phone, tablet, wearable device, etc.), which is not specifically limited in this embodiment of the present application.
  • vehicle auxiliary equipment such as a vehicle charging pile, etc.
  • mobile terminal such as a mobile phone, tablet, wearable device, etc.
  • the above vehicle and the cloud device can establish a communication connection, for example, the vehicle and the cloud device can use the hypertext transfer protocol (hyper text tansfer protocol, HTTP) or the hypertext transfer protocol based on the secure socket layer (hyper text transfer trotocol over secure socket layer) , HTTPS) and other protocols to establish a communication connection, which is not limited in this embodiment of the present application.
  • HTTP hypertext transfer protocol
  • HTTPS hypertext transfer protocol based on the secure socket layer (hyper text transfer trotocol over secure socket layer)
  • HTTPS hypertext transfer protocol based on the secure socket layer
  • FIG. 2 is a schematic diagram of a first exemplary application scenario provided by an embodiment of the present application.
  • the scene may include a vehicle 201 and a software OTA cloud device 202 .
  • Vehicle 201 is any form of vehicle with a software OTA client installed.
  • the software OTA cloud device 202 is a server that provides OTA upgrade, and is used to store software packages, and store the mapping relationship between the identification code (for example, RXSWIN) and the software version, and the like.
  • the software OTA cloud device 202 can obtain the software version information and/or identification code of each software on the software OTA client in the vehicle 201, and compare it with the identification code and software version stored in the vehicle 201.
  • the mapping relationship is compared, and when the software version information and/or identification code of each software in the car 201 is consistent with the mapping relationship, the software package can be automatically sent or sent according to the request command of the software OTA client to the software in the vehicle 201.
  • the software package contains the identification code.
  • the software OTA client in the vehicle 201 can update the software and the identification code according to the software package from the software OTA cloud device.
  • the number of the vehicle 201 and the software OTA cloud device 202 may be one or more, which is not specifically limited in this embodiment of the present application.
  • the software OTA cloud device can also be a car factory OTA cloud device.
  • the OTA cloud device of the car factory can be an OTA server for delivering the whole vehicle upgrade package.
  • FIG. 3 is a schematic diagram of a system architecture for software update in a vehicle according to an embodiment of the present application.
  • the system may include: a car factory OTA cloud device 301 , a software OTA cloud device 302 , a master control OTA client 303 and a software OTA client 304 .
  • the OTA cloud device 301 of the vehicle manufacturer may be a server of a vehicle manufacturer or a software service provider in a vehicle, and is used to manage software in the vehicle and store software data.
  • the software in the vehicle may include body control software and the like.
  • the software OTA cloud device 302 may be used to store software packages, and store the mapping relationship between identification codes and software versions, and the like.
  • the depot OTA cloud device 301 can interact with the software OTA cloud device 302 .
  • the software information of the OTA cloud device 301 of the car factory comes from the software OTA cloud device 302, or the OTA cloud device 301 of the car factory can also determine the software information by itself.
  • the OTA upgrade in the vehicle may include two levels of master node and slave node.
  • the master control OTA client 303 corresponds to the master control node, and can receive the whole vehicle upgrade package, and split and distribute it to multiple slave clients controlled by it.
  • the software OTA client 304 corresponds to the slave node, and may be a slave OTA client under the master OTA client 303 .
  • the software OTA client 304 may perform software updates as part of a vehicle OTA upgrade.
  • a possible implementation is that the software OTA cloud device 302 interacts with the software OTA client 304 to update the software.
  • the specific implementation process is consistent with the description of the application scenario shown in FIG. 1 , and details are not repeated here.
  • the car factory OTA cloud device 301, the main control OTA client 303 and the software OTA client 304 interact to update the software.
  • the car factory OTA cloud device 301 may be based on the mapping relationship between the identification code and the software version stored by itself, and the consistency of the software version and/or identification code obtained from the master OTA client 303 (or the software OTA client 304).
  • the software package that needs to be updated is sent to the main control OTA client 302 through the vehicle upgrade package.
  • the main control OTA client 302 receives and downloads the vehicle upgrade package, splits the vehicle upgrade package and sends it to the software OTA client 304 .
  • the software OTA client 304 updates the software and the identification code according to the software package in the split vehicle upgrade package.
  • FIG. 4 is a schematic diagram of a second exemplary application scenario provided by an embodiment of the present application.
  • the application scenario may include a server 401 , a first vehicle 402 , a second vehicle 403 , a second vehicle 404 and a second vehicle 405 .
  • the server 401 may be a fleet server, and the fleet server may obtain from the OTA server in advance the entire fleet (for example, including the first vehicle 402 , the second vehicle 403 , the second vehicle 404 and the second vehicle 405 ) required by the fleet server served by the fleet server. car upgrade package.
  • the first vehicle 402 , the second vehicle 403 , the second vehicle 404 and the second vehicle 405 are linked to the fleet server in the case of wireless fidelity (wireless-fidelity, WIFI) and other networking conditions, and when the upgrade package is received
  • the fleet server performs two-way authentication with the first vehicle 402, the second vehicle 403, the second vehicle 404 and the second vehicle 405 (such as the authentication method based on public key infrastructure). After the authentication is passed, the fleet server will upgrade the package.
  • the encryption key k is encrypted (encrypted with the public key of the vehicle) and then distributed to the first vehicle 402 , the second vehicle 403 , the second vehicle 404 and the second vehicle 405 .
  • the first vehicle 402 , the second vehicle 403 , the second vehicle 404 and the second vehicle 405 can use the key k to decrypt the key, and download the required whole vehicle software package from the server.
  • the first vehicle 402 can complete the software update according to the complete vehicle upgrade package.
  • the whole vehicle upgrade package may include a software package for updating the identification code.
  • the first vehicle 402 can update the software and the identification code according to the software package.
  • FIG. 5 is a schematic diagram of a third exemplary application scenario provided by an embodiment of the present application.
  • the application scenario may include a vehicle 501 and a vehicle auxiliary device 502 .
  • Vehicle 501 may be any form of vehicle.
  • the vehicle auxiliary device 502 may be a vehicle charging pile or any other terminal device (such as a mobile phone and a tablet, etc.) that assists the OTA update of the vehicle.
  • the vehicle auxiliary device 502 may send the software package that needs to be updated to the vehicle 501 based on the mapping relationship between the identification code and the software version stored by itself, and the consistency of the software version and/or identification code obtained from the vehicle 501 .
  • the vehicle 501 can update the software and the identification code according to the received software package.
  • Automotive OTA refers to the process of updating and upgrading its own system by downloading software update packages from a remote server through the network.
  • each update of the car OTA corresponds to a vehicle upgrade package and a vehicle version number
  • a vehicle upgrade package includes software of multiple ECUs in the vehicle.
  • OTA cloud device of car factory a cloud service provided by car manufacturers or service providers, which is responsible for managing upgrade tasks, software upgrade packages, or identification codes and other information in the cloud, and distributes it to vehicles that need software upgrades in the form of OTA.
  • the OTA method can be accessed through WIFI, long term evolution (LTE), fifth generation (5th generation, 5G) mobile communication system or new radio (NR) and satellite.
  • LTE long term evolution
  • 5G fifth generation
  • NR new radio
  • Software OTA cloud device a cloud service for software, which is responsible for managing certain software in the car in the cloud, or information such as identification codes, and distributes it to users or vehicles that need to be upgraded by OTA.
  • OTA cloud device or software OTA cloud device in the embodiments of the present application may be collectively referred to as an OTA cloud, which is used to update software and identification codes.
  • Update master (referred to as Master node): The software deployed on an ECU in the vehicle is responsible for centrally controlling the OTA upgrade of the vehicle, downloading the vehicle upgrade package from the OTA cloud, and distributing it to the corresponding ECU after splitting.
  • it may also be a module unit that exists alone on the vehicle, which is not limited in this embodiment of the present application.
  • Electronic control unit including automatic driving controller, cockpit controller, communication box (telematics box, T-Box) and gateway, etc.
  • the software upgrade of the ECU can be downloaded from the OTA cloud and installed and upgraded, or under the centralized control and coordination of the main control node, the main control node can split the whole vehicle upgrade package and distribute the software upgrade package for upgrade.
  • FIG. 6 is a schematic flowchart of an OTA-based communication method provided by an embodiment of the present application. As shown in FIG. 6 , the method may include the following steps:
  • the first information and the second information may be information used for the vehicle terminal and/or the cloud to verify the consistency between the software version information and the identification code.
  • the first information may include: the first software version information and/or the first identification code; the second information may include a first mapping; the first mapping includes the association relationship between the second software version information and the second identification code.
  • the first information may come from the vehicle end; the second information may come from the cloud.
  • the identification code may be used to indicate the permission information of the software version.
  • permissions can be understood as restrictions that allow car access.
  • the identification code may be other identifications such as RXSWIN.
  • the software version information may be information used to identify different software versions, for example, the software version information may be other information such as a software version number.
  • identification code and the software version information may include other contents according to actual scenarios, which are not limited in this embodiment of the present application.
  • the subject that obtains the first information and the second information may be the cloud or the vehicle terminal.
  • the vehicle can report the first information to the cloud, and the cloud can receive the first information reported by the vehicle and obtain the second information saved by itself, and then the first information and the second information can be obtained.
  • the cloud can send the second information to the vehicle terminal, and then the vehicle terminal can receive the second information sent from the cloud, and obtain the first information saved by itself, and then The consistency of the first information and the second information may be verified.
  • the consistency of the first software version information and the second software version information corresponding to the first mapping may include: the first software version information is consistent with the second software version information, or the first software version The information is inconsistent with the second software version information.
  • the subjects for verifying the consistency of the first software version information and the second software version information corresponding to the first mapping may include two types: the cloud or the vehicle terminal. It can be understood that the embodiment of the present application does not limit the execution subject that verifies the consistency of the first software version information and the second software version information corresponding to the first mapping.
  • the embodiments of the present application provide an OTA-based communication method and device, which can acquire first information from the vehicle and second information from the cloud during OTA maintenance and software installation, and use the first The matching relationship between the identification code and the software version in the information and the second information, to verify the consistency of the first information and the second information, and then to maintain the consistency of the software version and the identification code in the vehicle and/or the cloud to eliminate There is inconsistency between the software version upgraded through OTA and the software version at the time of admission, so as to ensure the normal upgrade of the car software.
  • the execution subject that verifies the consistency of the first software version information and the second software version information corresponding to the first mapping may be For the cloud, or the car side.
  • way 1 use the cloud to verify the consistency of the first software version information and the second software version information corresponding to the first mapping (the embodiment corresponding to FIG. 7 ).
  • Method 2 Use the vehicle end to verify the consistency of the first software version information and the second software version information corresponding to the first mapping (the embodiment corresponding to FIG. 8 ).
  • Method 1 Use the cloud to verify the consistency of the first software version information and the second software version information.
  • FIG. 7 is a schematic flowchart of a cloud maintaining consistency between an identification code and software version information according to an embodiment of the present application.
  • the cloud is the OTA cloud
  • the vehicle end includes a master control node, ECU1 and ECU2
  • the identification code is RXSWIN
  • the first mapping is the RXSWIN mapping (including the relationship between RXSWIN and software version information) as
  • the cloud verifies the consistency of the first software version information and the second software version information according to the first information and the second information.
  • This example does not constitute a limitation to the embodiments of the present application.
  • the process of maintaining the consistency between the identification code and the software version information in the cloud may include the following steps:
  • the master control node collects software version information on each ECU (including ECU1 and ECU2).
  • the master control node may periodically collect software version information on each ECU. For example, it is set to collect software version information on each ECU once a week.
  • the main control node reports the software version information of the vehicle end to the OTA cloud.
  • the OTA cloud receives the software version information reported by the vehicle.
  • the vehicle end may perform the steps shown in S703.
  • the main control node reports the RXSWIN identifier of the vehicle end to the OTA cloud.
  • the OTA cloud receives the RXSWIN reported by the vehicle.
  • the OTA cloud checks the consistency of RXSWIN related software version information, and if it is inconsistent, perform software upgrade.
  • the OTA cloud compares the software version information reported in the step shown in S702 with the RXSWIN mapping table saved in the OTA cloud, and when the software version information reported by the master node is inconsistent with the software version information in the RXSWIN mapping table , it can indicate that the software related to access has been modified illegally.
  • the OTA cloud can upgrade the software through OTA, and modify the software version information of the vehicle to ensure that the software version information of the vehicle is mapped with the RXSWIN saved in the OTA cloud. table consistency.
  • the cloud may perform the steps shown in S705.
  • the OTA cloud checks the consistency of RXSWIN, and if it is inconsistent, updates RXSWIN.
  • the OTA cloud compares the RXSWIN identifier reported in the step shown in S703 with the RXSWIN mapping table saved in the OTA cloud, and when the RXSWIN identifier reported by the vehicle is inconsistent with the RXSWIN identifier in the RXSWIN mapping table, the Indicates that the RXSWIN on the vehicle side has been tampered with.
  • the OTA cloud can issue an instruction to update the RXSWIN logo on the vehicle side to ensure the consistency between the RXSWIN logo on the vehicle side and the RXSWIN mapping table saved in the OTA cloud.
  • the OTA cloud can perform software upgrade based on the consistency judgment of the software version information between the vehicle and the cloud in the steps shown in S704; it can be based on the consistency judgment of the vehicle and the cloud RXSWIN in the steps shown in S705.
  • Software upgrade; or, based on the steps shown in S704 and S705 it can be judged whether to perform software upgrade according to the consistency of the software version information of the vehicle terminal and the cloud, and the consistency of RXSWIN, respectively.
  • Method 2 Use the vehicle terminal to verify the consistency of the first software version information and the second software version information.
  • FIG. 8 is a schematic flowchart of a vehicle-end maintenance identification code and software version information consistency provided by an embodiment of the present application.
  • the cloud is the OTA cloud
  • the vehicle end includes the main control node, ECU1 and ECU2
  • the identification code is RXSWIN
  • the first mapping is RXSWIN mapping (including the relationship between RXSWIN and software version information) as an example
  • the vehicle end verifies the consistency of the first software version information and the second software version information according to the first information and the second information.
  • This example does not constitute a limitation to the embodiments of the present application.
  • the process of maintaining the consistency between the identification code and the software version information at the vehicle end may include the following steps:
  • the OTA cloud sends the RXSWIN and RXSWIN mapping table to the master node.
  • the master control node receives the RXSWIN and RXSWIN mapping table issued by the OTA cloud.
  • the OTA cloud can send the changed RXSWIN mapping table to the master node.
  • the master control node collects software version information on each ECU (including ECU1 and ECU2).
  • the main control node checks the consistency of RXSWIN related software version information.
  • the master control node determines that the software version information related to the RXSWIN is inconsistent, it can alert the OTA cloud and report the inconsistent software version information.
  • the master control node determines that in the step shown in S802, the software version information reported by each ECU is inconsistent with the software version information in the RXSWIN mapping table issued by the OTA cloud in the step, it can indicate that the vehicle end is different from the software version information. Access-related software has been modified illegally. At this time, the master node can report inconsistent messages to the OTA cloud.
  • the cloud or the vehicle terminal is used to verify the consistency of the first software version information and the second software version information, and then the consistency of the software version and RXSWIN in the vehicle terminal and/or the cloud can be maintained to prevent the software version and/or RXSWIN is tampered with to ensure that the car software upgraded through OTA can be upgraded normally.
  • possible implementations further include:
  • the first vehicle when the first software version information is inconsistent with the second software version information, the first vehicle sends the first software version information, the first software version information, the first software version information to the cloud and/or the display device of the first vehicle Identification code and/or alarm information.
  • the display device may receive the first software version information, the first identification code and/or the warning information from the first vehicle.
  • the vehicle end described in the embodiments of the present application may include the first vehicle.
  • the warning information is used to indicate that the identification code and/or software version information of the vehicle is inconsistent with the mapping relationship of the server.
  • the display device may be a central control display screen of the first vehicle, a dashboard display screen of the first vehicle, or other display devices connected to the vehicle, such as a mobile phone.
  • the display device may include other content according to the actual scene, which is not limited in the embodiment of the present application.
  • the display device displays the alarm information.
  • FIG. 9 is a schematic diagram of an interface for displaying alarm information according to an embodiment of the present application.
  • the interface may be the interface displayed by the central control display screen 900 of the first vehicle.
  • the interface displayed by the central control display screen 900 may include an instruction message 901 for software version update, a system prompt message 902, Stop control 903, and continue control 904 and so on.
  • the instruction message 901 displays "Power steering software V2.0 (R79 90) is being updated".
  • V2.0 may be the software version information of the power steering software
  • R79 90 may be the identification code corresponding to the software version of the power steering software.
  • the first vehicle Before performing the software update, when the first vehicle detects that the first software version information is inconsistent with the second software version information, it can send warning information to the central control display screen 900 , and the warning information can be displayed on the central control display screen 900
  • the system prompt message 902. the system prompt message 902 shows, "The vehicle software may be illegally tampered with, please deal with it in time!"
  • the user can trigger the stop control 903 to suspend the software update; or, drive the vehicle to the 4S shop for processing.
  • the alarm information used in the system to indicate that the software version information is inconsistent with the identification code can be intuitively displayed to the user through the user interface, which is convenient for the user to carry out follow-up processing in a timely manner, and further ensures the normal upgrade of the automobile software.
  • S602 may include:
  • the first software version information is inconsistent with the second software version information, and/or the first identification code is inconsistent with the second identification code, it is determined that the first software version information is inconsistent with the second software version information.
  • the first software version information is inconsistent with the second software version information
  • the first identification code is inconsistent with the second identification code
  • the first software version information is inconsistent with the second software version information and the first identification code is inconsistent with the second software version information.
  • the identification codes are inconsistent, it is determined that the first software version information is inconsistent with the second software version information.
  • first software version information is inconsistent with the second software version information
  • first identification code and the second identification code may be consistent, or the first identification code and the second identification code may be inconsistent
  • first identification code If it is inconsistent with the second identification code, it can be understood that at this time, the first software version information and the second software version information may be consistent, or the first software version information and the second software version information may be inconsistent.
  • the first software version information and the second software version information are determined when the first software version information is consistent with the second software version information, and/or the first identification code is consistent with the second identification code Consistent.
  • the first software version information is consistent with the second software version information
  • the first identification code is consistent with the second identification code
  • the first software version information is consistent with the second software version information and the first identification code is consistent with the second software version information.
  • the identification codes are consistent, it is determined that the first software version information is consistent with the second software version information.
  • the first task is delivered by the cloud
  • the first software version information and/or the first identification code are consistent with the first mapping
  • the consistency check it is possible to further ensure that the car that has been upgraded through OTA
  • the software is upgraded normally; in the scenario where the cloud and/or the vehicle terminal regularly checks the consistency between the identification code and the software version information, the first software version information and/or the first identification code can be inconsistent with the first mapping.
  • a possible implementation manner further includes: updating the first software version information and/or the first identification code when the first software version information is inconsistent with the second software version information ; or, when the first software version information is consistent with the second software version information, update the first software version information and/or the first identification code.
  • the scenario in which the first software version information is inconsistent with the second software version information may be that due to the tampering of the first software version information and/or the first identification code at the vehicle end, the first software version information at the vehicle end is different from the first software version information.
  • the second software version information on the cloud is inconsistent.
  • the cloud can deliver the software version information and/or identification code stored by itself to the vehicle to ensure the consistency of the software version information and identification code between the cloud and the vehicle.
  • the software version information and/or identification code delivered by the cloud may be consistent with the software version information and/or identification code saved before the vehicle end was tampered with.
  • the process of updating the first software version information and/or the first identification code may not be performed.
  • the process of updating the first software version information and/or the first identification code based on the inconsistency may be the embodiments corresponding to FIG. 7 and FIG. 8 , and details are not described herein again.
  • the scenario where the first software version information is consistent with the second software version information may be that the first task (or update task) is issued by the cloud, and when the cloud determines the first software version information reported by the vehicle end And/or the first identification code is consistent with the second software version information stored in the cloud, and then the cloud can deliver the software version information and/or identification code carried in the first task to the vehicle based on the consistency guarantee.
  • the process of updating the first software version information and/or the first identification code may not be performed.
  • FIG. 10 is a schematic flowchart of a cloud performing consistency judgment according to an embodiment of the present application.
  • the vehicle end including the master control node, the first mapping being the RXSWIN mapping, and the identification code being RXSWIN as an example, between the first software version information and the second software version information If they are consistent, update the first software version information and/or the first identification code for description, and this example does not constitute a limitation on the embodiments of the present application.
  • the process of cloud consistency judgment may include:
  • the OTA cloud collects the RXSWIN logo on the master control node.
  • the OTA cloud may determine not to perform OTA.
  • the OTA cloud can issue an update task to the master control node, and the update task can carry the new RXSWIN identifier and the RXSWIN mapping table.
  • the master control node saves the new RXSWIN identifier and the RXSWIN mapping table.
  • the cloud and the car end can maintain the consistency of the software version information and/or identification code on the car end, and the mapping relationship with the cloud, thereby eliminating the software version and access through OTA upgrade. If there are inconsistencies in the software version at the time, the normal upgrade of the car software is guaranteed.
  • the above is the process of maintaining the consistency of the software version information and the identification code at the vehicle end and/or the cloud.
  • the following describes the process of ensuring the consistency of the software version information and the identification code in the process of OTA upgrading the car software.
  • FIG. 11 is a schematic flowchart of updating software according to an embodiment of the present application.
  • the subject of updating the software may include the cloud and the first vehicle.
  • the first vehicle may include a master control node and one or more ECUs.
  • the process of updating software may include the following steps:
  • the cloud sends a first task to a first vehicle.
  • the first vehicle receives the first task, and can update the first software version information and/or the first identification code according to the first task.
  • the subject receiving the first task may be a master control node in the first vehicle.
  • the first task is used to instruct to update the first software version information and/or the first identification code; in the case that the first software version information is inconsistent with the second software version information, the first task includes the first mapping
  • the first task includes the second mapping
  • the second mapping includes the association relationship between the third software version information and the third identification code
  • the third software version information is different For the second software version information, and/or, the third identification code is different from the second identification code.
  • the cloud may send the first task including the first mapping.
  • the first mapping may be understood as the association between the software version information and the identification code stored in the cloud before the software version and/or the identification code of the first vehicle is tampered with.
  • the cloud when the cloud determines that the first software version information of the first vehicle is consistent with the second software version information of the cloud, it can be understood that the first vehicle device and the cloud have passed through at this time, and the consistency judgment before the OTA software upgrade is performed. , at this time, the cloud can send the first task including the second mapping.
  • the second mapping can be understood as a mapping relationship triggered by the OTA including the new software version information and the new identification code.
  • the third identification code in the second mapping may be consistent with the first identification code saved by the first vehicle.
  • the battery management system of the first vehicle is V1.0, the system can support a cruising range of 500km; when the battery management system is upgraded through OTA, the battery management system of the first vehicle is updated to V1.1, its system can support a cruising range of 500km; at this time, due to the update of the battery management system, the specific parameters of the sustainable mileage have not been changed.
  • the third software version information in the second map delivered by the cloud is inconsistent with the first software version information saved by the first vehicle, and the third identification code in the second map is inconsistent. It may be consistent with the first identification code saved by the first vehicle.
  • the cloud sends the first software package to the first vehicle.
  • the first vehicle may receive the first software package and update the software of the vehicle in accordance with the first software package.
  • the software package may include software and software version information corresponding to the software.
  • the first software package in the case that the first software version information is inconsistent with the second software version information, the first software package includes the second identification code; or, in the case that the first software version information is consistent with the second software version information Next, the first software package includes a third identification code.
  • the cloud determines that the first software version information of the first vehicle is inconsistent with the second software version information of the cloud, it can be understood that the software version or the identification code of the first vehicle may have been tampered with, and the cloud
  • the first software package containing the second identification code can be sent.
  • the first software package may be understood as a software package stored in the cloud before the software version or identification code of the first vehicle is tampered with.
  • the software package stored in the cloud can store the software version of the first vehicle or the software and the identification code before the identification code is tampered with.
  • the cloud determines that the first software version information of the first vehicle is consistent with the second software version information of the cloud, it can be understood that the first vehicle device and the cloud have passed through at this time, and the consistency before the OTA software upgrade is performed. It is judged that the cloud can send the first software package including the third identification code at this time.
  • the first software package can be understood as a software package triggered by OTA.
  • the third identification code may be consistent with the first identification code, and the specific process thereof will not be repeated.
  • S1103 The first vehicle sends the first software package corresponding to each ECU to the ECU.
  • each ECU receives the first software package.
  • the number of ECUs may be one or more.
  • the first vehicle may send the first software package corresponding to each ECU to the N ECUs; N is a positive integer.
  • the master control node may receive the first software package sent by the cloud, and distribute the first software package to the corresponding ECU.
  • the ECU installs the first software package and updates the identification code.
  • the identification code may be a second identification code or a third identification code.
  • the ECU can roll back to the software before the installation and restore the first identification code.
  • the ECU rolls back to the software before installation, which may indicate that the ECU restores the first software version information.
  • the ECU when the ECU successfully installs the first software package, the ECU may update the first identification code and the first software version information.
  • the ECU sends the installation result to the first vehicle.
  • the first vehicle receives the installation result.
  • the installation result may be that the installation is successful, or the installation of any one or more ECUs fails.
  • the vehicle version and/or identification code may be updated.
  • the software installation result is that the installation is successful and the updated software is not enough to change the entire vehicle version, the entire vehicle version may not be changed.
  • the matching relationship between the software version information and the identification code can be guaranteed in the process of OTA software upgrade, and based on the consistency between the software version and the identification code in the vehicle and/or the cloud, the software version and the standard code upgraded through OTA can be eliminated. If there are inconsistencies in the software version in the current period, the normal upgrade of the car software is guaranteed.
  • the process may include: the cloud delivers the software package to the vehicle (the embodiment corresponding to FIG. 12 ), the vehicle successfully installs the software package (the embodiment corresponding to FIG. 13 ), and the vehicle fails to install the software package ( Figure 14 corresponds to the embodiment).
  • FIG. 12 is a schematic flowchart of a cloud delivering a software package to a vehicle according to an embodiment of the present application.
  • the cloud is the OTA cloud
  • the vehicle terminal includes the main control node, ECU1 and ECU2
  • the identification code is RXSWIN
  • the first mapping is RXSWIN mapping as an example, for the cloud to deliver the software package to the vehicle terminal.
  • the process is described, and this example does not constitute a limitation to the embodiments of the present application.
  • the process of delivering software packages from the cloud may include the following steps:
  • the OTA cloud delivers a software package to the master control node.
  • the master control node receives the software package delivered by the OTA cloud.
  • the software package carries the relevant RXSWIN identifier.
  • the master control node distributes the software package to ECU1 and ECU2.
  • the ECU1 and ECU2 receive the software package sent by the master control node.
  • the ECU1 and ECU2 may be ECUs corresponding to the software package.
  • S1203, ECU1 and ECU2 receive the software package and record the RXSWIN identifier.
  • the matching relationship between the software version information and the identification code can be guaranteed in the process of OTA software upgrade, and then based on the consistency of the software version and the identification code on the vehicle end and/or the cloud, the software version and access through OTA upgrade can be eliminated. If there are inconsistencies in the software version at the time, the normal upgrade of the car software is guaranteed.
  • the above is the process for the cloud to deliver the software package to the vehicle.
  • the following describes the process of installing the software package on the vehicle and the installation is successful.
  • FIG. 13 is a schematic flowchart of a vehicle-end installation software package provided by an embodiment of the present application.
  • the vehicle end includes the main control node, ECU1 and ECU2, the identification code is RXSWIN, and the first mapping is RXSWIN mapping as an example, the process of successfully installing the software package at the vehicle end is carried out. It should be noted that this example does not constitute a limitation to the embodiments of the present application.
  • the process of ECU installing software package can include the following steps:
  • ECU1 and ECU2 can install software based on the software package.
  • ECU1 and ECU2 send the installation result to the master node.
  • the master control node updates the vehicle version and/or updates the RXSWIN.
  • the vehicle version may not be changed, and will not be repeated here.
  • the matching relationship between the software version information and the identification code can be guaranteed in the process of OTA software upgrade, and based on the consistency between the software version and the identification code in the vehicle and/or the cloud, the software version and the standard code upgraded through OTA can be eliminated. If there are inconsistencies in the software version in the current period, the normal upgrade of the car software is guaranteed.
  • the installation software package at the vehicle end may be abnormal.
  • FIG. 14 is a schematic flowchart of another vehicle-end installation software package provided by an embodiment of the present application.
  • the vehicle end includes the main control node, ECU1 and ECU2, the identification code is RXSWIN, and the first mapping is the RXSWIN mapping as an example, the process of installing the software package at the vehicle end fails. It should be noted that this example does not constitute a limitation to the embodiments of the present application.
  • the process of ECU installing software package can include the following steps:
  • S1401, ECU1 and ECU2 install software and update related RXSWIN.
  • the ECU1 and ECU2 store the software before installing the software package.
  • ECU1 and ECU2 can roll back to the software before the software package is installed.
  • the ECU1 and ECU2 save the RXSWIN before installing the software package.
  • ECU1 and ECU2 can roll back to the RXSWIN before the software package is installed.
  • ECU1 and ECU2 notify the master node of the abnormality.
  • the matching relationship between the software version information and the identification code can be guaranteed in the process of OTA software upgrade, and based on the consistency between the software version and the identification code in the vehicle and/or the cloud, the software version and the standard code upgraded through OTA can be eliminated. If there are inconsistencies in the software version in the current period, the normal upgrade of the car software is guaranteed.
  • FIG. 15 is a schematic structural diagram of an OTA-based communication device provided by an embodiment of the application.
  • the OTA-based communication device 150 may be used in a communication device, circuit, hardware component, or chip,
  • the OTA-based communication device includes: a display unit 1501 , a processing unit 1502 and a communication unit 1503 .
  • the display unit 1501 is used to support the steps of display performed by the distribution network method;
  • the processing unit 1502 is used to support the OTA-based communication device to perform the information processing steps;
  • the communication unit 1503 is used to support the OTA-based communication device to perform data transmission or reception. A step of.
  • an embodiment of the present application provides an OTA-based communication device, the communication unit 1503 is configured to obtain first information and second information; the first information includes first software version information and/or a first identification code; the second The information includes a first mapping; the first mapping includes the association relationship between the second software version information and the second identification code; the identification code is used to indicate the authority information of the software version; the processing unit 1502 is also used for according to the first information and the second information. , and verify the consistency of the first software version information and the second software version information.
  • the processing unit 1502 is specifically configured to: determine the first software version when the first software version information is inconsistent with the second software version information, and/or when the first identification code is inconsistent with the second identification code.
  • the version information is inconsistent with the second software version information; or, when the first software version information is consistent with the second software version information, and/or the first identification code is consistent with the second identification code, determine the first software version information It is consistent with the second software version information.
  • the processing unit 1502 is further configured to: update the first software version information and/or the first identification code when the first software version information is inconsistent with the second software version information; If the software version information is consistent with the second software version information, the first software version information and/or the first identification code are updated.
  • the communication unit 1503 is configured to: send the first task to the first vehicle; the first task is used to instruct to update the first software version information and/or the first identification code; wherein, in the first software version information In the case of inconsistency with the second software version information, the first task includes the first mapping; in the case that the first software version information is consistent with the second software version information, the first task includes the second mapping; the second mapping includes the third mapping. The relationship between the software version information and the third identification code.
  • the communication unit 1503 is further configured to: send the first software package to the first vehicle; the first software package is used to update the software version information corresponding to the first vehicle; wherein, between the first software version information and the first software version When the two software version information are inconsistent, the first software package includes the second identification code; or, when the first software version information is consistent with the second software version information, the first software package includes a third identification code.
  • the communication unit 1503 is further configured to: send the first software version information, the first software version information, the first software version information to the server and/or the display device of the first vehicle when the first software version information is inconsistent with the second software version information An identification code and/or alarm information; the alarm information is used to indicate that the identification code and/or software version information of the vehicle is inconsistent with the mapping relationship of the server.
  • the communication unit 1503 is specifically configured to receive a first task from the server, where the first task is used to instruct to update the first software version information and/or the first identification code; If the second software version information is inconsistent, the first task includes the first mapping; or, in the case that the first software version information is consistent with the second software version information, the first task includes the second mapping; the second mapping includes the first mapping. 3. The association relationship between the software version information and the third identification code.
  • the communication unit 1503 is further configured to: receive the first software package from the server; the first software package is used to update the software version information corresponding to the first vehicle; wherein, between the first software version information and the second software version When the software version information is inconsistent, the first software package includes the second identification code; or, when the first software version information is consistent with the second software version information, the first software package includes a third identification code.
  • the identification code includes the first regulation-related software identification code RXSWIN.
  • the OTA-based communication device may further include: a storage unit 1504 .
  • the processing unit 1502 and the storage unit 1504 are connected through a line.
  • the storage unit 1504 may include one or more memories, which may be devices in one or more devices or circuits for storing programs or data.
  • the storage unit 1504 may exist independently, and is connected to the processing unit 1502 of the OTA-based communication device through a communication line.
  • the storage unit 1504 may also be integrated with the processing unit 1502.
  • the communication unit 1503 may be an input or output interface, a pin or a circuit, or the like.
  • the storage unit 1504 may store computer-implemented instructions for the radar or target device method, so that the processing unit 1502 executes the radar or target device method in the above embodiments.
  • the storage unit 1504 may be a register, a cache or a RAM, etc., and the storage unit 1504 may be integrated with the processing unit 1502 .
  • the storage unit 1504 may be a ROM or other type of static storage device that may store static information and instructions, and the storage unit 1504 may be separate from the processing unit 1502 .
  • FIG. 16 is a schematic diagram of the hardware structure of a control device provided by an embodiment of the application.
  • the control device includes a processor 1601, a communication line 1604, and at least one communication interface (in FIG. 1603 as an example to illustrate).
  • the processor 1601 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more processors for controlling the execution of programs in the present application. integrated circuit.
  • CPU central processing unit
  • ASIC application-specific integrated circuit
  • Communication lines 1604 may include circuitry to communicate information between the components described above.
  • the communication interface 1603 using any device such as a transceiver, is used to communicate with other devices or communication networks, such as Ethernet, wireless local area networks (WLAN) and the like.
  • devices or communication networks such as Ethernet, wireless local area networks (WLAN) and the like.
  • control device may also include a memory 1602 .
  • Memory 1602 may be read-only memory (ROM) or other type of static storage device that can store static information and instructions, random access memory (RAM), or other type of static storage device that can store information and instructions It can also be an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disk storage, CD-ROM storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or capable of carrying or storing desired program code in the form of instructions or data structures and capable of being executed by a computer Access any other medium without limitation.
  • the memory may exist independently and be connected to the processor through communication line 1604 .
  • the memory can also be integrated with the processor.
  • the memory 1602 is used for storing computer-executed instructions for executing the solution of the present application, and the execution is controlled by the processor 1601 .
  • the processor 1601 is configured to execute the computer-executed instructions stored in the memory 1602, thereby implementing the OTA-based communication method provided by the embodiments of the present application.
  • the computer-executed instructions in the embodiments of the present application may also be referred to as application code, which is not specifically limited in the embodiments of the present application.
  • the processor 1601 may include one or more CPUs, such as CPU0 and CPU1 in FIG. 16 .
  • control device may include multiple processors, such as the processor 1601 and the processor 1605 in FIG. 16 .
  • processors can be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor.
  • a processor herein may refer to one or more devices, circuits, and/or processing cores for processing data (eg, computer program instructions).
  • FIG. 17 is a schematic structural diagram of a chip provided by an embodiment of the present application.
  • the chip 170 includes one or more (including two) processors 1720 and a communication interface 1730 .
  • the memory 1740 stores the following elements: executable modules or data structures, or a subset thereof, or an extension set thereof.
  • the memory 1740 may include a read-only memory and a random access memory, and provides instructions and data to the processor 1720 .
  • a portion of memory 1740 may also include non-volatile random access memory (NVRAM).
  • NVRAM non-volatile random access memory
  • the memory 1740 , the communication interface 1730 , and the memory 1740 are coupled together through the bus system 2020 .
  • the bus system 2020 may also include a power bus, a control bus, a status signal bus, and the like, in addition to a data bus.
  • various buses are designated as bus system 2020 in FIG. 17 .
  • the methods described in the foregoing embodiments of the present application may be applied to the processor 1720 or implemented by the processor 1720 .
  • the processor 1720 may be an integrated circuit chip with signal processing capability.
  • each step of the above-mentioned method can be completed by an integrated logic circuit of hardware in the processor 1720 or an instruction in the form of software.
  • the above-mentioned processor 1720 can be a general-purpose processor (for example, a microprocessor or a conventional processor), a digital signal processor (digital signal processing, DSP), an application specific integrated circuit (ASIC), an off-the-shelf programmable gate Array (field-programmable gate array, FPGA) or other programmable logic devices, discrete gates, transistor logic devices or discrete hardware components, the processor 1720 can implement or execute the methods, steps and logic block diagrams disclosed in the embodiments of the present invention .
  • a general-purpose processor for example, a microprocessor or a conventional processor
  • DSP digital signal processing
  • ASIC application specific integrated circuit
  • FPGA field-programmable gate array
  • the steps of the method disclosed in conjunction with the embodiments of the present application may be directly embodied as executed by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor.
  • the software module may be located in a storage medium that is mature in the field, such as random access memory, read-only memory, programmable read-only memory, or electrically erasable programmable read only memory (EEPROM).
  • the storage medium is located in the memory 1740, and the processor 1720 reads the information in the memory 1740, and completes the steps of the above method in combination with its hardware.
  • the instructions stored by the memory for execution by the processor may be implemented in the form of a computer program product.
  • the computer program product may be written in the memory in advance, or downloaded and installed in the memory in the form of software.
  • a computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the procedures or functions according to the embodiments of the present application are generated in whole or in part.
  • the computer may be a general purpose computer, special purpose computer, computer network, or other programmable device.
  • Computer instructions may be stored in or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from a website site, computer, server, or data center over a wire (e.g. Coaxial cable, optical fiber, digital subscriber line (DSL) or wireless (eg infrared, wireless, microwave, etc.) means to transmit to another website site, computer, server or data center.
  • a wire e.g. Coaxial cable, optical fiber, digital subscriber line (DSL) or wireless (eg infrared, wireless, microwave, etc.
  • the computer readable storage medium may be Any available medium on which a computer can store or data storage device including a server, data center, etc., integrated with one or more available media.
  • available media may include magnetic media (eg, floppy disks, hard disks, or tapes), optical media (eg, Digital versatile disc (digital versatile disc, DVD)), or semiconductor media (for example, solid state disk (solid state disk, SSD)), etc.
  • Embodiments of the present application also provide a computer-readable storage medium.
  • the methods described in the above embodiments may be implemented in whole or in part by software, hardware, firmware or any combination thereof.
  • Computer-readable media can include both computer storage media and communication media and also include any medium that can transfer a computer program from one place to another.
  • the storage medium can be any target medium that can be accessed by a computer.
  • the computer readable medium may include compact disc read-only memory (CD-ROM), RAM, ROM, EEPROM or other optical disk storage; the computer readable medium may include magnetic disks memory or other disk storage devices.
  • any connection line is properly termed a computer-readable medium.
  • Disk and disc includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and blu-ray disc, where disks usually reproduce data magnetically, while discs use lasers to optically reproduce data.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Stored Programmes (AREA)

Abstract

本申请实施例提供一种基于空中下载技术OTA的通信方法和装置，涉及通信技术领域，包括：获得第一信息和第二信息；第一信息包括第一软件版本信息和/或第一标识码；第二信息包括第一映射；第一映射包含第二软件版本信息和第二标识码的关联关系；标识码用于指示软件版本的权限信息；根据第一信息和第二信息，验证第一软件版本信息与第一映射对应的第二软件版本信息的一致性。这样，可以实现在OTA的维护以及安装软件的过程中，保证汽车软件的正常升级，进而维护车辆的安全性。

Description

基于空中下载技术OTA的通信方法和装置 技术领域
本申请涉及通信技术领域，尤其涉及一种基于空中下载技术OTA的通信方法和装置。
背景技术
随着自动驾驶的发展，人们对于汽车的计算和控制能力要求越来越高。越来越多的功能以软件的形式提供给用户，因此软件定义汽车正在成为汽车发展的重要趋势。当汽车中的软件需要安装或更新时，可以利用空中下载技术(over the air technology，OTA)，借助OTA联网到云端安装或更新汽车中的软件。
然而OTA给人们带来便利的同时，也给汽车的准入带来了挑战。其中，准入可以理解为在汽车上市前，经历的一系列安全或排放等的相关测试，以满足相关标准的要求的过程。具体的，利用OTA更新汽车软件，可能会使得上市之后的汽车的准入参数发生改变。例如，通过OTA升级汽车的电池管理软件后，可能会使得汽车的续航里程提高，使其与准入时测量的续航里程不一致，进而可能出现汽车准入时测试的数据无效，需要重新测试的情况。因此，通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，对OTA的发展带来了一定的挑战。
发明内容
本申请实施例提供一种基于空中下载技术OTA的通信方法和装置，可以实现在OTA的维护以及安装软件的过程中，保证汽车软件的正常升级，进而维护车辆的安全性。
第一方面，本申请实施例提供一种基于OTA的通信方法，包括：获得第一信息和第二信息；第一信息包括第一软件版本信息和/或第一标识码；第二信息包括第一映射；第一映射包含第二软件版本信息和第二标识码的关联关系；标识码用于指示软件版本的权限信息；根据第一信息和第二信息，验证第一软件版本信息与第一映射对应的第二软件版本信息的一致性。
这样，可以利用第一信息和第二信息中的标识码与软件版本的匹配关系，验证第一信息与第二信息的一致性，实现在OTA的维护以及安装软件的过程中，通过维护车端和/或服务器(或称云端或云端设备)中，软件版本与标识码的一致性，进而保证汽车软件的正常升级，维护车辆的安全性。
结合第一方面，在一种可能的实现方式中，根据第一信息和第二信息，验证第一软件版本信息与第一映射对应的第二软件版本信息的一致性，包括：在第一软件版本信息与第二软件版本信息不一致，和/或，第一标识码与第二标识码不一致的情况下，确定第一软件版本信息与第二软件版本信息不一致；或者，在第一软件版本信息与第二软件版本信息一致，和/或，第一标识码与第二标识码一致的情况下，确定第一软件版本信息与第二软件版本信息一致。
这样，可以利用云端或车端验证第一软件版本信息与第二软件版本信息的一致性，进 而可以通过维护车端和/或云端中，软件版本与标识码的一致性，防止软件版本和/或标识码被篡改，保证通过OTA升级的汽车软件正常升级。
结合第一方面，在一种可能的实现方式中，方法还包括：在第一软件版本信息与第二软件版本信息不一致的情况下，更新第一软件版本信息和/或第一标识码；或者，在第一软件版本信息与第二软件版本信息一致的情况下，更新第一软件版本信息和/或第一标识码。
这样，云端和车端可以基于标识码与软件版本的匹配关系，维护车端的软件版本信息和/或标识码，与云端设备的映射关系的一致性，消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。
结合第一方面，在一种可能的实现方式中，在更新第一软件版本和/或第一标识码之前，方法还包括：向第一车辆发送第一任务；第一任务用于指示更新第一软件版本信息和/或第一标识码；其中，在第一软件版本信息与第二软件版本信息不一致的情况下，第一任务包括第一映射；或，在第一软件版本信息与第二软件版本信息一致的情况下，第一任务包括第二映射；第二映射包含第三软件版本信息和第三标识码的关联关系；第三软件版本信息不同于第二软件版本信息，和/或，第三标识码不同于第二标识码。
这样，可以在OTA升级软件的过程中保证软件版本信息和标识码的匹配关系，进而基于车端和/或云端中，软件版本与标识码的一致性，消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。
结合第一方面，在一种可能的实现方式中，方法还包括：向第一车辆发送第一软件包；第一软件包用于更新第一车辆对应的软件版本信息；其中，在第一软件版本信息与第二软件版本信息不一致的情况下，第一软件包包括第二标识码；或，在第一软件版本信息与第二软件版本信息一致的情况下，第一软件包包括第三标识码。
这样，可以在OTA升级软件的过程中保证软件版本信息和标识码的匹配关系，进而基于车端和/或云端中，软件版本与标识码的一致性，消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。
结合第一方面，在一种可能的实现方式中，还包括：在第一软件版本信息与第二软件版本信息不一致的情况下，向服务器和/或第一车辆的显示设备发送第一软件版本信息、第一标识码和/或告警信息；告警信息用于指示第一车辆的标识码和/或软件版本信息与服务器的映射关系不一致。
这样，可以使得云端设备和/或第一车辆的显示设备可以基于车端发送的告警信息进行及时处理，进一步保障汽车软件的正常升级。
结合第一方面，在一种可能的实现方式中，更新第一软件版本信息和/或第一标识码，包括：接收来自服务器的第一任务，第一任务用于指示更新第一软件版本信息和/或第一标识码；其中，在第一软件版本信息与第二软件版本信息不一致的情况下，第一任务包括第一映射；或，在第一软件版本信息与第二软件版本信息一致的情况下，第一任务包括第二映射；第二映射包含第三软件版本信息和第三标识码的关联关系；第三软件版本信息不同于第二软件版本信息，和/或，第三标识码不同于第二标识码。
这样，可以在OTA升级软件的过程中保证软件版本信息和标识码的匹配关系，进而基于车端和/或云端中，软件版本与标识码的一致性，消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。
结合第一方面，在一种可能的实现方式中，还包括：接收来自服务器的第一软件包；第一软件包用于更新第一车辆对应的软件版本信息；其中，在第一软件版本信息与第二软件版本信息不一致的情况下，第一软件包包括第二标识码；或，在第一软件版本信息与第二软件版本信息一致的情况下，第一软件包包括第三标识码。
这样，可以在OTA升级软件的过程中保证软件版本信息和标识码的匹配关系，进而基于车端和/或云端中，软件版本与标识码的一致性，消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。
结合第一方面，在一种可能的实现方式中，第一车辆中包括多个与第一软件包相关的电子控制单元，根据第一软件包更新第一车辆中的软件，包括：向N个电子控制单元发送各电子控制单元对应的第一软件包；N为正整数；接收来自N个电子控制单元的N个软件安装结果；在N个软件安装结果为任意一个或多个安装失败的情况下，回滚第一车辆的整车软件版本和标识码。
这样，可以在OTA升级软件的过程中保证软件版本信息和标识码的匹配关系，进而基于车端和/或云端中，软件版本与标识码的一致性，消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。
结合第一方面，在一种可能的实现方式中，接收来自第一车辆的告警信息；显示告警信息。
结合第一方面，在一种可能的实现方式中，标识码包括第一法规相关软件识别码RXSWIN。这样，可以利用RXSWIN与软件版本的匹配关系，在OTA的维护以及安装软件的过程中，保证RXSWIN与软件版本的一致性，保证汽车软件的正常升级。
这样，可以将系统内部用于指示软件版本信息与标识码不一致的告警信息，通过用户界面直观的显示给用户，方便用户及时进行后续处理，进一步保障汽车软件的正常升级。
第二方面，本申请实施例提供一种基于OTA的通信装置，通信单元，用于获得第一信息和第二信息；第一信息包括第一软件版本信息和/或第一标识码；第二信息包括第一映射；第一映射包含第二软件版本信息和第二标识码的关联关系；标识码用于指示软件版本的权限信息；处理单元，还用于根据第一信息和第二信息，验证第一软件版本信息与第一映射对应的第二软件版本信息的一致性。
结合第二方面，在一种可能的实现方式中，处理单元，具体用于：在第一软件版本信息与第二软件版本信息不一致，和/或，第一标识码与第二标识码不一致的情况下，确定第一软件版本信息与第二软件版本信息不一致；或者，在第一软件版本信息与第二软件版本信息一致，和/或，第一标识码与第二标识码一致的情况下，确定第一软件版本信息与第二软件版本信息一致。
结合第二方面，在一种可能的实现方式中，处理单元，还用于：在第一软件版本信息与第二软件版本信息不一致的情况下，更新第一软件版本信息和/或第一标识码；或者，在第一软件版本信息与第二软件版本信息一致的情况下，更新第一软件版本信息和/或第一标识码。
结合第二方面，在一种可能的实现方式中，通信单元，具体用于：向第一车辆发送第一任务；第一任务用于指示更新第一软件版本信息和/或第一标识码；其中，在第一软件版本信息与第二软件版本信息不一致的情况下，第一任务包括第一映射；在第一软件版本信 息与第二软件版本信息一致的情况下，第一任务包括第二映射；第二映射包含第三软件版本信息和第三标识码的关联关系；第三软件版本信息不同于第二软件版本信息，和/或，第三标识码不同于第二标识码。
结合第二方面，在一种可能的实现方式中，通信单元，还用于：向第一车辆发送第一软件包；第一软件包用于更新第一车辆对应的软件版本信息；其中，在第一软件版本信息与第二软件版本信息不一致的情况下，第一软件包包括第二标识码；或，在第一软件版本信息与第二软件版本信息一致的情况下，第一软件包包括第三标识码。
结合第二方面，在一种可能的实现方式中，通信单元，还用于：在第一软件版本信息与第二软件版本信息不一致的情况下，向服务器和/或第一车辆的显示设备发送第一软件版本信息、第一标识码和/或告警信息；告警信息用于指示车辆的标识码和/或软件版本信息与服务器的映射关系不一致。
结合第二方面，在一种可能的实现方式中，通信单元，具体用于：接收来自服务器的第一任务，第一任务用于指示更新第一软件版本信息和/或第一标识码；其中，在第一软件版本信息与第二软件版本信息不一致的情况下，第一任务包括第一映射；或，在第一软件版本信息与第二软件版本信息一致的情况下，第一任务包括第二映射；第三软件版本信息不同于第二软件版本信息，和/或，第三标识码不同于第二标识码。
结合第二方面，在一种可能的实现方式中，通信单元，还用于：接收来自服务器的第一软件包；第一软件包用于更新第一车辆对应的软件版本信息；其中，在第一软件版本信息与第二软件版本信息不一致的情况下，第一软件包包括第二标识码；或，在第一软件版本信息与第二软件版本信息一致的情况下，第一软件包包括第三标识码。
结合第二方面，在一种可能的实现方式中，通信单元，具体用于向N个电子控制单元发送各电子控制单元对应的第一软件包；N为正整数；通信单元，具体用于接收来自N个电子控制单元的N个软件安装结果；处理单元，具体用于在N个软件安装结果为任意一个或多个安装失败的情况下，回滚第一车辆的整车软件版本和标识码。
可能的实现方式中，通信单元，具体用于接收来自第一车辆的告警信息；显示单元，具体用于显示告警信息。
结合第二方面，在一种可能的实现方式中，标识码包括第一法规相关软件识别码RXSWIN。
第三方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序或指令，当计算机程序或指令在计算机上运行时，使得计算机执行如第一方面以及第一方面中的任意一种可能的实现方式中描述的基于OTA的通信方法。
第四方面，本申请实施例提供一种基于OTA的通信装置，该装置包括处理器和存储器，存储器存储有指令，指令被处理器运行时，实现如第一方面以及第一方面中的任意一种可能的实现方式描述的基于OTA的通信方法。
第五方面，本申请提供一种芯片或者芯片系统，该芯片或者芯片系统包括至少一个处理器和通信接口，通信接口和至少一个处理器通过线路互联，至少一个处理器用于运行计算机程序或指令，以实现第一方面以及第一方面的任意一种可能的实现方式中任一项所描述的基于OTA的通信方法。其中，芯片中的通信接口可以为输入/输出 接口、管脚或电路等。
在一种可能的实现中，本申请中上述描述的芯片或者芯片系统还包括至少一个存储器，该至少一个存储器中存储有指令。该存储器可以为芯片内部的存储单元，例如，寄存器、缓存等，也可以是该芯片的存储单元(例如，只读存储器、随机存取存储器等)。
第六方面，本申请实施例提供一种计算机程序产品，当所述计算机程序产品在一个或多个处理器上运行时，实现第一方面以及第一方面中任意一种可能的实施方式所描述的方法。
应当理解的是，本申请的第二方面至第六方面与本申请的第一方面的技术方案相对应，各方面及对应的可行实施方式所取得的有益效果相似，不再赘述。
附图说明
图1为本申请实施例提供的一种RXSWIN与软件版本对应关系示意图；
图2为本申请实施例提供的第一种应用场景示意图；
图3为本申请实施例提供的一种车辆中软件更新的系统架构的示意图；
图4为本申请实施例提供的第二种应用场景示意图；
图5为本申请实施例提供的第三种应用场景示意图；
图6为本申请实施例提供的一种基于OTA的通信方法的流程示意图；
图7为本申请实施例提供的一种云端维护标识码与软件版本信息一致性的流程示意图；
图8为本申请实施例提供的一种车端维护标识码与软件版本信息一致性的流程示意图；
图9为本申请实施例提供的一种显示告警信息的界面示意图
图10为本申请实施例提供的一种云端进行一致性判断的流程示意图；
图11为本申请实施例提供的一种更新软件的流程示意图；
图12为本申请实施例提供的一种云端向车端下发软件包的流程示意图；
图13为本申请实施例提供的一种车端安装软件包的流程示意图；
图14为本申请实施例提供的另一种车端安装软件包的流程示意图；
图15为本申请实施例提供的一种基于OTA的通信装置的结构示意图；
图16为本申请实施例提供的一种控制设备的硬件结构示意图；
图17为本申请实施例提供的一种芯片的结构示意图。
具体实施方式
为了便于清楚描述本申请实施例的技术方案，在本申请的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。例如，第一标识码和第二标识码是为了区分不同的标识码，并不对其先后顺序进行限定。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。
需要说明的是，本申请中，“示例性的”或者“例如”等词用于表示作例子、例证或 说明。本申请中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b，或c中的至少一项(个)，可以表示：a，b，c，a和b，a和c，b和c，或a、b和c，其中a，b，c可以是单个，也可以是多个。
随着自动驾驶的发展，人们对汽车的计算和控制能力要求越来越高。越来越多的汽车功能通过软件的形式提供给用户，因此软件定义汽车正在成为汽车发展的重要趋势。软件定义汽车，要求汽车能够像计算机或智能手机一样，便捷的实现软件的安装和更新，使汽车的各种功能可以常用常新。通常情况下，当汽车软件需要更新时，用户可以将汽车开到4S店或维修网点，由专业技术人员通过专用设备去刷新车内的软件，进而实现汽车软件的更新。汽车OTA提供了一种远程升级汽车软件或修复汽车软件缺陷的技术手段，用户可以借助OTA技术联网到云端下载和安装软件，OTA可以减轻目前汽车软件升级对于时间和空间的限制，因此OTA在汽车领域得到了广泛的应用。
然而OTA给人们带来便利的同时，也给汽车准入带来了挑战。其中，准入可以理解为在汽车上市前，经历的一系列安全或排放等的相关测试，以满足相关标准的要求的过程。具体的，由于汽车的缺陷可能导致重大的人身和财产损失，因此汽车是一种特殊产品。在汽车上市前，需要经历准入测试，当通过准入，汽车才可以允许进入市场。当汽车产品申请并通过准入后，作为汽车的准入监管机构可以进行记录，并向社会公告该汽车的准入信息。公告后的车可以允许销售。其中，该公告中可以包括汽车轮距、重量或排量等基本信息，还可以包括如续航里程或最高车速等技术特征参数信息。
为了保证汽车在准入后的生产一致性，监管部门可以定期抽查汽车产品的相关参数，并与公告信息进行比对，如果该公告信息与准入的参数不一致，则违反了生产一致性，可以要求汽车厂家整改或要求汽车厂家执行停产等措施。
在汽车上市后，可以通过OTA更新汽车软件，然而更新过程可能改变该软件准入时的测试参数。例如，通过OTA升级汽车的电池管理软件后，可能会使得汽车的续航里程提高，使其与准入时测量的续航里程不一致，进而出现汽车准入时测试的数据无效，需要重新测试的情况。因此，通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，对OTA的发展带来了一定的挑战。基于此，联合国欧洲经济委员会(the united nations economic commission for europe，UNECE)下属的联合国世界车辆法规协调论坛建立了OTA工作组，研讨将OTA纳入到准入监管体系。其中提到汽车的OTA可能影响准入一致性的，需要在OTA升级前向准入监管机构申请准入变更。为了监管这种变更，提出法规相关软件识别码(rx software identification number，RXSWIN)。该RXSWIN可以记录软件版本与准入的关系，其作用是以准入法规的角度记录和追溯对准入有影 响的软件和软件升级，便于准入监管机构管理汽车软件升级。其中，RXSWIN的变更可以表示软件升级引起的准入的变更。
示例性的，图1为本申请实施例提供的一种RXSWIN与软件版本对应关系示意图。如图1中的a所示，准入时可以配置初始RXSWIN及其对应的软件版本，如初始RXSWIN为R79 110。其中，R79 110对应的软件版本可以包括：助力转向电子控制单元(electronic control unit，ECU)对应的软件版本为v1.0；车身稳定ECU对应的软件版本为v2.0；整车控制ECU对应的软件版本为v1.0。
当借助OTA进行软件升级后，可以升级为如图1中的b所示的，升级后的RXSWIN与软件版本的对应关系示意图。其中，由于此时经过OTA后的软件，没有对准入时该软件对应的测试数据进行改变，因此发生不影响准入的软件升级后，RXSWIN关联的软件版本信息可以变更，但RXSWIN保持不变。此时，R79 110对应的软件版本可以包括：助力转向ECU对应的软件版本为v1.1；车身稳定ECU对应的软件版本为v2.2；整车控制ECU对应的软件版本为v1.0。
当进一步借助OTA进行软件升级后，可以升级为如图1中的c所示的，影响准入的软件升级后的RXSWIN与软件版本的匹配关系示意图。其中，发生影响准入的软件升级后，RXSWIN关联的软件版本信息变更，且RXSWIN变更。例如，RXSWIN由R79 110变更为R79 111。此时，R79 111对应的软件版本可以包括：助力转向ECU对应的软件版本为v2.0；车身稳定ECU对应的软件版本为v2.2；整车控制ECU对应的软件版本为v1.0。其中，OTA升级使得助力转向ECU对应的软件版本由原来的v1.1升级为v2.0，助力转向ECU的升级导致准入时该软件对应的测试参数的改变，故RXSWIN由R79 110变更为R79 111，该RXSWIN用以标识OTA升级影响了准入时参数。
也就是说，如图1所示，RXSWIN可以应用在基于OTA的软件升级时，用于表示与软件版本的对应关系。然而，在OTA的维护以及安装软件的过程中，无法保证车端与云端的RXSWIN与软件版本的一致性，也就无法很好的解决通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，进而难以维护汽车软件的安全升级。如何管理RXSWIN，以及如何维护车端和/或云端的RXSWIN与软件版本的一致性，目前还缺少合适的方法。
有鉴于此，本申请实施例提供一种基于OTA的通信方法和装置，可以在OTA的维护以及软件安装的过程中，获取第一信息和第二信息，利用第一信息和第二信息中的标识码与软件版本的匹配关系，基于标识码与软件版本的匹配关系验证第一信息与第二信息的一致性，进而可以通过维护车端和/或云端中，软件版本与标识码的一致性，消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。
可选的，该标识码可以为RXSWIN。
为了更好的理解本申请实施例的方法，下面首先对本申请实施例适用的应用场景进行描述。
可能的实现方式中，本申请实施例提供的一种基于OTA的通信方法，可以应用于各类型车辆OTA的维护及升级的场景中，例如通过车端与云端设备的数据交互，维护标识码与软件版本的一致性，或者下载或更新车辆中的软件等的场景中。其中，该车端 和/或云端设备的数量均可以为一个或多个。
车端(或称车辆或车端设备)可以是进行软件升级的任意形式的车辆，或任意形式的车辆辅助设备(例如车辆充电桩等)等，本申请实施例对此不作具体限定。
云端(或称云端设备或服务器)可以是用于下发整车升级包的OTA服务器，也可以是代理服务器，例如代理服务器可以是为车队服务的服务器等。在该云端设备为代理服务器时，代理服务器可以先与OTA服务器之间通过双向认证，建立安全通信，之后，代理服务器将车辆的硬件和软件信息发送给OTA服务器，OTA服务器生成整车升级包后，可以将整车升级包下发给代理服务器，可以理解的，OTA服务器也可以将整车升级包分块后，下发给多个代理服务器。
云端也可以是用于更新软件的软件客户端服务器，也可以是已从软件客户端服务器中获取并更新软件的车队服务器或其他任意可能的服务器。
云端还可以是任意形式的车辆、任意形式的车辆辅助设备(例如车辆充电桩等)或移动终端(例如手机、平板、可穿戴设备等)，本申请实施例对此不作具体限定。
上述车辆和云端设备可以建立通信连接，例如车辆和云端设备可以通过超文本传输协议(hyper text tansfer protocol，HTTP)或基于安全套接字层的超文本传输协议(hyper text transfer trotocol over secure socket layer，HTTPS)等协议建立通信连接，本申请实施例中对此不做任何限制。
图2为本申请实施例提供的第一种示例性应用场景示意图。如图2所示，该场景中可以包括车辆201和软件OTA云设备202。车辆201为安装有软件OTA客户端的任意形式的车辆。软件OTA云设备202为提供OTA升级的服务器，用于存储软件包，以及存储标识码(例如RXSWIN)和软件版本的映射关系等。当对车辆201中的软件进行更新时，软件OTA云设备202可以获取车辆201中的软件OTA客户端上各软件的软件版本信息和/或标识码，并与自身存储的标识码和软件版本的映射关系进行比对，当汽车201中的各软件的软件版本信息和/或标识码与该映射关系一致时，可以自动发送或根据软件OTA客户端的请求命令发送软件包，至车辆201中的软件OTA客户端中，其中该软件包中包含标识码。车辆201中的软件OTA客户端可以根据来自软件OTA云设备的软件包，更新软件以及标识码。
车辆201和软件OTA云设备202的数量均可以为一个或多个，本申请实施例对此不作具体限定。
可能的实现方式中，该软件OTA云设备也可以为车厂OTA云设备。此时，车厂OTA云设备可以为用于下发整车升级包的OTA服务器。
下面对上述软件OTA云设备以及车厂OTA云设备在车辆中的实现过程进行说明。示例性的，图3为本申请实施例提供的一种车辆中软件更新的系统架构的示意图。如图3所示，该系统中可以包括：车厂OTA云设备301、软件OTA云设备302、主控OTA客户端303和软件OTA客户端304。
其中，车厂OTA云设备301可以是车辆厂商或车辆中软件服务商的服务器，用于管理车辆中软件和存储软件数据。车辆中软件可以包括车身控制软件等。软件OTA云设备302可以是用于存储软件包，以及存储标识码和软件版本的映射关系等。车厂OTA云设备301可以与软件OTA云设备302进行交互。车厂OTA云设备301的软件信息 来自软件OTA云设备302，或者车厂OTA云设备301也可以自行确定软件信息。
需要说明的是，车辆中OTA升级可以包括主控节点和从属节点两级。如图3所示，主控OTA客户端303与主控节点相对应，可以接收整车升级包，并拆分分发给其控制的多个从属客户端。软件OTA客户端304与从属节点相对应，可以是主控OTA客户端303下的从属OTA客户端。软件OTA客户端304可以作为整车OTA升级的一部分进行软件更新。
因此，该系统架构中有两种可能的软件更新方式。一种可能的实现方式是软件OTA云设备302与软件OTA客户端304交互，对软件进行更新。具体实现过程与图1所示的应用场景的描述一致，此处不再赘述。
另一种可能的实现方式是车厂OTA云设备301、主控OTA客户端303和软件OTA客户端304交互，对软件进行更新。示例性的，车厂OTA云设备301可以基于自身存储的标识码与软件版本的映射关系，以及从主控OTA客户端303(或软件OTA客户端304)获取的软件版本和/或标识码的一致性，将需要更新的软件包通过整车升级包发送给主控OTA客户端302。主控OTA客户端302接收下载整车升级包，将整车升级包拆分后发送到软件OTA客户端304。软件OTA客户端304根据拆分后的整车升级包中的软件包，更新软件以及标识码。
如图4所示，图4为本申请实施例提供的第二种示例性应用场景示意图。如图4所示，该应用场景中可以包括服务器401、第一车辆402、第二车辆403、第二车辆404和第二车辆405。
服务器401可以是车队服务器，车队服务器可以提前从OTA服务器中获取该车队服务器所服务的车队(例如包括第一车辆402、第二车辆403、第二车辆404和第二车辆405)所需的整车升级包。
在车队例行检修期间，无线保真(wireless-fidelity，WIFI)等联网情况下，第一车辆402、第二车辆403、第二车辆404和第二车辆405链接车队服务器，当收到升级包下载通知时，车队服务器与第一车辆402、第二车辆403、第二车辆404和第二车辆405进行双向认证(如基于公钥基础设施的认证方式)，认证通过后，车队服务器将升级包的加密密钥k加密(利用车辆的公钥加密)后下发给第一车辆402、第二车辆403、第二车辆404和第二车辆405。
示例的，第一车辆402、第二车辆403、第二车辆404和第二车辆405均可以利用密钥k解密密钥，并从服务器下载各自需要的整车软件包。例如，第一车辆402可以根据完整的整车升级包完成软件的更新。该整车升级包中可以包括用于更新标识码的软件包。第一车辆402可以根据软件包，更新软件以及标识码。
如图5所示，图5为本申请实施例提供的第三种示例性应用场景示意图。如图5所示，该应用场景中可以包括车辆501以及车辆辅助设备502。车辆501可以是任意形式的车辆。车辆辅助设备502可以是车辆充电桩或其他任意辅助车辆OTA更新的终端设备(例如手机和平板等)。车辆辅助设备502可以基于自身存储的标识码与软件版本的映射关系，以及从车辆501获取的软件版本和/或标识码的一致性，向车辆501发送需要更新的软件包。车辆501可以根据接收的软件包，更新软件以及标识码。
为便于理解本申请实施例，首先对本申请中涉及到的一些词汇作简单说明。
1、汽车OTA：指汽车通过网络从远程服务器下载软件更新包对自身系统进行更新升级的过程。例如但不限于，汽车OTA每次更新对应一个整车升级包和一个整车版本号，一个整车升级包中包含车内的多个ECU的软件。
2、车厂OTA云设备：汽车厂商或服务商提供的一种云服务，负责在云端管理升级任务和软件升级包，或标识码等信息，并以OTA的方式下发给需要软件升级的车辆。其中，OTA方式可以通过WIFI、长期演进(long term evolution，LTE)、第五代(5th generation，5G)移动通信系统或新无线(new radio，NR)和卫星等进行接入。
3、软件OTA云设备：针对软件的一种云服务，负责在云端管理汽车中的某种软件，或标识码等信息，并以OTA的方式下发给需要升级的用户或车辆。
可以理解的是，本申请实施例中的车厂OTA云设备或软件OTA云设备可以统称为OTA云端，用于实现软件和标识码的更新。
4、主控节点(update master，简称Master节点)：部署在车辆中某个ECU上的软件，负责集中控制整车OTA升级，从OTA云端下载整车升级包，拆分后分发给对应ECU。
或者，也可以为车辆上单独存在的模块单元，本申请实施例对此不作限定。
5、电子控制单元：包括自动驾驶控制器、座舱控制器、通信盒子(telematics box，T-Box)和网关等。ECU的软件升级可以从OTA云下载软件升级包并安装升级，也可以在主控节点的集中控制和协调下由主控节点拆分整车升级包后分发得到软件升级包进行升级。
下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以独立实现，也可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。
图6为本申请实施例提供的一种基于OTA的通信方法的流程示意图，如图6所示，该方法可以包括如下步骤：
S601、获得第一信息和第二信息。
本申请实施例中，第一信息和第二信息，可以为用于车端和/或云端，验证软件版本信息与标识码的一致性的信息，例如该第一信息可以包括：第一软件版本信息和/或第一标识码；第二信息可以包括第一映射；该第一映射包含第二软件版本信息和第二标识码的关联关系。其中，该第一信息可以来自车端；该第二信息可以来自云端。
本申请实施例中，标识码可以用于指示软件版本的权限信息。其中，权限可以理解为允许汽车准入的限制。
示例性的，标识码可以为RXSWIN等其他标识。软件版本信息可以为用于标识不同软件版本的信息，例如该软件版本信息可以为软件版本号等其他信息。
可以理解的是，标识码和软件版本信息可以根据实际场景包括其他内容，本申请实施例中对此不做限定。
示例性的，获得第一信息和第二信息的主体可以为云端，或者车端。当执行主体为云端时，车端可以向云端上报第一信息，进而云端可以接收该车端上报的第一信息，并获取自身保存的第二信息，进而可以对该第一信息和第二信息的一致性进行验证；当执行主体为车端时，云端可以向车端下发第二信息，进而车端可以接收该自云端下发的第二信息， 并获取自身保存的第一信息，进而可以对该第一信息和第二信息的一致性进行验证。
S602、根据第一信息和第二信息，验证第一软件版本信息与第一映射对应的第二软件版本信息的一致性。
本申请实施例中，该第一软件版本信息与第一映射对应的第二软件版本信息的一致性的情况可以包括：第一软件版本信息与第二软件版本信息一致，或者，第一软件版本信息与第二软件版本信息不一致。
示例性的，根据第一信息和第二信息，验证第一软件版本信息与第一映射对应的第二软件版本信息的一致性的主体可以包括两种：云端，或者车端。可以理解的是，本申请实施例中对验证第一软件版本信息与第一映射对应的第二软件版本信息的一致性的执行主体不做限定。
综上所述，本申请实施例提供一种基于OTA的通信方法和装置，可以在OTA的维护以及安装软件的过程中，获取来自车端的第一信息和来自云端的第二信息，利用第一信息和第二信息中的标识码与软件版本的匹配关系，验证第一信息与第二信息的一致性，进而可以通过维护车端和/或云端中，软件版本与标识码的一致性，消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。
在图6对应的实施例的基础上，可能的实现方式中，S601-S602所示的步骤中，验证第一软件版本信息与第一映射对应的第二软件版本信息的一致性的执行主体可以为云端，或者车端。
示例性的，方式一：利用云端验证第一软件版本信息与第一映射对应的第二软件版本信息的一致性(如图7对应的实施例)。
方式二：利用车端验证第一软件版本信息与第一映射对应的第二软件版本信息的一致性(如图8对应的实施例)。
方式一：利用云端验证第一软件版本信息与第二软件版本信息的一致性。
示例性的，图7为本申请实施例提供的一种云端维护标识码与软件版本信息一致性的流程示意图。在图7对应的实施例中，以云端为OTA云端，车端包括主控节点、ECU1以及ECU2，标识码为RXSWIN，以及第一映射为RXSWIN映射(包含RXSWIN与软件版本信息的关联关系)为例，对云端根据第一信息和第二信息，验证第一软件版本信息与第二软件版本信息的一致性进行说明，该示例并不构成对本申请实施例的限定。
如图7所示，云端维护标识码与软件版本信息一致性的过程可以包括如下步骤：
S701、主控节点收集各个ECU(包括ECU1和ECU2)上的软件版本信息。
示例性的，主控节点可以定期收集各个ECU上的软件版本信息。例如，设定每周收集一次各个ECU上的软件版本信息。
S702、主控节点将车端的软件版本信息上报至OTA云端。
适应的，OTA云端接收该车端上报的软件版本信息。
可选的，当车端保存有RXSWIN标识时，车端可以执行S703所示的步骤。
S703、主控节点将车端的RXSWIN标识上报至OTA云端。
适应的，OTA云端接收该车端上报的RXSWIN。
S704、OTA云端检查RXSWIN相关软件版本信息一致性，若不一致，则进行软件升级。
示例性的，OTA云端将S702所示的步骤中上报的软件版本信息，与OTA云端保存的RXSWIN映射表进行比较，当该主控节点上报的软件版本信息与RXSWIN映射表中的软件版本信息不一致时，则可以表示与准入相关的软件遭到了不合规的修改，此时OTA云端可以通过OTA升级软件，并修改车端的软件版本信息，保证车端的软件版本信息与OTA云端保存的RXSWIN映射表的一致性。
可选的，当车端上报RXSWIN标识至云端时，云端可以执行S705所示的步骤。
S705、OTA云端检查RXSWIN一致性，若不一致则更新RXSWIN。
示例性的，OTA云端将S703所示的步骤中上报的RXSWIN标识，与OTA云端保存的RXSWIN映射表进行比较，当该车端上报的RXSWIN标识与RXSWIN映射表中的RXSWIN标识不一致时，则可以表示车端RXSWIN被篡改，此时OTA云端可以下发指令，更新车端RXSWIN标识，保证车端的RXSWIN标识与OTA云端保存的RXSWIN映射表的一致性。
可以理解的是，OTA云端可以基于S704所示的步骤中对于车端和云端软件版本信息的一致性判断进行软件升级；可以基于S705所示的步骤中对于车端和云端RXSWIN的一致性判断进行软件升级；或者，可以基于S704和S705所示的步骤中，分别对于车端和云端的软件版本信息的一致性，以及RXSWIN的一致性，判断是否进行软件升级。
方式二：利用车端验证第一软件版本信息与第二软件版本信息的一致性。
示例性的，图8为本申请实施例提供的一种车端维护标识码与软件版本信息一致性的流程示意图。在图8对应的实施例中，以云端为OTA云端，车端包括主控节点、ECU1以及ECU2，标识码为RXSWIN以及第一映射为RXSWIN映射(包含RXSWIN与软件版本信息的关联关系)为例，对车端根据第一信息和第二信息，验证第一软件版本信息与第二软件版本信息的一致性进行说明，该示例并不构成对本申请实施例的限定。
如图8所示，车端维护标识码与软件版本信息一致性的过程可以包括如下步骤：
S801、OTA云端下发RXSWIN和RXSWIN映射表至主控节点。
适应的，主控节点接收该OTA云端下发的RXSWIN和RXSWIN映射表。
示例性的，当OTA云端保存的RXSWIN映射表中的任一RXSWIN标识，或任一软件版本信息发生变化时，OTA云端则可以将变化后的RXSWIN映射表下发至主控节点。
S802、主控节点收集各个ECU(包括ECU1和ECU2)上的软件版本信息。
S803、主控节点检查RXSWIN相关软件版本信息一致性。
S804、若主控节点确定RXSWIN相关软件版本信息不一致，则可以向OTA云端告警，并上报该不一致的软件版本信息。
示例性的，若主控节点确定S802所示的步骤中，各ECU上报的软件版本信息与的步骤中，OTA云端下发的RXSWIN映射表中的软件版本信息不一致时，则可以表示车端与准入相关的软件遭到了不合规的修改，此时主控节点可以将不一致的消息上报至OTA云端。
基于此，利用云端或车端验证第一软件版本信息与第二软件版本信息的一致性，进而可以通过维护车端和/或云端中，软件版本与RXSWIN的一致性，防止软件版本和/或RXSWIN被篡改，保证通过OTA升级的汽车软件正常升级。
在图6对应的实施例的基础上，可能的实现方式中，还包括：
S603(图中未示出)、在第一软件版本信息与第二软件版本信息不一致的情况下，第一车辆向云端和/或第一车辆的显示设备，发送第一软件版本信息、第一标识码和/或告警信息。
适应的，显示设备可以接收来自第一车辆的第一软件版本信息、第一标识码和/或告警信息。其中，本申请实施例描述的车端可以包括第一车辆。
本申请实施例中，该告警信息用于指示车辆的标识码和/或软件版本信息与服务器的映射关系不一致。该显示设备可以为第一车辆的中控显示屏、第一车辆的仪表盘显示屏，或者与车辆连接的其他显示设备，例如手机等。本申请实施例中，该显示设备可以根据实际场景包括其他内容，本申请实施例中对此不做限制。
S604(图中未示出)、显示设备显示告警信息。
示例性的，图9为本申请实施例提供的一种显示告警信息的界面示意图。如图9所示，该界面可以为第一车辆的中控显示屏900所显示的界面，该中控显示屏900显示的界面中，可以包括软件版本更新的指示消息901，系统提示消息902，停止控件903，以及继续控件904等内容。该指示消息901中显示“助力转向软件V2.0(R79 90)正在更新中…”。其中，V2.0可以为该助力转向软件的软件版本信息，R79 90可以为该助力转向软件的软件版本对应的标识码。
在进行软件更新前，当第一车辆检测到第一软件版本信息与第二软件版本信息不一致时，可以向中控显示屏900发送告警信息，该告警信息可以为显示在中控显示屏900上的系统提示消息902。其中，该系统提示消息902中显示，“车辆软件可能受到非法篡改，请及时处理！”后续当用户看到该提示消息时，可以触发停止控件903，暂停软件的更新；或者，将车辆开到4S店进行处理。
基于此，可以将系统内部用于指示软件版本信息与标识码不一致的告警信息，通过用户界面直观的显示给用户，方便用户及时进行后续处理，进一步保障汽车软件的正常升级。
在图6对应的实施例的基础上，可能的实现方式中，S602可以包括：
一种实现中，在第一软件版本信息与第二软件版本信息不一致，和/或，第一标识码与第二标识码不一致的情况下，确定第一软件版本信息与第二软件版本信息不一致。
可以理解为，第一软件版本信息与第二软件版本信息不一致，第一标识码与第二标识码不一致，或者，第一软件版本信息与第二软件版本信息不一致且第一标识码与第二标识码不一致的情况下，确定第一软件版本信息与第二软件版本信息不一致。
其中，第一软件版本信息与第二软件版本信息不一致，可以理解为，此时第一标识码与第二标识码可以一致，或者第一标识码与第二标识码可以不一致；第一标识码与第二标识码不一致，可以理解为，此时第一软件版本信息与第二软件版本信息可以一致，或者第一软件版本信息与第二软件版本信息可以不一致。
另一种实现中，在第一软件版本信息与第二软件版本信息一致，和/或，第一标识码与第二标识码一致的情况下，确定第一软件版本信息与第二软件版本信息一致。
可以理解为，第一软件版本信息与第二软件版本信息一致，第一标识码与第二标识码一致，或者，第一软件版本信息与第二软件版本信息一致且第一标识码与第二标识码一致的情况下，确定第一软件版本信息与第二软件版本信息一致。
基于此，在云端下发第一任务的场景中，可以在第一软件版本信息和/或第一标识码，与第一映射一致的条件下，基于一致性校验进一步保证通过OTA升级的汽车软件正常升级；在云端和/或车端定期检查标识码与软件版本信息一致性的场景中，可以在第一软件版本信息和/或第一标识码，与第一映射不一致的条件下，及时发现由于该不一致产生的不合规风险，防止标识码和/或软件版本信息被篡改，保证通过OTA升级的汽车软件正常升级。
在图6对应的实施例的基础上，可能的实现方式中，还包括：在第一软件版本信息与第二软件版本信息不一致的情况下，更新第一软件版本信息和/或第一标识码；或者，在第一软件版本信息与第二软件版本信息一致的情况下，更新第一软件版本信息和/或第一标识码。
一种实现中，第一软件版本信息与第二软件版本信息不一致的场景可以为，由于车端的第一软件版本信息和/或第一标识码遭到篡改，导致车端的第一软件版本信息与云端的第二软件版本信息不一致。进而云端可以将自身保存的软件版本信息和/或标识码，下发至车端，保证云端与车端的软件版本信息和标识码的一致性。其中，云端下发的软件版本信息和/或标识码，可以与车端遭到篡改前保存的软件版本信息和/或标识码一致。在此场景下，若第一软件版本信息与第二软件版本信息一致，则可以不进行第一软件版本信息和/或第一标识码的更新处理。
示例性的，基于不一致更新第一软件版本信息和/或第一标识码的过程可以如图7以及图8对应的实施例，在此不再赘述。
另一种实现中，第一软件版本信息与第二软件版本信息一致的场景可以为，由云端下发第一任务(或称更新任务)，当云端确定由车端上报的第一软件版本信息和/或第一标识码，与云端保存的第二软件版本信息一致时，进而云端可以基于一致性的保证，将第一任务中携带的软件版本信息和/或标识码下发至车端。在此场景下，若第一软件版本信息与第二软件版本信息不一致，则可以不进行第一软件版本信息和/或第一标识码的更新处理。
示例性的，图10为本申请实施例提供的一种云端进行一致性判断的流程示意图。在图10对应的实施例中，以云端为OTA云端，车端包括主控节点，第一映射为RXSWIN映射，以及标识码为RXSWIN为例，对在第一软件版本信息与第二软件版本信息一致的情况下，更新第一软件版本信息和/或第一标识码进行说明，该示例并不构成对本申请实施例的限定。
如图10所示，云端进行一致性判断的过程可以包括：
S1001、OTA云端收集主控节点上的RXSWIN标识。
S1002、OTA云端检查RXSWIN一致性。
示例性的，若OTA云端确定车端的RXSWIN标识与第一映射中的RXSWIN标识不一致时，则OTA云端可以确定不进行OTA。
若OTA云端确定车端的RXSWIN标识与第一映射中的RXSWIN标识一致时，则OTA云端可以向主控节点下发更新任务，该更新任务可以携带新的RXSWIN标识和RXSWIN映射表。
S1003、主控节点保存新的RXSWIN标识和RXSWIN映射表。
基于此，云端和车端可以基于标识码与软件版本的匹配关系，维护车端的软件版本信息和/或标识码，与云端的映射关系的一致性，进而消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。
上述为车端和/或云端维护软件版本信息与标识码一致性的过程下面对OTA升级汽车软件的过程中，保证软件版本信息和标识码的一致性的过程进行描述。
示例性的，图11为本申请实施例提供的一种更新软件的流程示意图。如图11所示，更新软件的主体可以包括云端和第一车辆。其中第一车辆中可以包括主控节点以及一个或多个ECU。
如图11所示，该更新软件的过程可以包括如下步骤：
S1101、云端向第一车辆发送第一任务。
适应的，第一车辆接收第一任务，并可以根据第一任务更新第一软件版本信息和/或第一标识码。其中，接收第一任务的主体可以为第一车辆中的主控节点。
本申请实施例中，第一任务用于指示更新第一软件版本信息和/或第一标识码；在第一软件版本信息与第二软件版本信息不一致的情况下，第一任务包括第一映射；在第一软件版本信息与第二软件版本信息一致的情况下，第一任务包括第二映射；第二映射包含第三软件版本信息和第三标识码的关联关系；第三软件版本信息不同于第二软件版本信息，和/或，第三标识码不同于第二标识码。
示例性的，当云端确定第一车辆的第一软件版本信息与云端的第二软件版本信息不一致时，可以理解为此时第一车辆的软件版本和/或标识码可能遭到篡改，此时云端可以发送包含第一映射的第一任务。其中，第一映射可以理解为第一车辆的软件版本和/或标识码遭到篡改之前，云端保存的软件版本信息和标识码的关联关系。
示例性的，当云端确定第一车辆的第一软件版本信息与云端的第二软件版本信息一致时，可以理解为此时第一车辆设备与云端已经经过，进行OTA升级软件前的一致性判断，此时云端可以发送包含第二映射的第一任务。其中，第二映射可以理解为由OTA触发的包含新的软件版本信息与新的标识码的映射关系。
可以理解的是，当进行OTA对软件进行更新，不足以改变准入时该软件对应的测试参数时，第二映射中的第三标识码可以与第一车辆保存的第一标识码一致。示例性的，若第一车辆的电池管理系统为V1.0，其系统可以支持可续航里程为500km；当对该电池管理系统通过OTA进行软件升级时，将第一车辆的电池管理系统更新为V1.1，其系统可以支持可续航里程为500km；此时由于对电池管理系统的更新没有改变准入时，可持续里程的具体参数。因此，此时第一车辆通过OTA进行软件升级时，云端下发的第二映射中的第三软件版本信息与第一车辆保存的第一软件版本信息不一致，第二映射中的第三标识码可能与第一车辆保存的第一标识码一致。
S1102、云端向第一车辆发送第一软件包。
适应的，第一车辆可以接收第一软件包，并根据第一软件包更新车辆的软件。其中，软件包中可以包含软件，以及该软件对应的软件版本信息。
本申请实施例中，在第一软件版本信息与第二软件版本信息不一致的情况下，第一软件包包括第二标识码；或，在第一软件版本信息与第二软件版本信息一致的情况下，第一软件包包括第三标识码。
示例性的，当云端确定，第一车辆的第一软件版本信息与云端的第二软件版本信息不一致时，可以理解为此时第一车辆的软件版本或者标识码可能遭到篡改，此时云端可以发送包含第二标识码的第一软件包。其中，第一软件包可以理解为第一车辆的软件版本或者标识码遭到篡改之前，云端保存的软件包。其中，该云端保存的软件包中，可以保存第一车辆的软件版本或者标识码遭到篡改之前的软件和标识码。
示例性的，当云端确定，第一车辆的第一软件版本信息与云端的第二软件版本信息一致时，可以理解为此时第一车辆设备与云端已经经过，进行OTA升级软件前的一致性判断，此时云端可以发送包含第三标识码的第一软件包。其中，第一软件包可以理解为由OTA触发的软件包。
可以理解的是，当进行OTA时的软件版本更新，不足以改变准入时的参数时，第三标识码可以与第一标识码一致，其具体过程不再赘述。
S1103、第一车辆向ECU发送各ECU对应的第一软件包。
适应的，各ECU接收该第一软件包。其中，ECU的数量可以为一个或多个。例如，当ECU的数量为N个时，第一车辆可以向N个ECU发送各ECU对应的第一软件包；N为正整数。
示例性的，当第一车辆中包含主控节点时，主控节点可以接收到云端发送的第一软件包，并将该第一软件包分发给相应的ECU。
S1104、ECU安装第一软件包并更新标识码。
本申请实施例中，该标识码可以为第二标识码或第三标识码。
示例性的，当ECU在安装第一软件包出现异常时，ECU可以回滚至安装前的软件，并恢复第一标识码。其中，ECU回滚至安装前的软件，可以表示ECU恢复第一软件版本信息。
示例性的，当ECU在安装第一软件包成功时，ECU可以更新第一标识码和第一软件版本信息。
S1105、ECU将安装结果发送至第一车辆。
适应的，第一车辆接收该安装结果。其中，该安装结果可以为安装成功，或者任一个或多个ECU安装失败。
S1106、在该软件安装结果为任意一个或多个安装失败的情况下，回滚第一车辆的整车软件版本和标识码。
可选的，当该软件安装结果为安装成功的情况下，可以更新整车版本和/或标识码。示例性的，当软件安装结果为安装成功，且更新的软件不足以改变整车版本时，该整车版本可以不发生改变。
基于此，可以在OTA升级软件的过程中保证软件版本信息和标识码的匹配关系，进而基于车端和/或云端中，软件版本与标识码的一致性，消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。
基于上述实施例中所描述的内容，为了更好的理解本申请各实施例，下面以车端更新软件的整体过程进行分别描述。具体的，该过程可以包括：云端向车端下发软件包(如图12对应的实施例)，车端成功安装软件包(如图13对应的实施例)，以及车端安装软件包失败(如图14对应的实施例)。
图12为本申请实施例提供的一种云端向车端下发软件包的流程示意图。在图12对应的实施例中，以云端为OTA云端，车端包括主控节点、ECU1和ECU2，标识码为RXSWIN，第一映射为RXSWIN映射为例，对云端向车端下发软件包的过程进行说明，该示例并不构成对本申请实施例的限定。
如图12所示，云端下发软件包的过程可以包括如下步骤：
S1201、OTA云端向主控节点下发软件包。
适应的，主控节点接收该OTA云端下发的软件包。其中，该软件包携带相关RXSWIN标识。
S1202、主控节点向ECU1和ECU2分发软件包。
适应的，该ECU1和ECU2接收该主控节点发送的软件包。其中，该ECU1和ECU2可以为该软件包对应的ECU。
S1203、ECU1和ECU2接收软件包，记录RXSWIN标识。
基于此，可以在OTA升级软件的过程中保证软件版本信息和标识码的匹配关系，进而基于车端和/或云端，软件版本与标识码的一致性，消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。
上述为云端向车端下发软件包的过程，下文对车端安装软件包，且安装成功的过程进行描述。
示例性的，图13为本申请实施例提供的一种车端安装软件包的流程示意图。在图13对应的实施例中，以云端为OTA云端，车端包括主控节点、ECU1和ECU2，标识码为RXSWIN，第一映射为RXSWIN映射为例，对车端成功安装软件包的过程进行说明，该示例并不构成对本申请实施例的限定。
如图13所示，ECU安装软件包的过程可以包括如下步骤：
S1301、ECU1和ECU2安装软件。
示例性的，当主控节点向ECU1和ECU2分发软件包后，ECU1和ECU2可以基于软件包安装软件。
S1302、ECU1和ECU2安装软件成功，更新相关RXSWIN。
S1303、ECU1和ECU2将安装结果发送至主控节点。
S1304、主控节点更新整车版本和/或更新RXSWIN。
其中，该整车版本也可以不发生改变，在此不再赘述。
基于此，可以在OTA升级软件的过程中保证软件版本信息和标识码的匹配关系，进而基于车端和/或云端中，软件版本与标识码的一致性，消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。
上述为车端安装软件包，且安装成功的过程，可能的实现方式中，车端安装软件包可能发生异常，下文对车端安装软件包，且安装失败的过程进行描述。
示例性的，图14为本申请实施例提供的另一种车端安装软件包的流程示意图。在图14对应的实施例中，以云端为OTA云端，车端包括主控节点、ECU1和ECU2，标识码为RXSWIN，第一映射为RXSWIN映射为例，对车端安装软件包失败的过程进行说明，该示例并不构成对本申请实施例的限定。
如图14所示，ECU安装软件包的过程可以包括如下步骤：
S1401、ECU1和ECU2安装软件，更新相关RXSWIN。
S1402、ECU1和ECU2安装软件出现异常，软件回滚。
其中，该ECU1和ECU2保存有安装软件包前的软件，当ECU1和ECU2安装软件出现异常时，ECU1和ECU2可以回滚至该安装软件包前的软件。
S1403、ECU1和ECU2恢复旧RXSWIN。
其中，该ECU1和ECU2保存有安装软件包前的RXSWIN，当ECU1和ECU2安装软件出现异常时，ECU1和ECU2可以回滚至该安装软件包前的RXSWIN。
S1404、ECU1和ECU2向主控节点通知异常。
S1405、主控节点恢复相关旧RXSWIN。
基于此，可以在OTA升级软件的过程中保证软件版本信息和标识码的匹配关系，进而基于车端和/或云端中，软件版本与标识码的一致性，消除通过OTA升级的软件版本与准入时的软件版本存在不一致的情况，保证汽车软件的正常升级。
上面结合图6-图14，对本申请实施例提供的方法进行了说明，下面对本申请实施例提供的执行上述方法的装置进行描述。
示例性的，图15为本申请实施例提供的一种基于OTA的通信装置的结构示意图，如图8所示，基于OTA的通信装置150可以用于通信设备、电路、硬件组件或者芯片中，该基于OTA的通信装置包括：显示单元1501、处理单元1502和通信单元1503。其中，显示单元1501用于支持配网方法执行的显示的步骤；处理单元1502用于支持基于OTA的通信装置执行信息处理的步骤；通信单元1503用于支持基于OTA的通信装置执行数据发送或接收的步骤。
具体的，本申请实施例提供一种基于OTA的通信装置，通信单元1503，用于获得第一信息和第二信息；第一信息包括第一软件版本信息和/或第一标识码；第二信息包括第一映射；第一映射包含第二软件版本信息和第二标识码的关联关系；标识码用于指示软件版本的权限信息；处理单元1502，还用于根据第一信息和第二信息，验证第一软件版本信息与第二软件版本信息的一致性。
可能的实现方式中，处理单元1502，具体用于：在第一软件版本信息与第二软件版本信息不一致，和/或，第一标识码与第二标识码不一致的情况下，确定第一软件版本信息与第二软件版本信息不一致；或者，在第一软件版本信息与第二软件版本信息一致，和/或，第一标识码与第二标识码一致的情况下，确定第一软件版本信息与第二软件版本信息一致。
可能的实现方式中，处理单元1502，还用于：在第一软件版本信息与第二软件版本信息不一致的情况下，更新第一软件版本信息和/或第一标识码；或者，在第一软件版本信息与第二软件版本信息一致的情况下，更新第一软件版本信息和/或第一标识码。
可能的实现方式中，通信单元1503，用于：向第一车辆发送第一任务；第一任务用于指示更新第一软件版本信息和/或第一标识码；其中，在第一软件版本信息与第二软件版本信息不一致的情况下，第一任务包括第一映射；在第一软件版本信息与第二软件版本信息一致的情况下，第一任务包括第二映射；第二映射包含第三软件版本信息和第三标识码的关联关系。
可能的实现方式中，通信单元1503，还用于：向第一车辆发送第一软件包；第一软件包用于更新第一车辆对应的软件版本信息；其中，在第一软件版本信息与第二软件版本信 息不一致的情况下，第一软件包包括第二标识码；或，在第一软件版本信息与第二软件版本信息一致的情况下，第一软件包包括第三标识码。
可能的实现方式中，通信单元1503，还用于：在第一软件版本信息与第二软件版本信息不一致的情况下，向服务器和/或第一车辆的显示设备发送第一软件版本信息、第一标识码和/或告警信息；告警信息用于指示车辆的标识码和/或软件版本信息与服务器的映射关系不一致。
可能的实现方式中，通信单元1503，具体用于接收来自服务器的第一任务，第一任务用于指示更新第一软件版本信息和/或第一标识码；其中，在第一软件版本信息与第二软件版本信息不一致的情况下，第一任务包括第一映射；或，在第一软件版本信息与第二软件版本信息一致的情况下，第一任务包括第二映射；第二映射包含第三软件版本信息与第三标识码的关联关系。
可能的实现方式中，通信单元1503，还用于：接收来自服务器的第一软件包；第一软件包用于更新第一车辆对应的软件版本信息；其中，在第一软件版本信息与第二软件版本信息不一致的情况下，第一软件包包括第二标识码；或，在第一软件版本信息与第二软件版本信息一致的情况下，第一软件包包括第三标识码。
可能的实现方式中，标识码包括第一法规相关软件识别码RXSWIN。
通信在一种可能的实施例中，基于OTA的通信装置还可以包括：存储单元1504。处理单元1502、存储单元1504通过线路相连。
存储单元1504可以包括一个或者多个存储器，存储器可以是一个或者多个设备、电路中用于存储程序或者数据的器件。
存储单元1504可以独立存在，通过通信线路与基于OTA的通信装置具有的处理单元1502相连。存储单元1504也可以和处理单元1502集成在一起。
其中，则通信单元1503可以是输入或者输出接口、管脚或者电路等。示例性的，存储单元1504可以存储雷达或目标设备的方法的计算机执行指令，以使处理单元1502执行上述实施例中雷达或目标设备的方法。存储单元1504可以是寄存器、缓存或者RAM等，存储单元1504可以和处理单元1502集成在一起。存储单元1504可以是ROM或者可存储静态信息和指令的其他类型的静态存储设备，存储单元1504可以与处理单元1502相独立。
图16为本申请实施例提供的一种控制设备的硬件结构示意图，如图16所示，该控制设备包括处理器1601，通信线路1604以及至少一个通信接口(图16中示例性的以通信接口1603为例进行说明)。
处理器1601可以是一个通用中央处理器(central processing unit，CPU)，微处理器，特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制本申请方案程序执行的集成电路。
通信线路1604可包括在上述组件之间传送信息的电路。
通信接口1603，使用任何收发器一类的装置，用于与其他设备或通信网络通信，如以太网，无线局域网(wireless local area networks，WLAN)等。
可能的，该控制设备还可以包括存储器1602。
存储器1602可以是只读存储器(read-only memory，ROM)或可存储静态信息和 指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electrically erasable programmable read-only memory，EEPROM)、只读光盘(compact disc read-only memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过通信线路1604与处理器相连接。存储器也可以和处理器集成在一起。
其中，存储器1602用于存储执行本申请方案的计算机执行指令，并由处理器1601来控制执行。处理器1601用于执行存储器1602中存储的计算机执行指令，从而实现本申请实施例所提供的基于OTA的通信方法。
可能的，本申请实施例中的计算机执行指令也可以称之为应用程序代码，本申请实施例对此不作具体限定。
在具体实现中，作为一种实施例，处理器1601可以包括一个或多个CPU，例如图16中的CPU0和CPU1。
在具体实现中，作为一种实施例，控制设备可以包括多个处理器，例如图16中的处理器1601和处理器1605。这些处理器中的每一个可以是一个单核(single-CPU)处理器，也可以是一个多核(multi-CPU)处理器。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。
示例性的，图17为本申请实施例提供的一种芯片的结构示意图。芯片170包括一个或两个以上(包括两个)处理器1720和通信接口1730。
在一些实施方式中，存储器1740存储了如下的元素：可执行模块或者数据结构，或者他们的子集，或者他们的扩展集。
本申请实施例中，存储器1740可以包括只读存储器和随机存取存储器，并向处理器1720提供指令和数据。存储器1740的一部分还可以包括非易失性随机存取存储器(non-volatile random access memory，NVRAM)。
本申请实施例中，存储器1740、通信接口1730以及存储器1740通过总线系统2020耦合在一起。其中，总线系统2020除包括数据总线之外，还可以包括电源总线、控制总线和状态信号总线等。为了便于描述，在图17中将各种总线都标为总线系统2020。
上述本申请实施例描述的方法可以应用于处理器1720中，或者由处理器1720实现。处理器1720可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器1720中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器1720可以是通用处理器(例如，微处理器或常规处理器)、数字信号处理器(digital signal processing，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field-programmable gate array，FPGA)或者其他可编程逻辑器件、分立门、晶体管逻辑器件或分立硬件组件，处理器1720可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。
结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。其中，软件模块可以位于随机 存储器、只读存储器、可编程只读存储器或带电可擦写可编程存储器(electrically erasable programmable read only memory，EEPROM)等本领域成熟的存储介质中。该存储介质位于存储器1740，处理器1720读取存储器1740中的信息，结合其硬件完成上述方法的步骤。
在上述实施例中，存储器存储的供处理器执行的指令可以以计算机程序产品的形式实现。其中，计算机程序产品可以是事先写入在存储器中，也可以是以软件形式下载并安装在存储器中。
计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包括一个或多个可用介质集成的服务器、数据中心等数据存储设备。例如，可用介质可以包括磁性介质(例如，软盘、硬盘或磁带)、光介质(例如，数字通用光盘(digital versatile disc，DVD))、或者半导体介质(例如，固态硬盘(solid state disk，SSD))等。
本申请实施例还提供了一种计算机可读存储介质。上述实施例中描述的方法可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。计算机可读介质可以包括计算机存储介质和通信介质，还可以包括任何可以将计算机程序从一个地方传送到另一个地方的介质。存储介质可以是可由计算机访问的任何目标介质。
作为一种可能的设计，计算机可读介质可以包括紧凑型光盘只读储存器(compact disc read-only memory，CD-ROM)、RAM、ROM、EEPROM或其它光盘存储器；计算机可读介质可以包括磁盘存储器或其它磁盘存储设备。而且，任何连接线也可以被适当地称为计算机可读介质。例如，如果使用同轴电缆，光纤电缆，双绞线，DSL或无线技术(如红外，无线电和微波)从网站，服务器或其它远程源传输软件，则同轴电缆，光纤电缆，双绞线，DSL或诸如红外，无线电和微波之类的无线技术包括在介质的定义中。如本文所使用的磁盘和光盘包括光盘(CD)，激光盘，光盘，数字通用光盘(digital versatile disc，DVD)，软盘和蓝光盘，其中磁盘通常以磁性方式再现数据，而光盘利用激光光学地再现数据。
上述的组合也应包括在计算机可读介质的范围内。以上，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (23)

  1. 一种基于空中下载技术OTA的通信方法，其特征在于，包括：
    获得第一信息和第二信息；所述第一信息包括第一软件版本信息和/或第一标识码；所述第二信息包括第一映射；所述第一映射包含第二软件版本信息和第二标识码的关联关系；所述标识码用于指示软件版本的权限信息；
    根据所述第一信息和所述第二信息，验证所述第一软件版本信息与所述第一映射对应的第二软件版本信息的一致性。
  2. 根据权利要求1所述的方法，其特征在于，所述根据所述第一信息和所述第二信息，验证所述第一软件版本信息与所述第一映射对应的第二软件版本信息的一致性，包括：
    在所述第一软件版本信息与所述第二软件版本信息不一致，和/或，所述第一标识码与所述第二标识码不一致的情况下，确定所述第一软件版本信息与所述第二软件版本信息不一致；
    或者，在所述第一软件版本信息与所述第二软件版本信息一致，和/或，所述第一标识码与所述第二标识码一致的情况下，确定所述第一软件版本信息与所述第二软件版本信息一致。
  3. 根据权利要求1或2所述的方法，其特征在于，所述方法还包括：
    在所述第一软件版本信息与所述第二软件版本信息不一致的情况下，更新所述第一软件版本信息和/或所述第一标识码；
    或者，在所述第一软件版本信息与所述第二软件版本信息一致的情况下，更新所述第一软件版本信息和/或所述第一标识码。
  4. 根据权利要求3所述的方法，其特征在于，在所述更新所述第一软件版本信息和/或所述第一标识码之前，所述方法还包括：
    向第一车辆发送第一任务，所述第一任务用于指示更新所述第一软件版本信息和/或所述第一标识码；
    其中，在所述第一软件版本信息与所述第二软件版本信息不一致的情况下，所述第一任务包括所述第一映射；或，
    在所述第一软件版本信息与所述第二软件版本信息一致的情况下，所述第一任务包括第二映射，所述第二映射包含第三软件版本信息和第三标识码的关联关系。
  5. 根据权利要求3或4所述的方法，其特征在于，所述方法还包括：
    向所述第一车辆发送第一软件包，所述第一软件包用于更新所述第一车辆对应的软件版本信息；
    其中，在所述第一软件版本信息与所述第二软件版本信息不一致的情况下，所述第一软件包包括所述第二标识码；或，
    在所述第一软件版本信息与所述第二软件版本信息一致的情况下，所述第一软件包包括所述第三标识码。
  6. 根据权利要求1-3任一项所述的方法，其特征在于，所述方法还包括：
    在所述第一软件版本信息与所述第二软件版本信息不一致的情况下，向服务器和/或第一车辆的显示设备发送所述第一软件版本信息、所述第一标识码和/或告警信息，所述告警信息用于指示所述第一车辆的标识码和/或软件版本信息，与所述服务器的映射关系不一致。
  7. 根据权利要求3所述的方法，其特征在于，所述更新所述第一软件版本信息和/或所述第一标识码，包括：
    接收来自服务器的第一任务，所述第一任务用于指示更新所述第一软件版本信息和/或所述第一标识码；
    其中，在所述第一软件版本信息与所述第二软件版本信息不一致的情况下，所述第一任务包括所述第一映射；或，
    在所述第一软件版本信息与所述第二软件版本信息一致的情况下，所述第一任务包括第二映射；所述第二映射包含第三软件版本信息和第三标识码的关联关系。
  8. 根据权利要求7所述的方法，其特征在于，所述方法还包括：
    接收来自所述服务器的第一软件包；所述第一软件包用于更新所述第一车辆对应的软件版本信息；
    其中，在所述第一软件版本信息与所述第二软件版本信息不一致的情况下，所述第一软件包包括所述第二标识码；或，
    在所述第一软件版本信息与所述第二软件版本信息一致的情况下，所述第一软件包包括所述第三标识码。
  9. 根据权利要求1-8任一项所述的方法，其特征在于，所述标识码包括第一法规相关软件标识码RXSWIN。
  10. 一种基于空中下载技术OTA的通信装置，其特征在于，所述装置包括：
    通信单元，用于获得第一信息和第二信息；所述第一信息包括第一软件版本信息和/或第一标识码；所述第二信息包括第一映射；所述第一映射包含第二软件版本信息和第二标识码的关联关系；所述标识码用于指示所述软件版本的权限信息；
    所述处理单元，还用于根据所述第一信息和所述第二信息，验证所述第一软件版本信息与所述第一映射对应的第二软件版本信息的一致性。
  11. 根据权利要求10所述的装置，其特征在于，所述处理单元，具体用于：
    在所述第一软件版本信息与所述第二软件版本信息不一致，和/或，所述第一标识码与所述第二标识码不一致的情况下，确定所述第一软件版本信息与所述第二软件版本信息不一致；
    或者，在所述第一软件版本信息与所述第二软件版本信息一致，和/或，所述第一标识码与所述第二标识码一致的情况下，确定所述第一软件版本信息与所述第二软件版本信息一致。
  12. 根据权利要求10或11所述的装置，其特征在于，所述处理单元，还用于：
    在所述第一软件版本信息与所述第二软件版本信息不一致的情况下，更新所述第一软件版本信息和/或所述第一标识码；
    或者，在所述第一软件版本信息与所述第二软件版本信息一致的情况下，更新所述第一软件版本信息和/或所述第一标识码。
  13. 根据权利要求12所述的装置，其特征在于，所述通信单元，具体用于：
    向第一车辆发送第一任务；所述第一任务用于指示更新所述第一软件版本信息和/或所述第一标识码；
    其中，在所述第一软件版本信息与所述第二软件版本信息不一致的情况下，所述第一 任务包括所述第一映射；或，在所述第一软件版本信息与所述第二软件版本信息一致的情况下，所述第一任务包括第二映射；所述第二映射包含第三软件版本信息和第三标识码的关联关系。
  14. 根据权利要求12或13所述的装置，其特征在于，所述通信单元，还用于：
    向所述第一车辆发送第一软件包；所述第一软件包用于更新所述第一车辆对应的软件版本信息；
    其中，在所述第一软件版本信息与所述第二软件版本信息不一致的情况下，所述第一软件包包括所述第二标识码；或，在所述第一软件版本信息与所述第二软件版本信息一致的情况下，所述第一软件包包括所述第三标识码。
  15. 根据权利要求10-12任一项所述的装置，其特征在于，所述通信单元，还用于：
    在所述第一软件版本信息与所述第二软件版本信息不一致的情况下，向服务器和/或第一车辆的显示设备发送所述第一软件版本信息、所述第一标识码和/或告警信息；所述告警信息用于指示所述第一车辆的标识码和/或软件版本信息，与所述服务器的映射关系不一致。
  16. 根据权利要求12所述的装置，其特征在于，所述通信单元，具体用于：
    接收来自服务器的第一任务，所述第一任务用于指示更新所述第一软件版本信息和/或所述第一标识码；
    其中，在所述第一软件版本信息与所述第二软件版本信息不一致的情况下，所述第一任务包括所述第一映射；或，在所述第一软件版本信息与所述第二软件版本信息一致的情况下，所述第一任务包括第二映射；所述第二映射包含第三软件版本信息和第三标识码的关联关系。
  17. 根据权利要求16所述的装置，其特征在于，所述通信单元，还用于：
    接收来自所述服务器的第一软件包；所述第一软件包用于更新所述第一车辆对应的软件版本信息；
    其中，在所述第一软件版本信息与所述第二软件版本信息不一致的情况下，所述第一软件包包括所述第二标识码；或，在所述第一软件版本信息与所述第二软件版本信息一致的情况下，所述第一软件包包括所述第三标识码。
  18. 根据权利要求10-17任一项所述的装置，其特征在于，所述标识码包括第一法规相关软件识别码RXSWIN。
  19. 一种基于OTA的通信装置，其特征在于，包括：至少一个处理器，用于调用存储器中的程序，以执行权利要求1-9任一项所述的方法。
  20. 一种基于OTA的通信装置，其特征在于，包括：至少一个处理器和接口电路，所述接口电路用于为所述至少一个处理器提供信息输入和/或信息输出，所述至少一个处理器用于执行权利要求1-9任一项所述的方法。
  21. 一种芯片，其特征在于，包括至少一个处理器和接口；
    所述接口，用于为所述至少一个处理器提供程序指令或者数据；
    所述至少一个处理器用于执行所述程序行指令，以实现如权利要求1-9中任一项所述的方法。
  22. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有指令，当所述指令被执行时，使得计算机执行如权利要求1-9任一项所述的方法。
  23. 一种计算机程序产品，其特征在于，包括计算机程序，当所述计算机程序被运行时，使得所述计算机执行如权利要求1-9任一项所述的方法。
PCT/CN2021/080863 2021-03-15 2021-03-15 基于空中下载技术ota的通信方法和装置 WO2022193096A1 (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
PCT/CN2021/080863 WO2022193096A1 (zh) 2021-03-15 2021-03-15 基于空中下载技术ota的通信方法和装置
CN202180000506.0A CN113168317A (zh) 2021-03-15 2021-03-15 基于空中下载技术ota的通信方法和装置
JP2023556732A JP2024510237A (ja) 2021-03-15 2021-03-15 オーバー・ザ・エア技術（ｏｔａ）に基づいた通信方法及び装置
EP21930692.5A EP4307734A4 (en) 2021-03-15 2021-03-15 COMMUNICATION METHOD AND DEVICE BASED ON OTA (OVER-THE-AIR) TECHNOLOGY

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2021/080863 WO2022193096A1 (zh) 2021-03-15 2021-03-15 基于空中下载技术ota的通信方法和装置

Publications (1)

Publication Number Publication Date
WO2022193096A1 true WO2022193096A1 (zh) 2022-09-22

Family

ID=76875983

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/080863 WO2022193096A1 (zh) 2021-03-15 2021-03-15 基于空中下载技术ota的通信方法和装置

Country Status (4)

Country Link
EP (1) EP4307734A4 (zh)
JP (1) JP2024510237A (zh)
CN (1) CN113168317A (zh)
WO (1) WO2022193096A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116232766A (zh) * 2023-05-06 2023-06-06 中国第一汽车股份有限公司 一种基于ota的数据加密系统及方法

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022175761A (ja) * 2021-05-14 2022-11-25 株式会社デンソー 車両用電子制御装置、車両用電子制御システム及び更新後構成情報判定プログラム
CN113590164B (zh) * 2021-08-31 2024-03-22 重庆长安汽车股份有限公司 一种整车控制器软件的升级方法及系统
WO2023108618A1 (zh) * 2021-12-17 2023-06-22 华为技术有限公司 一种基于空中下载ota技术的升级方法及通信装置
CN114827108B (zh) * 2022-06-22 2022-11-04 小米汽车科技有限公司 车辆升级方法、装置、存储介质、芯片及车辆

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110347420A (zh) * 2018-04-08 2019-10-18 中国电力科学研究院有限公司 一种配电终端软件版本一致性检测方法和系统
WO2020032043A1 (ja) * 2018-08-10 2020-02-13 株式会社デンソー 車両用電子制御システム、配信パッケージのダウンロード判定方法及び配信パッケージのダウンロード判定プログラム
US20200057630A1 (en) * 2018-08-14 2020-02-20 Hyundai Motor Company Method and Apparatus for Wirelessly Updating Software for Vehicle
US20200081701A1 (en) * 2018-09-07 2020-03-12 Baidu Online Network Technology (Beijing) Co., Ltd. Information Upgrading Method, Apparatus and Storage Medium for Automatic Driving Vehicle
CN111464977A (zh) * 2020-06-18 2020-07-28 华人运通(上海)新能源驱动技术有限公司 语音场景更新方法、装置、终端、服务器和系统

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7035635B2 (ja) * 2018-03-07 2022-03-15 トヨタ自動車株式会社 車両制御システム及び車両制御システムにおけるソフトウェアの整合性確認方法
JP7081223B2 (ja) * 2018-03-07 2022-06-07 トヨタ自動車株式会社 マスタ装置、マスタ、ソフトウェアの整合性を確認するための方法及びプログラム、車両

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110347420A (zh) * 2018-04-08 2019-10-18 中国电力科学研究院有限公司 一种配电终端软件版本一致性检测方法和系统
WO2020032043A1 (ja) * 2018-08-10 2020-02-13 株式会社デンソー 車両用電子制御システム、配信パッケージのダウンロード判定方法及び配信パッケージのダウンロード判定プログラム
US20200057630A1 (en) * 2018-08-14 2020-02-20 Hyundai Motor Company Method and Apparatus for Wirelessly Updating Software for Vehicle
US20200081701A1 (en) * 2018-09-07 2020-03-12 Baidu Online Network Technology (Beijing) Co., Ltd. Information Upgrading Method, Apparatus and Storage Medium for Automatic Driving Vehicle
CN111464977A (zh) * 2020-06-18 2020-07-28 华人运通(上海)新能源驱动技术有限公司 语音场景更新方法、装置、终端、服务器和系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4307734A4 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116232766A (zh) * 2023-05-06 2023-06-06 中国第一汽车股份有限公司 一种基于ota的数据加密系统及方法

Also Published As

Publication number Publication date
EP4307734A4 (en) 2024-04-10
EP4307734A1 (en) 2024-01-17
CN113168317A (zh) 2021-07-23
JP2024510237A (ja) 2024-03-06

Similar Documents

Publication Publication Date Title
WO2022193096A1 (zh) 基于空中下载技术ota的通信方法和装置
US10592231B2 (en) Vehicle information communication system
US11163549B2 (en) Vehicle information communication system
EP4202645A1 (en) Vehicle upgrading method and apparatus
US10061574B2 (en) Method and apparatus for multiple vehicle software module reflash
CN113176902B (zh) 车辆ecu的ota升级方法、电子设备、车辆及可读存储介质
CN110120970B (zh) 基于车联网的数据处理方法、装置及网关系统
EP4068083A1 (en) Upgrading method and apparatus
CN111263352A (zh) 车载设备的ota升级方法、系统、存储介质及车载设备
US9443359B2 (en) Vehicle electronic control unit calibration
US11579865B2 (en) Vehicle information communication system
CN110362329A (zh) 一种版本更新检查方法及系统
EP3405923B1 (en) Updating a controller unit in a vehicle
JP7485106B2 (ja) 車両、車載制御装置、情報処理装置、車両用ネットワークシステム、アプリケーションプログラムの提供方法、及びプログラム
US20240069906A1 (en) Server, software update system, distribution method, and non-transitory storage medium
EP4375802A1 (en) Over-the-air (ota) upgrade method and apparatus
CN113296811A (zh) 基于联网车载终端的车身ota远程升级系统及方法
CN117242428A (zh) 软件升级方法和相关产品
CN114969223A (zh) 一种地图更新方法、装置及系统
US20230036444A1 (en) System, method, and non-transitory storage medium
WO2023108618A1 (zh) 一种基于空中下载ota技术的升级方法及通信装置
US20230033832A1 (en) System, center, method, and non-transitory storage medium
CN111338826B (zh) 一种电子设备以及设备联动控制系统、方法
US20220284743A1 (en) Center device and in-vehicle electronic control device
EP4345604A1 (en) Over-the-air (ota) upgrading method and apparatus

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21930692

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023556732

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 2021930692

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2021930692

Country of ref document: EP

Effective date: 20231008

NENP Non-entry into the national phase

Ref country code: DE