Upgrade method and device for embedded device and electronic device

Abstract

The application discloses an upgrading method and device of an embedded device and electronic equipment, and belongs to the technical field of firmware upgrading. The upgrading method of the embedded device comprises the following steps: in response to an access event of an external storage device, obtaining upgrading data from the external storage device; in the case that it is determined that an upgrading operation needs to be performed based on the upgrading data and local historical data, performing an upgrading operation on a plurality of to-be-upgraded devices based on configuration information in the upgrading data, the plurality of to-be-upgraded devices being determined based on the upgrading data; and in response to the upgrading operation, outputting target prompt information, the target prompt information being used for representing upgrading state information of the plurality of to-be-upgraded devices. The upgrading method of the embedded device of the application realizes a zero-operation threshold of plug-and-play, is simple to operate, improves operation and maintenance efficiency, solves a state sensing problem in a vehicle-mounted environment in a screen-free voice interaction mode, and improves user experience.

Description

Technical Field

[0001] This application belongs to the field of firmware upgrade technology, and in particular relates to an upgrade method, apparatus and electronic device for embedded devices. Background Technology

[0002] Currently, in-vehicle systems require regular updates and maintenance of the underlying firmware of domain controllers (such as MCU (Microcontroller Unit), SOC (System on Chip), Switch, and TBOX (Telematics Box) modules) and application software during operation. Traditional firmware update methods require on-site safety personnel to possess relevant skills, such as flashing cables and undergoing training. The operation is complex and time-consuming, affecting maintenance efficiency and presenting a high technical barrier. Summary of the Invention

[0003] This invention aims to solve at least one of the technical problems existing in the prior art. To this end, this invention proposes an upgrade method, apparatus, and electronic device for embedded devices, achieving plug-and-play operation with zero operational barriers. This allows non-technical personnel to complete the upgrade automatically simply by inserting an external storage device, without the need for training or specialized equipment. The operation is simple, improving maintenance efficiency. Furthermore, the screenless voice interaction method solves the problem of status perception in the in-vehicle environment, enhancing the user experience.

[0004] In a first aspect, this application provides an upgrade method for an embedded device, applied to the domain controller of the embedded device, the method comprising: In response to an access event from an external storage device, upgrade data is obtained from the external storage device; If an upgrade operation is determined to be required based on the upgrade data and local historical data, an upgrade operation is performed on multiple devices to be upgraded based on the configuration information in the upgrade data, wherein the multiple devices to be upgraded are determined based on the upgrade data; In response to the upgrade operation, a target prompt message is output, which is used to characterize the upgrade status information of the plurality of devices to be upgraded.

[0005] The embedded device upgrade method provided in this application automatically triggers the upgrade process and obtains upgrade data when an external storage device is connected. Then, when an upgrade is needed, the device to be upgraded is upgraded according to the configuration information in the upgrade data. During the upgrade process, voice prompts and other prompts representing the upgrade status information can be output in real time. This achieves plug-and-play with zero operational threshold, allowing non-technical personnel to complete the upgrade automatically without training or professional equipment by simply inserting an external storage device. The operation is simple, improving maintenance efficiency. The screenless voice interaction method solves the status perception problem in the vehicle environment and enhances the user experience.

[0006] An embodiment of the embedded device upgrade method of this application, wherein the upgrade operation is performed on multiple devices to be upgraded based on the configuration information in the upgrade data, including: Based on the configuration information in the upgrade data, obtain the identification information, upgrade file and integrity verification value corresponding to each of the devices to be upgraded; Based on the integrity check values, perform integrity checks on each of the upgrade files to obtain the corresponding check results. If the integrity verification is successful based on the verification result, an upgrade file corresponding to each of the devices to be upgraded is sent to each of the devices to be upgraded in order to perform an upgrade operation on the multiple devices to be upgraded.

[0007] An embodiment of the embedded device upgrade method of this application includes sending an upgrade file corresponding to each of the devices to be upgraded, comprising: Obtain the upgrade execution order corresponding to the multiple devices to be upgraded; Based on the upgrade execution order, upgrade files corresponding to each of the devices to be upgraded are sent to each of the devices to be upgraded.

[0008] An embodiment of the embedded device upgrade method of this application, wherein determining that an upgrade operation needs to be performed based on the upgrade data and local historical data includes: Obtain the identification information of the upgrade data; If the identification information of the upgrade data is inconsistent with the identification information of the local historical data, it is determined that an upgrade operation needs to be performed, and the upgrade data is stored locally.

[0009] An embodiment of the embedded device upgrade method of this application, wherein the step of outputting target prompt information in response to the upgrade operation includes: During the upgrade operation, the target prompt information is output at a preset upgrade status node. The preset upgrade status node includes at least one of the following: upgrade of each device to be upgraded begins, upgrade of each device to be upgraded is successful, upgrade of each device to be upgraded fails, all upgrades are successful, and all upgrades fail.

[0010] An embodiment of the embedded device upgrade method of this application, after outputting target prompt information in response to the upgrade operation, the method includes: Based on the upgrade execution results of each of the aforementioned devices to be upgraded, a system recovery operation is performed.

[0011] An embodiment of the embedded device upgrade method of this application, wherein the system recovery operation is performed based on the upgrade execution results of each of the devices to be upgraded, includes: If all the devices to be upgraded are successfully upgraded, the system boot partition is switched to the backup partition, and the system is restarted. If any of the multiple devices to be upgraded fail to upgrade, the current system startup partition remains unchanged, and the system is restarted.

[0012] An embodiment of the embedded device upgrade method of this application further includes: In the event that the upgrade of each of the aforementioned devices has started, succeeded, or failed, upgrade status information corresponding to the device to be upgraded is sent to the remote server.

[0013] Secondly, this application provides an upgrade apparatus for an embedded device, applied to the domain controller of the embedded device, the apparatus comprising: The first processing module is used to obtain upgrade data from the external storage device in response to an access event of the external storage device; The second processing module is used to perform upgrade operations on multiple devices to be upgraded based on the configuration information in the upgrade data when it is determined that an upgrade operation needs to be performed based on the upgrade data and local historical data. The multiple devices to be upgraded are determined based on the upgrade data. The third processing module is used to respond to the upgrade operation and output target prompt information, which is used to characterize the upgrade status information of the plurality of devices to be upgraded.

[0014] The embedded device upgrade apparatus provided in the embodiments of this application automatically triggers the upgrade process and obtains upgrade data when an external storage device is connected. Then, when an upgrade is required, the device to be upgraded is upgraded according to the configuration information in the upgrade data. During the upgrade process, voice prompts and other prompts that represent upgrade status information can be output in real time. This achieves plug-and-play with zero operational threshold, allowing non-technical personnel to complete the upgrade automatically without training or professional equipment by simply inserting an external storage device. The operation is simple and improves maintenance efficiency. The screenless voice interaction method solves the status perception problem in the vehicle environment and improves the user experience.

[0015] Thirdly, this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the embedded device upgrade method described in the first aspect above.

[0016] The above-described one or more technical solutions in the embodiments of this application have at least one of the following technical effects: By automatically triggering the upgrade process and acquiring upgrade data when an external storage device is connected, the system can then perform upgrade operations on the device to be upgraded based on the configuration information in the upgrade data when an upgrade is needed. During the upgrade process, it can output voice prompts and other prompts to represent upgrade status information in real time. This achieves plug-and-play operation with zero operational threshold, allowing non-technical personnel to complete the upgrade automatically without training or professional equipment, simply by inserting an external storage device. The operation is simple and improves operation and maintenance efficiency. With a screenless voice interaction method, it solves the status perception problem in the vehicle environment and enhances the user experience.

[0017] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0018] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 This is one of the flowcharts illustrating the method for upgrading an embedded device provided in this application embodiment; Figure 2 This is a second schematic flowchart of the embedded device upgrade method provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of the upgrade device for the embedded device provided in the embodiments of this application; Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0019] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0020] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0021] The following description, in conjunction with the accompanying drawings, details the embedded device upgrade method, embedded device upgrade apparatus, electronic device, and readable storage medium provided in this application through specific embodiments and application scenarios.

[0022] Among them, the upgrade method for embedded devices can be applied to the terminal, and can be executed by the hardware or software in the terminal.

[0023] The embedded device upgrade method provided in this application embodiment can be executed by an electronic device or a functional module or functional entity in an electronic device that can implement the embedded device upgrade method. The electronic devices mentioned in this application embodiment include, but are not limited to, mobile phones, tablets, computers, cameras and wearable devices. The embedded device upgrade method provided in this application embodiment will be described below using an electronic device as the execution subject as an example.

[0024] like Figure 1 As shown, the upgrade method for the embedded device includes steps 110, 120 and 130.

[0025] It should be noted that this method for upgrading embedded devices can be applied to the domain controllers of embedded devices. The embedded devices may include in-vehicle computing platforms, including domain controllers and their peripheral sensor / actuator modules. The embedded devices can be deployed in a fleet of vehicles and require regular firmware maintenance.

[0026] The domain controller can be an automotive domain control unit (ADCU), which serves as the computing center of the entire vehicle and can perform functions such as sensor fusion, decision planning, and vehicle control.

[0027] In this application, the entire upgrade process can be completed autonomously based on the domain controller without the need for external computing devices (such as laptops or dedicated flashing devices).

[0028] Step 110: In response to the access event of the external storage device, obtain upgrade data from the external storage device; In this step, the external storage device can include a portable hard drive or a USB flash drive, and can store firmware upgrade packages. The external storage device can use a USB (Universal Serial Bus) interface, supports hot-swapping, and requires no additional power supply or driver.

[0029] When an external storage device is manually plugged into the domain controller's USB port, the domain controller can detect the access event of the external storage device.

[0030] In some embodiments, the domain controller can recognize ordinary USB flash drives / external hard drives mapped to SCSI disk device names (such as / dev / sda1) via standard USB storage drives, and can also recognize virtual block devices (such as / dev / vblkdev0, / dev / vblkdev1) created by software or virtualization layers on specific embedded platforms (such as NVIDIA DRIVE AGX Xavier / Pegasus).

[0031] Domain controllers can monitor block device events of the USB subsystem in real time through the Linux udev (Userspace Device Management) mechanism. In practice, a predefined udev rule file (100-fota-storage-detect.rules) is loaded at system startup. Rules listen for ACTION=="add", KERNEL=="sd", or KERNEL=="vblkdev". Upon successful matching, a detection script is asynchronously invoked via systemd-run --no-block. This monitoring method has low resource consumption, high response speed, and does not block other system services.

[0032] The domain controller can automatically identify device partitions and file system types (supporting exFAT / FAT32 / NTFS), mount the device to an accessible path (such as / media, / mnt, / run / media), and scan predefined format files (.tar.gz compressed packages) in the preset directory ( / fota / ) to identify them as upgrade data packages.

[0033] In actual implementation, automatic device insertion detection and identification can be achieved based on the following steps: The built-in udev monitoring function of the Linux system can be used to monitor peripheral insertions, automatically identify the insertion type, and automatically launch the upgrade script. The udev rule file (100-fota-storage-detect.rules) is loaded at system startup. The rules monitor block device (block subsystem) insertion events (ACTION=="add"), supporting traditional SD devices (KERNEL=="sd*") and virtual block devices (KERNEL=="vblkdev*"). The detection script is executed asynchronously using `systemd-run --no-block` to avoid blocking system mount operations. The device file system type can be detected using: `fstype=$(blkid -s TYPE -o value "$device")`. If the entire disk has no file system, partitions are automatically detected. `lsblk` is used to identify partitions, recursively processing each partition. First, check if the device is automatically mounted (in directories such as / media, / mnt, / run / media). If it is not mounted, you can try mounting it using various mount options (ro, nosuid, nodev, noexec → ro → ro, user). It supports multiple file system types such as exFAT, FAT32, and NTFS.

[0034] Step 120: If it is determined that an upgrade operation needs to be performed based on the upgrade data and local historical data, upgrade operations are performed on multiple devices to be upgraded based on the configuration information in the upgrade data. The multiple devices to be upgraded are determined based on the upgrade data. In this step, the local historical data refers to the upgrade package files that have been persistently saved in the local storage area of ​​the domain controller (such as / opt / update / fota / ) and have been successfully upgraded in the past.

[0035] The domain controller can independently determine whether the currently inserted upgrade package is an older version that has already been flashed.

[0036] The domain controller can automatically extract the upgrade package file name (such as fota_v1.0.0.tar.gz) and perform a string comparison with all historical upgrade package file names stored locally. Based on the comparison results, it can determine whether an upgrade operation needs to be performed.

[0037] The configuration information is a structured configuration file included in the upgrade package, which includes the target hardware platform identifier (such as ADCU1 / ADCU2), the list of modules to be upgraded (MCU, SOC, Switch, TBOX or ANY, etc.), the firmware file path of each module (relative to the path in the package), the MD5 checksum of each module's firmware, and other optional parameters (such as flashing timeout, number of retries, and dependencies).

[0038] Multiple devices to be upgraded can be the underlying firmware of the domain controller, such as at least multiple modules in MCU, SOC, Switch and TBOX, and can also include extended ANY custom modules, etc.

[0039] Multiple devices to be upgraded can be heterogeneous processors or controller units that are internal to the domain controller or external to it, with different instruction set architectures, different communication interfaces, and different flashing protocols.

[0040] The system can dynamically determine the devices to be upgraded based on the configuration file in the upgrade package. For example, if an upgrade only requires updating the MCU and SOC, then only entries for these two modules will appear in the configuration file; if another upgrade requires a full update, then all modules will appear. This allows the same upgrade software to adapt to upgrade packages with different content, eliminating the need to release a new version of the domain controller firmware for each upgrade.

[0041] Step 130: In response to the upgrade operation, output the target prompt message.

[0042] In this step, the target prompt information may include voice prompts, etc.

[0043] For example, a domain controller can play pre-recorded .wav (Waveform Audio File Format) audio files as audio signals via an external USB speaker. Alternatively, the `aplay` command in the Linux ALSA (Advanced Linux Sound Architecture) system can be used to stream PCM (Pulse Code Modulation) data to a USB audio device. By utilizing the vehicle's standard USB speaker (used for human-machine interaction), no additional hardware costs are required.

[0044] The target prompt information is used to characterize the upgrade status information of multiple devices to be upgraded (e.g., module upgrade successful and module upgrade failed). The target prompt information can directly inform the on-site safety officer of the specific event that is currently happening. For example, playing "MCU upgrade successful" means that the MCU module has been fully written and verified; playing "SOC upgrade failed" means that the SOC module has encountered a writing error and the system will enter the rollback process.

[0045] In this application, the security officer does not need any technical training. He only needs to insert an external storage device, and the system will automatically start the upgrade process, eliminating the dependence on PCs, dedicated flashing cables, driver software, or technical manuals.

[0046] By outputting target prompts, which can be voice prompts, the system can solve problems such as unreadable screens in bright in-vehicle environments, poor visibility at a distance, or distraction during multitasking. This allows safety drivers to intuitively understand the upgrade progress and status, improving driving safety and user experience. Furthermore, the voice broadcast design enables non-technical personnel to clearly understand the status and error prompts, improving on-site feedback efficiency.

[0047] The embedded device upgrade method provided in this application automatically triggers the upgrade process and obtains upgrade data when an external storage device is connected. Then, when an upgrade is needed, the device to be upgraded is upgraded according to the configuration information in the upgrade data. During the upgrade process, voice prompts and other prompts representing the upgrade status information can be output in real time. This achieves plug-and-play with zero operational threshold, allowing non-technical personnel to complete the upgrade automatically without training or professional equipment by simply inserting an external storage device. The operation is simple, improving maintenance efficiency. The screenless voice interaction method solves the status perception problem in the vehicle environment and enhances the user experience.

[0048] In some embodiments, step 120 may include: Based on the configuration information in the upgrade data, obtain the identification information, upgrade file and integrity verification value corresponding to each device to be upgraded; Based on each integrity check value, perform integrity checks on each upgrade file to obtain the corresponding integrity check results; If the integrity verification is successful based on the verification results, an upgrade file corresponding to each device to be upgraded is sent to each device to be upgraded in order to perform upgrade operations on multiple devices.

[0049] In this embodiment, the domain controller can call a YAML parsing library (such as libyaml) to deserialize the file content into an in-memory object. The parsing process includes defensive programming measures such as syntax checking, required field validation, and type conversion. If a formatting error is encountered, the upgrade will immediately terminate and a failure message will be played.

[0050] The identification information is the field key name in the configuration file used to uniquely identify the device to be upgraded. For example, firmware information for each module can be extracted: MCU module: mcu_file+mcu_md5; SOC module: soc_file+soc_md5; Switch module: switch_file+switch_md5; TBOX module: tbox_file+tbox_md5; ANY module: any_file+any_md5.

[0051] Identification information may include module name, subtype, hardware version or region identifier, etc., to support firmware selection for different variants of the same module.

[0052] The upgrade files are firmware binary images corresponding to each module. For example, MCU firmware is usually in .hex or .s19 format (Intel Hex or Motorola S-record), SOC firmware is an ext4 image or a sparse image, and Switch firmware is a .bin pure binary. These files and configuration files are packaged together in a .tar.gz archive, which is accessed by relative path after unpacking.

[0053] The integrity verification value is the MD5 message digest that corresponds to each firmware file in the configuration file, and its length can be a 32-byte hexadecimal string. Using the MD5 algorithm as a transmission integrity verification tool is fast and has an extremely low collision probability, which can meet the needs of firmware upgrade scenarios.

[0054] The domain controller can open the firmware file in binary read-only mode, use the MD5 algorithm to calculate its 128-bit hash value, and compare the calculation result with the MD5 value declared in the configuration file in a constant-time string comparison.

[0055] The validation result can be either pass (match) or fail (no match).

[0056] If the integrity verification fails, the upgrade process for that device can be skipped without affecting the upgrades of other devices (e.g., if the MCU verification fails, the SOC can still continue to be upgraded). The system can record failure logs, report the corresponding status codes, and play a voice message indicating that the module upgrade failed.

[0057] The digital signatures and certificates required during the verification process are determined based on an automatic selection mechanism, ensuring security and compliance.

[0058] The domain controller can call the dedicated flash adapters corresponding to each module to transfer firmware data to the target hardware. The modular adapter design (DriveUpdate, MCU, Lidar, Camera, and Switch) facilitates expansion to new hardware and offers good scalability.

[0059] For example, MCU upgrades involve calling `flash_mcu()` (low-level erase / write), `swap_mcu()` (partition switching), and `dscudp_get_mcubank()` (current bank lookup). The communication protocol is I2C / SPI or UDS on CAN.

[0060] SOC upgrade: Call flash_soc() to directly write to the / dev / device node (e.g., / dev / mmcblk0p3). The communication protocol is SDIO / eMMC.

[0061] Switch upgrade: Call flash_switch_all() to access the switch registers via MDIO / I2C and write the firmware.

[0062] TBOX Upgrade: Call flash_tbox() to connect to the TBOX internal upgrade service port via TCP / IP and transfer firmware based on HTTP / TFTP.

[0063] In some embodiments, sending an upgrade file corresponding to each device to be upgraded may include: Obtain the upgrade execution order for multiple devices to be upgraded; Based on the upgrade execution order, upgrade files corresponding to each device to be upgraded are sent to each device to be upgraded.

[0064] In this embodiment, the upgrade execution order refers to the order in which the modules are flashed. The upgrade execution order can be determined based on system startup dependencies. For example, the MCU provides basic timing, watchdog timer, and power management, and should be upgraded first. The SOC relies on the MCU's stable clock and reset control, and should be upgraded next. The Switch is an Ethernet backplane, and its upgrade process may cause network interruptions, so it should be placed during non-critical periods. The TBOX is the vehicle-to-cloud communication unit and can be upgraded last.

[0065] Alternatively, the upgrade execution order can be determined by specifying it in the configuration file (e.g., adding fields such as order: 1, order: 2, etc. in YAML), the default order built into the code (e.g., array index defined by enumeration type), or dynamic dependency resolution (e.g., reading the depends_on field declared by each module and generating the execution sequence by topological sorting). This application does not impose any restrictions on this method.

[0066] It can perform upgrade operations on multiple devices in sequence, avoiding problems such as power transient drops, bus arbitration conflicts and thermal overload caused by simultaneous flashing of multiple modules.

[0067] In some embodiments, determining the need for an upgrade operation based on upgrade data and local historical data may include: Obtain the identification information of the upgrade data; If the identification information of the upgrade data is inconsistent with the identification information of the local historical data, it is determined that an upgrade operation needs to be performed, and the upgrade data is stored locally.

[0068] In this embodiment, the identification information of the upgrade data is the complete basic name of the upgrade package file. For example, it can scan the .tar.gz format files under the / fota / directory, then extract the package file name and record it in the log. For example, the file name is fota_v1.0.0.tar.gz, and the identification information is fota_v1.0.0.

[0069] If the string in the upgrade data is different from the string in the local historical data, the upgrade data is determined to be the new version.

[0070] You can copy the .tar.gz package completely to the persistent storage partition of the domain controller (such as / opt / update / fota / archive / ), preserving the original filename and modification timestamp.

[0071] If the identifier information of the upgraded data is consistent with the identifier information of the local historical data, it is determined that no upgrade is needed, no flashing operation is performed, and the "no update, exit" voice message can be played directly, thus ending the process.

[0072] In actual execution, directory structure identification is performed: The system checks if the ` / fota / ` directory exists under the mount point. If it does, it's identified as a dedicated FOTA upgrade disk, and a voice prompt "Upgrade package detected" is played. Then, upgrade package file scanning is performed: .tar.gz files under the ` / fota / ` directory are scanned, package filenames are extracted, and logged. Next, intelligent version detection is performed: Before copying the upgrade package to the local directory, it checks if a package with the same name already exists locally. If the package name is the same, it's considered the same version, the upgrade is skipped, and a "No update, exit" voice prompt is played. If the package name is different, it's considered a new version, and the upgrade process continues. After the upgrade, the local package file is retained for subsequent version comparison. Finally, integrity verification is performed: The upgrade package contains a `package_config.yaml` configuration file. The configuration is parsed to obtain the firmware file paths and MD5 checksums for each module. An MD5 checksum is performed on each module's firmware to ensure file integrity.

[0073] The embedded device upgrade method provided in the embodiments of this application compares the identification information of the upgrade data with the identification information of the local historical data, and performs the upgrade operation when the two are inconsistent. This can automatically identify the upgrade package version, avoid repeated upgrades, and improve upgrade efficiency and device lifespan.

[0074] In some embodiments, step 130 may include: During the upgrade operation, target prompt information is output at preset upgrade status nodes. The preset upgrade status nodes include at least one of the following: upgrade of each device to be upgraded has started, upgrade of each device to be upgraded has been successful, upgrade of each device to be upgraded has failed, all upgrades have been successful, and all upgrades have failed.

[0075] In this embodiment, during the upgrade operation, that is, within the time window from the start of the upgrade of the first device to be upgraded to the end of the upgrade of the last device, the target prompt information can be output at the preset upgrade status node.

[0076] Preset upgrade status nodes refer to the hard-coded locations in the upgrade engine code. When the program execution flow passes through these locations, the asynchronous voice playback task is triggered.

[0077] The upgrade process for each device to be upgraded has begun. For example, it can output a prompt indicating that the MCU is being upgraded, as well as status codes 351 / 353 / 357 / 355 (INSTALLING).

[0078] Each device to be upgraded has been successfully upgraded, for example, the corresponding module *_upgrade_successful.wav, with status codes 250 / 251 / 253 / 252 (SUCCESS).

[0079] Each device to be upgraded failed to upgrade, corresponding to the module *_upgrade_failed.wav, with status codes 450 / 451 / 453 / 452 (FAILED).

[0080] All upgrades were successful. After all upgrades were reported in upgrade_successful_restart_orin.wav with status codes 250 / 251 / 253 / 252, the overall status is SUCCESS.

[0081] All upgrades failed, corresponding to upgrade_failed_restart_orin.wav, with status codes 404 (INSTALL_FAILED) or 400 (ALL_FAILED).

[0082] In some embodiments, after step 130, the method may include: Based on the upgrade results of each device to be upgraded, a system recovery operation is performed.

[0083] In this embodiment, the upgrade execution result can be determined based on the upgrade result of each module. For example, if all devices to be upgraded are successfully upgraded, the upgrade execution result can be determined as successful. If any device to be upgraded fails to upgrade, the upgrade execution result can be determined as unsuccessful.

[0084] Based on the upgrade execution results, you can perform upgrade mode exit and system reset operations.

[0085] In some embodiments, performing a system recovery operation based on the upgrade execution results of each device to be upgraded may include: If multiple devices to be upgraded have been successfully upgraded, switch the system boot partition to the backup partition and control the system to restart. If there are devices among the multiple devices to be upgraded that have failed to be upgraded, keep the current boot partition of the system unchanged and restart the system.

[0086] In this embodiment, the system boot partition refers to two independently addressed system partitions in the domain controller's flash memory, named side A (active bank) and side B (inactive bank) respectively. The currently running system is located on side A, and the upgrade package is written to side B.

[0087] For example, if multiple devices to be upgraded have been successfully upgraded, the default boot partition after the next reset can be set to side B by modifying the BootLoader environment variable (such as boot_partition=1) or manipulating hardware registers (such as GPIO / General Purpose Input Output, general input / output level selection).

[0088] You can invoke the hardware watchdog to reset or the system to restart. For example, you can pull a specified GPIO pin high for 5 seconds to trigger the PMIC (Power Management Integrated Circuit) hardware to power down and then power on again.

[0089] If there are devices that have failed to upgrade among multiple devices to be upgraded, the BootLoader variable does not need to be modified, and the next boot will still boot from the old version partition before the upgrade.

[0090] For example, if all modules succeed, a success message can be played, the SWITCH state can be entered, the program can be switched to start the A / B side, and gpio_reset(5) can be executed to restart; if a single module fails, the module failure status can be reported, the overall failure (404 / 400) can be reported, a failure message can be played, the SWITCH state can be skipped, the program can be switched to start the A / B side without switching, and gpio_reset(5) can be executed to restart.

[0091] In this application, by setting up multi-level integrity verification, dependency detection, A / B partition switching and rollback, it can be ensured that when the upgrade fails, there is no need to restore the image from the outside, no need to enter the maintenance mode, no need for manual intervention, and the vehicle can be automatically rolled back to the state before the upgrade upon restart, so that the vehicle can resume operation immediately and reduce the risk of vehicle downtime.

[0092] In some embodiments, the method may further include: When an upgrade begins, succeeds, or fails, the system sends upgrade status information corresponding to the device to be upgraded to the remote server.

[0093] In this embodiment, the remote server refers to an MQTT Broker (such as EMQX or Mosquitto) deployed in the cloud, and the domain controller can act as an MQTT client to connect to a specified Topic (such as / fota / vehicle / {vin} / status).

[0094] Upgrade status information refers to the status payload in JSON format, which may include: vin (Vehicle Identification Number), module (MCU / SOC / Switch / TBOX), status (installing / success / failed), code (351 / 250 / 450, etc.), timestamp (ISO8601 timestamp), and version (upgrade package version number), etc.

[0095] Each module can generate an independent status message at each status node.

[0096] In actual execution, firmware upgrades for multiple modules can be performed based on the following steps: Configuration parsing: Parse package_config.yaml and select the corresponding configuration according to the ADCU type (ADCU1 / ADCU2). Extract firmware information for each module: MCU module: mcu_file+mcu_md5; SOC module: soc_file+soc_md5; Switch module: switch_file+switch_md5; TBOX module: tbox_file+tbox_md5; ANY module: any_file+any_md5.

[0097] Upgrade process state machine: Status reporting: Upgrade sequentially according to configuration. When each module upgrade starts / successfully / fails, the status code is reported via MQTT: MCU: 351 (INSTALLING) → 250 (SUCCESS) / 450 (FAILED), SOC: 353 (INSTALLING) → 251 (SUCCESS) / 451 (FAILED), Switch: 357 (INSTALLING) → 253 (SUCCESS) / 453 (FAILED), TBOX: 355 (INSTALLING) → 252 (SUCCESS) / 452 (FAILED), Overall status: 404 (INSTALL_FAILED) → 400 (ALL_FAILED) → Automatic restart.

[0098] Modular upgrade execution: MCU upgrade: call flash_mcu()+swap_mcu()+dscudp_get_mcubank(), SOC upgrade: call flash_soc() (directly write to / dev / device node), Switch upgrade: call flash_switch_all(), TBOX upgrade: call flash_tbox() (connect to TBOX upgrade server via TCP / IP).

[0099] Failure handling mechanism: Single module failure: Report module failure status → Report overall failure (404 / 400) → Play failure voice message → Skip SWITCH state, start A / B side without switching programs → Execute gpio_reset(5) to restart. If all modules succeed: Play success voice message → Enter SWITCH state, switch programs to start A / B side → Execute gpio_reset(5) to restart.

[0100] Voice broadcast status prompt: Environment variable control mechanism: Setting the FOTA_USB_UPGRADE_MODE=1 environment variable enables voice broadcast. Voice broadcast is only executed in USB flash drive upgrade mode and is silent in MQTT upgrade mode to avoid voice interference during normal MQTT upgrade.

[0101] Voice type mapping: Module upgrade is successful: mcu_upgrade_successful.wav / soc_upgrade_successful.wav / , switch_upgrade_successful.wav / tbox_upgrade_successful.wav.

[0102] Module upgrade failed: mcu_upgrade_failed.wav / soc_upgrade_failed.wav / , switch_upgrade_failed.wav / tbox_upgrade_failed.wav.

[0103] Overall results: upgrade_successful_restart_orin.wav / , upgrade_failed_restart_orin.wav.

[0104] Device detection: detected_upgrade_package.wav / no_updates_exit.wav.

[0105] When an upgrade package is detected, the system can play "Upgrade package detected"; when skipping the same version, it can play "Exit without updates"; when each module upgrade is completed / failed, it can play the corresponding module's voice message; when the overall upgrade is completed / failed, it can play the overall result voice message; the system can play the message in real time via a USB speaker (using the aplay command), allowing the safety operator to understand the upgrade status without having to look at the screen.

[0106] Status reporting and logging: MQTT status reporting: Status codes are reported to the MQTT server in real time during the upgrade process, supporting remote monitoring of the upgrade progress. Local logging: All operations are recorded in / opt / update / log / fota_service / fota-storage-check.log, including timestamps, operation types, execution results, and other detailed information.

[0107] The following section uses the upgrading of MCU, SOC, Switch, and TBOX modules as examples to specifically illustrate the upgrade method for embedded devices provided in this application.

[0108] like Figure 2As shown, the security officer inserts a portable hard drive containing package_config.yaml and firmware for the MCU, SOC, Switch, and TBOX modules, triggering the Linux udev event listener. The system automatically mounts the devices and scans for .tar.gz upgrade packages in the / fota / directory; it plays a "Upgrade data detected" message, then performs version comparison, checking the package name (i.e., the identifier information of the upgrade data). If the package name matches the local historical data package name, it plays a "No update, exit" message and terminates the process directly; if it is a new version, it copies the upgrade data to the local machine, parses the package_config.yaml configuration file, obtains the firmware paths and MD5 values ​​of the MCU, SOC, Switch, and TBOX modules, and performs MD5 integrity verification on each firmware file in turn; after successful verification, it calls flash_mcu(), flash_... The upgrade is performed by soc(), flash_switch_all() and flash_tbox(). Each module can report a status code via MQTT when the upgrade is started, successful or failed, and broadcast the corresponding module-level voice through the USB speaker (such as "MCU upgrade successful", or the prompt can be omitted, which can be configured according to user needs, and this application does not limit it). After all modules are completed, the results are aggregated. If all are successful, the A / B partition is switched to the spare partition and a successful restart voice is broadcast. If any module fails, the partition is not switched and a failure restart voice is broadcast. Finally, gpio_reset(5) is called to trigger the system restart, realizing the automatic closed loop of the upgrade process and fault self-healing.

[0109] During version comparison, if the security officer inserts upgrade package A (package name: fota_v1.0.0.tar.gz), the system detects that there is no package with the same name locally, performs the upgrade, and keeps a local copy. If the security officer inserts upgrade package A with the same name again, the system detects that a package with the same name already exists locally, plays a "no updates, exit" voice message, and skips the upgrade. If the security officer inserts upgrade package B (package name: fota_v1.0.1.tar.gz), the system detects that the package name is different, determines that it is the new version, and performs the upgrade.

[0110] The embedded device upgrade method provided in this application can be executed by an embedded device upgrade device. This application uses an embedded device upgrade device executing the embedded device upgrade method as an example to illustrate the embedded device upgrade device provided in this application.

[0111] This application also provides an upgrade device for an embedded device, applied to the domain controller of the embedded device.

[0112] like Figure 3As shown, the upgrade device for the embedded device includes: a first processing module 310, a second processing module 320, and a third processing module 330.

[0113] The first processing module 310 is used to obtain upgrade data from the external storage device in response to the access event of the external storage device; The second processing module 320 is used to perform upgrade operations on multiple devices to be upgraded based on the configuration information in the upgrade data when it is determined that an upgrade operation needs to be performed based on the upgrade data and local historical data. The multiple devices to be upgraded are determined based on the upgrade data. The third processing module 330 is used to respond to the upgrade operation and output target prompt information, which is used to characterize the upgrade status information of multiple devices to be upgraded.

[0114] The embedded device upgrade apparatus provided in the embodiments of this application automatically triggers the upgrade process and obtains upgrade data when an external storage device is connected. Then, when an upgrade is required, the device to be upgraded is upgraded according to the configuration information in the upgrade data. During the upgrade process, voice prompts and other prompts that represent upgrade status information can be output in real time. This achieves plug-and-play with zero operational threshold, allowing non-technical personnel to complete the upgrade automatically without training or professional equipment by simply inserting an external storage device. The operation is simple and improves maintenance efficiency. The screenless voice interaction method solves the status perception problem in the vehicle environment and improves the user experience.

[0115] In some embodiments, the second processing module 320 may also be used for: Based on the configuration information in the upgrade data, obtain the identification information, upgrade file and integrity verification value corresponding to each device to be upgraded; Based on each integrity check value, perform integrity checks on each upgrade file to obtain the corresponding integrity check results; If the integrity verification is successful based on the verification results, an upgrade file corresponding to each device to be upgraded is sent to each device to be upgraded in order to perform upgrade operations on multiple devices.

[0116] In some embodiments, the second processing module 320 may also be used for: Obtain the upgrade execution order for multiple devices to be upgraded; Based on the upgrade execution order, upgrade files corresponding to each device to be upgraded are sent to each device to be upgraded.

[0117] In some embodiments, the second processing module 320 may also be used for: Obtain the identification information of the upgrade data; If the identification information of the upgrade data is inconsistent with the identification information of the local historical data, it is determined that an upgrade operation needs to be performed, and the upgrade data is stored locally.

[0118] In some embodiments, the third processing module 330 can also be used for: During the upgrade operation, target prompt information is output at preset upgrade status nodes. The preset upgrade status nodes include at least one of the following: upgrade of each device to be upgraded has started, upgrade of each device to be upgraded has been successful, upgrade of each device to be upgraded has failed, all upgrades have been successful, and all upgrades have failed.

[0119] In some embodiments, the upgrade apparatus of the embedded device may include a fourth processing module, which, after outputting target prompt information in response to the upgrade operation, performs a system recovery operation based on the upgrade execution results of each device to be upgraded.

[0120] In some embodiments, the fourth processing module can also be used for: If multiple devices to be upgraded have been successfully upgraded, switch the system boot partition to the backup partition and control the system to restart. If there are devices among the multiple devices to be upgraded that have failed to be upgraded, keep the current boot partition of the system unchanged and restart the system.

[0121] In some embodiments, the upgrade apparatus for the embedded device may include a fifth processing module for: When an upgrade begins, succeeds, or fails, the system sends upgrade status information corresponding to the device to be upgraded to the remote server.

[0122] The upgrade device for the embedded device in this application embodiment can be an electronic device or a component within an electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other devices besides a terminal. For example, the electronic device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. It can also be a server, network attached storage (NAS), personal computer (PC), television (TV), ATM, or self-service machine, etc. This application embodiment does not specifically limit the scope of the device.

[0123] The upgrade device for the embedded device in this application embodiment can be a device with an operating system. This operating system can be a Microsoft (Windows) operating system, an Android operating system, an iOS operating system, or other possible operating systems; this application embodiment does not specifically limit the specific operating system.

[0124] The embedded device upgrade device provided in this application embodiment can achieve... Figures 1 to 2 The various processes implemented in the method implementation examples will not be described again here to avoid repetition.

[0125] In some embodiments, such as Figure 4 As shown, this application embodiment also provides an electronic device 400, including a processor 401, a memory 402, and a computer program stored in the memory 402 and executable on the processor 401. When the program is executed by the processor 401, it implements the various processes of the above-described embedded device upgrade method embodiment and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0126] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0127] This application also provides a non-transitory computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the various processes of the above-described embedded device upgrade method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0128] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0129] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method for upgrading an embedded device.

[0130] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0131] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described embedded device upgrade method embodiment and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0132] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0133] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0134] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the related technology, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0135] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

[0136] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0137] Although embodiments of this application have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of this application, the scope of which is defined by the claims and their equivalents.

Claims

1. A method for upgrading an embedded device, characterized in that, The method, applied to the domain controller of the embedded device, includes: In response to an access event from an external storage device, upgrade data is obtained from the external storage device; If an upgrade operation is determined to be required based on the upgrade data and local historical data, an upgrade operation is performed on multiple devices to be upgraded based on the configuration information in the upgrade data, wherein the multiple devices to be upgraded are determined based on the upgrade data; In response to the upgrade operation, a target prompt message is output, which is used to characterize the upgrade status information of the plurality of devices to be upgraded.

2. The method for upgrading an embedded device according to claim 1, characterized in that, The upgrade operation, based on the configuration information in the upgrade data, for multiple devices to be upgraded includes: Based on the configuration information in the upgrade data, obtain the identification information, upgrade file and integrity verification value corresponding to each of the devices to be upgraded; Based on the integrity check values, perform integrity checks on each of the upgrade files to obtain the corresponding check results. If the integrity verification is successful based on the verification result, an upgrade file corresponding to each of the devices to be upgraded is sent to each of the devices to be upgraded in order to perform an upgrade operation on the multiple devices to be upgraded.

3. The method for upgrading an embedded device according to claim 2, characterized in that, Sending the upgrade file corresponding to each of the devices to be upgraded includes: Obtain the upgrade execution order corresponding to the multiple devices to be upgraded; Based on the upgrade execution order, upgrade files corresponding to each of the devices to be upgraded are sent to each of the devices to be upgraded.

4. The method for upgrading an embedded device according to any one of claims 1-3, characterized in that, The determination of the need for an upgrade operation based on the upgrade data and local historical data includes: Obtain the identification information of the upgrade data; If the identification information of the upgrade data is inconsistent with the identification information of the local historical data, it is determined that an upgrade operation needs to be performed, and the upgrade data is stored locally.

5. The method for upgrading an embedded device according to any one of claims 1-3, characterized in that, In response to the upgrade operation, the target prompt information is output, including: During the upgrade operation, the target prompt information is output at a preset upgrade status node. The preset upgrade status node includes at least one of the following: upgrade of each device to be upgraded begins, upgrade of each device to be upgraded is successful, upgrade of each device to be upgraded fails, all upgrades are successful, and all upgrades fail.

6. The method for upgrading an embedded device according to any one of claims 1-3, characterized in that, After outputting the target prompt information in response to the upgrade operation, the method includes: Based on the upgrade execution results of each of the aforementioned devices to be upgraded, a system recovery operation is performed.

7. The method for upgrading an embedded device according to claim 6, characterized in that, The system recovery operation, based on the upgrade execution results of each of the aforementioned devices to be upgraded, includes: If all the devices to be upgraded are successfully upgraded, the system boot partition is switched to the backup partition, and the system is restarted. If any of the multiple devices to be upgraded fail to upgrade, the current system startup partition remains unchanged, and the system is restarted.

8. The method for upgrading an embedded device according to any one of claims 1-3, characterized in that, Also includes: In the event that the upgrade of each of the aforementioned devices has started, succeeded, or failed, upgrade status information corresponding to the device to be upgraded is sent to the remote server.

9. An upgrade device for an embedded device, characterized in that, A domain controller applied to the embedded device, the device comprising: The first processing module is used to obtain upgrade data from the external storage device in response to an access event of the external storage device; The second processing module is used to perform upgrade operations on multiple devices to be upgraded based on the configuration information in the upgrade data when it is determined that an upgrade operation needs to be performed based on the upgrade data and local historical data. The multiple devices to be upgraded are determined based on the upgrade data. The third processing module is used to respond to the upgrade operation and output target prompt information, which is used to characterize the upgrade status information of the plurality of devices to be upgraded.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the upgrade method for the embedded device as described in any one of claims 1-8.

Images