A vehicle off-line electric control data automatic flashing detection method and system

Abstract

This invention provides a method and system for automatically writing and detecting vehicle electronic control data after production line completion. The method includes: receiving electronic control data; parsing and determining the vehicle model information and actual vehicle assembly information of the electronic control unit (ECU) based on the vehicle configuration words in the electronic control data; matching predefined vehicle model electronic control data writing tasks according to the vehicle model information, and filtering based on the actual vehicle assembly information to generate actual vehicle electronic control data writing tasks for the target vehicle; matching a specific writing scheme for each ECU in the actual vehicle electronic control data writing task; executing the matched writing scheme to complete the electronic control data writing; automatically generating a corresponding ECU detection task for each ECU according to the writing scheme; generating and transmitting the execution record of electronic control data writing and ECU detection. This method replaces the traditional method relying on fixed lists and manual intervention, thereby achieving efficient, accurate, and flexible production line completion operations.

Description

Technical Field

[0001] This invention relates to a method and system for automatically writing and detecting electronic control data after a vehicle rolls off the production line, and pertains to the field of electronic control system design and application technology. Background Technology

[0002] ECU data flashing, also known as ECU remapping or car computer board remapping, has three main applications: first, data encapsulation when the engine / car leaves the factory; second, ECU updates and repairs at car repair shops; and third, engine modification applications.

[0003] Depending on the nature of the control task, ECU data can be divided into multiple data areas, such as component information configuration area, power parameter area, emission parameter area, and fault diagnosis area.

[0004] Currently, the rewriting of vehicle electronic control system (ECU) data after production line completion faces three main technical challenges: First, task generation lacks dynamism. Existing systems typically call a predefined "complete set" of all possible ECU rewriting tasks based on the vehicle model, failing to dynamically filter based on the actual vehicle assembly list. Performing invalid rewriting attempts on uninstalled ECUs wastes time, and the complexity of maintaining the task list increases dramatically with the number of configuration combinations. Second, rewriting scheme matching lacks precision. For a specific ECU type (such as a gateway), different suppliers and hardware versions may require different rewriting processes, diagnostic services, and data address mappings. Existing solutions either use a single universal process (poor compatibility and prone to failure) or require manually pre-setting numerous independent schemes for different attribute combinations (cumbersome maintenance and difficult to cover all situations), lacking an intelligent mechanism that can automatically match the most suitable rewriting scheme based on the ECU's actual identity information (such as part number, hardware version, etc.). Third, the rewriting and testing processes lack integration. Verification of successful flashing is often treated as a separate follow-up step, sometimes even relying on manual visual inspection or another set of testing equipment. This not only lengthens the production cycle but also makes it difficult to ensure the integrity of the verification (such as whether the configuration words are written correctly) and its strong correlation with the flashing operation itself. These pain points collectively restrict the automation level, production efficiency, and quality assurance capabilities of the offline flashing process. Summary of the Invention

[0005] To address the aforementioned practical problems, this invention provides a method and system for automatically writing and detecting vehicle off-line electronic control data. The specific technical solution is as follows: A method for automatically writing and detecting electronic control data after a vehicle rolls off the production line includes: S1, receives electronic control flashing data identified by the VIN code of the target vehicle; S2, based on the vehicle configuration words in the electronic control data, parse and determine the vehicle model information and the actual vehicle assembly information of the electronic control unit of the target vehicle; S3. Based on the vehicle model information, match the predefined vehicle model electronic control data flashing task, and filter it in combination with the actual vehicle assembly information to generate the actual vehicle electronic control data flashing task for the target vehicle. S4. Based on the predefined electronic control unit flashing scheme library and matching rules, a specific flashing scheme is matched for each electronic control unit in the actual vehicle electronic control data flashing task. S5, execute the matched flashing scheme to complete the electronic control data flashing; and automatically generate a corresponding electronic control unit detection task for each electronic control unit according to the flashing scheme; S6, Generate and return the execution record of electronic control data writing and electronic control unit detection; The electronic control data includes one or more of the following: vehicle configuration characters, VIN code, software package, and calibration settings. The vehicle configuration word is a data sequence formed by encoding actual vehicle assembly information and functional information according to preset rules. The data sequence includes at least the vehicle model information of the target vehicle and the actual assembly status of each electronic control unit in the target vehicle. The vehicle model electronic control data flashing task is to retrieve a pre-configured electronic control data flashing task set corresponding to the vehicle model based on the vehicle model information; wherein, the pre-configured electronic control data flashing task set is a collection of flashing tasks pre-defined for multiple electronic control unit types under the vehicle model platform; each electronic control unit type flashing task includes at least the following task definitions: whether to flash the software package, whether to flash the configuration word, whether to flash the VIN code, and whether to execute calibration items.

[0006] Preferably, the actual vehicle electronic control data flashing task in S3 includes: Parse vehicle configuration words to obtain the actual vehicle model information, and match the corresponding model electronic control data flashing task; The matching vehicle model electronic control data writing tasks are assigned to the relevant workstations on the production line, and the execution order of all tasks at each workstation is set to form the electronic control data writing tasks for the corresponding workstations of the vehicle models. At the same time, the actual assembly status of each electronic control unit is obtained from the vehicle configuration word, and the vehicle model electronic control data writing tasks are filtered based on the actual assembly status.

[0007] Preferably, in step S4, the electronic control unit (ECU) flashing scheme library predefines multiple selectable flashing schemes for each type of vehicle ECU; each flashing scheme is associated with a unique ECU attribute constraint. The electronic control attribute constraint is used to limit the specific values ​​of one or more attributes in a predefined set of electronic control unit attributes; For attributes in the electronic control unit attribute set that are not limited by this constraint, it means that any value of the attribute is compatible. The electrical control unit attribute set includes controller type, part number, supplier code, hardware version, and software version attributes.

[0008] Preferably, the electronic control attribute constraints are configured into multiple specific levels depending on the different attributes being defined; The specificity level includes at least one of the following: The first level specifies the values ​​for controller type, part number, supplier code, hardware version, and software version. The second level specifies the values ​​for controller type, part number, supplier code, and hardware version. The third level specifies the exact values ​​for controller type, part number, and supplier code. The fourth level specifies the exact values ​​for the controller type and part number; The fifth level specifies the exact values ​​that can be taken for the controller type.

[0009] Preferably, the specific flashing scheme matched for each electronic control unit in S4 is as follows: Taking any one of the electronic control units (ECUs) as the target ECU and matching it with a specific flashing scheme includes: Step S41: In the UDS diagnostic communication session established with the target electronic control unit, obtain the actual attribute values ​​of the target electronic control unit; Step S42: Based on the preset priority matching rules, match the actual attribute values ​​with the predefined electronic control unit flashing schemes associated with the electronic control attribute constraints. Step S43: If the match is successful, select the electronic control unit (ECU) flashing scheme associated with the successfully matched ECU attribute constraint; if the match fails, determine that there is no corresponding ECU flashing scheme.

[0010] Preferably, in step S42, the priority matching rule is as follows: Calculate a priority score for each electronic control attribute constraint; the more attributes that are constrained and the higher the level of the constraint in the specification level, the higher the priority score. During matching, the actual attribute values ​​are compared with the attribute values ​​defined by each electronic control attribute constraint condition in descending order of priority score. A match is successful when the actual attribute value matches all attribute values ​​specified in the current electronic control attribute constraint. This sequential matching follows the principle of stopping when the first match is successful. If all electronic control attribute constraints fail to match, the match fails.

[0011] Preferably, the electronic control unit (ECU) writing scheme includes one or more of the following predefined writing functions: configuration word writing function, software package writing function, VIN code writing function, and calibration function; The configuration word writing function predefines the rules for extracting data fields from the vehicle configuration word, as well as the UDS diagnostic service and address mapping relationship written to the electronic control unit. The software package flashing function predefines the flashing process based on the UDS diagnostic service. The VIN code writing function predefines the UDS diagnostic service and address mapping relationship for writing the VIN code. The calibration function predefines a calibration process based on UDS diagnostic services.

[0012] Preferably, the electronic control unit detection task includes detection functions corresponding to each flashing function in the executed flashing scheme; The detection function corresponding to the configuration word writing function is: to read the written field through the UDS diagnostic service and compare it with the configuration word source field in the received electronic control writing data for verification; The detection function corresponding to the software package flashing function is: to read the version information of the electronic control unit through the UDS diagnostic service and compare and verify it with the software package version in the received electronic control flashing data; The detection function corresponding to the VIN code writing function is: to read the written VIN code through the UDS diagnostic service and compare and verify it with the VIN code in the received electronic control writing data.

[0013] The detection function corresponding to the calibration function is: to read the calibration result through the UDS diagnostic service and determine whether the calibration is successful according to the preset calibration verification rules.

[0014] Preferably, based on the verification results of the detection functions of each electronic control unit, it is determined whether the detection of each electronic control unit has passed, and based on the detection results of all electronic control units, it is determined whether the vehicle inspection has passed; The execution record of electronic control data writing and testing is generated, and the execution record, along with the judgment results of whether each electronic control unit test and the whole vehicle test are passed, are sent back together.

[0015] An automatic vehicle off-line electronic control data writing and detection system includes: a vehicle writing and detection device and one or more vehicle electronic control units communicatively connected to the vehicle writing and detection device; the vehicle writing and detection device is used to execute the automatic vehicle off-line electronic control data writing and detection method as described above.

[0016] The beneficial effects of this invention compared to the prior art are as follows: This invention provides an automated method for detecting and writing electronic control data of vehicles after they have been manufactured. The method is executed by a vehicle writing and testing device and includes: receiving electronic control data identified by the vehicle's VIN code; wherein the vehicle configuration word is a data sequence encoded according to a preset rule, and includes at least vehicle model information and the actual assembly status of each electronic control unit.

[0017] This invention first achieves dynamic and precise generation of data flashing tasks. The system pre-configures a set of electronic control data flashing tasks for each vehicle platform and defines the flashing operation items for each type of electronic control unit. When processing a specific vehicle, the system parses the configuration words to obtain vehicle information to match the corresponding task set. At the same time, it obtains the actual vehicle assembly status to filter the task set, generating a vehicle-specific actual vehicle electronic control data flashing task. Furthermore, it can combine the workstation task allocation to generate workstation-level executable tasks, realizing intelligent progression from the "complete set of vehicle models" to the "subset of actual vehicles" and then to the "workstation execution set".

[0018] The core innovation of this invention lies in designing a library of electronic control unit (ECU) flashing schemes and matching rules with intelligent matching capabilities. This library pre-stores multiple selectable flashing schemes for each type of ECU, with each scheme associated with a unique ECU attribute constraint. This constraint limits the specific values ​​of one or more attributes in the ECU's attribute set; undefined attributes are compatible with any value. These constraints constitute multiple levels of specification based on their defined ranges.

[0019] The intelligent matching process is as follows: The actual attribute values ​​of the target electronic control unit (ECU) are read through the UDS diagnostic session; based on priority matching rules, the actual attribute values ​​are compared with the constraints associated with each scheme. The priority matching rules dynamically calculate a score for each constraint; the more attributes specified and the higher the level of detail, the higher the score. During matching, the scores are compared sequentially from highest to lowest. The constraint that achieves a complete match of all specified attribute values ​​for the first time is selected, and its associated scheme is determined as the flashing scheme for that ECU.

[0020] The flashing solution is a complete execution unit integrating operation and verification, including predefined flashing functions (configuration word flashing, software package flashing, VIN code flashing, calibration, and each function has a pre-defined UDS service process and address mapping), and deeply integrated with detection functions that correspond one-to-one with each flashing function. The system automatically generates a detection task for each electronic control unit based on the actual vehicle flashing task, and this detection task is implemented by calling the detection function in the same flashing solution.

[0021] After completing the flashing and testing of all electronic control units (ECUs), the system determines whether each ECU has passed the test based on the verification results of each test function, and comprehensively determines whether the entire vehicle has passed the test. Key operations, statuses, and results throughout the entire process are automatically generated as execution records and transmitted back, achieving end-to-end automation from vehicle identification to quality assessment. Attached Figure Description

[0022] Figure 1 This is a flowchart of Embodiment 3 of the present invention. Detailed Implementation

[0023] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] Example 1 A method for automatically writing and detecting electronic control data after a vehicle rolls off the production line includes: S1, receives electronic control flashing data identified by the VIN code of the target vehicle; S2, based on the vehicle configuration words in the electronic control flashing data, parse and determine the vehicle model information and the actual vehicle assembly information of the electronic control unit of the target vehicle; S3, based on vehicle model information, matches predefined vehicle model electronic control data flashing tasks, and combines them with actual vehicle assembly information for filtering, generating actual vehicle electronic control data flashing tasks for the target vehicle. S4, based on a predefined electronic control unit flashing scheme library and matching rules, matches a specific flashing scheme for each electronic control unit in the real vehicle electronic control data flashing task; S5, execute the matched flashing scheme to complete the electronic control data flashing; and automatically generate corresponding electronic control unit detection tasks for each electronic control unit according to the flashing scheme; S6, Generate and return the execution record of electronic control data writing and electronic control unit detection; The electronic control data includes one or more of the following: vehicle configuration characters, VIN code, software package, and calibration settings. The vehicle configuration word is a data sequence formed by encoding actual vehicle assembly information and functional information according to preset rules. The data sequence includes at least the vehicle model information of the target vehicle and the actual assembly status of each electronic control unit in the target vehicle. The vehicle model electronic control data flashing task involves retrieving a pre-configured set of electronic control data flashing tasks corresponding to the vehicle model based on the vehicle model information. The pre-configured set of electronic control data flashing tasks is a collection of flashing tasks pre-defined for multiple electronic control unit types under the vehicle model platform. Each electronic control unit type flashing task includes at least the following task definitions: whether to flash the software package, whether to flash the configuration word, whether to flash the VIN code, and whether to execute calibration items.

[0025] The S3 real-vehicle electronic control data flashing task includes: Parse vehicle configuration words to obtain the actual vehicle model information, and match the corresponding model electronic control data flashing task; The matching vehicle model electronic control data writing tasks are assigned to the relevant workstations on the production line, and the execution order of all tasks at each workstation is set to form the electronic control data writing tasks for the corresponding workstations of the vehicle models. At the same time, the actual assembly status of each electronic control unit is obtained from the vehicle configuration word, and the vehicle model electronic control data writing tasks are filtered based on the actual assembly status.

[0026] In S4, the electronic control unit (ECU) flashing scheme library predefines multiple selectable flashing schemes for each vehicle ECU type; each flashing scheme is associated with a unique ECU attribute constraint. Electronic control attribute constraints are used to limit the specific values ​​of one or more attributes in a predefined set of electronic control unit attributes; For attributes in the electronic control unit attribute set that are not limited by this constraint, it means that any value of the attribute is compatible. The electrical control unit attribute set includes controller type, part number, supplier code, hardware version, and software version attributes.

[0027] The electronic control attribute constraints are divided into multiple specific levels depending on the different attributes being constrained; The specific level includes at least one of the following: The first level specifies the values ​​for controller type, part number, supplier code, hardware version, and software version. The second level specifies the values ​​for controller type, part number, supplier code, and hardware version. The third level specifies the exact values ​​for controller type, part number, and supplier code. The fourth level specifies the exact values ​​for the controller type and part number; The fifth level specifies the exact values ​​that can be taken for the controller type.

[0028] In S4, a specific flashing scheme is matched for each electronic control unit as follows: Taking any one of the electronic control units (ECUs) as the target ECU and matching it with a specific flashing scheme includes: Step S41: In the UDS diagnostic communication session established with the target electronic control unit, obtain the actual attribute values ​​of the target electronic control unit; Step S42: Based on the preset priority matching rules, match the actual attribute values ​​with the predefined electronic control unit flashing schemes associated with the electronic control attribute constraints. Step S43: If the match is successful, select the electronic control unit (ECU) flashing scheme associated with the successfully matched ECU attribute constraint; if the match fails, determine that there is no corresponding ECU flashing scheme.

[0029] In S42, the priority matching rule is: Calculate a priority score for each electronic control attribute constraint; the more attributes that are constrained and the higher the level of the constraint in the concretization hierarchy, the higher the priority score. During matching, the actual attribute values ​​are compared with the attribute values ​​limited by each electronic control attribute constraint condition in descending order of priority score. A match is successful when the actual attribute value matches all the attribute values ​​specified in the current electronic control attribute constraint. This sequential matching follows the principle of stopping when the first match is successful. If all electronic control attribute constraints fail to match, the match fails.

[0030] The electronic control unit (ECU) flashing scheme includes one or more of the following predefined flashing functions: configuration word flashing function, software package flashing function, VIN code flashing function, and calibration function; Among them, the configuration word writing function predefines: the rules for extracting data fields from the vehicle configuration word, and the UDS diagnostic service and address mapping relationship written to the electronic control unit; The software package flashing function predefines the flashing process based on the UDS diagnostic service; The VIN code writing function predefines the relationship between the UDS diagnostic service for writing the VIN code and the address mapping. The calibration function predefines a calibration process based on the UDS diagnostic service.

[0031] The electronic control unit (ECU) testing tasks include testing functions corresponding to each flashing function in the executed flashing scheme; The detection function corresponding to the configuration word writing function is: read the written field through the UDS diagnostic service and compare it with the configuration word source field in the received electronic control writing data for verification; The detection function corresponding to the software package flashing function is: read the version information of the electronic control unit through the UDS diagnostic service and compare and verify it with the software package version in the received electronic control flashing data; The detection function corresponding to the VIN code writing function is: read the written VIN code through the UDS diagnostic service and compare and verify it with the VIN code in the received electronic control writing data.

[0032] The corresponding detection function for the calibration function is: to read the calibration results through the UDS diagnostic service and determine whether the calibration was successful according to the preset calibration verification rules.

[0033] Based on the verification results of the test functions of each electronic control unit, it is determined whether the test of each electronic control unit has passed, and based on the test results of all electronic control units, it is determined whether the test of the whole vehicle has passed. Generate execution records for electronic control data writing and testing, and send back the execution records along with the judgment results of whether each electronic control unit test passed and whether the whole vehicle test passed.

[0034] Example 2 An automatic vehicle off-line electronic control data writing and detection system includes: a vehicle writing and detection device and one or more vehicle electronic control units communicatively connected to the vehicle writing and detection device; the vehicle writing and detection device is used to execute any of the above-mentioned automatic vehicle off-line electronic control data writing and detection methods.

[0035] Example 3 like Figure 1 As shown, this invention is implemented at the final inspection station in the vehicle assembly workshop. Its core physical components include: a vehicle flashing and testing device (an industrial control unit integrating a vehicle bus communication interface, storage unit, and central processing unit) and one or more vehicle electronic control units (ECUs) inside the vehicle. The vehicle flashing and testing device connects to the vehicle network (such as a CAN bus) via a diagnostic interface, establishing UDS diagnostic communication links with each ECU. The device is pre-loaded with a vehicle model ECU data flashing task library, an ECU flashing scheme library, and a software system for implementing priority matching rules. The following embodiment will simulate the complete process of fully automated flashing and testing after a specific vehicle enters the station.

[0036] Basic end-to-end implementation – end-to-end automated operation of a high-spec commercial cargo truck Step S1: Receive electronic control flashing data identified by the vehicle's VIN code. A commercial vehicle with the VIN code "LSVA1234567890ABC" enters the workstation. The vehicle flashing and testing equipment reads the VIN code and uses it as an index to request and receive the corresponding electronic control flashing data from the factory's Manufacturing Execution System (MES). This data packet is a customized integrated data packet for this vehicle, and its contents include the vehicle configuration word, VIN code, software package, and calibration settings.

[0037] Step S2: Based on the vehicle configuration word, parse and determine the vehicle model information and the actual vehicle assembly information of the electronic control unit. The device parses the core of the data packet—the vehicle configuration word. This configuration word is a data sequence formed according to a preset encoding rule, with the content: "Sedan_Mid_EMS: 1, BCM: 1, GW: 1, IVI_High: 1, Sunroof: 0". The parsing rule is predictable: "Sedan_Mid" is parsed as the specific vehicle model information (high-spec commercial truck), "EMS: 1" indicates that the engine controller is actually "assembled", and "Sunroof: 0" indicates that the sunroof controller is not assembled. Through this step, the device accurately obtains the two types of core information required for decision-making: vehicle model information (Sedan_Mid) and a detailed list of actual vehicle assembly information of the electronic control unit.

[0038] Step S3: Generate the actual vehicle electronic control data flashing task. This step enables the dynamic and accurate generation of tasks from the "complete set of vehicle models and platforms" to the "actual vehicle-specific subset".

[0039] 3.1 Matching Vehicle Model Task Set: Based on the vehicle model information "Sedan_Mid", the device matches a set of pre-configured electronic control unit (ECU) data flashing tasks for that vehicle model platform. This set contains flashing tasks for all possible ECU types on the platform, and each task defines whether to flash the software package, configuration word, VIN code, or perform calibration.

[0040] 3.2 Filtering and Generating Real Vehicle Tasks: Next, the equipment simultaneously extracts the actual assembly status from the parsed configuration words and filters the vehicle's electronic control data flashing tasks based on this status. Specifically, the system automatically removes all tasks from the task set that target electronic control units in the "unassembled" state (Sunroof in this example). After filtering, a "Real Vehicle Electronic Control Data Flashing Task" is generated that is fully adapted to this real vehicle, containing only operation instructions for the four actually assembled controllers: EMS, BCM, GW, and IVI_High.

[0041] Step S4: Match a specific flashing scheme to each electronic control unit (ECU). This is the core innovative step, solving the problem of "how to accurately flash and test". Taking the scheme matching the gateway controller (GW) as an example: 4.1 Scheme Library and Constraints: The device accesses the electronic control unit (ECU) flashing scheme library. This library predefines multiple selectable flashing schemes (such as GW_A, GW_B, GW_C) for controllers like "gateways". Each scheme is associated with a unique ECU attribute constraint. This constraint limits the specific values ​​in a predefined set of ECU attribute attributes (including controller type, part number, supplier code, hardware version, and software version attributes). For example: GW_A scheme associated condition: {Controller type: Gateway, Part number: 5WK91234, Supplier code: Conti, Hardware version: H2.1}, GW_B scheme associated condition: {Controller type: Gateway, Part number: 5WK91234, Supplier code: Conti}, GW_C scheme constraint: {Controller type: Gateway}; 4.2 Obtaining Actual Attributes: The device establishes a communication session with the gateway on the actual vehicle through the UDS diagnostic service to obtain its actual attribute values, such as: {Controller type: Gateway, Part number: 5WK91234, Supplier code: Conti, Hardware version: H2.1, Software version: V3.0}.

[0042] 4.3 Priority Matching: The device makes decisions based on preset priority matching rules. These rules calculate a priority score for each electronic control attribute constraint. The score calculation can be based on a predefined function, for example: Score = (Number of Constrained Attributes × Weight A) + (Specification Level Coefficient × Weight B). The more constrained attributes and the higher the specification level coefficient (e.g., GW_A has a higher level than GW_B), the higher the score. During matching, the actual attribute value of the gateway is compared with the attribute values ​​constrained by each scheme in descending order of priority score. First, the system attempts to match the highest-scoring condition, GW_A. If the actual attribute value matches all the attribute values ​​constrained by this condition, the match is successful. The system follows the principle of stopping at the first successful match, immediately selecting the GW_A scheme and terminating subsequent matching. This mechanism ensures that the most specific and suitable scheme is automatically selected for each ECU.

[0043] Step S5: Execute the matched flashing scheme to complete the electronic control unit (ECU) data flashing and perform automated testing based on the flashing scheme. This step achieves an "execution-verification" closed loop based on the same scheme. Execute the flashing function: The selected GW_A scheme is a function package that includes predefined flashing functions, such as configuration word flashing and software package flashing. All operational details of these functions are predefined: the configuration word flashing function predefines the rules for extracting specific fields from the vehicle configuration word and the mapping relationship between the UDS diagnostic service and the address in the ECU; the software package flashing function predefines the complete flashing process based on the UDS diagnostic service. The device executes these predefined functions to complete the data flashing. Generate and execute the testing task: Based on the actual vehicle ECU flashing task, the system automatically generates the corresponding ECU testing task. Crucially, this testing task is executed by calling the testing functions included in the ECU flashing scheme that are matched for the corresponding ECU. This is because the GW_A scheme also includes testing functions that correspond one-to-one with each flashing function. For example, the detection function corresponding to its configuration word flashing function is configured as follows: after flashing, the field already written in the gateway is read through the UDS diagnostic service and compared with the configuration word source field in the received electronic control flashing data for verification. The detection function corresponding to its software package flashing function is configured as follows: the software version information of the gateway after flashing is read through the UDS diagnostic service and compared with the software package version in the received electronic control flashing data for verification.

[0044] Step S6: Result Determination and Record Generation. After all unit tasks are completed: 6.1. Based on the verification results of the detection functions of each electronic control unit, determine whether the detection of each electronic control unit has passed.

[0045] 6.2. Based on the test results of all electronic control units, determine whether the vehicle inspection has passed.

[0046] 6.3 Finally, the system generates execution records for electronic control data writing and detection and sends them back to the MES, achieving data closure. No manual decision-making or intervention is required throughout the entire process.

[0047] Example 4 In-depth analysis of intelligent decision-making and fault tolerance in solution matching: This embodiment aims to further clarify the intelligence and robustness of priority matching rules when facing differences in ECU attributes. Assume that for the Body Control Controller (BCM), the solution library contains: 1. Solution BCM_1: Associated conditions {Controller type: BCM, Part number: 1K0937123F, Supplier code: VW, Hardware version: H10} (High specification level).

[0048] 2. Scheme BCM_2: Associated conditions {Controller type: BCM, Part number: 1K0937123F, Supplier code: VW} (middle materialization level).

[0049] 3. Scheme BCM_3: Associated condition {Controller type: BCM} (low materialization level).

[0050] Scenario A: Exact Match (Ideal Situation). If the actual BCM attributes read from the vehicle are {Controller Type: BCM, Part Number: 1K0937123F, Supplier Code: VW, Hardware Version: H10, Software Version: 1234}. Matching Process: Condition BCM_1 receives the highest score due to having the most limiting attributes and is matched first. If the vehicle attributes completely match all attribute values ​​limited by this condition, the match is successful, and the system selects the BCM_1 solution.

[0051] Scenario B: Downgraded Matching (Addressing Supply Chain Differences). If, due to minor supply chain adjustments, the actual vehicle BCM hardware version changes to H11, its actual attributes are {Controller Type: BCM, Part Number: 1K0937123F, Supplier Code: VW, Hardware Version: H11, ...}. The matching process then becomes: 1. Attempt to match BCM_1: Matching failed because the actual hardware version (H11) does not match the condition limit value (H10).

[0052] 2. The system automatically attempts the next priority BCM_2. BCM_2 conditions only specify type, part number, and supplier; the actual attributes perfectly match across these three dimensions, resulting in a successful match. The system then selects the BCM_2 solution. This scenario perfectly demonstrates the fault tolerance and practicality of the matching rules: when no perfectly matching solution exists, the system can automatically "downgrade" and select the most specific and usable compatible solution under the current conditions, ensuring the continuity of the production process. It also reflects the design philosophy that "unrestricted attributes are compatible with any value."

[0053] Example 5 Demonstrating system flexibility—adapting to diverse configurations and collaborating with production line workstations: Scenario A: Adapting to personalized vehicle configuration (an extension of dynamic task generation). Following Example 3, when the next vehicle on the same platform but with a higher configuration enters, its vehicle configuration word is resolved as "Sedan_High_EMS: 1, BCM: 1, GW: 0, IVI_High: 1, Sunroof: 1, ...". In the step of generating the real vehicle electronic control data flashing task, the system will automatically include the sunroof controller flashing task in the final task list because the Sunroof status is "installed (1)". This intuitively demonstrates how the present invention can easily support flexible production of "one vehicle, one order".

[0054] Scenario B: Adapting to Production Line Off-Line Processes and Multi-Station Collaboration. On complex assembly lines, data flashing work is often broken down into different stations according to the production line's off-line process. Based on this process, the flashing tasks for the "Sedan_Mid" model have been pre-assigned to relevant stations, and the execution order has been set, forming the electronic control data flashing tasks for the corresponding station for each model. For example: Station 1 Task Table (Electronic Control Data Flashing Tasks for the Corresponding Station for the Model): Responsible for flashing and testing EMS, GW, IVI_High, and Sunroof. When the vehicle in Example 3 arrives at workstation 1, after generating the "real vehicle electronic control data writing task" (with EMS, BCM, IVI_High, but without GW and Sunroof) for the vehicle, the equipment performs a logical "intersection" operation: based on the real vehicle electronic control data writing task and the electronic control data writing task of the corresponding workstation for the vehicle model, it generates the final writing task to be performed at that workstation. Ultimately, the equipment at workstation 1 only performs the writing and detection of EMS and IVI_High. This achieves precise scheduling and efficient parallelism of tasks in the production line space, which is a key manifestation of the adaptability of the method of this invention to complex production scenarios.

[0055] In summary, through the step-by-step unfolding of the above specific embodiments, the present invention clearly and completely reveals how it works collaboratively through three core mechanisms: "Vehicle configuration characters" drive dynamic task generation, solving the problem of "what to flash" and achieving flexible adaptation; "Multi-level electronic control attribute constraints and priority matching rules" drive intelligent optimal selection of the solution, solving the problem of "how to flash precisely" and achieving accurate compatibility; "Deep binding of flashing and detection functions to the same solution" enables integrated operation and real-time verification, solving the problem of "how to reliably verify" and forming a quality closed loop.

Claims

1. A method for automatically writing and detecting electronic control data after a vehicle rolls off the production line, characterized in that, include: S1, receives electronic control flashing data identified by the VIN code of the target vehicle; S2, based on the vehicle configuration words in the electronic control data, parse and determine the vehicle model information and the actual vehicle assembly information of the electronic control unit of the target vehicle; S3. Based on the vehicle model information, match the predefined vehicle model electronic control data flashing task, and filter it in combination with the actual vehicle assembly information to generate the actual vehicle electronic control data flashing task for the target vehicle. S4. Based on the predefined electronic control unit flashing scheme library and matching rules, a specific flashing scheme is matched for each electronic control unit in the actual vehicle electronic control data flashing task. S5, execute the matched flashing scheme to complete the electronic control data flashing; and automatically generate a corresponding electronic control unit detection task for each electronic control unit according to the flashing scheme; S6, Generate and return the execution record of electronic control data writing and electronic control unit detection; The electronic control data includes one or more of the following: vehicle configuration characters, VIN code, software package, and calibration settings. The vehicle configuration word is a data sequence formed by encoding actual vehicle assembly information and functional information according to preset rules. The data sequence includes at least the vehicle model information of the target vehicle and the actual assembly status of each electronic control unit in the target vehicle. The vehicle model electronic control data flashing task is to retrieve a pre-configured electronic control data flashing task set corresponding to the vehicle model based on the vehicle model information; wherein, the pre-configured electronic control data flashing task set is a collection of flashing tasks pre-defined for multiple electronic control unit types under the vehicle model platform; each electronic control unit type flashing task includes at least the following task definitions: whether to flash the software package, whether to flash the configuration word, whether to flash the VIN code, and whether to execute calibration items.

2. The automatic writing and detection method for vehicle off-line electronic control data according to claim 1, characterized in that, The real vehicle electronic control data flashing task in S3 includes: Parse vehicle configuration words to obtain the actual vehicle model information, and match the corresponding model electronic control data flashing task; The matching vehicle model electronic control data writing tasks are assigned to the relevant workstations on the production line, and the execution order of all tasks at each workstation is set to form the electronic control data writing tasks for the corresponding workstations of the vehicle models. At the same time, the actual assembly status of each electronic control unit is obtained from the vehicle configuration word, and the vehicle model electronic control data writing tasks are filtered based on the actual assembly status.

3. The automatic writing and detection method for vehicle off-line electronic control data according to claim 1, characterized in that, In step S4, the electronic control unit flashing scheme library predefines multiple selectable flashing schemes for each type of vehicle electronic control unit; each flashing scheme is associated with a unique electronic control attribute constraint. The electronic control attribute constraint is used to limit the specific values ​​of one or more attributes in a predefined set of electronic control unit attributes; For attributes in the electronic control unit attribute set that are not limited by this constraint, it means that any value of the attribute is compatible. The electrical control unit attribute set includes controller type, part number, supplier code, hardware version, and software version attributes.

4. The automatic writing and detection method for vehicle off-line electronic control data according to claim 1, characterized in that, The electronic control attribute constraints are divided into multiple specific levels according to the different attributes being constrained; The specificity level includes at least one of the following: The first level specifies the values ​​for controller type, part number, supplier code, hardware version, and software version. The second level specifies the values ​​for controller type, part number, supplier code, and hardware version. The third level specifies the exact values ​​for controller type, part number, and supplier code. The fourth level specifies the exact values ​​for the controller type and part number; The fifth level specifies the exact values ​​that can be taken for the controller type.

5. The automatic writing and detection method for vehicle off-line electronic control data according to claim 1, characterized in that, The specific flashing scheme matched for each electronic control unit in S4 is as follows: Taking any one of the electronic control units (ECUs) as the target ECU and matching it with a specific flashing scheme includes: Step S41: In the UDS diagnostic communication session established with the target electronic control unit, obtain the actual attribute values ​​of the target electronic control unit; Step S42: Based on the preset priority matching rules, match the actual attribute values ​​with the predefined electronic control unit flashing schemes associated with the electronic control attribute constraints. Step S43: If the match is successful, select the electronic control unit (ECU) flashing scheme associated with the successfully matched ECU attribute constraint; if the match fails, determine that there is no corresponding ECU flashing scheme.

6. The automatic writing and detection method for vehicle off-line electronic control data according to claim 1, characterized in that, In S42, the priority matching rule is as follows: Calculate a priority score for each electronic control attribute constraint; the more attributes that are constrained and the higher the level of the constraint in the specification level, the higher the priority score. During matching, the actual attribute values ​​are compared with the attribute values ​​defined by each electronic control attribute constraint condition in descending order of priority score. A match is successful when the actual attribute value matches all attribute values ​​specified in the current electronic control attribute constraint. This sequential matching follows the principle of stopping when the first match is successful. If all electronic control attribute constraints fail to match, the match fails.

7. The automatic writing and detection method for vehicle off-line electronic control data according to claim 6, characterized in that, The electronic control unit (ECU) writing scheme includes one or more of the following predefined writing functions: configuration word writing function, software package writing function, VIN code writing function, and calibration function; The configuration word writing function predefines the rules for extracting data fields from the vehicle configuration word, as well as the UDS diagnostic service and address mapping relationship written to the electronic control unit. The software package flashing function predefines a flashing process based on the UDS diagnostic service. The VIN code writing function predefines the UDS diagnostic service and address mapping relationship for writing the VIN code. The calibration function predefines a calibration process based on UDS diagnostic services.

8. The automatic writing and detection method for vehicle off-line electronic control data according to claim 1, characterized in that, The electronic control unit detection task includes detection functions corresponding to each flashing function in the executed flashing scheme; The detection function corresponding to the configuration word writing function is: to read the written field through the UDS diagnostic service and compare it with the configuration word source field in the received electronic control writing data for verification; The detection function corresponding to the software package flashing function is: to read the version information of the electronic control unit through the UDS diagnostic service and compare and verify it with the software package version in the received electronic control flashing data; The detection function corresponding to the VIN code writing function is: to read the written VIN code through the UDS diagnostic service and compare and verify it with the VIN code in the received electronic control writing data; The detection function corresponding to the calibration function is: to read the calibration result through the UDS diagnostic service and determine whether the calibration is successful according to the preset calibration verification rules.

9. The automatic writing and detection method for vehicle off-line electronic control data according to claim 8, characterized in that, Based on the verification results of the test functions of each electronic control unit, it is determined whether the test of each electronic control unit has passed, and based on the test results of all electronic control units, it is determined whether the test of the whole vehicle has passed. The execution record of electronic control data writing and testing is generated, and the execution record, along with the judgment results of whether each electronic control unit test and the whole vehicle test are passed, are sent back together.

10. A vehicle off-line electronic control data automatic writing and detection system, characterized in that, include: A vehicle flashing and testing device and one or more vehicle electronic control units that are communicatively connected to the vehicle flashing and testing device; The vehicle data writing and detection equipment is used to perform the automatic data writing and detection method for vehicle off-line electronic control data as described in any one of claims 1-9.

Images