AUBASS Co., Ltd.

Shimada :

Could you please introduce AUBASS?

Mr. Yanagisawa :

Established in April 2016, we are a company with 51% DENSO capital investment, developing BSW that complies with AUTOSAR, the international automotive standard.
In addition to operating systems, we develop functional module components for communications, security, and other areas.
Rather than manufacturing vehicles directly, our role is developing the lowest-layer software that underpins applications and control logic.

Shimada :

What are your respective roles?

Mr. Shirai :

I am in charge of functional development for diagnostic (DIAG) communication.
To put it simply, "DIAG" is a function that stores internal vehicle information, which can then be read out by external tools for diagnostic purposes.
In other words, rather than handling core vehicle functions like driving, turning, and stopping, DIAG uses stored data to diagnose problems whenever a failure occurs.

Mr. Yanagisawa :

I am responsible for developing module components for "reprogramming" (reprog), which is used to rewrite automotive ECU software.

Shimada :

Is there anything in particular you pay close attention to during development?

Mr. Shirai :

For DIAG, specifications regarding the stored information are mandated by regulations.
Non-compliance with regulations could lead to recalls, so we carry out development with meticulous care to ensure full compliance with specifications.

Mr. Yanagisawa :

Because reprog software is designed to rewrite software when defects occur, defects in the reprog software itself are completely unacceptable.
Furthermore, since we always have to deploy across nearly ten different types of microcontrollers (MCUs), tailoring our development to the specific characteristics of each MCU is both challenging and rewarding.

Shimada :

Are allowable execution times clearly defined for the module components you develop?

Mr. Yanagisawa :

Since our Tier 1 customers develop a wide variety of ECUs, allowable control times differ for each ECU. There are also cases where explicit requirements for allowable execution times are not provided.
In those cases, we establish allowable execution times based on our internal standards while considering the specifics of each ECU.

Mr. Shirai :

Performance verification is defined within our development process as an essential step for finalizing logic. Only after confirming that execution falls within the allowable time limit is the logic finalized, allowing us to move on to unit testing and subsequent test phases.

Shimada :

Could you tell us about the background behind introducing PLAS-Qlite V2?

Mr. Yanagisawa :

Since our company does not possess actual ECUs, we had been conducting performance verification using actual hardware such as evaluation boards. However, we struggled with the limited availability of physical hardware units and the substantial setup man-hours required for measuring on actual hardware.
Around that time, we were introduced to PLAS-Qlite V1—a performance verification tool that reflects latency—and evaluating it served as our initial trigger.
Unfortunately, it lacked certain features necessary for our specific use cases, so we did not adopt it at that time and requested additional capabilities instead.

[Requested Features]
・ Performance measurement at the functional module (function integration) level
・ Specification of the performance measurement range (*Overall execution results of the entire test scenario are not required)
・ Output of maximum, minimum, and average values for functions within the specified range

Mr. Shirai :

Regarding the background of these requested features, designing test scenarios at the functional module level makes them much easier to visualize and construct.
However, when executing those test scenarios—in the case of DIAG, for example—there is preliminary setup processing during the preparation phase. Since we wanted to exclude this preliminary processing from the performance measurement, our request was to be able to specify a measurement range and output execution results specifically for functions within that designated range.
Subsequent to our request, these features were implemented, leading us to re-evaluate the tool and ultimately adopt it.

Shimada :

Could you tell us about your operations after introducing PLAS-Qlite V2?

Mr. Shirai :

Initially, we thought we could perform measurements using PLAS-Qlite V2 alone. However, since there is a variance between the measurement results from PLAS-Qlite V2 and actual hardware, we use it alongside actual hardware measurements from a quality assurance perspective.

Mr. Yanagisawa :

Once the logic is finalized, we take measurements with PLAS-Qlite V2 to identify potential performance concerns. For areas that look risky, we immediately measure them on actual hardware.

Mr. Shirai :

Measuring everything on actual hardware is time-consuming. The key improvement was using PLAS-Qlite V2 to establish a process for selecting measurement targets, thereby minimizing the number of locations that require measurement on physical hardware as much as possible.

Shimada :

Are there any features you hope to see in future releases of PLAS-Qlite V2, or do you have any requests for our company?

Mr. Yanagisawa / Mr. Shirai :

We have three main requests for the future.

First, we would like to see improved measurement accuracy. If accuracy is enhanced, we can further reduce the workload associated with actual hardware measurements.

Second, we would like the ability to measure mutual exclusion processing time. If the duration of interrupt-disabled sections can be measured, it will enable performance evaluation that takes into account the wait times of processes delayed during those sections.

Third, we would like to reduce the setup time for PLAS-Qlite V2. Regarding latency configuration in particular, it would be very helpful if preset configuration files were provided based on specific MCU part numbers.

If these three points can be addressed, we believe we will be able to utilize PLAS-Qlite V2 even more efficiently than we do now.

Through this interview, we learned how AUBASS Co., Ltd. successfully reduced performance measurement workload on actual hardware by introducing PLAS-Qlite V2.

Additionally, we confirmed that further man-hour reductions can be achieved by enhancing the measurement accuracy of PLAS-Qlite V2. GAIO TECHNOLOGY will continue its efforts to propose even better solutions in response to the requests received from AUBASS.

From left: Mr. Shirai and Mr. Yanagisawa, Development Section 3, Development Unit, AUBASS Co., Ltd.

*Note: PLAS-Qlite is for use in Japan only (cannot be used overseas).