Keeping the reasoning with the geometry: rules, reactions and checks in production automotive CAD

In the world of making cars, there is a quiet crisis that happens long before a vehicle ever reaches a showroom. Engineers spend years designing the curves of a bumper or the placement of a sensor, but the most valuable part of that work—the reasoning behind every single decision—is often the first thing to vanish. When a designer leaves a company, they take with them the "why" behind the "what." The computer files remain, holding the exact shape of the car, but the logic that justified those shapes disappears into thin air. This leaves the next team with a puzzle: they can see the gap between two parts is twelve millimeters, but they have no idea if it should be ten, or if twelve was a compromise made to avoid a collision with a hidden wire. For decades, the industry has tried to solve this by keeping rules in separate documents or spreadsheets, hoping that someone will remember to check them. But documents drift away from the designs they are supposed to govern, and the reasoning is lost again and again.

This paper reports on a different approach, tested in the high-stakes environment of actual car production. Instead of keeping the rules outside the design, the author moved them inside. Imagine a car part that, every time it is opened or changed, automatically checks itself against a set of strict conditions. If a design violates a rule, the model itself flags the error immediately, showing a warning right on the screen where the engineer is working. This is not a passive file waiting to be reviewed; it is an active system that watches, assigns values, and reacts to changes the moment they happen. The study followed four real car programs and a specific sensor network used to help drivers park, as well as a folding armrest built to test the limits of this method. The result was a system that kept the reasoning alive even when people left, but it also revealed a hard truth: a computer model can show you a mistake, but it cannot force a human to fix it.

The core of this work is a method called Knowledge-Activated Design. In traditional engineering, a rule might sit in a manual or a spreadsheet, separate from the 3D model of the car part. An engineer has to remember to look at the manual, find the rule, and then check the model. If they forget, or if the manual is outdated, the design can slip through with a hidden flaw. In this new method, the rule is written directly into the model's code. When the model is rebuilt—perhaps because a designer changed the shape of a bumper—the rule runs automatically. It checks the new shape against the old requirements. If the shape is wrong, the model turns red or displays a warning message instantly. The engineer sees the verdict right there, in front of them, without waiting for a weekly meeting or a separate review process.

The author tested this on a complex network of sensors for parking assistance. These sensors are tricky because they must be placed in a spot that satisfies five different groups: the people who design the car's looks, the engineers who pack the electronics, the team that builds the car, the safety experts, and the schedule managers. A change in the car's exterior skin could ruin the placement of a sensor, requiring a long chain of meetings to fix. By embedding the rules for these sensors directly into the computer model, the system could test every possible position instantly. When a designer proposed a new spot, the model would immediately show if it blocked a sensor's view or if it was too close to a metal part. The model didn't just say "yes" or "no"; it showed the consequences, like a cone of detection hitting the ground or a bracket that wouldn't fit.

This approach changed how teams worked. In one instance, a senior engineer who knew all the details about sensor placement left the company mid-project. In the past, this would have caused weeks of confusion as the team tried to figure out why certain spots were chosen. Instead, the replacement engineer opened the same computer file and found the reasoning built right into the part. The checks, the rules, and the history of decisions were all there, visible and active. The new engineer didn't have to guess or ask around; the model told them what was acceptable and why. This proved that the "why" could be preserved in the design itself, surviving the departure of the people who created it.

However, the study also found a sharp boundary where this method stops working. The author built a second example, a folding armrest, to see how far the rules could travel. In this case, a key measurement was based on a physical test done outside the computer, in a lab. The model could store that number and check against it, but it could not figure out the number itself. Because the rule relied on a value fixed by a physical test, the system could not fully automate the decision. This showed that while the method is powerful, it cannot replace the need for human judgment or external data. The model can enforce a rule, but it cannot create the rule if the answer lies outside its own logic.

Perhaps the most revealing finding came from a situation where the system worked perfectly, but the humans did not. In one car program, three different groups made separate agreements that slowly pushed a critical dimension past its safe limit. The computer model saw this happening. Every time the design was updated, the model flashed a warning, showing that the rule had been broken. It was clear, undeniable, and visible to everyone. Yet, the engineers in charge of releasing the car decided to ignore the warning and approved the design anyway. They had their own reasons, likely related to cost or timing, but the computer did not stop them. The model could show the error, but it could not enforce the decision. This highlighted a crucial limit: the system makes the reasoning visible, but it does not have the authority to stop a project. The power to say "yes" or "no" remains with the people, not the software.

The study concludes that moving rules inside the model is a powerful way to keep engineering knowledge alive. It turns a static drawing into a living document that explains itself. It ensures that when a team changes a shape, they immediately see the impact on safety, packaging, and manufacturing. But it is not a magic solution that fixes everything. It requires discipline to keep the rules updated, and it cannot override the complex negotiations that happen in a real company. The biggest gain is not necessarily speed or money, but clarity. The reasoning behind the geometry stops leaving the building. When a designer opens a file, they are not just looking at a shape; they are looking at the arguments that built it, preserved in a way that no one can accidentally delete.