From manual modeling to data-driven steel frame design

Overview

Problem

Every project starts in the structural analysis model, and by the time it is solved the profiles, member positions, and connection types are already decided. All of that had to be re-entered into Tekla Structures by hand: 3 to 5 days per frame, plus every connection modeled one by one and every drawing set up from scratch.

Solution

The client moved to central project storage, with a project database behind it and integrations to their ERP and other business systems. We worked on both sides of that link: the database and the REST API that serve the analysis data, and the Tekla Structures plugin that turns the analysis JSON into a physical model: frame generation, automatic connections, and standard assembly drawings.

Result

The handoff between analysis and detailing is no longer manual. The physical Tekla model is generated from the same data the ERP and the rest of the company already work with, so the model matches the analysis by construction, and a design revision means re-running the generator instead of remodeling.

Background

The client designs and fabricates steel frame buildings. Engineering starts in the structural analysis package: the frame is solved there, and the analytical model already carries member profiles, node positions, and the connection type at each node. Detailing then happened in Tekla Structures, where the team had good libraries and experienced modelers – but the model was rebuilt from scratch on every project, and every design revision started that rebuild over again.

Problem

The data already existed – it just wasn't connected

The bottleneck was never modeling speed. It was the gap between the analytical model and the detailing model: validated engineering data was retyped by hand, which is slow, error-prone, and breaks the link back to the analysis the moment anything changes.

  • Profiles and member positions were re-entered manually, node by node.

  • Connections were modeled one at a time, even though the analysis already stated the joint type.

  • Each analysis revision meant redoing the model and the drawings.

  • Nothing tied the detailing model back to the project data the ERP relied on.

Analysis

The client was already consolidating projects into one storage with the ERP and other systems connected to it, so the work split cleanly into two halves: a reliable JSON contract for the analytical model, served by the project database and its REST API, and a Tekla application able to build from it. We defined the payload up front (grid and frame geometry, member profiles and positions, connection type per node, plus the naming and mark conventions production needs), so every project is generated from a single, versioned source of truth.

Solution

We developed a Tekla Structures plugin that consumes the analysis JSON from the client platform and builds the frame end to end. Engineers stay in the analytical model; the physical model becomes a deterministic reflection of it, not a manual interpretation.

1

Read the analytical model

The plugin requests the project JSON from the central storage over its REST API: grid, frame geometry, member profiles and positions, and the connection type at each node.

2

Generate the frame

Columns, rafters, purlins, and bracing are created as physical members with the profiles and positions taken from the analysis, honoring bay spacing, roof slope, and the layout rules of the frame.

3

Apply connections automatically

Each joint type from the analysis is mapped to a Tekla component – base plates, eaves and apex splices, bracing gussets – and applied by rule with the right plates, bolts, and welds.

4

Assign attributes and marks

Names, prefixes, assembly marks, and materials are populated from the source data, so parts leave the model in the form fabrication and the ERP expect.

5

Produce the drawing set

Standard assembly drawings and general arrangement sheets are generated from templates once the model is complete.

Diagram of the workflow, from the structural analysis data and the client project database to the generated Tekla model and drawings

How it works

With the frame modeled and the connections in place, drawing production is the second half of the automation. The plugin issues the set from prepared templates: assembly drawings for the typical assemblies plus general arrangement sheets, with axes, dimensions, and marks already positioned, cutting 1–2 days of drawing work down to seconds.

1

3D overview

General arrangement view of the complete frame, generated from the analysis data.

2

Typical assembly drawings

Column, rafter, and bracing assemblies issued from templates, with plates, bolts, welds, and part marks.

3

Column and beam plans

With grid axes, dimensions, and member marks.

4

Longitudinal and transverse sections

Created automatically with the appropriate annotations.

Result

Engineers no longer rebuild the frame by hand once the analysis is done. They work in the analytical model, and the Tekla plugin turns that data into a detailed model with its connections and a complete drawing set.

  • The frame, its connections, and its drawings are generated from the analysis JSON; a design change is applied by updating the data and re-running the generator.

  • The analytical model is the single source of truth, and the Tekla model matches it by construction, with no manual data transfer in between.

  • Connections are applied by rule instead of being modeled node by node, and attributes and marks come straight from the source data.

  • The detailing model plugs straight into the central storage, so the project database, the ERP, and production all work from the same data.

~90%

Reduction in initial modeling time

~80%

Faster drawing production

0

Discrepancies between analysis and detailing models

Technologies

Tekla Open API

C#

.NET

REST API

PostgreSQL

Find out where you're losing time and money right now

Modern building