Mitsuba Accelerates Development of Reversing Wiper System

“Model-based development immediately improved our development process. Design reviews were faster and more effective at uncovering defects and issues with requirements. We found errors earlier, eliminated rework, and delivered a high-quality controller in less than 20% of the time we needed before.”


Design and implement an innovative reversing wiper system controller


Use MathWorks tools to model, simulate, verify, and generate production code for the control system


  • Development time for a specific feature reduced from 16 weeks to 3 weeks
  • Design review time and paper documents reduced by 90%
  • Design verified early, minimizing rework
Reversing wiper system controller.

Mitsuba’s innovative reversing wiper system benefits both drivers and manufacturers. When not in use, the system is hidden below the hood, improving the look of the car and the driver’s view and reducing aerodynamic drag. The system’s embedded controller can dynamically modify the motor’s angle of operation to compensate for changes in wind pressure and wiper speed. Because the system minimizes the operating range of mechanical parts, the wipers are more compact and can be more easily integrated into the vehicle design.

Using MathWorks tools, Mitsuba engineers developed the wiper system’s controller and delivered a complete system— including production code—in just three weeks.

“Even though we were new to the approach and tools, we saw clear improvements in development speed and product quality,” says Takao Arai, engineer in the Electric Engineering Department at Mitsuba. “Model-based development with MathWorks tools enabled us to identify and fix problems with the project requirements and early designs rather than late in development when testing on the final hardware.”


A reversing wiper system is more challenging to design than a conventional system because the controls are considerably more complex.

Mitsuba’s previous development process relied on paper-based requirements specifications and handwritten code. Debugging and tolerance testing (parameter tuning) were possible only on actual hardware, so most problems were not found until the later stages of development and resulted in significant rework that compromised system quality. Mitsuba engineers needed to accelerate development of the system to meet a tight deadline.

Because the system was a first for Mitsuba, they needed to verify new control algorithms and design ideas as early as possible. “In the past, our design reviews took a long time because it’s hard to understand design details using only written documentation,” says Arai. “The trend in our industry is toward model-based approaches. Many of our customers—automotive OEMs—have already moved in this direction, and it was clear that we needed to as well.”


Mitsuba used MathWorks tools to model, simulate, verify, and generate production code for the reversing wiper system control. Before beginning the project, Mitsuba took steps to ensure a smooth transition to model-based development. Engineers attended 10 days of onsite training, and the group drafted modeling guidelines and a design procedure. To foster the engineers’ continued education, Mitsuba developed skill standards based on JMAAB Style Guidelines, established by the Japan MATLAB® Automotive Advisory Board and based on Embedded Technology Skill Standards. At the same time, Mitsuba was promoting the use of models and simulation to accelerate development, increase quality, and improve communication both internally and with customers.

Working from the specification, Mitsuba engineers used Simulink® to model control structures, control functions, and test harnesses.

With Simulink and Simscape Multibody™ the group created a plant model, which included the windshield wiper link mechanism, wiper arms, and body mount.

They ran closed-loop simulations using the control system and plant models to verify the functionality of the controller and determine how the physical specifications of the wiper would affect motor control. Based on these simulations, the team performed variable scaling to create a detailed control model.

Using Simulink Coder™, they generated C code from the control and plant models, which they used to conduct software-in-the-loop and real-time processor-in-the-loop simulations. To perform hardware-in-the-loop simulations, they used the test harness created with Simulink and Stateflow® to drive the plant model code on an embedded processor.

The engineers used Embedded Coder® to generate production code for an NEC 78K series 8-bit microcontroller, and then conducted final tests on the production hardware.

The reversing wiper system is currently in production, with monthly shipments of 20,000–30,000 units.

Mitsuba engineers are reusing components of the wiper system and plant model on current projects. The company has standardized on model-based development for all new projects, including motor control products for hybrid and electric vehicles.


  • Development time for a specific feature reduced from 16 weeks to 3 weeks. “With our previous design process, taking a specific feature project from specification to production code running on a microprocessor typically required about 4 months,” says Arai. “With model-based development we completed the project in just 3 weeks. The ability to debug and test through simulation—instead of only on hardware—further accelerated development.”

  • Design review time and paper documents reduced by 90%. “We used our Simulink and Stateflow models as an executable specification, which streamlined the design review process significantly,” notes Arai. “We completed a thorough review in 10% of the time we’ve required in the past while eliminating 90% of the paper documentation used at every review stage.”

  • Design verified early, minimizing rework. “Model-based development enabled us to discover missing or conflicting requirements before testing on hardware, which minimized the amount of rework we had to do,” says Arai. “Plus, using Simulink we can run simulations using input patterns that would be difficult or impossible to test on the hardware itself.”