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

Abstract

The present application 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, which are applied to an instrument end, and the method comprises the following steps: receiving service upgrading requests from each vehicle-mounted application in a target vehicle, wherein the service upgrading request comprises a service identifier and a current version number of the service to be upgraded; querying service information and an updated version number of the service to be upgraded 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 inconsistent with the updated version number, screening the service information according to a configuration file corresponding to the target vehicle to obtain target service information; constructing a service upgrading package according to the target service information, and performing a partition upgrading operation on the vehicle-mounted application in the target vehicle by using the service upgrading package. The present application solves the problems of low safety and failure to pay attention to the upgrading failure of the instrument under the SOA architecture.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of instrument upgrading, and particularly relates to a partition upgrading method and device for vehicle-mounted services, a computer device and a storage medium. BACKGROUND

[0002] With the vigorous development of the automotive intelligent industry and the widespread popularity of Ethernet, intelligent cockpit technology is undergoing rapid changes. In this process, the adoption of digital instruments in vehicles has become an irreversible trend, which greatly improves the driving experience and enhances the functionality of vehicles. However, the adoption of digital instruments inevitably involves the problem of software upgrading, which is a key link to ensure the continuous optimization of instrument functions and the timely repair of security vulnerabilities.

[0003] Most existing digital instrument upgrading technologies are based on non-SOA architecture, which has many shortcomings: low security, vulnerable to system black screen, freezing and other problems; insufficient consideration of upgrade failure, which may cause damage to instrument functions and affect vehicle system stability; insufficient consideration of communication compatibility, making it difficult to adapt to diverse vehicle communication environments; and dependence on complex hardware devices and external systems, resulting in high costs and increasing the complexity of vehicle systems. SUMMARY

[0004] Therefore, the embodiments of the present application provide a partition upgrading method and device for vehicle-mounted services, a computer device and a storage medium to solve the problems of low security, lack of consideration of upgrade failure and lack of consideration of communication compatibility in the upgrading of vehicle instrument under SOA architecture.

[0005] In a first aspect, the embodiments of the present application provide a partition upgrading method for vehicle-mounted services applied to an instrument end, which comprises:

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

[0007] querying service information and an updated version number of the service to be upgraded 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;

[0008] if the current version number and the updated version number are inconsistent, filtering the service information according to a configuration file corresponding to the target vehicle to obtain target service information;

[0009] constructing a service upgrade package according to the target service information, and performing a partition upgrading operation on the vehicle-mounted applications in the target vehicle using the service upgrade package.

[0010] In an optional embodiment of the present application, before receiving the service upgrade request from each vehicle application in the target vehicle, the method further comprises:

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

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

[0013] obtaining a plurality of service information from the cloud based on the first communication link, and obtaining a plurality of vehicle information from the vehicle 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] publishing the service information to each vehicle application in the vehicle through the partition upgrade service system.

[0016] In an optional embodiment of the present application, the service information is filtered according to the configuration file corresponding to the target vehicle to obtain target service information, comprising:

[0017] traversing a plurality of configuration files stored in the instrument cluster;

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

[0019] determining the module type supported by the target vehicle for upgrade according to the target configuration file;

[0020] filtering the service information based on the module type to obtain target service information corresponding to the module type.

[0021] In an optional embodiment of the present application, the partition upgrade operation is performed on the vehicle application in the target vehicle using the service upgrade package, comprising:

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

[0023] obtaining the current zone mark of the target vehicle;

[0024] determining a first partition currently in a running state and a second partition in an idle state according to the zone mark;

[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] perform a partition upgrade operation on the in-vehicle application in the target vehicle based on the detection result.

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

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

[0029] If the detection result is that the flashing fails, 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 embodiment of the present application, the performing of the upgrade operation on the in-vehicle application in the target vehicle in the first partition based on the partition switching mechanism comprises:

[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 writing of the upgrade data succeeds, the first partition is started, and an upgrade operation is performed on the in-vehicle application in the target vehicle in the first partition;

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

[0034] In an optional embodiment of the present application, after the performing of the partition upgrade operation on the in-vehicle application in the target vehicle by using the service upgrade package, the method further comprises:

[0035] detecting whether an abnormal situation occurs in the current upgrade operation;

[0036] when the abnormal situation occurs, stopping the current upgrade operation, and triggering a data rollback mechanism;

[0037] restoring the current service version of the in-vehicle application in the target vehicle to a historical version before the upgrade by using the data rollback mechanism.

[0038] In a second aspect, an embodiment of the present application provides a partition upgrade device of an SOA service, which is applied to an instrument end, and the device comprises:

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

[0040] The querying module is configured to query service information of the service to be upgraded and an updated version number in the partition upgrade service system at the instrument end based on the service identifier, and compare the current version number with the updated version number.

[0041] The screening module is configured to screen the service information according to the 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] The constructing module is configured to construct a service upgrade package according to the target service information, and perform a partition upgrade operation on the vehicle-mounted application in the target vehicle by using the service upgrade package.

[0043] In a third aspect, an embodiment of the present application provides a computer device, including a memory and a processor, the memory and the processor are communicatively connected with each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the method in the first aspect or any of the corresponding embodiments.

[0044] In a fourth aspect, an embodiment of the present application provides a computer readable storage medium, the computer readable storage medium stores computer instructions, and the computer instructions are used to make a computer execute the method in the first aspect or any of the corresponding embodiments.

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

[0046] The method provided by the embodiment of the present application receives a service upgrade request from a vehicle-mounted application, and the present application realizes timely response to service upgrade demand and provides a basis for subsequent service upgrade operation. By querying service information of a service to be upgraded and an updated version number and comparing version numbers, the present application can accurately determine whether a service needs to be upgraded, avoids unnecessary upgrade operation, and improves upgrade efficiency. By screening service information according to a configuration file corresponding to a target vehicle, the present application can ensure the pertinence and applicability of an upgraded service, avoids generalization of the upgraded service, and improves the accuracy and effect of the upgrade. By constructing a service upgrade package and performing a partition upgrade operation, the present application realizes accurate upgrade of a vehicle-mounted application, improves the success rate and stability of the upgrade, reduces the influence of the upgrade on other systems of a vehicle, and improves user experience.

[0047] The method provided by the embodiment of the application realizes effective acquisition of service information and vehicle information by creating a communication interface and a link, constructs a customized configuration file for a target vehicle, and provides a basis for subsequent service upgrade operations, thereby improving the accuracy and efficiency of the upgrade. Through accurate screening of the service information, the pertinence and applicability of the upgrade service are ensured, and unnecessary upgrade operations are avoided. In the upgrade process, the stability and reliability of the upgrade operation are realized through accurate writing and detection of the upgrade data and flexible upgrade operation control, and the success rate of the upgrade and user experience are improved. Through detection of abnormal conditions such as partition damage and selection of corresponding upgrade strategies, the upgrade operation is further optimized. Through detection of whether an abnormal condition occurs in the upgrade operation and triggering of a data rollback mechanism, comprehensive protection of the upgrade operation is realized, and the robustness and user trust of the upgrade are improved. BRIEF DESCRIPTION OF DRAWINGS

[0048] In order to more clearly illustrate the technical solutions in the specific embodiments or prior art of the present application, the drawings needed to be used in the specific embodiments or prior art description will be briefly introduced. Obviously, the drawings in the following description are some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0049] Figure 1 is a flowchart of a partition upgrade method of a vehicle service according to some embodiments of the present application;

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

[0051] Figure 3 is a service management flowchart based on an SOA architecture according to an embodiment of the present application;

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

[0053] Figure 5 is a flowchart of another partition upgrade method of a vehicle service according to an embodiment of the present application;

[0054] Figure 6 is a flowchart of still another partition upgrade method of a vehicle service according to an embodiment of the present application;

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

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

[0057] In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the accompanying drawings. Obviously, the described embodiments are only some but not all of the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative efforts should fall into the scope of the present application.

[0058] According to the embodiments of the present application, a partition upgrade method and device for vehicle services, computer equipment and storage medium 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 the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0059] In the present embodiment, a partition upgrade method for vehicle services is provided, which is applied to an instrument end, Figure 1 is a flowchart of a partition upgrade method for vehicle services according to the embodiments of the present application, as shown in the figure, the flowchart includes the following steps: Figure 1

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

[0061] In the embodiments of the present application, when the automotive instrument system is running, if the vehicle-mounted application of the target vehicle has an upgrade requirement, it will send a request to the partition upgrade service, which contains the identifier of the service to be upgraded to specify which application needs to be upgraded, and also includes the current version number for comparison with the updated version number to determine whether and how to upgrade. For example, when the multimedia service discovers 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 the software version. The partition upgrade service determines whether to upgrade the service according to the above information.

[0062] It should be noted that, as Figure 2 ​As shown, the overall architecture of the present application mainly consists of three parts, i.e. the vehicle end, the cloud end and the instrument end. Through the cooperative work of the 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 end is responsible for connecting with the OTA remote upgrade system, downloading the related software upgrade package and other upgrade required service information, and establishing a communication connection with the instrument end through TCP. The vehicle end contains multiple vehicle-mounted applications, which receive upgrade service information through the communication link between the vehicle end and the instrument end. The instrument end includes an SOA gateway, which is responsible for establishing a communication connection with the cloud end and the vehicle end, and interacting with the partition upgrade service system, and is responsible for distributing and managing multiple service information.

[0063] Specifically, as shown in the figure, Figure 3 The figure is a schematic diagram of 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 centralized management of service information. The service provider (such as the service upgrade module of the vehicle-mounted application) registers the services (such as service information) provided by itself to the center, including service identification, current version number and other key information. The service requester (such as the instrument end or the cloud end) finds the required service through the service registration center, and judges whether it needs to be upgraded according to 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 to establish a first communication link between the instrument end and the cloud end.

[0066] Specifically, to realize the software upgrade of the digital instrument, the communication connection between the instrument end and the cloud end needs to be established first. A first communication interface is created to be responsible for data transmission between the instrument end and the cloud end, so as to establish a first communication link, so that the instrument end can communicate with the cloud server. The cloud end is a background server connected with the OTA remote upgrade, and is responsible for downloading the upgrade package. After establishing the link, the instrument end can obtain upgrade information and data from the cloud end, and prepares for the partition upgrade service.

[0067] Step A2, create a second communication interface to establish 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 with the cloud end, a second communication interface needs to be created to establish a communication link with the vehicle end. This interface is responsible for data transmission between the instrument end and the vehicle end, and after establishing the link, the instrument end can communicate with other systems of the vehicle end to obtain vehicle state information, etc., and can also provide partition upgrade service for the vehicle end, realize cooperative upgrade, reduce hardware dependence, and improve upgrade efficiency and stability.

[0069] Step A3, obtaining a plurality of service information from the cloud based on the first communication link, and obtaining a plurality of vehicle information from the vehicle end based on the second communication link.

[0070] Specifically, the service information including software upgrade package, upgrade instruction, service version information, etc. is obtained from the cloud (background server connected with OTA remote upgrade) through the first communication link for digital instrument upgrade. Meanwhile, the vehicle state information (such as engine state, battery power, vehicle speed, etc.), fault code and other vehicle information are obtained from the vehicle end (including whole vehicle head unit service and other parts with upgrade demand) through the second communication link. These information can help the instrument end to understand the vehicle running condition to make reasonable decision in upgrade, and also can provide reference for digital instrument upgrade to ensure its collaborative work with other systems of the vehicle.

[0071] Step A4, constructing corresponding configuration file according to the vehicle information, and initializing the partition upgrade service system under SOA architecture.

[0072] Specifically, as shown in Figure 4 the partition upgrade service system includes service discovery module, data acquisition module, control module, classification and screening storage module, flashing module, partition switching module and configuration file. In the initialization process of the partition upgrade service system, first, the data acquisition module will create UDS socket and perform service listening. At the same time, the service discovery module will create or configure one or more sockets, which are used for bidirectional communication with the cloud and other services or applications inside the vehicle end which need to be upgraded through network. Then, the instrument partition upgrade service is registered and service publishing is performed. In the instrument system, each service will also receive the service published by the service discovery module, and the information in the configuration file is saved in the local central processor, waiting for other services to use the service, then service subscription calling is performed. Thus, the initialization of the partition upgrade service is completed, which provides a stable and reliable service basis for the upgrade of the digital instrument.

[0073] Step A5, publishing the service information to each vehicle application in the vehicle end through the partition upgrade service system.

[0074] Specifically, the service discovery module in the partition upgrade service system will publish the service information including software upgrade package, upgrade instruction, service version information, etc. to the vehicle applications with upgrade demand such as engineering mode, OTA application, multimedia service, 4G module, etc. in the vehicle end. Thus, each vehicle application can know which upgrade service is available, so as to make service request when needed, and start the upgrade process. In this way, the effective propagation and application of the digital instrument upgrade service in the vehicle end is realized, which provides a basis for the partition upgrade of the digital instrument.

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

[0076] In this embodiment, upon receiving a service upgrade request from the target vehicle's in-vehicle application, the system queries the instrument cluster's partition upgrade service system based on the service identifier in the request. This system includes a service discovery module, which 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 match, it means the software version is the latest and does not require an upgrade, and the process ends; if they do not match, a new software version 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 this embodiment, if the current version number and the updated version number are inconsistent, an upgrade is required. In this case, the target service information is obtained by filtering service information based on the target vehicle's configuration file. Specifically, as follows... Figure 5 As shown, upon receiving a service upgrade request, the system immediately retrieves the current service version number and compares it with the version number to be updated. If the version numbers are the same, it determines that no upgrade is needed and the upgrade process is abandoned. If the version numbers are inconsistent, the process continues, retrieves the necessary upgrade configuration file, and checks whether the required module types exist. If the module type is missing or the integrity and validity of the configuration file fail verification, an error will be reported and the upgrade will terminate. Once all verifications are successful, the service upgrade package will be built, and the partition upgrade process will automatically begin. Finally, after the upgrade is complete, a reset and restart operation will be performed.

[0079] In this embodiment of the application, the service information is filtered 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: Iterate through the multiple configuration files stored in the instrument panel.

[0081] Specifically, during the partition upgrade process based on the automotive instrument cluster SOA architecture, multiple configuration files stored in the instrument cluster are traversed. The purpose is to determine which modules the current device supports for upgrades. If a module's configuration file does not exist, it means the current device does not need to upgrade that module, and an error will be reported and the upgrade will be abandoned. If the configuration file exists, the next step is to verify the completeness and validity of the upgrade package. By traversing the configuration files, the modules that need to be upgraded can be accurately identified, avoiding unnecessary upgrade operations and improving the efficiency and accuracy of the upgrade.

[0082] Step B2: Query the target configuration file that matches the target vehicle from multiple configuration files.

[0083] Specifically, the target configuration file matched with the target vehicle can be obtained by: 1. comparing the specific identification information of the target vehicle such as the vehicle model and the VIN code with the multiple configuration files; 2. screening and searching according to the key attributes of the hardware features and software version of the target vehicle; 3. calculating the matching degree of the key parameters of the configuration file and the parameters of the target vehicle by using a preset query algorithm, and determining the target configuration file when the matching degree reaches a certain threshold. In summary, the target configuration file is accurately found from the multiple configuration files by extracting the key information of the vehicle and comparing, screening and calculating the configuration file.

[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 characteristic identification), software version related parameters (current software version information including operating system and middleware version, software function module version such as audio processing, display driver version, etc.), vehicle model and configuration related parameters (vehicle model code, configuration level such as basic version and luxury version, etc.), and upgrade module support identification (support or not support identification for each upgrade module such as linux module, hypervisor, FPGA, audio, display, Hud (head-up display), secondary screen, and reserved type).

[0085] Step B3, determining the type of the module supported by the target vehicle for upgrading according to the target configuration file.

[0086] Specifically, the type of the upgrade module supported by the target vehicle is determined according to the target configuration file. The target configuration file contains key information such as vehicle hardware, software version, vehicle model and configuration related parameters, and upgrade module support identification, which can clearly determine the upgrade feasibility of the target vehicle in each module such as the linux module, make the upgrade more accurate, avoid wasting resources and time on modules that do not support, efficiently operate while ensuring compatibility with the actual status of the vehicle, and improve the stability and reliability of the system.

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

[0088] Specifically, after determining the type of the upgrade module supported by the target vehicle, the correlation between the requirements of each module and the service information is analyzed, and the service information is screened accordingly. For example, if the target vehicle supports linux module upgrade, the relevant service information such as upgrade tools and process guidance is selected from the numerous service information. In this way, only the service information related to the target module is obtained and used, irrelevant interference is avoided, the upgrade requirements of different modules are met, and the upgrade process is ensured to proceed smoothly.

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

[0090] Specifically, after determining the target service information corresponding to the module type supported by the target vehicle for upgrade, the specific service information is integrated, including the upgrade tools for different modules, the upgrade process guidance and the like, to construct a special service upgrade package. Then, the service upgrade package is used to perform a partition upgrade operation on the vehicle application in the target vehicle. Since the upgrade method is based on the SOA architecture, different modules or functional areas can be upgraded one by one in the upgrade process.

[0091] As an example, taking the hypervisor module supported by the target vehicle for upgrade as an example, the service upgrade package is used for upgrade, and the module partition operation is performed. In the upgrade, data is written to a non-current running partition. If the flashing is successful, the version information is stored, the start partition is switched, the bit area flag is updated, and the upgrade success state is fed back to wait for restart. If the flashing fails, it is determined whether the partition is complete. If the partition is complete, the failure is fed back and the current partition is started. If the partition is not complete, the data is copied to another partition, the failure is fed back, and the current partition is started. In this way, seamless upgrade can be realized, and the system can be rolled back to the old version software when the upgrade is wrong or fails, so as to ensure stability and reliability.

[0092] In the embodiment of the present application, the service upgrade package is used to perform a partition upgrade operation on the vehicle application in the target vehicle, including the following steps C1-C5:

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

[0094] Specifically, since the service upgrade includes software code update, configuration file adjustment content, upgrade tool description and process guidance and the like of a specific module (such as a linux, hypervisor module and the like), the format is a specific compression or custom data package format for storage and transmission. Therefore, after constructing the service upgrade package for the specific module of the target vehicle, it needs to be parsed, and the key data including software code update, configuration adjustment, new function module and the like is extracted by a specific algorithm or tool. The purpose is to convert the upgrade package information into data that can be actually used for upgrade operation, so as to accurately write the target partition upgrade.

[0095] Step C2, obtaining the bit area flag of the target vehicle.

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

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

[0098] Specifically, the first partition (A partition) currently running and the second partition (B partition) currently idle are determined according to the bit zone flag. The bit zone flag indicates the currently used partition, by which the first partition running software and the second partition idle can be distinguished. This distinction is important because during the upgrade, data is written to the non-currently running idle partition to avoid interference with the running software.

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

[0100] Specifically, after determining the first partition currently in a running state and the second partition currently in an idle state, the upgrade data obtained by parsing 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 writing, it is detected whether the upgrade data is successfully written to the second partition. After detection, a detection result is obtained, which includes a successful write or a failed write. The detection process can include: comparing the data size and quantity before and after writing and whether the checksum is consistent; performing a function test on a specific software module; checking whether the second partition version information is consistent with the expected; checking the error log and analyzing the log file to find successful prompt information.

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

[0102] In the embodiments of the present application, step C5 includes: if the detection result is a successful write, starting the second partition, performing a partition upgrade operation on the vehicle application in the target vehicle in the second partition, and updating the bit zone flag of the target vehicle and the working state of the second partition; if the detection result is a failed write, triggering a partition switching mechanism, and performing an upgrade operation on the 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 succeeds, that is, the upgrade data is successfully written into the second partition, at this time, the second partition is started, the vehicle-mounted application is upgraded by using the upgrade data in the second partition, and the target vehicle area mark 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, a partition switching mechanism is triggered, which ensures the normal running of the system and attempts to upgrade when the upgrade data flashing fails. Based on this mechanism, the upgrade operation on the vehicle-mounted application in the target vehicle is performed in the first partition.

[0104] In the embodiments of the present application, the upgrade operation on the vehicle-mounted application in the target vehicle is performed in the first partition based on the partition switching mechanism, including the following steps D1-D3:

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

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

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

[0108] Way one: file system check. Including traversing the partition file system to compare the expected directory structure, judging whether the second partition file directory structure is complete, if there is confusion, missing key directory or file path exception, the partition may be damaged. Or, checking file attributes (such as size, creation time, modification time, etc.), if the attributes are abnormal (such as size is zero, creation time is inconsistent, etc.), the file may be damaged. Or, randomly select some files, if reading errors occur such as unable to open, incomplete content or garbled code, etc., the partition may be damaged.

[0109] Way two: partition boot information check. Including 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 cannot be normally started. Or, checking the boot sector, by analyzing the boot sector content such as disk signature, partition table information, etc. to judge whether the sector is damaged, tampered or cannot be normally read.

[0110] Way three: bad track detection. Using a disk detection tool to detect bad tracks of the disk where the second partition is located, if there are bad tracks, it may affect the normal use of the partition, even cause data loss and partition damage, the bad track detection tool can scan the disk surface to mark the bad track position for processing. Or, checking the disk health status (including read / write speed, response time, error rate, etc.), if the indicators are abnormal, it indicates that the disk may be damaged.

[0111] Fourthly, partition startup test. Try to start the system or specific application from the second partition. If there is an error, crash or cannot normally enter the system, it may indicate that the second partition is damaged. Or, test specific software or functions stored in the second partition, such as storing audio files to play audio test sound, storing image files to view whether the image is normally displayed, and determine whether the partition is damaged.

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

[0113] Specifically, if the second partition is not damaged, the system can safely start in this partition to ensure that the upgrade process does not affect the currently running software version. When the system runs in the second partition, it can write new upgrade data to the first partition to prepare 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 system or application. This step ensures seamless switching and error rollback capability during the upgrade process, so that even if there is a problem during the upgrade process, the system can fall back to the previously stable running partition.

[0114] Step D3, if the second partition is damaged, write the original data stored in the second partition and the upgrade data to the first partition, and start the first partition to perform the upgrade operation on the vehicle application in the target vehicle in the first partition.

[0115] Specifically, since the second partition is damaged, it cannot be directly upgraded, so 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 new upgrade data and 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 vehicle application or software. This step ensures that even in the case of a damaged second partition, the system can safely perform the upgrade operation and maintain the integrity and consistency of the data.

[0116] As an example, as Figure 6As shown, taking the upgrade of an on-board application in a target vehicle as an example. The vehicle is provided with two partitions A and B. First, the current partition identifier is obtained, and it is determined whether the current partition is partition A. If it is not partition A, the upgrade data is written into partition A; if it is partition A, the upgrade data is written into partition B. Second, it is detected whether the data flashing is successful. If the flashing is successful, the flashing partition is started for upgrade, the version information is stored in the flashing partition, and the partition identifier and the working state are updated. If the flashing fails, it is further detected whether the flashing partition is complete. If the flashing partition is complete (i.e., not damaged), the current state is fed back; if the flashing partition is not complete (i.e., damaged), the upgrade data is written into the other partition, and the state is fed back.

[0117] In the embodiment of the present application, after performing the partition upgrade operation on the on-board application in the target vehicle by using the service upgrade package, the following steps are included: detecting whether an abnormal situation occurs in the current upgrade operation; stopping the current upgrade operation and triggering a data rollback mechanism when the abnormal situation occurs; and restoring the current service version of the on-board application in the target vehicle to a historical version before the upgrade by using the data rollback mechanism.

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

[0119] In the embodiment, a partition upgrade device for SOA service is also provided, which is used to implement the above-mentioned embodiments and preferred embodiments, and details are not repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware, or a combination of software and hardware is also possible and contemplated.

[0120] The embodiment provides a partition upgrade device for SOA service, which is applied to an instrument end, such as Figure 7 As shown, the device comprises:

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

[0122] The querying module 72 is configured to query service information and an updated version number of the service to be upgraded in the partition upgrade service system of the instrument end based on the service identifier, and compare the current version number with the updated version number.

[0123] The screening module 73 is configured to screen the service information according to the configuration file corresponding to the target vehicle if the current version number is inconsistent with the updated version number, to obtain target service information.

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

[0125] In an optional embodiment of the present application, the device further comprises a creation module configured to create a first communication interface to establish a first communication link between the instrument end and the cloud end, create a second communication interface to establish a second communication link between the instrument end and the vehicle end, obtain a plurality of service information from the cloud end based on the first communication link, obtain a plurality of vehicle information from the vehicle end based on the second communication link, construct a corresponding configuration file according to the vehicle information, initialize a partition upgrade service system under the SOA architecture, and publish the service information to each vehicle-mounted application of the vehicle end through the partition upgrade service system.

[0126] In an optional embodiment of the present application, the screening module 73 is configured to traverse a plurality of configuration files stored in the instrument end, query a target configuration file matched with the target vehicle from the plurality of configuration files, determine a module type supported by the target vehicle for upgrade according to the target configuration file, and screen the service information based on the module type to obtain target service information corresponding to the module type.

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

[0128] In an optional embodiment of the present application, the construction module 74 is configured to start the second partition if the detection result is that the writing is successful, perform a partition upgrade operation on the vehicle-mounted application in the target vehicle in the second partition, and update the bit area flag of the target vehicle and the working state of the second partition, or trigger a partition switching mechanism if the detection result is that the writing is unsuccessful, and perform an upgrade operation on the vehicle-mounted application in the target vehicle in the first partition based on the partition switching mechanism.

[0129] In an optional embodiment of the present application, the construction module 74 is configured to detect whether the second partition is damaged; if the second partition is not damaged, start the second partition, write the upgrade data to the first partition, and after the upgrade data is written successfully, start the first partition, and perform the upgrade operation on the vehicle application in the target vehicle in the first partition; or, if the second partition is damaged, write the original data stored in the second partition and the upgrade data to the first partition, and start the first partition, and perform the upgrade operation on the vehicle application in the target vehicle in the first partition.

[0130] In an optional embodiment of the present application, the device further comprises a recovery module configured to detect whether an abnormal situation occurs in the current upgrade operation; stop the current upgrade operation and trigger a data rollback mechanism when the abnormal situation occurs; and restore the current service version of the vehicle application in the target vehicle to a historical version before the upgrade by using the data rollback mechanism.

[0131] Please refer to Figure 8 , Figure 8 is a structural schematic diagram of a computer device provided by an optional embodiment of the present application, as shown in Figure 8 The computer device comprises one or more processors 10, a memory 20, and interfaces for connecting components, including high-speed interfaces and low-speed interfaces. The components are communicatively connected by using different buses, and can be installed on a common mainboard or in other manners as needed. The processor can process instructions executed in the computer device, including instructions stored in the memory or graphics information of a GUI stored in the memory to be displayed 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 part of the necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system).

[0132] The processor 10 can be a central processor, a network processor, or a combination thereof. The processor 10 can further comprise a hardware chip. The hardware chip can be an application-specific integrated circuit, a programmable logic device, or a combination thereof. The programmable logic device can be a complex programmable logic device, a field programmable logic gate array, a general array logic, or any combination thereof.

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

[0134] The memory 20 can include a program storage area and a data storage area. The program storage area can store an operating system and applications required by at least one function. The data storage area can store data created by the computer device according to the presentation of a small program landing page, and the like. In addition, the memory 20 can include a high-speed random access memory, and can also include a non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state memory device. In some optional embodiments, the memory 20 can optionally include a memory disposed remotely relative to the processor 10, and these remote memories can be connected to the computer device through a network. Examples of the network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.

[0135] The memory 20 can include a volatile memory, such as a random access memory, and can also include a non-volatile memory, such as a flash memory, a hard disk, or a solid-state disk. The memory 20 can also include a combination of the above-mentioned kinds of memories.

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

[0137] The embodiments of the present application also provide a computer readable storage medium. The above-mentioned method according to the embodiments of the present application can be implemented in hardware, firmware, or recorded in a storage medium, or stored in a remote storage medium or a non-transitory machine readable storage medium and stored in a local storage medium through network downloading of original computer code, so that the method described herein can be processed by such software on a storage medium using a general-purpose computer, a special-purpose processor, or programmable or special-purpose hardware. The storage medium can be a magnetic disk, an optical disk, a read-only memory, a random access memory, a flash memory, a hard disk, or a solid-state disk, and the like. Further, the storage medium can also include a combination of the above-mentioned kinds of memories. It can be understood that the computer, the processor, the microprocessor controller, or the programmable hardware includes a storage component that can store or receive software or computer code, and when the software or computer code is accessed and executed by the computer, the processor, or the hardware, the method shown in the above embodiments is implemented.

[0138] Although the embodiments of the present application are described in conjunction with the accompanying drawings, various modifications and changes can be made by those skilled in the art without departing from the spirit and scope of the present application, and such modifications and changes fall within the scope defined by the appended claims.

Claims

1. A partitioned upgrade method of an in-vehicle service, applied to an instrument end, characterized in that, The method comprises: receiving service upgrade requests from each vehicle-mounted application in a target vehicle, wherein the service upgrade request comprises a service identifier of a service to be upgraded and a current version number; querying service information and an updated version number of the service to be upgraded in a partition upgrade service system at the instrument end based on the service identifier, and comparing the current version number with the updated version number; if the current version number and the updated version number are inconsistent, screening the service information according to a configuration file corresponding to the target vehicle to obtain target service information; constructing a service upgrade package according to the target service information, and performing a partition upgrade operation on the vehicle-mounted application in the target vehicle by using the service upgrade package; the operation of performing a partition upgrade operation on the vehicle-mounted application in the target vehicle by using the service upgrade package comprises: parsing the service upgrade package to obtain upgrade data; obtaining a bit area mark of the target vehicle at present; determining a first partition in a running state and a second partition in an idle state according to the bit area mark; 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; performing a partition upgrade operation on the vehicle-mounted application in the target vehicle based on the detection result.

2. The method of claim 1, wherein, Before receiving the service upgrade requests from each vehicle-mounted application in the target vehicle, the method further comprises: creating a first communication interface to establish a first communication link between the instrument end and a cloud end; creating a second communication interface to establish a second communication link between the instrument end and a vehicle end; obtaining a plurality of service information from the cloud end based on the first communication link, and obtaining a plurality of vehicle information from the vehicle end based on the second communication link; constructing a corresponding configuration file according to the vehicle information, and initializing a partition upgrade service system under an SOA architecture; publishing the service information to each vehicle-mounted application at the vehicle end through the partition upgrade service system.

3. The method of claim 1, wherein, the operation of screening the service information according to the configuration file corresponding to the target vehicle to obtain target service information comprises: traversing a plurality of configuration files stored in the instrument end; querying a target configuration file matched with the target vehicle from the plurality of configuration files; determining a module type supported by the target vehicle according to the target configuration file; screening the service information based on the module type to obtain target service information corresponding to the module type.

4. The method of claim 1, wherein, the operation of performing an upgrade operation on the vehicle-mounted application in the target vehicle based on the detection result comprises: if the detection result is a successful writing, starting the second partition, performing a partition upgrade operation on the vehicle-mounted application in the target vehicle in the second partition, and updating a bit area mark of the target vehicle and a working state of the second partition; or, if the detection result is a failed writing, triggering a partition switching mechanism, and performing an upgrade operation on the vehicle-mounted application in the target vehicle in the first partition based on the partition switching mechanism.

5. The method of claim 4, wherein, the operation of performing an upgrade operation on the vehicle-mounted application in the target vehicle in the first partition based on the partition switching mechanism comprises: detecting whether the second partition is damaged; if the second partition is not damaged, starting the second partition, writing the upgrade data into the first partition, and after the upgrade data is written successfully, starting the first partition and performing an upgrade operation on the in-vehicle application in the target vehicle in the first partition; or, if the second partition is damaged, writing the original data stored in the second partition and the upgrade data into the first partition, and starting the first partition to perform an upgrade operation on the in-vehicle application in the target vehicle in the first partition.

6. The method of claim 1, wherein, After performing the partition upgrade operation on the in-vehicle application in the target vehicle using the service upgrade package, the method comprises: detecting whether an abnormal situation occurs in the current upgrade operation; stopping the current upgrade operation and triggering a data rollback mechanism when the abnormal situation occurs; restoring the current service version of the in-vehicle application in the target vehicle to a historical version before the upgrade using the data rollback mechanism.

7. An apparatus for partitioned upgrade of SOA services, characterized by The device is applied to an instrument terminal and comprises: a receiving module configured to receive a service upgrade request from each in-vehicle application in a target vehicle, wherein the service upgrade request comprises a service identifier and a current version number of a service to be upgraded; a querying module configured to query service information and an updated version number of the service to be upgraded based on the service identifier in a partition upgrade service system of the instrument terminal, and compare the current version number with the updated 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 constructing module configured to construct a service upgrade package according to the target service information and perform a partition upgrade operation on the in-vehicle application in the target vehicle using the service upgrade package; and the constructing module is configured to analyze the service upgrade package to obtain upgrade data, obtain a bit area flag of the target vehicle, determine a first partition in a running state and a second partition in an idle state according to the bit area flag, write the upgrade data into the second partition, and detect whether the upgrade data is successfully written into the second partition to obtain a detection result, and perform a partition upgrade operation on the in-vehicle application in the target vehicle based on the detection result.

8. A computer device, comprising: The method comprises: a memory and a processor, which are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the method of any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer instructions for causing a computer to perform the method of any one of claims 1 to 6.

Images