What is design automation?
The term covers very different things, from a parametric template to a full configurator. A look at the stages, and at the precondition that is almost always underestimated.
Design automation covers the methods by which recurring engineering steps are produced without manual repetition: parametric models, rule sets and configurators. It does not replace engineers, it takes the variants off their desk. The precondition is that the underlying rules and experience are documented and findable. Otherwise you automate assumptions instead of knowledge.
What does design automation actually mean?
Design automation covers every method by which an engineering step is produced without someone repeating it by hand. The term is deliberately broad, and that is exactly what makes conversations about it difficult: two people often mean two very different levels of maturity.
What all forms share is the starting point. There is an approach that repeats, and there are values that change from case to case. The approach gets automated, the values get varied.
Which stages of automation are there?
In practice four stages can be distinguished, each building on the last:
- Parametric models. A geometry is driven by dimensions instead of being redrawn. The simplest and most widespread form.
- Rule-based design. Conditions join the dimensions: a different profile above a certain load, an additional support above a certain length. The approach is now not merely dimensioned but decided.
- Configurators. The rules are made operable from outside engineering, often for sales or customers. A selection produces a valid variant together with its documents.
- Knowledge-based engineering. Beyond the rules, design knowledge, standards and experience from earlier projects feed in. Few reach this stage, and the reason is rarely the software.
Where is the line to AI support?
Automation executes what has been stored. It is deterministic: same inputs, same result. That is its strength, because only then is it verifiable and repeatable.
AI support comes in somewhere else, namely where no rule has been stored. How was a similar assembly designed four years ago? What does the standard say about this test step? Where has this material been used before, and with what outcome?
These are not automation questions but access questions. They do decide, however, whether the automation rests on dependable assumptions in the first place. The AI in engineering design page gives an overview of these use cases.
Why does design automation fail in practice?
Rarely because of the software. Far more often because the rules to be automated are nowhere written down in full.
They exist, but scattered: in design sheets, in past projects, in extracts from standards and above all in people's heads. As long as that knowledge has not been gathered, every automation project begins with a reconstruction. What comes out of it is at best the current consensus of those involved, not the documented state.
The generational change sharpens this. When experienced engineers leave, part of the rule base goes with them before it was ever written down. What that means for onboarding and knowledge retention is covered in the article on knowledge management in engineering design.
What has to be settled before automating?
Three questions, in this order:
Which approach genuinely repeats? Not the one everyone assumes is standard, but the one that was actually used in recent projects. The difference often only shows up when you go and look.
Where are the rules? If the answer is "ask colleague X", that is a finding, not an obstacle. But it belongs at the start of the project, not in the middle of it.
What happens to the special case? Automation covers the standard case. Its usefulness is decided by how cleanly the system recognises the case it cannot cover, and how easily an engineer then takes over.
The unspectacular first step
Before the first rule comes the question of whether the existing knowledge can be found at all. That is not an automation project but a stocktake, and it is considerably less demanding than its reputation suggests.
Anyone who makes designs, test reports and past projects searchable while keeping the source reference for every statement has created the ground on which rules can be formulated in the first place. What AI delivers here today is covered in the article on AI for engineering teams.
FAQ
Does design automation replace engineers?
No. It takes the variants off their desk, not the design decisions. What can be automated is the repetition of an approach that has already been decided. The decision itself, and the deviation from the standard case in particular, remains an engineering task.
From what production volume is it worth it?
Volume is the wrong measure. What matters is how often an approach repeats: how many times is the same engineering step run with different values? Even in one-off machine building there are assemblies that recur in similar form in every project.
How does design automation differ from AI in engineering?
Automation executes stored rules and returns the same result for the same inputs. AI support works where no rule is stored, for instance in finding earlier solutions or opening up documentation. The two complement each other; neither replaces the other.
What is the most common cause of failed projects?
That the rules to be automated are nowhere written down in full. They live in people's heads, in past projects and in design sheets. Anyone who cannot assemble them ends up automating a reconstruction from memory.
Roschiwal + Partner: Making a Large Document Archive Accessible, Drawings Included
Data that has grown over years is not a search problem, it is an access problem. How Roschiwal + Partner put its own archive to use, and why CAD and drawings are the harder part.
A chatbot for technical documentation: what it actually has to do
A chatbot on your own technical documentation sounds straightforward. In practice its usefulness is decided at four points, and generic chatbots fail at all of them.
ChatGPT for internal documents: secure and GDPR-compliant?
Many teams want to point ChatGPT at their own files. What risks this creates, when the use is GDPR-compliant, and how a dedicated solution differs from the public chatbot.
Less searching.
More engineering.
In a 30-minute demo, we show KoAssist working with your own documents and discuss setup, integrations and pricing for your team size.