2021 Ford F-150 Smart Reversing Wiper Motor software recovery and production launch.
Recovering a prototype-grade embedded-software effort by establishing requirements discipline, validation capability, Polarion traceability, staffing, and daily production-readiness control without attempting a risky late architectural rewrite.
When I assumed responsibility for Trico's software team in April 2019, the reversing-motor software worked, but the development system around it was not mature enough for a program of this scale. Requirements were sparse, validation was minimal, there was no dedicated software test bench or validation engineer, and the code remained largely monolithic.
Working software, but not a production-ready development system
My first step was to meet directly with the software team and ask for an unfiltered assessment. The inherited group consisted of three developers, with one already on the way out. The lead developer described the code as essentially prototype software and believed the program was at red-alert status.
The project was intended to follow ASPICE-oriented development principles, but meaningful requirements management and formal validation were largely absent. There was no dedicated validation resource, no software validation plan, no dedicated bench, and essentially no structured unit or integration testing.
The software itself was written close to the NXP microcontroller hardware and remained mostly monolithic. With production timing already compressed, a major architectural rewrite would have increased rather than reduced launch risk.
Stop the noise and make the product testable
I concluded that validation was the dominant unmanaged risk, but meaningful validation was impossible without a meaningful requirements baseline. I paused nonessential development work and protected the software team from being repeatedly pulled into DV issues that were more likely manufacturing or quality defects than software defects.
Polarion was already available, but the captured requirements were meager. We spent several weeks as a team decomposing requirements, improving their specificity, identifying missing functional behavior, and establishing the discipline needed to manage them as a controlled engineering baseline.
That traceability became the backbone of the recovery. It gave the team a controlled way to see what had been verified, what had failed, and what remained open.
Build the missing capability while continuing the recovery
While the requirements work was underway, I built a recovery timeline for management and requested three additional software developers plus a dedicated validation engineer. The full request was not staffed immediately, so the recovery had to begin with the people already available.
A dedicated validation position was ultimately established, and the development team reached four dedicated developers during part of the recovery. The staffing increase helped, but the more important change was that requirements, validation, defects, and release readiness were now being managed as one system.
Create the bench, then validate at multiple product levels
We did not have a dedicated software bench when the recovery began, so standing up that capability became part of the project. The bench allowed controlled testing of LIN behavior, communication faults, fault handling, recovery modes, and requirement-specific functional behavior.
The software was also validated as part of the physical product. Motor-assembly testing covered function, performance, and durability, and complete wiper-system testing exercised the same general categories at system level.
- LIN communication
- Communication faults
- Fault handling
- Recovery modes
- Functional verification
- Function
- Performance
- Durability
- Function
- Performance
- Durability
Recover the process without pretending there was time for a clean-sheet rewrite
The existing code remained largely monolithic. The practical recovery path was to make the current architecture production-capable through controlled requirements, disciplined change management, targeted development, traceable validation, defect closure, and daily readiness governance.
The recovery began in April 2019 and the software needed to be effectively production-ready by summer 2020, roughly a 15- to 17-month window. COVID-related vehicle-program delays provided useful schedule margin, but production software still had to be mature well before Ford began building trucks.
Production launch with the reversing architecture intact
The smart reversing-motor software reached production successfully. From a software-defect standpoint, the launch was successful: no post-launch software release was required to correct a software defect in the production application.
The job was not to become the software developer
The technical experts still had to write and debug the software. My responsibility was to recognize that the existing development system could not control the risk, listen to the engineers closest to the work, and create a realistic path to production.
That meant protecting scarce technical capacity, establishing requirements discipline, building validation capability, securing additional resources, and keeping requirements, defects, validation, and production readiness visible every day.