Communication method and apparatus based on over-the-air technology (OTA)

Abstract

This application provides a communication method and apparatus based on Over-The-Air (OTA) technology, relating to the field of communication technology. The method includes: obtaining first information and second information; the first information includes first software version information and / or a first identifier; the second information includes a first mapping; the first mapping contains the association between the second software version information and the second identifier; the identifier is used to indicate software version permission information; and verifying the consistency between the first software version information and the second software version information corresponding to the first mapping based on the first and second information. This ensures normal upgrades of automotive software during OTA maintenance and software installation, thereby maintaining vehicle safety.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a communication method and apparatus based on Over-the-Air (OTA) technology. Background Technology

[0002] With the development of autonomous driving, people have increasingly higher demands for the computing and control capabilities of vehicles. More and more functions are being offered to users in the form of software, making software-defined vehicles a significant trend in automotive development. When the software in a car needs to be installed or updated, over-the-air (OTA) technology can be used to connect to the cloud and install or update the software.

[0003] However, while OTA (Over-The-Air) updates bring convenience, they also pose challenges to vehicle market access. Market access can be understood as the process of undergoing a series of safety or emissions tests before a vehicle is launched on the market to meet relevant standards. Specifically, updating vehicle software via OTA may change the market access parameters of a vehicle after its launch. For example, upgrading the battery management software via OTA might increase the vehicle's driving range, making it inconsistent with the range measured during market access. This could invalidate the data from the initial market access tests, requiring retesting. Therefore, the inconsistency between the software version updated via OTA and the software version used during market access presents a challenge to the development of OTA. Summary of the Invention

[0004] This application provides a communication method and apparatus based on Over-the-Air (OTA) technology, which can ensure the normal upgrading of automotive software during OTA maintenance and software installation, thereby maintaining vehicle safety.

[0005] In a first aspect, embodiments of this application provide an OTA-based communication method, comprising: obtaining first information and second information; the first information including first software version information and / or a first identifier; the second information including a first mapping; the first mapping containing the association between the second software version information and the second identifier; the identifier being used to indicate the permission information of the software version; and verifying the consistency 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 consistency between the first and second information can be verified by using the matching relationship between the identification code in the first and second information and the software version. This ensures the normal upgrade of the vehicle software and maintains the vehicle's safety by maintaining the consistency between the software version and the identification code in the vehicle and / or server (or cloud or cloud device) during OTA maintenance and software installation.

[0007] In conjunction with the first aspect, in one possible implementation, verifying the consistency 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 and the second software version information are inconsistent if the first software version information and the second software version information are inconsistent, and / or if the first identifier code and the second identifier code are inconsistent; or determining that the first software version information and the second software version information are consistent if the first software version information and the second software version information are consistent, and / or if the first identifier code and the second identifier code are consistent.

[0008] In this way, the consistency between the first software version information and the second software version information can be verified using the cloud or the vehicle. Furthermore, by maintaining the consistency between the software version and the identification code in the vehicle and / or the cloud, the software version and / or identification code can be prevented from being tampered with, ensuring that the car software upgraded via OTA can be upgraded normally.

[0009] In conjunction with the first aspect, in one possible implementation, the method further includes: updating the first software version information and / or the first identification code when the first software version information and the second software version information are inconsistent; or updating the first software version information and / or the first identification code when the first software version information and the second software version information are consistent.

[0010] In this way, the cloud and the vehicle can maintain the consistency of the mapping relationship between the vehicle's software version information and / or identification code and the cloud device based on the matching relationship between the identification code and the software version. This eliminates the situation where the software version upgraded via OTA is inconsistent with the software version at the time of access, and ensures the normal upgrade of the vehicle software.

[0011] In conjunction with the first aspect, in one possible implementation, before updating the first software version and / or the first identification code, the method further includes: sending a first task to a first vehicle; the first task is used to instruct the updating of the first software version information and / or the first identification code; wherein, if the first software version information is inconsistent with the second software version information, the first task includes a first mapping; or, if the first software version information is consistent with the second software version information, the first task includes a second mapping; the second mapping includes the association between the third software version information and the third identification code; the third software version information is different from the second software version information, and / or, the third identification code is different from the second identification code.

[0012] In this way, the matching relationship between software version information and identification code can be guaranteed during the OTA software upgrade process. Based on the consistency between software version and identification code in the vehicle and / or cloud, the inconsistency between the software version upgraded via OTA and the software version at the time of access can be eliminated, thus ensuring the normal upgrade of vehicle software.

[0013] In conjunction with the first aspect, in one possible implementation, the method further includes: sending a first software package to a first vehicle; the first software package is used to update the software version information corresponding to the first vehicle; wherein, if the first software version information is inconsistent with the second software version information, the first software package includes a second identification code; or, if the first software version information is consistent with the second software version information, the first software package includes a third identification code.

[0014] In this way, the matching relationship between software version information and identification code can be guaranteed during the OTA software upgrade process. Based on the consistency between software version and identification code in the vehicle and / or cloud, the inconsistency between the software version upgraded via OTA and the software version at the time of access can be eliminated, thus ensuring the normal upgrade of vehicle software.

[0015] In conjunction with the first aspect, one possible implementation further includes: if the first software version information and the second software version information are inconsistent, sending the first software version information, the first identification code, and / or alarm information to the server and / or the display device of the first vehicle; the alarm information is used to indicate that the mapping relationship between the identification code and / or the software version information of the first vehicle and the server is inconsistent.

[0016] This allows cloud devices and / or the vehicle's display devices to process alarm information sent from the vehicle in a timely manner, further ensuring the normal upgrade of the vehicle's software.

[0017] In conjunction with the first aspect, in one possible implementation, updating the first software version information and / or the first identifier code includes: receiving a first task from a server, the first task being used to instruct the updating of the first software version information and / or the first identifier code; wherein, if the first software version information is inconsistent with the second software version information, the first task includes a first mapping; or, if the first software version information is consistent with the second software version information, the first task includes a second mapping; the second mapping includes an association between the third software version information and the third identifier code; the third software version information is different from the second software version information, and / or, the third identifier code is different from the second identifier code.

[0018] In this way, the matching relationship between software version information and identification code can be guaranteed during the OTA software upgrade process. Based on the consistency between software version and identification code in the vehicle and / or cloud, the inconsistency between the software version upgraded via OTA and the software version at the time of access can be eliminated, thus ensuring the normal upgrade of vehicle software.

[0019] In conjunction with the first aspect, one possible implementation further includes: receiving a first software package from a server; the first software package being used to update software version information corresponding to the first vehicle; wherein, if the first software version information is inconsistent with the second software version information, the first software package includes a second identification code; or, if the first software version information is consistent with the second software version information, the first software package includes a third identification code.

[0020] In this way, the matching relationship between software version information and identification code can be guaranteed during the OTA software upgrade process. Based on the consistency between software version and identification code in the vehicle and / or cloud, the inconsistency between the software version upgraded via OTA and the software version at the time of access can be eliminated, thus ensuring the normal upgrade of vehicle software.

[0021] In conjunction with the first aspect, in one possible implementation, the first vehicle includes multiple electronic control units associated with the first software package. Updating the software in the first vehicle according to the first software package includes: sending the 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 if any one or more of the N software installation results are installation failures, rolling back the overall vehicle software version and identification code of the first vehicle.

[0022] In this way, the matching relationship between software version information and identification code can be guaranteed during the OTA software upgrade process. Based on the consistency between software version and identification code in the vehicle and / or cloud, the inconsistency between the software version upgraded via OTA and the software version at the time of access can be eliminated, thus ensuring the normal upgrade of vehicle software.

[0023] In conjunction with the first aspect, in one possible implementation, alarm information is received from the first vehicle; the alarm information is then displayed.

[0024] In conjunction with the first aspect, in one possible implementation, the identification code includes the first regulatory-related software identification code RXSWIN. This allows for the use of the matching relationship between RXSWIN and the software version to ensure consistency between RXSWIN and the software version during OTA maintenance and software installation, thus guaranteeing normal vehicle software upgrades.

[0025] In this way, alarm messages that indicate a mismatch between the system's internal software version information and the identification code can be displayed to the user through the user interface, making it convenient for the user to take timely follow-up actions and further ensuring the normal upgrade of the vehicle's software.

[0026] Secondly, embodiments of this application provide an OTA-based communication device, a communication unit for obtaining first information and second information; the first information includes first software version information and / or a first identifier code; the second information includes a first mapping; the first mapping contains the association between the second software version information and the second identifier code; the identifier code is used to indicate the permission information of the software version; the processing unit is further configured to verify the consistency 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.

[0027] In conjunction with the second aspect, in one possible implementation, the processing unit is specifically configured to: determine that the first software version information and the second software version information are inconsistent if the first software version information and the second software version information are inconsistent, and / or if the first identifier code and the second identifier code are inconsistent; or determine that the first software version information and the second software version information are consistent if the first software version information and the second software version information are consistent, and / or if the first identifier code and the second identifier code are consistent.

[0028] In conjunction with the second aspect, in one possible implementation, the processing unit is further configured to: update the first software version information and / or the first identification code if the first software version information and the second software version information are inconsistent; or, update the first software version information and / or the first identification code if the first software version information and the second software version information are consistent.

[0029] In conjunction with the second aspect, in one possible implementation, the communication unit is specifically configured to: send a first task to a first vehicle; the first task is configured to instruct the updating of first software version information and / or a first identification code; wherein, if the first software version information is inconsistent with the second software version information, the first task includes a first mapping; if the first software version information is consistent with the second software version information, the first task includes a second mapping; the second mapping includes an association between third software version information and a third identification code; the third software version information is different from the second software version information, and / or, the third identification code is different from the second identification code.

[0030] In conjunction with the second aspect, in one possible implementation, the communication unit is further configured to: send a first software package to the first vehicle; the first software package is used to update the software version information corresponding to the first vehicle; wherein, if the first software version information is inconsistent with the second software version information, the first software package includes a second identification code; or, if the first software version information is consistent with the second software version information, the first software package includes a third identification code.

[0031] In conjunction with the second aspect, in one possible implementation, the communication unit is further configured to: send the first software version information, the first identification code, and / or alarm information to the server and / or the display device of the first vehicle when the first software version information is inconsistent with the second software version information; the alarm information is used to indicate that the mapping relationship between the vehicle's identification code and / or software version information and the server is inconsistent.

[0032] In conjunction with the second aspect, in one possible implementation, the communication unit is specifically configured to: receive a first task from a server, the first task being configured to instruct the updating of first software version information and / or a first identification code; wherein, if the first software version information is inconsistent with second software version information, the first task includes a first mapping; or, if the first software version information is consistent with second software version information, the first task includes a second mapping; and third software version information is different from second software version information, and / or, third identification code is different from second identification code.

[0033] In conjunction with the second aspect, in one possible implementation, the communication unit is further configured to: receive a first software package from a server; the first software package is used to update the software version information corresponding to the first vehicle; wherein, if the first software version information is inconsistent with the second software version information, the first software package includes a second identification code; or, if the first software version information is consistent with the second software version information, the first software package includes a third identification code.

[0034] In conjunction with the second aspect, in one possible implementation, the communication unit is specifically used to send the first software package corresponding to each of the N electronic control units to the N electronic control units; N is a positive integer; the communication unit is specifically used to receive N software installation results from the N electronic control units; and the processing unit is specifically used to roll back the vehicle software version and identification code of the first vehicle if any one or more of the N software installation results are installation failures.

[0035] In a possible implementation, the communication unit is specifically used to receive alarm information from the first vehicle; the display unit is specifically used to display the alarm information.

[0036] In conjunction with the second aspect, in one possible implementation, the identifier includes the first regulatory-related software identifier RXSWIN.

[0037] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program or instructions that, when executed on a computer, cause the computer to perform an OTA-based communication method as described in the first aspect and any possible implementation thereof.

[0038] Fourthly, embodiments of this application provide an OTA-based communication device, which includes a processor and a memory. The memory stores instructions, which, when executed by the processor, implement the OTA-based communication method as described in the first aspect and any possible implementation thereof.

[0039] Fifthly, this application provides a chip or chip system including at least one processor and a communication interface. The communication interface and the at least one processor are interconnected via a circuit. The at least one processor is used to run computer programs or instructions to implement the OTA-based communication method described in the first aspect and any possible implementation thereof. The communication interface in the chip can be an input / output interface, pins, or circuits, etc.

[0040] In one possible implementation, the chip or chip system described above in this application further includes at least one memory storing instructions. The memory can be an internal storage unit of the chip, such as a register or cache, or it can be a storage unit of the chip itself (e.g., read-only memory, random access memory, etc.).

[0041] Sixthly, embodiments of this application provide a computer program product that, when run on one or more processors, implements the method described in the first aspect and any possible implementation of the first aspect.

[0042] It should be understood that the second to sixth aspects of this application correspond to the technical solutions of the first aspect of this application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation are similar, and will not be repeated here. Attached Figure Description

[0043] Figure 1 This application provides a schematic diagram illustrating the correspondence between RXSWIN and software versions.

[0044] Figure 2 This is a schematic diagram illustrating the first application scenario provided in the embodiments of this application;

[0045] Figure 3 A schematic diagram of a system architecture for software updates in a vehicle provided in an embodiment of this application;

[0046] Figure 4 This is a schematic diagram illustrating a second application scenario provided in an embodiment of this application;

[0047] Figure 5 This is a schematic diagram illustrating a third application scenario provided in the embodiments of this application;

[0048] Figure 6 A flowchart illustrating an OTA-based communication method provided in an embodiment of this application;

[0049] Figure 7 A schematic diagram illustrating a process for maintaining the consistency between the identifier code and software version information in the cloud, as provided in an embodiment of this application;

[0050] Figure 8 A schematic diagram illustrating the process of ensuring consistency between vehicle-side maintenance identification code and software version information, provided in an embodiment of this application;

[0051] Figure 9 A schematic diagram of an interface for displaying alarm information provided in an embodiment of this application.

[0052] Figure 10 A schematic diagram illustrating a cloud-based consistency determination process provided in an embodiment of this application;

[0053] Figure 11 A schematic diagram illustrating a software update process provided in an embodiment of this application;

[0054] Figure 12 A schematic diagram illustrating a process for sending software packages from the cloud to the vehicle, provided as an embodiment of this application;

[0055] Figure 13 A schematic diagram illustrating a process for installing software packages on a vehicle, as provided in an embodiment of this application;

[0056] Figure 14 A schematic diagram illustrating another process for installing software packages on a vehicle side, provided as an embodiment of this application;

[0057] Figure 15 A schematic diagram of the structure of an OTA-based communication device provided in an embodiment of this application;

[0058] Figure 16 This is a schematic diagram of the hardware structure of a control device provided in an embodiment of this application;

[0059] Figure 17 This is a schematic diagram of the structure of a chip provided in an embodiment of this application. Detailed Implementation

[0060] To facilitate a clear description of the technical solutions in the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish identical or similar items with essentially the same function and effect. For example, the first identifier code and the second identifier code are used to distinguish different identifier codes, but do not limit their order. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and the terms "first" and "second" are not necessarily different.

[0061] It should be noted that, in this application, the terms "exemplary" or "for example" are used to indicate that something is being described as an example, illustration, or illustration. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0062] In this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, a and b, a and c, b and c, or a, b, and c, where a, b, and c can be single or multiple.

[0063] With the development of autonomous driving, people have increasingly higher demands for the computing and control capabilities of automobiles. More and more automotive functions are being provided to users in the form of software, making software-defined vehicles a significant trend in automotive development. Software-defined vehicles require cars to be able to install and update software as easily as computers or smartphones, ensuring that various car functions remain up-to-date. Normally, when car software needs an update, users can drive their cars to a 4S shop or repair center where professional technicians use specialized equipment to refresh the software. Over-the-air (OTA) updates provide a technical means to remotely upgrade or fix car software defects. Users can use OTA technology to connect to the cloud to download and install software. OTA alleviates the current limitations of time and space for car software upgrades, and therefore, OTA has been widely used in the automotive industry.

[0064] However, while OTA (Over-The-Air) updates bring convenience, they also present challenges to vehicle market access. Market access can be understood as the process of undergoing a series of safety or emissions tests before a vehicle is launched on the market to meet relevant standards. Specifically, because vehicle defects can lead to significant personal injury and property damage, automobiles are a special product. Before being launched, vehicles must undergo market access tests; only after passing these tests can a vehicle be allowed to enter the market. Once a vehicle product applies for and passes market access, the regulatory agency responsible for vehicle market access records this information and announces it to the public. Vehicles that have been announced are allowed to be sold. This announcement may include basic information such as wheelbase, weight, or engine displacement, as well as technical specifications such as driving range or maximum speed.

[0065] To ensure the consistency of automobile production after market access, regulatory authorities can periodically conduct spot checks on relevant parameters of automobile products and compare them with the information in the announcement. If the information in the announcement is inconsistent with the parameters for market access, it violates the production consistency rule, and the authorities can require automobile manufacturers to rectify the situation or implement measures such as production suspension.

[0066] After a car is launched, its software can be updated via Over-The-Air (OTA). However, the update process may alter the testing parameters used when the software was initially approved. For example, an OTA upgrade to the battery management software might increase the car's driving range, making it inconsistent with the range measured at the time of approval. This could invalidate the data from the initial approval tests, requiring retesting. Therefore, the inconsistency between the software version updated via OTA and the version used at the time of approval poses a challenge to the development of OTA. Based on this, the United Nations World Forum for Harmonization of Vehicle Regulations, under the United Nations Economic Commission for Europe (UNECE), established an OTA working group to discuss incorporating OTA into the market access regulatory system. This group states that if an OTA update might affect market access consistency, an application for market access change must be submitted to the market access regulatory body before the OTA upgrade. To monitor such changes, a regulatory-related software identification number (RXSWIN) has been proposed. The RXSWIN records the relationship between the software version and market access, allowing for the recording and tracing of software and software upgrades that affect market access from a regulatory perspective, facilitating the management of vehicle software upgrades by market access regulatory bodies. The change in RXSWIN can indicate a change in access caused by a software upgrade.

[0067] For example, Figure 1 This is a schematic diagram illustrating the correspondence between RXSWIN and software versions, provided as an embodiment of this application. Figure 1As shown in 'a', during the access process, an initial RXSWIN and its corresponding software version can be configured, such as the initial RXSWIN being R79110. The software version corresponding to R79110 can include: software version v1.0 for the power steering electronic control unit (ECU); software version v2.0 for the vehicle stability ECU; and software version v1.0 for the vehicle control ECU.

[0068] When software is upgraded via OTA, it can be upgraded to, for example... Figure 1 As shown in b, this diagram illustrates the correspondence between the upgraded RXSWIN and its software version. Since the OTA update did not alter the test data corresponding to the software at the time of access, the software version information associated with RXSWIN can change after a software upgrade that does not affect access, but RXSWIN itself remains unchanged. At this point, the software versions corresponding to R79 110 may include: power steering ECU software version v1.1; vehicle stability ECU software version v2.2; and vehicle control ECU software version v1.0.

[0069] When further software upgrades are performed via OTA, it can be upgraded to, for example... Figure 1 Figure c illustrates the matching relationship between RXSWIN and software version after a software upgrade affecting access. When a software upgrade affecting access occurs, the software version information associated with RXSWIN changes, and RXSWIN itself changes. For example, RXSWIN changes from R79 110 to R79 111. In this case, the software version corresponding to R79 111 can include: software version v2.0 for the power steering ECU; software version v2.2 for the vehicle stability ECU; and software version v1.0 for the vehicle control ECU. In this case, the OTA upgrade causes the software version corresponding to the power steering ECU to upgrade from v1.1 to v2.0. This upgrade of the power steering ECU leads to a change in the test parameters corresponding to this software at the time of access, hence the change in RXSWIN from R79 110 to R79 111. This RXSWIN is used to indicate that the OTA upgrade affected the parameters at the time of access.

[0070] In other words, such as Figure 1As shown, RXSWIN can be used in OTA-based software upgrades to represent the correspondence between software versions. However, during OTA maintenance and software installation, it's impossible to guarantee the consistency between the RXSWIN and the software version on both the vehicle and cloud sides. This makes it difficult to effectively address situations where the software version upgraded via OTA differs from the version used during initial access, thus hindering the secure maintenance of automotive software upgrades. Currently, there is a lack of suitable methods for managing RXSWIN and maintaining consistency between the RXSWIN and the software version on both the vehicle and / or cloud sides.

[0071] In view of this, embodiments of this application provide an OTA-based communication method and apparatus, which can acquire first information and second information during OTA maintenance and software installation, utilize the matching relationship between the identifier code in the first information and the software version, and verify the consistency between the first information and the second information based on the matching relationship between the identifier code and the software version. In turn, by maintaining the consistency between the software version and the identifier code in the vehicle and / or cloud, the situation where the software version upgraded via OTA is inconsistent with the software version at the time of access can be eliminated, thus ensuring the normal upgrade of the vehicle software.

[0072] Optionally, the identifier can be RXSWIN.

[0073] To better understand the methods of the embodiments of this application, the application scenarios to which the embodiments of this application are applicable are described below.

[0074] Among the possible implementations, the OTA-based communication method provided in this application embodiment can be applied to various scenarios of OTA maintenance and upgrades for vehicles, such as maintaining the consistency of identification codes and software versions through data interaction between the vehicle and cloud devices, or downloading or updating software in the vehicle. The number of vehicle and / or cloud devices can be one or more.

[0075] The vehicle-side (or vehicle or vehicle-side equipment) can be any form of vehicle undergoing software upgrades, or any form of vehicle auxiliary equipment (such as vehicle charging piles, etc.), and this application embodiment does not specifically limit it.

[0076] The cloud (or cloud device or server) can be an OTA server used to distribute vehicle upgrade packages, or it can be a proxy server, such as a server serving a fleet. When the cloud device acts as a proxy server, the proxy server can 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 the OTA server generates the vehicle upgrade package, it can distribute the upgrade package to the proxy servers. Understandably, the OTA server can also divide the vehicle upgrade package into chunks and distribute it to multiple proxy servers.

[0077] The cloud can be a software client server used to update software, a fleet server that has obtained and updated software from a software client server, or any other possible server.

[0078] The cloud can also be any type of vehicle, any type of vehicle auxiliary equipment (such as vehicle charging piles), or mobile terminal (such as mobile phones, tablets, wearable devices, etc.), and this application embodiment does not specifically limit it.

[0079] The aforementioned vehicle and cloud device can establish a communication connection. For example, the vehicle and cloud device can establish a communication connection through protocols such as Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol over Secure Socket Layer (HTTPS). This application embodiment does not impose any restrictions on this.

[0080] Figure 2 This is a schematic diagram illustrating a first exemplary application scenario provided in this application. For example... Figure 2As shown, this scenario may include a vehicle 201 and a software OTA cloud device 202. Vehicle 201 can be any type of vehicle with a software OTA client installed. Software OTA cloud device 202 is a server providing OTA upgrades, used to store software packages and the mapping relationship between stored identifiers (e.g., RXSWIN) and software versions. When updating the software in vehicle 201, software OTA cloud device 202 can obtain the software version information and / or identifiers of each software on the software OTA client in vehicle 201, and compare them with its stored mapping relationship between identifiers and software versions. When the software version information and / or identifiers of each software in vehicle 201 match the mapping relationship, it can automatically send, or send according to the request command of the software OTA client, a software package containing the identifier to the software OTA client in vehicle 201. The software OTA client in vehicle 201 can update the software and identifiers according to the software package from the software OTA cloud device.

[0081] The number of vehicles 201 and software OTA cloud devices 202 can be one or more, and this application embodiment does not specifically limit this.

[0082] In one possible implementation, the software OTA cloud device could also be a vehicle manufacturer's OTA cloud device. In this case, the vehicle manufacturer's OTA cloud device could be an OTA server used to distribute vehicle upgrade packages.

[0083] The following describes the implementation process of the aforementioned software OTA cloud devices and OEM OTA cloud devices in vehicles. For example, Figure 3 This is a schematic diagram of a system architecture for software updates in a vehicle, provided as an embodiment of this application. Figure 3 As shown, the system may include: vehicle manufacturer OTA cloud device 301, software OTA cloud device 302, main control OTA client 303, and software OTA client 304.

[0084] Among them, the OTA cloud device 301 can be a server of the vehicle manufacturer or the in-vehicle software service provider, used to manage the in-vehicle software and store software data. The in-vehicle software may include body control software, etc. The software OTA cloud device 302 can be used to store software packages, as well as the mapping relationship between storage identifiers and software versions, etc. The OTA cloud device 301 can interact with the software OTA cloud device 302. The software information of the OTA cloud device 301 comes from the software OTA cloud device 302, or the OTA cloud device 301 can determine the software information itself.

[0085] It should be noted that OTA upgrades in vehicles can include two levels: master node and slave node. For example... Figure 3As shown, the master OTA client 303 corresponds to the master node and can receive the vehicle upgrade package, which can then be split and distributed to multiple slave clients under its control. The software OTA client 304 corresponds to a slave node and can be a slave OTA client under the master OTA client 303. The software OTA client 304 can perform software updates as part of the vehicle OTA upgrade.

[0086] Therefore, there are two possible software update methods in this system architecture. One possible implementation is that the software OTA cloud device 302 interacts with the software OTA client 304 to update the software. The specific implementation process is as follows... Figure 1 The application scenarios shown are consistent with the descriptions, so they will not be repeated here.

[0087] Another possible implementation involves interaction between the vehicle manufacturer's OTA cloud device 301, the main control OTA client 303, and the software OTA client 304 to update the software. For example, the vehicle manufacturer's OTA cloud device 301 can send the software package to be updated via a vehicle upgrade package to the main control OTA client 303 based on its stored mapping relationship between identifiers and software versions, and the consistency of the software version and / or identifier obtained from the main control OTA client 303 (or the software OTA client 304). The main control OTA client 303 receives and downloads the vehicle upgrade package, splits it, and sends it to the software OTA client 304. The software OTA client 304 updates the software and identifiers according to the software packages in the split vehicle upgrade package.

[0088] like Figure 4 As shown, Figure 4 This is a schematic diagram illustrating a second exemplary application scenario provided in the embodiments of this application. For example... Figure 4 As shown, this application scenario may include server 401, first vehicle 402, second vehicle 403, second vehicle 404, and second vehicle 405.

[0089] Server 401 can be a fleet server. The fleet server can obtain the vehicle upgrade packages required by the fleet it serves (e.g., including vehicle 402, vehicle 403, vehicle 404, and vehicle 405) from the OTA server in advance.

[0090] During routine maintenance of the fleet, when connected to the network via wireless-fidelity (WIFI), vehicles 402, 403, 404, and 405 connect to the fleet server. When an upgrade package download notification is received, the fleet server performs two-way authentication with vehicles 402, 403, 404, and 405 (e.g., authentication based on public key infrastructure). After successful authentication, the fleet server encrypts the upgrade package's encryption key k (using the vehicle's public key) and sends it to vehicles 402, 403, 404, and 405.

[0091] For example, vehicles 402, 403, 404, and 405 can all use key k to decrypt the key and download their respective vehicle software packages from the server. For instance, vehicle 402 can update its software based on a complete vehicle upgrade package. This upgrade package may include a software package for updating the identification code. Vehicle 402 can then update both the software and the identification code based on the software package.

[0092] like Figure 5 As shown, Figure 5 This is a schematic diagram illustrating a third exemplary application scenario provided in the embodiments of this application. For example... Figure 5 As shown, this application scenario may include a vehicle 501 and a vehicle auxiliary device 502. The vehicle 501 can be any type of vehicle. The vehicle auxiliary device 502 can be a vehicle charging station or other terminal device that assists in OTA updates for the vehicle (such as a mobile phone or tablet). Based on its stored mapping relationship between identifiers and software versions, and the consistency of the software version and / or identifier obtained from the vehicle 501, the vehicle auxiliary device 502 can send the required update software package to the vehicle 501. The vehicle 501 can update the software and identifier according to the received software package.

[0093] To facilitate understanding of the embodiments of this application, some terms involved in this application will be briefly explained first.

[0094] 1. Automotive OTA: This refers to the process by which a vehicle updates its system by downloading software update packages from a remote server via the internet. For example, but not limited to, each automotive OTA update corresponds to a vehicle-wide upgrade package and a vehicle version number. A vehicle-wide upgrade package contains the software for multiple ECUs within the vehicle.

[0095] 2. Automotive Manufacturer OTA Cloud Equipment: A cloud service provided by automotive manufacturers or service providers, responsible for managing upgrade tasks and software upgrade packages, or identification codes, etc., in the cloud and distributing them to vehicles requiring software upgrades via OTA (Over-The-Air). OTA can be accessed via Wi-Fi, Long Term Evolution (LTE), 5th Generation (5G) mobile communication systems, new radio (NR), and satellite.

[0096] 3. Software OTA cloud device: A cloud service for software that manages certain software or identification codes in a car in the cloud and sends them to users or vehicles that need to be upgraded via OTA.

[0097] It is understood that the OTA cloud devices of the vehicle manufacturers or the software OTA cloud devices in the embodiments of this application can be collectively referred to as OTA cloud devices, which are used to realize the updating of software and identification codes.

[0098] 4. Master node (update master, or Master node for short): Software deployed on a certain ECU in the vehicle, responsible for centrally controlling the OTA upgrade of the whole vehicle, downloading the whole vehicle upgrade package from the OTA cloud, splitting it and distributing it to the corresponding ECU.

[0099] Alternatively, it can be a separate module unit existing on the vehicle; this application embodiment does not limit this.

[0100] 5. Electronic Control Unit (ECU): This includes the autonomous driving controller, cockpit controller, communication box (T-Box), and gateway, etc. ECU software upgrades can be performed by downloading and installing software upgrade packages from the OTA cloud, or by having the main control node distribute software upgrade packages after splitting the entire vehicle upgrade package under centralized control and coordination.

[0101] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be implemented independently or in combination with each other. The same or similar concepts or processes may not be described again in some embodiments.

[0102] Figure 6 A flowchart illustrating an OTA-based communication method provided in this application embodiment is shown below. Figure 6 As shown, the method may include the following steps:

[0103] S601, Obtain the first information and the second information.

[0104] In this embodiment, the first information and the second information can be information used on the vehicle side and / or in the cloud to verify the consistency between the software version information and the identification code. For example, the first information may include: first software version information and / or first identification code; the second information may include a first mapping; the first mapping includes the association between the second software version information and the second identification code. The first information may come from the vehicle side; the second information may come from the cloud.

[0105] In this embodiment of the application, the identifier code can be used to indicate the permission information of the software version. Permissions can be understood as restrictions on vehicle access.

[0106] For example, the identifier can be RXSWIN or other identifiers. The software version information can be information used to identify different software versions, such as the software version number or other information.

[0107] It is understood that the identification code and software version information may include other content depending on the actual scenario, and this application embodiment does not limit this.

[0108] For example, the entity that obtains the first information and the second information can be the cloud or the vehicle. When the executing entity is the cloud, the vehicle can report the first information to the cloud, and the cloud can receive the first information reported by the vehicle and obtain the second information it has stored, and then verify the consistency between the first information and the second information; when the executing entity is the vehicle, the cloud can send the second information to the vehicle, and the vehicle can receive the second information sent from the cloud and obtain the first information it has stored, and then verify the consistency between the first information and the second information.

[0109] 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.

[0110] In this embodiment of the application, the consistency between the first software version information and the second software version information corresponding to the first mapping may include: the first software version information and the second software version information are consistent, or the first software version information and the second software version information are inconsistent.

[0111] For example, based on the first information and the second information, the entity verifying the consistency between the first software version information and the second software version information corresponding to the first mapping can include two types: the cloud or the vehicle. It is understood that this application embodiment does not limit the entity performing the verification of the consistency between the first software version information and the second software version information corresponding to the first mapping.

[0112] In summary, the embodiments of this application provide an OTA-based communication method and apparatus, which can acquire first information from the vehicle and second information from the cloud during OTA maintenance and software installation. By using the matching relationship between the identifier code in the first and second information and the software version, the consistency between the first and second information can be verified. Furthermore, by maintaining the consistency between the software version and the identifier code in the vehicle and / or the cloud, the inconsistency between the software version upgraded via OTA and the software version at the time of access can be eliminated, thus ensuring the normal upgrade of automotive software.

[0113] exist Figure 6 Based on the corresponding embodiments, in possible implementations, in steps S601-S602, the execution entity that verifies the consistency between the first software version information and the second software version information corresponding to the first mapping can be the cloud or the vehicle.

[0114] For example, method one: Utilize cloud verification to confirm the consistency between the first software version information and the second software version information corresponding to the first mapping (e.g., Figure 7 (Corresponding implementation examples).

[0115] Method 2: Verify the consistency between the first software version information and the second software version information corresponding to the first mapping using the vehicle-side verification (e.g., Figure 8 (Corresponding implementation examples).

[0116] Method 1: Verify the consistency between the first software version information and the second software version information using the cloud.

[0117] For example, Figure 7 This is a schematic diagram illustrating a process for maintaining the consistency between identifier codes and software version information in the cloud, as provided in an embodiment of this application. Figure 7 In the corresponding embodiment, taking the cloud as the OTA cloud, the vehicle end as the main control node, ECU1 and ECU2, the identification code as RXSWIN, and the first mapping as RXSWIN mapping (including the association between RXSWIN and software version information) as an example, the cloud verifies the consistency between the first software version information and the second software version information based on the first information and the second information. This example does not constitute a limitation on the embodiments of this application.

[0118] like Figure 7 As shown, the process of maintaining consistency between the identifier code and software version information in the cloud may include the following steps:

[0119] S701, the master control node collects software version information from each ECU (including ECU1 and ECU2).

[0120] For example, the master node can periodically collect software version information from each ECU. For instance, it could be configured to collect software version information from each ECU weekly.

[0121] S702, the main control node reports the vehicle's software version information to the OTA cloud.

[0122] The OTA cloud system receives the software version information reported by the vehicle.

[0123] Optionally, when the vehicle terminal stores the RXSWIN identifier, the vehicle terminal can execute the steps shown in S703.

[0124] S703, the main control node reports the RXSWIN identifier from the vehicle to the OTA cloud.

[0125] The OTA cloud system receives the RXSWIN reported by the vehicle.

[0126] S704 and OTA cloud check the consistency of RXSWIN related software version information. If they are inconsistent, the software will be upgraded.

[0127] For example, the OTA cloud compares the software version information reported in step S702 with the RXSWIN mapping table stored in the OTA cloud. When the software version information reported by the master control node is inconsistent with the software version information in the RXSWIN mapping table, it indicates that the software related to access has been modified in a non-compliant manner. At this time, the OTA cloud can upgrade the software via OTA and modify the software version information on the vehicle side to ensure the consistency between the software version information on the vehicle side and the RXSWIN mapping table stored in the OTA cloud.

[0128] Optionally, when the vehicle reports the RXSWIN identifier to the cloud, the cloud can execute the steps shown in S705.

[0129] S705 and OTA cloud check RXSWIN consistency; if inconsistent, update RXSWIN.

[0130] For example, the OTA cloud compares the RXSWIN identifier reported in step S703 with the RXSWIN mapping table stored in the OTA cloud. When the RXSWIN identifier reported by the vehicle is inconsistent with the RXSWIN identifier in the RXSWIN mapping table, it indicates that the vehicle's RXSWIN has been tampered with. At this time, the OTA cloud can issue an instruction to update the vehicle's RXSWIN identifier to ensure the consistency between the vehicle's RXSWIN identifier and the RXSWIN mapping table stored in the OTA cloud.

[0131] It is understandable that the OTA cloud can perform a software upgrade based on the consistency judgment of the vehicle-side and cloud software version information shown in step S704; it can perform a software upgrade based on the consistency judgment of the vehicle-side and cloud RXSWIN shown in step S705; or, it can determine whether to perform a software upgrade based on the consistency of the vehicle-side and cloud software version information and the consistency of RXSWIN shown in steps S704 and S705 respectively.

[0132] Method 2: Verify the consistency between the first software version information and the second software version information using the vehicle-side.

[0133] For example, Figure 8 This is a schematic diagram illustrating the process of ensuring consistency between vehicle-side maintenance identification codes and software version information, provided as an embodiment of this application. Figure 8 In the corresponding embodiment, taking the cloud as the OTA cloud and the vehicle as the main control node, ECU1 and ECU2, with the identifier RXSWIN and the first mapping as RXSWIN mapping (including the association between RXSWIN and software version information), the vehicle verifies the consistency between the first software version information and the second software version information based on the first information and the second information. This example does not constitute a limitation on the embodiments of this application.

[0134] like Figure 8 As shown, the process of ensuring consistency between the vehicle-side maintenance identification code and the software version information may include the following steps:

[0135] S801 and OTA cloud download RXSWIN and RXSWIN mapping table to the master node.

[0136] The master node receives the RXSWIN and RXSWIN mapping table sent from the cloud via OTA.

[0137] For example, when any RXSWIN identifier or any software version information in the RXSWIN mapping table stored in the OTA cloud changes, the OTA cloud can send the changed RXSWIN mapping table to the master control node.

[0138] S802, the master control node collects software version information from each ECU (including ECU1 and ECU2).

[0139] S803, the master node checks the consistency of RXSWIN related software version information.

[0140] S804. If the master node determines that the RXSWIN related software version information is inconsistent, it can send an alarm to the OTA cloud and report the inconsistent software version information.

[0141] For example, if the master control node determines that the software version information reported by each ECU in step S802 is inconsistent with the software version information in the RXSWIN mapping table sent by the OTA cloud in step S802, it can indicate that the vehicle-side software related to access has been modified in a non-compliant manner. At this time, the master control node can report the inconsistent message to the OTA cloud.

[0142] Based on this, by verifying the consistency between the first software version information and the second software version information in the cloud or on the vehicle, the consistency between the software version and RXSWIN in the vehicle and / or cloud can be maintained to prevent the software version and / or RXSWIN from being tampered with, thus ensuring the normal upgrade of automotive software via OTA.

[0143] exist Figure 6 Based on the corresponding embodiments, possible implementations also include:

[0144] S603 (not shown in the figure): In the event that the first software version information and the second software version information are inconsistent, the first vehicle sends the first software version information, the first identification code and / or the alarm information to the cloud and / or the display device of the first vehicle.

[0145] Accordingly, the display device can receive first software version information, first identification code, and / or alarm information from the first vehicle. The vehicle-side device described in this embodiment may include the first vehicle.

[0146] In this embodiment, the alarm information is used to indicate that the mapping relationship between the vehicle's identification code and / or software version information and the server is inconsistent. The display device can be the central control display screen of the first vehicle, the instrument panel display screen of the first vehicle, or other display devices connected to the vehicle, such as a mobile phone. In this embodiment, the display device may include other content depending on the actual scenario, and this embodiment does not impose any limitations on this.

[0147] S604 (not shown in the figure) displays alarm information on the display device.

[0148] For example, Figure 9 This is a schematic diagram of an interface for displaying alarm information provided in an embodiment of this application. For example... Figure 9 As shown, this interface can be the interface displayed on the central control display screen 900 of the first vehicle. The interface displayed on the central control display screen 900 may include a software version update indication message 901, a system prompt message 902, a stop control 903, and a continue control 904, etc. The indication message 901 displays "Power steering software V2.0 (R79 90) is updating...". Here, V2.0 can be the software version information of the power steering software, and R79 90 can be the identifier code corresponding to the software version of the power steering software.

[0149] Before a software update, if the first vehicle detects a discrepancy between the first and second software version information, it can send an alarm message to the central control display screen 900. This alarm message can be a system prompt message 902 displayed on the central control display screen 900. The system prompt message 902 states, "Vehicle software may have been illegally tampered with; please handle it immediately!" When the user subsequently sees this prompt message, they can trigger the stop control 903 to pause the software update; alternatively, they can drive the vehicle to a 4S dealership for processing.

[0150] Based on this, alarm information that indicates a mismatch between the software version information and the identification code can be displayed to the user through the user interface, making it convenient for the user to take timely follow-up actions and further ensuring the normal upgrade of the vehicle software.

[0151] exist Figure 6 Based on the corresponding embodiments, in possible implementations, S602 may include:

[0152] In one implementation, if the first software version information is inconsistent with the second software version information, and / or the first identifier code is inconsistent with the second identifier code, it is determined that the first software version information is inconsistent with the second software version information.

[0153] This can be understood as follows: if the first software version information is inconsistent with the second software version information, the first identifier code is inconsistent with the second identifier code, or if the first software version information is inconsistent with the second software version information and the first identifier code is inconsistent with the second identifier code, then it is determined that the first software version information is inconsistent with the second software version information.

[0154] The inconsistency between the first software version information and the second software version information can be understood as either the first identifier code and the second identifier code being the same, or the first identifier code and the second identifier code being different; the inconsistency between the first identifier code and the second identifier code can also be understood as either the first software version information and the second software version information being the same, or the first software version information and the second software version information being different.

[0155] In another implementation, if the first software version information is consistent with the second software version information, and / or the first identifier code is consistent with the second identifier code, then the first software version information is determined to be consistent with the second software version information.

[0156] This can be understood as follows: if the first software version information is consistent with the second software version information, and the first identifier code is consistent with the second identifier code, or if the first software version information is consistent with the second software version information and the first identifier code is consistent with the second identifier code, then the first software version information is determined to be consistent with the second software version information.

[0157] Based on this, in scenarios where the first task is issued from the cloud, under the condition that the first software version information and / or the first identifier code are consistent with the first mapping, consistency verification can be used to further ensure the normal upgrade of automotive software via OTA. In scenarios where the consistency between the identifier code and the software version information is checked periodically in the cloud and / or on the vehicle, under the condition that the first software version information and / or the first identifier code are inconsistent with the first mapping, non-compliance risks caused by such inconsistencies can be detected in a timely manner, preventing the identifier code and / or software version information from being tampered with, and ensuring the normal upgrade of automotive software via OTA.

[0158] exist Figure 6 Based on the corresponding embodiments, possible implementations may further include: updating the first software version information and / or the first identification code when the first software version information and the second software version information are inconsistent; or updating the first software version information and / or the first identification code when the first software version information and the second software version information are consistent.

[0159] In one implementation, a scenario where the first software version information and the second software version information are inconsistent can occur because the first software version information and / or the first identifier code on the vehicle side have been tampered with, causing a discrepancy between the first software version information on the vehicle side and the second software version information on the cloud side. The cloud side can then distribute its stored software version information and / or identifier code to the vehicle side, ensuring consistency between the software version information and identifier code on the cloud and the vehicle side. The software version information and / or identifier code distributed by the cloud side can be consistent with the software version information and / or identifier code stored on the vehicle side before the tampering. In this scenario, if the first software version information and the second software version information are consistent, then updating the first software version information and / or the first identifier code is unnecessary.

[0160] For example, the process of updating the first software version information and / or the first identifier code based on inconsistency can be as follows: Figure 7 as well as Figure 8 The corresponding implementation examples will not be described in detail here.

[0161] In another implementation, the scenario where the first software version information and the second software version information are consistent can be as follows: the cloud issues a first task (or update task). When the cloud determines that the first software version information and / or the first identifier code reported by the vehicle are consistent with the second software version information stored in the cloud, the cloud can then, based on the consistency guarantee, issue the software version information and / or identifier code carried in the first task to the vehicle. In this scenario, if the first software version information and the second software version information are inconsistent, then updating the first software version information and / or the first identifier code is not required.

[0162] For example, Figure 10 This is a schematic diagram illustrating a cloud-based consistency determination process provided in an embodiment of this application. Figure 10 In the corresponding embodiment, taking the cloud as the OTA cloud, the vehicle end as the main control node, the first mapping as the RXSWIN mapping, and the identifier code as RXSWIN as an example, this describes how to update the first software version information and / or the first identifier code when the first software version information and the second software version information are consistent. This example does not constitute a limitation on the embodiments of this application.

[0163] like Figure 10 As shown, the process of performing consistency checks in the cloud can include:

[0164] S1001, OTA cloud collection of the RXSWIN identifier on the master control node.

[0165] S1002, OTA cloud check RXSWIN consistency.

[0166] For example, if the OTA cloud determines that the RXSWIN identifier on the vehicle is inconsistent with the RXSWIN identifier in the first mapping, the OTA cloud can determine not to perform OTA.

[0167] If the OTA cloud determines that the RXSWIN identifier on the vehicle is consistent with the RXSWIN identifier in the first mapping, the OTA cloud can send an update task to the master control node. This update task can carry the new RXSWIN identifier and the RXSWIN mapping table.

[0168] S1003, The master node saves the new RXSWIN identifier and RXSWIN mapping table.

[0169] Based on this, the cloud and vehicle can maintain the consistency of the mapping relationship between the vehicle's software version information and / or identification code and the cloud based on the matching relationship between the identification code and the software version. This will eliminate the situation where the software version upgraded via OTA is inconsistent with the software version at the time of access, and ensure the normal upgrade of the vehicle software.

[0170] The above describes the process of maintaining consistency between the software version information and the identification code on the vehicle side and / or in the cloud. The following describes the process of ensuring consistency between the software version information and the identification code during the OTA upgrade of automotive software.

[0171] For example, Figure 11 This is a schematic diagram illustrating a software update process provided in an embodiment of this application. Figure 11 As shown, the main components for updating the software can include the cloud and a first vehicle. The first vehicle can include a master control node and one or more ECUs.

[0172] like Figure 11As shown, the software update process may include the following steps:

[0173] S1101, The cloud sends the first task to the first vehicle.

[0174] Accordingly, the first vehicle receives the first task and can update the first software version information and / or the first identification code based on the first task. The entity receiving the first task can be the master control node within the first vehicle.

[0175] In this embodiment, the first task is used to instruct the updating of the first software version information and / or the first identification code; when the first software version information is inconsistent with the second software version information, the first task includes a first mapping; when the first software version information is consistent with the second software version information, the first task includes a second mapping; the second mapping includes the association between the third software version information and the third identification code; the third software version information is different from the second software version information, and / or the third identification code is different from the second identification code.

[0176] For example, when the cloud determines that the first software version information of the first vehicle is inconsistent with the second software version information on the cloud, it can be understood that the software version and / or identification code of the first vehicle may have been tampered with. At this time, the cloud can send a first task containing a first mapping. Here, the first mapping can be understood as the association between the software version information and the identification code stored in the cloud before the software version and / or identification code of the first vehicle were tampered with.

[0177] For example, when the cloud determines that the first software version information of the first vehicle is consistent with the second software version information on the cloud, it can be understood that the first vehicle's equipment and the cloud have undergone a consistency check before performing an OTA software upgrade. At this time, the cloud can send a first task containing a second mapping. The second mapping can be understood as a mapping relationship triggered by OTA that includes new software version information and a new identifier code.

[0178] Understandably, when an OTA software update is insufficient to change the test parameters corresponding to the software at the time of access, the third identifier in the second mapping may be consistent with the first identifier stored in the first vehicle. For example, if the battery management system of the first vehicle is V1.0, its system can support a range of 500km; when the battery management system is upgraded via OTA to V1.1, its range can also support 500km; at this time, since the update of the battery management system does not change the specific parameters of the range at the time of access, the third software version information in the second mapping sent by the cloud is inconsistent with the first software version information stored in the first vehicle, and the third identifier in the second mapping may be consistent with the first identifier stored in the first vehicle.

[0179] S1102, The cloud sends the first software package to the first vehicle.

[0180] Accordingly, the first vehicle can receive the first software package and update its software based on the first software package. The software package may contain software and its corresponding software version information.

[0181] In this embodiment of the application, if the first software version information and the second software version information are inconsistent, the first software package includes a second identifier; or, if the first software version information and the second software version information are consistent, the first software package includes a third identifier.

[0182] For example, when the cloud determines that the first software version information of the first vehicle is inconsistent with the second software version information on the cloud, it can be understood that the software version or identification code of the first vehicle may have been tampered with. In this case, the cloud can send a first software package containing the second identification code. The first software package can be understood as the software package stored in the cloud before the software version or identification code of the first vehicle was tampered with. This cloud-stored software package can contain the software and identification code of the first vehicle before the software version or identification code was tampered with.

[0183] For example, when the cloud determines that the first software version information of the first vehicle is consistent with the second software version information of the cloud, it can be understood that the first vehicle's equipment and the cloud have undergone a consistency check before performing an OTA software upgrade. At this time, the cloud can send a first software package containing a third identifier code. The first software package can be understood as a software package triggered by OTA.

[0184] It is understandable that when the software version update during OTA is insufficient to change the parameters at the time of access, the third identifier code can be consistent with the first identifier code, and the specific process will not be elaborated here.

[0185] S1103, The first vehicle sends the first software package corresponding to each ECU to the ECU.

[0186] Accordingly, each ECU receives the first software package. The number of ECUs can be one or more. For example, when there are N ECUs, the first vehicle can send the first software package corresponding to each of the N ECUs; N is a positive integer.

[0187] For example, when the first vehicle contains a master control node, the master control node can receive the first software package sent from the cloud and distribute the first software package to the corresponding ECU.

[0188] S1104, Install the first software package and update the identification code on the ECU.

[0189] In this embodiment of the application, the identification code can be a second identification code or a third identification code.

[0190] For example, when an error occurs during the installation of the first software package, the ECU can roll back to the software before installation and restore the first identification code. Rolling back to the software before installation can mean that the ECU restores the first software version information.

[0191] For example, when the ECU successfully installs the first software package, the ECU can update the first identifier and the first software version information.

[0192] S1105, the ECU sends the installation results to the first vehicle.

[0193] The first vehicle receives the installation result. This result can indicate successful installation or installation failure for one or more ECUs.

[0194] S1106. If the software installation results in one or more installation failures, roll back the vehicle software version and identification code of the first vehicle.

[0195] Optionally, if the software installation is successful, the vehicle version and / or identification code can be updated. For example, if the software installation is successful and the updated software is insufficient to change the vehicle version, the vehicle version may remain unchanged.

[0196] Based on this, the matching relationship between software version information and identification code can be guaranteed during the OTA software upgrade process. Furthermore, based on the consistency between the software version and identification code in the vehicle and / or cloud, the inconsistency between the software version upgraded via OTA and the software version at the time of access can be eliminated, thus ensuring the normal upgrade of automotive software.

[0197] Based on the content described in the above embodiments, in order to better understand the various embodiments of this application, the overall process of updating software on the vehicle side will be described separately below. Specifically, this process may include: the cloud sending a software package (such as...) to the vehicle side. Figure 12 (Corresponding implementation examples) The software package was successfully installed on the vehicle side (e.g. Figure 13 Corresponding implementation examples), and failure to install software packages on the vehicle side (such as...). Figure 14 (Corresponding implementation examples).

[0198] Figure 12 This is a schematic diagram illustrating a process for sending software packages from the cloud to the vehicle, as provided in an embodiment of this application. Figure 12 In the corresponding embodiment, taking the cloud as the OTA cloud and the vehicle as the main control node, ECU1 and ECU2, with the identifier code RXSWIN and the first mapping as RXSWIN mapping, the process of the cloud sending software packages to the vehicle is explained. This example does not constitute a limitation on the embodiments of this application.

[0199] like Figure 12 As shown, the process of distributing software packages from the cloud may include the following steps:

[0200] S1201, OTA cloud sends software packages to the master control node.

[0201] Accordingly, the master control node receives the software package sent from the cloud via OTA. This software package carries the relevant RXSWIN identifier.

[0202] S1202, the master node distributes the software package to ECU1 and ECU2.

[0203] Accordingly, ECU1 and ECU2 receive the software package sent by the master control node. ECU1 and ECU2 can be the ECUs corresponding to the software package.

[0204] S1203, ECU1, and ECU2 receive the software package and record the RXSWIN identifier.

[0205] Based on this, the matching relationship between software version information and identification code can be guaranteed during the OTA software upgrade process. Thus, based on the consistency between software version and identification code on the vehicle and / or cloud, the inconsistency between the software version upgraded via OTA and the software version at the time of access can be eliminated, ensuring the normal upgrade of automotive software.

[0206] The above describes the process of the cloud sending software packages to the vehicle. The following section describes the process of installing the software packages on the vehicle and ensuring successful installation.

[0207] For example, Figure 13 This is a schematic diagram illustrating a process for installing a software package on a vehicle, as provided in an embodiment of this application. Figure 13In the corresponding embodiment, taking the cloud as the OTA cloud and the vehicle as the main control node, ECU1 and ECU2, with the identifier code RXSWIN and the first mapping as RXSWIN mapping, the process of successfully installing the software package on the vehicle is explained. This example does not constitute a limitation on the embodiments of this application.

[0208] like Figure 13 As shown, the process of installing the software package on the ECU may include the following steps:

[0209] S1301, ECU1 and ECU2 installation software.

[0210] For example, after the master node distributes the software package to ECU1 and ECU2, ECU1 and ECU2 can install the software based on the software package.

[0211] Software installation successful for S1302, ECU1, and ECU2; RXSWIN updated.

[0212] S1303, ECU1, and ECU2 send the installation results to the master node.

[0213] S1304, update the vehicle version and / or update RXSWIN on the master node.

[0214] The vehicle version can also remain unchanged, which will not be elaborated here.

[0215] Based on this, the matching relationship between software version information and identification code can be guaranteed during the OTA software upgrade process. Furthermore, based on the consistency between the software version and identification code in the vehicle and / or cloud, the inconsistency between the software version upgraded via OTA and the software version at the time of access can be eliminated, thus ensuring the normal upgrade of automotive software.

[0216] The above describes the process of successfully installing the software package on the vehicle side. However, in some possible implementations, the installation of the software package on the vehicle side may encounter errors. The following section describes the process of installing the software package on the vehicle side and failing to install it.

[0217] For example, Figure 14 This is a schematic diagram illustrating another process for installing a software package on a vehicle side, as provided in an embodiment of this application. Figure 14 In the corresponding embodiment, taking the cloud as the OTA cloud and the vehicle as the main control node, ECU1 and ECU2, with the identifier code RXSWIN and the first mapping as RXSWIN mapping, the process of the vehicle failing to install the software package is explained. This example does not constitute a limitation on the embodiments of this application.

[0218] like Figure 14 As shown, the process of installing the software package on the ECU may include the following steps:

[0219] Install software on S1401, ECU1, and ECU2, and update the relevant RXSWIN.

[0220] The software installation for S1402, ECU1, and ECU2 encountered an error and was rolled back.

[0221] ECU1 and ECU2 contain the software prior to the installation of the software package. If an error occurs during the installation of the software package on ECU1 and ECU2, ECU1 and ECU2 can be rolled back to the software prior to the installation of the software package.

[0222] S1403, ECU1 and ECU2 are restored to the old RXSWIN.

[0223] Specifically, ECU1 and ECU2 store the RXSWIN before the software package was installed. When the software installation on ECU1 and ECU2 encounters an error, ECU1 and ECU2 can roll back to the RXSWIN before the software package was installed.

[0224] S1404, ECU1 and ECU2 notify the master control node of the anomaly.

[0225] S1405, Master node recovery related old RXSWIN.

[0226] Based on this, the matching relationship between software version information and identification code can be guaranteed during the OTA software upgrade process. Furthermore, based on the consistency between the software version and identification code in the vehicle and / or cloud, the inconsistency between the software version upgraded via OTA and the software version at the time of access can be eliminated, thus ensuring the normal upgrade of automotive software.

[0227] The above combination Figures 6-14 The methods provided in the embodiments of this application have been described. The apparatus for performing the above methods provided in the embodiments of this application is described below.

[0228] For example, Figure 15 A schematic diagram of the structure of an OTA-based communication device provided in this application embodiment is shown below. Figure 8 As shown, the OTA-based communication device 150 can be used in communication equipment, circuits, hardware components, or chips. The OTA-based communication device includes a display unit 1501, a processing unit 1502, and a communication unit 1503. The display unit 1501 supports the display steps of the network distribution method; the processing unit 1502 supports the information processing steps of the OTA-based communication device; and the communication unit 1503 supports the data transmission or reception steps of the OTA-based communication device.

[0229] Specifically, this application provides an OTA-based communication device, a communication unit 1503, for obtaining first information and second information; the first information includes first software version information and / or a first identifier code; the second information includes a first mapping; the first mapping includes the association between the second software version information and the second identifier code; the identifier code is used to indicate the permission information of the software version; the processing unit 1502 is further used to verify the consistency between the first software version information and the second software version information based on the first information and the second information.

[0230] In a possible implementation, the processing unit 1502 is specifically used to: determine that the first software version information and the second software version information are inconsistent when the first software version information and the second software version information are inconsistent, and / or when the first identification code and the second identification code are inconsistent; or, determine that the first software version information and the second software version information are consistent when the first software version information and the second software version information are consistent, and / or when the first identification code and the second identification code are consistent.

[0231] In a possible implementation, the processing unit 1502 is further configured to: update the first software version information and / or the first identification code when the first software version information and the second software version information are inconsistent; or, update the first software version information and / or the first identification code when the first software version information and the second software version information are consistent.

[0232] In a possible implementation, the communication unit 1503 is configured to: send a first task to a first vehicle; the first task is configured to instruct the updating of first software version information and / or a first identification code; wherein, if the first software version information is inconsistent with the second software version information, the first task includes a first mapping; if the first software version information is consistent with the second software version information, the first task includes a second mapping; the second mapping includes the association between third software version information and a third identification code.

[0233] In a possible implementation, the communication unit 1503 is further configured to: send a first software package to the first vehicle; the first software package is used to update the software version information corresponding to the first vehicle; wherein, if the first software version information is inconsistent with the second software version information, the first software package includes a second identification code; or, if the first software version information is consistent with the second software version information, the first software package includes a third identification code.

[0234] In a possible implementation, the communication unit 1503 is further configured to: send the first software version information, the first identification code, and / or alarm information to the server and / or the display device of the first vehicle when the first software version information and the second software version information are inconsistent; the alarm information is used to indicate that the mapping relationship between the vehicle's identification code and / or software version information and the server is inconsistent.

[0235] In a possible implementation, the communication unit 1503 is specifically used to receive a first task from the server, the first task being used to instruct the updating of first software version information and / or first identification code; wherein, if the first software version information is inconsistent with the second software version information, the first task includes a first mapping; or, if the first software version information is consistent with the second software version information, the first task includes a second mapping; the second mapping includes the association between third software version information and third identification code.

[0236] In a possible implementation, the communication unit 1503 is further configured to: receive a first software package from a server; the first software package is used to update the software version information corresponding to the first vehicle; wherein, if the first software version information is inconsistent with the second software version information, the first software package includes a second identification code; or, if the first software version information is consistent with the second software version information, the first software package includes a third identification code.

[0237] In possible implementations, the identification code includes the first regulatory-related software identification code RXSWIN.

[0238] In one possible embodiment, the OTA-based communication device may further include a storage unit 1504. The processing unit 1502 and the storage unit 1504 are connected by a line.

[0239] Storage unit 1504 may include one or more memories, which may be devices in one or more devices or circuits used to store programs or data.

[0240] The storage unit 1504 can exist independently and be connected to the processing unit 1502 of the OTA-based communication device via a communication line. Alternatively, the storage unit 1504 can be integrated with the processing unit 1502.

[0241] The communication unit 1503 can be an input or output interface, pins, or circuits. For example, the storage unit 1504 can store computer-executable instructions for methods of the radar or target device, so that the processing unit 1502 can execute the methods of the radar or target device described in the above embodiments. The storage unit 1504 can be a register, cache, or RAM, and can be integrated with the processing unit 1502. The storage unit 1504 can be a ROM or other type of static storage device capable of storing static information and instructions, and can be independent of the processing unit 1502.

[0242] Figure 16 This is a schematic diagram of the hardware structure of a control device provided in an embodiment of this application, such as... Figure 16 As shown, the control device includes a processor 1601, a communication line 1604, and at least one communication interface. Figure 16 (The example is illustrated using communication interface 1603).

[0243] 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 used to control the execution of programs according to the present application.

[0244] Communication line 1604 may include circuitry for transmitting information between the aforementioned components.

[0245] Communication interface 1603 uses any transceiver-like device for communicating with other devices or communication networks, such as Ethernet, wireless local area networks (WLAN), etc.

[0246] Possibly, the control device may also include a memory 1602.

[0247] The memory 1602 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory may exist independently and be connected to the processor via communication line 1604. The memory may also be integrated with the processor.

[0248] The memory 1602 stores computer execution instructions for implementing the scheme of this application, and the execution is controlled by the processor 1601. The processor 1601 executes the computer execution instructions stored in the memory 1602, thereby implementing the OTA-based communication method provided in the embodiments of this application.

[0249] It is possible that the computer execution instructions in the embodiments of this application may also be referred to as application code, and the embodiments of this application do not specifically limit this.

[0250] In a specific implementation, as one example, the processor 1601 may include one or more CPUs, for example... Figure 16 CPU0 and CPU1 in the CPU.

[0251] In a specific implementation, as one example, the control device may include multiple processors, for example... Figure 16 Processors 1601 and 1605 are mentioned. Each of these processors can be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. A processor here can refer to one or more devices, circuits, and / or processing cores used to process data (such as computer program instructions).

[0252] For example, Figure 17 This is a schematic diagram of a chip structure provided in an embodiment of this application. The chip 170 includes one or more processors 1720 and a communication interface 1730.

[0253] In some implementations, memory 1740 stores elements such as executable modules or data structures, or subsets thereof, or extended sets thereof.

[0254] In this embodiment, memory 1740 may include read-only memory and random access memory, and provides instructions and data to processor 1720. A portion of memory 1740 may also include non-volatile random access memory (NVRAM).

[0255] In this embodiment, the memory 1740, the communication interface 1730, and the memory 1740 are coupled together via a bus system 2020. The bus system 2020 may include a data bus, a power bus, a control bus, and a status signal bus, in addition to the data bus. For ease of description, in... Figure 17 The general will label all buses as Bus System 2020.

[0256] The methods described in the embodiments of this application can be applied to, or implemented by, processor 1720. Processor 1720 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above methods can be completed by integrated logic circuits in the hardware of processor 1720 or by instructions in software form. Processor 1720 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 devices, discrete gates, transistor logic devices, or discrete hardware components. Processor 1720 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention.

[0257] The steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules can be located in mature storage media in the art, such as random access memory, read-only memory, programmable read-only memory, or electrically erasable programmable read-only memory (EEPROM). This storage medium is located in memory 1740, and processor 1720 reads information from memory 1740 and, in conjunction with its hardware, completes the steps of the above method.

[0258] In the above embodiments, the instructions stored in the memory for execution by the processor can be implemented in the form of a computer program product. This computer program product can be pre-written into the memory, or it can be downloaded and installed into the memory as software.

[0259] A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is 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 one computer-readable storage medium to another. For example, computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or data center that integrates one or more available media. For example, available media may include magnetic media (e.g., floppy disks, hard disks, or magnetic tapes), optical media (e.g., digital versatile discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0260] This application also provides a computer-readable storage medium. The methods described in the above embodiments can be implemented, in whole or in part, 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 capable of transferring a computer program from one place to another. The storage medium can be any target medium accessible by a computer.

[0261] As one possible design, computer-readable media may include compact disc read-only memory (CD-ROM), RAM, ROM, EEPROM, or other optical disc storage; computer-readable media may also include disk storage or other disk storage devices. Furthermore, any connecting cable may also be appropriately referred to as computer-readable media. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of media. As used herein, disks and optical discs include optical discs (CD), laser discs, optical discs, digital versatile discs (DVD), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically, while optical discs optically reproduce data using lasers.

[0262] The above combinations should also be included within the scope of computer-readable media. The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A communication method based on Over-the-Air (OTA) download technology, characterized in that, include: The system obtains first information from the vehicle and second information from the cloud; the first information includes first software version information and a first identifier code; the second information includes a first mapping; the first mapping contains the association between the second software version information and the second identifier code; the identifier code is used to indicate the permission information of the software version. 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; The step of verifying the consistency 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: If the first software version information is inconsistent with the second software version information, and / or the first identification code is inconsistent with the second identification code, it is determined that the first software version information is inconsistent with the second software version information. Alternatively, if the first software version information is consistent with the second software version information, and the first identification code is consistent with the second identification code, then the first software version information is determined to be consistent with the second software version information. The method further includes: If the first software version information is inconsistent with the second software version information, update the first software version information and / or the first identification code; Alternatively, if the first software version information is consistent with the second software version information, update the first software version information and / or the first identification code.

2. The method according to claim 1, characterized in that, Before updating the first software version information and / or the first identifier, the method further includes: Send a first task to the first vehicle, the first task being used to instruct the updating of the first software version information and / or the first identification code; Wherein, if the first software version information and the second software version information are inconsistent, the first task includes the first mapping; or, If the first software version information is consistent with the second software version information, the first task includes a second mapping, and the second mapping contains the association between the third software version information and the third identifier code.

3. The method according to claim 1, characterized in that, The method further includes: Send a first software package to the first vehicle, the first software package being used to update the software version information corresponding to the first vehicle; Wherein, if the first software version information and the second software version information are inconsistent, the first software package includes the second identifier; or, If the first software version information is consistent with the second software version information, the first software package includes a third identifier code.

4. The method according to claim 1, characterized in that, The method further includes: If the first software version information is inconsistent with the second software version information, the first software version information, the first identification code, and / or alarm information are sent to the server and / or the display device of the first vehicle. The alarm information is used to indicate that the mapping relationship between the identification code and / or software version information of the first vehicle and the server is inconsistent.

5. The method according to claim 1, characterized in that, The updating of the first software version information and / or the first identifier code includes: Receive a first task from the server, the first task being used to instruct the update of the first software version information and / or the first identification code; Wherein, if the first software version information and the second software version information are inconsistent, the first task includes the first mapping; or, If the first software version information is consistent with the second software version information, the first task includes a second mapping; the second mapping includes the association between the third software version information and the third identifier code.

6. The method according to claim 5, characterized in that, The method further includes: Receive a first software package from the server; the first software package is used to update the software version information corresponding to the first vehicle. Wherein, if the first software version information and the second software version information are inconsistent, the first software package includes the second identifier; or, If the first software version information is consistent with the second software version information, the first software package includes the third identification code.

7. The method according to any one of claims 1-6, characterized in that, The identification code includes the first regulatory-related software identification code RXSWIN.

8. A communication device based on Over-the-Air (OTA) download technology, characterized in that, The device includes: A communication unit is used to obtain first information from the vehicle and second information from the cloud; the first information includes first software version information and a first identification code; the second information includes a first mapping; the first mapping contains the association between the second software version information and the second identification code; the identification code is used to indicate the permission information of the software version; The processing unit is configured to verify the consistency 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. The processing unit is specifically used for: If the first software version information is inconsistent with the second software version information, and / or the first identification code is inconsistent with the second identification code, it is determined that the first software version information is inconsistent with the second software version information. Alternatively, if the first software version information is consistent with the second software version information, and the first identification code is consistent with the second identification code, then the first software version information is determined to be consistent with the second software version information. The processing unit is further configured to: If the first software version information is inconsistent with the second software version information, update the first software version information and / or the first identification code; Alternatively, if the first software version information is consistent with the second software version information, update the first software version information and / or the first identification code.

9. The apparatus according to claim 8, characterized in that, The communication unit is specifically used for: Send a first task to the first vehicle; the first task is used to instruct the updating of the first software version information and / or the first identification code. Wherein, if the first software version information and the second software version information are inconsistent, the first task includes the first mapping; or, if the first software version information and the second software version information are consistent, the first task includes the second mapping; the second mapping includes the association between the third software version information and the third identifier code.

10. The apparatus according to claim 8, characterized in that, The communication unit is further used for: Send a first software package to the first vehicle; the first software package is used to update the software version information corresponding to the first vehicle. Wherein, if the first software version information is inconsistent with the second software version information, the first software package includes the second identification code; or, if the first software version information is consistent with the second software version information, the first software package includes the third identification code.

11. The apparatus according to claim 8, characterized in that, The communication unit is further used for: If the first software version information is inconsistent with the second software version information, the first software version information, the first identification code, and / or alarm information are sent to the server and / or the display device of the first vehicle; the alarm information is used to indicate that the mapping relationship between the identification code and / or software version information of the first vehicle and the server is inconsistent.

12. The apparatus according to claim 8, characterized in that, The communication unit is specifically used for: Receive a first task from the server, the first task being used to instruct the update of the first software version information and / or the first identification code; Wherein, if the first software version information and the second software version information are inconsistent, the first task includes the first mapping; or, if the first software version information and the second software version information are consistent, the first task includes the second mapping; the second mapping includes the association between the third software version information and the third identifier code.

13. The apparatus according to claim 12, characterized in that, The communication unit is further used for: Receive a first software package from the server; the first software package is used to update the software version information corresponding to the first vehicle. Wherein, if the first software version information is inconsistent with the second software version information, the first software package includes the second identification code; or, if the first software version information is consistent with the second software version information, the first software package includes the third identification code.

14. The apparatus according to any one of claims 8-13, characterized in that, The identification code includes the first regulatory-related software identification code RXSWIN.

15. An OTA-based communication device, characterized in that, include: At least one processor is configured to invoke a program in memory to perform the method according to any one of claims 1-7.

16. An OTA-based communication device, characterized in that, include: At least one processor and an interface circuit, the interface circuit being configured to provide information input and / or information output to the at least one processor, the at least one processor being configured to perform the method according to any one of claims 1-7.

17. A chip, characterized in that, Includes at least one processor and interface; The interface is used to provide program instructions or data to the at least one processor; The at least one processor is configured to execute the program line instructions to implement the method as described in any one of claims 1-7.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed, cause a computer to perform the method as described in any one of claims 1-7.

19. A computer program product, characterized in that, Includes a computer program that, when run, causes the computer to perform the method as described in any one of claims 1-7.

Images