Electric-assisted bicycle control configuration generation and review diagnosis method and device, medium, controller and electric-assisted bicycle

Abstract

The application provides an electrically assisted bicycle control configuration generation and review diagnosis method, device, medium, controller and electrically assisted bicycle. After-sales determines a target vehicle end, reads a vehicle after-sales current configuration snapshot containing a current accessory installation state field generated by the target vehicle end, obtains an associated vehicle delivery configuration snapshot and verifies field by field to generate a vehicle configuration consistency verification record containing a difference field and a corresponding verification reference state; generate a vehicle configuration difference diagnosis disposal record according to the difference field and the corresponding verification reference state, obtain a disposal state and generate a configuration review preparation record, read the corresponding configuration field to generate a configuration review snapshot accordingly, verify the configuration review snapshot field by field according to the corresponding verification reference state, and generate a vehicle configuration review record after disposal. Therefore, the after-sales diagnosis can complete the same field review before and after disposal around the configuration difference, and the diagnosis confusion generated by only relying on the reading result is reduced.

Description

Technical Field

[0001] This application relates to the field of electric-assisted bicycle vehicle control configuration and after-sales diagnostic technology. Specifically, it relates to a method, device, medium, controller and electric-assisted bicycle for generating and verifying the control configuration of an electric-assisted bicycle. Background Technology

[0002] As the control functions of e-bikes become increasingly sophisticated, the vehicles may undergo changes in accessory configurations, control parameter adjustments, firmware updates, or changes in the status of vehicle control components during delivery and subsequent use. When a vehicle exhibits abnormalities in assist response, start-up response, power output, or other control performance, it is necessary to use after-sales diagnostic equipment to read the vehicle's current operating configuration to determine whether the vehicle's current control state is in an appropriate configuration state, and to provide a technical basis for subsequent inspection or configuration adjustments.

[0003] Existing after-sales diagnostic solutions for e-bikes typically involve a service device connecting to the vehicle's control unit to read vehicle data such as current control parameters, firmware identifiers, fault status, and communication status. The service device then analyzes the read data against pre-saved parameter ranges or preset configuration data, outputting corresponding fault categories or configuration adjustment prompts based on the analysis results. For some configuration anomalies, the service device can also rewrite the control parameters or update the vehicle's firmware, allowing the vehicle to operate according to the updated configuration.

[0004] However, the aforementioned technical solutions primarily rely on a one-time determination of the current state read during vehicle diagnostics. There is a lack of technical correlation between the read results and the vehicle's prior configuration state, allowing for continuous tracing based on corresponding configuration items. When multiple configuration items change or the usage status of accessories changes during vehicle use, relying solely on the currently read data and general preset information makes it difficult to directly identify changes in specific abnormal configuration items relative to the vehicle's original configuration state. Furthermore, after configuration adjustments, existing solutions typically lack a continuous technical process for rereading and verifying the same abnormal configuration item and its original configuration state. Therefore, it is difficult to directly distinguish whether the configuration anomaly has been eliminated or persists at the configuration data level, resulting in a lack of continuous technical verification between the after-sales configuration diagnostic results and the vehicle's configuration state after adjustments. Summary of the Invention

[0005] This application provides a method, apparatus, medium, controller, and electric-assisted bicycle for generating and verifying control configuration, so as to at least alleviate the above-mentioned technical problems.

[0006] The technical advantages of the technical solution provided in this application are: This application's method for generating and verifying the control configuration of electric-assist bicycles addresses the problem that existing after-sales diagnostics primarily rely on a one-time judgment based on the vehicle status and general preset data read at the time of diagnosis. This lack of a continuous technical correspondence between specific abnormal configuration items and the vehicle's prior configuration status results in a lack of continuity. By identifying the target vehicle through after-sales service, reading the target vehicle's generated after-sales current configuration snapshot containing the current accessory installation status field, and obtaining the vehicle delivery configuration snapshot associated with the target vehicle, both are verified field by field according to their configuration fields. Therefore, the vehicle's current configuration status is no longer used as an isolated after-sales reading result, but rather uses the vehicle delivery configuration snapshot associated with the target vehicle as the corresponding verification object. This ensures that the current accessory installation status field and other corresponding configuration fields in the vehicle's after-sales current configuration snapshot can respectively form a clear technical correspondence between the current status and the verification baseline status. Compared to processing methods that only rely on current reading values ​​and general parameter data for judgment, this application can pinpoint vehicle configuration changes to specific difference fields while simultaneously retaining the corresponding verification baseline status. This allows subsequent diagnostics to focus on the specific changed configuration fields, reducing the possibility of confusion between diagnostic objects when multiple configuration status changes occur.

[0007] Furthermore, by generating vehicle configuration consistency verification records based on the difference fields obtained from field-by-field verification and their corresponding verification baseline states, the comparison results between the current after-sales configuration snapshot and the vehicle delivery configuration snapshot not only indicate whether differences exist, but also explicitly retain the configuration fields where differences occur and the corresponding verification baseline states. Therefore, when a vehicle has multiple configuration changes that may affect control performance, subsequent processing has clearly defined configuration field objects and corresponding recovery or review references, eliminating the need to re-determine the configuration items requiring attention from all vehicle configuration data. This process transforms after-sales configuration diagnosis from a one-time judgment of the current state of the entire vehicle to continuous data processing targeting specific difference configuration fields. This improves the targeting of the configuration anomaly localization process and reduces interference from vehicle configuration fields unrelated to the current configuration difference.

[0008] To address the issue in existing technologies that lack follow-up technical verification for the same abnormal configuration item after configuration adjustment or inspection, this application generates a vehicle configuration difference diagnosis and handling record based on the difference fields and corresponding verification baseline status in the vehicle configuration consistency verification record, obtains the handling status of the vehicle configuration difference diagnosis and handling record, and then generates a configuration review preparation record based on the handling status, difference fields, and corresponding verification baseline status. Since the difference fields continue from the configuration consistency verification stage to the diagnosis and handling stage and the configuration review stage, subsequent reviews do not involve rereading all vehicle configuration statuses indiscriminately. Instead, they read the corresponding configuration fields on the target vehicle based on the difference fields in the configuration review preparation record. This maintains a continuous correspondence between the diagnostic object, the handling object, and the review object at the configuration field level, reducing the possibility that the review results may not correspond to the previous diagnostic results due to deviations in the configuration items targeted before and after handling.

[0009] During the post-processing technical verification process, this application reads the corresponding configuration fields on the target vehicle based on the difference fields in the configuration review preparation record to generate a configuration review snapshot. It then continues to verify the configuration review snapshot field by field using the corresponding verification benchmark status in the configuration review preparation record to generate a post-processing vehicle configuration review record. Compared to simply recording the operation completion status or performing a normal vehicle diagnostic again after configuration adjustment, the above process continues to use the verification benchmark status corresponding to the previous difference fields as the verification basis for the post-processing configuration fields. This ensures that the specific configuration differences discovered before processing can directly correspond to the same configuration fields read after processing. Therefore, it can reflect whether the corresponding configuration fields have reached the corresponding verification benchmark status after processing from the vehicle configuration data level. This creates a continuous technical link for vehicle configuration diagnosis: "current configuration reading—difference field determination—difference diagnosis and processing—corresponding field re-reading—review based on the original verification benchmark status." This improves the traceability between the after-sales configuration diagnosis results and the post-processing vehicle configuration status and helps distinguish between eliminated configuration differences and those that still require further diagnosis. Attached Figure Description

[0010] Figure 1 This application provides an embodiment of a method for generating and verifying the control configuration of an electric-assisted bicycle. Figure 2 This application provides an embodiment of an electric-assist bicycle control configuration generation and verification diagnostic device. Figure 3 This application provides an embodiment of a computer storage medium. Figure 4 This application describes an electric-assisted bicycle. Figure 5 This is a controller according to an embodiment of the present application. Detailed Implementation

[0011] like Figure 1 The image shows an embodiment of the present application of a method for generating and verifying the control configuration of an electric-assisted bicycle, comprising: Step S1: Obtain the vehicle's basic configuration status and accessory installation status, and generate a vehicle configuration record to be written based on the vehicle's basic configuration status, accessory installation status, and control configuration scheme. Step S2: Determine the target vehicle based on the vehicle configuration record to be written, write the control configuration scheme in the vehicle configuration record to be written to the target vehicle to generate a vehicle configuration write record that retains the accessory installation status, read back the configuration status of the target vehicle based on the vehicle configuration write record to generate a vehicle delivery configuration snapshot containing the accessory installation status field, and proceed to step S3 for field-by-field verification of the vehicle delivery configuration snapshot. Step S3: After-sales service determines the target vehicle terminal, reads the target vehicle terminal to generate a snapshot of the current configuration of the vehicle after-sales service containing the current accessory installation status field, obtains the vehicle delivery configuration snapshot associated with the target vehicle terminal, and verifies the current configuration snapshot of the vehicle after-sales service field by field according to the vehicle delivery configuration snapshot to generate a vehicle configuration consistency verification record containing the difference fields and the corresponding verification benchmark status. Step S4: Generate a vehicle configuration difference diagnosis and handling record based on the difference fields and corresponding verification benchmark status in the vehicle configuration consistency verification record; obtain the handling status of the vehicle configuration difference diagnosis and handling record; generate a configuration review preparation record based on the handling status, difference fields and corresponding verification benchmark status; read the corresponding configuration fields on the target vehicle based on the difference fields in the configuration review preparation record to generate a configuration review snapshot; verify the configuration review snapshot field by field based on the corresponding verification benchmark status in the configuration review preparation record to generate a vehicle configuration handling post-review record.

[0012] Specifically, in this application, the vehicle basic configuration state represents the vehicle configuration conditions that have been determined before the formation of the control configuration scheme and can affect the vehicle control configuration. The vehicle basic configuration state is obtained from vehicle configuration data saved during the vehicle delivery phase and vehicle configuration data readable by the target vehicle. The vehicle basic configuration state at least reflects the combined state between product specifications, vehicle category, firmware version, and controller capabilities. Product specifications define the range of functional configurations already formed on the target vehicle, vehicle category defines the vehicle configuration category corresponding to the control configuration scheme, firmware version determines the control configuration fields currently recognizable by the target vehicle, and controller capabilities determine the control configuration fields currently executable by the target vehicle. Product specifications, vehicle category, firmware version, and controller capabilities are first used to form the vehicle basic configuration state. The vehicle basic configuration state then participates in the generation of the control configuration scheme together with the accessory installation state, ensuring that the control configuration fields in the control configuration scheme correspond to the vehicle configuration conditions currently possessed by the target vehicle.

[0013] The accessory installation status indicates the current installation configuration status of accessories associated with the vehicle control configuration when the vehicle control configuration scheme is formed. The accessory installation status can be obtained from the vehicle delivery configuration record, accessory configuration data readable by the target vehicle, accessory configuration data saved on the display terminal, or accessory configuration data saved on the application terminal. In one embodiment, the accessory installation status is saved according to the accessory field identifier and accessory field status corresponding to the accessory configuration item. The accessory field identifier is used to distinguish different accessory configuration items, and the accessory field status is used to indicate the current installation configuration status of the corresponding accessory configuration item. The accessory field identifier and accessory field status together form the accessory installation status. The accessory installation status is retained after entering the vehicle configuration to be written record and continues to be retained until the vehicle configuration write record and the vehicle delivery configuration snapshot, enabling the current accessory installation status field read in the after-sales stage to establish a field correspondence with the accessory installation status field formed in the delivery stage.

[0014] The vehicle configuration record to be written is used to organize the vehicle's basic configuration state, accessory installation state, and control configuration scheme into continuous configuration data required for a single vehicle configuration write. When forming the vehicle configuration record to be written, the range of executable control configuration fields that the target vehicle can accept and execute is first limited based on the vehicle's basic configuration state. Then, based on the accessory installation state, control configuration fields within the executable control configuration field range that are associated with the accessory installation state are determined. Subsequently, the control configuration state corresponding to each control configuration field is determined, and the control configuration field and its control configuration state form the control configuration scheme. The control configuration scheme may include one or more of the following: speed limit state, power assist mode state, start-up response state, power increase rate state, torque increase rate state, warning state, or disabled state. The aforementioned control configuration fields are used for vehicle control configuration on the target vehicle side, and the specific parameter values ​​of the control configuration fields are not a necessary condition for the establishment of the control configuration scheme. The vehicle configuration record to be written also saves the vehicle's basic configuration state and accessory installation state used to form the control configuration scheme, allowing the vehicle's basic configuration state and accessory installation state to continue participating in the target vehicle side determination, target configuration execution side determination, and vehicle delivery configuration snapshot formation in step S2.

[0015] Preferably, each control configuration field in the vehicle configuration record to be written is associated with another field using a field identifier. The field identifier is pre-configured by the name of the control configuration field or the storage location of the control configuration field, which can be recognized by the target vehicle. The same field identifier is used in the vehicle configuration record to be written, the vehicle configuration write record, the vehicle delivery configuration snapshot, and the vehicle after-sales current configuration snapshot. When pre-configuring the field identifier, a correspondence is established between the field position of the same control configuration field in the vehicle configuration record to be written, its configuration position in the target configuration execution terminal, its field position in the vehicle delivery configuration snapshot, and its field position in the vehicle after-sales current configuration snapshot, and this correspondence is saved as a field identifier correspondence. In step S2, the field identifier correspondence is used to determine the target configuration execution terminal for the control configuration field. In step S3, it is used to establish the field correspondence between the vehicle delivery configuration snapshot and the vehicle after-sales current configuration snapshot, thereby ensuring that the same control configuration field maintains the same meaning during vehicle configuration writing, vehicle delivery configuration reading, and vehicle after-sales current configuration reading.

[0016] Specifically, in this application, step S2 receives the vehicle configuration record to be written generated in step S1 and uses the vehicle basic configuration status in the vehicle configuration record to determine the target vehicle terminal. The target vehicle terminal is used to represent the vehicle terminal that corresponds to the current vehicle configuration write, vehicle delivery configuration readback, and vehicle after-sales current configuration read. The vehicle basic configuration status may include a vehicle identifier associated with the target vehicle terminal, and the vehicle identifier establishes a correspondence with the vehicle basic configuration status during the vehicle delivery stage. Step S2 determines the target vehicle terminal based on the vehicle identifier. After the target vehicle terminal is determined, the vehicle configuration write record and the vehicle delivery configuration snapshot continue to establish an association with the target vehicle terminal. Step S3 determines the target vehicle terminal again based on the same vehicle identifier and obtains the vehicle delivery configuration snapshot associated with the target vehicle terminal, thereby making the vehicle delivery configuration snapshot and the vehicle after-sales current configuration snapshot correspond to the same target vehicle terminal.

[0017] When the control configuration scheme is written to the target vehicle, the target configuration execution terminal corresponding to each control configuration field is determined based on the field identifier of each control configuration field in the control configuration scheme. Then, the corresponding control configuration fields are written to the target configuration execution terminal according to the control configuration status in the vehicle's configuration record to be written. The target configuration execution terminal returns a write status for each control configuration field's write request. The write status indicates whether the corresponding control configuration field has completed the vehicle configuration write. The write status is associated with the control configuration scheme, firmware version, and accessory installation status written this time to generate a vehicle configuration write record. The vehicle configuration write record thus represents the control configuration scheme written to the target configuration execution terminal, the corresponding firmware version and accessory installation status at the time of writing, and the write status returned by the target configuration execution terminal. The vehicle configuration write record is then directly used to determine the vehicle delivery configuration readback range and form the vehicle delivery configuration status.

[0018] After the target configuration execution terminal completes the control configuration scheme writing, it does not directly use the control configuration status in the vehicle configuration record to be written as the vehicle delivery configuration status. Instead, it reads the corresponding configuration status already saved by the target configuration execution terminal based on the vehicle configuration writing record. The read corresponding configuration status includes at least the control configuration scheme verification value, firmware version, and accessory installation status. The control configuration scheme verification value is used to characterize the control configuration scheme actually read back from the target configuration execution terminal; the firmware version is used to characterize the firmware status of the target configuration execution terminal after the vehicle configuration writing is completed; and the accessory installation status is used to characterize the accessory configuration status associated with the vehicle configuration writing. A correspondence is established between the actually read control configuration scheme verification value, firmware version, and accessory installation status and the writing status in the vehicle configuration writing record to generate the vehicle delivery configuration status. Then, a vehicle delivery configuration snapshot is generated based on the vehicle delivery configuration status. Thus, the vehicle delivery configuration snapshot reflects the actual vehicle delivery configuration status formed by reading it from the target configuration execution terminal again after the vehicle configuration writing is completed, rather than directly copying the expected vehicle configuration content in the vehicle configuration record to be written.

[0019] The vehicle delivery configuration snapshot is used to retain a vehicle configuration baseline after vehicle delivery, which can be used for field-by-field verification in step S3. The vehicle delivery configuration snapshot includes at least the accessory installation status field, control configuration scheme verification value, firmware version, and write result field. The accessory installation status field stores the accessory installation status corresponding to the formation of the control configuration scheme; the control configuration scheme verification value characterizes the control configuration scheme after the vehicle configuration is written and read back; the firmware version stores the firmware status corresponding to the target vehicle at the time the vehicle delivery configuration snapshot is generated; and the write result field indicates the result status corresponding to this vehicle configuration write and vehicle delivery configuration read back. The accessory installation status field, control configuration scheme verification value, firmware version, and write result field are stored in the vehicle delivery configuration snapshot according to field identifiers. Step S3 determines the corresponding fields required for reading the current vehicle after-sales configuration based on the field identifiers in the vehicle delivery configuration snapshot and further establishes the field correspondence.

[0020] In a preferred embodiment, the vehicle delivery configuration snapshot may also save the vehicle identifier and configuration write time information corresponding to the current vehicle configuration write. The vehicle identifier is used to associate the vehicle delivery configuration snapshot with the target vehicle, and the configuration write time information is used to distinguish vehicle delivery configuration snapshots formed at different vehicle configuration write stages for the same target vehicle. The configuration write time information is written into the vehicle delivery configuration snapshot each time a vehicle delivery configuration snapshot is generated, based on the formation time of the corresponding vehicle configuration write record. When there are multiple vehicle delivery configuration snapshots for the same target vehicle, the vehicle delivery configuration snapshot associated with the target vehicle is first determined based on the vehicle identifier, and then the vehicle delivery configuration snapshot corresponding to the current vehicle delivery configuration stage is determined based on the configuration write time information. The determined vehicle delivery configuration snapshot then proceeds to step S3 for field-by-field verification.

[0021] Specifically, in this application, step S3 first determines the target vehicle terminal to be read during the after-sales phase. The target vehicle terminal is determined based on the vehicle identifier associated with the vehicle delivery configuration snapshot, ensuring that the target vehicle terminal read during the after-sales phase is consistent with the target vehicle terminal corresponding to the one formed when the vehicle delivery configuration snapshot was created. After determining the target vehicle terminal, the vehicle after-sales configuration read field record is determined based on the field identifiers corresponding to the accessory installation status field, control configuration scheme verification value, and firmware version already saved in the vehicle delivery configuration snapshot. The vehicle after-sales configuration read field record limits the control configuration field, firmware version field, and accessory installation status field to be read from the target vehicle terminal this time. The vehicle after-sales configuration read field record then sequentially participates in the reading of the current control configuration scheme verification value, the current firmware version, and the current accessory installation status, ensuring a direct field correspondence between the current configuration field in the current after-sales configuration snapshot and the corresponding configuration field in the vehicle delivery configuration snapshot.

[0022] The vehicle after-sales current configuration snapshot is used to represent the actual vehicle configuration status currently saved on the target vehicle at the time of after-sales reading. When generating the vehicle after-sales current configuration snapshot, the current control configuration scheme verification value, current firmware version, and current accessory installation status on the target vehicle are read sequentially according to the vehicle after-sales configuration reading field record, and the current control configuration scheme reading status, current firmware version reading status, and current accessory installation status reading status are formed respectively. The current control configuration scheme verification value is used to characterize the control configuration scheme currently saved on the target vehicle at the time of after-sales; the current firmware version is used to represent the corresponding firmware status on the target vehicle at the time of after-sales; the current accessory installation status is used to represent the accessory configuration status formed during after-sales reading; the current control configuration scheme reading status, current firmware version reading status, and current accessory installation status reading status are used together to determine the vehicle after-sales configuration reading status. The vehicle after-sales configuration reading status then proceeds to steps S35 and S36, which are used to determine whether the corresponding configuration fields in the vehicle after-sales current configuration snapshot and the vehicle delivery configuration snapshot meet the field verification conditions.

[0023] After obtaining the current configuration snapshot of the vehicle after-sales service, a field correspondence is established between the field identifiers in the vehicle delivery configuration snapshot and the field identifiers in the current configuration snapshot of the vehicle after-sales service. For the same field identifier, the corresponding configuration field status in the vehicle delivery configuration snapshot is used as the corresponding verification baseline status, and the corresponding configuration field status in the current configuration snapshot of the vehicle after-sales service is used as the current status. The matching status is then determined based on the corresponding verification baseline status and the current status. After completing the verification of each corresponding configuration field, the field identifier, the corresponding verification baseline status, the current status, and the matching status are saved together. After completing the verification of the control configuration scheme verification value, firmware version, and accessory installation status fields participating in this field-by-field verification, the difference fields are determined based on the matching status to generate a vehicle configuration field difference record. Then, a vehicle configuration consistency verification record is generated based on the vehicle configuration field difference record.

[0024] The vehicle configuration consistency verification record is not a single consistent or inconsistent state, but rather retains at least the identifier of the difference field and the corresponding verification baseline state. Furthermore, the vehicle configuration consistency verification record also retains the current state and matching state corresponding to the difference field, enabling step S4 to directly identify the changed difference field, the corresponding verification baseline state of the difference field in the vehicle delivery configuration snapshot, and the current state of the difference field in the vehicle after-sales current configuration snapshot. The difference field, corresponding verification baseline state, current state, and matching state continue into step S4 along the field correspondence established in step S3, allowing step S4 to directly generate a vehicle configuration difference diagnosis and handling record for the difference field without needing to re-establish the field correspondence between the vehicle delivery configuration snapshot and the vehicle after-sales current configuration snapshot.

[0025] Specifically, in this application, step S4 generates a vehicle configuration difference diagnosis and handling record based on the difference fields and corresponding verification baseline states in the vehicle configuration consistency verification record. The vehicle configuration difference diagnosis and handling record stores the difference fields requiring vehicle configuration difference diagnosis, the corresponding verification baseline states for each difference field, and the handling direction corresponding to each difference field. The handling direction maintains a field-to-field correspondence with the difference fields, ensuring that when multiple difference fields exist simultaneously, each difference field corresponds to a specific handling direction. After the vehicle configuration difference diagnosis and handling record is generated, the handling status is obtained. The handling status indicates whether the corresponding handling in the vehicle configuration difference diagnosis and handling record has been executed to the stage where vehicle configuration review can be performed.

[0026] When generating a configuration review preparation record based on the handling status, difference fields, and corresponding verification baseline status, the difference fields that need to be reread, the corresponding verification baseline status for each difference field, and the handling status are all stored in the configuration review preparation record. When the handling status in the configuration review preparation record indicates that vehicle configuration review can be performed, the corresponding configuration fields on the target vehicle are reread based on the difference fields in the configuration review preparation record. A configuration review snapshot is then generated from the read corresponding configuration fields and the corresponding verification baseline status. Since the reread corresponding configuration fields are directly derived from the difference fields in the previous vehicle configuration consistency verification record, the corresponding configuration fields in the configuration review snapshot maintain a field correspondence with the difference fields in the vehicle configuration difference diagnosis and handling record.

[0027] After generating the configuration review snapshot, the corresponding configuration fields in the configuration review snapshot are checked field by field according to the corresponding verification benchmark status of each difference field in the configuration review preparation record. When a corresponding configuration field reaches the corresponding verification benchmark status, it is determined as a processing completed field; when a corresponding configuration field does not reach the corresponding verification benchmark status, it is determined as a continuing diagnosis field. A vehicle configuration processing post-review record is generated based on the processing completed field and the continuing diagnosis field. The vehicle configuration processing post-review record thus indicates whether the difference fields determined in step S3 have reached the corresponding verification benchmark status on the target vehicle after processing in step S4, thus forming a continuous data processing relationship between the vehicle delivery configuration snapshot, the vehicle after-sales current configuration snapshot, the vehicle configuration consistency verification record, the vehicle configuration difference diagnosis and processing record, the configuration review snapshot, and the vehicle configuration processing post-review record.

[0028] Optionally, step S1 includes: Step S11: Obtain product specifications, vehicle category, firmware version, controller capabilities, and accessory configuration items to generate vehicle delivery configuration input records; Step S12: Determine the vehicle basic configuration status based on the product specifications, vehicle category, firmware version and controller capabilities in the vehicle delivery configuration input record to generate a vehicle basic configuration status record containing the vehicle basic configuration status and accessory configuration items. Step S13: Determine the accessory installation status based on the accessory configuration items in the vehicle basic configuration status record to generate a vehicle accessory configuration status record containing the vehicle basic configuration status and accessory installation status; continue to execute steps S14 and S15 based on the vehicle accessory configuration status record to generate the vehicle configuration record to be written in step S1.

[0029] Specifically, in this application, step S11 obtains product specifications, vehicle category, firmware version, and controller capabilities from the vehicle configuration data available during the vehicle delivery phase, and obtains attachment configuration items from the attachment configuration data associated with the target vehicle. Product specifications represent the product configuration specifications already formed on the target vehicle; vehicle category represents the vehicle configuration category associated with the control configuration field range of the target vehicle; firmware version is read from the firmware version field of the target vehicle to determine the control configuration fields currently recognizable by the target vehicle; controller capabilities are obtained from the control capability fields stored on the target vehicle or from capability description data associated with the corresponding controller version of the target vehicle, representing the range of control configuration fields that the target vehicle can execute; attachment configuration items represent the attachment configuration fields involved in the formation of the control configuration scheme. After obtaining the product specifications, vehicle category, firmware version, controller capabilities, and attachment configuration items, a vehicle delivery configuration input record is generated according to the field identifiers used in the vehicle delivery configuration.

[0030] The vehicle delivery configuration input record does not simply list fields from different sources consecutively; instead, it retains the field identifiers corresponding to product specifications, vehicle category, firmware version, controller capabilities, and accessory configuration items. This allows these fields to participate in the formation of the vehicle's basic configuration state and accessory installation state during subsequent processing. Step S12 reads the product specifications, vehicle category, firmware version, and controller capabilities from the vehicle delivery configuration input record. Based on these factors, it determines the vehicle configuration conditions currently available to the target vehicle, generating the vehicle's basic configuration state. After the vehicle's basic configuration state is formed, it is written to the vehicle's basic configuration state record along with the accessory configuration items, allowing the accessory configuration items to proceed to step S13.

[0031] Step S13 reads the accessory configuration items from the vehicle basic configuration status record and determines the accessory installation status based on the accessory field identifier and accessory field status corresponding to the accessory configuration item. The accessory field identifier indicates the corresponding accessory configuration item, and the accessory field status indicates the current installation configuration status of the accessory configuration item. After forming the accessory installation status based on the accessory field identifier and accessory field status, the accessory installation status and the vehicle basic configuration status are jointly written into the vehicle accessory configuration status record. The vehicle accessory configuration status record then directly proceeds to step S14, where the vehicle basic configuration status is used to determine the range of executable control configuration fields, and the accessory installation status is used to identify the control configuration fields within the range of executable control configuration fields that are affected by the accessory installation status.

[0032] In a preferred embodiment, the vehicle delivery configuration input record also retains the product specification read status, vehicle category read status, firmware version read status, controller capability read status, and accessory configuration item read status. The product specification read status indicates whether valid field content has been obtained for the product specification; the vehicle category read status indicates whether valid field content has been obtained for the vehicle category; the firmware version read status indicates whether valid field content has been obtained for the firmware version; the controller capability read status indicates whether valid field content has been obtained for the controller capability; and the accessory configuration item read status indicates whether valid field content has been obtained for the accessory configuration item. The product specification read status, vehicle category read status, firmware version read status, and controller capability read status collectively contribute to the formation of the vehicle's basic configuration status; the accessory configuration item read status and accessory configuration items collectively contribute to the formation of the accessory installation status. Therefore, each read status continues to participate in its corresponding subsequent processing and is not stored as independently unused technical information.

[0033] Optionally, step S1 further includes: Step S14: Determine the range of executable control configuration fields based on the vehicle basic configuration status in the vehicle accessory configuration status record, and generate an accessory association control configuration record containing the vehicle basic configuration status and accessory installation status within the range of executable control configuration fields based on the accessory installation status in the vehicle accessory configuration status record. Step S15: Generate a vehicle configuration record to be written, which includes the vehicle basic configuration status, accessory installation status, and control configuration status within the scope of the executable control configuration field in the attached associated control configuration record.

[0034] Specifically, in this application, the executable control configuration field range represents the boundary of control configuration fields that can be recognized and executed by the target vehicle under the constraints of the vehicle's basic configuration state. When determining the executable control configuration field range, the control configuration fields currently recognizable by the target vehicle are determined based on the firmware version in the vehicle's basic configuration state. Then, based on the controller capabilities in the vehicle's basic configuration state, the control configuration fields executable by the target vehicle are determined from the recognizable control configuration fields. The determined control configuration fields form the executable control configuration field range. The firmware version limits whether the control configuration fields can be recognized by the target vehicle, and the controller capabilities further limit whether the control configuration fields can be executed by the target vehicle; both contribute to the formation of the executable control configuration field range.

[0035] After obtaining the range of executable control configuration fields, the control configuration fields within the range that are configured to be associated with the accessory installation status are identified based on the accessory installation status in the vehicle accessory configuration status record. This configuration association means that when the accessory installation status changes, the corresponding control configuration field needs to adopt a control configuration status that adapts to the accessory installation status. For example, a control configuration field can correspond to power assist mode status, start-up response status, power increase rate status, torque increase rate status, warning status, or disabled status. All of the above control configuration fields are within the range of executable control configuration fields; it is not required that the vehicle's configuration record to be written contain all control configuration fields simultaneously.

[0036] After determining the control configuration fields affected by the accessory installation status based on the accessory installation status, the enabling or restrictive status corresponding to each control configuration field affected by the accessory installation status is further determined, and the enabling or restrictive status forms the corresponding control configuration status for each control configuration field. The vehicle basic configuration status, accessory installation status, and control configuration fields with determined control configuration statuses are jointly written into the accessory-related control configuration record. Step S15 continues to read the vehicle basic configuration status, accessory installation status, and control configuration status corresponding to each control configuration field from the accessory-related control configuration record, generates a control configuration scheme based on the control configuration status corresponding to each control configuration field, and then jointly writes the vehicle basic configuration status, accessory installation status, and control configuration scheme into the vehicle configuration record to be written.

[0037] Preferably, the range of executable control configuration fields can be pre-configured based on the firmware version and controller capabilities to establish a correspondence between firmware capability fields. When configuring the firmware capability field correspondence, a cross-correspondence is established between control configuration fields recognizable by different firmware versions and control configuration fields executable by different controller capabilities, and the corresponding field identifiers are saved for this cross-correspondence. Step S14 reads the corresponding field identifiers from the firmware capability field correspondence based on the firmware version and controller capabilities in the vehicle's basic configuration state, and determines the range of executable control configuration fields based on these field identifiers. The firmware capability field correspondence is then used to determine whether the target vehicle can recognize and execute the corresponding control configuration fields, but it does not include the specific control parameter values ​​for the control configuration fields.

[0038] Optionally, step S14 includes: Step S141: Determine the executable control configuration field based on the firmware version and controller capability corresponding to the vehicle basic configuration status in the vehicle accessory configuration status record, so as to generate a vehicle executable control configuration field record containing the vehicle basic configuration status, accessory installation status and executable control configuration field. Step S142: Determine the range of executable control configuration fields based on the executable control configuration fields in the vehicle executable control configuration field record, identify the control configuration fields affected by the accessory installation status based on the accessory installation status, and generate an accessory-affected control configuration field record that retains the vehicle basic configuration status, accessory installation status, and affected control configuration fields; continue to execute steps S143 and S144 based on the accessory-affected control configuration field record to generate an accessory-associated control configuration record.

[0039] Specifically, in this application, step S141 first reads the vehicle basic configuration status from the vehicle accessory configuration status record, and then obtains the firmware version and controller capabilities from the vehicle basic configuration status. Based on the firmware version, it reads the control configuration fields that the current firmware version can recognize from the firmware capability field correspondence, and then determines the control configuration fields that the current controller capability can execute from the control configuration fields that the current firmware version can recognize. The control configuration fields determined through the above sequential processing constitute executable control configuration fields, and together with the vehicle basic configuration status and accessory installation status, generate a vehicle executable control configuration field record.

[0040] The vehicle basic configuration status in the vehicle executable control configuration field record continues to represent the vehicle configuration conditions used when forming the executable control configuration field. The accessory installation status continues to serve as the basis for identifying the affected control configuration field in step S142. The executable control configuration field is used to limit the control configuration fields that are allowed to participate in the accessory installation status association judgment in the subsequent process. Step S142 forms the range of executable control configuration fields based on all executable control configuration fields in the vehicle executable control configuration field record, and then reads the accessory field association relationship corresponding to each executable control configuration field according to the accessory installation status. When the accessory field association relationship indicates that the corresponding executable control configuration field needs to change its control configuration status according to the current accessory installation status, the corresponding executable control configuration field is determined as the affected control configuration field.

[0041] When the appendix-affected control configuration field record is saved, the vehicle's basic configuration status and the appendix installation status are also retained. The vehicle's basic configuration status continues to be used to restrict the affected control configuration fields from exceeding the range of currently executable control configuration fields on the target vehicle side, and the appendix installation status continues to be used in step S143 to determine the enabled or restricted status corresponding to the affected control configuration fields. After the appendix-affected control configuration field record is formed, steps S143 and S144 are entered to continue generating the appendix control configuration field adaptation record and the appendix-associated control configuration record.

[0042] In a preferred embodiment, the attachment field association can be pre-configured according to the correspondence between the field identifiers of attachment configuration items and control configuration fields. When pre-configuring the attachment field association, the attachment field identifier, attachment field status, and control configuration field identifier affected by the attachment field status of the attachment configuration item are saved. After reading the attachment installation status in step S142, the attachment field association is located based on the attachment field identifier and attachment field status in the attachment installation status. Then, the control configuration field identifier affected by the attachment installation status is read from the attachment field association, and the affected control configuration field is determined by the control configuration field identifier affected by the attachment installation status. The attachment field association is then used in step S143 to determine the state adaptation relationship between the affected control configuration field and the attachment installation status.

[0043] Optionally, step S14 further includes: Step S143: Determine the enabled or restricted status of each affected control configuration field based on the affected control configuration fields and their accessory installation status in the attached affected control configuration field record, so as to generate an accessory control configuration field adaptation record containing the vehicle basic configuration status, accessory installation status, and the enabled or restricted status of each affected control configuration field. Step S144: Generate an attachment-related control configuration record based on the vehicle basic configuration status, attachment installation status, and the enable or restrict status of each affected control configuration field in the attachment control configuration field adaptation record.

[0044] Specifically, in this application, the "enabled" state indicates that the affected control configuration field can participate in the control configuration scheme according to the control configuration state allowed by the vehicle's basic configuration state, while the "restricted" state indicates that the affected control configuration field needs to change its control configuration state based on the attachment installation state or should not enter the current control configuration scheme. When determining the enabled or restricted state, the attachment field association relationship is read based on the attachment installation state in the attachment-affected control configuration field record, and then the enabled or restricted state of the affected control configuration field is determined based on the state adaptation relationship between the attachment field state and the affected control configuration field in the attachment field association relationship.

[0045] After step S143 generates the attachment control configuration field adaptation record, this record simultaneously includes the vehicle's basic configuration status, attachment installation status, and the enabled or restricted status of each affected control configuration field. Step S144 determines the control configuration fields and their control configuration status that need to be included in the subsequent control configuration scheme based on the enabled or restricted status of each affected control configuration field. Then, it generates an attachment-related control configuration record by combining the control configuration fields and their control configuration status with the vehicle's basic configuration status and attachment installation status. The attachment-related control configuration record then proceeds to step S15, enabling step S15 to generate a control configuration scheme based on the vehicle's basic configuration status, attachment installation status, and control configuration status in the attachment-related control configuration record.

[0046] Furthermore, for affected control configuration fields corresponding to the enabled state, the control configuration states allowed by the vehicle's basic configuration state can continue to be used; for affected control configuration fields corresponding to the restricted state, their control configuration state boundaries are determined jointly based on the vehicle's basic configuration state and the accessory installation state. The control configuration state boundaries are used to limit the control configuration states that affected control configuration fields can use in the current accessory installation state. After the control configuration state boundaries are formed, they continue to participate in the generation of control configuration schemes and do not form additional results that are separate from the vehicle's configuration record to be written.

[0047] Optionally, step S2 includes: Step S21: Determine the target vehicle terminal based on the vehicle basic configuration status in the vehicle configuration record to be written, and determine the target configuration execution terminal in the target vehicle terminal based on the control configuration field corresponding to the control configuration scheme in the vehicle configuration record to be written, so as to generate a vehicle configuration write path record containing the target configuration execution terminal, control configuration scheme, accessory installation status and firmware version. Step S22: Write the control configuration scheme to the target configuration execution terminal according to the vehicle configuration write path record, and generate a vehicle configuration write record containing the control configuration scheme, firmware version, accessory installation status and write status according to the write status returned by the target configuration execution terminal; continue to execute steps S23 and S24 according to the vehicle configuration write record to generate a vehicle delivery configuration snapshot.

[0048] Specifically, in this application, the target configuration execution terminal refers to the configuration location of the control configuration field corresponding to the control configuration scheme actually stored or executed in the target vehicle terminal. The vehicle basic configuration status in the vehicle configuration record to be written is used to determine the target vehicle terminal, the control configuration scheme in the vehicle configuration record to be written is used to provide the control configuration fields to be written and their control configuration status, and the field identifiers corresponding to the control configuration fields are further used to determine the target configuration execution terminal corresponding to the corresponding control configuration field. The target configuration execution terminal is determined by the field identifier correspondence and does not temporarily change the configuration location corresponding to the control configuration field during the vehicle configuration writing process.

[0049] Step S21 generates a vehicle configuration write path record based on the target configuration execution terminal corresponding to each control configuration field. The vehicle configuration write path record retains at least the target configuration execution terminal, the control configuration scheme to be written, the accessory installation status when the control configuration scheme was formed, and the firmware version in the vehicle's basic configuration status. The target configuration execution terminal is used to locate the configuration position corresponding to the control configuration scheme; the control configuration scheme is used to provide the control configuration fields to be written and their control configuration status; the accessory installation status is used to ensure that the subsequent vehicle delivery configuration readback result corresponds to the accessory installation status when the control configuration scheme was formed; the firmware version is used to ensure that the subsequent vehicle delivery configuration snapshot retains the firmware status at the time of vehicle configuration writing. The target configuration execution terminal, control configuration scheme, accessory installation status, and firmware version then proceed to step S22.

[0050] Step S22 executes vehicle configuration writing based on the target configuration execution end and control configuration scheme in the vehicle configuration write path record. For each control configuration field in the control configuration scheme, the corresponding configuration position in the target configuration execution end is located according to the field identifier corresponding to the control configuration field, and then the control configuration status corresponding to the control configuration field is written to the corresponding configuration position. After the target configuration execution end completes the writing of the corresponding control configuration field, it returns the write status. The write status corresponding to each control configuration field is associated with the control configuration scheme, firmware version, and accessory installation status to generate a vehicle configuration write record. The vehicle configuration write record then directly proceeds to step S23, which is used to determine the target control configuration scheme verification value, the vehicle delivery configuration readback field record, and the vehicle delivery configuration status.

[0051] Preferably, the vehicle configuration write record saves the write status according to the control configuration field, maintaining a field correspondence between the control configuration field and the write status. The write status corresponding to the control configuration field enters step S231 to form the vehicle delivery configuration readback baseline record, and in step S234, it participates in the formation of the vehicle delivery configuration status together with the readback status of the corresponding control configuration field. Therefore, the write status is not an independently recorded operation result, but continues to participate in the formation of the write result field in the vehicle delivery configuration status and the vehicle delivery configuration snapshot.

[0052] Optionally, step S2 further includes: Step S23: Based on the control configuration scheme, firmware version, accessory installation status and write status in the vehicle configuration write record, read back the corresponding configuration status of the target configuration execution terminal, and generate the vehicle delivery configuration status based on the read back control configuration scheme verification value, firmware version, accessory installation status and write status. Step S24: Generate a vehicle delivery configuration snapshot based on the vehicle delivery configuration status; the vehicle delivery configuration snapshot includes the accessory installation status field, control configuration scheme verification value, firmware version and write result field, and proceeds to step S3 as the field-by-field verification benchmark for the current configuration snapshot of the vehicle after-sales service.

[0053] Specifically, in this application, step S23 uses the control configuration scheme in the vehicle configuration write record as the basis for determining the vehicle delivery configuration readback range. Based on the field identifier corresponding to the control configuration scheme, the control configuration fields that need to be read again from the target configuration execution end are determined. Based on the firmware version in the vehicle configuration write record, the firmware version field that needs to be read is determined. Based on the accessory installation status in the vehicle configuration write record, the accessory installation status field that needs to be read or retained is determined. The aforementioned control configuration fields, firmware version fields, and accessory installation status fields together form the vehicle delivery configuration readback field record, ensuring that the vehicle delivery configuration readback content corresponds to the current vehicle configuration write record.

[0054] After reading the control configuration fields from the target configuration execution terminal, a control configuration scheme verification value is formed based on the read-back control configuration fields. The control configuration scheme verification value is used to represent the control configuration scheme actually read from the target configuration execution terminal in a fixed data format. When forming the control configuration scheme verification value, the control configuration fields participating in the control configuration scheme verification are subjected to the same verification encoding process according to a pre-configured field identifier order that remains consistent between the vehicle delivery configuration read-back stage and the vehicle after-sales current configuration read-back stage. The verification encoding result forms the control configuration scheme verification value. The field identifier order is used to fix the arrangement relationship of the control configuration fields participating in the formation of the control configuration scheme verification value, and the field identifier order remains consistent when forming the target control configuration scheme verification value in step S231 and when forming the read-back control configuration scheme verification value in step S233.

[0055] The read-back control configuration scheme verification value, firmware version, accessory installation status, and write status in the vehicle configuration write record are combined to generate the vehicle delivery configuration status. The vehicle delivery configuration status then proceeds to step S24, where the accessory installation status forms an accessory installation status field, the control configuration scheme verification value forms the control configuration scheme verification value in the vehicle delivery configuration snapshot, the firmware version forms the firmware version in the vehicle delivery configuration snapshot, and the write status, combined with the corresponding read-back status, forms a write result field. The vehicle delivery configuration snapshot thus simultaneously reflects the actual read-back content of the control configuration scheme, the firmware status corresponding to the vehicle configuration write, the accessory installation status, and the result status corresponding to the vehicle configuration write and vehicle delivery configuration read-back, and directly proceeds to step S3.

[0056] In a preferred embodiment, the write result field can be categorized based on the write status and readback status, such as "vehicle configuration writing completed and vehicle delivery configuration readback completed," "vehicle configuration writing completed but corresponding control configuration field not readback completed," and "vehicle configuration writing error." After entering steps S35 and S36, the write result field participates in the field validation condition determination, ensuring that when the vehicle delivery configuration readback itself is abnormal, the corresponding configuration field for which a valid current status cannot be obtained is not directly identified as a content difference field.

[0057] Optionally, step S23 includes: Step S231: Determine the target control configuration scheme verification value based on the control configuration scheme in the vehicle configuration write record; generate a vehicle delivery configuration readback baseline record containing the target control configuration scheme verification value, firmware version, accessory installation status, and write status based on the firmware version, accessory installation status, and target control configuration scheme verification value in the vehicle configuration write record. Step S232: Determine the corresponding fields that need to be read back from the target configuration execution end based on the target control configuration scheme verification value, firmware version and accessory installation status in the vehicle delivery configuration readback baseline record, so as to generate the vehicle delivery configuration readback field record; continue to execute steps S233 and S234 based on the vehicle delivery configuration readback field record to generate the vehicle delivery configuration status.

[0058] Specifically, in this application, the target control configuration scheme verification value represents the expected vehicle configuration write verification state formed based on the control configuration scheme in the vehicle configuration write record. When generating the target control configuration scheme verification value, the control configuration fields participating in this vehicle configuration write are determined according to the field identifiers corresponding to the control configuration fields in the control configuration scheme. Then, verification encoding processing is performed on the corresponding control configuration fields according to the field identifier order to generate the target control configuration scheme verification value. The target control configuration scheme verification value originates from the control configuration scheme in the vehicle configuration write record and serves as the verification benchmark corresponding to the read-back control configuration scheme verification value in step S234.

[0059] Step S231 combines the target control configuration scheme verification value with the firmware version, accessory installation status, and write status from the vehicle configuration write record to generate a vehicle delivery configuration readback baseline record. The target control configuration scheme verification value in the vehicle delivery configuration readback baseline record is used to determine the control configuration scheme that needs to be verified; the firmware version is used to determine the firmware version field that needs to be read from the target configuration execution end; the accessory installation status is used to determine the accessory installation status field that needs to be read or retained; and the write status is used in step S234 to generate the vehicle delivery configuration status. The target control configuration scheme verification value, firmware version, accessory installation status, and write status all continue to be processed in subsequent vehicle delivery configuration readback steps.

[0060] Step S232 determines the control configuration fields to be read back based on the control configuration fields corresponding to the target control configuration scheme verification value, determines the firmware version field based on the firmware version, and determines the accessory installation status field based on the accessory installation status, thereby generating a vehicle delivery configuration readback field record. The vehicle delivery configuration readback field record describes the control configuration fields, firmware version field, and accessory installation status field that need to be read from the target configuration execution end in step S233, and saves the field correspondence between each corresponding field and the target control configuration scheme verification value, firmware version, and accessory installation status in the vehicle delivery configuration readback baseline record. Step S233 directly reads the target configuration execution end based on the vehicle delivery configuration readback field record, without re-determining the vehicle delivery configuration readback range from the vehicle configuration record to be written.

[0061] Furthermore, the control configuration fields in the vehicle delivery configuration readback field record are saved according to the field identifier order used when generating the target control configuration scheme verification value. This field identifier order is used to generate the readback control configuration scheme verification value after the control configuration fields are read in step S233, enabling step S234 to determine the correspondence between the target control configuration scheme verification value and the readback control configuration scheme verification value under the same field identifier order.

[0062] Optionally, step S23 further includes: Step S233: Read the control configuration scheme verification value, firmware version and accessory installation status of the target configuration execution terminal according to the vehicle delivery configuration readback field record, so as to generate a vehicle delivery configuration readback record containing the corresponding readback field value; Step S234: Determine the readback status of the control configuration scheme verification value, firmware version and accessory installation status field by field based on the vehicle delivery configuration readback baseline record and the vehicle delivery configuration readback record. Generate the vehicle delivery configuration status based on the write status and readback status in the vehicle delivery configuration readback baseline record, so that step S24 can generate a vehicle delivery configuration snapshot.

[0063] Specifically, in this application, step S233 initiates a corresponding configuration field read from the target configuration execution terminal based on the field identifiers in the vehicle delivery configuration readback field record. For the control configuration field corresponding to the control configuration scheme, the state of the control configuration field already saved by the target configuration execution terminal is obtained according to the field identifier order in the vehicle delivery configuration readback field record, and the readback control configuration scheme verification value is formed according to the verification encoding used when generating the target control configuration scheme verification value; for the firmware version field, the firmware version currently saved by the target configuration execution terminal is read; for the accessory installation status field, the accessory installation status associated with this vehicle configuration write is read. The readback control configuration scheme verification value, firmware version, and accessory installation status are written into the vehicle delivery configuration readback record according to the field correspondence in the vehicle delivery configuration readback field record.

[0064] Step S234 uses the vehicle delivery configuration readback baseline record and the vehicle delivery configuration readback record as continuous verification objects. For the control configuration scheme verification value, the target control configuration scheme verification value in the vehicle delivery configuration readback baseline record is matched with the control configuration scheme verification value in the vehicle delivery configuration readback record to form a readback state corresponding to the control configuration scheme verification value; for the firmware version, the firmware version in the vehicle delivery configuration readback baseline record is matched with the firmware version in the vehicle delivery configuration readback record to form a readback state corresponding to the firmware version; for the accessory installation state, the accessory installation state in the vehicle delivery configuration readback baseline record is matched with the accessory installation state in the vehicle delivery configuration readback record to form a readback state corresponding to the accessory installation state.

[0065] Subsequently, the readback status corresponding to the control configuration scheme verification value, the readback status corresponding to the firmware version, and the readback status corresponding to the accessory installation status are associated with the write status in the vehicle delivery configuration readback baseline record to generate the vehicle delivery configuration status. The vehicle delivery configuration status thus reflects the continuous relationship between the vehicle configuration write status and the vehicle delivery configuration readback status. After generating the vehicle delivery configuration snapshot based on the vehicle delivery configuration status in step S24, the vehicle delivery configuration snapshot serves as the corresponding verification baseline used for field-by-field verification in step S3.

[0066] Optionally, the process of generating a snapshot of the vehicle's current after-sales configuration in step S3 includes: Step S31: Determine the after-sales read field identifier based on the accessory installation status field, control configuration scheme verification value and firmware version in the vehicle delivery configuration snapshot, so as to generate a vehicle after-sales configuration read field record; Step S32: Read the current control configuration scheme verification value of the target vehicle based on the vehicle after-sales configuration read field record and determine the current control configuration scheme read status to generate a vehicle current control configuration read record containing the current control configuration scheme verification value, the current control configuration scheme read status, the firmware version field identifier, and the accessory installation status field identifier; continue to read the current firmware version and the current accessory installation status based on the vehicle current control configuration read record to generate a vehicle after-sales current configuration snapshot.

[0067] Specifically, in this application, step S31 does not read the target vehicle terminal according to a fixed field list unrelated to the vehicle delivery configuration snapshot. Instead, it reads the field identifiers corresponding to the accessory installation status field, control configuration scheme verification value, and firmware version from the vehicle delivery configuration snapshot, and generates a vehicle after-sales configuration read field record based on the aforementioned field identifiers. The vehicle after-sales configuration read field record is used to determine the control configuration field, firmware version field, and accessory installation status field that need to be read again from the target vehicle terminal during the after-sales stage.

[0068] The field identifiers in the vehicle after-sales configuration read field record correspond to the field identifiers in the vehicle delivery configuration snapshot. The field identifier corresponding to the control configuration scheme verification value is used to determine the control configuration field read range corresponding to the current control configuration scheme verification value; the firmware version field identifier is used to read the current firmware version in step S33; and the accessory installation status field identifier is used to read the current accessory installation status in step S34. After the vehicle after-sales configuration read field record is formed, each of its included field identifiers continues to be used in the current control configuration scheme verification value, current firmware version, and current accessory installation status read processes, respectively.

[0069] Step S32 first reads the currently saved control configuration fields on the target vehicle according to the field identifier corresponding to the control configuration scheme verification value in the vehicle after-sales configuration read field record. After reading the currently saved control configuration fields on the target vehicle, the current control configuration scheme verification value is formed according to the same field identifier order and verification code as in step S233. The current control configuration scheme read status is determined based on whether the corresponding control configuration fields involved in forming the current control configuration scheme verification value have been read. The current control configuration scheme verification value, the current control configuration scheme read status, the firmware version field identifier, and the accessory installation status field identifier are used together to generate the vehicle current control configuration read record.

[0070] The vehicle's current control configuration read record then proceeds to step S33, where the firmware version field is used to read the current firmware version, and the current control configuration scheme verification value and the current control configuration scheme read status are retained. The vehicle's current firmware read record formed in step S33 then proceeds to step S34, where the accessory installation status field is used to read the current accessory installation status. Through the above continuous reading relationship, the current control configuration scheme verification value, current firmware version, and current accessory installation status in the vehicle's after-sales current configuration snapshot can all be traced back to the corresponding configuration fields in the vehicle's delivery configuration snapshot based on the field identifiers.

[0071] Optionally, the process of generating a snapshot of the vehicle's current after-sales configuration in step S3 further includes: Step S33: Read the current firmware version based on the firmware version field identifier in the vehicle current control configuration read record and determine the current firmware version read status to generate a vehicle current firmware read record containing the current control configuration scheme verification value, current control configuration scheme read status, current firmware version, current firmware version read status and accessory installation status field identifiers; Step S34: Read the current accessory installation status based on the accessory installation status field identifier in the vehicle's current firmware read record and determine the current accessory installation status read status to generate a vehicle current accessory status read record containing the current control configuration scheme verification value, current firmware version, current accessory installation status, current control configuration scheme read status, current firmware version read status, and current accessory installation status read status; determine the vehicle after-sales configuration read status based on each read status in the vehicle current accessory status read record, and generate a vehicle after-sales current configuration snapshot based on the current control configuration scheme verification value, current firmware version, current accessory installation status, and vehicle after-sales configuration read status.

[0072] Specifically, in this application, step S33 locates the firmware version field corresponding to the target vehicle based on the firmware version field identifier in the vehicle current control configuration read record, then reads the current firmware version in the firmware version field, and forms the current firmware version read status based on whether the current firmware version has been read. The current firmware version and the current firmware version read status, together with the previously obtained current control configuration scheme verification value, the current control configuration scheme read status, and the accessory installation status field identifier still to be used in step S34, jointly generate the vehicle current firmware read record.

[0073] Step S34 continues to use the accessory installation status field in the vehicle's current firmware read record to identify the current accessory installation status. The current accessory installation status maintains the same field meaning as the accessory installation status field in the vehicle delivery configuration snapshot, ensuring that subsequent field-by-field verification targets the same accessory configuration item. After reading the current accessory installation status, a current accessory installation status read status is formed based on whether the current accessory installation status has been read successfully. Then, the current control configuration scheme verification value, current firmware version, current accessory installation status, current control configuration scheme read status, current firmware version read status, and current accessory installation status read status are all written together into the vehicle's current accessory status read record.

[0074] After the current vehicle accessory status read record is formed, the vehicle after-sales configuration read status is determined based on the current control configuration scheme read status, current firmware version read status, and current accessory installation status read status. The vehicle after-sales configuration read status indicates whether the current control configuration scheme verification value, current firmware version, and current accessory installation status, which participated in the formation of the vehicle after-sales current configuration snapshot, have completed this after-sales read. Subsequently, a vehicle after-sales current configuration snapshot is generated based on the current control configuration scheme verification value, current firmware version, current accessory installation status, and vehicle after-sales configuration read status. The vehicle after-sales configuration read status then proceeds to steps S35 and S36, which are used to determine whether the corresponding configuration fields in the vehicle delivery configuration snapshot and the vehicle after-sales current configuration snapshot meet the field verification conditions.

[0075] In one embodiment, the vehicle after-sales current configuration snapshot stores the current control configuration scheme verification value, current firmware version, and current accessory installation status fields using the same field identifier structure as the vehicle delivery configuration snapshot. This identical field identifier structure allows step S35 to directly establish field correspondences based on the field identifiers, and enables these field correspondences to proceed to steps S36 and S37 to participate in field verification condition determination and field matching verification.

[0076] Optionally, step S3 further includes: Step S35: Generate a vehicle configuration field correspondence record containing the field correspondence, write result field, and vehicle after-sales configuration read status based on the field identifiers in the vehicle delivery configuration snapshot and the current vehicle after-sales configuration snapshot; Step S36: Determine whether the field verification conditions are met based on the write result field in the corresponding record of the vehicle configuration field and the vehicle after-sales configuration read status, so as to generate a vehicle configuration verification pre-state record containing the field correspondence and the field verification condition determination result; continue to execute steps S37, S38 and S39 based on the vehicle configuration verification pre-state record to generate a vehicle configuration consistency verification record.

[0077] Specifically, in this application, step S35 reads the field identifiers from the vehicle delivery configuration snapshot and the vehicle after-sales current configuration snapshot, respectively, and establishes a field correspondence relationship for corresponding configuration fields with the same field identifier. The field correspondence relationship includes at least the field correspondence between the control configuration scheme verification value and the current control configuration scheme verification value, the field correspondence between the firmware version and the current firmware version, and the field correspondence between the accessory installation status field and the current accessory installation status field. After establishing the field correspondence relationship, the write result field from the vehicle delivery configuration snapshot and the vehicle after-sales configuration read status from the vehicle after-sales current configuration snapshot are added to the vehicle configuration field correspondence record.

[0078] The field correspondence is used in step S37 to determine the corresponding configuration fields that need to be matched and verified field by field. The write result field and the vehicle after-sales configuration read status are used in step S36 to determine whether the corresponding configuration field meets the field verification conditions. When the write result field in the vehicle delivery configuration snapshot indicates that the corresponding configuration field has completed vehicle configuration writing and vehicle delivery configuration reading, and the vehicle after-sales configuration read status indicates that the corresponding current configuration field has completed after-sales reading, the corresponding field correspondence is determined to meet the field verification conditions. When the write result field or the vehicle after-sales configuration read status indicates that the corresponding field has not formed a valid state that can be matched and verified, the corresponding field correspondence is determined to not meet the field verification conditions, instead of directly determining the incomplete reading as a field content mismatch.

[0079] Step S36 generates a vehicle configuration verification pre-state record. This record saves the field correspondences formed in step S35 and stores the field verification condition judgment results for each corresponding field correspondence. The field correspondences proceed to step S37, where the field verification condition judgment results determine whether field matching verification is performed on the corresponding field correspondences. Subsequent step S38 continues to use the vehicle configuration verification pre-state record to distinguish differences arising from changes in field content from field verification condition judgment results corresponding to vehicle configuration write anomalies or vehicle after-sales configuration read anomalies.

[0080] Preferably, the field verification conditions are determined separately according to the field correspondence, rather than forming a single field verification condition determination result for the entire vehicle after-sales current configuration snapshot. For field correspondences with field verification conditions, step S37 continues to form the corresponding verification baseline state, current state, and matching state; for field correspondences without field verification conditions, the vehicle configuration verification pre-state record continues to retain the corresponding field verification condition determination result, and the corresponding vehicle configuration verification pre-state is retained in the vehicle configuration consistency verification record.

[0081] Optionally, step S3 further includes: Step S37: When the field verification condition judgment result in the vehicle configuration verification pre-state record indicates that the field verification condition is met, the matching status of the control configuration scheme verification value, firmware version and accessory installation status fields is verified according to the field correspondence relationship to generate a vehicle core configuration field verification record containing the verification benchmark status, current status and matching status of each field. Step S38: Determine the difference fields based on the vehicle configuration verification pre-state record and the vehicle core configuration field verification record to generate a vehicle configuration field difference record containing the vehicle configuration verification pre-state, difference field identifier, and corresponding verification benchmark state, current state, and matching state. Step S39: Generate a vehicle configuration consistency verification record based on the vehicle configuration field difference record, which retains the vehicle configuration verification pre-verification status, difference field identifier, corresponding verification benchmark status, current status, and matching status. The vehicle configuration consistency verification record proceeds to step S4 for vehicle configuration difference diagnosis.

[0082] Specifically, in this application, step S37 performs field matching verification item by item for the field correspondences in the vehicle configuration verification pre-state record that indicate the field verification conditions are met. For the field correspondence between the control configuration scheme verification value and the current control configuration scheme verification value, the control configuration scheme verification value in the vehicle delivery configuration snapshot is used as the corresponding verification baseline state, and the current control configuration scheme verification value in the vehicle after-sales current configuration snapshot is used as the current state. A matching state corresponding to the control configuration scheme verification value is formed based on the corresponding verification baseline state and the current state. For the field correspondence between the firmware version and the current firmware version, the firmware version in the vehicle delivery configuration snapshot is used as the corresponding verification baseline state, and the current firmware version in the vehicle after-sales current configuration snapshot is used as the current state. A matching state corresponding to the firmware version is formed based on the corresponding verification baseline state and the current state. For the field correspondence between the accessory installation status field and the current accessory installation status field, the accessory installation status field in the vehicle delivery configuration snapshot is used as the corresponding verification baseline state, and the current accessory installation status field in the vehicle after-sales current configuration snapshot is used as the current state. A matching state corresponding to the accessory installation status field is formed based on the corresponding verification baseline state and the current state.

[0083] The control configuration scheme verification value, firmware version, and accessory installation status fields, respectively, are written into the vehicle core configuration field verification record according to their field identifiers, along with their corresponding verification baseline status, current status, and matching status. The vehicle core configuration field verification record not only retains the matching status but also the corresponding verification baseline status and current status used to form the matching status, enabling the acquisition of the corresponding verification baseline status and current status for the differing fields after step S38 determines the differing fields.

[0084] Step S38 combines the vehicle configuration verification pre-verification status record and the vehicle core configuration field verification record to determine the difference fields. For corresponding configuration fields that already meet the field verification conditions and whose matching status indicates a mismatch, these corresponding configuration fields are identified as difference fields. For corresponding configuration fields that do not meet the field verification conditions, the field verification condition judgment results in the vehicle configuration verification pre-verification status record are retained, and these corresponding configuration fields are not directly identified as content difference fields. This generates a vehicle configuration field difference record. The vehicle configuration field difference record at least saves the difference field identifier, the corresponding verification baseline status, the current status, and the matching status, and also continues to save the vehicle configuration verification pre-verification status.

[0085] Step S39 generates a vehicle configuration consistency verification record based on the vehicle configuration field difference record. The vehicle configuration consistency verification record retains the vehicle configuration verification pre-verification state, the difference field identifier, and the corresponding verification baseline state, current state, and matching state for each difference field. This allows step S4 to directly diagnose vehicle configuration differences based on the difference field, the corresponding verification baseline state, the current state, and the matching state. In a preferred embodiment, the vehicle configuration consistency verification record establishes field association relationships between the difference field and the corresponding verification baseline state, current state, and matching state according to the difference field identifier. These field association relationships are then used for vehicle authorized configuration change record verification and field-by-field verification of configuration review snapshots.

[0086] Optionally, step S38 includes: Step S381: Determine the candidate difference fields in the control configuration scheme verification value, firmware version and accessory installation status fields based on the vehicle core configuration field verification record, and generate a vehicle candidate difference record containing the vehicle configuration verification pre-state and the verification benchmark state and current state corresponding to the candidate difference fields, in combination with the vehicle configuration verification pre-state record. Step S382: When the vehicle candidate difference record contains a control configuration scheme verification value or a firmware version difference, read the pre-stored vehicle authorized configuration change record corresponding to the target vehicle and the candidate difference field according to the candidate difference field in the vehicle candidate difference record, so as to generate an authorized change verification record that retains the vehicle candidate difference record and contains the corresponding changed configuration status; continue to execute steps S383 and S384 according to the authorized change verification record to determine the difference fields that are not interpreted by the vehicle authorized configuration change record.

[0087] Specifically, in this application, the candidate difference field is used to represent a configuration field that has formed a mismatch state after the field matching verification in step S37, but has not yet been verified whether the mismatch state can be interpreted by the vehicle authorized configuration change record. Step S381 reads the control configuration scheme verification value, firmware version, or accessory installation status field indicating a mismatch from the vehicle core configuration field verification record, determines the corresponding configuration field as a candidate difference field, and continues to write the field identifier, corresponding verification baseline state, and current state corresponding to the candidate difference field into the vehicle candidate difference record. At the same time, the vehicle configuration verification pre-state in the vehicle configuration verification pre-state record continues to write into the vehicle candidate difference record, so that the vehicle candidate difference record retains the field verification conditions when the candidate difference field was formed.

[0088] Vehicle authorized configuration change records are used to represent configuration changes that have been completed on the target vehicle and are allowed to be retained in subsequent vehicle configurations after the vehicle delivery configuration snapshot is formed. Vehicle authorized configuration change records are generated when a configuration change that is allowed to be retained occurs in the corresponding configuration field, and are associated with the target vehicle and the field identifier where the configuration change occurred. Vehicle authorized configuration change records include at least the field identifier where the configuration change occurred and the corresponding post-change configuration status. The field identifier enables the vehicle authorized configuration change record to correspond to the candidate difference fields in the vehicle candidate difference record, and the post-change configuration status is used to perform subsequent difference interpretation and determination based on the current status of the candidate difference field.

[0089] Step S382 reads the vehicle authorized configuration change record when the vehicle candidate difference record contains a control configuration scheme verification value or a firmware version difference. First, the vehicle authorized configuration change record associated with the current vehicle is determined based on the target vehicle. Then, the configuration change content corresponding to the candidate difference field is determined from the vehicle authorized configuration change record based on the field identifier corresponding to the candidate difference field. Thus, the read vehicle authorized configuration change record establishes a correspondence with both the target vehicle and the candidate difference field, without using the changed configuration status of other target vehicles or other configuration fields to interpret the current candidate difference field.

[0090] When generating the authorized change verification record based on the vehicle candidate difference record and the read vehicle authorized configuration change record, the candidate difference field, the corresponding verification benchmark status, and the current status in the vehicle candidate difference record are retained, and the changed configuration status in the vehicle authorized configuration change record is added. The authorized change verification record thus simultaneously possesses the corresponding verification benchmark status of the candidate difference field in the vehicle delivery configuration snapshot, the current status of the candidate difference field in the vehicle after-sales current configuration snapshot, and the changed configuration status in the vehicle authorized configuration change record. The corresponding verification benchmark status, the current status, and the changed configuration status then proceed to step S383, used to determine whether the candidate difference field can be interpreted by the vehicle authorized configuration change record.

[0091] In a preferred embodiment, the vehicle authorized configuration change record can also store firmware version applicability conditions corresponding to the changed configuration state. When the vehicle authorized configuration change record is generated, the firmware version applicability conditions are pre-configured based on the range of firmware versions applicable to the changed configuration state and associated with the corresponding changed configuration state. When a candidate difference field belongs to a control configuration scheme verification value, step S382 reads the firmware version applicability conditions corresponding to the changed configuration state while reading the changed configuration state, and writes the firmware version applicability conditions into the authorized change verification record. The firmware version applicability conditions in the authorized change verification record then proceed to step S383 together with the current firmware version in the vehicle after-sales current configuration snapshot, ensuring that the difference corresponding to the current control configuration scheme verification value only proceeds to the subsequent difference interpretation state determination when the current state conforms to the changed configuration state and the current firmware version meets the firmware version applicability conditions.

[0092] Optionally, step S38 further includes: Step S383: Determine whether the candidate difference field can be interpreted by the vehicle authorized configuration change record based on the current status of the candidate difference field and the corresponding post-change configuration status in the authorized change verification record, so as to generate a vehicle configuration difference interpretation record that retains the authorized change verification record and marks the difference interpretation status. Step S384: Determine the unexplained difference fields based on the difference explanation status in the vehicle configuration difference explanation record, update the corresponding field matching status based on the unexplained difference fields, and generate a vehicle configuration field difference record that includes the vehicle configuration verification pre-state and the verification benchmark state, current state and matching state corresponding to the unexplained difference fields; the vehicle configuration field difference record proceeds to step S39 to generate a vehicle configuration consistency verification record.

[0093] Specifically, in this application, step S383 directly follows the authorization change verification record formed in step S382. The authorization change verification record already stores the verification baseline state, current state, and post-change configuration state corresponding to the candidate difference field according to the same candidate difference field. Therefore, step S383 does not reread other vehicle configuration data, but instead reads the current state and post-change configuration state in the authorization change verification record based on the field identifier corresponding to the candidate difference field, and then determines whether the current state corresponds to the post-change configuration state. When the current state corresponds to the post-change configuration state, the difference explanation state corresponding to the candidate difference field is determined as an explained state; when the current state does not correspond to the post-change configuration state, the difference explanation state corresponding to the candidate difference field is determined as an unexplained state. The candidate difference field, the corresponding verification baseline state, the current state, the post-change configuration state, and the difference explanation state are all retained in the vehicle configuration difference explanation record, allowing the vehicle configuration difference explanation record to continue to step S384.

[0094] For candidate difference fields corresponding to the control configuration scheme verification value, in an implementation where the authorized change verification record also includes firmware version applicability conditions, step S383 first determines whether the configuration content corresponds based on the current state of the candidate difference field and the changed configuration state, and then determines whether the current firmware version meets the firmware version applicability conditions based on the current firmware version and firmware version applicability conditions. When the configuration content corresponds and the current firmware version meets the firmware version applicability conditions, the difference explanation state of the candidate difference field corresponding to the control configuration scheme verification value is determined to be explained; when the configuration content does not correspond or the current firmware version does not meet the firmware version applicability conditions, the difference explanation state of the candidate difference field corresponding to the control configuration scheme verification value is determined to be unexplained. Therefore, the vehicle authorized configuration change record does not directly eliminate candidate difference fields simply because it exists; instead, the difference explanation state is determined jointly by the current state, the changed configuration state, and the firmware version applicability conditions associated with the changed configuration state.

[0095] Step S384 reads the difference explanation status in the vehicle configuration difference explanation record and identifies candidate difference fields with an "unexplained" status as unexplained difference fields. For candidate difference fields with an "explained" status, these fields are no longer considered for further vehicle configuration difference diagnosis. For unexplained difference fields, the corresponding verification baseline status and current status are retained, and the matching status remains "mismatched." Subsequently, the vehicle configuration verification prerequisite status, unexplained difference fields, the corresponding verification baseline status, the current status, and the matching status are combined to generate a vehicle configuration field difference record. After the vehicle configuration field difference record proceeds to step S39, a vehicle configuration consistency verification record is generated, ensuring that the difference fields in the vehicle configuration consistency verification record remain configuration fields that cannot yet be explained by the vehicle authorized configuration change record.

[0096] Preferably, vehicle authorized configuration change records are saved according to the correspondence between the target vehicle, field identifier, and post-change configuration status, and the configuration change time information corresponding to the vehicle authorized configuration change record is saved synchronously when the vehicle authorized configuration change record is generated. After determining the vehicle authorized configuration change record based on the target vehicle and candidate difference fields in step S382, when there are multiple vehicle authorized configuration change records corresponding to the same field identifier, the most recently completed vehicle authorized configuration change record after the formation of the vehicle delivery configuration snapshot is determined based on the configuration change time information, and then the post-change configuration status in the determined vehicle authorized configuration change record proceeds to step S383. The configuration change time information is thus used to determine the post-change configuration status to explain the current status of the candidate difference fields when there are continuous configuration changes on the same target vehicle, and continues to participate in the formation of the authorized change verification record along with the corresponding vehicle authorized configuration change record.

[0097] Optionally, step S37 includes: Step S371: Verify the control configuration scheme verification value against the current control configuration scheme verification value according to the vehicle configuration field corresponding record, so as to generate a control configuration scheme field verification record containing the field correspondence relationship and the control configuration scheme corresponding verification benchmark state, current state and matching state; Step S372: Read the firmware applicable conditions corresponding to the control configuration scheme verification value according to the field correspondence in the control configuration scheme field verification record. Determine the firmware matching status according to the firmware applicable conditions and the current firmware version to generate a firmware applicable verification record that retains the control configuration scheme field verification record and includes the verification benchmark status, current status and matching status corresponding to the firmware version. Continue to execute steps S373 and S374 according to the firmware applicable verification record to complete the accessory installation status field verification and generate the vehicle core configuration field verification record.

[0098] Specifically, in this application, step S371 reads the field correspondence between the control configuration scheme verification value and the current control configuration scheme verification value from the vehicle configuration field corresponding record. The control configuration scheme verification value comes from the vehicle delivery configuration snapshot, and the current control configuration scheme verification value comes from the vehicle after-sales current configuration snapshot. According to the field correspondence, the control configuration scheme verification value is used as the control configuration scheme corresponding verification baseline state, and the current control configuration scheme verification value is used as the current state. Then, the same verification encoding used in the vehicle delivery configuration readback stage and the vehicle after-sales current configuration read stage is used to determine whether the control configuration scheme corresponding verification baseline state and the current state correspond, so as to form a matching state corresponding to the control configuration scheme verification value. The field correspondence, the control configuration scheme corresponding verification baseline state, the current state, and the matching state are jointly written into the control configuration scheme field verification record.

[0099] The field correspondence in the control configuration scheme field verification record continues to step S372. Firmware applicability conditions indicate the firmware version conditions under which the control configuration scheme corresponding to the control configuration scheme verification value can be normally applied on the target vehicle. When forming the control configuration scheme, the firmware applicability conditions are pre-configured based on the firmware version range required for the control configuration fields in the control configuration scheme to be recognized and executed by the target vehicle, and a correspondence is established according to the control configuration scheme verification value. When pre-configuring firmware applicability conditions, a correspondence is established between the firmware version range that can recognize and execute the corresponding control configuration fields and the control configuration scheme verification value, and this correspondence is saved, enabling step S372 to read the corresponding firmware applicability conditions based on the control configuration scheme verification value in the control configuration scheme field verification record.

[0100] After reading the firmware applicability conditions, the current firmware version in the vehicle's current configuration snapshot is used as the current state corresponding to the firmware version. A firmware matching state is then formed based on whether the current firmware version meets the firmware applicability conditions. The firmware version corresponding verification baseline state represents the configuration baseline limited by the firmware applicability conditions, the current state represents the current firmware version in the vehicle's current configuration snapshot, and the matching state represents whether the current firmware version meets the firmware applicability conditions. The control configuration scheme field verification record, along with the firmware version corresponding verification baseline state, the current state, and the matching state, are jointly written into the firmware applicability verification record, and the process continues to steps S373 and S374.

[0101] The firmware applicability verification described above differs from simply checking whether the firmware version in the vehicle delivery configuration snapshot is the same as the current firmware version. For situations where the same control configuration scheme can correspond to multiple firmware versions, the firmware version corresponding verification baseline status indicates the firmware applicability conditions associated with the control configuration scheme. A matching status is formed when the current firmware version meets the firmware applicability conditions; if the current firmware version cannot recognize or execute the relevant control configuration fields in the control configuration scheme, the current firmware version does not meet the firmware applicability conditions, thus forming a mismatch status. The firmware matching status is thus used to indicate the firmware applicability relationship between the current firmware version and the control configuration scheme, and continues to be processed in the vehicle core configuration field verification record.

[0102] Optionally, step S37 further includes: Step S373: According to the field correspondence in the firmware applicable verification record, verify the attachment installation status field with the current attachment installation status field to generate an attachment installation status field verification record that retains the firmware applicable verification record and includes the verification baseline status, current status and matching status of the attachment installation status field. Step S374: Based on the control configuration scheme field verification results, firmware applicability verification results, and accessory installation status field verification results retained in the accessory installation status field verification record, generate a vehicle core configuration field verification record containing the verification baseline status, current status, and matching status corresponding to the control configuration scheme verification value, firmware version, and accessory installation status field, respectively; the vehicle core configuration field verification record proceeds to step S38 to determine the difference fields.

[0103] Specifically, in this application, step S373 continues to use the field correspondence relationship retained in the firmware applicable verification record to read the accessory installation status field in the vehicle delivery configuration snapshot and the current accessory installation status field in the vehicle after-sales current configuration snapshot from the field correspondence relationship. The accessory installation status field serves as the verification baseline state for the accessory installation status field, and the current accessory installation status field serves as the current state. Based on whether the verification baseline state and the current state represent the same installation configuration state corresponding to the same accessory configuration item, a matching state for the accessory installation status field is formed, and the verification baseline state, the current state, and the matching state are written into the accessory installation status field verification record.

[0104] The attachment installation status field verification record also retains the firmware applicability verification record, which in turn retains the control configuration scheme field verification record. Therefore, step S374 can read the control configuration scheme field verification results corresponding to the control configuration scheme field verification record, the firmware applicability verification results corresponding to the firmware applicability verification record, and the attachment installation status field verification results corresponding to the attachment installation status field verification record from the attachment installation status field verification record. The control configuration scheme field verification results include the corresponding verification baseline status, current status, and matching status of the control configuration scheme; the firmware applicability verification results include the corresponding verification baseline status, current status, and matching status of the firmware version; and the attachment installation status field verification results include the corresponding verification baseline status, current status, and matching status of the attachment installation status field.

[0105] Step S374 writes the control configuration scheme field verification results, firmware applicability verification results, and accessory installation status field verification results into the vehicle core configuration field verification record according to the field identifiers. This ensures that the vehicle core configuration field verification record contains the corresponding verification baseline status, current status, and matching status for the control configuration scheme verification value, firmware version, and accessory installation status fields, respectively. The vehicle core configuration field verification record then proceeds to step S38, where the matching statuses corresponding to the control configuration scheme verification value, firmware version, and accessory installation status fields are used to determine candidate difference fields.

[0106] The matching status corresponding to the control configuration scheme verification value indicates whether the content of the control configuration scheme has changed; the matching status corresponding to the firmware version indicates whether the current firmware version meets the firmware applicability conditions corresponding to the control configuration scheme; the matching status corresponding to the attachment installation status field indicates whether the current attachment installation status field has changed relative to the verification benchmark state corresponding to the attachment installation status field. All three types of matching status retain their respective corresponding verification benchmark states and current states. Therefore, after determining the candidate difference field in step S38, it is possible to continue reading the verification benchmark state and current state corresponding to the candidate difference field based on the candidate difference field.

[0107] Preferably, when the current state corresponding to the accessory installation status field is the accessory installation pending confirmation state, the accessory installation pending confirmation state is not directly interpreted as an installation configuration state opposite to the verification benchmark state corresponding to the accessory installation status field. Instead, the matching state corresponding to the accessory installation status field is determined as a mismatch state, and the accessory installation pending confirmation state is retained as the current state corresponding to the accessory installation status field. This matching state and the current state are jointly entered into the vehicle core configuration field verification record, so that the accessory installation status field subsequently enters steps S38 and S42, and step S42 forms the vehicle accessory configuration status uncertainty type.

[0108] Optionally, step S34 includes: Step S341: Based on the accessory installation status field identifier in the current firmware read record of the vehicle, read the accessory status data from the accessory status source associated with the target vehicle to generate an accessory source record containing the source identifier, source read status, current control configuration scheme verification value, current firmware version and its read status; Step S342: Determine the source consistency of the same attachment installation status field based on the source identifier and corresponding attachment status data in the attachment source record, so as to generate an attachment source consistency record that retains the current control configuration scheme verification value, current firmware version, corresponding read status, source read status and source consistency determination result; continue to execute steps S343 and S344 based on the attachment source consistency record to determine the current attachment installation status and generate a snapshot of the current vehicle after-sales configuration.

[0109] Specifically, in this application, step S341 is used to continuously save the attachment status data and the corresponding source relationships when the current attachment installation status can be obtained from multiple attachment status sources. Attachment status sources may include vehicle delivery configuration records, attachment configuration data saved on the display terminal, attachment configuration data saved on the application terminal, or attachment configuration data readable by the target vehicle terminal. Each attachment status source saves a source identifier and an identifier of the attachment installation status field it can provide during pre-configuration, enabling step S341 to determine the attachment status source that can provide the attachment status data corresponding to that attachment installation status field based on the attachment installation status field identifier in the vehicle's current firmware read record.

[0110] After determining the source of the attachment status, the attachment status data is read according to the read position corresponding to each attachment status source, and a source identifier and source read status are saved for each attachment status data. The source identifier is used to indicate the attachment status source corresponding to the attachment status data, and the source read status is used to indicate whether the corresponding attachment status source has completed the attachment status data reading. The current control configuration scheme verification value, current firmware version, current control configuration scheme read status, and current firmware version read status are continued to be written into the attachment source record along with the attachment status data, source identifier, and source read status, so that the attachment status source reading process continues to retain the current control configuration scheme verification value, current firmware version, and corresponding read status required for the formation of the vehicle after-sales current configuration snapshot.

[0111] Step S342 establishes a source correspondence relationship for the attachment status data corresponding to the same attachment configuration item in the attachment source record according to the attachment installation status field identifier, and then determines the attachment status data participating in the source consistency determination based on the source read status. When the source read status corresponding to each attachment status source indicates that the attachment status data has been read completely, and each attachment status data indicates the same attachment installation status, the source consistency determination result is determined to be consistent; when the attachment status data corresponding to different attachment status sources indicate different attachment installation statuses, the source consistency determination result is determined to be conflicting; when an attachment status source that can provide the corresponding attachment installation status field fails to obtain valid attachment status data, the source consistency determination result is determined to be missing status.

[0112] The attachment source consistency record retains the current control configuration scheme verification value, current firmware version, current control configuration scheme read status, current firmware version read status, source read status, and source consistency determination result, and directly proceeds to step S343. The source consistency determination result is used in step S343 to determine the current attachment installation status. The source read status is further used to form the current attachment installation status read status, which then proceeds to step S344 to determine the vehicle after-sales configuration read status. Therefore, when multiple attachment status sources conflict or are missing, one attachment status data is not selected as the current attachment installation status before forming the source consistency determination result.

[0113] Preferably, when the attachment status sources include multiple attachment status sources capable of reading the same attachment installation status field, source validity conditions can be pre-configured for each attachment status source. Source validity conditions indicate under what source reading states the attachment status data corresponding to a given attachment status source can participate in source consistency determination. A correspondence is established between the source validity conditions and the source identifier. In step S342, it is first determined whether the attachment status source meets the source validity conditions based on the source reading state, and then the attachment status data that meets the source validity conditions is used to form the source consistency determination result. The source validity conditions are thus used to exclude attachment status data that has not been effectively read and continue to participate in the formation of the source consistency determination result.

[0114] Optionally, step S34 further includes: Step S343: Determine the current attachment installation status based on the source consistency determination result in the attachment source consistency record; when the source consistency determination result indicates a source conflict or missing status, determine the current attachment installation status as an attachment installation pending confirmation status, so as to generate a current attachment status determination record containing the current attachment installation status, the current control configuration scheme verification value, the current firmware version and each read status; Step S344: Determine the vehicle after-sales configuration reading status based on the reading status in the current attachment status determination record. Generate a snapshot of the vehicle after-sales current configuration based on the current control configuration scheme verification value, current firmware version, current attachment installation status, and vehicle after-sales configuration reading status. The vehicle after-sales current configuration snapshot proceeds to step S35 to establish a field correspondence with the vehicle delivery configuration snapshot.

[0115] Specifically, in this application, step S343 directly reads the source consistency determination result from the attachment source consistency record. When the source consistency determination result indicates source consistency, the current attachment installation status is determined based on the attachment status data corresponding to the source consistency determination result. When the source consistency determination result indicates source conflict, attachment status data is not selected from the attachment status data where a source conflict occurs as the current attachment installation status; instead, the current attachment installation status is determined as the attachment installation pending confirmation status. When the source consistency determination result indicates status is missing, the current attachment installation status is also determined as the attachment installation pending confirmation status. The attachment installation pending confirmation status is thus used to indicate that the current attachment installation status cannot yet form a consistent installation configuration status based on the attachment status source.

[0116] The current attachment status determination record saves the current attachment installation status, and continues to save the current control configuration scheme verification value, current firmware version, current control configuration scheme read status, and current firmware version read status. Based on the source consistency determination result and the source read status, it forms the current attachment installation status read status. If the source consistency determination result indicates a consistent source, the current attachment installation status read status indicates that the current attachment installation status has been formed by attachment status data that meets the source validity conditions. If the source consistency determination result indicates a source conflict or missing status, the current attachment installation status read status indicates that the current attachment installation status is in the attachment installation pending confirmation state. The current attachment installation status, current control configuration scheme verification value, current firmware version, and the above-mentioned read statuses together form the current attachment status determination record.

[0117] Step S344 determines the vehicle after-sales configuration read status based on the current control configuration scheme read status, the current firmware version read status, and the current accessory installation status read status. Then, the current control configuration scheme verification value, the current firmware version, the current accessory installation status, and the vehicle after-sales configuration read status are used together to generate a snapshot of the vehicle's current after-sales configuration. After the vehicle's current after-sales configuration snapshot proceeds to step S35, a field correspondence is established between the field identifier and the vehicle delivery configuration snapshot. The accessory installation pending confirmation status thus continues as the current status corresponding to the current accessory installation status field in step S37, and is ultimately used in step S42 to determine the uncertain type of the vehicle accessory configuration status.

[0118] In a preferred embodiment, when the current accessory installation status is "Accessory Installation Pending Confirmation," the vehicle after-sales current configuration snapshot can also retain the source consistency determination result that led to the "Accessory Installation Pending Confirmation" status. The source consistency determination result establishes a correspondence with the current accessory installation status field and continues to be used to select the corresponding configuration handling action after the vehicle accessory configuration status uncertainty type is formed. When the source consistency determination result indicates a source conflict, the configuration handling action can reread the accessory status data based on the accessory status source where the source conflict occurred; when the source consistency determination result indicates a missing status, the configuration handling action can reread the accessory status data based on the accessory status source lacking valid accessory status data. The reread accessory status data continues to enter the source consistency determination process and is used to re-determine the current accessory installation status.

[0119] Optionally, step S4 includes: Step S41: Based on the vehicle configuration consistency verification record, generate a vehicle configuration difference diagnosis diversion record that retains the above field verification information, including the vehicle configuration verification pre-state, difference field identifier, corresponding verification benchmark state, current state, and matching state. Continue to execute steps S42 and S43 based on the vehicle configuration difference diagnosis diversion record to determine the vehicle configuration diagnosis type and generate a vehicle configuration difference diagnosis handling record.

[0120] Specifically, in this application, step S41 directly uses the vehicle configuration consistency verification record as the input for vehicle configuration difference diagnosis. The vehicle configuration verification pre-state indicates whether the vehicle configuration write or after-sales configuration read corresponding to the difference field forms a field verification condition; the difference field identifier indicates the vehicle configuration field where the configuration difference occurs; the corresponding verification baseline state indicates the configuration baseline corresponding to the corresponding vehicle configuration field in the vehicle delivery configuration snapshot or firmware applicable conditions; the current state indicates the current vehicle configuration state corresponding to the corresponding vehicle configuration field in the current after-sales configuration snapshot; and the matching state indicates the matching relationship between the current state and the corresponding verification baseline state.

[0121] When generating a vehicle configuration difference diagnosis routing record, the vehicle configuration verification pre-verification status, corresponding verification baseline status, current status, and matching status corresponding to the same difference field are associated according to the difference field identifier, and the above field verification information is written into the vehicle configuration difference diagnosis routing record. Each difference field in the vehicle configuration difference diagnosis routing record is thus associated with the vehicle configuration verification pre-verification status, corresponding verification baseline status, current status, and matching status, enabling step S42 to determine the vehicle configuration diagnosis type according to the field verification information corresponding to each difference field.

[0122] After the vehicle configuration difference diagnosis triage record is formed, it directly proceeds to step S42. Step S42 determines the vehicle configuration diagnosis type based on the vehicle configuration verification pre-state and matching state corresponding to the difference field, and then the vehicle configuration diagnosis type, the corresponding difference field, the corresponding verification benchmark state, and the current state are combined to proceed to step S43. Therefore, the vehicle configuration difference diagnosis processing record formed in step S43 can continue to retain the corresponding difference field that generated the corresponding vehicle configuration diagnosis type, as well as its corresponding verification benchmark state and current state.

[0123] Optionally, step S4 further includes: Step S42: Determine the vehicle configuration diagnosis type corresponding to the difference field based on the vehicle configuration difference diagnosis diversion record: when the vehicle configuration verification pre-state indicates an abnormal write result field or vehicle after-sales configuration read state, it is determined to be a vehicle configuration write / read abnormal type; when the control configuration scheme verification value has a difference that is not interpreted by the vehicle authorized configuration change record, it is determined to be a vehicle control configuration drift type; when the firmware version field's matching state indicates a mismatch, it is determined to be a vehicle firmware configuration mismatch type; when the accessory installation status field's matching state indicates a mismatch, it is determined to be a vehicle accessory configuration status uncertain type, so as to generate a vehicle configuration difference diagnosis type record that associates the vehicle configuration diagnosis type, difference field, corresponding verification benchmark state, and current state; Step S43: Determine the corresponding handling direction based on the vehicle configuration diagnosis type, corresponding difference field, corresponding verification benchmark status and current status in the vehicle configuration difference diagnosis type record, so as to generate a vehicle configuration difference diagnosis and handling record that retains the vehicle configuration diagnosis type, corresponding difference field, corresponding verification benchmark status and current status; the vehicle configuration difference diagnosis and handling record enters the configuration review process in step S4.

[0124] Specifically, in this application, step S42 determines the vehicle configuration diagnostic type based on the cause of the difference field formation and the matching status corresponding to the difference field. The "Vehicle Configuration Write / Read Anomaly" type indicates that the difference field has not yet formed a vehicle configuration write state or vehicle after-sales configuration read state capable of normal field content verification. The "Vehicle Control Configuration Drift" type indicates that the current state corresponding to the control configuration scheme verification value differs from the corresponding verification baseline state, and this difference remains an unexplained difference field after steps S383 and S384. The "Vehicle Firmware Configuration Mismatch" type indicates that the current firmware version does not meet the firmware applicability conditions corresponding to the control configuration scheme verification value. The "Vehicle Accessory Configuration Status Uncertainty" type indicates that the matching status corresponding to the accessory installation status field is a mismatch, including situations where the current accessory installation status differs from the verification baseline state corresponding to the accessory installation status field, and where the current accessory installation status is an accessory installation pending confirmation state.

[0125] After determining the vehicle configuration diagnostic type, a correspondence is established between the vehicle configuration diagnostic type and the corresponding difference field, corresponding verification baseline state, and current state that generated the vehicle configuration diagnostic type, to generate a vehicle configuration difference diagnostic type record. The corresponding verification baseline state and current state in the vehicle configuration difference diagnostic type record continue to step S43, which is used to determine the configuration handling action and the applicable conditions for the configuration handling action. Therefore, when the same vehicle configuration diagnostic type corresponds to multiple corresponding difference fields, each corresponding difference field still retains its own corresponding verification baseline state and current state.

[0126] Step S43 determines the corresponding handling direction based on the vehicle configuration difference diagnosis type record. The handling direction corresponding to the vehicle configuration write / read anomaly type is used to re-establish a vehicle configuration write state or vehicle after-sales configuration read state that can be validated by field verification; the handling direction corresponding to the vehicle control configuration drift type is used to convert the current state of the corresponding difference field to the configuration state corresponding to the verification benchmark state; the handling direction corresponding to the vehicle firmware configuration mismatch type is used to make the current firmware version meet the firmware applicability conditions; the handling direction corresponding to the vehicle accessory configuration status uncertainty type is used to re-establish the current accessory installation state that can be validated by accessory installation status field verification. The above corresponding handling directions are further converted into configuration handling actions, applicable conditions for configuration handling actions, and target configuration states through steps S431 and S432.

[0127] The vehicle configuration difference diagnosis and handling record saves the vehicle configuration diagnosis type, corresponding difference fields, corresponding verification benchmark status, and current status, and continues into the configuration review process. The corresponding difference fields in the vehicle configuration difference diagnosis and handling record are used to determine the vehicle configuration fields that need to be reviewed subsequently. The corresponding verification benchmark status is used to form the configuration review benchmark record. The current status is used in steps S431 and S432 to determine the applicable status of the configuration handling action, thereby ensuring that the vehicle configuration difference diagnosis and configuration review maintain a continuous relationship between the same vehicle configuration fields.

[0128] Optionally, step S39 includes: Step S391: Verify whether the control configuration scheme verification value, firmware version and accessory installation status fields have corresponding verification benchmark status and current status according to the vehicle configuration field difference record, so as to generate a vehicle configuration verification field integrity record that retains the vehicle configuration field difference record and contains the integrity judgment results of each field. Step S392: Determine the configuration fields that can be verified and those that have not been verified based on the integrity judgment results of each field in the vehicle configuration verification field integrity record, so as to generate a vehicle configuration field integrity classification record that retains the vehicle configuration verification field integrity record and marks the two types of configuration fields; continue to execute steps S393 and S394 based on the vehicle configuration field integrity classification record to form a vehicle configuration consistency verification record.

[0129] Specifically, in this application, step S391 is used to prevent vehicle configuration fields lacking corresponding verification baseline states or current states from directly entering the field content matching judgment. For control configuration scheme verification values, it verifies whether the vehicle configuration field difference record simultaneously contains the verification baseline state corresponding to the control configuration scheme and the current state corresponding to the current control configuration scheme verification value; for firmware versions, it verifies whether the vehicle configuration field difference record simultaneously contains the verification baseline state corresponding to the firmware version and the current state corresponding to the current firmware version; for accessory installation status fields, it verifies whether the vehicle configuration field difference record simultaneously contains the verification baseline state corresponding to the accessory installation status field and the current state corresponding to the current accessory installation status field. After each vehicle configuration field completes the above verification, a corresponding field integrity judgment result is formed.

[0130] The vehicle configuration verification field integrity record retains records of differences in vehicle configuration fields and saves the field integrity judgment results according to the vehicle configuration fields. The field integrity judgment results are used to indicate whether the corresponding vehicle configuration field has the corresponding verification benchmark state and current state required to form a matching state. Step S392 distinguishes the vehicle configuration fields into configuration fields that can be verified and configuration fields that have not been verified based on the field integrity judgment results. Configuration fields that can be verified continue to retain the already formed matching state, while configuration fields that have not been verified continue to retain the field integrity judgment results that are missing the corresponding verification benchmark state or current state.

[0131] The vehicle configuration field integrity classification record simultaneously stores both configuration fields that can be verified and those that cannot. It also retains the vehicle configuration verification field integrity record, enabling step S393 to determine the corresponding matching status for configuration fields that can be verified and to determine a field insufficiency status for those that cannot be verified. Therefore, incomplete field data is not converted into a configuration content mismatch status, but rather forms a field insufficiency status that can be distinguished from the differences in configuration content, and continues to be processed in the vehicle configuration consistency verification record.

[0132] Optionally, step S39 further includes: Step S393: Determine the corresponding matching status based on the configuration fields that can be verified in the vehicle configuration field integrity classification record, and determine the field insufficiency status based on the configuration fields that have not been verified, so as to generate a vehicle configuration field integrity judgment record containing the configuration fields that can be verified and their matching status, the configuration fields that have not been verified and their field insufficiency status. Step S394: Generate a vehicle configuration consistency verification record based on the matching status and field insufficiency status in the vehicle configuration field integrity determination record. The vehicle configuration consistency verification record retains the vehicle configuration field difference record and marks the matching status corresponding to the configuration fields that can be verified and the field insufficiency status corresponding to the configuration fields that cannot be verified.

[0133] Specifically, in this application, step S393 reads the configuration fields that can be verified from the vehicle configuration field integrity classification record, and continues to use the matching state already formed in step S37 for the configuration fields that can be verified; for configuration fields that cannot be verified, a field insufficiency state is formed based on the field integrity judgment result of the missing corresponding verification benchmark state or the current state. The field insufficiency state is used to indicate that the corresponding vehicle configuration field cannot currently complete the field matching verification between the corresponding verification benchmark state and the current state, and does not indicate that the current state of the corresponding vehicle configuration field is different from the corresponding verification benchmark state.

[0134] Subsequently, the configuration fields that can be validated and their matching status, as well as the configuration fields that cannot be validated and their insufficient status, are written together into the vehicle configuration field integrity determination record. The vehicle configuration field integrity determination record retains the results of the fields that have been validated, while allowing the configuration fields that cannot be validated to continue to step S394 through the insufficient status.

[0135] Step S394 generates a vehicle configuration consistency verification record based on the vehicle configuration field integrity determination record. The vehicle configuration consistency verification record continues to retain vehicle configuration field difference records, saving the corresponding matching status for configuration fields that can complete verification, and saving the corresponding field insufficiency status for configuration fields that cannot complete verification. After the vehicle configuration consistency verification record enters step S41, the field insufficiency status continues to enter the vehicle configuration difference diagnosis diversion record through the vehicle configuration verification pre-state, thereby forming a vehicle configuration write / read exception type in step S42, without being confused with vehicle control configuration drift type, vehicle firmware configuration mismatch type, or vehicle accessory configuration status uncertainty type.

[0136] Preferably, when both verifiable and non-verifiable configuration fields exist on the same target vehicle, the vehicle configuration consistency verification record retains both the matching status of the verifiable configuration fields and the insufficient status of the non-verifiable configuration fields. Verifiable configuration fields that have already formed a mismatch status continue to the corresponding vehicle configuration diagnostic type formation process, while non-verifiable configuration fields enter the vehicle configuration write / read anomaly type formation process. This ensures that a single non-verifiable configuration field does not prevent other verifiable configuration fields from continuing vehicle configuration difference diagnosis.

[0137] Optionally, step S42 includes: Step S421: Determine the candidate diagnosis type based on the difference fields and their matching status in the vehicle configuration difference diagnosis diversion record, so as to generate a vehicle configuration candidate diagnosis record that is associated with the candidate diagnosis type, difference fields, corresponding verification benchmark status and current status. Step S422: When the vehicle configuration candidate diagnostic record contains only one candidate diagnostic type, the candidate diagnostic type is determined as the main configuration diagnostic type to generate a vehicle configuration diagnostic order record that retains the corresponding difference field, the corresponding verification benchmark state, and the current state. The vehicle configuration diagnostic order record proceeds to step S424. When multiple candidate diagnostic types are included, the pre-stored diagnostic priority order is read to generate a diagnostic priority order record that includes the candidate diagnostic type, the corresponding difference field, the corresponding verification benchmark state, the current state, and the diagnostic priority order. The diagnostic priority order record proceeds to step S423.

[0138] Specifically, in this application, the candidate diagnostic type is formed from the vehicle configuration diagnostic type determined in step S42. Step S421 determines the candidate diagnostic type according to the vehicle configuration verification pre-state and matching state corresponding to each difference field in the vehicle configuration difference diagnostic diversion record, and then generates a vehicle configuration candidate diagnostic record by combining the candidate diagnostic type with the corresponding difference field that generated the candidate diagnostic type, the corresponding verification baseline state, and the current state. The vehicle configuration candidate diagnostic record thus not only stores the candidate diagnostic type, but also continues to store the corresponding difference field, the corresponding verification baseline state, and the current state required by steps S431 and S432 to determine the applicable state of the configuration handling action.

[0139] Step S422 first determines the number of candidate diagnostic types in the vehicle configuration candidate diagnostic record. When the vehicle configuration candidate diagnostic record contains only one candidate diagnostic type, that candidate diagnostic type is determined as the primary configuration diagnostic type, and a vehicle configuration diagnostic order record is generated by combining the primary configuration diagnostic type, the corresponding difference field, the corresponding verification baseline state, and the current state. The vehicle configuration diagnostic order record directly proceeds to step S424, thus preventing the introduction of a diagnostic priority order when only one candidate diagnostic type exists.

[0140] When a vehicle configuration candidate diagnostic record contains multiple candidate diagnostic types, the pre-stored diagnostic priority order is read. This priority order is predetermined when configuring the vehicle configuration diagnostic processing relationship, based on the dependency relationship between different vehicle configuration diagnostic types on the subsequent interpretation of vehicle configuration status. In one embodiment, the diagnostic priority order sequentially includes vehicle configuration write / read anomaly types, vehicle firmware configuration mismatch types, vehicle control configuration drift types, and vehicle accessory configuration status uncertainty types. The vehicle configuration write / read anomaly type is first used to distinguish whether the vehicle configuration field has a valid vehicle configuration write status or a vehicle aftermarket configuration read status; after the vehicle configuration field can be verified, the vehicle firmware configuration mismatch type is determined based on the firmware applicability conditions; subsequently, the vehicle control configuration drift type is determined based on the vehicle authorized configuration change record; and the matching status corresponding to the accessory installation status field is used to determine the vehicle accessory configuration status uncertainty type.

[0141] The diagnostic priority order, along with the candidate diagnostic types, corresponding difference fields, corresponding verification baseline states, and the current state, generates a diagnostic priority order record. This record then proceeds to step S423, where the primary configuration diagnostic type and secondary configuration diagnostic type are determined according to the diagnostic priority order. This diagnostic priority order is thus only used to determine the processing order among vehicle configuration diagnostic types when multiple candidate diagnostic types exist simultaneously; it does not change the corresponding difference fields, corresponding verification baseline states, or the current state for each candidate diagnostic type.

[0142] Optionally, step S42 further includes: Step S423: When a diagnostic priority order record exists, the candidate diagnostic types are matched sequentially according to the diagnostic priority order record. The first matching type is determined as the primary configuration diagnostic type, and the remaining matching types are determined as secondary configuration diagnostic types, so as to generate a vehicle configuration diagnostic order record that retains the corresponding difference fields, corresponding verification benchmark status and current status of each diagnostic type. Step S424: Generate a vehicle configuration difference diagnosis type record based on the vehicle configuration diagnosis sequence record, which includes the main configuration diagnosis type, the existing secondary configuration diagnosis types, their respective corresponding difference fields, the corresponding verification benchmark status, and the current status; the vehicle configuration difference diagnosis type record proceeds to step S43 to determine the configuration handling action.

[0143] Specifically, in this application, step S423 reads candidate diagnostic types sequentially according to the diagnostic priority order in the diagnostic priority order record. The first matched candidate diagnostic type is determined as the primary configuration diagnostic type, and the corresponding difference field, corresponding verification baseline state, and current state of the primary configuration diagnostic type remain associated. The remaining candidate diagnostic types are sequentially determined as secondary configuration diagnostic types, and their corresponding difference fields, corresponding verification baseline states, and current states are retained respectively. The primary configuration diagnostic type, secondary configuration diagnostic type, and their respective corresponding difference fields, corresponding verification baseline states, and current states together generate the vehicle configuration diagnostic order record.

[0144] The primary configuration diagnostic type is used to determine the primary configuration disposal candidate record first formed in step S431, and the secondary configuration diagnostic type is used to form the secondary configuration disposal candidate record corresponding to step S432. The secondary configuration diagnostic type is not deleted because the primary configuration diagnostic type exists, but continues to steps S424 and S43, so that step S43 can read the corresponding configuration disposal action, the applicable conditions of the configuration disposal action, and the target configuration status according to the primary configuration diagnostic type and the existing secondary configuration diagnostic type, respectively.

[0145] Step S424 generates a vehicle configuration difference diagnosis type record based on the vehicle configuration diagnosis sequence record. The vehicle configuration difference diagnosis type record at least stores the primary configuration diagnosis type, its corresponding difference field, corresponding verification baseline status, and current status; if secondary configuration diagnosis types exist, it also stores the secondary configuration diagnosis type, its corresponding difference field, corresponding verification baseline status, and current status for each secondary configuration diagnosis type. The vehicle configuration difference diagnosis type record directly proceeds to step S43, enabling the configuration handling action to be determined based on the actual vehicle configuration field status of the corresponding vehicle configuration diagnosis type.

[0146] Furthermore, when multiple sub-configuration diagnostic types correspond to different corresponding difference fields, the sub-configuration diagnostic types retain their order relationship according to their diagnostic priority. This order relationship proceeds to step S432, causing each sub-configuration diagnostic type to sequentially generate its corresponding sub-configuration handling candidate record. Thus, the configuration handling actions corresponding to multiple sub-configuration diagnostic types can proceed to step S433 and coordinate with the configuration handling actions in the main configuration handling candidate record for configuration handling coordination.

[0147] Optionally, step S43 includes: Step S431: Based on the main configuration diagnosis type, corresponding difference field, corresponding verification baseline status and current status in the vehicle configuration difference diagnosis type record, read the configuration handling action, the applicable conditions of the configuration handling action and the target configuration status corresponding to the configuration handling action, and determine the applicable status of the configuration handling action based on the corresponding verification baseline status and current status, so as to generate a main configuration handling candidate record containing the main configuration diagnosis type, corresponding difference field, configuration handling action, target configuration status and applicable status of the configuration handling action; Step S432: When a secondary configuration diagnosis type exists, read the configuration handling action, applicable conditions of the configuration handling action, and target configuration status corresponding to the configuration handling action based on the secondary configuration diagnosis type, corresponding difference field, corresponding verification baseline status, and current status. Determine the applicable status of the configuration handling action based on the corresponding verification baseline status and current status to generate a secondary configuration handling candidate record containing the secondary configuration diagnosis type, corresponding difference field, configuration handling action, target configuration status, and applicable status of the configuration handling action. The primary configuration handling candidate record and the existing secondary configuration handling candidate record proceed to step S433 for configuration handling coordination.

[0148] Specifically, in this application, the configuration handling action, the applicable conditions for the configuration handling action, and the target configuration state are pre-configured according to the vehicle configuration diagnosis type, and a correspondence is established between the vehicle configuration diagnosis type and the configuration handling action, the applicable conditions for the configuration handling action, and the target configuration state. The configuration handling action is used to represent the vehicle configuration handling content that needs to be performed for the corresponding difference field; the applicable conditions for the configuration handling action are used to restrict the configuration handling action to only form an applicable configuration handling action state when the current state and the corresponding verification benchmark state meet the conditions of the corresponding field; the target configuration state is used to represent the vehicle configuration state that the corresponding difference field needs to reach after the configuration handling action is completed.

[0149] For vehicle configuration write / read anomalies, the handling action can be to reread the corresponding vehicle configuration field or re-execute the vehicle configuration write related to the corresponding difference field. The applicable conditions for the handling action are determined based on the write result field and the vehicle after-sales configuration read status. The target configuration status corresponds to the vehicle configuration status that can form a valid field read result. For vehicle control configuration drift, the handling action can be to restore the control configuration status that matches the corresponding verification benchmark status or rewrite the corresponding control configuration field. The applicable conditions for the handling action are determined based on the difference relationship between the current status corresponding to the unexplained difference field and the corresponding verification benchmark status. The target configuration status establishes a correspondence with the corresponding verification benchmark status. For vehicle firmware configuration mismatch, the handling action can be to make the current firmware version meet the firmware applicability conditions. The applicable conditions for the handling action are determined based on the matching status between the current firmware version and the firmware applicability conditions. The target configuration status corresponds to the firmware version status that meets the firmware applicability conditions. For vehicle accessory configuration status uncertainty, the handling action can be to reread the current accessory installation status or re-form the source consistency judgment result. The applicable conditions for the handling action are determined based on the matching status corresponding to the accessory installation status field and the accessory installation pending confirmation status. The target configuration status corresponds to the current accessory installation status that can participate in the accessory installation status field verification again.

[0150] Step S431 reads the corresponding configuration handling action, applicable conditions for the configuration handling action, and target configuration status according to the main configuration diagnosis type. Then, based on the corresponding verification benchmark status and the current status corresponding to the main configuration diagnosis type, it determines whether the configuration handling action meets the applicable conditions for the configuration handling action, thus forming the applicable status of the configuration handling action. The main configuration diagnosis type, corresponding difference field, configuration handling action, target configuration status, and applicable status of the configuration handling action together generate the main configuration handling candidate record.

[0151] When a sub-configuration diagnostic type exists, step S432 processes each sub-configuration diagnostic type according to the same vehicle configuration diagnostic type correspondence. For each sub-configuration diagnostic type, the corresponding configuration action, applicable conditions for the configuration action, and target configuration status are read, and an applicable status for the configuration action is formed based on the corresponding verification baseline status and the current status of the sub-configuration diagnostic type. The sub-configuration diagnostic type, corresponding difference field, configuration action, target configuration status, and applicable status for the configuration action are used to generate a sub-configuration disposal candidate record. The primary configuration disposal candidate record and the existing sub-configuration disposal candidate records then proceed to step S433.

[0152] Preferably, the configuration handling action does not directly proceed to subsequent vehicle configuration field reading simply because a vehicle configuration diagnostic type is generated. The applicable status of the configuration handling action indicates whether the configuration handling action can proceed to step S433 for configuration handling coordination. Step S433 only performs target configuration status conflict determination for configuration handling actions whose applicable status is applicable. Thus, the vehicle configuration diagnostic type, the corresponding verification baseline status, and the current status jointly restrict the conditions for a configuration handling action to proceed to subsequent configuration handling coordination.

[0153] Optionally, step S43 further includes: Step S433: Based on the main configuration disposal candidate record and the existing secondary configuration disposal candidate record, determine whether the target configuration status of the configuration disposal action is applicable and its target configuration status, and generate a configuration disposal coordination record containing the configuration disposal action, target configuration status, corresponding difference field and corresponding verification benchmark status. Step S434: Based on the configuration handling coordination record, retain the configuration handling actions for which there is no conflict in the target configuration state, and determine the configuration handling actions for which there is a conflict in the target configuration state as manual review handling actions, so as to generate a vehicle configuration difference diagnosis and handling record containing conflict-free configuration handling actions, manual review handling actions, corresponding difference fields and corresponding verification benchmark states.

[0154] Specifically, in this application, step S433 first determines the applicable configuration handling action from the primary configuration handling candidate record and the existing secondary configuration handling candidate record, and then determines the vehicle configuration field that the configuration handling action actually acts on based on the corresponding difference field corresponding to the configuration handling action. For configuration handling actions that act on different vehicle configuration fields and there is no field constraint relationship between the target configuration states, the target configuration state is determined to be conflict-free; for multiple configuration handling actions that act on the same vehicle configuration field, it is determined whether the target configuration states corresponding to each configuration handling action can be established simultaneously; for configuration handling actions that act on vehicle configuration fields that have firmware applicability relationships or control configuration field association relationships, it is determined whether each target configuration state can be established simultaneously based on the aforementioned firmware applicability conditions and field identifier correspondence.

[0155] For example, if one configuration action targets a configuration state that requires the current firmware version to meet firmware applicability conditions, and another configuration action targets a configuration state that requires the control configuration state corresponding to the control configuration scheme verification value to meet the corresponding verification baseline state, then if the current firmware version can identify and execute the corresponding control configuration field after meeting firmware applicability conditions, the two target configuration states are determined to be conflict-free. However, if two configuration actions result in target configuration states that cannot be simultaneously established for the same control configuration field, then the two target configuration states are determined to be conflict-free. The above conflict determination directly uses the configuration action, target configuration state, corresponding difference field, and corresponding verification baseline state, and the target configuration state conflict determination result is then written into the configuration action coordination record.

[0156] Based on the aforementioned target configuration status conflict determination results, a configuration handling coordination record is generated. The configuration handling coordination record saves the target configuration status, corresponding difference fields, corresponding verification benchmark status, and target configuration status conflict determination results according to the configuration handling actions. After reading the configuration handling coordination record in step S434, configuration handling actions indicating no conflict are retained according to the target configuration status conflict determination results, forming conflict-free configuration handling actions; for configuration handling actions indicating a conflict, the configuration handling actions are designated as manual review handling actions. Conflict-free configuration handling actions, manual review handling actions, corresponding difference fields, and corresponding verification benchmark statuses together generate a vehicle configuration difference diagnosis and handling record.

[0157] After the vehicle configuration discrepancy diagnosis and handling record is formed, the corresponding discrepancy fields are used in step S44 to determine the vehicle configuration fields that need to be reviewed, and the corresponding verification benchmark status is used to form the configuration review benchmark record. Conflict-free configuration handling actions and manual review handling actions correspond to handling statuses, and the handling statuses continue to step S45. Therefore, both the conflict-free configuration handling actions and the manual review handling actions formed from the configuration handling coordination record continue to participate in the subsequent configuration review process.

[0158] In a preferred embodiment, for configuration handling actions indicating a conflict in the target configuration state conflict determination result, the manual review handling action does not change the corresponding difference field and the corresponding verification benchmark state; it only changes the way the corresponding configuration handling action enters the subsequent handling process. After the handling state corresponding to the manual review handling action is handled, steps S44 to S48 still perform configuration review according to the original corresponding difference field and the corresponding verification benchmark state, thus ensuring that the previously formed field correspondence is not changed due to the conversion of the configuration handling action to a manual review handling action.

[0159] Optionally, step S4 further includes: Step S44: Based on the conflict-free configuration handling actions, manual review handling actions and their corresponding difference fields in the vehicle configuration difference diagnosis and handling record, determine the vehicle configuration fields that need to be reviewed. Establish the correspondence between the vehicle configuration fields and the corresponding verification benchmark status as needed to establish the review field correspondence between the vehicle configuration fields and the verification benchmark status, so as to generate a configuration review benchmark record containing the vehicle configuration fields that need to be reviewed, the corresponding verification benchmark status and the review field correspondence. Step S45: Obtain the processing status of the vehicle configuration difference diagnosis and processing record, and generate a configuration review preparation record based on the processing status and configuration review benchmark record. The configuration review preparation record contains the processing status, the vehicle configuration fields that need to be reviewed, the corresponding verification benchmark status, and the correspondence between the review fields. The correspondence between the review fields in the configuration review preparation record is used to determine the corresponding vehicle configuration fields that need to be read in the target vehicle.

[0160] Specifically, in this application, step S44 reads the corresponding difference fields corresponding to the conflict-free configuration handling actions and manual review handling actions in the vehicle configuration difference diagnosis and handling record, respectively. The corresponding difference field represents the vehicle configuration field in the preceding vehicle configuration consistency verification record where a configuration difference actually occurred and underwent vehicle configuration difference diagnosis. Therefore, the corresponding difference field is determined as the vehicle configuration field that needs to be reviewed. For cases where the same vehicle configuration field corresponds to multiple configuration handling actions, only one vehicle configuration field that needs to be reviewed is retained, and the corresponding verification benchmark state corresponding to the vehicle configuration field that needs to be reviewed is continued to be associated.

[0161] When establishing the mapping relationship between verification fields, each vehicle configuration field requiring verification is mapped to its corresponding verification benchmark status according to the field identifier. For example, the vehicle configuration field requiring verification corresponding to the control configuration scheme verification value is mapped to the corresponding verification benchmark status of the control configuration scheme; the vehicle configuration field requiring verification corresponding to the firmware version is mapped to the corresponding verification benchmark status of the firmware version; and the vehicle configuration field requiring verification corresponding to the accessory installation status is mapped to the corresponding verification benchmark status of the accessory installation status. The vehicle configuration fields requiring verification, the corresponding verification benchmark status, and the mapping relationship between verification fields together generate a configuration verification benchmark record.

[0162] The firmware version corresponding verification benchmark state is formed according to the aforementioned step S372. When the vehicle firmware configuration mismatch type stems from the current firmware version not meeting the firmware applicability conditions, the firmware version corresponding verification benchmark state represents the configuration benchmark limited by the firmware applicability conditions. Therefore, subsequent configuration review forms a matching result based on whether the processed current firmware version meets the firmware version corresponding verification benchmark state. The vehicle configuration fields that need to be reviewed corresponding to the control configuration scheme verification value continue to use the control configuration scheme corresponding verification benchmark state; the vehicle configuration fields that need to be reviewed corresponding to the accessory installation status field continue to use the accessory installation status field corresponding verification benchmark state.

[0163] Step S45 retrieves the processing status from the vehicle configuration difference diagnosis and processing record. For conflict-free configuration processing actions, the processing status indicates whether the action has been executed to the point where configuration review can proceed; for manual review processing actions, the processing status indicates whether the action has been executed to the point where configuration review can proceed. The processing status and the configuration review baseline record are combined to generate a configuration review preparation record, ensuring that the configuration review preparation record simultaneously includes the processing status, the vehicle configuration field to be reviewed, the corresponding verification baseline status, and the correspondence between the review fields.

[0164] After the configuration review preparation record is formed, the correspondence between review fields is directly used in step S46 to determine the corresponding vehicle configuration fields that need to be reread from the target vehicle. Only vehicle configuration fields that require review and whose handling status indicates that the handling is complete are included in step S46; vehicle configuration fields that require review and whose handling status does not yet indicate that the handling is complete remain in the configuration review preparation record and are not generated in advance as configuration review snapshots. Thus, the handling status and the correspondence between review fields jointly limit the vehicle configuration fields to be read in step S46.

[0165] Preferably, when there are multiple conflict-free configuration handling actions or manual review handling actions in the vehicle configuration difference diagnosis and handling record, the handling status can be saved separately according to the corresponding difference fields. The corresponding difference fields that already have a handling status indicating completion enter the configuration review process, while the corresponding difference fields whose handling status does not yet indicate completion remain in the configuration review preparation record. The configuration review preparation record saves the handling status according to the corresponding difference fields, ensuring that if one of the multiple configuration handling actions is not yet completed, it does not affect the entry of the corresponding difference fields whose handling status indicates completion into the configuration review process.

[0166] Optionally, step S4 further includes: Step S46: When the processing status in the configuration review preparation record indicates that the processing is completed, read the vehicle configuration fields that need to be reviewed from the target vehicle according to the review field correspondence in the configuration review preparation record, so as to generate a configuration review snapshot containing the read vehicle configuration fields, the corresponding verification benchmark status and the review field correspondence. Step S47: Based on the correspondence of the review fields in the configuration review snapshot, verify the read vehicle configuration fields with the corresponding verification benchmark status field by field to generate a configuration review verification record containing the matching results of each vehicle configuration field with the corresponding verification benchmark status. Step S48: Based on the matching results in the configuration review and verification record, mark the vehicle configuration fields that have reached the corresponding verification benchmark state as the processing completed field, and mark the vehicle configuration fields that have not reached the corresponding verification benchmark state as the continuing diagnosis field, so as to generate a vehicle configuration processing post-review record containing the processing completed field and the continuing diagnosis field.

[0167] Specifically, in this application, step S46 first reads the processing status in the configuration review preparation record and determines the vehicle configuration fields that need to be reviewed, indicating that the processing is complete. Then, according to the correspondence between the review fields, it reads the field identifiers corresponding to each vehicle configuration field that needs review, and rereads the corresponding vehicle configuration fields from the same target vehicle end associated with the vehicle delivery configuration snapshot and the vehicle after-sales current configuration snapshot based on the field identifiers. Therefore, this configuration review reading still targets the same target vehicle end and the same vehicle configuration fields for which the differences were determined in step S3 and have undergone vehicle configuration difference diagnosis and processing.

[0168] For vehicle configuration fields requiring verification corresponding to the control configuration scheme verification value, the processed control configuration scheme verification value is formed using the same field identifier order and verification code as in the vehicle delivery configuration readback stage and the vehicle after-sales current configuration read stage. For vehicle configuration fields requiring verification corresponding to the firmware version, the processed current firmware version is read. For vehicle configuration fields requiring verification corresponding to the accessory installation status field, the processed current accessory installation status is formed using the aforementioned accessory status source reading method. The processed control configuration scheme verification value, the processed current firmware version, or the processed current accessory installation status are used as the read vehicle configuration fields, and together with the corresponding verification baseline status and verification field correspondence, a configuration verification snapshot is generated.

[0169] The configuration review snapshot contains vehicle configuration fields that correspond to the previously identified difference fields and whose processing status indicates that processing has been completed. Each vehicle configuration field in the configuration review snapshot is further associated with the corresponding difference field and the corresponding verification baseline status in the vehicle configuration consistency verification record through the review field mapping relationship. The configuration review snapshot then directly proceeds to step S47 without re-establishing another set of vehicle configuration field mapping relationships.

[0170] Step S47 reads the vehicle configuration fields and their corresponding verification benchmark states field by field according to the correspondence of the verification fields in the configuration verification snapshot, and then forms a matching result according to the field verification method used in step S37 for the corresponding vehicle configuration fields. For the control configuration scheme verification value, the processed control configuration scheme verification value is matched with the corresponding verification benchmark state of the control configuration scheme; for the firmware version, a matching result is formed based on whether the processed current firmware version reaches the corresponding verification benchmark state of the firmware version; for the accessory installation status field, the processed current accessory installation status is matched with the corresponding verification benchmark state of the accessory installation status field.

[0171] After each vehicle configuration field has undergone configuration verification, the vehicle configuration field, the corresponding verification benchmark status, and the matching result are written together into the configuration verification record. The configuration verification record directly indicates whether the processed vehicle configuration field has reached the corresponding verification benchmark status on which the vehicle configuration difference diagnosis is based, and then proceeds to step S48.

[0172] Step S48 marks the vehicle configuration fields with status based on the matching results in the configuration review and verification record. If the matching result indicates that the vehicle configuration field has reached the corresponding verification baseline status, the vehicle configuration field is marked as a "processing completed" field; if the matching result indicates that the vehicle configuration field has not yet reached the corresponding verification baseline status, the vehicle configuration field is marked as a "continue diagnosis" field. Both the "processing completed" field and the "continue diagnosis" field retain the field identifier corresponding to the original vehicle configuration field, enabling the "processing completed" field to trace back to the corresponding difference field that has already completed configuration review, and allowing the "continue diagnosis" field to continue entering the vehicle configuration difference diagnosis process.

[0173] A post-processing review record for vehicle configuration is generated based on the "Processing Completed" and "Continue Diagnosis" fields. This record stores at least the "Processing Completed" and "Continue Diagnosis" fields, along with their respective matching results. When a "Continue Diagnosis" field exists in the post-processing review record, the matching result from the configuration review verification record is read based on the field identifier of that field, and the "Continue Diagnosis" field is used as a new difference field in subsequent vehicle configuration difference diagnoses. When all vehicle configuration fields requiring review have become "Processing Completed" fields, the post-processing review record indicates that all vehicle configuration fields requiring review have reached their respective verification benchmark states.

[0174] In a preferred embodiment, the vehicle configuration post-processing review record may also store review time information corresponding to the configuration review snapshot. The review time information is obtained when the configuration review snapshot is generated and is stored together with the processing completion field and the continue diagnostics field. The review time information is used to distinguish different vehicle configuration post-processing review records formed after multiple configuration processes for the same difference field. When the continue diagnostics field re-enters vehicle configuration difference diagnosis and completes subsequent configuration processing, a new vehicle configuration post-processing review record is generated based on the new configuration review snapshot, and different vehicle configuration post-processing review records are distinguished based on the new review time information, enabling the configuration status of the same vehicle configuration field in the continuous configuration processing process to be traced in chronological order.

[0175] Furthermore, in one embodiment, the configuration review snapshot and the vehicle delivery configuration snapshot use the same field identifier structure, and the vehicle after-sales current configuration snapshot also uses the same field identifier structure. The vehicle delivery configuration snapshot provides the corresponding verification baseline state, the vehicle after-sales current configuration snapshot provides the current state before processing, and the configuration review snapshot provides the vehicle configuration fields reread after processing. All of the above vehicle configuration snapshots establish a field correspondence based on the same field identifier, enabling the post-processing review record to reflect the continuous state changes of the same vehicle configuration field from the vehicle delivery configuration snapshot, the vehicle after-sales current configuration snapshot to the configuration review snapshot.

[0176] Preferably, for the vehicle configuration difference explanation, vehicle configuration diagnosis type determination, configuration handling coordination, and configuration review processes formed in steps S383 to S48, the field correspondence established in step S35 and the subsequently formed difference field identifiers continue to be used, without re-establishing configuration field correspondences with different meanings in each processing stage. The difference field identifiers in the vehicle configuration field difference record continue to enter the vehicle configuration difference diagnosis triage record, the corresponding difference fields in the vehicle configuration difference diagnosis type record continue to enter the vehicle configuration difference diagnosis handling record, the corresponding difference fields in the vehicle configuration difference diagnosis handling record continue to form the vehicle configuration fields that need to be reviewed, and the review field correspondence in the configuration review benchmark record is finally used for field-by-field verification of the configuration review snapshot. Through the above continuous field transmission relationship, the vehicle configuration fields used in each processing stage can always be traced back to the same vehicle configuration field corresponding to the difference fields formed in step S3.

[0177] In a preferred embodiment, when differences in control configuration scheme verification values, firmware versions, and accessory installation status fields coexist, the following steps are taken: First, the vehicle configuration field is checked against the vehicle configuration verification prerequisite status to determine if it meets the verification conditions. Then, the firmware version is checked against the firmware applicability conditions to determine if it is compatible with the control configuration scheme. Next, the vehicle authorized configuration change record is used to determine if the candidate difference field corresponding to the control configuration scheme verification value can be interpreted by the vehicle authorized configuration change record. Finally, the vehicle accessory configuration status uncertainty type is determined based on the matching status corresponding to the accessory installation status field. The above processing order corresponds to the diagnostic priority order, ensuring that when multiple configuration differences coexist, the vehicle configuration diagnostic results generated in the preceding steps continue to serve as the basis for coordinating the vehicle configuration status in subsequent configuration handling.

[0178] Furthermore, if the candidate difference field corresponding to the control configuration scheme verification value has already been explained by the vehicle authorized configuration change record, but the current firmware version cannot meet the firmware version applicability conditions corresponding to the changed configuration state, the difference explanation status of the candidate difference field corresponding to the control configuration scheme verification value is determined to be explained. However, the current firmware version still continues to form a vehicle firmware configuration mismatch type based on the firmware applicability conditions. Therefore, the vehicle authorized configuration change record only explains the control configuration scheme verification value differences that can be explained by the changed configuration state, and does not eliminate the firmware version mismatch state formed between the current firmware version and the firmware applicability conditions.

[0179] In a preferred embodiment, when the current accessory installation status is "Accessory Installation Pending Confirmation," the configuration handling action corresponding to the "Uncertain Vehicle Accessory Configuration Status" type is first used to reread the accessory status data and then generate a source consistency judgment result based on the reread accessory status data. After re-determining the current accessory installation status based on the new source consistency judgment result, a new matching status is formed based on the verification benchmark status corresponding to the accessory installation status field. When the new current accessory installation status reaches the verification benchmark status corresponding to the accessory installation status field, the corresponding accessory installation status field generates a handling completion field during the configuration review stage; when the new current accessory installation status still does not reach the verification benchmark status corresponding to the accessory installation status field, the corresponding accessory installation status field generates a continued diagnosis field during the configuration review stage. Through the above processing, source conflicts or status missing issues are first resolved by rereading the accessory status data to generate a new source consistency judgment result, and then the accessory installation status field is verified based on the new current accessory installation status.

[0180] In a preferred embodiment, for configuration handling actions corresponding to vehicle configuration write / read anomaly types, after re-executing the corresponding vehicle configuration field read, a new vehicle after-sales configuration read status is first formed. When the new vehicle after-sales configuration read status indicates that the corresponding vehicle configuration field has been effectively read, the current status and matching status are re-formed based on the field correspondence in the vehicle delivery configuration snapshot; if the new vehicle after-sales configuration read status still indicates that the corresponding vehicle configuration field read was abnormal, the corresponding vehicle configuration field continues to be retained as a field for further diagnosis. Therefore, the configuration review corresponding to the vehicle configuration write / read anomaly type first determines whether the corresponding vehicle configuration field has been restored to a state where field validation can be performed, and then determines whether to continue vehicle configuration difference diagnosis based on the restored field status.

[0181] In a preferred embodiment, for configuration handling actions corresponding to vehicle control configuration drift types, after rewriting the corresponding control configuration fields, the corresponding control configuration fields are read again according to the vehicle delivery configuration readback method used in steps S233 and S234. The processed control configuration scheme verification value is then formed using the same field identifier order and verification code used when forming the target control configuration scheme verification value, the control configuration scheme verification value, and the current control configuration scheme verification value. The processed control configuration scheme verification value is entered into the configuration review snapshot and verified against the corresponding verification baseline state of the control configuration scheme. Therefore, the configuration review uses the control configuration scheme verification value actually reread from the target vehicle after handling, rather than the control configuration state prepared for the configuration handling action.

[0182] In a preferred embodiment, for configuration handling actions corresponding to vehicle firmware configuration mismatch types, after the current firmware version changes, the current firmware version is reread, and the corresponding firmware applicable conditions are read again based on the control configuration scheme verification value. The reread current firmware version is matched with the firmware applicable conditions to form the firmware version matching result in the configuration review stage. Therefore, the configuration review judgment for vehicle firmware configuration mismatch types is based on whether the current firmware version after handling reaches the corresponding firmware version verification benchmark state, rather than whether the current firmware version has changed.

[0183] In a specific embodiment, taking an electric-assist bicycle with a rear rack installed but no child seat installed at delivery as an example, the following further explains the aforementioned vehicle basic configuration status, accessory installation status, control configuration scheme, vehicle delivery configuration snapshot, vehicle after-sales current configuration snapshot, and configuration review process. After the vehicle enters the delivery configuration stage, the vehicle identifier, product specifications, vehicle category, firmware version, and controller capabilities corresponding to the target vehicle are first read, and the accessory configuration items corresponding to the rear rack and child seat are obtained. In this embodiment, the aforementioned vehicle basic configuration status is specifically formed by product specifications, vehicle category, firmware version, and controller capabilities; the aforementioned accessory installation status specifically includes two accessory installation statuses: rear rack installed and child seat not installed. The vehicle identifier is used to ensure that the subsequently generated vehicle configuration record to be written, vehicle configuration write record, vehicle delivery configuration snapshot, and vehicle after-sales current configuration snapshot all correspond to the same target vehicle. The product specifications and vehicle category are used to determine the vehicle configuration category adopted by the target vehicle. The firmware version is used to determine the control configuration fields that the target vehicle can currently recognize. The controller capabilities are used to further determine the control configuration fields that the target vehicle can actually execute. When a delivery configuration package is formed from the vehicle's basic configuration status and accessory installation status, the delivery configuration package can store vehicle identification, product specifications, vehicle category, accessory installation status, firmware version, controller capabilities, rule version, and verification value. The rule version identifies the vehicle configuration rule version used when forming the control configuration scheme and continues to be included in the control configuration scheme formation process along with the delivery configuration package. The verification value indicates the data verification status when the above configuration fields in the delivery configuration package are formed and is used to verify the data integrity of the delivery configuration package before reading it to form the control configuration scheme. In this embodiment, the vehicle configuration record to be written, as described in the aforementioned specific implementation, is specifically the vehicle configuration record to be written after establishing a correspondence between the delivery configuration package and the control configuration scheme formed based on the delivery configuration package. The vehicle's basic configuration status and accessory installation status continue to be stored in the vehicle configuration record to be written along with the control configuration scheme and continue to be included in the vehicle configuration writing and vehicle delivery configuration snapshot formation processes.

[0184] When forming a control configuration scheme based on the delivery configuration package, the lower-level control configuration fields in the control configuration scheme can take the form of speed limit state, power assist mode state, start-up response state, power increase rate state, torque increase rate state, warning state, and disabled state. Specifically, firstly, based on the firmware version and controller capabilities, the control configuration fields that can be recognized and executed by the target vehicle are determined, thus forming the aforementioned range of executable control configuration fields. Then, based on the accessory installation status (rear rack installed, child seat not installed), the control configuration fields affected by the accessory installation status are determined within the range of executable control configuration fields, and the enabled or restricted status corresponding to the control configuration fields affected by the accessory installation status is further determined. The enabled or restricted status forms the control configuration status corresponding to the corresponding control configuration field. Thus, the accessory installation status actually participates in the formation of the control configuration scheme, rather than just being stored as vehicle delivery configuration data. After the control configuration scheme is formed, the target configuration execution terminal in the target vehicle is determined based on the field identifier corresponding to the control configuration field, and then the control configuration scheme is written to the target configuration execution terminal. In this embodiment, the target configuration execution end can correspond to a controller or a display end. When the battery management system, application end, or cloud end in the product implementation can also save the corresponding control configuration fields, the corresponding target configuration execution end can be determined according to the pre-configured correspondence between the field identifiers corresponding to the control configuration fields and the field identifiers of the target configuration execution end. After the control configuration scheme is written, the corresponding configuration status is reread from the target configuration execution end, and the vehicle delivery configuration status is formed according to the reread configuration status, thereby avoiding directly using the expected control configuration status in the vehicle configuration record to be written as the vehicle delivery configuration status already written to the target vehicle end.

[0185] When a vehicle delivery configuration snapshot is generated based on the vehicle delivery configuration status, the following fields can be saved: configuration package identifier, control configuration scheme identifier, control configuration scheme verification value, firmware version, accessory installation status field, write result field, and timestamp. The configuration package identifier establishes a correspondence with the aforementioned delivery configuration package to determine the delivery configuration package corresponding to the vehicle delivery configuration snapshot; the control configuration scheme identifier establishes a correspondence with the control configuration scheme to determine the control configuration scheme corresponding to the vehicle delivery configuration snapshot; the control configuration scheme verification value indicates the control configuration scheme actually written and reread; the accessory installation status field specifically saves whether the after-sales service shelf is installed or the child seat is not installed; the firmware version saves the firmware version corresponding to the target vehicle at the time the vehicle delivery configuration snapshot was generated; the write result field saves whether the vehicle configuration write and vehicle delivery configuration readback have resulted in data that can still be used for after-sales verification; the timestamp indicates the time position when the vehicle delivery configuration snapshot was generated, and is used to determine the vehicle delivery configuration snapshot corresponding to the current vehicle delivery configuration stage when multiple vehicle delivery configuration snapshots exist on the same target vehicle. The configuration package identifier, control configuration scheme identifier, control configuration scheme verification value, firmware version, attachment installation status field, write result field, and timestamp are all stored in the vehicle delivery configuration snapshot. This allows the vehicle delivery configuration snapshot to serve as the corresponding verification benchmark for field-by-field verification during the after-sales phase, rather than simply forming ordinary delivery text.

[0186] After a vehicle enters the after-sales diagnostic phase, the same target vehicle is identified based on the vehicle identifier, and then the vehicle's current after-sales configuration snapshot is read. In this embodiment, the vehicle's current after-sales configuration snapshot specifically includes the current control configuration scheme identifier, the current control configuration scheme verification value, the current firmware version, the current accessory installation status field, the error code, the vehicle's after-sales configuration read status, and a timestamp. The current control configuration scheme identifier is used to determine the control configuration scheme currently saved on the target vehicle during after-sales reading; the current control configuration scheme verification value is used to characterize the content of the control configuration scheme currently saved on the target vehicle during after-sales reading; the current firmware version is used to indicate the current firmware state of the target vehicle during after-sales reading; the current accessory installation status field is used to indicate the accessory installation state formed during after-sales reading; the vehicle's after-sales configuration read status is used to indicate whether the current control configuration scheme verification value, current firmware version, and current accessory installation status field have been effectively read; the timestamp is used to indicate the time position when the vehicle's current after-sales configuration snapshot was formed; and the error code is used to further determine whether protection-related anomalies on the target vehicle can be explained by vehicle configuration differences. When performing field mapping, a field mapping relationship is established between the control configuration scheme verification value in the vehicle delivery configuration snapshot and the current control configuration scheme verification value in the vehicle after-sales current configuration snapshot; a field mapping relationship is established between the firmware version in the vehicle delivery configuration snapshot and the current firmware version in the vehicle after-sales current configuration snapshot; and a field mapping relationship is established between the accessory installation status field in the vehicle delivery configuration snapshot and the current accessory installation status field in the vehicle after-sales current configuration snapshot. The corresponding configuration field status in the vehicle delivery configuration snapshot forms the corresponding verification baseline status, and the corresponding configuration field status in the vehicle after-sales current configuration snapshot forms the current status. A matching status is formed by checking each field according to the corresponding verification baseline status and the current status.

[0187] For example, sample number CASE-002 can be used to illustrate the aforementioned vehicle control configuration drift type. Sample number CASE-002 represents a control configuration scheme drift scenario, corresponding to field-level consistency verification rule number R2. The judgment content corresponding to rule number R2 is: the current control configuration scheme verification value is inconsistent with the control configuration scheme verification value in the vehicle delivery configuration snapshot, and there is no vehicle authorized configuration change record that can explain the difference. In the aforementioned specific implementation, the vehicle authorized configuration change record specifically corresponds to the vehicle configuration change data that has been saved and is allowed to continue to be retained on the target vehicle; the changed configuration status in the vehicle authorized configuration change record specifically corresponds to the changed control configuration scheme status recorded in the vehicle authorized configuration change record. When the current control configuration scheme verification value is different from the control configuration scheme verification value in the vehicle delivery configuration snapshot, and there is no changed configuration status in the vehicle authorized configuration change record that can correspond to the current control configuration scheme verification value, the candidate difference field corresponding to the control configuration scheme verification value forms an unexplained difference field, and further forms a vehicle control configuration drift type. The configuration handling action corresponding to the vehicle control configuration drift type can specifically be parameter restoration or rewriting of the control configuration scheme. The parameter recovery or rewriting of the control configuration scheme is still subject to the applicable conditions of the configuration handling action and the current vehicle configuration conditions on the target vehicle, and does not mean that all vehicle configuration fields will be unconditionally recovered.

[0188] For example, sample number CASE-012 can be used to illustrate the role of the aforementioned vehicle authorized configuration change record. Sample number CASE-012 corresponds to the scenario of protecting against false positives in legitimate changes. When the current control configuration scheme verification value in the vehicle after-sales current configuration snapshot differs from the control configuration scheme verification value in the vehicle delivery configuration snapshot, but a vehicle authorized configuration change record exists, and the current control configuration scheme verification value and the current firmware version correspond to the changed configuration status and firmware version applicable conditions recorded in the vehicle authorized configuration change record, although the current control configuration scheme verification value has changed relative to the control configuration scheme verification value in the vehicle delivery configuration snapshot, the candidate difference field corresponding to the control configuration scheme verification value can be interpreted by the vehicle authorized configuration change record. Therefore, in the aforementioned steps S383 and S384, the difference interpretation status of the candidate difference field corresponding to the control configuration scheme verification value is determined to be an interpreted status, and the candidate difference field corresponding to the control configuration scheme verification value is no longer used as input for the vehicle control configuration drift type. Therefore, the vehicle authorized configuration change record is used to store configuration changes that have been completed and are allowed to be retained on the target vehicle side; the authorized change verification record is used to store the corresponding verification benchmark status, current status, and post-change configuration status in the vehicle authorized configuration change record for candidate difference fields; the vehicle configuration difference explanation record is used to store the difference explanation status formed based on the authorized change verification record; the difference explanation status is used to indicate whether the candidate difference field can be explained by the vehicle authorized configuration change record. Sample number CASE-012 specifically corresponds to the processing scenario where, when the vehicle authorized configuration change record can explain the difference in the control configuration scheme verification value, the corresponding candidate difference field is no longer identified as a vehicle control configuration drift type.

[0189] For the firmware version field, sample number CASE-003 and rule number R3 can be used for further explanation. Sample number CASE-003 is used to indicate a scenario where the firmware version does not meet the firmware conditions corresponding to the control configuration scheme, and rule number R3 corresponds to firmware mismatch judgment. The aforementioned firmware applicability conditions in this specific scenario are used to indicate the firmware version conditions that the control configuration scheme needs to meet to be recognized and executed by the current firmware version of the target vehicle. When the control configuration scheme is formed, the firmware applicability conditions are pre-configured according to the range of firmware versions required for the control configuration field in the control configuration scheme to be recognized and executed by the target vehicle, and a corresponding relationship is established with the control configuration scheme verification value. When the current firmware version does not meet the firmware applicability conditions, the matching status of the firmware version is a mismatch status, thus forming a vehicle firmware configuration mismatch type. The handling direction corresponding to the vehicle firmware configuration mismatch type can specifically adopt over-the-air upgrade suggestions or firmware compatibility confirmation. Over-the-air upgrade suggestions and firmware compatibility confirmation are both handling directions corresponding to the vehicle firmware configuration mismatch type, and do not mean directly changing the current firmware version without authorization and compatibility verification. After completing the firmware processing that is allowed to be executed, the current firmware version is read again, and the current firmware version is matched with the firmware applicable conditions. The matching result of the matching result is used to form the matching result of the configuration review stage and enter the configuration review snapshot.

[0190] For the accessory installation status field, sample numbers CASE-004, CASE-005, and CASE-006, along with rule number R4, can be used for explanation. Sample number CASE-004 indicates a scenario where the current accessory installation status field generated by after-sales service indicates the accessory exists, but the accessory installation status field in the vehicle delivery configuration snapshot does not save the corresponding accessory installation status. Sample number CASE-005 indicates a scenario where the accessory installation status field in the vehicle delivery configuration snapshot saves the corresponding accessory installation status, but the current accessory installation status field in the vehicle after-sales current configuration snapshot indicates the corresponding accessory is missing. Sample number CASE-006 indicates a scenario where there is a source conflict between multiple accessory status sources. Rule number R4 forms an uncertain type for vehicle accessory configuration status in the above scenarios, rather than directly forming a conclusion of accessory misinstallation. In this embodiment, when re-reading the current accessory installation status corresponding to the rear rack and child seat after-sales service, accessory status data corresponding to the same accessory installation status field can be obtained from accessory configuration data saved on the application side, accessory configuration data saved on the display side, accessory configuration data detected by the target vehicle side, and accessory configuration data read by the service tool, respectively. The attachment configuration data saved on the application, the display, the target vehicle, and the service tool each have corresponding source identifiers and source reading statuses, and are collectively recorded in the attachment source record. When determining source consistency based on these data, if the attachment status data from each source is consistent, the current attachment installation status is determined based on the consistent data. If the attachment status data from different sources is inconsistent, a source conflict occurs. If a source capable of providing the corresponding attachment installation status field fails to obtain valid attachment status data, a status is missing. Both source conflicts and status missing statuses result in the current attachment installation status being designated as an "attachment installation pending confirmation" status. This "attachment installation pending confirmation" status continues as the current status corresponding to the current attachment installation status field and enters the field validation process, further forming an uncertain vehicle attachment configuration status type. Subsequently, the attachment status data is reread, allowing the reread attachment status data to participate in the source consistency determination again, rather than directly selecting any attachment status data from any source as the final current attachment installation status.

[0191] For the write result field and the vehicle after-sales configuration read status, sample number CASE-008 and rule number R6 can be used for explanation. Sample number CASE-008 represents a scenario where vehicle configuration write anomalies and control configuration scheme verification value differences coexist. Rule number R6 corresponds to the suspected write failure judgment, and its judgment content includes vehicle configuration write failure, vehicle delivery configuration readback failure, configuration storage failure, or control configuration scheme verification value anomaly. When the write result field in the vehicle delivery configuration snapshot indicates that the control configuration scheme has not formed a normal vehicle configuration write result, or the vehicle after-sales configuration read status in the current vehicle after-sales configuration snapshot indicates that the relevant vehicle configuration field has not been effectively read, the vehicle configuration verification pre-state is used to indicate that the corresponding vehicle configuration field does not yet meet the field verification conditions. In this case, a vehicle configuration write-read anomaly type is formed first, rather than directly forming a vehicle control configuration drift type based on the missing or abnormal vehicle configuration field content. Sample number CASE-008 is also used to explain that when the vehicle configuration write-read anomaly type and the vehicle control configuration drift type exist at the same time, the vehicle configuration write-read anomaly type is first determined as the main configuration diagnostic type according to the diagnostic priority, and then the vehicle control configuration drift type is processed in subsequent steps. This avoids directly interpreting the vehicle configuration write anomaly or the vehicle after-sales configuration read anomaly as a drift in the control configuration scheme content.

[0192] When critical vehicle configuration fields such as vehicle delivery configuration snapshot, vehicle after-sales current configuration snapshot, accessory installation status field, or firmware version are missing, sample number CASE-010 and rule number R8 can be used for explanation. Sample number CASE-010 indicates a scenario where a snapshot is missing or critical vehicle configuration fields are insufficient, and rule number R8 corresponds to a downgrade judgment due to insufficient information. In this case, the vehicle configuration verification field integrity record first verifies whether the control configuration scheme verification value, firmware version, and accessory installation status fields have corresponding verification baseline status and current status, respectively. Vehicle configuration fields lacking corresponding verification baseline status or current status are identified as configuration fields that have not completed verification, and further form a field insufficiency status; vehicle configuration fields with corresponding verification baseline status and current status are identified as configuration fields that can complete verification, and continue to form corresponding matching statuses. Field insufficiency statuses then enter the vehicle configuration consistency verification record and participate in vehicle configuration difference diagnosis through the vehicle configuration verification pre-state. For vehicle configuration fields corresponding to field insufficiency statuses, the corresponding vehicle configuration data is reread or supplemented; for configuration fields that can complete verification, the already formed matching status is retained. Therefore, the vehicle configuration difference will not be caused by deleting other configuration fields that can be verified due to the absence of a single vehicle configuration field, nor will the state of insufficient fields be directly identified as the vehicle control configuration drift type.

[0193] Furthermore, sample numbers CASE-001, CASE-007, CASE-009, and CASE-011 can be used to illustrate the remaining field-level consistency verification branches. Sample number CASE-001 corresponds to rule number R1. When the control configuration scheme verification value, firmware version, and accessory installation status fields all match their respective verification baseline states, a configuration consistency result is formed. This result indicates that no discrepancies requiring configuration recovery have been found in the core vehicle configuration fields. Sample number CASE-007 corresponds to rule number R5. When a mismatch exists between the vehicle category field and the vehicle configuration category or speed limit status corresponding to the control configuration scheme, a vehicle category configuration anomaly result is formed. This result is used to further verify the configuration relationship between the vehicle category and the corresponding control configuration field. Sample number CASE-009 corresponds to rule number R7. When the error code in the current configuration snapshot of the vehicle after-sales service belongs to the protection category, and the protection category error code cannot be explained by the vehicle configuration difference in the vehicle configuration consistency verification record, a hardware fault pending investigation result is formed. The hardware fault pending investigation result is used to allow the protection category error code to enter the subsequent ordinary fault code diagnosis, instead of directly attributing the protection category error code to the vehicle configuration difference. Sample number CASE-011 is used to represent a scenario where multiple vehicle configuration diagnosis types exist simultaneously. The corresponding multiple vehicle configuration diagnosis types are determined according to the aforementioned diagnosis priority order to determine the primary configuration diagnosis type and the secondary configuration diagnosis type. Then, the primary configuration diagnosis type and the secondary configuration diagnosis type generate configuration handling actions respectively and enter the configuration handling coordination. Therefore, rule number R1, rule number R5, and rule number R7 all have corresponding input fields, judgment relationships, and subsequent processing directions. Sample numbers CASE-001, CASE-007, CASE-009, and CASE-011 are also used to describe the specific vehicle configuration status of the corresponding judgment branch.

[0194] After completing parameter recovery, rewriting the control configuration scheme, or performing firmware processing, the target vehicle is read again based on the aforementioned corresponding difference fields, thus forming a configuration review snapshot. The configuration review snapshot specifically corresponds to the vehicle configuration snapshot formed after recovery or inspection and rereading. For vehicle control configuration drift types, the control configuration scheme verification value is reread, and the reread control configuration scheme verification value is compared with the corresponding verification benchmark state of the control configuration scheme. For vehicle firmware configuration mismatch types, the current firmware version is reread, and it is determined whether the reread current firmware version meets the firmware applicability conditions. For vehicle accessory configuration status uncertainty types, accessory status data is re-obtained, and a source consistency judgment result is formed again. The current accessory installation status is then re-determined based on the source consistency judgment result, and the re-determined current accessory installation status participates in the accessory installation status field verification. When the matching result in the configuration review verification record indicates that the vehicle configuration field has reached the corresponding verification benchmark state, the vehicle configuration field is marked as a processing completed field; when the matching result in the configuration review verification record indicates that the vehicle configuration field has not yet reached the corresponding verification benchmark state, the vehicle configuration field is marked as a field for continued diagnosis. Based on the "Completed Processing" and "Continued Diagnosis" fields, a post-processing review record for vehicle configuration is generated. This allows the configuration review snapshot formed after recovery or inspection to continue entering field-by-field verification, and the configuration review verification record formed by field-by-field verification directly participates in the generation of the post-processing review record for vehicle configuration.

[0195] The rule numbers R1 to R8 and sample numbers CASE-001 to CASE-012 are used to identify the judgment branches and verification samples corresponding to different vehicle configuration states. Rule number R1 corresponds to consistent configuration; rule number R2 corresponds to configuration drift; rule number R3 corresponds to firmware mismatch; rule number R4 corresponds to uncertain attachment status; rule number R5 corresponds to abnormal vehicle category configuration; rule number R6 corresponds to suspected write failure; rule number R7 corresponds to hardware fault pending investigation; and rule number R8 corresponds to degrading due to insufficient information. Sample CASE-001 corresponds to a normal consistency scenario; Sample CASE-002 corresponds to a control configuration scheme drift scenario; Sample CASE-003 corresponds to a firmware mismatch scenario; Sample CASE-004 corresponds to an attachment addition scenario; Sample CASE-005 corresponds to an attachment missing scenario; Sample CASE-006 corresponds to a multi-source conflict scenario; Sample CASE-007 corresponds to a vehicle category configuration anomaly scenario; Sample CASE-008 corresponds to a write failure scenario; Sample CASE-009 corresponds to an error code and configuration concurrency scenario; Sample CASE-010 corresponds to a snapshot missing or critical vehicle configuration field insufficient scenario; Sample CASE-011 corresponds to a multiple inconsistency scenario; and Sample CASE-012 corresponds to a legitimate change false alarm prevention scenario. Rule numbers R1 to R8 are used to determine which judgment branch the corresponding vehicle configuration state enters. Sample numbers CASE-001 to CASE-012 are used to explain the vehicle configuration diagnostic results formed after different vehicle configuration input states have passed through the corresponding judgment branches. Rule numbers R1 to R8 and sample numbers CASE-001 to CASE-012 are not used as vehicle control parameters; the actual vehicle configuration processing still uses the specific vehicle configuration field status and field correspondence in the vehicle delivery configuration snapshot and the vehicle after-sales current configuration snapshot as the judgment data.

[0196] like Figure 2 As shown, this is an embodiment of an electric-assisted bicycle control configuration generation and verification diagnostic device, which includes: The first program unit is used to obtain the vehicle's basic configuration status and accessory installation status, and generate a vehicle configuration record to be written based on the vehicle's basic configuration status, accessory installation status and control configuration scheme. The second program unit is used to determine the target vehicle terminal based on the vehicle configuration record to be written, write the control configuration scheme in the vehicle configuration record to be written to the target vehicle terminal to generate a vehicle configuration writing record that retains the accessory installation status, read back the configuration status of the target vehicle terminal based on the vehicle configuration writing record to generate a vehicle delivery configuration snapshot containing the accessory installation status field, and the vehicle delivery configuration snapshot enters step S3 for field-by-field verification. The third program unit is used to identify the target vehicle terminal determined by after-sales service, read the target vehicle terminal to generate a snapshot of the current configuration of the vehicle after-sales service containing the current accessory installation status field, obtain the vehicle delivery configuration snapshot associated with the target vehicle terminal, and verify the current configuration snapshot of the vehicle after-sales service field by field according to the vehicle delivery configuration snapshot to generate a vehicle configuration consistency verification record containing the difference fields and the corresponding verification benchmark status. The fourth program unit is used to generate a vehicle configuration difference diagnosis and handling record based on the difference fields and corresponding verification benchmark status in the vehicle configuration consistency verification record, obtain the handling status of the vehicle configuration difference diagnosis and handling record, generate a configuration review preparation record based on the handling status, difference fields and corresponding verification benchmark status, read the corresponding configuration fields of the target vehicle based on the difference fields in the configuration review preparation record to generate a configuration review snapshot, and verify the configuration review snapshot field by field based on the corresponding verification benchmark status in the configuration review preparation record to generate a vehicle configuration handling post-review record.

[0197] like Figure 3 As shown, a computer storage medium according to an embodiment of this application stores a computer executable program, which, when executed, performs the method of any one of the claims of this application.

[0198] like Figure 4 As shown, an electric-assisted bicycle according to an embodiment of this application includes a controller, which is configured to execute the electric-assisted bicycle control configuration generation and verification diagnostic method described in any one of the claims of this application.

[0199] like Figure 5 As shown, a controller according to an embodiment of this application includes a memory storing a computer program. When the processor executes the computer program, it implements the electric-assisted bicycle control configuration generation and verification diagnostic method described in any one of this application.

[0200] Figures 2-5 For an exemplary description, please refer to the above. Figure 1 This will not be elaborated upon here.

Claims

1. A method for generating and verifying the control configuration of an electric-assisted bicycle, characterized in that, include: Step S3: After-sales service determines the target vehicle terminal, reads the target vehicle terminal to generate a snapshot of the current configuration of the vehicle after-sales service containing the current accessory installation status field, obtains the vehicle delivery configuration snapshot associated with the target vehicle terminal, and verifies the current configuration snapshot of the vehicle after-sales service field by field according to the vehicle delivery configuration snapshot to generate a vehicle configuration consistency verification record containing the difference fields and the corresponding verification benchmark status. Step S4: Generate a vehicle configuration difference diagnosis and handling record based on the difference fields and corresponding verification benchmark status in the vehicle configuration consistency verification record; obtain the handling status of the vehicle configuration difference diagnosis and handling record; generate a configuration review preparation record based on the handling status, difference fields and corresponding verification benchmark status; read the corresponding configuration fields on the target vehicle based on the difference fields in the configuration review preparation record to generate a configuration review snapshot; verify the configuration review snapshot field by field based on the corresponding verification benchmark status in the configuration review preparation record to generate a vehicle configuration handling post-review record.

2. The method according to claim 1, characterized in that, Also includes: Step S1: Obtain the vehicle's basic configuration status and accessory installation status, and generate a vehicle configuration record to be written based on the vehicle's basic configuration status, accessory installation status, and control configuration scheme. Step S2: Determine the target vehicle based on the vehicle configuration record to be written, write the control configuration scheme in the vehicle configuration record to be written to the target vehicle to generate a vehicle configuration write record that retains the accessory installation status, read back the configuration status of the target vehicle based on the vehicle configuration write record to generate a vehicle delivery configuration snapshot containing the accessory installation status field, and proceed to step S3 for field-by-field verification of the vehicle delivery configuration snapshot.

3. The method according to claim 2, characterized in that, Step S1 includes: Step S11: Obtain product specifications, vehicle category, firmware version, controller capabilities, and accessory configuration items to generate vehicle delivery configuration input records; Step S12: Determine the vehicle basic configuration status based on the product specifications, vehicle category, firmware version and controller capabilities in the vehicle delivery configuration input record to generate a vehicle basic configuration status record containing the vehicle basic configuration status and accessory configuration items. Step S13: Determine the accessory installation status based on the accessory configuration items in the vehicle basic configuration status record to generate a vehicle accessory configuration status record containing the vehicle basic configuration status and accessory installation status; continue to execute steps S14 and S15 based on the vehicle accessory configuration status record to generate the vehicle configuration record to be written in step S1.

4. The method according to claim 3, characterized in that, Step S1 also includes: Step S14: Determine the range of executable control configuration fields based on the vehicle basic configuration status in the vehicle accessory configuration status record, and generate an accessory association control configuration record containing the vehicle basic configuration status and accessory installation status within the range of executable control configuration fields based on the accessory installation status in the vehicle accessory configuration status record. Step S15: Generate a vehicle configuration record to be written, which includes the vehicle basic configuration status, accessory installation status, and control configuration status within the scope of the executable control configuration field in the attached associated control configuration record.

5. The method according to claim 4, characterized in that, Step S14 includes: Step S141: Determine the executable control configuration field based on the firmware version and controller capability corresponding to the vehicle basic configuration status in the vehicle accessory configuration status record, so as to generate a vehicle executable control configuration field record containing the vehicle basic configuration status, accessory installation status and executable control configuration field. Step S142: Determine the range of executable control configuration fields based on the executable control configuration fields in the vehicle executable control configuration field record, identify the control configuration fields affected by the accessory installation status based on the accessory installation status, and generate an accessory-affected control configuration field record that retains the vehicle basic configuration status, accessory installation status, and affected control configuration fields; continue to execute steps S143 and S144 based on the accessory-affected control configuration field record to generate an accessory-associated control configuration record.

6. The method according to claim 5, characterized in that, Step S14 also includes: Step S143: Determine the enabled or restricted status of each affected control configuration field based on the affected control configuration fields and their accessory installation status in the attached affected control configuration field record, so as to generate an accessory control configuration field adaptation record containing the vehicle basic configuration status, accessory installation status, and the enabled or restricted status of each affected control configuration field. Step S144: Generate an attachment-related control configuration record based on the vehicle basic configuration status, attachment installation status, and the enable or restrict status of each affected control configuration field in the attachment control configuration field adaptation record.

7. A device for generating, verifying, and diagnosing the control configuration of an electric-assisted bicycle, characterized in that, include: The first program unit is used to obtain the vehicle's basic configuration status and accessory installation status, and generate a vehicle configuration record to be written based on the vehicle's basic configuration status, accessory installation status and control configuration scheme. The second program unit is used to determine the target vehicle terminal based on the vehicle configuration record to be written, write the control configuration scheme in the vehicle configuration record to be written to the target vehicle terminal to generate a vehicle configuration writing record that retains the accessory installation status, read back the configuration status of the target vehicle terminal based on the vehicle configuration writing record to generate a vehicle delivery configuration snapshot containing the accessory installation status field, and the vehicle delivery configuration snapshot enters step S3 for field-by-field verification. The third program unit is used to identify the target vehicle terminal determined by after-sales service, read the target vehicle terminal to generate a snapshot of the current configuration of the vehicle after-sales service containing the current accessory installation status field, obtain the vehicle delivery configuration snapshot associated with the target vehicle terminal, and verify the current configuration snapshot of the vehicle after-sales service field by field according to the vehicle delivery configuration snapshot to generate a vehicle configuration consistency verification record containing the difference fields and the corresponding verification benchmark status. The fourth program unit is used to generate a vehicle configuration difference diagnosis and handling record based on the difference fields and corresponding verification benchmark status in the vehicle configuration consistency verification record, obtain the handling status of the vehicle configuration difference diagnosis and handling record, generate a configuration review preparation record based on the handling status, difference fields and corresponding verification benchmark status, read the corresponding configuration fields of the target vehicle based on the difference fields in the configuration review preparation record to generate a configuration review snapshot, and verify the configuration review snapshot field by field based on the corresponding verification benchmark status in the configuration review preparation record to generate a vehicle configuration handling post-review record.

8. A computer storage medium, characterized in that, It stores a computer-executable program thereon, which, when executed, performs the method of any one of claims 1-6.

9. An electric-assisted bicycle, characterized in that, The system includes a controller configured to perform the electric-assist bicycle control configuration generation and verification diagnostic method as described in any one of claims 1-6.

10. A controller, characterized in that, The system includes a memory storing a computer program, and the processor executes the computer program to implement the electric-assist bicycle control configuration generation and verification diagnostic method according to any one of claims 1-6.

Images