Parametrisch modelleren staat in de bouwsector nog in de kinderschoenen. Er is echter steeds meer mogelijk met databasegerelateerd ontwerpen. Door in eigenschappen van prefab-betonelementen te parametriseren, kan een wezenlijke efficiëntieslag worden gerealiseerd.

Het advies- en ingenieursbureau Wagemaker en prefab-betonleverancier Betonson zijn samen een project gestart met als doel een geheel nieuw type betonligger voor viaducten en bruggen te ontwikkelen. Door gebruik te maken van parametrisering van de liggereigenschappen kunnen het ontwerp- en productieproces in een uiterst kort tijdsbestek worden gerealiseerd. De kwaliteit moet echter wel worden gegarandeerd. Uitgangspunt in het project was niet méér te modelleren dan nodig is en de computer vooral het ‘logische werk’ te laten doen. In een startnotitie is duidelijk vastgelegd wat wordt verwacht en hoe dat wordt bereikt.

De OQ-ligger

Het nieuw ontwikkelde liggertype, de zogenoemde OQ-ligger, is efficiënt qua materiaalgebruik, praktisch in vorm en efficiënt in bouwsnelheid (fig. 1). Hij is in een minimaal tijdsbestek gereedgemaakt voor productie. Er is een volledig digitaal parametrisch model gemaakt dat direct kan worden ingezet in het productieproces. Hiermee is er één digitaal script voor alle mogelijke verschijningsvormen die in de toekomst worden vervaardigd (fig. 2).

Het behalen van dit resultaat was enkel mogelijk door intensief samen te werken en door het proces te programmeren in een softwarepakket dat hier, vooral op detailniveau, uitstekende mogelijkheden toe biedt.

Parameters

Het idee achter een volledig parametrisch ontwerp is eigenlijk het digitaliseren van iets dat we al sinds jaar en dag doen. Tekenaars (of constructieprogrammeurs) en constructeurs zijn de menselijke vorm van informatiefilteraars. Zij zijn de specialisten die continu parameters aan het vangen zijn om tot de juiste output te komen. Ze zijn constant bezig met de vraag: ‘Welke informatie ga ik op welke manier overbrengen op de persoon of machine die dit onderdeel moet vervaardigen?’ Hierbij is de vakkennis van die ontwerper cruciaal. Juiste keuzes moeten worden gemaakt en niet altijd om dezelfde eenduidige redenen. Wijzigt er een parameter, dan heeft dat invloed op andere elementen binnen het ontwerp. Het is een complex werk om deze onderlinge relaties te begrijpen en te beheersen.

Met de benodigde kennis van parametriseren is vrijwel elke menselijke beslissing te vertalen in een parameter. Elke parameter is input voor een te programmeren formule. Deze formule kan alle onderlinge relaties tussen objecten vastleggen. Op deze manier kunnen alle objecten en relaties worden geregistreerd. Uiteindelijk ontstaat er een sluitend ontwerp dat alle vormen aan kan nemen die nodig worden geacht.

Voor de OQ-ligger zijn beslismomenten geordend en zijn onderlinge relaties tussen onderdelen vastgelegd. In dit geval zijn dat: de geometrie van de ligger, de wapeningsstaven, voorspanningsstrengen met onthechtingen en in te storten voorzieningen. Dit lijkt zeer uitgebreid, maar toch valt het mee als het vergeleken wordt met een normaal ontwerpproces.

In een regulier ontwerpproces gaat men namelijk bij elk nieuw project minimaal eenmalig nadenken over alle beslispunten die kunnen voorkomen. Sommige beslissingen zijn logisch en altijd hetzelfde. Over andere gaat men in discussie. Hierover worden voorstellen gedaan; er worden elementen en afmetingen gewijzigd en er wordt geoptimaliseerd. Deze nieuwe inzichten worden veelvuldig verwerkt op tekening of in het model, totdat iedereen kan leven met de beslissingen zoals deze zijn verwerkt. Een tijdrovende bezigheid die kan worden voorkomen door eenmalig de speelvrijheid vast te leggen. Deze ontwerpvrijheid is namelijk maar tot een bepaald detailniveau efficiënt.

Het is nu zaak hetzelfde ontwerpproces eenmalig en volledig bij de start van de programmeerwerkzaamheden te doorlopen, maar ook na te denken over welke parameters echt nodig zijn om alle gewenste variaties in liggers te kunnen produceren. Sommige beslissingen kosten meer tijd dan dat ze uiteindelijk aan efficiëntie opleveren. Dit moet men in dit stadium erkennen, want het scheelt wezenlijk in de complexiteit van het uiteindelijke model.

Een simpel voorbeeld: Wat is effectiever, vijf of drie verschillende h.o.h.-maten van een beugelgroep inbouwen? Meer h.o.h.-maten toepassen betekent een mindere hoeveelheid staal. Weegt deze besparing echter op tegen de eenvoud en snelheid van de productie? Dit is niet altijd het geval. Ergens in deze afweging zit een optimum. Het toepassen van meer wapeningsgroepen resulteert in meer onderlinge relaties. Hierdoor worden meer parameters gegenereerd en zijn er dus meer in te voeren vrijheden. Deze afwegingen zijn bepalend voor de hoeveelheid parameters in het uiteindelijke script. Dit heeft weer een directe relatie met de mate van vrijheid in het ontwerp.

Het nagaan van alle mogelijke verschijningsvormen van het onderdeel (zeker bij dit nieuwe liggertype) kost tijd. De lijst met vragen, beslissingen en opmerkingen wordt zeer uitgebreid. Hoe kan in dit gigantische web van onderdelen, onderlinge relaties en definities structuur worden aangebracht? Dat is de kunst van de constructieprogrammeur, die behalve het programmeren van beslissingen ook meningen moet kunnen vertalen naar formules, formules moet kunnen invoeren en een beeld moet kunnen vormen van de uiteindelijke gebruikerstool. Maar bovenal moet hij/zij kennis hebben van de eigenlijke materie.

Totstandkoming van het model

Het parametrisch model, of beter gezegd ‘script’, kan pas worden afgerond door alle acties en beslissingen te valideren in een complete zogenaamde validatielijst. Zwart-wit gezien is het script pas compleet als alle acties zijn verwerkt in het model. Tijdens het ontwikkelproces is een validatielijst bijgehouden, zodat geen acties over het hoofd werden gezien. Het totaaloverzicht kan tijdens het programmeren immers nogal complex worden. Het is zaak dit proces overzichtelijk te houden. Het project is globaal opgedeeld in drie fasen: de voorbereiding, het programmeren en de nazorg. De meest belangrijke aandachtspunten uit deze fasen worden hieronder beschreven.

Voorbereiding

De eerste beslissing is meteen de belangrijkste. Is het beoogde type object op basis van de huidige technologie überhaupt efficiënt te parametriseren? Zorg dat hiervoor een specialist wordt ingeschakeld die kennis heeft van wat er met de huidige software wel en (nog) niet kan. Dit kan een hoop tijd besparen.

Uiteindelijk is alles te parametriseren, alleen moet men realistisch blijven in wat er met de huidige software kan en of de fysieke en financiële inspanning het doel waard zijn. Het liggertype moet bijvoorbeeld enige repetitie ondervinden om de gemaakte ontwikkelkosten terug te verdienen.Voordat begonnen wordt met het technisch overleg moet ervoor worden gezorgd dat bedrijfsinstellingen softwarematig overeenstemming bereiken over de bedrijfsbibliotheek, de coderingen van in te storten voorzieningen, de materiaalgegevens enz. Hierdoor is het model dat op locatie B wordt geprogrammeerd direct toepasbaar op bedrijfslocatie A.

Er is in het geval van de OQ-ligger gekozen voor een parametrisch model dat bestaat uit verschillende componenten (bij relatief eenvoudige liggers kan er ook worden gekozen voor een enkel component). Deze gezamenlijke componenten vormen de complete parametrische ligger waaraan dus niet fysiek wordt gemodelleerd door de gebruiker. De knip die wordt gemaakt tussen de componenten is puur praktisch om de invoer per component overzichtelijk en snel te houden, de foutgevoeligheid te minimaliseren en deelopleveringen te kunnen laten plaatsvinden. Hierbij mag in het beste geval een in te voeren parameter slechts eenmaal worden ingevoerd om redundantie (meervoudig voorkomen van dezelfde informatie) te voorkomen. Goed nadenken over waar de knip wordt gelegd, is dus essentieel. Het is zaak de gevolgen van de knip vooraf in te zien. Als het niet hoeft, moet die knip ook zeker niet worden gelegd.

Wanneer het voorgaande in acht wordt genomen, kan begonnen worden aan de volgende fase, het eigenlijke programmeren.

Programmeren

Een gouden regel is gebleken: ‘Elke op zich staande maat is altijd een losse parameter!’ Als een maat meer malen voorkomt in meer formules, moet deze naar dezelfde parameter verwijzen. Door deze discipline te hanteren, kan men in een later stadium zeer eenvoudig wijzigingen aanbrengen en weet men zeker dat deze wijziging alle relaties tot die gewijzigde maat aanpast. Consistentie in het programmeren loont dus in een later stadium.

Verder moet worden bepaald wat de minimale startinvoer van een ligger wordt. Uiteindelijk zijn alle referentieafstanden hieraan gekoppeld. Door bijvoorbeeld in het betreffende 3D-BIM-model twee punten aan te wijzen als oplegpunt voor de OQ-ligger, kan de geometrie automatisch worden gemodelleerd op basis van de gekozen variabiliteit van de betondoorsnede. Ook eventuele afschuiningen zijn meegeprogrammeerd. Deze parametrische betongeometrie is de basis van alle hierna toe te passen componenten. Overigens, bij correct programmeren volgen de componenten de eventuele toekomstige wijzigingen in de betoncontour.

infrasite_insert_image_7

Door het toepassen van component x worden op basis van alle gemaakte afspraken en beslismomenten elementen in de ligger geplaatst. Dit kunnen sparingen, voorspanningsstrengen, wapeningsstaven, of in te storten voorzieningen zijn. Hierin zijn vrijheden opgenomen in een parametervenster (fig. 3). Door middel van een korte beschrijving van de parameter kan de constructieprogrammeur naar eigen inzicht wijzigingen aanbrengen door met bedrijfsspecifieke parameters te sturen op het ontwerp. Dit is overigens bij elk component op deze wijze opgebouwd. De ‘standaardwaarden’ voor veel parameters hoeven voor de grootste hoeveelheid liggers niet te worden aangepast. Toch is er bij enkele parameters voor gekozen ze in uitzonderlijke gevallen handmatig te kunnen wijzigen. Wijkt men af van de standaardwaarde, die ook staat vermeld bij de variabele parameter, dan moet er logischerwijs een gegronde reden bestaan om dit te doen.

Het toepassen van de overige componenten maakt de ligger verder compleet. Hierbij is het altijd mogelijk de parameters te wijzigen. Het model wordt live aangepast, dus er wordt direct een visuele feedback gegeven op de actie die wordt uitgevoerd. Conflicten worden dan ook direct waargenomen en dit resulteert in faalkostenreductie. Mocht het voorkomen dat de gewenste situatie afwijkt van de standaard mogelijkheden, dan is het altijd mogelijk om het parametrisch component los te laten en zelf alle mogelijke wijzigingen aan te brengen (het slimme component is te ‘exploderen’ zodat de onderlinge relaties verdwijnen).

Het parametrisch component blijft altijd ‘open source’ toegankelijk, dus deze kan in de loop der tijd worden aangepast aan nieuwe inzichten. Dit is natuurlijk ook een te erkennen risico. Het originele script moet consistent worden beheerd, zodat aanpassingen op de juiste wijze kunnen worden geïmplementeerd. Omschrijvingen van parameters en onderlinge relaties moeten eenduidig zijn vastgelegd, zodat verscheidene mensen de wijze van programmeren juist kunnen interpreteren en hierop kunnen inspelen.

Nazorg

Doordat er bij de OQ-ligger meer deelcomponenten zijn toegepast, is het mogelijk om tussentijds deelopleveringen te testen op de werkelijke situatie. Feedback is op deze manier direct terug te koppelen naar het model. Nadat het hele model gereed is, volgt er nog een periode van nazorg. Er wordt nog een aantal malen contact gehouden, zodat het script eventueel kan worden aangepast aan de wensen van de klant, op basis van de ervaringen die tijdens het eerste gebruik zijn opgedaan. Dit zijn tot dusver vooral kleine aanpassingen geweest, die door juist te programmeren snel konden worden aangepast.

Het automatisch genereren van werktekeningen is uiteindelijk beter verlopen dan verwacht. In principe kan hiervoor uiteindelijk dezelfde methode worden gehanteerd als men gewend was. Het belangrijkste is dat de output, het eigenlijke liggermodel, de volledige informatie bevat die nodig is om een werktekening te kunnen genereren. Op deze manier is een parametrisch model ontstaan dat direct bruikbaar is in de productie en waarbij aantoonbaar efficiënter kan worden ontworpen.

Meerwaarde

Naderhand kan worden gesteld dat er een belangrijke kans is gegrepen en dat deze goed is uitgepakt. Een gestructureerde aanpak en goede samenwerking heeft geleid tot onder andere:

• een innovatieve ontwikkeling om trots op te zijn;
• een grotere ontwerpcapaciteit met dezelfde personele bezetting;
• een kortere voorbereidingstijd op de productie;
• een 100% clashvrij ontwerp en een perfecte geometrische afstemming met het totaalontwerp;
• een duidelijke interne en externe communicatie door de directe visuele feedback;
• het inzicht krijgen in de mate van efficiëntie die behaald wordt door bepaalde beslissingen te nemen;
• het eigenlijke doel, een nieuw kwalitatief hoogwaardig product leveren.

De toekomst

Deze ontwikkeling was erg leerzaam. Er zijn veel mogelijkheden voor de toekomst, maar ook de valkuilen moeten worden erkend. Tijdens het project komen situaties voor die te denken geven over de huidige gang van zaken bij ‘ingesleten’ ontwerpprocessen. Zo zal naar verwachting in de toekomst de uitvoerings- en materiaalkennis van de tekenaar/ontwerper belangrijker worden dan het eigenlijke ‘tekenwerk’. Vakkennis op de juiste manier toepassen wordt de essentie van het maken van productietekeningen.

Enkele vragen die we over een aantal jaren waarschijnlijk kunnen beantwoorden en waar we nu slechts over kunnen speculeren:

• In hoeverre wordt de ontwerpvrijheid en toekomstige flexibiliteit beperkt door het gebruik van volledig parametrische

  modellen?

• Kan een constructeur zelf niet aan de parameters draaien (en dus het model creëren) en zo een foutgevoelige informatie-overdracht naar de tekenaar overslaan?
• Vervaagt de traditionele rol constructeur-tekenaar en zo ja, wat worden de nieuwe rollen?
• Zou het niet mogelijk zijn om kwaliteitsborging aan het parametrisch model te koppelen in plaats van aan elke nieuwe tekening die automatisch is gegenereerd?
• Gezien de ontwikkeling van de databasegerichte ontwerpsoftware van de afgelopen jaren kunnen we de komende jaren nog veel ontwikkelingen verwachten. Is het niet aan de markt om de softwareleverancier actief te voeden met informatie en wensen in plaats van een afwachtende houding aan te nemen?
• Zijn er digitale alternatieven om bouwinformatie naar de werkvloer over te brengen? Is een constructietekening binnen enkele jaren verleden tijd? Een simpele gedachtegang: Wat kost meer? Met tien tekenaars modellen vertalen naar tekeningen en de tekeningen naar de productiehal sturen, of twee personen op de werkvloer digitale modellen van de constructeurs laten vertalen naar wat productiemedewerkers werkelijk moeten plaatsen? Stof tot nadenken?

Tot slot

De ontwikkeling in deze materie in de bouwwereld gaat op het moment sneller dan de meesten zich kunnen voorstellen. De informatie uit dit artikel zal snel oud nieuws zijn. Om stappen te kunnen zetten is het echter wel belangrijk de informatie te delen.

De wereld verandert, de bouw ook. Duurzaamheid wordt belangrijker en we moeten zuiniger omgaan met onze grondstoffen. Allemaal redenen om efficiënter om te gaan met onze materialen en productieprocessen. BIM is hierin een belangrijke tool, maar het werken hiermee vereist een immense cultuuromslag die als grote barrière kan worden bestempeld.

Hoeveel werkzaamheden worden er op het moment uitgevoerd omdat het nu eenmaal altijd zo gaat? Dit mag geen belemmering zijn om te veranderen. De efficiencyslag, als in dit artikel besproken, is zo ook een logisch gevolg van de veranderingen die gaande zijn.