Performance determination method and device for electronic control unit in vehicle and vehicle

Abstract

The invention discloses a performance determination method and device for an electronic control unit in a vehicle and the vehicle. The method comprises the steps that a demand document of an electronic control unit in a vehicle is obtained, and the demand document is used for representing performance required by the electronic control unit; a test demand parameter set is extracted from the demand document, the test demand parameter set comprises at least one test demand parameter, and the test demand parameter is used for determining to-be-tested performance of the electronic control unit; the test requirement parameter set is converted into a target test case, and the target test case is used for guiding the test process of testing the performance of the electronic control unit; converting the target test case into an executable code, and obtaining a running result of the executable code; and determining the performance of the electronic control unit based on the operation result. The technical problem of low test efficiency of the electronic control unit is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of system testing, in particular, to a method and device for determining performance of an electronic control unit in a vehicle and the vehicle. BACKGROUND

[0002] At present, the current automotive electronic hardware-in-the-loop (HIL) test sequence generation field is still dominated by traditional methods, mainly relying on manual writing of test cases to complete the construction of test sequences. However, manually testing the electronic control unit has the technical problem of low test efficiency of the electronic control unit.

[0003] In view of the above problems, no effective solution has been proposed so far. SUMMARY

[0004] The embodiments of the present application provide a method and device for determining performance of an electronic control unit in a vehicle and the vehicle, to at least solve the technical problem of low test efficiency of the electronic control unit.

[0005] According to an aspect of the embodiments of the present application, a method for determining performance of an electronic control unit in a vehicle is provided, which can include: obtaining a requirement document of the electronic control unit in the vehicle, wherein the requirement document is used to represent the required performance of the electronic control unit; extracting a test requirement parameter set from the requirement document, wherein the test requirement parameter set includes at least one test requirement parameter, and the test requirement parameter is used to determine the to-be-tested performance of the electronic control unit; converting the test requirement parameter set into a target test case, wherein the target test case is used to guide the test process of testing the performance of the electronic control unit; converting the target test case into executable code, and obtaining a running result of the executable code; and determining the performance of the electronic control unit based on the running result.

[0006] Optionally, extracting the test requirement parameter set from the requirement document includes: parsing the requirement document to obtain at least one keyword in the requirement document, wherein the keyword is used to locate the to-be-tested performance of the electronic control unit; converting the at least one keyword into a key signal parameter in a standard format, wherein the key signal parameter is used to represent the boundary condition of the to-be-tested performance; determining at least one test requirement parameter matched with the key signal parameter from a domain dictionary to obtain the test requirement parameter set, wherein the domain dictionary is used to store at least one test requirement parameter matched with different key signal parameters.

[0007] Optionally, converting the test requirement parameter set into the target test case comprises: converting at least one test requirement parameter in the test requirement parameter set into at least one vector representation; generating an initial test case based on the at least one vector representation; and updating the initial test case to obtain the target test case.

[0008] Optionally, updating the initial test case to obtain the target test case comprises: checking the initial test case to obtain a checking result, wherein the checking result is used to represent integrity of the initial test case; and updating the initial test case based on the checking result to obtain the target test case.

[0009] Optionally, obtaining the running result of the executable code comprises: transmitting the executable code to a hardware-in-the-loop system; and obtaining a running result of the executable code obtained by the hardware-in-the-loop system.

[0010] According to another aspect of the embodiments of the present application, a device for determining performance of an electronic control unit in a vehicle is provided. The device can include: an obtaining unit configured to obtain a requirement document of the electronic control unit in the vehicle, wherein the requirement document is used to represent a required performance of the electronic control unit; an extracting unit configured to extract a test requirement parameter set from the requirement document, wherein the test requirement parameter set includes at least one test requirement parameter, and the test requirement parameter is used to determine a performance to be tested of the electronic control unit; a converting unit configured to convert the test requirement parameter set into a target test case, wherein the target test case is used to guide a test process of testing the performance of the electronic control unit; a processing unit configured to convert the target test case into an executable code, and obtain a running result of the executable code; and a determining unit configured to determine the performance of the electronic control unit based on the running result.

[0011] According to another aspect of the embodiments of the present application, a computer readable storage medium is provided. The computer readable storage medium includes a stored program, wherein the program, when executed by an apparatus in which the computer readable storage medium is located, performs the method for determining performance of an electronic control unit in a vehicle according to the embodiments of the present application.

[0012] According to another aspect of the embodiments of the present application, a processor is provided. The processor is configured to execute a program, wherein the program, when executed by the processor, performs the method for determining performance of an electronic control unit in a vehicle according to the embodiments of the present application.

[0013] According to another aspect of the embodiments of the present application, a program product is provided. The program product includes computer instructions, wherein the computer instructions, when executed by a processor, implement the method for determining performance of an electronic control unit in a vehicle according to the embodiments of the present application.

[0014] According to another aspect of the embodiments of the present application, a vehicle is also provided, which can be used to perform the method for determining the performance of the electronic control unit in the vehicle according to the embodiments of the present application.

[0015] In the embodiments of the present application, a requirement document of the electronic control unit in the vehicle is acquired, wherein the requirement document is used to represent the required performance of the electronic control unit; a test requirement parameter set is extracted from the requirement document, wherein the test requirement parameter set includes at least one test requirement parameter, and the test requirement parameter is used to determine the to-be-tested performance of the electronic control unit; the test requirement parameter set is converted into a target test case, wherein the target test case is used to guide the test process of testing the performance of the electronic control unit; the target test case is converted into executable code, and a running result of the executable code is acquired; and the performance of the electronic control unit is determined based on the running result. That is, in the embodiments of the present application, through the full-process cooperation of requirement analysis, intelligent generation, format conversion and relationship tracing, the automatic generation from the functional requirement of the automotive electronic control unit to the executable test code is realized, thereby realizing the technical effect of improving the test efficiency of the electronic control unit, and solving the technical problem of low test efficiency of the electronic control unit. BRIEF DESCRIPTION OF DRAWINGS

[0016] The accompanying drawings, which are included to provide a further understanding of the present application, constitute a part of the present application and illustrate the illustrative embodiments of the present application and its description, which serve to explain the present application, and do not constitute improper limitations on the present application. In the drawings: Figure 1 is a flowchart of a method for determining the performance of an electronic control unit in a vehicle according to an embodiment of the present application; Figure 2 is a schematic diagram of an optional automotive electronic test sequence generation system based on a Transformer architecture according to an embodiment of the present application; Figure 3 is a schematic diagram of a performance determination apparatus of an electronic control unit in a vehicle according to an embodiment of the present application; Figure 4 is a structural block diagram of a computer terminal according to an embodiment of the present application; Figure 5 is a block diagram of an electronic device for a method for determining the performance of an electronic control unit in a vehicle according to an embodiment of the present application. DETAILED DESCRIPTION

[0017] In the following, the technical solutions in the embodiments of the present application will be described clearly and completely in conjunction with the drawings in the embodiments of the present application, so that those skilled in the art can better understand the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor should be within the scope of protection of the present application.

[0018] It should be noted that the terms "first", "second", and the like in the specification and claims of the present application and the above-described drawings are used to distinguish similar objects, and do not necessarily indicate a specific order or a chronological sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device including a series of steps or units does not have to be limited to only those steps or units clearly listed, but can include other steps or units not clearly listed or inherent to the process, method, product or device.

[0019] According to the embodiments of the present application, an embodiment of a method for determining the performance of an electronic control unit in a vehicle is provided, the steps shown in the flowchart of the drawings can be executed in a computer system such as a set of computer executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0020] At present, the current automotive electronic hardware-in-the-loop (Hardware-in-the-Loop, referred to as HIL) test sequence generation field is still dominated by traditional methods, mainly relying on manual writing of test cases to complete the construction of test sequences. Most automobile enterprises still use semi-manual test sequence generation methods, which test preparation period accounts for an average of 35% of the total project cycle, seriously restricting the realization of product rapid iteration requirements. In the above method, the automatic semantic understanding ability is insufficient, resulting in a manual translation gap between test requirements and case generation; the complex scene modeling capability is limited, and it is difficult to effectively reproduce the extreme working conditions of multi-system interaction; the test knowledge reuse mechanism is missing, making it difficult to convert historical experience into reusable digital assets. The above problems seriously affect the efficiency and quality of hardware-in-the-loop testing, resulting in the technical problem of low test efficiency of the current hardware-in-the-loop testing.

[0021] To solve the above problems, in this embodiment, a performance determination method of an electronic control unit in a vehicle is proposed. The method obtains a requirement document of the electronic control unit in the vehicle, wherein the requirement document is used to represent the performance required for the electronic control unit. From the requirement document, a test requirement parameter set is extracted, wherein the test requirement parameter set includes at least one test requirement parameter, and the test requirement parameter is used to determine the performance to be tested of the electronic control unit. The test requirement parameter set is converted into a target test case, wherein the target test case is used to guide the test process of testing the performance of the electronic control unit. The target test case is converted into executable code, and the running result of the executable code is obtained. Based on the running result, the performance of the electronic control unit is determined. That is, in the embodiment of the present application, through the whole-process cooperation of requirement analysis, intelligent generation, format conversion and relationship tracing, the automatic generation from the functional requirement of the automotive electronic control unit to the executable test code is realized, thereby realizing the technical effect of improving the test efficiency of the electronic control unit, and solving the technical problem of low test efficiency of the electronic control unit.

[0022] Optionally, the method realizes systematic improvement of the automotive electronic test sequence generation capability, realizes end-to-end automatic generation from natural language test requirements to executable test sequences, and needs to completely cover the whole process of requirement analysis, test case generation and script conversion, to a certain extent, optimizes the information loss and efficiency bottleneck in the traditional manual conversion link. Secondly, the method improves the coverage and generation efficiency of complex scene test cases, enhances the recognition and generation ability of edge scene through intelligent method, and reduces the cost of manual intervention.

[0023] Figure 1 It is a flowchart of a performance determination method of an electronic control unit in a vehicle according to an embodiment of the present application. As shown in Figure 1 the method can include the following steps:

[0024] Step S102, obtaining a requirement document of an electronic control unit in a vehicle, wherein the requirement document is used to represent the performance required for the electronic control unit.

[0025] In the technical solution provided in the above step S102 of the present application, the requirement document can be a functional specification document, which can be used to represent the performance required for the electronic control unit, that is, can be used to represent the functions that can be implemented by the electronic control unit.

[0026] Optionally, the above-mentioned requirement document can be a document describing the expected behavior, functional requirements and characteristics of the electronic control unit, which can include but is not limited to: system overview, used to describe the overall architecture of the system, components and the way of interaction between components; function description, used to describe all the functions that the system should have, including but not limited to start sequence, communication protocol, behavior of input / output signal, etc. For example, for a power system, it can include start condition of engine, idle speed control, acceleration response, etc.; performance index, which can be used to define the quantitative standard of system performance, such as response time, accuracy, reliability and power consumption, etc.; boundary condition, which can be used to specify how the system should behave under certain conditions, such as extreme temperature, voltage fluctuation or fault mode.

[0027] Optionally, the functional specification document can be used as a guide document for subsequent development and testing work, and all development activities (including software coding, hardware design) and testing schemes can be carried out according to the description in the document.

[0028] Optionally, before testing the performance of the electronic control unit, the requirement document of the electronic control unit can be obtained, and the test code of the electronic control unit can be determined by analyzing the requirement document.

[0029] Step S104, extracting a test requirement parameter set from the requirement document, wherein the test requirement parameter set includes at least one test requirement parameter, and the test requirement parameter is used to determine the performance to be tested of the electronic control unit.

[0030] In the technical solution provided by the above-mentioned step S104 of the present application, the above-mentioned test requirement parameter set can include at least one test requirement parameter. The above-mentioned test requirement parameter can be used to determine the performance to be tested of the electronic control unit, can be a set of key information extracted from the functional specification document, which is used to guide the design and generation of test cases, and can be used to determine the function points, operation conditions, boundary values, expected behaviors and outputs that need to be verified.

[0031] For example, assuming that we are developing an automatic emergency braking system for a smart car, the test requirement parameter set extracted from the functional specification document can include: signal name (such as VehicleSpeed, ObstacleDistance, ObstacleVelocity), data type, such as integer (VehicleSpeed), floating point (ObstacleDistance), boundary value, test condition, functional logic relationship, expected output, automation identification, etc.

[0032] Optionally, after obtaining the requirement document, at least one test requirement parameter can be extracted from the requirement document by using a requirement analysis module to obtain the test requirement parameter set.

[0033] For example, the input to the requirements analysis module can be a Portable Document Format (PDF) document containing the functional requirements of an electric vehicle drive system, and a comma-separated values ​​(CSV) file defining CAN / LIN bus signals. After obtaining the requirements document, the requirements analysis module can first use Natural Language Processing (NLP) to identify key test requirements in the PDF document, such as "When the motor temperature exceeds 80°C, the system needs to trigger overheat protection." Simultaneously, the CSV file contains detailed attributes of the motor temperature signal. Through these steps, the requirements analysis module can process the requirements document to generate a structured set of test requirement parameters, such as the signal "MotorTemperature" (ID: 0x18FCE001), with a threshold attribute set to 80 degrees Celsius (°C), a trigger condition of ">", and the corresponding functional logic "overheat protection".

[0034] Step S106: Convert the test requirement parameter set into target test cases, wherein the target test cases are used to guide the test process of testing the performance of the electronic control unit.

[0035] In the technical solution provided by step S106 of this application, the target test case can be a test case sequence, which can be used to guide the test process of testing the performance of the electronic control unit, and can include signal excitation and expected system response.

[0036] Optionally, the target test cases mentioned above can be a series of structured test steps and conditions, which can be used to verify whether the object under test (such as an electronic control unit ECU) can correctly respond to predetermined inputs and produce expected results in a specific scenario. The content of the target test cases may include, but is not limited to: test preconditions, test steps, and expected test results. It should be noted that this is only an example and there are no specific limitations on the content of the target test cases.

[0037] Optionally, target test cases can comprehensively examine the behavior and performance of vehicle hardware (including electronic control units) under various expected and unexpected conditions. This is particularly important for testing automotive electronic systems, as these systems often need to handle complex signal interactions and safety-critical functions.

[0038] Optionally, after obtaining the test requirement parameter set, the test requirement parameter set can be converted by using a conversion model to obtain the target test case. The conversion model can include a Transformer model and a test case generation module. The Transformer model can be a neural network architecture for sequence-to-sequence processing.

[0039] Optionally, the requirement analysis module is used to process the requirement document to obtain the test requirement parameter set and the signal attribute. The test requirement parameter set and the signal attribute are input into the conversion model (such as the Transformer model), and the natural language requirements and the signal attribute in the test requirement parameter set are converted into vector representations by using an embedding layer. An encoder is used to capture the semantics of the requirements and the timing characteristics of the signals. A decoder generates a preliminary test case sequence, such as “send MotorTemperature = 81°C, check if the overheat protection is activated”, to obtain the preliminary test case sequence, which includes signal excitation and expected system response.

[0040] Further, the preliminary test case sequence is input into the test case generation module, and the test case generation module is used to automatically supplement boundary value tests, such as “MotorTemperature = 0°C, check system response”. A combination logic test case is generated by using a causal graph method to ensure that all combinations of condition stakes and action stakes are covered. Syntax correctness and logical consistency are checked to ensure sequence function safety standards. After optimization and verification, the standardized test case is obtained, and the target test case is obtained in the format of an Excel table, which is convenient for management and tracking.

[0041] In step S108, the target test case is converted into executable code, and the running result of the executable code is obtained.

[0042] In the technical solution provided in the above step S108 of the present application, the executable code can be an executable test sequence.

[0043] Optionally, the target test case (which can be a standardized test case) is transmitted to the sequence mapping and mapping relationship management module, the sequence mapping and mapping relationship management module is controlled, a programming language (such as Python) script is used to read the target test case, each step of the test case is converted into a code format executable by the HIL system, and executable code is obtained. Further, a mapping relationship between a case identifier (Identity, referred to as ID) and a test sequence execution log can be established to ensure that the test result can be traced back to a specific requirement and a case. The HIL system can directly execute the test sequence code, and the mapping relationship supports bidirectional tracing.

[0044] Optionally, after the executable code is obtained, the HIL execution engine can be used to input the executable code generated by the sequence mapping module into the HIL execution engine, run the test sequence code in the HIL system, simulate the environment of the actual electric vehicle driving system, including signal injection, motor temperature control, etc., to obtain a running result. The running result can be a test result, which can include but is not limited to whether the test system (such as hardware in a vehicle) correctly responds to the overheat protection, whether the signal transmission meets the expectation, etc. It should be noted that this is only an example and the content of the test result is not specifically limited.

[0045] In step S110, the performance of the electronic control unit is determined based on the running result.

[0046] In the technical solution provided in the above step S110 of the present application, based on the running result, it can be determined whether the performance of the electronic control unit is normal.

[0047] For example, this embodiment extracts the “motor temperature overheat protection” requirement from the functional specification document, and obtains the attributes of the motor temperature signal from the signal list. The requirement is converted into a test sequence using a Transformer model, such as “simulate motor temperature 81°C, check if the overheat protection is activated”. Boundary test cases can be supplemented, such as “simulate motor temperature 0°C, check system response”, and the syntax and logic of the sequence are ensured to be correct. The test cases are stored in an Excel table, each case containing an ID, a test step, an expected result, etc. The target test case (such as an Excel case) is converted into executable code (such as a CANoe test script), and after execution, the system response is recorded to confirm whether the overheat protection is correctly triggered. The test ID and the execution result can be mapped to facilitate subsequent debugging and maintenance.

[0048] Through the above process, an end-to-end automated test sequence generation scheme from requirements to execution results is provided, which significantly improves the efficiency and accuracy of HIL testing of electric vehicle electronic systems.

[0049] By the above steps S102 and S110, the requirement document of the electronic control unit in the vehicle is obtained, wherein the requirement document is used to represent the required performance of the electronic control unit; from the requirement document, a test requirement parameter set is extracted, wherein the test requirement parameter set includes at least one test requirement parameter, and the test requirement parameter is used to determine the to-be-tested performance of the electronic control unit; the test requirement parameter set is converted into a target test case, wherein the target test case is used to guide the test process of testing the performance of the electronic control unit; the target test case is converted into executable code, and a running result of the executable code is obtained; and based on the running result, the performance of the electronic control unit is determined. That is, in the embodiment of the present application, through the whole-process cooperation of requirement analysis, intelligent generation, format conversion and relationship tracing, the automatic generation from the functional requirement of the automotive electronics to the executable test code is realized, thereby realizing the technical effect of improving the test efficiency of the electronic control unit, and solving the technical problem of low test efficiency of the electronic control unit.

[0050] The above method of the embodiment will be further introduced below.

[0051] As an optional implementation, in step S104, the test requirement parameter set is extracted from the requirement document, including: the requirement document is parsed to obtain at least one keyword in the requirement document, wherein the keyword is used to locate the to-be-tested performance of the electronic control unit; the at least one keyword is converted into a key signal parameter in a standard format, wherein the key signal parameter is used to represent the boundary condition of the to-be-tested performance; at least one test requirement parameter matched with the key signal parameter is determined from a domain dictionary to obtain the test requirement parameter set, wherein the domain dictionary is used to store at least one test requirement parameter matched with different key signal parameters.

[0052] In this embodiment, the keywords can be key information in the requirement document, can be important words or phrases in the requirement document that reflect core functions or key features, and can be used to help locate the performance of the electronic control unit to be tested. For example, the keywords can be "battery SOC", "charging port cover", "vehicle stationary", "system startup", "charging rate", "battery temperature", etc. in the requirement document. The key signal parameters can be standardized keywords, i.e., parameters converted according to the prediction description format, which can be used to determine the boundary conditions of the performance to be tested. For example, for the keyword "vehicle speed control", the key signal parameters can be "minimum value of vehicle speed signal", "maximum value of vehicle speed signal", "change rate of vehicle speed signal", etc. The domain dictionary can be pre-constructed and can be used to store at least one test requirement parameter matched with different key signal parameters. For example, the test requirement parameters related to the "vehicle speed control" keyword in the domain dictionary can include: "when the vehicle speed signal is at the boundary value, the cruise control system should respond correctly"; "when the vehicle distance is less than the set threshold, the cruise control system should automatically slow down to a safe vehicle distance"; and the like. It should be noted that the above is only an example and the content and type of the keywords, the representation content of the key signal parameters, and the content of the domain dictionary are not limited.

[0053] Optionally, after obtaining the requirement document, the requirement document can be transmitted to the requirement analysis module, which is a data entry of the system and can be used to parse the functional specification document and signal list such as CAN / LIN bus signal definition of the automotive electronic control unit, and extract structured test requirement parameters. The functional specification document, such as the functional safety requirement, includes a signal list containing signal name, data type, boundary value, period, etc. The requirement analysis module processes the requirement document to obtain a test requirement parameter set, which can include the message ID of the key message, the boundary condition (such as voltage range 9-16V), the timing constraint (such as signal sending period 10ms), and the functional logic relationship (such as "when the brake signal is activated, the acceleration signal should be suppressed").

[0054] Optionally, the requirement analysis module can use natural language processing (NLP) technology to parse unstructured documents and combine regular expressions and domain dictionaries (such as an automotive electronic term library) to accurately extract parameters.

[0055] For example, suppose there is a requirements document regarding the functional specifications of an electric vehicle charging system, which includes the following description: > When the battery's State of Charge (SOC) is below 20%, the charging port cover is closed, and the vehicle is stationary, the system should automatically initiate the charging process. The charging rate should be adjusted according to the battery temperature; at high temperatures (above 45°C), the charging current should be reduced to 16A, and at low temperatures (below -5°C), a preheating function should be used with a charging current of 8A. Using a PDF parsing library to convert the PDF document to plain text, we get the plain text description: "When the battery's SOC is below 20%, the charging port cover is closed, and the vehicle is stationary, the system should automatically initiate the charging process. The charging rate should be adjusted according to the battery temperature; at high temperatures (above 45°C), the charging current should be reduced to 16A, and at low temperatures (below -5°C), a preheating function should be used with a charging current of 8A." Furthermore, NLP can be used to extract key information, and the requirements document can be parsed to identify keywords such as "battery SOC", "charging port cover", "vehicle stationary", "system start-up", "charging rate", and "battery temperature". Pre-trained models (such as BERT NER) can be used to identify specific technical parameters and conditions, such as "20%", "45°C", "16A", "-5°C", and "8A".

[0056] Furthermore, regular expression matching is used to match specific numerical values ​​and conditions. For example, "below 20%" corresponds to the regular expression `below\s*(\d+)%`, extracting the battery SOC boundary value of 20%. Regular expressions can be pre-defined standard format content. After obtaining keywords, they can be converted into key signal parameters in a preset format. Once the key signal parameters are obtained, the corresponding test requirement parameters can be determined based on a domain dictionary mapping. The domain dictionary can include information such as the test conditions and test content corresponding to the key signal parameters.

[0057] By following the steps above, test requirement parameters can be accurately and efficiently extracted from unstructured functional specification documents, providing a foundation for subsequent test design and execution. This approach not only reduces errors and omissions from manual document parsing but also significantly improves the automation and standardization of test requirement analysis.

[0058] As an optional implementation, step S106, converting the test requirement parameter set into target test cases, includes: converting at least one test requirement parameter in the test requirement parameter set into at least one vector representation; generating an initial test case based on the at least one vector representation; and updating the initial test case to obtain the target test case.

[0059] In this embodiment, the Transformer model module can be used to convert at least one test requirement parameter in the test requirement parameter set into at least one vector representation, and generate an initial test case based on the at least one vector representation. Further, the test case generation module can be used to update the initial test case to obtain a target test case. The test case generation module can be used to fill in the missing contents in the initial test case to obtain a complete target test case.

[0060] Optionally, the Transformer model module serves as the core intelligent engine of the system, and converts the test requirement parameters into the test case sequence based on the sequence-to-sequence architecture to capture the timing dependence and logical association between signals. The Transformer model module can include an encoder and a decoder. The encoder can be stacked by 6 encoder blocks, each block containing 8 heads, a self-attention layer with a dimension of 512, and a feedforward neural network. The encoder can convert the input functional specification text and signal parameters into context vectors through an embedding layer (Word2Vec word vector + sine position encoding). The decoder can include 6 decoder blocks, each block adding an encoder-decoder attention layer, and generating a test case sequence meeting the modified condition / decision coverage (MC / DC) coverage standard by fusing the encoder output and the historical generated sequence through the multi-head attention mechanism. The input of the Transformer model module can be the structured parameter set output by the requirement analysis module, and the output can be the initial test case sequence (including test steps, input signal excitation, expected output, etc.).

[0061] Optionally, the requirements analysis module outputs a test requirement parameter set, which may include key information such as test objectives, signal names, data types, boundary values, and preconditions. The aforementioned textual information and signal parameters are converted into numerical vectors for easier model processing. Word embeddings (such as Word2Vec or BERT) and sinusoidal positional encoding are used to represent the features and positional information of each element in the sequence. The encoder module in the Transformer model module captures the dependencies between different signals and conditions in the input sequence through multiple sets of parallel self-attention heads, with each attention head responsible for learning the associations of different parts of the sequence. The FFN in the encoder is used to further extract signal features, enhancing the model's understanding of specific signal attributes (such as data types and boundary conditions). The decoder in the Transformer model module receives the encoder's output and the current state of the generated sequence, generates the contextual dependencies of the sequence, and predicts the next signal or test step. The sequence generated by the decoder contains information such as the description of the test step, the value of the input signal, and the expected signal response, which constitutes a preliminary test case sequence.

[0062] Optionally, through interaction with the encoder, the decoder can supplement test cases under boundary conditions to ensure that tests cover all critical scenarios. The generated sequences can undergo syntax and semantic checks to ensure the consistency and rationality of signal logic and test steps, avoiding the generation of invalid or contradictory test cases. Finally, the generated sequences are converted into an easy-to-understand format, such as an Excel spreadsheet or a specific test case description language, facilitating standardized processing and execution by the subsequent test case generation module.

[0063] As an optional implementation, updating the initial test cases to obtain target test cases includes: verifying the initial test cases to obtain verification results, wherein the verification results are used to characterize the integrity of the initial test cases; and using the verification results to update the initial test cases to obtain target test cases.

[0064] In this embodiment, after generating initial test cases using the Transformer model module, the test case generation module can be used to optimize and verify the initial sequence output by the Transformer to ensure that it meets the test coverage requirements of functional safety standards. The verification results can be used to characterize the completeness of the initial test cases.

[0065] Optionally, based on the verification results, it can be determined where there is missing data in the initial test cases, and the data can be supplemented to obtain the target test cases.

[0066] Optionally, by utilizing the test case generation module, after obtaining the verification results, boundary value test cases (such as minimum / maximum signal values, outlier injection) can be automatically supplemented based on the verification results; the test case generation module can also generate combinational logic test cases based on the cause-effect graph method to ensure full combination coverage of condition stubs and action stubs; at the same time, the correctness of the test case syntax can be verified (such as no contradictions in signal format and timing logic).

[0067] Optionally, the input data for the test case generation module can be the initial test case sequence output by the Transformer model module. The output data can be standardized test cases (Excel format, including test case ID, priority, preconditions, steps, and expected results).

[0068] Optionally, after constructing the target test cases, you can use the sequence mapping and mapping relationship management module to transform the target test cases into executable code. Specifically, the sequence mapping and mapping relationship management module can be used to convert test cases from a standardized format to executable code in a Hardware-in-the-Loop (HIL) test system, establishing a complete bidirectional mapping between test requirements, test cases, execution sequences, and test results, thus connecting the "requirement-test case-execution" link.

[0069] Optionally, the sequence mapping and mapping relationship management module can parse Excel test cases based on an open-source database (such as the openpyxl library), extract test steps and signal parameters, and generate executable code through preset templates; it can also integrate the test sequence management system interface to synchronize test case status to the execution end, match test case IDs with execution logs, and automatically associate test results with test cases.

[0070] Optionally, the input data for the sequence mapping and mapping relationship management module can be Excel test cases output by the test case generation module. The output data can be HIL system executable code (such as the CANoe.can script or a Python test script).

[0071] As an optional implementation, step S108, obtaining the execution result of the executable code, includes: transferring the executable code to the hardware-in-the-loop system; and obtaining the execution result obtained by running the executable code in the hardware-in-the-loop system.

[0072] In this embodiment, the executable code generated by the sequence mapping and management module is transmitted to the HIL testing system. This executable code can be a test script for a specific electronic control unit.

[0073] Optionally, once the executable code runs in the HIL system, a series of results can be obtained, including but not limited to ECU responses, system state changes, and fault simulation results. These results can be used to evaluate test success, detect potential faults, and verify the correctness of control strategies.

[0074] In this embodiment, a requirements document is obtained, processed by a requirements analysis module to obtain a test requirement parameter set, and then processed by a Transformer encoder and decoder to obtain initial test cases. The test cases are then standardized using a test case generation module to obtain target test cases. A sequence conversion module is used to convert the target test cases into HIL code (i.e., executable code). The executable code is then run using the HIL execution engine to obtain test results (i.e., execution results), thus forming a closed-loop automated process from requirements analysis to result traceability. Each module achieves loose coupling integration through standardized data interfaces, meeting the testing requirements of different automotive electronic ECUs (such as VCU, BMS, and ADAS controllers).

[0075] In this embodiment, an automotive electronics test sequence generation system based on the Transformer architecture is also proposed. The system architecture is based on modular design and achieves automated generation from automotive electronic functional requirements to executable test sequences through the whole process of requirement analysis, intelligent generation, format conversion and relationship traceability. Figure 2 This is a schematic diagram of an optional automotive electronics test sequence generation system based on the Transformer architecture according to an embodiment of this application, such as... Figure 2 As shown, the system may include: a requirements analysis module 201, a Transformer model module 202, a test case generation module 203, and a sequence mapping and management module 204. Each module achieves efficient interaction through a standardized data interface.

[0076] Optionally, the HIL execution engine 205 obtains the executable code and runs it to obtain the execution result. This execution result can be stored in the form of a test result log.

[0077] Optionally, the above four modules revolve around four core aspects: data preprocessing, model training, test case generation, sequence transformation, and mapping relationship management, forming a complete closed loop from requirements analysis to automated test execution. The specific operation content, parameter settings, and technical details of each step are as follows: First, the requirements analysis module 201 parses the PDF format functional specification document (i.e., the functional specification input), extracts the core test signal list (such as vehicle speed, motor speed, battery SOC, etc.), and avoids exceeding the byte (token) length limit through text segmentation technology. The CAN signals in the historical test data are cleaned and standardized, outliers are removed, and voxel features are generated. Continuous signals are discretized into fixed-length time segments, with the sequence length uniformly ranging from 512 to 1024 tokens. The word segmenter performs sub-word segmentation on the functional specification text to solve the out-of-vocabulary word problem, and simultaneously creates an attention mask to distinguish between real content and filler content, ensuring that the model focuses on effective information.

[0078] Optionally, the requirements analysis module 201 acquires the functional specification input, uses an NLP parsing engine to parse the unstructured document, and combines regular expressions with a domain dictionary (such as an automotive electronics terminology library) to accurately extract parameters, obtaining a structured test requirement parameter set. This structured test requirement parameter set is then input into the Transformer model module 202.

[0079] Optionally, the Transformer model module 202 can be provided with high-quality input by standardizing the data format and enhancing features through the requirements analysis module 201, thereby reducing noise interference and improving the accuracy of sequence pattern learning.

[0080] Optionally, the Transformer model module 202 may include an encoder and a decoder. The Transformer model training process may include: dataset construction, collecting historical test cases (including CAN signal sequences, fault injection records, and expected results), dividing them into a training set and a validation set in an 8:2 ratio. The training set contains sample codes (fault codes / function codes) and corresponding feedback information, while the validation set is used to evaluate generalization ability; model parameter configuration, defining the Transformer model based on the PyTorch framework, with core parameters including but not limited to: n_head=8 multi-head attention heads, dim_feedforward=2048 feedforward network dimensions, dropout rate 0.1, embedding layer dimension 512, and 6 encoder / decoder layers each.

[0081] Optionally, the Transformer model can be trained using the Adam optimizer with cross-entropy loss function for supervised training, iterating through multiple rounds. After each round, the average loss is calculated using the validation set, and an early stopping mechanism is triggered when the loss does not decrease for three consecutive rounds.

[0082] Optionally, multiple attention heads are used to capture local and global dependencies in the signal sequence in parallel; overfitting is suppressed to enhance the model's adaptability to unseen test scenarios; voxel features are used to transform the temporal features of CAN signals into a spatial grid structure to improve the Transformer's robustness to high-frequency noise.

[0083] Optionally, by training with large-scale historical data, the model learns the timing logic and signal association rules of automotive electronic test sequences, laying the reasoning foundation for the automated generation of test cases.

[0084] Optionally, the test case generation module 203 automatically supplements boundary value test cases and generates combinational logic test cases based on the cause-effect graph method to ensure full combination coverage of condition stubs and action stubs, so as to obtain standardized test cases (i.e., standardized Excel test cases).

[0085] Optionally, test case generation may include receiving JSON-formatted functional specification text (including test objectives and boundary conditions) and a list of signals. The preprocessed text and signal features are input into a trained Transformer decoder, and a beam search strategy is used to generate test cases. These cases include test steps (e.g., "Power on → Send 0x123 signal → Read response"), expected results (e.g., "Response word 0x5A"), and boundary conditions (e.g., "Overload protection triggered at vehicle speed = 250km / h"). This generates an Excel test case table with fields including test case ID, test module, step description, input signal, expected result, priority, and automation flag.

[0086] Optionally, based on the sequence generation capability of Transformer, it is possible to achieve automated conversion from natural language requirements to structured test cases, covering functional verification and boundary testing scenarios.

[0087] Optionally, the sequence mapping and mapping relationship management module 204 can parse Excel test cases based on the openpyxl library, extract test steps and signal parameters, generate executable code (i.e., script) through a preset template, and use a hash table to map and store test cases.

[0088] Optionally, test sequence conversion and mapping management may include: using a Python script (based on the openpyxl library) to read Excel test cases, parse test steps and signal parameters, and automatically generate CANoe test sequences, supporting the CAN FD protocol. The association between CAN signals and system variables is established through the "Simulation-Environment-Signal Mapping" module, supporting three mapping methods: bidirectional transmission, unidirectional send / receive, for example, mapping the database signal "EngSpeed" to the system variable SV_EngSpeed. Hardware fault insertion unit control instructions are embedded in the test sequences to simulate abnormal conditions such as short circuits and overvoltages, such as "setting a short circuit between CAN_H line and GND for 500ms". A hash table is used to store the correspondence between test case IDs and CANoe sequence IDs, with the key being the test case ID (e.g., "TCMCU001") and the value being the sequence path (e.g., "D: / TestSeq / MCU / TCMCU001.cfg"). Changes to Excel test cases are monitored, and the hash table mapping is automatically synchronized through an event-triggered mechanism, with an update latency of <100ms. Read-write locks are used to avoid conflicts and support concurrent writes.

[0089] Optionally, the test sequence conversion and mapping relationship management module can be used to achieve seamless conversion of test cases into automated execution sequences, directly connect to the HIL test environment, and improve test execution efficiency and protocol compatibility. Through efficient mapping relationship management, dynamic association between test cases and execution sequences can be achieved, supporting rapid location and update in large-scale test scenarios.

[0090] Optionally, in hardware-in-the-loop (HIL) testing for autonomous driving, real-world road environments and sensor inputs can be simulated to verify the controller's perception, decision-making, and execution logic. In such scenarios, the Transformer model can automatically generate compliant test sequence code based on Excel test cases and maintain stability under high-concurrency requests (such as simultaneous injection of multi-sensor data).

[0091] Optionally, for powertrain components such as engine control unit (ECU) and automatic transmission control unit (TCU), the HIL system can integrate MATLAB / Simulink vehicle dynamics models to simulate extreme conditions such as rapid acceleration and brake failure, and verify the correctness of the control algorithm. Traditional manual coding requires a lot of time to maintain signal mapping relationships, while the automated generation system can significantly improve efficiency.

[0092] In this embodiment, the Transformer architecture is introduced into the field of automotive electronics test sequence generation. An Encoder-Decoder structure and a Masked Attention mechanism enable end-to-end generation of CAN message sequences from test requirements. A three-level decoupled architecture of "data dictionary - device node - signal path" is used, with a standardized abstraction layer to debind the test sequence from the underlying hardware and signal protocols. For distributed testing requirements of multiple ECUs, a clustered HIL technology based on IOHUB is proposed, constructing a three-in-one architecture of "hardware synchronization - distributed computing - real-time scheduling." The hardware layer uses optical fiber to synchronize the clocks and data of multiple HIL nodes. The abnormal data generation capability of Generative Adversarial Networks (GANs) is deeply integrated with the physical simulation advantages of HIL to construct a closed-loop testing system of "virtual data - physical verification."

[0093] In this embodiment of the application, through the collaborative process of requirement analysis, intelligent generation, format conversion and relationship tracing, the automated generation of automotive electronic functional requirements into executable test code is achieved, thereby improving the testing efficiency of electronic control units and solving the technical problem of low testing efficiency of electronic control units.

[0094] According to an embodiment of this application, a performance determination device for an electronic control unit in a vehicle is also provided. It should be noted that the performance determination device for an electronic control unit in a vehicle of this embodiment can be used to execute the performance determination method for an electronic control unit in a vehicle according to Embodiment 1 of this application.

[0095] Figure 3 This is a schematic diagram of a performance determination device for an electronic control unit in a vehicle according to an embodiment of this application. Figure 3 As shown, the performance determination device 30 of the electronic control unit in the vehicle may include: an acquisition unit 302, an extraction unit 304, a conversion unit 306, a processing unit 308, and a determination unit 310.

[0096] The acquisition unit 302 is used to acquire the requirements document of the electronic control unit in the vehicle, wherein the requirements document is used to characterize the performance required for the electronic control unit.

[0097] Extraction unit 304 is used to extract a set of test requirement parameters from the requirements document, wherein the set of test requirement parameters includes at least one test requirement parameter, which is used to determine the performance of the electronic control unit to be tested;

[0098] The conversion unit 306 is used to convert the test requirement parameter set into target test cases, wherein the target test cases are used to guide the test process of testing the performance of the electronic control unit.

[0099] The processing unit 308 is used to convert the target test case into executable code and obtain the running results of the executable code.

[0100] The determination unit 310 is used to determine the performance of the electronic control unit based on the operating results.

[0101] The vehicle electronic control unit (ECU) performance determination device of this embodiment acquires a requirement document for the ECU through an acquisition unit, wherein the requirement document characterizes the performance requirements for the ECU; extracts a set of test requirement parameters from the requirement document through an extraction unit, wherein the set of test requirement parameters includes at least one test requirement parameter used to determine the performance to be tested of the ECU; converts the set of test requirement parameters into target test cases through a conversion unit, wherein the target test cases guide the testing process for testing the performance of the ECU; processes the target test cases into executable code through a processing unit and acquires the execution results of the executable code; and determines the performance of the ECU based on the execution results through a determination unit. This achieves the technical effect of improving the testing efficiency of the ECU and solves the technical problem of low testing efficiency for the ECU.

[0102] Embodiments of this application may provide a computer terminal, which may be any computer terminal device in a group of computer terminals. Optionally, in this embodiment, the aforementioned computer terminal may also be replaced by a mobile terminal or other terminal device.

[0103] Optionally, in this embodiment, the computer terminal may be located in at least one of a plurality of network devices in a computer network.

[0104] In this embodiment, the aforementioned computer terminal can execute program code for the following steps in the method for determining the performance of an electronic control unit in a vehicle: obtaining a requirements document for the electronic control unit in the vehicle, wherein the requirements document characterizes the performance required for the electronic control unit; extracting a set of test requirements parameters from the requirements document, wherein the set of test requirements parameters includes at least one test requirement parameter used to determine the performance of the electronic control unit to be tested; converting the set of test requirements parameters into target test cases, wherein the target test cases guide the testing process for testing the performance of the electronic control unit; converting the target test cases into executable code and obtaining the execution results of the executable code; and determining the performance of the electronic control unit based on the execution results.

[0105] Optionally, Figure 4 This is a structural block diagram of a computer terminal according to an embodiment of this application, such as... Figure 4As shown, the computer terminal 408 may include one or more (only one is shown in the figure) processors 402, memory 404, and transmission devices 406.

[0106] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the performance determination method and apparatus for the electronic control unit in a vehicle in this embodiment of the application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the aforementioned performance determination method for the electronic control unit in a vehicle. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to computer terminal 408 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0107] The processor can invoke information and application programs stored in memory via a transmission device to perform the following steps: obtaining a requirements document for the electronic control unit (ECU) in the vehicle, wherein the requirements document characterizes the performance requirements for the ECU; extracting a set of test requirements parameters from the requirements document, wherein the set of test requirements parameters includes at least one test requirement parameter used to determine the performance of the ECU to be tested; converting the set of test requirements parameters into target test cases, wherein the target test cases guide the testing process for testing the performance of the ECU; converting the target test cases into executable code and obtaining the execution results of the executable code; and determining the performance of the ECU based on the execution results.

[0108] Those skilled in the art will understand that Figure 4 The structure shown is for illustrative purposes only. Computer terminal 408 can also be a smartphone (such as an Android phone, iOS phone, etc.), tablet computer, handheld computer, mobile internet device (MID), PAD and other terminal devices. Figure 4 This does not limit the structure of the computer terminal 408 described above. For example, the computer terminal 408 may also include components that are more advanced than those described above. Figure 4 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 4 The different configurations shown.

[0109] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0110] According to an embodiment of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored program, wherein the program executes the performance determination method of the electronic control unit in the vehicle in Embodiment 1.

[0111] Optionally, in this embodiment, the computer-readable storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0112] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for performing the following steps: obtaining a requirements document for an electronic control unit in a vehicle, wherein the requirements document characterizes the performance requirements for the electronic control unit; extracting a set of test requirements parameters from the requirements document, wherein the set of test requirements parameters includes at least one test requirement parameter used to determine the performance to be tested of the electronic control unit; converting the set of test requirements parameters into target test cases, wherein the target test cases guide the testing process for testing the performance of the electronic control unit; converting the target test cases into executable code and obtaining the execution results of the executable code; and determining the performance of the electronic control unit based on the execution results.

[0113] Optionally, the aforementioned computer-readable storage medium may also execute program code that performs the following steps: parsing a requirements document to obtain at least one keyword in the requirements document, wherein the keyword is used to locate the performance to be tested of the electronic control unit; converting the at least one keyword into a key signal parameter in a standard format, wherein the key signal parameter is used to characterize the boundary conditions of the performance to be tested; determining at least one test requirement parameter matching the key signal parameter from a domain dictionary to obtain a set of test requirement parameters, wherein the domain dictionary is used to store at least one test requirement parameter matching different key signal parameters.

[0114] Optionally, the aforementioned computer-readable storage medium may also execute program code that performs the following steps: converting at least one test requirement parameter in the test requirement parameter set into at least one vector representation; generating an initial test case based on the at least one vector representation; and updating the initial test case to obtain a target test case.

[0115] Optionally, the computer-readable storage medium may also execute program code that performs the following steps: verifying the initial test cases to obtain verification results, wherein the verification results are used to characterize the integrity of the initial test cases; and using the verification results to update the initial test cases to obtain target test cases.

[0116] Optionally, the computer-readable storage medium may also execute program code that performs the following steps: transferring executable code to a hardware-in-the-loop system; and obtaining the execution results obtained by the hardware-in-the-loop system running the executable code.

[0117] In this embodiment, through the collaborative process of requirement analysis, intelligent generation, format conversion and relationship tracing, the automated generation of automotive electronic functional requirements into executable test code is achieved, thereby improving the testing efficiency of electronic control units and solving the technical problem of low testing efficiency of electronic control units.

[0118] According to an embodiment of this application, a processor is also provided for running a program, wherein the performance determination method of the electronic control unit in the vehicle in Embodiment 1 is executed when the program is run by the processor.

[0119] Optionally, in this embodiment, the computer terminal may be located in at least one of a plurality of network devices in a computer network.

[0120] In this embodiment, the aforementioned computer terminal can execute program code for the following steps in the method for determining the performance of an electronic control unit in a vehicle: obtaining a requirements document for the electronic control unit in the vehicle, wherein the requirements document characterizes the performance required for the electronic control unit; extracting a set of test requirements parameters from the requirements document, wherein the set of test requirements parameters includes at least one test requirement parameter used to determine the performance of the electronic control unit to be tested; converting the set of test requirements parameters into target test cases, wherein the target test cases guide the testing process for testing the performance of the electronic control unit; converting the target test cases into executable code and obtaining the execution results of the executable code; and determining the performance of the electronic control unit based on the execution results.

[0121] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the performance determination method and apparatus for the electronic control unit in a vehicle in this application embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the aforementioned performance determination method for the electronic control unit in a vehicle. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to a computer terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0122] The processor can invoke information and application programs stored in memory via a transmission device to perform the following steps: obtaining a requirements document for the electronic control unit (ECU) in the vehicle, wherein the requirements document characterizes the performance requirements for the ECU; extracting a set of test requirements parameters from the requirements document, wherein the set of test requirements parameters includes at least one test requirement parameter used to determine the performance of the ECU to be tested; converting the set of test requirements parameters into target test cases, wherein the target test cases guide the testing process for testing the performance of the ECU; converting the target test cases into executable code and obtaining the execution results of the executable code; and determining the performance of the ECU based on the execution results.

[0123] Optionally, the processor may also execute program code that performs the following steps: parsing the requirements document to obtain at least one keyword in the requirements document, wherein the keyword is used to locate the performance to be tested of the electronic control unit; converting the at least one keyword into a key signal parameter in a standard format, wherein the key signal parameter is used to characterize the boundary conditions of the performance to be tested; and determining at least one test requirement parameter that matches the key signal parameter from the domain dictionary to obtain a set of test requirement parameters, wherein the domain dictionary is used to store at least one test requirement parameter that matches different key signal parameters.

[0124] Optionally, the processor may also execute program code that performs the following steps: converting at least one test requirement parameter in the test requirement parameter set into at least one vector representation; generating an initial test case based on the at least one vector representation; and updating the initial test case to obtain the target test case.

[0125] Optionally, the processor may also execute program code that performs the following steps: verifying the initial test cases and obtaining verification results, wherein the verification results are used to characterize the integrity of the initial test cases; and using the verification results to update the initial test cases and obtain the target test cases.

[0126] Optionally, the processor may also execute program code that performs the following steps: transferring executable code to the hardware-in-the-loop system; and obtaining the execution results obtained by the hardware-in-the-loop system running the executable code.

[0127] By employing the embodiments of this application, through the collaborative process of requirement analysis, intelligent generation, format conversion and relationship tracing, the automated generation of automotive electronic functional requirements into executable test code is achieved, thereby realizing the technical effect of improving the testing efficiency of electronic control units and solving the technical problem of low testing efficiency of electronic control units.

[0128] According to an embodiment of this application, a computer program product is also provided, which includes computer instructions, wherein when the computer instructions are executed by a processor, they implement the performance determination method of the electronic control unit in the vehicle in Embodiment 1.

[0129] Embodiments of this application may provide an electronic device that may include a memory and a processor.

[0130] Figure 5 This is a block diagram of an electronic device for determining the performance of an electronic control unit in a vehicle according to an embodiment of this application. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present application described and / or claimed herein.

[0131] like Figure 5 As shown, device 500 includes a computing unit 501, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 502 or a computer program loaded from storage unit 508 into random access memory (RAM) 503. RAM 503 can also store various programs and data required for the operation of device 500. The computing unit 501, ROM 502, and RAM 503 are interconnected via bus 504. Input / output (I / O) interface 505 is also connected to bus 504.

[0132] Multiple components in device 500 are connected to I / O interface 505, including: input unit 506, such as keyboard, mouse, etc.; output unit 504, such as various types of monitors, speakers, etc.; storage unit 508, such as disk, optical disk, etc.; and communication unit 509, such as network card, modem, wireless transceiver, etc. Communication unit 509 allows device 500 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0133] The computing unit 501 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 501 performs the various methods and processes described above, such as data verification methods. For example, in some embodiments, the data verification method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 508. In some embodiments, part or all of the computer program may be loaded and / or installed on device 500 via ROM 502 and / or communication unit 509. When the computer program is loaded into RAM 503 and executed by the computing unit 501, one or more steps of the data verification method described above may be performed. Alternatively, in other embodiments, the computing unit 501 may be configured to perform a data verification method by any other suitable means (e.g., by means of firmware).

[0134] According to an embodiment of this application, a method for determining the performance of an electronic control unit in a vehicle is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0135] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems on a chip (SOCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0136] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0137] In the context of this application, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0138] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display, monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or pathball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0139] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0140] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0141] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0142] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0143] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection of units or modules may be electrical or other forms.

[0144] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0145] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0146] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0147] The above are merely preferred embodiments of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for determining the performance of an electronic control unit in a vehicle, characterized in that, include: Obtain the requirements document for the electronic control unit in the vehicle, wherein the requirements document is used to characterize the performance required for the electronic control unit; From the requirements document, a set of test requirements parameters is extracted, wherein the set of test requirements parameters includes at least one test requirement parameter, which is used to determine the performance of the electronic control unit to be tested; The test requirement parameter set is converted into target test cases, wherein the target test cases are used to guide the test process for testing the performance of the electronic control unit; The target test case is converted into executable code, and the execution result of the executable code is obtained; Based on the operating results, the performance of the electronic control unit is determined.

2. The method according to claim 1, characterized in that, The step of extracting the test requirement parameter set from the requirement document includes: The requirement document is parsed to obtain at least one keyword in the requirement document, wherein the keyword is used to locate the performance to be tested of the electronic control unit; At least one of the keywords is converted into key signal parameters in a standard format, wherein the key signal parameters are used to characterize the boundary conditions of the performance to be tested; From the domain dictionary, at least one of the test requirement parameters that matches the key signal parameter is determined to obtain a test requirement parameter set, wherein the domain dictionary is used to store at least one test requirement parameter that matches different key signal parameters.

3. The method according to claim 1, characterized in that, The step of converting the test requirement parameter set into target test cases includes: Convert at least one of the test requirement parameters in the set of test requirement parameters into at least one vector representation; Based on the at least one vector representation, generate initial test cases; The initial test cases are updated to obtain the target test cases.

4. The method according to claim 3, characterized in that, The step of updating the initial test cases to obtain the target test cases includes: The initial test cases are validated to obtain validation results, wherein the validation results are used to characterize the completeness of the initial test cases; Using the verification results, the initial test case is updated to obtain the target test case.

5. The method according to claim 1, characterized in that, The step of obtaining the execution result of the executable code includes: The executable code is transferred to the hardware-in-the-loop system; Obtain the execution results obtained by running the executable code in the hardware-in-the-loop system.

6. A performance determination device for an electronic control unit in a vehicle, characterized in that, include: An acquisition unit is configured to acquire a requirements document for an electronic control unit in the vehicle, wherein the requirements document characterizes the performance requirements for the electronic control unit; An extraction unit is used to extract a set of test requirement parameters from the requirement document, wherein the set of test requirement parameters includes at least one test requirement parameter, which is used to determine the performance of the electronic control unit to be tested; A conversion unit is used to convert the test requirement parameter set into target test cases, wherein the target test cases are used to guide the test process for testing the performance of the electronic control unit; The processing unit is used to convert the target test case into executable code and obtain the execution result of the executable code; A determining unit is used to determine the performance of the electronic control unit based on the operating results.

7. A vehicle, characterized in that, Used to perform the method according to any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein, when the program is executed, it controls the device on which the computer-readable storage medium is located to perform the method according to any one of claims 1 to 5.

9. A processor, characterized in that, The processor is used to run a program, wherein the program is executed by the processor to perform the method according to any one of claims 1 to 5.

10. A computer program product, characterized in that, Includes computer instructions that, when executed by a processor, implement the method described in any one of claims 1 to 5.

Images