BIM afspraken LOD

BIM afspraken

Level of Development
Form and/or Function

 

Sinds enkele tijd zijn we ons als bureau aan het verdiepen in het maken van principe afspraken voor BIM projecten. Daarvoor gebruiken we het IPC BIM protocol als uitgangspunt. Daarnaast verdiepen we ons in de consequenties van de RGD norm. En dan met name het stuk uit de norm waarin het LOD niveau wordt aangegeven voor de afzonderlijke fases. De RGD verwijst hiermee naar een beperkt en klein stukje uit de Amerikaanse AIA E202-2008 norm. Bij dit onderzoek vallen ons een paar zaken op. En het blijkt ook moeite te kosten om de discussie, zuiver en pragmatisch te houden.

In de eerste plaats het IPC BIM protocol. Dit is een uitstekend handvat en een goede Nederlandse vertaling van wat er wereldwijd al voorhanden is. Het integreert bijvoorbeeld de AIA E202 in de Nederlandse situatie, door onze DNR fasering en onze SFB codering toe te voegen.

 

De RGD doet in zijn RGD-norm een paar bijzondere uitspraken. In de eerste plaats door pas bij de DO fase een LOD te vragen. Vervolgens de uitvoerings- of werktekeningen fase over te slaan en direct door te gaan naar de Revisie stukken. De eis die ze aan de afzonderlijke fases stellen is (geheel tegen de opzet van de oorspronkelijke AIA E202-2008 norm in) ongespecificeerd met betrekking tot afzonderlijke BIM onderdelen. Hele fases schijnen aan de LOD300 te moeten voldoen zonder uit te leggen wat dat betekend. Ook de verantwoordelijkheden voor onderdelen van het BIM model lijken niet aan de orde te komen. Verder  introduceren ze het begrip LOD300+. Wat dat ook mogen inhouden...

 

Wat opvalt aan de AIA E202-2008 is de nadruk op de geometrische  eigenschappen van het model. En daarmee het onderbelichten van de metadata van het model. Toch heb ik het gevoel dat deze Amerikaanse norm is bedoeld, om de eenduidige kwaliteit van het BIM model te kunnen specificeren en kwantificeren. Hoe ze dit willen garanderen door de metadata zo ondergeschikt te maken aan de geometrisch informatie is mij volstrekt onduidelijk. Hopelijk geeft de in ontwikkeling zijnde nieuwe AIA G202-2012 hier meer duidelijkheid.

Wellicht is dit ook de reden waarom veel grote opdrachtgevers (En daar zou de Nederlandse RGD toch ook onder moeten vallen) met eigen aanvullingen komen, om deze lacune op te vullen. Voorbeelden daarvan zijn de VA met een enorme matrix. De United States Army Corps of Engineers (USACE) met een extra Grade bovenop de LOD (lijkt op de LOD300+ van de RGD, maar is echt wat anders). Verder de New York City Department of Design + Construction, die in de bijlage van zijn BIM Guideline per Revit categorie aangeeft welke Parameters bepaald moeten zijn.
De COBie deliverables zijn ook een stevig signaal dat LOD absoluut geen eindstation is.

 

Vooralsnog proberen wij deze inzichten te combineren.

Dit doen we door enerzijds een samenvatting te geven van de gefaseerde LOD ontwikkeling per SFB code. Dit dient als standaard uitgangspunt bij het opstellen van een BIM contract. Anderzijds een uitgebreidere lijst waar per Revit categorie wordt aangegeven wat gespecificeerd moet zijn, om het LOD niveau van die categorie te behalen.

Die laatste lijst is een inhoudelijk document, waar een modelleur ondubbelzinnig mee aan het werk moet kunnen gaan. Dus zonder dat er ‘continu’ gediscussieerd hoeft te worden, over waarom en hoe iets gemodelleerd moet worden.

 

Wat wel afwijkt van andere documenten die ik tot nu toe gezien heb, zijn de volgende punten.

We willen per SFB code een eerste splitsing maken tussen het Model,  de bijbehorende Annotatie en het "losse domme" tekenwerk (om een goede leesbare tekening te kunnen maken).

Vervolgens willen we de Model informatie opsplitsen in Geometrische en Meta data. En daarbij elke vereiste parameter benoemen.

Onderdelen die het resultaat zijn van een ander onderdeel, geven we een visuele onderscheiding. Denk hierbij aan maatvoering dat hangt aan onderdelen in het model. De maatvoering mag niet los zijn en moet ook hangen aan het model. Een ander voorbeeld is een Room Tag die hangt aan een Room. Het is nadrukkelijk niet de bedoeling dat dergelijke tekst los in een tekening staat. Tenslotte een ander voorbeeld. Het is nog niet duidelijk of de opbouw van een gevel, vloer of dak als losse tekst of met Tags c.q. Keynotes dient te worden opgelost. Het gaat ten slotte om een beperkt aantal verduidelijkende opsommingen van teksten en zou dus ook los kunnen.

 

In eerste instantie ligt de focus op het vertalen van de traditionele manier van werken naar een BIM (Revit) manier. Hierbij rekening houdend met de Nederlandse normen en contracten. Daarna gaan we deze basis aanvullen met optionele eisen die te maken hebben met mogelijke analyses die op het model worden uitgevoerd. Denk aan calculaties, PvE vergelijkingen, samenwerken met een Constructeur, Installateur, Aannemer, werken volgens de RGD norm etc.

Deze lange lijsten leveren ook wel interne discussies op. Vooral omdat het onwerkbaar zou zijn en 'niemand het gaat gebruiken'. De bijbehorende wedervraag is: ‘Wat is het alternatief?, of "Hoe weet je anders dat je volgens een bepaalde LOD werkt?’ Neemt niet weg dat we goed gaan nadenken over de verschijningsvorm van deze lijsten. Wellicht kan je in Excel eenvoudige filters maken, om de zin van de onzin te scheiden.

Ook gaan we, nadat deze lijsten klaar zijn, nadenken of er een eenvoudige logica achter de uitgebreide lijsten schuilgaat. Om vervolgens deze logische overwegingen als basis afspraken vast te leggen.

Nog pragmatischer zijn bijvoorbeeld Schedules die gebaseerd zijn op deze afspraken. Zodat je in een oogopslag kan zien of een project volgens de afspraken is getekend en wat er eventueel nog aangevuld zou moeten worden. En in dan ook in interactie met deze Revit Schedules.
 

Op deze manier proberen we een slim en werkbaar model te krijgen, waarbij de inhoudelijke kwaliteit en beheersbaarheid hogere prioriteiten krijgen, dan de geometrische informatie waar de AIA E202-2008 de nadruk op legt. Deze voegt namelijk niet altijd iets wezenlijks toe, maar kan wel ophouden. Ook past het niet zondermeer in de ontwikkelingsfase van een project. Want als de RGD beweerd dat een Definitief Ontwerp model er net zo gedetailleerd uitziet als een Revisie model gaat er toch echt iets fout ben ik bang. En wellicht willen ze ook wel wat metadata hangen aan elke deur van het ministerie van justitie.