In-vehicle screen firmware upgrade methods and related equipment

Abstract

This application discloses a method and related equipment for upgrading in-vehicle screen firmware, relating to the field of vehicle networking technology. The method includes: acquiring a screen upgrade data packet pre-installed in the vehicle's infotainment system of the target vehicle; if a vehicle power-on event is detected, acquiring the current version identifier of the in-vehicle screen; determining a version comparison result based on the current version identifier and the target version identifier in the screen upgrade data packet; if the version comparison result indicates that the current version identifier is lower than the target version identifier, performing a firmware upgrade operation on the current screen based on the screen upgrade data packet. This application integrates the screen upgrade data packet with the vehicle infotainment system and performs upgrades on demand based on version comparison after the vehicle is powered on, thereby reducing external dependencies while improving the efficiency, stability, and system version consistency of screen firmware upgrades.

Description

Technical Field

[0001] This application relates to the field of vehicle networking technology, and more specifically, to a method for upgrading firmware for an in-vehicle screen and related equipment. Background Technology

[0002] With the continuous development of automotive electronics and intelligent connected technologies, in-vehicle displays, as an important component of the vehicle system, undertake key functions such as information display and human-machine interaction. Timely firmware upgrades are of great significance for ensuring display effects, system stability, and overall vehicle user experience. Therefore, how to efficiently and reliably complete in-vehicle screen firmware upgrades has become a technical issue that urgently needs attention in the research, development, and maintenance of in-vehicle systems.

[0003] In related technologies, in-vehicle screen firmware upgrades typically rely on independent upgrade processes or obtain upgrade packages through external upgrade channels. During vehicle use, these processes require additional upgrade triggering or network-dependent data delivery. This not only increases the complexity of the upgrade process but also easily leads to upgrade interruptions or repetitive operations in cases of unstable network conditions or upgrade failures, impacting upgrade efficiency and system stability. Furthermore, existing technologies often fail to perform screen version detection and upgrade control at appropriate system operating times, potentially resulting in inappropriate upgrade timing or unreasonable resource consumption. In other words, related technologies suffer from complex in-vehicle screen firmware upgrade processes, high dependence on external resources, and imperfect upgrade timing control and version management, leading to low upgrade efficiency and reliability. Summary of the Invention

[0004] The summary section of this application introduces a series of simplified concepts, which will be further explained in detail in the detailed description section. The summary section of this application is not intended to limit the key features and essential technical features of the claimed technical solution, nor is it intended to determine the scope of protection of the claimed technical solution.

[0005] The vehicle screen firmware upgrade method and related equipment provided in this application can integrate and deploy the screen upgrade data package with the vehicle system, and perform the upgrade on demand based on version comparison after the vehicle is powered on. This can improve the efficiency, stability and system version consistency of screen firmware upgrades while reducing external dependencies.

[0006] In a first aspect, this application provides a method for upgrading the firmware of an in-vehicle screen, applied to a target vehicle, comprising: acquiring a screen upgrade data packet pre-installed in the vehicle infotainment system of the target vehicle, wherein the screen upgrade data packet is integrated into a version data packet of the vehicle infotainment system; if a vehicle power-on event of the target vehicle is detected, acquiring the current version identifier of the in-vehicle screen; determining a version comparison result based on the current version identifier and a target version identifier in the screen upgrade data packet; if the version comparison result indicates that the current version identifier is lower than the target version identifier, performing a firmware upgrade operation on the current screen based on the screen upgrade data packet.

[0007] In some implementations, obtaining the current version identifier of the in-vehicle screen if a vehicle power-on event of the target vehicle is detected includes: detecting the vehicle power status signal of the target vehicle after detecting the vehicle power-on event; and after detecting that the vehicle power status signal meets the preset screen operation conditions for a first preset time, sending a version query request to obtain the current version identifier through the communication interface between the vehicle system and the in-vehicle screen.

[0008] In some implementations, detecting the vehicle power status signal of the target vehicle after detecting the vehicle power-on event includes: detecting the power-on broadcast of the vehicle system after detecting the vehicle power-on event; and acquiring the vehicle power status signal after a second preset duration of the detected power-on broadcast.

[0009] In some implementations, sending a version query request to obtain the current version identifier through the communication interface between the vehicle system and the vehicle screen includes: sending a version query request to the vehicle screen through the communication interface; if no version response information is received from the vehicle screen within a third preset time period, then repeatedly sending the version query request until the cumulative number of times sent reaches a preset number threshold; if the version response information is received before the cumulative number of times sent reaches the preset number threshold, then extracting the current version identifier from the version response information.

[0010] In some implementations, determining the version comparison result based on the current version identifier and the target version identifier in the screen upgrade data package includes: extracting characters from the current version identifier based on a preset extraction location to obtain a supplier identification code; determining the target supplier category corresponding to the vehicle screen based on the supplier identification code; parsing a first numerical version number from the current version identifier and a second numerical version number from the target version identifier based on a preset parsing rule corresponding to the target supplier category; and comparing the first numerical version number with the second numerical version number to obtain the version comparison result.

[0011] In some implementations, performing a firmware upgrade operation on the current screen based on the screen upgrade data package includes: determining the storage path of the target firmware file from the screen upgrade data package based on the target vendor category; copying the target firmware file to a preset temporary storage area of ​​the vehicle system to obtain a local upgrade file; and performing a firmware update on the vehicle screen based on the local upgrade file.

[0012] In some implementations, before obtaining the screen upgrade data package pre-installed in the vehicle infotainment system of the target vehicle, the vehicle screen firmware upgrade method further includes: if a remote upgrade instruction for the vehicle infotainment system is received, obtaining the version data package from the cloud, wherein the screen upgrade data package is encapsulated in the form of an application installation package and is synchronously distributed and stored as an integrated component of the version data package.

[0013] Secondly, this application also provides an in-vehicle screen firmware upgrade device, applied to a target vehicle, comprising: a data acquisition unit, configured to acquire a screen upgrade data packet pre-installed in the vehicle infotainment system of the target vehicle, wherein the screen upgrade data packet is integrated into the version data packet of the vehicle infotainment system; a version acquisition unit, configured to acquire the current version identifier of the in-vehicle screen if a vehicle power-on event of the target vehicle is detected; a version comparison unit, configured to determine a version comparison result based on the current version identifier and a target version identifier in the screen upgrade data packet; and a screen upgrade unit, configured to perform a firmware upgrade operation on the current screen based on the screen upgrade data packet if the version comparison result indicates that the current version identifier is lower than the target version identifier.

[0014] Thirdly, this application also provides an electronic device, including: a memory and a processor, wherein the processor is configured to execute a computer program stored in the memory to implement the steps of the vehicle screen firmware upgrade method described in the first aspect.

[0015] Fourthly, this application also provides a computer-readable storage medium storing computer-executable instructions or a computer program, wherein when the computer-executable instructions or the computer program are executed by a processor, the steps of the vehicle screen firmware upgrade method described in the first aspect are implemented.

[0016] Fifthly, this application also provides a computer program product, including a computer program or computer executable instructions, wherein when the computer program or computer executable instructions are executed by a processor, the steps of the vehicle screen firmware upgrade method provided in the embodiments of this application are implemented.

[0017] In summary, this application integrates the screen upgrade data package into the vehicle system's version data package beforehand and deploys it to the target vehicle along with the vehicle system. This eliminates the need to acquire additional upgrade data packages during vehicle screen firmware upgrades, reducing external dependencies and improving overall upgrade efficiency. By using vehicle power-on as one of the upgrade trigger conditions, the current version identifier of the vehicle screen is only acquired and processed after vehicle power-on is detected. This allows version detection and upgrade operations to be performed while the system is operational, thereby improving the stability and reliability of the screen firmware upgrade process. By comparing the current version identifier of the vehicle screen with the target version identifier in the screen upgrade data package, firmware upgrades are only performed when the current version is lower than the target version, effectively avoiding duplicate or invalid upgrades and reducing system resource consumption. Integrating the screen upgrade data package with the vehicle system version data package and using the target version identifier as the upgrade basis allows the vehicle screen firmware to automatically upgrade to the target version matching the vehicle system after vehicle power-on, which helps maintain overall system version consistency. In summary, the in-vehicle screen firmware upgrade method provided in this application integrates and deploys the screen upgrade data package along with the vehicle system, and performs the upgrade on demand based on version comparison after the vehicle is powered on. This can reduce external dependencies while improving the efficiency, stability, and system version consistency of screen firmware upgrades. Attached Figure Description

[0018] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit this specification. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart illustrating a method for upgrading firmware for an in-vehicle screen, provided in an embodiment of this application; Figure 2 This application provides a schematic diagram of the composition structure of an in-vehicle screen firmware upgrade device according to an embodiment of the present application. Figure 3 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] The terms used in the specification, claims, and drawings of this application, such as "first," "second," "third," "fourth," etc. (if any), are used to distinguish similar objects and not to describe a specific order or sequence. Therefore, it is to be understood that these terms can be used interchangeably where appropriate, allowing the described embodiments to be used in different orders, unless specifically required by the illustrations or description. Furthermore, the terms "is" and "has," and any variations thereof, are intended to cover, non-exclusively, all possible constituent elements. For example, a process, method, system, product, or apparatus comprising several steps or units is not necessarily limited to the steps or units explicitly listed, but may also include other steps or units not explicitly listed, or steps or units inherent to the process, method, product, or apparatus.

[0020] In this application, a "module" or "unit" refers to a computer program or part of a computer program that has a specific function and works in conjunction with other related parts to achieve a predetermined goal. These modules or units can be implemented by software, hardware (e.g., processing circuitry or memory), or a combination of both. One or more processors or memories can implement one or more modules or units. Furthermore, each module or unit can also be part of a larger module or unit.

[0021] The technical solutions of this application will be described in detail below with reference to the accompanying drawings of the embodiments. It should be noted that the described embodiments are only a part of this application, and not all embodiments. In the following description, the "some embodiments" mentioned are only a subset of all possible embodiments, which may be the same or different subsets, and different embodiments can be combined with each other without conflict.

[0022] Figure 1 This is a schematic flowchart illustrating a method for upgrading firmware for an in-vehicle screen according to an embodiment of this application. For example, see [link to example]. Figure 1 The vehicle screen firmware upgrade method provided in this application embodiment is applied to the target vehicle and may include the following steps 101 to 104: Step 101: Obtain the screen upgrade data package pre-installed in the vehicle's infotainment system of the target vehicle.

[0023] The screen upgrade data package is integrated into the vehicle infotainment system's version data package.

[0024] In some examples, the target vehicle is a specific vehicle used to implement the in-vehicle screen firmware upgrade method of this application, equipped with an in-vehicle device that supports data storage, file reading, and communication interaction functions, enabling the storage and retrieval of screen upgrade data packages; for example, a 2026 compact smart sedan produced by a certain automaker. The in-vehicle infotainment system (IVI) is the core control and interaction platform integrated into the target vehicle, possessing functions such as system program operation, data storage, external device communication, and broadcast reception, providing hardware and software support for the storage of screen upgrade data packages, version comparison, and subsequent upgrade operations; for example, an in-vehicle dedicated infotainment system developed based on Android 14, supporting local file reading and writing, screen device communication, and application operation. The screen upgrade data package is a dedicated data set used for firmware updates of in-vehicle screens. It contains the target version firmware file and target version identification information required for normal upgrades of the in-vehicle screen. It is deeply integrated with the vehicle system version data package and does not need to be obtained separately from external sources. It can be synchronously distributed and stored in the vehicle system along with the vehicle system version data package. For example, it contains a dedicated data package containing the in-vehicle screen firmware version V3.2.1.0 produced by supplier A and the version identifier "V32100000". The version data package is a complete data set used for the vehicle system's own upgrades. It contains the latest system programs, configuration files, functional modules, and integrated screen upgrade data packages required for the vehicle system to run. It is the basic data carrier for the vehicle system to achieve self-updates and screen synchronous upgrades. It can be downloaded from the cloud server and stored in the designated storage area of ​​the vehicle system after the target vehicle receives a remote upgrade command. For example, a certain car brand pushed out a vehicle system version V5.0 data package for its 2026 compact smart sedan. In addition to the vehicle system's own upgrade files, this data package synchronously integrates the corresponding in-vehicle screen upgrade data package.

[0025] By implementing step 101, the screen upgrade data packet pre-installed in the target vehicle's infotainment system is obtained. This screen upgrade data packet is integrated with the version data packet of the infotainment system, so that the data required for screen upgrade can be obtained locally in the vehicle without having to obtain additional upgrade resources during the upgrade process. This reduces dependence on external upgrade channels or network environments, simplifies the upgrade process, and improves the overall efficiency of screen firmware upgrade.

[0026] Step 102: If a vehicle power-on event of the target vehicle is detected, obtain the current version identifier of the in-vehicle screen.

[0027] In some examples, a vehicle power-on event is a trigger event that occurs when the target vehicle's power system switches from a power-off state to a power-on state. This covers various power-on scenarios, including cold starts, and serves as the trigger condition for initializing in-vehicle equipment and related processes. The vehicle's infotainment system can monitor voltage changes or control signals in the vehicle's power circuit in real time through its power management module. When a signal meeting a preset power-on threshold is detected, it is determined to be a vehicle power-on event. For example, when a user presses the vehicle's one-button start, the power circuit is connected and a preset voltage signal is generated. The infotainment system captures this signal and identifies it as a vehicle power-on event. The in-vehicle screen is a dedicated display device integrated into the target vehicle for information display and human-machine interaction. It is one of the carriers for interaction between the vehicle and the user, supporting the functional display and operational response needs of the infotainment system. For example, the 12.3-inch high-definition touchscreen in the target vehicle supports multi-touch operation, can display navigation information, multimedia content, and vehicle status data, and establishes a stable communication connection with the infotainment system. The current version identifier is a unique version number of the firmware currently running on the vehicle screen. It can consist of numbers, letters, or a combination thereof, and includes version iteration information, adaptation attributes, etc. It serves as the basis for distinguishing the age of the screen firmware. The vehicle infotainment system can establish a data interaction link with the vehicle screen through a preset communication protocol (such as CAN bus protocol, Ethernet protocol), send a version query command to the screen, receive the version data fed back by the screen, and extract it. For example, the version identifier of the firmware currently running on the vehicle screen is "V3.0.2P105", where "V" represents the version identifier prefix, "3.0.2" is the core version number, "P" is a specific identifier character, and "105" is the sub-version number.

[0028] By implementing step 102, using the vehicle power-on event as the trigger condition, the current version identifier of the in-vehicle screen is obtained only after the target vehicle is detected to be powered on. This ensures that the version acquisition operation occurs when the system is already in a working state, avoiding version reading when the system is unstable or unavailable, thereby improving the stability and reliability of the screen version detection process.

[0029] Step 103: Determine the version comparison result based on the current version identifier and the target version identifier in the screen upgrade data package.

[0030] In some examples, the target version identifier is a pre-defined firmware standard version number that the in-vehicle screen needs to be upgraded to in the screen upgrade data package. Its format is consistent with the current version identifier and includes core version information, adaptation identifiers, etc. It serves as the basis for determining whether an upgrade operation needs to be performed. The in-vehicle infotainment system can call the file reading module to access the screen upgrade data package extracted in step 101 and read and extract it from the preset configuration path or fixed fields of the data package. For example, the target version identifier stored in the screen upgrade data package is "V3.1.0P120", where "V" is the version identifier prefix, "3.1.0" is the core version number, "P" is the adaptation identifier character, and "120" is the sub-version sequence number, which corresponds to the structure of the current version identifier to ensure the consistency of the comparison logic. The version comparison result is a conclusion reached by the in-vehicle infotainment system after comparing the current version identifier with the target version identifier according to preset version comparison rules. It can be divided into two categories: one is that the firmware version corresponding to the current version identifier has met or exceeded the requirements of the target version identifier; the other is that the firmware version corresponding to the current version identifier is lower than the requirements of the target version identifier. This result directly determines whether to initiate the upgrade process. The in-vehicle infotainment system's built-in version comparison algorithm performs numerical or logical comparisons on key parts such as the core version number and sub-serial number of the two version identifiers sequentially, ultimately outputting a clear conclusion. For example, comparing the current version identifier "V3.0.2P105" with the target version identifier "V3.1.0P120" yields the result "the current version is lower than the target version"; if the current version identifier is "V3.1.0P120" or "V3.2.0P130", then the result is "the current version meets the requirements of the target version".

[0031] By implementing step 103, the current version identifier of the vehicle screen is compared with the target version identifier in the screen upgrade data package. This allows for an accurate determination of whether the screen currently requires an upgrade, providing a clear basis for whether to perform a firmware upgrade. This avoids blindly performing upgrade operations and improves the accuracy of upgrade decisions.

[0032] Step 104: If the version comparison result indicates that the current version identifier is lower than the target version identifier, then perform a firmware upgrade operation on the current screen based on the screen upgrade data package.

[0033] In some examples, the version comparison result indicating that the current version identifier is lower than the target version identifier is a clear conclusion output by the in-vehicle infotainment system after comparing key information such as the core version number and sub-version sequence number of the current version identifier and the target version identifier. This conclusion indicates that the firmware currently running on the in-vehicle screen has not met the preset standards in terms of functional iteration, optimization level, or adaptability, and is the trigger condition for initiating the firmware upgrade operation. For example, the conclusion obtained in step 103 that "the current version identifier V3.0.2P105 is lower than the target version identifier V3.1.0P120" is a specific manifestation of "the version comparison result indicates that the current version identifier is lower than the target version identifier". If the comparison result is "the current version has met the target version requirements", then this trigger condition is not met. The process of performing a firmware upgrade on the current screen based on the screen upgrade data package involves the in-vehicle infotainment system (IVI) calling the target firmware file pre-installed in the screen upgrade data package after the upgrade trigger conditions are met. It then sends an upgrade command to the in-vehicle screen via a pre-defined communication link, pushing the screen firmware to replace the current version with the target version. This process may include firmware file retrieval, data transmission, write update, and activation verification. For example, the IVI extracts the target firmware file corresponding to V3.1.0P120 from the screen upgrade data package, sends an upgrade start command to the 12.3-inch high-definition touchscreen in-vehicle screen via Ethernet protocol, transmits the firmware file data to the screen storage area, overwrites the original old firmware version, and completes activation.

[0034] By implementing step 104, the firmware upgrade operation is only performed based on the screen upgrade data package when the version comparison result shows that the current screen version is lower than the target version. This can effectively avoid repeated upgrades or unnecessary upgrade processes, reduce the occupation of system resources, and ensure that the screen firmware is eventually upgraded to the target version, which is conducive to maintaining the stability of system operation.

[0035] In summary, this application's embodiments integrate the screen upgrade data package into the vehicle system's version data package beforehand and deploy it to the target vehicle along with the vehicle system. This eliminates the need to acquire additional upgrade data packages during vehicle screen firmware upgrades, reducing external dependencies and improving overall upgrade efficiency. Using vehicle power-on as one of the upgrade trigger conditions, the current version identifier of the vehicle screen is only acquired and processed after vehicle power-on is detected. This allows version detection and upgrade operations to be performed while the system is operational, thereby improving the stability and reliability of the screen firmware upgrade process. By comparing the current version identifier of the vehicle screen with the target version identifier in the screen upgrade data package, firmware upgrades are only performed when the current version is lower than the target version, effectively avoiding duplicate or invalid upgrades and reducing system resource consumption. Integrating the screen upgrade data package with the vehicle system version data package and using the target version identifier as the upgrade basis allows the vehicle screen firmware to automatically upgrade to the target version matching the vehicle system after vehicle power-on, which helps maintain overall system version consistency. In summary, the vehicle screen firmware upgrade method provided in this application integrates and deploys the screen upgrade data package along with the vehicle system, and performs the upgrade on demand based on version comparison after the vehicle is powered on. This can reduce external dependencies while improving the efficiency, stability, and system version consistency of screen firmware upgrades.

[0036] In some embodiments, the aforementioned step 102 may include: after detecting a vehicle power-on event, detecting the vehicle power status signal of the target vehicle; after detecting that the vehicle power status signal meets the preset screen operation conditions for a first preset time, sending a version query request to obtain the current version identifier through the communication interface between the vehicle system and the vehicle screen.

[0037] In some examples, the vehicle power status signal is an electrical signal output by the target vehicle's power system that reflects the stability and level of power supply. It may include information such as power supply voltage, current stability, and power mode (e.g., the power supply status corresponding to the ignition switch position), and serves as the basis for determining whether the in-vehicle screen is ready to operate. The in-vehicle infotainment system can collect the electrical signal data of the vehicle's power circuit in real time through its built-in power management module, and obtain a resolvable status signal after signal conversion. For example, if the vehicle power status signal is a 12V DC power supply voltage signal, and the voltage fluctuation range is controlled within ±0.3V, it indicates that the power supply is in a stable power supply state.

[0038] Preset screen operation conditions are pre-defined power status standards that ensure the vehicle screen can respond to commands and perform data interaction normally. They can be formulated based on the hardware operating requirements of the vehicle screen and can cover indicators such as power supply voltage range and power supply stability duration. Fixed parameter thresholds can be preset in the system configuration file of the vehicle infotainment system as the basis for judging whether the power status meets the standards. For example, the preset screen operation conditions are that the vehicle power status signal continuously maintains a voltage range of 11.8V-12.5V, and the duration of this stable state is not less than 2 seconds.

[0039] The first preset duration is the system stabilization waiting time reserved after the vehicle power status signal meets the preset screen operation conditions. It is used to reserve a stable startup cycle for the communication link and hardware devices between the in-vehicle infotainment system and the in-vehicle screen, avoiding command interaction failure due to the system not being fully ready. The fixed duration parameter can be pre-configured according to the vehicle hardware performance and system startup characteristics, without the need for dynamic adjustment. For example, the first preset duration is set to 10 seconds, which means that after the power status meets the conditions, wait 10 seconds before performing subsequent operations.

[0040] The communication interface between the vehicle infotainment system and the in-vehicle screen is a hardware connection port and a combination of supporting communication protocols that enable data transmission and command interaction between the two systems. It serves as the channel for information exchange between them. For example, the communication interface uses an Ethernet interface and is equipped with a Transmission Control Protocol / Internet Protocol (TCP / IP) to support high-speed and stable data interaction, enabling the rapid transmission of information such as version query commands and upgrade data.

[0041] A version query request is a standardized data command sent by the in-vehicle infotainment system to the in-vehicle screen to obtain the current firmware version identifier of the screen. It can include information such as command type, target device identifier, and data interaction format to ensure that the in-vehicle screen can accurately identify and respond. For example, a version query request is a data packet encapsulated by the TCP / IP protocol, containing "version query command code 0x001, in-vehicle screen device address 0x01, data return format requirements, etc." to ensure that the screen can return version information in the specified format after receiving it.

[0042] For example, after the in-vehicle infotainment system detects a vehicle power-on event, it immediately initiates real-time monitoring of the vehicle's power status signal through the power management module. When a signal with a voltage within the range of 11.8V-12.5V and stable for 2 seconds is captured, it is determined that the preset screen operation conditions are met. Subsequently, it enters a first preset waiting period of 10 seconds. After the communication link between the vehicle and the screen is fully stable, the IVI sends a version query request containing the instruction code 0x001 to the in-vehicle screen through the Ethernet interface according to the TCP / IP protocol. After receiving the request, the in-vehicle screen returns its current firmware version data according to the preset format. The IVI successfully receives and extracts the current version identifier.

[0043] Through the implementation of the above embodiments, after detecting a vehicle power-on event, the vehicle power status signal is further detected, and the screen version identifier is obtained only after the preset screen operation conditions are met and the process continues for a first preset time. This ensures that the screen is in a working state where it can communicate and operate normally before performing the version query, avoids performing operations when the system is not yet stable, reduces the occurrence of version reading failures or abnormal situations, and improves the rationality of the timing control of the vehicle screen firmware upgrade and the stability of the upgrade process.

[0044] In some embodiments, the aforementioned detection of the vehicle power status signal after detecting a vehicle power-on event may include: detecting the power-on broadcast of the vehicle system after detecting a vehicle power-on event; and acquiring the vehicle power status signal after a second preset duration following the detection of the power-on broadcast.

[0045] In some examples, the vehicle infotainment system's boot broadcast is a standardized notification signal sent by the system to various related components within the vehicle after the system startup initialization is complete. It is a system-level broadcast message and can include information such as system startup status and initialization progress, used to synchronously inform relevant applications or devices that the vehicle infotainment system has entered a working state. The broadcast signal can be automatically generated and sent by the underlying system after the vehicle infotainment system completes its own startup process, without the need for additional triggering operations. For example, the BOOT_COMPLETED broadcast sent after the vehicle infotainment system starts up is transmitted in a fixed data format and includes the status identifier code 0x0001 indicating that the system has started.

[0046] The process of detecting the vehicle's infotainment system's startup broadcast after a vehicle power-on event is as follows: after the target vehicle captures the trigger signal of the power-on event, it activates the built-in broadcast monitoring module to continuously monitor whether the in-vehicle infotainment system sends a startup broadcast. This process confirms that the vehicle's infotainment system has completed its startup initialization, providing a prerequisite for subsequently obtaining the vehicle's power status signal. For example, the 2026 compact smart sedan immediately activates the broadcast monitoring module after power-on, continuously scanning for received broadcast messages. When it detects a BOOT_COMPLETED broadcast containing the identifier code 0x0001, it confirms that the vehicle's infotainment system's startup broadcast has been captured.

[0047] The second preset duration is the system stabilization waiting time reserved after detecting the vehicle infotainment system's startup broadcast. It is used to reserve a stable period for subsequent interactions between the vehicle infotainment system and the vehicle's power system, avoiding inaccurate power status signal detection due to the vehicle system just starting up and system resources not being fully allocated. A fixed duration parameter can be preset in the configuration file according to the resource allocation cycle after the vehicle system starts up and the stability characteristics of the power system, without the need for dynamic adjustment throughout the process. For example, if the second preset duration is set to 5 seconds, it means that after detecting the startup broadcast, wait 5 seconds before performing the subsequent operation of obtaining the power status signal.

[0048] After the second preset duration of the power-on broadcast is detected, the process of acquiring the vehicle power status signal is an operation performed by the power management module of the in-vehicle infotainment system to collect the status signal output by the vehicle power system after the second preset duration of waiting is completed. This is used to confirm whether the vehicle power supply is in a stable power supply state, providing a reliable guarantee for the subsequent sending of version query requests.

[0049] For example, taking a 2026 compact smart sedan as the target vehicle, its in-vehicle infotainment system immediately activates the broadcast monitoring module after detecting a vehicle power-on event, continuously monitoring broadcast messages sent by the IVI; upon capturing a BOOT_COMPLETED power-on broadcast containing the identifier code 0x0001, it enters a second preset waiting period of 5 seconds to ensure complete allocation of vehicle system resources and stable operation; after the waiting period ends, it sends a power status signal acquisition command to the IVI through the system interface. The IVI's power management module collects the power supply data of the entire vehicle's power circuit in real time, generates a 12V stable power supply status signal, and feeds back the vehicle's power status signal, preparing for subsequent sending of version query requests through the communication interface.

[0050] By implementing the above embodiments, and combining the power-on broadcast of the vehicle system with the vehicle power status signal for judgment, the vehicle power status signal is obtained after a second preset time after the power-on broadcast is detected. This not only covers the vehicle cold start scenario, but also takes into account complex power-on situations such as hot start. This can improve the accuracy of identifying the actual working status of the vehicle, which is conducive to triggering the subsequent upgrade process at the appropriate system operation stage, and further improves the reliability and adaptability of the vehicle screen firmware upgrade.

[0051] In some embodiments, the aforementioned method of sending a version query request to obtain the current version identifier through the communication interface between the vehicle system and the vehicle screen may include: sending a version query request to the vehicle screen through the communication interface; if no version response information is received from the vehicle screen within a third preset time period, then repeatedly sending the version query request until the cumulative number of times sent reaches a preset number threshold; if a version response information is received before the cumulative number of times sent reaches the preset number threshold, then extracting the current version identifier from the version response information.

[0052] In some examples, the process of sending a version query request to the in-vehicle screen via the communication interface is an operation in which the in-vehicle infotainment system, after confirming that the vehicle's power status meets the conditions, generates a standardized version query command based on the communication interface and supporting protocol pre-adapted with the in-vehicle screen and transmits it to the in-vehicle screen; for example, the IVI sends a version query request data packet containing command code 0x001 and device address 0x01 to the in-vehicle screen via the Ethernet interface, based on the Transmission Control Protocol / Internet Protocol.

[0053] The third preset duration is the maximum time threshold for the in-vehicle infotainment system to wait for the in-vehicle screen to respond with version information after sending a version query request. It is used to balance response waiting and system efficiency, and to avoid consuming system resources due to infinite waiting. The fixed duration parameter can be preset in the configuration file according to the communication latency characteristics between the vehicle and the screen and the screen hardware response speed. For example, if the third preset duration is set to 3 seconds, it means that after the IVI sends a query request, it will wait for a maximum of 3 seconds to receive the screen's response information.

[0054] The cumulative number of sends is the total number of times the in-vehicle infotainment system (IVI) repeatedly sends a version query request when no valid version response is received. It records the frequency of request sending and provides a basis for triggering the cessation of repeated requests. A built-in counter can be used, automatically incrementing by 1 after each version query request is sent, with an initial value of 0. For example, the counter is set to 1 after the IVI sends the first query request; if no response is received and a second request is sent, the counter is updated to 2, and so on. The preset threshold is a pre-defined maximum number of repeated version query requests. It limits meaningless repeated requests and avoids excessive consumption of communication resources and system computing power. A fixed value can be preset in the system configuration, taking into account factors such as signal stability and screen response probability in a connected vehicle environment. For example, a preset threshold of 10 means that a version query request can be repeatedly sent a maximum of 10 times; if no response is received, sending will stop.

[0055] After the in-vehicle infotainment system sends a version query request, it starts a third preset timer. If no valid response is received from the in-vehicle screen before the timer expires, and the current cumulative number of requests has not exceeded the preset threshold, the same version query request will be automatically regenerated and sent until the cumulative number of requests reaches the threshold. For example, if the IVI sends a query request and waits for 3 seconds without receiving a screen response, and the cumulative number of requests is 3 (not reaching the 10-time threshold), the version query request will be automatically sent again until the cumulative number of requests reaches 10.

[0056] If a version response is received before the cumulative number of requests reaches a preset threshold, the process of extracting the current version identifier from the version response information is as follows: During repeated version query requests, if the cumulative number of requests does not exceed the preset threshold and the version response information from the vehicle screen is successfully received, the in-vehicle infotainment system (IVI) parses the response information and extracts the version data. The IVI can receive the response data packet, filter out key fields containing the version identifier according to preset data parsing rules, extract and convert them into a standardized version identifier format. For example, after the third query request, the IVI receives a response data packet from the vehicle screen containing the version information field "V3.0.2P105". The IVI extracts this string as the current version identifier.

[0057] By implementing the above embodiments, a waiting time and resending mechanism are introduced after sending the version query request. The screen version response information is obtained multiple times within a preset number of thresholds. This can effectively address issues such as communication delay, bus congestion, or unstable screen response in the vehicle network environment, improve the success rate of obtaining the current version identifier, avoid misjudging the upgrade status due to a single communication failure, and enhance the accuracy of screen version management and the robustness of the upgrade process.

[0058] In some embodiments, step 103 may include: extracting characters from the current version identifier based on a preset extraction location to obtain a supplier identification code; determining the target supplier category corresponding to the vehicle screen based on the supplier identification code; parsing a first numerical version number from the current version identifier and a second numerical version number from the target version identifier based on a preset parsing rule corresponding to the target supplier category; and comparing the first numerical version number with the second numerical version number to obtain a version comparison result.

[0059] In some examples, the preset extraction position is a predefined, fixed character position used to extract the supplier identification code from the version identifier. This position can be standardized according to the version identifier formats of different suppliers to ensure standardized extraction logic. Specific position parameters, such as character index and number range, can be preset in the configuration file of the in-vehicle infotainment system. For example, the preset extraction position might be the 4th character of the current version identifier (counted from left to right, ignoring the prefix "V" and separators). The supplier identification code is a specific character or combination of characters used to uniquely identify the in-vehicle screen supplier and serves as the basis for associating the corresponding version parsing rules. Its format is determined through negotiation among multiple suppliers and pre-set in the system; the corresponding character or combination of characters can be extracted from the preset extraction position of the current version identifier.

[0060] The process of extracting characters from the current version identifier based on a preset extraction position to obtain the supplier identification code is an operation in which the in-vehicle infotainment system extracts specific characters from the acquired current version identifier at preset fixed positions as the basis for identifying suppliers. For example, if the current version identifier is "V3.0.2P105", the character "P" is extracted at the preset extraction position (the 4th character), and this character is the supplier identification code. The target supplier category is the type of supplier to which the in-vehicle screen belongs, determined based on the supplier identification code. It is a key classification for matching version parsing rules and only includes legitimate suppliers pre-adapted by the system. A mapping table between supplier identification codes and supplier categories can be preset in the IVI. After extracting the identification code, the category can be determined by querying this table. For example, querying the mapping table shows that the identification code "P" corresponds to the target supplier category A, and the identification code "Q" corresponds to the target supplier category B.

[0061] The preset parsing rules corresponding to the target supplier category are standardized rules pre-defined for different supplier categories to extract numerical version numbers from version identifiers. These rules include requirements such as character truncation range, delimiter handling, and invalid character filtering. The corresponding parsing rule parameters can be stored separately in the IVI system configuration according to the supplier category, and can be directly called after determining the target supplier category. For example, the preset parsing rule for supplier A is: ignore the version identifier prefix "V", remove the delimiter ".", and extract the numerical values ​​corresponding to the 2nd to 8th digits and valid characters to form a continuous numerical string; the preset parsing rule for supplier B is: ignore the prefix "V" and the first two characters, remove the delimiter "-", and extract the 3rd to 9th digits to form a continuous numerical string.

[0062] The first numerical version number is a pure numerical version number obtained by processing the current version identifier according to the preset parsing rules of the target supplier category. It is used to convert non-standardized version identifiers into a format that can be directly compared numerically. For example, the current version identifier "V3.0.2P105" corresponds to supplier A. After processing according to its parsing rules, the first numerical version number is 302105 (removing "V" and ".", and extracting the numeric part "302105" from "302P105"). The second numerical version number is a pure numerical version number obtained by processing the target version identifier in the screen upgrade data package according to the preset parsing rules of the same target supplier category. It is completely consistent with the format of the first numerical version number, ensuring the validity of the comparison. For example, the target version identifier "V3.1.0P120" corresponds to supplier A. After processing according to its parsing rules, the second numerical version number is 310120 (removing "V" and ".", and extracting the numeric part "310120" from "310P120").

[0063] The process of comparing the first numerical version number with the second numerical version number to obtain the version comparison result involves the in-vehicle infotainment system comparing the size of the first and second numerical version numbers and outputting a clear conclusion such as "the current version is lower than the target version" or "the current version meets the requirements of the target version". The IVI can directly call the underlying numerical comparison function of the system and map the comparison result to the corresponding version comparison conclusion. For example, when comparing the first numerical version number 302105 with the second numerical version number 310120, since 302105 < 310120, the comparison result "the current version is lower than the target version" is output. If the first numerical version number is 310120 or 320130, then "the current version meets the requirements of the target version" is output.

[0064] For example, the in-vehicle infotainment system has obtained the current version identifier "V3.0.2P105" and the target version identifier "V3.1.0P120". First, it extracts "P" from the current version identifier at the preset extraction position (the 4th character), determines the supplier identification code, and queries the mapping table to find that the target supplier category is supplier A. Then, the IVI calls the preset parsing rules corresponding to supplier A to process the current version identifier and the target version identifier respectively, extracting the numerical part to obtain the first numerical version number 302105 and the second numerical version number 310120. Finally, the IVI starts the numerical comparison algorithm, confirms by comparing the size that 302105 is less than 310120, and finally generates a version comparison result of "current version is lower than target version", providing a decision basis for subsequent upgrade operations.

[0065] By implementing the above embodiments, the supplier identification code is extracted from the current version identifier and the corresponding screen supplier category is determined accordingly. Then, the numerical version number is parsed and compared using the parsing rules that match the supplier. In the context of vehicle networking applications where multiple screen suppliers coexist, unified management and accurate comparison of different version formats can be achieved, avoiding upgrade judgment errors caused by version rule differences. This can improve the accuracy of version management and the reliability of upgrade decisions.

[0066] In some embodiments, the aforementioned firmware upgrade operation performed on the current screen based on the screen upgrade data package may include: determining the storage path of the target firmware file from the screen upgrade data package based on the target vendor category; copying the target firmware file to a preset temporary storage area of ​​the vehicle system to obtain a local upgrade file; and performing a firmware update on the vehicle screen based on the local upgrade file.

[0067] In some examples, the target firmware file is a vehicle screen upgrade file pre-stored in the screen upgrade data package, which is fully adapted to the target version identifier and the target vendor category. It contains key data such as program code and configuration parameters required for screen operation and serves as the carrier for firmware updates. It can be a complete file package extracted from the corresponding storage path of the screen upgrade data package according to the target vendor category and the target version identifier. For example, the target firmware file corresponding to the target version identifier "V3.1.0P120" and the target vendor category is vendor A, is named "firmware_A_V310120.bin" and contains all the program data required for the vendor's screen upgrade. The storage path of the target firmware file is the specific location where the target firmware file is stored within the screen upgrade data package. This path is differentiated according to different target vendor categories to ensure accurate file retrieval. A mapping table between vendor categories and storage paths can be preset in the in-vehicle infotainment system. After determining the target vendor category, the corresponding path can be retrieved through this table. For example, when the target vendor category is vendor A, the corresponding storage path is " / screen_update / package / vendorA / "; when the target vendor category is vendor B, the corresponding storage path is " / screen_update / package / vendorB / ".

[0068] The preset temporary storage area is a pre-allocated temporary storage area in the in-vehicle infotainment system specifically for storing firmware files to be upgraded. It features fast read / write speeds and low system resource consumption, avoiding file read conflicts during the upgrade process. A fixed storage partition can be pre-planned and access permissions configured during IVI system initialization, serving as a dedicated temporary storage space for upgrade files. For example, the preset temporary storage area path built into IVI is " / data / local / tmp / screen_update / ", which reserves 10GB of storage space solely for the temporary storage and retrieval of upgrade files. The local upgrade file is a copy of the target firmware file created by copying it from the screen upgrade data package to the preset temporary storage area. It is completely identical to the original target firmware file, preventing file occupancy or read failures caused by directly reading the original data package, thus ensuring the stability of the upgrade process. For example, copying "firmware_A_V310120.bin" from the storage path " / screen_update / package / vendorA / " to " / data / local / tmp / screen_update / " creates the local upgrade file.

[0069] The process of updating the firmware of an in-vehicle screen based on a local upgrade file involves the in-vehicle infotainment system transmitting the local upgrade file data from a preset temporary storage area to the screen via a communication interface, triggering screen firmware replacement, program installation, and activation. This can be achieved by first sending an upgrade start command to the screen via the communication interface, and then transmitting the local upgrade file data after the screen responds with a "ready" signal, while simultaneously monitoring the upgrade progress until the screen completes the firmware replacement and restarts to take effect. For example, the IVI sends an upgrade start command to the screen via an Ethernet interface. After the screen returns a "ready" signal, it continuously transmits the data of the local upgrade file "firmware_A_V310120.bin" to the screen. Upon receiving the data, the screen overwrites the existing old firmware, completes the installation, and automatically restarts, thus achieving the firmware update.

[0070] For example, the in-vehicle infotainment system has identified the target vendor category as Vendor A and the target version as "V3.1.0P120". By querying the vendor-path mapping table, the storage path of the target firmware file is located as " / screen_update / package / vendorA / ". Subsequently, the IVI calls the file copying module to completely copy "firmware_A_V310120.bin" from this path to the preset temporary storage area " / data / local / tmp / screen_update / ", generating a local upgrade file. After the copying is complete, the IVI sends an upgrade start command to the in-vehicle screen via the Ethernet interface. After confirming that the screen is ready, it starts data transmission, monitors the upgrade progress in real time, and after the screen completes the firmware replacement and restarts, the IVI verifies again that the screen version has been updated to the target version, completing the entire firmware update operation.

[0071] By implementing the above embodiments, the firmware file storage path is determined according to the target supplier category, and the target firmware file is copied to the local temporary storage area of ​​the vehicle system before the screen firmware update is performed. This allows the upgrade process to be completed locally in the vehicle system, reducing reliance on external storage or network resources. At the same time, it ensures that the upgrade file used is accurately matched with the screen type, which can reduce the risk of upgrade failure and improve the security and success rate of the vehicle screen firmware upgrade process.

[0072] In some embodiments, prior to step 101, the aforementioned vehicle screen firmware upgrade method may further include: if a remote upgrade instruction for the vehicle system is received, obtaining a version data package from the cloud, wherein the screen upgrade data package is encapsulated in the form of an application installation package and is synchronously distributed and stored as an integrated component of the version data package.

[0073] In some examples, the remote upgrade command is a standardized command sent by the cloud server to the in-vehicle infotainment system of the target vehicle to trigger a system version update. It includes an upgrade task identifier, version data package address, verification information, etc., and serves as a trigger signal to initiate the cloud version data package acquisition process. The in-vehicle infotainment system can continuously monitor the command delivery channel of the cloud server through the in-vehicle network (such as 4G / 5G network, vehicle-to-everything communication protocol), receive and verify the legality of the command, and then confirm the acquisition. For example, a remote upgrade command sent by the OTA (Over-the-Air Technology) cloud server of a certain car brand includes the task ID "UP20260601001", the version data package download address "https: / / ota.xxx.com / ivi / V5.0 / package.zip" and the MD5 checksum "E8F32A7B9C4D10E6". The cloud is a remote server cluster with data storage, command issuance, and data packet distribution functions. It is dedicated to providing remote upgrade services for the vehicle's infotainment system and related components, and is the source of version data packets for storage and distribution. For example, a car brand's dedicated OTA cloud server cluster is deployed on a cloud computing platform and has high concurrency distribution capabilities, which can provide version data packet download services for a large number of vehicles at the same time.

[0074] The firmware files, version verification logic, supplier adaptation rules, and other content required for in-vehicle screen upgrades can be packaged in the standard application (APP) format to form an independent file that can be recognized, installed, and called by the vehicle system. The packaged data has the characteristics of integrity protection and convenient integration. Through Android development tools, the screen upgrade firmware, version comparison code, upgrade execution logic, etc. can be integrated and compiled to generate an application installation package (Android Package, APK) that meets the compatibility requirements of the vehicle system. For example, the screen upgrade data package is packaged into an application installation package named "ScreenUpdate_V3.1.0.apk", which contains the firmware file "firmware_A_V310120.bin" of supplier A, the firmware file "firmware_B_V310080.bin" of supplier B, and code for version parsing, upgrade control, etc. When the screen upgrade data package (in the form of an application installation package) is packaged in the cloud, it is embedded in the version data package of the vehicle system, forming a complete integrated data package. During the distribution process, the two are transmitted synchronously. When stored, the screen upgrade data package is stored together with the version data package in the designated storage directory of the vehicle system, without the need for separate download. For example, the vehicle system V5.0 version data package "package.zip" contains "ivi_system / " (the vehicle system upgrade file directory) and "screen_update / " (the screen upgrade APK storage directory). Both are downloaded synchronously from the cloud by the vehicle system, and after decompression, they are stored together in the vehicle system's system storage directory " / system / update / ".

[0075] For example, the in-vehicle infotainment system of the target vehicle continuously monitors the command channel of the brand's OTA cloud server via the 4G network. When it receives a remote upgrade command containing the task ID "UP20260601001", it verifies the verification code and confirms the command is legitimate. Subsequently, the IVI downloads the V5.0 version data package "package.zip" integrating the screen upgrade APK from the cloud server through the vehicle network communication link according to the download address in the command, and temporarily stores it in the preset temporary storage area " / data / ota / tmp / ". After the download is completed, the IVI decompresses and verifies the data package, stores the vehicle system upgrade file in " / system / update / ivi_system / ", and stores the integrated "ScreenUpdate_V3.1.0.apk" in " / system / update / screen_update / ", completing the synchronous distribution and storage, laying the foundation for obtaining the screen upgrade data package in the subsequent step 101.

[0076] Through the implementation of the above embodiments, when a remote upgrade command for the vehicle system is received, a version data package containing screen upgrade data is uniformly obtained from the cloud, and packaged and synchronously distributed in the form of an application installation package. This ensures that the screen upgrade data is consistent with the vehicle system version, reduces the complexity of independent upgrade operations, reduces the number of interactions between the cloud and the vehicle, and improves the efficiency and reliability of collaborative upgrades between the vehicle system and the vehicle screen in the context of vehicle networking.

[0077] Furthermore, as an implementation of the aforementioned method embodiments, this application also provides an in-vehicle screen firmware upgrade device for implementing the aforementioned method embodiments. This device embodiment corresponds to the aforementioned method embodiments. For ease of reading, this in-vehicle screen firmware upgrade device embodiment will not repeat the details of the aforementioned method embodiments one by one, but it should be clear that the device in this application embodiment can correspondingly implement all the contents of the aforementioned method embodiments. For example... Figure 2 As shown, the in-vehicle screen firmware upgrade device 20 includes: a data acquisition unit 201, a version acquisition unit 202, a version comparison unit 203, and a screen upgrade unit 204. The data acquisition unit 201 is used to acquire a screen upgrade data packet pre-installed in the vehicle's infotainment system of the target vehicle, wherein the screen upgrade data packet is integrated into the version data packet of the infotainment system. The version acquisition unit 202 is used to acquire the current version identifier of the in-vehicle screen if a vehicle power-on event of the target vehicle is detected. The version comparison unit 203 is used to determine the version comparison result based on the current version identifier and the target version identifier in the screen upgrade data packet. The screen upgrade unit 204 is used to perform a firmware upgrade operation on the current screen based on the screen upgrade data packet if the version comparison result indicates that the current version identifier is lower than the target version identifier.

[0078] In some embodiments, the version acquisition unit 202 is further configured to detect the vehicle power status signal of the target vehicle after detecting a vehicle power-on event; and after detecting that the vehicle power status signal meets the preset screen operation conditions for a first preset time, send a version query request to obtain the current version identifier through the communication interface between the vehicle system and the vehicle screen.

[0079] In some embodiments, the version acquisition unit 202 is further configured to detect the power-on broadcast of the vehicle system after detecting a vehicle power-on event; and acquire the vehicle power status signal after a second preset duration of detecting the power-on broadcast.

[0080] In some embodiments, the version acquisition unit 202 is further configured to send a version query request to the vehicle screen through a communication interface; if no version response information is received from the vehicle screen within a third preset time period, the version query request is sent repeatedly until the cumulative number of times sent reaches a preset number threshold; if a version response information is received before the cumulative number of times sent reaches the preset number threshold, the current version identifier is extracted from the version response information.

[0081] In some embodiments, the version comparison unit 203 is further configured to extract characters from the current version identifier based on a preset extraction position to obtain a supplier identification code; determine the target supplier category corresponding to the vehicle screen based on the supplier identification code; parse a first numerical version number from the current version identifier and a second numerical version number from the target version identifier based on a preset parsing rule corresponding to the target supplier category; and compare the first numerical version number with the second numerical version number to obtain a version comparison result.

[0082] In some embodiments, the screen upgrade unit 204 is further configured to determine the storage path of the target firmware file from the screen upgrade data package based on the target supplier category; copy the target firmware file to the preset temporary storage area of ​​the vehicle system to obtain a local upgrade file; and perform a firmware update on the vehicle screen based on the local upgrade file.

[0083] In some embodiments, the data acquisition unit 201 is further configured to acquire a version data package from the cloud if a remote upgrade instruction for the vehicle system is received, wherein the screen upgrade data package is encapsulated in the form of an application installation package and is synchronously distributed and stored as an integrated component of the version data package.

[0084] This application also provides a computer-readable storage medium storing computer-executable instructions or computer programs, which, when executed by a processor, will cause the processor to perform any step of the vehicle screen firmware upgrade method provided in this application.

[0085] In some embodiments, the computer-readable storage medium may be a random access memory (RAM), a read-only memory (ROM), flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM); or it may be a variety of devices that include one or any combination of the above-mentioned memories.

[0086] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0087] In some embodiments, computer-executable instructions may, but do not necessarily, correspond to files in a file system, and may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0088] In some embodiments, computer-executable instructions may be deployed to execute on an electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0089] like Figure 3 As shown, this application also provides an electronic device 30, including a memory 310, a processor 320, and a computer program 311 stored in the memory 310 and executable on the processor. When the processor 320 executes the computer program 311, it implements any step of the above-described vehicle screen firmware upgrade method.

[0090] This application also provides a computer program product comprising a computer program or computer-executable instructions stored in a computer-readable storage medium. The processor of an electronic device reads the computer program or computer-executable instructions from the computer-readable storage medium and executes the computer program or computer-executable instructions, causing the electronic device to perform any step of the above-described vehicle screen firmware upgrade method of this application.

[0091] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for upgrading firmware for an in-vehicle screen, characterized in that, Applied to the target vehicle, the in-vehicle screen firmware upgrade method includes: Obtain the screen upgrade data package pre-installed in the vehicle infotainment system of the target vehicle, wherein the screen upgrade data package is integrated into the version data package of the vehicle infotainment system; If a power-on event of the target vehicle is detected, the current version identifier of the in-vehicle screen is obtained; The version comparison result is determined based on the current version identifier and the target version identifier in the screen upgrade data package; If the version comparison result indicates that the current version identifier is lower than the target version identifier, then a firmware upgrade operation is performed on the current screen based on the screen upgrade data package.

2. The vehicle screen firmware upgrade method according to claim 1, characterized in that, If a power-on event of the target vehicle is detected, the current version identifier of the in-vehicle screen is obtained, including: After detecting the vehicle power-on event, the overall vehicle power status signal of the target vehicle is detected; After detecting that the vehicle power status signal meets the preset screen operation conditions for a first preset time, a version query request is sent through the communication interface between the vehicle system and the vehicle screen to obtain the current version identifier.

3. The vehicle screen firmware upgrade method according to claim 2, characterized in that, The step of detecting the vehicle power status signal after detecting the vehicle power-on event includes: After detecting the vehicle power-on event, the power-on broadcast of the vehicle system is detected; After a second preset duration of the power-on broadcast is detected, the vehicle power status signal is acquired.

4. The vehicle screen firmware upgrade method according to claim 2, characterized in that, The step of sending a version query request to obtain the current version identifier through the communication interface between the vehicle system and the vehicle screen includes: A version query request is sent to the vehicle screen via the communication interface; If no version response information is received from the vehicle screen within the third preset time period, the version query request will be sent repeatedly until the cumulative number of times it is sent reaches the preset number threshold. If the version response information is received before the cumulative number of transmissions reaches the preset threshold, the current version identifier is extracted from the version response information.

5. The vehicle screen firmware upgrade method according to claim 1, characterized in that, The step of determining the version comparison result based on the current version identifier and the target version identifier in the screen upgrade data package includes: Based on the preset extraction location, the current version identifier is extracted to obtain the supplier identification code; Based on the supplier identification code, the target supplier category corresponding to the vehicle screen is determined; Based on the preset parsing rules corresponding to the target supplier category, the first numerical version number is parsed from the current version identifier, and the second numerical version number is parsed from the target version identifier; The first numerical version number is compared with the second numerical version number to obtain the version comparison result.

6. The vehicle screen firmware upgrade method according to claim 5, characterized in that, The step of performing a firmware upgrade operation on the current screen based on the screen upgrade data package includes: Based on the target vendor category, determine the storage path of the target firmware file from the screen upgrade data package; The target firmware file is copied to the preset temporary storage area of ​​the vehicle system to obtain a local upgrade file; Based on the local upgrade file, a firmware update is performed on the vehicle screen.

7. The vehicle screen firmware upgrade method according to any one of claims 1 to 6, characterized in that, Before obtaining the screen upgrade data packet pre-installed in the vehicle's infotainment system, the in-vehicle screen firmware upgrade method further includes: If a remote upgrade command for the vehicle system is received, the version data package is obtained from the cloud. The screen upgrade data package is encapsulated in the form of an application installation package and is synchronously distributed and stored as an integrated component of the version data package.

8. A vehicle-mounted screen firmware upgrade device, characterized in that, Applied to target vehicles, the in-vehicle screen firmware upgrade device includes: A data acquisition unit is used to acquire a screen upgrade data packet pre-installed in the vehicle infotainment system of the target vehicle, wherein the screen upgrade data packet is integrated into the version data packet of the vehicle infotainment system; The version acquisition unit is used to acquire the current version identifier of the in-vehicle screen if a vehicle power-on event of the target vehicle is detected. The version comparison unit is used to determine the version comparison result based on the current version identifier and the target version identifier in the screen upgrade data packet; The screen upgrade unit is configured to perform a firmware upgrade operation on the current screen based on the screen upgrade data packet if the version comparison result indicates that the current version identifier is lower than the target version identifier.

9. An electronic device, comprising: The memory and processor are characterized in that the processor, when executing a computer program stored in the memory, implements the steps of the vehicle screen firmware upgrade method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having stored thereon computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or the computer program are executed by a processor, the steps of the vehicle screen firmware upgrade method as described in any one of claims 1 to 7 are implemented.

Images