Mitsubishi Electric Mechatronics Software Co., Ltd. Shizuoka Office

Among the residential room air conditioners developed by Mitsubishi Electric Mechatronics Software, we first asked about the control of the "indoor unit," which is easy for the general public to understand.

– Could you please introduce yourselves and tell us about the development work you usually do?

Mr. Hakamada :

I joined the company in 1998. I started out developing software for outdoor units of room air conditioners. After a few years, I moved to other departments, where I gained experience developing sales support systems and software for remote controllers, such as the wall-mounted units used for central air conditioning in buildings. Recently, in that department, I was also involved in developing smartphone apps to remotely control air conditioners. Currently, I have returned to the Equipment Development Department, where I originally started, and am managing development operations.

Mr. Ishikawa :

I joined the company in 2006. In the Equipment Development Department, we develop software for both indoor and outdoor units of room air conditioners, but I have been dedicated exclusively to software development for outdoor units ever since I joined. You may have seen our products in TV commercials under the brand name "Kirigamine," and I am precisely in charge of software development for those products.

– We often hear about your room air conditioner brand "Kirigamine" in TV commercials. We understand that recently it can detect the "perceived temperature" tailored to occupants in the room. Could you explain what kind of technology this is?

Mr. Hakamada :

The feature highlighted in Kirigamine's commercials, such as those featuring "people who feel hot vs. people who feel cold," is the airflow control function of the indoor unit. The latest feature is "MoveEye mirA.I." (MoveEye Mirai). It uses a 360-degree rotating sensor to recognize room temperature distribution visually. Previously, feedback control was performed to actively direct cool air toward high-temperature areas after recognizing changes in temperature. With this approach alone, temperature control lagged behind changes, placing limits on maintaining room comfort.

– The "AI" in "MoveEye mirA.I." stands for artificial intelligence, correct?

Mr. Hakamada :

That is correct. "MoveEye mirA.I." is equipped with artificial intelligence that learns daily room temperature conditions. Based on this, by "predicting" temperature changes throughout the room, it can control airflow direction to each location in the room more appropriately. It is said that a temperature change of just 1 degree Celsius leads to 10% energy savings, so this type of "predictive" control contributes significantly to energy savings as well.

Mitsubishi Electric's room air conditioners feature multiple flaps to control airflow direction, delivering three-dimensional airflow rather than just a continuous stream. We asked about this technology.

– In room air conditioners, the flaps that determine airflow direction move automatically and precisely, right? Doesn't your technology have unique features here as well?

Mr. Hakamada :

Using "MoveEye mirA.I." to detect who is where and deliver optimal airflow control is a key signature of Mitsubishi. What makes this possible is a feature called "Takumi Flap." By controlling vertical flaps, horizontal flaps, and inner louvers, it not only adjusts flap direction but also varies air volume using the width of the flaps. Multiple stepping motors are used to achieve precise control.

On recent models, the "MoveEye mirA.I." temperature sensor allows the system to direct vertically changing airflow if it detects someone standing, or deliver a gentle horizontal breeze if it detects someone lying on a sofa. It can control this simultaneously for two people in a room. It is designed to deliver customized, comfortable airflow simultaneously to "people who feel hot" and "people who feel cold." I think this technology truly earns us the reputation of "Mitsubishi for Airflow Control."

– What kind of microcontrollers are used to perform these controls?

Mr. Hakamada :

For indoor unit control, we use one 16-bit microcontroller. On models equipped with the "MoveEye mirA.I." temperature sensor, there is an additional dedicated 16-bit microcontroller that handles image acquisition and recognition processing from the temperature sensor. This information is sent to the main unit's microcontroller, and they operate cooperatively.

Next, we asked about the control system on the "outdoor unit" side of room air conditioners.

– The outdoor unit is the equipment installed outside the room, correct? Could you explain how it operates?

Mr. Ishikawa :

Air conditioners cool the air by utilizing the property of a "liquid" refrigerant absorbing heat from its surroundings as it evaporates—that is, as it transitions into a "gas." First, let me explain the mechanism of cooling through the changes in the state of the refrigerant.

First, the refrigerant that has returned from the indoor unit as a "gas" is compressed by the compressor in the outdoor unit. The high-temperature, high-pressure refrigerant enters the heat exchanger of the outdoor unit and is cooled by a fan, undergoing "liquefaction" while releasing heat.

Next, the expansion valve (LEV) reduces the pressure of the "liquid" refrigerant. The refrigerant, now at a lower pressure and more prone to vaporization, enters the indoor unit's heat exchanger. There, it evaporates into a "gas" while absorbing surrounding heat, which cools down the heat exchanger.

Indoor air is drawn in by a fan and passes through this chilled heat exchanger, blowing back into the room as cool air.

The refrigerant, now a low-temperature, low-pressure "gas," returns to the outdoor unit's compressor, and the cycle repeats.

The microcontroller in the outdoor unit manages this refrigerant pressure by controlling the compressor's three-phase motor. PID control, the foundation of feedback control, is applied here. The software performs calculus computations and is implemented on a 32-bit microcontroller.

– Given that it is an outdoor unit, do you face challenges operating it under harsh environmental conditions?

Mr. Ishikawa :

Recently, predictive elements have been incorporated into outdoor unit control as well. Standard PID control acts to correct output after a change occurs; however, this approach risks damaging the equipment under excessive loads. Therefore, when heavy loads are anticipated, pressure is controlled in advance. For example, if the heat released during refrigerant compression causes temperatures to rise excessively, it could damage components like the heat exchanger while also wasting electricity from an energy efficiency standpoint. We utilize predictive control to prevent such issues.

The compressor motor in the outdoor unit utilizes three-phase AC PWM control via an inverter to adjust rotational speed. While precise control of this motor type is challenging, we have been utilizing it for over a decade and have established the foundational control methodology in-house. It is primarily a process of tuning control constants to match specific operating environments and destination market specifications.

Next, we asked about how the software is developed, its architecture, and how it has evolved over time.

– Embedded software is generally developed in C, but have there been any shifts in the programming languages you use?

Mr. Hakamada :

This goes back more than 15 years. At that time, air conditioner control software was basically written in assembly language. Since assembly depends heavily on the specific microcontroller type, we decided to transition from assembly to C at a certain point to improve development efficiency. However, initially, our efforts focused mostly on replacing assembly code line-by-line with C, resulting in software that was essentially a massive collection of global variables.

We gradually advanced its structuring over time, and while we do not use C++, the features today are almost fully structured and encapsulated. We encapsulate functions based on the principle of "one function, one purpose," adopting structured design principles that pay close attention to coupling and cohesion.

Mitsubishi Electric Mechatronics Software Co., Ltd. Shizuoka Office is a long-standing customer who has been using CoverageMaster since its early versions. We asked them what originally prompted them to adopt CoverageMaster.

– Your company adopted CoverageMaster back in 2005. Could you tell us what originally led you to adopt CoverageMaster at that time?

Mr. Ishikawa :

At our company, we originally had a rule to perform unit testing back from the assembly language era, and at that time, we performed unit tests using step execution within a debugger. However, it was difficult to standardize unit testing methods and evidence. While we kept records of pass/fail test output results, establishing objective evidence to evaluate overall coverage or identify omissions remained a major challenge.

Additionally, because it was manual work using a debugger, it was simply time-consuming. It was standard practice to rerun unit tests whenever the MCU or compiler changed, so performing manual operations every single time was terribly inefficient, which was another major issue.

Therefore, to improve efficiency, we considered introducing CoverageMaster and decided to adopt it. At the time of adoption, CoverageMaster's manuals and guidebooks were not fully established, so we developed our own internal manuals and procedures to enable operational use of unit testing with original MCU compilers within our company.

– For unit testing C code, it seems possible using a PC environment like Visual Studio. Why did you consider CoverageMaster specifically?

Mr. Ishikawa :

While using Visual Studio or other unit testing tools was indeed an option, our requirement was the ability to test with code output by the embedded MCU's original target compiler. Having originally developed in assembly language, our core philosophy is to conduct tests matched to the actual MCU environment. For example, there were unit testing tools that utilized GNU native compilers, but we hold the view that testing at a different level from the hex object code actually written to the product ROM is not fully trustworthy. Wanting concrete evidence tested against actual target code was our primary reason.

Currently, CoverageMaster is used as a standard tool for unit testing. We asked about how they routinely use it.

– Could you tell us how you routinely use CoverageMaster?

Mr. Ishikawa :

We perform functional testing and coverage verification based on code output by the MCU's original target compiler. Whenever an unexpected result occurs, checking coverage while viewing CoverageMaster's mixed assembly display, or linking CoverageMaster's built-in code debugger to step through code and investigate the root cause, is a daily routine for us. I was actually doing that yesterday, too (laughs).

– How are your test cases created?

Mr. Ishikawa :

Recently, we shifted our mindset from white-box testing to a black-box testing perspective. The idea is to create test patterns for testing functionality based on function specifications. We embed test patterns within the detailed design documents of functions, allowing macros to export them into CoverageMaster's CSV format. We manage this so that when a function is reused, carrying over the design document automatically brings the test patterns along. We are advancing CI (Continuous Integration) principles and aim to automate as much as possible.

– Do you utilize the automated test case creation feature?

Mr. Ishikawa :

Yes, from a white-box perspective, we use the automatic generation feature in CasePlayer2. We use it for retesting long-standing library functions whenever we change the MCU or compiler. We generate test patterns achieving 100% coverage using CasePlayer2's auto-generation feature and use them to verify whether they produce the same results in the new MCU environment.

The catalyst for this was back in 2011, when the earthquake disrupted MCU supplies and we had to switch microcontrollers. Regrettably, we were not using CasePlayer2 at the time, and creating test patterns was a major struggle. Today, we fully utilize CasePlayer2's auto-generation feature to streamline our process.

Our benchmark for coverage is C0, which can be measured using target code alone. C1 is performed only when necessary.

– Are there any features you utilize for managing test evidence?

Mr. Hakamada :

Ideally, results for all functions from unit testing and coverage measurement should be compiled into a test report so they can be reviewed at a glance. Previously, pass/fail status for each test case was recorded on individual test sheets, making it difficult to summarize the overall picture. With CoverageMaster, coverage rates are displayed quantitatively as percentage values, which I think is great because it makes the evidence explicit.

Mr. Ishikawa :

We use CoverageMaster's result output sheets, which summarize the results of all tested functions in HTML. However, because comments cannot be added directly to the HTML afterward, we cannot append details such as reasons why coverage did not reach 100%. Therefore, we use an in-house tool we developed to add information to the generated HTML files.

Recently, SQA representatives have begun participating in reviews to verify the contents of software quality evidence. While test results were previously used only internally within development, using the HTML result output sheets as evidence now allows us to demonstrate quality to third parties as well.

Finally, we asked about their expectations for GAIO moving forward.

– As GAIO is one of the few tool vendors in Japan, what are your expectations for our company going forward?

Mr. Ishikawa :

As a unit testing tool, it has become a staple within our company and is smoothly operated, so we are generally satisfied. Outside the scope of unit testing, we currently use tools from overseas vendors to verify variable exclusion relationships, but combining tools from multiple manufacturers is challenging. It would be ideal if GAIO offered a tool that could check for such exclusions and conflicts.

Mr. Hakamada :

During the design phase, we would like to utilize PC-based simulator environments more extensively. To achieve that, it would be helpful to have features that mock peripheral devices—especially standard I/O, A/D, and PWM outputs—so they can be easily incorporated into simulations. Developing software in a "hardware-free" (target-less) environment is our ultimate goal, but since doing so requires significant time and money, we hope GAIO will develop tools that can address this area.

Through this interview, we learned from Mitsubishi Electric Mechatronics Software Co., Ltd. Shizuoka Office, Equipment Development Department that their unit testing is fundamentally based on embedded MCU "target code," and that they utilize "CoverageMaster winAMS" as a standard in-house tool to streamline unit testing and generate software quality evidence.

GAIO TECHNOLOGY will continue striving to improve tool functionality and propose new solutions, including addressing the feedback received at the end, to contribute to verifying embedded software quality.

* "Kirigamine" and "MoveEye mirA.I." are registered trademarks of Mitsubishi Electric Corporation.
* "Visual Studio" is a registered trademark of Microsoft Corporation in the United States and/or other countries.