Automated Transformer Variant Design

Your order book is full of transformers that are 80 percent the same — and every single one is still modeled by hand.

Ask any transformer constructor what fills their week: adapting the tank from the last order, stretching the cooling arrangement, re-deriving the sheet-metal developments, updating a hundred drawings. Each unit is a unicum on paper — winding arrangement, tank dimensions, fittings all follow the customer order — but the engineering behind it is repetitive adaptation of patterns your works has built a thousand times.

The large players industrialised exactly this: modular, rule-driven transformer design is how they turn record demand into shipped units. What mid-sized manufacturers are missing is not the product knowledge — it is the automation layer on top of it.

We build that layer inside your existing Siemens NX and Teamcenter landscape: parametric templates, rule-based model and drawing generation with NXOpen, and — where it genuinely helps — AI that makes the rules easier to build and maintain. Electrical design in, released drawing set out.

// Variant engineering, in numbers

of variant design work is repetitive adaptation of known patterns — not new engineering

0%+

design-time reduction targeted with rule-based construction in Siemens NX

drawings and documents per transformer order — today updated largely by hand

0 h

from order parameters to a generated model and drawing set — the realistic automation target

Every transformer is one of a kind. The engineering shouldn’t be.

Here is the uncomfortable arithmetic of a transformer works today: the market will buy every unit you can build, your constructors are the scarcest resource you have — and a large share of their hours goes into work that follows rules which already exist. They exist in your works standards, in your winding and tank design practice, and in the heads of three senior constructors. They just don’t exist as executable rules.

Copy-paste engineering has a second cost besides time: every copied model carries the assumptions of the order it came from. A stiffener layout that was right for the donor tank, a clearance that no longer matches the new voltage class — these errors surface in the drawing check if you are lucky, and on the shop floor if you are not.

Design automation inverts the workflow. The product family logic is captured once — as parametric templates and rules — and every new order becomes an execution of that logic: parameters in, geometry, sheet-metal developments, drawings and BOM out. Your constructors stop being copy machines and become the authors and reviewers of the system.

IN — PARAMETERS

Electrical design & order data

Ratings, impedances, losses
Winding data from your calc tools
Customer options & accessories
Excel, database or configurator

LOGIC — RULES

Your product family, encoded

Parametric master templates
Design rules & works standards
NX Expressions / NXOpen / PTS
Versioned, documented, yours

GENERATE — 3D

Model built, not copied

Active part & winding envelope
Tank with stiffeners & fittings
Cooling, conservator, cabling space
Clearances checked by rule

OUT — DELIVERABLES

Manufacturing-ready outputs

Drawing set derived & dimensioned
Sheet-metal developments / DXF
BOM to Teamcenter & SAP
Same structure, every order

Three levels of automation — you don’t have to jump to the top

Design automation is not an all-or-nothing decision. The technology is a ladder, and each rung pays for itself. Most transformer works start with one component family — the tank is the classic candidate — prove the time savings, and expand from there. Here is what the rungs look like:

LEVEL 1 — WEEKS

Parametric templates & part families

Single components become configurable: expressions, part families, Product Template Studio. A radiator bank or a cable box that used to be remodeled per order is now driven by a handful of parameters. Fast to build, immediate relief — and the proving ground for your rules.

NX ExpressionsPart FamiliesProduct Template Studio

LEVEL 2 — MONTHS

Rule-based assembly & drawing generation

Whole assemblies — the complete tank, the cooling system — are generated by programmed rules: NXOpen and Knowledge Fusion build geometry, place fittings by works standard, derive the drawing set and push the BOM to Teamcenter. This is where the 50 percent-plus design-time reductions live, and where a Teamcenter product configurator can drive the whole chain from the order.

NXOpenKnowledge FusionDrafting AutomationTC Product Configurator

LEVEL 3 — AI-ASSISTED

AI that builds and maintains the rules with you

The historic blocker of design automation was never the geometry — it was authoring and maintaining the rules. This is where LLMs change the economics: they draft NXOpen code from natural-language rule descriptions, translate senior constructors' knowledge into documented logic, and keep legacy automation alive across NX versions. Where Siemens' generic Design Copilot stops, we build the works-specific layer.

LLM-assisted rule authoringNXOpen code generationLegacy macro modernization

When does variant design automation pay off?

The economics are simple: automation pays where the same family of products is engineered again and again with different parameters. For transformer, switchgear and generator manufacturers that is the core business. You are a candidate if most of these sound familiar:

Your constructors spend 1–2 weeks per order adapting models and drawings that follow known patterns.
The same components — tanks, radiator banks, conservators, cable boxes — are remodeled from copies on every order.
Drawing-set updates and sheet-metal developments consume more hours than the actual design decisions.
Copy-paste errors from donor orders reach the drawing check or the shop floor more often than anyone likes to admit.
The rules behind your designs live in the heads of a few senior constructors — several of them close to retirement.
You run Siemens NX (ideally with Teamcenter) and want automation built on supported extension points, not fragile macros.

The automation toolbox we build with

Supported Siemens extension points and open interfaces — upgrade-safe by design, no hacks that die with the next NX release.

NX Expressions Part Families Product Template Studio Knowledge Fusion NXOpen (C# / C++ / Python) Drafting Automation Sheet Metal / DXF Export Teamcenter Product Configurator BOM to Teamcenter & SAP LLM-assisted Rule Authoring

Before and after: the same customer order, two ways of engineering it

Take a typical distribution transformer order with a non-standard tank height and a customer-specific fitting list. Here is where the constructor hours go on each side of the change:

Before — copy & adapt

Find the "closest" old order to copy from — ½ day
Adapt tank, stiffeners, fittings by hand in NX — 3–5 days
Update the drawing set & sheet-metal developments — 1–2 weeks
Donor-order assumptions slip through into drawings
Every rush order means senior-constructor overtime

After — generate & review

Order parameters enter the configurator — minutes
Model generated by rules, clearances checked — hours
Drawing set + DXF derived automatically — overnight
Errors are fixed once — in the rule, for every future order
Constructors review and engineer the special 20 percent

Why inteliScience

Design automation projects fail for two reasons: they are built by CAD generalists who don’t program, or by programmers who have never sat next to a constructor. We are the third kind — engineers who build NXOpen automation and Teamcenter customization every day, on Siemens’ supported extension points, so your automation survives the next NX upgrade instead of dying with it.

Just as important is who owns the result. The rules we build are documented, versioned and handed over — your constructors learn to read and extend them, with AI assistance making that maintenance radically cheaper than it was even two years ago. The system encodes your works standards; it does not lock you into ours.

And the division of labour stays honest: rules and AI generate the routine 80 percent, your constructors decide the special 20 percent — and review everything that ships. AI takes the routine. Your engineers keep the design.

Fixed price — no day rates, no surprises

Variant Automation Pilot

from €14,500

Rules workshop with your constructors — one product family selected (e.g. the tank)
Working NX automation for that family: model + drawing generation from parameters
Measured time comparison on 3 real past orders — your numbers, not ours
Teamcenter/SAP integration concept for the full rollout
Documented, versioned rules — handed over, with maintenance training

Start the pilot conversation

6–8 weeks · built on your NX installation · the automation stays yours, whatever you decide afterwards.

For comparison

The cost of not automating

~1,500 senior-constructor hours per year spent on copy-paste adaptation
Orders declined or delayed because design capacity is the bottleneck
Family knowledge retires with its owners — unwritten, unautomated

Frequently asked questions

Our transformers are too customer-specific for automation. Does this still apply to us?

Almost certainly — because automation doesn't require identical products, only recurring logic. Rules work on ranges and conditions, not fixed sizes: "stiffener pitch follows tank height per works standard X" covers every variant at once. The honest split is 80/20 — the rules generate the recurring 80 percent, and your constructors spend their time on the genuinely special 20. The pilot's first workshop identifies exactly where that line runs in your product family.

Expressions, Product Template Studio, Knowledge Fusion, NXOpen — which one do we need?

Usually a combination, chosen per component. Expressions and part families for simple parametrics, Product Template Studio for reusable configurable templates, Knowledge Fusion for rule logic inside the model, NXOpen where whole assemblies and drawing sets are generated programmatically. The decision criteria are maintainability and who will own the rules later — not tool fashion. That mapping is part of the pilot.

Who maintains the rules once the project is over?

Your team — that is a design goal, not a promise. Rules are written against supported Siemens extension points, documented, version-controlled and handed over with training. And this is where the AI level genuinely changes things: LLM assistance lets your own constructors read, adapt and extend rule code that would have required a specialist developer a few years ago. We stay available for the hard cases; we don't become a dependency for the easy ones.

Can it start from our electrical design tools and Excel calculations?

Yes. Any structured source works as input: Excel sheets from your winding calculation, databases, in-house tools, or a Teamcenter product configurator if you have one. In practice most pilots start with the Excel that already exists — the configurator can come later, as part of the rollout, once the rules have proven themselves.

We already have old NXOpen macros and journals. Are they wasted?

The opposite — they are proof that automation works in your works, and they encode real rules. Typically they are orphaned: their author left, and they broke on some NX upgrade. We modernize them across API versions (LLM-assisted, which makes this dramatically faster), fold their logic into the documented rule base, and keep everything on supported interfaces so it doesn't orphan again.

Is this the same as Siemens' Design Copilot in NX?

No — and the difference matters. Siemens' copilots are generic assistants: they answer NX questions and help with commands, but they don't know your tank standard, your fitting catalogue or your drawing conventions. Variant automation is deterministic: the same parameters always produce the same, works-standard-compliant result — which is exactly what you want for released manufacturing documents. We use AI where it belongs (authoring and maintaining the rules), not where determinism belongs (generating released geometry).

Your constructors have built this transformer a thousand times. Let the rules build it the thousand-and-first.

Pick the component family that eats the most hours — we'll show you what a generated model and drawing set look like on your own works standards.

Talk to an NX Automation Engineer

Subscribe to our Newsletter

Always here to support you – reach out to us with your questions, and we’ll guide you every step of the way.

Phone: +40 774 463 429
Our Location: Str. Ploiești 9, 400157
Cluj-Napoca, Romania
Email: info@inteliscience.net
LinkedIn: inteliScience on LinkedIn
YouTube: inteliScience on YouTube