A system, method, and computer program for managing vehicle software updates.

Abstract

To provide a system, method and apparatus for automatically managing software updates for a vehicle.SOLUTION: In an example embodiment, a system comprises a memory storage device storing computer-executable instructions and at least one processor communicatively coupled to the memory storage device, wherein the at least one processor is configured to receive software information from a neighboring vehicle, wherein the software information includes a version of software of the neighboring vehicle, and generate a software update based on a hash map indicating one or more differences between a current version of the software and the version of the software of the neighboring vehicle by: The software update is formed from a plurality of data chunks, and is configured to execute instructions for transmitting the software update to a neighboring vehicle by individually transmitting the plurality of data chunks to the neighboring vehicle.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] Systems, methods, and computer programs consistent with exemplary embodiments of the present disclosure relate to software updates, and more particularly, to the management of software updates for vehicles.

Background Art

[0002] Modern vehicles can perform a wide range of complex functions such as generating telemetry data and transmitting and receiving data via the Internet. To perform the above functions, the vehicle is essentially connected to an upstream server. In this regard, software updates are periodically sent to the vehicle and the updates are executed on the vehicle to maintain the latest information and ensure the execution of the above functions when connecting to the server.

[0003] In the prior art, for a vehicle to receive a software update, such a software update can be sent over-the-air (OTA) from a server as a single whole software update or as sequential software updates. Nevertheless, the above approach for managing software updates may have at least the following drawbacks.

[0004] Since the software update is sent as a single whole software update or as sequential software updates, if the vehicle cannot complete the update process for some reason (e.g., disconnected from the server), it may be necessary to restart the update process from the beginning where the software update has to be resent. Further, if the vehicle skips one or more versions of a software update, it may be necessary to execute the update process for all skipped versions of the software update regardless of the similarity between the skipped versions of the software update. As a result, the time required to perform the update process can increase.

Summary of the Invention

[0005] The exemplary embodiments of this disclosure automatically manage vehicle software updates. Thus, the exemplary embodiments of this disclosure enable software updates to be transmitted to and applied to the vehicle in a coordinated manner, while avoiding situations where the update process must be restarted from the beginning.

[0006] According to an exemplary embodiment, a system is provided. The system comprises a memory storage device for storing computer-executable instructions, and at least one processor communicatively coupled to the memory storage device, wherein the at least one processor is configured to execute instructions for receiving software information from a neighboring vehicle, the software information including the software version of the neighboring vehicle, and generating a software update based on a hash map showing one or more differences between the current version of the software and the software version of the neighboring vehicle, the software update being formed from a plurality of data chunks, and transmitting the software update to the neighboring vehicle by sending the plurality of data chunks individually to the neighboring vehicle.

[0007] According to an exemplary embodiment, at least one processor may be configured to execute instructions for generating a software update by determining one or more differences between the current version of the software and the software versions of neighboring vehicles, generating a hash map based on the one or more differences, retrieving data related to the one or more differences based on the hash map, and dividing the data into a plurality of data chunks to form a software update.

[0008] According to an exemplary embodiment, at least one processor may be configured to execute instructions for sending a software update by determining the priority of a plurality of data chunks and, based on the priority, sending the plurality of data chunks individually to neighboring vehicles.

[0009] According to an exemplary embodiment, the priority of multiple data chunks may be determined based on one or more of the following: the update applicability of each of the multiple data chunks, the size of each of the multiple data chunks, the safety impact of each of the multiple data chunks, and the applicability of ECU restart for each of the multiple data chunks.

[0010] According to an exemplary embodiment, one or more differences between the current version of the software and the software versions of neighboring vehicles may be determined based on a differential comparison algorithm.

[0011] According to an exemplary embodiment, the difference comparison algorithm may include the Levenshtein distance algorithm.

[0012] According to an exemplary embodiment, multiple data chunks may be transmitted individually via torrent.

[0013] According to an exemplary embodiment, the software of a neighboring vehicle may be divided into at least an application partition and a base partition, and the neighboring vehicle may be configured to update the software of the neighboring vehicle by applying multiple data chunks of software update to corresponding parts of the application partition and the base partition.

[0014] According to an exemplary embodiment, a method is provided. The method comprises a processor receiving software information from a neighboring vehicle, the software information including the software version of the neighboring vehicle; generating a software update based on a hash map showing one or more differences between the current version of the software and the software version of the neighboring vehicle, the software update being formed from a plurality of data chunks; and transmitting the software update to the neighboring vehicle by sending the plurality of data chunks individually to the neighboring vehicle.

[0015] According to an exemplary embodiment, generating a software update may involve determining one or more differences between the current version of the software and the software versions of neighboring vehicles, generating a hash map based on the one or more differences, retrieving data related to the one or more differences based on the hash map, and dividing the data into the plurality of data chunks to form a software update.

[0016] According to an exemplary embodiment, transmitting a software update may involve determining the priority of several data chunks and, based on the priority, transmitting the several data chunks individually to nearby vehicles.

[0017] According to an exemplary embodiment, the priority of multiple data chunks may be determined based on one or more of the following: the update applicability of each of the multiple data chunks, the size of each of the multiple data chunks, the safety impact of each of the multiple data chunks, and the applicability of ECU restart for each of the multiple data chunks.

[0018] According to an exemplary embodiment, one or more differences between the current version of the software and the software versions of neighboring vehicles may be determined based on a differential comparison algorithm.

[0019] According to an exemplary embodiment, the difference comparison algorithm may include the Levenshtein distance algorithm.

[0020] According to an exemplary embodiment, multiple data chunks may be transmitted individually via torrent.

[0021] According to an exemplary embodiment, the software of a neighboring vehicle may be divided into at least an application partition and a base partition, and the neighboring vehicle may be configured to update the software of the neighboring vehicle by applying multiple data chunks of software update to corresponding parts of the application partition and the base partition.

[0022] According to the embodiment, a computer program is provided. The computer program causes a processor to perform the following processes: receiving software information from a nearby vehicle, the software information including the software version of the nearby vehicle; generating a software update based on a hash map showing one or more differences between the current version of the software and the software version of the nearby vehicle, the software update being formed from a plurality of data chunks; and transmitting the software update to the nearby vehicle by individually transmitting the plurality of data chunks to the nearby vehicle.

[0023] According to an exemplary embodiment, generating a software update may include determining one or more differences between the current version of the software and the version of the software of neighboring vehicles, generating a hash map based on the one or more differences, obtaining data related to the one or more differences based on the hash map, and splitting the data into a plurality of data chunks to form the software update.

[0024] According to an exemplary embodiment, transmitting a software update may include determining the priorities of a plurality of data chunks and individually transmitting the plurality of data chunks to neighboring vehicles based on the priorities.

[0025] According to an exemplary embodiment, one or more differences between the current version of the software and the version of the software of neighboring vehicles may be determined based on a difference comparison algorithm.

[0026] Additional aspects are described in part in the following description, become apparent in part from the description, or may be realized by the implementation of the presented embodiments of the disclosure.

[0027] The features, advantages, and significance of exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings in which like reference numerals indicate like elements.

Brief Description of the Drawings

[0028] [Figure 1] FIG. 1 shows a block diagram of an exemplary system configuration for managing software updates of a vehicle according to one or more embodiments. [Figure 2] FIG. 2 shows a block diagram of exemplary components in a software update management (SUM) system according to one or more embodiments. [Figure 3] FIG. 3 shows a flowchart of an exemplary method for managing software updates of a vehicle according to one or more embodiments. [Figure 4]Figure 4 shows a flowchart of an exemplary method 400 for generating and sending software updates, according to one or more embodiments. [Modes for carrying out the invention]

[0029] A detailed description of the following exemplary embodiments is provided with reference to the accompanying drawings. Identical reference numerals in different drawings are used to identify identical or similar elements.

[0030] Such disclosures are illustrative and explanatory, but are not intended to be exhaustive or to limit implementations to the exact form disclosed. Modifications and variations may be possible in light of the above disclosures or may be obtained from the execution of the implementations. Furthermore, one or more features or components of one embodiment may be incorporated into another embodiment (or one or more features of another embodiment) or combined with another embodiment. In addition, it should be understood that in the flowcharts and operation descriptions provided below, one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least partially), and the order of one or more operations may be changed.

[0031] It will become apparent that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or combinations of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not a limitation of implementation. Therefore, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It should be understood that software and hardware may be designed to implement the systems and / or methods based on the descriptions herein.

[0032] Certain combinations of features are described in the claims and / or disclosed herein, but these combinations are not intended to limit the disclosure of possible implementations. In fact, many of these features can be combined in ways not specifically described in the claims and / or disclosed herein. Each of the dependent claims listed below can directly depend on only one claim, but the disclosure of possible embodiments includes each dependent claim combined with all other claims in the set of claims.

[0033] Any element, action, or command used herein should not be construed as important or essential unless expressly stated otherwise. Furthermore, where used herein, the articles “a” and “an” are intended to include one or more items and may be used interchangeably with “one or more.” When only one item is intended, the term “one” or similar language is used. Also, where used herein, terms such as “has,” “have,” “having,” “include,” and “including” are intended to be open-ended terms. Additionally, the phrase “based on” should mean “at least partially based on” unless otherwise specified. Furthermore, expressions such as “at least one of [A] and [B],” “[A] and / or [B],” or “at least one of [A] or [B]” should be understood as including only A, only B, or both A and B.

[0034] The features, advantages, and significance of the exemplary embodiments described above are only a part of this disclosure and are not intended to be exhaustive or to limit the technical scope of this disclosure.

[0035] Further descriptions of the features, components, configuration, operation, and implementations of the system of this disclosure, in one or more embodiments, are provided below. Examples of system architectures

[0036] Figure 1 shows a block diagram of an exemplary system configuration 100 for managing vehicle software updates according to one or more embodiments. As shown in Figure 1, the system configuration 100 may include a neighboring vehicle 110 and a Software Update Management (SUM) system 120.

[0037] The SUM system 120 may include devices, systems, platforms, modules, etc., which can be configured to perform one or more operations or actions for managing vehicle software updates. According to an exemplary embodiment, the SUM system 120 may be installed on any kind of object, unit, or device that contains the same software as the software installed on a neighboring vehicle 110. For example, the SUM system 120 may be installed on a vehicle (hereinafter referred to as the "current vehicle") that contains the same software as the software installed on a neighboring vehicle 110. In another example, the SUM system 120 may be installed on a beacon that contains the same software as the software installed on a neighboring vehicle 110. According to an exemplary embodiment, the SUM system 120 may be installed on multiple objects, units, and / or devices, and such multiple objects, units, and / or devices may be coupled together in a way that allows them to communicate with one another. For example, the SUM system 120 may be included in multiple vehicles and may be configured to communicate with one another.

[0038] Furthermore, according to exemplary embodiments, the SUM system 120 may include one or more components that enable the SUM system 120 to communicate with a nearby vehicle 110. For example, the SUM system 120 may include a digital communications module (DCM). The DCM may be an electronic control unit (ECU) including a cellular modem and may be configured to communicate with the nearby vehicle 110 via shortwave radio, direct communication between DCMs, Bluetooth®, etc. According to exemplary embodiments, all transmissions between the SUM system 120 and the nearby vehicle 110 can be encrypted.

[0039] Exemplary operations that can be performed by the SUM system 120 for managing vehicle software updates are described below with reference to Figures 3 and 4. Furthermore, several exemplary components that may be included in the SUM system 120 in one or more embodiments are described below with reference to Figure 2.

[0040] A neighboring vehicle 110 is traveling near the SUM system 120 and can include any type of vehicle that has the same software installed on the SUM system 120. For example, a neighboring vehicle 110 can include a vehicle traveling in the same direction and within the communication range of the SUM system 120 installed on the current vehicle, in which case both vehicles have the same software installed.

[0041] According to an exemplary embodiment, the software installed on the neighboring vehicle 110 may be a different version from the software installed on the SUM system 120. For example, the current vehicle and the SUM system 120 may have received the latest software updates from the server, but the neighboring vehicle 110 may not have received the latest software updates yet. Therefore, the version of the software installed on the SUM system 120 may be the latest version, while the version of the software installed on the neighboring vehicle 110 may be an older version. According to an exemplary embodiment, the software installed on the neighboring vehicle 110 may be the same version as the software installed on the SUM system 120.

[0042] According to an exemplary embodiment, the neighboring vehicle 110 may also include the SUM system 120. According to an exemplary embodiment, the neighboring vehicle 110 does not have to include the SUM system 120, but may still be able to communicate with the SUM system 120.

[0043] Figure 2 shows a block diagram of exemplary components within the SUM system 200 according to one or more embodiments. The SUM system 200 can correspond to the SUM system 120 of Figure 1, and therefore, features related to the SUM system 120 and the SUM system 200 may be similarly applicable to each other unless explicitly stated otherwise.

[0044] As shown in Figure 2, the SUM system 200 may include at least one communication interface 210, at least one processor 220, at least one input / output component 230, and at least one storage device 240, but it should be understood that the SUM system 200 may include more or fewer components than those shown in Figure 2, and / or may be configured in a manner different from that shown in Figure 2 without departing from the technical scope of this disclosure.

[0045] The communication interface 210 may include at least one transceiver-like component (e.g., transceivers, separate receivers and transmitters, buses, etc.) that enables the components of the SUM system 200 to communicate with each other and / or with one or more components outside the SUM system 200, for example, via wired connections, wireless connections, or a combination of wired and wireless connections. For example, the communication interface 210 may include Ethernet® interfaces, optical interfaces, coaxial interfaces, infrared interfaces, radio frequency (RF) interfaces, Universal Serial Bus (USB) interfaces, Wi-Fi® interfaces, cellular network interfaces, etc.

[0046] For example, the communication interface 210 may connect the processor 220 to the storage device 240, thereby enabling them to communicate and interact with each other when performing one or more operations. In another example, the communication interface 210 may connect the SUM system 200 (or one or more components contained therein) to a neighboring vehicle 110, enabling them to communicate and interact with each other.

[0047] According to one or more embodiments, the communication interface 210 may include one or more application programming interfaces (APIs) that enable the SUM system 200 (or one or more components contained therein) to communicate with one or more software applications (for example, software applications deployed in a nearby vehicle 110).

[0048] The input / output component 230 may include at least one component that enables the SUM system 200 to receive information and / or provide output information. In some embodiments, the input / output component 230 may include at least one input component (e.g., a touchscreen display, keyboard, keypad, mouse, button, switch, microphone, etc.) and at least one output component (e.g., a display, speaker, one or more light-emitting diodes (LEDs), etc.), each of which may be isolated from one another. In addition, or alternatively, at least one input component may include a sensor for sensing information (e.g., a Global Positioning System (GPS®) component, accelerometer, gyroscope, and / or actuator).

[0049] The storage device 240 may include one or more storage media suitable for storing data, information, and / or computer executable instructions. According to an exemplary embodiment, the storage device 240 may include at least one memory storage device, such as random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory), for storing information and / or instructions used by the processor 220. In addition or alternatively, the storage device 240 may include, together with a corresponding drive, a hard disk (e.g., magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), a compact disk (CD®), a digital versatile disk (DVD®), a floppy disk, a cartridge, magnetic tape, and / or another type of non-temporary computer-readable media. Computer-readable media are defined herein as non-temporary storage devices. A memory device includes a memory space in a single physical storage device or a memory space distributed across multiple physical storage devices.

[0050] According to exemplary embodiments, the storage device 240 may be configured to store information such as raw data and metadata. Additionally or alternatively, the storage device 240 may be configured to store one or more pieces of information relating to one or more operations performed by the processor 220. For example, the storage device 240 may store information defining historical operations performed by the processor 220 to manage vehicle software updates, the results of one or more operations performed by the processor 220, etc. Furthermore, the storage device 240 may store data or information required when managing vehicle software updates.

[0051] In one embodiment, the storage device 240 may include multiple storage media, and the storage device 240 may be configured to store copies or duplicates of at least some of the information in the multiple storage media, providing redundancy and backing up information or related data. Furthermore, the storage device 240 may store computer-readable or computer-executable instructions that, when executed by one or more processors (e.g., processor 220), cause one or more processors to perform one or more actions / operations described herein.

[0052] The processor 220 may include at least one processor that can be programmed or configured to perform functions or operations described herein. For example, the processor 220 may be configured to execute computer executable instructions stored in at least one storage medium or memory storage device (e.g., storage device 240) to perform one or more actions or operations described herein.

[0053] According to exemplary embodiments, the processor 220 may be configured to receive one or more signals and / or one or more user inputs (for example, via a communication interface 210, via an input / output component 230, etc.) that define one or more instructions for performing one or more operations. Furthermore, the processor 220 may be implemented in hardware, firmware, or a combination of hardware and software. For example, the processor 220 may include at least one of a central processing unit (CPU), graphics processing unit (GPU), acceleration unit (APU), microprocessor, microcontroller, digital signal processor (DSP), field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), and / or another type of processing or computing component.

[0054] According to an exemplary embodiment, the processor 220 may be configured to collect, extract, and / or receive one or more pieces of information (in the form of signals or data, for example) from a neighboring vehicle 110, process the received pieces of information, and thereby manage software updates for the vehicle.

[0055] The number and arrangement of components shown in Figure 2 are provided as an example. In practice, the SUM system 200 may include additional components, fewer components, different components, or components arranged differently from those shown in Figure 2. In addition, or alternatively, a set of components of the SUM system 200 (for example, one or more components) may perform one or more functions that are described as being performed by another set of components of the SUM system 200.

[0056] A description of some exemplary operations that can be performed by the processor 220 is provided below with reference to Figures 3 and 4. Exemplary Operation for Managing Vehicle Software Updates in This Disclosure

[0057] The following describes some exemplary operations that can be performed by the SUM system of this disclosure, with reference to Figures 3 and 4.

[0058] Figure 3 shows a flowchart of an exemplary method 300 for managing vehicle software updates according to one or more embodiments. One or more operations in method 300 may be performed by at least one processor of the SUM system (for example, processor 220).

[0059] As shown in Figure 3, in operation S310, at least one processor may be configured to detect a nearby vehicle. A nearby vehicle is traveling near the SUM system and may include any type of vehicle that has the same software installed on the SUM system.

[0060] According to an exemplary embodiment, at least one processor may be configured to detect nearby vehicles by broadcasting a discovery transmission. The discovery transmission may be discovered and received by a vehicle traveling within the communication range of the SUM system. In this regard, if a nearby vehicle receives a discovery transmission, the nearby vehicle may be configured to reply to the SUM system with a discovery transmission. Thus, at least one processor may be configured to detect nearby vehicles by further receiving discovery transmissions from nearby vehicles.

[0061] According to an exemplary embodiment, when a nearby vehicle is detected, at least one processor may be configured to perform authentication with the nearby vehicle. Authentication may be performed to verify that the SUM system and the nearby vehicle trust each other. According to the embodiment, authentication may be performed via public-key cryptography (e.g., signature for authentication). Next, the method proceeds to operation S320.

[0062] In operation S320, at least one processor may be configured to send a software update notification. The software update notification may be sent to a nearby vehicle and may include information about the SUM system software (i.e., the software installed in the current vehicle on which the SUM system is installed) that is available to update the software of the nearby vehicle. According to one embodiment, the software update notification may include the version of the SUM system software. According to another embodiment, the software update notification may further include a message indicating that the SUM system has a software update available.

[0063] According to an exemplary embodiment, when a nearby vehicle receives a software update notification, the nearby vehicle may be configured to determine, based on the software update notification, whether an update is needed for the nearby vehicle's software. According to an exemplary embodiment, the nearby vehicle may be configured to determine whether an update is needed by determining whether the version of the nearby vehicle's software is older than the version of the SUM system software indicated in the software update notification.

[0064] Therefore, based on the determination that the software version of a nearby vehicle is older than the software version of the SUM system, the nearby vehicle can determine that an update is needed and then send software information to the SUM system. The software information may include information about the software of the nearby vehicle, such as the software version of the nearby vehicle.

[0065] On the other hand, a nearby vehicle may determine that it does not need an update based on the determination that its software version is not older than the SUM system's software version (e.g., the same version). In this regard, the nearby vehicle may send a notification to the SUM system indicating that its software version is the same as the SUM system's software version and therefore does not need an update. Alternatively, the nearby vehicle may simply ignore the software update notification without sending any notification back to the SUM system.

[0066] According to an exemplary embodiment, at least one processor may be configured to send a software update notification in response to the detection of a nearby vehicle. According to an exemplary embodiment, at least one processor may be configured to send a software update notification in response to the reception of an update request from a nearby vehicle. In particular, when a nearby vehicle and the SUM system detect each other, the nearby vehicle can decide whether to send an update request. The update request may include a request to receive software update information. According to an exemplary embodiment, the nearby vehicle may decide whether to send an update request based on one or more trigger conditions. One or more trigger conditions may include, for example, one or more of the time since the nearby vehicle last received an update, daylight saving time, geographical location, and fuel level status. Thus, in response to deciding to send an update request, the nearby vehicle may be configured to send the update request to the SUM system. According to an exemplary embodiment, at least one processor may be configured to send a software update notification in response to the detection of a nearby vehicle, even if no update request has been received from the nearby vehicle. The method then proceeds to operation S330.

[0067] In operation S330, at least one processor may be configured to receive software information. As described above, the software information may be received from a neighboring vehicle in response to the neighboring vehicle determining that an update is needed, and may include information about the neighboring vehicle's software, such as the software version of the neighboring vehicle. The method then proceeds to operation S340.

[0068] In operation S340, at least one processor may be configured to generate a software update. According to an exemplary embodiment, the software update may be generated based on a hash map showing one or more differences between the software version of the SUM system (i.e., the current version of the software) and the software versions of neighboring vehicles indicated in the software information. Furthermore, according to an exemplary embodiment, the software update may include only update data related to one or more differences and may be formed from multiple data chunks. The method then proceeds to operation S350.

[0069] In operation S350, at least one processor may be configured to send a software update. The software update may be sent to a neighboring vehicle to perform a software update on the neighboring vehicle. According to an exemplary embodiment, the software update may be sent by individually sending a plurality of data chunks (forming the software update) to the neighboring vehicle.

[0070] Additional descriptions and examples of the operations for generating and sending software updates are provided below with reference to Figure 4.

[0071] When a software update is sent to nearby vehicles, those vehicles may be configured to apply the software update and update their own software.

[0072] When operation S350 is performed, method 300 may be ended or terminated. Alternatively, method 300 may return to operation S310 so that at least one processor is configured to repeatedly detect nearby vehicles (operation S310), send software update notifications (operation S320), receive software information (operation S330), generate software updates (operation S340), and transmit software updates (operation S350) for at least a predetermined time. For example, at least one processor may continuously (or periodically) detect more nearby vehicles, then resume detecting nearby vehicles (operation S310), send software update notifications (operation S320), receive software information (operation S330), generate software updates (operation S340), and transmit software updates (operation S350). Exemplary operation for generating and sending software updates in this disclosure

[0073] Figure 4 shows a flowchart of an exemplary method 400 for generating and transmitting software updates according to one or more embodiments. One or more operations of method 400 may be part of operations S340 and S350 of method 300 and may be performed by at least one processor of the SUM system (e.g., processor 220).

[0074] As shown in Figure 4, in operation S410, at least one processor may be configured to determine one or more differences between the current version of the software (i.e., the software version of the SUM system) and the software versions of neighboring vehicles.

[0075] According to an exemplary embodiment, one or more differences may be any form of difference between the current version of the software and the software version of a neighboring vehicle. Here, it may be assumed that the software version of the neighboring vehicle is older than the current version of the software and has at least one difference. According to an exemplary embodiment, one or more differences may represent one or more differences between one or more sections of code representing the current version of the software and one or more sections of code representing the software version of the neighboring vehicle.

[0076] Furthermore, one or more differences may indicate one or more sections of code representing the software version of a neighboring vehicle that are different from the code representing the current version of the software, and as a result, one or more sections of code representing the software version of a neighboring vehicle will require some additions, deletions, and / or modifications to convert the code representing the software version of a neighboring vehicle to the code representing the current version of the software.

[0077] According to an exemplary embodiment, one or more differences between the current version of the software and the software versions of neighboring vehicles can be determined based on a difference comparison algorithm. The difference comparison algorithm may include, for example, the Levenshtein distance algorithm. The method then proceeds to operation S420.

[0078] In operation S420, at least one processor may be configured to generate a hash map. The hash map may be generated based on one or more differences and may include a mapping between one or more sections of code representing the current version of the software and one or more corresponding sections of code representing different versions of the software in neighboring vehicles.

[0079] For example, if a section in the code representing the software version of a neighboring vehicle relates to a software interface function, and this section in the code representing the current version of the software relates to a software interface function, the hash map may include a mapping between these sections. The method then proceeds to operation S430.

[0080] In operation S430, at least one processor may be configured to retrieve data related to one or more differences based on a hash map. The data can be retrieved from the current version of the software. For example, at least one processor may be configured to retrieve data related to the software interface functionality from code representing the current version of the software, based on a hash map.

[0081] An example is provided here. Between the software version of a neighboring vehicle and the current version of the software, the software developer may have modified the code / data for the software interface function. Therefore, in operation S410, it may be determined that the section associated with the software interface function in the code representing the neighboring vehicle's software version is different from the section associated with the software interface function in the code representing the current version of the software, and such section associated with the software interface function in the code representing the neighboring vehicle's software version requires modification to convert the code representing the neighboring vehicle's software version to the code representing the current version of the software. Next, in operation S420, a hash map can be generated that maps the above sections together. Subsequently, in operation S430, data related to the software interface function may be retrieved from the current version of the software based on the hash map, and as a result, the data may be sent to the neighboring vehicle (see below) to convert the code representing the neighboring vehicle's software version to the code representing the current version of the software, and the section associated with the software interface function in the code representing the neighboring vehicle's software version may be modified.

[0082] Therefore, it is possible to generate software updates that are tailored to nearby vehicles, and the software updates can include only update data associated with one or more differences. Thus, even if nearby vehicles skip one or more versions of the software update, it is not necessary to perform the update process for all skipped versions of the software update, and the update process can be performed in relation to only one or more differences. The method then proceeds to operation S440.

[0083] In operation S440, at least one processor may be configured to divide data into multiple data chunks to form a software update. The data may be divided into multiple data chunks in a manner known in the prior art. Next, the method proceeds to operation S450.

[0084] In operation S450, at least one processor may be configured to determine the priority of multiple data chunks. The priority may be determined based on one or more of the following: the update applicability of each of the multiple data chunks, the size of each of the multiple data chunks, the safety impact of each of the multiple data chunks, and the ECU restart applicability of each of the multiple data chunks. For example, if data is divided into three data chunks, and one data chunk must be applied alone to provide updates to sections related to interface functions, and the remaining two data chunks must be applied together to provide updates to sections related to infotainment functions, then the one data chunk (applied to provide updates to sections related to interface functions) may be determined to have the highest priority, followed by the remaining two data chunks (applied to provide updates to sections related to infotainment functions). The method then proceeds to operation S460.

[0085] In operation S460, at least one processor may be configured to send multiple data chunks individually to neighboring vehicles based on priority. Sending multiple data chunks individually based on priority may include sending each of the multiple data chunks one by one based on priority. For example, the data chunk with the highest priority is sent first, followed by the data chunk with the second highest priority, and so on. According to an exemplary embodiment, the multiple data chunks may be sent individually via torrent.

[0086] Therefore, since software updates can be sent to nearby vehicles in the form of data chunks that are individually applied for the update process (see below), if a nearby vehicle is unable to complete the update process for any reason, the update process may not need to be restarted from the beginning, but simply need to be restarted from the data chunks that were applied / sent when the update process was interrupted.

[0087] Considering the above, software updates only need to include update data related to one or more differences, and the update process can be resumed from the data chunks that were being applied / sent when the update process was interrupted, thus minimizing the amount of data that needs to be sent for the update process. Also, for the same reasons, by not having to read or write data that is not necessary for the update process, the lifespan of the memory disk can be maximized, and the overall use of computing resources for the update process can be reduced.

[0088] When a software update is sent to nearby vehicles, those vehicles may be configured to apply the software update and update their own software.

[0089] According to an exemplary embodiment, software may be divided into at least an application partition and a base partition. The application partition and base partition may be physical or logical partitions. For example, the application partition and base partition may be logical partitions enforced by the configuration of the operating system itself, thereby allowing software that does not conform to or is unaware of the partition mechanism to continue to perform updates.

[0090] The base partition may contain non-malformable data and / or data that is unlikely to change or evolve over time. According to an exemplary embodiment, the base partition may include data related to mathematical libraries, localization support, help files, common operating system components, safety calibration data that is unlikely to be tied to vehicle hardware, and data related to safety-critical elements. In other words, the base partition may include all data that does not require updating or is unlikely to require periodic updating. According to an exemplary embodiment, the data in the base partition may be centrally located within the vehicle hardware and may operate in secure boot mode.

[0091] An application partition may include malleable data and / or data that is likely to change or evolve over time. According to an exemplary embodiment, an application partition may include data related to infotainment applications, non-safety-related functions, etc. According to an exemplary embodiment, an application partition may include multiple subpartitions, each of which may include data related to one or more of the applications and functions of the application partition. According to an exemplary embodiment, an application partition may operate in a distributed manner across different parts of a neighboring vehicle.

[0092] According to an exemplary embodiment, the application partition and the base partition may be partitioned based on an update record. The update record may include information about past update processes for vehicles with similar models to neighboring vehicles and may indicate the frequency of changes to all data of the software during past update processes.

[0093] In particular, a software image is generated with each update process, and after past updates, the software images are compared to each other to determine which software data has been frequently modified during past updates and which data has not been modified very often (or has not been modified at all). Files associated with the image are hashed and a timestamp is recorded. Therefore, software data that has been frequently modified throughout past updates may be determined as the application partition, while software data that has not been modified very often (or has not been modified at all) throughout past updates may be determined as the base partition.

[0094] According to an exemplary embodiment, the application partition and the base partition may be divided based on safety criticality. Safety criticality can indicate which data in the software is critically safe and which data in the software is not critically safe. Thus, data in the software that is critically safe may be determined as the base partition, while data in the software that is not critically safe may be determined as the application partition.

[0095] According to exemplary embodiments, the application partition and the base partition may be partitioned based on a combination of update records and safety criticality.

[0096] According to an exemplary embodiment, user-associated data (e.g., driver) may always be determined to change frequently, so that user-associated data is always part of the application partition. According to an exemplary embodiment, user-associated data may be determined to reside in a user partition separate from the application partition and base partition. The user partition may be a logical partition or a logical and physical partition (i.e., logically and physically separated from the application partition and base partition) to allow for ease of erasure and to satisfy privacy-related requirements. According to an exemplary embodiment, user-associated data in the user partition may include user profile data, application logs, and data collected by the vehicle itself (e.g., sensor data before and after ADAS departure collected for further analysis and continuous improvement).

[0097] According to an exemplary embodiment, data in the base partition and data in the application partition can interact with each other. For example, data in the application partition may derive functionality from data in the base partition. In such cases, making the base partition and application partition logical partitions can prevent potential interoperability issues. Furthermore, according to an exemplary embodiment, dependencies between the base partition and the application partition can be represented in metadata in a continuous integration and continuous delivery / deployment (CI / CD) system, tested and enforced during installation and startup. The dependencies may also be part of a Software Bill of Materials (SBOM), which is a unique structured list of software and materials for each vehicle.

[0098] According to an exemplary embodiment, the software may be further divided into a companion data partition. The companion data partition may be a physical or logical partition. The companion data partition may be associated with the application partition and the base partition, and may contain configuration-related data, calibration-related data, non-user-related data for other vehicles, etc. Data in the companion data partition may be read by code in the associated partition, in which case the code must be designed to update the data without adding any safety risks.

[0099] In view of the above, neighboring vehicles may be configured to update the software of neighboring vehicles by applying multiple data chunks of the software update to corresponding parts of the application partition and the base partition.

[0100] In particular, multiple data chunks can apply to data in one or both of the application partition and the base partition. For example, one or more of the multiple data chunks may correspond to data related to interface functionality (i.e., non-security related data), and therefore, one or more of the above-mentioned multiple data chunks may apply to data in the partition related to interface functionality within the application partition.

[0101] According to an exemplary embodiment, multiple data chunks of a software update may be applied to corresponding portions of an application partition based on their impact on the user and / or computational requirements. For example, if multiple data chunks correspond to data related to features that the user is not currently using, the multiple data chunks of the software update may be applied immediately. On the other hand, if multiple data chunks correspond to data related to features that the user is currently using, the multiple data chunks of the software update may be applied later, when the user is not using such features.

[0102] According to an exemplary embodiment, multiple data chunks of a software update may be applied to corresponding portions of the base partition based on user safety.

[0103] Therefore, by not only dividing software updates into multiple data chunks, but also by splitting the software between the base partition and the application partition, updates can be applied individually to each partition, just as they are within the application partition, rather than being applied to the entire software at once.

[0104] According to an exemplary embodiment, the software update may further include a cryptographic signature, which may be used by a nearby vehicle for authentication and protection against tampering when the software update is received. Various embodiments

[0105] The foregoing disclosures are illustrative and explanatory, but are not intended to be exhaustive or to limit implementations to the exact forms disclosed. Modifications and variations may be possible in light of the foregoing disclosures or may be derived from the execution of the implementations.

[0106] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of technical detail of integration. Furthermore, one or more of the above-described components may be implemented as instructions stored in a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-temporary storage medium having computer-readable program instructions for causing a processor to perform an action.

[0107] A computer-readable storage medium can be a tangible device capable of holding and storing instructions used by an instruction execution device. A computer-readable storage medium may be, but is not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. A non-exclusive list of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or Flash memory), static random access memory (SRAM), portable compact disk® read-only memory (CD-ROM), digital general-purpose disk (DVD®), memory stick®, floppy disk, mechanically encoded devices such as punch cards or three-dimensional structures in grooves having instructions recorded thereon, and any suitable combination thereof. Computer-readable storage media, as used herein, should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through fiber optic cables), or electrical signals transmitted through wires.

[0108] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing unit, or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing / processing unit receives computer-readable program instructions from the network and transfers them to be stored in a computer-readable storage medium within each computing / processing unit.

[0109] The computer-readable program code / instructions for performing an operation may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk® and C++®, and procedural programming languages ​​such as the C programming language or similar programming languages. The computer-readable program instructions can run as a standalone software package entirely on the user's computer, partially on the user's computer, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or wide area network (WAN), or the connection may be to an external computer (for example, via the Internet using an Internet Service Provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer-readable program instructions by utilizing state information of computer-readable program instructions to personalize the electronic circuit in order to perform an action or operation.

[0110] These computer-readable program instructions are provided to the processor of a general-purpose computer, a dedicated computer, or other programmable data processing device so that instructions executed via the processor of the computer or other programmable data processing device can generate a machine that creates means for implementing functions / operations specified in blocks or blocks of a flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that can instruct computers, programmable data processing devices, and / or other devices to function in a particular way, and as a result, a computer-readable storage medium having instructions stored therein includes a product containing instructions that implements modes of functions / operations specified in blocks or blocks of a flowchart and / or block diagram.

[0111] Computer-readable program instructions can also be loaded onto a computer, other programmable data processing device, or other device to cause a set of operational steps executed on the computer, other programmable device, or other device to generate a computer implementation process executed on the computer, other programmable device, or other device, so that instructions executed on the computer, other programmable data processing device, or other device implement a function / operation specified in a flowchart and / or block diagram block or block.

[0112] The flowcharts and block diagrams in the figures illustrate the architecture, functions, and operation of various possible implementations of systems, methods, and computer-readable media. In this regard, each block in a flowchart or block diagram may represent a microservice module, segment, or part of an instruction that comprises one or more executable instructions for implementing a particular logical function. Methods, computer systems, and computer-readable media may include additional blocks, fewer blocks, different blocks, or blocks arranged differently from those shown in the diagram. In some alternative implementations, the functions shown within a block may occur out of the order shown in the diagram. For example, two consecutively shown blocks may actually be executed simultaneously or substantially simultaneously, or blocks may be executed in reverse order depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, as well as combinations of blocks in a block diagram and / or flowchart, may be implemented by a dedicated hardware-based system that performs a particular function or action, or a combination of dedicated hardware and computer instructions.

[0113] It will be apparent that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or combinations of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not a limitation of implementation. Therefore, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it is understood that software and hardware may be designed to implement the systems and / or methods based on the descriptions herein.

[0114] In light of the above teachings, it can be seen that numerous modifications and variations of this disclosure are possible. Within the technical scope of the appendix, it will be apparent that this disclosure may be implemented in ways other than those specifically described herein.

Claims

1. A memory device that stores computer-executable instructions, At least one processor is communicatively coupled to the memory storage device, Equipped with, The aforementioned at least one processor is Receiving software information from a nearby vehicle, wherein the software information includes the software version of the nearby vehicle. To determine one or more differences between the current version of the software and the version of the software in the neighboring vehicle, Generating a hash map based on one or more of the differences, wherein the hash map includes a mapping between one or more sections of code representing the current version of the software and one or more corresponding sections of code representing the software versions of the neighboring vehicles. Obtaining data related to one or more differences based on the hash map, The process involves dividing the data related to the one or more differences into multiple data chunks to generate a software update, The software update is transmitted to the nearby vehicles by individually transmitting the plurality of data chunks to the nearby vehicles. A system configured to execute instructions for a purpose.

2. The aforementioned at least one processor is Determining the priority of the aforementioned multiple data chunks, Based on the aforementioned priority, the plurality of data chunks are transmitted individually to the neighboring vehicles, The system according to claim 1, configured to execute a command for transmitting the software update.

3. The system according to claim 2, wherein the priority of the plurality of data chunks is determined based on one or more of the following: the update applicability of each of the plurality of data chunks, the size of each of the plurality of data chunks, the impact on safety of each of the plurality of data chunks, and the applicability of ECU restart for each of the plurality of data chunks.

4. The system according to claim 1, wherein the one or more differences between the current version of the software and the version of the software in the neighboring vehicle are determined based on a differential comparison algorithm.

5. The system according to claim 4, wherein the difference comparison algorithm includes the Levenshtein distance algorithm.

6. The system according to claim 1, wherein the plurality of data chunks are transmitted individually via torrents.

7. The system according to any one of claims 1 to 6, wherein the software of the neighboring vehicle is divided into at least an application partition and a base partition, and the neighboring vehicle is configured to update the software of the neighboring vehicle by applying the plurality of data chunks of the software update to corresponding portions of the application partition and corresponding portions of the base partition.

8. The processor, Receiving software information from a nearby vehicle, wherein the software information includes the software version of the nearby vehicle. To determine one or more differences between the current version of the software and the version of the software in the neighboring vehicle, Generating a hash map based on one or more of the differences, wherein the hash map includes a mapping between one or more sections of code representing the current version of the software and one or more corresponding sections of code representing the software versions of the neighboring vehicles. Obtaining data related to one or more differences based on the hash map, The process involves dividing the data related to the one or more differences into multiple data chunks to generate a software update, The software update is transmitted to the nearby vehicles by individually transmitting the plurality of data chunks to the nearby vehicles. A method that involves performing an action.

9. Sending the aforementioned software update means Determining the priority of the aforementioned multiple data chunks, Based on the aforementioned priority, the plurality of data chunks are transmitted individually to the neighboring vehicles, The method according to claim 8, wherein the method is characterized by having the following:

10. The method according to claim 9, wherein the priority of the plurality of data chunks is determined based on one or more of the following: the update applicability of each of the plurality of data chunks, the size of each of the plurality of data chunks, the safety impact of each of the plurality of data chunks, and the applicability of ECU restart for each of the plurality of data chunks.

11. The method according to claim 8, wherein the one or more differences between the current version of the software and the version of the software in the neighboring vehicle are determined based on a differential comparison algorithm.

12. The method according to claim 11, wherein the difference comparison algorithm includes the Levenshtein distance algorithm.

13. The method according to claim 8, wherein the plurality of data chunks are transmitted individually via torrent.

14. The method according to any one of claims 8 to 13, wherein the software of the neighboring vehicle is divided into at least an application partition and a base partition, and the neighboring vehicle is configured to update the software of the neighboring vehicle by applying the plurality of data chunks of the software update to corresponding portions of the application partition and corresponding portions of the base partition.

15. Receiving software information from a nearby vehicle, wherein the software information includes the software version of the nearby vehicle. To determine one or more differences between the current version of the software and the version of the software in the neighboring vehicle, Generating a hash map based on one or more of the differences, wherein the hash map includes a mapping between one or more sections of code representing the current version of the software and one or more corresponding sections of code representing the software versions of the neighboring vehicles. Obtaining data related to one or more differences based on the hash map, The process involves dividing the data related to the one or more differences into multiple data chunks to generate a software update, The software update is transmitted to the nearby vehicles by individually transmitting the plurality of data chunks to the nearby vehicles. A computer program that causes a processor to perform a process that has the following characteristics.

16. Sending the aforementioned software update means Determining the priority of the aforementioned multiple data chunks, Based on the aforementioned priority, the plurality of data chunks are transmitted individually to the neighboring vehicles, A computer program according to claim 15, having the following:

17. The computer program according to claim 15 or 16, wherein the one or more differences between the current version of the software and the version of the software in the neighboring vehicle are determined based on a differential comparison algorithm.

Images