Over-the-air (OTA) based communication method and device
The OTA-based communication method and device address the challenge of maintaining software version consistency and compliance during vehicle updates by verifying and aligning software versions with regulatory identification numbers, ensuring safe and compliant upgrades.
Patent Information
- Application Number
- JP2023556732
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2021-03-15
- Publication Date
- 2025-11-17
- Estimated Expiration
- 2041-03-15
AI Technical Summary
The challenge of maintaining software version consistency and regulatory compliance during over-the-air (OTA) updates in vehicles, as changes can affect admission parameters and require retesting, is unresolved.
An OTA-based communication method and device that verifies and maintains the match between software version information and identification numbers, such as RXSWIN, to ensure consistency between the vehicle end and the cloud, preventing unauthorized changes and ensuring successful software upgrades.
Ensures that OTA software updates align with admission standards, preventing unauthorized changes and ensuring safe and compliant software upgrades by maintaining the match between software versions and regulatory identification numbers.
Smart Images

Figure 0007771207000001 
Figure 0007771207000002 
Figure 0007771207000003
Abstract
Description
[Technical Field]
[0001] This application relates to the field of communications technology, in particular over-the-air technology. ( OTA ) The present invention relates to a communication method and apparatus based on the above. [Background technology]
[0002] With the development of autonomous driving, people are increasingly demanding the computing and control capabilities of vehicles. The number of functions provided to users in the form of software is increasing. Therefore, software-defined vehicles are becoming an important trend in vehicle development. When vehicle software needs to be installed or updated, over-the-air technology (OTA) may be used to connect to the cloud and install or update vehicle software.
[0003] However, while OTA brings convenience to people, it also brings challenges to vehicle admission. Admission can be understood as a process in which a series of tests for safety, emissions, etc. are performed to satisfy the requirements of relevant standards before a vehicle is released to the market. Specifically, updating vehicle software using OTA may change the vehicle's admission parameters after the vehicle is released to the market. For example, after a vehicle's battery management software is upgraded using OTA, the vehicle's endurance mileage may increase, and the endurance mileage of the vehicle may no longer match the endurance mileage measured during admission. Furthermore, the data tested during vehicle admission becomes invalid, and the test must be performed again. Therefore, the software version upgraded using OTA may not match the software version used during admission. This poses challenges to the development of OTA. Summary of the Invention
[0004] The present application provides an over-the-air technology solution to ensure the successful upgrade of OTA maintenance and software installation processes, and further maintain the safety of the vehicle. ( OTA ) A communication method and apparatus based on the method are provided.
[0005] According to a first aspect, there is provided an OTA-based communication method, the method including: acquiring first information and second information, where the first information includes first software version information and / or a first identification number, and the second information includes a first mapping, where the first mapping includes an association relationship between the second software version information and the second identification number, and the identification number indicates software version permission information; and verifying a match between the first software version information and the second software version information corresponding to the first mapping based on the first information and the second information.
[0006] In this way, the match between the first information and the second information can be verified by using the matching relationship between the identification number and software version of the first information and the second information, so that the consistency between the software version and the identification number at the vehicle end and / or server (or called the cloud or cloud device) is maintained so as to ensure successful upgrade of the vehicle software and keep the vehicle safe during the OTA maintenance and software installation process.
[0007] Referring to the first aspect, in a possible implementation, verifying a match between the first software version information and the second software version information corresponding to the first mapping based on the first information and the second information includes determining that the first software version information does not match the second software version information when the first software version information does not match the second software version information and / or the first identification number does not match the second identification number, or determining that the first software version information matches the second software version information when the first software version information matches the second software version information and / or the first identification number matches the second identification number.
[0008] In this way, the agreement between the first software version information and the second software version information can be verified by using the cloud or the vehicle end. Furthermore, the consistency between the software version and the identification number at the vehicle end and / or the cloud can be maintained to prevent the software version and / or the identification number from being tampered with and ensure the successful upgrade of the vehicle software that is upgraded by using OTA.
[0009] Referring to the first aspect, in a possible implementation, the method further includes updating the first software version information and / or the first identification number when the first software version information does not match the second software version information, or updating the first software version information and / or the first identification number when the first software version information matches the second software version information.
[0010] In this way, the cloud and vehicle end can maintain consistency between the software version and / or identification number at the vehicle end and the mapping relationship of the cloud device based on the matching relationship between the identification number and the software version, so as to eliminate cases where the software version upgraded by using OTA does not match the software version used during admission and ensure successful upgrade of the vehicle software.
[0011] Referring to the first aspect, in a possible implementation, prior to updating the first software version information and / or the first identification number, the method further includes transmitting a first task to the first vehicle, the first task instructing the first vehicle to update the first software version information and / or the first identification number. When the first software version information does not match the second software version information, the first task includes a first mapping, or when the first software version information matches the second software version information, the first task includes a second mapping. The second mapping includes an association relationship between third software version information and the third identification number. The third software version information is different from the second software version information and / or the third identification number is different from the second identification number.
[0012] In this way, based on the consistency between the software version and the identification number at the vehicle end and / or the cloud, the matching relationship between the software version information and the identification number can be ensured in the OTA software upgrade process, so as to eliminate the case where the software version upgraded by using OTA does not match the software version used during admission, and to ensure the successful upgrade of the vehicle software.
[0013] Referring to the first aspect, in a possible implementation, the method further includes transmitting a first software package to the first vehicle, the first software package being used to update software version information corresponding to the first vehicle. When the first software version information does not match the second software version information, the first software package includes a second identification number, or when the first software version information matches the second software version information, the first software package includes a third identification number.
[0014] In this way, based on the consistency between the software version and the identification number at the vehicle end and / or the cloud, the matching relationship between the software version information and the identification number can be ensured in the OTA software upgrade process, so as to eliminate the case where the software version upgraded by using OTA does not match the software version used during admission, and to ensure the successful upgrade of the vehicle software.
[0015] Referring to the first aspect, in a possible implementation, the method further includes, when the first software version information does not match the second software version information, transmitting the first software version information, the first identification number, and / or alarm information to the server and / or a display device of the first vehicle, wherein the alarm information indicates that the identification number and / or software version information of the first vehicle does not match the mapping relationship of the server.
[0016] In this way, the cloud device and / or the display device of the first vehicle can perform timely processing based on the alarm information sent by the vehicle end, so as to further ensure the successful upgrade of the vehicle software.
[0017] Referring to the first aspect, in a possible implementation, updating the first software version information and / or the first identification number includes receiving a first task from a server, the first task instructing to update the first software version information and / or the first identification number. When the first software version information does not match the second software version information, the first task includes a first mapping, or when the first software version information matches the second software version information, the first task includes a second mapping. The second mapping includes an association relationship between third software version information and the third identification number. The third software version information is different from the second software version information and / or the third identification number is different from the second identification number.
[0018] In this way, based on the consistency between the software version and the identification number at the vehicle end and / or the cloud, the matching relationship between the software version information and the identification number can be ensured in the OTA software upgrade process, so as to eliminate the case where the software version upgraded by using OTA does not match the software version used during admission, and to ensure the successful upgrade of the vehicle software.
[0019] Referring to the first aspect, in a possible implementation, the method further includes receiving a first software package from the server, the first software package being used to update software version information corresponding to the first vehicle. When the first software version information does not match the second software version information, the first software package includes a second identification number, or when the first software version information matches the second software version information, the first software package includes a third identification number.
[0020] In this way, based on the consistency between the software version and the identification number at the vehicle end and / or the cloud, the matching relationship between the software version information and the identification number can be ensured in the OTA software upgrade process, so as to eliminate the case where the software version upgraded by using OTA does not match the software version used during admission, and to ensure the successful upgrade of the vehicle software.
[0021] Referring to the first aspect, in a possible implementation, a first vehicle includes a plurality of electronic control units associated with a first software package. Updating software of the first vehicle based on the first software package includes: sending a first software package corresponding to each of the N electronic control units to the N electronic control units, where N is a positive integer; receiving N software installation results from the N electronic control units; and, when the N software installation results indicate that any one or more of the N software packages failed to install, rolling back a vehicle software version and an identification number of the first vehicle.
[0022] In this way, based on the consistency between the software version and the identification number at the vehicle end and / or the cloud, the matching relationship between the software version information and the identification number can be ensured in the OTA software upgrade process, so as to eliminate the case where the software version upgraded by using OTA does not match the software version used during admission, and to ensure the successful upgrade of the vehicle software.
[0023] Referring to the first aspect, in a possible implementation, alarm information from a first vehicle is received and the alarm information is displayed.
[0024] Referring to the first aspect, in a possible implementation, the identification number is a first regulation-related software identification number.(regulation-related software identification number, RXSWIN ) In this way, the matching relationship between RXSWIN and the software version can be used to ensure consistency between RXSWIN and the software version in the OTA maintenance and software installation process and ensure successful upgrade of the vehicle software.
[0025] In this way, alarm information indicating a discrepancy between software version information and identification number in the system can be intuitively displayed to the user on the user interface, which helps the user to take subsequent action in a timely manner and further ensures the successful upgrade of vehicle software.
[0026] According to a second aspect, an embodiment of the present application provides a communication device based on TA. The communication unit is configured to acquire first information and second information, where the first information includes first software version information and / or a first identification number, and the second information includes a first mapping, where the first mapping includes an association relationship between the second software version information and the second identification number, and the identification number indicates permission information of the software version. The processing unit is further configured to verify, based on the first information and the second information, a match between the first software version information and the second software version information corresponding to the first mapping.
[0027] With reference to the second aspect, in a possible implementation, the processing unit is particularly configured to determine that the first software version information does not match the second software version information when the first software version information does not match the second software version information and / or the first identification number does not match the second identification number, or to determine that the first software version information matches the second software version information when the first software version information matches the second software version information and / or the first identification number matches the second identification number.
[0028] Referring to the second aspect, in a possible implementation, the processing unit is further configured to update the first software version information and / or the first identification number when the first software version information does not match the second software version information, or to update the first software version information and / or the first identification number when the first software version information matches the second software version information.
[0029] Referring to the second aspect, in a possible implementation, the communication unit is specifically configured to transmit a first task to the first vehicle, the first task instructing the first vehicle to update the first software version information and / or the first identification number. When the first software version information does not match the second software version information, the first task includes a first mapping, or when the first software version information matches the second software version information, the first task includes a second mapping. The second mapping includes an association relationship between third software version information and the third identification number. The third software version information is different from the second software version information and / or the third identification number is different from the second identification number.
[0030] Referring to the second aspect, in a possible implementation, the communication unit is further configured to transmit a first software package to the first vehicle, the first software package being used to update software version information corresponding to the first vehicle. When the first software version information does not match the second software version information, the first software package includes a second identification number, or when the first software version information matches the second software version information, the first software package includes a third identification number.
[0031] Referring to the second aspect, in a possible implementation, the communication unit is further configured to transmit the first software version information, the first identification number, and / or alarm information to the server and / or the display device of the first vehicle when the first software version information does not match the second software version information, and the alarm information indicates that the identification number and / or software version information of the first vehicle does not match the mapping relationship of the server.
[0032]
[0013] Referring to the second aspect, in a possible implementation, the communication unit is specifically configured to receive a first task from the server, the first task instructing to update the first software version information and / or the first identification number, and when the first software version information does not match the second software version information, the first task includes a first mapping, or when the first software version information matches the second software version information, the first task includes a second mapping. The second mapping includes an association relationship between the third software version information and the third identification number. The third software version information is different from the second software version information and / or the third identification number is different from the second identification number.
[0033] Referring to the second aspect, in a possible implementation, the communication unit is further configured to receive a first software package from the server, the first software package being used to update software version information corresponding to the first vehicle, and when the first software version information does not match the second software version information, the first software package includes a second identification number, or when the first software version information matches the second software version information, the first software package includes a third identification number.
[0034] With reference to the second aspect, in a possible implementation, the communication unit is particularly configured to send first software packages corresponding to the N electronic control units to the N electronic control units, where N is a positive integer. The communication unit is particularly configured to receive N software installation results from the N electronic control units. The processing unit is particularly configured to roll back a vehicle software version and an identification number of the first vehicle when the N software installation results indicate that any one or more of the N software packages failed to install.
[0035] In a possible implementation, the communication unit is particularly configured to receive alarm information from the first vehicle, and the display unit is particularly configured to display the alarm information.
[0036] Referring to the second aspect, in a possible implementation, the identification number is a first regulation-related software identification number. ( RXSWIN ) Includes.
[0037] According to a third aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program or instructions, which, when executed by a computer, can cause the computer to perform an OTA-based communication method according to the first aspect or any one of the possible implementations of the first aspect.
[0038] According to a fourth aspect, an embodiment of the present application provides an OTA-based communication device. The device includes a processor and a memory. The memory stores instructions. When the instructions are executed by the processor, an OTA-based communication method according to the first aspect or any one of the possible implementations of the first aspect is performed.
[0039] According to a fifth aspect, the present application provides a chip or 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. The at least one processor is configured to execute a computer program or instructions to perform an OTA-based communication method according to the first aspect or any one of the possible implementations of the first aspect. The communication interface of the chip may be an input / output interface, a pin, a circuit, etc.
[0040] In a possible implementation, the chip or chip system described herein further includes at least one memory for storing instructions, which may be a storage unit within the chip, such as a register or cache, or may be a storage unit of the chip (e.g., a read-only memory or a random access memory).
[0041] According to a sixth aspect, an embodiment of the present application provides a computer program product which, when executed on one or more processors, performs a method according to the first aspect or any one of the possible implementations of the first aspect.
[0042] The technical solutions of the second to sixth aspects of the present application correspond to the technical solutions of the first aspect of the present application, and the advantageous effects achieved by those other aspects and corresponding feasible implementations are similar, and the details will not be described again. [Brief explanation of the drawings]
[0043] [Figure 1] FIG. 2 is a schematic diagram of the correspondence between RXSWIN and software versions according to an embodiment of the present application. [Figure 2] FIG. 2 is a schematic diagram of a first application scenario according to an embodiment of the present application; [Figure 3] FIG. 1 is a schematic diagram of a system architecture for vehicle software updates according to an embodiment of the present application. [Figure 4] FIG. 2 is a schematic diagram of a second application scenario according to an embodiment of the present application. [Figure 5] FIG. 10 is a schematic diagram of a third application scenario according to an embodiment of the present application. [Figure 6] 1 is a schematic flowchart of an OTA-based communication method according to an embodiment of the present application; [Figure 7] 1 is a schematic flowchart of maintaining consistency between identification numbers and software version information by the cloud according to an embodiment of the present application; [Figure 8] 1 is a schematic flow chart of maintaining consistency between identification number and software version information by a vehicle end according to an embodiment of the present application; [Figure 9] FIG. 2 is a schematic diagram of an interface displaying alarm information according to an embodiment of the present application. [Figure 10] 1 is a schematic flow chart of making a match decision by the cloud according to an embodiment of the present application; [Figure 11] 1 is a schematic flow chart of a software update according to an embodiment of the present application; [Figure 12] 1 is a schematic flow chart of distributing software packages to vehicle end by cloud according to an embodiment of the present application; [Figure 13] 1 is a schematic flow chart of installing a software package at the vehicle end according to an embodiment of the present application. [Figure 14] 10 is another schematic flow chart of installing a software package at the vehicle end according to an embodiment of the present application. [Figure 15] 1 is a schematic diagram of the structure of an OTA-based communication device according to an embodiment of the present application; [Figure 16] FIG. 2 is a schematic diagram of a hardware structure of a control device according to an embodiment of the present application. [Figure 17] 1 is a schematic diagram of a chip structure according to an embodiment of the present application. DETAILED DESCRIPTION OF THE INVENTION
[0044] In order to clearly describe the technical solutions in the embodiments of the present application, terms such as "first" and "second" are used in the embodiments of the present application to distinguish between the same or similar items having essentially the same function or purpose. For example, a first identification number and a second identification number are used to distinguish between different identification numbers, and the first identification number and the second identification number are not limited. Those skilled in the art can understand that terms such as "first" and "second" do not limit the quantity or execution order, and terms such as "first" and "second" do not indicate clear differences.
[0045] It should be noted that terms such as "example" or "for example" are used herein to denote an example, instance, or illustration. Any embodiment or design scheme described herein as "example" or "for example" should not be construed as preferred or advantageous over other embodiments or design schemes. Indeed, the use of terms such as "example" or "for example" is intended to concretely present the relevant concept.
[0046] As used herein, "at least one" means one or more, and "plurality" means two or more. "And / or" describes an association relationship between related objects and indicates that three relationships may exist. For example, A and B may represent the following: A alone is present, both A and B are present, and B alone is present. Here, A alone and B alone may be singular or plural. The character " / " generally indicates a "logical or" relationship between related objects. "At least one of" a following item or similar phrases refers to any combination of these items, including any combination of a single item or multiple items. For example, "at least one of" a, b, or c can represent: a, b, c, a and b, a and c, b and c, or a, b, and c, where a, b, and c may be singular or plural.
[0047] With the development of autonomous driving, people are increasingly demanding vehicle computing and control capabilities. The number of functions provided to users in the form of software is increasing. Therefore, software-defined vehicles are becoming an important trend in vehicle development. Software-defined vehicles, like computers or smartphones, require easy software installation and update, so that various vehicle functions can be frequently used and updated. Generally, when vehicle software needs to be updated, users drive their vehicles to a 4S shop or repair shop, where specialized technicians use dedicated equipment to refresh the vehicle software. Vehicle OTA provides a technical means for remotely upgrading vehicle software or correcting defects in vehicle software. Users can use OTA technology to connect to the cloud and download and install software. OTA can reduce the time and space limitations of vehicle software upgrades. For this reason, OTA is widely used in the automotive field.
[0048] However, while OTA brings convenience to people, it also brings challenges to vehicle admission. Admission can be understood as a process in which a series of tests, such as safety and emissions tests, are conducted on a vehicle to ensure it meets the requirements of relevant standards before it is released to the market. Specifically, vehicle defects can cause serious damage to people and property. For this reason, vehicles are special products. Before being released to the market, vehicles must pass an admission test. Only after passing the admission test can a vehicle be released to the market. After a vehicle product has applied for and passed the admission test, the vehicle regulatory authority may record the vehicle's admission information and make it publicly available. After the admission, the vehicle is available for sale. The announcement may include basic information such as the vehicle's wheelbase, weight, or emissions, as well as technical characteristic parameter information such as mileage or maximum vehicle speed.
[0049] To ensure the manufacturing consistency of the vehicle after admission, the supervisory department may periodically spot check the relevant parameters of the vehicle product and compare those parameters with published information. If the published information does not match the admission parameters, the manufacturing consistency has been violated and the vehicle manufacturer may be required to make corrections or may be required to implement measures such as halting production.
[0050] After a vehicle is released to the market, vehicle software may be updated using OTA. However, during the update process, the software test parameters measured during admission may change. For example, after a vehicle's battery management software is upgraded using OTA, the vehicle's endurance mileage may increase, resulting in the endurance mileage no longer matching the endurance mileage measured during admission. Furthermore, the data tested during vehicle admission becomes invalid, and testing must be performed again. Therefore, the software version upgraded using OTA may not match the software version used during admission. This poses challenges for OTA development. Based on this, the World Forum for Harmonization of Vehicle Regulations under the United Nations Economic Commission for Europe (UNECE) has established an OTA Working Group to discuss incorporating OTA into the admission supervision system. It has been stated that if a vehicle's OTA may affect admission consistency, a request for admission change must be submitted to the admission supervision authority before the OTA upgrade is performed. To supervise such changes, a regulatory-related software identification number (RSI) is required. (RRXSWIN has been proposed. RXSWIN can record the relationship between software versions and admissions. The function of RXSWIN is to record and track software and software upgrades that affect admissions from the point of view of admission regulations, and to help admission authorities manage vehicle software upgrades. Changes in RXSWIN can indicate changes in admissions caused by software upgrades.
[0051] For example, Figure 1 is a schematic diagram of the correspondence between RXSWIN and software versions according to an embodiment of the present application. As shown in Figure 1a, the initial RXSWIN and the software version corresponding to the initial RXSWIN may be set during admission. For example, the initial RXSWIN is R79 110. The software versions corresponding to R79 110 may include software version v1.0 corresponding to a power steering electronic control unit (ECU), software version v2.0 corresponding to a body stabilization ECU, and software version v1.0 corresponding to a vehicle control ECU.
[0052] After the software is upgraded via OTA, the upgraded software can be shown in the diagram of correspondence between the upgraded RXSWIN and the software version, as shown in Figure 1b. In this case, the software upgraded via OTA does not change the test data corresponding to the software during admission. Therefore, after software that does not affect admission is upgraded, the software version information related to RXSWIN may change, but RXSWIN itself remains unchanged. In this case, the software versions corresponding to the R79 110 may include software version v1.1 corresponding to the power steering ECU, software version v2.2 corresponding to the body stabilization ECU, and software version v1.0 corresponding to the vehicle control ECU.
[0053] After the software is further upgraded via OTA, the upgraded software can be represented by a schematic diagram of the matching relationship between RXSWIN and the software version of the upgraded software that affects admission, as shown in Figure 1c. After the software that affects admission is upgraded, the software version information related to RXSWIN is changed, and RXSWIN is modified. For example, RXSWIN is updated from R79110 to R79111. In this case, the software versions corresponding to R79111 may include software version v2.0 corresponding to the power steering ECU, software version v2.2 corresponding to the body stabilization ECU, and software version v1.0 corresponding to the vehicle control ECU. The OTA upgrade allows the software version corresponding to the power steering ECU to be upgraded from the original v1.1 to v2.0. The power steering ECU upgrade results in changes to the test parameters corresponding to the software being admitted. Therefore, RXSWIN is updated from R79110 to R79111, and RXSWIN identifies that the OTA upgrade affects the admission parameters.
[0054] In other words, as shown in FIG. 1, RXSWIN may be applied to software upgrades based on OTA, and the correspondence between RXSWIN and the software version is shown. However, during the OTA maintenance and software installation process, consistency between RXSWIN and the software version at the vehicle end and the cloud cannot be ensured, and if the software version upgraded using OTA does not match the software version used during admission, it cannot be properly rejected. As a result, it is difficult to maintain safe upgrades of vehicle software. Currently, there is no suitable method for managing RXSWIN and maintaining consistency between RXSWIN and the software version at the vehicle end and / or the cloud.
[0055] In view of this, the present embodiment provides an OTA-based communication method and device, which obtains first information and second information in an OTA maintenance and software installation process, and verifies the agreement between the first information and the second information based on the matching relationship between the identification number and the software version by using the matching between the identification number and the software version in the first information and the second information. Furthermore, if the software version upgraded by using OTA does not match the software version used during admission, it can be eliminated by maintaining consistency between the software version and the identification number at the vehicle end and / or the cloud, so as to ensure the successful upgrade of the vehicle software.
[0056] Optionally, the identification number may be RXSWIN.
[0057] To better understand the method in the embodiment of the present application, the following first describes an application scenario to which the embodiment of the present application is applied.
[0058] In a possible implementation, the OTA-based communication method provided in the embodiments of the present application may be applied to various types of vehicle OTA maintenance and upgrade scenarios, such as scenarios where consistency between identification numbers and software version information is maintained by data exchange between the vehicle end and a cloud device, and scenarios where vehicle software is downloaded or updated. There may be one or more vehicle end and / or cloud devices.
[0059] The vehicle end (also referred to as a vehicle or a vehicle end device) may be any type of vehicle that performs a software upgrade, any type of vehicle auxiliary device (e.g., a vehicle charging pile), etc. This is not particularly limited in the embodiments of the present application.
[0060] The cloud (also referred to as a cloud device or server) may be an OTA server configured to distribute the vehicle upgrade package, or may be a proxy server. For example, the proxy server may be a server that provides services to a vehicle platoon. When the cloud device is a proxy server, the proxy server may first establish secure communication with the OTA server through two-way authentication. Then, the proxy server sends the vehicle's hardware and software information to the OTA server. After generating the vehicle upgrade package, the OTA server may distribute the vehicle upgrade package to the proxy server. It may be understood that the OTA server may alternatively divide the vehicle upgrade package into blocks and distribute the blocks to multiple proxy servers.
[0061] Alternatively, the cloud may be a software client server configured to upgrade the software, or may be a platoon server or any other possible server that obtains and updates software from the software client server.
[0062] Alternatively, the cloud may be any type of vehicle, any type of vehicle auxiliary device (e.g., a vehicle charging pile), or a mobile terminal (e.g., a mobile phone, a tablet, or a wearable device), which is not particularly limited in the embodiments of the present application.
[0063] The vehicle and the cloud device may establish a communication connection. For example, the vehicle and the cloud device may establish a communication connection by using a protocol such as hypertext transfer protocol (HTTP) or hypertext transfer protocol over secure socket layer (HTTPS), although this is not a limitation of the present embodiment.
[0064] 2 is a schematic diagram of an example of a first application scenario according to an embodiment of the present application. As shown in FIG. 2, the scenario may include a vehicle 201 and a software OTA cloud device 202. The vehicle 201 is any type of vehicle on which a software OTA client is installed. The software OTA cloud device 202 is a server that provides OTA upgrades and is configured to store software packages, store mapping relationships between identification numbers (e.g., RXSWIN) and software versions, and the like. When updating software in the vehicle 201, the software OTA cloud device 202 may obtain identification numbers and / or software version information of each piece of software on the software OTA client in the vehicle 201 and compare the identification numbers and / or software version information with the mapping relationships between identification numbers and software versions stored in the software OTA cloud device 202. When the identification number and / or software version information of each software of vehicle 201 matches the mapping relationship, software OTA cloud device 202 may automatically send or send according to a request command of the software OTA client a software package to the software OTA client in vehicle 201, where the software package includes the identification number. The software OTA client of vehicle 201 may upgrade its software and identification number based on the software package from software OTA cloud device 202.
[0065] There may be one or more vehicles 201 and one or more software OTA cloud devices 202. This is not particularly limited in the embodiment of the present application.
[0066] In a possible implementation, the software OTA cloud device may alternatively be a vehicle manufacturer OTA cloud device, in which case the vehicle manufacturer OTA cloud device may be an OTA server configured to distribute vehicle upgrade packages.
[0067] The following describes the process of implementing a software OTA cloud device and a vehicle manufacturer OTA cloud device in a vehicle. For example, Figure 3 is a schematic diagram of a system architecture for updating vehicle software according to an embodiment of the present application. As shown in Figure 3, the system may include a vehicle manufacturer OTA cloud device 301, a software OTA cloud device 302, a master OTA client 303, and a software OTA client 304.
[0068] Vehicle manufacturer OTA cloud device 301 may be a server of a vehicle manufacturer or a vehicle software service provider, and is configured to manage vehicle software and store software data. The vehicle software may include body control software, etc. Software OTA cloud device 302 may be configured to store software packages, store a mapping relationship between identification numbers and software version information, etc. Vehicle manufacturer OTA cloud device 301 may interact with software OTA cloud device 302. The software information of vehicle manufacturer OTA cloud device 301 is from software OTA cloud device 302, or vehicle manufacturer OTA cloud device 301 may determine the software information.
[0069] It should be noted that an OTA upgrade in a vehicle may include two levels: a master node and a subordinate node. As shown in FIG. 3, the master OTA client 303 corresponds to the master node and may receive a vehicle upgrade package, split the vehicle upgrade package, and distribute the split upgrade package to multiple subordinate clients controlled by the master OTA client 303. The software OTA client 304 corresponds to a subordinate node and may be a subordinate OTA client controlled by the master OTA client 303. The software OTA client 304 may be used as part of the vehicle OTA upgrade to perform the software update.
[0070] Therefore, there are two possible software update methods in the system architecture. In a possible implementation, 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 Figure 1. The details will not be described again here.
[0071] In another possible implementation, the vehicle manufacturer OTA cloud device 301, the master OTA client 303, and the software OTA client 304 interact with each other to update software. For example, the vehicle manufacturer OTA cloud device 301 may update the master OTA client 303 (or the software OTA client 304) by using a vehicle upgrade package based on the mapping relationship between the identification number and software version information stored in the vehicle manufacturer OTA cloud device 301 and the consistency of the software version and / or identification number obtained from the master OTA client 303 (or the software OTA client 304). 303 The Master OTA Client may send the software package that needs to be updated to the Master OTA Client. 303 receives and downloads the vehicle upgrade package, splits the vehicle upgrade package, and sends the split vehicle upgrade package to the software OTA client 304. The software OTA client 304 updates the software and identification number based on the software packages in the split vehicle upgrade package.
[0072] 4 is a schematic diagram of an example of a second application scenario according to an embodiment of the present application. As shown in FIG. 4, 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.
[0073] Server 401 may be a vehicle platoon server. The vehicle platoon server may obtain, in advance from an OTA server, vehicle upgrade packages required by the vehicle platoon (e.g., including first vehicle 402, second vehicle 403, second vehicle 404, and second vehicle 405) served by the vehicle platoon server.
[0074] During scheduled maintenance of the vehicle platoon, the first vehicle 402, the second vehicle 403, the second vehicle 404, and the second vehicle 405 connect to the vehicle platoon server using a network connection such as wireless fidelity (Wi-Fi). Upon receiving an upgrade package download notification, the vehicle platoon server performs bidirectional authentication (e.g., a public key infrastructure-based authentication method) with the first vehicle 402, the second vehicle 403, the second vehicle 404, and the second vehicle 405. After successful authentication, the vehicle platoon server encrypts the upgrade package encryption key k (by using the vehicle's public key) and distributes the encrypted encryption key k to the first vehicle 402, the second vehicle 403, the second vehicle 404, and the second vehicle 405.
[0075] For example, first vehicle 402, second vehicle 403, second vehicle 404, and second vehicle 405 may all use key k to decrypt the key and download vehicle software packages needed by first vehicle 402, second vehicle 403, second vehicle 404, and second vehicle 405 from the server. For example, first vehicle 402 may complete a software update based on a complete vehicle upgrade package. The vehicle upgrade package may include a software package used to update the identification number. First vehicle 402 may update its software and identification number based on the software package.
[0076] 5 is a schematic diagram of an example of a third application scenario according to an embodiment of the present application. As shown in FIG. 5, the application scenario may include a vehicle 501 and a vehicle auxiliary device 502. The vehicle 501 may be any type of vehicle. The vehicle auxiliary device 502 may be a vehicle charging pile or any other terminal device (e.g., a mobile phone or a tablet) that supports vehicle OTA updates. The vehicle auxiliary device 502 may send to the vehicle 501 a software package that needs to be updated based on the mapping relationship between the identification number and the software version stored in the vehicle auxiliary device 502 and the consistency of the software version and / or the identification number obtained from the vehicle 501. The vehicle 501 may update the software and the identification number based on the received software package.
[0077] To aid in understanding the embodiments of the present application, a brief explanation of some terminology used in the present application will first be provided.
[0078] 1. Vehicle OTA is a process in which a vehicle downloads a software update package from a remote server over a network to update the vehicle's system. For example, but without limitation, each vehicle OTA update corresponds to one vehicle upgrade package and one vehicle version number, and one vehicle upgrade package includes software for multiple ECUs in the vehicle.
[0079] 2. The vehicle manufacturer OTA cloud device refers to a cloud service provided by a vehicle manufacturer or a service provider. The vehicle manufacturer OTA cloud device is responsible for managing information about upgrade tasks, software upgrade packages, identification numbers, etc. on the cloud and delivering the information to vehicles whose software needs to be upgraded via the OTA method. In the OTA method, access may be performed using Wi-Fi, long-term evolution (LTE), 5th generation (5G) mobile communication systems or new radio (NR) systems, satellites, etc.
[0080] 3. Software OTA cloud device refers to a cloud service for software, which is responsible for managing information about specific vehicle software, identification numbers, etc. on the cloud, and delivering the information to users who need to upgrade or vehicles that need to be upgraded via OTA.
[0081] The vehicle manufacturer OTA cloud device or software OTA cloud device in embodiments of the present application may be collectively referred to as the OTA cloud, and is configured to update software and identification numbers.
[0082] 4. Master node (Update Master, or Master node for short) is software deployed on the vehicle's ECU. The master node is responsible for centrally controlling the vehicle OTA upgrade, downloading the vehicle upgrade package from the OTA cloud, splitting the vehicle upgrade package, and distributing the split upgrade package to the corresponding ECU.
[0083] Alternatively, the master node may be a modular unit that resides independently in the vehicle, which is not a limitation of the present embodiment.
[0084] 5. Electronic control units include autonomous driving controllers, cockpit controllers, telematics boxes (T-Boxes), gateways, etc. For software upgrades of ECUs, software upgrade packages may be downloaded from the OTA cloud and installed to perform the upgrade. Alternatively, under the centralized control and coordination of the master node, the master node may split the vehicle upgrade package and distribute the split vehicle upgrade packages to obtain the software upgrade packages for the upgrade.
[0085] The following describes in detail the technical solutions of the present application and how the technical problems mentioned above are solved by using specific embodiments. The following specific embodiments may be implemented independently or in combination with each other, and the same or similar concepts or processes may not be repeatedly described in some embodiments.
[0086] 6 is a schematic flowchart of an OTA-based communication method according to an embodiment of the present application. As shown in FIG. 6, the method may include the following steps:
[0087] S601: First information and second information are acquired.
[0088] In this embodiment of the present application, the first information and the second information may be information used at the vehicle end and / or the cloud to verify the consistency between the software version information and the identification number. For example, the first information may include first software version information and / or the first identification number, and the second information may include a first mapping. The first mapping includes an association relationship between second software version information and the second identification number. The first information may be from the vehicle end, and the second information may be from the cloud.
[0089] In this embodiment of the present application, the identification number may indicate permission information of the software version, where permission may be understood as a restriction on allowing admission of a vehicle.
[0090] For example, the identification number may be another identifier such as RXSWIN. The software version information may be information used to distinguish between different software versions. For example, the software version information may be other information such as a software version number.
[0091] It can be understood that the identification number and software version information may include other contents based on the actual scenario, which is not limited in this embodiment of the present application.
[0092] For example, the entity that acquires the first information and the second information may be a cloud or a vehicle end. When the executing entity is a cloud, the vehicle end may report the first information to the cloud, and then the cloud may receive the first information reported by the vehicle end, acquire the second information stored in the cloud, and further verify a match between the first information and the second information. Alternatively, when the executing entity is a vehicle end, the cloud may distribute the second information to the vehicle, and then the vehicle may receive the second information distributed by the cloud, acquire the first information stored in the vehicle end, and further verify a match between the first information and the second information.
[0093] S602: Based on the first information and the second information, verify the consistency between the first software version information and the second software version information corresponding to the first mapping.
[0094] In this embodiment of the present application, the match between the first software version information and the second software version information corresponding to the first mapping may include the following cases: the first software version information matches the second software version information, or the first software version information does not match the second software version information.
[0095] For example, there may be two entities: a cloud or a vehicle end, for verifying the match between the first software version information and the second software version information corresponding to the first mapping based on the first information and the second information. It may be understood that the executing entity verifying the match between the first software version information and the second software version information corresponding to the first mapping is not limited in this embodiment of the present application.
[0096] In summary, the embodiments of the present application provide an OTA-based communication method and device, which obtains first information from a vehicle and second information from a cloud in an OTA maintenance and software installation process, and verifies the agreement between the first information and the second information by using a matching relationship between the identification number and the software version in the first information and the second information. Furthermore, if the software version upgraded by using OTA does not match the software version used during admission, it can be eliminated by maintaining consistency between the software version and the identification number at the vehicle end and / or the cloud to ensure the successful upgrade of the vehicle software.
[0097] Based on the embodiment corresponding to Figure 6, in a possible implementation, in steps S601 and S602, the executing entity that verifies the match between the first software version information and the second software version information corresponding to the first mapping may be the cloud or the vehicle end.
[0098] For example, in Method 1, the cloud is used to verify the match between the first software version information and the second software version information corresponding to the first mapping (shown in an embodiment corresponding to FIG. 7).
[0099] In Method 2, the vehicle end is used to verify the match between the first software version information and the second software version information corresponding to the first mapping (shown in an embodiment corresponding to FIG. 8).
[0100] Method 1: The cloud is used to verify the match between the first software version information and the second software version information.
[0101] For example, Figure 7 is a schematic flowchart of maintaining consistency between an identification number and a software version by a cloud according to an embodiment of the present application. In the embodiment corresponding to Figure 7, the cloud verifying the consistency between the first software version information and the second software version information based on the first information and the second information is described by using an example in which the cloud is an OTA cloud, the vehicle end includes a master node, ECU1, and ECU2, the identification number is RXSWIN, and the first mapping is an RXSWIN mapping (including an association relationship between RXSWIN and software version information). This example does not constitute a limitation on this embodiment of the present application.
[0102] As shown in FIG. 7, the process by which the cloud maintains consistency between the identification number and the software version information may include the following steps:
[0103] S701: The master node collects software version information for each ECU (including ECU1 and ECU2).
[0104] For example, the master node may periodically collect software version information for each ECU, for example, the software version information for each ECU may be set to be collected once a week.
[0105] S702: The master node reports the vehicle-end software version information to the OTA cloud.
[0106] Accordingly, the OTA cloud receives software version information reported by the vehicle end.
[0107] Optionally, if the vehicle end stores the RXSWIN identifier, the vehicle end may execute the step indicated by S702.
[0108] S703: The master node reports the vehicle-end RXSWIN identifier to the OTA cloud.
[0109] Adaptably, the OTA cloud receives the RXSWIN reported by the vehicle end.
[0110] S704: The OTA cloud checks the consistency of the RXSWIN-related software version information, and if there is a mismatch, performs a software upgrade.
[0111] For example, the OTA cloud compares the software version information reported in the step shown in S702 with the RXSWIN mapping table stored in the OTA cloud. When the software version information reported by the master node does not match the software version information in the RXSWIN mapping table, it may indicate that the admission-related software has been illegally modified. In this case, the OTA cloud may upgrade the software by using OTA and modify the vehicle-end software to ensure consistency between the vehicle-end software version information and the RXSWIN mapping table stored in the OTA cloud.
[0112] Optionally, when the vehicle end reports the RXSWIN identifier to the cloud, the cloud may perform the step shown in S705.
[0113] S705: The OTA cloud checks whether the RXSWIN matches, and if not, updates the RXSWIN.
[0114] For example, the OTA cloud compares the RXSWIN identifier reported in the step shown in S703 with the RXSWIN mapping table stored in the OTA cloud. When the RXSWIN identifier reported by the vehicle end does not match the RXSWIN identifier in the RXSWIN mapping table, it may indicate that the RXSWIN at the vehicle end has been tampered with. In this case, the OTA cloud may deliver an instruction to update the RXSWIN identifier at the vehicle end to ensure consistency between the RXSWIN identifier at the vehicle end and the RXSWIN mapping table stored in the OTA cloud.
[0115] It may be understood that the OTA cloud may perform a software upgrade based on a determination of a match between the vehicle-end software version information and that of the cloud in the step shown in S704, may perform a software upgrade based on a determination of a match between the vehicle-end RXSWIN and that of the cloud in the step shown in S705, or may determine whether to perform a software upgrade based on a match between the vehicle-end software version information and that of the cloud and a match between the vehicle-end RXSWIN and that of the cloud in the steps shown in S704 and S705.
[0116] Method 2: The vehicle end is used to verify the match between the first software version information and the second software version information.
[0117] For example, Figure 8 is a schematic flowchart of maintaining consistency between an identification number and a software version by a vehicle end according to an embodiment of the present application. In the embodiment corresponding to Figure 8, the vehicle end verifying the consistency between the first software version information and the second software version information based on the first information and the second information is described by using an example in which the cloud is an OTA cloud, the vehicle end includes a master node, ECU1, and ECU2, the identification number is RXSWIN, and the first mapping is an RXSWIN mapping (including an association relationship between RXSWIN and software version information). This example does not constitute a limitation on this embodiment of the present application.
[0118] As shown in FIG. 8, the process by which the vehicle end maintains consistency between the identification number and the software version information may include the following steps:
[0119] S801: The OTA cloud distributes the RXSWIN and the RXSWIN mapping table to the master node.
[0120] Adaptively, the master node receives the RXSWIN and RXSWIN mapping table delivered by the OTA cloud.
[0121] For example, when the RXSWIN identifier or any software version information in the RXSWIN mapping table stored in the OTA cloud is changed, the OTA cloud may distribute the changed RXSWIN mapping table to the master node.
[0122] S802: The master node collects software version information for each ECU (including ECU1 and ECU2).
[0123] S803: The master node checks the consistency of the RXSWIN-related software version information.
[0124] S804: If the master node determines that the RXSWIN-related software version information is inconsistent, the master node may generate an alarm to the OTA cloud and report the inconsistent software version information.
[0125] For example, if the master node determines that the software version information reported by each ECU in the step shown in S802 does not match the software version information in the RXSWIN mapping table distributed by the OTA cloud, it may indicate that the admission-related software at the vehicle end has been modified in an illegal manner. In this case, the master node may report a mismatch message to the OTA cloud.
[0126] Based on this, the agreement between the first software version information and the second software version information is verified by using the cloud or the vehicle end. Furthermore, the consistency between the software version and RXSWIN at the vehicle end and / or the cloud can be maintained to prevent the software version and / or RXSWIN from being tampered with and ensure the successful upgrade of the vehicle software upgraded by using OTA.
[0127] Based on the embodiment corresponding to FIG. 6, in a possible implementation, the method further includes the following steps:
[0128] S603 (not shown): When the first software version information does not match the second software version information, the first vehicle sends the first software version information, the first identification number, and / or alarm information to the cloud and / or the display device of the first vehicle.
[0129]
[0023] Adaptively, the display device may receive the first software version information, the first identification number, and / or the alarm information from the first vehicle. The vehicle end described in this embodiment of the present application may include the first vehicle.
[0130] In this embodiment of the present application, the alarm information indicates that the vehicle identification number and software version information do not match the mapping relationship of the server. The display device may be a central control display of the first vehicle, a dashboard display of the first vehicle, or another display device connected to the vehicle, such as a mobile phone. In this embodiment of the present application, the display device may include other content based on actual scenarios, which is not limited in this embodiment of the present application.
[0131] S604 (not shown): The display device displays the alarm information.
[0132] For example, Fig. 9 is a schematic diagram of an interface displaying alarm information according to an embodiment of the present application. As shown in Fig. 9, the interface may be an interface displayed on a central control display 900 of a first vehicle. The interface displayed on the central control display 900 may include content such as a software version update instruction message 901, a system prompt message 902, a stop control 903, and a continue control 904. The instruction message 901 displays "Updating power steering software V2.0 (R79 90)." V2.0 may be software version information of the power steering software, and R79 90 may be an identification number corresponding to the software version of the power steering software.
[0133] Before the software update is performed, if the first vehicle detects that the first software version information does not match the second software version information, the first vehicle may send alarm information to the central control display 900, where the alarm information may be a system prompt message 902 displayed on the central control display 900. The system prompt message 902 may display, "Vehicle software may have been illegally tampered with. Please address this issue as soon as possible!" After sending the prompt message, the user may then trigger a stop control 903 to suspend the software update, or the user may drive the vehicle to a 4S store for processing.
[0134] Based on this, alarm information indicating a discrepancy between the software version information and the identification number in the system can be intuitively displayed to the user on the user interface, which helps the user to take subsequent action in a timely manner and further ensures the normal upgrade of the vehicle software.
[0135] Based on the embodiment corresponding to FIG. 6, in a possible implementation, S602 may include:
[0136] In implementation, when the first software version information does not match the second software version information and / or the first identification number does not match the second identification number, it is determined that the first software version information does not match the second software version information.
[0137] It can be understood as follows: when the first software version information does not match the second software version information, or the first identification number does not match the second identification number, or the first software version information does not match the second software version information and the first identification number does not match the second identification number, it is determined that the first software version information does not match the second software version information.
[0138] The first software version information not matching the second software version information can be understood as follows: in this case, the first identification number may match the second identification number, or the first identification number may not match the second identification number. The first identification number not matching the second identification number can be understood as follows: in this case, the first software version information may match the second software version information, or the first software version information may not match the second software version information.
[0139] In another implementation, the first software version information is determined to match the second software version information when the first software version information matches the second software version information and / or the first identification number matches the second identification number.
[0140] It can be understood as follows: when the first software version information matches the second software version information, or the first identification number matches the second identification number, or the first software version information matches the second software version information and the first identification number matches the second identification number, the first software version information is determined to match the second software version information.
[0141] Based on this, in a scenario where the cloud distributes the first task, when the first software version information and / or the first identification number match the first mapping, it can be further ensured that the vehicle software upgraded using OTA is successfully upgraded based on the consistency check. In a scenario where the cloud and / or the vehicle end periodically checks the consistency between the identification number and the software version, when the first software version information and / or the first identification number do not match the first mapping, the risk of non-compliance caused by the mismatch can be detected in a timely manner, so as to prevent the identification number and / or software version information from being tampered with and ensure that the vehicle software upgraded using OTA is successfully upgraded.
[0142] Based on the embodiment corresponding to FIG. 6, in a possible implementation, the method may further include updating the first software version information and / or the first identification number when the first software version information does not match the second software version information, or updating the first software version information and / or the first identification number when the first software version information matches the second software version information.
[0143] In implementation, a scenario in which the first software version information does not match the second software version information may be as follows: The first software version information and / or the first identification number at the vehicle end have been tampered with, so that the first software version information at the vehicle end does not match the second software version information at the cloud. Furthermore, the cloud may distribute the software version information and / or the identification number stored in the cloud to the vehicle end to ensure a match between the software version information at the cloud and that at the vehicle end, and between the identification number at the cloud and that at the vehicle end. The software version information and / or the identification number distributed by the cloud may match the software version information and / or the identification number stored at the vehicle end before the software version information and / or the identification number were tampered with. In this scenario, if the first software version information matches the second software version information, the update process cannot be performed on the first software version information and / or the first identification number.
[0144] For example, the process of updating the first software version information and / or the first identification number based on the discrepancy may be as described in the embodiments corresponding to Figures 7 and 8. The details will not be described again here.
[0145] In another implementation, a scenario in which the first software version information matches the second software version information may be as follows: The cloud delivers a first task (also called an update task). When the cloud determines that the first software version information and / or the first identification number reported by the vehicle end matches the second software version information stored in the cloud, the cloud may deliver the software version information and / or the identification number carried in the first task to the vehicle end based on the consistency guarantee. In this scenario, if the first software version information does not match the second software version information, the update process may not be performed for the first software version information and / or the first identification number.
[0146] For example, Figure 10 is a schematic flowchart of performing matching determination by a cloud according to an embodiment of the present application. In the embodiment corresponding to Figure 10, updating the first software version information and / or the first identification number when the first software version information matches the second software version information is described by using an example in which the cloud is an OTA cloud, the vehicle end includes a master node, the first mapping is an RXSWIN mapping, and the identification number is RXSWIN. This example does not constitute a limitation on this embodiment of the present application.
[0147] As shown in FIG. 10, the process by which the cloud performs a match determination may include the following steps:
[0148] S1001: The OTA cloud collects the RXSWIN identifier for the master node.
[0149] S1002: OTA cloud checks for RXSWIN match.
[0150] For example, if the OTA cloud determines that the vehicle-end RXSWIN identifier does not match the RXSWIN identifier in the first mapping, the OTA cloud may decide not to perform the OTA.
[0151] If the OTA cloud determines that the vehicle-end RXSWIN identifier matches the RXSWIN identifier in the first mapping, the OTA cloud may distribute an update task to the master node, where the update task may carry the new RXSWIN identifier and the RXSWIN mapping table.
[0152] S1003: The master node stores the new RXSWIN identifier and the RXSWIN mapping table.
[0153] Based on this, in order to eliminate cases where the software version upgraded by using OTA does not match the software version used during admission and to ensure successful upgrade of the vehicle software, the cloud and the vehicle end can maintain consistency between the software version information of the vehicle end and / or the mapping relationship between the identification number and the cloud based on the matching relationship between the identification number and the software version.
[0154] The above is the process by which the vehicle end and / or the cloud maintains consistency between the software version information and the identification number. The following describes the process by which the consistency between the software version information and the identification number is ensured during the process of upgrading the vehicle software using OTA.
[0155] For example, Figure 11 is a schematic flowchart of updating software according to an embodiment of the present application. As shown in Figure 11, entities that update the software may include a cloud and a first vehicle. The first vehicle may include a master node and one or more ECUs.
[0156] As shown in FIG. 11, the process of updating software may include the following steps:
[0157] S1101: The cloud transmits a first task to a first vehicle.
[0158] The first vehicle may receive the first task and update the first software version information and / or the first identification number based on the first task. The entity receiving the first task may be the master node of the first vehicle.
[0159] In this embodiment of the present application, the first task instructs updating the first software version information and / or the first identification number. When the first software version information does not match the second software version information, the first task includes a first mapping; alternatively, when the first software version information matches the second software version information, the first task includes a second mapping. The second mapping includes an association relationship between the third software version information and the third identification number. The third software version information is different from the second software version information and / or the third identification number is different from the second identification number.
[0160] For example, when the cloud determines that the first software version information of the first vehicle does not match the second software version information of the cloud, it may be understood that the software version and / or the identification number of the first vehicle may have been tampered with. In this case, the cloud may transmit a first task including a first mapping. The first mapping may be understood as an association relationship between the software version and the identification number stored in the cloud before the software version and / or the identification number of the first vehicle were tampered with.
[0161] For example, when the cloud determines that the first software version information of the first vehicle matches the second software version information of the cloud, the first vehicle device and the cloud may be considered to have passed the matching determination performed before upgrading the software by using OTA. In this case, the cloud may send a first task including a second mapping. The second mapping may be considered as a mapping relationship triggered by OTA, including new software version information and a new identification number.
[0162] It may be understood that when updating the software using OTA is insufficient to change the test parameters corresponding to the software during admission, the third identification number in the second mapping may match the first identification number stored in the first vehicle. For example, when the battery management system of the first vehicle is V1.0, the system of the first vehicle may support an endurance driving range of 500 km. When a software upgrade is performed on the battery management system using OTA, the battery management system of the first vehicle may be updated to V1.1, and the system of the first vehicle may support an endurance driving range of 500 km. In this case, the update of the battery management system does not change the specific parameter of the endurance driving range during admission. Therefore, in this case, when the first vehicle performs a software upgrade using OTA, the third software version information in the second mapping distributed by the cloud may not match the first software version information stored in the first vehicle, and the third identification number in the second mapping may match the software version information stored in the first vehicle.
[0163] S1102: The cloud transmits a first software package to a first vehicle.
[0164] The first vehicle may accordingly receive the first software package and update the vehicle's software based on the first software package. The software package may include software and software version information corresponding to the software.
[0165] In this embodiment of the present application, when the first software version information does not match the second software version information, the first software package includes a second identification number, or when the first software version information matches the second software version information, the first software package includes a third identification number.
[0166] For example, when the cloud determines that the first software version information of the first vehicle does not match the second software version information of the cloud, it may be understood that the software version and / or identification number of the first vehicle may have been tampered with. In this case, the cloud may transmit a first software package including the second identification number. The first software package may be understood as a software package stored in the cloud before the software version and / or identification number of the first vehicle were tampered with. The software package stored in the cloud may store the software and identification number of the first vehicle that were stored before the software version and / or identification number of the first vehicle were tampered with.
[0167] For example, when the cloud determines that the first software version information of the first vehicle matches the second software version information of the cloud, the first vehicle device and the cloud may be considered to have passed the matching determination performed before upgrading the software by using OTA. In this case, the cloud may send a first software package including a third identification number. The first software package may be considered to be a software package triggered by OTA.
[0168] When updating the software by using OTA is not enough to change the parameters during admission, the third identification number may be consistent with the first identification number, the specific process of which will not be described again.
[0169] S1103: The first vehicle transmits, to the ECU, a first software package corresponding to the ECU.
[0170] Adaptably, each ECU receives the first software package. There may be one or more ECUs. For example, if there are N ECUs, the first vehicle may transmit the first software package corresponding to the N ECUs to the N ECUs, where N is a positive integer.
[0171] For example, if the first vehicle includes a master node, the master node may receive the first software package transmitted by the cloud and distribute the first software package to corresponding ECUs.
[0172] S1104: Install the first software package in the ECU and update the identification number.
[0173] In this embodiment of the present application, the identification number may be the second identification number or the third identification number.
[0174] For example, when an exception occurs during installation of a first software package on an ECU, the ECU may roll back to the software existing before the installation and restore the first identification number. The ECU rolling back to the software existing before the installation may indicate that the ECU restores the first software version information.
[0175] For example, upon successful installation of the first software package on the ECU, the ECU may update the first identification number and the first software version information.
[0176] S1105: The ECU transmits the installation result to the first vehicle.
[0177] Adaptively, the first vehicle receives an installation result, which may be a successful installation or a failed installation on any one or more ECUs.
[0178] S1106: When the software installation result is that the installation on any one or more ECUs has failed, roll back to the vehicle software version and identification number of the first vehicle.
[0179] Optionally, when the software installation result is that the installation was successful, the vehicle software version and / or the identification number may be updated. For example, when the software installation result is that the installation was successful and the updated software is insufficient to change the vehicle software version, the vehicle software version may not be changed.
[0180] Based on this, based on the consistency between the software version and the identification number at the vehicle end and / or the cloud, the matching relationship between the software version information and the identification number can be ensured in the OTA software upgrade process, so as to eliminate the case where the software version upgraded by using OTA does not match the software version used during admission, and to ensure the successful upgrade of the vehicle software.
[0181] Based on the contents described in the above embodiments, in order to better understand the embodiments of the present application, the entire process of updating software at the vehicle end is separately described below. Specifically, the process may include: the cloud delivers the software package to the vehicle end (shown in the embodiment corresponding to FIG. 12), the vehicle end successfully installs the software package (shown in the embodiment corresponding to FIG. 13), and the vehicle end fails to install the software package (shown in the embodiment corresponding to FIG. 14).
[0182] 12 is a schematic flowchart of distributing a software package to a vehicle end by a cloud according to an embodiment of the present application. In the embodiment corresponding to FIG. 12, the process of distributing a software package to a vehicle end by a cloud is described by using an example in which the cloud is an OTA cloud, the vehicle end includes a master node, ECU1, and ECU2, the identification number is RXSWIN, and the first mapping is an RXSWIN mapping. This example does not update the limitations on this embodiment of the present application.
[0183] As shown in FIG. 12, the process of cloud delivering a software package may include the following steps:
[0184] S1201: The OTA cloud distributes the software package to the master node.
[0185] In response, the masternode receives the software package delivered by the OTA cloud, which carries the associated RXSWIN identifier.
[0186] S1202: The master node distributes the software package to ECU1 and ECU2.
[0187] Correspondingly, ECU1 and ECU2 receive the software package sent by the master node, and ECU1 and ECU2 may be ECUs corresponding to the software package.
[0188] S1203: ECU1 and ECU2 receive the software package and record the RXSWIN identifier.
[0189] Based on this, based on the consistency between the software version and the identification number at the vehicle end and / or the cloud, the matching relationship between the software version information and the identification number can be ensured in the OTA software upgrade process, so as to eliminate the case where the software version upgraded by using OTA does not match the software version used during admission, and to ensure the successful upgrade of the vehicle software.
[0190] The above is the process of the cloud delivering the software package to the vehicle end. The following describes the process of the successful installation of the software package at the vehicle end.
[0191] For example, Figure 13 is a schematic flowchart of installing a software package at a vehicle end according to an embodiment of the present application. In the embodiment corresponding to Figure 13, the process of successfully installing a software package at a vehicle end is described by using an example in which the cloud is an OTA cloud, the vehicle end includes a master node, ECU1, and ECU2, the identification number is RXSWIN, and the first mapping is an RXSWIN mapping. This example does not update the limitations on this embodiment of the present application.
[0192] As shown in FIG. 13, the process by which a software package is installed on an ECU may include the following steps:
[0193] S1301: Install software in ECU1 and ECU2.
[0194] For example, after the master node distributes a software package to ECU1 and ECU2, software can be installed in ECU1 and ECU2 based on the software package.
[0195] S1302: When the software is successfully installed in ECU1 and ECU2, update the associated RXSWIN.
[0196] S1303: ECU1 and ECU2 transmit the installation results to the master node.
[0197] S1304: The master node updates the vehicle software version and / or updates RXSWIN.
[0198] Alternatively, the vehicle software may not be modified, the details of which will not be described again here.
[0199] Based on this, based on the consistency between the software version and the identification number at the vehicle end and / or the cloud, the matching relationship between the software version information and the identification number can be ensured in the OTA software upgrade process, so as to eliminate the case where the software version upgraded by using OTA does not match the software version used during admission, and to ensure the successful upgrade of the vehicle software.
[0200] The above is the process for successful installation of the software package at the vehicle end. In a possible implementation, an exception may occur when the software package is installed at the vehicle end. The following describes the process for unsuccessful installation of the software package at the vehicle end.
[0201] For example, Figure 14 is another schematic flowchart of installing a software package at a vehicle end according to an embodiment of the present application. In the embodiment corresponding to Figure 14, the process of failing to install a software package at a vehicle end is described by using an example in which the cloud is an OTA cloud, the vehicle end includes a master node, ECU1, and ECU2, the identification number is RXSWIN, and the first mapping is an RXSWIN mapping. This example does not update the limitations on this embodiment of the present application.
[0202] As shown in FIG. 14, the process by which a software package is installed on an ECU may include the following steps:
[0203] S1401: Install software in ECU1 and ECU2 and update related RXSWIN.
[0204] S1402: If an exception occurs during the process of installing software in ECU1 and ECU2, the software is rolled back.
[0205] ECU1 and ECU2 store the software that existed before the software package was installed. If an exception occurs during the software installation process on ECU1 and ECU2, ECU1 and ECU2 may roll back to the software that existed before the software package was installed.
[0206] S1403: ECU1 and ECU2 restore the old RXSWIN.
[0207] ECU1 and ECU2 store the RXSWIN that existed before the software package was installed. If an exception occurs during the software installation process in ECU1 and ECU2, ECU1 and ECU2 may roll back to the RXSWIN that existed before the software package was installed.
[0208] S1404: ECU1 and ECU2 notify the master node of the exception.
[0209] S1405: The master node restores the associated old RXSWIN.
[0210] Based on this, based on the consistency between the software version and the identification number at the vehicle end and / or the cloud, the matching relationship between the software version information and the identification number can be ensured in the OTA software upgrade process, so as to eliminate the case where the software version upgraded by using OTA does not match the software version used during admission, and to ensure the successful upgrade of the vehicle software.
[0211] The above has described the method provided in the embodiment of the present application with reference to Figures 6 to 14. The following describes the apparatus provided in the embodiment of the present application for performing the aforementioned method.
[0212] For example, FIG. 15 is a schematic diagram of the structure of an OTA-based communication device according to an embodiment of the present application. 15 As shown in the figure, the OTA-based communication device 150 may be used in a communication device, a circuit, a hardware component, or a 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 configured to support a display step performed in a network configuration method. The processing unit 1502 is configured to support the OTA-based communication device to perform an information processing step. The communication unit 1503 is configured to support the OTA-based communication device to perform a data transmission or reception step.
[0213] Specifically, 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, where the first information includes first software version information and / or a first identification number, and the second information includes a first mapping, where the first mapping includes an association relationship between the second software version information and the second identification number, and the identification number indicates permission information of the software version. The processing unit 1502 is further configured to verify a match between the first software version information and the second software version information based on the first information and the second information.
[0214] In a possible implementation, the processing unit 1502 is particularly configured to determine that the first software version information does not match the second software version information when the first software version information does not match the second software version information and / or the first identification number does not match the second identification number, or to determine that the first software version information matches the second software version information when the first software version information matches the second software version information and / or the first identification number matches the second identification number.
[0215] In a possible implementation, the processing unit 1502 is further configured to update the first software version information and / or the first identification number when the first software version information does not match the second software version information, or to update the first software version information and / or the first identification number when the first software version information matches the second software version information.
[0216] In one possible implementation, the communication unit 1503 is configured to send a first task to the first vehicle, the first task instructing the first vehicle to update the first software version information and / or the first identification number. When the first software version information does not match the second software version information, the first task includes a first mapping, or when the first software version information matches the second software version information, the first task includes a second mapping. The second mapping includes an association relationship between third software version information and the third identification number.
[0217] In a possible implementation, the communication unit 1503 is further configured to send a first software package to the first vehicle, where the first software package is used to update software version information corresponding to the first vehicle. When the first software version information does not match the second software version information, the first software package includes a second identification number, or when the first software version information matches the second software version information, the first software package includes a third identification number.
[0218] In a possible implementation, the communication unit 1503 is further configured to send the first software version information, the first identification number, and / or alarm information to the server and / or the display device of the first vehicle when the first software version information does not match the second software version information, and the alarm information indicates that the identification number and / or software version information of the first vehicle does not match the mapping relationship of the server.
[0219] In a possible implementation, the communication unit 1503 is specifically configured to receive a first task from the server, the first task instructing to update the first software version information and / or the first identification number. When the first software version information does not match the second software version information, the first task includes a first mapping, or when the first software version information matches the second software version information, the first task includes a second mapping. The second mapping includes an association relationship between third software version information and a third identification number.
[0220] In a possible implementation, the communication unit 1503 is further configured to receive a first software package from the server, the first software package being used to update software version information corresponding to the first vehicle, and when the first software version information does not match the second software version information, the first software package includes a second identification number, or when the first software version information matches the second software version information, the first software package includes a third identification number.
[0221] In a possible implementation, the identification number is the first legally related software identification number. ( RXSWIN ) Includes.
[0222] In a possible implementation, 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.
[0223] The storage unit 1504 may include one or more memories configured to store programs or data and may be components within one or more devices or circuits.
[0224] The storage unit 1504 may exist independently and be connected to the processing unit 1502 of the OTA-based communication device through a communication line. Alternatively, the storage unit 1504 may be integrated with the processing unit 1502.
[0225] The communication unit 1503 may be an input / output interface, a pin, a circuit, etc. For example, the storage unit 1504 may be OTA-based communication The processing unit 1502 may store computer-executable instructions for the method, such as OTA-based communication The memory unit 1504 may be a register, a cache, a RAM, etc. The memory unit 1504 may be integrated with the processing unit 1502. The memory unit 1504 may be a ROM or other type of static storage device capable of storing static information and instructions. The memory unit 1504 may be separate from the processing unit 1502.
[0226] 16 is a schematic diagram of a hardware structure of a control device according to an embodiment of the present application. As shown in FIG. 16, the control device includes a processor 1601, a communication line 1604, and at least one communication interface (communication interface 1603 is used as an example in FIG. 16 for illustration purposes).
[0227] The processor 1601 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to control program execution of the solutions of the present application.
[0228] Communication lines 1604 may include circuitry for transmitting information between the aforementioned components.
[0229] The communication interface 1603 is any device, such as a transceiver, configured to communicate with other devices or communication networks, such as Ethernet or a wireless local area network (WLAN).
[0230] Optionally, the control device may further include a memory 1602 .
[0231] Memory 1602 may be read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, or random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or may be electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other compact disc storage, optical disc storage (including compact optical discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disc storage media or other magnetic storage devices, or any other medium that can be used to carry or store expected program code in the form of instruction structures or data structures and that can be accessed by a computer. However, it is not so limited. The memory may exist independently and be connected to the processor via communication lines 1604. Alternatively, the memory may be integral to the processor.
[0232] The memory 1602 is configured to store computer-executable instructions for implementing the solution of the present application, and the processor 1601 controls the execution of the computer-executable instructions. The processor 1601 is configured to execute the computer-executable instructions stored in the memory 1602 to implement the OTA-based communication method provided in the embodiment of the present application.
[0233] In some cases, the computer-executable instructions of this embodiment of the present application may also be referred to as application program code, which is not particularly limited in this embodiment of the present application.
[0234] In a specific implementation, in an embodiment, the processor 1601 may include one or more CPUs, for example, CPU0 and CPU1 in FIG.
[0235] In a specific implementation, in an embodiment, the control device may include multiple processors, such as processor 1601 and processor 1605 of FIG. 16. Each of the processors may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor, where a processor may be one or more devices, circuits, and / or processing cores configured to process data (e.g., computer program instructions).
[0236] For example, Figure 17 is a schematic diagram of a chip structure according to an embodiment of the present application. Chip 170 includes one or more (including two) processors. 1710 and a communication interface 1730.
[0237] In some implementations, memory 1740 stores the following elements: executable modules or data structures, a subset thereof, or an extended set thereof.
[0238] In this embodiment of the present application, memory 1740 includes read-only memory and random access memory, and provides instructions and data to the processor. 1710A portion of memory 1740 may further include non-volatile random access memory (NVRAM).
[0239] In this embodiment of the present application, Processor 1710 , the communication interface 1730, and the memory 1740 are connected to a bus system 1720 In addition to the data bus, the bus system 1720 may further include a power bus, a control bus, a status signal bus, etc. For ease of description, FIG. 17 shows various types of buses as a bus system. 1720 is marked as
[0240] The method described in the foregoing embodiment of the present application comprises: 1710 Alternatively, the processor 1710 The processor may be 1710 may be an integrated circuit chip and have signal processing capabilities. In the implementation process, the steps of the above method are performed by a processor 1710 This may be accomplished by using integrated logic circuitry in hardware circuitry within a processor, or by using instructions in the form of software. 1710 The processor 1710 may be a general-purpose processor (e.g., a microprocessor or conventional processor), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, a discrete gate, a transistor logic device, or a discrete hardware component. The processor 1710 may implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present invention.
[0241] The steps of the methods disclosed with reference to the embodiments of the present application may be directly executed and completed by using a hardware decoding processor, or may be executed and completed by using a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium mature in the art, such as a random access memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable read-only memory (EEPROM). The storage medium is located in the memory 1740. Processor 1710 reads the information in the memory 1740 and 1710 in combination with the hardware to complete the steps of the aforementioned method.
[0242] In the above-described embodiments, the instructions stored in the memory and to be executed by the processor may be embodied in the form of a computer program product, which may be pre-written in the memory or downloaded in the form of software and installed in the memory.
[0243] A computer program product includes one or more computer instructions. When the computer program instructions are loaded into a computer and executed, all or part of the procedures or functions of the embodiments of the present application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from a computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, fiber optic, or digital subscriber line (DSL)) or wireless (e.g., infrared, radio wave, or microwave) transmission. The computer-readable storage medium may be any available medium accessible by a computer or a data storage device, such as a server or data center, that includes one or more available media. For example, usable media may include magnetic media (e.g., floppy disks, hard disks, or magnetic tapes), optical media (e.g., digital versatile discs (DVDs)), semiconductor media (e.g., solid state disks (SSDs)), and the like.
[0244] The embodiments of the present application further provide a computer-readable storage medium. All or part of the methods described in the above embodiments may be implemented by software, hardware, firmware, or any combination thereof. The computer-readable medium may include computer storage media and communication media, and may also include any medium that can transfer a computer program from one place to another. The storage medium may be any target medium that can be accessed by a computer.
[0245] In possible designs, the computer-readable medium may include a compact disc read-only memory (CD-ROM), RAM, ROM, EEPROM, or other optical disc memory. The computer-readable medium may also include a magnetic disc memory or other magnetic disc storage device. Furthermore, any connecting wire may be properly referred to as a computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, DSL, or radio technologies (e.g., infrared, radio waves, and microwaves), the coaxial cable, fiber optic cable, twisted pair, DSL, or radio technologies such as infrared, radio waves, and microwaves are included in the definition of medium. As used herein, magnetic disks and optical disks include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs. Magnetic disks typically reproduce data magnetically, while optical disks reproduce data optically by using laser light.
[0246] The above combinations should also be included in the scope of computer-readable media. The above description is only a specific implementation of the present invention and is not intended to limit the protection scope of the present invention. Any modifications or replacements that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should fall within the protection scope of the present invention. Therefore, the protection scope of the present invention should be subject to the protection scope of the claims.
Claims
1. A processor-implemented communication method based on over-the-air technology (OTA), comprising: obtaining first information and second information, the first information including first software version information and a first identification number, the second information including a first mapping, the first mapping including an association relationship between the second software version information and a second identification number, and the second identification number indicating permission information of the software version; verifying a match between the first software version information and the second software version information corresponding to the first mapping based on the first information and the second information; updating the first software version information and / or the first identification number based on the result of the verification of the match; and The updating step includes: updating the first software version information and the first identification number to match the second software version information and the second identification number based on a result of the match verification indicating that the first software version information is determined to not match the second software version information; or updating the first software version information to upgrade it to third software version information, or updating the first software version information and the first identification number to upgrade it to third software version information and third identification number, respectively, based on a result of the match verification indicating that the first software version information is determined to match the second software version information. Including, Communication method.
2. verifying a match between the first software version information and the second software version information corresponding to the first mapping based on the first information and the second information, determining that the first software version information does not match the second software version information when the first software version information does not match the second software version information, or when the first identification number does not match the second identification number, or when the first software version information does not match the second software version information and the first identification number does not match the second identification number; or determining that the first software version information matches the second software version information when the first software version information matches the second software version information, or when the first identification number matches the second identification number, or when the first software version information matches the second software version information and the first identification number matches the second identification number; having The communication method according to claim 1 .
3. The processor is included in a server communicatively coupled to a first vehicle, and prior to updating the first software version information and / or the first identification number, the communication method comprises: transmitting a first task to the first vehicle, the first task instructing the first vehicle to update the first software version information and / or the first identification number; When the result of the match verification indicates that the first software version information does not match the second software version information, the first task includes the first mapping; or When the result of the matching verification indicates that the first software version information matches the second software version information, the first task includes a second mapping, and the second mapping includes an association relationship between the third software version information and the third identification number. The communication method according to claim 1 or 2.
4. The communication method is transmitting a first software package to the first vehicle, the first software package being used to update software version information corresponding to the first vehicle; When the result of the matching verification indicates that the first software version information does not match the second software version information, the first software package includes the second identification number; or When the result of the matching verification indicates that the first software version information matches the second software version information, the first software package includes the third identification number. The communication method according to claim 3 .
5. The processor is included in a first vehicle communicatively coupled to a server, and the communication method comprises: and when the result of the matching verification indicates that the first software version information does not match the second software version information, sending the first software version information, the first identification number, and / or alarm information to the server and / or to a display device of the first vehicle, the alarm information indicating that at least one of the identification number and software version information of the first vehicle does not match a mapping relationship stored in the server. The communication method according to claim 1 or 2.
6. The processor is included in a first vehicle communicatively coupled to a server, and updating the first software version information and / or the first identification number comprises: receiving a first task from the server, the first task instructing updating the first software version information and / or the first identification number; When the result of the match verification indicates that the first software version information does not match the second software version information, the first task includes the first mapping; or When the result of the matching verification indicates that the first software version information matches the second software version information, the first task includes a second mapping, and the second mapping includes an association relationship between the third software version information and the third identification number. The communication method according to claim 1 or 2.
7. The communication method is receiving a first software package from the server, the first software package being used to update software version information corresponding to the first vehicle; When the result of the matching verification indicates that the first software version information does not match the second software version information, the first software package includes the second identification number; or When the result of the matching verification indicates that the first software version information matches the second software version information, the first software package includes the third identification number. The communication method according to claim 6.
8. The second identification number includes a regulatory software identification number (RXSWIN). A communication method according to any one of claims 1 to 7.
9. A communication device based on over-the-air technology (OTA), comprising: a communication unit configured to obtain first information and second information, the first information including first software version information and a first identification number, the second information including a first mapping, the first mapping including an association relationship between the second software version information and the second identification number, and the second identification number indicating permission information of the software version; a processing unit configured to verify a match between the first software version information and the second software version information corresponding to the first mapping based on the first information and the second information; and the processing unit is further configured to update the first software version information and / or the first identification number based on a result of the verification of the match; The processing unit updating the first software version information and / or the first identification number includes: updating the first software version information and the first identification number to match the second software version information and the second identification number based on a result of the match verification indicating that the first software version information does not match the second software version information; or updating the first software version information to upgrade it to third software version information, or updating the first software version information and the first identification number to upgrade it to third software version information and third identification number, respectively, based on a result of the verification of the match indicating that the first software version information matches the second software version information. Including, Communication equipment.
10. The processing unit determining that the first software version information does not match the second software version information when the first software version information does not match the second software version information, or when the first identification number does not match the second identification number, or when the first software version information does not match the second software version information and the first identification number does not match the second identification number; or determining that the first software version information matches the second software version information when the first software version information matches the second software version information, or when the first identification number matches the second identification number, or when the first software version information matches the second software version information and the first identification number matches the second identification number; Specifically composed of The communication device according to claim 9.
11. The communication device is included in a server communicatively coupled to the first vehicle; the communication unit is specifically configured to send a first task to the first vehicle, the first task instructing to update the first software version information and / or the first identification number; When the result of the match verification indicates that the first software version information does not match the second software version information, the first task includes the first mapping; or When the result of the matching verification indicates that the first software version information matches the second software version information, the first task includes a second mapping, and the second mapping includes an association relationship between the third software version information and the third identification number.
11. A communication device according to claim 9 or 10.
12. The communication unit is further configured to transmit a first software package to the first vehicle, the first software package being used to update software version information corresponding to the first vehicle; When the result of the matching verification indicates that the first software version information does not match the second software version information, the first software package includes the second identification number; or When the result of the matching verification indicates that the first software version information matches the second software version information, the first software package includes the third identification number. The communication device according to claim 11.
13. The communication device is included in a first vehicle that is communicatively coupled to a server; the communication unit is further configured to, when a result of the matching verification indicates that the first software version information does not match the second software version information, send the first software version information, the first identification number, and / or alarm information to the server and / or a display device of the first vehicle; The alarm information indicates that at least one of the identification number and software version information of the first vehicle does not match a mapping relationship stored in the server.
11. Apparatus according to claim 9 or 10.
14. The communication device is included in a first vehicle that is communicatively coupled to a server; the communication unit is specifically configured to receive a first task from the server, the first task instructing to update the first software version information and / or the first identification number; When the result of the match verification indicates that the first software version information does not match the second software version information, the first task includes the first mapping; or When the result of the matching verification indicates that the first software version information matches the second software version information, the first task includes a second mapping, and the second mapping includes an association relationship between the third software version information and the third identification number.
11. Apparatus according to claim 9 or 10.
15. the communication unit is further configured to receive a first software package from the server, the first software package being used to update software version information corresponding to the first vehicle; When the result of the matching verification indicates that the first software version information does not match the second software version information, the first software package includes the second identification number; or When the result of the matching verification indicates that the first software version information matches the second software version information, the first software package includes the third identification number.
15. The apparatus of claim 14.
16. The second identification number includes a regulatory software identification number (RXSWIN).
16. Apparatus according to any one of claims 9 to 15.
17. at least one processor configured to invoke a program in a memory to execute the communication method according to any one of claims 1 to 8, OTA-based communication device.
18. having at least one processor and an interface circuit; the interface circuitry is configured to provide information input and / or information output to the at least one processor; The at least one processor is configured to perform the communication method according to any one of claims 1 to 8. OTA-based communication device.
19. having at least one processor and an interface; the interface is configured to provide program instructions to the at least one processor; The at least one processor is configured to execute the program instructions to perform the communication method of any one of claims 1 to 8. Tips.
20. A computer-readable storage medium storing instructions, comprising: When the instructions are executed on a computer, the computer is capable of carrying out the communication method according to any one of claims 1 to 8. A computer-readable storage medium.
21. A computer program comprising: When the computer program is executed on a computer, the computer program causes the computer to perform the communication method according to any one of claims 1 to 8. Computer program.
Citation Information
Patent Citations
Quantification of sequencing instruments and reagents for use in molecular diagnostic methods
WO2020146253A1