Partition upgrading method and device for vehicle-mounted service, computer equipment and storage medium

By adopting the partition upgrade method of in-vehicle services in digital instruments, the problems of low security and poor stability in the upgrade in the existing technology are solved, and efficient, safe and stable partition upgrade of in-vehicle services is achieved, improving user experience and system performance.

CN119902788AActive Publication Date: 2025-04-29CHONGQING CHANGAN AUTOMOBILE CO LTD

Patent Information

Application Number
CN202510028668.5
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-01-08
Publication Date
2025-04-29
Estimated Expiration
2045-01-08

AI Technical Summary

Technical Problem

The existing digital instrument upgrade technology is based on a non-SOA architecture, and has problems such as low security, no attention to upgrade failures, and no consideration of communication compatibility, resulting in low upgrade efficiency, poor stability and high cost.

Method used

The partition upgrade method of in-vehicle services is adopted. By receiving service upgrade requests for in-vehicle applications, querying the service information and update version number of the service to be upgraded, filtering service information based on the configuration file of the target vehicle, building a service upgrade package, and using this package to perform partition upgrade operations to ensure the security and stability of the upgrade.

Benefits of technology

It improves the safety and stability of the upgrade, enhances the targetedness and accuracy of the upgrade, reduces the impact of the upgrade on other systems of the vehicle, and improves the user experience and overall performance of the system.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119902788A_ABST
    Figure CN119902788A_ABST
Patent Text Reader

Abstract

The invention relates to the technical field of instrument upgrading, and discloses a partition upgrading method and device for vehicle-mounted services, computer equipment and a storage medium, the method is applied to an instrument end, the method comprises the steps that service upgrading requests from all vehicle-mounted applications in a target vehicle are received, and the service upgrading requests comprise service identifiers of to-be-upgraded services and current version numbers; querying the service information of the to-be-upgraded service and the updated version number in a partition upgrading service system of the instrument end based on the service identifier, and comparing the current version number with the updated version number; if the current version number is not consistent with the updated version number, screening the service information according to a configuration file corresponding to the target vehicle to obtain target service information; and constructing a service upgrade package according to the target service information, and executing partition upgrade operation on the vehicle-mounted application in the target vehicle by using the service upgrade package. According to the method, the problems that the security is not high and the condition of upgrading failure is not concerned when the instrument upgrading of the lower vehicle under the SOA architecture are solved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the technical field of instrument upgrade, and in particular to a partition upgrade method, device, computer equipment and storage medium for vehicle-mounted services. Background Art

[0002] With the booming development of the automotive intelligence industry and the widespread popularity of Ethernet, smart cockpit technology is undergoing rapid changes. In this process, the installation of digital instruments in cars has become an irreversible trend, which greatly improves the driving experience and enhances the functionality of vehicles. However, the use of digital instruments inevitably involves software upgrades, which is a key link to ensure that instrument functions are continuously optimized and security vulnerabilities are promptly patched.

[0003] Most of the existing digital instrument upgrade technologies are based on non-SOA architectures and have many shortcomings: low security and susceptible to problems such as system black screen and freezing; failure to fully consider upgrade failures, which may cause damage to instrument functions and affect vehicle system stability; insufficient consideration of communication compatibility issues, making it difficult to adapt to diverse in-vehicle communication environments; and reliance on complex hardware equipment and external systems, which is costly and increases the complexity of the in-vehicle system. Summary of the invention

[0004] In view of this, the embodiments of the present invention provide a partition upgrade method, apparatus, computer equipment and storage medium for vehicle services to solve the problems faced by vehicle instrument upgrades under the SOA architecture, such as low security, lack of attention to upgrade failures, and lack of consideration of communication compatibility.

[0005] In a first aspect, an embodiment of the present invention provides a partition upgrade method for an in-vehicle service, which is applied to an instrument terminal, and the method includes:

[0006] Receiving a service upgrade request from each vehicle-mounted application in the target vehicle, wherein the service upgrade request includes a service identifier and a current version number of the service to be upgraded;

[0007] Based on the service identifier, query the partition upgrade service system of the meter end for service information and an updated version number of the service to be upgraded, and compare the current version number with the updated version number;

[0008] If the current version number is inconsistent with the updated version number, the service information is filtered according to the configuration file corresponding to the target vehicle to obtain the target service information;

[0009] A service upgrade package is constructed according to the target service information, and the service upgrade package is used to perform a partition upgrade operation on the vehicle-mounted application in the target vehicle.

[0010] In an optional implementation of the present application, before receiving a service upgrade request from each vehicle-mounted application in the target vehicle, the method further includes:

[0011] Creating a first communication interface to establish a first communication link between the instrument terminal and the cloud;

[0012] Creating a second communication interface to establish a second communication link between the instrument end and the vehicle end;

[0013] Acquire multiple service information from the cloud based on the first communication link, and acquire multiple vehicle information from the vehicle side based on the second communication link;

[0014] Constructing a corresponding configuration file according to the vehicle information, and initializing a partition upgrade service system under the SOA architecture;

[0015] The service information is published to each vehicle-mounted application on the vehicle side through the partition upgrade service system.

[0016] In an optional implementation manner of the present application, the filtering of the service information according to the configuration file corresponding to the target vehicle to obtain the target service information includes:

[0017] Traversing multiple configuration files stored in the instrument terminal;

[0018] Querying a target configuration file matching the target vehicle from the plurality of configuration files;

[0019] Determining the module type supported for upgrading of the target vehicle according to the target configuration file;

[0020] The service information is screened based on the module type to obtain target service information corresponding to the module type.

[0021] In an optional implementation of the present application, the using the service upgrade package to perform a partition upgrade operation on the vehicle-mounted application in the target vehicle includes:

[0022] Parsing the service upgrade package to obtain upgrade data;

[0023] Obtaining the current position zone flag of the target vehicle;

[0024] Determine the first partition currently in the running state and the second partition currently in the idle state according to the bit zone flag;

[0025] Writing the upgrade data into the second partition, and detecting whether the upgrade data is successfully written into the second partition, to obtain a detection result;

[0026] A partition upgrade operation is performed on the vehicle-mounted application in the target vehicle based on the detection result.

[0027] In an optional implementation of the present application, performing an upgrade operation on the vehicle-mounted application in the target vehicle based on the detection result includes:

[0028] If the detection result is that the flashing is successful, the second partition is started, a partition upgrade operation is performed on the vehicle-mounted application in the target vehicle in the second partition, and a bit zone flag of the target vehicle and a working state of the second partition are updated;

[0029] Alternatively, if the detection result is a flash failure, a partition switching mechanism is triggered, and an upgrade operation is performed on the in-vehicle application in the target vehicle in the first partition based on the partition switching mechanism.

[0030] In an optional implementation of the present application, performing an upgrade operation on the vehicle-mounted application in the target vehicle in the first partition based on the partition switching mechanism includes:

[0031] Detecting whether the second partition is damaged;

[0032] If the second partition is not damaged, the second partition is started, the upgrade data is written into the first partition, and after the upgrade data is successfully written, the first partition is started, and the in-vehicle application in the target vehicle is upgraded in the first partition;

[0033] Alternatively, if the second partition is damaged, the original data and the upgrade data stored in the second partition are written into the first partition, and the first partition is started to perform an upgrade operation on the vehicle-mounted application in the target vehicle in the first partition.

[0034] In an optional implementation manner of the present application, after performing a partition upgrade operation on the vehicle-mounted application in the target vehicle using the service upgrade package, the following steps are included:

[0035] Check whether the current upgrade operation has any abnormality;

[0036] When an abnormal situation occurs, the current upgrade operation is stopped and the data rollback mechanism is triggered;

[0037] The data rollback mechanism is used to restore the current service version of the vehicle-mounted application in the target vehicle to the historical version before the upgrade.

[0038] In a second aspect, an embodiment of the present invention provides a partition upgrade device for SOA services, which is applied to a meter end, and the device includes:

[0039] A receiving module, configured to receive a service upgrade request from each vehicle-mounted application in a target vehicle, wherein the service upgrade request includes a service identifier and a current version number of the service to be upgraded;

[0040] A query module, used to query the service information and update version number of the service to be upgraded in the partition upgrade service system of the meter end based on the service identifier, and compare the current version number with the update version number;

[0041] A screening module, configured to screen the service information according to a configuration file corresponding to the target vehicle to obtain target service information if the current version number is inconsistent with the updated version number;

[0042] A construction module is used to construct a service upgrade package according to the target service information, and use the service upgrade package to perform a partition upgrade operation on the vehicle-mounted application in the target vehicle.

[0043] In a third aspect, an embodiment of the present invention provides a computer device, comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the method of the first aspect or any corresponding embodiment thereof by executing the computer instructions.

[0044] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute the method of the first aspect or any corresponding embodiment thereof.

[0045] The method provided in the embodiment of the present application has the following beneficial effects:

[0046] The method provided in the embodiment of the present application receives a service upgrade request from an in-vehicle application, and the present invention realizes a timely response to the service upgrade demand, providing a basis for subsequent service upgrade operations. By querying the service information and update version number of the service to be upgraded, and comparing the version numbers, the present invention can accurately determine whether the service needs to be upgraded, avoiding unnecessary upgrade operations and improving the upgrade efficiency. By screening the service information according to the configuration file corresponding to the target vehicle, the present invention can ensure the pertinence and applicability of the upgrade service, avoid the generalization of the upgrade service, and improve the accuracy and effect of the upgrade. By constructing a service upgrade package and performing a partition upgrade operation, the present invention realizes the precise upgrade of the in-vehicle application, improves the success rate and stability of the upgrade, and at the same time reduces the impact of the upgrade on other systems of the vehicle, thereby improving the user experience.

[0047] The method provided in the embodiment of the present application realizes the effective acquisition of service information and vehicle information by creating communication interfaces and links, constructs a customized configuration file for the target vehicle, and provides a basis for subsequent service upgrade operations, thereby improving the accuracy and efficiency of the upgrade. By accurately screening the service information, the pertinence and applicability of the upgrade service are ensured, and unnecessary upgrade operations are avoided. During the upgrade process, the stability and reliability of the upgrade operation are achieved through accurate writing and detection of the upgrade data, as well as flexible control of the upgrade operation, thereby improving the success rate of the upgrade and user experience. The upgrade operation is further optimized by detecting abnormal situations such as partition damage and selecting corresponding upgrade strategies. By detecting whether an abnormal situation occurs in the upgrade operation and triggering the data rollback mechanism, comprehensive protection of the upgrade operation is achieved, thereby improving the robustness of the upgrade and user trust. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0049] Figure 1 is a flowchart of a partition upgrade method for an in-vehicle service according to some embodiments of the present invention;

[0050] Figure 2 is a schematic diagram of the overall architecture of the instrument partition upgrade service according to an embodiment of the present invention;

[0051] Figure 3 is a schematic diagram of a service management process based on SOA architecture according to an embodiment of the present invention;

[0052] Figure 4 is a schematic diagram of the initialization structure of a partition upgrade service system according to an embodiment of the present invention;

[0053] Figure 5 is a flow chart of another partition upgrade method for an in-vehicle service according to an embodiment of the present invention;

[0054] Figure 6 is a flowchart of a partition upgrade method for another in-vehicle service according to an embodiment of the present invention;

[0055] Figure 7 is a structural block diagram of a partition upgrade device for SOA services according to an embodiment of the present invention;

[0056] Figure 8 It is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0057] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0058] According to an embodiment of the present invention, a partition upgrade method, apparatus, computer device and storage medium for in-vehicle services are provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in an order different from that shown here.

[0059] In this embodiment, a partition upgrade method for an in-vehicle service is provided, which is applied to a meter terminal. Figure 1 is a flow chart of a partition upgrade method for an in-vehicle service according to an embodiment of the present invention. Figure 1 As shown, the process includes the following steps:

[0060] Step S11, receiving a service upgrade request from each vehicle-mounted application in the target vehicle, wherein the service upgrade request includes a service identifier of the service to be upgraded and a current version number.

[0061] In the embodiment of the present application, when the vehicle instrument system is running, if the vehicle-mounted application of the target vehicle needs to be upgraded, a request will be sent to the partition upgrade service. The request contains the identifier of the service to be upgraded to clarify which specific application needs to be upgraded, and also includes the current version number, which is used to compare with the update version number to determine whether and how to upgrade. For example, when a multimedia service finds a new version, it sends a request to the partition upgrade service. The service identifier indicates that it is a multimedia service request, and the current version number reflects its software version. The partition upgrade service determines whether it is an upgrade for the service based on this.

[0062] It should be noted that if Figure 2As shown, the overall architecture of the present invention is mainly composed of three parts: the vehicle side, the cloud side, and the instrument side. Through the collaborative work of these three parts, the partition upgrade service of the digital instrument is realized, the flexibility and efficiency of the upgrade are improved, and the dependence on hardware is reduced. Among them, the cloud side is responsible for connecting with the OTA remote upgrade system, downloading related software upgrade packages and other service information required for the upgrade, and establishing a communication connection with the instrument side through TCP. The vehicle side includes multiple on-board applications, which receive upgrade service information through the communication link between the vehicle side and the instrument side. The instrument side includes a SOA gateway, which is responsible for establishing communication connections with the cloud side and the vehicle side, interacting with the partition upgrade service system, and is responsible for allocating and managing multiple service information.

[0063] Specifically, Figure 3 As shown in the figure, this is a schematic diagram of the service registration, search, request and release process based on SOA (service-oriented architecture). Under the SOA architecture, the service registration center is the core and is responsible for the centralized management of service information. Service providers (such as the service upgrade module of the vehicle application) register the services they provide (such as service information) with the center, including key information such as service identification and current version number. The service requester (such as the instrument or cloud) searches for the required service through the service registration center and determines whether it needs to be upgraded based on the service identification and version number.

[0064] In the embodiment of the present application, before receiving the service upgrade request from each vehicle-mounted application in the target vehicle, the following steps A1-A5 are included:

[0065] Step A1, create a first communication interface, and establish a first communication link between the meter and the cloud.

[0066] Specifically, to achieve the digital instrument software upgrade, it is necessary to first establish a communication connection between the instrument and the cloud. Create a first communication interface, which is responsible for data transmission between the instrument and the cloud, so as to establish a first communication link so that the instrument can communicate with the cloud server. The cloud is a background server connected to the OTA remote upgrade, responsible for downloading the upgrade package. After establishing this link, the instrument can obtain upgrade information and data from the cloud to prepare for the partition upgrade service.

[0067] Step A2, creating a second communication interface, and establishing a second communication link between the instrument end and the vehicle end.

[0068] Specifically, in the partition upgrade of the digital instrument, in addition to connecting to the cloud, a second communication interface needs to be created to establish a communication link with the vehicle. This interface is responsible for data transmission between the instrument and the vehicle. After the link is established, the instrument can communicate with other systems on the vehicle to obtain vehicle status information, etc. It can also provide partition upgrade services for the vehicle, realize collaborative upgrades, reduce hardware dependence, and improve upgrade efficiency and stability.

[0069] Step A3: obtaining multiple service information from the cloud based on the first communication link, and obtaining multiple vehicle information from the vehicle side based on the second communication link.

[0070] Specifically, the first communication link is used to obtain service information such as software upgrade packages, upgrade instructions, and service version information from the cloud (backend server connected to OTA remote upgrade) for digital instrument upgrade. At the same time, the second communication link is used to obtain vehicle status information (such as engine status, battery power, vehicle speed, etc.), fault codes, and other vehicle information from the vehicle side (including vehicle computer services and other parts that need to be upgraded). This information can help the instrument side understand the vehicle's operating status to make reasonable decisions during the upgrade, and can also provide a reference for the digital instrument upgrade to ensure that it works in coordination with other vehicle systems.

[0071] Step A4: construct a corresponding configuration file according to the vehicle information, and initialize the partition upgrade service system under the SOA architecture.

[0072] Specifically, Figure 4 As shown, the partition upgrade service system includes: a service discovery module, a data acquisition module, a control module, a classification and filtering storage module, a flashing module, a partition switching module and a configuration file. During the initialization process of the partition upgrade service system, first, the data acquisition module will create a UDS socket and perform service monitoring. At the same time, the service discovery module will create or configure one or more sockets, which are used to communicate bidirectionally with the cloud and other services or applications that need to be upgraded inside the vehicle through the network. After that, register the instrument partition upgrade service and publish the service. In the instrument system, each service will also receive the service published by the service discovery module, and obtain the information in the configuration file and save it in the local central processor, waiting for other services to need to use the service, and then make a service subscription call. Thus, the initialization of the partition upgrade service is completed, providing a stable and reliable service foundation for the upgrade of digital instruments.

[0073] Step A5: publish the service information to various vehicle-mounted applications on the vehicle side through the partition upgrade service system.

[0074] Specifically, the service discovery module in the partition upgrade service system will publish service information including software upgrade packages, upgrade instructions, service version information, etc. to the vehicle-side engineering mode, OTA applications, multimedia services, 4G modules and other vehicle-mounted applications that have upgrade requirements. As a result, each vehicle-mounted application can know which upgrade services are available so that it can make service requests when necessary and start the upgrade process. In this way, the effective dissemination and application of digital instrument upgrade services on the vehicle side is realized, providing a basis for the partition upgrade of digital instruments.

[0075] Step S12: query the service information and update version number of the service to be upgraded in the partition upgrade service system of the meter end based on the service identifier, and compare the current version number with the update version number.

[0076] In the embodiment of the present application, after receiving the service upgrade request of the target vehicle's onboard application, the instrument-side partition upgrade service system is queried according to the service identifier in the request. The system includes a service discovery module, etc., and the service discovery module can be used to find the service information to be upgraded and the update version number. Then the current version number is compared with the update version number. If they are consistent, it means that the software version is the latest and does not need to be upgraded, and the process ends; if they are inconsistent, there is a new version of the software that needs to be upgraded.

[0077] Step S13: If the current version number is inconsistent with the updated version number, the service information is filtered according to the configuration file corresponding to the target vehicle to obtain the target service information.

[0078] In the embodiment of the present application, if the current version number is inconsistent with the updated version number, an upgrade process is required. At this time, the target service information is obtained by filtering the service information according to the configuration file of the target vehicle. Specifically, Figure 5 As shown, a service upgrade request is received, and then the version number of the current service is immediately obtained and compared with the version number to be updated. If the two version numbers are the same, it is determined that there is no need to upgrade and the upgrade process is directly abandoned. If the version numbers are inconsistent, the process continues to obtain the necessary upgrade configuration files and check whether the required module type exists. If the module type is missing or the configuration file integrity and legality check fails, an error will be reported and the upgrade will be terminated. Once all checks are successful, a service upgrade package will be built and the partition upgrade process will be automatically entered. Finally, after the upgrade is completed, a reset and restart operation is performed.

[0079] In the embodiment of the present application, the service information is screened according to the configuration file corresponding to the target vehicle to obtain the target service information, including the following steps B1-B4:

[0080] Step B1, traverse multiple configuration files stored in the instrument end.

[0081] Specifically, in the partition upgrade process based on the automobile instrument SOA architecture, multiple configuration files stored in the instrument end are traversed. The purpose is to determine which modules the current device supports for upgrade. If the configuration file of a module does not exist, it means that the current device does not need to upgrade the module, an error will be reported and the upgrade will be abandoned; if the configuration file exists, the next step is to verify the integrity and legality of the upgrade package. By traversing the configuration file, the modules that need to be upgraded can be accurately determined, unnecessary upgrade operations can be avoided, and the efficiency and accuracy of the upgrade can be improved.

[0082] Step B2: searching for a target configuration file matching the target vehicle from multiple configuration files.

[0083] Specifically, searching for a target configuration file that matches a target vehicle from multiple configuration files can be achieved as follows: first, compare the target vehicle's specific identification information, such as vehicle model and VIN code, one by one in multiple configuration files; second, filter and search based on key attributes such as the target vehicle's hardware features and software version; third, calculate the matching degree between the key parameters of the configuration file and the parameters of the target vehicle through a preset query algorithm, and determine it as the target configuration file when the matching degree reaches a certain threshold. In short, by extracting the key information of the vehicle and performing operations such as comparison, screening, and calculation with the configuration files, the target configuration file can be accurately found from multiple configuration files.

[0084] It should be noted that the key parameters of the configuration file include but are not limited to: vehicle hardware related parameters (specific hardware module model, hardware function feature identification), software version related parameters (the current software version information includes the operating system and middleware versions, software function module versions such as audio processing, display driver version, etc.), vehicle model and configuration related parameters (vehicle model code, configuration level such as basic version and deluxe version, etc.) and upgrade module support identification (setting support or non-support identification for each upgrade module such as Linux module, hypervisor, FPGA, audio, display, Hud (head-up display), secondary screen, reserved class, etc.).

[0085] Step B3: determining the module types supported for upgrading of the target vehicle according to the target configuration file.

[0086] Specifically, the target vehicle's supported upgrade module types are determined based on the target configuration file. The target configuration file contains key information such as vehicle hardware, software version, vehicle model, configuration-related parameters, and upgrade module support identification, which can clarify the upgrade feasibility of the target vehicle in various modules such as the Linux module, making the upgrade more accurate, avoiding wasting resources and time on unsupported modules, ensuring efficient operation while matching the actual vehicle conditions, and improving system stability and reliability.

[0087] Step B4, filtering the service information based on the module type to obtain target service information corresponding to the module type.

[0088] Specifically, after determining the upgrade module types supported by the target vehicle, analyze the correlation between each module requirement and service information, and perform targeted screening of service information. For example, if the target vehicle supports Linux module upgrades, select relevant service information from a large number of service information, such as upgrade tools, process guidance, etc. This ensures that only service information related to the target module is obtained and used, avoiding irrelevant interference, meeting the upgrade requirements of different modules, and ensuring a smooth upgrade process.

[0089] Step S14, constructing a service upgrade package according to the target service information, and using the service upgrade package to perform a partition upgrade operation on the vehicle-mounted application in the target vehicle.

[0090] Specifically, after determining the target service information corresponding to the module type supported by the target vehicle, these specific service information are integrated, including upgrade tools for different modules, upgrade process guidance, etc., to build a special service upgrade package. Then, use this service upgrade package to perform a partition upgrade operation on the vehicle-mounted applications in the target vehicle. Since this upgrade method is based on the SOA architecture, different modules or functional areas can be upgraded one by one during the upgrade process.

[0091] As an example, take the target vehicle supporting the hypervisor module upgrade as an example. When using the service upgrade package for the upgrade, the module partition operation is performed. During the upgrade, the data is written to the non-current running partition. If the flash is successful, the version information is stored, the boot partition is switched, the bit area flag is updated, and the upgrade success status is fed back and waits for restart; if the flash fails, it is determined whether the partition is complete. If it is complete, the failure is fed back and the current partition is started. If it is incomplete, the data is copied to another partition and the failure is fed back and the current partition is started. This can achieve seamless upgrades, ensure that the system can roll back to the old version of the software when the upgrade is wrong or fails, and ensure stability and reliability.

[0092] In the embodiment of the present application, the partition upgrade operation is performed on the vehicle-mounted application in the target vehicle using the service upgrade package, including the following steps C1-C5:

[0093] Step C1, parse the service upgrade package to obtain upgrade data.

[0094] Specifically, since the service upgrade contains data information such as software code updates, configuration file adjustment content, upgrade tool instructions and process guidance for specific modules (such as Linux, hypervisor modules, etc.), the format is a specific compressed or custom data packet format for storage and transmission. Therefore, after building a service upgrade package for a specific module of the target vehicle, it is necessary to parse it and extract key data including software code updates, configuration adjustments, new functional modules, etc. through specific algorithms or tools. The purpose is to convert the upgrade package information into data that can actually be used for upgrade operations so that it can be accurately written into the target partition upgrade.

[0095] Step C2, obtaining the current position zone flag of the target vehicle.

[0096] Specifically, the bit zone flag is used to indicate the partition currently in use, i.e., the first partition (partition A) or the second partition (partition B). By obtaining the bit zone flag, it is possible to determine which partition the current target vehicle is in. The main difference between the first and second partitions is that they store different software versions and which partition the target vehicle starts and runs from at a specific point in time. During the upgrade process, data will be written to the partition that is not currently running, which ensures that the upgrade process will not interfere with the running software. By obtaining the bit zone flag, a key judgment basis is provided for the subsequent accurate partition upgrade operation.

[0097] Step C3, determining the first partition currently in the running state and the second partition currently in the idle state according to the bit zone flag.

[0098] Specifically, the currently running first partition (partition A) and the idle second partition (partition B) are determined according to the bit zone flag. The bit zone flag indicates the currently used partition, thereby distinguishing the first partition where the software is running and the idle second partition. This distinction is important because during the upgrade, data will be written to the idle partition that is not currently running to avoid interference with the running software.

[0099] Step C4, writing the upgrade data into the second partition, and detecting whether the upgrade data is successfully written into the second partition to obtain a detection result.

[0100] Specifically, after determining the first partition that is currently in operation and the second partition that is in idle state, the upgrade data parsed from the service upgrade package is written to the second partition. The purpose is to perform the upgrade operation without affecting the currently running software (i.e., the software in the first partition). After the writing is completed, a test is performed to determine whether the upgrade data is successfully written to the second partition. After the test, a test result will be obtained, including whether the flashing is successful or failed. The test process may include: comparing the size and quantity of data before and after writing and whether the checksum is consistent; performing functional testing on specific software modules; checking whether the version information of the second partition is consistent with expectations; checking error logs and analyzing log files to find successful prompt information.

[0101] Step C5: performing a partition upgrade operation on the vehicle-mounted application in the target vehicle based on the detection result.

[0102] In an embodiment of the present application, step C5 includes: if the detection result is that the flashing is successful, starting the second partition, performing a partition upgrade operation on the in-vehicle application in the target vehicle in the second partition, and updating the bit zone flag of the target vehicle and the working status of the second partition; if the detection result is that the flashing fails, triggering the partition switching mechanism, and performing an upgrade operation on the in-vehicle application in the target vehicle in the first partition based on the partition switching mechanism.

[0103] Specifically, if the detection result is that the flashing is successful, that is, the upgrade data is successfully written into the second partition, the second partition is started, and the vehicle application is upgraded using the upgrade data therein, and the target vehicle area flag is updated to the second partition, and the working state of the second partition is updated to running. If the detection result is that the flashing fails, the partition switching mechanism is triggered. This mechanism ensures that the system runs normally and attempts to upgrade when the upgrade data fails to be flashed. Based on this mechanism, the upgrade operation is performed on the vehicle application in the first partition.

[0104] In the embodiment of the present application, performing an upgrade operation on the vehicle-mounted application in the target vehicle in the first partition based on the partition switching mechanism includes the following steps D1-D3:

[0105] Step D1, detecting whether the second partition is damaged.

[0106] It should be noted that during the partition upgrade process, especially after the data is written to the second partition, if the writing fails, it is necessary to determine the status of the second partition. The purpose of detecting whether the second partition is damaged is to determine whether the partition can be used normally and whether subsequent upgrade operations or data rollback operations can be successfully performed.

[0107] Specifically, the damage of the second partition can be detected in the following ways:

[0108] Method 1: File system check. This includes traversing the partition file system and comparing it with the expected directory structure to determine whether the second partition file directory structure is complete. If there is confusion, missing key directories, or abnormal file paths, the partition may be damaged. Or, check file attributes (such as size, creation time, modification time, etc.). If the attributes are abnormal (such as size is zero, creation time does not match, etc.), the file may be damaged. Or, randomly select some files. If there are errors in reading, such as being unable to open, incomplete content, or garbled characters, the partition may be damaged.

[0109] Method 2: Check the partition boot information. This includes using special tools or software to read and check whether the second partition boot record is complete and correct. If the boot record is damaged, the partition will not be able to start normally. Or, check the boot sector and analyze the boot sector content such as disk signature, partition table information, etc. to determine whether the sector is damaged, tampered or cannot be read normally.

[0110] Method 3: Bad track detection. Use a disk detection tool to detect bad tracks on the disk where the second partition is located. If there are bad tracks, it may affect the normal use of the partition and even cause data loss and partition damage. The bad track detection tool can scan the disk surface to mark the bad track position for easy processing. Or, check the disk health status (including read and write speed, response time, error rate and other indicators). If the indicators are abnormal, it means that the disk may be damaged.

[0111] Method 4: Partition startup test. Try to start the system or specific application from the second partition. If there is an error, freeze, or the system cannot be entered normally, it may indicate that the second partition is damaged. Alternatively, test the specific software or functions stored in the second partition, such as playing audio test sounds when storing audio files, and checking whether the images are displayed normally when storing image files, to determine whether the partition is damaged.

[0112] Step D2, if the second partition is not damaged, start the second partition, write the upgrade data into the first partition, and after the upgrade data is successfully written, start the first partition and perform the upgrade operation on the vehicle-mounted application in the target vehicle in the first partition.

[0113] Specifically, if the second partition is not damaged, the system can be safely booted to the partition to ensure that the upgrade process does not affect the currently running software version. When the system is running in the second partition, the new upgrade data can be written to the first partition to prepare the new version data without interfering with the currently running system. After the upgrade data is successfully written, the system can safely switch to the first partition and start the new version of the system or application. This step ensures seamless switching and error rollback capabilities during the upgrade process. Even if problems occur during the upgrade process, the system can roll back to the previously stable partition.

[0114] Step D3: if the second partition is damaged, the original data and the upgrade data stored in the second partition are written into the first partition, and the first partition is started, and the upgrade operation is performed on the vehicle-mounted application in the target vehicle in the first partition.

[0115] Specifically, since the second partition is damaged and cannot be upgraded directly, the original data of the second partition needs to be written to the currently running first partition together with the new upgrade data to create a complete image containing the new upgrade data and the original data. This is done to maintain the integrity and consistency of the data during the upgrade process. After the data is successfully written, the system can safely switch to the first partition and start the software or application, and then perform the upgrade operation to update the in-vehicle application or software. This step ensures that the system can safely perform the upgrade operation and maintain the integrity and consistency of the data even if the second partition is damaged.

[0116] As an example, Figure 6As shown, take the upgrade of an in-vehicle application of a target vehicle as an example. The vehicle is provided with two partitions, A and B. First, obtain the current bit zone identifier to determine whether it is currently in partition A. If it is not partition A, write the upgrade data to partition A; if it is partition A, write the upgrade data to partition B. Secondly, check whether the data flash is successful. If the flash is successful, start the flash partition for upgrade, store the version information in the flash partition, and update the bit zone flag and working status. If the flash fails, further check whether the flash partition is complete. If the flash partition is complete (ie, not damaged), feedback the current status; if the flash partition is incomplete (ie, damaged), write the upgrade data to another partition, and feedback the status.

[0117] In an embodiment of the present application, after using the service upgrade package to perform a partition upgrade operation on the in-vehicle application in the target vehicle, it includes: detecting whether an abnormal situation occurs in the current upgrade operation; when an abnormal situation occurs, stopping the current upgrade operation and triggering a data rollback mechanism; using the data rollback mechanism to restore the current service version of the in-vehicle application in the target vehicle to the historical version before the upgrade.

[0118] Specifically, during the upgrade process, key indicators and status are continuously monitored to detect abnormal situations, such as upgrade data write failure, partition damage, communication errors, incomplete or damaged upgrade packages, etc. When an abnormal situation occurs, the upgrade operation is stopped immediately to protect the vehicle applications and data from damage. Subsequently, the data rollback mechanism is triggered to restore the service version of the vehicle application to the historical version before the upgrade. This process ensures that even if problems occur during the upgrade process, the vehicle application can continue to operate normally and is not affected.

[0119] In this embodiment, a partition upgrade device for SOA service is also provided, which is used to implement the above embodiments and preferred implementation modes, and the descriptions that have been made will not be repeated. As used below, the term "module" can implement a combination of software and / or hardware of a predetermined function. Although the device described in the following embodiments is preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0120] This embodiment provides a partition upgrade device for SOA services, which is applied to a meter end, such as Figure 7 As shown, including:

[0121] The receiving module 71 is used to receive a service upgrade request from each vehicle-mounted application in the target vehicle, wherein the service upgrade request includes a service identifier and a current version number of the service to be upgraded;

[0122] A query module 72, for querying the service information and update version number of the service to be upgraded in the partition upgrade service system of the meter end based on the service identifier, and comparing the current version number with the update version number;

[0123] A screening module 73 is used to screen the service information according to the configuration file corresponding to the target vehicle to obtain the target service information if the current version number is inconsistent with the updated version number;

[0124] The construction module 74 is used to construct a service upgrade package according to the target service information, and use the service upgrade package to perform a partition upgrade operation on the vehicle-mounted application in the target vehicle.

[0125] In an optional embodiment of the present application, the device also includes: a creation module, used to create a first communication interface, establish a first communication link between the instrument end and the cloud; create a second communication interface, establish a second communication link between the instrument end and the vehicle end; obtain multiple service information from the cloud based on the first communication link, and obtain multiple vehicle information from the vehicle end based on the second communication link; construct a corresponding configuration file based on the vehicle information, and initialize the partition upgrade service system under the SOA architecture; publish the service information to various vehicle-mounted applications on the vehicle end through the partition upgrade service system.

[0126] In an optional implementation of the present application, the screening module 73 is used to traverse multiple configuration files stored in the instrument terminal; query a target configuration file that matches the target vehicle from the multiple configuration files; determine the module type supported for upgrading by the target vehicle according to the target configuration file; and screen the service information based on the module type to obtain the target service information corresponding to the module type.

[0127] In an optional embodiment of the present application, a construction module 74 is used to parse the service upgrade package to obtain upgrade data; obtain the current bit zone flag of the target vehicle; determine the first partition that is currently in operation and the second partition that is in idle state according to the bit zone flag; write the upgrade data to the second partition, and detect whether the upgrade data is successfully written to the second partition to obtain a detection result; and perform a partition upgrade operation on the on-board application in the target vehicle based on the detection result.

[0128] In an optional embodiment of the present application, a construction module 74 is used to start the second partition if the detection result is a successful flashing, perform a partition upgrade operation on the in-vehicle application in the target vehicle in the second partition, and update the bit zone flag of the target vehicle and the working status of the second partition; or, if the detection result is a flashing failure, trigger the partition switching mechanism, and perform an upgrade operation on the in-vehicle application in the target vehicle in the first partition based on the partition switching mechanism.

[0129] In an optional embodiment of the present application, a construction module 74 is used to detect whether the second partition is damaged; if the second partition is not damaged, the second partition is started, the upgrade data is written to the first partition, and after the upgrade data is successfully written, the first partition is started, and the upgrade operation is performed on the vehicle-mounted application in the target vehicle in the first partition; or, if the second partition is damaged, the original data and the upgrade data stored in the second partition are written to the first partition, and the first partition is started, and the upgrade operation is performed on the vehicle-mounted application in the target vehicle in the first partition.

[0130] In an optional embodiment of the present application, the device also includes: a recovery module for detecting whether an abnormal situation occurs in the current upgrade operation; when an abnormal situation occurs, stopping the current upgrade operation and triggering a data rollback mechanism; using the data rollback mechanism to restore the current service version of the in-vehicle application in the target vehicle to the historical version before the upgrade.

[0131] See also Figure 8 , Figure 8 is a schematic diagram of the structure of a computer device provided by an optional embodiment of the present invention, such as Figure 8 As shown, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. Various components are connected to each other using different buses for communication, and can be installed on a common mainboard or installed in other ways as needed. The processor can process the instructions executed in the computer device, including instructions stored in or on the memory to display the graphical information of the GUI on an external input / output device (such as, a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system).

[0132] The processor 10 may be a central processing unit, a network processor or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be a dedicated integrated circuit, a programmable logic device or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic or any combination thereof.

[0133] The memory 20 stores instructions executable by at least one processor 10, so that at least one processor 10 executes the method shown in the above embodiment.

[0134] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created by the use of a computer device based on the presentation of a small program landing page, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely arranged relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0135] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid state drive; the memory 20 may also include a combination of the above types of memory.

[0136] The computer device further comprises a communication interface 30 for the computer device to communicate with other devices or a communication network.

[0137] The embodiment of the present invention also provides a computer-readable storage medium. The method according to the embodiment of the present invention can be implemented in hardware, firmware, or can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium through a network download, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state hard disk, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor, or hardware, the method shown in the above embodiment is implemented.

[0138] Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations are all within the scope defined by the appended claims.

Claims

1. A partition upgrade method for vehicle-mounted services, applied to an instrument terminal, characterized in that: The method comprises: Receiving a service upgrade request from each vehicle-mounted application in the target vehicle, wherein the service upgrade request includes a service identifier and a current version number of the service to be upgraded; Based on the service identifier, query the partition upgrade service system of the meter end for service information and an updated version number of the service to be upgraded, and compare the current version number with the updated version number; If the current version number is inconsistent with the updated version number, the service information is filtered according to the configuration file corresponding to the target vehicle to obtain the target service information; A service upgrade package is constructed according to the target service information, and the service upgrade package is used to perform a partition upgrade operation on the vehicle-mounted application in the target vehicle.

2. The method according to claim 1, characterized in that Before receiving the service upgrade request from each in-vehicle application in the target vehicle, the method further includes: Creating a first communication interface to establish a first communication link between the instrument terminal and the cloud; Creating a second communication interface to establish a second communication link between the instrument end and the vehicle end; Acquire multiple service information from the cloud based on the first communication link, and acquire multiple vehicle information from the vehicle side based on the second communication link; Constructing a corresponding configuration file according to the vehicle information, and initializing a partition upgrade service system under the SOA architecture; The partition upgrade service system publishes service information to various vehicle-mounted applications on the vehicle side.

3. The method according to claim 1, characterized in that The filtering of the service information according to the configuration file corresponding to the target vehicle to obtain the target service information includes: Traversing multiple configuration files stored in the instrument terminal; Querying a target configuration file matching the target vehicle from the plurality of configuration files; Determining the module type supported for upgrading of the target vehicle according to the target configuration file; The service information is screened based on the module type to obtain target service information corresponding to the module type.

4. The method according to claim 1, characterized in that: The using the service upgrade package to perform a partition upgrade operation on the vehicle-mounted application in the target vehicle includes: Parsing the service upgrade package to obtain upgrade data; Obtaining the current position zone flag of the target vehicle; Determine the first partition currently in the running state and the second partition currently in the idle state according to the bit zone flag; Writing the upgrade data into the second partition, and detecting whether the upgrade data is successfully written into the second partition, and obtaining a detection result; A partition upgrade operation is performed on the vehicle-mounted application in the target vehicle based on the detection result.

5. The method according to claim 4, characterized in that The performing an upgrade operation on the vehicle-mounted application in the target vehicle based on the detection result includes: If the detection result is that the flashing is successful, the second partition is started, a partition upgrade operation is performed on the vehicle-mounted application in the target vehicle in the second partition, and a bit zone flag of the target vehicle and a working state of the second partition are updated; Alternatively, if the detection result is a flash failure, a partition switching mechanism is triggered, and an upgrade operation is performed on the in-vehicle application in the target vehicle in the first partition based on the partition switching mechanism.

6. The method according to claim 5, characterized in that The performing an upgrade operation on the vehicle-mounted application in the target vehicle in the first partition based on the partition switching mechanism includes: Detecting whether the second partition is damaged; If the second partition is not damaged, the second partition is started, the upgrade data is written into the first partition, and after the upgrade data is successfully written, the first partition is started, and the in-vehicle application in the target vehicle is upgraded in the first partition; Alternatively, if the second partition is damaged, the original data and the upgrade data stored in the second partition are written into the first partition, and the first partition is started to perform an upgrade operation on the vehicle-mounted application in the target vehicle in the first partition.

7. The method according to claim 1, characterized in that After performing a partition upgrade operation on the vehicle-mounted application in the target vehicle using the service upgrade package, the method includes: Check whether the current upgrade operation has any abnormality; When an abnormal situation occurs, the current upgrade operation is stopped and the data rollback mechanism is triggered; The data rollback mechanism is used to restore the current service version of the vehicle-mounted application in the target vehicle to the historical version before the upgrade.

8. A partition upgrade device for SOA services, characterized in that: Applied to the instrument end, the device comprises: A receiving module, configured to receive a service upgrade request from each vehicle-mounted application in a target vehicle, wherein the service upgrade request includes a service identifier and a current version number of the service to be upgraded; A query module, used to query the service information and update version number of the service to be upgraded in the partition upgrade service system of the meter end based on the service identifier, and compare the current version number with the update version number; A screening module, configured to screen the service information according to a configuration file corresponding to the target vehicle to obtain target service information if the current version number is inconsistent with the updated version number; A construction module is used to construct a service upgrade package according to the target service information, and use the service upgrade package to perform a partition upgrade operation on the vehicle-mounted application in the target vehicle.

9. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the method according to any one of claims 1 to 7 by executing the computer instructions.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the method according to any one of claims 1 to 7.

Citation Information

Patent Citations

  • OSGi (Open Service Gateway Initiative)-based remote real-time automobile diagnosis system

    CN102213962A

  • Intelligent vehicle service system based on Internet of vehicles

    CN108845562A

  • Automobile instrument upgrading method and system, vehicle and medium

    CN114780116A

  • Software upgrade method and apparatus for vehicle-mounted controller, and device and storage medium

    WO2023241458A1

Cited By

  • OTA upgrading method and equipment of intelligent equipment, medium and program product

    CN120730291A

  • Vehicle fault diagnosis system based on TBOX

    CN121541629A

  • Dual-backup starting and integrity verification method and system for vehicle-mounted bus

    CN121560359A

  • Method and system for dual backup starting and integrity verification of vehicle-mounted bus

    CN121560359B