From failed feature test to
cross-team fix in minutes

Summary

Cars are built by many specialist teams. A feature's requirements are signed off and tested once, on an early software version, and marked as passed. After that they are rarely checked again. Later versions keep changing underneath them, so a feature that passed can quietly stop working, and nobody finds out until integration, months later.

In this case study, the cabin-comfort requirements had already been signed off and passed on an earlier version. A later change by another team broke them. Vinci re-checked them against the new version, found the cause and reached every responsible engineer in about ten minutes, by one person, while still in development. The usual path is a failure at integration months later, followed by days of meetings across four teams.

The system in plain terms

An electric car's thermal system has one job that the driver notices in cabin and the second that they don't in the powertrain. It keeps the cabin comfortable, and it keeps the battery and motor at safe temperatures. Several engineering teams build it together, and each team owns one part.

Three subsystems behind one feature

• Cabin Climate is the air handler behind the dashboard: blower, vents and flaps. Its software decides how cold the air leaving the cooling coil should be.
• Refrigerant is the air-conditioning loop: the compressor and the cooling coil that actually makes the air cold. Its software runs the compressor and stops the coil from icing up.
• PT Cooling (powertrain cooling) is the radiator and coolant loop that keep the battery and motor cool.
• Thermal Feature isn't hardware. It is the promise to the driver, such as "the cabin stays within 1.5 °C of the temperature you set", and it is only kept if all three subsystems work together.

Where the subsystems touch

The teams work separately, but their parts are physically connected:

• The cooling coil sits between Cabin and Refrigerant. Cabin asks for an air temperature; Refrigerant runs the compressor to deliver it.
• The radiator fan at the front of the car is shared by Refrigerant and PT Cooling. It runs at whichever team's request is higher.

A change that looks local to one team can therefore change how another team's part behaves.

Each team builds and tests its own box. The driver experiences the whole, and the two shared parts are where one team's change reaches another.

How requirements are layered

Each promise to the driver is broken down, level by level, into instructions precise enough for one team to build. A change at the bottom can break a promise at the top.

Who owns what

In Vinci the four projects are linked as one workspace, with 90 links running from the feature requirements down into the subsystems.

What went wrong

The cabin-comfort feature had already passed its tests on an earlier version, so it was considered done. Then, in a later version, the PT Cooling team made a minor calibration change: they turned down the radiator fan to save energy and noise. Their own tests passed. But the same fan also cools the air conditioning, so the change reached the Refrigerant team and then the Cabin team, and on hot days the driver ends up in a cabin that won't stay cool.

Each team's own checks still passed, and the feature's earlier pass was still on record, so no one could see the problem.

Why this goes unnoticed today

The biggest issue is not the change itself. It is that requirements and their tests are not re-verified as the product evolves. This is one of the biggest flaws of the V-Cycle: requirements once tested are signed off instead of being monitored continuously.

The software industry solved "breaking what already works" with CI/CD pipelines. Hardware companies still do not have that luxury. Continuous monitoring is expected of systems engineers who are already working on the next programme's feature set. Robust active coverage has become close to impossible under the sheer complexity of both the systems and the market.

A requirement that passed on Thermal Feature version 1 keeps its "passed" status while the downstream systems keep evolving from v1 to v10 until integration begins. The failure stays hidden until the whole car is assembled and tested at integration, often months later. By then the change that caused it is long forgotten.

Workflow without Vinci

The feature is checked once, and the problem surfaces months later.

1. The feature passes its tests on an early version and is signed off. Its "passed" status never expires.
2. Downstream evolved versions change the parts underneath it, including PT Cooling's fan calibration. Nobody re-runs the feature tests.
3. Months later, at integration, the assembled car fails: the cabin won't hold its temperature.
4. Four teams each check their own part, and each part looks fine. Days of meetings follow until someone remembers PT Cooling's calibration change.
5. The fix lands at integration, the second most expensive point to change anything. This is where delays are introduced.

The issue first lands with the product owners, then pulls in system engineers from every subsystem, then software and finally calibration engineers. Each new person must align with everyone already involved, so the conversations grow much faster than the headcount. Just agreeing on the cause can take weeks, and the fix itself then needs the same people to re-align on a new calibration.

Workflow with Vinci

Requirements are re-checked with every new version, so the problem surfaces the same day.

1. The new version is checked against the signed-off feature requirements. The comfort test now fails, while the product is still in development.
2. The engineer asks "why?" Vinci follows the links between the teams' requirements and points to PT Cooling's calibration change, who made it and when.
3. Vinci lists everything affected in all four teams, and what each owner needs to do.
4. The owners are brought in as reviewers, with a Slack thread that already holds the full analysis.

Outcome

The root cause and the owner of every follow-up were known within minutes of the failing test, and the fix moved from integration into development. The "without Vinci" column describes the typical path for this kind of problem, not a measured baseline.

Appendix for engineers: impact by owner

The chain: PT Cooling lowers its front-end fan map (CAL-PTC-002). The shared fan runs at max(Refrigerant, PT Cooling) request (SW-PTC-006), so it now spins slower whenever PT Cooling was the higher request. Less condenser airflow raises AC discharge pressure. Refrigerant's high-pressure protection (SW-REF-006) freezes, ramps down or stops the compressor, so the evaporator can't reach its target. Cabin can't deliver cold vent air (TSR-CAB-002), and the cabin drifts above setpoint (FSR-001).

Based on the EV Thermal AC/HP requirement set and simulated hot-weather test data.