In the era of automotive “new four modernizations”—electrification, connectivity, intelligence, and sharing—the motor control unit, as a core component of the “smart terminal,” has seen its perception, decision-making, and execution functions become increasingly complex. Ensuring the quality and shortening the development cycle of these systems is a critical concern for both original equipment manufacturers and suppliers. Testing is a vital part of quality assurance for motor control units, where the quality and efficiency of test case development significantly impact system reliability. Furthermore, functional safety standards such as GB/T 34590 specify requirements for test coverage, equivalence classes, boundary values, and more. Thus, efficient and high-coverage test case generation, especially automated generation, has become a focal point. Currently, most automated test case generation techniques are model-based, but these methods often fail to cover multi-dimensional test inputs, coupled conditions in test requirements, or meet functional safety standards. With advancements in natural language models, transforming text-based functional specifications into structured, more interpretable requirements has emerged as a mainstream approach.
Against this backdrop, I research intelligent test case generation methods for automotive motor control units. By leveraging large language models (LLMs) to convert functional specifications into structured requirements, analyzing their content and structure, and combining this with test coverage demands, I aim to automatically generate test case attributes. This approach seeks to enhance the efficiency and quality of test case development for motor control units. The technical roadmap integrates LLM-based transformation with algorithmic generation, as illustrated below, where functional specifications are processed into structured flows for automated test case output.
The core of this research lies in developing algorithms that satisfy different structural coverage criteria—specifically, Modified Condition/Decision Coverage (MC/DC), branch coverage, and statement coverage—while incorporating equivalence class and boundary value testing. These algorithms are designed to handle both non-coupled and coupled conditions within motor control unit logic. To clarify terminology, I define key terms used throughout the algorithms in Table 1.
| Term | Explanation |
|---|---|
| Condition | An expression containing variables, relational operators, and values, e.g., $a \geq 5$. |
| Decision | A Boolean expression composed of conditions and logical operators. When more than two operators exist, the outermost is the parent decision, which can be recursively split into sub-decisions, e.g., $((a < 6) \&\& (b > 8)) || (c == 1)$. |
| Independent Condition | A condition that solely determines the parent decision’s value. |
| Dependent Condition | Other conditions in the parent decision not classified as independent. |
| Current Processing Condition | A dependent condition being processed. |
| Same-Parent Decision | The sub-decision with the fewest conditions that contains both the independent and current processing conditions. |
| First-Level Independent Sub-decision | The sub-decision at the next level of the same-parent decision that contains an independent condition. |
| First-Level Comparative Sub-decision | The sub-decision at the next level of the same-parent decision that contains the current processing condition. |
| First Condition | The initial condition in a decision expression. |
| Determining Condition | A condition that decides the output of a non-independent decision, such as the first condition. |
| Complement Set | A test case where the independent condition’s value (including repeats) is negated, while other conditions remain unchanged. |
| Independent Condition Influence | For a decision with two conditions and one logical operator (e.g., $(A \&\& B)$ or $(C || D)$), an independent condition influences the decision independently if: when the operator is “$\&\&$”, it must be set to true (T); when “||”, it must be false (F). |
Branch coverage requires each decision in a program to take both true and false values at least once. MC/DC coverage extends this by ensuring each condition within a decision independently affects the outcome, taking true and false values, while satisfying branch coverage. My algorithms generate test cases that meet these criteria, adapting to non-coupled and coupled scenarios.
Test Case Generation Algorithm for MC/DC Coverage
For non-coupled decisions, the algorithm proceeds as follows. Let a decision be represented as a logical expression $D$ with conditions $C_1, C_2, \dots, C_n$ and operators. The goal is to produce a truth table that fulfills MC/DC.
Step 1: Set the first condition $C_1$ to false (F). The value of the current processing condition is determined by traversing sub-decisions from bottom to top until a sub-decision where it acts as a non-determining condition is found, based on the logical operator.
Step 2: Iteratively select subsequent conditions as independent, with values opposite to the previous case. Then, choose other dependent conditions as current processing conditions, assigning values according to Rule A: (i) if the current condition is non-determining, its value is set by the preceding logical operator; (ii) if determining, by the logical operator of the sub-decision where it is non-determining; (iii) if always determining, by the logical operator of the same-parent decision.
Step 3: Generate the complement set of the first test case.
For coupled decisions, where conditions may appear multiple times, the algorithm adjusts:
Step 1: Set the first condition to F. The current processing condition’s value follows Rule B: if a first-level comparative sub-decision exists, its value is set by that sub-decision’s preceding logical operator; otherwise, by the current condition’s preceding operator.
Step 2: Choose subsequent conditions as independent, with opposite values. Then, select other dependent conditions, prioritizing those in the same branch as the independent condition, with values per Rule C: determined by the first-level independent sub-decision’s preceding operator; if absent and the current condition precedes the independent condition, use the independent condition’s preceding operator; otherwise, use the current condition’s preceding operator.
Step 3: Generate complement sets for cases from Steps 1-2, removing duplicates.
To map condition values to variable values, I incorporate equivalence class and boundary value analysis. For a motor control unit, variables can be Boolean or integer. Boolean variables with relational operators (e.g., equality) are assigned based on the operator and negation. Integer variables are handled via transformation: if arithmetic operators are involved, conditions are rewritten to isolate variables, then equivalence class and boundary algorithms derive values. For example, for a condition $x + 5 \geq 10$, rewrite as $x \geq 5$, then apply boundary analysis to choose $x = 5$ (boundary) and $x = 6$ (interior).
This process ensures that test cases for the motor control unit not only achieve MC/DC but also cover critical input domains. The mathematical formulation for condition independence in MC/DC can be expressed as: for a decision $D = f(C_1, C_2, \dots, C_n)$, each condition $C_i$ must satisfy $$\exists \text{ assignments } \mathbf{A}_1, \mathbf{A}_2 \text{ such that } f(\mathbf{A}_1) \neq f(\mathbf{A}_2) \text{ and } C_i \text{ varies while others are fixed}.$$
Test Case Generation Algorithm for Branch Coverage
Branch coverage is less stringent than MC/DC. For non-coupled decisions:
Step 1: Similar to MC/DC non-coupled Step 1.
Step 2: Generate the complement set.
For coupled decisions:
Step 1: Set the first condition to F per Rule B.
Step 2: Generate the complement set.
This yields two test cases per decision, ensuring each branch is taken. For a motor control unit with a decision like $(pressure > 100) \&\& (temperature < 50)$, branch coverage requires cases where the whole decision is true and false.
Test Case Generation Algorithm for Statement Coverage
Statement coverage requires every statement to execute at least once. The algorithm focuses on achieving decision outcomes that trigger all statements.
For non-coupled decisions:
Step 1: As in MC/DC non-coupled Step 1.
Step 2: Generate the complement set.
Step 3: If only the parent decision being true leads to specific actions, select test cases with true outcomes as the base set for statement coverage.
For coupled decisions:
Step 1: As in MC/DC coupled Step 1.
Step 2: Generate the complement set.
Step 3: Same as non-coupled Step 3.
This ensures that all code paths in the motor control unit are exercised, albeit with minimal cases.
Structured Requirement-Based Test Case Generation Algorithm
The overall approach integrates LLMs and the above algorithms. Structured requirements are represented using standardized symbols, as shown in Table 2, which facilitates parsing and path analysis.
| Symbol | Meaning | Symbol | Meaning |
|---|---|---|---|
| ○ | Start | □ | Process |
| ● | End | ▽ | Input |
| ◇ | Decision | → | Flow Line |
| • | Connector |
The intelligent generation steps are as follows:
Step 1: Structured Test Requirement Generation. I use an LLM trained on automotive domain texts, including motor control unit specifications, to transform functional documents into structured flowcharts. The LLM outputs two data parts: one for visualization and editing, and another with attribute details for each flowchart element.
Step 2: Structured Test Requirement Parsing. The flowchart may contain multiple branches. I parse it into paths from start to end, storing them in a path set. For each path, I extract and process elements sequentially.
Step 3: Coverage and Variable Assignment Selection. Choose structural coverage (MC/DC, branch, or statement) and variable assignment methods (equivalence class, boundary value, historical data).
Step 4: Start and Input Box Processing. Extract initial states from start boxes and input variable features (e.g., range, precision, valid values) from input boxes for equivalence class generation.
Step 5: Check for Decision Boxes. If a path contains decision boxes, proceed to Step 6-12; else, go to Step 13.
Step 6: Test Step Base Library Generation. From the first unprocessed decision box, extract the condition expression. Based on Step 3 settings and coupling detection, invoke the appropriate algorithm to generate a truth table for that decision, forming a test step base.
Step 7: Input Variable Value Extraction. Convert condition values to input variable values using the chosen assignment method.
Step 8: Handle Multiple Decision Boxes and Coupling. If other decision boxes exist without coupling, process each similarly and combine data (Step 9). With coupling, treat later decisions as having前置 conditions, merge truth tables, and cover coupled variables (Step 10). Otherwise, proceed to Step 11.
Step 9: Non-coupled Decision Processing and Combination. For each additional decision, repeat Steps 6-7, passing processed data downward and combining results across levels.
Step 10: Coupled Decision Processing and Combination. For coupled decisions, use prior decision data as constraints, combine truth tables, and ensure coverage of coupled variables.
Step 11: Expected Result Extraction. Extract expected outcomes from process boxes. If multiple process boxes involve coupled outputs, the last one’s value is taken as the expected result.
Step 12: Handling Other Paths. For paths not covered, assign default values to variables and handle coupled outputs as in Step 11.
Step 13: Generating Test Steps for Non-branching Requirements. Select mid-range values for inputs; if zero, use non-zero alternatives. Supplement with boundary values for outputs: choose input combinations that maximize and minimize output variables.
Step 14: Test Case ID and Purpose Generation. Generate IDs based on defined rules and purposes from structured content.
Step 15: Path Coverage Check. Repeat Steps 4-14 until all paths in the current requirement are covered.
Step 16: Overall Requirement Coverage. Iterate until all structured requirements are processed.
This algorithm enables automated test case generation for motor control units, adapting to various coverage needs. The coupling judgment can be formalized as: for a decision expression $E$, let $V(E)$ be the set of variables. Coupling exists if $$\exists v \in V(E) \text{ such that } \text{count}(v, E) > 1,$$ where $\text{count}$ is the occurrence of $v$ in $E$.
Algorithm Verification
To validate the approach, I implemented the algorithms in Java, emphasizing modularity for efficiency and maintainability. For instance, key functions include MCDC_Coupling() and BranchNonCoupling(), which handle different coverage scenarios. As a case study, I applied this to a motor control unit function: low-beam headlight control. The LLM converted the textual specification into a structured requirement, depicted as a flowchart with decisions like $(\text{ignition} == \text{ON}) \&\& (\text{position lamp switch} == \text{ON}) \&\& (\text{low-beam switch} == \text{ON})$. Using MC/DC coverage and boundary value assignment, the algorithm generated test cases automatically exported to Excel. For example, one test case sets ignition OFF, position lamp ON, low-beam ON, expecting the headlight to remain off. The generated suite covered all paths and met MC/DC, demonstrating efficiency and quality improvements for motor control unit testing.
The verification shows that structured requirements can be effectively transformed into executable test cases, satisfying coverage criteria. This method reduces manual effort while ensuring comprehensive testing of motor control units. In practice, for a motor control unit managing torque or speed, similar algorithms can generate cases for conditions like $(\text{speed} > 1000) || (\text{temperature} < 80)$, covering safety-critical scenarios.
Conclusion
In this research, I present an intelligent test case generation framework for automotive motor control units. By employing large language models to create structured requirements from functional specifications, and developing algorithms for MC/DC, branch, and statement coverage, I automate test case generation while incorporating equivalence class and boundary value analysis. The method parses structured paths, handles coupled and non-coupled conditions, and produces test cases that enhance development efficiency and quality. Future work could extend this to real-time motor control unit testing or integrate with simulation tools. Ultimately, this approach supports the rigorous validation required for modern motor control units in the evolving automotive landscape.
The algorithms ensure that test cases are both thorough and efficient, addressing the complexities of motor control unit software. By leveraging structured data and coverage metrics, I enable high-quality testing that aligns with functional safety standards, paving the way for more reliable motor control systems in vehicles.