ECU power-on programming test monitoring integrated system and method based on digital twinning

Abstract

The application relates to the technical field of ECU testing, and discloses an ECU power-on programming test monitoring integrated system and method based on digital twinning. The system comprises a test environment division module, a state tracking module, an abnormality detection module, a test strategy adjustment module, a task allocation module, a scheme evaluation module and an execution control module. The test environment division module divides test areas; the state tracking module determines the real-time working state of the ECU based on digital twinning; the abnormality detection module identifies abnormal events; the test strategy adjustment module determines the test execution priority level; the task allocation module designs a test scheme; the scheme evaluation module calculates a scheme execution priority value; and the execution control module selects the optimal scheme and controls execution. The system can optimize the test environment layout, track the ECU state in real time, identify abnormalities in a timely manner, dynamically adjust the test strategy, automatically select the optimal scheme, improve the order, efficiency and quality of the test, and is suitable for the ECU power-on programming test scene.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of ECU test, in particular to an ECU power-on programming test monitoring integrated system and method based on digital twinning. BACKGROUND

[0002] With the rapid development of automotive electronics technology, electronic control units (ECUs) are increasingly widely used in automobiles, and their functions are becoming more and more complex. ECU needs to go through strict power-on programming test in the production process to ensure its performance and reliability meet the design requirements. At present, the traditional ECU power-on programming test system mostly adopts a decentralized test mode, the test environment is not reasonably divided, and different test tasks are cross-performed in the same space, which is prone to test resource conflict, resulting in low test efficiency.

[0003] In terms of ECU state monitoring, the traditional system usually relies on a single sensor to collect data, which is difficult to comprehensively and real-time grasp the working state of all ECUs. When an ECU appears abnormal, the staff often cannot detect it in time, and can only analyze it through data playback after the test is completed, which not only prolongs the troubleshooting time, but also may cause unqualified ECUs to flow into the subsequent links, increasing production costs.

[0004] The test strategy adjustment of the traditional test system lacks flexibility. In the test process, if abnormal events occur in the test environment, such as voltage fluctuation, temperature anomaly, etc., the system cannot dynamically adjust the test execution priority according to the real-time situation, and still carries out the test according to the preset fixed process, which may cause some key test tasks to be delayed, affecting the overall test progress. At the same time, in the test scheme formulation and selection, the traditional way mostly relies on manual experience, and the staff needs to manually design the test scheme according to the test environment layout and task requirements, which not only consumes time and effort, but also is difficult to comprehensively consider various factors, resulting in the selected test scheme not being the optimal one, further reducing the test efficiency and test quality.

[0005] With the continuous increase of ECU production and the diversification of test demand, the traditional test system has been difficult to meet the requirements of large-scale, high-efficiency and high-precision test, and an integrated system is needed to realize the reasonable division of test environment, real-time tracking of ECU state, timely detection of abnormal events, dynamic adjustment of test strategy and automatic selection of optimal test scheme, in order to solve many problems existing in the current ECU power-on programming test process. SUMMARY

[0006] The purpose of the present application is to provide an ECU power-on programming test monitoring integrated system and method based on digital twinning to solve the problems raised in the background.

[0007] In order to achieve the above object, the application provides an ECU power-on programming test monitoring integrated system based on digital twinning, which comprises:

[0008] A test environment division module is configured to obtain layout information of the ECU power-on programming test environment and divide the ECU power-on programming test environment into several test areas.

[0009] A state tracking module is configured to determine the real-time working states of all ECUs based on the digital twinning system.

[0010] An abnormality detection module is configured to identify abnormal events in the test environment based on the test data collected by the monitoring devices of all ECUs.

[0011] A test strategy adjustment module is configured to determine the test execution priority levels of the test areas in the test environment based on the abnormal events in the test environment and the real-time working states of all ECUs.

[0012] A task allocation module is configured to determine the starting conditions of the test tasks and the target conditions of the test tasks, determine at least one test scheme based on the layout information of the ECU power-on programming test environment.

[0013] A scheme evaluation module is configured to calculate the execution priority values of each test scheme based on the test execution priority levels of the test areas in the test environment.

[0014] An execution control module is configured to select the test scheme with the largest execution priority value as the optimal test scheme, issue a control instruction, and control the test system to execute the optimal test scheme.

[0015] Preferably, the state tracking module comprises:

[0016] A digital twinning construction unit is configured to construct a digital twinning model based on the ECU power-on programming test environment.

[0017] A digital twinning interaction unit is configured to receive synchronization data sent by the digital twinning model and analyze the state information contained in the synchronization data.

[0018] A state calculation unit is configured to calculate the state difference between the ECU and the reference point in the digital twinning model based on the analyzed state information.

[0019] A position mapping unit is configured to map the actual state of the ECU in the test environment based on the state of the reference point in the digital twinning model and the calculated state difference.

[0020] Preferably, the step of constructing a digital twin model by the digital twin construction unit comprises:

[0021] acquiring physical layout information of an ECU power-on programming test environment and attribute parameters of test equipment;

[0022] establishing a virtual test environment three-dimensional model corresponding to the physical test environment based on the physical layout information and the attribute parameters of the test equipment;

[0023] defining ECU working state parameters, test flow logic parameters, and environment monitoring parameters in the virtual test environment three-dimensional model;

[0024] establishing a real-time data bidirectional transmission channel between sensor devices in the physical test environment and the virtual test environment three-dimensional model;

[0025] acquiring actual test data through the real-time data synchronization interface unit, and continuously comparing the running state difference between the physical test environment and the virtual test environment three-dimensional model;

[0026] real-time correcting parameters and logic rules in the virtual test environment three-dimensional model according to the running state difference, to form a digital twin model that is synchronized with the physical test environment.

[0027] Preferably, the abnormality detection module comprises:

[0028] a data acquisition unit, configured to acquire multi-dimensional performance parameters of an ECU in a test process through a monitoring device;

[0029] a feature extraction unit, configured to extract key feature indicators from the multi-dimensional performance parameters;

[0030] an abnormality determination unit, configured to compare the key feature indicators with preset standard indicator ranges, and mark test data that exceeds the standard indicator ranges as abnormal data;

[0031] an event confirmation unit, configured to aggregate abnormal data positions identified in all ECU test processes, and determine whether there are at least two ECUs that identify abnormal data at the same test position, and if so, determine that there is a fixed abnormal event at the test position.

[0032] Preferably, the test strategy adjustment module comprises:

[0033] a parallel capability analysis unit, configured to determine the number of test tasks that can be processed in parallel at each test point in a test area based on abnormal events in the test environment;

[0034] a region capability evaluation unit, configured to calculate a parallel processing capability index of the test region based on a maximum number of test tasks simultaneously and in parallel processed by each test point in the test region and a total length of test paths in the test region;

[0035] a comprehensive priority calculation unit, configured to comprehensively calculate a test execution priority level of each test region based on the parallel processing capability index of the test region and real-time working states of all ECUs.

[0036] Preferably, the task allocation module comprises:

[0037] a condition analysis unit, configured to analyze a starting condition of the test task and a target condition of the test task;

[0038] a path generation unit, configured to generate at least one test path as a test scheme based on layout information of the ECU in-circuit programming test environment.

[0039] Preferably, the scheme evaluation module comprises:

[0040] a path analysis unit, configured to determine a length of the test scheme passing through each test region;

[0041] an index calculation unit, configured to multiply the length of the test scheme passing through the test region and the test execution priority level of the test region to obtain an execution index of the test scheme in the test region;

[0042] a priority summary unit, configured to accumulate and sum the execution indexes of the test scheme in all test regions to obtain an execution priority value of the test scheme.

[0043] Preferably, the execution control module comprises:

[0044] a scheme selection unit, configured to compare the execution priority values of all test schemes and select a test scheme with a maximum execution priority value;

[0045] an instruction generation unit, configured to generate a control instruction according to the optimal test scheme;

[0046] an execution management unit, configured to dispatch test resources according to the control instruction to control the test process to be executed according to the optimal test scheme.

[0047] Preferably, the system further comprises:

[0048] a log recording module, configured to record all operation instructions and execution results in the test process.

[0049] a report generation module for generating a test report based on the test execution result and the recorded log data.

[0050] Preferably, the application also includes a digital twin-based ECU power-on programming test monitoring integrated method, including all modules and method processes of the digital twin-based ECU power-on programming test monitoring integrated system.

[0051] Compared with the prior art, the application has the beneficial effects that:

[0052] The digital twin-based ECU power-on programming test monitoring integrated system can obtain the layout information of the ECU power-on programming test environment and divide it into several test areas through the test environment division module, effectively avoiding resource conflict problems caused by different test tasks being performed in the same space, making the test environment layout more reasonable, and each test area can independently carry out test work, reducing the mutual interference between test tasks, and helping to improve the orderliness of the overall test process.

[0053] The state tracking module determines the real-time working state of all ECUs based on the digital twin system. Compared with the traditional method of relying on a single sensor to collect data, the digital twin technology can integrate multi-dimensional monitoring data and construct a virtual mapping model of the ECU. The working staff can intuitively and comprehensively understand the working state of each ECU, including the real-time changes of key parameters such as voltage, current, and temperature, without waiting for the test to be completed for data playback analysis, and can timely find abnormal signs of the ECU working state, thus gaining time for subsequent abnormal processing.

[0054] The abnormality detection module identifies abnormal events in the test environment based on the test data collected by the monitoring devices of all ECUs, which can cover various abnormal situations in the test process, such as test equipment failure and abnormal environmental parameters. Through comprehensive analysis of multi-source test data, the accuracy of abnormal event identification is improved, avoiding misjudgment or omission caused by a single data source, ensuring that abnormal events can be discovered in time, thus reducing the adverse effects on test results caused by abnormal events not being handled in time.

[0055] The test strategy adjustment module determines the test execution priority level of each test area based on the abnormal events and the real-time working state of the ECUs, making the test strategy adjustment more targeted and flexible. When the test environment is abnormal or the working state of the ECUs changes, the system can dynamically adjust the priority level of different test areas, allocate test resources to key test tasks in priority, avoid delaying key tasks due to insufficient resources, and ensure that the overall test progress proceeds according to the plan.

[0056] The task allocation module determines the starting condition, target condition of the test task, and designs at least one test scheme based on the test environment layout information, without manual design by the staff, reduces manual intervention, reduces the labor intensity of the staff, and at the same time, can fully combine the test environment layout characteristics to design a more actual test demand scheme, avoiding the unreasonable scheme caused by insufficient experience or incomplete consideration when manually designing the scheme.

[0057] The scheme evaluation module calculates the execution priority value of each test scheme based on the test execution priority level of each test area, provides an objective and quantitative basis for the selection of the test scheme, replaces the traditional scheme selection method relying on manual experience, can more comprehensively consider various influencing factors in the test process, and ensures that the selected scheme has more advantages in priority matching degree.

[0058] The execution control module selects the test scheme with the largest execution priority value as the optimal test scheme, and issues a control instruction to control the test system to execute, realizes automatic selection and execution of the optimal test scheme, does not need manual judgment and operation, further improves the test efficiency, and at the same time, the execution of the optimal test scheme can ensure that the test task is completed in a more efficient and reasonable way, helps to improve the test quality, reduces the possibility of unqualified ECUs flowing into the subsequent link, reduces the production cost, and meets the demand of large-scale ECU power-on programming test. BRIEF DESCRIPTION OF DRAWINGS

[0059] Figure 1 is a working principle diagram of the ECU power-on programming test monitoring integrated system based on digital twinning provided by the application;

[0060] Figure 2 is a working principle diagram of the state tracking module;

[0061] Figure 3 is a working principle diagram of the abnormality detection module;

[0062] Figure 4 is a working principle diagram of the task allocation module. DETAILED DESCRIPTION

[0063] The technical solutions in the embodiments of the application will be described clearly and completely below with reference to the drawings in the embodiments of the application. Obviously, the described embodiments are only part of the embodiments of the application, rather than all the embodiments. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative labor fall within the protection scope of the application.

[0064] Please refer to Figure 1 The application provides an ECU power-on programming test monitoring integrated system and method based on digital twinning. The system comprises:

[0065] The test environment division module obtains layout information of the ECU power-on programming test environment and divides the test environment into several test areas. The state tracking module determines the real-time working state of all ECUs based on the digital twin system. The anomaly detection module identifies abnormal events in the test environment based on the test data collected by the monitoring device. The test strategy adjustment module determines the test execution priority level of each test area based on the abnormal events and the real-time working state of the ECUs. The task allocation module determines the starting condition and target condition of the test task and generates at least one test scheme based on the layout information. The scheme evaluation module calculates the execution priority value of each test scheme based on the test execution priority level. The execution control module selects the test scheme with the largest execution priority value as the optimal test scheme and issues a control instruction to control the test system to execute the optimal scheme.

[0066] Embodiment 1: refer to Figure 2 The digital twin technology accurately maps and tracks the real-time state of all ECUs in the physical test environment, and its construction begins with the digital twin construction unit. This unit first collects the physical layout information of the ECU power-on programming test environment, including the geometric distribution of the test bench, the spatial position of the power supply and data interface, the wiring path of the cable, and the physical structure of the cooling system. At the same time, it obtains the attribute parameters of the test equipment, such as the firmware version of the programmer, the communication protocol type, the output specification of the power module, and the speed curve of the cooling fan. These physical information and equipment parameters are input into a three-dimensional modeling software to construct a virtual test environment three-dimensional model that has strict geometric and functional correspondence with the real environment. In this virtual model, every physical entity, from the tiny interface to the whole test bench, is given an accurate digital representation.

[0067] On the basis of the virtual model, a series of parameters need to be defined to drive the model's operation. The ECU working state parameters include its voltage value, current value, core temperature, memory usage, and the current stage of the firmware being burned. The test flow logic parameters define the sequence of steps in the burning process, such as the conditions and jump rules for the power-on self-test, firmware transmission, checksum verification, and restart. The environmental monitoring parameters cover external factors that may affect the test process, such as environmental temperature, humidity, and electromagnetic interference strength. These parameters make the virtual model no longer a static geometric structure, but a dynamic system that can simulate the real test process. To achieve synchronization between the physical and virtual worlds, a bidirectional data channel needs to be established. Sensors in the physical test environment, such as voltage probes, current clamps, thermocouples, and cameras, continuously collect data. These data are transmitted in real time to the virtual model through industrial networks such as Ethernet or CAN bus. At the same time, the instructions or state predictions calculated in the virtual model, such as adjusting the output of a power module to respond to a simulated voltage drop, can also be sent back to the actuators in the physical environment. This bidirectional channel ensures a closed loop of data flow.

[0068] The digital twin interaction unit is responsible for handling this data flow. It continuously listens for synchronization data packets from the digital twin model, which are usually in a structured format such as JSON or ProtocolBuffers, encapsulating timestamps, device identifiers, and various state information. The unit parses the data packets and extracts key state information such as "the current core temperature of ECU_001 is 65.3 degrees Celsius" or "burner_002 is currently in the firmware transmission state, with a completion percentage of 78%". The parsed information is converted into standardized data structures that the system can handle. The state calculation unit receives these parsed state information, and its responsibility is to compare the physical ECU's state with the reference state preset in the digital twin model. For example, for a certain ECU, the reference point in the model may set its standard current to be 2.0A±0.1A at the 5th second after power-on. The state calculation unit will obtain the actual current reading of the ECU at the same time, and calculate the deviation from the reference value. This difference calculation covers all key parameters, including timing, voltage, temperature, and progress. The calculation result is a series of quantitative difference values, accurately describing the degree of deviation between the physical object and the ideal model.

[0069] With these calculated state discrepancies, the position mapping unit takes the ideal state of the reference point in the digital twin model as the absolute benchmark, and reverses the mapping of the calculated discrepancy values back to the physical space. For example, if the model shows that a certain ECU should be located in slot 3 of test bench A, and its temperature discrepancy value is +5°C, then the position mapping unit will not only confirm the location of the ECU in the physical world, but also update its state to "located in bench A-slot 3, temperature abnormally high by 5°C". This process realizes the accurate mapping from virtual coordinates to physical coordinates, and fuses the state discrepancy with specific location information, finally outputting the actual state panorama of each ECU in the test environment. The entire process from data collection, transmission, analysis, calculation to mapping constitutes a continuously running closed loop, enabling the digital twin system to dynamically and realistically reflect the ever-changing physical test environment.

[0070] Embodiment 2: Referring to Figure 3 Through a systematic data processing flow, abnormal events occurring in the test environment are identified, and its operation begins with the data acquisition unit, which obtains multi-dimensional performance parameters generated during the ECU test process through monitoring devices deployed at various locations in the test environment. These monitoring devices include high-precision digital multimeters, current probes, infrared thermal imagers, digital storage oscilloscopes, and protocol analyzers. For example, at the power input end of the ECU, the digital multimeter samples the voltage value at millisecond intervals; on the communication line, the protocol analyzer captures CAN bus or Ethernet data packets, records the transmission rate, error rate, and packet loss; the thermal imager non-contact monitors the ECU surface temperature distribution. All collected raw data, including voltage waveforms, current readings, temperature heat maps, and digital signal sequences, are time-stamped and device-identified, transmitted to the central processing system through data acquisition cards and industrial networks. The data acquisition unit needs to process the massive asynchronous data streams generated by different sensors, buffer, align, and preliminarily format them, forming a multi-channel data stream with a unified time reference.

[0071] The feature extraction unit receives the time series data of these multi-dimensional performance parameters, which extracts the key feature indicators representing the working status of the ECU from the raw data using digital signal processing techniques. For voltage and current signals, it calculates their DC components, effective values of AC ripple, peak coefficients, and short-term fluctuation trends. For temperature data, it extracts the temperature rise slope, local hotspot temperature difference, and temperature distribution uniformity indicators. For communication data, it analyzes the jitter of message intervals, the occurrence pattern of error frames, and the frequency of retransmission requests. The feature extraction process is not a simple statistics, but applies algorithms such as sliding window filtering, fast Fourier transform, wavelet packet analysis, etc. to mine data connotation from both time and frequency domains. For example, an FFT transform on a 10-second voltage sampling window can extract the amplitude of the 50Hz power frequency interference, which may indicate the status of the power filter. All extracted feature indicators are organized into structured feature vectors, each corresponding to a performance snapshot of a specific ECU in a specific time period.

[0072] The anomaly determination unit receives these feature vectors, which internally stores pre-set standard indicator ranges based on the technical specifications of ECU models, statistical distributions of historical test data, and reliability engineering requirements. For example, the core voltage standard range of a certain type of ECU during the burning stage may be set to 3.3V ± 5%, the communication error rate threshold to 10^{-8}, and the maximum allowed temperature rise rate to 5°C / min. The anomaly determination unit compares the real-time extracted feature indicators with the corresponding standard ranges item by item. The comparison logic is not a simple threshold judgment, but combines statistical process control methods, such as calculating the Z-score of the indicators or using control charts based on moving range. When a certain feature indicator continuously exceeds the control limit, or although within the limit but shows an abnormal trend (such as 7 consecutive points rising), the data point will be marked as abnormal. The marked information includes the type of anomaly, the degree of deviation, the time stamp of occurrence, and the involved ECU identifier. All anomaly markers are stored in a real-time updated anomaly log database.

[0073] The event confirmation unit monitors the entire exception log database, focusing not only on individual ECU exceptions, but also on analyzing the spatial distribution patterns of exception data. This unit maintains a map of the test environment, where each test site (such as a specific programming station, power output port, or communication switch interface) has a unique identifier. When a new entry appears in the exception log, the event confirmation unit analyzes the physical location where the exception occurred. For example, if the exception data comes from an ECU connected to test bench A port 3, the exception is mapped to the location "bench A - port 3". The unit continuously scans the database for location correlations. It uses a sliding statistical method based on a time window: if, within the last 5-minute time window, two or more different ECUs at the same physical location (such as "bench A - port 3") have generated the same type of exception data (such as a communication timeout error), the unit determines that there is a fixed exception event at that location. The event confirmation unit generates an exception event report, detailing the event location, exception type, involved ECU list, start time, and ongoing status. This report is pushed to the test strategy adjustment module, triggering a system alarm to notify the operator. The entire exception detection process, from data collection to event confirmation, forms a multi-level, closed-loop monitoring system that can effectively distinguish between random occasional exceptions and systematic fixed faults, providing decision-making basis for dynamic adjustment of the test process.

[0074] Example 3: refer to Figure 4 The test strategy adjustment module is composed of a parallel capability analysis unit, a regional capability evaluation unit, and a comprehensive priority calculation unit. The parallel capability analysis unit receives exception event reports from the exception detection module. This unit maintains a test environment topology map, marking all test sites and their connection relationships. When an exception event report is received, such as "test bench B - power port 2 has a voltage fluctuation exception", the unit evaluates the impact of this exception on the parallel processing capability of related test sites. It analyzes the hardware resource configuration of each site, including the number of available programmers, the number of power output ports, communication bandwidth, and cooling capacity. At the same time, it considers the functional degradation that may be caused by the exception event, such as an exception in a power port that may prevent two programming channels that rely on it from working at full power simultaneously. Through comprehensive analysis of resource availability and the degree of exception impact, the unit calculates the maximum number of test tasks that each test site can safely and stably process in parallel under the current state. This number is a dynamic value that adjusts with changes in the environment state.

[0075] The zone capability evaluation unit works based on the output of the parallel capability analysis unit, which acquires the maximum number of parallel tasks for each test site, and extracts the physical path information of each test zone from the test environment model. This unit calculates a parallel processing capability index reflecting the overall efficiency of the zone, taking into account the parallel capability of the site and the physical size of the zone. The calculation expression of this index is:

[0076] ;

[0077] Wherein: represents the parallel processing capability index of the test zone, the larger the value, the stronger the overall processing capability of the zone. represents the total number of test sites contained in the test zone. represents the maximum number of test tasks that can be simultaneously processed by the ith test site in the zone, which is provided by the parallel capability analysis unit. represents the total length of the path required to complete all test procedures in the test zone, which can be the physical distance or the time cost. is an adjustment index, used to control the weight of the number of parallel tasks in the index, usually taking a value between 1 and 2. is an adjustment index, used to control the influence of path length in the index, usually taking a value between 0.5 and 1. This calculation method reflects the balance between the ability to handle multiple tasks simultaneously and the operating efficiency of the test zone.

[0078] The comprehensive priority calculation unit receives the parallel processing capability index data of all test areas, and obtains the real-time working state information of the ECUs provided by the state tracking module. The ECU state information includes the current state of each ECU, such as idle, busy, fault or completion, and the current test progress percentage. The unit calculates the test execution priority level of each test area using a multi-factor weighted algorithm. The algorithm considers the following factors: the parallel processing capability index value of the area, the proportion of currently idle ECUs in the area, the average test progress of ECUs in the area, and the distance between the area and the abnormal point. Each factor is assigned a weight coefficient, and these coefficients can be adjusted according to the test strategy focus. For example, if the completion efficiency is valued, the parallel processing capability index weight is higher; if risk avoidance is valued, the weight of the distance from the abnormal point is higher. The weighted sum of all factors constitutes the final priority level of the area, and the higher the level value, the higher the priority of the area for arranging test tasks. The task allocation module closely cooperates with the test strategy adjustment module, and its condition analysis unit is responsible for analyzing the starting conditions and target conditions of the test task. The starting conditions include the environmental state required when the test task starts, such as temperature range, voltage stability requirement, required burner type and protocol version. The target conditions include the state that needs to be reached when the test is completed, such as passing the firmware checksum and verification, completing the function test, and correctly outputting all diagnostic codes. The condition analysis unit converts these conditions into specific resource demand constraints and completion standards.

[0079] The path generation unit is based on the detailed layout information of the ECU power-on programming test environment, including the three-dimensional coordinates of the test bench, the wiring path of the connection cable, the movement channel of the transfer robot, and the location of the safety isolation area. The unit uses a path search algorithm to find all possible paths from the physical location corresponding to the starting condition to the target condition. Each path needs to satisfy the following constraints: avoiding the currently existing abnormal area, meeting the kinematics limit of the transfer equipment, and satisfying the time sequence requirement of the test process. For a complex test environment, the path generation unit generates multiple alternative paths, each path representing a complete test scheme, including the movement sequence of the ECU, the use order of the test points, and the estimated time consumption of each step. These schemes are passed to the scheme evaluation module for further processing. The whole implementation process embodies the dynamic adjustment characteristics of the test strategy, which can optimize resource allocation and task execution order in real time according to the changes in the environment state.

[0080] Embodiment 4: The scheme evaluation module receives multiple sets of test schemes from the task allocation module, and execution priority data of each test area from the test strategy adjustment module. The path analysis unit of this module first parses each test scheme to determine the specific path trajectory of each test area passed by the scheme. This analysis not only considers the simple geometric path length, but also takes into account the switching time of test equipment between different areas, signal transmission delay, and equipment warm-up time and other timing factors. For example, a test scheme may require the ECU to start from the preprocessing area, pass through the power stability test area, firmware burning area, function verification area in turn, and finally reach the finished product output area. The path analysis unit will accurately calculate the residence time and operation distance of the scheme in each area, and quantify these time and distance into a unified "area length" metric value.

[0081] The index calculation unit then works, which multiplies the length value of each test scheme in a specific test area with the current test execution priority of the area to obtain the execution index of the scheme in the area. This calculation process reflects the difference in the contribution of different areas to the overall test efficiency: even if the path length is short, the execution index of a high-priority area may be high; while a low-priority area may have a relatively limited contribution to the overall index even if the path is long. This calculation method ensures that the evaluation of test schemes can reflect the actual state and priority distribution of the current test environment. The priority aggregation unit is responsible for accumulating and summing all area execution indexes of each test scheme to obtain the final execution priority value of the scheme. This aggregation process is not a simple arithmetic addition, but takes into account the timing dependency and resource conflict probability between areas. For example, two schemes may have the same index sum, but one scheme needs to use two areas with resource competition in sequence, while the other scheme uses areas without competition between them, and the latter may be assigned a higher priority value.

[0082] The scheme selection unit of the execution control module receives all test schemes and their calculated execution priority values, and this unit sorts these schemes using a comparison algorithm, and selects the scheme with the highest execution priority value as the optimal test scheme. In the selection process, not only the numerical value is considered, but also the feasibility risk of the scheme is evaluated, such as checking whether the scheme avoids known abnormal areas and whether it meets all the capacity limits of the test equipment. The instruction generation unit converts the selected optimal test scheme into a specific set of control instructions. These instructions include device control instructions such as adjusting power parameters, selecting burning program versions, and setting test thresholds; mechanical motion instructions such as guiding the mechanical arm to grab a specific ECU and controlling the running speed of the conveyor belt; timing coordination instructions such as synchronizing the start time of multiple test equipment and setting the timeout threshold of each test step. Each instruction contains an accurate timestamp and execution condition to ensure the orderly progress of the entire test process.

[0083] The execution management unit is responsible for the implementation of these control instructions, which directly interacts with the underlying control system of the test environment, schedules test resources, and monitors the status of instruction execution. When the instruction execution deviates or encounters unexpected situations, the execution management unit initiates the preset fault-tolerant processing flow, and feeds back the execution status to the upper-level module if necessary, triggering dynamic adjustment of the scheme. Referring to Table 1, to more specifically illustrate this process, consider the following example data for test scheme evaluation.

[0084] Table 1: Test scheme execution index calculation table

[0085]

[0086] The scheme evaluation module performs evaluation calculations on the three test schemes, each of which passes through four test areas, and the path analysis unit provides length metric values in each area. The index calculation unit multiplies the area length by the corresponding priority level to obtain the execution index of each area. The priority aggregation unit accumulates the execution indexes of each area to obtain the total priority value of each scheme. From the calculation results, it can be seen that scheme C obtains the highest priority value of 152.8, and therefore is determined by the scheme selection unit as the optimal test scheme.

[0087] The instruction generation unit generates corresponding control instructions based on the path sequence of scheme C: first, 12.5 time units of preparation work are performed in the pre-processing area, then 7.8 time units of power stability testing are performed in the power test area, followed by 12.3 time units of function testing in the function verification area, and finally 14.5 time units of firmware burning operation in the burning area. The execution management unit arranges the timing according to this sequence, coordinates the equipment resources of each test area, and ensures that the entire test process is smoothly executed according to the optimal scheme. During the entire execution process, the execution management unit continuously monitors the execution status of each stage, records the difference between the actual execution time and the planned time, and these data will be fed back to the system for subsequent optimization calculation.

[0088] Embodiment 5: The log recording module continuously runs during the test process, and its core function is to comprehensively record all operation instructions generated by the test system and the corresponding execution results. This module adopts a hierarchical data collection architecture, and captures data through log agent programs deployed at each node of the test environment. These agent programs monitor the communication bus of the system, intercept all operation instructions issued via the execution control module, including device control commands, parameter setting instructions, flow jump instructions, etc. Each instruction is captured with an accurate timestamp, instruction sequence number, module identification, and target device identification. At the same time, the log agent program also monitors the state feedback of each execution unit, records the execution results of the instructions, including execution success status, execution time, output data, and possible error codes.

[0089] The recorded data is stored in a structured format, usually using a time-series based database management system. Each log record contains multiple fields: a globally unique identifier for the record ID, a timestamp accurate to the millisecond level, an event type distinguishing whether it is an instruction or a result, a device ID indicating the involved test device, a content field storing the specific instruction or result data, and a status field recording the execution status. The log record module also implements data compression and rotation mechanisms, automatically archiving historical data to a long-term storage system when the storage space reaches a threshold, while maintaining fast access capabilities for recent data. The report generation module works based on the data collected by the log record module, which triggers the report generation process periodically or after the completion of a test task. First, it extracts complete records for the relevant time period from the log database, and aggregates data according to multiple dimensions such as test task, device type, and time range. The data cleaning process filters out debugging information, duplicate records, and system internal communication data, retaining only the core information directly related to the test process.

[0090] The module uses a template-driven report generation mechanism, with multiple report templates built into the system, including detailed test reports, exception summary reports, performance statistics reports, etc. Each template defines the structural framework of the report, the mapping relationship of data fields, and the formatting rules. The report generation engine fills the aggregated log data into the selected template, automatically generating a complete test report. The report content usually includes multiple standard sections. The overview section describes the basic information of the test task, including test time, involved devices, and test case number, etc. The detailed results section lists all important operation instructions and their execution results in chronological order, presenting key data in table form. The exception event summary section counts all exceptions that occurred during the test process, classified by type, severity, and device. The performance statistics section calculates various performance indicators, such as average instruction execution time, test case pass rate, and resource utilization rate, etc. The conclusion section provides an overall evaluation of the test results.

[0091] The generated test report supports multiple output formats, including printable document format, structured data format for easy data exchange, and web format suitable for online viewing. The report generation module also implements version management functions, labeling and storing each generated report with a version number, facilitating subsequent tracing and comparative analysis. The entire log recording and report generation process is fully automated, reducing errors that may be introduced by manual intervention. The collaborative work of the two modules provides complete traceability support for the test process, allowing each link of the test process to be audited and reviewed.

[0092] It is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting; it is not intended to exclude myriad other embodiments of the present application that other inventors can develop based on the same general inventive concepts embodied by the described embodiments. That is, although the present application is described in terms of particular embodiments and implementations, it is to be understood that the terminology used is for the purpose of descriptive clarity and that it should be taken in its broadest possible sense. For example, the terms "a", "an", and "the" include both singular and plural referents unless the context clearly dictates otherwise. The terms "comprises", "comprising", "includes", "including" and the like can be used in conjunction with the term "consisting of to include the elements or steps listed after such conjunctive language, but not to the exclusion of other elements or steps. The singular forms "a", "an" and "the" include plural referents unless the context clearly dictates otherwise.

[0093] While the embodiments of the application have been shown and described herein, it is to be understood that the application is not limited to these embodiments. Rather, many modifications, changes and substitutions are intended to fall within the scope of the present application, which is limited only by the scope of the claims hereinafter appended.

Claims

1. A digital-twin-based ECU power-on programming test monitoring integrated system, characterized in that, Comprise: The test environment division module is used for obtaining the layout information of the ECU power-on programming test environment, and dividing the ECU power-on programming test environment into several test areas; The state tracking module is used for determining the real-time working state of all ECUs based on the digital twin system; The abnormality detection module is used for identifying abnormal events in the test environment based on the test data collected by the monitoring devices of all ECUs; The test strategy adjustment module is used for determining the test execution priority level of each test area in the test environment based on the abnormal events in the test environment and the real-time working state of all ECUs; The task allocation module is used for determining the starting condition of the test task and the target condition of the test task, and determining at least one test scheme based on the layout information of the ECU power-on programming test environment; The scheme evaluation module is used for calculating the execution priority value of each test scheme based on the test execution priority level of each test area in the test environment; The execution control module is used for screening out the test scheme with the largest execution priority value as the optimal test scheme, and issuing a control instruction to control the test system to execute according to the optimal test scheme.

2. The digital-twin-based ECU power-on programming test monitoring integrated system according to claim 1, wherein, The state tracking module comprises: The digital twin construction unit is used for constructing a digital twin model based on the ECU power-on programming test environment; The digital twin interaction unit is used for receiving synchronization data sent by the digital twin model, and analyzing the state information contained in the synchronization data; The state calculation unit is used for calculating the state difference between the ECU and the reference point in the digital twin model based on the analyzed state information; The position mapping unit is used for mapping the actual state of the ECU in the test environment based on the state of the reference point in the digital twin model and the calculated state difference.

3. The digital-twin-based ECU power-on programming test monitoring integrated system according to claim 2, wherein, The steps of the digital twin construction unit constructing the digital twin model comprise: Obtain the physical layout information of the ECU power-on programming test environment and the test equipment attribute parameters; Based on the physical layout information and test equipment attribute parameters, a virtual test environment three-dimensional model completely corresponding to the physical test environment is established; Define ECU working state parameters, test flow logic parameters and environment monitoring parameters in the virtual test environment three-dimensional model; Establish a real-time data bidirectional transmission channel between the sensor devices in the physical test environment and the virtual test environment three-dimensional model; Obtain actual test data through the real-time data synchronization interface unit, and continuously compare the running state difference between the physical test environment and the virtual test environment three-dimensional model; According to the running state difference, the parameters and logic rules in the virtual test environment three-dimensional model are real-time corrected, forming a digital twin model synchronized with the physical test environment.

4. The digital-twin-based ECU power-on programming test monitoring integrated system according to claim 1, wherein, The abnormality detection module comprises: The data acquisition unit is used for obtaining multi-dimensional performance parameters of the ECU in the test process through the monitoring device; The feature extraction unit is configured to extract key feature indicators in multi-dimensional performance parameters; The anomaly determination unit is configured to compare the key feature indicators with a preset standard indicator range, and mark test data exceeding the standard indicator range as abnormal data; The event confirmation unit is configured to aggregate abnormal data positions identified in all ECU test processes, and determine whether at least two ECUs identify abnormal data at the same test position, and if so, determine that a fixed abnormal event exists at the test position.

5. The digital-twin-based ECU power-on programming test monitoring integrated system according to claim 4, wherein, The test strategy adjustment module includes: The parallel capability analysis unit is configured to determine the number of test tasks that can be processed in parallel at each test point in the test area based on abnormal events in the test environment; The regional capability evaluation unit is configured to calculate a parallel processing capability indicator of the test area based on the maximum number of test tasks that can be processed in parallel at each test point in the test area and the total length of test paths in the test area; The comprehensive priority calculation unit is configured to comprehensively calculate a test execution priority level of each test area based on the parallel processing capability indicator of the test area and real-time working states of all ECUs.

6. The digital-twin-based ECU power-on programming test monitoring integrated system according to claim 5, wherein, The task allocation module includes: The condition analysis unit is configured to analyze starting conditions of test tasks and target conditions of test tasks; The path generation unit is configured to generate at least one test path as a test scheme based on layout information of the ECU programming-in-test environment.

7. The digital-twin-based ECU power-on programming test monitoring integrated system according to claim 6, wherein, The scheme evaluation module includes: The path analysis unit is configured to determine the length of the test scheme passing through each test area; The indicator calculation unit is configured to multiply the length of the test scheme passing through a test area by a test execution priority level of the test area to obtain an execution indicator of the test scheme in the test area; The priority summary unit is configured to accumulate and sum execution indicators of the test scheme in all test areas to obtain an execution priority value of the test scheme.

8. The digital-twin-based ECU power-on programming test monitoring integrated system according to claim 7, wherein, The execution control module includes: The scheme selection unit is configured to compare execution priority values of all test schemes, and select a test scheme with the largest execution priority value; The instruction generation unit is configured to generate a control instruction according to the optimal test scheme; The execution management unit is configured to dispatch test resources according to the control instruction, and control the test process to be executed according to the optimal test scheme.

9. The digital-twin-based ECU power-on programming test monitoring integrated system according to claim 1, wherein, Further includes: The log recording module is configured to record all operation instructions and execution results in the test process; The report generation module is configured to generate a test report based on test execution results and recorded log data.

10. An ECU power-on programming test monitoring integrated method based on digital twinning, characterized in that, All modules and method processes of the ECU programming-in-test test monitoring integrated system based on digital twinning according to any one of claims 1 to 9 are included.

Images