Een HSB-dak is geen standaardproduct, maar wel herhaalbaar. Daktypes, gootdetails, sparingen en constructieve oplossingen volgen vaste regels, terwijl de maten per project verschillen. Dat maakt dakengineering een van de meest geschikte processen om te automatiseren, mits de configurator de constructieve logica volgt en niet alleen de vorm.
Waarom dakconstructies zich lenen voor automatisering
Een dakconstructie bestaat uit veel onderdelen die onderling samenhangen: spanten, gordingen, regels, dakbeschot, isolatie, gootdetails en aansluitingen. Een wijziging in de helling raakt al die onderdelen.
Met de hand betekent dat rekenen en opnieuw modelleren. Met een parametrisch model beweegt de constructie mee met de invoer. Dat is precies het type werk waarbij automatisering betrouwbaar kan zijn: veel herhaling, weinig uitzonderingen per regel.
Eis 1: daktypes als vaste basis
Een dakconfigurator moet de daktypes kennen die je daadwerkelijk levert. Niet als losse modellen, maar als varianten binnen één systeem met dezelfde datastructuur.
Zonder die eenduidigheid ontstaat per project een nieuw model, en daarmee vervalt het voordeel. De kracht zit in de herkenning: dit is een variant van ons standaardtype, met deze afwijkingen.
Eis 2: gootdetails en aansluitingen
De goot is in de praktijk een van de meest afstemmingsgevoelige onderdelen. Hoogte, positie, bevestiging en aansluiting op de gevel bepalen of het detail klopt.
Een dakconfigurator moet gootdetails als vast onderdeel van het model behandelen, niet als losse toevoeging achteraf. Hetzelfde geldt voor aansluitingen op de onderliggende constructie en op aangrenzende elementen.
Eis 3: sparingen en doorvoeren
Sparingen zijn de plek waar automatisering zich bewijst of stukloopt. Een sparing beïnvloedt deconstructie, dus de plaats en grootte moeten binnen de regels van het bouwconcept vallen.
Een goede configurator plaatst sparingen consequent en geeft een melding wanneer een sparing buiten de vastgelegde grenzen valt. Zo blijft de uitkomst valideerbaar in plaats van visueel plausibel.
Eis 4: constructieve validatie
Een model dat er goed uitziet, is nog geen veilige constructie. De configurator moet de constructieve uitgangspunten van je bouwconcept toepassen en zichtbaar maken waar een situatie beoordeling vraagt.
De formele goedkeuring blijft bij de bevoegde engineer. Automatisering levert een gevalideerd uitgangspunt, geen vervanging van de constructeur.
Eis 5: een uitwisselprotocol
Wil je dat klanten of architecten brondata aanleveren, dan is een eenduidig uitwisselprotocol nodig. Bijvoorbeeld in JSON- of XML-formaat, met afspraken over velden, eenheden en verplichte gegevens.
Die afstemming vooraf neemt veel ruis weg in projecten. Het alternatief is dat iedere partij zijn eigen aanlevering doet en dat de engineer bij elk project hetzelfde uitzoekwerk verricht. Zonder protocol wordt een digitale stekker nooit meer dan een spreadsheet per project.
Eis 6: output die aansluit op productie
De uitkomst moet bruikbaar zijn in de fabriek: modeldata, tekeningen, stuklijsten en in sommige gevallen bestanden voor machines. Een configurator die alleen een 3D-beeld oplevert, lost de helft van het probleem op.
Leg daarom vooraf vast welke output de productie werkelijk gebruikt, en toets de gegenereerde constructie daarop. Dat is dezelfde logica als bij iedere andere vorm van engineeringautomatisering.
Hoe CADblanche dit heeft ingericht
CADblanche ontwikkelde de RoofDesigner voor HSB-dakconstructies, in een intensieve constructieve samenwerking met De Groot Vroomshoop. Daktypes, gootdetails, sparingen en constructieve oplossingen zijn volledig parametrisch en bewegen mee met de wensen van het project.
De inrichting voor een productiebedrijf vraagt een specifiek ontwikkelingstraject: het standaard bouwconcept wordt gedefinieerd en de RoofDesigner wordt waar nodig aangepast aan de eigen productiemethode. Daarna is de uitkomst eenduidige modeldata die als basis kan dienen voor verdere automatisering van het productieproces.
CADblanche positioneert de tool als dakconstructies genereren binnen enkele seconden, met gevalideerde data als uitgangspunt. De winst zit niet alleen in snelheid, maar vooral in minder afstemming en minder fouten tussen partijen.
Wat je van de architect nodig hebt
Een dakconfigurator kan alleen werken met invoer die eenduidig is. Vraag daarom vooraf om een beperkte set gegevens: dakvorm, hoofdmaten, hellingen, positie van sparingen en de aansluiting op de onderliggende constructie.
Vraag ook om één bron. Wanneer een architect een tekening en een model aanlevert die van elkaar afwijken, moet vooraf duidelijk zijn welke leidend is. Anders begint iedere configuratie met een uitzoekvraag.
Een vaste invoerlijst met verplichte velden werkt beter dan een vrij formaat. Het kost de architect tien minuten extra en bespaart de engineer een middag.
Van configuratie naar productie
De configuratie is het begin, niet het eind. De gegenereerde constructie moet door naar tekeningen, stuklijsten en in sommige gevallen machinebestanden.
Die stap vraagt afstemming met de fabriek: welke gegevens hebben de mensen op de vloer nodig, in welke vorm, en op welk moment? Een model dat alleen op kantoor bruikbaar is, levert geen winst in de hal.
Leg daarom de output eerst vast, en toets die bij de mensen die ermee werken. Vaak blijkt een eenvoudiger uitvoer beter te werken dan een volledig model.
De rol van de constructeur
Bij dakconstructies is de constructieve beoordeling geen formaliteit. Een configurator kan binnen de grenzen van het bouwconcept blijven, maar moet zichtbaar maken waar een situatie buiten die grenzen valt.
Maak die grens expliciet in de tool: een melding, een blokkade of een verplichte controle. Zo blijft de verantwoordelijkheid op de juiste plek en voorkomt de tool dat een afwijking ongemerkt doorstroomt naar productie.
Dat is ook wat een samenwerking zoals die met De Groot Vroomshoop leerzaam maakt: de constructieve kennis zit in het systeem, de beoordeling blijft bij de constructeur.
Wat je zelf eerst vastlegt
Voor je een dakconfigurator overweegt, leg je drie dingen vast:
- Je daktypes: welke varianten lever je structureel, en waarin verschillen ze?
- Je details: welke goot- en aansluitdetails zijn standaard en welke zijn projectgebonden?
- Je grenzen: bij welke sparing, helling of overspanning stopt de standaard en begint beoordeling?
Die drie op papier zijn tegelijk de specificatie van de configurator. Ontbreken ze, dan wordt een traject vooral een discussie over productdefinitie. Wil je die fase goed voorbereiden, lees dan Wanneer is een prefabproduct geschikt voor een configurator?
Veelgestelde vragen
Wat is een dakconfigurator voor HSB-constructies?
Een systeem dat op basis van invoer zoals dakvorm, afmetingen en aansluitingen automatisch een HSB-dakconstructie genereert, inclusief spanten, regels, gootdetails en sparingen, in een vaste datastructuur.
Waarom is HSB-dakengineering geschikt voor automatisering?
Omdat de constructieve opbouw per bouwconcept herhaalbaar is. Daktypes, gootdetails en sparingen volgen vaste regels, ook al verschillen de maten per project.
Welke gegevens heb je nodig om een HSB-dak te configureren?
Minimaal de dakvorm, hoofdmaten, hellingen, aansluitingen op de onderliggende constructie, positie van sparingen en de productieafspraken die bij het bouwconcept horen.
Kan een klant of architect zelf brondata aanleveren?
Dat kan via een uitwisselingsprotocol, bijvoorbeeld in JSON- of XML-formaat. Dat vraagt wel afstemming vooraf, zodat de aangeleverde data eenduidig is.
Blijft handmatige bijsturing mogelijk?
Ja. Een automatisch gegenereerde constructie blijft aanpasbaar. Constructieve beoordeling en vrijgave blijven bij de verantwoordelijke engineer.
RoofDesigner in de praktijk zien?
CADblanche ontwikkelde de RoofDesigner samen met De Groot Vroomshoop. Vraag een demo aan en bekijk wat er met jouw dakconcepten mogelijk is.
Vraag een demo aan