Vehicle software verification method and device, electronic equipment and storage medium
By obtaining vehicle identification information and pre-defined mapping relationships to determine the target software version number, verifying and updating non-compliant software versions, the problem of inconsistent software versions in the vehicle electronic inspection system is solved, thereby improving vehicle safety and management efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- TIANJIN FAW TOYOTA MOTOR CO LTD
- Filing Date
- 2025-12-31
- Publication Date
- 2026-04-17
AI Technical Summary
Existing vehicle electronic inspection systems cannot ensure that the software versions of all electronic control units in a vehicle are up-to-date, leading to defective vehicles entering the market and potentially causing safety accidents.
By acquiring vehicle identification information, determining the target software version number using a preset mapping relationship, and verifying the vehicle's software version information, the system prompts users to update any substandard software, thus achieving precise update management.
This improves vehicle safety, prevents accidents caused by substandard vehicles entering the market, and ensures accurate updates and management of vehicle software versions.
Smart Images
Figure CN121879829A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of vehicle management technology, and in particular to a vehicle software verification method, device, electronic device, and storage medium. Background Technology
[0002] When performing electronic control unit (ECU) checks on existing vehicles, the Vehicle Electronic Inspection System (TVECS) connects to the vehicle via Bluetooth antenna and can only read and store the version information of all the Electronic Control Units (ECUs) actually installed in the vehicle. This means that some software in the vehicle inspected by the TVECS may not be the latest version. Furthermore, because the TVECS cannot communicate with defective vehicles, these vehicles are unaware of the outdated software, potentially allowing them to enter the market and increasing the risk of safety incidents. Summary of the Invention
[0003] The purpose of this application is to provide a vehicle software verification method, device, electronic device, and storage medium, which aims to accurately verify the software version of the electronic control unit in the vehicle and determine whether to generate vehicle qualification information based on the verification results, thereby improving the safety of vehicle use.
[0004] Firstly, a vehicle software verification method is provided, applied to a software version management system. The method includes: obtaining the identification information of the target vehicle; determining the target software version number corresponding to the target software in the target vehicle based on the identification information; wherein the target software version number is the software version number after the target software is updated; verifying the currently installed software version information of the target software using the software version information corresponding to the target software version number, and obtaining a verification result; if the verification result is that the verification fails, prompting the user to update the target software.
[0005] This application provides a vehicle software verification method that can pre-store the software version numbers corresponding to the software in the vehicle that need to be updated, verify the version information of the software in the vehicle using the software version numbers, and update the software in the vehicle when it is not updated, thereby achieving precise update management of vehicle software. Based on the update management, it can intercept defective vehicles that have not been updated, avoid safety accidents caused by defective vehicles entering the market, and improve the safety of vehicle use.
[0006] Optionally, based on the identification information, the target software version number corresponding to the target software in the target vehicle is determined, including: determining the target software version number based on the identification information and a preset mapping relationship; wherein, the preset mapping relationship is used to characterize the correspondence between the vehicle's identification information and the target software version number corresponding to the software in the vehicle.
[0007] Optionally, the software version information corresponding to the target software version number is used to verify the currently installed software version information of the target software. Before obtaining the verification result, the method further includes: obtaining the currently installed software version information from the target shared space; wherein, the currently installed software version information is updated to the target shared space by the vehicle electronic inspection system after the target software in the target vehicle is updated.
[0008] Optionally, the software version information corresponding to the target software version number is used to verify the currently installed software version information of the target software to obtain a verification result, including: if the software version information corresponding to the target software version number does not exist, or if the software version information corresponding to the target software version number is inconsistent with the currently installed software version information, the verification result is determined to be verification failed.
[0009] Optionally, the method also includes: after the target software update is completed, using the software version information corresponding to the target software version number to verify the updated software version information of the target software and obtain the verification result; if the verification result is that the verification fails, prompting the user to update the target software again.
[0010] Optionally, the identification information includes at least one of the following: the target vehicle's identification code, and the target vehicle's configuration information.
[0011] Optionally, the target software is each piece of software configured in the target vehicle; the method further includes: if the verification result of the target software is that the verification is passed, prompting the target vehicle that the update is complete.
[0012] Optionally, the method further includes: generating a software update statistics chart for the target vehicle; wherein the software update statistics chart includes the number of updates, update time, update reason, and update reason category of the target software within a preset time range; and generating a statistics chart for the vehicle to be updated.
[0013] Secondly, this application also provides a vehicle software verification device applied to a software version management system. The device includes: a data acquisition module, a determination module, a verification module, and a prompting module. The data acquisition module is used to acquire the identification information of the target vehicle; the determination module is used to determine the target software version number corresponding to the target software in the target vehicle based on the identification information; wherein the target software version number is the software version number after the target software is updated; the verification module is used to verify the currently installed software version information of the target software using the software version information corresponding to the target software version number, and obtain a verification result; the prompting module is used to prompt for an update of the target software if the verification result is a failure.
[0014] Thirdly, this application provides a vehicle, which includes a software version management system; the software version management system is equipped with a vehicle software verification device as described in the second aspect above.
[0015] Fourthly, this application provides an electronic device comprising: a processor and a memory; the memory storing processor-executable instructions; when the processor is configured to execute the instructions, causing the electronic device to implement the method of the first aspect described above.
[0016] Fifthly, this application provides a computer-readable storage medium comprising: computer software instructions; which, when executed in an electronic device, cause the electronic device to implement the method described in the first aspect.
[0017] Sixthly, this application provides a computer program product that, when run on a computer, causes the computer to perform the functions of the related system described in the first aspect, so as to implement the method of the first aspect.
[0018] The beneficial effects of the second to sixth aspects mentioned above can be referred to the corresponding descriptions in the first aspect, and will not be repeated here. Attached Figure Description
[0019] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0020] Figure 1 A flowchart illustrating a vehicle software verification method provided in an embodiment of this application; Figure 2 A schematic diagram of ECU information for a car provided in an embodiment of this application; Figure 3 A schematic diagram of a page for pre-maintaining data in a software version management system provided in this application embodiment; Figure 4 This application provides an embodiment of a software version management system that pre-maintains a page for obtaining the current software version; Figure 5 A schematic diagram of a system page for reading data using TVECS is provided as an embodiment of this application; Figure 6 A schematic diagram of the inspection results of an ECU provided in an embodiment of this application; Figure 7 This is a schematic diagram of an undesirable result of a vehicle inspection provided in an embodiment of this application; Figure 8 A data statistics illustration provided for an embodiment of this application Figure 1 ; Figure 9 A data statistics illustration provided for an embodiment of this application Figure 2 ; Figure 10 This is a schematic diagram illustrating the composition of a vehicle software verification device provided in an embodiment of this application; Figure 11 This is a schematic diagram of the structure of a vehicle software verification device provided in an embodiment of this application. Detailed Implementation
[0021] In the embodiments of this application, the terms "first," "second," "third," "fourth," "fifth," and "sixth" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," "third," "fourth," "fifth," and "sixth" may explicitly or implicitly include one or more of that feature.
[0022] In embodiments of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.
[0023] "A and / or B" includes the following three combinations: A only, B only, and a combination of A and B.
[0024] In the embodiments of this application, "parallel," "perpendicular," and "equal" include the described situation and situations similar to the described situation, where the range of similarity is within an acceptable deviation range, wherein the acceptable deviation range is determined by those skilled in the art taking into account the measurement under discussion and the error associated with the measurement of a particular quantity (i.e., the limitations of the measurement system). For example, "parallel" includes absolute parallelism and approximate parallelism, wherein the acceptable deviation range for approximate parallelism may be, for example, a deviation within 5°; "perpendicular" includes absolute perpendicularity and approximate perpendicularity, wherein the acceptable deviation range for approximate perpendicularity may also be, for example, a deviation within 5°. "Equal" includes absolute equality and approximate equality, wherein the acceptable deviation range for approximate equality may be, for example, a difference between the two equals being less than or equal to 5% of either one.
[0025] As described in the background section, when performing electronic control unit (ECU) checks on existing vehicles, the Vehicle Electronic Inspection System (TVECS) connects to the vehicle via Bluetooth antenna and can only read and store the version information of all the Electronic Control Units (ECUs) actually installed in the vehicle. This means that some software in the vehicle inspected by the TVECS may not be the latest version. Furthermore, because the TVECS cannot communicate with defective vehicles, these vehicles are unaware that their installed software is outdated, potentially leading to these defective vehicles entering the market and increasing the risk of safety incidents.
[0026] If automakers fail to manage the software versions of their vehicle's ECUs, it can lead to fatal problems across multiple dimensions, including safety, compliance, and after-sales service, directly threatening user safety and causing operational crises. For example: 1. Safety risks erupt. Incompatible software versions or unpatched vulnerabilities in the three-electric system (new energy vehicles) or powertrain (gasoline vehicles) can cause serious safety incidents such as battery overcharging and fire, motor malfunction, and unexpected engine stalling. Inconsistent software versions of different modules (such as the Battery Management System (BMS) and VCU, and the Transmission Control Unit (TCU) and ECU) can lead to signal transmission errors, causing fatal malfunctions such as brake failure and abnormal steering. Without version traceability, it's impossible to pinpoint the software root cause of safety incidents, making it difficult to subsequently investigate and prevent similar problems. 2. Uncontrolled and unreliable vehicle performance. The same vehicle model may be equipped with different batches and states of ECU software, resulting in significant differences in vehicle power output, energy consumption, range, and other performance aspects, leading to inconsistent user experiences. Performance defects in older software versions (such as shift jerking and inaccurate range claims) cannot be fixed through upgrades, leading to a continuous decline in vehicle performance throughout its lifecycle. Furthermore, the inability to release versions adapted for extreme road conditions and climates makes vehicles prone to malfunctions in high-temperature, low-temperature, and high-altitude environments, significantly reducing reliability. The inconsistent software versions also prevent some vehicles from meeting environmental emission and safety standards, lacking a version change record and traceability system. Finally, the inability to implement over-the-air (OTA) remote upgrades means vehicle malfunctions can only be addressed through offline repairs, which often fail to match the correct software version, worsening the problem. This results in extremely low service efficiency and high costs.
[0027] Based on this, this application provides a vehicle software verification method that can pre-store the software version number corresponding to the software in the vehicle that needs to be updated, verify the version information of the software in the vehicle using the software version number, and update the software in the vehicle when it is not updated, thereby achieving precise update management of vehicle software. Based on the update management, it can intercept defective vehicles that have not been updated, avoid safety accidents caused by defective vehicles entering the market, and improve the safety of vehicle use.
[0028] The vehicle software verification method provided in this application can be applied to a software version management system (hereinafter referred to as the system). It can be applied not only in the vehicle software verification scenario of the vehicle system, but also in the vehicle software verification scenario of other mobile vehicles. This application does not limit the scale and type of specific application scenarios.
[0029] The following describes in detail a vehicle software verification method provided by this application, with reference to specific embodiments and accompanying drawings.
[0030] Figure 1 This is a flowchart illustrating a vehicle software verification method provided in an embodiment of this application. Specifically, as shown... Figure 1 As shown, it includes the following: S101. Obtain the identification information of the target vehicle.
[0031] In some embodiments, the identification information includes at least one of the following: the target vehicle's identification code, and the target vehicle's configuration information.
[0032] In one implementation, after the target vehicle arrives at the inspection station, the software version management system at the inspection station scans the vehicle information of the target vehicle through the traceability system equipped at the traceability scanning station to obtain the target vehicle's identification information. For example, the software version management system scans the QR code on the information sheet of the target vehicle to obtain the target vehicle's configuration information. Alternatively, the software version management system scans the vehicle body or identification code to obtain the target vehicle's identification code. The identification code can be, for example, a QR code, barcode, or other different types of identification codes.
[0033] In this way, vehicle configuration information (SFX) can be automatically obtained with a single scan, without any additional work.
[0034] In one implementation, the identification information of the target vehicle is used, such as the Vehicle Identification Number (VIN), which is a unique identification number for the vehicle.
[0035] S102. Based on the identification information, determine the target software version number corresponding to the target software in the target vehicle.
[0036] Among them, the target software version number is the software version number after the target software is updated, which is also the baseline information used to verify the version of the target software in the target vehicle.
[0037] In some embodiments, the target software version number is determined based on the identification information and the preset mapping relationship; wherein, the preset mapping relationship is used to characterize the correspondence between the vehicle's identification information and the target software version number corresponding to the software in the vehicle.
[0038] In one implementation, the target software version number can be a specific number or it can be empty. If the target software version number is empty, it indicates that the administrator has not maintained the target software version number in the software version management system beforehand.
[0039] Optionally, the software configured on the vehicle can be software installed in different units, modules, or other areas. In this embodiment, the software version of the electronic control unit is used for illustration.
[0040] Optionally, the ECU can use data acquisition and exchange from various sensors to determine the vehicle's status and the driver's intentions, and then control the car through actuators. For example, the ECU acquires digital and analog signals collected by sensors to determine the vehicle's status and the driver's intentions, and then controls the car to perform operations such as driving, braking, and air conditioning charging / discharging through actuators.
[0041] Optionally, the ECU is responsible for receiving and processing sensor signals and controlling actuators. Essentially an embedded computer, it consists of a microprocessor, memory, and input / output interfaces. It centrally manages the vehicle's core systems; different models may have multiple ECUs, each responsible for different modules such as powertrain, chassis, and body (e.g., engine ECU, battery management ECU). Specifically, it collects sensor data, such as engine speed, intake air volume, coolant temperature, wheel speed, and accelerator pedal position. It calculates the optimal control scheme according to a preset program and outputs commands to the actuators, such as controlling fuel injection quantity, ignition timing, and braking force. It monitors the system status in real time, stores fault codes when faults are identified, and illuminates the dashboard malfunction indicator light to alert the user. ECU software is iterable; upgrading the software version can optimize performance and fix vulnerabilities (some support OTA remote upgrades). ECUs are strongly matched to hardware; ECUs from different models and configurations cannot be arbitrarily interchanged or flashed with incompatible programs. The software version of a car ECU is the version number of the program running inside the ECU (engine control unit), used to identify the program's update and iteration status.
[0042] Optionally, ECU coding formats are not standardized, commonly consisting of letters and numbers (e.g., V2.1, 03H906021AK), and different car manufacturers have different coding rules. ECUs are associated with vehicle control functions such as powertrain adjustment, emission control, and fault diagnosis. When errors occur in these functions, updating to a newer version can fix the vulnerabilities. ECUs are matched to specific hardware models; different software versions cannot be arbitrarily flashed across different models or vehicle types. By connecting a professional diagnostic tool to the vehicle's On-Board Diagnostics (OBD) interface, the ECU's version information can be directly read.
[0043] In one implementation, the current software version number is marked on the owner's manual, engine compartment nameplate, or ECU housing of some vehicle models. Alternatively, staff can obtain the current software version number by querying it through the manufacturer's proprietary system.
[0044] Understandably, ECU software version management for new energy vehicles is a core element in ensuring vehicle safety, performance, and user experience, directly impacting the stable operation and lifecycle value of the three-electric system (battery, motor, and electronic control system). For example: 1. Ensuring the safe operation of the three-electric system. New energy vehicles rely on ECUs to control battery management, motor drive, and the electronic control system. Version inconsistencies can lead to safety hazards such as abnormal voltage control and thermal management failures. Timely version updates can fix issues like battery overcharge / over-discharge protection vulnerabilities and motor torque control deviations, reducing the risk of fire and loss of control. Unified version management avoids incompatibility between different modules (such as BMS and Vehicle Control Unit (VCU)) software, preventing malfunctions caused by system misjudgments. 2. Maintaining stable core performance. Battery energy management strategies (such as charging speed and range calculation accuracy) need to be optimized through version iterations to avoid older versions exhibiting false range claims or decreased charging efficiency. The motor control software version directly affects the smoothness of power output and the accuracy of energy consumption control; improper management can lead to power reduction and increased energy consumption. Version updates adapted to different climates and road conditions (such as low-temperature range optimization) need to be precisely pushed through standardized management to ensure performance in different scenarios. 3. Version management for new energy vehicles must record software change trajectories to ensure traceability. Control logic is adjusted through version iterations, while version archives are retained. 4. Support for OTA upgrades and full lifecycle services. Standardized version management is the foundation of OTA (Over-The-Air) updates, accurately identifying the vehicle's current version and pushing matching upgrade packages to avoid cross-version upgrade failures. This allows manufacturers to track vehicle software status, target common issues for version optimization, and improve after-sales service efficiency.
[0045] Optionally, since there are multiple target software programs on a vehicle, and different models of vehicles are equipped with different target software programs, after identifying the target vehicle, it is necessary to determine the target software version number corresponding to the vehicle model maintained in the software management system based on the vehicle's identification information.
[0046] Optionally, administrators can pre-maintain a preset mapping relationship between each vehicle and its corresponding target software and version number in the software version management system. Based on the target vehicle's identification information, all target software and their version numbers for that vehicle can be obtained.
[0047] For example, such as Figure 2 As shown, Figure 2 This is a schematic diagram of ECU information for a car provided in an embodiment of this application. The car has four configuration types, as shown in the bar chart from low to high: low-end, mid-range, high-end, and top-end. These four configuration types are further subdivided. For example, the low-end configuration can be subdivided into configuration 1, configuration 2, and configuration 3; the mid-range configuration can be subdivided into configuration 4, configuration 5, configuration 6, and configuration 7; the high-end configuration can be subdivided into configuration 8 and configuration 9; and the top-end configuration can be subdivided into configuration 10 and configuration 11. That is... Figure 2 Each bar chart represents a configuration, and each bar chart contains the name of the target software that the vehicle needs to be equipped with (such as the name of the ECU) and the corresponding target software version number (not shown in the figure).
[0048] Optionally, since different configurations of a car model may be equipped with different target software (such as different ECUs), it is necessary to first determine the number of ECUs and the specific names of the ECUs installed in the target vehicle.
[0049] For example, a page in a software version management system that pre-maintains data such as Figure 3 As shown, the vehicle type refers to the car model, SFX is the code information (i.e., identification information) for one of the car's configurations, and the abbreviation of the component name is the ECU name. A preset mapping relationship is established between the vehicle type, configuration code information, component name abbreviation, and target software version number, so that other information can be determined based on any one or more of these items according to the preset mapping relationship. For example, Figure 3 As shown, the page also includes information such as item code, creator, creation time, updater, and update time.
[0050] In this way, a multi-dimensional correlation database was established to ensure that there are no mismatches or omissions in each ECU version for each vehicle, and to achieve accurate comparison of all ECUs for a single vehicle one by one.
[0051] In some embodiments, since different vehicles are in different states—for example, a vehicle may be in a test verification state, a regular verification state, etc.—the corresponding target software version number selected for verifying the target software in the vehicle will also be different for vehicles in different states. Therefore, by maintaining the unique identification information of the vehicle in the software version management system, the target software version number corresponding to different identification information can be indicated.
[0052] In one implementation, a new car model needs to undergo trial production preparation before its market launch. This preparation phase involves the initial uploading of the target software version number to the software version management system for that model. During the trial production phase, since the trial-produced vehicles may be on the same verification production line as existing mass-produced vehicles, and since new trial-produced models typically arrive at the verification station consecutively, it is only necessary to determine which vehicle marks the beginning of the new model. Starting with that vehicle, the target software version number corresponding to the new model's identification information can be used to verify a predetermined number of subsequent vehicles.
[0053] Optionally, before vehicle verification, the identification information of the first vehicle of the new model in the trial production stage is obtained. This determines that the vehicle requires verification using the latest software version number. Therefore, a preset mapping relationship is established in the software version management system between the identification information of the first vehicle of the new model and the latest target software version number. On the scanning verification production line, after the software version management system scans the identification information of the current target vehicle, such as the VIN number, it determines that this identification information belongs to the first vehicle of the new model in the trial production stage. Based on this identification information, the target software version number with the preset mapping relationship in the software version management system is determined. It can then be determined that from this vehicle onwards, the target software version number of a preset number of subsequent vehicles after the target software update will all be this target software version number. The preset number refers to the number of new models in this trial production stage.
[0054] In one implementation, after vehicle mass production, ECU software undergoes frequent upgrades. When a particular ECU software version needs to be changed, to avoid disrupting continuous production, a small-batch verification can be performed on a few vehicles. Once the verification is successful, the software can be phased out in bulk. For example, three vehicles from the same batch can be selected for small-batch verification. Specifically, in the software version management system, a preset mapping relationship is established between the identification information of the three vehicles selected for small-batch verification and the latest target software version number of the ECU software that needs updating. During the vehicle verification process, after obtaining the identification information of the three vehicles undergoing small-batch verification, the software version management system directly determines the latest target software version number based on the preset mapping relationship.
[0055] In one possible implementation, after all vehicles in a small batch of verification have passed, a batch replacement of the vehicles to be verified is required. Since there are a certain number of workstations between the ECU assembly station and the final verification station, a clear replacement breakpoint needs to be defined. Vehicles before the replacement breakpoint continue to be verified using the old target software version number. The identification information of the first vehicle to be replaced with the new version serves as the dividing point; all vehicles after this point are verified using the new target software version number. The identification information of the first vehicle to be replaced with the new version is a crucial parameter managed by the software version management system when performing ECU software version changes. In the software version management system, a preset mapping relationship is established between the identification information of the vehicle identified as the replacement breakpoint and the latest target software version number of the ECU software to be updated. During vehicle verification, after obtaining the identification information of the vehicle at the replacement breakpoint, the software version management system directly determines the latest target software version number based on the preset mapping relationship. Furthermore, all vehicles after the vehicle at the replacement breakpoint are verified using this latest target software version number.
[0056] In one possible implementation, the software version management system establishes a preset mapping relationship between the vehicle's identification information before the aforementioned cutoff point and the historical target software version number of the ECU software that needs to be updated. During vehicle verification, after obtaining the vehicle's identification information before the aforementioned cutoff point, the software version management system determines the historical target software version number according to the preset mapping relationship. The historical target software version number is set by the inspector and can be any historical version number other than the latest target software version number.
[0057] In this way, the version switch point is clearly identified by the identification information of the target vehicle, so that the vehicle before the breakpoint corresponds to the historical target software version number, and the vehicle after the breakpoint corresponds to the new version of the target software version number. By deeply binding ECU version management with the entire vehicle production process (trial production-verification-mass production), the industry problem of disordered version switch control in multiple scenarios is solved, and dynamic and accurate matching of "scenario-version-vehicle" is achieved.
[0058] S103. Using the software version information corresponding to the target software version number, verify the currently installed software version information of the target software and obtain the verification result.
[0059] In some embodiments, the software version information corresponding to the target software version number is used to verify the currently installed software version information of the target software. Before obtaining the verification result, the currently installed software version information is obtained from the target shared space. The currently installed software version information is updated to the target shared space by the vehicle electronic inspection system after the target software in the target vehicle is updated.
[0060] Optionally, due to confidentiality restrictions, the existing TVECS system used to obtain the current installed software version information of the software configured on the target vehicle does not allow direct access from the software version management system. Data in the TVECS system cannot be directly retrieved and used; indirect data access is required through plugins.
[0061] For example, a page for retrieving the current software version is pre-maintained in the software version management system, such as... Figure 4 As shown, the abbreviation for the component name is the ECU name; WorkPartsId is a software version read command from the software version management system to the TVECS system, such as 506373, which is an instruction to read the target ECU information of the target vehicle; CanId is the Internet Protocol (IP) address pointing to the network interconnection protocol of the ECU to be acquired on the vehicle, such as 0722; RECEIVE_CanId is a return address used to send the software version of the ECU read from the vehicle back to the corresponding location in the shared space indicated by TVECS. The address needs to be converted from hexadecimal to decimal before verification. Automatic hexadecimal conversion is achieved by setting the WorkPart, CanId, and Receive_Did fields. According to the information maintained on this page, the shared disk can be accessed through the software version management system, indirectly accessing the data collected by TVECS in real time.
[0062] Optionally, TVECS stores the collected data in a shared space based on the Receive_Did field. The data in the shared space is updated every second according to the vehicle's verification status.
[0063] For example, such as Figure 5 As shown, TVECS, as a system for reading data, can read the current software version of the ECU. If the information is read successfully, it displays "OK"; if reading is in progress, it displays "In Operation"; if reading has not been performed, it displays "Not Operation". This system can be deployed to perform corresponding checks on the brakes.
[0064] In some embodiments, if the software version information corresponding to the target software version number does not exist, or if the software version information corresponding to the target software version number is inconsistent with the currently installed software version information, the verification result is determined to be verification failure.
[0065] Understandably, when verifying the software version of the target vehicle's ECU, the data pre-maintained in the software version management system is standard software version information expected to be installed on the target vehicle, while the data read by TVECS is the currently installed software version information of the target vehicle. If these two sets of version information are the same, it indicates that the software version of the ECU installed on the target vehicle is already the latest version and does not require updating; the verification result is "verification passed." If these two sets of version information are different, it indicates that the software version of the ECU installed on the target vehicle is not the latest version and needs to be updated; the verification result is "verification failed."
[0066] In one possible implementation, there are cases in the software version management system where the target software version number corresponding to some ECUs is empty. In this case, the target software version number does not exist, and the software version information corresponding to the target software version number cannot be used to verify the currently installed software version information of the target software. Therefore, the verification result is determined to be that the verification failed.
[0067] Optionally, the target software refers to each of the software programs configured for the target vehicle. In some embodiments, if the verification result of the target software is successful, a message indicating that the target vehicle update is complete is displayed.
[0068] For example, such as Figure 6 As shown, this interface displays the vehicle's VIN information, SFX configuration information, and inspection results for various ECUs. An OK result indicates successful inspection, while an NG (no good, NG) result indicates failed inspection. When an NG result appears on the display, the operator records the issue and registers it in the inspection information system.
[0069] In some embodiments, the target vehicle update is completed by generating qualified information for the target vehicle, or by displaying an OK verification result on the interface.
[0070] S104. If the verification result is that the verification failed, prompt the user to update the target software.
[0071] In some embodiments, after the target software update is completed, the updated software version information of the target software is verified using the software version information corresponding to the target software version number, and a verification result is obtained; if the verification result is that the verification fails, the target software is prompted to be updated again.
[0072] Optionally, if the verification result is that the verification fails, the certificate of conformity information cannot be printed if the target software that failed the verification is not updated.
[0073] For example, such as Figure 7 As shown, when the verification result is "failed," an "NG" (Not Acceptable) entry for vehicle lane crossing information appears in the system. The NG error messages can be categorized as follows: for example, the software version standard may not be maintained, or the software version may be inconsistent. Specific reasons for this error include: incorrect software version labeling, incorrect software version of components used on the vehicle, and the system failing to obtain version information from the TVECS.
[0074] This ensures that vehicles failing the verification cannot be issued a certificate of conformity, forcibly preventing substandard vehicles from entering the market and improving vehicle quality and safety.
[0075] In one implementation, after obtaining the cause of the problem, the software version information corresponding to the target software version number is obtained to get the updated target vehicle. Then, the software configured on the updated target vehicle is verified again. If the verification result of the second verification is successful (displaying OK), the problem task is closed and the verification ends.
[0076] It should be noted that when re-verifying the updated target vehicle, the software versions of all target software on the updated target vehicle need to be verified. However, the software maintained in the software version management system may not include all target software on the vehicle; that is, the number of software versions maintained in the software version management system may be less than or equal to the total number of target software on the vehicle.
[0077] In some embodiments, a software update statistics chart of the target vehicle is generated; wherein the software update statistics chart includes the number of updates, update time, update reason and update reason category of the target software within a preset time range; and a statistics chart of the vehicle to be updated is generated.
[0078] In some embodiments, a component quantity statistics chart corresponding to the target vehicle is generated based on the number of software configured on the target vehicle; a cumulative statistics chart of software change times and a software change time trend chart corresponding to the target vehicle are generated based on the number of times standard data is updated within a first preset time range.
[0079] For example, such as Figure 8 As shown, a component quantity statistics chart is generated based on the number of software programs in the target vehicle, displaying the component quantity information for the current vehicle model. A cumulative software change count statistics chart is generated based on the number of updates to the target software within a preset time range, allowing for the statistical analysis of vehicle model task counts by date range. A software change count time-lapse chart is generated based on the number of updates and update times of the target software within a preset time range, allowing for the statistical analysis of monthly task counts for each vehicle model by year.
[0080] In some embodiments, an update task reason statistics chart is generated based on the update reasons corresponding to the software configured on the target vehicles within a second preset time range; an update vehicle reason classification statistics chart is generated based on the update reasons of the software configured on each type of target vehicle within a third preset time range; and a vehicle to be updated statistics chart is generated based on the number of target vehicles that have not yet been updated.
[0081] For example, such as Figure 8 The chart showing the status of ongoing tasks displays the current vehicle type and the number of tasks in progress. Clicking the corresponding number for the "NG (Not Yet Parsed)" indicator allows you to view the vehicle's crossing status. Clicking the corresponding number for the "VINNO (Vehicle Identification Number)" indicator allows you to access the vehicle switching settings.
[0082] For example, such as Figure 9 As shown, based on the date and vehicle type within a preset time range, the update reason statistics chart for associated tasks is generated by counting the corresponding number of vehicles and generating an update task reason statistics chart. Based on the date and vehicle type within the preset time range, the update reason categories for vehicle NG (Not Returning) reasons are counted, and the corresponding numbers are generated. A pending update vehicle statistics chart is generated to display the number of unprocessed NG vehicles of the current time type.
[0083] In this way, multi-dimensional statistical dashboards are generated, enabling real-time data visualization and supporting filtering and analysis by date, vehicle model, SFX configuration, and other dimensions. This builds a full-process data statistics system, providing accurate decision-making basis for vehicle quality optimization.
[0084] This application embodiment can verify the current software version of the software installed on the vehicle. If the verification fails, it identifies defective parts and prevents the generation of qualified information, thus effectively intercepting defective parts and preventing accidents caused by defective vehicles entering the market. Using software to verify vehicles saves manpower and reduces verification costs. For frequent software changes, targeted standard input and checks can be performed on the current software version of each software installed on each vehicle model. This ensures comprehensive management across different modes, including trial production, small-batch verification, and batch verification. By generating various statistical charts through data statistics, the system can visually display various data acquired, ensuring accurate vehicle quality management based on data.
[0085] In an exemplary embodiment, Figure 10 This is a schematic diagram illustrating the composition of a vehicle software verification device provided in an embodiment of this application. The vehicle software verification device can be applied to a software version management system. Figure 10As shown, the vehicle software verification device includes: a data acquisition module 1001, a determination module 1002, a verification module 1003, and a prompting module 1004. The data acquisition module 1001 is used to acquire the identification information of the target vehicle; the determination module 1002 is used to determine the target software version number corresponding to the target software in the target vehicle based on the identification information; wherein the target software version number is the software version number after the target software is updated; the verification module 1003 is used to verify the currently installed software version information of the target software using the software version information corresponding to the target software version number, and obtain a verification result; the prompting module 1004 is used to prompt the user to update the target software if the verification result is a failure.
[0086] In an exemplary embodiment, this application also provides an electronic device, which may be the vehicle software verification device in the above method embodiments. Figure 11 This is a schematic diagram of a vehicle software verification device provided in an embodiment of this application. Figure 11 As shown, the vehicle software verification device may include: a processor 1101 and a memory 1102; the memory 1102 stores instructions executable by the processor 1101; when the processor 1101 is configured to execute instructions, it causes electronic devices or network devices or managers to implement the system functions described in the foregoing method embodiments.
[0087] Through the above description of the implementation methods, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.
[0088] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or units through some interfaces, and may be electrical, mechanical, or other forms.
[0089] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0090] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0091] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.
[0092] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A vehicle software verification method, characterized in that, Applied to a software version management system, the method includes: Obtain the identification information of the target vehicle; Based on the identification information, the target software version number corresponding to the target software in the target vehicle is determined; wherein, the target software version number is the software version number after the target software is updated; Using the software version information corresponding to the target software version number, the currently installed software version information of the target software is verified to obtain the verification result; If the verification result is that the verification failed, the system will prompt the user to update the target software.
2. The vehicle software verification method according to claim 1, characterized in that, The step of determining the target software version number corresponding to the target software in the target vehicle based on the identification information includes: Based on the identification information and the preset mapping relationship, the target software version number is determined; The preset mapping relationship is used to characterize the correspondence between the vehicle's identification information and the target software version number corresponding to the software in the vehicle.
3. The vehicle software verification method according to claim 1, characterized in that, Before verifying the currently installed software version information of the target software using the software version information corresponding to the target software version number, and obtaining the verification result, the method further includes: Obtain the currently installed software version information from the target shared space; The currently installed software version information is updated to the target shared space by the vehicle electronic inspection system after the target software in the target vehicle is updated.
4. The vehicle software verification method according to claim 1, characterized in that, The step of verifying the currently installed software version information of the target software using the software version information corresponding to the target software version number, and obtaining the verification result, includes: If the software version information corresponding to the target software version number does not exist, or if the software version information corresponding to the target software version number is inconsistent with the currently installed software version information, the verification result is determined to be verification failed.
5. The vehicle software verification method according to claim 1 or 3, characterized in that, The method further includes: After the target software update is completed, the updated software version information of the target software is verified using the software version information corresponding to the target software version number, and the verification result is obtained. If the verification result is that the verification failed, the system will prompt the user to update the target software again.
6. The vehicle software verification method according to any one of claims 1-4, characterized in that, The identification information includes at least one of the following: the identification code of the target vehicle, and the configuration information of the target vehicle.
7. The vehicle software verification method according to claim 5, characterized in that, The target software is each of the software configured in the target vehicle; the method further includes: If the verification result of the target software is successful, the target vehicle will be notified that the update is complete.
8. The vehicle software verification method according to claim 7, characterized in that, The method further includes: Generate a software update statistics chart for the target vehicle; wherein, the software update statistics chart includes the number of updates, update time, update reason, and category of the update reason for the target software within a preset time range; as well as, Generate a statistical chart of vehicles to be updated.
9. A vehicle software verification device, characterized in that, The device, used in a software version management system, includes: a data acquisition module, a determination module, a verification module, and a prompting module; The data acquisition module is used to acquire the identification information of the target vehicle; The determining module is used to determine the target software version number corresponding to the target software in the target vehicle based on the identification information; wherein, the target software version number is the software version number after the target software is updated; The verification module is used to verify the currently installed software version information of the target software using the software version information corresponding to the target software version number, and obtain the verification result. The prompting module is used to prompt the target software to be updated if the verification result is that the verification failed.
10. A vehicle, the vehicle including a software version management system; the software version management system being configured with the vehicle software verification device as described in claim 9.
11. An electronic device, characterized in that, The controller includes: a processor and a memory; The memory stores instructions that the processor can execute; When the processor is configured to execute the instructions, the controller causes the controller to implement the method as described in any one of claims 1-8.
12. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes: computer software instructions; When the computer software instructions are executed in an electronic device, the electronic device causes the electronic device to perform the method as described in any one of claims 1-8.