How it works
It is the component that makes remote, enterprise-level automation possible: an ERP system submits a request (an XML file describing one or more elevators), and the server — running LDAWP — generates the 3D model and General Arrangement Drawings (GAD) in the requested output formats (DWG, PDF, 3D DWG, SVG, STEP/SAT, IFC, LDBIM, LD3) without any human opening Liftdesigner interactively.
TIP: LDAWP does not generate drawings itself — it orchestrates and manages the process.
Server architecture
LDAWP is built on an ASP.NET / MVC architecture. It communicates with Liftdesigner through LDOOP (Liftdesigner Out-of-Process), a COM-registered application that runs Liftdesigner instances outside the interactive desktop session.
Server requests are processed in parallel — multiple LDOOP processes run concurrently — which reduces latency per request and makes efficient use of multicore server hardware.
Component | Minimum | Recommended |
Operating system | Windows Server 2022 or newer | Latest updates installed |
CPU | Multicore processor | 1 high-speed physical core per parallel LDOOP process |
Memory (RAM) | 8 GB | 16 GB (up to 8 GB per LDOOP process for CAD workflows) |
Disk space | 1 GB for web services | Additional storage as needed for supplier/project data |
Software | Web Server (IIS), .NET Framework 4.8, Windows Process Activation Service (with ASP & WCF sub-features) | — |
Three distinct user accounts are involved in an LDAWP setup:
An Administrator-type user, needed to install and activate Liftdesigner itself and to install and configure LDAWP.
LDAWPServiceUser, the standard account LDAWP uses to actually generate drawings and other output files (either a full Administrator account or a Non-Interactive group account, depending on the security model chosen).
The built-in NETWORK SERVICE account, to which some files and folders get permissions assigned.
Distinguishing LDAWP from related concepts
LDAWP vs. LDOOP — LDAWP is the web/server plugin that receives and manages requests; LDOOP is the actual Liftdesigner engine process that LDAWP starts and controls to do the modelling and drawing work. A server typically runs several LDOOP instances in parallel, managed by LDAWP.
LDAWP vs. the .NET Reference Model — the Reference Model is custom VB.NET logic that maps ERP/XML data to Liftdesigner parameters; LDAWP is the infrastructure that runs the whole server-side automation environment. Building a Reference Model is a separate, developer-level activity from installing and configuring LDAWP.
LDAWP vs. Product Loading / Dynamic Sheet Templates — these two pillars are about preparing content (the BIM component library and the drawing/sheet templates) so that automation has something correct to generate. LDAWP does not create or edit that content; it only executes generation requests against whatever content has already been loaded.
Remote automation vs. local automation — LDAWP only exists in the remote/server setup. A site running purely local, per-workstation automation has no LDAWP component at all.