A software automatic updating method based on a vehicle-mounted embedded operating system

Abstract

This invention relates to an automatic software update method based on an in-vehicle embedded operating system, belonging to the field of computer software technology. It solves the problem that existing methods cannot simultaneously achieve reliable system startup and flexible, secure automatic software updates. The method includes: partitioning the physical disk into a system root partition, a user data partition, and an OverlayFS working partition; automatically entering safe mode by detecting kernel boot parameters, mounting the system root partition as read-only, and mounting specified directories as read-write overlays based on the OverlayFS file system and whitelist configuration files; dynamically switching the safe mode on and off via system services and command lines; upon detecting an external update device, entering maintenance mode, performing security verification on the update package from the external update device, and then performing an atomic update operation on the user data partition. This achieves both reliable operating system startup and flexible automatic software updates.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and in particular to an automatic software update method based on an in-vehicle embedded operating system. Background Technology

[0002] As the automotive industry rapidly evolves towards intelligence and connectivity, in-vehicle operating systems are developing towards high performance, powerful processing capabilities, multifunctionality, and high integration. Against this backdrop, the automotive field is increasingly adopting large-scale server and desktop Linux operating systems to support complex intelligent algorithm frameworks and models, as well as the compatibility requirements with various GPUs / NPUs. Vehicles face a high risk of sudden power outages during operation or maintenance. Software updates performed in unstable power supply environments pose a significant challenge to the reliable startup of the operating system and data consistency.

[0003] Existing methods typically employ a fixed combination of a read-only root file system and OverlayFS. This method mounts the system root partition as a read-only squashfs file system, while simultaneously mounting the user data partition as a read-write layer within OverlayFS. Upon system reboot, all written data on the OverlayFS layer is automatically discarded, rolling the system back to its initial clean state and ensuring reliable boot under any circumstances. However, this mechanism of automatically losing all user data and updates upon system reboot makes it completely unsuitable for automatic software updates requiring persistent storage. Furthermore, its read / write mode is fixed during system installation, lacking the ability to dynamically switch between protected and updateable modes, resulting in insufficient flexibility and failing to meet the complex debugging and update requirements of automotive scenarios.

[0004] Alternatively, some systems employ an A / B system partition update mechanism. This method maintains two complete system partitions (A and B) for the operating system. When the system is running on partition A, the complete system update image is deployed to the idle partition B, and the bootloader switches to partition B to perform the update. If the update verification fails, the bootloader automatically switches back to partition A to roll back. This method requires twice the storage space to store two complete system images, making it costly and uneconomical on automotive hardware platforms with limited storage resources. Summary of the Invention

[0005] Based on the above analysis, the embodiments of the present invention aim to provide a distributed collaborative exploration and mapping method for multiple unmanned ground platforms, in order to solve the problem that existing methods cannot simultaneously achieve reliable system startup and flexible and secure automatic software updates in vehicle-mounted Linux operating systems based on Ext4 and XFS file systems.

[0006] This invention provides a method for automatic software updates based on an in-vehicle embedded operating system, comprising the following steps:

[0007] Partition the physical disk to create a system root partition, a user data partition, and an OverlayFS working partition;

[0008] When the operating system starts, the kernel boot parameters are detected by the joverlay service and the system automatically enters safe mode. In this mode, the system root partition is mounted as read-only, and the specified directory is mounted as an overlay layer with read and write capabilities based on the OverlayFS file system and whitelist configuration file. Safe mode is dynamically switched on and off through both system services and command line.

[0009] Upon detecting an external update device, the system automatically shuts down the security mode and enters the maintenance mode. After performing security verification on the update package in the external update device, it performs an atomic update operation in the user data partition to complete the software update.

[0010] Based on the above method, a further improvement is made: before the operating system starts, the joverlay service file, joverlay executable script, and whitelist configuration file are deployed to a specified directory of the operating system; the joverlay service is set to start automatically at boot by executing the systemctl enablejoverlay.service command.

[0011] Further improvements to the above method, based on the OverlayFS file system and whitelist configuration file, mount the specified directory as an overlay layer with read and write capabilities, including:

[0012] After the Joverlay service starts, it calls the Joverlay executable script;

[0013] The joverlay executable script reads the whitelist configuration file and obtains the list of directories that need to be mounted as overlays; for each directory in the directory list, it creates the corresponding parent directory and working directory in the OverlayFS working partition;

[0014] Execute the mount command to mount OverlayFS with the corresponding directory under the system root partition as the lower read-only directory and the created upper directory as the writable layer.

[0015] By binding and mounting, the mounted OverlayFS merge directory is overwritten with the original directory path, thus completing the mounting process.

[0016] Based on further improvements to the above method, the safe mode is dynamically switched on and off through both system services and command lines, including:

[0017] The systemd service can be used to permanently enable or disable safe mode; and the joverlay command can be used to temporarily enable or disable safe mode when the operating system is in safe mode.

[0018] Based on further improvements to the above method, when the operating system is in safe mode and safe mode is temporarily disabled via the joverlay command line, the OverlayFS is unloaded via the umount command according to the directory list in the whitelist configuration file. When the system restarts, it will automatically return to safe mode because the joverlay service is enabled.

[0019] Based on the above method, a further improvement is made to deploy the user-defined script to a specified directory of the operating system before the operating system starts; after mounting is completed, the user-defined script is executed to restart system services related to the file system.

[0020] Based on a further improvement to the above method, upon detecting an externally updated device, the system automatically shuts down the security mode and enters maintenance mode, including:

[0021] By listening to system events through udev rules, when the partition label of the connected USB device matches a predefined specific identifier, a pre-deployed mount script is automatically executed;

[0022] The mounting script mounts the USB device to the specified directory and checks if a preset identifier file exists in the USB device's update directory. If it does, it automatically closes the safe mode and enters the maintenance mode.

[0023] Based on further improvements to the above method, security verification is performed on update packages in external update devices, including:

[0024] The digital signature of the update packet is verified using an asymmetric encryption algorithm;

[0025] Calculate the hash check value of the update package and compare it with the preset baseline value in the update package.

[0026] Based on further improvements to the above method, a multi-version directory structure is maintained within the user data partition, and symbolic links are used to point to the currently active version directory; atomic update operations are performed within the user data partition, including:

[0027] Back up the currently active version directory to the previous version directory;

[0028] Extract the contents of the verified update package to a temporary directory and obtain the update configuration file;

[0029] Based on the target path of the files to be updated as defined in the update configuration file, the files to be updated in the temporary directory are deployed to the current version directory;

[0030] Activate the updated version directory by switching the symbolic link pointing to the current version directory.

[0031] Based on further improvements to the above method, the automatic software update method also includes: in maintenance mode, recording the entire process log of the update operation by calling a unified log interface, and managing the log files according to the log rolling strategy.

[0032] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects:

[0033] 1. By introducing a dynamically switchable "safe mode," the root file system is set to read-only to ensure the stability of the core system. At the same time, a configurable whitelist mechanism is used to allow read and write operations on specified directories. This not only prevents startup failures caused by tampering with critical system files, but also meets the needs of user data and application updates. Moreover, it does not rely on specific hardware or a deeply customized kernel, and can be widely used in various Linux-based automotive, embedded, and server scenarios, with good versatility and scalability.

[0034] 2. By using both systemd services and joverlay commands, it supports permanent or temporary switching of "safe mode," enabling the temporary disabling of safe mode during development and debugging phases to freely install software and library files; while ensuring the system remains in a protected and stable state during production operation, greatly simplifying the complexity of system maintenance.

[0035] 3. By automatically identifying specific USB update devices and triggering maintenance mode through udev rules, and integrating digital signature authentication and file integrity verification, it effectively prevents the implantation of malicious software and corrupted update packages. At the same time, it adopts a mechanism of temporary update, version directory and symbolic link atomic replacement to ensure the atomicity of update operations, and can automatically and quickly roll back in the event of update failure, thus maximizing the service continuity of the system.

[0036] 4. By providing a unified log management API interface, the entire software update process is recorded in detail, and log rolling strategies based on size and time are supported, which facilitates problem tracing and status monitoring for development and maintenance personnel, thereby improving the maintainability of the system.

[0037] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0038] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts.

[0039] Figure 1 This is a flowchart of an automatic software update method based on an in-vehicle embedded operating system according to an embodiment of the present invention;

[0040] Figure 2 This is a schematic diagram of a technical architecture for automatic software updates based on an in-vehicle embedded operating system, as described in an embodiment of the present invention. Detailed Implementation

[0041] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0042] A specific embodiment of the present invention discloses an automatic software update method based on an in-vehicle embedded operating system, such as... Figure 1 As shown, steps S1-S3 are included:

[0043] S1. Partition the physical disk to create a system root partition, a user data partition, and an OverlayFS working partition.

[0044] This step uses disk partitioning strategies to achieve physical isolation between system data and user data, providing underlying support for subsequent "safe mode" and reliable updates. The partitioning of physical disk space is implemented during the operating system installation process. Large server and desktop systems such as Kylin and openEuler provide a visual interface for partitioning during installation, without explicit restrictions on the operating system's platform architecture or type.

[0045] Preferably, partitioning is planned based on five principles: necessity, security, maintainability, performance optimization, and scalability. The necessity principle ensures that partitions necessary for system operation exist; the security principle separates frequently accessed directories (such as logs and temporary files) from the root partition to prevent them from becoming full and causing the entire system to fail to boot; the maintainability principle sets user data and applications as separate partitions to ensure user data is preserved during system reinstallation or upgrades, simplifying maintenance processes; the performance optimization principle matches partitions to hardware characteristics. For example, directories with high access demands (such as databases) are allocated to high-speed disks; for large file storage and high concurrency access requirements, the XFS file system is recommended to leverage its superior performance under high IO pressure; the scalability principle allows for partitioning using LVM (Logical Volume Management) to accommodate future changes in demand, supporting dynamic adjustment of partition sizes or reserving a certain proportion of disk space for future expansion or emergency repairs.

[0046] Based on the above principles, and to avoid the problem of difficulty in standardizing partition sizes due to different total disk capacities, this embodiment adopts a method of first fixing the partition size and then proportionally dividing it. Specifically, this includes:

[0047] First, partition the space necessary for system booting and operation; the size of this partition is relatively fixed.

[0048] Preferably, the following necessary partitions are divided:

[0049] Boot partition ( / boot): Formatted as Ext4, allocated 1~2GB of space, used to store boot files such as the kernel (vmlinuz) and the initial memory disk (initramfs);

[0050] EFI system partition ( / boot / efi): uses vfat format, allocated 512MB space, used to store UEFI boot program;

[0051] Swap partition ( / swap): Its size is generally 1-2 times that of physical memory, and it is used for memory expansion and system hibernation functions.

[0052] Furthermore, the remaining disk space is divided proportionally to achieve a balance between user data, system files, and OverlayFS runtime space.

[0053] Preferably, the partitioning is done according to the following ratio: 50% for user data partitioning, 30% for root partitioning, and 20% for OverlayFS partitioning, as detailed below:

[0054] User data partition (e.g., / home, / ide0): occupies 50% of the total remaining space; this partition is used to store user data, applications, and update files. To meet high performance requirements, it is recommended to use the XFS file system for the application partition ( / ide0);

[0055] Root partition ( / ): occupies 30% of the total remaining space; uses Ext4 format, and serves as the root directory for all system and application files;

[0056] OverlayFS working partition (e.g., / var): occupies 20% of the total remaining space; it uses the Ext4 format and will be used to store the upper directory and working directory of OverlayFS. It is the physical location for all write operations in "safe mode".

[0057] S2. When the operating system starts, the kernel boot parameters are detected by the joverlay service and the system automatically enters safe mode. The system root partition is mounted as read-only, and the specified directory is mounted as an overlay layer with read and write capabilities based on the OverlayFS file system and whitelist configuration file. Safe mode is dynamically switched on and off through both system services and command line.

[0058] It should be noted that before the operating system starts, the scripts and configuration files required for this embodiment should be deployed to the designated directory of the operating system and given the appropriate permissions, including:

[0059] The joverlay service file (joverlay.service) is used to manage the start and stop of safe mode. It is deployed to the / etc / systemd / system / directory and given read and write permissions.

[0060] The joverlay executable script is responsible for performing the mounting and unmounting of OverlayFS, and is deployed to the / usr / bin / directory with executable permissions.

[0061] The whitelist configuration file (white.list) is used to define the list of directories that need to be protected by OverlayFS. It is deployed to the / var / joverlay / directory and given read and write permissions.

[0062] User-defined scripts (hook.joverlay) are user-defined commands or programs used to restart file system-related services after OverlayFS is mounted. They are deployed to the / var / joverlay / directory and given read, write, and execute permissions.

[0063] In the bootloader configuration, add `joverlay=on` to the kernel boot parameters. This parameter is a necessary flag and master switch for automatically entering safe mode at system startup. Configure the JOverlay service to start automatically at boot by executing the command `systemctl enablejoverlay.service`.

[0064] A dynamic "safe mode" runtime environment is built using the aforementioned core components. In this mode, core system files are protected, while user data and directories specified in the whitelist configuration file remain freely readable and writable.

[0065] After booting, the joverlay service, which is set to start automatically on boot, will be executed first. This service checks whether "joverlay=on" exists in the kernel parameters using the command cat / proc / cmdline | grep joverlays=on. If it is detected, it will start in safe mode; otherwise, even if the service is enabled, it will not start normally.

[0066] Furthermore, after the JOverlay service starts, it calls the ` / usr / bin / joverlay start` command in the JOverlay executable script. This command reads the whitelist configuration file ` / var / joverlay / white.list`. This file lists all system directories that need read and write capabilities (e.g., ` / etc`, ` / var`, ` / home`). Directories requiring protection can be dynamically configured in the whitelist according to actual needs without reinstalling the system.

[0067] For each directory in the directory list, create the corresponding parent directory and working directory within the OverlayFS working partition;

[0068] Execute the mount command to mount OverlayFS with the corresponding directory under the system root partition as the lower read-only directory and the created upper directory as the writable layer.

[0069] By binding and mounting, the mounted OverlayFS merge directory is overwritten with the original directory path, thus completing the mounting process.

[0070] It's important to note that the OverlayFS file system is a union file system. Directories under the system root partition are read-only layers, providing initial files. Directories in the whitelist configuration file are extracted from the system root partition and used as lower-level read-only directories. Upper-level directories are read-write layers, storing all modifications. The working directory is a temporary directory used for file renaming, moving, and other operations to ensure consistency; it is automatically managed by the OverlayFS file system. The merge directory integrates the contents of lower and upper-level directories, presenting a unified view. Therefore, all read and write operations on directories in the whitelist configuration file by user data and applications are actually performed in the writable layer of OverlayFS, while the original root partition content remains read-only, thus protecting critical system data.

[0071] Furthermore, after mounting is complete, a user-defined script is executed to restart system services related to the file system. This design provides great scalability because some system services (such as sshd and docker) may need to be restarted to function properly after the file system mount point changes. Administrators can write corresponding commands in this script (such as systemctl restart sshd) to ensure that all services are in optimal condition after the system enters safe mode.

[0072] At this point, the vehicle operating system has successfully booted and is running in "Safe Mode." The system functions perceived by the user are complete, and the user can read and write to specified directories normally; however, the underlying critical system files have been isolated and protected.

[0073] It should be noted that the security mode in this embodiment is dynamically switched on and off through both system services and command lines, implementing two control methods with different operating cycles to meet different needs of system operation and maintenance and development debugging:

[0074] ① Permanently control whether safe mode is enabled or disabled via the systemd service.

[0075] This can be achieved using the systemd service's command-line tool, systemctl, including:

[0076] Execute the command `systemctl enable joverlay.service` to permanently enable safe mode, which will then automatically enter this mode every time the system restarts.

[0077] Executing the command `systemctl disable joverlay.service` permanently disables safe mode. After disabling and restarting the system, OverlayFS will no longer be mounted, and the root file system will remain readable and writable. This mode is suitable for periods where the system requires extensive software installations or in-depth configuration adjustments over a long period.

[0078] ② Use the joverlay command to temporarily enable or disable safe mode when the operating system is in safe mode.

[0079] With the operating system in safe mode (and the JOverlay service enabled), the `joverlay stop` command in the JOverlay executable script is executed via the JOverlay service. This command reads the directory list from the whitelist configuration file and uses the `umount` command to unmount OverlayFS, that is, unmounting all mounted OverlayFS file systems one by one, and remounting the root file system in read-write mode. When the system restarts, because the JOverlay service is still enabled, the system will automatically re-enter safe mode, ensuring that the stability of the production environment is not compromised by temporary debugging. This method allows administrators to temporarily bypass the restrictions of safe mode to install debugging software or perform system-level configurations.

[0080] After a temporary shutdown, no restart is required. You can execute the `joverlay start` command to remount OverlayFS and return to safe mode.

[0081] In addition, the joverlay command also supports various functions such as status (to check the status) and reset (to clear the upper layer data), which provides convenience for system maintenance.

[0082] S3. After detecting an external update device, automatically shut down the safe mode and enter the maintenance mode. After performing security verification on the update package in the external update device, perform an atomic update operation in the user data partition to complete the software update.

[0083] This step enables a seamless switch from "safe mode" to "maintenance mode," completing a safe, reliable, and automated software update process. It ensures that the update operation itself does not compromise system stability and allows for rapid recovery in the event of an unexpected situation.

[0084] It should be noted that upon detecting an external update device, the system automatically shuts down safe mode and enters maintenance mode, including:

[0085] By listening to system events through udev rules, when the partition label of the connected USB device matches a predefined specific identifier, a pre-deployed mount script is automatically executed;

[0086] The mounting script mounts the USB device to the specified directory and checks if a preset identifier file exists in the USB device's update directory. If it does, it automatically closes the safe mode and enters the maintenance mode.

[0087] Specifically, a udev rule file is created in the system to automatically identify specific external update devices. A specific external update device is defined as a device partition formatted as EXT4 or FAT32, labeled as UPDATE, and containing an identifier file named .update_mode in the update directory.

[0088] For example, the rule file created in the system is: / etc / udev / rules.d / 99-usb-maintenance.rules, and the content of this rule is: ACTION=="add", SUBSYSTEM=="EXT4 / FAT32", ENV{ID_FS_LABEL}=="UPDATE", RUN+=" / usr / bin / usb_maintenance.sh". When a USB device is plugged in, the 99-usb-maintenance.rules file is triggered. After detecting that the USB device's file system type is Ext4 and the partition label is UPDATE, the mount script usb_maintenance.sh specified in the rule file is executed. This script creates the / mnt / usb mount point, mounts UPDATE as an EXT4 file system using the mount command, and checks whether the identifier file .update_mode exists in the USB device's update directory. If it exists, the joverlay service is shut down, and maintenance mode is entered. At this time, the root directory changes from read-only to read-write.

[0089] Specifically, when the identifier file .update_mode exists, and the system automatically shuts down safe mode and enters maintenance mode, the joverlay command is triggered to temporarily shut down safe mode (joverlay stop), unmount all OverlayFS files, and remount the root file system as read-write. The operating system then exits "safe mode" and temporarily enters "maintenance mode," which allows writing to system-level directories.

[0090] Furthermore, after entering maintenance mode, the software update service update-mode.service is started by running systemctl start update-mode.service. This service starts a binary update program called usb-update, which performs a security verification of the update package in the external update device and then performs an atomic update operation on the user data partition.

[0091] Specifically, security verification is performed on update packages in external update devices, including signature authentication and integrity verification.

[0092] Among them, signature authentication uses an asymmetric encryption algorithm to verify the digital signature of the update packet;

[0093] It should be noted that, to prevent malware injection, OpenSSL is used to sign the update package update.tar when it is created, generating a digital signature update.tar.sig; during verification, the update program uses the public key public_key.pem in the USB device to verify the digital signature update.tar.sig of the update package update.tar.

[0094] Integrity verification involves calculating the hash check value of the update package and comparing it with a preset baseline value in the update package.

[0095] To prevent file corruption during transfer or storage, the update program calculates the SHA256 checksum of the update.tar file and compares it with the preset baseline value in the USB device, namely the checksum stored in the SHA256SUM file in the USB settings.

[0096] Only update packages that pass both of the above verifications will be processed; otherwise, the update process will be terminated immediately.

[0097] After successful verification, the update process enters the atomic update process, ensuring that the system is in a definable (current or previous version) stable state at any time (including in the event of a sudden power outage during the update process).

[0098] It should be noted that within the user data partition, a multi-version directory structure is maintained, and symbolic links are used to point to the currently active version directory.

[0099] Perform atomic update operations on user data partitions, including:

[0100] Back up the currently active version directory to the previous version directory for easy rollback in case of update failure.

[0101] Extract the contents of the verified update package to a temporary directory and obtain the update configuration file;

[0102] Based on the target path of the files to be updated as defined in the update configuration file, the files to be updated in the temporary directory are deployed to the current version directory;

[0103] Activate the updated version directory by switching the symbolic link pointing to the current version directory.

[0104] After the update is complete, a health check is performed, such as using `ps aux` to check if the update process exists. If the process is detected as non-existent or an error occurs in the update process itself, the symbolic links are automatically switched back to point to the previous version directory, thus achieving a rollback.

[0105] It should be noted that the method in this embodiment also includes step S4, and the complete technical architecture diagram is shown below. Figure 2 As shown:

[0106] S4. In maintenance mode, the entire process of update operations is recorded by calling a unified log interface, and the log files are managed according to the log rolling strategy, providing traceability and monitoring capabilities for key operations in maintenance mode.

[0107] To facilitate the reuse of logging functionality by other applications requiring highly reliable log management, logging macros are defined in the header file jss_logger.h for user invocation. The dynamic library libseverant.so provides the specific implementation methods for the logging macros. When the update program usb_update starts in maintenance mode, it only needs to reference the logging header file and the dynamic library to call the corresponding function interface to implement the log scrolling recording function.

[0108] It should be noted that multiple log scrolling strategies are supported, including:

[0109] Rolling strategies based on the size of a single log file and the total number of log files are suitable for scenarios with frequent updates and strict control over log disk usage; while rolling strategies based on preset time frequencies are suitable for scenarios that require archiving logs on a daily, hourly, or other periodic basis.

[0110] After the update program starts, it first initializes the logs according to the determined log rolling strategy. If the rolling strategy based on the size of a single log file and the total number of log files is selected, the current application name, the current service name, the storage path of the log files, the maximum size of a single log file, and the maximum number of log files to be retained are initialized. If the rolling strategy based on a preset time frequency is selected, the current application name, the current service name, the storage path of the log files, the time format, and the time frequency are initialized.

[0111] After initialization, the updater uses predefined logging macros for hierarchical logging during key execution steps, which facilitates quick filtering of information at different levels when troubleshooting problems.

[0112] It should be noted that logging macros are used to record different levels of logging information, including: general information, debugging information, warning information, and error information. Preferably, standard logging macros and enhanced logging macros are provided; the enhanced logging macros, in addition to the standard logging macros, automatically append the function name and line number of the logging statement.

[0113] Log the following key execution steps of the update process:

[0114] Process start and end: Record the start and final completion status (success / failure) of the update task;

[0115] Security verification: Records detailed results of signature authentication and integrity verification;

[0116] Atomic update: Records the results of each step of the operation, such as backup creation, temporary storage and decompression, configuration file parsing, file copying, and symbolic link switching.

[0117] Exceptions and Rollback: Record any errors or exceptions encountered, as well as the decision-making process that triggers an automatic rollback.

[0118] It should be noted that the operating system itself and many system services generate a large number of logs (such as / var / log / messages, / var / log / syslog). If left unmanaged, these log files may fill up their respective partitions (usually / var), leading to system failures.

[0119] Preferably, the logrotate tool of the Linux system is used to automate the management of system logs.

[0120] By recording data in log files, the update process can be traced, and the entire software update process can be fully reproduced, allowing for precise understanding of the status and time consumption of each step. When an update fails or the system malfunctions after the update, the error and warning messages in the logs become the primary clues for troubleshooting. Combined with function name and line number information, this can greatly shorten the problem diagnosis time.

[0121] Compared with existing technologies, this embodiment provides an automatic software update method based on an in-vehicle embedded operating system. By introducing a dynamically switchable "safe mode," the root file system is set to read-only to ensure the stability of the core system. Simultaneously, a configurable whitelist mechanism allows read and write operations on specified directories, preventing boot failures caused by tampering with critical system files while meeting the needs of user data and application updates. Furthermore, it does not rely on specific hardware or deeply customized kernels, and can be widely applied to various Linux-based in-vehicle, embedded, and server scenarios, exhibiting good versatility and scalability. Through both the systemd service and the joverlay command, the "safe mode" can be permanently or temporarily switched on and off. This allows for temporarily disabling safe mode during development and debugging phases to freely install software and libraries, while ensuring the system remains in a protected and stable state during production operation, greatly simplifying system maintenance complexity. By automatically identifying specific USB update devices and triggering maintenance mode through udev rules, and integrating digital signature authentication and file integrity verification, the system effectively prevents the implantation of malware and corrupted update packages. Simultaneously, it employs mechanisms such as temporary updates and atomic replacement of version directories and symbolic links to ensure the atomicity of update operations and enable automatic and rapid rollback in case of update failure, maximizing system service continuity. By providing a unified log management API interface, the entire software update process is recorded in detail, and log rolling strategies based on size and time are supported, facilitating problem tracing and status monitoring for development and operations personnel, thus improving system maintainability.

[0122] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0123] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for automatic software updates based on an in-vehicle embedded operating system, characterized in that, Includes the following steps: Partition the physical disk to create a system root partition, a user data partition, and an OverlayFS working partition; When the operating system boots, the joverlay service detects kernel boot parameters and automatically enters safe mode. The joverlay service file is used to manage the start and stop of safe mode. The system root partition is mounted as read-only, and based on the OverlayFS file system and whitelist configuration file, specified directories are mounted as overlay layers with read and write capabilities. The safe mode is dynamically switched on and off through two methods: system services and command line. These include: permanently controlling the safe mode to be turned on or off through the systemd service; and temporarily turning the safe mode on or off when the operating system is in safe mode through the joverlay command. Upon detecting an external update device, the system automatically shuts down the security mode and enters maintenance mode. This is achieved by triggering the joverlay command to temporarily disable the security mode. After performing security verification on the update package in the external update device, an atomic update operation is performed on the user data partition to complete the software update.

2. The automatic software update method based on an in-vehicle embedded operating system according to claim 1, characterized in that, Before the operating system starts, deploy the joverlay service file, joverlay executable script, and whitelist configuration file to the specified directory of the operating system; the joverlay executable script is responsible for performing the mounting and unmounting of OverlayFS operations; the joverlay service is set to start automatically on boot by executing the command systemctl enable joverlay.service.

3. The automatic software update method based on an in-vehicle embedded operating system according to claim 2, characterized in that, Based on the OverlayFS file system and whitelist configuration file, the specified directory is mounted as an overlay layer with read and write capabilities, including: After the Joverlay service starts, it calls the Joverlay executable script; The joverlay executable script reads the whitelist configuration file and obtains the list of directories that need to be mounted as an overlay layer; for each directory in the directory list, a corresponding parent directory and working directory are created in the OverlayFS working partition; Execute the mount command to mount OverlayFS with the corresponding directory under the system root partition as the lower read-only directory and the created upper directory as the writable layer. By binding and mounting, the mounted OverlayFS merge directory is overwritten with the original directory path, thus completing the mounting process.

4. The automatic software update method based on an in-vehicle embedded operating system according to claim 3, characterized in that, When the operating system is in safe mode and safe mode is temporarily disabled via the joverlay command line, the OverlayFS is unloaded via the umount command according to the directory list in the whitelist configuration file. Upon system restart, the system will automatically return to safe mode because the joverlay service is enabled.

5. The automatic software update method based on an in-vehicle embedded operating system according to claim 3, characterized in that, Before the operating system starts, user-defined scripts are also deployed to a specified directory of the operating system; After mounting is complete, execute the user-defined script to restart system services related to the file system.

6. The automatic software update method based on an in-vehicle embedded operating system according to claim 1, characterized in that, Upon detecting an external update device, the system automatically shuts down the security mode and enters maintenance mode, including: By listening to system events through udev rules, when the partition label of the connected USB device matches a predefined specific identifier, a pre-deployed mount script is automatically executed; The mounting script mounts the USB device to a specified directory and checks whether a preset identifier file exists in the update directory of the USB device. If it does, the script automatically closes the security mode and enters the maintenance mode.

7. The automatic software update method based on an in-vehicle embedded operating system according to claim 1, characterized in that, The security verification of the update package in the external update device includes: The digital signature of the update packet is verified using an asymmetric encryption algorithm; Calculate the hash check value of the update package and compare it with the preset baseline value in the update package.

8. The automatic software update method based on an in-vehicle embedded operating system according to claim 1, characterized in that, Within the user data partition, a multi-version directory structure is maintained, and symbolic links point to the currently active version directory; atomic update operations are performed within the user data partition, including: Back up the currently active version directory to the previous version directory; Extract the contents of the verified update package to a temporary directory and obtain the update configuration file; Based on the target path of the file to be updated defined in the update configuration file, the file to be updated in the temporary directory is deployed to the current version directory; Activate the updated version directory by switching the symbolic link to point to the current version directory.

9. The automatic software update method based on an in-vehicle embedded operating system according to claim 1, characterized in that, The automatic software update method further includes: in maintenance mode, recording the entire process log of the update operation by calling a unified log interface, and managing the log files according to a log rolling strategy.

Images