QTE（Quality Town for Embedded grade）
Next-Generation Testing Tool for Modern Development
Don't slow down the pace of AI-driven development!
MC/DC-Compliant "Coverage Measurement & Data Satisfaction Analysis Support Tool"
- Target Industry : Automotive, Robotics, FA, Medical, etc.
- Target Department : Embedded Software Development
- Standards : ISO 26262 / IEC 61508 Tool Certification Acquired
Problem
While AI has accelerated code writing, are you still manually calculating input values to satisfy complex conditions?
- While using AI significantly accelerates gtest code writing, it is difficult for AI to accurately infer and calculate the correct input values needed to satisfy complex C/C++ conditional statements (&&, ||).
Solution
QTE accurately measures up to MC/DC (Multiple Condition/Decision Coverage).
Furthermore, it analyzes unsatisfied elements and can output them in an AI-friendly format.
Provides the necessary information to satisfy unmet conditions in an AI-friendly format. By eliminating manual calculations by engineers and keeping the AI on track, it enables the completion of high-quality tests without halting the development pipeline.
Why is it necessary to go as far as "MC/DC coverage" now?
-
Simply covering C0 (statement) or C1 (branch) coverage is not enough to guarantee the quality and safety of today's complex embedded software.
-
1． [Functional Safety Perspective] Compliance with Standards (ISO 26262 / DO-178C, etc.)
In high-safety system development such as automotive (ISO 26262 ASIL-D), aerospace, and medical devices, measuring and satisfying MC/DC is a mandatory requirement.
-
２． [Quality Improvement Perspective] Eliminating Critical Bugs Hidden in "Combinations of Conditions"
Many major defects in the past occurred not from a single branch (C1), but from accidental combinations of multiple conditions, flags, and boundary values. By satisfying MC/DC, you can verify whether each specific condition functions correctly and independently without being masked by other conditions, allowing you to root out latent bugs before deploying to actual hardware.
Challenges in the Field: The "Last Mile" Encountered in AI x Free Tool (gcov) Environments
-
Limitations of gcov/lcov
While it can output C1 coverage rates, it is impossible to analyze which conditional expression prevents the truth value from being satisfied in MC/DC, or to back-calculate what input values are required to satisfy it.
-
Limitations of AI (LLMs)
AI struggles with calculating combinations of truth values in complex C/C++ conditional expressions, pointers, bitwise operations, and structure parameters. It repeatedly produces hallucinations (errors)—such as referencing non-existent properties or generating dummy data that fails to traverse the path—wasting engineers' time.
QTE's Solution
The Ultimate Division of Labor Between QTE and AI
Roles are clearly defined: "writing code" is the AI's job, while "determining the correct input values" is this tool's job.
Comparison: QTE + AI vs. Standalone AI vs. Traditional Manual Analysis
-
Evaluation Criteria QTE ＋ AI Standalone General AI
(Copilot, etc.)Traditional Manual Analysis
(gcov only)C1 Coverage Support ◎Measurement result analysis & presentation of additional info◯Automatic generation possible△Manual data calculation
（PC-Native / Target）MC/DC Support ◎Measurement result analysis & presentation of additional info×Frequent hallucinations×Extremely difficult(Manual work)Test Data
Derivation TimeA few seconds to a few minutes(Reduces AI processing time/tokens as the tool provides supplementary info)30 minutes to several hours through trial and error Several hours per location Engineer Workload Low(Only requires giving instructions via prompts)Medium(Verifying AI-generated data)High(Code tracing & manual calculation)
Cost Benefits of Implementation
-
While test code generation using AI (such as Copilot) is extremely powerful, attempting to resolve unsatisfied paths at the MC/DC level creates significant hidden costs due to the trial and error required for AI to derive "correct data."
By implementing QTE, you can dramatically optimize these costs.
Three Pillars of Cost Optimization
-
1
Significant Reduction in Engineering Costs
-
2
Optimizing API Token Consumption Costs
-
3
Mitigating Critical Bug Risks and Preventing Rework
-
1
Significant Reduction in Engineering Costs
When AI hallucinates (proposing incorrect input values) in complex conditional branches, it forces engineers to manually analyze the logic and revise their prompts. Because QTE directly provides pre-analyzed logical conditions, it minimizes the time engineers spend on trial and error, creating an environment where they can focus on their core, creative development tasks.
01
-
2
Optimizing API Token Consumption Costs
The back-and-forth prompting required to make AI repeatedly reload code and regenerate test cases consumes a massive amount of tokens, driving up API costs. By supplying the "pinpoint correct data" derived by QTE, you can generate the expected code on the very first try, effectively keeping LLM usage fees under control.
02
-
3
Mitigating Critical Bug Risks and Preventing Rework
Beyond simply reducing man-hours, reliably satisfying MC/DC prevents critical bugs that could otherwise surface during downstream development or post-shipment. Considering the rework costs and liability risks associated with severe defects, the return on investment is immeasurable.
03
Recommended Application Areas & Use Cases
-
Automotive ECU development (ISO 26262 compliance projects)
-
Functional safety software for medical devices, industrial robots, etc.
-
C/C++ middleware development involving complex combinations of pointers, structures, and bitwise operations
-
Development teams that have adopted AI-driven development but are stuck on the "last 15%" of coverage achievement
Product Feature Overview
Download Related Documents
Co-creating unprecedented evolution through unstoppable technology.
Please feel free to contact us for details on our products and services or to request materials.