DENSO CORPORATION

First, our guests introduced themselves and shared their career history and responsibilities at the company from when they joined up to the present.

– Could you please introduce yourselves and tell us what kind of development work you have been involved in?

Mr. Makino :

My primary focus has traditionally been on the development of functional safety microcontrollers, working on microcontroller-related development environments. As part of this, I have developed environments for measuring code coverage and MC/DC using microcontroller simulators, as well as tools that log internal microcontroller values for EPS (Electric Power Steering) calibration.

Currently, as part of microcontroller technology planning specifically related to redundant functional safety, I am involved in constructing and verifying safety concepts for ASIL-D, which represents the highest level of functional safety requirements.

Mr. Watanabe :

I have been working in the EPS department since around 2005, making it about 13 years now. Initially, I was in charge of control software development for EPS-ECUs, but observing the development work of engineers around me at the time, a significant portion—starting with unit testing—was being performed manually.
Driven by a desire to streamline this process as well as my own personal interest, I developed an automated programming tool and proposed it.
It was warmly received by the engineers around me, which served as the catalyst for my involvement in unit testing automation.

– We understand that Mr. Makino has been involved in the development of microcontrollers related to functional safety. Could you tell us what a functional safety microcontroller is?

Mr. Makino :

First, I would like to share the history of functional safety microcontrollers. Around 1990, I began developing software for ABS (Anti-lock Braking Systems) together with automakers, which marked the start of my involvement with safety systems. Around 2002, I transferred to the EPS department and developed software for electric power steering. Leveraging that experience, around 2004, I began planning and developing "functional safety microcontrollers" in collaboration with microcontroller manufacturers.

A "functional safety microcontroller" is a microcontroller that controls critical vehicle functions—specifically "driving, turning, and stopping"—where safety is especially paramount.

At that time, the ISO 26262 functional safety standard for automobiles did not exist yet, so the meta-standard IEC 61508 served as the functional safety requirement. While single-core microcontrollers were mainstream back then, discussions began regarding safety configurations using lockstep dual microcontrollers, and I was deeply involved in defining this architecture.

Back then, the prevailing philosophy was "fail-safe"—stopping the system if a fault occurred. However, around 2010, the shift moved toward "fail-operational," where control continues even if a failure occurs. At DENSO as well, there has been a trend transitioning from single-channel to dual-channel designs—so-called "redundant functional safety." Consequently, multicore microcontrollers or two independent microcontrollers have become new safety requirements.

Mr. Makino :

Various new requirements are emerging for automotive software, but in fulfilling them, the reality is that development teams will not accept solutions unless legacy software assets are carried over. One major concept is implementing functions in hardware to satisfy new requirements without putting a burden on the software. For example, safety design features include "stack separation" and "memory protection." If you were to write these features entirely in software code, you would face challenges where design becomes difficult and final performance targets cannot be achieved.

Therefore, functions need to be implemented in coordination with hardware. Striking the right balance—implementing functions with short "fault tolerant time" requirements (meaning short time constraints after a fault occurs) in hardware and others in software—is a key design technique. I believe this is an interesting and rewarding area for engineers.

– Currently, CoverageMaster is used as a standard tool not only in the EPS development department but also across other divisions. Could you tell us what prompted its adoption?

Mr. Makino :

Regarding software compliance with functional safety, methods such as "Software Criticality Analysis"—which categorizes risk levels for each functional element of software—and "Structural Coverage"—an analysis method focusing on structural completeness of software—were being applied. In particular, regarding code coverage, we began considering whether "MC/DC" measurement proposed by NASA could be applied to our control software.

At that time, we were evaluating a system that used an embedded microcontroller and peripheral simulator. However, MC/DC measurement cannot be achieved solely through the execution environment; it requires a mechanism to instrument the original source code and extract intermediate execution results within conditional statements. We were searching for a method that could make this possible.

Around that time in 2007, I happened to encounter "CoverageMaster" at a trade show. Learning that it was a tool designed to measure coverage using target MCU code, we considered adopting it. Later, as its features were enhanced to enable MC/DC measurement, we integrated it into our in-house tool. In the initial in-house tool setup, we ran both CoverageMaster's ISS and a semiconductor manufacturer's ISS to confirm that their execution results matched. Having thoroughly verified their consistency, we have now reached full-scale operations utilizing CoverageMaster alone.

– Could you tell us how unit testing automation is achieved using this in-house tool?

Mr. Watanabe :

I am developing DENSO's in-house automated unit test execution tool. The tool is named "D-SPIDER." We named it "SPIDER" with the concept of catching bugs in a spiderweb, while the "D" stands for "DENSO." Let me explain how the system works.

First, the test engineer enters the target function name, designed input/output variables, input values, and expected values into DENSO's proprietary unit test data format. Prioritizing color-coding and legibility, we use Excel XLSX files for their high formatting flexibility rather than CSV files.

Users simply specify the created Excel file in D-SPIDER's UI and click the execute button. D-SPIDER invokes CasePlayer2 to analyze the source code of the specified function and generate instrumented code for MC/DC measurement. Furthermore, it calls the cross-compiler to compile the instrumented code, generating object code executable in CoverageMaster.

To compile the instrumented code, the original makefile must be modified accordingly, and we have automated this mechanism as well.

In this way, after automatically generating the environment—including the object code for unit test execution—D-SPIDER converts the test cases listed in Excel into CoverageMaster CSV format, invokes CoverageMaster, and executes unit testing alongside MC/DC measurement.

The execution results from CoverageMaster's CSV are written back into a DENSO-formatted Excel file by D-SPIDER. This includes match/mismatch results against expected values for each test case, MC/DC coverage percentages, and coverage reports. Taking advantage of Excel's color-coding, we incorporated features such as highlighting mismatched test cases in red to make it easy to review test results later.

From the user's perspective, it offers a remarkably simple interface where clicking a button automatically executes unit tests on a specified MCU simulator and returns results including pass/fail evaluation against expected values and MC/DC coverage percentages. Rather than operating on a server, D-SPIDER is installed on each engineer's client PC, functioning as a local tool that drives unit testing.

– How are test cases created?

Test cases are created manually by each test engineer based on function specifications. We do not automate this part. Unit testing at DENSO has a long history predating automated mechanisms like D-SPIDER, and we continue to use the same methodology for test data design.

Before D-SPIDER, we used MCU simulators other than CoverageMaster at times, but even when tool mechanisms change, we ensure that test engineers can continuously use the same test design methodology. The same applies when the MCU is changed. Because of this, test case files created based on function specifications can also be continuously operated in the exact same manner.

– Could you tell us what benefits were gained by enabling the automation of unit testing?

Mr. Watanabe :

When source code is modified, we rerun the test by passing the same test cases through D-SPIDER. Testing in D-SPIDER executes all operations automatically with just the click of a button, keeping retesting man-hours to a minimum. By building up test cases as reusable assets, we can perform regression testing to check for degradation every time source code changes, without placing a burden on our engineers.

Mr. Makino :

D-SPIDER integrates all tasks performed by test engineers, including unit test preparation, execution, and evaluation of results. Until recently, this tool had no official name, so to describe it, we had to use long explanations like "a tool that automatically handles everything from unit test preparation to execution and evaluation tailored to the user's environment." Therefore, we named it "D-SPIDER" to make it memorable and convey the image of catching bugs in a spiderweb.

It was completed around 2012 as a tool for EPS, and gradually gained traction across the company. Currently, its adoption has expanded to departments beyond EPS, with plans underway to expand to 6 departments this fiscal year and 12 departments next fiscal year.

– Finally, could you share any requests or feedback you have for GAIO?

Mr. Watanabe :

I sometimes receive questions about CoverageMaster from internal users operating D-SPIDER. Because CoverageMaster supports a wide range of microcontrollers, it can be adapted across many departments. On the flip side, because it offers numerous parameters, operation can sometimes be complex. For example, for users who only want to use specific functions, having something like a "Simple UI Mode" would make it much easier to use.

Additionally, display customization features would be convenient. For instance, allowing users who prefer simplicity to see only a limited selection of menus and buttons would help drive broader adoption within the company.

Since adopting GAIO's tools, user support has been comprehensive, so we have no particular complaints. Responses to our inquiries are prompt, allowing us to work with confidence.

Mr. Makino :

To perform unit testing, the initial input requires designing test cases. This is where engineers put in significant effort and sweat, but the heavy burden remains an ongoing challenge. Therefore, we would like to introduce automated generation features that assist in test case creation. For example, we hope GAIO will propose features that support test case creation based on specifications, focusing on test perspectives such as maximum and minimum variable values, boundary conditions (±1), and median values for equivalence partitioning. CoverageMaster already includes test analysis functions and editors, but we hope for more advanced support capabilities building on those.

Next, from a governance perspective, tools and development processes are becoming increasingly standardized. Achieving this requires rich toolchains across tool vendors. If individual tool vendors establish standards that allow deeper integration at interface boundaries between tools, it would accelerate the deployment of new tools.

Furthermore, D-SPIDER achieves its functionality through integration with GAIO's tools. In the past, a CoverageMaster version update caused an issue where the D-SPIDER system stopped working. To prevent such incidents, we would appreciate receiving information on interface changes at an early stage prior to version updates.

In this interview, DENSO CORPORATION's Chassis Control Components Department spoke about their in-house automated unit testing tool developed using CoverageMaster. We learned how constructing a mechanism to automatically execute MC/DC coverage measurement required for functional safety with the click of a single button has standardized unit testing across many DENSO departments, significantly contributing to streamlining quality verification for automotive software.

GAIO TECHNOLOGY will continue striving to improve functionality, including addressing the requests received at the end, so that our tools can continue to serve as standard unit testing tools in the future.