NOBI I BM PROJECT: HET INTECHNO BOUWKUNDIG l\:fodel

NOBI I BM PROJECT: HET INTECHNO BOUWKUNDIG l\:fODEL EINDRAPPORT

Erik P. Deiman, J.C. Hubers, Jos P. van Leeuwen, Geert T.A. Smeltzer, Hannen C.A. Tacke, Bauke de Vries, en Rob H.M. van Zutphen.

BIT Notes 1994 I 5

Building Infm'm~tion 'I'echnology Notes (BIT Notes) This is a series of notes of tht section Bouwinfonnatica of the faculty of Architecture. Building and Planning Eindhoven University of Technology. Since many of these are preliminary versions. or may be published elsewhere. they have a limited distribution only and are not for review. ISSN 1381-3129 editors: ing. Jan Dijkstra ir. Jos P. van Leeuwen prof. dr. Robert M. Oxman prof. ir. Harry Wagter Copies can be ordered from: Secretary of the section Bouwinfonnatica. Eindhoven University of Technology Faculty of Architecture. Bnilding and Planning PosIVak20 P.O. Box 513 5600 MB Eindhoven The Netherlands © 1994 Eindhoven University of Technology. faculty of Architecture. Building and Planning. section Building Infonnation Technologies.

TUE I Building Infonnation Technology

BIT Notes

Other issues in the series of BIT Notes are: 94/1

Future Organisation of the Building Process Information Technology in the Building Industry. Geert T.A. Smeltzer.

94/2

Future Studies in Construction Information Technology in the Building Industry. Geert T.A. Smeltzer, Ian Dijkstra, Rob H.M. van Zutphen.

94/3

The Application of Virtual Reality Systems in Architectural Design Processes. Geert T.A. Smeltzer, Jo M.M. Mantelers, Walther A.H. Roelen.

94/4

NOB! / BBB Project Bouwkosten en bestek Rapport prototype Rob H.M. van Zutphen, A.I. Iessurun, P. de long.

NOBI I BM Project: Het Intechno Bouwkundig Model Eindrappon Erik P. Deiman, J.C. Hubers, Jos P. van Leeuwen, Geen T.A. Smeltzer, Hannen C.A. Tacke. Bauke de Vries. en Rob H.M. van Zutphen. Eindhoven: Technische Universiteit Eindhoven. Faculteit Bouwkunde, sec tie Bouwinformatica. Keywords: Computer aided design; Construction industry; lnfonnation modelling; Product model; Building model; Prototype. © 1994 Technische Universiteit Eindhoven, faculteit Bouwkunde, sectie Bouwinfunnatica. Aile rechten voorbehouden. Niets uit deze uitgave mag woden verveelvoudigd enlof openbaar gemaakt door middel van druk. fotocopie. microfilm, electronische media of op welke andere wijze oole, wnder voorafgaande schrifteJijke toestemrning van de uitgever. All rights preserved. No part of this publication may be reproduced, stored in a retrieval system, transmitted or utilized in any fonn or by any means, electronic, mechanical. photocopying, recording or otherwise, without the prior written permission of the publisher.

2

BIT Notes

TUE I Building Information Technology

Het Intechno Bouwkundig Model

opdracht: SBRen VCA

Datum:

18 april 1994

uitvoering: Technische Universiteit Eindhoven, Instituut Calibre en VCA: ir. Erik P. Deiman ir. J.C. Hubers ir. Jos P. van Leeuwen ir. Geert T.A. Smeltzer ir. Harmen C.A. Tacke ir. Bauke de Vries ir. Rob H.M. van Zutphen

commentaargroep: T. Jongkind, ASC ir. P. van Dam, VABI ir. J. Neuteboom

financiering: SBR, VCA, Instituut Calibre

3


BIT Notes

Voorwoord. Computergebruik bij architektenburo's is zo'n tienjaar geleden bij de Vereniging Computergebruik Architektenburo's gestart met de ontwikkeling van applicaties in de vorm van CAD-bibliotheken, werkmethodieken en tabletmenu's. Deze ontwikkeling ging veelal in samenwerking met de leverancier van het systeem in specifieke CAD-gebruikersgroepen. Elk CAD-systeem heeft zijn eigen mogelijkheden en tekortkoming. Om op korte termijn tot bruikbare resultaten te komen was standaardisatie en coordinatie tussen systemen maar beperkt mogelijk. De gevolgen van deze korte termijn ontwikkelingen worden nu pijnlijk duidelijk: eilandautomatisering, een enorme drempel om tot integrale uitwisseling van gekoppelde gegevens te komen. De collectief onderzoek programmerende instelling in de bouw coOrdineren enkele bouwinformatica-projecten onder leiding van SBR in het Nationaal Onderzoekkader Boud Informatica. Bijdragen op projectniveau komen van onder andere de VCA, de Vereniging Automatisering Bouw en Installatiebedrijven (V ABI) en de vereniging van ingenieursburo's (CIAO). Het is de grote verdienste van de SBR om deze partijen er toe te bewegen hun ontwikkelingen op elkaar af te stemmen. Ook de financiering is mede door de SBR en met subsidie van bet Ministerie van Economische Zaken tot stand gekomen. In plaats van top-down met een masterplan voor de hele bouwvoorbereiding te beginnen, is bottom-up gewerkt aan een meer gestructureerde samenwerking tussen de informatie verwerkende en verstrekkende partners in bet proces. Het Data Uitwisseling Systeem van VABI en het Budget-Begroting-Bestekmodel van VCA hebben belangrijke voorwaardenscheppende impulsen gegeven. CAD-documenten blijken echter maar beperkt bruikbaar voor bestekschrijvers, kostendeskundigen en installatie-adviseurs. SBR besloot daarom tot een aanvullende opdracht voor een Bouwkundig Model, dit maal echter zonder subsidie van Economische Zaken. Door deze beperking in middelen is een Bouwkundig Model ontwikkeld, gericht op het in een model vastleggen van bouwkundige gegevens t.b.v. de andere NOBI-projecten. Gezien de beperkte middelen is er geen ruimte geweest voor uitvoerige consultatie van gebruikers. Het resultaat is een theoretisch model gevoed vanuit de kennis aanwezig bij het Instituut Calibre van de TV Eindhoven. Een van de belangrijkste bevindingen van het NOBI is de cyclische interactie tussen theorie, proces- en gegevensmodellen, software en de integrale bouwpraktijk. Het Bouwkundig Model heeft de cyclus niet in zijn geheel doorlopen - laat staan dat bet model in meerdere cycli is getoetst. Overigens is bet opstellen van een algemeen geaccepteerde theorie en procesmodel voor het bouwkundig ontwerpen een eeuwigdurend proces. Het is een verstandige keuze geweest om in het project te beginnen met een gegevensmodel. Op zijn minst moet echter worden gecontroleerd of dit model de meest gebruikte ontwerp-processen adequaat ondersteunt. Het Bouwkundig Model is nu nog geen model van bouwkundigen. Het beslaat het deel van de gegevens die interessant zijn voor kostendeskundigen en installatie-adviseurs. Gezien de beperkingen is er een goed resultaat behaald. Naast een heldere rapportage ligt er een illustratief prototype, dat in kort bestek laat zien welke functionaliteit van een bouwkundig model verwacht mag worden. Beide resultaten zullen een belangrijke rol speIen in verder onderzoek in de bouwinformatica.

ir. J.C. Hubers algemeen coordinator VCA

4


BIT Notes

Inhoudsopgave: Voorwoord Inhoudsopgave Ljjst van Figuren en Tabellen Deel A:

Opdracht & aanpak.

1

Inleiding ................................................................................................ 8

2

Randvoorwaarden............................................................................... 10 2.1 2.2 2.3

2.4

3

Het ABI. .................................................................................................... 10 Ontwerp NEN 2660................................................................................... 12 ISO Technical report 59 se13 WG2 ......................................................... 14 Het bouwbesluit........................................................................................ 15

Afbakening en aanpak van het onderzoek. ......................................... 18 3.1 3.2

De architect, de kostendeskundige en de installatietechnicus ................... 18 Het ontwerpproces ..................................................................................... 19 3.2.1

3.3

4

De fasering van het ontwerpproces. .. ................................................................. 19

Het Intechno gebouw ................................................................................. 21

Inventarisatie ....................................................................................... 22 4.1

Het NOBIIBBB modeL ............................................................................. 22 4.1.1 4.1.2 4.1.3

4.2

Het V ABIIDUS model. ............................................................................. 27 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.2.6 4.2.7 4.2.8

4.3

Applicaties .......................................................................................................... 28 Definities en uitgangspunten ............................................................................... 28 Technieken en toepassing.................................................................................... 29 STEP en Express binnen VABIlDUS .................................................................. 29 Functionele specificaties van DUS ...................................................................... 29 Het meta datamodel. ............................................................................................ 31 Aspekt-type modellen .......................................................................................... 32 Samenvatting....................................................................................................... 32

Analyse recente gebouw-produktmodellen............................................... 33 4.3.1 4.3.2 4.3.3 4.3.4

4.4

Het NOBIIBBB systeemconcept. ........................................................................ 23 Technieken .......................................................................................................... 25 Uitwisseling, STEP en Express ........................................................................... 26

Het VTT-RATAS model ..................................................................................... 33 Het model van de 'Groupe Structuration de Donnees' (GDS) ............................ 34 Het model 'De Waard' (DWH) ........................................................................... 36 Het CombinelIDM model. ................................................................................... 37

Het synthese-model van Bjork.................................................................. 39 4.4.1 4.4.2 4.4.3 4.4.4 4.4.5 4.4.6

Ruimten............................................................................................................... 39 Ruimtebegrenzingen ............................................................................................ 39 Omsluitende entiteiten ......................................................................................... 41 Gaten, deuren en ramen ....................................................................................... 42 Geometrie ............................................................................................................ 43 Integratie - het synthese model volgens Bjork - (SMB) ...................................... 43

5


Deel B: 5

Het NOB! Bouwkundig Model.

Uitgangspunten ................................................................................... 45 5.1

Interpretatie van te gebruiken data-modellen ............................................ 45 5.1.1 5.1.2 5.1.3

5.2

6

Deel C:

Een procesmodel van het ontwerpproces................................................. 47

Typering van het NOBIIBM ...................................................................... 50 Abstractie mechanismen.......................................................................... 50 Decompositie van een gebouw .................................................................. 51 Specialisatie van een bouwdeel. ............................................................... 53 Decompositie van bouwdelen ................................................................... 53 Eigenschappen: gewenste en gerea1iseerde waarde ................................... 53 Aansluitingen ............................................................................................ 54

Het prototype.

Uitgangspunten voor het ontwikkelde prototype............................... 55 7.1 7.2 7.3 7.4 7.5 7.6

8

Het NOBIIBBB model..................................•..................................................... 45 Het VABIIDUS model. ....................................................................................... 46 Het synthesemodel zoaIs opgesteld door Bjork.................................................. .47

Het NOB! Bouwkundig Model. .......................................................... 50 6.1 6.2 6.3 6.4 6.5 6.6 6.7

7

BIT Notes

Demonstratie en doelgroep ....................................................................... 55 Subview van de architect ........................................................................... 55 Informatie-behoefte ................................................................................... 55 Intechno gebouw ....................................................................................... 56 Platform en software................................................................................. 56 Onderdelen van het NOBIIBM in de demonstratie................................... 56

Het prototype ....................................................................................... 58 8.1 8.2 8.3 8.4

Werkwijze van modelleren ........................................................................ 58 Data-management. ..................................................................................... 59 Opbouw van de interface ........................................................................... 59 Werken met het prototype......................................................................... 60 8.4.1 8.4.2 8.4.3 8.4.4 8.4.5

Instellen van de bouwdeel-classificatie............................................................... 60 Modelleren van bouwdelen ................................................................................. 61 ImpIiciet modelleren van ruimtebegrenzingen.. ................................................... 64 Opvragen en wijzigen van gegevens van ruimtenen bouwdelen ........................ 64 Exporteren naar VCAlDUS ................................................................................ 66

9

Toetsing ............................................................................................... 67

10

Conclusies & aanbevelingen............................................................... 69

Gebruikte literatuur....................................................................................... 70 Bijlagen: A B C

Het NOBI Bouwkundig Model versie 1.0................................................. 73 Definities van begrippen........................................................................... 74 (Meta)modellen van mogelijke oplossingen voor weergave van 'gewenste' c.q. 'gerealiseerde' waarde...................................................... 77

6

TUE 1 Building Infonnation Technology

BIT Notes

Lijst van Figuren en Tabellen Tabel1 Figuur 3.3 Figuur 4.1 Figuur 4.3.1 Figuur 4.3.2 Figuur 4.3.3 Figuur 4.3.4 Figuur 4.4.2 Figuur 4.4.3 Figuur 4.4.5 Figuur 4.4.4 Figuur 4.4.6 Figuur 5.l.2 Figuur 5.1.3 Figuur 5.2 Figuur 6.1 Figuur 8.1 Figuur 8.2 Figuur 8.3 Figuur 8.4 Figuur 8.5 Figuur 8.6 Figuur 8.7 Figuur 8.8 Figuur 8.9 Figuur 9.1 Bijlage A Figgur C.l Figuur C.2 Figuur C.3

Planning ............................................................................................................................ 18 Het Intechnokantoor .......................................................................................................... 21 NOBIIBBB infonnatiediagram ......................................................................................... 24 Het VTT RATAS model ................................................................................................... 34 Het GSD model ................................................................................................................. 35 Het DWH model ............................................................................................................... 36 Het IDM model ................................................................................................................. 38 Abstracte hierarchie voor 'ruimte begrenzingen' .............................................................. .40 Abstracte hierarchie voor 'omsluitende structuren' ........................................................... .41 Basisprincipe vOor het koppelen van geometrische infonnatie aan een entiteit.. ............. .42 Schema voor 'openingen' en hun relaties met andere entiteiten ........................................ .43 Het synthese model volgens Bjork (SMB model) ............................................................ .44 Intepretatie van het V ABIIDUS bouwfysisch model ....................................................... .46 Interpretatie van het 5MB model ...................................................................................... 46 Toetsingsmodel ................................................................................................................. 48 NOBIIBM infonnatiediagram - Architektenview van het Intechnokantoor - Versie 1.0 ................................................... 52 Prototype NOBIIBM: AutoCAD pulldown-menu's .......................................................... 60 Prototype NOBIIBM: Settings .......................................................................................... 60 Prototype NOBIIBM: Selectie van bouwdelen ................................................................. 61 Prototype NOBIIBM: Bouwdeel specificatie en selectie van sub-bouwdelen .................. 62 Prototype NOBIIBM: Bouwdeel prestaties ....................................................................... 63 Prototype NOBIIBM: Bouwdeel bibliotheek .................................................................... 64 Prototype NOBIIBM: Ruimte infonnatie .......................................................................... 65 Prototype NOBIIBM: Bouwdeel infonnatie ..................................................................... 65 Prototype NOBIIBM: Export naar VCAlDUS .................................................................. 66 Een bouwlaag van het Intechnokantoor ............................................................................ 67 NOBIIBM informatiediagram - Architektenview van het Intechnokantoor - Versie l.0 ................................................... 73 V ABIIDUS functionele en technische specificaties .......................................................... 77 NOBIIBBB attributen ....................................................................................................... 77 NOBIIBM attributen metamodel: gewenste en gerealiseerde waarde ............................... 77

7

TUE I Building lnfonnation Technology

Deel A: 1

BIT Notes

Opdracht & aanpak.

Inleiding.

Er is een duidelijke tendens waar te nemen binnen het huidige bouwproces, namelijk de groeiende behoefte aan betere en snellere bouwtechnische informatievoorzieningen, gezien in de brede context van de bouwnijverheid. Enerzijds is deze groei een rechtstreeks gevolg van het aanbod van steeds krachtigere computersystemen en technische infrastructuren waarmee technologisch gezien steeds meer mogelijk wordt. In managementtermen spreekt men van een 'technology-push'. Anderzijds noodzaakt de toenemende complexiteit en kwaIiteitseisen ten aanzien van het bouwproces tot de inzet van een nieuw innovatief instrumentarium. Vindt dit plaats op basis van een goed beleid, dan is er sprake van een 'management-pull'. Dankzij de technology-push is met de intrede van de computer weliswaar de traditionele tekening vervangen door de CAD-tekening en is het CADsysteem een niet meer weg te denken instrument in de dagelijkse bouwpraktijk. Het gevolg is echter. dat de automatisering in de bouwpraktijk zich kenmerkt door een wildgroei van allerlei systemen, die nauweIijks op elkaar zijn afte stemmen. De term 'eiland-automatisering' komt in dit verband dan ook om de hoek kijken. Er is geen afstemming van programmatuur en gemeenschappelijke projectgegevens. Iedere participant in het bouwproces heeft zijn eigen toepassingen geautomatiseerd en eigen gegevensbestanden opgebouwd. De integratie van deze bouwkundige informatiesystemen is in zo'n omgeving slechts gedeeIteIijk mogeIijk. Een optimale inzet van informatietechnologie kan aIleen worden bereikt als de werkwijze en de achterliggende visie ten aanzien van het informatiebeleid herzien wordt in het Iicht van de nieuwe (on)mogeIijkheden. Een veel gehoorde kreet is immers: "automatiseren is veranderen". De integreerbaarheid van verschillende applicaties hangt nauw samen met de communicatie tussen de verschillende participanten in het bouwproces. De architect en de kostendeskundige, of de architect en de installateur verstaan elkaars vakjargon voldoende om met elkaar te kunnen communiceren. De praktijk leert ons echter anders. Communicatie geschiedt nog steeds via tekeningen of in een enkel geval via een ingewikkelde en (vaak) onbetrouwbare koppeling tussen twee verschillende applicaties. Willen we een integra tie tussen verschillende applicatieprogramma's tot stand brengen dan is dat aileen mogelijk als informatie betreffende het ontwerp volledig en ondubbelzinnig wordt vastgelegd, zodat deze door derden (lees: participanten in het bouwproces of applicatie-programmatuur) eenduidig kan worden geYnterpreteerd. V oor het opzetten van een goede basis moeten we afstappen van het idee dat een tekening, als informatiedrager, alle noodzakelijke informatie bevat. Informatie zal op basis van een ander concept gemodelleerd en uitgewisseld moeten worden. Hierbij moet gedacht worden in de richting van een gemeenschappelijk gedefinieerde gegevensmodellen. Iedere branche binnen het bouwproces zou deze gegevensmodellen moeten kunnen gebruiken om de daar voor hem relevante informatie uit te kunnen pullen, of in weg te schrijven. Dergelijk gegevensmodellen beschrijven produkten van een bouwwerk en worden ook weI produktmodellen genoemd. Een of meerdere produktrnodelen zullen de functie van de bouwtekening als informatiedrager gaan vervangen. Is het produkt een gebouw. dan spreken we van een gebouwmodel. Deze benaderingswijze opent de mogelijkheden om diverse gegevensbestanden optimaal aan elkaar te koppelen. De informatie die in een produktrnodel wordt opgeslagen behelst aIle projectgebonden gegevens die vanaf de voorbereidingsfase tot en met de sloop van het produkt een rol spelen. Een produktrnodel kan aldus gezien worden als een informatiemodel van een bepaald produkt.

Opdracht. NatuurIijk is er op dit gebied reeds veel gebeurd. In het NOB! worden modeUen en prototypes van computerprogramma's ontwikkeld voor de uitwisseling van gegevens over gebouwen tussen verschillende disciplines. Het V ABIIDUS project richt zich hierbij met name op de installatietechnische aspecten en het NOBIIBBB project richt zich met name op kostentechnische aspecten. Wat echter nog ontbreekt is het model van een bouwkundig on twerp waarin de basis wordt gelegd van de informatie en waarin na verwerking door de disciplines de wijzigingen en toevoegingen kunnen worden verwerkt. Voor het demonstreren van de NOBIprojecten blijkt dit model onontbeerlijk, omdat anders niet duidelijk is over welk gebouw het gaat en waar VABIIDUS en NOBIIBBB de inputgegevens vandaan halen. Er zal dus een 'bouwkundig model' ontwikkeld moeten worden. Dit model zal de naam NOBI Bouwkundig Model, oftewel NOBIIBM krijgen. In het NOBI-BBB onderzoek is een reeds ontworpen en gerealiseerd kantoorgebouw als voorbeeld aangewezen, teneinde hieraan de te ontwikkelen methoden en technieken van kostenraming te kunnen toetsen. Het betreft het gebouw voor Intechno B.V. te VeenendaaI. Oit kantoorgebouw is ontworpen door het bureau

8

TOO I Building Infonnation Technology

BlTNotes

voor architectuur en ruimtelijke vormgeving Van der Hoef & Bronsvoort B.V .. Het gebouw is volledig uitgewerkt in bestek-, werken detailtekeningen. alsmede in de vorm van een bestek gebaseerd op de STABUmethodiek. Het NOBI-Bouwkundig model zal zich, gezien de krappe planning en beperkte financiele middelen. beperken tot het ontwikkelen van een model van een kantoorgebouw in relatie tot de modellen zoals die zijn opgesteld in het kader van het NOBUBBB- en het VABIIDUS-onderzoek. Het kantoorgebouw waarvoor het bouwkundig model zal worden ontwikkeld zal het 'Intechno gebouw' zijn, zoals dat is gebruikt in het NOBUBBBonderzoek. Evenals in laatstgenoemd onderzoek zal het model zich beperken tot de situatie zoals die is vastgelegd in het definitief ontwerp van dit kantoorgebouw (DO-fase). Een en ander leidt tot de volgende probleem- en doelstelling. Probleemstelling:

Hoe ziet in aansluiting op afspraken in het NOBI een bouwkundig model van het Intechno gebouw eruit, waarbij gegevensvraag van de installatietechnicus (VABIIDUS) en de kostendeskundige (NOBUBBB) en aanbod van de architect bij elkaar komen, en hoe kan daar in de praktijk mee worden omgegaan.

Doelstelling:

Het project moet opleveren: Het produkttypemodel 'Intechno Bouwkundig Model' beschreven in NIAM en EXPRESS. Daarnaast zal in aanvulling op de VCAlDUSmodule zoals die in het kader van het NOBUBBB-project wordt ontwikkeld. een prototype computerprogramma worden ontwikkeld. De functionaliteit van het te ontwikkelen prototype zal beperkt blijven tot demonstraties van uitwisseling van de belangrijkste gegevens van het Intechno kantoor tussen een CAD-systeem, het NOBUBBB-prototype en de VABIIDUS applicaties.

Doelgroepen:

I. Informatici Het resultaat van het onderzoek is bruikbaar voor (NOBI)onderzoekers op het terrein van de bouwinformatica en voor ontwikkelaars van bouwinformatiesystemen en applicaties. Zij kunnen de resultaten gebruiken voor implementatie, opname in eigen ontwikkelingen en aansluiting aan hun eigen modellen. 2. Bouwkundigen Het resultaat zal gebruikt worden om het nut en de toepassing van produktmodellen bij het bouwkundig ontwerpen duidelijk te maken aan de verschillende betrokken disciplines. Het zal in deze zin gebruikt kunnen worden voor het veranderen van de houding tegenover deze materie. Deze kennisoverdracht zal in het NOBI worden verzorgd.

Begrenzingen:

De voornaamste begrenzingen in dit onderzoek komen voort uit de beperkte financiele rniddelen en de krappe planning en zijn: - Het model is ontwikkeld worden voor een kantoorgebouw in relatie tot de modellen die in het NOBI/ABI-project worden ontwikkeld. - De inventarisatie van de gegevensvraag is beperkt tot die van het prototype van het NOBUBBB-project en de VABI-applicaties voor warmteverliesberekening en kanalendistributie. - Bij de inventarisaties en bouw van het prototype is uitgegaan van een veel gebruikt CAD-systeem - De functionaliteit van het te ontwikkelen prototype. als aanvulling op het prototype van VCAlDUS. is beperkt tot demonstraties van uitwisseling van de belangrijkste gegevens van het Intechnokantoor tussen CAD-systeem, het NOBUBBB-prototype en de VABI-applicaties - Er is niet gestreefd naar een objectgeorienteerde aanpak, wat het gedrag van objecten zou impliceren. Eerder is er sprake van een componentgerichte aanpak De prototyping is van het type "explorative incremental development".

9

ruE I Building Infonnation Technology

2

BlTNotes

Randvoorwaarden.

Bij de ontwikkeling van discipline overbruggende produktmodelJen, zoals in dit onderzoek, is het noodzakelijk kennis te nemen van en indien mogeJijk aansluiting zoeken bij relevante ontwikkelingen. Wij doelen daarbij met name op ontwikkelingen op het gebied van afsprakenstelsels, normen en regelgevingen. Immers, om goed te kunnen communiceren moeten goede afspraken gemaakt worden over de structuur van gegevensopslag en de betekenis van de opgeslagen gegevens. Zonder deze afspraken kunnen gegevens niet eenduidig worden vastgelegd, en is geen eenduidige communicatie tussen verschillende bouwpartners mogelijk. Zowel in nationaal als in internationaal verband wordt er over deze problematiek nagedacht. Oit heeft geleid tot een aantaI publicaties, waaronder een ontwerp NEN-norm. Oaamaast is er het een en ander veranderd in de regelgeving. Oit heeft geleid tot de invoering van het zogenaamde bouwbesluit. Ten behoeve van dit onderzoek zijn de volgende publicaties bestudeerd:

* *

*

*

ABI (versie 0.2 - 1992) Ontwerp NEN 2660 ISO technical report 59 SC13 WG2 Het bouwbesluit

Achtereenvolgens wordt elk van deze documenten in de volgende paragrafen nader toegelicht.

2.1

Het ABI.

Het Afsprakenstelsel Bouwinformatica (ABI) sluit aan bij. en geeft invulling aan het Nationaal Onderzoekskader Bouwinformatica (NOBI). Het NOBI is opgesteld door de programma advies commissie 'Bouwinformatica', die op haar beurt is ingesteld door de programma coordinatie raad van CROW, CUR, ISSO enSBR. Centrale doelstelling van het project 'Afsprakenstelsel Bouwinformatica (ABI)' is het bundelen, coordineren en rich ten van Bouwinformatica-ontwikkelingen in Nederland door het aanbieden van een referentie-architectuur bouwinformatica. Oit afsprakenstelsel bevat richtlijnen ter ondersteuning van de praktijkprojecten van NOBI bij het ontwikkelen van ge'integreerde programmatuur. Het richt zich op de methoden met bijbehorende technieken en de modellen die zijn ontstaan in het veld van PDI-Bouw en die daar mogen rekenen op een grote acceptatie. Het afsprakenstelsel heeft tot op heden een voorlopig karakter. Het is nog niet voldoende uitgewerkt en uitgekristalliseerd. Het afsprakenstelsel zal in de loop van het NOBI worden bijgesteld en uitgebouwd tot dat er een volwaardig produkt ontstaat. Oe voorlopige versie biedt echter voldoende houvast om in de uitgangspunten mee te nemen. 8DM. Het ontwerpen van een informatiesysteem moet op een beheersbare wijze plaatsvinden. In het ABI wordt hiervoor als systeemontwikkelingsmethode SDM (System Development Methodology) gekozen. Binnen 80M wordt het systeemontwikkelingsproces opgesplitst in de volgende fasen: fase 1 fase 2 fase 3 fase4 fase5 fase 6

definitiestudie basisontwerp detailontwerp realisatie invoering gebruik en beheer

Het function eel en het technisch ontwerp zijn hier opgenomen in fasen 2 en 3. SOM geeft niet aan hoe en met welke technieken en hulpmiddelen men de benodigde activiteiten in de verschillende fasen verricht. Oit komt dus nader aan de orde in het ABI.

10


BIT Notes

Voor wat betreft fase 1: de definitiestudie wordt opgemerkt dat er in principe vier mogelijkbeden ter beschikking staan om informatie te verzamelen. Deze vier mogelijkhedeo zijn achtereenvolgens: • • • •

het putten uit eigen ervaring literatuuronderzoek interviews met deskundigen protocol-analyse

Hierbij wordt opgemerkt dat voor de NOBI praktijkprojecten een mix van de eerste drie methoden het meest geschikt wordt bevonden. In fase 2 staat het functionee1 ontwerp centraal. Het is in deze fase dat wordt vastgelegd wat er gerealiseerd moet worden zonder dat direct wordt ingegaan op hoe en waarmee eeo en ander tot stand komt. Het functioneel ontwerp levert delen van de informatiestructuur aan en geeft de specificaties voor het ontwerp van de systeemen technische structuur. Ais uitgangspunt fungeert de systeemdefinitie. In een functie analyse wordt vastgelegd welke functies (wat) er vervuld mooten worden, en welke informatiestromeo er tussen de verschillende (deel)processen van het systeem plaatsvinden. Hierbij wordt ook de informatieuitwisseling met de omgeving vastgelegd. Bij het gebruik van SOM moeten we echter in het kader van dit onderzoek een aantal kanttekeningen maken. Oe keuze van een goede faseringsmethode, zoals SOM, als hulpmiddel voor de bewaking en sturing van zoweI voortgang als kwaliteit is onontbeerlijk. Het gebruik van SOM in onderzoeksprojekten zoals het NOBIIBM project kent echter ook nadeIige aspecten. Een nadee! van deze werkwijz.e is, dat het veelal dogmatisch hanteren van de faseringsmethode kan leiden tot starheid in het ontwildcelingsproces en overaccentuering van relatief minder belangrijke aspecten. Ook vergt het strikt uitvoeren van de methode relatief veel tijd en zijn terugkoppelingen om eerder genomen beslissingen of onnauwkeurigheden te corrigeren niet of nauwelijks mogelijk. Oaarom is voor de ontwikkeling van het BM-prototype binnen de globale fasering volgens SOM gekozen voor een iteratieve, meer pragmatische benadering, beter bekend als prototyping of incrementele ontwikkeling. En omdat het prototype wordt gebruikt als uitgangspunt voor verdere ontwikkelingen is er sprake van een zogenaamde 'evolutionaire incrementele ontwikkeling'. Hoewel deze methodiek niet in het ABI wordt vermeld. is het met name in situaties met een sterk onderzoekskarakter een zeer geschikte werkwijze. Ook is prototyping geschikt in omgevingen waar capaciteit en/of tijd voor een gedegen analyse sIechts beperkt aanwezig zijn. Ooor middel van prototyping kan de altijd aanwezige communicatiekloof tussen ontwikkelaars en gebruikers sneller en veelal ook doelmatiger worden overbrugt. Andere voordelen zijn de grotere betrokkenheid van gebruikers en opdrachtgevers met het ontwikkelingsproces, de mogelijkbeid voor training en voorlichting, bet inschatten van het effect op de organisatie (werkwijze en werklast). Omdat prototyping lastiger te beheren en te sturen is, is er door de projectgroop een balans tussen beide method en gevonden, tussen de fasering en verplichte activiteiten van SOM en het flexibele maar las tiger te beheersen prototyping. Eigenlijk zou binnen hel ABI onderscheid moeten worden gemaakt tussen de ontwikkeling in een praktijksituatie en in een onderzoeksomgeving. Bij elke omgeving hoort. zoals uit bovenstaande duidelijk blijkt, een specifieke benadering en besturing.

IDEFO-methodiek. Bij de proces-analyse ligt de nadruk op het specificeren van de processen, die het systeem dienen te vervullen met de daarvoor benodigde activiteiten. Het doel is om de processtructuur. de relaties tussen functies, activiteiten en informatiestromen inzichtelijk te maken. Overdracht van informatie via een schema is over het algemeen efficient. In het ABI wordt gekozen voor het maken van schema's met behulp van de IDEFO· methode. Er is bewust voor deze methodiek gekozen, o.a. vanwege de ervaringen met deze methode in de bouwwereld. Oaarnaast speelde de internationale toepassing van de IDEFO-methodiek in ISO·STEP verband hierbij ook een rol. NIAM. Uit de functie-analyse voIgen de gegevensstromen tussen deelprocessen en is vast te leggen, welke gegevens opgenomen worden in het informatiesysteem. Oe gegevens (of attributeD) worden bij de informatie-analyse gegroepeerd naar gegevensgroepen (objecttypen). Het doel is, om de infrastructuur inzichtelijk te maken. En ook hier geldt dat een plaatje veelal een lekst kan ondersteunen als het gam om een duidelijk begrip van de

11


BIT Notes

materie. Dankzij deze grafische mogelijkbeden, gekoppeld aan de syntax waarmee de semantiek van de gegevens kan worden vastgelegd is NIAM als methode goed bruikbaar tijdens de systeemanalyse. Voor de informatie-analyse wordt in het ABI gekozen voor NIAM. NIAM staat hierbij voor Nijssens Informatie Analyse Methode. In deze methode woreJt veel aandacht geschonken aan de relaties tussen objecttypen, waardoor de betekenis van de gegevens op een meer formele manier zijn vast te leggen. De methode heeft internationaal een breed draagvlak (ISO-STEP en Combine), en daarnaast biedt het de mogelijkheid om de koppeling naar een database en Express te automatiseren.

Express. De objecttypen en de in de objecttypen voorkomende attributen dienen eenduidig gespecificeerd te zijn na beeindiging van de informatie-analyse. De specificatie kan voor een deel gebeuren door middel van de grafische informatie-modellen. Dat is cchter onvoldoende. Door middel van teksten moeten grafische specificaties worden aangevuld. We kwmen bierbij denken aan de specificatie van de eenheden van de attributen, het dome in en aan voorwaanleD.ln het ABI wordt voor het maken van deze specificatie gekozen voor de in ISO-STEP verband ontwikkdde data-definitietaal Express. De beschrijving van gegevensmodellen in Express, en in de grafische variant Express-G, bieden de mogelijkheid om de informatiemodellen gedetailleerd uit te werken. Hoewel zowel NIAM als Express-G Us grafische modelleertechniek kunnen worden aangemerkt, hebben beiden specifieke kenmerken, waardoor zij ieder hun sterke en zwakke kanten vertonen. Dit leidt ertoe dat de technieken meestal in combinatie worden toegepast.

2.2

Ontwerp NEN 2660.

Het ontwerp NEN 2660 opgesteld door bet NNI, getiteld: 'Informatiesysteem voor de bouw; termen, definities en algemene regels' bevat een samenvatting van de opvattingen over de ordening van informatie in de bouw. De voorgestelde ordening moel resulten:n in een informatiesysteem waarin gegevens worden beheerd op een zodanige wijze dat die gegevens correct, actueel en onderling consistent zijn. Ben en ander is een uitwerking van het werkdocument 'Ordeningsprincipes voor een informatiesysteem voor de bouw', van de normcommissie 352 25 'CIassificatie in de bouw'. Het werkdocument is opgesteld onder auspicien van de SBR in het kader van de samenwerking tussen deze stichting en de normcommissie. In het ontwerp normblad zijn de voor een informatiesysteem relevante termen, definities en begripsbepalingen opgenomen. Waarna vervolgens regels worden gegeven voor een op te stellen informatiesysteem voor de bouw. De belangrijkste begrippen zoals voorgesteld in bet ontwerp normblad worden hieronder kort toegelicht.

Objecttypen & attributen. Informatie staat niet op zichzelf, maar is gebonden aan een onderwerp van beschouwing. Het beschouwde onderwerp wordt aangeduid met de term 'entiteit'. Informatie met betrekking tot een entiteit wordt vastgelegd in de vorm van een 'gegevensverzameling'. De gegevens die bij een entiteit horen worden de 'attributen' van die entiteit genoemd. Tezamen bevatten de:ze attributen de vastgelegde informatie over de entiteit. Het normblad maakt een onderscheid tussen objectentiteiten en procesentiteiten. Hierbij is een objectentiteit een entiteit die bestaat in werkelijkheid of in gedachte vorm, waarin gegevens worden ondergebracht met betrekking tot functionaliteit, prestaties en hoedanigheid van het betreffende object. Attributen van objectentiteiten kunnen onder andere betrekking hebben op de functionaliteit van het object, de prestaties die het object vanuit verschitlende gezichtspunten gezien kan leveren, of zij kunnen de hoedanigheid van het object beschrijven. Een procesentiteit is ceo entiteit waarin gegevens worden ondergebracht die betrekking hebben op imaginaire-. werkelijke- of plaatsgevonden hebbende gebeurtenissen. Attributen van procesentiteiten kunnen onder andere beCrekking hebben op gegevens over de transformatie van 'invoer' tot 'uitvoer', de hulpmiddelen en de besturing.

12

BIT Notes


Object-modellen en proces-modellen. De verschillende objecttypen hebben niet aileen hun eigen attributenverzameling, maar zijn ook onderling aan elkaar gerelateerd. Deze relaties zijn onderdeel van modellen. Een model is een atbeelding van de werkelijkheid vanuit een bepaald gezichtspunt. Op basis van de onderverdeling van objecttypen in de hoofdtypen 'object-entiteiten' en 'proces-entiteiten' wordt een onderscheid gemaakt tussen respectievelijk 'objectmodellen' en 'procesmodellen'. Relaties tussen entiteiten geven steeds de samenhang binnen het model aan. Een bijzondere vorm van het objectrnodel is een 'produktrnodel', waarbij het gaat om geproduceerde objecten. Hiervan weer een bijzondere vorm is het 'gebouwmodel', waarbij het gebouw wordt gezien als een SUbtype van een 'produkt'. Met een procesmodel kunnen onder andere de verschillende levensfasen van een object (produkt, gebouw) worden weergegeven, inclusief de relaties tussen deze fasen. Een nationaal en internationaal geaccepteerde techniek voor het weergeven van objectrnodellen zijn de zogenaamde NIAM-diagrammen, terwijl voor procesmodellen in dit verband gebruik gemaakt wordt van de IDEFO-diagrammen.

Specialisatie (vs. generalisatie) & decompositie vs. aggregatie. Entiteiten worden gekenmerkt door hun attributen. Een entiteit behoort tot een bepaald type als deze entiteit ten minste een tot dat type behorende verzameling attributen bevat. Dit zijn de kenmerkende of classificerende attributen. Specialisatie leidt tot sUbtypen van entiteiten. Een entiteit is een subtype van een entiteit (een supertype), wanneer het aile kenmerkende attributen heeft van het supertype en daarnaast tenminste een extra attribuut bezit waarmee het zich van het supertype onderscheidt. Het subtype is een specialisatie van het supertype. Decompositie en aggregatie zijn bewerkingen die leiden tot nieuwe entiteittypen. Bij decompositie wordt een entiteit opgedeeld in samenstellende entiteiten van een ander (entiteits)type. Aggregatie is het tegenovergestelde: daarin worden entiteiten (van verschillende typen) samengevoegd tot een entiteit van een andertype.

Een informatiesysteem voor de bouw. Volgens het ontwerp normblad moet een informatiesysteem voor de bouw zijn gebaseerd op de theorie zoals die hiervoor is beschreven. Dat wit zeggen dat het systeem op objecten procesmodellen moet zijn gebaseerd. Het basisobjectrnodel voor de bouw omvat het bouwwerk met zijn omgeving. Bij de decompositie van het bouwwerk wordt een opsplitsing gemaakt in 'ruimten' en 'elementen of resultaten'. Voorts stelt het ontwerp normblad dat er moet worden uitgegaan van twee basis-procesmodellen: • •

Het procesmodel dat de levensfasen van het bouwwerk weergeeft Het procesmodel waarbij de bouwprocessen aan de orde worden gesteld.

De hoofdonderdelen van de c1assificatie moeten zijn: • •

het onderscheiden van entiteitstypen het definieren van attributen, hun domeinen en hun groepering in verschillende aspecten.

Er wordt een voorlopige clustering van attributen tot bepaalde aspecten voorgesteld. Hierbij wordt echter terecht opgemerkt dat de voorgestelde clustering tenminste onvolledig en bovendien arbitrair is samengesteld. Derhalve wordt voorgesteld de clustering onder te brengen in twee categorieen, te weten: de categorie 'niet projectgebonden gegevens' en de categorie 'project gebonden gegevens'. Uiteindelijk moet het informatiesysteem een verzameling van attribuuttypen bevatten die aBe relevant zijn voor het beschrijven van een of meerdere entiteitstypen. Omdat deze verzameling niet permanent is zullen attribuuttypen moeten worden toegevoegd en verwijderd. Daamaast zullen ook hun domeinen aan verandering onderhevig zijn. In het concept normblad wordt voorts onderkend dat er aspectmodellen bestaan. Een aspectmodel wordt gedefinieerd als een deelmodel dat een enkel aspect van de entiteitenverzameling beschouwt. Aspectrnodellen moeten worden gevormd door het objectrnodel, aangevuld met een specifieke selectie van een bepaalde set attributen.

13


2.3

BIT Notes

ISO technical report 59 SC13 WG2.

Het rapport draagt de titel'Classification of information in the construction industry' en heeft de status van een voorlopig rapport. De hoofddoelstelling van dit rapport is gelegen in het leggen van een goede basis voor alle informatiestromen die tijdens het bouwproces plaatsvinden en het geven van richtlijnen voor een goede informatiestructuur in de bouwwereld. In de inleiding wordt gesteld dat het rapport niet los gezien kan worden van een aantal intemationale classificatie-standaards. Hierbij moet gedacht worden aan classificatie-tabellen voor gebouwen, ruimten. elementen, etc. Het rapport pretendeert de onderliggende filosofie van deze tabellen te definieren. Daarnaast wordt de relatie tussen al deze losse tabellen, alsmede de wijze waarop ze zouden kunnen worden samengevoegd tot een groot gei'ntegreerd geheel. besproken. Het rapport geeft een overzicht van informatiestromen in de bouw, maar blijft daarbij toch redelijk globaal. Een gebouw, zo wordt gesteld. kan afhankelijk van de invalshoek van een bij het bouwproces betrokken participant worden opgesplitst in verschillende delen. Er wordt een onderscheid gemaakt in spaces, elements, work sections en construction products. Het is moeilijk en gevaarlijk om deze termen te vertalen naar gangbare nederlandse begrippen. Daarom zal elk deel kort toegelicht worden. Spaces. De term spaces wordt gedefinieerd als zijnde drie-dimensionale ruimtes in en om gebouwen en andere bouwwerken, die daadwerkelijk danwel theoretisch worden begrensd. We kunnen hierbij bijvoorbeeld denken aan kantoor-ruimten, maar ook aan bijvoorbeeld de ruimte die een weg in beslag neemt. Er wordt een onderscheid gemaakt naar mimte en netto-mimte. Een netto-ruimte is in dit geval een ruimte waarin bijvoorbeeld een bepaalde functie kan worden uitgeoefend. Het begrip ruimte omvat dan deze netto-mimte inclusief de omringende muren, vloeren en daken. Er wordt gesteld dat de werkbare definitie van het begrip mimte afhangt van de 'view' van degene die met het begrip als zodanig moet werken. De term space kunnen we gevoegelijk vertalen met het nederlandse woord mimte. De meest wijd verbreide bestaande c1assificatie-tabel voor mimten is de CIfSm tabel-O. Bij deze tabel worden echter een aantal kanttekeningen geplaatst. Een belangrijke kanttekening is in dit geval dat de tabel problemen heeft met het c1assificeren van duale begrippen als een kantoorruimte in een fabriek. Elements. Voor de term elements vinden we de volgende definitie temg in het rapport: Elementen zijn de belangrijkste fysieke delen en systemen van een gebouw of bouwkundig werk. Zij worden gekenmerkt door het feit dat zij elk een karakteristieke functie hebben. Het begrip elementen wordt los gezien van de materialisatie (technical solution), of de bouwmethode. Voorbeelden vinden we in de begrippen vloeren, funderingen, buitenwandopeningen, etc. Deze elementen zijn belangrijk voor verschillende partijen in het bouwproces en zouden daarom uitermate geschikt zijn als informatiedrager. Intemationale overeenstemming over een te gebmiken c1assificatiesysteem zou dan ook, zo wordt gesteld, grote voordelen opleveren. Helaas wordt er in verschillende landen met evenzovele classificatiesystematieken voor elementen gewerkt. De meeste bestaande classificaties, waarvan vele min of meer zijn geent op tabel-l van het sm systeem, zijn slechts geschikt voor een beperkt aantal doelen. Een intemationale classificatietabel van elementen zou dan ook in technisch opzicht uit moeten stijgen boven de in omloop zijnde nationale classificaties. Dat vergt echter motivatie van aile partijen en grote inspanningen om huidige standaards aan te passen of los te laten en over te stappen naar een nieuwe systeem.

Work sections. Het begrip work sections wordt als voigt gedefinieerd: Een work section bestaat uit een of meerdere fysieke delen van een gebouw ofbouwwerk, gezien als het resultaat van specifieke vaardigheden en technieken die op bepaalde produkten tijdens de bouw worden uitgeoefend. Deze vaardigheden en technieken worden gewoonlijk uitgevoerd door verschillende gespecialiseerde onderaannemers of andere specialisten. Het begrip vertegenwoordigt een tweeledig concept. Enerzijds kan het begrip worden beschouwd vanuit de input-zijde (bijvoorbeeld de gebmikte basis componenten) en anderzijds kan het begrip ook worden beschouwd vanuit de output-zijde als we kijken naar de delen die ontstaan na het toevoegen van arbeid, en materieel aan de componenten.

14

BIT Notes


Het begrip work sections kan misschien het best vertaald worden middels het nederlandse begrip bouwdeel. Enkele voorbeelden van het begrip work sections kunnen dit misschien verduidelijken. Metselwerk, ramen, sprinkler installaties, etc. worden allen gezien als work sections. Deze work sections zijn met name belangrijk voor de aannemer en kunnen in direct verband worden gebracht met uit te voeren werkzaamheden op de bouwplaats. Ben bepaald type work section kunnen we in meerdere elementen tegenkomen. En evenzo bevat een element vaak meerdere typen work sections. Het zijn de work sections die het element materialiseren en vorm geven.

Construction products. Het begrip 'construction products' wordt gedefinieerd als zijnde produkten of componenten die zijn geIncorporeerd in het gebouw of bouwwerk. Opgemerkt wordt dat in de meeste Europese landen databases met produkinformatie bestaan. Er is zelfs een samenwerkingsverband tussen organisaties op dit terrein uit 10 landen. Dit samenwerkingsverband met de naam EPIC (European Product Information Co-operation) heeft zich als doel gesteld een gezamenlijke standaard voor de uitwisseIing van produktinformatie te ontwikkelen.

Informatie modellen. Het document wordt afgesloten met een aantal bijlagen waarin bovenstaande del en en de in omloop zijnde classificatie-systematieken voor deze delen kort worden behandeld. Daarnaast wordt nog enige aandacht geschonken aan gebouw-produkt-modellering. Er wordt gewezen op de ontwikkelingen die in dit kader in ISO/STEP verband plaatsvinden. Er wordt op gewezen dat gebouwen en andere bouwwerken kunnen worden gedecomponeerd in enerzijds fysieke delen en anderzijds in ruimten. Deze beide worden gezien als twee verschillende object-klassen. Afgezien van de fysieke attributen hebben ruimten dezelfde attributen als de 'fysieke delen', zij kunnen worden gedecomponeerd of geaggregeerd in ruimten op een lager dan wei hoger niveau. Eigenlijk is dit het min of meer bekende verhaal dat we overal tegenkomen. Een en ander zal nog aan de orde komen in hoofdstuk 5.

2.4

Het bouwbesluit.

Het bouwbesluit is een misschien ietwat 'vreemde eend in de bijt' van dit hoofdstuk. Toch mag het niet ontbreken. Het bouwbesluit vah niet in de categorie normen of afsprakenstelsels maar moet men scharen onder het kopje regelgeving. Het zijn bouwvoorschriften, door de overheid vastgelegd, waaraan bouwwerken moeten voldoen. Met name de hierarchische indeling die ten aanzien van het begrip prestatie-eisen geldt is in het kader van dit onderzoek van belang. Eerst een klein stukje geschiedenis. Aan deze nieuwe bouwvoorschriften ligt een langdurige geschiedenis ten grondslag. In de beginjaren 'SO is het streven naar vermindering en vereenvoudiging van de regelgeving en regeldruk ingezet. Het eerste kabinet Lubbers heeft dat streven tot deregulering tot een van zijn doelstellingen gemaakt. Met het oog op de deregulering van de bouwregelgeving is toen een stuurgroep ingesteld. Na vele adviezen en behandeling van allerlei wetsvoorstellen in de tweede kamer is uiteindelijk het bouwbesluit in december 1991 door de koningin bekrachtigd en op 31 december van dat zelfde jaar in de Staatscourant gepubliceerd.

Vijf niveans van regeling. Het bouwbesluit bevat de minimum voorschriften waaraan een bouwwerk publiekrechtelijk gezien. moet voldoen. wil, wat deze voorschriften betreft, voor het bouwen daarvan bouwvergunning kunnen worden verleend. De in het bouwbesluit gegeven voorschriften beperken zich tot bouwtechnische en woon- of inrichtingstechnische voorschriften. Bouwtechnische voorschriften zijn voorschriften die aangeven op welke wijze de constructie van een bouwwerk moet worden gemaakt en waaraan de daarin aangebrachte technische voorzieningen moeten voldoen. Tot deze voorschriften worden ook bouwfysische voorschriften en brandveiligheidsvoorschriften gerekend. De voorschriften met betrekking tot energiezuinigheid behoren tot de bouwfysische eisen. De bouwtechnische voorschriften houden dan ook hoofdzakelijk verband met de

15


BIT Notes

veiligheid en de gezondheid van de gebruikers van bouwwerken, alsmede met, wat gebouwen betreft, een zuinig gebruik van energie. Het bouwbesluit is beschreven vanuit de optiek van deregulering: vermindering van regeldruk. Dit kan onder andere worden bereikt door de technische eisen op een zo hoog mogelijk niveau te regelen. Dil is echter niet voor aile te stellen eisen mogelijk gebleken. De eisen zijn uiteindelijk als voigt - van hoog naar laag - in de volgende vijf niveaus gerangschikt:

1. 2. 3. 4. 5.

bouwwerk ruimte scheidingsconstructie bouwdeel materiaal

Deze vijf niveaus zullen even kort worden toegelicht. Niveau I:

Bouwwerk

Een bouwwerk, meestal een gebouw, is het hoogste niveau waarop eisen zijn gesteld. Een eis gesteld aan het hele gebouw omvat dan ook altijd de lagere niveaus. Een voorbeeld: de eisen aan de stabiliteit van een bouwwerk zijn op het hoogste niveau (bouwwerk) gesteld. Deze eisen zijn echter tevens van invloed op bouwdelen en materialen (de laagste niveaus) waaruit dat bouwwerk is opgebouwd. Niveau 2:

Ruimte

Een gebouw is in de regel uit meerdere ruimten opgebouwd. Daarom is als tweede niveau een ruimte gekozen waaraan eisen worden gesteld. Wat dit betreft kan dan bijvoorbeeld gedacht worden aan de minimaal vereiste ventilatiecapaciteit van een verblijfsgebied (de term verblijfsgebied is in het bouwbesluit nader uitgewerkt). De eisen die op het ruimteniveau zijn gesteld werken op hun beurt weer door op de niveaus die lager zijn dan een ruimte. Zo werkt de aan een verblijfsgebied gestelde minimumeis voor de ventilatie door naar het direct daarop volgende lagere niveau, te weten: een scheidingsconstructie. Niveau 3:

Scheidingsconstructie

Het begrip scheidingsconstructie omvat aanduidingen als geve1, wand en dak. Het bouwbesluit maakt daarbij verschil tussen een inwendige scheidingsconstructie, en een uitwendige scheidingsconstructie. Het begrip 'inwendige scheidingsconstructie' is van belang wanneer de gestelde eisen gelden tussen: • • •

twee binnen hetzelfde gebouw gelegen ruimten twee niet in hetzelfde gebouw gelegen, maar aan elkaar grenzende ruimten twee ruimten van hetzelfde gebouw, waarbij de ene ruimte in het gebouw is gelegen en de andere ruimte de scheiding vormt met buiten, zoals bijvoorbeeld met een serre het geval is.

Het begrip 'uitwendige scheidingsconstructie' is van belang wanneer de gestelde eisen gelden tussen een in het gebouw gelegen ruimte en buiten. Een scheidingsconstructie is in de regel opgebouwd uit bouwdelen, die dan ook het vierde niveau van regeling vormen. Niveau4:

Bouwdeel

Bouwdelen zijn bijvoorbeeld gevel- en dakelementen, deuren en kozijnen, die in een bouwwerk worden toegepast. de aansluitdetails zijn daarbij inbegrepen. Bouwdelen maken in veel gevallen deel uit van een scheidingsconstructie. Te denken valt bijvoorbeeld aan ramen, wanden, daken, ventilatievoorzieningen, etc. Een eis op bouwdeelniveau is bijvoorbeeld de maximale rookontwikkeling van een constructie-onderdeel van een gebouw. Een bouwdee1 is opgebouwd uit materiaal. Materiaal vormt dan ook het laatste niveau van regeling.

16

BIT Notes

TUB I Building Infonnation Technology

Niveau 5:

Materiaal

Aile bouwdelen zijn opgebouwd uit materialen. het laagste niveau van regeling. Op dit niveau steh het bouwbesluit nog geen directe eisen. Bij ministeriele regeling kunnen echter wei eisen worden gesteld ten aanzien van de toepassing van schadelijke of hinderlijke materialen. zoals bijvoorbeeld voor asbesthoudende materialen. Het is ook niet uitgesloten dat voor de uitvoeri~g van de EEG-richtlijn bouwprodukten nog eisen aan materialen gesteld gaan worden.

Prestatie-eisen. De voorschriften in het bouwbesluit zijn geformuleerd als zogeheten prestatie-eisen. Deze zijn gebaseerd op functionele omschrijvingen. De prestatie-eis is een gekwantificeerde grenswaarde waarvoor een bepalingsmethode is te geven. In de functionele omschrijving staat het motief voor een te stellen prestatie-eis. Tot op heden zijn nog niet voor aile 'niet tot bewoning bestemde gebouwen' toegesneden prestatie-eisen geformuleerd. Het begrip prestatie-eis wordt als voigt gedefinieerd: Een prestatie-eis is een in maten of getallen geconcretiseerd voorschrift dat is toegespitst op een bepaalde eigenschap van een bouwconstructie en dat een te behalen grenswaarde bevat die ondubbelzinnig kan worden gemeten of berekend. Zoals reeds eerder gemeld zijn met name voor de categorie 'niet tot bewoning bestemde gebouwen' nog niet aIle prestatie-eisen geformuleerd. Dit betekent dat voor deze categorie bouwwerken de ontbrekende prestatieeisen als functionele eisen zijn geformuleerd. Voor de omzetting van deze functionele eisen in prestatie-eisen is nog het nodige onderzoek en overleg vereist. Een en ander zal voor oktober 1996 zijn beslag krijgen. Zoals uit de definitie blijkt wordt de prestatie-eis onder meer in een concrete waarde uitgedrukt. Het vasdeggen van deze grenswaarde vindt in beginsel plaats in het bouwbesluit. Niet aIleen de grenswaarde, maar ook een bepalingsmethode maakt deel uit van de prestatie-eis. De wijze waarop een grenswaarde wordt bepaald is een bepalingsmetbode. Deze zorgt ervoor dat een grenswaarde ondubbelzinnig meetbaar en controleerbaar wordt. Het is voorts van belang te vermelden dat bij prestatie-eisen de te leveren prestaties van belang zijn en niet de manier waarop deze tot stand komen. Het bouwbesluit gaat bij het geven van voorschriften dan ook uit van het gerede produkt.

17

TUB I Building Infonnation Technology

3

BIT Notes

Afbakening en aanpak van het onderzoek.

Gezien de krappe planning, zie tabell, en de beperkte financiele middelen is het noodzakelijk het onderzoek strak in te kaderen. Om binnen deze restricties toch tot aansprekende resultaten te kunnen komen is een bepaalde aanpak vereist.

Aktiviteiten

Dagen

1. Voorbereiding, planning, contracten, management etc.

10

2.0verleg 3. Inventarisatie gegevensvraag begroting en bestek 4. Inventarisatiegegevensvraag VABI 5. Inventarisatie gegevensaanbod architektlcad-systemen 6.0verleg 7. Ontwikkeling theorie bouwkundig ontwerpen 8. Inventarisatie randvoorwaarden (DUS)software VAB! 9. Inventarisatie randvoorwaarden Clasco, STEP etc 1O.0verleg 11. Ontwikkeling voorbeeld bouwkundig model in NIAM en Expess 12. Toetsing van het model aan de praktijk/overleg 13. Ontwikkeling prototype VCAlDUS met CAD-interface 14. Toetsing en aanpassing van het prototypefoverleg 15. Rapportage 16.0verieg tabel 1: Planning

3 4 4 8

3 15

3 6 3 13

6 27

8 10

3

Binnen deze aanpak is, hoe graag we dat ook zouden willen, geen ruimte voor uitgebreide 'eigen' onderzoeken. Op zich is dat geen probleem. Er is narnelijk voldoende informatie op het gebied van produkten gebouwmodellen voorhanden. Deze ontwikkelde kennis, van vaak gerenommeerde onderzoeksinstituten. waar vele jaren aan is gewerkt kan als basis voor verder onderzoek goede diensten bewijzen. Voor een allesomvattende inventarisatie is echter de tijd niet aanwezig. Vandaar dat er een doelgerichte inventarisatie heeft plaatsgevonden. Onder doelgericht verstaan wij in dit verband dat er een inventarisatie heeft plaatsgevonden vanuit de gegevensvraag, zoals die wordt geformuleerd in het NOBIfBBB- en het V ABIfDUSproject. Om een en ander in een ruimer architectonisch kader te plaatsen is gebruik gemaakt van het synthesemodel dat door Bjork is opgesteld. Dit model van Bjork is gekozen vanwege diens grote expertice op het gebied ban productmodellen en omdat het synthese model, de naarn zegt het ai, een samenvoeging is van vier recente uit onderzoek voortvloeiende produktmodellen. Zie voor een verdere behandeling van deze modellen paragraaf 4.3 en 4.4. De samenvoeging van het BBB-, het V ABIfDUS- en het Bjork-model hebben geJeid tot het NOBI Bouwkundig Model.

3.1

De architect, de kostendeskundige en de installatietechnicus.

De architect, de kostendeskundige en de installatietechnicus vertegenwoordigen drie verschillende disciplines die elk op hun eigen manier tegen een (nieuw te ontwerpen) gebouw aan zullen kijken. Daar waar voor de architect een gebouw wordt gevormd door massa's, ruimten en materialen met een bepaaJde uitstraling en gesitueerd in een bepaaJde stedebouwkundige omgeving, zal een gebouw voor de andere twee disciplines gevormd worden door andere zaken. De bouwkostendeskundige zal een gebouw bijvoorbeeld beschouwen als zijnde een verzarneling aan elkaar gerelateerde kostendragers die 'uitgetrokken' moeten kunnen worden en waaraan vervolgens een prijskaartje gehangen kan worden. Ben installatietechnicus zal het gebouw wellicht zien a1s zijnde een 'systeem' dat moet worden verwarmd, gekoeld, geventileerd. etc. Het is dan ook algemeen erkend dat elke discipline een andere kijk, een andere view, op hetzelfde bouwprodukt zal hebben. Een view kan worden gezien als een bepaaJde hoeveelheid informatie waarvan de structuur en betekenis discipline-afhankelijk is. In het kader van dit onderzoek is het enerzijds belangrijk om te onderkennen dat deze verschillende disciplines ieder vanuit hun eigen invalshoek naar een gebouw kijken, maar anderzijds is het veel belangrijker om te kijken wat de gemeenschappelijke basis is. Met andere woorden waar overlappen de verschillende disciplines elkaar als het gaat om informatie die aile partijen sarnen gebruiken. of sarnen zouden kunnen gebruiken.

18


BIT Notes

Teneinde een view bespreekbaar te maken en aIs basis voor verdere ontwikkelingen te kunnen gebruiken, wordt een view vastgelegd middels een viewmodel. Dit onderzoek neemt de architectendiscipline aIs uitgangspunt. Wij spreken van een architecten-viewmodel. Gezien de te verwachten omvang en complexiteit van dit model beperken wij ons in dit onderzoek tot die specifieke infonnatie in het architecten-viewmodel die voor kostendeskundigen en instaIlatietechnici nodig is voor het kunnen uitvoeren van hun berekeningen. De gegevensvraag van zowel de kostendeskundige aIs de installatietechnicus zijn in het kader van dit onderzoek bekend. Deze vraag is namelijk vastgelegd in de binnen deze disciplines gebruikte applicaties. Voor de kostendeskundige wordt hier uitgegaan van de gegevensbehoefte roals is vastgesteld in het NOBIIBBBproject. Voorde installatietechnicus wordt uitgegaan van de gegevensvraag zoaIs die is vastgelegd in de VABI-modellen en daarop gebaseerde applicaties. De architect zal deze gegevens moeten aanleveren. Zoals reeds is gezegd is het in het kader van dit onderzoek niet de bedoeling om een compleet 'architectenviewmodel' te beschrijven. Wei worden de view-modellen van de kostendeskundige en de installatietechnicus uit hun 'enge' verband gehaald en in een 'ruimer' architectonisch kader geplaatsl We kunnen dan ook zeggen dat NOBIIBM een sub-viewmodel van de architect is.

3.2

Het ontwerpproces.

De gegevensvraag van een architect hangt natuurlijk direct samen met diens werkwijze en aktiviteiten oftewel het ontwerpproces en moet dus in het kader van dit onderzoek worden bestudeerd. We kunnen hier kort over zijn: Het ontwerpproces kunnen we niet beschrijven. Met andere woorden, welke informatie moet worden vastgelegd in een viewmodel is binnen zekere grenzen haalbaar, echter hoe de informatie tijdens het ontwerpproces wordt vergaard, bewerkt c.q. verwerkt is niet zonder meer formeel te beschrijven en vergt onderzoek op vele fronten. Een ontwerpproces wordt immers door verschiUende ontwerpers en voor verschillende opdrachten vaak geheel verschillend doorlopen. Weliswaar zijn er vele meer of minder gedetailleerde procesmodellen opgesteld zoaIs in het BIM of in bet SBR rapport 211 - Informatie-overdracht via tekeningen. Hoewel ze zeer zeker een bijdrage leveren aan de algemene begripsvorming, zijn deze modellen overwegend mechanisch deterministisch van aard, houden ze geen rekening met cognitieve aspecten en worden ze niet geplaatst in een culturele en sociaal economische context. Ook op internationaal vlak wordt veel onderzoek verricht naar ontwerpmethoden. Om enkele bekende methoden te noemen: "Case based design, constraint based design, object based design, goal driven design, problem driven design, topdown design, bottom up design, component based design". Het grootste gedeelte beperkt zich echter tot puur geometrische en topologische aspekten. Het beschrijven van de vele ontwerpprocesbenaderingen is in dit kader niet mogelijk. Derhalve is besloten voor het toetsen van de gegevensmodellen in de praktijk met behulp van een prototype. Zie voor een beschrijving deel C van dit rapport. Ondanks de vele verschillende beschouwingswijzen zijn er overeenkomsten te noteren. AIle modellen c.q. method en gaan uit van een zekere fasering van het ontwerpproces, van een mogelijke opsplitsing van een bouwwerk in kleinere onderdelen (decompositie) en van aggregatietoestanden. De Nederlandse norm 2574 'Indeling van gegevens op tekeningen' biedt wat betreft de fasering enig houvast en wordt in de volgende paragraaf nader besproken. Wat betreft de decompositie en aggregatietoestanden en hoe deze worden vertaaId naar aktiviteiten in het ontwerpproces, is de procesbeschrijving genomen zoals deze in een ander NOBI project. te weten het BBBproject, is verwoord. Uitgangspunt is dat het ontwerpproces als een communicatieproces wordt beschouwd. In het BM-onderzoek betreft het de communicatie tussen architect, installatietechnisch adviseur en kostendeskundige.

3.2.1

De fasering van het ontwerpproces.

Een fase kan gezien worden als een afgebakend onderdeel van het proces. Elke fase kent een duidelijk omschreven resultaat. In de SBR publicatie 211 - Informatieoverdracht via tekeningen - zijn een aantal faseringsmodellen nader bekeken. Er wordt een voorkeur uitgesproken ten aanzien van de fasering volgens NEN2574. Weliswaar behandelt de norm de indeling van gegevens op basis van tekeningen, terwijl dit onderzoek uitgaat van het produktmodelleringsconcept (waarbij de tekening niet centraal staat, maar een afgeleide is), de gehanteerde fasering blijft geldig en bruikbaar. De norm onderscheidt een viertal hoofdfasen die elk zijn onderverdeeld in twee of drie subfasen, namelijk:

19

TUEI Building Information Technology

A.

PROGRAMMERING

BIT Notes

1.

2. 3. B.

ONTWERPEN

4.

5. 6. C.

UITWERKING

7.

8. D.

BOUW

9. 10. 11.

Initiatief Haalbaarheidsstudie Projectdefinitie Structuurontwerp Voorlopig ontwerp Definitief ontwerp Bestek Prijsvorming Werkvoorbereiding Uitvoering Oplevering

De programmering start bij het eerste onderzoek naar ruimtebehoefte. Indien de programmering door de resultaten van het onderzoek niet eerder is stopgezet, eindigt het programma op het moment dat ereen functioneel, technisch, financieel, ruimtelijk en organisatorisch kader is bepaald waarbinnen nieuwbouw of verbouw dient plaats te vinden. Tijdens het ontwerpen worden, in toenemende mate van gedetailleerdheid, een ruimtelijk en functioneel ontwerp en financiele, technische en organisatorische plannen gemaakt. In ontwerp en plannen worden de wensen van de opdrachtgever, bevoegde instanties en de toekomstige gebruikers verwerkt. De uitwerking begint met het maken van bestektekeningen en overige documenten die nodig zijn voor de bouwaanvraag. Tijdens de uitwerking wordt de bouwaanvraag ingediend en worden tevens de bestektekeningen, de bestekbeschrijving, begroting en overige documenten ten behoeve van de prijsvorming opgesteld. De uitwerking eindigt met de aannemingsovereenkomst. De bouw begint met de voorbereiding op het bouwen door zowel adviseurs als aannemer(s). Tijdens het daadwerkelijke bouwen kan de architect de directievoering verkrijgen. De bouw eindigt met de oplevering. Na de oplevering voigt de fase die 'beheer & gebruik' kan worden genoemd. Deze fase wordt echter niet in deze norm behandeld. Een 'bouwkundig model' kan in elk van de boven beschreven fasen goede diensten bewijzen als het gaat om een effectieve en efficiente informatie-uitwisseling tussen de verschillende partijen die bij het ontwerp-, bouwen gebruiksproces zijn betrokken. In het kader van dit onderzoek beperken we ons echter tot het gebruik van het NOBIIBM in de DO-fase.

20


3.3

BIT Notes

Het Intechno gebouw.

Ten behoeve van de noodzakelijke toetsing van het NOBIIBM aan de praktijk, zal het model worden ingevuld met objecttypen zoals die voorkomen in een bestaand kantoorgebouw. Het kantoorgebouw dat voor deze toets zal worden gebruikt is gerealiseerd in Veenendaal ten behoeve van het ingenieursbureau 'Intechno'. We spreken dan ook voortaan over het 'Intechno gebouw'. Daar waar het NOBIIBM in eerste instantie aIleen een abstract begrippenkader biedt, wordt dat middels het Intechno gebouw concreet met bouwkundige zaken ingevuld. Aan de hand van deze toets wordt het NOBIIBM model gedetailleerder uitgewerkt. Deze invulling geeft het uiteindelijke 'Intechno Bouwkundig Model'. Deze aanpak is overigens conform de informatie-analyse volgens NIAM. waarbij eerst de specifieke objecttypen worden geldentificeerd, waaruit vervolgens de entiteittypen worden gedestilleerd. Natuurlijk is bij de opzet van het NOBIIBM gepoogd om het model een zo algemeen mogelijk karakter te geven, zodat het zal kunnen dienen aIs informatiedrager voor verschillende typen gebouwen. Het NOBIIBM wordt echter getoetst aan ren specifiek kantoorgebouw, het Intechnogebouw. Dit is een verdere afbakening van de opdracht.

Figuur 3.3: Het Intechnokantoor

21


4

BIT Notes

Inventarisatie.

Zoals in het voorgaande hoofdstuk is toegelicht, beperken we ons in het kader van dit onderzook tot de gegevensvraag zoals we die kennen uit het NOBIIBBB-model en het VABIIDUS-model. Het is derhalve belangrijk te weten hoe deze modellen zijn opgebouwd, en wat ze beogen. Derhalve mooten beide modellen geinventariseerd worden. Kenmerk van productmodellen is dat ze nooit af zijn. Producten veranderen en aan de modellen valt altijd weI iets te verbeteren. De beschrijvingen van de in dit hoofdstuk behandeide modellen moeten dan ook ais een momentopname worden gezien! Het blijkt dat in het ~OBIIBBB model veel met bouwdelen wordt gewerkt, daar waar in het V ABIIDUS model veel met ruimten wordt gewerkt. In het NOBIIBM zullen beide entiteittypen in een model op een duidelijke en overzichtelijke manier aan elkaar gerelateerd mooten worden. Derhalve is dankbaar gekeken naar een model zo~ls dat door Bjork is opgesteld naar aanleiding van zijn analyse van een viertal bestaande modellen zoais die zijn gedefinieerd door gerenomeerde onderzooksinstituten. Een en ander wordt uitgebreid in dit inventariserende hoofdstuk toegelicht.

4.1

Het NOBIIBBB-model.

Onder de titel 'NOBIIBBB Bouwkosten en bestek' is een onderzook gaande met als onderzoeksthema het vergroten van de kwaliteit van kostenramingen in de ontwerpfase. Het onderzoek tracht een antwoord te vinden op de tekortkomingen zoals die bij de huidige begrotingssoftware wordt ervaren. De belangrijkste knelpunten zijn: De huidige software is voornamelijk gebaseerd op begrotingsregels van aannemers. Een koppeling tussen ontwerp enerzijds en begroting c.q. bestek anderzijds is nauwelijks aanwezig en ook niet good door te vooren, hetzelfde kan worden gezegd over de mogelijkheid tot terugkoppeling van kostengegevens. Verder is er behoofte aan een integraJe kostenbudgetteringmethode en aan aigemeen gestandaardiseerde kostenbestanden. Het onderzoek vindt plaats in opdracht van YeA, SBR en DHV met subsidie van het Ministerie van Economische Zaken, in het kader van het Nationaal Onderzooksprogramma Bouwinformatica (NOBI). Het onderzoek loopt eind 1993 af.

De doelstelling. De doelstelling van het NOBIIBBB onderzook is het vergroten van de kwaliteit van kostenramingen in de ontwerpfase. Daarbij wordt gestreefd naar een integratie van kosten-, ontwerp-, en bestekgegevens gezien vanuit de positie ('view') van de begrotingsdeskundige. Het onderzook richt zich daarbij op drie concrete resultaten: •

• •

Het ontwikkelen van een voor architecten en bouwkostendeskundigen algemeen bruikbare methode voor het bepalen van de kooten van een bouwproject in de verschillende ontwerpstadia. Het ontwikkelen van een afsprakenstelsel met betrekking tot de kostendatabase, waarvan de methode gebruik zaJ maken. Het ontwikkelen van een prototype van een computerprogramma. Hiermee is het mogeJijk om de doelgroepen overtuigend te laten kennis maken met het project en hun commentaar op de methodiek doeltreffend te verzamelen en te verwerken.

Resultaten. De resultaten van het onderzook liggen vast in een aantal rapporten. Tevens is er een semi-operationeel computerprogramma ontwikkeld. Een prototype ten behoeve van een betere communicatie en ter demonstratie van het ontwikkelde begrotings- en uitwisselingsconcept. De verschillende resultaten worden hieronder nader beschreven.

22


4.1.1

BIT Notes

Bet NOBIIBBB systeemconcept.

Belangrijk voor het BBB-onderzoek is de modelgerichte benadering in tegenstelling tot een procesgerichte benadering. Laatste bemoeilijkt, de praktijk heeft dit uitgewezen, het streven naar integratie van de verschillende bouwkundige informatiesystemen. Het BBB-systeemconcept is dan ook gebaseerd op de produktmodelleringsparadigma. Het systeem bestaat uit twee delen te weten het begrotingsconcept en het uhwisselingsconcept. Het begrotingsconcept geeft de structuur en plaats van de te ontwikkelen begrotingssoftware weer. Het uitwisselingsconcept beschrijft de datastructuur en uitwisseling van gegevens tussen de verschillende systemen. In het kort gaat het begrotingsconcept uit van: Het werken met referenties, de koppelingen tussen de verschillende ontwerpstadia en bestek, een hierarchische structuur van de kostendragers (zie volgende paragraaf) en heeft als uitgangspunt de elementenbenadering van ontwerpers.

Bet datamodel. Dit model beschrijft de verschillende kostendragende objecten en bijbehorende structuur. Met structuur wordt gerefereerd naar de relaties tussen de objecten. Uitgangspunt is het NIAM-schema zoals beschreven in het rapport 'Classification of Information in the Contruction industry ISO TC 59 SC 13 WG2'. Oit concept is inmiddels in Nederland verder ontwikkeld en gehanteerd bij het definieren van de ontwerpnorm NEN 2660. Het BBB onderscheidt een viertal kostendragers met een duidelijke hierarchie. Deze vier zijn: bouwwerk, element, bouwdeel en middel. De samenhang is als voIgt: Een bouwwerk bevat elementen, bedoeld worden NL/SfB elementen. Deze elementen bevatten bouwdelen die op hun beurt zijn opgebouwd uit middelen. De decompositie van een kostendragend object in subobjecten is niet dwingend. Bijvoorbeeld, een bouwdeel hoeft niet verder te worden onderbouwd door middelen. Binnen het BBB is dan sprake van een niet gematerialiseerd bouwdeel in tegenstelling tot een door middelen onderbouwd gematerialiseerd bouwdeel. De middelen kunnen arbeid, materiaal of materieel zijn. Via een bouwdeelrecept, een soort cluster van middelen, worden middelen gekoppeld aan een bouwdeeL Ais notatietechniek is conform het ABI gebruik gemaakt van NIAM. Voor het NIAM-schema wordt verwezen naar figuur 4.1.

Bet procesmodel. Uitgangspunt voor het procesmodel zijn de resultaten van het BIM, aangevuld met de, door de in de onderzoeksgroep vertegenwoordigde begrotingsdeskundigen, opgestelde begrotingsmodellen. Het centrale proces uit BIM dat relevant is voor het NOBIIBBB, is A22: 'Maak objectspecificatie' Binnen het BBB is dit vertaald naar: 'Ontwerp, teken en begroot het te bouwen object, maak de bijbehorende controleberekeningen, en maak bestek en bijbehorende tekeningen, volgens het programma van eisen en volgens de geldende regels en normen, uitgaande van de gegeven situatie. de beschikbare modellen, en met behulp van beschikbare middelen en deskundigheid'. Het procesmodel is beschreven met behulp van de IDEF-analysetechniek.

23

- ... ,'NIJSru \ " , code I ;""

(nurn/codel \

()fmdui jving)

gereAli!leerd door

\

,

besuan uit

uitmalcen van

TUB I Building Information Technology

BIT Notes

Het prototype. Het prototype moet worden gezien als een instrument, in de vorm van een computerprogramma, dat zowel het door de BBB-projektteam ontwikkelde begrotingsconcept als de methodiek van het VCAlDUS uitwisselingsconcept inzichtelijk en overdraagbaar moet maken. Oit voor zowel toekomstige gebruikers als ontwikkelaars van begrotingsprogrammatuur. Hoewel niet alle systeemeisen operationeel zijn, geeft het prototype een relatief goed beeld van de begrotingssoftware zoals deze volgens het BBB-concept zou moeten zijn. De uitgangspunten voor het prototype zijn: - De door de projektgroep ontwikkelde begrotingsmethodiek moet worden ondersteund. - Het systeem moet geschikt zijn voor projekten op het gebied van kantorenbouw. - Bepaling van bouwkosten zoaIs gedefinieerd in NEN 2631. - Beschouwd worden aIleen de bouwprocesfasen definitief ontwerpen en bestek (BNA). - De indeling naar elementen gaat volgens Elementenmethode '91. - De besteksordening gaat volgens de STABU2 systematiek. - Toetsing op basis van het Intechno gebouw moet mogelijk zijn. - Het prototype moet op gangbare apparatuur gedemonstreerd kunnen worden. Ten behoeve van de ontwikkeling van het prototype zijn er een aantaI keuzes gemaakt. Daarbij ging de voorkeur uit naar een uitwerking in de breedte. Met andere woorden, niet een enkel aspekt, zoals bijvoorbeeld de userinterface of een specifiek uitwisselingsformaat zoaIs Express, is volledig uitgewerkt, maar zoveel mogelijk verschillende onderdelen. Uiteraard met de consequentie dat uiteindelijk niet alles even volledig gedefinieerd en getmplementeerd is. Het voordeel van deze benadering is dat er binnen het gestelde termijn en budget een operationeel prototype is ontwikkeld, dat gebruikt kan worden voor toetsing van de nieuw gedefinieerde begrotingsmethodiek en dat zich goed leent voor demonstraties aan de verschillende doelgroepen.

4.1.2

Teehnieken.

Mede gezien de complexiteit en diversiteit van de materie, welke uit een integrale modelgerichte benadering voortvloeit, dient het ontwerpen van een informatiesysteem op een geordende en beheersbare wijze plaats te vinden. Ais systeemontwikkelingsmethode binnen het BBB is gekozen voor de faseringsmethode SDM zoals is vastgelegd in het Afsprakenstelsel Bouwinformatica (ABI). Kenmerkend voor deze methode is de gefaseerde benaderingswijze. Voor het BBB-project zijn dat achtereenvolgens de fasen Definitiestudie, Basis- en Detail ontwerp en Prototyping. Voor elke fase dienen een aantal activiteiten te worden verricht. De daaruit voortvloeiende resultaten worden per fase vastgelegd in zogenaamd beslisdocumenten c.q. rapporten. Elk afsluitend document of rapport vormt het uitgangspunt voor de daarop volgende fase. Zo kent het BBB onder meer de rapporten Inventarisatie, Gebouwmodel, Prototype. Zoals aangegeven, is de keuze van een goede faseringsmethode, zoals SDM, als hulpmiddel voor de bewaking en sturing van zowe! voortgang als kwaliteit onontbeerlijk. Het gebruik van SDM in onderzoeksprojekten zoaIs het NOBIIBBB project kent echter ook nadelige aspecten. Een nadeel van deze werkwijze is, dat het veelaI dogmatisch hanteren van de faseringsmethode kan leiden tot starheid in het ontwikkelingsproces en overaccentuering van relatief minder belangrijke aspecten. Ook vergt het strikt uitvoeren van de methode relatief veel tijd en zijn terugkoppelingen om eerder genomen beslissingen of onnauwkeurigheden te corrigeren niet of nauwelijks mogeJijk. Daarom is voor de ontwikkeling van het BBB-prototype binnen de globaIe fasering volgens SDM gekozen voor een iteratieve, meer pragmatische benadering, beter bekend als prototyping of incrementele ontwikkeling. En omdat het prototype wordt gebruikt als uitgangspunt voor verdere ontwikkelingen is er sprake van evolutionaire incrementele ontwikkeling. Hoewel deze methodiek niet in het ABI wordt vermeld (helaas, zoaIs uit bovenstaande mag worden afgeleid), is het met name in situaties met een sterk onderzoekskarakter een zeer geschikte werkwijze. Ook is prototyping geschikt in omgevingen waar capaciteit enlof tijd voor een gedegen analyse slechts beperkt aanwezig zijn. Door middel van prototyping kan de altijd aanwezige communicatiekloof tussen ontwikkelaars en gebruikers sneller en veelal ook doelmatiger worden overbrugt. Andere voordelen zijn de grotere betrokkenheid van gebruikers en opdrachtgevers met het ontwikkelingsproces, de mogelijkheid voor training en voorlichting, het inschatten van het effect op de organisatie (werkwijze en werklast).

25


BIT Notes

Omdat prototyping lastiger te beheren en te sturen is, is er door de projectgroep een balans tussen beide methoden gevonden, tussen de fasering en verplichte activiteiten van SDM en het flexibele maar lastiger te beheersen proto typing.

4.1.3

Uitwisseling, Step en Express.

Binnen het systeemconcept is sprake van een uitwisselingsconcept en een begrotingsconcept. De grootste aandacht is daarbij uitgegaan naar het begrotingsconcept. Het uitwisselingsconcept is summier uitgewerkt en beperkt zich tot enkele globale omschrijvingen. Overigens is dit conform de doelstelling van het onderzoek. Het BBB onderzoek gaat er vanuit, dat het uitwerken van het uitwisselingsconcept in het kader van het Bouwkundig Model onderzoek plaats zal vinden. Uitzondering hierop vormt de uitwisseling c.q. koppeling met bestekgegevens. Daarvoor zijn een drietal koppelingen binnen de structuur aangegeven. De eerste koppeling vindt plaats op bouwdeelniveau waarbij de identificerende code van een bouwdeel gelijk is aan die zoals STABU deze hanteert. Dit vergt een classificatie van aile denkbare bouwdelen die op het moment echter nog niet beschikbaar is. De tweede koppeling vormt het bouwdeelrecept welke qua structuur en functionaliteit vrijwel overeenkomt met het STABU korttekst begrip, ware het niet dat bouwdeelrecepten bouwdeel georienteerd zjjn en kortteksten werksoort georienteerd. STABU is op het moment bezig met de definities van zogenaamde clusters waardoor dit knelpunt zal komen te vervallen. De derde en laatste koppeling Iigt op het middelen niveau. Hier is een koppeling met de specificatieteksten van STABU goed mogeJijk, alhoewel ook hier geldt dat niet aile middelen een-eenduidig zijn vastgelegd. Hoewel er Express schema's zijn gegenereerd, zie het rapport Gebouwmodel, komen deze niet volledig overeen met de datarnodellen zoals die in het rapport Prototype als NJAMschema's zijn opgenomen. Het moet echter niet moeilijk zijn de Express definities te genereren uit de beschreven NJAMschema's. Het onderzoek tracht bij de definitie van de verschillende STEP en Express structuren zoveel mogelijk aansluiting te vinden bij het VABUDUS.

26


4.2

BIT Notes

Bet VABIIDUS model (Fase 4).

Automatisering blijft achter in de bouw ten opzichte van andere bedrijfstakken. De oorzaak hiervoor ligt vol gens de V ABI (Vereniging voor Automatisering in Bouw- en Installatie-techniek) in het feit dat het bouwproces gekenmerkt wordt door een tijdelijk samenwerkingsverband tussen verschillende partijen met slechts weinig herhalingen. V ABI heeft het initiatief genomen voor het ontwikkelen van een stelsel van conventies met betrekking op gegevens die voor meerdere partijen in het bouwproces van belang zijn. Dil onderzoek wordt uitgevoerd onder de naam DUS (Data Uitwisselings Systeem). Het project is in 1987 opgestart en heeft geleid tot de ontwikkeling van een proefsysteem. In de huidige fase van DUS wordt een prototype van het systeem gebouwd, specifiek voor de uitwisseling van installatie-technische gegevens.

Bij de bespreking van van VABIIDUS wordt uitgegaan van de ontwikkelingen zoals deze zich in Fase 4 bevinden. Doelstelling. De doelstelling van het V ABIIDUS project omvat het ontwerp en de verwezenlijking van een Data Uitwisselings Systeem voor bouwen installatietechniek om automatisering in en tussen deze bedrijfstakken te stimuleren ten behoeve van hogere efficientie en kwaliteitsverbetering. DUS maakt een uitwisseling van gegevens mogelijk tussen verschillende partners in het bouwproces (exteme communicatie), en een koppeling van applicaties van verschillende disciplines aan grafische CAD-systemen (interne communicatie). Centraal staat een projektbestand, waarin op eenduidige wijze gegevens van een project zijn opgeslagen, volgens het principe van het produktmodel. Het model definieert de opslagstruktuur op de gegevensdrager. De gegevens kunnen door de verschillende participanten worden gebruikt en bewerkt, waama de resultaten weer in het projektbestand worden geplaatst. Resultaten

nus.

Het DUS boek bevat een afsprakenstelsel over de struktuur van de informatie. De gegevens struktuur wordt vastgelegd met behuJp van: • •

produkttype modellen en aspekttype modellen die samen een gebouwmodel opleveren; ondersteunende software.

De struktuur van het produkttype model biedt de mogelijkheid om via eigenschappen relaties te leggen tussen produkten (objekten). Eigenschappen kunnen topologisch enlof geometrisch van karakter zijn. 'AIle in een bouwwerk voorkomende produkten leiden tot het 'alles omvattende' gebouwmodel (het produkt is in dit geval het gebouw met zijn installaties).' De verschillende disciplines communiceren met een projektdatabank, welke is gebaseerd op een uniform produkUype model. Het produkttype model wordt gegenereerd vanuit bouwkundige ontwerptekeningen en bevat zowel geometrische gegevens als niet-geometrische gegevens. Vervolgens kan het produkttype model door aIle deelnemers worden gebruikt voor het inlezen van projektgegevens Lb.v. bestaande rekenprograrnma's.

27


4.2.1

BIT Notes

Applicaties.

DUS richt zich op de uitwisseling van gegevens tussen verschillende applicaties. Deze applicaties zijn ingedeeld in verschillende categorieen, merin worden de volgende onderscheiden: a) b) c) d) e)

Kwaliteitsbepalende programma's beoordeling van ruimte of bouwdeel, bv. op energiegebruik; Kapaciteitsbepalende programma's uitvoer: kapaciteit van installatie-onderdelen; Dimensionerende programma's uitvoer: afmetingen van onderdelen; Koordinatie-programma's ten behoeve van ruimtelijke koordinatie tussen verschillende disciplines; Hoeveelheidsstaten-programma's voor opzetten van raming, begroting of bestek.

Deze applicaties maken met name gebruik van geometrische en topologische data en wisselen onderling data uit. V ABI/DUS beoogt richtlijnen te verstrekken voor het leveren van interfaces door applicatie-Ieveranciers. met als belangrijkste voordeel dat slechts een interface hoeft te worden ontwikkeld en onderhouden per appIicatie.

4.2.2

Definities en uitgangspunten.

In het project wordt onderscheid gemaakt tussen: • • • •

gegevens: zonder betekenis informatie: gegevens in een context, dus met betekenis beslissingen: sturend ten opzichte van processen, op basis van informatie en kennis kennis: opgeslagen informatie voorzien van extra ordening

Het begrip data-uitwisselingssysteem wordt in V ABI/DUS nader toegelicht door te steJlen dat data moel worden gelezen als produktmodel. In VABI/DUS worden de volgende definities gehanteerd voor produktmodel en detailmodel. 'Een produktmodel is een methodische beschrijving van gegevens waardoor het rnogelijk is om deze gegevens als informatie te beschouwen. Produktmodellen zijn opgebouwd uit een verzameling van entiteiten, attributen en relaties.' 'Een detailmodel is een verzameling produktmodellen die onderling sterk samenhangen' (bv. van een bepaalde participant). Uitgangspunten bij het opstellen van de produktmodeUen: • • •

modulariteit tussen produkten detailmodellen; modulariteit ten opzichte van 'beschouwingsnivo's'; ordening op meta-data niveau, in plaats van produktniveau.

Informatiestromen. Door middel van modulariteit kan bereikt worden dat een applicatie aileen wijzigingen kan uitvoeren op de gegevens waarvoor deze bevoegdheden heeft. Een willekeurige applicatie heeft te maken met drie informatiestromen: - inkomend - intern - uitgaand Inkomende informatie wordt aangevuld met resultaten uit de applicatie. Vervolgens wordt in principe aIleen die informatie afgeJeverd, waarvoor de applicatie verantwoordelijk is.

28


4.2.3

BIT Notes

Technieken en toepassing.

In het DUS boek wordt gebruik gemaakt van de modelleringstechnieken IDEF-D, IDEF-IX en NIAM voor het beschrijven van de processen en data-modellen. Het uitwisselingssysteem zelf maakt gebruik van Express en STEP voor het vastleggen van het produkttype model en de instantiering daarvan, het produktmodel.

Toepassing. Ter illustratie van de toepassing van DUS in de verschillende disciplines worden in het DUS boek schema's gegeven waarin de betreffende discipline centraal staat en de communicatiestromen met de overige disciplines worden aangegeven. Beschreven wordt welke informatie voor de verschillende disciplines van belang is en welke informatie wordt gecommuniceerd. Voor de architekt is het van belang om de samenhang van beslissingen en keuzes te kunnen evalueren. Daarvoor moet het bouwkundig model vanuit verschillende invalshoeken informatie kunnen verschaffen, welke kan worden aangeleverd via DUS. Hiervoor moet DUS een classificatie volgens de elementenmethode ondersteunen. Het bouwkundig ontwerp is het uitgangspunt voor de konstrukteur voor het maken van een konstruktief on twerp. Hiervoor wordt informatie als vorm, afmeting en materiaal uitgewisseld, door het gebruik van het bouwkundig ontwerp als onderlegger. In de communicatie met de installatie-adviseurs wordt met name informatie over sparingen, belastingen en afmetingen van konstrukties uitgewisseld. Installatietechnische adviseurs krijgen met behulp van DUS bouwkundige, topologische en geometrische informatie aangeleverd van de architect. Deze informatie omvat bijvoorbeeld afmetingen van ruimten en wanden en de opbouw van wanden. Van de konstrukteur ontvangt de installatietechnisch adviseur informatie met betrekking op de functie van de constructie (dragend of niet-dragend). Naar de installateur toe wordt geometrische en specificerende informatie uitgewisseld. De installateur, tot slot, krijgt van de hiervoor genoemde partijen geometrische informatie aangeleverd en informatie welke de specificaties omtrent de installatie bevat.

4.2.4

STEP en Express binnen VABIIDUS.

Binnen V ABIIDUS is een implementatie van STEP en Express toegepast met een aantal specifieke uitbreidingen. Zo zijn een aantal standaard header entities gedefinieerd, en een aantal structured data types. Tevens zijn echter een aantal beperkingen aangebracht, zoals de beperking tot het gebruik van slechts drie simple data types (integer, real en string). Een aantal faciliteiten van STEP zijn niet ge"implementeerd, zoals het gebruik van embedded entities. Verder zijn in Express een (zeer) beperkt aantal keywords toegestaan en wordt het gebruik van operatoren en constanten (nog) niet ondersteund. het Subset-mechanisme. Voor de communicatie tussen applicaties is in V ABIIDUS een Express model opgezet. Hierbij wordt een zogenaamd subset-mechanisme voorgesteld, hetgeen inhoudt dat een relevant deel van het Express model wordt gebruikt voor de verschillende applicaties. Dit subset-mechanisme is in de V ABIIDUS software ingebouwd. In een speciale file (subset-file) wordt aangegeven welke entiteit-definities uit de centrale expressfile door een bepaalde applicatie moeten worden gelezen voor het interpreteren van de STEP files.

4.2.5

Functionele specificatie van DUS.

De beschrijving van het data-uitwisseJingsproces wordt gegeven met behulp van een uitwisselings-model en een interface-model. Het opzetten van de gegevensstrukturen is gedaan zoals in het BIM, namelijk door het specificeren van een meta-datamodel, waaraan aIle specifieke gegevensmodellen moeten voldoen. Het GARM (General ABC Reference Model) is aanknopingspunt geweest. Uitgangspunt zijn produktmodellen welke modulair van opzet zijn, zodat compositie en decompositie van produkten mogelijk is. Voor het beheer van de uitgewisselde informatie en het informatie-proces is een beheermodel opgezet, waarmee consistentie van informatie kan worden gewaarborgd.

29


BIT Noles

Het programma van eisen voor DUS, Het programma van eisen voor DUS bestaat uit de volgende onderdelen: • • • • • • • • • • • •

uitwisseling van gegevens tussen participanten; aan de hand van beschikbare applicaties wordt bepaald welke gegevens uitgewisseld worden. Applicaties die onder MS-DOS draaien moeten door interfaces kunnen worden gekoppeld; uitwisseling start bij de aanwezigheid van een ruimtelijk ontwerp; waar mogelijk worden de gegevensstrukturen geconformeerd aan BIM enlof GARM; gebruik maken van STEP en Express; decompositie van het produkt (bijv. opdelen in verdiepingen); basis voor produkt modellering is 3D B-rep (volumes. vlakken, lijnen en punten) maar ook 2D of minder. de projektgegevens worden opgeslagen in een of meerdere projektbestanden welke centraal of decentraal kunnen worden beheerd, afhankelijk van de projektorganisatie; eenvoudige struktuur van het projektbestand, mogelijkheid tot opdelen; participanten hebben aile rechten voor eigen entiteiten, kunnen andere entiteiten lezen en attributen daaraan toevoegen, waarvan zij eigenaar zijn; een C-Iibrary voor interface-ontwikkeling wordt ontwikkeld voor lees en schrijf routines van STEP-files; op korte tennijn inzet bij het ontwerpproces tussen architekt, constructeur en adviseur E+W.

Het uitwisselingsproces, De interne datastructuur van een applicatie moet kunnen worden afgebeeld op de DUS struktuur. Hiervoor wordt in de functionele specificatie van DUS een beschrijving gegeven van het uitwisselingsproces, waarvan het ontwerpproces onderdeel uitmaakt. Voor DUS zijn de volgende process en van belang: • • • •

lever data definitie (actie van de DUS-werkgroep); ontvang object definitie; ontwerpproces; verzend ontwerp.

De gegevensstromen die hierbij horen zijn: • • •

data definitie: de fonnele specificatie van de DUS struktuur in Express, definitie van data in interfaceprogrammatuur en eenduidige beschrijving van gegevens voor de participanten; object definitie: de definitie van het object, gebaseerd op de data definitie; ontwerp: functionele specificaties + technische specificaties + materiaal specificaties.

De data definitie vonnt in feite de kern van DUS, welke wordt bepaald en onderhouden door een samenwerkingsverband van participanten in het bouwproces, software leveranciers en de DUS-werkgroep.

Het interfacemodel. Hier wordt de interface beschreven welke kan worden gebruikt voor het uitwisselen van data via een STEP file. De processen die hier een rol spelen zijn: • • • •

het converteren van applicatie data naar de DUS interne data buffer en terug; het onderhouden van een tijdeJijke opslag in een relationele database; het controleren van de data aan de hand van de data definitie (Express); het schrijven en lezen van een STEP fysieke file.

30

TUEI Building Infonnation Technology

4.2.6

BIT Notes

Het meta datamodel.

Het meta datamodel beschrijft de opbouw van de onderdelen van de modellen die in V ABIIDUS worden gedefinieerd.

Entiteiten. Entiteiten zijn in DUS onderverdeeld in de klassen object en aspekt, waarbij een object overeenkomt met een voorkomen van een bepaald produkt binnen het gehele project en een aspekt een groepering van eigenschappen is die een bepaald aspekt van een object beschrijven. Objekten kunnen zijn: materiaal, bouwdeel of ruimtedeel. Aspecten zijn onder te verdelen in functionele specificaties (functie, randvoorwaarden. eisen, wensen, etc.) en technische specificaties (bv. fabrikaat, type-aanduiding).

Geometrie. Gestreefd wordt naar een 3D geometrie, tot op heden uitgewerkt in een B-rep overeenkomend met GARM: volume, vlak, lijn, punt en de hierarchische relaties hiertussen. Deze entiteiten worden gelntegreerd in het gegevensmodel door sUbtypen af te leiden, by. ruimte, wand, hoeklijn, hoekpunt.

Relaties. In het gegevensmodel worden drie klassen van relaties onderscheiden: - object-object (t.b.v. topologie: ligUn, grensCaan, bestaacuit); - object-aspekt (t.b.v. beschrijving van eigenschappen van objekten); - object-geometrie (t.b.v. geometrische beschrijving van objekten).

Object- en aspekt-geometrie relaties. 'De geometrische beschrijving van het aspekt is een project onafhankeJijke geometrische omschrijving van het produkt. De globale variabelen om het produkt in het bouwwerk vast te leggen worden bij het object ingevuld via de object~eometrie relatie. Het object refereert aan het aspekt. (... ) Het aspekt wordt beschreven in een eigen assenstelsel, terwijl het object wordt geplaatst in de reele wereld.' vb.: een kolom aspekt: een vlak (de doorsnede) object: een lijn (de verticale as) In het model staat dan: 1 constructie-aspekt: 1 vlak, 4 Iijnen, 4 punten 1 object: 1 lijn, 2 punten D.m. v. een transformatiematrix wordt het vlak van het aspekt geplaatst in de reele wereld. Het produkt is de optelsom van het aspekt en het object. Het produkt wordt dan voorgesteld door een volume. Detailmodel en subset Een detail model is een formele beschrijving van een verzameling produktmodellen, en bevat entiteit-en attribuutdefinities. Een entiteitdefinitie beschrijft de naam, type, attributen en relaties van een entiteit. Een attribuutdefinitie beschrijft de naam en type eigenschap van een attribuut. Een subset is een deelverzameling van een aantal data-definities en geeft een opsomming van de entiteiten en attributen die bij een bepaalde applicatie worden gebruikt, en bevat verwijzingen naar entiteiten attribuutdefinities.

31


BIT Notes

Bet beheennodel. In VABIJDUS is een beheennodel opgenomen dat de volgende onderdelen bevat. werkgebied Een groepering van entiteitsvoorkomens uit meerdere produktmodellen. basis Een set gegevens, zoals eigenaar, versie en status, die voor een verzameling entiteiten geldt. participant De eigenaar van een entiteit of attribuut, een entiteit kan meerdere eigenaars hebben, een attribuutwaarde slechts een. gebaseerd_op Koppeling van gegevens aan een werkgebied of basis. Het data- en projektbeheer model is verwerkt in de andere modellen. Elk van de andere modellen bevat de entiteiten uit het beheennodel.

4.2.7

Aspekt-type modeUen.

In V ABIJDUS zijn aspekt-type modellen opgesteld, hetgeen inhoudt dat voor verschillende aspecten van het ontwerp-proces, ten aanzien van data uitwisseling, entiteiten en attributen zijn gedefinieerd. Deze afspraak dient door de participanten in het proces te worden gehanteerd, dat wi! zeggen dat het de basis is voor uitwisselings-applicaties. De interne gegevens-struktuur van applicaties moet de aspekt-type modellen kunnen vullen en de applicatie moet de aspekt-type modellen kunnen lezen en vertaIen naar de interne struktuur (m.b.v. de interface-programma's). Er zijn door VABIJDUS 4 aspekt-type modellen opgesteld, namelijk voor: • • • •

4.2.8

data-en projektbeheer bouwfysika distributie bestek

Samenvatting.

V ABIJDUS biedt binnen de standaard, welke is beschreven door ISO-STEP en Express, een stelsel van afspraken omtrent de gegevens struktuur voor de bouwen installatie-techniek. Hiennee wordt invulling gegeven aan de behoefte die er bestaat om met behulp van de genoemde methodieken STEP en Express produktmodellen te kunnen hanteren welke kunnen worden gecommuniceerd tussen participanten in het bouwproces. Binnen dezelfde methodieken is tevens een model opgezet voor het beheer van gegevens, verantwoordelijkheden en versies van gegevens. Ten behoeve van de toepassing van deze afspraken is ondersteunende software ontwikkeld voor de ontwikkeling van interfaces voor applicaties in het bouwproces.

32

ruE I Building Information Technology

4.3

BIT Notes

Analyse recente gebouw-produktmodellen.

Bij het modelleren van gebouwen gaan we ervan uit dat er twee manieren zijn om naar een gebouw te kijken. De ene manier is door naar een gebouw te kijken als een samenstelling van verschillende mimten, de niet fysieke delen van een gebouw zoals kantoorruimte. entree, vergaderruimte, etc. De andere manier is door naar gebouwen te kijken als bestaande uit gebouwelementen, de fysieke delen van een gebouw zoals wanden, vlooren, ramen, etc. In het BBB-model voor kostenberekeningen wordt hoofdzakelijk uitgegaan van gebouwelementen als kostendragers, terwijl het V ABIIDUS model haar berekeningen baseert op een indeling in mimten met eigenschappen als gewenste mimtetemperatuur, volume, aantal aanwezige personen. We concIuderen dat beide manieren niet los van elkaar te beschouwen zijn. Ruimten worden nu eenmaal gevormd door gebouwelementen, zoals scheidingsconstructies. Daarom zou een produktmodel opgesteld mooten worden, waarbij beide manieren om naar een gebouw te kijken gelntegreerd zijn in een model. Inmiddels zijn er een aantal produktmodellen tot stand gekomen. De tot stand gekomen produktmodellen verschillen van elkaar in niveau en aandachtsgebied. In dit hoofdstuk worden een aantal produktmodellen beschouwd die in het bijzonder van belang zijn in het kader van het NOBIIBM-onderzoek. Zij hebben namelijk gemeenschappelijk dat zij uitgaan van een benadering waarbij de entiteittypen 'mimten' en 'elementen' gelntegreerd zijn in een model.

4.3.1

Het VTT-RATAS model.

Het RATAS-model biedt een algemeen kader dat de abstracte hierarchie (gebouw, systeem, subsysteem, deel, detail), kenmerkend voor een gebouwproduktmodel, beschrijft. Dit model maakt een onderscheid naar twee typen relaties die tussen objecten kunnen voorkomen. Enerzijds de 'part-of relaties, anderzijds de zogenaamde 'connected-to' relaties. Het model werd in 1987 gezien als zijnde toonaangevend en richtingbepalend voor verdere ontwikkelingen, maar was niet voldoende gedetailleerd uitgewerkt om te dienen als basis voor commerciele toepassingen. In de jaren die daarop volgden zijn in het 'Technical Research Center of Finland' een aantal prototypes ontwikkeld. Deze prototypes maakten allen gebruik van verschiLlende combinaties van relationele databases, hypermedia en CAD-systemen, met als uiteindelijke bedoeling om de benadering voorgesteld in het model uit 1987 in de praktijk te testen. Tijdens het ontwikkelen van deze prototypes werden, noodzakelijkerwijs, meer gedetailleerde object-klassen en relatie-typen gedefinieerd. Twee prototypes zijn belangrijk in het kader Van dit verhaal. Bij de ontwikkeling van deze prototypes werd gebruik gemaakt van een hypermedia-programma voor de bouw van de user-interface en een re!ationele database voor de eigenlijke data-opslag. Vervolgens werd daaraan een CAD-systeem toegevoegd met behulp waarvan de getekende informatie beheerd werd. Het conceptuele model is gemodelleerd in Express-G, zie figuur 4.3.1. We vinden hier een aantal hoofdentiteiten terug. De entiteit 'opening' is een supertype van de entiteiten 'raam' en 'deur', die op hun beurt beiden supertypes zijn van binnengelegen- en buitengelegen ramen en deuren. Een ruimte wordt afgebakend door een of meerdere 'surfaces'. Deze entiteit 'surface' kan ofweI een 'floor surface', of een 'ceiling surface' of een 'wall surface' zijn. Zo'n 'surface' zit op een 'component'. Met deze entiteiten 'room', 'opening', 'surface' en 'component' kan het model in abstractie beschreven worden. In een prototype tenslotte werd ook geometrische informatie vastgelegd. Elk object werd vastgelegd middels een x-, y- en een z-coordinaat. De vorm van de verschillende componenten werd vastgelegd in de beschrijving van verschillende typen objecten. De geometrische beschrijving had niet tot doe! voldoende informatie te verschaffen voor een foutloze 3-dimensionale modellering, maar bevatte de meest noodzakelijke kwantitatieve gegevens van verschillende componenten voor de tooleverende industrie.

33

TUE I Building Tnfonnation Technology

I t

Floor

o,

Aparonenl

anOi

partoi

BIT Notes

has SII:'!I

9

~~-R-oo-m--~~I----surface of a room S[I:'I Finish

Facade

Slab field

Figuur 4.3.1

4.3.2

Het VTT RATAS model

Het model van de 'Groupe Structuration de Donnees' (GSD).

In de periode 1985-1990 zijn in Frankrijk door verschillende onderzoeksgroepen een aantal conceptuele gebouwmodellen ontwikkeld. Deze verschillende projecten werden van overheidswege gesteund in het kader van het onderzoeksprogramma IN.PRO.BAT (Informatique et Productique Batiment). De modellen zijn met behulp van 'proto typing' ontwikkeld en zijn tot op verschillende niveaus en op verschillende manieren uitgewerkt. Voortkomend uit de behoefte naar nationale en internationale standaardisatie op dit gebied werden een aantal deelnemende onderzoekers aan deze verschillende projecten benaderd om een gezamenlijk conceptueel model, op basis van de reeds bestaande modellen, te ontwikkelen. De resultaten van dit GSD-werk zijn vastgelegd in NIAM-schema's die opgesplitst zijn in categorieen. De referentieschema's bevatten de hoofdzaken van het synthese-model. Een aantal entiteiten uit de referentie-schema's worden verder gespecialiseerd in zogenaamde 'specialisatie-bomen'. In figuur 4.3.2 zijn de voor deze vergelijking interessante data-structuren weergegeven. Deze data-structuren zijn hoofdzakelijk afkomstig uit de referentie-schema's. De hoofdentiteit is een 'project object'. Dit 'project object' is ofwei een 'space' of een 'element'. De relatie tussen een 'space' en een 'element' wordt gelegd middels de entiteit 'included element'. Een 'space' bevat nul of meerdere 'included elements'. Een belangrijke functie van een 'element' is de scheidende functie. Deze wordt weergegeven door de entiteit 'separator'. Deze 'separator' is ofweI een ornhullend element, een 'enclosure' ofwei een openingselement, een 'opening'.

34

BIT Notes

TUE I Building InConnation Technology

Geometrische aspecten worden eigenlijk nauwelijks behandeld in het GSD-model. Op een zeer algemeen niveau kan elk object een geometrische beschrijving bevatten, weergegeven door een 'boundary representation'. De GSD-groep bepleit het gebruik van STEP voor het vastieggen van geometrische data-structuren. Kenmerkend voor het model is de modellering van architectonisch belangrijke topologische relaties tussen verschilIende objecten.

is ojerced flY Sfl:'l

Figuur 4.3.2

Het GSD model

35


4.3.3

BIT Notes

Ret model 'De Waard' (DWR).

Het door De Waard ontwikkelde 'produkttype-model voor woningen en woongebouwen' is ontwikkeld met als doel om een bepaald gebouwontwerp met behulp van de computer te toetsen aan de geldende bouwvoorschriften. De Waard ontwikkelde zijn conceptuele gebouwmodel voor woningen als een zogenaamd 'multi-layered' model, waardoor hij kon voortbouwen op het reeds gedane onderzoekswerk in deze richting door TNO. De basis van het model wordt gevormd door een fundamenteel datamodel, opgebouwd volgens data-structuren zoals die in Express gebruikt kunnen worden. De tweede laag wordt gevormd door het wei bekende General AEC Reference Model (GARM). De derde laag tens lotte bevat de entiteiten die voorkomen in het produkt-type-model voor woongebouwen. In zijn proefschrift maakt De Waard gebruik van NIAM en Express, met behulp waarvan hij zowel een gebouw-kern-model a1s een meer specifiek gebouw-model toegespitst op woonhuizen definieert. Daarnaast maakt hij gebruik van Express om de entiteiten en beperkingen mals die zijn vastgelegd in het bouwbesluit te definieren. Vervolgens is, op basis van deze twee conceptuele gebouwmodellen, prototype-software ontwikkeld die het mogelijk maakt om een ontwerp te toetsen aan de geldende bouwvoorschriften.

consisl5 of S[O:?]

consists of SIO:?) is bounded by SIO:?]

Opening

Figuur 4.3.3

Het DWH model

In figuur 4.3.3 wordt een sterk vereenvoudigd schema getoond van het model zoals dat door De Waard is ontwikkeld. Het is een gedeelte van het gebouw-kern-model, waarbij het GARM-concept van de 'functionele eenheden' en de 'technische oplossing' is uitgefilterd. In het eigenlijke model heeft De Waard een zeer uitgebreide abstracte hierarchie voor 'ruimten', 'ruimtebegrenzingen' en 'scheidingsstructuren' opgezet. Voorbeelden van verschillende ruimtelijke entiteiten zoals die door De Waard gebruikt worden zijn: 'building block space', 'building floor space', 'house space', 'house floor space' en 'private elementary space'. Deze decompositie is afgeleid van de typische organisatie van een meer verdiepingen tellend appartementen complex. Het abstractie mechanisme voor ruimte-scheidingen Iijkt sterk op dat van de ruimten, zoals hierboven in een voorbeeld is aangehaald. Zo zijn er ruimte begrenzende entiteiten op elk van de bovengenoemde niveaus:

36


BIT Notes

'building floor space boundary" 'house space boundary', 'house floor space boundary' en 'elementary space boundary'. Scheidingsstructuren worden in het model onderverdeeld in 'inner-' of 'outer separation structures' en verder voor 'inner separation structures' in 'perceel-' of gewoon 'ruimtescheidende structuren'. Verder kunnen ze worden opgedeeld in horizontale-, vertic ale- en veranderlijke scheidingsstructuren. In de meer gedetailleerde beschrijving van het model vinden we elementen terug uit de in het RATAS-project gedefinieerde prototypes. Om hiervan een voorbeeld te geven: Openingen kunnen worden gedecomponeerd in 'binnengelegen deuropeningen', 'binnengelegen raamopeningen', 'buitengelegen deuropeningen' en 'buitengelegen raamopeningen'. Het model bevat daarnaast een algemene beschrijving van het 'dragende systeem' van een gebouw. middels de beschrijving van balken kolom-entiteiten. De geometrische beschrijving van entiteiten geschied door de entiteiten uit het gebouwmodel te associeren met volume, face, edge en vertex-entities in een zogenaamde 'extended relational reference representation'. Het gebouwmodel kan echter los van zijn vorm representatie bekeken worden.

4.3.4

Bet CombineJIDM model.

Het COMBINE project is een internationaal project dat gefinancierd wordt door het EC Joule research programma. Vijftien organisaties, afkomstig uit acht landen, participeren in dit project. De hoofddoelstelling van COMBINE is om aan te tonen dat het mogelijk is om, gebruik makend van de produktmodel benadering. verschillende energetische ontwerp-evaluatietechnieken met elkaar en in combinatie met CAD-systemen te integreren. Voor dit doel is een produkt-data-model, het zogenaamde 'Integrated Data Model' (IDM) ontwikkeld. Met behulp van dit datarnodel kan de input en output van res verschillende ontwerpen analyseprogramma's worden gedefinieerd. In aansluiting op dit onderzoek worden specifieke interfaces tussen deze programma's en een centrale database ontwikkeld. Voor de implementatie van deze centrale data-opslag zal gebruik worden gemaakt van MIPS-software dat is ontwikkeld door het Franse onderzoeksinstituut CSTB. De huidige versie van het IDM is vastgelegd in de vorm van NIAM-diagrammen. een data-dictionary en gedeeJtelijk als Express-file. Het IDM is een omvangrijk naslagwerk geworden. In zijn huidige omvang bevat het meer dan 400 definities van verschillende entiteiten. Het merendeel hiervan zijn echter entiteiten die specifiek iets te maken hebben met de energiehuishouding en met de installatietechniek. In figuur 4.3.4. zien we de uitgeklede versie, waarin aileen die entiteiten voorkomen die een directe relatie hebben met het modelleren van ruimten en scheidingsstructuren. Voor de geometrische representatie maakt het IDM gebruik van STEP entiteiten. Zo worden bijvoorbeeld entiteiten als 'face' en 'closed shell' gefmporteerd uit STEP. De reden hiervoor is dat er in de nabije toekomst een integratie van de resultaten van het COMBINE-project met de door STEP gedefinieerde standaard wordt voorzien. De entiteiten die nu reeds STEP-compatible zijn worden in de figuur gemarkeerd middels de letters 'STEP' in de rechteronderhoek.

37


BIT Noles

Storey

is deiimited by Space geometry

Sbell

is composed of

has

has box domain

is composed of

~ Figuur 4.3.4

Het IDM model

38


4.4

BIT Notes

Het synthese-model van Bjork.

De vier modellen zoals hiervoor beschreven worden kort door Bjork bediscussieerd, waarna hij tot een synthese komt in een door hem opgesteld model. Het gebouw wordt door hem beschreven als een netwerk van ruimten, gescheiden door gebouw elementen. Dit betekent dat op macro-niveau entiteiten zoals het gehele gebouw niet in de beschouwing worden meegenomen. Ook de entiteiten die behoren tot de draagstructuur of elektrische systemen, etc. worden buiten beschouwing gelaten. Bij het modelleren van de omsluitende structuren worden bewust bepaalde sub-typen die misschien nodig zouden zijn voor de beschrijving van dakenloffunderings-constructies weggelaten. Op micro-niveau beperkt hij zich tot de identificatie van die entiteiten die men daadwerkelijk in het gebouw kan herkennen. Deze modellen worden bediscussieerd door ze achtereenvolgens vanuit verschillende invalshoeken te bekijken. Deze invalshoeken zijn achtereenvolgens: 1. 2. 3. 4. 5.

ruimten ruimtebegrenzingen omsluitende entiteiten gaten, deuren en ramen vorm en locatie

Vanuit deze verschillende invalshoeken worden de verschillende delen zoals we die uiteindelijk terugvinden in het synthese-model opgebouwd. Eerst voigt dus een beschrijving van de verschillende delen zoals we die in een uiteindelijk model terug zouden moeten vinden. AIle bij dit hoofdstuk behorende figuren zijn tenzij anders aangegeven gemaakt in EXPRESS-G.

4.4.1

Ruimten.

Zowel de uiteindelijke gebruiker van het gebouw alsmede de architect die het gebouw ontwerpt kijken naar het gebouw als een samenstel van ruimten. We herkennen twee elkaar aanvullende beschrijvingen van het begrip ruimte. De eerste manier om een ruimte te beschrijven gaat uit van een complete beschrijving van de fysieke scheiding tussen twee ruimten, die wordt gevormd door fysieke objecten die verantwoordelijk zijn voor de (visuele, akoestische, klimatologische en andere vormen van) beleving van zo'n ruimte. De tweede manier om een ruimte te beschrijven gaat uit van het begrip ruimte als een plaats waar gelijksoortige activiteiten plaatsvinden. Dergelijke functionele ruimten vragen vaak, ondanks het feit dat ze onderdeel uitrnaken van een grotere omsloten ruimte, om een speciale wandafwerking of om speciale inrichtingselementen. We kunnen stellen dat het functionele ruimtebegrip met name belangrijk is voor architecten in de vroege ontwerpfasen. Van de eerder beschreven modellen herkennen zowel het RATAS-model als het GSD-model aIleen de ruimten die totaal worden begrensd door fysieke afscheidingen en zij staan niet toe dat een ruimte wordt gedecomponeerd in meerdere kleine ruimten. Het DWH-model en het IDM-model staan de onderverdeling van ruimten in meerdere sub-ruimten weI toe. In het DWH-kernmodel wordt daartoe dezelfde entiteit 'space' recursief gebruikt. In het meer uitgebreide DWH-model is de entiteit 'space' gespecialiseerd, waarbij we in een abstracte hierarchie entiteiten als 'house space', 'house floor space', 'elementary space' en 'internal space' tegenkomen. Deze entiteiten worden gebruikt voor een decompositie. Het IDM-model maakt gebruik van een aparte 'zone'-entiteit voor de decompositie van ruimten. Een 'zone' in het IDM-model kan echter zowel een gedeelte van een bepaalde ruimte zijn als ook een samenstel van meerdere ruimten. Een generiek model moet de mogelijkheid bieden om zowel fysiek omsloten ruimten alsook de niet fysiek omsloten, functioneel bepaalde ruimten, te kunnen definieren. Tevens moet het model de mogelijkheid bieden om op entiteit-niveau een duidelijk onderscheid te kunnen maken tussen enerzijds gedeelten van omsloten ruimten en anderzijds een samenstel van meerdere ruimten (bijv. appartementen, zones met gelijke temperatuur, etc.). Dit onderscheid moet gemaakt kunnen worden omdat er verschillende datastructuren nodig zijn voor deze twee vormen van het begrip ruimte.

4.4.2

Ruimtebegrenzingen.

Uitgangspunt is dat elke ruimte wordt omsloten door een omhulsel dat bestaat uit wanden, een vloer, een plafond en een aantal gaten die kunnen worden gevuld door ramen en deuren. Dit omhulsel zorgt ervoor dat we de ruimte (visueel, akoestisch, klimatologisch en op andere manieren) als ren ruimte beleven. De verschillende delen van dit omhulsel hebben een andere oppervlaktestructuur. De fysieke scheidingsstructuren (wanden, vloeren) die dit omhulsel vormen kunnen meerdere ruimten begrenzen. De zichtbare oppervlaktestructuren corresponderen exact met de binnen afmetingen van de ruimten die door het omhulsel worden begrenst De

39

TUE J Building lnfonnation Technology

BIT Notes

tenn 'ruimtebegrenzing' (space boundary) wordt gebruikt om de verschillende gedeelten van het omhulsel te beschrijven. In het 10M-model worden ruimtebegrenzingen en hun bijbehorende materiaal-eigenschappen gemodelleerd door gebruik te maken van een entiteit 'sub-face'. Er wordt hierbij slechts een sub-face gerelateerd aan de unieke combinatie van een ruimte en een wand. In het RATAS-model wordt de entiteit 'surface' gedefinieerd als zijnde een aaneengesloten oppervlak op dezelfde wand, waar bovendien een zelfde afwerkingsmateriaal wordt toegepast. Een en dezelfde wand in een gegeven ruimte kan dus meerdere 'surface'-entiteiten bevatten. Het DWH-model definieert niet duidelijk een entiteit 'afwerking'. De entiteiten 'surface' en 'face', zoals die respectievelijk worden gedefinieerd in het RATAS- en het IOMmodel bevatten niet direct een entiteit 'opening' met de daarbij behorende relaties met de ruimte. In het GSDmodel maken zowel'scheidende structuren' als 'openingen' deel uit van dezelfde superklasse 'separator'. In het DWH-model worden openingen opgevat als zijnde slechts onderdeel van scheidende structuren.

Space bOundary assembly consistS of S[ I:?} bounded by SrI:?] "'":- - - - - - , l J - - - - - - . , Space or subspace

I

contains swfaces Sf!:?]

Swiate tinish

L p bas finish

6 Swface

'-------'

Piguur 4.4.2

Abstracte hierarchie voor 'ruimte begrenzingen'

De entiteit 'ruimtebegrenzing' zoals die zou moeten worden opgenomen in het model is de unieke ruimtebegrenzing die hoort bij slechts een omsluitende structuur (wand, vloer) en een elementaire ruimte. Een doorsnee ruimte zou derhalve zes van dergelijke ruimtebegrenzingen hebben. maar dit aantal mag niet noodzakelijkerwijs beperkt zijn tot zes. Daamaast. zo stelt Bjork, is er een behoefte aan een hierarchische decompositie van de entiteit ruimtebegrenzing. Deze decompositie vinden we op een goede manier terug in het DWH-model. In het betreffende model kunnen we op verschillende ruimtelijke niveaus verschillende ruimte begrenzende entiteiten terugvinden. Wat echter in het DWH-model ontbreekt is een begrenzende entiteit die niet rechtstreeks aan een bepaalde ruimte is gekoppeld. maar een kleinere oppervlakte van eenzelfde materiaal beschrijft. Een dergelijke entiteit is namelijk geschikt voor het genereren van uittrekstaten, bestekken en/of onderhoudspJanningen. De ruimte begrenzende delen op een hoger abstractie-niveau kunnen worden gebruikt v~~r verschillende analyses, of v~~r het checken van prestatie-eisen en bouw-regelgeving en kunnen worden veralgemeniseerd in een entiteittype 'samenstel van ruimtebegrenzingen' (space boundary assembly). Het IDMmodel bevat ook een decompositie van ruimtebegrenzingen. en weI een decompositie in de volgende twee niveaus: 'faces' en 'sub-faces'. In een op te stellen model. zo concludeert Bjork. hebben we een decompositie hierarchie van de entiteit ruimtebegrenzing op drie niveaus nodig. We onderscheiden hierbij vlakjes met een gelijksoortig oppervlak. ruimtebegrenzingen tussen exact een omsluitende structuur en een ruimte. en een samenstel van ruimtebegrenzingen. Daarnaast is het noodzakelijk om een onderscheid te kunnen maken tussen fysieke ruimtebegrenzingen en imaginaire ruimtebegrenzingen. Deze laatste zijn nodig om sub-ruimtes af te bakenen. Deze abstractie hierarchie wordt weergegeven in figuur 4.4.2.

40

TUE J Building Information Technology

4.4.3

BIT Notes

Omsluitende entiteiten.

Fysieke omsluitende structuren zijn bijvoorbeeld van belang voor een constructeur. Maar ook andere actoren in het bouwproces hebben dergelijke entiteiten nodig om gegevens aan te kunnen koppelen. De hierarchische decompositie van omsluitende structuren is echter complexer dan de gelijksoortige decompositie van ruimten. Als we beginnen op een abstract niveau, kunnen we stellen dat een omsluitende structuur continue en homogeen in materiaalgebruik moet zijn. Daarnaast mag een omsluitende structuur geen grote uitstulpingen bevatten, omdat deze op zich weer als omsluitende structuur gezien kunnen worden. Of we te maken hebben met een, dan weI twee of meerdere omsluitende structuren zal ook liggen aan het feit of de structuur plaatselijk scherpe hoeken (vaak 90°) maakt. In het ontwerpstadium zal de architect vaak beginnen met het modelleren van de omsluitende structuren, die in hun ruimtelijke samenhang de verschillende ruimten waaruit het gebouw is opgebouwd vormen. Pas in latere fasen is het noodzakelijk om deze structuren te kunnen decomponeren in kleinere componenten. Het zou daarnaast voor zowel analyse- als ontwerpdoeleinden ook mogelijk moeten zijn om meerdere omsluitende structuren te aggregeren tot grotere entiteiten, zoals bijvoorbeeld de totale schil van een gebouw. Net als in het geval van de ruimten en ruimtebegrenzingen is er een dergelijke entiteit, genaamd 'samenstel van omsluitende structuren' (enclosing structure assembly) gemodelleerd. Meer specifieke voorbeelden van omsluitende structuren zijn wanden vloerstructuren. In het geval van buitenwanden zal een wand doorgaans meerdere verdiepingen bestrijken, in het geval van binnenwanden zal een wand echter meestal slechts een verdieping bestrijken.

Endosing entity consislS of SII:?]

lias sections S[O:"!}

cp bas swtaces [I:?I

lias components 51 I:?J

l..J.yer

lias layers S[ I :?J

I

Figuur 4.4.3

Abstracte hierarchie voor 'omsluitende structuren'

41


BIT Notes

De decompositie van deze omsluitende structuren kan in twee richtingen plaatsvinden. Enerzijds kunnen we een omsluitende structuur decomponeren in de richting loodrecht op de structuur, dit leidt tot het ontstaan van bepaalde 'lagen" waarbij iedere laag uit een ander materiaal is opgebouwd. Deze informatie is belangrijk voor bijvoorbeeld constructiedoeleinden of een energie-analyse. Ben dergelijke decompositie is bijvoorbeeld relevant voor bepaalde typen wand- of vloerconstructies, maar kan voor andere onderdelen van de omsluitende structuur weer minder relevant zijn. Anderzijds kunnen we een omsluitende structuur decomponeren in zijn eigen vlak. Deze decompositie kan plaats vinden op basis van de fysieke structuur (bijvoorbeeld in het geval van geprefabriceerde elementen) of op basis van het feit dat bepaalde secties van de structuur grenzen aan bepaalde ruimten. Om het model meer inzichtelijk te maken zijn in het model een aantal sub-types van het entiteittype 'component' weergegeven. We vinden hier bijvoorbeeld buitenmuurcomponenten en vloercomponenten. Een eventuele verdere detaillering zou bijvoorbeeld Ieiden tot entiteiten als 'sandwich-elementen'. daarnaast is de plaats weergegeven waar volgens Bjork entiteiten als balken en kolommen in het schema geplaatst moeten worden. In figuur 4.4.3 wordt de abstracte hierarchie voor omsluitende structuren weergegeven.

4.4.4

Gaten, deuren en ramen.

Omsluitende structuren kunnen doorbroken worden door openingen. Deze openingen maken de achterliggende ruimten toegankelijk voor mensen, zonlicht, lucht, etc.. Typische objecten die we vaak in dergelijke openingen tegenkomen zijn ramen, deuren en leidingen. Bjork concentreert zich hierbij alleen op de entiteiten wanden en ramen. Zowel het RATAS-model als het IDM- en GSD-model herkennen de directe relatie tussen deuren en ramen en de ruimten waar zij aan grenzen. Tegelijkertijd herkennen deze modellen de relatie tussen deuren en ramen en de structuren waar zij in geplaatst zijn. In het IDM-model is deze relatie indirect gemodelleerd middels de extra entiteit 'gat'. In het RATAS-en het GSD-model zit deze relatie direct ingebakken.

I

FormsS(I:?)

bas boles S[O:'!)

serves S(I :11

bas holes S{O:?1

Figuur 4.4.4

Schema voor 'openingen' en hun relaties met andere entiteiten

Het lijkt zinvol om in het model zowel de relatie met de omsluitende structuur alsook de relatie met de ruimte te modelleren. Het besef van een gat in een structuur, waar vervolgens bijvoorbeeld een raam, een deur of een lei ding in is geplaatst kan bijvoorbeeld zinvol zijn voor constructiedoeleinden of voor prefabricage. Omdat zowel deuren als ramen tot dezelfde categorie fysieke objecten als omsluitende entiteiten kunnen worden

42


BIT Notes

gerekend (ze bevatten materiaal en hebben een drie-dimensionale opbouw) is besloten ze als sub-type van de entiteit 'component' te modelleren. Het schema voor opening-componenten en hun relaties met andere entiteiten wordt weergegeven in figuur 4.4.4.

4.4.5

Geometrie.

In het door Bjork voorgestelde model wordt ervoor gekozen om aIle geometrische data buiten het model te houden. De noodzakelijke verbinding met een geometrische beschrijving kan op een algemeen niveau plaatsvinden. Ervanuitgaande dat aBe entiteiten in het voorgestelde schema sub-types zijn van een meer algemene entiteit die we weer kunnen geven met de naam 'gebouw beschrijvende entileit', kunnen we de geometrische beschrijving modelleren als een attribuut van de hierboven genoemde gebouw beschrijvende entiteit. Een en ander wordt weergegeven in figuur 4.4.5. De verschillende geometrische representaties zoals die zijn weergegeven in de figuur zijn slechts voorbeelden en zijn zeker geen uitputtende opsomrning van aIle mogelijke geometrische beschrijvingen. Het grote voordeel is dat je de gebruiker toe staat meerdere geometrische beschrijvingen te gebruiken voor dezelfde entiteit. Oit betekent dat we de geometrische beschrijving van een entiteit kunnen veranderen zonder daarbij de topologische of functionele relaties van entiteiten onderling te be'invloeden. Het is daarbij te hopen dat verschillende oplossingen voor de integratie van geometrische data in produktmodellen zullen worden gedefinieerd op een meer algemeen niveau in een STEP-standaard. Het model dat wordt weergegeven door Bjork is zodanig geconstrueerd dat het mogelijk is om deze te integreren met de oplossingen zoals die zijn gekozen binnen STEP.

Building desaiptio'1-"':';:;:=-~,-{JI entity

represenr.ation

Figuur 4.4.5

4.4.6

represenr.ation

Geometrical description

represenr.ation

represenr.ation

Basisprincipe voor het koppelen van geometrische informatie aan een entiteit

Integratie - het synthese model volgens Bjork - (5MB).

De in de voorgaande paragrafen gepresenteerde schema's betreffende ruimten, ruimtebegrenzingen, omsluitende entiteiten en gaten, deuren en ramen worden in deze paragraaf ge'integreerd in een schema. Oit schema wordt weergegeven in figuur 4.4. In een eerder geschreven artikel door Bjork, waarin hij een aantal algemene richtlijnen uiteenzet waaraan produktrnodellen moeten voldoen, is expliciet gewezen op het feit dat een produktmodel geen redundante informatie mag bevatten. De exacte betekenis van het begrip redundantie werd echter niet duidelijk weergegeven. In het bewuste artikel werd een voorbeeld aangehaald betreffende de vloeroppervlakte van een ruimte en de relatie hiervan met de begrenzende wanden van deze ruimte. Er werd gesteld dat het niet noodzakelijk is om de vloeroppervlakte van een ruimte als attribuut vast te leggen als we de locatie en de vorm van de ruimtebegrenzende wanden reeds hebben vastgelegd. In een dergelijk geval kunnen we de vloeroppervlakte namelijk impliciet afleiden. Er werden twee mogelijke oplossingen voorgesteld om dit probleem van redundantie op te lossen. De eerste oplossing ging ervan uit dat applicatie-programma's de kennis zouden moeten bevatten om de bewuste vloeroppervlakte af te kunnen leiden uit de beschikbare informatie. De tweede oplossing zou zijn om deze kennis in het model zelf te modelleren. Een belangrijk kenmerk van het 5MB-model zoals weergegeven in figuur 4.4.6 is dat het onmiskenbaar redundante informatie bevat, in de zin van het feit dat somrnige expliciet gemodelleerde informatie ook op een eenduidige wijze uit de overige beschikbare informatie afgeleid zou kunnen worden. Een zekere mate van redundantie is echter noodzakelijk. In veel gevallen zal een specifieke applicatie slechts een beperkt aantal entiteiten uit het schema gebruiken of zou bijvoorbeeld alleen behoefte hebben aan informatie die impliciet aanwezig is in het model en eerst afgeleid zal moeten worden. Maar omdat een aantal entiteiten en relaties die

43


BIT Notes

noodzakelijk zijn om de uiteindelijke gewenste informatie af te kunnen leiden niet door de applicatie gebruikt worden of gei'nterpreteerd kunnen worden zou de uit te wisselen informatie incompleet kunnen zijn. Het non-redundantie-principe behoeft enige opheldering. Naar aanleiding van een aantal recent uitgevoerde experimenten stell Bjork een interpretatie van het begrip redundantie voor. Het is niet de bedoeling om exact dezelfde informatie binnen een produktmodel redundant te modelleren in de vorm van verschillende entiteiten of attributen. Het data-model in EXPRESS, dat de vrije hypermedia-achtige relaties tussen verschillende data ondersteunt, helpt dergelijke vormen van redundantie te vermijden omdat de data die zijn gemodelleerd als een entiteit kunnen worden hergebruikt als data-type van een andere entiteit. Het gebruik maken van dit principe betekent echter niet dat informatie die is af te leiden uit andere informatie zondermeer weggelaten kan worden omdat vaak de informatie waarop de afleiding is gebaseerd ontbreekt in de database of in de transfer-file.

Space boundary assembly

Space ass.embl y

consists of SI I:?J

consists of 5[1::') bounded by S[I:?)

forms S(I:?)

has holes SI0:?1

has boles SiO:?)

consists of S[ I:?)

Hole

contains surfaces S[I:?)

fiUed by

Surface fmisb

oI

has finisb

bas surfaces [I:'?]

Figuur 4.4.6 : Het synthese model volgens Bjork (SMB model)

44


Deel B: 5

BIT Notes

Het NOBI Bouwkundig Model.

Uitgangspunten.

In tegenstelling tot het in het voorgaande hoofdstuk beschreven 5MB-model, zal het NOBI Bouwkundig Model (NOBIIBM) zowel op macro-niveau het gehele gebouw enlof gebouwdelen, alsook op micro-niveau installatietechnische aspecten in de beschouwing mee moeten nemen. Het synthese model van Bjork biedt voldoende houvast om dit samen met de modellen zoals die door de VABYDUS en door NOBIIBBB ontwikkeld zijn te gebruiken als uitgangspunt voor een op te stellen bouwkundig model. In het NOBIIBBB model wordt voornamelijk gewerkt met gebouwcomponenten. We hebben het hier over 'elementen', 'bouwdelen' en 'middelen'. De V ABI vraagt in haar applicaties daarentegen voornamelijk informatie die is gekoppeld aan het oegrip 'ruimte'. Juist in het synthesemodel van Bjork worden deze entiteittypen op een heldere manier in een gebouwmodel aan elkaar gerelateerd. Dit betekent echter zeker niet dat dit synthesemodel in de context van het NOB! Bouwkundig Model zomaar 'klakkeloos' kan worden overgenomen. Dat i~ dan ook niet gebeurd! Het synthesemodel van Bjork is uitgebreid bestudeerd en besproken. Zeker in de begripsdefinities zoals deze door Bjork zijn opgesteld hebben wij de nodige inconsequenties aangetroffen. Toch bood het model voldoende aanknopingspunten voor verder gebruik. Ben kritische bestudering van het model heeft geleid tot een interpretatie van dit model zoals wij dit zien. Deze interpretatie heeft samen met de interpretaties van het NOBIIBBB- en het VABYDUS-model ten grondslag gelegen aan het door ons opgestelde NOBIIBM.

5.1

Interpretatie van te gebruiken data-modellen.

Om deze drie bovengenoemde basismodellen te kunnen gebruiken zijn deze eerst zorgvuldig geabstraheerd. Zij zijn ontdaan van allerlei, voor dit doel, overbodige zaken en zijn teruggebracht tot de kern. Het betreft hier interpretaties van de modellen zoals wij die zien. Ben beschrijving van deze drie abstracties vinden we terug in de volgende drie paragrafen. Aile bij dit hoofdstuk behorende figuren zijn tenzij anders aangegeven gemaakt in EXPRESS-G.

5.1.1

Het NOBIIBBB model.

In het NOBIIBBB-modeI komen we een zeventaI belangrijke entiteiten tegen. Deze entiteiten, te weten: bouwwerk, gebouwdeel, ruimte, element, bouwdeel en midde! worden duidelijk gedefinieerd. In de laatste versie wordt een nieuw begrip geintroduceerd te weten aktiviteit (bewerking). Oit begrip is in deze versie van het BM-model niet meegenomen. Deze definities worden kort weergegeven. "Ben ruimte is een gebied, al dan niet fysiek beperkt door vloeren, muren en andere ruimtescheidende middelen. Een ruimte kan zich buiten het gebouw bevinden of binnen het gebouw. Zo'n interne ruimte kan zijn opgebouwd uit een of meerdere vertrekken of een deel van een vertrek". Voor de term element vinden we de volgende definitie: "Elementen zijn de voornaamste fysieke onderdelen en systemen van een gebouw, met een eigen specifieke locatie enlof functie. Elementen hebben een algemeen geldend karakter zonder dat wordt ingegaan op de specifieke technische oplossing, materialisatie of constructiemethode". Deze definitie is ontleend aan het document Classification of information in the construction industry (draft), ISO Technical Committee 59 SC13 WG2, augustus 1992. We komen dezelfde definitie ook in het ABI tegen. Er wordt uitgegaan van de elementen zoals deze worden benoemd in de elementenmethode '91. Voor de term bouwdeel wordt uitgegaan van de volgende definitie: "Een bouwdeel is een fysiek en gematerialiseerd onderdeel of systeem van een gebouw, dat beschouwd kan worden als een te onderscheiden kostendrager in het bouwvoorbereidingsproces. Een bouwdeel maakt onderdeel uit van een element Een bouwdeel onderscheidt zich van een element doordat een bouwdeel door de materialisatie een specifieke functie heeft in de begroting en bestek". Voor het entiteittype middel wordt de volgende definitie gegeven: "Middelen zijn de samenstellende delen van een bouwdeel, terugkomend in het bouwdeelrecept als aparte gedefinieerde en gecodeerde regel, eenheidsprijs en gegeven eenheid. Middelen zijn onder te verdelen naar materiaal, arbeid en materiaal". Voor een beschrijving in Niam van het NOBIIBBB-model wordt verwezen naar figuur 4.1. Ben gebouw is te decomponeren in ruimten en elementen, In die zin dat een gebouw een of meerdere ruimtes heeft en een of meerdere elementen bevat. Ben element is samengesteld uit bouwdelen en bevat dus altijd een of meerdere bouwdelen. Ben bouwdeel heeft eventueel een recept (bouwdeelrecept) waarin wordt aangegeven

45


BIT Notes

dat het betreffende bouwdeel een of meerdere middelen bevat. Een middel kan hierbij materiaal, arbeid of materieel zijn. De hierboven genoemde entiteiten fungeren als kostendmgend object. Een kostendragend object kan niet tegelijkertijd bijvoorbeeld een element en een mid del zijn. Daarmee is niet gezegd dat een begroting niet kan zijn opgebouwd uit bijvoorbeeld een combinatie van elementen, bouwdelen en ruimten, zolang elk onderdeel van het bouwproject maar benoemd wordt en er geen dubbeltellingen plaats vinden.

5.1.2

Ret VABIIDUS model.

Het VABIIDUS-model bevat vier modellen. Van deze modellen, detail modellen genaamd zijn in het kader van dit onderzoek twee modellen met name van belang. Het betreft hier het bouwfysisch-model en het distributiemodel. Het bouwfysisch model beschrijft bouwkundige entiteiten waarmee een installateur te maken krijgt. De belangrijkste entiteiten die er in voorkomen zijn ruimte, wand, deur en mam. Aan iedere entiteit in het model worden twee specificatie-entiteiten gekoppeld. Zo is er van iedere entiteit een functionele specificatie (FS) waarin de eisen staan geformuleerd waaraan de attributen van deze entiteit moeten voldoen. Daarnaast is er de technische specificatie (TS), welke voldoet aan de eisen gesteld door de functionele specificatie. In de V ABIIDUS-modellen zijn deze steeds als een drietal nauw verbonden objecten terug te vinden: Object, ObjectYS en ObjeccTS. Voor onze interpretatie van het model zijn de twee laatste verschijningsvormen voor de duidelijkheid weggelaten. In een volgende paragraaf: Attributen: gewenste en gerealiseerde waarde komen we hierop terug. gebouw

beetl S(I:?}

begrensd door S[I:?] beval S[I:?)

iaag

beschrijft

geomelrische beschrijving

Figuur 5.1.2: Intepretatie van het V ABIIDUS bouwfysisch model Een gebouw bestaat uit een of meerdere ruimten, die op hun beurt door een of meerdere wanden worden begrensd. Een wand kan hierbij ook een vloer of een plafond zijn. In het 'normale' geval van een recht-hoekige ruimte wordt deze dus begrensd door zes wanden. Zo'n wand kan vervolgens nul of meerdere openingselementen bevatten. Het entiteittype 'openingselement' is geen entiteit zoals die in het model voorkomt, maar maakt het model overzichtelijker. Een 'openingselement' is hier een supertype van de entiteiten 'raam' en 'deur' zoals die wei in het model voorkomen. Een en ander wordt weergegeven in figuur 5.1.2. We zien in de figuur dat zowel aan een 'wand' als aan een 'openingselement' een geometrische beschrijving wordt gekoppeld. Een wand heeft een gelaagde structuur en bevat een of meerdere lagen .. Het distributiemodel dekt het specifieke terrein van de installateur. Het is een vrijwel op zich zelf staand geheel en heeft via de verbindingen met wand, ruimte en project contact met de buitenwereld. Het model probeert op

46


BIT Notes

een zo algemeen mogelijke wijze distributiesystemen voor lucht, water en elektriciteit in een gebouw te beschrijven. Daarbij worden de begrippen 'node', 'flowpath' en 'part' gebruikt. Voor een overzicht van het VABUDUS model wordt verwezen naar de V ABI documentatie [lit.29]. Juist omdat het model een zo op zich zelf staand geheel is moet het niet in het op te stellen kern model worden opgenomen. Met de te beschrijven entiteit 'distributiesysteem' wordt een opening geboden naar het V ABUDUS-distributiemodel.

5.1.3

Het synthesemodel zoals opgesteld door Bjork.

Het door Bjork opgestelde synthese-model, kan op een abstracte manier worden weergegeven volgens het schema in figuur 5.1.3. De uitgebreide hoeveelheid entiteiten uit het 5MB-model is sterk gereduceerd om de hoofdstructuur weer te geven. Groepen van entiteiten zijn daarbij geclusterd en worden weergegeven met een verzamelnaarn.

vormt S(l:?] begrenzing

strnctuur

bevat S( l:?J

heett S[l:?]

IlI.lI.g

heett S[O:?] I

'-----0 Figuur 5.1.3

Interpretatie van het 5MB model

In de interpretatie gaan we uit van de entiteit 'ruimte'. Deze 'ruimte' wordt begrensd door een of meerdere 'ruimtebegrenzingen'. Peze 'ruimtebegrenzing' wordt gevormd door een of meerdere 'begrenzende structuren' en kan een of meerdere 'gaten' hebben. zo'n 'gat' wordt vervolgens weer gevuld door nul of meerdere 'begrenzende structuren' Ais we een 'begrenzende structuur' loodrecht op zijn vlak decomponeren vinden we een of meerdere 'Iagen'.

5.2

Een procesmodel van het ontwerpproces.

Om te komen tot een generiek gegevensmodel, wat het NOBIIBM in zekere zin is, moet zowel een proces- als ook een gegevensgeorienteerde methodiek gevolg worden. Bij de gegevensgerichte orientatie wordt gestart met het analyseren van noodzakelijke gegevens en vraagt men zich vervolgens af wat er met die gegevens (data) gebeurt. Dit komt overeen met de aanpak en de resuItaten zoals die zijn beschreven in de voorgaande hoofdstukken. Bij de procesorientatie worden de activiteiten en de gegevensverwerkende processen als uitgangspunt genomen. Het ontwikkelen van een procesmodel en een gegevensmodel zou eigenlijk parallel aan elkaar moeten plaatsvinden. Een procesmodel en een gegevensmodel hebben een relatie met elkaar: door de modellen met elkaar te vergelijken onstaat de mogelijkbeid tot verificatie. De gegevens van een gegevensmodel worden

47


BIT Notes

toegepast: ze worden gecreeerd, geraadpleegd, gewijzigd of verwijderd door een proces. Niet elk proces is geautoriseerd om elk soort toepassing uit te voeren. Er zal per soort proces moeten worden vast gesteld welk soort toepassing op een gegeven mag worden uitgevoerd. Bovendien vindt de toepassing plaats in een bepaalde volgorde: een gegeven kan niet verwijderd worden als het nog niet gecreeerd is. Met behulp van een procesmodel kan de volgorde van toepassing worden geverifieerd. Processen kunnen onderverdeeld worden in deelprocessen. Ais gevolg van deze decompositie van processen, worden tevens de gegevensstromen verbijzonderd. Omdat het procesmodel uit moet gaan van de activiteiten is de benaderingswijze probleemgericht. Een gevolg van deze probleemgerichte benadering is dat de gebruiker in de benoeming van de processen en de gegevensstromen zijn eigen activiteiten zal kunnen herkennen. Bovendien zal hij door de decompositie van de processen te volgen op een steeds concreter niveau uitkomen. Nu de noodzaak van een procesmodel is toegelicht kunnen we een en ander zeggen over het procesmodel van het ontwerpproces. Het ontwerpproces laat zich echter moeilijk in procesmodellen vangen. Oit is inherent aan het feit dat het ontwerpproces niet bestaat. Iedere ontwerper ontwerpt op zijn of haar eigen manier. Zoals reeds in hoofdstuk 3.2 is beschreven kunnen we weI verschillende fasen in het ontwerpproces herkennen, maar daarmee zeggen we weinig over het ontwerpproces zelf. Eigenlijk is de hele problematiek rond de informatie-uitwisseling gedurende het ontwerpproces terug te voeren op het feit dat het ontwerpwerk bespreekbaar en toetsbaar moet worden gernaakt. In diezelfde paragraaf 3.2 is aangegeven dat er vele manieren zijn om het ontwerpproces te beschouwen. Oaar wordt uitgelegd dat er gekozen is voor een toetsing van de gegevensmodellen aan de hand van een prototype. AIs uitgangspunt is het toetsingsmodel uit het NOBJJBBB onderzoek overgenomen, zie fig 5.2. Bij de toetsing gaan we er dus vanuit dat het ontwerpproces een communicatieproces is, waarbij gegevens moeten worden uitgewisseld. proj'-~l

behccr-

applk,ui.:-

lIi\.'l-proj'':I-

~\.·hlm\k~n

:Ipplkulirs

~"hon(k'll

f.,-""",kn

dll("Ullh:nh..~n

£t:~t.:\'\.·n"

y.:!!~n·ns

I vcrsi..: I () t-- -

I I

o

U W

K U

N D I G M

o J)

E

I.

~

CAD-document

K

r.-

1-.::::==:::i::i=======::::U C_A_D_._B_ib_li_o_lh_c,_·k_'_---'' _ I n l c l ' i l l l o ,,-__

">':"~-~'-II ruillll~

I

1--B

I~V_E

inrnnnl.'d nrUlil

1 12

t-- -

0

S

VCA

I DUS

Elemenll:nb.:gl'oling

T

1 3 __ E 1 1

1-'

Oudgctriuning

l3011wdelenbegrming b,IUWlkl~1I "l\'g~n~gd

a,ul ocgnlling

N

Bestek

S

VABI Wunmeverl ies

~--

I

U

VAnl

B

DUS

w4lfmh.~\·t·lli\.~s b.:rd~,,·,.ing

CUllUl!."U

I

VAnl Kanal.:n

S

E

VABI .* ..

# . . . . . . ~.~ • • • • • • • • • • • •

T YAm Kosten

Figuur 5.2: Toetsingsmodel

48


BIT Notes

Noodzakelijk is dat deze gegevens voor de ontvanger informatie bevatten en dat betekent dat deze eenduidig en fonneeI moeten zijn vastgelegd gebruikmakende van het gegevensmodei. Zal uit de toets bIijken dat aile gewenste informatie eenduidig kan worden uitgewisseld, mag worden geconcludeerd dat het achterliggende gegevensmodel voJdoet. Het moge duidelijk zijn dat op dit gebied nog veel onderzoek moet worden verricht. Mogelijk dat de door de VCA nieuw op te richten Fanfare 11- werkgroep in de nabije toekomst een bruikbare werkwijze zal opleveren. De doelstelling van deze werkgroep is het streven naar en praktisch realiseren van een uniforme CADwerkmethodiek voor de tekenkamers van architectenburo's. Daarbij willen wij wei de kanttekening plaatsen, dat de werkgroep dient te beseffen dat de inzet van nieuwe concepten (productmodel) en technologieen een verandering van werkwijzen met zich meebrengen. De kreet "automatiseren is veranderen" is eerder genoemd. Bij het bekijken van de huidige werkwijzen van CADhanterende architecten moet men zich steeds afvragen in hoeverre deze werkwijzen niet zozeer bewust zijn gekozen, maar eerder zijn onstaan vanuit de technische mogeUjkheden. Indien zo, moet aandachtig worden bekeken of die richting nog steeds wenselijk is.

49


6

BIT Notes

Het NOBI Bouwkundig Model (NOBIIBM).

Het NOBI Bouwkundig Model is een integratie van de drie voorgaande modellen. In onderstaand verhaal wordt de opbouw van dit model uitgebreid besproken. er wordt hierbij achtereenvolgens ingegaan op het type model. Met andere woorden: hoe moeten we in termen van het ABI het model plaatsen. Vervolgens worden de gebruikte abstractie-mechanismen uiteengezet, waarna wordt ingegaan op de opbouw van het feitelijke model in paragraaf getiteld 'decompositie van een gebouw'. Het gebruik van, de speciaIisatie en de decompositie van het entiteitstype 'bouwdeel' worden uitvoerig behandeld. Het hoofdstuk wordt afgesloten met een korte behandeling van het begrip 'aansluiting'.

6.1

Typering van het NOBI Bouwkundig Model.

Het NOB I bouwkundig model is te typeren aIs een produkttypemodel van het produkt 'gebouw'. Het bouwkundig model is opgesteld met de integratie van het NOBIIBBB model en het VABIIDUS model aIs uitgangspunt en vanuit het oogpunt van de architect. Hiertoe zijn de genoemde modellen samen met het synthesemodel van Bjork geinterpreteerd en geintegreerd. Het onderhavige bouwkundig model kan, in termen van het ABI, als kemmodel worden beschouwd voor de drie invalshoeken van kostenbepaling, bouwfysisch rekenen en bouwkundig ontwerpen. Vanuit deze views, ofwei disciplines, vormt het model een produkttypemodel voor gebouwen: een gebouwtypemodel. Opgemerkt dient te worden dat het model niet zozeer een generiek gebouwtypemodel kan worden genoemd, maar dat het model een integratie vormt van de behoeften vanuit de drie views zoals is vastgelegd in de modellen van het NOBIIBBB en het VABIIDUS en het synthesemodel van Bjork. In het ABI versie 0.3 wordt een onderscheid gemaakt tussen produkttypemodellen, geometriemodellen en documentrnodellen. Het produkttypemodel wordt daarbij als fundamenteel model gezien, terwijl het geometrieen het documentmodel dienen ten behoeve van representaties van het produkt c.q. gebouw. In het ABI wordt geconcludeerd dat voor het uitwisselen van produktgegevens geen standaard geometriemodel noodzakelijk is, maar dat het geometrisch model van het gebouw lokaal kan worden gegenereerd op basis van het uitgewisselde produktrnodel. Dit betekent dat het prdukttypemodel voldoende mogelijkheden moet bieden om bouwkundige objecten eenduidig te beschrijven, inclusief een impliciete beschrijving van de geometrie. De geometrie van gebouwen wordt ook in het hier beschreven bouwkundig model niet expliciet opgenomen, maar gerefereerd. Daarmee wordt de mogelijkheid geboden om verschillende typen geometrische modellen toe te passen, hetgeen verschillende typen representaties mogelijk maakt. Een geometrisch model wordt weI gebruikt als invoermechanisme vanuit het oogpunt van de architect. Daarnaast is uitwisseling van geometrie voor VABIIDUS, zoals op dit moment gespecificeerd, noodzakelijk. Uitgangspunt is echter dat het produkttypemodel aile gegevens bevat welke voor uitwisseling tussen de drie genoemde disciplines noodzakelijk zijn. In figuur 6.1 is het informatiemodel van het Intechno bouwkundig model weergegeven.

6.2

Abstractie mechanismen.

Het NOBIIBM zoals hiema gepresenteerd bevat entiteiten welke in gebouwen kunnen worden onderscheiden. In de EXPRESS-G schema's zijn deze entiteiten aangegeven met hun onderlinge relaties. De entiteiten worden beschreven door hun attributen, deze zijn echter niet weergegeven in de schema's. In het model kunnen twee typen relaties tussen entiteiten worden onderscheiden, namelijk ten behoeve van decompositie van entiteiten en ten behoeve van specialisatie van entiteiten. Decompositie is toegepast indien entiteiten kunnen worden onderverdeeld in entiteiten van een lager niveau, zo kan een gebouw worden gedecomponeerd in gebouwdelen. Een decompositie relatie wordt vaak aangeduid als een has_a relatie. Van specialisatie is sprake indien een entiteit als supertype wordt onderverdeeld in subtypen. Dit levert entiteiten op die aile attributen hebben van het supertype en daarnaast een aantal attributen die hen van dit supertype onderscheiden. Een voorbeeld hiervan is een openingscomponent als supertype van ramen en deuren. Een dergelijke relatie kan worden verwoord aIs een is_a relatie. Supertype entiteiten worden enerzijds gebruikt om op eenvoudige wijze relaties aan te geven met aBe onderliggende sub-entiteiten, anderzijds om objecten te modelleren waarvan (nog) niet aangegeven kan worden van welke subtype zij zijn.

50

TUE I Building Information Tecbnology

6.3

BIT Notes

Decompositie van een gebouw.

Het NIAM model in figuur 6.1 toont een schema waarin de objecttypen van het NOBIIBM zijn weergegeven: gebouw, gebouwdeel, al dan niet begrenzend bouwdeel, element, aansluiting, ruimte, ruimtebegrenzing, gat, recept en middel . Daarbij vah op dat de decompositie van een gebouw op twee manieren plaatsvindt namelijk in ruimten en in elementen. Deze decompositiewijze vloeit voort uit de twee praktijkprojecten die als uitgangspunt voor dit bouwkundig modelzijn genomen. In deze twee projecten, het NOBIIBBB en het V ABIIDUS project, worden twee verschillende benaderingen voor de decompositie van een gebouw onderscheiden. In NOBIIBBB spelen elementenlbouwdelen de belangrijkste rol als kostendragers. In de data-modellen is er weliswaar een koppeling mogelijk naar ruimten. maar deze functionaliteit wordt voor wat betreft de kostenbepaling in het BBB-model niet verder uitgewerkt. In V ABIIDUS wordt juist uitgegaan van ruimten als gegevensdragende objecten. Hierbij worden de bouwdelen (wanden, ramen en deuren) gekoppeld aan de ruimten, waarna de fysieke conditie van de ruimten en de technische vereisten daarvoor kunnen worden bepaald. Evenals in het synthesemodel van Bjork is in het NOBIIBM een synthese van deze twee benaderingen gevonden. Een gebouwdeel wordt derhalve onderverdeeld in enerzijds elementenlbouwdelen en anderzijds in ruimten. De bouwdelen en ruimten onderling worden gerelateerd door middel van een entiteit ruimtebegrenzing. Ruimtebegrenzingen zijn niet vertegenwoordig door een fysiek objecten in het gebouw, maar kunnen worden beschouwd als abstracte objecten die aangeven wat de begrenzing van een enkele ruimte is. Zo'n ruimtebegrenzing kan een imaginair vlak zijn, een functioneel onderscheid van de ruimte, maar kan ook fysiek worden vertegenwoordigd door begrenzende bouwdelen. In dat geval zal bijvoorbeeld een binnenwand een ruimtebegrenzing vormen. De relatie tussen ruimtebegrenzing en begrenzend bouwdeel is niet 1: 1, een begrenzend bouwdeel kan deel uitmaken van de begrenzing van meerdere ruimten. Op deze wijze is de relatie gelegd tussen de informatiebehoefte vanuit de ruimtelijke functionaliteit en de informatiebehoefte op het niveau van fysieke bouwdelen, welke o.a. naar bouwtechnische of kostentechnische functionaliteit kunnen worden gemodelleerd. Eveneens in het NlAM schema vinden we een objecuype gat. Door middel van dit type wordt de mogelijkheid geboden om in zowel bouwdelen gaten te modelleren als in ruimtebegrenzingen. Een gat kan uiteraard niet in een imaginaire ruimtebegrenzing bevinden. Tevens is het mogelijk om aan te geven of en door welke bouwdelen deze gaten worden opgevuld. Hiermee ligt de relatie van deze opvullende bouwdelen vast zowel met de begrenzende bouwdelen als met ruimtebegrenzingen. Daarmee wordt ook hier de mogelijkheid geboden gegevens te benaderen vanuit de invalshoeken van NOBIIBBB en V ABIIDUS.

51

~

(Iq

s:: ..,s:: ?'

a t:I:I

§3 :r::: 5'

0'

3 ~.

8..

~'

~ >

(l

:=: ,... ~ ~

U1

N

::I

<

0' ~

< ~ ~

........ ::I

g

:r

is

[ 0

..,0 ~

{;I

0'

1::>

is onderdeel van wordl levormd door beveL

is onderdeel van boorl bl)


6.4

BIT Notes

Specialisatie van een bouwdeel.

Een bouwdeel zoals in de vorige paragraaf besproken is een vrij generieke objecttype welke de basis vormt voor aile objecten in het mod~l welke een fysieke vertegenwoordiging in het gebouw hebben. Deze objecttypen kunnen verder worden onderverdeeld. Een eerste onderscheid kan worden gemaakt naar de functionaliteit begrenzend en niet begrenzend (van een ruimte). Dit onderscheid is nodig bijvoorbeeld voor het identificeren van de bouwdelen die van invloed zijn op de berekeningen aan het binnenklimaat van een ruimte. Daarnaast is het gewenst om aan te kunnen geven welke bouwdelen zich in een bepaalde ruimte bevinden, naast de begrenzende bouwdelen, bijvoorbeeld een kolom in een ruimte. Voor niet begrenzende bouwdelen is een specialisatie opgenomen voor distributiesystemen, hetgeen evident is ten behoeve van de communicatie met VABI applicaties. Door de relatie die een distributie systeem als niet begrenzend bouwdeel heeft met gaten in begrenzende bouwdelen en ruimtebegrenzingen, wordt hiermee de mogelijkheid geboden om een sparingenmodel onder te brengen.

6.5

Decompositie van bouwdelen.

In navolging van het NOBIIBBB model is een decompositie van bouwdelen in middelen in het BM opgenomen. Hoewel in het datamodel van het NOBIIBBB niet expliciet gemodeHeerd, is hier de objecttype recept als zelfstandige type aanwezig. Het recept bevat de kennis die specificeert welke middelen samen het bouwdeel vormen en op welke wijze deze samenhang in de verschillende views tot stand moet worden gebracht. Voor de view van de kostendeskundige is deze rol van het recept in het NOBIIBBB project duidelijk aanwijsbaar. Een uitbreiding van het BBB model is hier de specialisatie van de objecttype middel in opnieuw bouwdelen naast de entiteiten materiaal, arbeid en materieel welke we al in BBB vonden. Naar aanleiding van het prototype dat voor het NOBIIBBB model is gebouwd is gebleken dat er behoefte bestond aan een hierarchie in bouwdelen. Een bouwdeel kan worden gedecomponeerd in andere bouwdelen. Maar ook: een element kan bestaan uit bouwdelen met overerving van diverse eigenschappen waaronder de functionaliteit. Men kan zich afvragen wanneer nu een fysiek gebouwonderdeel een element dan wei een bouwdeel is. Het verschil tussen bouwdelen en elementen is, informaticatechnisch gezien, niet zo groot. Zo zou een bouwdeel gemodelleerd kunnen worden als subtype van element met als toevoeging die eigenschappen. die een bijbehorende technische oplossing beschrijven. Maar het kan ook anders . In NOBIIBBB zijn naast bouwdelen en midde1en ook elementen expliciet als objecttypen opgenomen. Daarbij zijn bouwdelen niet als sUbtypen van elementen gemodelleerd maar als 'decompositie van'. Uit een analyse van het BBB-model is geconcludeerd dat de functionaliteit van elementen gesteld kan worden op een selectie-mechanisme voor bouwdelen waarbij geldt dat elementen een meer algemeen geldend karakter hebben zonder dat wordt ingegaan op een specifiek technische oplossing. Met andere woorden: Het objecuype element komt dus tegemoet aan de behoefte om met fysieke onderdelen te kunnen werken zonder direct met technische oplossingen rekening te hoeven houden. En omdat een geschikte classificatie van bouwdelen voor zover bekend niet beschikbaar is, komt het ook tegemoet aan de behoefte gebruik te kunnen maken van de bestaande classificatiemethode van elementen (NUSfB).

6.6

Eigenscbappen: gewenste en gerealiseerde waarde.

Naast het identificeren van objecttypen in het NOBIIBM is het noodzakelijk deze objecttypen inhoudelijk te specificeren. Dit houdt in dat de attributen van deze objecttypen moe ten worden vastgelegd. In dit onderzoek zal het bepalen van de attributen worden gedaan aan de hand van een gerealiseerd bouwwerk, het Intechno gebou w. Enerzijds biedt deze methode een betere garantie voor een reeel gebouwtypemodel. anderzijds maakt deze methode het model beduidend minder generiek. Allereerst moet echter worden bepaald volgens welke structuur attributen worden vastgelegd, welke typen attributen worden onderscheiden, en wat hun relaties onderling en met de objecttypen zijn. Deze structuur kan worden gekozen zonder inhoudelijk te specificeren welke attributen een entiteit beschrijven. In het NOBIIBBB en het V ABIIDUS worden attributen op twee verschillende manieren gestructureerd. V ABIIDUS beschrijft de objecuypen welke hier vergeleken kunnen worden met de entiteit bouwdeel. aan de hand van gekoppelde objecttypen waarin de functionele en technische specificaties van de betreffende entiteit worden vastgelegd in attributen. Er is dus steeds sprake van drie entiteittypen welke onderling zijn gekoppeld zoals getoond in het IDEF Ix model, zie figuur C.I in de bijlage C. In dit model zijn functionele en technische

53

TUB / Building Infonnation Technology

BIT Notes

specificatie strikt gescheiden. Het model zelf biedt geen plaats voor het vastleggen van kennis omtrent de relatie tussen de beide specificaties. Deze kennis en het afstemmen van beide typen specificaties op elkaar valt onder verantwoordelijkheid van de applicaties. In NOBIIBBB wordt ook een onderscheid gemaakt in attribuuttypen. Een verschil tussen functionele en technische specificaties wordt hier aangegeven door middel van het begrip status. De attributen van een entiteit kunnen steeds twee waarden aannemen. een projectwaarde en een referentiewaarde (zie figuur C.2 in bijlage C). De waarde die uiteindelijk wordt gebruikt is bij voorkeur de projectwaarde. die het meest specifiek voor het onderhavige project is. Het gaat hier in beide gevallen om een gerealiseerde waarde voor een attribuut. Dit onderscheid tussen projecten referentiewaarde zien we niet terug in V ABUDUS. In het NOBIIBM is een synthese van de hiervoor beschreven technieken toegepast. Figuur C.3 in bijlage C toont dat de attributen van een entiteit optionee I twee waarden kunnen hebben: een gewenste waarde en een gerealiseerde waarde. Dit onderscheid biedt de mogelijkheid om eis en oplossing te kunnen modelleren, zoals dit ook door V ABUDUS wordt gedaan in de vorm van functionele en technische specificaties. De gewenste waarde kan verschillende bronnen hebben, genormeerd, of zelf ingegeven. De gerealiseerde waarde kan, zoals in NOBIIBBB een projectwaarde zijn, indien deze bekend is, of een referentiewaarde indien beschikbaar. Deze waarden hebben betrekking op hetzelfde attribuut en hebben dus dezelfde grootheid. Het is niet altijd mogelijk om van cen attribuut zowel een gewenste als een gerealiseerde waarde te geven (bijvoorbeeld in het geval van bouwfysische specificaties en oplossingen). In normen wordt vaak aangegeven op welke wijze een aantal gewenste waarden samen bepalen wat de gerealiseerde waarde moet zijn. Uiteindelijk zal echter steeds bij iedere gerealiseerde waarde een toets aan een bijbehorende gewenste waarde plaatsvinden, ook als deze resulteert als procesgegeven uit een berekening van andere gewenste attribuutwaarden.

6.7

Aansluitingen.

In een late fase van het onderzoek is de sterke behoefte aan het entiteitstype 'aansluiting' naar voren gekomen. Een aansluiting legt de informatie vast die ontstaat, wanneer twee of meer bouwdelen dan wei twee of meer elementen bij elkaar komen en op de een of andere manier een relatie met elkaar hebben. Het belang van dit entiteitstype is evident. Daarom is het opgenomen in het BM-model. Een aansluiting wordt gezien als een subtype van het typew bouwdeel. Dat betekent niet dat daarmee aile knelpunten zijn opgelost. Probeer als oefening maar eens een aansluiting, bijvoorbeeld een hoekdetail van de verbinding van een vliesgevel met een binnenwand en een vloer in 3D voor te stellen. Bedenk daarbij dat deze samenvallende componenten als functionele elementen of als verder uitgewerkte bouwdelen kunnen worden bekeken. Ook zijn er vele typen aansluitingen, afhankelijk van de view. Deze problematiek kon niet uitputtend worden bekeken. Daarom is in het prototype aileen de aansluiting als topologische relatie meegenomen, nameIijk die van een deur in een binnenwand en een binnenwand die grenst aan een andere wand.

54


Deel C: 7

BIT Notes

Het prototype.

Uitgangspunten voor het ontwikkelde prototype.

Ten behoeve van de demonstratie van het Bouwkundig Model is een prototype gebouwd. Voor dit prototype zijn een aantal randvoorwaarden opgesteld die hier in het kort worden beschreven.

7.1

Demonstratie en doelgroep.

De demonstratie waarvoor het prototype wordt gebouwd heeft als doel aan te tonen op welke wijze een ontwerp kan worden gemodelleerd op basis van het NOBIIBM. De doelgroep van de demonstratie bestaat enerzijds uil de betrokken participanten van het deel van het ontwerp-proces waarop het NOBIIBM betrekking heeft, te weten de architect, de kostendeskundige en de installatietechnisch adviseur. Anderzijds behoren ook software ontwikkelaars tot de doelgroep van de demonstratie. Het prototype dient dus inzichtelijk te maken op welke wijze het NOBIIBM ingezet kan worden in het ontwerp-proces. Daarnaast moet het prototype een voorbeeld vormen voor te ontwikkelen software ten behoeve van de implementatie van de principes van het NOBIIBM.

7.2

Subview van de architect.

Het prototype demonstreert een programma, waarmee het voor een architect mogelijk moet zijn om een 3D model te produceren van het gebouwontwerp in de DO fase, op basis van het NOBIIBM. De ruimten en bouwdelen die worden gemodelleerd zijn gedefinieerd vanuit een subview van de architect. De hierarchie van de bouwdelen wordt dan ook door de architect zelf bepaald. Voor ruimten wordt een classificatie door de architect toegestaan. In het prototype moet het mogelijk zijn aan te sluiten bij bestaande standaarden voor de classificatie van componenten, met name de NL-SfB classificatie.

grafische interface. De subview van de architect vereist van dit programma een grafische interface, dat wit zeggen, interactieve grafische terugkoppeling van de keuzen die tijdens het modelleren worden gemaakt. Deze eis manifesteert zich bijvoorbeeld bij het maken van keuzen uit een bibliotheek voor het plaatsen van bouwdelen. De bibliotheek moet grafisch gepresenteerd worden, opdat een keuze op basis van visuele herkenning kan worden gemaakt. Daarnaast is echter een hoge mate van grafische interactie van belang tijdens het modelleren zelf. Het resultaat van de handelingen van de gebruiker moet direct duidelijk zijn. Ten slotte dient de communicatie over specifieke onderdelen van het gebouw steeds gebruik te maken van de grafische representatie van deze onderdelen. Bijvoorbeeld een ruimte wordt geldentificeerd aan de hand van de grafische representatie ervan.

7.3

Informatie-behoefte.

Het NOBIIBM beschrijft de informatie-behoefte vanuit de subview van de architect, waarbij de informatievoorziening ten behoeve van kostendeskundige en installatietechnisch adviseur wordt gelntegreerd. Het model representeert het gebouw in de vorm van ruimten en bouwdelen.

Ruimten vs. bouwdelen. Voor zowel de subview van de architect als van de installatietechnisch adviseur is het noodzakelijk het gebouw te beschrijven aan de hand van de ruimten die het gebouw bevat en de relaties hiervan met de begrenzingen van deze ruimten en de gaten hierin. Van de ruimten, ruimtebegrenzingen, en gaten moeten zowel geometrische als niet-geometrische gegevens worden gemodelleerd. De ruimtebegrenzingen en de gaten hebben een relatie met de bouwdelen die de fysieke vorm van deze onderdelen bepalen. Naast het ruimte-concept voor het modelleren van het gebouw, wordt het gebouw samengesteld uit de kleinste bouwdelen die voor de DO fase worden onderscheiden vanuit een subview van de architect. Van deze bouwdelen moet worden aangegeven of ze een functie als ruimte-begrenzing hebben.

55

TUE I Building Infonnalion Technology

BIT Notes

Te modelleren data. Voor de sub view van de architect worden deze objecttypen gemodelleerd door middel van hun geometrie, topologie en semantische data zoa1s functie en prestatie-eisen. De informatiebehoefte van de kostendeskundige en de installatietechnisch adviseur wordt bepaald vanuit twee gekozen computerapplicaties, respectievelijk het BBB programma voor begrotingen en het V ABI programma voor warmteverliesberekeningen (VA 101). Ten behoeve van BBB moeten bouwdelen kunnen worden geclassificeerd op basis van de NL-Sm, en moeten hoeveelheden van ieder type bouwdeel kunnen worden bepaald. De V ABI programmatuur vraagt geometrie van ruimten, door middel van de ruimtebegrenzingen en de openingen daarin, en bouwfysische eigenschappen en eisen van zowel ruimten als begrenzingen met openingen. In het prototype wordt niet getracht een uitputtende verzameling van de genoemde gegevens te modelleren, maar wordt gestreefd naar het aantonen van de mogelijkbeden om dergelijke informatie gei'ntegreerd vast te leggen en uit te wisselen.

7.4

Intechno gebouw.

De demonstratie van het NOBIIBM met behulp van het prototype zal gebeuren aan de hand van een model van het Intechno gebouw. Daartoe wordt uitgegaan van de DO fase van het ontwerp van dit gebouw, waarvan bestektekeningen beschikbaar zijn gesteld. Het gehele gebouw wordt onderverdeeld in bouwdelen zoals gedefinieerd in het NOBIIBM en gemodelleerd in een CAD systeem. Dit model wordt vervolgens gebruikt om de principes van het NOBIIBM te demonstreren. Dit impliceert niet dat het prototype een werkend stuk software is, maar dat het de werking van te ontwikkelen software aan moet tonen.

7.5

Platform en software.

Gezien de aansluiting bij de bestaande software voor BBB en VABI, welke op het PC-platform zijn ge'implementeerd, wordt voor het prototype ook de keuze gemaakt voor een ontwikkeling op PC's. Als CAD systeem wordt gekozen voor AutoCAD, gelet op de mogelijkbeid voor aansluiting op de genoemde software van BBB en V ABI. Daarnaast wordt gekozen voor Windows 3.1 als operating systeem van waaruit de demonstratie zal worden gegeven.

7.6

Onderdelen van het NOBIIBM in de demonstratie.

In de demonstratie moeten de volgende onderdelen inzichtelijk worden gemaakt.

Modelleren van het gebouw. •

Het modelleren van het gebouw in zowel ruimten als bouwdelen. Voor beide typen objecuypen moeten commando's beschikbaar zijn voor toevoegen aan het model, wijzigen, samenVoegen en verwijderen. Tevens moet het mogelijk zijn informatie van de gemodelleerde objecttypen op te vragen en deze te wijzigen.

•

De relatie tussen ruimten en bouwdelen. Ruimten worden gemodelleerd door middel van hun begrenzingen en de gaten daarin. Deze beide typen objecttypen hebben relaties met de bouwdelen die hun fysieke representatie vormen. Deze relatie dient tijdens het modelleren tot stand te worden gebracht en onderhouden.

•

Het modelleren van bouwdeJen, op basis van een bibliotheek of op basis van in te voeren prestatieeisen. Bouwdelen kunnen worden gemodelleerd door te refereren naar de definities in een bibliotheek van bouwdelen. In deze bibliotheek zijn de gegevens betreffende het bouwdeel, geometrie, topologie. prestatie-eisen, etc., al dan niet parametrisch vastgelegd. De informatie omtrent het bouwdeel wordt dan uitgewisseld op basis van de standaardisatie van de bibliotheek. Bouwdelen kunnen echter ook worden gemodelleerd door het specificeren van de prestatie-eisen tijdens het modelleren, en het plaatsen van een geometrisch/topologische representatie. Deze twee wijzen van modelleren moeten in het prototype inzichtelijk worden gemaakt.

56


BIT Notes

Uitwisselen met VCAJDUS. •

Exporteren van gegevens vanuit het BM naar VCAlDUS.

•

Importeren van deze gegevens vanuit VCAlDUS in respectievelijk BBB en Warmteverliesberekening (VAlOI).

57


8

BIT Notes

Het prototype.

Het prototype wordt beschreven aan de hand van de wijze waarop met het prototype kan worden gemodelleerd. Tevens wordt het proces van uitwisseling van gegevens met de applicaties BBB en YAWl toegelicht.

8.1

Werkwijze van modelleren.

Modelleren van bouwdelen. Het Intechno gebouwmodel is opgebouwd op basis van de bestektekeningen van het gerealiseerde Intechno gebouw zoals ze door de architect beschikbaar zijn gesteld. In deze tekeningen uit de DO fase zijn de kleinste bouwdelen onderscheiden en 3D gemodelleerd in AutoCAD. De verzameling bouwdelen die op deze wijze is ontstaan kan worden beschouwd als een bibliotheek van bouwdelen. Met behulp van deze bibliotheek kan het gebouw worden gemodelleerd. De componenten uit de bibliotheek zijn geometrisch bepaald, al dan niet met behulp van parameters. Dat wi) zeggen dat in de bibliotheek procedurele kennis, voor het plaatsen van de bouwdelen en het bepalen van de vorm van de bouwdelen, is opgeslagen. Daamaast is van de bouwdelen in de bibliotheek de data opgeslagen die de prestatie-eisen van de bouwdelen beschrijven. Een andere methode van modelleren wordt in het prototype ook toegepast. Bouwdelen kunnen worden gemodelleerd door het specificeren van prestatie-eisen van bouwdelen en daarbij het plaatsen van een representatie van dit bouwdeel in het model. De geometrie van deze representatie kan eveneens in een bibliotheek worden opgenomen, wederom al dan niet parametrisch.

Gemodelleerde informatie van een bouwdeel. De informatie die van een bouwdeel wordt gemodelleerd bestaat dus uit de volgende onderdelen: • c1assificatie volgens de subview van de architect • NL-Sffi classificatie • geometrie van het bouwdeel (dit impliceert de hoeveelheid en afmetingen van het bouwdeel) • topologie van het bouwdeel • prestaties I prestatie-eisen. Deze lijst van gegevens is een arbitrair vastgesteld lijst. welke naar behoefte kan worden aangevuld. Met name de gegevens betreffende de prestaties en prestatie-eisen verdient bij verdere ontwikkeling ruime aandacht.

Modelleren van ruimten. Het modelleren van ruimten kan op een expliciete wijze, door het modelleren van de begrenzingen van de ruimten en de gaten in deze begrenzingen. Het prototype biedt echter de mogelijkbeid ruimtebegrenzingen impliciet te modelleren tijdens het modelleren van de bouwdelen die de fysieke representatie van de ruimtebegrenzingen vormen. Op deze wijze kan een ruimte worden gevormd door de ruimtebegrenzingen welke worden gemodelleerd door het plaatsen van de wanden, vloer en plafond van de ruimte. Door het plaatsen van een binnenwand kan een ruimte worden gesplitst in twee ruimten, waarvan een de functionaliteit van de oorspronkelijke ruimte behoudt, terwijl voor de andere een nieuwe specificatie wordt ingevoerd. De specificatie van een ruimte bestaat in het prototype uit: • naam van de ruimte • c1assificatie (bijvoorbeeld volgens CI-Sffi) • functie van de ruimte (omschrijving) • oppervlak in m2 • • • •

hoogte in mm volume in m 3 gewenste temperatuur nachtverlaging.

Ook hier geldt dat deze lijst van gegevens arbitrair is vastgesteld en dat naar behoefte uitbreidingen kunnen worden aangebracht. Deze behoefte zal vanzelfsprekend moeten worden afgestemd op de gewenste output van gegevens die van het model wordt gevraagd.

58

TUEf Building Infonnation Technology

8.2

BIT Notes

Data-management.

Wanneer in het gehele traject van de ontwikkeling van computerondersteuning wordt overgegaan tot implementatie, moet er worden gekozen voor een methode van beheer van data. Tenzij de methode van datamanagement zelf het onderwerp van evaluatie vormt, is het bij proto typing niet belangrijk welke methode hiervoor wordt gekozen. Belangrijker is in het prototype inzichtelijk te maken welke data wordt opgeslagen, wat de samenhang tussen deze data is, op welke wijze het systeem met de gebruiker communiceert en welke inen uitvoer het systeem vraagt en toestaat. De keuze voor de methode van data-management is in dit prototype gebaseerd op grond van eenvoud en flexibiliteit. Dit komt in het kort neer op de volgende verdeling van data: • geometrie van ruimten en bouwdelen in AutoCAD entiteiten • niet-geometrische data van ruimten en bouwdelen in ASCII bestanden buiten AutoCAD • relaties tussen ruimten en bouwdelen op basis van layer-informatie en extended entity data in AutoCAD • communicatie met externe appIicaties door middel van ASCII bestanden.

8.3

Opbouw van de interface.

Het prototype is gebouwd met behulp van AutoCAD en de daarbij horende middelen voor softwareontwikkeling. De interface bestaat uit een aantal onderdelen. In het menu van AutoCAD zijn items en submenu's opgenomen welke het prototype aansturen. Bij het opstarten van een tekening wordt de software geladen en worden de benodigde instellingen voor het werken met het prototype uitgevoerd. Een aantal instellingen kunnen door de gebruiker van het programma worden gewijzigd, zoa1s de gewenste c1assificatietabel voor bouwdelen. In het menu zijn twee submenu's opgenomen voor het modelleren van respectievelijk ruimten en bouwdelen. De oorspronkelijke AutoCAD submenu's blijven daarbij binnen handbereik, zodat de gebruiker ook deze functionaliteit ter beschikking houdt. Na het selecteren van een van de items in de submenu's voor het modelleren van ruimten of bouwdelen wordt de communicatie met de gebruiker door het systeem gevoerd door middel van dia)oogvensters, of, bij zeer eenvoudige communicatie, via de command-line van AutoCAD. Wanneer, ten slotte, grafische invoer van de gebruiker nodig is kunnen met behulp van een digitizer 3D coOrdinaten worden ingegeven. .

S9

BIT Notes


8.4

Werken met bet prototype.

Aan de hand van de onderdelen van de interface wordt hieronder een toelichting gegeven op het werken met het prototype. In het AutoCAD menu worden twee submenu's aangetroffen welke onderdeel zijn van het prototype, respectievelijk BM-RUIMTE en BM-BOUWDEEL (zie onderstaande figuur).

BM-Ruimte

BM-Bouwdeel

AutoCAD View

AutoCAD Assis1

Identificeren

Info

Toevoegen Verwijderen Samenvoegen Wijzig

Toevoegen Verwijderen Samenvoegen Wijzig

Fig.8.1 Prototype NOBIIBM: AutoCAD pUlldown-menu's.

Met de commando's in het submenu BM-RUIMTE kunnen ruimten expliciet worden gemodelleerd. De gegevens die bij een ruimte worden opgeslagen kunnen worden opgevraagd en gewijzigd met behulp van het commando IDENTlFlCEREN. Na het activeren van dit commando kan een ruimte worden ge'identificeerd in het model door binnen de ruimtebegrenzingen een punt aan te wijzen. Met de commando's in het submenu BM-BoUWDEEL kunnen bouwdelen worden gemodelleerd. Hier kan met het commando INFO de informatie van een bouwdeel worden opgevraagd. 8.4.1

Instellen van de bouwdeel-c1assificatie.

In het AutoCAD submenu SETTINGS kan het commando BM SETTINGS worden geactiveerd voor het instelling van de bouwdeel classificatie. De gebruiker kan in het dialoogvenster dat hierna verschijnt de naam van het bestand invoeren dat een beschrijving van de classificatie bevat. Deze ins telling bepaalt de communicatie van het systeem met de gebruiker bij het selecteren van te modelleren bouwdelen.

bouwdeel classificatie:

~I'~ii~4~ft~m~.~I~_______--.J

ruimtebegrenzlngen: C?Sl definltie door bouwdelen prestatle-eisen:

0

bouwdeel afhankeliik

Fig. 8.2 Prototype NOBIIBM: Settings.

60


BIT Notes

In hetzelfde dialoogvenster kan de gebruiker aangeven of de bouwdelen, die na deze instelling worden gemodelleerd, de functie van fysieke ruimtebegrenzingen moeten hebben. Indien dit het geval is zal, tijdens het plaatsen van bouwdelen die ruimtebegrenzend kunnen zijn, impliciet een ruimtebegrenzing worden gemodelleerd, hetgeen van invloed is op het ruimte-model van het gebouw en versnellend werkt v~~r de CADoperator.

Bouwlagen. In het zelfde pulldown-menu van het prototype kan het commando BM BOmyLAGEN worden geactiveerd, waarna in een dialoogvenster aangegeven kan worden welke bouwlagen van het gebouw actief zijn v~~r het modelleren.

8.4.2

Modelleren van bouwdelen.

Het activeren van het commando BM-BoUWDEELI TOEVOEGEN brengt het volgende dialoogvenster op het scherm. Het uiterlijk van dit dialoogvenster is afhankelijk van de instelling van de bouwdeelclassificatie. Niet aileen bepaalt deze instelling de inhoud van de c1assificatie, de hierarchie van de bouwdelen, ook het al dan niet coderen van deze hierarchie wordt door de keuze v~~r een bepaalde classificatie vastgelegd. In het dialoogvenster kan door middel van aanwijzen het gewenste bouwdeel uit de c1assificatie worden geselecteerd. Door OK te kiezen wordt deze keuze bevestigd. Indien de gekozen classificatie gecodeerd is, dan kan in het dialoogvenster, naast het aanwijzen van het gewenste bouwdeel, de gewenste code ook direct worden ingetypt. Het dialoogvenster zal zich aan deze code aanpassen.

Bouwdeel code: binnenwandopeningen; gevuld met deuren, draaideuren 13 - vloeren op 16 - funderingsconstructies 17 - paalfunderingen 21 - bultenwanden 22 - blnnenwanden 23-vloeren 2.( - trappen en helllngen 27-daken 28 - hoofddraagconstructies 133 - vloeropeningen 34 - balustrades en leunlngen 37 - dakopeningen 38-

32.32 - schuifdeuren 32.33 - tuimeldeuren 32.34 - tourniquets

Fig. 8.3 Prototype NOBUBM: Selectie van bouwdelen. Afbankelijk van de keuze die in dit dialoogvenster is gemaakt verschijnt daarna een van de volgende dialoogvensters. Indien het geselecteerde bouwdeel in de classificatie niet verder is onderverdeeld in subbouwdelen, wordt direct een grafische representatie van het bouwdeel getoond en kan de keuze tussen BIBLIOTHEEK en PRESTATIE worden gemaakt. In het geval wei verdere decompositie van het bouwdeel is gespecificeerd in de c1assificatie, dient eerst een keuze worden gemaakt voor het te modelleren sub-bouwdeel. Vervolgens kan ook dan met behulp van BIBLIOTHEEK of PRESTATIE dit bouwdeel worden gemodelleerd.

61


Bouwdeel:

BIT Notes

22.13 - systeemwanden

grafische weergave

I~;;:);Bibliotheek< : 11·:' Presta!i({';~i ".:~ :I

I'Ca~C;'~I}lJ -"$'

'.

',""'Vifici'''.'T

Bouwdeel groep:

I."';'-ii:ie."Ipi~{~f,~[ "';: .,j

22.12 - spouwwanden

Fig. 8.4 Prototype NOBIIBM: Bouwdeel specificatie en selectie van sub-bouwdelen.

62

TOE I Building Infonnation Technology

BIT Notes

Modelleren op basis van prestatie-eisen. Wanneer in een van de voorgaande dialoogvensters gekozen wordt voor het plaatsen van een bouwdeel door het specificeren van prestatie-eisen. verschijnt het volgende dialoogvenster. Hierin vindt men de prestatieeisen zoals voor het betreffende bouwdeel voorgedefinieerd in de classificatie-tabel. Deze kunnen vervolgens worden gewijzigd en aangevuld waarna een geometrische representatie van het bouwdeel kan worden gemodelleerd.

eenheid

waarde

gedrag blJ brand vloelstoffen. vaste mutaties------------------------------------------------------------~

prestatie-els: 1brandwerendheld eenheld: 1min. waarde:

~================~

1 . . . . . 1_

_

_

_

_

_

_

_

_

_-

'

L22~~~~g

Fig. 8.5 Prototype NOBIIBM: Bouwdeel prestaties.

In het prototype wordt onderscheid gemaakt tussen bouwdelen die worden gemodelleerd door referentie naar een bibliotheek en bouwdelen waarvan in het model de prestatie-eisen worden gemodelleerd. De prestatie-eisen welke hier worden gespecificeerd zijn niet gekoppeld aan bouwdelen die deel uitmaken van de bibliotheek. Het is echter wei mogelijk de prestatie-eisen van een bouwdeel uit de bibliotheek over te nemen en vervolgens naar behoefte aan te passen. Prestaties kunnen ook op zichzelf worden bewaard in een referentie-bestand en hieruit terug worden ingelezen.

Modelleren na selectie uit een bibliotheek. Door het selecteren van BmLIOTHEEK in een van de dialoogvensters in fig. 4, kan een bouwdeel uit de bibliotheek worden geplaatst in het model. Deze bouwdelen kunnen parametrisch zijn, hetgeen betekent dat niet aile data in de bibliotheek is vastgelegd, maar dat tijdens het modelleren door de gebruiker nadere gegevens kunnen of mooten worden ingevoerd. In onderstaand diaIoogvenster kan de gebruiker het gewenste bouwdeel uit de bibliotheek selecteren. Een grafische representatie van het in de Iijst geactiveerde bouwdeel wordt direct getoond in het diaIoogvenster. Van dit bouwdeel kan eerst informatie worden opgevraagd omtrent de prestaties die ervoor zijn gespecificeerd, alvorens het bouwdeel wordt geplaatst in het model.

63


BlTNates

Naast de standaard bibliotheek die voor het huidige project actief is, kan hier ook worden gekozen voor het plaatsen van bouwdelen uit externe bibliotheken, of leveranciers·bibliotheken.

Bouwdeel: 22.13 - systeemwanden vast bibliothee 22.13.1 - aluminium panelen 100mm 22.13.2 - Sandwich eel. PB 0 Nr 1292/01 22.13.4 - Sandwichpaneel. PBO Nr 4502/01

Prestatle~nfo .

Fig. 8.6 Prototype NOBIIBM: Bouwdeel bibliotheek.

Tijdens het plaatsen van een bouwdeel determineert het prototype op welke bouwdelen in het model dit nieuw geplaatste bouwdeel aansluit. Uit een bibliotheek van aansluitingen worden de juiste aansluitingen geselecteerd, waannee het bouwdeel in het model wordt geplaatst. Indien er onvoldoende kennis in deze bibliotheek van 3D aansluitingen aanwezig is. of indien er keuze-mogelijkheden zijn, wordt via een dialoogbox invoer van de gebruiker gevraagd voor het selecteren van de juiste aansluiting.

8.4.3

Impliciet modelleren van ruimtebegrenzingen.

Indien bij SEmNGS I BM SETTINGS is aangegeven dat bouwdelen ruimtebegrenzend zijn, worden tijdens het modelleren van ruimtebegrenzende bouwdelen de ruimtebegrenzingen impliciet gemodelleerd. Dit heeft gevolgen voor het ruimte-model van het gebouw. Een ruimte ontstaat wanneer ruimtebegrenzingen een volume volledig omsluiten. De ruimte kan dan worden geYdentificeerd en de benodigde informatie kan worden ingevoerd. Wanneereen ruimtebegrenzend bouwdeel, bijvoorbeeld een binnenwand, wordt geplaatst in een ruimte. kan daannee een ruimte in twee delen worden gesplitst. Een van deze delen behoudt dan de functionaliteit van de oorspronkelijke ruimte, terwijl het andere deel nieuwe functionaliteit krijgt toegekend. De nieuwe ruimten worden automatisch herkend. In het prototype wordt na het splitsen van een ruimte in twee ruimten, door het plaatsen van een binnenwand, de mogelijkheid geboden in de binnenwand een deur te plaatsen. Deze deur impliceert de plaatsing van een gat in de ruimtebegrenzing.

8.4.4

Opvragen en wijzigen van gegevens van ruimten en bouwdelen.

Met respectievelijk de commando's BM-RuIMTEI IOENTJFICEREN en BM-BoUWDEELI INFO kan informatie worden opgevraagd van gemodelleerde ruimten en bouwdelen. Een aantal van deze gegevens kunnen direct worden gewijzigd, bijvoorbeeld de functie van een ruimte. Andere gegevens zijn afhankelijk van de

64

TUE / Building InfolTlllltion Technology

BIT Notes

geometrisch/topologische representatie van de ruimten en bouwdelen, en kunnen aIleen grafisch worden gewijzigd. De onderstaande dia100gvensters geven de gegevens van een ruimte, respectievelijk bouwdeel.

naam

IllliIDidl

classificatie

32.920.1

functle

kantoor

oppervlak (m2)

39.20

hoogte (mm)

2160

volume (m3)

108.18

gewenste temperatuur 119 nachtverlaging

~==================~

11-1_3_ _ _ _ _ _ _ _ _ _--'

Fig.8.7 Prototype NOBIIBM: Ruimte informatie.

Bouwdeel: classificatie

systeemwanden vast

bln~~rrwan~~~.~------__--____,

nlet constructlef systeemwanden vast aluminium panelen 100mm NL-SfB: 22.13 eometrle lengte: dikte: hoogte: locatie: orientatie:

5150.00 100.00 2160.00 14580.00. 1300.00. 0.00 90.00

restatie-eisen

>geleldlng U-waarde

>vuur. explosle

eenheid W/(m2.K)

brandvoortplantlng rookontwlkkelln rook eta!

Fig. 8.8 Prototype NOBIIBM: BouwdeeJ informatie.

65

waarde 1.0

TUE I Building lnfonnalion Technology

8.4.5

BIT Notes

Exporteren naar VCAJDUS.

In het AutoCAD submenu Fn..E kan het commando BM EXPORT VCAlDUS worden geactiveerd. Het gehele model wordt dan geexporteerd naar een extern bestand, waarna met behulp van de VCAlDUS module de uitwisseling met andere applicaties kan worden verzorgd.

Export Bouwkundlg Model naar VCAlDUS Schrljven naar be stand...

767

Fig. 8.9 Prototype NOBUBM: Export naar VCNDUS.

66

TUE f Building Information Technology

9

BIT Notes

Toetsing

Ten behoeve van de toetsing van het NOBI Bouwkundig Model, binnen de gestelde randvoorwaarden, is een prototype gebouwd waarmee vanuit een sub-view van de architect invulling kan worden gegeven aan de gegevensopbouw van het bouwkundig model. Dit prototype wordt uitvoerig beschreven in deel C van dit eindrapport. De sub-view van de architect wordt nader toegelicht in hoofdstuk 3. De toetsing in dit onderzoek bestaat uit twee onderdelen:

A De inhoudelijke toetsing van het produkttypemodel. Hierin zijn de compleetheid, consistentie en werkbaarheid van het produkttypemodel, ten aanzien van het modelleren van architectonische informatie, aan de orde gekomen. Deze toetsing is uitgevoerd aan de hand van een case, namelijk het modelleren van het Intechno gebouw op basis van het produkttypemodel. In het prototype wordt het concept van modelleren met het produkttypemodel gedemonstreerd. Ten behoeve hiervan zijn over het gehele proces van modelleren verschillende acties operationeel geimplementeerd in het prototype, zoals het toevoegen van ruimten en bouwdelen op een bouwlaag.

figuur 9.1: Ben bouwlaag van het Intechnokantoor De demonstraties met het prototype hebben aangetoond, enerzijds dat het modelleren op basis van het produkttypemodel mogelijk is, anderzijds dat het mogelijk is een systeem te bouwen dat het werken volgens dit produkttypemodel vanuit de view van de architect mogelijk maakt. In de demonstratie is aan de orde gekomen dat bouwkundig produktmodelleren betekent: het modelleren van een gebouw in zowel ruimten als bouwdelen, met de relaties tussen beiden, relaties tussen bouwdelen onderling, de wijze van modelleren van ruimten en bouwdelen, en een directe terugkoppeling van de gemodelleerde informatie in het CAD systeem. Daamaast wordt in het prototype benadrukt dat het classificeren van ruimten en bouwdelen van belang is.

B Functionele toetsing van het produktrnodel in het uitwisselingsproces tussen de gekozen drie participanten in het ontwerpproces. In het prototype wordt aangetoond op welke wijze zowel bouwkundige informatie vanuit de view van de architect voor de eigen informatiebehoefte wordt gemodelleerd, als bouwkundige informatie welke benodigd is voor de communicatie tussen de architect en repsectievelijk de kostendeskundige en de installatietechnisch adviseur. De informatie ten behoeve van de communicatie kan zonder noemenswaardige extra inspanning door de architect in het model worden verwerkt. In de demonstratie wordt het proces van communicatie getoond. via VCA/DUS. naar respectievelijk het prototype van het NOBIIBBB onderzoek en naar de applicatie voor warmteverliesberekening van VABI.

67


BIT Notes

Bij de communicatie met de VABI software is gebleken dat het mogelijk is de informatievoorziening ten behoeve van deze software, naar aanleiding van het aanbod van informatie vanuit een bouwkundige produktmodel zoals het NOBIIBM, verder kan worden geautomatiseerd, waardoor een verbetering in consistentie en een hogere betrouwbaarheid van informatie kan worden bereikt. Bovendien is minder effort nodig voor evaluatie van een model, hetgeen kan lei den tot kwaliteitsverbetering van het produkt, het gebouwontwerp. Het prototype is gedemonstreerd aan de betrokken participanten in het NOBIIBM onderzoek en aan een aantaI andere deskundigen op het gebied van ontwikkeling en toepassing van CAD software. In aIle gevallen is positief gereageerd op zowel het produkttypemodel als de wijze waarop in de demonstratie wordt aangetoond hoe op basis hiervan een produktmodel kan worden opgebouwd en deze informatie kan worden gecommuniceerd. Een algehele conc1usie omtrent het prototype en de demonstratie is, dat dit resultaat van het NOBIIBM onderzoek een waardevol demonstratiemiddel kan zijn bij het aantonen van de mogelijkheden van produktmodelleren in de dagelijkse praktijk van architecten en communicerende partijen in het ontwerpproces. Daarnaast kan deze demonstratie een stimulans zijn voor betrokkenen in de ontwikkeling van bouwkundige software. Het concept van produktmodelleren zoals aangetoond in het prototype en de demonstratie van proces en mogelijkheden van de communicatie op basis van produktmodeIlen kunnen ondersteuning geven bij de ontwikkeling en onderlinge aansluiting van eigen modellen en software.

68

TUE' Building Infonnation Technology

10

BIT Notes

Conclusies en aanbevelingen.

De gewenste resultaten zijn, zoals uit de verschiIIende toetsingen is gebleken, bereikt. De resultaten zijn enerzijds het NOBI Bouwkundig Model voor het Intechnokantoor. beschreven met behulp van informatieanalysetechniek NIAM en anderzijds het prototype waarmee dit model is getoetst. Tevens kan het prototype in het vervolg worden gebruikt voor demonstraties aan bouwkundigen en informatici om het concept 'ontwerpen op basis van produktrnodellen' inzichtelijk te maken en om ontwikkeIingen op dit gebied te stimuleren. De toetsing van het NOBI Bouwkundig Model heeft in het totaal driemaal plaatsgevonden. Eenmaal voor leden van de sectie BouwInformatica aan de Technische Universiteit Eindhoven, eenmaal voor de NOBIIBM commentaargroep en eenmaal voor leden van de Fanfare II werkgroep. De meeste reacties zijn positief te noemen. Het prototype sluit goed aan op de resultaten van het NOBIIBBB onderzoek en kunnen in het vervolg gezamenlijk worden gedemonstreerd. Daarmee winnen beide onderzoeksresultaten enorm aan waarde omdat het principe van communicatie op basis van productmodellering duideJijker naar voren komt. Ook de gegevensuitwisseling met de installatietechnisch adviseur (VABI) wordt goed ondersteund en inzichtelijk gemaakt Het NOBI Bouwkundig Model bevat aile essentiele entiteittypen en biedt een oplossing voor het probleem van de ruimtebenadering enerzijds en de bouwcomponentenbenadering anderzijds. Met name de waardevolle bijdrage van het prototype als een vorm van technische implementatie van de informatiemodellen is in dit onderzoek sterk naar voren gekomen. Voor velen zijn de informatiemodellen erg abstract en hoewel bedoeld als ondersteuning voor communicatie werken ze voor minder ingewijden veelal averechts. Deze person en hebben grote behoefte aan prototypes om een duidelijke beeld te krijgen van de materie. De verplichting binnen het NOBI om theoretische resultaten te vertalen naar een technisch prototype mag bijzonder succesvol worden genoemd. Een belangrijk resultaat van het onderzoek zijn ook de vele knelpunten die duidelijk naar voren komen wanneer over deze materie wordt nagedacht. Andere projecten, bijvoorbeeld het NOBIIABI, kunnen of hebben hier reeds direct of indirect gebruik van gemaakt. Er is dan ook sprake van een duidelijke wisselwerking met andere NOBI projecten. Zo zuBen de in dit rapport gepresenteerde resultaten worden verwerkt in het ABI project en zullen toekomstige resultaten uit het ABI leiden tot bijsteIlingen en toevoegingen van het NOBI Bouwkundig Model. De gevonden knelpunten geven een goed beeld van verschillende belangrijke aandachtgebieden die nader moeten worden bestudeerd ten behoeve van de ontwikkeling van toekomstige bouwkundige informatiesystemen op basis van productrnodellering. De aanbevolen aandachtsgebieden zijn: •

De werkwijze c.q. ontwerpmethode van architecten op basis van productrnodellering

•

Classificatie van de diverse entiteittypen, met name aansluiting en bouwdelen

•

Het mechanisme van de transformatie van hogere abstractienivo's naar lagere abstractienivo's inclusie het tijdsaspect.

•

Geometrisch model in relatie tot 3D modelleren en hoeveelhedenextractie.

•

Eenduidige beschrijving en classificatie van prestatie-eigenschappen

•

De informatietechnische beschrijving, structurering en verwerking van procedurele kennis.

•

Beschrijving c.q. ontwikkeling van CADsystemen die productrnodellering kunnen ondersteunen

Tot slot willen we aansluiten op de uitspraak "Produktrnodellering blijkt een zaak van een lange adem" uit het NOBIIBBB rapport. In dit licht bezien is naast het NOBIIBBB model ook het NOBI Bouwkundig Model een succesvolle bijdrage aan dit proces, maar zeker geen eindstation.

,

69

I

\

\


BIT Notes

Gebruikte Iiteratuur [01]

Augenbroe, G., 1991 Integrated building performance evaluation in the early design stages., Preproc. First international symposium on 'Buildings Systems Automation·lntegration'., 1991

[02]

Bjork, B.C., 1989 Basic structure of a proposed building product model. Artikel in Computer Aided Design, volume 21, nr. 2, pp. 71·79, march 1989.

[03]

Bjork, B.C., 1992 The RATAS project -an example of co-operation between industry and research towards computer integrated construction. Draft of a paper., oktober 1992.

[04]

Bjork. B.C., 1992 A conceptual model of spaces, space boundaries and enclosing structures. Artikel in Automation in Construction I, pp. 193-214, 1992.

[05]

Bouwcentrum Rotterdam, 1984 NUSfB classificatiesysteem.

[06]

Deiman, E.P., Smeltzer, G.T.A .• Vriens. B., 1992 Rapportage inventarisatie ten behoeve van het Fanfare-project. 1992.

[07]

Dubois. A., 1992 COMBINE integrated datamodel. volume I V.3.3, CSTB, 1992

[08]

Dubois, A., 1992 COMBINE integrated datamodel, volume II V.3.3, CSTB, 1992

[09]

Eastman, C.M., et al., 1991 Product information models.

[10]

Eastman, C.M.• 1992 A datamodel analysis of modularity and extensibility in building databases., Environment and building, 1992. Eastman, C.M., 1993 Life cycle requirements for building product models. Artkel in Management of information technology for construction. pp.369-390, august 1993.

[11]

[12]

Eilers, A.B., 1989 Systeemontwikkeling op kleinere schaal met SDM, Academic service, 1989.

[13]

Harfmann, AC., et al., 1993 A component-based approach to building product representation and design development. ArtikeI in CAAD-futures '93.

[14]

Houtsma, E.O., et ai., 1979 Een rekenmodel van de samenhang tussen gebouwonderdelen., SBR-rapport A20-1., 1979.

[15]

Hubers, H., 1993 Inhoud presentatie bouwkundig modeL, februari 1993.

[16]

ISO, 1993 Classification of information in the construction industry. ISO technical committee 59SC13WG2, Draft, march 1993.

[17]

Jutte, A.C., et aI., 1993 Bestek en P(E)DI, Het besteksanalysemodel., maart 1993.

70


BIT Notes

[18]

Nederveen, S. van, Bakkeren, W., Luiten, B., 1993 Infonnation models for integrated design. Artikel in CAAD-futures '93.

[19]

Neuteboom, J., 1993 Werkdocument NOBI/ABI raamwerk, versie OJ, april 1993.

[20]

Neuteboom, J., 1993 Het DUS-model, 2 e versie, mei 1993.

[21]

NNI, 1989 NVN 2574: Indeling van gegevens op tekeningen.

[22]

NNI, 1993 Ordeningsprincipes voor een infonnatiesysteem voor de bouw. Werkdocument van nonncie. 352.25 'Classificatie in de bouw'., Delft, maart 1993.

[23]

NNI, 1993 Ontwerp NEN 2660 'Infonnatiesysteem voor de bouw. Tennen, defmities en algemene regels.', Delft, mei 1993.

[24]

SBR, 1993 Projectplan NOBI versie 2. 'Plan ter uitvoering van het nationaal onderzoekskader bouwinfonnatica., januari 1993.

[25]

SBR, 1990 Infonnatie-overdracht via tekeningen, publicatie 211 , Rotterdam 1990.

[26]

Stichting Bouwkwaliteit, 1991 Elementenmethode '91.

[27]

TNO-bouw, 1992 Afsprakenstelsel bouwinfonnatica (ABI) versie 0.2, september 1992

[28]

TNO-bouw, 1992 Projectplan afsprakenstelsel bouwinfonnatica., versie december 1992.

[29]

Tolman, F.P., et aI., 1992 Modelling multiple views on buildings. Artikel in Automation in Construction 1., pp. 215-224, 1992.

[30]

VABI,1991 DUS-boek, fase 3 versie 1.00, Beschrijving van een data-uitwisselings-systeem voor de bouw en installatietechniek., Delft, mei 1991.

[31]

VCA, 1993 NOBI·BBB project. Bouwkosten en bestek. Opgestelde rapporten.

[32]

VCA, 1993 Inventarisatieoverzicht NOBIIBM., juli 1993.

[33]

Waard, M. de, 1992 Computer aided confonnance checking: checking residential building designs against building regulations with the aid of computers. Phd-thesis, TUD, 1992.

[34]

Wintraecken, J.J.V.R., 1986 Infonnatieanalyse volgens NIAM in theorie en praktijk. Academic service, 1986.

71


BIT NoleS

[35]

Wix, J., McLelland, C., 1987 Data exchange between computer systems in the construction industry., 1987.

[36]

Woestenenk, K. et aI. 1993 DUS 5: specificeren, klassificeren en koderen. Deelproject B. Het uitwerken van een classificatiestructuur ten behoeve van objectspecificatie.

[37]

Woestenenk, K., 1993 Bouwdelen, elementen en resultaten. Artikel geschreven in opdracht van de VCA, mei 1993.

[38]

Zutphen, R. van, Dijkstra, J., 1991 Ontwikkeling van informatiesystemen in de bouw. Collegedictaat Technische Universiteit Eindhoven., 1991.

72

t:=

c::: ~

~

> ..

is onderdeel von

'Wordt ,evormd door

is onderdeeJ 1I'an hoort bll

i. onderdeel van


BIT Notes

Bijlage B: Definities van begrippen, versie 3.1. In onderstaande lijst worden definities van begrippen gegeven zoals ze in en in relatie met het NOBIIBM worden gehanteerd. Deze definities worden aangeduid met NOBIIBM. Naast de definities voor het NOBIIBM zijn per begrip, ter vergelijking ook definities opgenomen van gelijksoortige begrippen die zijn gedefinieerd in de volgende publikaties. ISO ISO TC59 SC13 WG2 Classification of information in the construction industry, maart 1993. NNI ontwerp NEN 2660, aug. 1993. ABI Afsprakenstelsel BouwInformatica 0.3, oktober 1993. (In het ABI worden verschillende modellen behandeld, waarbij niet bij aIle modellen definities van gebruikte begrippen worden gegeven. De definities die in het ABI gegeven zijn bij de behandeling van het NOBIIBBB model worden hier gerefereerd met de aanduiding BBB. De vertalingen in het ABI van de begrippen uit het ISO document worden bij de ISO definities aangegeven.) BBB VCA, NOBIIBBB-project, rapport Begrotingstheorie Gebouwmodel Aanvulling, maart 1993. Bjork Bo-Christer Bjork, "A conceptual model of spaces, space boudaries and enclosing structures" in Automation and construction, vol. 1 nr. 3, dec. 1992. In VABIIDUS, fase 4 versie 2.00, april 1992, wordt, behalve voor het distributiemodel, geen definitie van begrippell uit de modellen gegeven. De objecttypen uit de aspekt-type modellen worden aileen formeel beschreven door eell opsomming van de bijbehorende attributen.

gebouw NOBIIBM ISO

Bjork

gebouwdeel NOBIIBM

element NOBIIBM

ISO

NNI BBB

Bjork

ruimte NOBIIBM

ISO

NNI

Een gebouw is een netwerk van ruimten en bouwdelen, gesitueerd in een omgeving. (gedefinieerd als voorbeeld van een 'facility') [A facility is] a physical structure or installation, including related site works, serving one or more main purpose. A building is a facility comprising partially or totally enclosed space and providing shelter. ABI: building facility = gebouw-faciliteit, gebouw. (building) A network of spaces separated by building elements.

Een gebouwdeel is eenfunctionele aggregatie van ruimten en bouwdelen. (bijvorbeeld een verdieping, de verzameling kantoren, openbare ruimten, etc.).

Fysiek deel van een bouwwerk, met een ruimtescheidende, ruimteconditionerende ofruimteinrichtende functie. Een element kan meerdere bouwdelen bevatten. Elementen worden geclassificeerd volgens tabel1 van de NL-SfB classificatie, beschreven in "Elementenmethode '91", SBK, 1992. (elements) The major physical parts and systems of a building or other facility, each with a characteristic function. Elements are considered without regard to the type of technical solution or the method or form of construction. ABI: element = element. (element) Fysiek deel van een bouwwerk, met een ruimtescheidende, ruimteconditionerende of ruimte-inrichtende functie. Een element is gekenmerkt door zijn functie. (element) De voomaamste fysieke onderdelen en systemen van een gebouw, met een eigen specifieke locatie en/of functie. Elementen hebben een algemeen geldend karakter zonder dat wordt ingegaan op de specifieke technische oplossing, materialisatie of konstruktiemethode. (enclosing entity) An abstract supertype for all kinds of objects and assemblies of objects which form spaces by functioning as space boundaries. Een ruimte is een gebied, beperkt door al dan niet fysieke ruimtebegrenzingen. Een ruimte kan zich buiten het gebouw bevinden of binnen her gebouw. Ruimtes kunnen worden opgebouwd uit andere ruimtes. (spaces) Three dimensional spaces within and around buildings and other facilities, bounded actually or theoratically. (ruimte) Gebied, al dan niet fysiek begrensd door vloeren, wanden en andere ruimtescheidende middelen, en bestemd voor gebruik door mensen, dieren, installaties of opslag.

74


BBB

Bjork

BIT Notes

(ruimte) Een ruimte is een gebied, al dan niet fysiek beperkt door vloeren, muren en andere ruimtescheidende middelen. Een ruimte kan zich buiten het gebouw bevinden ofbinnen het gebouw. Zo'n interne ruimte kan zijn opgebouwd uit een of meerdere vertrekken of een deel van een vertrek. Een ruimte wordt gerelateerd aan het bouwprojekt en aan de elementen die een ruimte bevat. Ruimtes kunnen worden opgebouwd uit andere ruimtes. (space) A volume bounded on all sides by invlosing structures, which forms the physical sp ace boundaries of the space. (NB. bij de definitie van een ruimtebegrenzing voegt Bjork toe dat ook imaginary space boundaries bestaan voor subspaces.)

bouwdeel NOBIIBM

ISO

NNI BBB

Een bouwdeel is eenfysiek onderdeel van een gebouw met een specifieke locatie enfunctie. Een bouwdeel kan gematerialiseerd zijn door technische oplossingen. Door middel van een recept kan een bouwdeel worden gedecomponeerd in middelen. (work sections) One or several physical parts of a building or other facility viewed as the result of particular skills and techniques applied to particular construction products and/or elements during the production phase. ( ... ) The class is influenced by both inputs (e.g. the construction products used) and outputs (the parts of the building or facility constructed), and thus represents a dual concept. ABI: work section = bouwdeel. (resultaat) Fysiek deel van een bouwwerk, met een ruimtescheidende, ruimteconditionerende of ruimte-inrichtende functie. Een resultaat is gekenmerkt door zijn samenstelling. (bouwdeel) Een bouwdeel is een fysiek en gematerialiseerd onderdeel of systeem van een gebouw, dat beschouwd kan worden als een te onderscheiden kostendrager in het bouwvoorbereidingsproces. Een bouwdeel maakt onderdeel uit van een element. Een bouwdeel onderscheidt zich van een element doordat een bouwdeel door de materialisatie een specifieke functie heeft in de begroting en bestek.

begrenzend bouwdeel Een begrenzend bouwdeel is een bouwdeel dat gedeeltelijk of in zijn geheel functioneert als de begrenzing van een of meerdere ruimten.

NOBIIBM Bjork

(enclosing structure) An aggregation of objects which forms the space boundaries of two or more individual spaces. An enclosing structure should be continuous and fairly uniform in its internal structure.

niet begrenzend bouwdeel Een niet begrenzend bouwdeel is een bouwdeel dot geen ruimte begrenzende functie vervult.

NOBIIBM

aansluiting NOBIIBM

Wanneer twee of meer elementen of bouwdelen samenkomen is er sprake van een aansluiting.

ruimtebegrenzing Een abstract concept dat de begrenzing van een ruimte representeert, 01 dan niet gevormd door fysieke bouwdelen. Bjork (space boundary) An abstract concept which represents a part of the infinitesimally thin skin

NOBIIBM

which surrounds a space or enclosing structures that bounds it. Subspaces can in addition to physical boundaries also have imaginary space boundaries.

gat NOBIIBM

Bjork

Een got is een opening in een ruimtebegrenzing. Er zijn twee subtypen van gaten: openingen en sparingen. Een opening is een got dot kan worden gevuld door een begrenzend bouwdeel (bijvoorbeeld met een specifiekefunctie zoals het verlenen van toegang tot de ruimte). Een sparing dient voor het doorlaten van een niet begrenzend bouwdeel (bijvoorbeeld een onderdeel van een distributie systeem), of kan leeg worden gelaten. waardoor de ruimte ter plaatse van het got niet fysiek wordt begrensd. (hole) A void volume which forms part of an enclosing structure. Is usually filled by a door, window or pierced by HVAC ducts. Can also in some instances be left empty.

distributiesysteem

75

TUEI Building Information Technology

NOBIIBM

BIT Notes

Niet begrenzende bouwdelen worden onderscheiden naar bouwdelen die een distributiesysteem, lOals bedoeld binnen de VAB/, vormen en overige niet begrenzende bouwdelen.

recept

NOBIIBM

Een recept beschrijft de samenhang tussen een bouwdeel en de mUlde len die de materialisatie van dat bouwdeel vormen. Indien in een recept middelen voorkomen die op zich weer bouwdelen zijn, is daarbij uitgesloten dat het recept de beschrijving van een van deze bouwdelen is.

middel

NOBIIBM

Een middel vormt een materialisatie van (een deel van) een bouwdeel. Een middel kan wederom een bouwdeel zijn (waarvan verdere materialisatie kan worden gespecificeerd) of worden gevormd door een materiaal. (NB. In BBB worden naast materiaal ook de middelen arbeid en materieel onderscheiden, deze zijn echter in het BM niet relevant en kunnen derhalve buiten het model worden gehouden.)

ISO

(construction products) Products, components and 'kits of parts' incorporated or intended for incorporation into buildings or other facilities, invluding furniture and equipment. ABI: construction product =bouwstof, component. (middel) Wat nodig is voor het tot stand brengen van een bouwwerk. Middelen zijn de samenstellende delen van een bouwdeel, terugkomend in het bouwdeelrecept als aparte gedefinieerde en gecodeerde regel, eenheidsprijs en gegeven eenheid. Middelen zijn onder te verdelen naar materiaal, arbeid en materieel. (component) A clearly delimited part of an enclosing structure, which often is prefabricated and fastened to other components on site using joints or seams. In some border cases the same component can be a part of several enclosing structures at the same time.

NNI BBB

Bjork

materiaal

NOBIIBM

Materiaal is een onderdeel van een bouwdeel dat onafhankelijk van her bouwdeel kan worden gespecificeerd, geproduceerd en geleverd.

NNI

(toeleveringsprodukt) Verkrijgbaar produkt dat wordt verwerkt in een ander produkt. (materiaal) Niet relevant voor NOBIIBBB, anders dan in de omschrijving van de objecten.

BBB

76

TUE / Building Infonnation Technology

BIT Notes

Bijlage C: (Meta)modellen van mogelijke oplossingen voor weergave van 'gewenste' c.q. 'gerealiseerde waarde.

entiteitJ'S

enLentJs

entiteit

entileiLTS

FiguurC.l

V ABIJDUS functionele en technische specificaties

project

L -___e_nu_.t_el_t__

~~b-e-ef-t---9~___a_tm_._bu_u_t__~~--

gerealilleorde waarde

referentie

FiguurC.2

NOBIIBBB attributen

no I'll'Rl'live

FiguurC.3

NOBIIBM attributen metamodel: gewenste en gerealiseerde waarde

77

NOBI I BM PROJECT: HET INTECHNO BOUWKUNDIG l\:fodel

Recommend Documents