System and method for managing device update in vehicle system, and computer program

Abstract

To provide a method in a vehicle system.SOLUTION: Provided are a method, a system and a device for managing one or more updates for one or more devices in a vehicle system. According to embodiments, the method may be implemented by at least one processor of a system and may include: obtaining information associated with the update; generating a message including information of the update; and configuring deployment of the update. The update comprises one of a temporary update and a non-temporary update.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] Systems and methods consistent with example embodiments of the present disclosure relate to vehicle systems, and more particularly, to managing one or more updates for one or more devices in one or more vehicle systems. [Background technology]

[0002] Modern vehicles include a diverse range of devices that form interconnected vehicle systems. These devices include, but are not limited to, electronic control units (ECUs), infotainment systems, sensors, actuators, telematics units, and communication modules. These devices interact to provide essential functions such as propulsion, safety, entertainment, connectivity, advanced driver assistance, and the like. Regular and timely software and firmware updates for vehicle system devices are important to ensure optimal performance, safety, and user experience, as well as to maintain functionality, safety, and compatibility with other systems. However, with the development of vehicle technology and the introduction of complex features, managing device updates has become increasingly complex and cumbersome.

[0003] One of the major factors that creates difficulties in handling device updates is the continuous evolution in vehicle functionality, which results in a continuous and significant increase in the number and variety of devices in vehicle systems, ranging from traditional functions such as in-vehicle infotainment systems to new advanced functions such as Internet of Things (IoT) functions (e.g., Vehicle-to-Everything (V2X)).

[0004] Furthermore, advances in software technologies such as virtualization and containerization have revolutionized device deployment and management in the automotive industry, enabling various devices in vehicle systems (e.g., electronic control units (ECUs)) to be deployed in software form. As a result, the number of software components in vehicle systems continues to increase significantly. The ever-increasing number of software components in vehicle systems exacerbates the challenge of managing updates, making it a time-consuming and error-prone process.

[0005] In this regard, systems and methods for handling device updates in vehicle systems in the related art are inadequate to effectively address the complexities and challenges for at least the following reasons:

[0006] First, related art systems lack a centralized approach to handling device updates. For example, in conventional vehicle systems, device updates are typically performed individually and require manual intervention for each device (e.g., a user must send the vehicle and / or associated devices to the vehicle manufacturer for updates, a technician must physically visit the device and perform the updates there, etc.). This approach is time-consuming, error-prone, and inefficient, especially in scenarios where multiple devices in a vehicle system require simultaneous updates.

[0007] Furthermore, related art systems often lack a standardized and streamlined update process. Each device may have its own unique update mechanism and require separate tools, procedures, and protocols. This fragmentation in the update process leads to inconsistencies, compatibility issues, and challenges in coordinating updates across different devices in a vehicle system.

[0008] Furthermore, systems in the related art fail to provide efficient and effective collaboration among users when managing device updates. Specifically, complex functionality in vehicle-related systems often involves multiple users and stakeholders, and therefore, managing device updates in a coordinated manner across various users can be difficult, especially when different users have different preferences, requirements, or usage patterns. Ensuring that all users have access to the latest updates and that the updates do not interfere with each other's workflows or preferences presents significant challenges. Thus, the process of updating a device, such as updates related to the device's operating system (OS) or firmware, can be complicated, especially when the updates (e.g., update OS, update firmware, etc.) are provided by a user / party different from the user managing the device.

[0009] In addition, systems in the related art cannot effectively handle different types of updates. In particular, temporary updates, which are often required for specific operations or scenarios, can be particularly difficult to manage. For example, whenever an update or change to a device is temporarily required, the update / change may be made to a root software file (e.g., a root OS image file). Therefore, the root system image file may drift from a known point, and restoring the image file to its original state after the temporary update is no longer required can be time-consuming and complicated.

[0010] In view of at least the above, there is a need to provide improved systems, methods, devices, and the like for managing device updates in vehicle systems. Summary of the Invention

[0011] SUMMARY OF THE INVENTION Exemplary embodiments consistent with the present disclosure provide methods, systems, and apparatus for effectively and efficiently managing one or more updates for one or more devices in one or more vehicle systems.

[0012] According to an embodiment, a method for managing updates to devices in a vehicle system is provided. The method may be implemented by at least one processor of the system and may include obtaining information associated with an update, generating a message including information of the update, and configuring a deployment of the update, where the update may include one of a transient update and a non-transient update. The software files may include operating system (OS) files.

[0013] According to an embodiment, obtaining information associated with the update may include obtaining information from at least one of a user equipment, a build system, and a database. Further, configuring deployment of the update may include providing a message to the device via over-the-air (OTA) communication, causing the device to configure deployment of the update based on the message.

[0014] According to an embodiment, the device may include a remote device located at a different geographic location than the system. Further, the update may be created by a first user located at a first geographic location. Information associated with the update may be obtained from a second user located at a second geographic location, and the first geographic location may be different from the second geographic location.

[0015] According to an embodiment, the update may include a temporary update to a software file on a device. The device may include a lower layer that includes the software file, and configuration for deploying the update may include providing a message to the device to cause the device to retrieve the update software file from a database, create an upper layer that includes software files based on the lower layer and the software files included in the lower layer, replace the software file in the upper layer with the update software file, and remove the update software file in the upper layer after a period of time.

[0016] According to an embodiment, the update may include a non-transient update to a software file on a device, and the device may include a first partition and a second partition. The first partition and the second partition may include the software file, and the configuration for deploying the update may include providing a message to the device to cause the device to retrieve the update software file from a database, replace the software file in one of the first partition and the second partition with the update software file, configure the partition with the update software file as a primary partition, and reboot the device to run the update software file as the primary software.

[0017] According to an embodiment, a system for managing updates to devices in a vehicle system is provided. The system may include a memory storage that stores computer-executable instructions and at least one processor communicatively coupled to the memory storage, where the at least one processor may be configured to execute the instructions to obtain information associated with an update, generate a message including information about the update, and configure deployment of the update, where the update may include one of a transient update and a non-transient update. The software files may include operating system (OS) files.

[0018] According to an embodiment, the at least one processor may be configured to execute instructions to obtain information associated with the update by obtaining the information from at least one of a user equipment, a build system, and a database. Further, the at least one processor may be configured to execute instructions to configure deployment of the update by providing a message to the device via over-the-air (OTA) communication and causing the device to configure deployment of the update based on the message.

[0019] According to an embodiment, the device may include a remote device located at a different geographic location than the system. Further, the update may be created by a first user located at a first geographic location. Information associated with the update may be obtained from a second user located at a second geographic location, and the first geographic location may be different from the second geographic location.

[0020] According to an embodiment, the update may include a temporary update to a software file on a device, and the device may include a lower layer that includes the software file, and at least one processor may be configured to execute instructions to configure deployment of the update by providing a message to the device to cause the device to retrieve the update software file from a database, create an upper layer that includes software files based on the lower layer and the software files included in the lower layer, replace the software file in the upper layer with the update software file, and remove the update software file in the upper layer after a period of time.

[0021] According to an embodiment, the update may include a non-transient update to a software file on a device, the device may include a first partition and a second partition, the first partition and the second partition may include a software file, and at least one processor may be configured to configure deployment of the update by executing instructions to provide a message to the device to cause the device to retrieve the update software file from a database, replace the software file in one of the first partition and the second partition with the update software file, configure the partition having the update software file as a primary partition, and reboot the device to run the update software file as the primary software.

[0022] According to an embodiment, a non-transitory computer-readable storage medium may be provided. The non-transitory computer-readable storage medium may have instructions executable by at least one processor of the system to cause the processor to perform a method of managing updates to devices in a vehicle system, the method including obtaining information associated with the update, generating a message including information of the update, and configuring a deployment of the update. The update may include one of a transient update and a non-transitory update.

[0023] According to an embodiment, a non-transitory computer-readable medium may have stored thereon instructions executable by at least one processor to perform the method, and obtaining information associated with the update may include obtaining information from at least one of a user equipment, a build system, and a database. Further, the non-transitory computer-readable medium may have stored thereon instructions executable by at least one processor to perform the method, and configuring deployment of the update may include providing a message to the device via over-the-air (OTA) communication and causing the device to configure deployment of the update based on the message. Further, the non-transitory computer-readable medium may have stored thereon instructions executable by at least one processor to perform the method, and the device may include a remote device located in a different geographic location than the system.

[0024] Additional aspects will be set forth in part in the description that follows, and in part will be apparent from the description, or may be learned by practice of presented embodiments of the present disclosure. [Brief explanation of the drawings]

[0025] The features, advantages, and importance of preferred embodiments of the present disclosure will now be described with reference to the accompanying drawings, in which like reference numerals refer to like elements. [Figure 1]FIG. 1 illustrates a block diagram of an exemplary system architecture for managing one or more updates for one or more devices in a vehicle system, according to one or more embodiments. [Figure 2] FIG. 2 illustrates a block diagram of example components of a device management system according to one or more embodiments. [Figure 3] FIG. 3 illustrates a flow diagram of an exemplary method for managing one or more updates for one or more devices in a vehicle system, according to one or more embodiments. [Figure 4] FIG. 4 illustrates a block diagram of an exemplary system configuration for providing update delivery, according to one or more embodiments. [Figure 5A] FIG. 5A illustrates a block diagram of a first configuration of an exemplary use case for deploying a device update, according to one or more embodiments. [Figure 5B] FIG. 5B illustrates a block diagram of a second configuration of an exemplary use case for deploying a device update, according to one or more embodiments. [Figure 6] FIG. 6 illustrates a block diagram of an exemplary use case configuration for deploying temporary device updates, according to one or more embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0026] The following detailed description of preferred embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of 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, it is understood that one or more operations may be omitted, one or more operations may be added, one or more operations may occur (at least partially) concurrently, and the order of one or more operations may be swapped.

[0027] Although a particular combination of features is recited in a claim and / or disclosed herein, such combination is not intended to limit the disclosure of possible implementations. Indeed, many of the features may be combined in ways not specifically recited in the claims and / or disclosed herein. Although each dependent claim listed below may depend directly on only one claim, the disclosure of possible implementations includes each dependent claim in combination with all other claims in the claim set.

[0028] No element, act, or instruction used herein should be construed as critical or required unless expressly stated otherwise. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." Where only one item is intended, the term "a" or similar terms are used. Also, as used herein, the terms "has," "have," "having," "include," "including," and the like are intended to be open-ended terms. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless expressly stated otherwise. Furthermore, phrases such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include A only, B only, or both A and B.

[0029] References throughout this specification to "one embodiment," "an embodiment," "a non-limiting preferred embodiment," or similar terms mean that the particular features, structures, or characteristics described in connection with the illustrated embodiment are included in at least one embodiment of the solution. Thus, the phrases "in one embodiment," "in an embodiment," "a non-limiting preferred embodiment," and similar terms throughout this specification may, but do not necessarily, all refer to the same embodiment.

[0030] Furthermore, the described features, advantages, and characteristics of the present disclosure may be combined in any suitable manner in one or more embodiments. Those skilled in the art will recognize, in light of the description herein, that the present disclosure may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present disclosure.

[0031] Additionally, as used herein, the term "vehicle" or the like may refer to any motorized and / or mechanical machine capable of carrying or transporting people and / or cargo, such as cars, trucks, motorcycles, buses, bicycles, mobility scooters, and the like.

[0032] SUMMARY OF THE INVENTION Exemplary embodiments consistent with the present disclosure provide methods, systems, and apparatus for managing one or more updates for one or more devices in one or more vehicle systems.

[0033] In particular, the illustrative embodiments provide a device management system (and a method for utilizing the device management system) that can provide centralized management of device updates in a vehicle system, such that devices in the vehicle system, such as remote devices, can be effectively and efficiently updated without manual intervention or physical on-site visits.

[0034] Additionally, the device management system of example embodiments may provide a standardized and streamlined update process, thereby ensuring consistency and compatibility of device updates across different devices in a vehicle system. Additionally, the device management system of example embodiments may receive input from multiple users and manage device updates based on the user input, thereby providing efficient and effective collaboration among users in managing device updates. Furthermore, the device management system of example embodiments may provide efficient and effective updates for different types of updates, ensuring modifiable updates.

[0035] Ultimately, exemplary embodiments of the present disclosure enable efficient and effective management of updates for a significant number of devices, thereby resolving problems in related art systems such as those discussed above.

[0036] It is assumed that the features, advantages, and significance of the exemplary embodiments described herein above are merely part of the present disclosure and are not intended to be exhaustive or to limit the scope of the present disclosure. A further description of the features, components, configuration, operation, and implementation aspects of the exemplary embodiments of the present disclosure, as well as associated technical advantages and significance, is provided below.

[0037] 1 illustrates a block diagram of an exemplary system architecture 100 for managing one or more updates for one or more devices in a vehicle system, according to one or more embodiments. As shown in FIG. 1, system architecture 100 may include a device management system 110, a plurality of user equipments (UEs) 120-1 through 120-N, a plurality of devices 130-1, a database 140, and a network 150.

[0038] Generally, device management system 110 may be communicatively coupled to a plurality of UEs 120-1 through 120-N and database 140 via network 150 and may be configured to interoperate with the UEs and database to manage one or more updates for a plurality of devices 130-1 through 130-N. Components that may be included in device management system 110 are described below with reference to FIG. 2, and operations that may be performed by device management system 110 are described below with reference to FIG. 3.

[0039] The plurality of UEs 120-1 through 120-N may include one or more systems, devices, and any other suitable equipment that may be utilized by one or more users associated with one or more of devices 130-1 through 130-N. The one or more users may include, but are not limited to, a software developer developing software / firmware associated with one or more of devices 130-1 through 130-N, an administrator of one or more of devices 130-1 through 130-N, a vehicle manufacturer / device vendor of one or more of devices 130-1 through 130-N, a driver / user of one or more of devices 130-1 through 130-N, and the like. The one or more users may be located in different geographic locations.

[0040] Multiple UEs 130-1 through 130-N may be utilized by one or more associated users to access and utilize the device management system 110. Specifically, a user may access the device management system 110 via an associated UE to manage one or more device updates. For example, a user may utilize the device management system 110 via an associated UE to search for one or more available device updates, to schedule one or more device updates, to configure one or more device updates, to perform deployment of one or more device updates, to publish one or more device updates, and the like. Furthermore, a user may also utilize the device management system 110 to obtain (e.g., view, download, etc.) information associated with one or more device updates (e.g., the contents of the device update, the type of device update, the creator of the device update, etc.).

[0041] According to one or more exemplary embodiments, one or more of the plurality of UEs 120-1 through 120-N may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile device (e.g., a smartphone, etc.), a wearable device (e.g., a pair of smart glasses or a smart watch), a SIM-based device, or any other suitable device that may be associated with one or more users. Further, the plurality of UEs 120-1 through 120-N may include, for example, a workstation, a test system, a software development system, and the like.

[0042] According to one or more exemplary embodiments, at least some of the plurality of UEs 120-1 through 120-N may be located at different geographic locations. For example, a first portion of the plurality of UEs 120-1 through 120-N may be utilized by a first user (e.g., a developer of software updates for a first device, etc.), and the first user and associated UEs may be located at a first location, while a second portion of the plurality of UEs 120-1 through 120-N may be utilized by a second user (e.g., an administrator of the first device, etc.), and the second user and associated UEs may be located at a second location different from the first location.

[0043] According to one or more exemplary embodiments, devices 130-1 through 130-N may include one or more remote devices associated with a vehicle system. In this regard, a remote device as described herein may refer to electronic components, subsystems, and / or modules that are interconnected (e.g., via network 150) and capable of communicating with one or more systems (e.g., device management system 110) and one or more pieces of equipment (e.g., UEs 120-1 through 120-N, database 140, etc.). -Devices associated with control units in vehicles, such as Electronic Control Units (ECUs), Transmission Control Units (TCUs), Body Control Module (BCM) units, and the like; -Vehicle infotainment systems and functional devices such as audio / visual entertainment systems, navigation systems, connectivity features, user interfaces, and the like; -Telematics devices, such as components responsible for vehicle communication and remote monitoring, enabling services such as remote diagnostics, vehicle tracking, and emergency assistance. -Sensor devices, such as devices that collect data from various sensors, such as those related to ADAS (Advanced Driver Assistance Systems) or environmental monitoring may include, but is not limited to:

[0044] Additionally or alternatively, devices 130-1 through 130-N may include other types of devices within a vehicle system that require update management, each of which may be embedded or configured with software or firmware that, when executed by the device, performs one or more associated operations.

[0045] Additionally, one or more of devices 130-1 through 130-N may be one or more remote devices that may be located in a different geographic location than device management system 110, one or more of plurality of UEs 120-1 through 120-N, and / or database 140. The remote devices may be interconnected with device management system 110, database 140, and / or plurality of UEs 120-1 through 120-N via network 150, and software / firmware associated therewith may be remotely updated by device management system 110 via utilization of over-the-air (OTA) update capabilities. Similarly, at least some of devices 130-1 through 130-N may be located in a different geographic location than another portion of devices 130-1 through 130-N.

[0046] 1 , database 140 may include a server, repository, or any suitable device that may be configured to store data or information associated with device updates. According to an embodiment, database 140 may leverage the indexing and querying capabilities of a database (e.g., PostgreSQL, etc.) in storing and serving device updates. Thus, database 140 may efficiently manage and search device updates (and / or data and information associated therewith) based on various criteria, such as device model, software version, schedule, planned release date, device location, and the like.

[0047] Network 150 may include one or more wired and / or wireless networks configured to connect device management system 110, multiple UEs 120-1 to 120-N, multiple devices 120-1 to 120-N, and database 140 to one another.

[0048] For example, network 150 may include a cellular network (e.g., a fifth generation (5G) network, a long term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., a public switched telephone network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, an optical fiber-based network, or the like, and / or a combination of these or other types of networks.

[0049] According to one or more example embodiments, network 150 may include a virtual network, which may include one or more physical network components (e.g., Ethernet, WiFi modules, telecommunications network hardware, etc.) on which one or more virtualized network functions (e.g., a Control Area Network (CAN) bus, etc.) are implemented.

[0050] According to one or more example embodiments, network 150 may be utilized by device management system 110 for OTA device updates on one or more of devices 130-1 through 130-N. In this manner, OTA communication between device management system 110 and devices 130-1 through 130-N enables efficient and secure device updates, thereby enabling device management system 110 to securely and reliably manage and distribute device updates in the form of data packages while enabling devices to receive the updates in a timely manner.

[0051] It will be understood that the components included in system architecture 100 and their arrangement described above with reference to FIG. 1 are merely exemplary embodiments, and that without departing from the scope of the present disclosure, the system architecture may include more or fewer components than those described, and / or the components included therein may be arranged in any manner different from that described.

[0052] For example, according to one or more exemplary embodiments, system architecture 100 may include one or more proxy servers interconnecting devices 130-1 through 130-N to device management system 110 via network 150, one or more network load balancers interconnecting devices 130-1 through 130-N to the one or more proxy servers, and the like, to manage incoming and / or outgoing network traffic to provide functionality such as load balancing, routing, security, and observability. Additionally, system architecture 100 may also include one or more virtual private networks (VPNs) interconnecting UEs 120-1 through 120-N to device management system 110.

[0053] Reference is now made to Figure 2, which illustrates a block diagram of example components of a device management system 200, according to one or more embodiments. The device management system 200 may be similar to the device management system 110 of Figure 1.

[0054] 2, device management system 200 may include at least one communication interface 210, at least one storage 220, and at least one processor 230. According to an embodiment, device management system 200 (or one or more components included therein) may be deployed on a server (e.g., a cloud server, a hybrid cloud server, a server cluster, etc.).

[0055] The communications interface 210 may include components such as a transceiver (e.g., a transceiver, a separate receiver and transmitter, a bus, etc.) that enable the device management system 200 (or one or more components included therein) to communicate with one or more components external to the device management system 200, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections.

[0056] For example, communication interface 210 may connect device management system 200 (or one or more components included therein) to multiple UEs (e.g., UEs 120-1 through 120-N in FIG. 1 ), multiple devices (e.g., devices 130-1 through 130-N in FIG. 1 ), and / or a database (e.g., database 140 in FIG. 1 ), thereby enabling them to communicate with and interoperate with each other. As another example, communication interface 210 may enable components of device management system 200 to communicate with each other. For example, communication interface 210 may connect storage 220 to processor 230, thereby enabling them to communicate with and interoperate with each other.

[0057] The communication interface 210 may include a hardware-based interface, such as a 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, a software interface, or the like. According to an embodiment, the communication interface 210 may include at least one controller area network (CAN) bus, which is configurable to communicatively couple components of the device management system 200 (e.g., storage 220, processor 230, etc.) to multiple UEs (e.g., UEs 120-1 through 120-N), multiple devices (e.g., devices 130-1 through 130-N), and / or database 140. Additionally or alternatively, the communication interface 210 may include a software-based interface, such as an application programming interface (API), a virtualized network interface (e.g., a virtualized CAN bus, etc.), or the like.

[0058] Communications interface 210 may be configured to receive information from one or more components external to device management system 200 and provide the information to processor 230 for further processing and / or to storage 220 for storage. For example, communications interface 210 may receive one or more user inputs from multiple UEs for management of one or more device updates (e.g., viewing available updates, viewing device information, scheduling deployment of a device update, triggering deployment of a device update, configuring or modifying a device update, etc.) and provide the user inputs to processor 230 and / or storage 220. Similarly, communications interface 210 may be configured to enable processor 230 of device management system 200 to provide one or more information to one or more components external to device management system 200.

[0059] 2, at least one storage 220 may include one or more storage media suitable for storing data, information, and / or computer-readable / computer-executable instructions therein. According to an embodiment, storage 220 may include random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) that stores information and / or instructions for use by processor 230.

[0060] Additionally or alternatively, storage 220 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, and / or a 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-transitory computer-readable medium, along with a corresponding drive.

[0061] Storage 220 may be configured to store information utilized by processor 230 to perform one or more operations to manage one or more updates for one or more devices. For example, storage 220 may be configured to store one or more device update deployment settings provided by one or more users, store information associated with one or more users and / or update deployments associated with devices, store information for one or more devices, store device updates received from a database, and the like.

[0062] At least one processor 230 may be configured to receive one or more signals (e.g., via communications interface 210, etc.) that define one or more instructions to perform one or more operations. Furthermore, processor 230 may be implemented in hardware, firmware, or a combination of hardware and software. Processor 230 may include a central processing unit (CPU), a graphics processing unit (GPU), an accelerated 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 another type of processing or computational component.

[0063] At least one processor 230 may include one or more processors that are programmable to perform one or more device update management functions or operations. For example, processor 230 may be configured to execute computer-readable instructions stored in memory storage (e.g., storage 220, etc.) to thereby perform one or more acts or operations described herein.

[0064] It will be understood that the components included in device management system 200 and their configuration described above with reference to FIG. 2 are merely exemplary embodiments, and that without departing from the scope of the present disclosure, device management system 200 may include more or fewer components than those described, and / or the components included therein may be arranged in any manner different from that described.

[0065] For example, according to one or more exemplary embodiments, the device management system 200 may include an input module (e.g., a touchscreen display, buttons, switches, a microphone, sensors, a keyboard, a mouse, a joystick, a keypad, soft keys, etc.) and / or an output module (e.g., a display, a speaker, a ringer, one or more light emitting diodes (LEDs), an LED-based display, e.g., an active matrix organic light emitting diode (AMOLED) display, a thin film transistor (TFT) display, a liquid crystal display, etc.) that may be configured to receive one or more user inputs from one or more users and / or output information to one or more users.

[0066] 3, which illustrates a flow diagram of an example method 300 for managing one or more updates for one or more devices in a vehicle system, according to one or more embodiments. One or more operations of method 300 may be performed by at least one processor (e.g., processor 230, etc.) of a device management system upon execution of computer-executable instructions stored on at least one storage medium (e.g., storage 220, etc.).

[0067] 3, at operation S310, at least one processor of the device management system may be configured to obtain information associated with one or more device updates (which may be referred to herein as “update information”). According to an embodiment, the at least one processor may obtain the update information from a user. Alternatively, or in addition, the at least one processor may obtain the update information from a database and / or a build system. A description of an example use case in which update information is received is provided below with reference to the example use case of FIG. 4.

[0068] Upon obtaining the update information, method 300 may proceed to operation S320, where at least one processor of the device management system may be configured to generate one or more messages associated with the update (which may be referred to herein as “update messages”) based on the obtained update information. For example, the at least one processor may determine the type of update (e.g., temporary update, mandatory update, optional update, etc.), the importance of the update (e.g., urgent update, non-urgent update, update associated with a safety feature, etc.), and the like based on the obtained update information. Accordingly, the at least one processor may generate an update message based on the determined information. The update message may include information of the update, such as device identification information, the type of update (e.g., temporary update, non-temporary update, etc.), the importance / urgency of the update, the update version, a deployment schedule, storage information for the update, and the like.

[0069] Thus, at operation S330, the at least one processor may configure deployment of the update. For example, the at least one processor may provide an update message to a device to be updated (which may be referred to herein as a “target device”), thereby instructing the target device to configure the update deployment. According to an embodiment, the at least one processor may be configured to generate and provide an update message to a target device to cause the target device to configure a non-transient update (a description of an exemplary use case associated therewith is provided below with reference to FIGS. 5A-5B). According to an embodiment, the at least one processor may be configured to generate and provide an update message to a target device to cause the target device to configure a transitory update (a description of an exemplary use case associated therewith is provided below with reference to FIG. 6).

[0070]

[0041] Referring now to Figure 4, Figure 4 illustrates a block diagram of an exemplary system configuration 400 for providing update distribution, according to one or more embodiments. As shown in Figure 4, system configuration 400 may include a device management system 410, a build system 420, a device 430, and a database 440. Device management system 410 and database 440 may be similar to those described herein with reference to other figures, build system 420 may be similar to the UE described herein with reference to other figures, and device 430 may be similar to the target device described herein with reference to other figures. Additionally, one or more operations of Figure 4 may be similar to one or more operations in method 300 of Figure 3.

[0071] 4, a first user (e.g., a software developer, etc.) may utilize build system 420 (at act S401) to create or build an update for device 430. Upon building or creating the device update, build system 420 may be configured to provide the update (e.g., via network 150, etc.) to database 440, which may be configured to store the device update internally (at act S402).

[0072] Accordingly, a second user (e.g., an administrator of the device 430, etc.) may access the device management system 410 (e.g., via an associated UE, direct access without a UE, etc.) to manage device updates (at operation S403), e.g., to schedule deployment of device updates, execute deployment of device updates, and the like. In this operation, the device management system 410 (or at least one processor included therein) may receive update information from the second user. In this regard, the device management system 410 may be configured to generate and output one or more graphical user interfaces (GUIs) and output the one or more GUIs to the second user (via an input / output module). Accordingly, the device management system 410 may receive user input from the second user by determining user interaction with the one or more GUIs.

[0073] Additionally or alternatively, the device management system 410 may obtain or receive update information from the build system 420 (at optional operation S403-1) and / or may obtain or receive update information from the database 440 (at optional operation S403-2).

[0074] Upon obtaining the update information, the device management system 410 (or at least one processor included therein) may be configured to generate one or more update messages based on the update information. The update messages may then be provided (at operation S404) to the device 430. One or more of the operations performed by the device management system, e.g., receiving the update information and / or providing the update messages, may be performed over-the-air.

[0075] Upon receiving the update message from the device management system 410, the device 430 may be configured to search or retrieve (at operation S405) the device update from the database 440 based on the update message. Accordingly, the device 430 may configure the deployment of a device update based on the searched device update and the update message. A description of an example use case of a device configuring the deployment of a device update is provided below with reference to FIGS. 5A-6.

[0076]

[0033] Referring first to Figure 5A, Figure 5A illustrates a block diagram of a first configuration of an exemplary use case for deploying a device update, according to one or more embodiments. In the example of Figure 5A, it is assumed that device 530 (which may be similar to device 430 of Figure 4) has received an update message from a device management system (e.g., device management 410 of Figure 4) and determined that the type of update is a non-transient update (e.g., mandatory update, optional update, etc.).

[0077] 5A, device 530 may include first portion 531 and second portion 532, each of which may have a first version of software (denoted as "Software Version 1" in FIG. 5A). In this regard, one of portions 531 and 532 may be configured to store primary software that the device executes, while another of portions 531 and 532 may be configured to store clone versions of the software for backup, redundancy, or any other suitable purposes. According to an embodiment, the software may include an operating system (OS) image.

[0078] In this regard, device 530 may determine a needed device update based on the update message and may retrieve the update from database 540 (which may be similar to database 440 of FIG. 4 ). By way of example, assume that the update message indicates that the update is a non-transient update that updates software from “version 1” to “version 1.1,” device 530 may retrieve the update (e.g., software version 1.1) from database 540 and deploy the update accordingly. For example, device 530 may overwrite or replace software in one of first portion 531 and second portion 532 with software retrieved from database 540.

[0079]

[0033] Referring now to Figure 5B, which illustrates a block diagram of a second configuration of an exemplary use case for deploying a device update, according to one or more embodiments. The components of Figure 5B may be similar to those described above with reference to Figure 5A.

[0080] In the example of Figure 5B, it is assumed that device 530 has obtained a device update "Software Version 1.1," overwriting or replacing the software in second portion 532 (denoted as "Software Version 1" in Figure 5A). The device may then switch its primary software from the software in first portion 531 (e.g., "Software Version 1") to the updated software in second portion 532 (e.g., "Software Version 1.1"). Device 530 may then reboot or resume to switch its running software to the new primary software.

[0081] It may be understood that device 530 may be configured to deploy non-transient device updates in any other suitable manner and / or to deploy any other type of non-transient device update in a similar manner without departing from the scope of this disclosure.

[0082]

[0041] Referring to Figure 6, Figure 6 illustrates a block diagram of an exemplary use case configuration for deploying a temporary device update, according to one or more embodiments. In the example of Figure 6, it is assumed that device 630 (which may be similar to device 440 of Figure 4) has received an update message from a device management system (e.g., device management 410 of Figure 4), determined that the type of update is a temporary update (e.g., an update for a beta version of software, a temporary hot fix, an update for testing purposes, etc.), and retrieved the device update from a database (e.g., database 430 of Figure 4).

[0083] 6, device 630 may include overlay file system 631 including upper layer 631-1 and lower layer 631-2. Layers 631-1 and 631-2 may be included in one or more of first portion 531 and second portion 532. Furthermore, each of layers 631-1 and 631-2 may include the same software files, and upper layer 631-1 and / or the software files included therein may be temporarily created by device 630 based on lower layer 631-2 and the software files included therein.

[0084] Specifically, based on determining from the update message provided by the device management system that the update is a temporary update, device 630 may create a reference or pointer to the software file in lower layer 631-2, allowing device 630 to continue executing the software file in lower layer 631-2 for normal operation without interruption.

[0085] The device 630 may then begin making temporary copies of the software files and include the copied software files in the upper layer 631-1 to which the temporary update is applied. Thus, the temporary update is performed in the upper layer 631-1, ensuring that the original software files in the lower layer 631-2 remain intact and uninterrupted during the temporary update process. According to an embodiment, the device 630 may be configured to remove the software files in the upper layer 631-1 after a period of time (e.g., after a predetermined amount of time specified in the update message, after the device 630 is rebooted, etc.), so that the device 630 may return to its last known state.

[0086] In view of the above, software files in the upper layer 631-1 may be referred to as "read-write files," while software files in the lower layer 631-2 may be referred to as "read-only files." According to an embodiment, the device 630 may utilize a copy-on-write (CoW) mechanism in managing the overlay file system 631. Thus, the temporary update process may be more efficient and resource-friendly, ensuring minimal disruption to the normal operation of the device 630. Furthermore, reversible updates may be provided, thereby minimizing the risk of potential problems such as state drift of the device 630.

[0087] To this end, exemplary embodiments of the present disclosure provide a device management system (and a method of utilizing the device management system) that enables effective and efficient management of one or more updates for one or more devices in a vehicle system, and that addresses the problems in the related art as described above.

[0088] It is understood that the specific order or hierarchy of blocks in the processes / flowcharts disclosed herein is an example of an exemplary approach. Based on design preferences, it is understood that the specific order or hierarchy of blocks in the processes / flowcharts may be rearranged. Furthermore, some blocks may be combined or omitted. The accompanying method claims present elements of the various blocks in a sample order and are not meant to be limited to the specific order or hierarchy presented.

[0089] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of technical detail of integration. Additionally, as described herein, one or more of the above components described above may be implemented as instructions stored on 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) having computer-readable program instructions for causing a processor to perform operations.

[0090] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction-execution device. A computer-readable storage medium may be, for example, but 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 suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: 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 disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge-in-groove structures with instructions recorded thereon, and any suitable combination thereof. As used herein, computer-readable storage media should not be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over wires.

[0091] The computer-readable program instructions described herein may be downloaded to each computing / processing device from a computer-readable storage medium, or 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 fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing / processing device.

[0092] The computer-readable program code / instructions for performing operations may be either 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 or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, or the like, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may be executed 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 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 the connection to the external computer may be made (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to perform an aspect or operation.

[0093] The computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the function(s) / act(s) specified in the block(s) of the flowcharts and / or block diagrams. The computer-readable program instructions may also be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture containing instructions that implement aspects of the function(s) / act(s) specified in the block(s) of the flowcharts and / or block diagrams.

[0094] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or another device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to create a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device implement the function / act specified in the block or blocks of the flowcharts and / or block diagrams.

[0095] 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. The methods, computer systems, and computer-readable media may include additional, fewer, different, or differently arranged blocks compared to those depicted in the figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be executed concurrently or substantially concurrently, or the blocks may even be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or acts or executes a combination of dedicated hardware and computer instructions.

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

Claims

1. 1. A method for managing device updates in a vehicle system, the method being implemented by at least one processor of the system, comprising: The process performed by the processor is obtaining information associated with the update; and generating a message containing information about the update; configuring a deployment of the updates; Including, The method, wherein the update comprises one of a transient update and a non-transient update.

2. The obtaining of the information associated with the update includes: The method of claim 1 , comprising obtaining the information from at least one of a user device, a build system, and a database.

3. The configuring the deployment of the updates comprises: The method of claim 1 , comprising providing the message to the device via over-the-air (OTA) communication and causing the device to configure the deployment of the update based on the message.

4. The method of claim 1 , wherein the device is a remote device located in a different geographic location than the system.

5. 10. The method of claim 1, wherein the update is created by a first user located at a first geographic location and the information associated with the update is obtained from a second user located at a second geographic location, the first geographic location being different from the second geographic location.

6. The update is a temporary update to a software file on the device, the device having a lower layer that includes the software file, and the configuration for the deployment of the update comprises: providing the message to the device, and causing the device to: Retrieve updated software files from the database, creating an upper layer comprising software files based on the lower layer and the software files included in the lower layer; replacing the software file in the upper layer with the updated software file; 4. The method of claim 3, including causing the update software files in the upper layer to be removed after a period of time.

7. The method of claim 6 , wherein the software files comprise operating system (OS) files.

8. The update is a non-transient update to a software file on the device, the device comprising a first partition and a second partition, the first partition and the second partition comprising the software file, and the configuration for the deployment of the update comprises: providing the message to the device, and causing the device to: Retrieve updated software files from the database, replacing the software file in one of the first partition and the second partition with the updated software file; configuring the partition containing the update software file as a primary partition; 4. The method of claim 3, further comprising rebooting the device to execute the update software file as primary software.

9. 1. A system for managing device updates in a vehicle system, the system comprising: memory storage for storing computer-executable instructions; at least one processor communicatively connected to the memory storage; wherein the at least one processor executes the instructions to Obtaining information associated with the update; generating a message containing information about the update; configured to configure deployment of the update; The update comprises one of a transient update and a non-transient update.

10. The at least one processor executes the instructions to:

10. The system of claim 9, configured to obtain the information associated with the update by obtaining the information from at least one of a user device, a build system, and a database.

11. The at least one processor executes the instructions to:

10. The system of claim 9, wherein the system is configured to configure the deployment of the update by providing the message to the device via over-the-air (OTA) communication and causing the device to configure the deployment of the update based on the message.

12. The system of claim 9 , wherein the device is a remote device located in a different geographic location than the system.

13. 10. The system of claim 9, wherein the update is created by a first user located at a first geographic location and the information associated with the update is obtained from a second user located at a second geographic location, the first geographic location being different from the second geographic location.

14. The update is a temporary update to a software file on the device, the device having a lower layer that includes the software file, and the at least one processor executes the instructions to: providing the message to the device, and causing the device to: Retrieve updated software files from the database, creating an upper layer comprising software files based on the lower layer and the software files included in the lower layer; replacing the software file in the upper layer with the updated software file; 12. The system of claim 11, configured to configure the deployment of the update by causing the update software file in the upper layer to be removed after a period of time.

15. The system of claim 14 , wherein the software files comprise operating system (OS) files.

16. The update is a non-transitory update to a software file on the device, the device comprising a first partition and a second partition, the first partition and the second partition comprising the software file, and the at least one processor executing the instructions to: providing the message to the device, and causing the device to: Retrieve updated software files from the database, replacing the software file in one of the first partition and the second partition with the updated software file; configuring the partition containing the update software file as a primary partition; 12. The system of claim 11, configured to configure the deployment of the update by rebooting the device to execute the update software file as primary software.

17. 1. A computer program product for causing a processor to perform a method for managing updates to devices in a vehicle system, the method comprising: obtaining information associated with the update; and generating a message containing information about the update; configuring a deployment of the updates; Including, The computer program product, wherein the update comprises one of a transient update and a non-transient update.

18. The obtaining of the information associated with the update includes:

20. The computer program product of claim 17, comprising obtaining the information from at least one of a user device, a build system, and a database.

19. The configuration for the deployment of the updates includes:

20. The computer program product of claim 17, comprising providing the message to the device via over-the-air (OTA) communication and causing the device to configure the deployment of the update based on the message.

20. 20. The computer program product of claim 17, wherein the device is a remote device located in a different geographic location than the system.

Images