System and method for facilitating differential software updates to automotive operating systems

Abstract

To facilitate differential software updates for automotive operating systems (OS). [Solution] The update method includes communicating information associated with a software update to the vehicle system's OS with an external source of the vehicle system, obtaining a portion of the software update from the source, and applying the obtained portion of the software update to a partition of the OS, wherein the partition of the OS comprises at least one of a first partition managing a first type of data and a second partition managing a second type of data, the first type of data comprising at least one of non-adaptive data, data that is not frequently changed, and safety-critical data, and the second type of data comprising at least one of adaptable data, data that is frequently changed, and non-safety-critical data, and the first partition and the second partition are logical partitions implemented by the OS configuration.

Description

Technical Field

[0001] Exemplary embodiments of the present disclosure relate to software updates in a vehicle system, and more particularly, to facilitating differential software updates in an operating system (OS) of a vehicle system.

Background Art

[0002] Recent vehicles rely heavily on software for operations such as vehicle performance management, safety system control, navigation, infotainment, and the like. Software updates in a vehicle system involve installing new or modified software in the vehicle's operating system (OS) to improve functionality, correct system bugs, enhance security, and / or add new features. Such software updates can be delivered during vehicle maintenance at a service center or wirelessly (OTA) via a wireless (e.g., cellular) connection.

Summary of the Invention

[0003] Exemplary embodiments consistent with the present disclosure effectively and efficiently facilitate differential software updates to an operating system (OS) of an automobile.

[0004] According to an exemplary embodiment, a method that a processor can perform to update software in a vehicle system may include: communicating information associated with a software update to the vehicle system's OS with an external source of the vehicle system; obtaining a portion of the software update from the source; and applying the obtained portion of the software update to a partition of the OS. The partition of the OS may include at least one of a first partition managing a first type of data and a second partition managing a second type of data. The first type of data may include at least one of non-adaptive data, data that does not change frequently, and safety-critical data. The second type of data may include at least one of adaptable data, data that changes frequently, and non-safety-critical data. The first and second partitions may be logical partitions implemented by the configuration of the OS.

[0005] According to an exemplary embodiment, a device for updating software in a vehicle system may include memory storage and a processor. The memory storage may store computer executable instructions, and the processor may be communicatively connected to the memory storage and configured to execute instructions, communicate information associated with a software update to the vehicle system's OS with an external source, retrieve a portion of the software update from the source, and apply the retrieved portion of the software update to a partition of the OS. The partition of the OS may include at least one of a first partition managing a first type of data and a second partition managing a second type of data. The first type of data may include at least one of non-adaptive data, data that does not change frequently, and safety-critical data. The second type of data may include at least one of adaptable data, data that changes frequently, and non-safety-critical data. The first and second partitions may be logical partitions implemented by the configuration of the OS.

[0006] According to an exemplary embodiment, a non-temporary computer-readable recording medium may record processor-executable instructions to cause the processor to perform a method for updating software in a vehicle system. The method may include communicating information associated with a software update to the vehicle system's OS with an external source of the vehicle system, obtaining a portion of the software update from the source, and applying the obtained portion of the software update to a partition of the OS. The partition of the OS may include at least one of a first partition managing a first type of data and a second partition managing a second type of data. The first type of data may include at least one of non-adaptive data, data that does not change frequently, and safety-critical data. The second type of data may include at least one of adaptable data, data that changes frequently, and non-safety-critical data. The first and second partitions may be logical partitions implemented by the configuration of the OS.

[0007] Further embodiments may be described in part in the following description, partially as will become apparent from the description, or may be realized by implementing the embodiments presented in this disclosure. [Brief explanation of the drawing]

[0008] The features, advantages, and importance of preferred embodiments of the present disclosure are described below with reference to the accompanying drawings, in which similar reference numerals indicate similar elements.

[0009] [Figure 1] Figure 1 shows a block diagram of an exemplary system configuration according to one or more exemplary embodiments. [Figure 2A] Figure 2A shows a block diagram of exemplary operation according to one or more exemplary embodiments. [Figure 2B] Figure 2B shows a block diagram of an exemplary operation according to one or more exemplary embodiments. [Figure 2C] Figure 2C shows a block diagram of exemplary operation according to one or more exemplary embodiments. [Figure 2D] Figure 2D shows a block diagram of an exemplary operation according to one or more exemplary embodiments. [Figure 2E] Figure 2E shows a block diagram of an exemplary operation according to one or more exemplary embodiments. [Figure 2F] Figure 2F shows a block diagram of an exemplary operation according to one or more exemplary embodiments. [Figure 3] Figure 3 shows a diagram of exemplary components of a device that may be configured to implement one or more exemplary embodiments. [Modes for carrying out the invention]

[0010] A detailed description of preferred embodiments follows with reference to the accompanying drawings. The foregoing disclosure provides examples and explanations, but is not intended to be exhaustive or to limit implementations to the exact forms disclosed. Modifications and variations are possible in view of the foregoing disclosure or may be obtained from implementations. Furthermore, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Furthermore, in the flowcharts and descriptions of operations provided below, one or more operations may be omitted, one or more operations may be added, one or more operations may be performed (at least partially) simultaneously, and the order of one or more operations may be changed.

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

[0012] Any element, action, or command used herein should not be construed as important or essential unless explicitly stated otherwise. Furthermore, when 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 referring to only one item, the term “one” or similar terms should be used. Also, when used herein, the terms “has,” “have,” “having,” “include,” “including,” or similar terms are intended to be open-ended. Additionally, the phrase “based on” is intended to mean “at least partially based on” unless explicitly stated otherwise. Furthermore, expressions such as "[A] and / or [B]," “at least one of [A] and [B],” or "[A] or [B]" should be understood as including only A, only B, or both A and B.

[0013] Expressions such as "at least one processor" should be understood as either a single processor implementing multiple operations or executing multiple instructions, or as each of multiple processors implementing at least some (but not necessarily all) of the multiple operations.

[0014] Throughout this specification, references to “one embodiment,” “embodiment,” “non-limiting preferred embodiment,” or similar terms mean that certain features, structures, or characteristics described in relation to the embodiments shown are included in at least one embodiment of the Solution. Therefore, throughout this specification, phrases such as “in one embodiment,” “in an embodiment,” “in a non-limiting preferred embodiment,” “in one or more exemplary embodiments,” and similar terms may refer to the same embodiment, but not necessarily the same embodiment.

[0015] Furthermore, the features, advantages, and characteristics described herein may be combined in any preferred manner in one or more exemplary embodiments. Those skilled in the art will recognize, in view of the description herein, that the disclosure may be implemented without one or more of the specific features or advantages of a particular embodiment. In other examples, further features and advantages may be recognized in certain embodiments, which may not be present in all embodiments of the disclosure.

[0016] Furthermore, the term “vehicle” as used herein refers to any preferred type of vehicle on which exemplary embodiments of the present disclosure may be implemented. For example, “vehicle” may refer to a powered vehicle, such as a passenger car, truck, bus, motorcycle, or any other preferred type of motor vehicle powered by an engine, motor, or other mechanical means. Alternatively or further, “vehicle” as used herein may refer to a bicycle, skateboard, and any other preferred type of unpowered vehicle, without departing from the scope of the present disclosure.

[0017] Software updates are crucial for ensuring that the software system remains up-to-date with the latest technological advancements, safety-critical updates, and security patches. This is because it improves or optimizes the overall performance of the vehicle and enhances the user experience. Therefore, installing or applying software updates to the vehicle's automotive software system (e.g., vehicle OS, application stack, etc.) is important.

[0018] In related technologies, updating an automotive software system requires that the entire software update be installed each time. This requires a large amount of communication bandwidth to transmit the software update (or associated files) to the vehicle, a significant amount of storage to hold the entire software update, and a considerable amount of time for the software update to be applied. Furthermore, in related technologies, software updates are not interruptible. For example, if a software update is interrupted, it must be restarted from the beginning.

[0019] Furthermore, in related technologies, the communication between a vehicle system and a source providing software updates may not be secure. Specifically, the communication before and during the acquisition of software updates may be exposed to security risks (e.g., the vehicle system may communicate with an untrusted source, and the files / data being exchanged may be tampered with). In addition, the downloaded software updates may be unauthentic and / or incomplete.

[0020] Exemplary embodiments of the present disclosure provide a system, method, device, and the like that can effectively reduce the time related to the transmission of software updates, reduce the storage required to store software update data, and accelerate the application of software updates. Specifically, the exemplary embodiments of the present disclosure facilitate differential software updates to the operating system (OS) in a vehicle system by dividing the OS into multiple partitions and separating the software updates into multiple parts. As a result, software updates for different partitions of the OS can be performed separately and independently without requiring the transmission of the entire software update, the storage of the entire update, and the installation of the entire software update. Since the software updates can be performed by partition, only the associated parts of the software update are required for transmission, storage, and application.

[0021] Furthermore, the exemplary embodiments of the present disclosure provide a system, method, device, and the like that utilize various security mechanisms to improve the security of software updates. For example, the communication between the vehicle system and the source before and during the acquisition of software updates can be improved through security operations such as mutual authentication, cryptographic verification, and / or data encryption. In addition, the reliability and integrity of the downloaded software updates can be verified before the software updates are stored and applied to the vehicle system. As a result, the exemplary embodiments can improve the security of the transmission, storage, and application of software updates.

[0022] It is assumed that the features, advantages, and significance of the exemplary embodiments described in this specification are merely a part of the present disclosure, not intended to be comprehensive, nor intended to limit the scope of the present disclosure. Further explanations regarding the features, components, configurations, operations, and implementation aspects of the exemplary embodiments of the present disclosure are provided below.

[0023] Exemplary System Configuration FIG. 1 shows a block diagram of an exemplary system configuration according to one or more exemplary embodiments. As shown in FIG. 1, a vehicle system 100 may be implemented in a vehicle and interact with a source 200 to communicate information associated with a software update 210.

[0024] The vehicle system may include an operating system (OS) 110. The OS 110 may be separated into at least two partitions, namely, a first partition 111 and a second partition 112. The first partition 111 and the second partition 112 may be logical partitions implemented by the configuration of the OS 110. This enables software that does not follow or recognize a partitioning mechanism to still perform updates to the OS 110.

[0025] In this regard, the logical partitions described in this specification may refer to virtual partitions within the system resources (e.g., memory, storage, etc.) created and managed by the OS 110. The logical partitions may correspond to different functional roles and / or security levels in the system. The configuration of the OS 110 that implements the logical partitions may include, for example, a file system structure (e.g., the types of files / data that each partition can store, the organization of files / data within each partition, etc.), an access control configuration (e.g., only core system applications can access the first partition 111, only a specific type of software update can modify the content in the first partition 111, etc.), and the like.

[0026] The first compartment 111 may be located in a central location within the vehicle hardware and may be configured to manage a first type of data. The first type of data may include data that does not require updates or is unlikely to require regular updates, such as incompatible data, data that does not change frequently, and / or safety-critical data. In non-limiting examples, the first type of data may include mathematical libraries, localization support data, help files, common operating system components or safety calibration data that are strongly tied to the hardware, and similar. The first compartment 111 may receive and contain safety-critical and / or incompatible elements (or associated data) of software updates and may operate in secure boot mode. In some exemplary implementations, the first compartment 111 may also be referred to as the “base compartment”.

[0027] The second compartment 112 may be located in various places within the vehicle hardware and may be configured to manage a second type of data. The second type of data may include data that may require frequent updates or may require periodic updates, such as adaptive data, frequently changing data, and / or non-safety-critical data. In non-limiting examples, the second type of data may include infotainment application data, media metadata, and / or any other data associated with non-safety-related functions. According to exemplary embodiments, the second compartment 112 may include multiple subcompartments sharing the same characteristics (e.g., non-safety-critical) and may operate in a distributed manner across different parts of the vehicle. In some exemplary implementations, the second compartment 112 may also be referred to as an “application compartment”.

[0028] According to exemplary embodiments, each of the first compartment 111 and the second compartment 112 may comprise a data compartment (or have associated data compartments). The data compartments may include configuration data, calibration data, and / or other non-user data. The first compartment 111 and the second compartment 112 may include executable code / libraries that, when executed (e.g., by a processor associated with the vehicle system 100), enable the first compartment 111 and the second compartment 112 to read and manage data in their associated data compartments. In some exemplary implementations, the executable code may be designed so that data can be managed (e.g., updated) without adding safety risks.

[0029] During operation, the first partition 111 and the second partition 112 can cooperate and interact with each other. According to exemplary embodiments, the second partition 112 can extract functions from the first partition 111 (for example, an application in the second partition can access mathematical libraries present in the first partition). In this respect, since the first partition 111 and the second partition 112 are logical partitions implemented by the OS 110, potential interoperability issues (which may arise in physical partitions) can be prevented. Dependencies between the first partition 111 and the second partition 112 can be represented in the metadata of the associated continuous integration and continuous delivery (CI / CD) system and can be tested and implemented during installation and boot time. In some exemplary embodiments, inter-partition dependencies can be contained in a software bill of materials (SBOM), which is a unique structured list of software and associated materials related to the vehicle.

[0030] The determination, identification, or definition of adaptable and imadaptable data may be performed, for example, by the vehicle manufacturer, based on an analysis of historical data (e.g., software installed on similar vehicle models in the past). According to an exemplary embodiment, when software is installed in a vehicle (e.g., installed in an electronic control unit (ECU), OS, etc.), an image of the installed software may be created, and associated files may be hashed and associated timestamps recorded. Thus, available updates (e.g., updates available for the ECU, OS, etc.) may be applied to or installed on the image in sequence. After the updates are applied, the associated files / data may again be hashed and compared to the initially installed software in order to determine and record the changed / updated files / data (e.g., delta). After the updates are applied, it may be possible to determine which files / data have not been changed, which files / data have been changed rarely, and which files / data have been modified frequently. Such information may be used to determine or define adaptable and imadaptable data.

[0031] Still referring to Figure 1, the vehicle system 100 may interact with source 200 to communicate information that is available to or associated with software updates associated with OS 110. Source 200 may include, for example, devices (e.g., servers) of the vehicle manufacturer or original product manufacturer (OEM) (which may provide software updates relating to core applications and safety-critical features), devices (e.g., servers) of third-party service providers (e.g., infotainment application providers), devices (e.g., servers) of authorized service centers, and similar devices. Communication between the vehicle system 100 and source 200 may occur over-the-air (OTA) via wireless connections such as cellular network connections (e.g., 5G, LTE, etc.), Wi-Fi connections, satellite connections, roadside infrastructure (e.g., vehicle-to-infrastructure (V2I) communications, etc.), and similar devices.

[0032] According to an exemplary embodiment, source 200 may broadcast a beacon to inform the associated vehicle about an available software update. In some exemplary implementations, the beacon may include information indicating that a software update is available. In this case, upon detecting the beacon, vehicle system 100 may communicate with source 200 (e.g., via the initiation of a handshake procedure) to obtain details of the available software update. Alternatively, the beacon may include detailed information about the available software update, such as the type of software update (e.g., safety critical, optional), the file size and version number of the software update, part information (e.g., which parts of the software update contain adaptable / inadaptive data), the target application to which the software update should be applied (e.g., ADAS application, navigation application), and similar information. In this case, upon detecting the beacon, vehicle system 100 may evaluate whether the available software update is required in OS 110 and then initiate communication with source 200 if required.

[0033] Alternatively or further, the vehicle system 100 may actively query the source 200 for software updates based on one or more default conditions, such as time-based conditions, event-based conditions, system health-based conditions, and similar conditions. For example, the vehicle system 100 may initiate a query to the source 200 when it detects from a timer that a predetermined amount of time has elapsed since the last software update, when it detects from navigation information that the vehicle has crossed a geographical boundary, when it detects from the system clock that Daylight Saving Time (DTS) has been implemented, when it detects from the fuel counter that the vehicle has refueled a certain number of times, when it detects from a battery sensor that the vehicle battery has dropped to a certain level, when it detects from the odometer that the vehicle's mileage exceeds a certain threshold, and similar conditions. According to an exemplary embodiment, the conditions that trigger a software update query may be included in a list, and the vehicle system 100 may periodically monitor the vehicle and, if one or more of the conditions in the list are detected, initiate a query for a software update. According to an exemplary embodiment, each software or application installed on the OS 110 may have its own trigger conditions (i.e., if different conditions are detected, the vehicle system 100 may initiate a query for a software update for a different application).

[0034] If the vehicle system 100 receives a response indicating that no software update is available after sending a query to source 200, the vehicle system 100 may reset the associated trigger conditions (for example, resetting a timer indicating the elapsed time since the last update, or resetting a fuel counter). On the other hand, based on the decision that a software update is available, the vehicle system 100 may communicate with source 200 to obtain the software update.

[0035] Before obtaining or downloading a software update from source 200, vehicle system 100 may initiate a handshake session with source 200, during which vehicle system 100 and source 200 may perform one or more actions to authenticate and verify each other. According to an exemplary embodiment, vehicle system 100 and source 200 may perform mutual authentication to ensure that both are trusted, that the data is authentic, and that the communication is secure. For example, vehicle system 100 may provide its identification credentials (e.g., a digital certificate containing a public key or other identification information) to source 200. Similarly, source 200 may provide its identification credentials (e.g., a digital certificate containing a public key or other identification information) to vehicle system 100. Thus, vehicle system 100 and source 200 may verify each other's identification information (e.g., by checking the received certificate against the credential authority (CA) that issued the certificate, or by checking the received certificate against a list of known certificates and using public key cryptography technology).

[0036] According to an exemplary embodiment, during mutual authentication, the vehicle system 100 may provide the source 200 with unique vehicle identification information. This unique identification information may include a vehicle identification number (VIN) and / or a unique combination of the SBOM and associated hash. The SBOM and hash may be generated in the vehicle system 100 upon successful verification of several vehicle components (e.g., verification of secure boot of multiple ECUs via a shortest path algorithm). Thus, the vehicle system 100 may provide unique vehicle identification information regardless of the vehicle's geographical location or VIN format.

[0037] According to an exemplary embodiment, upon successful mutual authentication, the vehicle system 100 and source 200 may use public key cryptography to verify or authenticate each other's integrity and reliability, as well as data exchange between the vehicle system 100 and source 200. For example, source 200 may sign data using its private key and then provide the signed data to the vehicle system 100. Thus, vehicle system 100 may verify the signed data using the source's public key (obtained during mutual authentication) (e.g., vehicle system 100 may decrypt the signed data using the source's public key). Similarly, vehicle system 100 may sign data using its private key and then provide the signed data to source 200, and source 200 may verify the signed data using the vehicle system's public key (obtained during mutual authentication).

[0038] According to exemplary embodiments, cryptographic operations may be performed in software and / or hardware. Software-based cryptographic operations are implemented and executed using algorithms in software, and cryptographic functions (e.g., encryption, writing, signing, etc.) may be performed on general-purpose components (e.g., a CPU). On the other hand, hardware-based cryptographic operations are implemented and executed using hardware components dedicated to processing security-related tasks (e.g., hardware components implementing a highly reliable execution environment (TEE)). The location where cryptographic operations are performed may be dynamically selected based on, for example, the cryptographic algorithm (e.g., complexity, security, library support, hardware support, etc.), the size of the data to be encrypted / decrypted, and security implications (e.g., maximum execution time, etc.). In this way, the vehicle system 100 can dynamically select the optimal location for performing cryptographic operations.

[0039] Upon successful mutual authentication (or, in some embodiments, successful cryptographic verification), a secure communication channel can be established between the vehicle system 100 and the source 200. At this stage, the vehicle system 100 and the source 200 can securely communicate and exchange data with each other. For example, the vehicle system 100 may provide the source 200 with the current version of software installed therein, and the source 200 may verify that a software update is available for the vehicle system 100. In some exemplary embodiments, the vehicle system 100 and the source 200 may optionally encrypt data transmission over the secure communication channel (e.g., via Advanced Encryption Standard (AES) encryption) to further enhance the security of communication between the vehicle system 100 and the source 200.

[0040] According to exemplary embodiments, the vehicle system 100 and source 200 may synchronize necessary information / data by exchanging lists of files through an operation such as rsync. In this regard, an rsync-like operation as described herein may refer to an operation that synchronizes data between two systems (e.g., vehicle system 100 and source 200) by comparing files / data in the two systems and transferring only the files or data that are different. In some exemplary embodiments, advanced data structures and algorithms may be used by the vehicle system 100 and / or source 200 to efficiently manage large amounts of data during file / data synchronization. Some non-exclusive examples of advanced data structures are rolling hashes that enable rapid identification of changes between files / data, Bloom filters that enable rapid determination of the presence or absence of files / data, and Merkle trees that enable efficient identification of differences in data at different levels (e.g., root level, branch level, etc.).

[0041] Once file exchange and synchronization are complete, the vehicle system 100 may obtain the software update (or associated data) from the source 200. According to an exemplary embodiment, the source 200 may broadcast the software update to the vehicle system 100. Furthermore, or alternatively, the vehicle system 100 may obtain the software update by, for example, directly downloading from a server associated with the source 200, performing a peer-to-peer (P2P) download from another vehicle or device that has already obtained the required software update, downloading from a Content Delivery Network (CDN), or a combination thereof. According to an exemplary embodiment, the software update (or data associated with the software) may include a signature that can be verified or authenticated by the vehicle system 100. For example, in the case of P2P file sharing, the software update may be distributed in the form of multiple pieces or torrent blocks (e.g., via torrent packetization). In this case, each torrent block or packet within the torrent may be signed (using the public key of source 200, for example), and the vehicle system 100 may verify or authenticate the torrent block / packet (using the public key of source 200 obtained during mutual authentication, for example) to ensure that the downloaded data is not corrupted or tampered with.

[0042] According to exemplary embodiments, the application of a software update (which may also be referred to herein as “software installation”) may be separated into at least two parts, each of which may be performed on a separate partition in OS110. For example, as shown in Figure 1, a software update 210 may be separated into a first part 211 and a second part 212. In this regard, the first part 211 may include non-adaptive data, data that does not change frequently, and / or safety-critical data that can be installed or applied to a first partition 111 of OS110, and the second part 212 may include adaptable data, data that changes frequently, and / or non-safety-critical data that can be installed or applied to a second partition 112 of OS110. Further descriptions of examples and characteristics of data have been given above with reference to the first partition 111 and the second partition 112, and therefore, redundant descriptions associated with such examples and characteristics of data may be omitted below for brevity.

[0043] According to an exemplary embodiment, the vehicle system 100 may obtain only the necessary parts of the software update (e.g., a first part 211, a second part 212, etc.) from the source 200, rather than downloading the entire software update 210. For example, the vehicle system 100 may determine that a software update is needed in a second section 112, and therefore obtain only the second part 212 of the software update from the source 200.

[0044] When a software update is obtained from source 200, the vehicle system 100 may store the obtained software update in, for example, a cache or non-volatile storage, so that the vehicle system 100 can apply the software update in the associated partition at a later time. According to an exemplary embodiment, the vehicle system 100 may perform integrity and reliability checks on the obtained software update before storing or applying it. For example, the software update may be signed by source 200, and the vehicle system 100 may verify the digital signature in the software update using the public key of source 200 (obtained during mutual authentication), thereby ensuring that the software update was provided by source 200 and was not modified during transmission. As another example, the vehicle system 100 may perform an integrity check by verifying the hash or checksum of the software update, thereby ensuring that the necessary parts of the software update have been downloaded correctly and that there are no missing or corrupted parts.

[0045] According to exemplary embodiments, the installation or application of a software update may be automatically triggered. For example, the vehicle system 100 may set a timer so that, once a software update (or a necessary part thereof) is acquired, the software update may be automatically installed or applied after a certain amount of time has elapsed. As another example, the vehicle system 100 may build a schedule, for example, based on the driver's preferences or habits, so that the installation or application of a software update may be automatically performed when the vehicle is not in use. Furthermore or alternatively, the installation or application of a software update may be manually triggered by a vehicle user (e.g., the driver, passengers, etc.). For example, when the vehicle system 100 is ready to install or apply a software update, it may notify the vehicle user, for example, by outputting a notification about the software update (e.g., displaying a notification in the infotainment system). Thus, upon receiving approval from the vehicle user, the vehicle system 100 may install or apply the software update. In some exemplary embodiments, the installation or application of a software update (e.g., downloading, installing, and checking update files, etc.) may be performed in the background while the vehicle is running or in use. For example, upon acquiring a software update (or its necessary parts / data), the vehicle system 100 may determine whether the vehicle or the vehicle system 100 has sufficient resources (e.g., memory, computing power, etc.) to install or apply at least part of the software update in the background without affecting the vehicle's performance. Therefore, based on the determination that the vehicle / vehicle system 100 has sufficient resources to install or apply the software update in the background, the vehicle system 100 may automatically install or apply the software update in the background.On the other hand, based on the determination that the vehicle / vehicle system 100 does not have sufficient resources to install or apply the software update in the background, the vehicle system 100 may install or apply the software update at a later time (for example, when the vehicle is not in use or when the vehicle has sufficient resources to install or apply the software update in the background).

[0046] The configuration and associated features of Figure 1 described herein are merely examples of possible embodiments, and it is assumed that the scope of this disclosure should not be limited to such examples. Specifically, the system may include more / fewer components than those described and / or be configured in a different manner without departing from the scope of this disclosure. For example, in some exemplary embodiments, the vehicle system 100 may communicate with a plurality of sources 200, the sources 200 may include a plurality of software updates 210, some of the software updates 210 may be further separated into a plurality of sub-parts, and so on.

[0047] According to an exemplary embodiment, OS110 may include a third partition that is logically (and, where applicable, physically) separated from the other partitions of OS110. This third partition may be configured to manage or store highly private data, such as user profile data, application logs, data collected by the vehicle (e.g., sensor data around the time ADAS is deactivated for further analysis and continuous improvement), and similar data. Because this data may have special requirements from a privacy standpoint, any software updates should not access this third partition or modify the data in this third partition, but may only modify the data in the general data partition. Furthermore, the data in this third partition should be easily erasable, and (where applicable) additional security mechanisms should be applied. Thus, managing this data in a logically (and, where applicable, physically) separated partition may facilitate deletion and provide further improvements in data security.

[0048] To this end, exemplary embodiments of this disclosure provide a system that effectively facilitates differential software updates to an OS in a vehicle system. Specifically, partitioning the OS and separating software updates enables differential software updates to any of the OS partitions. For example, software updates to different partitions of the OS can be performed separately and independently without requiring the transmission of the entire software update, storage of the entire update, and installation of the entire software update. Conversely, since software updates can be performed by partition, only the relevant portion of the software update is required for transmission, storage, and application. As a result, the system of the exemplary embodiment can effectively reduce the time required for transmitting software updates, reduce the storage required to store software update data, and accelerate the application of software updates.

[0049] Furthermore, exemplary embodiments of this disclosure also provide systems that utilize various security mechanisms to enhance the security of software updates. For example, communication between the vehicle system and the source before and during the acquisition of software updates can be enhanced through security operations such as mutual authentication, cryptographic verification, and / or data encryption. In addition, the reliability and integrity of downloaded software updates can be verified before the software updates are stored and applied to the vehicle system. As a result, the systems of exemplary embodiments can enhance the security of software update transmission, storage, and application.

[0050] Exemplary behavior As described above, various operations may be performed by the vehicle system 100 and source 200 to facilitate differential software updates and improve the security of software updates. Some exemplary operations according to one or more exemplary embodiments are described below with reference to Figures 2A to 2F. One or more operations (or data relating to such operations) may be the same as those described above with reference to Figure 1, and therefore the operations / data described may apply similarly to the operations in Figures 2A to 2F (unless otherwise specified), and redundant explanations associated with such operations / data may be omitted for brevity.

[0051] For explanatory purposes, the operations are described primarily as being performed by the vehicle system 100; however, in actual implementations, it can be understood that, without departing from the scope of this disclosure, the source 200 may perform similar / related operations from the reverse side. For example, the operation of the vehicle system 100 receiving data from the source 200 may represent or suggest the operation of the source 200 transmitting data to the vehicle system 100; the operation of the vehicle system 100 verifying the source 200 may represent or suggest similar operations as when the source 200 verifies the vehicle system 100; and similar things.

[0052] According to exemplary embodiments, the vehicle system 100 may include (or be implemented in) one or more hardware components, and one or more operations described herein below may be performed by one or more hardware components of the vehicle system 100. For example, the vehicle system 100 may include (or be implemented in) a processor and memory storage (or any other suitable storage medium), and the memory storage may include computer executable instructions that, when executed by the processor, cause the processor to perform one or more operations described herein.

[0053] Figure 2A shows a block diagram of an exemplary method 300 for facilitating differential software updates according to one or more exemplary embodiments.

[0054] In operation S310, the vehicle system 100 (or associated processor) may be configured to communicate information associated with a software update of the vehicle system's OS (e.g., OS110) with an external source (e.g., source 200) of the vehicle system 100. An exemplary operation for communicating information associated with a software update is described below with reference to Figures 2C and 2D.

[0055] When information associated with a software update is communicated, in operation S320, the vehicle system 100 (or associated processor) may be configured to retrieve a portion of the software update from the source. An exemplary operation for retrieving a portion of the software update is described below with reference to Figure 2B.

[0056] Upon acquiring a portion of a software update, in operation S330, the vehicle system 100 (or associated processor) may be configured to apply the acquired portion of the software update to a partition of the OS. As described above with reference to Figure 1, the partition of the OS may include at least one of a first partition (e.g., partition 111) managing a first type of data and a second partition (e.g., partition 112) managing a second type of data. The first type of data may include at least one of non-adaptive data, data that does not change frequently, and safety-critical data, while the second type of data may include at least one of adaptable data, data that changes frequently, and non-safety-critical data. Furthermore, the first and second partitions may be logical partitions implemented by the OS configuration. An exemplary operation of acquiring a portion of a software update is described below with reference to Figure 2F.

[0057] Figure 2B shows a block diagram of an exemplary method 400 for obtaining a portion of a software update from a source, according to one or more exemplary embodiments. One or more operations in Figure 2B may be part of operation S320 in Figure 2A.

[0058] As shown in Figure 2B, in operation S410, the vehicle system 100 (or associated processor) may be configured to determine which part of the OS (e.g., which of the first and second parts) requires a software update.

[0059] Therefore, based on the determination that the first partition of the OS requires a software update, method 400 may proceed to operations S420 and S430. Otherwise, based on the determination that the second partition of the OS requires a software update, method 400 may proceed to operations S440 and S450.

[0060] In operation S420, the vehicle system 100 (or associated processor) may be configured to output a request to a resource for a portion of a software update (e.g., a first portion 211) associated with a first type of data (managed by the first compartment). Then, in operation S430, the vehicle system 100 (or associated processor) may be configured to retrieve the requested portion of the software update from the source.

[0061] Similarly, in operation S440, the vehicle system 100 (or associated processor) may be configured to output a request to a resource for a portion of a software update (e.g., a second portion 212) associated with a second type of data (managed by the second compartment). Then, in operation S450, the vehicle system 100 (or associated processor) may be configured to retrieve the requested portion of the software update from the source.

[0062] Figures 2C and 2D each show block diagrams of exemplary methods for communicating information associated with a software update, according to one or more exemplary embodiments. One or more operations in Figures 2C and 2D may be part of operation S310 in Figure 2A.

[0063] First, refer to Figure 2C, which shows a block diagram of an exemplary method 500 for passively obtaining information associated with a software update, according to one or more exemplary embodiments.

[0064] In operation S510, the vehicle system 100 (or associated processor) may be configured to receive a beacon from a source indicating that a software update is available. Thus, in operation S520, the vehicle system 100 (or associated processor) may be configured to determine whether the software update is associated with the OS (for example, whether the software update or a part thereof can be applied to a partition of the OS).

[0065] Method 500 may terminate based on the decision that the software update is not associated with the OS. Alternatively, Method 500 may return to operation S510 so that the vehicle system 100 (or associated processor) can perform Method 500 continuously (or repeatedly) for at least a predetermined period.

[0066] On the other hand, based on the decision that the software update is associated with the OS, method 500 may proceed to operation S530, in which the vehicle system 100 (or associated processor) may be configured to initiate a handshake session with the source. An exemplary operation for initiating a handshake session is described below with reference to Figure 2E.

[0067] Once the handshake session has started successfully, method 500 may proceed to operation S540, in which the vehicle system 100 (or associated processor) may be configured to retrieve information associated with the software update from a source.

[0068] Next, referring to Figure 2D, which shows a block diagram of an exemplary method 600 for actively obtaining information associated with a software update, according to one or more exemplary embodiments.

[0069] In operation S610, the vehicle system 100 (or associated processor) may be configured to determine whether a trigger condition for querying a software update is met. According to an exemplary embodiment, the trigger condition may include at least one of a time-based condition, an event-based condition, and a system health-based condition.

[0070] Method 600 may terminate based on the determination that the trigger condition is not met. Alternatively, the vehicle system 100 (or associated processor) may perform Method 600 continuously (or repeatedly) for at least a predetermined period of time.

[0071] On the other hand, based on the determination that the trigger condition is met, method 600 may proceed to operation S620, in which the vehicle system 100 (or associated processor) may be configured to initiate a handshake session with the source. An exemplary operation for initiating a handshake session is described below with reference to Figure 2E.

[0072] Once the handshake session has started successfully, method 600 may proceed to operation S630, in which the vehicle system 100 (or associated processor) may be configured to retrieve information associated with the software update from a source.

[0073] Figure 2E shows a block diagram of an exemplary method 700 for initiating a handshake session according to one or more exemplary embodiments. One or more actions in Figure 2E may be part of action S530 in Figure 2C or action S620 in Figure 2D.

[0074] In operation S710, the vehicle system 100 (or associated processor) may be configured to perform mutual authentication with the source. Thus, method 700 may proceed to operation S720, in which the vehicle system 100 (or associated processor) may determine whether the mutual authentication was successful. Based on the determination that the mutual authentication was unsuccessful, method 700 may proceed to operation S730, in which the vehicle system 100 (or associated processor) may determine that the handshake session failed to be established.

[0075] On the other hand, based on the determination that mutual authentication is successful, method 700 may proceed to operation S740, in operation S740, in which the vehicle system 100 (or associated processor) may determine that the handshake session has been successfully established.

[0076] Alternatively, based on the determination that mutual authentication is successful, method 700 may proceed to operation S750, in operation S750, the vehicle system 100 (or associated processor) may be configured to perform cryptographic verification against the source. Thus, in operation S760, the vehicle system 100 (or associated processor) may determine whether the cryptographic verification is successful or unsuccessful. Based on the determination that the cryptographic verification is successful, method 700 may proceed to operation S740, in operation S740, the vehicle system 100 (or associated processor) may determine that the handshake session is successfully established. Otherwise, based on the determination that the cryptographic verification is unsuccessful, method 700 may proceed to operation S730, in operation S730, the vehicle system 100 (or associated processor) may determine that the handshake session has failed to be established.

[0077] According to an exemplary embodiment, once it determines that a handshake session has been successfully established, the vehicle system 100 (or associated processor) may be configured to encrypt any data or messages that the vehicle system 100 sends to the source.

[0078] Figure 2F shows a block diagram of an exemplary method 800 for applying a software update according to one or more exemplary embodiments. One or more operations in Figure 2F may be part of operation S330 in Figure 2A.

[0079] In operation S810, the vehicle system 100 (or associated processor) may be configured to verify the authenticity of the acquired software update (for example, a portion of the software update acquired in operation S320). As described above with reference to Figure 1, the vehicle system 100 (or associated processor) may use the source public key to verify whether the acquired software update is authentic.

[0080] Based on the determination that the acquired software update is genuine, method 800 may proceed to operation S820, in which the vehicle system 100 (or associated processor) may be configured to store the acquired software update in a cache (or non-volatile memory) for at least a predetermined amount of time.

[0081] Subsequently, in operation S830, the vehicle system 100 (or associated processor) may be configured to apply the acquired software update (e.g., a portion of the software update acquired in operation S320 and stored in operation S820) to the associated partition of the OS. According to an exemplary embodiment, based on verification that the acquired software update is authentic, the vehicle system 100 (or associated processor) may set the timing for applying the software update (e.g., starting a timer, building a schedule, etc.). In this case, based on the determination that the set timing has elapsed, the vehicle system 100 (or associated processor) may automatically apply the acquired software update to the associated partition of the OS. Alternatively, based on verification that the acquired software update is authentic, the vehicle system 100 (or associated processor) may output a notification regarding the software update, receive user approval to apply the software update, and then apply the acquired software update to the associated partition of the OS. According to an exemplary embodiment, the vehicle system 100 (or associated processor) may be configured to apply acquired software updates (e.g., a portion of software updates acquired in operation S320 and stored in operation S820) in the background while the vehicle is operating or in use. For example, the vehicle system 100 (or associated processor) may be configured to determine whether the vehicle system 100 has sufficient resources to apply acquired software updates in the background while the vehicle system 100 is operating or in use. Therefore, based on the determination that the vehicle system 100 has sufficient resources to apply acquired software updates in the background, the vehicle system 100 (or associated processor) may be configured to apply the acquired software updates to the associated partition of the OS while the vehicle system is operating or in use.

[0082] On the other hand, based on the determination that the acquired software update is not genuine, method 800 may terminate, and the acquired software update may not be stored in the vehicle system or applied to the OS. Alternatively, method 800 may proceed to operation S840, in which the vehicle system 100 (or associated processor) may create an error log (or event log) containing detailed information about the incident (e.g., information about the rejected software update, the reason for the failure, source information, etc.). Then, in operation S850, the vehicle system 100 (or associated processor) may notify the associated user (e.g., present an update failure notification to the driver via the infotainment system, or send the error log to the vehicle manufacturer). Furthermore, the error log information may be sent by the vehicle system to the user's dealer or service center in order to provide the user with services and improvements. Separately, the vehicle system may send the error log information to the vehicle manufacturer or supplier in order to enable continuous improvement.

[0083] To this end, exemplary embodiments of this disclosure provide a method for effectively facilitating differential software updates to an OS in a vehicle system. Specifically, the method includes operations that affect the partitioning of the OS and the separation of software updates, such as acquiring a portion of the software update, applying a portion of the software update to a partition of the OS, and similar actions. Thus, the method of the exemplary embodiment allows software updates to different partitions of the OS to be performed separately and independently without requiring the transmission of the entire software update, storage of the entire update, and installation of the entire software update. Conversely, since software updates can be performed by partition, only the relevant portion of the software update is required for transmission, storage, and application. As a result, the method of the exemplary embodiment can effectively reduce the time required for transmitting software updates, reduce the storage required to store software update data, and accelerate the application of software updates.

[0084] Furthermore, exemplary embodiments of this disclosure also provide methods that include various security mechanisms to enhance the security of software updates. For example, communication between the vehicle system and the source before and during the acquisition of a software update may be enhanced through security operations such as mutual authentication, cryptographic verification, and / or data encryption. In addition, the reliability and integrity of the downloaded software update may be verified before the software update is stored and applied to the vehicle system. As a result, the methods of the exemplary embodiments may enhance the security of software update transmission, storage of software updates, and application of software updates.

[0085] Exemplary components Figure 3 shows a diagram of exemplary components of device 900 according to one or more exemplary embodiments. In some exemplary embodiments, device 900 may be an in-vehicle device implementing vehicle system 100 (or one or more operations associated with vehicle system 100). Furthermore, device 900 may also be equipment such as a server implementing source 200 (or one or more operations associated with source 200).

[0086] As shown in Figure 3, the device 900 may include at least one bus 901, at least one processor 902, at least one memory 903, at least one storage component 904, at least one input component 905, at least one output component 906, and at least one communication interface 907.

[0087] Device 900 is expected to include more or fewer components than those shown in Figure 3 without departing from the scope of this disclosure. For example, in some embodiments, device 900 may include a plurality of storage components 904, input components 905 and output components 906 may be implemented as transceiver components, memory 903 and storage components 904 may be implemented as memory storage, and so on.

[0088] Bus 901 may be configured to facilitate or enable communication between components of device 900. Specifically, bus 901 may connect components in a communicative manner to provide means for the data transfer and flow of control signals between components. Bus 901 may include one or more of the following types of buses that can be implemented in device 900 to enable real-time (or near real-time) communication and cooperation between components within device 900: internal bus, address bus, data bus, control bus, Controller Area Network (CAN) bus, Ethernet bus, Peripheral Component Interconnect Express (PCIe) bus, and any other suitable type of bus.

[0089] The processor 902 may be implemented as hardware, firmware, or a combination of hardware and software, and may be configured to handle real-time (or near real-time) data processing and control of the control device 900. The processor 902 may include one or more of the following: a central processing unit (CPU), an image processing unit (GPU), a neural processing unit (NPU), a tensor processing unit (TPU), an accelerator processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), and / or other types of processing or computational components that may be implemented in the device 900. In some implementations, the processor 902 may be programmable to perform one or more operations described herein. Furthermore, the processor 902 may include multiple processing units, each dedicated to performing a particular operation.

[0090] Memory 903 may include one or more media for storing temporary data, runtime variables, program instructions, and buffers required for the operation of the control device 900. Memory 903 may include one or more of the following types of memory that can be implemented in device 900 to store information and / or instructions for use by the processor 902: flash memory, read-only memory (ROM), random access memory (RAM), dynamic or static storage devices (e.g., flash memory, magnetic memory, and / or optical memory), and any other suitable types of memory.

[0091] The storage component 904 may be configured to store non-volatile data, such as firmware, configuration settings, calibration data, information, and / or software related to the operation and use of device 900. For example, the storage component 904 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, a magnetic tape, and / or another type of non-temporary computer-readable media.

[0092] According to one embodiment, the storage component 904 may be configured to store computer-readable instructions or computer-executable instructions that implement one or more operations of the device 900. The storage component 904 may provide the stored information to the memory 903 for the execution of the processor 902.

[0093] The input component 905 may include one or more input components (e.g., a touchscreen display, keyboard, keypad, mouse, buttons, switches, and / or microphone) that enable the device 900 to receive information via user input or the like. The output component 906 may include one or more output components (e.g., a display, speaker, navigation device, one or more light-emitting diodes (LEDs), etc.) that provide output information from the device 900. According to the embodiment, the input component 905 and / or the output component 906 may be optional and may be excluded from the device 900. According to the exemplary embodiment, the input component 905 and / or the output component 906 may be optional.

[0094] At least one communication interface 907 may include transceiver-like components (e.g., transceivers and / or separate receivers and transmitters) that enable device 900 to communicate with other components (e.g., ECUs, user devices, etc.) via wired connections, wireless connections, or a combination of wired and wireless connections. For example, communication interface 907 may include a Controller Area Network (CAN) bus interface, an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a Universal Serial Bus (USB) interface, a Wi-Fi interface, a cellular network interface, or similar.

[0095] According to one or more embodiments, the communication interface 907 may include at least one input / output (I / O) interface, at least one network interface, at least one storage interface, or similar, which enable components 902-906 to communicate with other components. Furthermore, the communication interface 907 may include one or more application programming interfaces (APIs) which enable device 900 (or one or more components included in device 900) to communicate with one or more software applications (e.g., software applications deployed in an ECU).

[0096] Computer executable instructions (e.g., software instructions) may be read into memory 903 and / or storage component 904 from another computer-readable medium or another device (e.g., a remote server, external storage) via, for example, the communication interface 907. When executed, the computer executable instructions stored in memory 903 and / or storage component 904 may cause the processor 902 to perform one or more processes described herein. Furthermore or alternatively, hardwired circuits may be used in place of or in combination with software instructions to perform one or more processes described herein. Therefore, the implementations described herein are not limited to any particular combination of hardware circuits and software.

[0097] Various embodiments Referring to Figures 1 to 3, the features, advantages, and importance of the exemplary embodiments described herein are merely part of the disclosure and are not intended to be exhaustive or to limit the scope of the disclosure. Further descriptions of the features, components, configurations, operations, and implementations of the exemplary embodiments of the disclosure, as well as the associated technical advantages and importance, are provided below.

[0098] It is understood that any particular order or hierarchy of blocks in the processes / flowcharts disclosed herein is illustrative of exemplary techniques. It is understood that any particular order or hierarchy of blocks in the processes / flowcharts may be rearranged based on design preferences. Furthermore, some blocks may be combined or omitted. The appended method claims present elements of various blocks in a sample order and are not intended to be limited to any particular order or hierarchy presented.

[0099] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of technical detail of integration. Furthermore, as described herein, 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 (or multiple mediums) having computer-readable program instructions to cause a processor (or multiple processors) to perform an operation.

[0100] A computer-readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction-executing device. A computer-readable storage medium may be, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any preferred combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes, namely, 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 versatile disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punched cards or grooved raised structures on which instructions are recorded, and any preferred 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 transmitting media (e.g., light pulses passing through optical fiber cables), or electrical signals transmitted through wires.

[0101] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device, or they may be downloaded 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 device receives computer-readable program instructions from the network and transfers the computer-readable program instructions for storage in a computer-readable storage medium within each computing / processing device.

[0102] The computer-readable program code / instructions that perform the 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, C++, or similar, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may be fully executed on the user's computer, partially executed on the user's computer, executed as a standalone software package, partially executed on the user's computer and partially executed on a remote computer, or fully executed on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or a connection to an external computer may be made (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 personalizing the electronic circuit using state information of computer-readable program instructions in order to perform a particular action or operation.

[0103] The computer-readable program instructions may be provided to the processor of a SoC, general-purpose computer, dedicated computer, or other programmable data processing device to generate a machine, and as a result, the instructions executed via the processor of the computer or other programmable data processing device create means for implementing functions / actions specified in blocks or blocks of a flowchart and / or block diagram. The 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, the computer-readable storage medium in which the instructions are stored comprises a manufactured article containing instructions for implementing modes of functions / actions specified in blocks or blocks of a flowchart and / or block diagram.

[0104] Computer-readable program instructions can also be loaded onto a computer, other programmable data processing device, or other device to perform a series of operational steps on the computer, other programmable device, or other device, thereby generating a computer implementation process, the instructions executed on the computer, other programmable device, or other device, which implement the functions / actions specified in the blocks or blocks(s) of a flowchart and / or block diagram.

[0105] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions comprising one or more executable instructions that implement a specified logical function. Methods, computer systems, and computer-readable media may include additional blocks, fewer blocks, different blocks, or blocks arranged differently compared to those depicted in the figures. In some alternative implementations, the functions described in the blocks may occur regardless of the order in which they are shown in the figures. For example, two blocks shown consecutively 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, and combinations of blocks in a block diagram and / or flowchart, may be implemented by a dedicated hardware-based system that performs a specified function or action or executes a dedicated combination of hardware and computer instructions.

[0106] It will be apparent that the systems and / or methods described herein can be implemented in various forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement such systems and / or methods is not a limitation of the 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 can be designed to implement the systems and / or methods based on the descriptions herein.

Claims

1. A method for updating software in a vehicle system, wherein the method is: The processor communicates information associated with software updates to the operating system (OS) of the vehicle system with an external source of the vehicle system, The aforementioned processor obtains a portion of the software update from the aforementioned source, The processor applies the acquired portion of the software update to the OS partition, Includes, The partition of the OS comprises at least one of a first partition for managing a first type of data and a second partition for managing a second type of data. The first type of data comprises at least one of the following: immutable data, data that does not change frequently, and safety-critical data. The second type of data comprises at least one of adaptive data, frequently changing data, and non-safety-critical data. A method wherein the first partition and the second partition are logical partitions implemented by the configuration of the OS.

2. The acquisition of the aforementioned part of the software update is The processor determines which of the first and second partitions requires the software update, Based on the determination that the first partition requires the software update, the processor outputs a request to the source for a portion of the software update associated with the first type of data, Based on the determination that the second partition requires the software update, the processor outputs a request to the source for a portion of the software update associated with the second type of data, The processor obtains the requested portion of the software update from the source, The method according to claim 1, including the method described in claim 1.

3. The communication of the information associated with the software update is The processor receives a beacon from the source indicating that the software update is available, The processor determines whether the software update is associated with the OS, Based on the decision that the software update is associated with the OS, the processor initiates a handshake session with the source, Based on the determination that the handshake session has started successfully, the processor obtains information associated with the software update from the source, The method according to claim 1 or 2, including the method described in claim 1 or 2.

4. The communication of the information associated with the software update is The aforementioned processor determines whether the trigger conditions for querying a software update are met, Based on the determination that the trigger condition is met, the processor initiates a handshake session with the source. Based on the determination that the handshake session has started successfully, the processor obtains information associated with the software update from the source, The method according to claim 1 or 2, including the method described in claim 1 or 2.

5. The commencement of the handshake session is The processor performs mutual authentication with the source, Based on the determination that the aforementioned mutual authentication is successful, the processor performs cryptographic verification on the source, The method according to claim 3, including the method described in claim 3.

6. The method according to claim 4, wherein the trigger condition comprises at least one of a time-based condition, an event-based condition, and a system health-based condition.

7. The method according to claim 1 or 2, further comprising the processor verifying the authenticity of a portion of the acquired software update based on the public key of the source.

8. The method according to claim 7, further comprising the processor storing the acquired portion of the software update in a cache for at least a predetermined amount of time, based on verification that the acquired portion of the software update is genuine.

9. The aforementioned application of the aforementioned software update, Based on verification that a portion of the acquired software update is genuine, the processor sets the timing for applying that portion of the software update. Based on the determination that the set timing has elapsed, the processor applies the acquired portion of the software update to the partition of the OS. The method according to claim 7 or 8, including the method described in claim 7 or 8.

10. The aforementioned application of the aforementioned software update, Based on verification that a portion of the acquired software update is genuine, the processor outputs a notification regarding the software update. The processor receives user authorization to apply the software update, The processor applies the acquired portion of the software update to the partition of the OS, The method according to claim 7 or 8, including the method described in claim 7 or 8.

11. The aforementioned application of the aforementioned software update, The processor determines whether the vehicle system has sufficient resources to apply the acquired portion of the software update in the background while the vehicle system is operating, Based on the determination that the vehicle system has sufficient resources to apply the acquired portion of the software update in the background, the acquired portion of the software update is applied to the OS partition while the vehicle system is operating. The method according to claim 1 or 2, including the method described in claim 1 or 2.

12. A device for updating software in a vehicle system, wherein the device is Memory storage that stores executable computer instructions, A processor that is communicatively connected to the aforementioned memory storage, The processor is equipped with the following, and executes the instruction: Information related to software updates for the operating system (OS) of the vehicle system is communicated with an external source of the vehicle system. A portion of the aforementioned software update is obtained from the aforementioned source, The software update is configured to apply a portion of the acquired software update to the OS partition. The partition of the OS comprises at least one of a first partition for managing a first type of data and a second partition for managing a second type of data. The first type of data comprises at least one of the following: immutable data, data that does not change frequently, and safety-critical data. The second type of data comprises at least one of adaptive data, frequently changing data, and non-safety-critical data. The first partition and the second partition are logical partitions implemented by the configuration of the OS, and the device.

13. The aforementioned processor, To determine which of the first and second partitions requires the software update, Based on the determination that the first partition requires the software update, a request for a portion of the software update associated with the first type of data is output to the source, Based on the determination that the second partition requires the software update, a request for a portion of the software update associated with the second type of data is output to the source, The processor obtains the requested portion of the software update from the source, The device according to claim 12, configured to obtain the portion of the software update by means of the device.

14. The aforementioned processor, Receiving a beacon from the source indicating that the aforementioned software update is available, To determine whether the aforementioned software update is associated with the aforementioned OS, Based on the decision that the software update is associated with the OS, a handshake session with the source is initiated. Based on the determination that the handshake session has started successfully, information associated with the software update is obtained from the source, The device according to claim 12 or 13, configured to communicate the information associated with the software update.

15. The aforementioned processor, Determining whether the trigger conditions for querying software updates are met, Based on the determination that the trigger condition is met, a handshake session with the source is initiated. Based on the determination that the handshake session has started successfully, information associated with the software update is obtained from the source, The device according to claim 12 or 13, configured to communicate the information associated with the software update.

16. The aforementioned processor, Mutual authentication with the aforementioned source, Based on the determination that the aforementioned mutual authentication is successful, cryptographic verification is performed on the source, The device according to claim 14, configured to initiate the handshake session.

17. The device according to claim 15, wherein the trigger condition comprises at least one of a time-based condition, an event-based condition, and a system health-based condition.

18. The device according to claim 12 or 13, wherein the processor is further configured to verify the authenticity of any acquired portion of the software update based on the public key of the source.

19. The device according to claim 18, wherein the processor is further configured to store the acquired portion of the software update in a cache for at least a predetermined amount of time, based on verification that the acquired portion of the software update is authentic.

20. A computer program for causing a processor to perform a method for updating software in a vehicle system, wherein the method is: The processor communicates information associated with software updates to the operating system (OS) of the vehicle system with an external source of the vehicle system, The aforementioned processor obtains a portion of the software update from the aforementioned source, The processor applies the acquired portion of the software update to the OS partition, Includes, The partition of the OS comprises at least one of a first partition for managing a first type of data and a second partition for managing a second type of data. The first type of data comprises at least one of the following: immutable data, data that does not change frequently, and safety-critical data. The second type of data comprises at least one of adaptive data, frequently changing data, and non-safety-critical data. The first partition and the second partition are computer programs, which are logical partitions implemented by the configuration of the OS.

Images