The DigiPara Liftdesigner elevator automation process rests on three integrated pillars — Product Loading (PL), Dynamic Sheet Templates (DST), and the .NET Reference Model — that work together within Liftdesigner to turn raw technical data into fully realized 3D models and General Arrangement Drawings (GAD), without a design engineer building the project by hand.
Pillar | Role | Key technical assets |
Product Loading (PL) | The Foundation — defines the physical "DNA" of the elevator. | LDXObjects, parametric rules, CAD 3D models (LOD), component catalogs. |
Dynamic Sheet Templates (DST) | The Output — automates the creation of GADs (General Arrangement Drawings). | PDF/DWG/image files, view frames, Datamanager rules (scale, position). |
.NET Reference Model | The Intelligence — maps XML inputs to Liftdesigner parameters and overrides logic. | VB.NET code, component activation and sheet-template logic. |
How it works
Pillar 1 — Product Loading: creating the BIM library
The foundation of automation is the elevator components BIM library, which must be loaded into Liftdesigner before any automation can occur. This stage can be performed as a professional service, or by an advanced Liftdesigner user on the client side.
Manufacturer data requirements
Liftdesigner uses LDXObjects to generate high-fidelity 3D models. Implementing manufacturer-specific components requires:
Component catalogs & technical drawings — define parametric rules and varied configurations based on variables such as payload or cabin dimensions.
CAD 3D models — required for high-precision rendering and to achieve the desired Level of Detail (LOD).
The main LDXObject categories Liftdesigner needs to generate the elevator 3D model:
Category | Example objects |
|
Car | Car Frames, Guide Shoes, Car Platforms, Safety Gears, Car Operating Panels, Car Balustrades | 
|
Cabin design | Car Design, Car Walls, Mirrors, Handrails, Car Ceilings, Car Floors, Lights | 
|
Entrance, lobby & doors | Car & Landing Doors, Wall Fixings, Jambs and Wall Openings, Sill Supports | 
|
Traction elevator | Counterweight, Counterweight Guard Screen, Traction Machines, Machine Beds, Pulley Beams, Traction Sheaves, Ropes, Traveling Cables | 
|
Hydraulic elevator | Jack and Jack Support, Yoke Guide, Tanks | 
|
Shaft materials | Rail Brackets, Separator Beams, Rope Wall Fixings, Load Hooks, Pitbase Unit, Governors, Tensioning Weights, Buffers, Guide Rails | 
|
Machine room | Switch Gear Cabinet, Controller Boxes, Lighting, Fans, Ventilation Window, Machine Room Door, Power Receiving Box | 
|
Pillar 2 — Dynamic Sheet Templates: automated drafting
Once the BIM components are defined, Liftdesigner can automate technical drawings — complete dynamic drawing generation driven by real-time parameters such as payload, shaft dimensions, elevator groups, and travel height.
GAD specification requirements
Configuring the sheet templates requires client GAD specifications in these formats:
PDF files — representative examples of all sheets contained within the GAD.
DWG files — required for title blocks, border blocks, specific annotations, and technical details.
Raster images (JPEG/BMP) — for corporate logos and graphical content.
Configuration and Datamanager integration
Drawing templates consist of view frames, DWG blocks, and the sheets themselves — configured in Liftdesigner and registered in the database via the Datamanager. Within the Datamanager, parametric rules for the Sheets group control:
Automatic scaling and positioning.
Conditional activation of specific sheets or view frames.
DWG visibility based on configuration.
Pillar 3 — .NET Reference Model: the intelligence layer
The .NET Reference Model is the intelligence layer of the automation. It performs three functions:
Data mapping — converts XML input into a 3D model by mapping client-specific parameters to Liftdesigner parameters.
Model optimization — complements Product Loading by dynamically activating, swapping, or modifying components.
Drawing optimization — using developer-named view frames, sets dimension points, and can programmatically position components or rotate views to match specific configurations.
This stage requires advanced proficiency in VB.NET and the Liftdesigner Core API.
XML file structure
The interface between the ERP system and Liftdesigner uses an XML format with a fixed structure:
<COMMON>— a mandatory, predefined section that should not be modified. Contains the drawing template's primary and secondary language codes, and the model name to be generated.<UNITS>— contains individual<UNIT>information for each elevator in the project.
Sample XML files illustrating different configurations are available (XML_Samples.zip).
API sample project
A sample project illustrating core LDXObject functions is available to download from the Download Portal, for developing and customizing a Reference Model.
Setting it up locally requires Windows 10 or higher, 8 GB+ RAM, and Microsoft Visual Studio 2022 (with DigiPara Liftdesigner installed).
Distinguishing from related concepts
The automation process vs. LDAWP — the three pillars described here are what gets prepared and automated (the component library, the drawing templates, and the parameter-mapping logic). LDAWP is the server-side infrastructure that executes automation requests remotely, at scale. All three pillars apply whether automation runs locally or through LDAWP.
Product Loading vs. Dynamic Sheet Templates vs. the .NET Reference Model — Product Loading defines what the elevator is (its components); Dynamic Sheet Templates define what the output drawings look like; the .NET Reference Model is the custom logic that connects incoming client data to both of the others at generation time. A working automation setup needs all three — none of them alone is sufficient.
Local automation vs. remote automation — this concept page describes the content and logic layers that both automation types share. Which one a specific deployment uses (local, per-workstation automation vs. centralized server automation via LDAWP) is a separate, infrastructure-level decision.