.webp)
The most convincing case for connected engineering workflows isn't one we can make about ourselves. So we were glad to see Bollinger+Grohmann make it in print, on a project that comes down to one thing: getting from a 3D model all the way to a code check, without the standard being the place the pipeline breaks.
In the May edition of Beton- und Stahlbau (Ernst & Sohn), their team (Lars Ahlfeld, Alexander Hofbeck and Ljuba Tascheva) published Durchgängige digitale Pipelines – vom 3D-Modell zum Normnachweis ("End-to-end digital pipelines: from 3D model to code verification"). It walks through a real design pipeline that carried structural data from the architectural model all the way to the Normnachweis, the code verification, across several firms and several pieces of software. CalcTree did the code checks.
The problem: BIM keeps growing, structural workflows stay separate
The article starts where a lot of structural teams actually are. BIM requirements in public tenders keep expanding, but structural design workflows often stay decoupled from the digital coordination happening around them. Coordination, collaboration and structural analysis run as separate processes, so information gets duplicated and extra model-quality steps get bolted on to keep everything in sync. That is where the time goes.
The authors' position is the interesting part: the components needed for a consistent, cross-software structural workflow already exist. The gap isn't missing technology. It's connecting what's already there.
The pipeline: from architectural model to code check
To prove the point, they built a working pipeline on a real project, and crucially it didn't stop at their own walls. It reached across to the project architects, ASTOC Architects and Planners, who were working in Graphisoft Archicad, alongside Bollinger+Grohmann's own use of Revit, Rhino and RFEM. The goal was to connect each stakeholder's design data rather than re-model it at every handover.
A few pieces did the connecting:
- Speckle was the backbone: the data transport layer between stakeholders, plus versioning and a place to comment.
- RFEM (Dlubal's structural analysis software) doesn't yet ship a Speckle connector, so the Parametric FEM Toolbox by Dr.-Ing. Diego Apellániz served as the interface into RFEM. Bollinger+Grohmann's Alina Schuster also built a proof of concept for a connector.
- Grasshopper orchestrated the whole pipeline.
- CalcTree handled parts of the design code verification, the Normnachweis at the end of the chain.
Where CalcTree fit
CalcTree was the code-verification layer. The pipeline was orchestrated in Grasshopper and the data moved over Speckle; CalcTree is where the design code checks actually happened. Lars Ahlfeld used its Python editor to build the advanced calculations and the output graphics, and that's the part worth dwelling on: the code checks weren't a fixed black box. They were custom logic the engineer wrote and ran against the project's real geometry and loads, inside a Grasshopper-driven workflow.
That's the standards story in miniature. The code verification, the bit that actually applies the standard, lived right where the engineering work was happening, not in a separate document or a separate app. Grasshopper drove the geometry and the orchestration; CalcTree turned the standard's checks into running, transparent calculations on that geometry, with Python doing the heavy lifting where the logic got involved.
(For completeness: in this particular build the team used CalcTree's Python editor rather than its Grasshopper connector. Either path lands in the same place, and they reached for whatever fit the job, which is exactly how real pipelines come together.)
The bigger idea: pipelines engineers can run themselves
The vision behind the article is worth sitting with. Bollinger+Grohmann want engineers to be able to spin up these pipelines without a computational designer sitting in the middle. The domain experts, the people who understand the structure and the code, should be the ones trailblazing the workflow, not waiting on a specialist to wire it together for them.
That's a meaningful shift. It treats connected workflows as something structural engineers own, not something they outsource.
Honest about the gaps
The authors are candid that it wasn't all smooth. Reality never is, as they put it, and they frame the article as a foundation for discussion rather than a finished answer.
There's one gap worth naming, and it sits on our side of the project. CalcTree's templates and its AI already made building and extending the code-verification checks quick. What wasn't there yet was the standard itself, available inside the platform in a ready-to-use form, so the engineer still had to bring the code's requirements in by hand before the checks could run against the model. With that content sitting in CalcTree's knowledge base, reachable by the AI and by reusable template components, the same checks would have been faster to stand up and easier to mould to the pipeline, and the workflow more powerful for it.
That's the gap we're working to close: getting the standards themselves into CalcTree's knowledge base, so the requirements are there to build on rather than re-entered each time. The components for connected workflows already exist, the connective tissue is still maturing, and every real project teaches the next one. As the authors put it, they weren't the first to think about this, and they won't be the last.
Where we see it
For a standards body, this is the part to sit with. Strip the project back and what you're looking at is a standard's code checks running inside an engineer's live, connected workflow, on real project data, at the moment the design is being made. That is what "bringing a standard into the workflow" looks like in practice, rather than on a slide.
It's also the work we're closest to. We've been working with Standards Australia on exactly this question: how to take standards content and turn it into live, verifiable logic that runs where engineers actually work. The Bollinger+Grohmann pipeline is an independent, published example of the same idea on a real project, from 3D model to Normnachweis, with the code checks sitting inside the workflow instead of beside it.
Our thanks to Bollinger+Grohmann for the work and for letting the wider industry learn from it, and to the ecosystem around it: ASTOC, Speckle, and Diego Apellániz's Parametric FEM Toolbox.
You can read Bollinger+Grohmann's full article here. If you own or maintain a standard and want to see what it looks like running inside the workflow, book a call.
