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.
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.
Geen opmerkingen:
Een reactie posten