The story behind the Rain Sensing Wiper

The development of the first Rain Sensing Wiper illustrates how a classic failure to fully conceptualize a product's physical architecture resulted in the discovery of integration issues at servicing time, thus quickly leading to engineering change requests. The scenario revolves around the initial introduction of the Rain Sensing Wiper (RSW) feature in an automobile manufacturer's vehicle program.

Before examining the reason of the failure of the RSW, let us briefly review the characteristics of the system. The RSW contains mechanical (optical mounting device), electronics (IR sensors and ECU), and software (computer vision algorithm) components that are procured by tier-one suppliers. These components are simply integrated by the manufacturer. The main parameters of the system are: (1) the optical and geometric specifications of the windshield, in particular its thickness and glass optical indexes, and (2) the ranges of operation of the electronic optical sensors. The detection software also has normal ranges of operation relative to these parameters, but in addition relies on data about the actual values of the parameters of the windshield.

The fact that the RSW electronics and software specifications include ranges for the relevant windshield properties is important, because it allows more flexibility on the choice of the windshield itself. This is a critical design choice, the procurement and integration costs associated with the windshield being an order of magnitude greater than that of the RSW. For optimal performance, the actual values of the windshield properties should fall near the center of the normal operating ranges both for the RSW sensors and the software; however, acceptable operation should be guaranteed for the whole range.

From a procurement standpoint, the windshield is simultaneously purchased from different suppliers. Depending on the year of production and where the product is manufactured, suppliers may modify the design of their windshields. Also, one or more changes of suppliers can occur during the production phase.

In the failure scenario, which occurred during the first year of the RSW's introduction, a local windshield supplier provided a component whose characteristics were incompatible with the operating range of the sensor. Unfortunately, no requirement for calibrating the system properly (i.e., for verifying that sensor and windshield are compatible) had been captured for the RSW at that point. Thus cars were sent to customers with a non-functioning wiper system.

Initial diagnostics designated the software as the culprit for the malfunction, since it was difficult for mechanics to test its behavior. The other components (ECU, sensor, and windshield) were functioning normally when tested independently. The failure mode for the RSW resided at the level of its sub-systems, which made it difficult for the manufacturer to discover it.

After discovering the root cause, a new requirement was captured to ensure that new systems will be properly calibrated at the production stage. In the SysML example, this requirement is named System Calibration and is shown in Figure 3 and Figure 5 in Part 1 of the article.

About the author

Dr. Laurent Balmelli is a research staff member at the Watson Research Center and a member of several leadership councils in IBM. His areas of expertise are integrated product development solutions, metamodeling, and systems engineering methodologies. He has been the technical lead for several customer engagements in the area of product development and systems engineering. Since 2003, Laurent Balmelli has represented IBM within the SysML submission team and is one of the lead authors of the SysML language specification. He was recently awarded the position of invited professor at the Graduate School of Systems Engineering and Management at Keio University in Tokyo, Japan, where he currently resides. He can be reached at balmelli@us.ibm.com.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• The story behind the Rain Sensing Wiper
• About the author
• Comments

Next steps from IBM

With Rational Software Modeler you can increase productivity by dragging and dropping your way to a visual interpretation of your UML design.

---

• Try: Download a free trial version of Rational Software Modeler, a UML 2.0-based visual modeling and design tool for architects, systems analysts, and designers.
• Article: Learn what UML limitations are and how you can overcome them with Rational Software Modeler.
• Tutorial: This tutoral provides a tour of Rational Software Modeler's Visual UML modeling tools.
• Demo: This demo guides you through the creation of a UML modeling with Rational Software Modeler.
• Buy: WebSphere Application Server - Express

My developerWorks community

Dig deeper into Rational on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers