Method, device, and program product for updating software in a vehicle system

Abstract

The present disclosure relates to the provision of methods, apparatuses, and program products for updating software in a vehicle system. Exemplary embodiments of the present disclosure facilitate differential software updates to an operating system (OS) of an automobile. According to embodiments, a method can include communicating information associated with a software update to the OS, obtaining a portion of the software update, and applying the obtained portion of the software update to a partition of the OS. The partition of the OS can be a first partition that manages a first type of data and / or a second partition that manages a second type of data. The first type of data can include inadaptable data, infrequently changing data, and / or safety-critical data. The second type of data can include adaptable data, frequently changing data, and / or non-safety-critical data. The first and second partitions can be logical partitions implemented by a constitution of the OS.

Description

Technical Field

[0001] Exemplary embodiments of this disclosure relate to software updates in vehicle systems, and more specifically, to techniques that facilitate differential software updates in the operating system (OS) of a vehicle system. Background Technology

[0002] Modern vehicles rely heavily on motion-related software such as vehicle performance management, safety system control, navigation, infotainment, and similar functions. Software updates to vehicle systems involve installing new or modified software onto the vehicle's operating system (OS) to improve functionality, correct system bugs, enhance safety, and / or add new features. These software updates can be delivered during vehicle maintenance at a service center or wirelessly (e.g., via cellular connections) via over-the-air (OTA) updates. Summary of the Invention

[0003] Exemplary implementations matching this disclosure effectively and efficiently facilitate differential software updates to the operating system (OS) of a vehicle.

[0004] According to an exemplary implementation, a processor-executable method for updating software in a vehicle system may include: communicating with a source outside the vehicle system regarding information associated with a software update of the vehicle system's OS; 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 OS partition 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-malleable data, infrequently changing data, and safety-critical data. The second type of data may include at least one of malleable data, frequently changing data, and non-safety-critical data. The first and second partitions may be logical partitions implemented through the configuration of the OS.

[0005] According to an exemplary embodiment, a device for updating software in a vehicle system may include a storage device and a processor. The storage device may store computer-executable instructions, and the processor may be communicatively connected to the storage device and configured to execute instructions to perform the following actions: communicating with a source outside the vehicle system regarding information associated with a software update to the vehicle system's OS; 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 OS partition 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, infrequently changing data, and safety-critical data. The second type of data may include at least one of adaptive data, frequently changing data, and non-safety-critical data. The first and second partitions may be logical partitions implemented through the configuration of the OS.

[0006] According to an exemplary embodiment, a non-transitory computer-readable recording medium may record instructions executable by a processor for causing the processor to perform a method of updating software in a vehicle system. The method may include: communicating with a source outside the vehicle system regarding information associated with a software update of the vehicle system's operating 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 operating system. The partition of the operating system 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, infrequently changing data, and safety-critical data. The second type of data may include at least one of adaptive data, frequently changing data, and non-safety-critical data. The first and second partitions may be logical partitions implemented through the configuration of the operating system.

[0007] Further solutions are described in part in the following description, and will become apparent in part from the description, or may be implemented by practicing the embodiments presented in this disclosure. Attached Figure Description

[0008] Hereinafter, the features, advantages and importance of preferred embodiments of the present disclosure will be described with reference to the accompanying drawings, in which the same reference numerals denote the same elements.

[0009] Figure 1 A block diagram illustrating an exemplary system configuration of one or more exemplary implementations.

[0010] Figure 2A A block diagram illustrating exemplary actions of one or more exemplary implementations.

[0011] Figure 2B A block diagram illustrating exemplary actions of one or more exemplary implementations.

[0012] Figure 2C A block diagram illustrating exemplary actions of one or more exemplary implementations.

[0013] Figure 2D A block diagram illustrating exemplary actions of one or more exemplary implementations.

[0014] Figure 2E A block diagram illustrating exemplary actions of one or more exemplary implementations.

[0015] Figure 2F A block diagram illustrating exemplary actions of one or more exemplary implementations.

[0016] Figure 3 A diagram showing exemplary constituent elements of a device that can be configured to implement more than one exemplary implementation. Detailed Implementation

[0017] The following detailed description of preferred embodiments is with reference to the accompanying drawings. The above disclosure provides examples and descriptions, but is not intended to be exhaustive, nor is it intended to limit implementations to the exact forms disclosed. Modifications and variations can be made based on the above disclosure, or can be obtained through implementation. Furthermore, one or more features or constituent elements of one embodiment can be incorporated into another embodiment (or one or more features of another embodiment) or combined with another embodiment (or one or more features of another embodiment). Moreover, it is understood that in the flowcharts and descriptions of the actions provided below, one or more actions may be omitted, one or more actions may be added, one or more actions may be performed simultaneously (at least partially), and the order of one or more actions may be changed.

[0018] Even if a specific combination of features is listed in the claims and / or disclosed in this specification, such combination is not intended to limit the disclosure of possible implementations. In fact, many features can be combined in ways not specifically listed in the claims and / or not specifically disclosed in this specification. Each dependent claim listed below may be directly dependent on only one claim, but the disclosure of possible implementations includes each dependent claim combined with all other claims in the set of claims.

[0019] Unless otherwise explicitly stated, elements, actions, or instructions used in this specification should not be construed as essential or necessary. Furthermore, when used in this specification, the articles “a” and “an” refer to more than one item and can be used interchangeably with “more than one.” When referring to only one item, the term “one” or similar terms is used. Additionally, when used in this specification, the terms “has,” “have,” “having,” “include,” “including,” or similar terms imply open-ended usage. Moreover, unless otherwise explicitly stated, the phrase “based on” means “at least partially based on.” Furthermore, expressions such as “[A] and / or [B],” “at least one of [A] and [B],” or “at least one of [A] or [B]” should be understood as referring to only A, only B, or including both A and B.

[0020] When configured to perform the implementation of multiple actions, the execution of multiple instructions, etc., the expression "at least one processor" should be understood as a single processor performing the implementation of multiple actions, etc., or each of a plurality of processors performing the implementation of at least some (but not necessarily all) of the multiple actions, etc.

[0021] Throughout this specification, references to "one embodiment," "implementation," "non-limiting preferred embodiment," or the like refer to a specific feature, structure, or characteristic described in connection with the illustrated embodiment that is included in at least one embodiment of the solution. Therefore, the phrases "in one embodiment," "in an embodiment," "in a non-limiting preferred embodiment," "in more than one exemplary embodiment," and the like throughout this specification may all refer to the same embodiment, but are not necessarily required to refer to the same embodiment.

[0022] Furthermore, the features, advantages, and characteristics described in this disclosure can be combined in any suitable manner in more than one exemplary embodiment. Those skilled in the art, in view of the description herein, will recognize that this disclosure can be implemented without any of the specific features or advantages of a particular embodiment. In other instances, further features and advantages that are not sometimes present in all embodiments of this disclosure may be recognized in certain specific embodiments.

[0023] Furthermore, the term "vehicle" as used in this specification refers to any suitable type of vehicle capable of implementing the exemplary embodiments of this disclosure. For example, "vehicle" can refer to a powered vehicle, such as a passenger car, truck, bus, motorcycle, or any other suitable type of automobile powered by an engine, motor, or other mechanical means. Alternatively or further, without departing from the scope of this disclosure, "vehicle" as used in this specification can refer to a bicycle, skateboard, and any other suitable type of unpowered vehicle.

[0024] Software updates ensure that the software system remains up-to-date through the latest technological advancements, safety-critical updates, and security patches. This, in turn, improves or optimizes the overall performance of the vehicle, thereby enhancing the user experience. Therefore, the installation or application of software updates in the vehicle's software system (e.g., vehicle OS, application stack, etc.) is of great importance.

[0025] In related technologies, updating automotive software systems requires installing the entire software update each time. This requires significant communication bandwidth to send the software update (or associated files) to the vehicle, a substantial amount of storage to hold the entire software update, and considerable time to apply the update. Furthermore, in related technologies, software updates cannot be interrupted. For example, if a software update is interrupted, it needs to be restarted from the beginning.

[0026] Furthermore, in related technologies, communication between the vehicle system and the source providing the software update is sometimes insecure. Specifically, communication before and during the software update acquisition is sometimes exposed to security risks (e.g., the vehicle system may sometimes communicate with untrusted sources, or the exchanged files / data may be tampered with). In addition, downloaded software updates are sometimes unreliable and / or incomplete.

[0027] Exemplary embodiments of this disclosure provide systems, methods, apparatuses, and the like that effectively reduce the time associated with sending software updates, reduce the storage required for storing software update data, and accelerate the application of software updates. Specifically, exemplary embodiments of this disclosure facilitate differential software updates to the OS in a vehicle system by partitioning the OS into multiple partitions and separating software updates into multiple parts. As a result, software updates to different partitions of the OS can be performed independently without the need for sending the entire software update, storing the entire update, and installing the entire software update. Since software updates can be performed by partitioning, only the associated portions of the software update need to be sent, stored, and applied.

[0028] Furthermore, exemplary embodiments of this disclosure provide systems, methods, apparatuses, and the like 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 a software update can be enhanced via security actions such as mutual authentication, password verification, and / or data encryption. In addition, the reliability and integrity of the downloaded software update can be verified before it is stored and applied to the vehicle system. As a result, exemplary embodiments can enhance the security of software update delivery, storage, and application.

[0029] It is assumed that the features, advantages, and importance of the exemplary embodiments described in this specification are only a part of this disclosure and are not intended to be exhaustive or to limit the scope of this disclosure. Further descriptions relating to the features, constituent elements, configurations, operations, and implementations of the exemplary embodiments of this disclosure will be provided below.

[0030] Exemplary system configuration

[0031] Figure 1 A block diagram illustrating an exemplary system configuration of one or more exemplary implementations. (e.g.) Figure 1 As shown, the vehicle system 100 can be implemented in a vehicle and can interact with the source 200 to communicate information associated with the software update 210.

[0032] The vehicle system may include an operating system (OS) 110. OS 110 may be partitioned 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 through the structure of OS 110. This allows software that does not comply with the partitioning mechanism or does not recognize the partitioning mechanism to still update OS 110.

[0033] In this respect, the logical partition described in this specification can refer to a virtual partition within system resources (e.g., memory, storage, etc.) created and managed by OS110. This logical partition can correspond to different functional roles and / or security levels within the system. The configuration of OS110 implementing logical partitions may include, for example, a file system structure (e.g., the types of files / data that can be stored in each partition, the organization of files / data within each partition, etc.), access control configuration (e.g., only core system applications can access the first partition 111, only specific types of software updates can modify the contents of the first partition 111, etc.), and similar configurations.

[0034] The first partition 111 can be configured in a central location within the vehicle hardware and can be configured to manage data of a first type. This first type of data may include data that does not require updating or is unlikely to require periodic updates, such as non-adaptive data, data that does not change frequently, and / or safety-critical data. As a non-limiting example, the first type of data may include math libraries, localization support data, help files, shared operating system components or security correction data closely associated with the hardware, and similar data. The first partition 111 can receive and accommodate safety-critical elements and / or non-adaptive elements (or associated data) for software updates and can operate via secure boot. In some exemplary implementations, the first partition 111 may also be referred to as the "base partition."

[0035] The second partition 112 can be configured in various locations within the vehicle hardware and can be configured to manage second-type data. This second-type data may include data that may require frequent updates or data that may require periodic updates, such as adaptive data, frequently changing data, and / or non-safety-critical data. As a non-limiting example, the second-type data may include infotainment application data, media metadata, and / or any other data associated with non-safety-related functions. According to exemplary implementations, the second partition 112 may include multiple sub-partitions sharing the same characteristics (e.g., non-safety-critical), which can operate in a distributed manner across different parts of the vehicle. In some exemplary implementations, the second partition 112 may also be referred to as an "application partition."

[0036] According to an exemplary implementation, the first partition 111 and the second partition 112 may each have a data partition (or may have a data partition associated with it). The data partition may include constituent data, correction data, and / or other non-user data. The first partition 111 and the second partition 112 may include executable code / libraries that, when executed (e.g., by a processor associated with the vehicle system 100, etc.), allow the first partition 111 and the second partition 112 to read and manage data in the associated data partition. In one exemplary implementation, the executable code may be designed to manage (e.g., update) the data without increasing security risks.

[0037] During operation, the first partition 111 and the second partition 112 can collaborate and work together. According to an exemplary implementation, the second partition 112 can extract functionality from the first partition 111 (e.g., applications in the second partition can access math libraries, etc., present in the first partition). At this point, the first partition 111 and the second partition 112 are logical partitions implemented through OS 110, thus preventing potential interoperability issues (that might arise in physical partitions). The dependency between the first partition 111 and the second partition 112 can be expressed in the metadata of the associated Continuous Integration and Continuous Delivery (CI / CD) system, and can be tested and implemented during installation and startup. In a portion of the exemplary implementation, the dependency between partitions can be included in a Software Bill of Materials (SBOM), which is an inherent structured list of vehicle-related software and associated materials.

[0038] The identification, differentiation, or definition of adaptive and non-adaptive data can be based on the analysis of past data (e.g., software previously installed on the same vehicle model), for example, by the vehicle manufacturer. According to an exemplary implementation, when software is installed in a vehicle (e.g., in an Electronic Control Unit (ECU), OS, etc.), an image of the installed software can be created, and the associated files can be hashed and the timestamp of the association recorded. Therefore, available updates (e.g., updates available to the ECU, OS, etc.) can be applied or installed sequentially in the image. After an update is applied, the associated files / data can be hashed again and compared with the originally installed software to identify and record the changed / updated files / data (e.g., the amount of change (delta)). After the applied update, it can be determined which files / data have not been changed so far, which files / data have been changed infrequently, and which files / data have been modified frequently. Such information can be used to identify or define adaptive and non-adaptive data.

[0039] Still refer to Figure 1Vehicle system 100 can interact with source 200 to communicate information related to software updates that can be used in or associated with OS 110. Source 200 may include, for example, equipment (e.g., servers) from vehicle manufacturers or original equipment manufacturers (OEMs) that can provide software updates related to core applications and safety-critical features, equipment (e.g., servers) from third-party service providers (e.g., providers of infotainment applications), equipment (e.g., servers) from authorized service centers, and similar equipment. Communication between vehicle system 100 and source 200 can be 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), and similar communications.

[0040] According to an exemplary implementation, source 200 may broadcast a beacon to notify associated vehicles of an available software update. In one exemplary implementation, the beacon may contain information indicating that the software update is available. In this case, when the beacon is detected, vehicle system 100 may communicate with source 200 (e.g., via the start of a handshake process) to obtain details of the available software update. Alternatively, the beacon may contain detailed information about the available software update, such as the type of software update (e.g., safety critical, optional, etc.), the file size and version number of the software update, partial information (e.g., which parts of the software update include adaptive / non-adaptive data, etc.), the target application to which the software update should be applied (e.g., ADAS application, navigation application, etc.), and similar information. In this case, when the beacon is detected, vehicle system 100 assesses whether an available software update is needed in OS 110, and then may initiate communication with source 200 if necessary.

[0041] Alternatively or further, vehicle system 100 may proactively query source 200 for software updates based on one or more predetermined conditions, such as time-based conditions, event-based conditions, system health-based conditions, and similar conditions. For example, vehicle system 100 may begin querying source 200 when: vehicle system 100 detects from a timer that a predetermined amount of time has elapsed since the previous software update; vehicle system 100 detects from navigation information that the vehicle has crossed a geographical boundary; vehicle system 100 detects from the system clock that Daylight Savings Time (DTS) has been implemented; vehicle system 100 detects from the fuel counter that the vehicle has made a specific number of refuelings; vehicle system 100 detects from the battery sensor that the vehicle battery has dropped to a specific level; vehicle system 100 detects from the odometer that the vehicle's mileage has exceeded a specific threshold; and similar conditions. According to an exemplary implementation, the conditions for triggering a software update query may include a list. The vehicle system 100 may periodically monitor the vehicle, and when one or more conditions in the list are detected, a query related to a software update may be initiated. According to an exemplary implementation, each software or application installed on the OS 110 may have dedicated trigger conditions (i.e., when different conditions are detected, the vehicle system 100 may initiate a query related to a different application for a software update).

[0042] When a query is sent to source 200, if vehicle system 100 receives a response indicating that the software update is unavailable, vehicle system 100 can reset the triggering conditions for establishing the association (e.g., it can reset a timer indicating the elapsed time since the last update, or reset a fuel counter, etc.). On the other hand, based on the determination that the software update is available, vehicle system 100 can communicate with source 200 to obtain the software update.

[0043] Before obtaining or downloading software updates from source 200, vehicle system 100 may initiate a handshake session with source 200, during which vehicle system 100 and source 200 may perform more than one action of mutual authentication and verification. According to an exemplary implementation, vehicle system 100 and source 200 mutually authenticate each other, ensuring that both are trusted, the data is authentic, and communication is secure. For example, vehicle system 100 may provide its authentication information (e.g., a digital certificate containing a public key or other authentication information) to source 200. Similarly, source 200 may provide its authentication information (e.g., a digital certificate containing a public key or other authentication information) to vehicle system 100. Therefore, vehicle system 100 and source 200 may verify each other's authentication information (e.g., by checking the certificate against a Certificate Authority that issued it, or by checking the certificate against a list of known certificates and using public-key encryption, etc.).

[0044] According to an exemplary implementation, in mutual authentication, vehicle system 100 can provide inherent vehicle identification information to source 200. The inherent identification information may include an inherent combination of a Vehicle Identification Number (VIN) and / or a Single Module Name (SBOM) and a hash used to establish the association. The SBOM and hash can be generated in vehicle system 100 when the authentication of some vehicle components (e.g., authentication of secure startup of multiple ECUs via a shortest path algorithm, etc.) is successful. Therefore, vehicle system 100 can provide inherent vehicle identification information regardless of the vehicle's geographical location or VIN format.

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

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

[0047] When mutual authentication is successful (or, in some embodiments, when password verification is successful), a secure communication channel can be established between vehicle system 100 and source 200. During this phase, vehicle system 100 and source 200 can securely communicate and exchange data. For example, vehicle system 100 can provide the source 200 with the current version of software installed therein, and source 200 can verify that the software update is available to vehicle system 100. In some exemplary embodiments, vehicle system 100 and source 200 can arbitrarily choose to encrypt data transmissions in the secure communication channel (e.g., via Advanced Encryption Standard (AES) encryption), thereby further enhancing the security of communication between vehicle system 100 and source 200.

[0048] According to an exemplary implementation, vehicle system 100 and source 200 synchronize the required information / data by exchanging lists of files through an action such as rsync. In this regard, the action of rsync described in this specification can refer to the action of synchronizing data between two systems (e.g., vehicle system 100 and source 200) by comparing files / data in the two systems and transferring only the different files or data. In a portion of the exemplary implementations, advanced data structures and algorithms can be utilized by vehicle system 100 and / or source 200 to efficiently manage large amounts of data during file / data synchronization. Non-limiting examples of advanced data structures include rolling hashes that can quickly identify changes between files / data, Bloom filters that can quickly determine the presence or absence of files / data, and Merkle trees that can efficiently identify differences in data at different levels (e.g., root level, branch level, etc.).

[0049] Once file exchange and synchronization are complete, vehicle system 100 can obtain software updates (or associated data) from source 200. According to an exemplary implementation, source 200 may broadcast the software update to vehicle system 100. Further or alternatively, vehicle system 100 may obtain the software update, for example, via direct download from a server associated with source 200, peer-to-peer (P2P) download from other vehicles or devices that have already obtained the required software update, download from a content delivery network (CDN), or a combination thereof. According to an exemplary implementation, the software update (or associated data) may include a signature that can be verified or authenticated by vehicle system 100. For example, in the case of P2P file sharing, the software update may be distributed (via torrent packetization, etc.) in the form of multiple pieces or torrent file chunks. In this case, various sub-file blocks or data packets within the seed file can be signed (using the public key of source 200, etc.), and vehicle system 100 can verify or authenticate the seed file blocks / data packets (using the public key of source 200 obtained in mutual authentication, etc.), thereby ensuring that the downloaded data has not been corrupted or tampered with.

[0050] According to an exemplary implementation, the application of a software update (which may also be referred to as "software installation" in this specification) can be separated into at least two parts, each of which can target a separate partition in OS110. For example, as Figure 1 As shown, software update 210 can be separated into a first part 211 and a second part 212. At this point, the first part 211 may include non-adaptive data, infrequently changing data, and / or security-critical data that can be installed or applied to the first partition 111 of OS 110, and the second part 212 may include adaptive data, frequently changing data, and / or non-security-critical data that can be installed or applied to the second partition 112 of OS 110. Further descriptions relating to examples and characteristics of the data have been given above with reference to the first partition 111 and the second partition 112; therefore, for the sake of brevity, lengthy descriptions relating to the examples and characteristics of the data may be omitted below.

[0051] According to an exemplary implementation, vehicle system 100 may not download the entire software update 210, but instead obtain only the required portion of the software update (e.g., first portion 211, second portion 212, etc.) from source 200. For example, vehicle system 100 may determine that a software update in second partition 112 is needed, and therefore may obtain only the second portion 212 of the software update from source 200.

[0052] When a software update is obtained from source 200, vehicle system 100 may store the obtained software update, for example, in a cache or non-volatile memory, so that vehicle system 100 can apply the software update in the associated partition at a later time. According to an exemplary implementation, vehicle system 100 may verify the integrity and reliability of the obtained software update before storing or applying it. For example, the software update may be signed by source 200, and 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 is provided by source 200 and is not altered during transmission. As another example, vehicle system 100 performs an integrity check by verifying the hash or checksum of the software update, thereby ensuring that the required parts of the software update are downloaded correctly, without missing or corrupted parts.

[0053] According to exemplary embodiments, the installation or application of software updates can be triggered automatically. For example, vehicle system 100 can set a timer so that when a software update (or a required portion thereof) is received, the software update can be automatically installed or applied after a certain amount of time has elapsed. As another example, vehicle system 100 can, for instance, build a schedule based on driver preferences or habits so that software updates can be installed or applied automatically when the vehicle is not in use. Further or alternatively, the installation or application of software updates can be manually triggered by the vehicle user (e.g., driver, passenger, etc.). For example, when preparations for the installation or application of a software update are complete, vehicle system 100 can notify the vehicle user, for instance, via the output of a notification related to the software update (e.g., the display of a notification in the infotainment system, etc.). Thus, vehicle system 100 can install or apply the software update when approval is received from the vehicle user. In some exemplary embodiments, the installation or application of software updates (e.g., downloading, installing, and checking update files, etc.) can be performed in the background while the vehicle is being operated or used. For example, when a software update (or its required components / data) is received, vehicle system 100 can determine whether the vehicle or vehicle system 100 has sufficient resources to install or apply at least a portion of the software update in the background without affecting vehicle performance (e.g., memory, computing power, etc.). Therefore, based on the determination that the vehicle / vehicle system 100 has sufficient resources to install or apply the software update in the background, vehicle system 100 can 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, vehicle system 100 can install or apply the software update at a later time (e.g., when the vehicle is not in use, or when the vehicle has sufficient resources to install or apply the software update in the background, etc.).

[0054] Assuming the above has been described in this specification Figure 1 The features constituting and establishing associations are merely examples of possible implementations, and the scope of this disclosure should not be limited to these examples. Specifically, without departing from the scope of this disclosure, the system may include more or fewer components than those described and / or may be configured in different ways. For example, in one exemplary implementation, the vehicle system 100 may communicate with multiple sources 200, which may include multiple software updates 210, a portion of which may be further subdivided into multiple sub-parts, and similar configurations.

[0055] According to an exemplary implementation, OS110 may include a third partition that is logically separate from other partitions of OS110 (and physically separate where applicable). This third partition may be configured to manage or store high-privacy data, such as user profile data, application logs, data collected by the vehicle (e.g., sensor data before and after ADAS deactivation for further analysis and continuous improvement), and similar data. This data may have special requirements from a privacy perspective; therefore, any software update should not access or modify the data in this third partition, but may only modify data in general data partitions. Furthermore, the data in this third partition should be easily erasable, and (where applicable) further security mechanisms should be applied. Therefore, managing this data in a logically separate (and physically separate where applicable) partition can facilitate deletion, thereby providing a further improvement in data security.

[0056] To this end, exemplary embodiments of this disclosure provide a system that efficiently facilitates differential software updates to an OS in a vehicle system. Specifically, the partitioning of the OS and the separation of software updates enable differential software updates to any partition of the OS. For example, software updates to different partitions of the OS can be performed independently without the need for sending, storing, and installing the entire software update. Instead, software updates can be performed by partition, thus requiring only the associated portion of the software update to be sent, stored, and applied. As a result, the system of the exemplary embodiments can effectively reduce the time associated with sending software updates, reduce the storage required for storing software update data, and accelerate the application of software updates.

[0057] 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 a software update can be enhanced via security actions such as mutual authentication, password verification, and / or data encryption. In addition, the reliability and integrity of the downloaded software update can be verified before it is stored and applied to the vehicle system. As a result, the systems of the exemplary embodiments can enhance the security of software update delivery, storage, and application.

[0058] Exemplary actions

[0059] As described above, various actions can be performed by the vehicle system 100 and the source 200 to facilitate differential software updates and improve the security of software updates. The following will refer to... Figures 2A to 2FSome exemplary actions of one or more exemplary embodiments are described. One or more actions (or data related to those actions) may be described in conjunction with the above references. Figure 1 Since the actions described are the same, the recorded actions / data (unless otherwise specified) can be applied in the same way. Figures 2A to 2F In the context of actions, it's understandable that lengthy descriptions linking actions / data to them can be omitted for the sake of brevity.

[0060] Although for illustrative purposes, actions are primarily described as those performed by vehicle system 100, it is understood that in actual implementations, source 200 may perform the same / related actions from the opposite side without departing from the scope of this disclosure. For example, actions by vehicle system 100 receiving data from source 200 may indicate or imply actions by source 200 sending data to vehicle system 100; actions by vehicle system 100 verifying source 200 may indicate or imply the same actions as those by source 200 verifying vehicle system 100, and similar actions.

[0061] According to an exemplary embodiment, the vehicle system 100 may include more than one hardware component (or may be implemented in such hardware component), and more than one action described below can be performed by more than one hardware component of the vehicle system 100. For example, the vehicle system 100 may include a processor and a memory (or any other suitable storage medium) (or may be implemented in such processor and memory), and the memory may include computer-executable instructions that, when executed by the processor, cause the processor to perform more than one action described in this specification.

[0062] Figure 2A A block diagram illustrating an exemplary method 300 that facilitates differential software updates, representing one or more exemplary implementations.

[0063] In action S310, vehicle system 100 (or the associated processor) can be configured to communicate with an external source (e.g., source 200) regarding information associated with software updates to the vehicle system's OS (e.g., OS 110). The following will refer to... Figure 2C and Figure 2D Exemplary actions for communicating information associated with software updates are described.

[0064] When communicating information related to a software update, in action S320, vehicle system 100 (or the associated processor) can be configured to retrieve the software update from a source as part of the process. The following will refer to... Figure 2BAn exemplary action for obtaining a part of a software update is described.

[0065] When a portion of a software update is received, in action S330, vehicle system 100 (or the associated processor) can be configured to apply the received portion of the software update to the OS partition. See above for reference. Figure 1 As described, the OS partitions 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-adaptable data, infrequently changing data, and security-critical data; conversely, the second type of data may include at least one of adaptive data, frequently changing data, and non-security-critical data. Furthermore, the first and second partitions may be logical partitions implemented through the OS configuration. The following will refer to... Figure 2F An exemplary action for obtaining a part of a software update is described.

[0066] Figure 2B A block diagram illustrating an exemplary method 400 for obtaining a portion of a software update from a source, representing one or more exemplary implementations. Figure 2B One or more actions can be Figure 2A It is part of the action S320.

[0067] like Figure 2B As shown, in action S410, vehicle system 100 (or the associated processor) can be configured to determine which partition of the OS (e.g., which of the first and second partitions) requires a software update.

[0068] Therefore, if the determination that the first OS-based partition requires a software update is made, method 400 can proceed to actions S420 and S430. If this is not the case, and the determination that the second OS-based partition requires a software update is made, method 400 can proceed to actions S440 and S450.

[0069] In action S420, vehicle system 100 (or the associated processor) can be configured to output a request for a portion (e.g., first portion 211) of a software update associated with data of the first type (managed via the first partition) to the source. Then, in action S430, vehicle system 100 (or the associated processor) can be configured to retrieve the requested portion of the software update from the source.

[0070] Similarly, in action S440, vehicle system 100 (or the associated processor) can be configured to output a request for a portion (e.g., second part 212) of a software update associated with second type of data (managed via the second partition) to the source. Then, in action S450, vehicle system 100 (or the associated processor) can be configured to retrieve the requested portion of the software update from the source.

[0071] Figure 2C and Figure 2D The diagrams illustrate exemplary methods for communicating information associated with software updates, representing one or more exemplary implementations. Figure 2C and Figure 2D One or more actions can be Figure 2A Part of action S310 in the process.

[0072] First, refer to Figure 2C , Figure 2C A block diagram illustrating an exemplary method 500 for passively acquiring information associated with software updates, representing one or more exemplary implementations.

[0073] In action S510, vehicle system 100 (or the associated processor) can be configured to receive from a source a beacon indicating that a software update is available. Therefore, in action S520, vehicle system 100 (or the associated processor) can be configured to determine whether a software update is associated with the OS (e.g., whether the software update or a portion thereof can be applied to partitions of the OS, etc.).

[0074] Based on the determination that the software update has not been associated with the OS, method 500 can end. Alternatively, method 500 can return to action S510 so that the vehicle system 100 (or the associated processor) can continuously (or repeatedly) execute method 500 for at least a specified period.

[0075] On the other hand, based on the determination of the association between the software update and the OS, method 500 can proceed to action S530, in which vehicle system 100 (or the processor establishing the association) can be configured to begin a handshake session with the source. The following will refer to... Figure 2E Exemplary actions for initiating a handshake session are documented.

[0076] When the handshake session is started normally, method 500 can proceed to action S540, in which vehicle system 100 (or the associated processor) can be configured to obtain information associated with the software update from the source.

[0077] Next, refer to Figure 2D , Figure 2D A block diagram illustrating an exemplary method 600 for proactively acquiring information associated with software updates, representing one or more exemplary implementations.

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

[0079] Based on the determination that the triggering condition is not met, method 600 can terminate. Alternatively, vehicle system 100 (or the associated processor) can continuously (or repeatedly) execute method 600 for at least a specified period.

[0080] On the other hand, based on the determination that the triggering condition is met, method 600 can proceed to action S620, in which vehicle system 100 (or the processor establishing the association) can be configured to begin a handshake session with the source. The following will refer to... Figure 2E Exemplary actions for initiating a handshake session are documented.

[0081] When the handshake session is started normally, method 600 can proceed to action S630, in which vehicle system 100 (or the associated processor) can be configured to obtain information associated with the software update from the source.

[0082] Figure 2E A block diagram illustrating an exemplary method 700 for initiating a handshake session, representing one or more exemplary implementations. Figure 2E One or more actions can be Figure 2C Action S530 or Figure 2D Part of the action S620.

[0083] In action S710, vehicle system 100 (or the processor establishing the association) can be configured to perform mutual authentication with the source. Therefore, method 700 can proceed to action S720, where vehicle system 100 (or the processor establishing the association) can determine whether the mutual authentication was successful. Based on the determination that the mutual authentication was unsuccessful, method 700 can proceed to action S730, where vehicle system 100 (or the processor establishing the association) can determine that the handshake session establishment failed.

[0084] On the other hand, based on the determination that mutual authentication is successful, method 700 can proceed to action S740, in which vehicle system 100 (or the processor that established the association) can determine that the handshake session has been established normally.

[0085] Alternatively, based on the determination that mutual authentication was successful, method 700 can proceed to action S750, in which vehicle system 100 (or the associated processor) can be configured to perform password authentication on the source. Therefore, in action S760, vehicle system 100 (or the associated processor) can determine whether the password authentication was successful or failed. Based on the determination that the password authentication was successful, method 700 can proceed to action S740, in which vehicle system 100 (or the associated processor) can determine that the handshake session was established normally. If this is not the case, based on the determination that the password authentication failed, method 700 can proceed to action S730, in which vehicle system 100 (or the associated processor) can determine that the handshake session establishment failed.

[0086] According to an exemplary implementation, when it is determined that a handshake session has been successfully established, the vehicle system 100 (or the associated processor) can be configured to encrypt data or messages sent by the vehicle system 100 to the source.

[0087] Figure 2F A block diagram illustrating an exemplary method 800 for updating application software, representing one or more exemplary implementations. Figure 2F One or more actions can be Figure 2A Part of the action S330 in the process.

[0088] In action S810, vehicle system 100 (or the associated processor) can be configured to verify the reliability of acquired software updates (e.g., a portion of the software update acquired in action S320). See above. Figure 1 As described, vehicle system 100 (or the associated processor) can use the source's public key to verify whether the obtained software update is genuine.

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

[0090] Subsequently, in action S830, vehicle system 100 (or the associated processor) can be configured to apply the acquired software update (e.g., a portion of the software update acquired in action S320 and stored in action S820) to the associated partition of the OS. According to an exemplary implementation, based on the verification that the acquired software update is genuine, vehicle system 100 (or the associated processor) can set a timer for applying the software update (e.g., start a timer, create a schedule, etc.). In this case, based on the determination that the set timer has been reached, vehicle system 100 (or the associated processor) can automatically apply the acquired software update to the associated partition of the OS. Alternatively, based on the verification that the acquired software update is genuine, vehicle system 100 (or the associated processor) can output a notification related to the software update and receive user approval for applying the software update, and then apply the acquired software update to the associated partition of the OS. According to an exemplary implementation, vehicle system 100 (or the associated processor) can be configured to apply software updates acquired in the background (e.g., a portion of the software updates acquired in action S320 and stored in action S820) while the vehicle is operating or being used. For example, vehicle system 100 (or the associated processor) can be configured to determine whether vehicle system 100 has sufficient resources to apply software updates acquired in the background while vehicle system 100 is operating or being used. Therefore, based on the determination that vehicle system 100 has sufficient resources to apply software updates acquired in the background, vehicle system 100 (or the associated processor) can be configured to apply the acquired software updates to the associated partition of the OS while the vehicle system is operating or being used.

[0091] On the other hand, based on the determination that the obtained software update is not genuine, method 800 can end, and the obtained software update will not be stored in the vehicle system or applied to the OS. Alternatively, method 800 can proceed to action S840, in which vehicle system 100 (or the associated processor) can create an error log (or event log) containing detailed information about the event (e.g., information about the rejected software update, the reason for the failure, source information, etc.). Then, in action S850, vehicle system 100 (or the associated processor) can notify the associated user (e.g., presenting an update failure notification to the driver via the infotainment system, sending the error log to the vehicle manufacturer, etc.). Furthermore, the error log information can be sent through the vehicle system to the user's dealership or service center to provide service and improvements to the user. Additionally, the vehicle system can send the error log information to the vehicle manufacturer or supplier for continuous improvement.

[0092] To this end, exemplary embodiments of this disclosure provide a method that efficiently facilitates differential software updates to an OS in a vehicle system. Specifically, the method includes actions that affect the partitioning of the OS and the separation of software updates, such as obtaining a portion of the software update, applying that portion of the software update to a partition of the OS, and similar actions. Therefore, the method of the exemplary embodiment can perform software updates to different partitions of the OS independently, without requiring the transmission, storage, and installation of the entire software update. Instead, software updates can be performed by partition, thus requiring only the associated portion of the software update to be transmitted, stored, and applied. As a result, the method of the exemplary embodiment can effectively reduce the time associated with transmitting software updates, reduce the storage required for storing software update data, and accelerate the application of software updates.

[0093] 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 can be enhanced via security actions such as mutual authentication, password verification, and / or data encryption. In addition, the reliability and integrity of the downloaded software update can be verified before it is stored and applied to the vehicle system. As a result, the methods of the exemplary embodiments can enhance the security of software update delivery, storage, and application.

[0094] Exemplary constituent elements

[0095] Figure 3 This diagram illustrates exemplary components of a device 900 in one or more exemplary embodiments. In some exemplary embodiments, the device 900 may be an in-vehicle device that implements the vehicle system 100 (or one or more operations associated with the vehicle system 100). Furthermore, the device 900 may also be equipment such as a server that implements the source 200 (or one or more operations associated with the source 200).

[0096] like Figure 3 As shown, 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.

[0097] Assuming that without departing from the scope of this disclosure, device 900 may include more than Figure 3The components shown may be more or less numerous. For example, in one embodiment, device 900 may include multiple storage components 904, input components 905 and output components 906 may be implemented as transceiver components, and memory 903 and storage components 904 may be implemented as storage memory and the like.

[0098] Bus 901 can be configured to facilitate or enable communication between the components of device 900. Specifically, bus 901 can communicatively connect the components and provide means for the transmission and streaming of data for control signals between the components. Bus 901 may include one or more of the following buses that can be implemented in device 900 to enable real-time (or near-real-time) communication and cooperation between the 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.

[0099] Processor 902 can be implemented in hardware, firmware, or a combination of hardware and software, and can be configured to perform real-time (or near-real-time) data processing and control of control device 900. Processor 902 may include one or more of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), Neural Processing Unit (NPU), Tensor Processing Unit (TPU), Accelerated Processing Unit (APU), microprocessor, microcontroller, Digital Signal Processor (DSP), Field-Programmable Gate Array (FPGA), Application-Specific Integrated Circuit (ASIC), and / or other types of processing or computing components that can be implemented in device 900. In some implementations, processor 902 may be programmed to perform more than one action described in this specification. Furthermore, processor 902 may include multiple processing units, each dedicated to performing a specific action.

[0100] Memory 903 may include one or more media for storing temporary data, runtime variables, program instructions, and buffers required for the operation of 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 processor 902: flash memory, read-only memory (ROM), random-access memory (RAM), dynamic or static storage devices (e.g., flash memory, magnetic storage, and / or optical storage), or any other suitable type of memory.

[0101] Storage component 904 can be configured to store non-volatile data, such as firmware, configuration settings, calibration data, information, and / or software associated with the operation and use of device 900. For example, storage component 904 may include hard disks (e.g., magnetic disks, optical disks, magneto-optical disks, and / or solid-state drives), compact optical disks (CDs), digital versatile optical disks (DVDs), floppy disks, cartridges, magnetic tapes, and / or other types of non-transitory computer-readable media, and include corresponding drives.

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

[0103] Input element 905 may include one or more input elements (e.g., touchscreen display, keyboard, keypad, mouse, button, switch, and / or microphone) that enable device 900 to receive information via user input. Output element 906 may include one or more output elements (e.g., display, speaker, navigation device, one or more light-emitting diodes (LEDs)). According to embodiments, input element 905 and / or output element 906 may be arbitrarily selected and may be removed from device 900. According to exemplary embodiments, input element 905 and / or output element 906 may be arbitrarily selected.

[0104] At least one communication interface 907 may include a transceiver (e.g., a transceiver and / or a separate receiver and transceiver) that enables the device 900 to communicate with other components (e.g., an ECU, user equipment, etc.) via a wired connection, a wireless connection, or a combination of wired and wireless connections. For example, the 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 a similar interface.

[0105] 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 memory interface, or a similar interface that enables the components 902-906 to communicate with other components. Furthermore, the communication interface 907 may include one or more application programming interfaces (APIs) that enable the device 900 (or one or more components included in the device 900) to communicate with one or more software applications (e.g., software applications deployed in an ECU).

[0106] Computer-executable instructions (e.g., software instructions, etc.) may be read into memory 903 and / or memory component 904 via communication interface 907 from other computer-readable media or from other devices (e.g., remote servers, external storage, etc.). When executed, the computer-executable instructions stored in memory 903 and / or memory component 904 may cause processor 902 to execute one or more processes described herein. Further or alternatively, hard-wired circuitry may be used in place of or in combination with software instructions to execute one or more processes described herein. Therefore, the implementation schemes described herein are not limited to any specific combination of hardware circuitry and software.

[0107] Various implementation schemes

[0108] Assuming the above reference Figures 1-3 The features, advantages, and significance of the exemplary embodiments described in this specification are only part of this disclosure and are not intended to be exhaustive or to limit the scope of this disclosure. Further descriptions of the features, constituent elements, configurations, operations, and implementations of exemplary embodiments of this disclosure, along with their associated technical advantages and significance, will be provided below.

[0109] It is understood that the specific order or hierarchy of function blocks in the process / flowcharts disclosed in this specification is an example of exemplary methods. It is understood that the specific order or hierarchy of function blocks in the process / flowcharts can be reconfigured based on design preferences. Furthermore, some function blocks can be combined or omitted. The appended method claims present the elements of various function blocks in a sample order and are not intended to limit the specific order or hierarchy presented.

[0110] A portion of the implementation may involve systems, methods, and / or computer-readable media at a detailed level of any possible integrated technology. Furthermore, as described above in this specification, one or more of the aforementioned constituent elements 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-transitory storage medium (or media(s)) having computer-readable program instructions for causing a processor (or processor(s)) to perform actions.

[0111] A computer-readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium can be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof, but is not limited thereto. A non-exhaustive list of more specific examples related to 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 disc read-only memory (CD-ROM), digital versatile optical disc (DVD), memory sticks, floppy disks, punched cards containing instructions, or devices with mechanically encoded structures in slots, and any suitable combinations thereof. As used in this specification, computer-readable storage media should not be construed as temporary signals 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.

[0112] The computer-readable program instructions described in this specification can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded to external computers or external storage devices via networks such as the Internet, local area networks, wide area networks, and / or wireless networks. The network may include copper cables, optical fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. Network adapter cards or network interfaces within each computing / processing device receive and transmit the computer-readable program instructions from the network for storage on the computer-readable storage media within the respective computing / processing device.

[0113] Computer-readable program code / instructions that perform actions can be any of the following: assembly instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages. These programming languages ​​include object-oriented programming languages ​​such as Smalltalk, C++, or similar languages, as well as procedural programming languages ​​such as "C" or similar languages. Computer-readable program instructions can execute entirely on the user's computer, partially on the user's computer, as a standalone software package, 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 can connect to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or (for example, via the internet using an internet service provider) connect to an external computer. In some implementations, for example, electronic circuits including programmable logic circuits, field-programmable gate arrays (FPGAs) or programmable logic arrays (PLAs) can be personalized to execute computer-readable program instructions by utilizing state information of computer-readable program instructions to perform schemes or actions.

[0114] The computer-readable program instructions can be provided to a processor of a SoC (System on Chip), a general-purpose computer, a special-purpose computer, or other programmable data processing device to generate a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing device, create parts that implement the functions / behaviors specified in the flowcharts and / or block diagrams, or in the function blocks(s). The computer-readable program instructions can also be stored in a computer-readable storage medium that can instruct a computer, programmable data processing device, and / or other device to function in a particular manner, such that the computer-readable storage medium containing the instructions has an article of manufacture comprising instructions for implementing the functions / behaviors specified in the function blocks of the flowcharts and / or block diagrams, or in the function blocks(s).

[0115] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus or other device, and perform a series of action steps on the computer, other programmable apparatus or other device to generate a computer-implemented process, the result of which the instructions executed on the computer, other programmable apparatus or other device implement the functions / behaviors specified in the function blocks of the flowchart and / or block diagram or in the function blocks(multiple).

[0116] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and action of various implementations of systems, methods, and computer-readable media. In this respect, each functional block in a flowchart or block diagram may represent a module, segment, or portion of instructions having one or more executable instructions that implement the specified logical function. Methods, computer systems, and computer-readable media may include additional functional blocks, fewer functional blocks, different functional blocks, or functional blocks configured differently compared to those depicted in the figures. In some alternative implementations, the functions described in the functional blocks may occur independently of the order shown in the figures. For example, two consecutively shown functional blocks may be executed practically or substantially simultaneously, or functional blocks may sometimes be executed in reverse order according to their related functions. It should also be noted that the functional blocks of the block diagrams and / or flowcharts, and combinations of functional blocks in the block diagrams and / or flowcharts, can be implemented by a system based on dedicated hardware that performs the specified functions or actions or executes a combination of dedicated hardware and computer instructions.

[0117] It is evident that the systems and / or methods described in this specification can be implemented in various forms, including hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement the system and / or method is not a limitation on the implementation. Therefore, it is understood that the operation and behavior of the system and / or method are not described in this specification with reference to specific software code, and software and hardware can be designed to implement the system and / or method based on the description in this specification.

[0118] Alternatively, the computer program product including the computer program of the above embodiments may be stored in a storage medium or distributed through a communication line.

Claims

1. A method for updating software in a vehicle system, wherein, The method includes: The processor communicates with external sources of the vehicle system regarding information associated with software updates to the vehicle system's operating system (OS). A portion of the software update is obtained from the source via the processor; and The processor applies a portion of the software update obtained to the OS partition. The OS partition has 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 possesses at least one of the following characteristics: non-adaptable data, infrequently changing data, and security-critical data. The second type of data possesses at least one of the following characteristics: adaptive data, frequently changing data, and non-security-critical data. The first partition and the second partition are logical partitions implemented through the configuration of the OS.

2. The method according to claim 1, wherein, The acquisition of the portion of the software update includes: 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 for a portion of the software update associated with the first type of data to the source; Based on the determination that the second partition requires the software update, the processor outputs a request for a portion of the software update associated with the second type of data to the source; and The processor retrieves a portion of the request for the software update from the source.

3. The method according to claim 1 or 2, wherein, The communication of the information associated with the software update includes: The processor receives from the source a beacon indicating that the software has been updated to be usable; The processor determines whether the software update is associated with the OS. Based on the determination that the software update is associated with the OS, a handshake session with the source is initiated through the processor; and Based on the determination that the handshake session has started normally, the processor obtains information from the source that is associated with the software update.

4. The method according to any one of claims 1 to 3, wherein, The communication of the information associated with the software update includes: The processor determines whether the triggering conditions for querying software updates are met. Based on the determination that the triggering condition is met, the processor initiates a handshake session with the source; and Based on the determination that the handshake session has started normally, the processor obtains information from the source that is associated with the software update.

5. The method according to claim 3 or 4, wherein, The start of the handshake session includes: Mutual authentication with the source is performed through the processor; and Based on the confirmation that the mutual authentication was successful, the processor performs cryptographic verification on the source.

6. The method according to claim 4, wherein, The triggering condition includes at least one of the following: time-based condition, event-based condition, and system health-based condition.

7. The method according to any one of claims 1 to 6, wherein, The method further includes: using the processor to verify the reliability of a portion of the software update obtained based on the public key of the source.

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

9. The method according to claim 7 or 8, wherein, The application acquired in the software update includes: Based on the verification that a portion of the software update obtained is genuine, the processor sets the timing for applying this portion of the software update; and Based on the predetermined time interval, the processor applies a portion of the software update obtained to the partition of the OS.

10. The method according to any one of claims 7 to 9, wherein, The application that is acquired in the software update includes: Based on the verification that a portion of the software update obtained is genuine, the processor outputs a notification related to the software update. The processor receives user approval for the software update; and The processor applies a portion of the obtained software update to the partition of the OS.

11. The method according to any one of claims 1 to 10, wherein, The application that is acquired in the software update includes: The processor determines whether the vehicle system has sufficient resources to apply a portion of the acquired software update in the background while the vehicle system is operating; and 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 partition of the OS while the vehicle system is operating.

12. An apparatus for updating software in a vehicle system, wherein, The device includes: Storage memory, which stores computer-executable instructions; and The processor is communicatively connected to the storage device. The processor is configured to execute the instructions to perform the following actions: The system communicates with external sources of the vehicle system regarding information associated with software updates to the vehicle system's operating system (OS). A portion of the software update is obtained from the source; as well as The obtained portion of the software update is applied to the partition of the OS. The OS partition has 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 possesses at least one of the following characteristics: non-adaptable data, infrequently changing data, and security-critical data. The second type of data possesses at least one of the following characteristics: adaptive data, frequently changing data, and non-security-critical data. The first partition and the second partition are logical partitions implemented through the configuration of the OS.

13. The device according to claim 12, wherein, The processor is configured to acquire the portion of the software update by performing the following actions: 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; as well as The processor retrieves a portion of the request for the software update from the source.

14. The device according to claim 12 or 13, wherein, The processor is configured to communicate the information associated with the software update by: Receive from the source a beacon indicating that the software has been updated to be usable; Determine whether the software update is associated with the OS; Based on the determination that the software update is associated with the OS, a handshake session with the source is initiated; as well as Based on the confirmation that the handshake session has started normally, information associated with the software update is obtained from the source.

15. The device according to any one of claims 12 to 14, wherein, The processor is configured to communicate the information associated with the software update by: Determine whether the triggering conditions for querying software updates are met; Based on the determination that the triggering condition is met, a handshake session with the source is initiated; as well as Based on the confirmation that the handshake session has started normally, information associated with the software update is obtained from the source.

16. The device according to claim 14, wherein, The processor is configured to initiate the handshake session by performing the following actions: Perform mutual authentication with the source; and Based on the confirmation that the mutual authentication was successful, the source is then subjected to password verification.

17. The device according to claim 15, wherein, The triggering condition includes at least one of the following: time-based condition, event-based condition, and system health-based condition.

18. The device according to any one of claims 12 to 17, wherein, The processor is also configured to verify the reliability of a portion of the software update obtained based on the public key of the source.

19. The device according to claim 18, wherein, The processor is also configured to: Based on the verification that a portion of the software update obtained is genuine, the portion of the software update obtained is stored in the cache for at least a specified period of time.

20. A computer program product comprising a computer program for causing a processor to execute a method for updating software in a vehicle system, wherein, The method includes: The processor communicates with external sources of the vehicle system regarding information associated with software updates to the vehicle system's operating system (OS). A portion of the software update is obtained from the source via the processor; and The processor applies a portion of the software update obtained to the OS partition. The OS partition has 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 possesses at least one of the following characteristics: non-adaptable data, infrequently changing data, and security-critical data. The second type of data possesses at least one of the following characteristics: adaptive data, frequently changing data, and non-security-critical data. The first partition and the second partition are logical partitions implemented through the configuration of the OS.

Images