1

De COINS-systematiek Deze publicatie bevat de beschrijving van de COINS-systematiek. Dit betreft een verzameling werkmethoden en informatieafspraken ten behoeve van de totstandkoming van bouwwerken. Het doel van deze afspraken is het mogelijk maken van procesverbetering en betere benutting van informatie. De COINS-systematiek bevat de afspraken met een algemeen karakter en geldigheid. Voor specifieke toepassingen zullen aanvullende afspraken in de vorm van COINS-referentiekaders beschikbaar gesteld worden.

De COINS-systematiek is door de COINS-projectgroep als concept vrijgegeven in april 2008. Kritiek, commentaar, discussie, suggesties en vragen met betrekking tot de COINS-systematiek zijn van harte welkom; gebruik hiervoor ons forum: http://www.coinsweb.nl/modules/newbb/.

Colofon De COINS-systematiek, Concept publicatie – april 2008 De systematiek rondom gebruik van bouwinformatie, opgesteld door de projectgroep COINS

Auteurs: H.A. Schaap J.W. Bouwman P.H. Willems

De COINS-systematiek is ontstaan door bijdragen van o.a.: Arjen Adriaanse, Wouter Ariëns, Radboud Baayen, Gerard Bakker, Jacob Beetz, Wouter den Besten, Jan Beumer, Steven Beune, Marco van Bijnen, Wilbert Blom, Peter Bonsma, Jan Bouwman, Henk Burggraaff, Frans van Dam, Mark Damen, Dick Dokter, Piet van Dongen, Richard Doornekamp, René Dorleijn, Leo van Geffen, Frans de Graaf, Hans Hendriks, Jos Houtvast, Sipke Huitema, Peter van Hulten, Paul Jansen, Aad Jongbloets, Hans Jongedijk, Henk Kersten, Peter van Keulen, Olaf Kok, Bart Koster, Dick de Kreek, Matty van Leeuwen, Marc van Leusen, Thomas Liebich, Gerrit Luiten, Gert-Jan van Manen, Roy Meenhuis, Camiel Meijneken, Hans Moll, Bram Mommers, Gerrie Mühren, Martin Murre, Sander van Nederveen, Leo Nieuwenhuizen, Wim Nijman, Herman Oogink, Willem Pel, Myrte Post, Ton van Riezen, Renzo van Rijswijk, Henk Schaap, Wim Scheele, Jasper Schilder, Ton Schillemans, Krijn Smallenburg, Theo Specker, Gé Spees, Karel Veenvliet, Henk Vereijken, Cor Visser, Bauke de Vries, Peter Willems, Bernard Witteveen, Bert de Wolde, Wilfred Wolf, Wilfred van Woudenberg.

CUR-rapport 208-3

© De COINS-systematiek is een uitgave van COINS-programma, CUR Bouw & Infra, Gouda. Inlichtingen: CUR Bouw & Infra, Tel +31 182 540 600, e-mail info@cur.nl

De COINS-systematiek is een open standaard. Over de inhoud van de standaard kan vrijelijk worden beschikt. Er zijn geen beperkingen omtrent het hergebruik van de standaard.

DISCLAIMER: De voorliggende publicatie is samengesteld voor gebruik door personen met deskundigheid in diverse voorkomende disciplines. Het gebruik van de publicatie is geheel voor eigen risico. CUR Bouw & Infra kan op geen enkele wijze verantwoordelijk gehouden worden voor fouten in de publicatie en/of fouten als gevolg van het gebruik van de publicatie.

2

Inhoudsopgave 1. Inleiding en achtergrond – bldz. 3 2. Algemene beschrijving van de systematiek – bldz. 7 3. Producten van het COINS-programma – bldz. 26 4. Formele beschrijving van de systematiek – bldz. 32 5. Beschrijving uitwisselingsformaat – COINS Container – bldz.49 6. Voorbeeld ‘Utility Ducts’ – bldz. 62 7. Termen en definities – bldz. 71 8. FAQ - Vaak gestelde vragen – bldz. 73

3

Inleiding en achtergrond

Inhoud 

• 1 Inleiding • 2 Waarom COINS? • 3 Positie t.o.v. andere initiatieven/ontwikkelingen • 4 Leeswijzer

Inleiding 

Deze publicatie bevat de beschrijving van de COINS-systematiek. Dit betreft een verzameling werkmethoden en informatieafspraken ten behoeve van de totstandkoming van bouwwerken. Het doel van deze afspraken is het mogelijk maken van procesverbetering en betere benutting van informatie. De COINS-systematiek bevat de afspraken met een algemeen karakter en geldigheid. Voor specifieke toepassingen zullen aanvullende afspraken in de vorm van COINS-referentiekaders beschikbaar gesteld worden.

De eindgebruiker vindt in deze publicatie de principes achter COINS, waaronder principes voor virtueel bouwen en uitgangspunten voor een breed toepasbare informatiestructuur. De projectleider vindt daarnaast de principes die relevant zijn voor informatiemanagement en projectorganisatie. Hoewel er thans nog geen COINS-compatible hulpmiddelen beschikbaar zijn, vindt de projectleider toch uitgangspunten om de COINS werkmethode met reeds beschikbare hulpmiddelen toe te passen. De ICT-deskundige vindt een meer formele beschrijving van de uitgangspunten, zodanig dat een COINS-compatible omgeving opgezet kan worden. Tenslotte is ter illustratie een praktijkvoorbeeld opgenomen.

Deze publicatie is samengesteld in het kader van het COINS-programma hetgeen een projectorganisatie is onder de vlag van CUR Bouw & Infra. Alle auteursrechten zijn eigendom van CUR Bouw & Infra.

De COINS-systematiek is een publicatie die onderdeel vormt van een serie publicaties die voortkomen uit het COINS-programma. Dit betreft thans:

• COINS-systematiek • Functioneel specificeren met behulp van het COINS Referentiekader • Ramen van hoeveelheden met behulp van het COINS Referentiekader

DISCLAIMER: De voorliggende publicatie is samengesteld voor gebruik door personen met deskundigheid in diverse voorkomende disciplines. Het gebruik van de publicatie is geheel voor eigen risico. CUR Bouw & Infra kan op geen enkele wijze verantwoordelijk gehouden worden voor fouten in de publicatie en/of fouten als gevolg van het gebruik van de publicatie.

4

Waarom COINS? 

Het COINS-programma is een initiatief van de bouwsector voor de bouwsector. De ambitie is om bij te dragen aan procesvernieuwing in de bouw. Het streven is om het bouwproces te verbeteren door slim gebruik mogelijk te maken van de informatie van 3D-bouwobjecten. Om dit doel te bereiken ontwikkelt COINS sectorbrede afsprakenstelsels over informatie van 3D-bouwobjecten en afsprakenstelsels over werkwijze. In het COINS-programma wordt een aansluiting gemaakt op vier ontwikkelingen die belangrijk zijn voor de bouwsector. Deze ontwikkelingen zijn: systems engineering, objectbenadering, 3D-modelleren en procesintegratie. De aansluiting op deze ontwikkelingen komen tot uiting in de afspraken die sectorbreed beschikbaar gesteld worden.

Waarom COINS? In industrieën zoals de scheepsbouw, proces industrie en automotive, is de toepassing van 3D-objecten in combinatie met Product Data Management ver doorgedrongen. Deze werkwijze heeft geleid tot spectaculaire verbeteringen. Het aantal fouten is gereduceerd, de flexibiliteit is toegenomen en de concurrentiepositie is versterkt. Projectpartners in de bouw hebben ervaren dat de wijze waarop nu de communicatie en samenwerking is ingericht, een belangrijke oorzaak is van de grote foutgevoeligheid van de informatiestroom. De bouw kan leren van de ervaringen van andere industrieën. In 2003 kwam een aantal vertegenwoordigers uit de Nederlandse bouw met een plan om afspraken te ontwikkelen voor het werken met 3D-objectinformatie. Dit plan vormde het begin van wat nu bekend staat als “COINS”.

De projectgroep COINS heeft vervolgens een stap gemaakt door een inventarisatie uit te voeren van de state-of-the-art en een onderzoek te doen naar de haalbaarheid van de toepassing van een 3D-objectbenadering voor procesintegratie. In 2006 werden de bevindingen van de COINS-projectgroep gepubliceerd in een rapport met de titel Toekomst voor het bouwproces, Een 3D-objectbenadering.

Rapport: "Toekomst voor het bouwproces"

Een belangrijke bevinding uit het rapport was dat het toekomstbeeld van een geïntegreerd bouwproces alleen kans van slagen heeft als er afspraken beschikbaar komen, die waarborgen dat werkwijze en informatie van partners op elkaar aansluiten. In vervolg daarop zijn door de COINS-projectgroep dergelijke afspraken ontwikkeld en beproefd. Deze publicatie is een onderdeel van de resultaten.

5

Waar staat COINS voor? COINS is de afkorting van ‘Constructieve Objecten en de INtegratie van processen en Systemen’. Het COINS-programma heeft de volgende doelstellingen:

• Het beschikbaar maken van werkmethoden en informatieafspraken die nodig zijn om het bouwproces te ondersteunen;

• Om daarmee een gemeenschappelijke basis te bieden voor het gebruik van objectinformatie en de integratie van het bouwproces.

• Uitgangspunten te bieden voor een efficiënter en beter bouwproces en betere benutting van investeringen in informatie- en communicatietechnologie (ICT).

Het COINS-programma wordt uitgevoerd door de projectgroep COINS met daarin vertegenwoordigers van opdrachtgevers, bouwbedrijven, ingenieursbureaus, netwerk organisaties en kennisinstellingen. Daarnaast nemen IT-bedrijven deel.

Positie t.o.v. andere initiatieven/ontwikkelingen 

COINS staat niet op zichzelf; de standaard heeft een samenhang met standaards die nationaal en internationaal ontwikkeld worden, in het bijzonder VISI, IFD, IFC en IDM. Eén en ander kan duidelijk gemaakt worden als we bekijken voor welke toepassingebieden de diverse standaards relevant zijn:

• VISI heeft de focus op het proces en de informatie die betrekking heeft op het nemen van besluiten (management communicatie); dergelijke besluiten kunnen betrekking hebben op het bouwwerk of delen daarvan. Zie ook http://www.visi.nl.

• COINS heeft de focus op het proces en de informatie die betrekking heeft op het bouwwerk (object communicatie)

• Bij het ontwerpen van een bouwwerk is het aantrekkelijk om gebruik te kunnen maken van bibliotheken met beschrijvingen van te gebruiken onderdelen en leveranciersgegevens; voor dergelijke bibliotheken is in internationaal kader de standaard IFD (International Framework for Dictionaries) in ontwikkeling. In nederland worden volgens deze standaard, bibliotheken ontwikkeld door Stabu en CROW. Voor een toelichting op IFD, zie: http://dev.ifd-library.org/index.php/Ifd:IFD_in_a_Nutshell.

• Een onderdeel van de beschrijving van een bouwwerk betreft de 3D-vormgeving. Internationaal wordt hiervoor de IFC standaard ontwikkeld. COINS heeft deze standaard geadopteerd voor 3D-representatie.

• In internationaal kader is men zich er van bewust geworden dat bij communicatie tussen bouwpartners niet alleen informatieafspraken gemaakt moeten worden, maar ook procesafspraken overeengekomen moeten worden. Voor dat doel is de standaard IDM (Information Delivery Manual) in ontwikkeling. Door de organisaties achter VISI en COINS wordt geparticipeerd in deze ontwikkeling.

6

Toepassingsdomeinen en relevante standaarden

Leeswijzer 

Hoofdstuk 2, "Algemene beschrijving van de systematiek" geeft een inleiding op de principes, werkmethoden en informatieafspraken die opgenomen zijn in de COINS-standaard. Aan de orde komen: Virtueel bouwen als proces, Systems engineering, Project organiseren en Informatie managen. Dit hoofdstuk is bedoeld als algemene introductie voor een breed publiek, zoals projectleiders, toepassers en ICT-deskundigen. Hoofdstuk 3 gaat in op de producten die de COINS-organisatie beschikbaar stelt en hoe die gebruikt kunnen worden. Dit hoofdstuk is geschreven voor projectleiders en ICT-deskundigen. Een toelichting wordt gegeven op de COINS-systematiek als algemene basis en COINS-Referentiekaders als aanvullingen voor specifieke toepassingsgebieden. Voorts komt aan de orde hoe de producten gebruikt worden bij: Voorschrijven van Informatieoverdracht, Inrichten van een Bouwwerk Informatiesysteem, en bij het organiseren van een project. De hoofdstukken 4 en 5 zijn technisch van aard en vooral bedoeld voor ICT-deskundigen. Hoofdstuk 4 geeft een formele beschrijving van de COINS-systematiek. In hoofdstuk 5 wordt een beschrijving gegeven van het COINS-uitwisselingsformaat. Tenslotte geeft hoofdstuk 6 een beknopt voorbeeld van de toepassing van de COINS-standaard bij het 'Utility Ducts project'.

7

Algemene beschrijving van de systematiek

Inhoud 

• 1 Inleiding • 2 De virtuele omgeving • 3 Virtueel bouwen als proces

o 3.1 De aanleiding o 3.2 Stappen in het Virtueel Bouwen

• 4 De kern van de COINS-systematiek: het bouwwerk o 4.1 De kern van de COINS-systematiek o 4.2 Het bouwdeel

• 5 Aansluitingen en verbindingen • 6 3D-geometrie van bouwdelen • 7 Functies, eisen en prestaties • 8 Ruimtes • 9 Informatie management en het virtuele bouwwerk

o 9.1 De toepassing van Baselines o 9.2 De toestand van een bouwdeel o 9.3 Creëren en wijzigen van informatieobjecten

9.3.1 De versie en status van een informatieobject 9.3.2 De relaties tussen creëren/wijzigen, vrijgeven en publiceren

o 9.4 Besluiten expliciet vastleggen o 9.5 Informatie uitwisselen

• 10 Een bouwproject organiseren • 11 Bevoegdheden

Inleiding 

Dit hoofdstuk geeft een inleiding op de principes, werkmethoden en informatieafspraken die opgenomen zijn in de COINS-systematiek. Aan de orde komen: Virtueel bouwen als proces, Systems engineering, Project organiseren en Informatie managen. Dit hoofdstuk is bedoeld als algemene introductie voor een breed publiek, zoals projectleiders, toepassers en ICT-deskundigen.

De virtuele omgeving 

Dit hoofdstuk heeft de titel "Virtueel bouwen en COINS" gekregen. Virtueel bouwen is een kreet die staat voor het beeld dat een bouwwerk eerst zoveel mogelijk in een digitale omgeving wordt vastgelegd, alvorens de werkelijke bouw plaatsvindt. Dit virtuele/digitale bouwwerk is het resultaat van het specificeren en ontwerpen en vormt het uitgangspunt voor inkoop, logistiek, realisatie, kwaliteitsborging etc.

Het virtuele bouwen vindt plaats in een digitale omgeving die geschetst kan worden als in het volgende plaatje.

8

Door middel van het Internet wordt de informatie van een bouwwerk toegankelijk gemaakt door middel van een Bouwwerk Informatiesysteem. Dit Bouwwerk Informatiesysteem is Coins-compatible, hetgeen wil zeggen dat het systeem de werkmethoden en informatieafspraken van de COINS-systematiek ondersteunt. Bij de totstandkoming van het bouwwerk zijn verschillende partners betrokken. Ook deze partners zijn Coins-compatible. Partners kunnen daardoor moeiteloos informatie uitwisselen met elkaar en met het centrale informatiesysteem.

De communicatie tussen partners en het centrale Bouwwerk Informatiesysteem is real-time of verloopt via batch-gewijze informatieoverdracht. In het geval van batch-gewijze informatieoverdracht wordt het Coins-container uitwisselingsformaat gebruikt.

De COINS-systematiek bevat twee onderdelen. Dat betreft:

• Een verzameling werkmethoden die de naam COINS Engineering heeft gekregen, of kortweg CEM

• Een informatiemodel dat de naam COINS Bouw Informatiemodel heeft gekregen, of kortweg CBIM.

De werkmethoden hangen nauw samen met het informatiemodel. In de volgende hoofdstukken worden vooral de werkmethoden besproken.

Virtueel bouwen als proces 

In het Activiteitenschema Bouw, zoals dat ook al in voorgaande publicaties is gepresenteerd, is aangegeven welke acitviteiten een rol spelen in het totale bouwproces, en welke ondersteund worden door het Bouwwerk Informatiesysteem dat ingericht is volgens de COINS-systematiek. Dit is in de figuur hieronder nogmaals weergegeven:

9

Zodra het Bouwwerk Informatiesysteem in de processen van de Bouwwerk Leverende wordt ingezet is er sprake van Virtueel Bouwen. We gaan die stappen wat meer in detail na en beginnen linksboven in het schema.

De aanleiding 

Het bouwtraject begint met een probleem. Iemand, wil die ongewenste situatie omvormen naar een gewenste situatie. Om dit goed te kunnen doen, moet er eerst bepaald worden op welke wijze deze ongewenste situatie ongedaan gemaakt kan worden. Deze activiteiten vinden plaats in het domein van de instelling die het probleem heeft en ook (zelf) gebaat is bij de oplossing hiervan (de Belanghebbende). Vaak wordt hiervoor de term Opdrachtgever gebruikt, maar eigenlijk is dat niet juist of niet volledig, want een opdrachtgever bestaat uiteraard pas wanneer er een opdracht is gegeven, en dat is in het begin van het traject nog niet het geval.

Waar het om gaat is dat de Belanghebbende (ook wel Originele Probleem Eigenaar genoemd) in algemene zin verantwoordelijk is voor de uitvoering een proces waarvan de voortgang wordt belemmerd (= een ongewenste situatie). Hij heeft verstand van dat proces en hij heeft inzicht in de manier dat proces het beste kan worden uitgevoerd. Hij kan ook bepalen hoe de gewenste situatie er uit moet komen te zien, want dat hoort bij zijn vak. Kortom, de Belanghebbende is in staat om het probleem te beschrijven, de doelen waaraan de oplossing moet voldoen te formuleren. Hij heeft kennis van het (primaire) systeem waarin de oplossing moet passen, hij heeft inzicht in de vrijheden (en beperkingen) die hij heeft en welke oplossingsrichtingen tot de mogelijkheden behoren en welke niet.

Aan de hand van deze gegevens en inzichten bepaalt hij en kiest hij een oplossingsrichting en formuleert daarbij wat deze oplossing moet kunnen om werkelijk een oplossing voor zijn probleem te zijn. Kortom: hij formuleert gewenste functies, de eisen die daarbij horen, de randvoorwaarden en condities en betrekt daarbij zoveel mogelijk de wet- en regelgeving maar ook standaarden vanuit zijn primaire proces en, indien noodzakelijk, de mogelijke locaties van uitvoering. Deze oplossingsrichtingen kunnen zeer gevarieerd zijn, maar pas wanneer deze oplossingsrichting een bouwwerk betreft komen we binnen de grenzen van COINS.

10

Voorbeeld: Het ontwikkelen van een nieuwe onderwijsmethode of het invoeren van een nieuwe betaalwijze voor het openbaar vervoer zijn heldere oplossingen voor welgeformuleerde problemen, maar vallen door hun aard buiten de huidige scope van COINS.

Dit geeft direct inzicht in hoe een bouwwerk binnen COINS wordt opgevat, nl. als een oplossing van een probleem, of, wat algemener gesteld, als een deel van het systeem van de Belanghebbende waarmee zijn primaire proces wordt uitgevoerd. Het hoofddoel van een bouwwerk zal dus bij voorkeur in termen van het primaire proces van de eindgebruiker worden geformuleerd.

Voorbeelden: Doel van een Basisschool: het bieden van ruimte en beschutting om het opleidingsproces van 4 tot 12 jarigen optimaal plaats te laten vinden. Doel van een Station: Het bieden van de mogelijkheid om (geautoriseerd) van transportmiddel te veranderen voor reizigers uit het verzorgingsgebied (plaats) en de spoorlijn van (A) naar (B) vv. Doel van Utility Ducts: Het bieden van de mogelijkheid om een aantal panden in (plaats) aan te sluiten op de nutsvoorzieningen, zonder daarvoor de straat steeds open te hoeven breken. Doel van een Kippenfarm: Het leveren van EKO-eieren en stamboekkuikens door het houden en fokken van kippen in een optimale omgeving.

Vanaf dit moment kan de COINS-systematiek worden ingezet en vanaf dit moment is er sprake van Virtueel Bouwen.

Stappen in het Virtueel Bouwen 

Kijken we naar het Activiteitenschema Bouw dan herkennen we daarin een aantal belangrijke zaken. We volgen de pijl naar beneden en het eerste dat dan opvalt is dat er een ander domein in beeld komt. Het gaat nu niet meer (alleen) om de Belanghebbende (de Originele Probleem Eigenaar), maar er wordt een andere partij genoemd, nl. de Bouwwerk Leverende. Deze partij is belangrijk in het COINS concept. Het is namelijk deze persoon of instantie die verantwoordelijk is voor het ontstaan van het bouwwerk en zo mogelijk voor het correct blijven functioneren ervan gedurende heel zijn levensduur. Het is ook deze instantie die vanaf het begin tot het eind de COINS-systematiek toepast. Deze instantie bestaat natuurlijk niet uit één bepaalde persoon of bedrijf, maar is meer bedoeld als de aanduiding van een verantwoordelijke speler in het veld.

11

De Bouwwerk Leverende kan bestaan uit meerdere partijen

Een essentiële stap in de COINS filosofie is het organiseren en inrichten van deze partij. (zie de voorgaande COINS publicatie: ‘Toekomst voor het bouwproces’ Hfdst. 5 e.v.). In dit hoofdstuk gaan we hier niet verder op in. Belangrijk is dat die partij er is en dat deze partij Virtueel Bouwt (en later in het traject ook ‘echt bouwt’ en het bouwwerk onderhoudt, maar dit terzijde).

De eerste stap in het Virtueel Bouwen is dat door de daartoe geautoriseerde medewerkers de oplossingsrichting (het systeem waarmee de oplossing mogelijk wordt) en het geformuleerde hoofddoel in het Bouwwerk Informatiesysteem worden opgeslagen. Vervolgens kunnen de volgende handelingen repeterend voorkomen in het proces van Virtueel Bouwen:

• Het vaststellen van de hoofdfuncties op basis van de aanvankelijke functionele eisen van de oplossingsrichting

• Het benoemen van bouwdelen die deze functies kunnen realiseren • Het verder onderverdelen van functies in subfuncties, en de daarbij

behorende bouwdelen • Het vastleggen van eisen op basis van de functies en ruimten • Het verder detailleren van de bouwdelen tot maakbare cq. koopbare

componenten. • Het controleren van de prestaties aan de eisen. • Het toekennen van bepaalde toestanden aan de objecten naarmate het

werk vordert • Het aangeven van de aansluitingen van de bouwdelen. • Het leggen van verbindingen tussen (aansluitingen) van bouwdelen. • Het controleren van de onderlinge posities en juiste passing. • Het bepalen van de bouwvolgorde en bouwplanning • Het simuleren van de bouwlogistiek en het toekennen van daarbij behorende

toestanden • Het genereren van doorsneden, lijsten, schema’s, tekeningen, digitale data

etc. tbv andere activiteiten rondom De Bouw van het bouwwerk.

En continue: het controleren van prestaties en eisen op alle niveaus.

12

Nota Bene: er wordt door de COINS-systematiek geen werkwijze voorgeschreven, maar wel mogelijkheden geboden. COINS is geen keurslijf. Het is dus niet verplicht om van alle mogelijkheden die COINS biedt gebruik te maken. Je kunt de COINS-systematiek beschouwen als een gereedschapskist waarvan je de gereedschappen toepast afhankelijk van de aard van het bouwwerk en de behoeften van een project.

In de volgende hoofdstukken brengen we de gereedschappen in beeld die deel uitmaken van de COINS-systematiek.

De kern van de COINS‐systematiek: het bouwwerk 

De kern van de COINS‐systematiek 

De kern van een bouwwerkinformatiesysteem volgens COINS wordt gevormd door het bouwwerk zelf. Het bouwwerk kan worden voorgesteld als een verzameling van met elkaar verbonden onderdelen (bouwdelen). Omdat de werkelijke afmetingen als data worden opgenomen in het model, kan het Coins Virtuele Bouwwerk daardoor worden opgevat als een digitale maquette op ware grootte. Dit is een belangrijk concept om vast te houden!

Het Coins Virtuele Bouwwerk is dus een beschrijving van het fysieke bouwwerk, maar dan in digitale vorm. Het maken van het fysieke bouwwerk (het ‘echte, harde, tastbare’ bouwwerk) kan dan worden opgevat als het ‘kopiëren’ van het virtuele bouwwerk ‘in steen’.

Een aardige vergelijking hierbij is de werking van een NC draaibank: de digitale voorstelling van de te maken as wordt ingevoerd in de machine, waarna de machine die gegevens ‘overdraagt’ naar het ruwe metaal en daaruit de werkelijke as draait. Die werkelijke as is in alle opzichten een afdruk van de digitale voorstelling van die as, met als verschil dat de werkelijke as van echt metaal is, en de digitale as op zijn hoogst een fotorealistische voorstelling daarvan op een beeldscherm is.

Het bouwdeel 

Het is belangrijk om de digitale voorstelling van een bouwwerk op een dusdanige manier vorm te geven dat we er makkelijk en zonder fouten mee kunnen werken. Het liefst op een manier die in de werkelijkheid ook zo voorkomt. Of tenminste daar sterk op lijkt. En die manier hebben we gevonden. We zorgen ervoor dat alle onderdelen, van het grootste tot het kleinste, van de meest complexe samenstelling tot de meest eenvoudige baksteen als één soort ‘ding’ kan worden opgevat. Dat ‘ding’ is het bouwdeel. Alles is dus een bouwdeel. Een pomp is een bouwdeel, maar een schroef kan dat ook zijn, of een verdiepingsvloer, of een gebouw, maar ook een jachthaven, of een recreatie-eiland. Een viaduct, een zandlichaam. Alles wat onderdeel uitmaakt van het bouwwerk. Een bouwdeel kan bestaan uit één of meerdere bouwdelen. En een groepje samengestelde bouwdelen mogen we dus ook een bouwdeel noemen. Dat maakt de digitale maquette eenvoudig. En omdat we er dan later eenvoudig (en eenduidig) mee kunnen werken. Een bouwwerk, bestaande uit bouwdelen kan nu worden voorgesteld in het informatiemodel als een eenvoudige hiërarchie:

13

Decompositie van een bouwdeel

Je kunt hiermee oneindig veel bouwdelen benoemen. Maar je ook beperken tot slechts één. Het nuttige (en praktische) aantal ligt in daar ergens tussenin en wordt vooral bepaald door de stappen die je verderop in het bouwproces met deze bouwdelen moet maken.

Aansluitingen en verbindingen 

Aansluitingen en verbindingen

Maar… zo voorgesteld is het slechts een stapel losse onderdelen, waarvan wel gezegd kan worden dat de ene bestaat uit een aantal andere, maar toch het blijft ‘los zand’. In een 3D-omgeving kan je ieder onderdeel een positie geven en ruimtelijk blijft dit overeind omdat zwaartekracht geen rol speelt. Optisch lijkt het dan een samenhangend geheel maar dat is schijn. Je weet niet precies hoe ze staan ten opzichte van elkaar. Je weet nog niet ‘hoe het in elkaar zit’. Je weet niet hoe het aan elkaar zit. En voor een aantal toepassingen is het juist gewenst om precies te weten hoe bouwdelen aan elkaar verbonden zijn.

14

Vergelijk het maar met een IKEA kast. In de platte doos die je mee naar huis neemt zitten alle onderdelen van die kast. Het zijn er niet teveel en niet te weinig (hoop je). Maar het is nog geen kast. Dat wordt het pas wanneer je hem in elkaar zet. Wanneer je alle onderdelen op de juiste manier aan elkaar verbindt. Dan pas heb je (met exact dezelfde onderdelen die in de platte doos zaten) een ruimtelijke kast gekregen, waar je ook werkelijk dingen in op kunt bergen. Je kleren bijvoorbeeld. Want daar heb je hem voor gekocht. Om die functie te kunnen vervullen. Verbindingen zijn dus belangrijk om de ruimtelijke samenhang vast te leggen. Om het echte bouwwerk te kunnen maken. Om virtueel te kunnen bouwen.

Het volgende lijstje geeft enkele voorbeelden van situaties waarin het vastleggen van verbindingen essentieel is:

• Als je een stromingsberekening wil doen van een leidingsysteem • Als je een stijfheidsmodel wil afleiden uit een 3D-model • Als je de logische verbindingen tussen onderdelen van een systeem wil

vastleggen (systeemschema) • Als je geautomatiseerd parametrisch wil ontwerpen (parameters worden

overgenomen d.m.v. de verbinding)

Maar, verbindingen alleen zijn niet voldoende. Je moet ook de mogelijkheid hebben om die verbinding te kunnen maken. Die mogelijkheid noemen we aansluitingen. En aansluiting is de mogelijkheid om een verbinding te kunnen maken. Aansluitingen zijn er altijd, ze vormen een eigenschap van het bouwdeel. Verbindingen zijn er niet altijd, die zijn er pas als ze zijn aangebracht. Met het aanbrengen van verbindingen veranderen losse bouwdelen in samengestelde bouwdelen. Door het aanbrengen van verbindingen ‘bouw’ je, al of niet ‘virtueel’.

En zo is dat ook in de COINS-systematiek uitgewerkt: elk bouwdeel heeft de mogelijkheid om één of meer aansluitingen aan te kunnen geven. En een verbinding bestaat tussen exact twee aansluitingen. Niet meer en niet minder. Dit principe is uitgelicht in bijgaande figuur. (PS: het wiebertje geeft aan dat de aansluiting een onderdeel is van het bouwdeel: is er geen bouwdeel, dan is er ook geen aansluiting!).

Dit is het. Dit is de kleinste kern van het CBIM. Hiermee kun je een digitale maquette maken van alle gebouwde (en nog te bouwen) bouwwerken. Hiermee kun je al spelen. Je kunt losse bouwdelen aan elkaar verbinden en weer losmaken, Je kunt lijsten maken van alle bouwdelen. Of van een gedeelte. Je kunt de bouwdelen anders rangschikken. Of maten aanpassen. Je kunt ook hoeveelheden bepalen, en afmetingen, en ruimtebeslag en mooie plaatjes maken. Mits je weet uit welke onderdelen het bouwwerk allemaal bestaat. En hoe het aan elkaar moet worden gezet. En wat het moet kunnen doen of waarvoor jet het kunt gebruiken. Maar dat weet je pas nadat je het bouwwerk hebt ontworpen! En dat proces willen we ook kunnen ondersteunen met het CBIM..

3D‐geometrie van bouwdelen 

3D-modellen zijn een krachtig hulpmiddel om een virtueel bouwwerk visueel te beoordelen. De COINS-systematiek kent twee manieren om met 3D-geometrie om te gaan. De eenvoudige manier is om een zogenaamde 'bounding box' te definiëren en deze te koppelen aan een bouwdeel. Zodoende kan in een vroeg ontwerpstadium een eenvoudig ruimtelijk beeld gecreëerd worden. Zo'n 'bounding box' kan ook gebruikt worden om een

15

ruimtereservering vast te leggen. Omdat een bouwdeel op verschillende niveaus beschreven kan worden, kunnen we ook op ieder niveaus het ruimtebeslag vastleggen.

Een bouwdeel kan refereren aan een vormobject binnen een grafisch bestand

Voor ruimtelijke coördinatie of voor een visualisatie, is veelal een nauwkeuriger ruimtelijke beschrijving van een bouwdeel nodig. Voor dergelijke toepassingen kunnen we gebruik maken van 3D-bestanden volgens het IFC-formaat (een standaard die voortgekomen is uit de IAI). Vanuit de definitie van van het bouwdeel wordt de relatie gelegd met een IFC-object binnen een IFC-bestand. Hoewel IFC een 'de facto' standaard is voor geometriegegevens, zal de COINS-systematiek ook toegepast kunnen worden in combinatie met andere gangbare geometriebestanden zoals DWG.

Functies, eisen en prestaties 

In de vorige hoofdstukken is de kern getoond van een Bouwwerk Informatiesysteem volgens de COINS-systematiek. Die kern bestaat uit een hoeveelheid gestructureerde gegevens die het bouwwerk zelf beschrijven. Een digitale maquette van het bouwwerk. Kernbegrippen zijn Bouwdelen, Aansluitingen en Verbindingen, en 3D-Representatie. Wat nog ontbreekt zijn gegevens waarmee je kunt vastleggen wat het bouwwerk moet kunnen en hoe het dat doet. We hebben het dan over de functies van het bouwwerk, de eisen die daaraan gesteld worden en prestaties die verbonden zijn aan de gekozen bouwdelen. Ontwerpen kan worden opgevat als het vertalen van die eerste formulering van hoe een einde gemaakt kan worden aan een ongewenste situatie naar de uiteindelijk vorm van het technische product dat dat dan ook doet. Ontwerpen is het komen van een gewenste functie (abstract) naar een technisch product (concreet). Daarbij moet telkens getoetst worden of de prestaties van het product voldoen aan de eisen die gesteld zijn. In ons geval kennen we dat technische product al, dat wordt ingevuld door het bouwwerk met zijn bouwdelen.

Activiteiten zoals het stellen van eisen, functies bedenken en ontwerpen hebben een samenhangend plekje gekregen in de werkmethodiek die bekend staat als Sytems Engineering

16

(of kortweg SE). SE is voortgekomen uit de defensieindustrie en is ontstaan uit de behoefte om het ontwikkelproces van complexe producten beter te beheersen. De COINS-systematiek ondersteunt het werken volgens SE. De keuze voor de ondersteuning van de methodiek van systems engineering staat niet op zichzelf; recent hebben Rijkswaterstaat en ProRail, in samenwerking met brancheorganisaties, een Leidraad Systems Engineering voor de Bouwsector [1] uitgebracht.

Systems Engineering Process

De schema hierboven laat de essenties van het Systems Engineering process zien. In de COINS-systematiek zijn we in staat om de gegevens die de functies beschrijven vast te leggen. Tevens zijn we in staat om de technische eigenschappen van een bouwdeel vast te leggen. Maar die twee zijn niet helemaal onafhankelijk van elkaar. Het ontwerpen is nl. een proces waarbij gegevens veranderen van aard. Eerst heb je het nl. over de beschrijving van functies, en pas later heb je het over het beschrijven van bouwdeel, maar je voelt direct aan dat die betrekking hebben op in wezen dezelfde zaken. Het bouwdeel met zijn Technische Beschrijving is een nadere uitwerking van een vereiste Functie. Met een Functie beschrijf je ‘wat een Bouwdeel moet kunnen’ (de vraag), en met de Technische Beschrijving van het bouwdeel beschrijf je ‘wat het Bouwdeel kan en hoe het dat doet’ (het antwoord) .

We streven ernaar om een functie door één Bouwdeel te laten invullen. Heel vaak lukt dit, maar lang niet altijd. Soms heb je meer bouwdelen die gezamenlijk een functie moeten invullen. Daarom wordt in de COINS-systematiek de mogelijkheid geboden om functies te relateren aan meerdere bouwdelen.

Functies en Bouwdelen bevatten beschrijvingen in de vorm van tekst. En teksten zijn niet gemakkelijk door een computer te begrijpen. Maar dat willen we wel, dus daarom moeten deze teksten ‘vertaald’ worden naar eenduidige kwantitatieve begrippen, die wèl door een computer kunnen worden begrepen. De integriteit van deze vertaalslag is de

17

verantwoordelijkheid van de ontwerper. Aan de Functies worden daarom (tijdens het werken met het Bouwwerk Informatiesysteem) Eisen gekoppeld (die relevant zijn voor die Functie) en aan de gekozen Bouwdelen worden Prestaties gekoppeld (die relevant zijn voor het bouwdeel). Een Eis en een Prestatie vormen ook een combinatie en moeten paarsgewijs vergeleken kunnen worden. Een functie kan meerdere eisen bevatten en een Bouwdeel kan meerdere prestaties leveren. Het Bouwdeel wordt dan ook de functievervuller genoemd. Indien alle eisen door de bijbehorende prestaties voldaan worden, vervult het Bouwdeel de gewenste Functie op correcte wijze. Is dat niet zo, dan heeft de verantwoordelijke ontwerper de vertaling verkeerd of onvolledig gedaan!

Relatie eis en prestatie

Ruimtes 

Naast bouwdelen kunnen ook ruimtes functies vervullen. Ruimtes kunnen ook prestaties vertonen, hebben een locatie, een ruimtelijke vorm en kunnen worden geordend in een decompositiestructuur. Ruimtes hebben dus veel eigenschappen met bouwdelen gemeen. Daarnaast is het in de COINS-systematiek mogelijk om een bouwdeel aan een ruimte toe te kennen; dat betekent zoveel als: bouwdeel x zal een plekje krijgen in ruimte y. Met deze eigenschap wordt het mogelijk om al in een vroeg stadium (als de ruimtes gedefinieerd zijn) aan ruimtelijke planning te doen.

Een ruimte bevat nul of meer bouwdelen

18

Informatie management en het virtuele bouwwerk 

De toepassing van Baselines 

De ontwikkeling van een bouwwerk doorloopt gewoonlijk een aantal fasen of niveaus van ontwikkeling. Een verdeling kan bijvoorbeeld zijn:

• Concept studie • Systeem definitie • Voorontwerp • Detailontwerp

Aan het eind van een fase wordt bekeken of alle benodigde informatie beschikbaar is, het ontwerp in overeenstemming is met de eisen, en de onderlinge samenhang correct is. Nadat de betrokken partijen een positief besluit hebben genomen, wordt de ontwikkelfase afgesloten en de informatie bevroren. Zo'n verzameling informatie wordt in de COINS-systematiek een 'Baseline' genoemd (de term 'Baseline' is afkomstig uit de Systems Engineering Methodiek). Bij de afsluiting van een fase wordt de baseline gesloten; wijzigen is daarna niet meer mogelijk. De inhoud van de baseline vormt een stabiel vertrekpunt voor een volgende ontwikkelfase.

De fasering van het ontwikkelproces is in de COINS-systematiek vrij te kiezen en zal onder meer afhankelijk van de aard van het te ontwikkelen bouwwerk. Uiteraard zijn er bekende faseringen die gebruikt kunnen worden, bijvoorbeeld zoals omschreven in de RVOI-2001 [2] .

Het volgende schema geeft ook een voorbeeld van een ontwikkelproces met verschillende fasen. Iedere fase vormt een baseline. Een open baseline is als grijze balk weergegeven. Na sluiting is de balk zwart.

19

Het ontwikkelproces resulteert dus in een serie van baselines, één voor ieder ontwikkelingsniveau. De verschillende baselines blijven bewaard en beschikbaar in ons bouwwerk informatiesysteem. Daarmee wordt de mogelijkheid geboden om terug te kijken.

De toestand van een bouwdeel 

Een bouwdeel doorloopt een Product Life Cycle, van ontwerp tot aan sloop. Waar een bouwdeel zich bevindt in de Life-cycle wordt vastgelegd door de Toestand (wordt ook wel Lifecycle_stage genoemd). Tijdens de voorbereiding van een bouwproject wordt bepaald welke toestanden van belang zijn om bij te houden. Het volgende lijstje is een voorbeeld van mogelijke toestanden:

• Conceptueel ontwerp • Constructief ontwerp • Voorbereiding uitvoering • Besteld bij leverancier • Op bouwplaats • Gemonteerd

Toestandsovergangen ontstaan door een besluit van een rol of een andere gebeurtenis. Zo’n besluit of gebeurtenis wordt gelogd en kan altijd in relatie tot het bouwdeel ingezien worden.

Creëren en wijzigen van informatieobjecten 

De ontwikkeling van een bouwwerk is een creatief en evolutionair proces; het aanbrengen van wijzigingen is een inherent onderdeel van dat proces. Het is van belang om het creëren/wijzigen ordelijk te laten verlopen om daarmee te waarborgen dat:

• duidelijk is wat de laatste stand van zaken is • duidelijk is waarom wijzigingen uitgevoerd dienen te worden en door wie • duidelijk is waarom wijzigingen uitgevoerd zijn, wanneer en door wie (audit

trail) • een oude situatie teruggehaald kan worden.

Een bouwwerk informatiesysteem bevat een grote verzameling informatieobjecten. Deze hebben betrekking op tal van onderwerpen, zoals: eisen, functies, bouwdelen, ruimten, documenten, enzovoort. In dit hoofdstuk wordt de werkwijze beschreven m.b.t. creëren en wijzigen van informatieobjecten. Als eerste worden enkele relevante begrippen toegelicht.

De versie en status van een informatieobject

Ten behoeve van het beheerst verlopen van het creëren/wijzigen van informatieobjecten zijn de volgende eigenschappen van een informatieobject relevant:

• Versie • Status, te onderscheiden in:

o Vrijgavestatus o Baselinestatus o Geldigheidsstatus

20

Versie Een bepaald informatieobject kan meerdere keren voorkomen in een informatiesysteem. De verschillende instanties worden onderscheiden door een versienummer. Alleen de laatste versie is geldig; alle voorgaande versies zijn vervallen (zie geldigheidsstatus) en worden beschikbaar gehouden om de historie te kunnen inzien.

Status Door middel van de status wordt de betekenis vastgelegd van een bepaald informatieobject voor de totstandkoming van het bouwwerk. De status wordt bepaald door een drie eigenschappen die bij ieder informatieobject voorkomen, te weten: Vrijgavestatus, Baselinestatus en Geldigheidsstatus.

Vrijgavestatus Binnen een bepaalde baseline doorloopt een informatieobject nog een andere cyclus die te maken heeft met de betekenis van het informatieobject binnen die specifieke baseline; we noemen dit de vrijgavestatus. De vrijgavestatus kan de volgende waarden bezitten:

• voorlopig • te verifiëren • te corrigeren • vrijgegeven • te wijzigen

Baselinestatus Een bouwwerk komt tot stand volgens een gefaseerde ontwikkeling die samenvalt met de Life Cycle. Voor een beheerst ontwikkelproces is het essentieel dat de ontwikkeling van een bepaalde fase niet gebeurt voordat de informatieobjecten van een voorgaande fase beschouwd kunnen worden als compleet, stabiel en gecontroleerd. 'Reviews' en 'audits' worden toegepast om te waarborgen dat een fase afgesloten kan worden en gebruikt kan worden als uitgangspunt voor een volgende fase. Door middel van de Baselinestatus wordt aangegeven dat deze controle heeft plaatsgevonden en positief is afgesloten. De Baselinestatus kan de waarden 'open' of 'gesloten' bezitten.

Geldigheidsstatus Een informatieobject dat betekenis heeft voor de actuele beschrijving van een bouwwerk heeft een geledigheidsstatus 'geldig'. Na vrijgave van een informatieobject kan, om wat voor een reden dan ook, besloten worden tot wijziging. In dat geval zal de geldigheidsstatus wijzigen van 'geldig' naar 'vervallen' en zal de wijziging uitgevoerd worden op een kopie met een ander versienummer en een andere vrijgavestatus. De geldigheidsstatus kan geen andere waarde hebben dan 'geldig' of 'vervallen'.

De relaties tussen creëren/wijzigen, vrijgeven en publiceren

Een informatieobject in ons bouwwerk informatiesysteem doorloopt dus een eigen levenscyclus. Het volgende schema geeft aan hoe dat verloopt en wat de relaties zijn tussen creëren/wijzigen, vrijgeven en publiceren.

21

Creëren/wijzigen is het creëren of wijzigen van informatieobjecten Vrijgeven is het verifiëren en van kracht zijnde verklaren van informatieobjecten Publiceren is het bewaren en toegankelijk maken van informatieobjecten, zodanig dat deze beschikbaar zijn voor de betrokken rollen.

Besluiten expliciet vastleggen 

In de hoofdstukken hiervoor zagen we dat een bouwdeel een levenscyclus doorloopt die bijgehouden kan worden door middel van de Toestand van het bouwdeel. Dan hebben we ook gezien dat ieder informatieobject in het bouwwerk informatiesysteem binnen een baseline een vrijgavecyclus doorloopt die bijgehouden wordt door middel van de vrijgavestatus.

Verandering van de toestand van een bouwdeel of de vrijgavestatus van een informatieobject gebeurt niet zomaar. Altijd ligt er een besluit van een verantwoordelijke rol/persoon aan ten grondslag. Voor het vastleggen van de communicatie die zich afspeelt rond het nemen van besluiten maken we gebruik van de VISI-standaard [3]. Door middel van de uitwisseling van gestandaardiseerde berichten tussen verantwoordelijke rollen/personen komt een besluit tot stand. Het volgende schema laat als voorbeeld zien welke berichten uitgewisseld kunnen worden tussen een opdrachtgever en een aannemer bij het overeenkomen van een wijziging.

De communicatie die op een dergelijke manier heeft plaatsgevonden wordt opgeslagen in het bouwwerk informatiesysteem. De COINS-systematiek voorziet erin dat deze informatie toegankelijk wordt. Zo wordt het mogelijk om via een bouwdeel een lijstje te verkrijgen van besluiten die van invloed waren op dat bouwdeel.

22

Informatie uitwisselen 

Communicatie over het bouwwerk vindt plaats door middel van het 'delen' van informatie. Dat kan op twee manieren gebeuren. Ten eerste kan dat gebeuren door middel van versturen van pakketten informatie tussen rollen/personen. Dit is de oude vertrouwde wijze. De tweede manier is als de verschillende rollen/personen real-time verbonden zijn met één informatiesysteem en voortdurend op de hoogte zijn van elkaars virtuele bouwactiviteiten.

Voor de afzienbare termijn moeten we verwachten dat veel informatie volgens het batch-patroon uitgewisseld zal worden. De COINS-systematiek voorziet hierin door de introductie van het COINS Digitaal Dossier of kortweg CDD (ook wel COINS Container genoemd). Deze ontwikkeling sluit aan op het document georiënteerde Elektronisch Opleverdossier van RWS.

• Een CDD wordt gebruikt om een opleverdossier in digitale vorm over te dragen tussen rollen/personen in een bouwproject.

• Een CDD kan beschouwd worden als een container voor transport van informatie.

• In het CDD is een voorschrift opgenomen worden voor de indeling van het dossier, geheel overeenkomstig het CBIM

• Een CDD kan leeg zijn (zonder informatieobjecten). • Een CDD kan gevuld zijn (met informatieobjecten). • Bij het vullen van een CCD ben je verplicht om de regels van het

overeengekomen CBIM te volgen • Een CDD kan handmatig gevuld worden of geheel automatisch.

Omdat een CDD gebaseerd is op de taal OWL (Ontology Web Language, zie [4]) kunnen vrij op markt beschikbare tools gebruikt worden om een CDD handmatig samen te stellen (zie bijvoorbeeld de OWL-editor Protégé [5]). De toepassingsmogelijkheden van het CDD zijn zeer breed. Het CDD kan al profijtvol ingezet worden bij het digitaal uitwisselen van digitale documenten zoals teksten en 2D-tekeningen.

23

Een bouwproject organiseren 

Voor een efficiënte uitvoering van het project is nodig dat duidelijk is wie verantwoordelijk is voor welke informatie. Deze verantwoordelijkheid wordt overeenkomstig de VISI-systematiek gekoppeld aan rollen. Tijdens de voorbereiding van een project wordt bepaald welke rollen nodig zijn om het project uit te voeren. Bij de uitwerking van de projectorganisatie worden rollen toegewezen aan organisaties/personen. Het volgende plaatje geeft een beeld van het proces dat uitgevoerd wordt bij het 3D-ontwerpen en ramen van hoeveelheden. De betrokken rollen zijn gegroepeerd rond een centrale rol die hier bouwwerkregisseur is genoemd.

De organisatie krijgt structuur door voor iedere rol vast te leggen wat de taken en verantwoordelijkheden zijn. Het volgende plaatje laat een voorbeeld zien.

24

Bevoegdheden 

Informatieoverdracht vindt plaats tussen rollen. Rollen zijn onderling verbonden doordat afspraken tussen die rollen gemaakt zijn over te verrichten werkzaamheden. In de VISI-terminologie worden dat 'transacties' genoemd. De afspraken over informatieoverdracht tussen twee rollen worden vastgelegd in de transacties die deze twee rollen verbinden. In zo'n transactie wordt aan een uitvoerende partij bevoegdheden toegekend om een bijdrage te leveren aan de totstandkoming van het virtuele bouwwerk. In de transactie wordt omschreven wat de te leveren bijdrage precies omvat en op welke plek in het informatiemodel deze bijdrage uiteindelijk (na acceptatie door de opdrachtgevende) zal worden gepositioneerd. Belangrijk is dat deze bevoegdheden duidelijk worden omschreven. Hierbij zal al gauw de behoefte aan indelingsprincipes (modulariteit) ontstaan: het selecteren van clusters van objecten met hetzelfde niveau van toegankelijkheid. In de COINS-systematiek wordt hiervoor de mogelijkheid geboden door de leesbevoegdheid en schrijfbevoegdheid van de uitvoerende rol vast te leggen. De vastlegging van de bevoegdheden en verantwoordelijkheden met betrekking tot informatieobjecten in de transactie wordt ook wel de 'Exchange requirement' genoemd.

25

Door middel van de transactie worden de lees- en schrijfbehoeften van de uitvoerende rol vastgelegd (window of autorisation)

26

Producten van het COINS-programma

Inhoud 

• 1 Inleiding • 2 Uitgangspunten

o 2.1 Uitgangspunten voor de ontwikkeling van COINS-producten o 2.2 Uitgangspunten voor gebruik

2.2.1 De projectorganisatie 2.2.2 De IT-aanbieder

• 3 De systematiek als basis • 4 COINS kernmodel • 5 Referentiekaders als aanvulling - Plug-in modellen

Inleiding 

Door het COINS-programma wordt een standaard ontwikkeld die het mogelijk moet maken om het proces van de totstandkoming van bouwwerken te verbeteren en informatie die daarin ontstaat beter te benutten. Deze standaard wordt beschikbaar gemaakt door middel van de volgende producten:

• COINS-systematiek Een verzameling algemene afspraken voor proces en informatie die de ruggengraat vormen voor integratie van het proces

• COINS-referentiekaders Aanvullende afspraken om specifieke toepassingen te kunnen ondersteunen, zoals het 'functioneel specificeren' of 'ramen van hoeveelheden'

• COINS-implementatierichtlijnen Richtlijnen die zich voor richten op de IT-implementatie van de standaard, met als doel om interoperabiliteit van IT-systemen te bewerkstelligen

De verhouding tussen proces, informatie en ICT is in het volgende plaatje weergegeven: informatie is dienend aan het proces en ICT is dienend aan informatieverwerking. Verder is in het plaatje de positie van de verschillende afspraken weergegeven. Zowel systematiek als referentiekaders bevatten procesaspecten en informatieaspecten.

27

In dit hoofdstuk worden uitgangspunten beschreven voor de ontwikkeling en het gebruik van de COINS-producten en wordt een toelichting gegeven op de de COINS-systematiek en COINS-referentiekaders.

Uitgangspunten 

Uitgangspunten voor de ontwikkeling van COINS‐producten 

Voor de ontwikkeling van de COINS-producten zijn de volgende uitgangspunten van belang:

• De COINS-systematiek en -referentiekaders zijn een leidraad voor de inrichten van proces en informatie

• De COINS-producten zijn een middel om virtueel bouwen mogelijk te maken • De COINS-producten zijn een middel om procesintegratie mogelijk te maken • We streven ernaar om COINS-producten zo klein mogelijk te houden en alleen

de essenties vast te leggen • We streven ernaar om COINS-producten zoveel mogelijk formeel vast te

leggen en in digitale vorm aan te bieden • De COINS-producten vormen geen rigide standaard; ze zijn flexibel te

gebruiken en kunnen toegepast worden als sjablonen • De focus van de COINS-producten ligt op toepassing tbv het primaire proces

van de totstandkoming van bouwwerken (levenscyclus)

Uitgangspunten voor gebruik 

De volgende uitgangspunten zijn voor het gebruik van van de COINS-producten van belang:

28

• De COINS-producten worden ontwikkeld en gepubliceerd door een beheerorganisatie (CUR Bouw en Infra)

• De gebruikers van de COINS-producten zijn projectorganisaties en IT-bedrijven

De projectorganisatie

Voor de projectorganisatie is het volgende van belang:

• De projectorganisatie heeft de taak om een ordelijk en efficiënt proces tot stand te brengen

• De projectorganisatie kiest de systematiek en eventuele referentiekaders als uitgangspunt voor een project

• De projectorganisatie maakt zonodig een aanpassing op de referentiekaders (projectspecifiek)

• De projectorganisatie maakt gebruik van de systematiek om voor iedere rol vast te leggen hoe het informatieproces verloopt

• De projectorganisatie maakt gebruik van de systematiek om voor iedere rol het informatieproces overeen te komen.

• De projectorganisatie maakt gebruik van de systematiek en eventuele referentiekaders om een IT-bedrijf voor te schrijven hoe het informatieproces ondersteund moet worden.

De IT-aanbieder

De volgende uitgangspunten zijn voor de IT-aanbieder van belang:

• De IT-aanbieder ontvangt de systematiek en eventuele referentiekaders met projectspecifieke aanpassingen als specificatie voor het informatieproces dat hij dient te ondersteunen

• IT-aanbieders gebruiken de COINS-systematiek en implementatierichtlijnen om COINS-compatible informatiesystemen te bouwen

• IT-aanbieders gebruiken de COINS-systematiek en implementatierichtlijnen om COINS-compatible interfaces aan softwaretools te bouwen

De systematiek als basis 

Voor de COINS-systematiek wordt uitgegaan van een modulair karakter van de standaard. Centraal staat een kernmodel dat door elke COINS-compatibele applicatie geïmplementeerd moet worden. Daar omheen gegroepeerd zijn een aantal plug-in modellen die deze kern in een specifieke richting detailleren. Deze aanpak biedt een aantal voordelen:

• Applicaties implementeren alleen het kernmodel plus één of meer plug-in modellen die betekenis voor hen hebben.

• De invloed van wijzigingen is beperkt tot het model waarop ze betrekking hebben

• Een uitbreiding (het toevoegen van een nieuw plug-in model) heeft geen invloed op bestaande applicaties.

29

• Een nieuw plug-in model kan eerst lokaal van start gaan (bijvoorbeeld binnen een lopend project) om vervolgens te promoveren naar een standaard COINS plug-in model.

Voorbeelden van plug-in modellen zijn die voor "Functioneel specificeren" en "Maken van ramingen".

Het staat ook andere partijen vrij dergelijke plug-in modellen te ontwikkelen mits zij aansluiten op het kernmodel en geen toevoegingen doen die met dit model strijdig zijn. Op deze wijze kan iedere COINS compatibele applicatie altijd op kernmodel niveau communiceren met andere applicaties. De meer gedetailleerde communicatie op plug-in model niveau is uiteraard alleen mogelijk als ook dat niveau is geïmplementeerd.

Kernmodel met plug-in modellen

Applicaties benaderen de informatie in een COINS model niet rechtstreeks. Een set van functies (aangeduid met de ICT term API (van Application Programming Interface)) beheert het model en draagt er zorg voor dat het model consistent blijft en in het algemeen voldoet aan alle gestelde regels. De API beslaat zowel het kernmodel als ook alle plug-in modellen.

Een belangrijk voordeel van een API is dat kleine wijzigingen in het model niet altijd tot een wijziging in de API hoeven te leiden. Zodat de applicaties die van de API gebruikmaken dan ook niet aangepast hoeven worden. Modeluitbreidingen zullen in het algemeen aanleiding geven tot nieuwe functies, maar bestaande applicaties (die deze functies dus niet gebruiken) hoeven ook dan niet onmiddellijk te worden aangepast.

30

CBIM en API

COINS kernmodel  

De COINS-systematiek bevat de beschrijving van het informatiemodel dat de kern vormt voor vele applicaties. Dit zogenaamde COINS kernmodel bevat de centrale decompositiestructuur van het virtuele bouwwerk aangevuld met concepten die de toepassing van Systems Engineering kunnen ondersteunen. Het gebruik van de Systems Engineering concepten is niet verplicht zodat ook modellen die enkel een bouwdelenstructuur kennen van COINS gebruik kunnen maken.

Het kernmodel kent één objecttype (CbimObject) waar alle andere objecttypes van erven. Dit objecttype definieert de gemeenschappelijke kenmerken van CBIM objecten zoals: identificatie, naam, creatiedatum, enz.

Ook definieert het kernmodel het objecttype Bouwwerk dat de centrale toegang tot het virtuele bouwwerk vormt en tevens het topobject van de bouwdelenboom (objectenboom) vormt.

Referentiekaders als aanvulling ‐ Plug‐in modellen 

Referentiekaders zijn aanvullende afspraken om specifieke toepassingen te kunnen ondersteunen, zoals het 'functioneel specificeren' of 'ramen van hoeveelheden'. Deze referentiekaders worden als separate publicaties uitgebracht. Ieder referentiekader gebruikt de COINS-systematiek als basis. Voor wat betreft het informatiemodel (CBIM) wordt zo'n

31

toevoeging een plug-in model genoemd. Plug-in modellen voegen meer specifieke details toe aan het kernmodel. Hiervoor zijn verschillende mechanismen beschikbaar:

• Toevoegen van één of meer extra attributen aan een bestaand objecttype Dit is de meest simpele vorm. Het bestaande objecttype wordt met wat extra attribuutwaarden verrijkt.

• Nieuw objecttype als specialisatie van een bestaand objecttype Dit biedt de mogelijkheid de algemene objecttypen uit het kernmodel te specialiseren voor een specifieke toepassing bijvoorbeeld voor installaties.

• Toevoegen van een associatie tussen een bestaand objecttype en een nieuw objecttype Zo kan de bestaande kernmodelstructuur worden verrijkt met nieuwe objecttypen.

32

Formele beschrijving van de systematiek Het idee “Virtueel bouwen” vormt de basis van zowel de COINS Engineering Methode (CEM) als het COINS Bouw Informatiemodel (CBIM). Voor de wijze waarop het virtuele bouwwerk tot stand komt baseert CEM zich voornamelijk op de Systems Engineering methodiek. CBIM legt vast hoe de hiervoor noodzakelijke informatie moet worden vastgelegd.

Inhoud 

• 1 Virtueel bouwen o 1.1 Bouwdelen (Physical Objects) o 1.2 Vorm en locatie o 1.3 Connectiviteit o 1.4 Functies (Functions) o 1.5 Eisen (Requirements) o 1.6 Prestaties (Performances) o 1.7 Ruimtes (Spaces) o 1.8 Bibliotheekobjecten

• 2 Systems Engineering o 2.1 Requirements Analysis o 2.2 Functional Analysis/Allocation o 2.3 Synthesis

• 3 Modelmanagement o 3.1 Basisattributen o 3.2 Status

• 4 COINS Application Programming Interface o 4.1 Interface CbimObject o 4.2 Interface Amount o 4.3 Interface Baseline o 4.4 Interface CataloguePart o 4.5 Interface Function o 4.6 Interface Performance o 4.7 Interface PhysicalObject o 4.8 Interface PropertyType o 4.9 Interface PropertyValue o 4.10 Interface Requirement o 4.11 Interface Space

Virtueel bouwen Bouwdelen (Physical Objects)  

Om virtueel bouwen te kunnen ondersteunen moet alle informatie betreffende het bouwwerk en de wijze waarop dat tot stand komt kunnen worden vastgelegd. Het vastleggen van het

33

bouwwerk vergt het opslaan van de informatie die elk fysiek onderdeel van het bouwwerk (bouwdelen) beschrijft: vorm, locatie, materiaal en andere eigenschappen. Om enige structuur aan te brengen in deze berg van gegevens worden de bouwdelen geordend volgens het decompositieprincipe: hoe de grotere eenheden zijn opgebouwd uit kleinere onderdelen.

Figuur 1: Decompositie van het bouwwerk.

De decompositiestructuur is die van een boom: bovenaan vindt men één enkel object dat voor het bouwwerk als geheel staat. Daaronder een laag met objecten die gezamenlijk ook weer het bouwwerk representeren maar dan met meer detail. Zo kan men verder werken tot aan het niveau dat verdere detaillering niet zinvol meer is, bijvoorbeeld omdat de objecten in deze laag worden betrokken van een toeleverancier of omdat de wijze van produceren volgens standaard receptuur kan geschieden.

Bij het ontwerp van CBIM is er vanuit gegaan dat de representatie van het bouwwerk in zijn samenstellende bouwdelen volgens een decompositiestructuur de kern van het informatiemodel zou moeten vormen. Dit is met slechts één informatieobjecttype plus één relatie plus één attribuut te modelleren.

Figuur 2: Decompositiestructuur van bouwdelen (physical objects).

34

Het laag attribuut bevat de index van de laag waar het bouwdeel zich in bevindt. Alle bouwdelen met dezelfde laagindex vormen samen weer het complete bouwwerk. Bij laagsgewijze decompositie mogen geen lagen worden “overgeslagen”. De decompositierelatie mag dus alleen worden gelegd tussen bouwdelen in aansluitende lagen en wel met ouderindex (i) en kindindex (i + 1). Wel kan het voorkomen dat bepaalde takken minder ver worden uitgediept dan andere takken. In dat geval representeren de diepere lagen niet meer het gehele bouwwerk maar alleen de tot die laag uitgedetailleerde delen.

Vorm en locatie  

Een bouwdeel heeft een ruimtelijke vorm en deze kan dus met een 3D representatie worden vastgelegd. CBIM bevat geen eigen vormrepresentatie objecttypen maar maakt gebruik van externe formaten voor 3D representatie. Hierbij wordt in eerste instantie aan IFC gedacht maar ook andere formaten worden niet uitgesloten. Een bouwdeel zal voor zijn vormdefinitie refereren aan een extern model waarvan de locatie en andere gegevens worden vastgelegd in een apart linkobject (“Explicit 3D representation”).

Figuur 3: Vorm en locatie.

Naast de vormdefinitie is ook de positie en oriëntatie van het bouwdeel van belang. Deze informatie wordt wel in CBIM opgeslagen via het locator objecttype. Een locator bevat een aantal 3D vectoren voor locatie, oriëntatie en ook voor het specificeren van een bounding box. Met dit laatste concept kan in een vroeg stadium toch iets over de ruimtelijke aspecten van een bouwwerk worden vastgelegd.

In combinatie met decompositie kunnen globale en gedetailleerde vormmodellen laagsgewijs aan de bouwdelenboom worden gehangen. Een kindbouwdeel zal met zijn locator in het algemeen een relatieve positie en oriëntatie ten opzichte van de locator van het directe ouderbouwdeel krijgen toebedeeld, maar een absolute locatie of oriëntatie kan indien gewenst ook worden vastgelegd.

35

Connectiviteit  

De bouwdelenboom legt vast uit welke bouwdelen een bouwwerk is samengesteld en hoe deze subbouwdelen weer zijn opgebouwd uit weer andere kleinere bouwdelen, enz. Met de locator objecten en de vormrepresentaties kan een 3D model worden opgebouwd. Optisch lijkt het dan een samenhangend geheel maar dat is schijn. Er is geen expliciete informatie betreffende de wijze waarop de bouwdelen aan elkaar zijn verbonden in het model beschikbaar. Heeft men deze informatie toch nodig voor bepaalde analyses (sterkte, energietransmissie, etc.) dan moet deze expliciet aan het model worden toegevoegd.

Figuur 4: Expliciete connectiviteitsrelaties

Hiervoor definieert het bouwdeel één of meer aansluitingen (terminal): een plek waar een aangrenzend bouwdeel met zijn aansluiting mee verbonden kan worden. De daadwerkelijke connectie wordt vastgelegd in een verbinding (connection). Een aansluiting heeft een positie (locator link) maar kan ook een vormdefinitie specificeren: het aanrakingsoppervlak.

Functies (Functions)  

Naast de fysieke verschijningsvorm van een bouwwerk door zijn samenstellende bouwdelen valt de beschrijving van de functies van het bouwwerk ook binnen het bestek van COINS. Zoals bijna alles in CBIM gaat het hier de mogelijkheid tot en betreft het niet een verplichting om het ook toe te passen.

36

In het algemeen vervult een bouwdeel één of meer functies maar een functie kan ook worden uitgesmeerd over meer dan één bouwdeel.

Figuur 5: Veel-naar-veel relatie tussen functies en bouwdelen.

Een dergelijk onbegrensde relatie kan makkelijk aanleiding geven tot een spaghettistructuur. Daarom is de restrictie aangebracht dat functie en bouwdeel tot dezelfde decompositielaag moeten behoren. Zo specificeert laag 0 alleen de functies die het bouwwerk als geheel moet vervullen. Laag 1 benoemt de functies voor de bouwdelen in die laag, enz.

Figuur 6: Voorbeeld van model met twee hoofdfuncties en twee decompositielagen.

Het uitgangspunt dat de bouwdelenboom de centrale structuur beschrijft blijft gehandhaafd. Tussen de functies in de verschillende decompositielagen vormen ook een structuur die in sommige situaties a functiesboom genoemd zou kunnen worden (maar meer algemeen een gericht netwerk). Deze structuur wordt niet expliciet in CBIM vastgelegd maar kan betrekkelijk eenvoudig worden afgeleid door de aanwezige routes (wordt-vervuld-door relatie + bouwdeel decompositierelatie) te volgen.

Eisen (Requirements)  

De beschrijving van de gewenste functionaliteit kan nader worden gepreciseerd door het specificeren van eisen. In het CBIM zijn eisen telkens met één functie verbonden.

37

Figuur 7: Een eis is verbonden met één functie

Hoe de eisen vervolgens aan een bouwdeel zijn geassocieerd wordt bepaald door de vervult/is-vervuld-door relatie. Er zijn twee mogelijkheden:

• de functie wordt vervuld door precies één bouwdeel.In dat geval is het bouwdeel volledig verantwoordelijk voor het voldoen aan de gestelde eisen van deze functie.

• De functie wordt vervuld door meer dan één bouwdeel.Nu wordt de verantwoordelijkheid gedeeld. De bouwdelen worden in dit geval als één functievervuller opgevat: gezamenlijk moet aan de gestelde eisen worden voldaan.

Figuur 8: Eis verbonden via functie en vervult-door relatie met enkelvoudig bouwdeel of een cluster van bouwdelen

Prestaties (Performances)  

Een bouwdeel levert prestaties. Deze prestaties moeten voldoen aan de eisen die behoren bij de functie(s) die het bouwdeel vervult.

38

Figuur 9: Prestaties worden vergeleken met de daaraan gestelde eisen

Algemeen gesteld kan een eis verbonden zijn met meer dan één prestatie (in het geval dat de eis twee of meer prestaties met elkaar verbindt). Andersom kunnen verschillende eisen betrekking hebben op dezelfde prestatie (bijvoorbeeld wanneer zowel een boven- als een ondergrens aan de prestatie wordt opgelegd).

Figuur 10: Relatie eis en prestatie

In het geval dat een functie door meer dan één bouwdeel wordt vervuld zal nader vastgesteld moeten worden hoe de deelprestaties tot een totaalprestatie kunnen worden herleid. Soms kan dit door een sommatie, in een ander geval telt de zwakste schakel, etc.

Ruimtes (Spaces)  

Naast bouwdelen kunnen ook ruimtes ook functies vervullen. Ruimtes kunnen ook prestaties vertonen, hebben een locatie, een ruimtelijke vorm en kunnen worden geordend in een decompositiestructuur. Ruimtes hebben dus veel eigenschappen met bouwdelen gemeen. Dit gemeenschappelijke kan worden ondergebracht in een abstracte superklasse “FunctieVervuller”.

Alleen de decompositie wordt gescheiden gehouden opdat bouwdelen alleen uit subbouwdelen en ruimtes alleen uit subruimtes kunnen bestaan.

Daarnaast is het mogelijk om een bouwdeel aan een ruimte toe te kennen; dat betekent zoveel als: bouwdeel x zal een plekje krijgen in ruimte y.

39

Figuur 11: FunctieVervuller beschrijft het gemeenschappelijke gedrag van bouwdelen en ruimtes

Bibliotheekobjecten  

Decompositie eindigt op het niveau dat bouwdelen betrokken kunnen worden van toeleveranciers als item uit een catalogus of zelf gefabriceerd kunnen worden volgens een standaard recept van activiteiten en middelen. Een bouwdeel op deze decompositielaag verwijst dan naar één of meer bibliotheekobjecten (catalogue parts). De bibliotheekobjecten in een CBIM hebben betrekking op het project waarmee het CBIM is verbonden. Via linken kan een bibliotheekobject gerelateerd worden aan standaard bibliotheken als SmartBuilding IFD, CROW objectenbibliotheek of STABU. Lexicon.

40

Figuur 12: Bouwdeel wordt samengesteld uit een verzameling bibliotheekobjecten.

Bibliotheekobjecten kunnen een hiërarchie vormen waarbij een object weer bestaat uit subobjecten. Bibliotheekobjecten hebben eigenschappen (properties) die mogelijk parametrisch van aard zijn.

Systems Engineering Het Systems Engineering proces is een iteratief en recursief probleemoplossingproces. Het proces wordt sequentieel uitgevoerd, één niveau tegelijkertijd, terwijl bij ieder niveau van ontwikkeling meer detail en definitie toegevoegd wordt. Het proces onderscheidt drie activiteiten waartussen een drietal iteraties plaatsvinden.

41

Figuur 11: Systems Engineering proces

Met het CBIM kan deze gelaagde benadering precies worden gerepresenteerd. Alle relevante objecttypen kunnen een niveauindicator bevatten. Deze niveauindicator bepaalt op welk niveau het informatieobject zich bevind: niveau 0 is het topniveau, niveau 1 het eerste uitwerkingsniveau, enz. Op deze wijze wordt bereikt dat alleen informatieobjecten van hetzelfde ontwikkelingsniveau de typerende Systems Engineering relaties aangaan.

Requirements Analysis  

De Requirements Analysis activiteit genereert de eisen die op het betreffende detailniveau van belang zijn.

Voor CBIM betekent dit dat men in staat is eisen te formuleren en vast te leggen.

Functional Analysis/Allocation  

De Functional Analysis/Allocation activiteit definieert de te vervullen functies op het betreffende detailniveau en bundelt eerder geformuleerde eisen aan functies. Tijdens deze activiteit zullen ook nieuwe eisen worden geïdentificeerd wat door de requirements loop tot uitdrukking wordt gebracht.

Voor CBIM betekent dit dat men in staat is functies te formuleren en vast te leggen. Bovendien moet men in staat zijn eisen aan functies te verbinden.

42

Synthesis  

De synthesis activiteit genereert functievervullers (hier bouwdelen) voor de eerder opgestelde functies. Tijdens deze activiteit zullen ook nieuwe (afgeleide) functies worden ontdekt wat tot uitdrukking komt in de design loop. Daarnaast moeten de functievervullers voldoen aan de gestelde eisen van de eerste activiteit wat tot uitdrukking komt in de verification loop.

Voor het CBIM betekent dit dat men in staat is een bouwdeel te ontwerpen en deze een relatie aan te laten gaan met zijn te vervullen functie(s). Ook moet duidelijk zijn aan welke eisen het bouwdeel moet voldoen.

Figuur 12: Processtappen Systems Engineering

Modelmanagement Basisattributen  

Alle informatieobjecten in een C-BIM hebben een vaste set van attributen die van belang zijn voor identificatie en modelmanagement.

43

Figuur 14: Modelmanagement attributen

Deze attribuutwaarden/associaties zijn in alfabetische volgorde:

• baseline referentie naar de baseline waar dit informatieobject onderdeel vanuit maakt

• beschrijving (description) beschrijving van dit informatieobject

• creatiedatum (creation date) creatiedatum van dit informatieobject

• creator persoon of organisatie die dit informatieobject gecreëerd heeft

• document gelinkte documenten

• gebruikerscode (user ID) door gebruiker te bepalen code aan dit informatieobject

• geldigheidsstatus (expired) is dit informatieobject niet meer geldig?

• modificatiedatum (modification date) modificatiedatum van dit informatieobject

• modifier persoon of organisatie die dit informatieobject veranderd heeft

• naam (name) naam van het informatieobject

• volgende versie (next version) verwijzing naar een recentere versie van dit informatieobject

44

• vrijgavedatum (release date) datum van de laatste vrijgavestatus

• vrijgavestatus (release state) status van het informatieobject

• wijzigingen (change log) lijst met wijzigingen op dit informatieobject

Status  

Door middel van de status wordt de betekenis vastgelegd van een bepaald informatieobject voor de totstandkoming van een bouwwerk. De status wordt bepaald door een vier eigenschappen.

Toestand Een bouwdeel doorloopt een Product Life Cycle, van ontwerp tot aan sloop. Waar een bouwdeel zich bevindt in de Life Cycle wordt vastgelegd door de toestand. Tijdens de voorbereiding van een bouwproject wordt bepaald welke toestanden van belang zijn om bij te houden.

Figuur 15: Toestand van een bouwdeel

Vrijgavestatus (Release status) De vrijgavestatus kan de volgende waarden bezitten:

• voorlopig • te verifiëren • te corrigeren • vrijgegeven • te wijzigen

Baselinestatus Een bouwwerk komt tot stand volgens een gefaseerde ontwikkeling die samenvalt met de Life Cycle. Voor een beheerst ontwikkelproces is het essentieel dat de ontwikkeling van een bepaalde fase niet gebeurt voordat de informatieobjecten van een voorgaande fase beschouwd kunnen worden als compleet, stabiel en gecontroleerd. 'Reviews' en 'audits' worden toegepast om te waarborgen dat een fase afgesloten kan worden en gebruikt kan worden als uitgangspunt voor een volgende fase. Door middel van de Baselinestatus wordt aangegeven dat deze controle heeft plaatsgevonden en positief is afgesloten. De Baselinestatus kan de waarden 'open' of 'gesloten' bezitten.

Geldigheidsstatus Een informatieobject dat betekenis heeft voor de actuele beschrijving van een bouwwerk heeft een geldigheidsstatus 'geldig'. Na vrijgave van een informatieobject kan, om wat voor een

45

reden dan ook, besloten worden tot wijziging. In dat geval zal de geldigheidsstatus wijzigen van 'geldig' naar 'vervallen' en zal de wijziging uitgevoerd worden op een kopie met een ander versienummer en een andere vrijgavestatus. De geldigheidsstatus kan geen andere waarde hebben dan 'geldig' of 'vervallen'.

COINS Application Programming Interface In dit hoofdstuk wordt een overzicht gegeven van de COINS-API (Application Programming Interface). Het is opgedeeld in een verzameling interfaces die in de regel één-op-één corresponderen met het objecttype van dezelfde naam. Iedere interface specificeert een lijst met functies die de inhoud van een informatieobject kunnen ondervragen of manipuleren.

Benadrukt wordt dat de hier gespecificeerde API slechts een voorzet is van een mogelijke invulling. De API is daarom ook nog niet compleet: er ontbreken objecttypen en bovendien is een mechanisme voor het creëren en verwijderen van objecten nog niet opgenomen. In samenspraak met de ICT partners zal de uiteindelijke interfacedefinitie worden opgesteld.

Interface CbimObject  

• void addDocument(Document document)Add a new document link. • Baseline getBaseline()Return the baseline that owns this C-BIM object. • String getCreationDate()Return the creation date. • PersonOrOrganisation getCreator()Return the person that created this C-BIM

object. • String getDescription()Return the description. • int getLayerIndex()Return the layer index. • String getLocalName()Return the local name. • String getModificationDate()Return the last modification date. • String getName()Return the name. • String getNameSpace()Return the name space. • CbimObject getNextVersion()Return the next version of this C-BIM object. • String getReleaseDate()Return the date of the current release status. • String getReleaseStatus()Return the current release status. • String getURI()Return the URI. • String getUserID()Return the user defined identification. • Boolean isExpired()Return the expiration status. • Iterator<Document> listDocuments()List all document links associated with

this function. • void removeDocument(Document document)Remove an obsolete document

link. • void setBaseline(Baseline baseline)(Re)Set the baseline that owns this C-

BIM object. • void setCreationDate(String creationDate)(Re)Set the creation date. • void setCreator(PersonOrOrganisation creator)(Re)Set the person that

created this C-BIM object. • void setDescription(String description)(Re)Set the description. • void setExpired(Boolean expired)(Re)Set the expiration status. • void setLayerIndex(int layerIndex)(Re)Set the layer index.

46

• void setModificationDate(String modificationDate)(Re)Set the modification date.

• void setName(String name)(Re)Set the name. • void setNextVersion(CbimObject nextVersion)(Re)Set the next version of this

C-BIM object. • void setReleaseDate(String releaseDate)(Re)Set the date of the current

release status. • void setReleaseStatus(String releaseStatus)(Re)Set the current release

status. • void setUserID(String userID)(Re)Set the user defined identification.

Interface Amount  

• Float getAmount() Return the amount value. • CataloguePart getCataloguePart() Return the catalogue part. • void setAmount(Float amount) (Re)Set the amount value. • void setCataloguePart(CataloguePart cataloguePart) (Re)Set the

catalogue part.

Interface Baseline  

• Boolean isBaselineOpen()Return the baseline status. • void setBaselineOpen(Boolean baselineStatus)(Re)Set the baseline status.

Interface CataloguePart  

• void addPropertyValue(PropertyValue propertyValue) Add a new property value.

• void addSubPart(float amount, CataloguePart subPart) Add an Amount/CataloguePart combination.

• boolean contains(CataloguePart subPart) Does this catalogue part item contain this subpart.

• Amount getAmount(CataloguePart subPart) Get the Amount object of this CataloguePart class.

• String getQuantity() Return the quantity type of the catalogue part item. • String getUnit() Return the unit of the catalogue part item. • Iterator<Amount> listAmounts() List all Amount objects of this CataloguePart. • Iterator<PropertyValue> listPropertyValues() List the property values of this

catalogue part item object. • void removePropertyValue(PropertyValue propertyValue) Remove an

obsolete property value. • void removeSubPart(CataloguePart subPart) Remove an

Amount/CataloguePartItem combination. • void setQuantity(String quantity) (Re)Set the quantity type of the

catalogue part item. • void setUnit(String unit) (Re)Set the unit of the catalogue part item.

47

Interface Function  

• void addFunctionFulfiller(FunctionFulfiller functionFulfiller) Add a new function fulfiller.

• void addRequirement(Requirement requirement) Add a new requirement. • Iterator<FunctionFulfiller>listFunctionFulfillers() Return a list of all function

fulfillers. • Iterator<Requirement> listRequirements() Return a list of all requirements. • void removeFunctionFulfiller(FunctionFulfiller functionFulfiller)

Remove an obsolete function fulfiller. • void removeRequirement(Requirement requirement) Remove an obsolete

requirement.

Interface Performance  

• FunctionFulfiller getContainerFunctionFulfiller() Return the containing function fulfiller.

• void setContainerFunctionFulfiller(FunctionFulfiller containerFunctionFulfiller) (Re)Set the containing function fulfiller.

Interface PhysicalObject  

• void addChildPhysicalObject(PhysicalObject childPhysicalObject) Add a new physical object that is part of this assembly object.

• PhysicalObject getParentPhysicalObject() Return the physical object that represents the assembly from which this object is a part.

• Iterator<PhysicalObject> listChildPhysicalObjects() Return a list of all child physical objects.

• void removeChildPhysicalObject(PhysicalObject childPhysicalObject) Remove an obsolete physical object that is part of this assembly object.

• void setParentPhysicalObject(PhysicalObject parentPhysicalObject) (Re)Set the physical object that represents the assembly from which this object is a part.

Interface PropertyType  

• Integer getTypeIndex() Return the type index. • String getUnit() Return the unit of the property type. • void setTypeIndex(Integer typeIndex) (Re)Set the type index. • void setUnit(String unit) (Re)Set the unit of the property type.

Interface PropertyValue  

• PropertyType getPropertyType() Return the property type. • Object getValue() Return the property value. • void setPropertyType(PropertyType propertyType) (Re)Set the property

type.

48

• void setValue(Object value) (Re)Set the property value.

Interface Requirement  

• Function getContainerFunction() Return the containing function. • void setContainerFunction(Function containerFunction) (Re)Set the

containing function.

Interface Space  

• void addChildSpace(Space childSpace) Add a new space object that is part of this assembly space object.

• Space getParentSpace() Return the space object that represents the assembly from which this space object is a part.

• Iterator<Space> listChildSpaces() Return a list of all child space objects. • void removeChildSpace(Space childSpace) Remove an obsolete space

object that is part of this assembly space object. • void setParentSpace(Space parentSpace) (Re)Set the space object that

represents the assembly from which this space object is a part.

49

Beschrijving uitwisselingsformaat – COINS Container Het COINS Bouw Informatie Model is gespecificeerd met OWL (Web Ontology Language). OWL is een standaard van het World Wide Web Consortium (W3C) die onder andere ook de XML en HTML standaarden ontwikkelt en beheert. OWL biedt een aantal voordelen boven andere specificatietalen onder andere door zijn nauwe verwevenheid met het internet en de flexibiliteit waarmee nieuwe definities toegevoegd kunnen worden. Voor OWL zijn verschillende tools beschikbaar:

• Protégé is een public domain OWL ontwikkelomgeving.

• TopBraid Composer een commerciële ontwikkelomgeving die goed samenwerkt met Eclipse.

• Jena is een bibliotheek met Java routines om OWL modellen te creëren en te wijzigen.

COINS Container  

OWL heeft een eigen bestandsformaat (RDF) voor model/dataopslag. RDF zelf maakt op zijn beurt weer gebruik van XML als bestandsformaat. Daarom ziet OWL data er ook XML-achtig uit. Applicaties die (nog) niet rechtstreeks gebruikmaken van de COINS-API zouden wel via OWL bestanden kunnen communiceren. Een dergelijke applicatie opereert dan niet rechtstreeks op het gezamenlijke CBIM model maar vult een OWL model met het resultaat van een bepaalde activiteit dat vervolgens als een subboom aan het gezamenlijke model kan worden gehangen. Omgekeerd kan natuurlijk ook.

Voor het lezen en schrijven van deze bestanden bestaan bibliotheken (in de regel in Java) die de inspanning voor het maken van een dergelijke vertaler sterk kunnen bekorten.

<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:xsd="http://www.w3.org/2001/XMLSchema#" xmlns="http://www.coinsweb.nl/c-bim.owl#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xml:base="http://www.coinsweb.nl/c-bim.owl"> <owl:Ontology rdf:about=""> <owl:versionInfo rdf:datatype="http://www.w3.org/2001/XMLSchema#string" >Created with TopBraid Composer</owl:versionInfo> </owl:Ontology> <owl:Class rdf:ID="Connection"> <owl:equivalentClass> <owl:Restriction> <owl:allValuesFrom rdf:resource="#Connection"/> <owl:onProperty> <owl:ObjectProperty rdf:ID="nextVersion"/> </owl:onProperty> </owl:Restriction>

50

</owl:equivalentClass> <rdfs:subClassOf> <owl:Class rdf:ID="CbimObject"/> </rdfs:subClassOf> <owl:equivalentClass> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="maleTerminal"/> </owl:onProperty> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:cardinality> </owl:Restriction> </owl:equivalentClass> <owl:equivalentClass> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="femaleTerminal"/> </owl:onProperty> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:cardinality> </owl:Restriction> </owl:equivalentClass> </owl:Class> <owl:Class rdf:ID="Vector"> <owl:equivalentClass> <owl:Restriction> <owl:allValuesFrom rdf:resource="#Vector"/> <owl:onProperty> <owl:ObjectProperty rdf:about="#nextVersion"/> </owl:onProperty> </owl:Restriction> </owl:equivalentClass> <rdfs:subClassOf> <owl:Class rdf:about="#CbimObject"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Baseline"> <owl:equivalentClass> <owl:Restriction> <owl:allValuesFrom rdf:resource="#Baseline"/> <owl:onProperty> <owl:ObjectProperty rdf:about="#nextVersion"/> </owl:onProperty> </owl:Restriction> </owl:equivalentClass> <rdfs:subClassOf> <owl:Class rdf:about="#CbimObject"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="PropertyValue"> <rdfs:subClassOf> <owl:Class rdf:about="#CbimObject"/> </rdfs:subClassOf> <owl:equivalentClass> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:about="#nextVersion"/> </owl:onProperty> <owl:allValuesFrom rdf:resource="#PropertyValue"/> </owl:Restriction> </owl:equivalentClass>

51

<owl:equivalentClass> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="propertyType"/> </owl:onProperty> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:cardinality> </owl:Restriction> </owl:equivalentClass> </owl:Class> <owl:Class rdf:ID="Explicit3DRepresentation"> <rdfs:subClassOf> <owl:Class rdf:ID="Document"/> </rdfs:subClassOf> <owl:equivalentClass> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:about="#nextVersion"/> </owl:onProperty> <owl:allValuesFrom rdf:resource="#Explicit3DRepresentation"/> </owl:Restriction> </owl:equivalentClass> </owl:Class> <owl:Class rdf:ID="Locator"> <owl:equivalentClass> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="translation"/> </owl:onProperty> <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:maxCardinality> </owl:Restriction> </owl:equivalentClass> <owl:equivalentClass> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="primaryOrientation"/> </owl:onProperty> <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:maxCardinality> </owl:Restriction> </owl:equivalentClass> <owl:equivalentClass> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="secondaryOrientation"/> </owl:onProperty> <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:maxCardinality> </owl:Restriction> </owl:equivalentClass> <owl:equivalentClass> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="minBoundingBox"/> </owl:onProperty> <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"

52

>1</owl:maxCardinality> </owl:Restriction> </owl:equivalentClass> <owl:equivalentClass> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="maxBoundingBox"/> </owl:onProperty> <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:maxCardinality> </owl:Restriction> </owl:equivalentClass> <owl:equivalentClass> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:about="#nextVersion"/> </owl:onProperty> <owl:allValuesFrom rdf:resource="#Locator"/> </owl:Restriction> </owl:equivalentClass> <rdfs:subClassOf> <owl:Class rdf:about="#CbimObject"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="#Document"> <owl:equivalentClass> <owl:Restriction> <owl:allValuesFrom rdf:resource="#Document"/> <owl:onProperty> <owl:ObjectProperty rdf:about="#nextVersion"/> </owl:onProperty> </owl:Restriction> </owl:equivalentClass> <rdfs:subClassOf> <owl:Class rdf:about="#CbimObject"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="#CbimObject"> <owl:equivalentClass> <owl:Restriction> <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:maxCardinality> <owl:onProperty> <owl:ObjectProperty rdf:about="#nextVersion"/> </owl:onProperty> </owl:Restriction> </owl:equivalentClass> <owl:equivalentClass> <owl:Restriction> <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:maxCardinality> <owl:onProperty> <owl:ObjectProperty rdf:ID="modifier"/> </owl:onProperty> </owl:Restriction> </owl:equivalentClass> <owl:equivalentClass> <owl:Restriction>

53

<owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:maxCardinality> <owl:onProperty> <owl:ObjectProperty rdf:ID="creator"/> </owl:onProperty> </owl:Restriction> </owl:equivalentClass> <owl:equivalentClass> <owl:Restriction> <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:maxCardinality> <owl:onProperty> <owl:ObjectProperty rdf:ID="baseline"/> </owl:onProperty> </owl:Restriction> </owl:equivalentClass> <rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/> </owl:Class> <owl:Class rdf:ID="Amount"> <rdfs:subClassOf rdf:resource="#CbimObject"/> <owl:equivalentClass> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:about="#nextVersion"/> </owl:onProperty> <owl:allValuesFrom rdf:resource="#Amount"/> </owl:Restriction> </owl:equivalentClass> <owl:equivalentClass> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="cataloguePart"/> </owl:onProperty> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:cardinality> </owl:Restriction> </owl:equivalentClass> </owl:Class> <owl:Class rdf:ID="CataloguePart"> <rdfs:subClassOf rdf:resource="#CbimObject"/> <owl:equivalentClass> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:about="#nextVersion"/> </owl:onProperty> <owl:allValuesFrom rdf:resource="#CataloguePart"/> </owl:Restriction> </owl:equivalentClass> <owl:equivalentClass> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="amountPropertyType"/> </owl:onProperty> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:cardinality> </owl:Restriction> </owl:equivalentClass> </owl:Class> <owl:Class rdf:ID="PersonOrOrganisation">

54

<owl:equivalentClass> <owl:Restriction> <owl:allValuesFrom rdf:resource="#PersonOrOrganisation"/> <owl:onProperty> <owl:ObjectProperty rdf:about="#nextVersion"/> </owl:onProperty> </owl:Restriction> </owl:equivalentClass> <rdfs:subClassOf rdf:resource="#CbimObject"/> </owl:Class> <owl:Class rdf:ID="FunctionFulfiller"> <owl:equivalentClass> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:ID="PhysicalObject"/> <owl:Class rdf:ID="Space"/> </owl:unionOf> </owl:Class> </owl:equivalentClass> <rdfs:subClassOf rdf:resource="#CbimObject"/> <owl:equivalentClass> <owl:Restriction> <owl:onProperty> <owl:TransitiveProperty rdf:ID="parent"/> </owl:onProperty> <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:maxCardinality> </owl:Restriction> </owl:equivalentClass> </owl:Class> <owl:Class rdf:ID="Performance"> <owl:equivalentClass> <owl:Restriction> <owl:allValuesFrom rdf:resource="#Performance"/> <owl:onProperty> <owl:ObjectProperty rdf:about="#nextVersion"/> </owl:onProperty> </owl:Restriction> </owl:equivalentClass> <rdfs:subClassOf rdf:resource="#CbimObject"/> <owl:equivalentClass> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="performanceOf"/> </owl:onProperty> <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:maxCardinality> </owl:Restriction> </owl:equivalentClass> </owl:Class> <owl:Class rdf:ID="State"> <owl:equivalentClass> <owl:Restriction> <owl:allValuesFrom rdf:resource="#State"/> <owl:onProperty> <owl:ObjectProperty rdf:about="#nextVersion"/> </owl:onProperty> </owl:Restriction> </owl:equivalentClass>

55

<rdfs:subClassOf rdf:resource="#CbimObject"/> <owl:equivalentClass> <owl:Restriction> <owl:onProperty> <owl:FunctionalProperty rdf:ID="releaseStatus"/> </owl:onProperty> <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:maxCardinality> </owl:Restriction> </owl:equivalentClass> </owl:Class> <owl:Class rdf:ID="Building"> <owl:equivalentClass> <owl:Restriction> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >0</owl:cardinality> <owl:onProperty> <owl:ObjectProperty rdf:ID="physicalParent"/> </owl:onProperty> </owl:Restriction> </owl:equivalentClass> <rdfs:subClassOf> <owl:Class rdf:about="#PhysicalObject"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="#Space"> <owl:equivalentClass> <owl:Restriction> <owl:allValuesFrom rdf:resource="#Space"/> <owl:onProperty> <owl:ObjectProperty rdf:about="#nextVersion"/> </owl:onProperty> </owl:Restriction> </owl:equivalentClass> <owl:disjointWith> <owl:Class rdf:about="#PhysicalObject"/> </owl:disjointWith> <rdfs:subClassOf rdf:resource="#FunctionFulfiller"/> <owl:equivalentClass> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="spatialParent"/> </owl:onProperty> <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:maxCardinality> </owl:Restriction> </owl:equivalentClass> </owl:Class> <owl:Class rdf:ID="PropertyType"> <rdfs:subClassOf rdf:resource="#CbimObject"/> <owl:equivalentClass> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:about="#nextVersion"/> </owl:onProperty> <owl:allValuesFrom rdf:resource="#PropertyType"/> </owl:Restriction> </owl:equivalentClass> </owl:Class>

56

<owl:Class rdf:ID="Function"> <owl:equivalentClass> <owl:Restriction> <owl:allValuesFrom rdf:resource="#Function"/> <owl:onProperty> <owl:ObjectProperty rdf:about="#nextVersion"/> </owl:onProperty> </owl:Restriction> </owl:equivalentClass> <rdfs:subClassOf rdf:resource="#CbimObject"/> </owl:Class> <owl:Class rdf:ID="Terminal"> <owl:equivalentClass> <owl:Restriction> <owl:allValuesFrom rdf:resource="#Terminal"/> <owl:onProperty> <owl:ObjectProperty rdf:about="#nextVersion"/> </owl:onProperty> </owl:Restriction> </owl:equivalentClass> <rdfs:subClassOf rdf:resource="#CbimObject"/> <owl:equivalentClass> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="terminalOf"/> </owl:onProperty> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:cardinality> </owl:Restriction> </owl:equivalentClass> </owl:Class> <owl:Class rdf:ID="Requirement"> <owl:equivalentClass> <owl:Restriction> <owl:allValuesFrom rdf:resource="#Requirement"/> <owl:onProperty> <owl:ObjectProperty rdf:about="#nextVersion"/> </owl:onProperty> </owl:Restriction> </owl:equivalentClass> <rdfs:subClassOf rdf:resource="#CbimObject"/> <owl:equivalentClass> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="requirementOf"/> </owl:onProperty> <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:maxCardinality> </owl:Restriction> </owl:equivalentClass> </owl:Class> <owl:Class rdf:about="#PhysicalObject"> <owl:equivalentClass> <owl:Restriction> <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:maxCardinality> <owl:onProperty> <owl:ObjectProperty rdf:ID="isSituatedIn"/> </owl:onProperty>

57

</owl:Restriction> </owl:equivalentClass> <owl:equivalentClass> <owl:Restriction> <owl:allValuesFrom rdf:resource="#PhysicalObject"/> <owl:onProperty> <owl:ObjectProperty rdf:about="#nextVersion"/> </owl:onProperty> </owl:Restriction> </owl:equivalentClass> <owl:disjointWith rdf:resource="#Space"/> <rdfs:subClassOf rdf:resource="#FunctionFulfiller"/> <owl:equivalentClass> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:about="#physicalParent"/> </owl:onProperty> <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:maxCardinality> </owl:Restriction> </owl:equivalentClass> </owl:Class> <owl:ObjectProperty rdf:ID="contains"> <rdfs:domain> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#PhysicalObject"/> <owl:Class rdf:about="#CataloguePart"/> </owl:unionOf> </owl:Class> </rdfs:domain> <rdfs:range rdf:resource="#Amount"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#propertyType"> <rdfs:range rdf:resource="#PropertyType"/> <rdfs:domain rdf:resource="#PropertyValue"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#secondaryOrientation"> <rdfs:range rdf:resource="#Vector"/> <rdfs:domain rdf:resource="#Locator"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#maleTerminal"> <rdfs:domain rdf:resource="#Connection"/> <rdfs:range rdf:resource="#Terminal"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="terminal"> <rdfs:domain rdf:resource="#FunctionFulfiller"/> <rdfs:range rdf:resource="#Terminal"/> <owl:inverseOf rdf:resource="#terminalOf"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#baseline"> <owl:inverseOf> <owl:ObjectProperty rdf:ID="baselineObject"/> </owl:inverseOf> <rdfs:range rdf:resource="#Baseline"/> <rdfs:domain rdf:resource="#CbimObject"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#femaleTerminal"> <rdfs:domain rdf:resource="#Connection"/> <rdfs:range rdf:resource="#Terminal"/>

58

</owl:ObjectProperty> <owl:ObjectProperty rdf:about="#primaryOrientation"> <rdfs:range rdf:resource="#Vector"/> <rdfs:domain rdf:resource="#Locator"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#minBoundingBox"> <rdfs:range rdf:resource="#Vector"/> <rdfs:domain rdf:resource="#Locator"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#modifier"> <rdfs:domain rdf:resource="#CbimObject"/> <rdfs:range rdf:resource="#PersonOrOrganisation"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="situates"/> <owl:ObjectProperty rdf:about="#creator"> <rdfs:range rdf:resource="#PersonOrOrganisation"/> <rdfs:domain rdf:resource="#CbimObject"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#isSituatedIn"> <owl:inverseOf rdf:resource="#situates"/> <rdfs:range rdf:resource="#Space"/> <rdfs:domain rdf:resource="#PhysicalObject"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#spatialParent"> <rdfs:subPropertyOf rdf:resource="#parent"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="propertyValue"> <rdfs:domain rdf:resource="#CataloguePart"/> <rdfs:range rdf:resource="#PropertyValue"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="performance"> <rdfs:domain rdf:resource="#FunctionFulfiller"/> <rdfs:range rdf:resource="#Performance"/> <owl:inverseOf rdf:resource="#performanceOf"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="shape"> <rdfs:domain> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#FunctionFulfiller"/> <owl:Class rdf:about="#Terminal"/> <owl:Class rdf:about="#CataloguePart"/> </owl:unionOf> </owl:Class> </rdfs:domain> <rdfs:range rdf:resource="#Explicit3DRepresentation"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#amountPropertyType"> <rdfs:domain rdf:resource="#CataloguePart"/> <rdfs:range rdf:resource="#PropertyType"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="requirement"> <rdfs:domain rdf:resource="#Function"/> <rdfs:range rdf:resource="#Requirement"/> <owl:inverseOf rdf:resource="#requirementOf"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="document"> <rdfs:domain rdf:resource="#CbimObject"/> <rdfs:range rdf:resource="#Document"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#nextVersion">

59

<rdfs:range rdf:resource="#CbimObject"/> <rdfs:domain rdf:resource="#CbimObject"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="fulfills"> <owl:inverseOf> <owl:ObjectProperty rdf:ID="isFulfilledBy"/> </owl:inverseOf> <rdfs:domain rdf:resource="#FunctionFulfiller"/> <rdfs:range rdf:resource="#Function"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#physicalParent"> <rdfs:subPropertyOf rdf:resource="#parent"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#translation"> <rdfs:range rdf:resource="#Vector"/> <rdfs:domain rdf:resource="#Locator"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#maxBoundingBox"> <rdfs:range rdf:resource="#Vector"/> <rdfs:domain rdf:resource="#Locator"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#cataloguePart"> <rdfs:domain rdf:resource="#Amount"/> <rdfs:range rdf:resource="#CataloguePart"/> </owl:ObjectProperty> <owl:TransitiveProperty rdf:ID="physicalChild"> <rdfs:subPropertyOf> <owl:TransitiveProperty rdf:ID="child"/> </rdfs:subPropertyOf> <rdfs:range rdf:resource="#PhysicalObject"/> <rdfs:domain rdf:resource="#PhysicalObject"/> <owl:inverseOf rdf:resource="#physicalParent"/> </owl:TransitiveProperty> <owl:TransitiveProperty rdf:about="#child"> <rdfs:domain rdf:resource="#FunctionFulfiller"/> <rdfs:range rdf:resource="#FunctionFulfiller"/> <owl:inverseOf rdf:resource="#parent"/> </owl:TransitiveProperty> <owl:TransitiveProperty rdf:ID="spatialChild"> <rdfs:range rdf:resource="#Space"/> <rdfs:domain rdf:resource="#Space"/> <rdfs:subPropertyOf rdf:resource="#child"/> <owl:inverseOf rdf:resource="#spatialParent"/> </owl:TransitiveProperty> <owl:FunctionalProperty rdf:ID="zCoordinate"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#float"/> <rdfs:domain rdf:resource="#Vector"/> </owl:FunctionalProperty> <owl:FunctionalProperty rdf:ID="layerIndex"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/> <rdfs:domain rdf:resource="#CbimObject"/> </owl:FunctionalProperty> <owl:FunctionalProperty rdf:ID="userID"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#CbimObject"/> </owl:FunctionalProperty> <owl:FunctionalProperty rdf:ID="yCoordinate"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#float"/> <rdfs:domain rdf:resource="#Vector"/> </owl:FunctionalProperty> <owl:FunctionalProperty rdf:ID="amount">

60

<rdfs:domain rdf:resource="#Amount"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#float"/> </owl:FunctionalProperty> <owl:FunctionalProperty rdf:ID="changelog"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#CbimObject"/> </owl:FunctionalProperty> <owl:FunctionalProperty rdf:ID="description"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#CbimObject"/> </owl:FunctionalProperty> <owl:FunctionalProperty rdf:ID="modificationDate"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#date"/> <rdfs:domain rdf:resource="#CbimObject"/> </owl:FunctionalProperty> <owl:FunctionalProperty rdf:ID="creationDate"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#date"/> <rdfs:domain rdf:resource="#CbimObject"/> </owl:FunctionalProperty> <owl:FunctionalProperty rdf:ID="releaseDate"> <rdfs:domain rdf:resource="#CbimObject"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#date"/> </owl:FunctionalProperty> <owl:FunctionalProperty rdf:about="#releaseStatus"> <rdfs:domain rdf:resource="#CbimObject"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:FunctionalProperty> <owl:FunctionalProperty rdf:ID="baselineStatus"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#boolean"/> <rdfs:domain rdf:resource="#Baseline"/> </owl:FunctionalProperty> <owl:FunctionalProperty rdf:ID="name"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#CbimObject"/> </owl:FunctionalProperty> <owl:FunctionalProperty rdf:ID="value"> <rdfs:domain rdf:resource="#PropertyValue"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#float"/> </owl:FunctionalProperty> <owl:FunctionalProperty rdf:ID="valueDomain"> <rdfs:domain rdf:resource="#PropertyType"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/> </owl:FunctionalProperty> <owl:FunctionalProperty rdf:ID="documentUri"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Document"/> </owl:FunctionalProperty> <owl:FunctionalProperty rdf:ID="unit"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#PropertyType"/> </owl:FunctionalProperty> <owl:FunctionalProperty rdf:ID="expired"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#boolean"/> <rdfs:domain rdf:resource="#CbimObject"/> </owl:FunctionalProperty> <owl:FunctionalProperty rdf:ID="documentAliasFilePath"> <rdfs:domain rdf:resource="#Document"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:FunctionalProperty> <owl:FunctionalProperty rdf:ID="xCoordinate"> <rdfs:domain rdf:resource="#Vector"/>

61

<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#float"/> </owl:FunctionalProperty> </rdf:RDF>

62

Voorbeeld ‘Utility Ducts’

Inhoud 

• 1 Inleiding • 2 Fasering van de ontwikkeling • 3 Toepassing van systems engineering • 4 Projectorganisatie • 5 Bepalen van de gewenste functies en bouwdelen • 6 Eisen benoemen, kwantificeren en verdelen over de functies • 7 Beschrijving van de artikelbibliotheek • 8 Beschrijving van een 3D-model

Inleiding 

Het probleem dat de aanleiding vormt tot de casus laat zich, in termen van de gebruiker, als volgt omschrijven: De gemeente Rotterdam moet een aantal panden in een renovatiewijk aansluiten aan een aantal nutsvoorzieningen en deze aansluitingen voor een bekend aantal jaren in stand houden. Tevens moet de mogelijkheid geboden worden om deze aansluitingen (qua aantal en soort) gedurende die jaren aan te passen of te verwijderen, zonder veel overlast voor de omgeving.

Op basis van deze formulering is een oplossingsrichting gekozen: ‘Utility Ducts’. Deze oplossing laat zich als volgt omschrijven: In de wijk wordt een systeem aangelegd bestaande uit een aantal betonnen putten, groot genoeg om in te werken en de bochten van de kabels en leidingen van de nutsvoorzieningen te bevatten. Deze putten zijn met elkaar en met de huizen verbonden door middel van een aantal mantelbuizen waarin de kabels en leidingen worden aangelegd. De putten worden afgesloten met een deksel. In dit hoofdstuk wordt informatie beschreven die opgenomen zou kunnen zijn in een gemeenschappelijke dataset tijdens het constructief ontwerp van het ‘Utility Ducts’ project.

Een uitgebreidere beschrijving van de casus is te vinden in hoofdstuk 7 van het rapport met de titel Toekomst voor het bouwproces, Een 3D-objectbenadering.

De informatie in dit hoofdstuk wordt uitsluitend gepresenteerd als voorbeeld; het aantal onderdelen in het bouwwerk is daarom beperkt; daarnaast worden alleen de informatie-elementen getoond die echt nodig zijn voor het voorbeeld.

Fasering van de ontwikkeling 

De ontwikkeling van een systeem doorloopt gewoonlijk een aantal fasen of niveaus van ontwikkeling. De tabel hieronder laat zien welke fasering we gekozen hebben voor de ontwikkeling van het bouwwerk 'Utility Ducts'. In principe is deze fasering vrij te kiezen en is

63

afhankelijk van de aard van een te ontwikkelen bouwwerk. Volgens de gekozen fasering zal een drietal baselines toegepast worden. Bij iedere baseline hoort een abstractieniveau van de uitwerking van het fysieke bouwwerk. De verdeling is voor dit bouwwerk als volgt gekozen:

In de voorliggende casus wordt vooral de informatie beschreven die behoort tot het constructief ontwerp.

Toepassing van systems engineering 

In het voorbeeldproject wordt de methode van systems engineering toegepast. Dat houdt onder meer in dat voor iedere fase hetzelfde systems engineering proces wordt doorlopen dat globaal bestaat uit:

• Specificatieproces van eisen van belanghebbenden • Functionele analyse en allocatie • Ontwerpproces • Verificatie of het ontwerp voldoet aan de eisen.

Zoals hiervoor werd vermeld, bestaat ons eenvoudige voorbeeld uit een drietal fasen of niveaus van ontwikkeling. Tijdens de vraagspecificatie (Laag 01) staat de hoofdfunctie centraal: het bieden van ondergrondse ruimte voor kabels en leidingen voor nutsvoorzieningen, inclusief werkruimten. Deze wordt gekoppeld aan het bouwwerk als geheel: 'Utility Ducts Lloyds kwartier'. Vervolgens worden tijdens het Concept Ontwerp (Laag 02) deelfuncties bepaald en bouwdelen gekozen. Tevens wordt vastgelegd welke bouwdelen zorgdragen voor het vervullen van de functies. Tijdens het Constructief ontwerp komen we op het derde niveau (Laag 03). Gezien de eenvoud van het voorbeeld zijn de functies niet meer verder verdeeld en is volstaan met een detailleringsslag van de bouwdelen. Voor wat betreft de bouwdelen zijn we op componentniveau uitgekomen. Het detailleringsniveau wordt enerzijds bepaald door de behoeften voor ruimtelijke coördinatie, en anderzijds bepaald door overwegingen op het vlak van inkoop, uitbesteding en logistiek.

64

Projectorganisatie 

Voor de fase Constructief ontwerp wordt een projectorganisatie toegepast zoals in het volgende schema is afgebeeld in de vorm van een zogenaamd Interactie Model (IAM). In dit model wordt zichtbaar gemaakt welke zakelijke afspraken tot het uitvoeren van werkzaamheden worden gemaakt en welke rol initiatiefnemer dan wel uitvoerder is.

De volgende rollen zijn betrokken in de organisatie:

65

De projectregisseur maakt met de betrokken rollen afspraken over de bijdrage van een ieder. Overeenkomstig de VISI-methodiek worden dit transacties genoemd. In het project worden de volgende transacties onderscheiden:

Voor het onderdeel projectorganisatie (rollen, transacties) maken we gebruik van de VISI-systematiek. Om die reden vinden we deze informatieobjecten niet terug in het CBIM.

Bepalen van de gewenste functies en bouwdelen 

In het hoofdstuk 'Toepassing van systems engineering is aangegeven hoe het proces verloopt van 'analyse van functies' en 'bepalen van bouwdelen'. In dit hoofdstuk worden functies en bouwdelen op de verschillende niveaus benoemd. Tijdens de vraagspecificatie is de hoofdfunctie vastgesteld die het ‘Utility Ducts’ project moet kunnen vervullen.

We maken nu de slag naar de bouwdelen die ook wel functievervullers of fysieke objecten worden genoemd. In de eerste laag is ons bouwwerk als geheel geïdentificeerd. De volgende tabel identificeert het bouwwerk; aangezien er geen hogergelegen bouwdeel is, is de rubriek 'Parent' leeg.

Tijdens het Concept ontwerp (Laag 02) zijn de volgende functies vastgesteld:

66

Tijdens het Concept ontwerp (Laag 02) is het Utility Ducts bouwwerk onderverdeeld in subsystemen. Er is ook een subsysteem gereserveerd voor de bebouwde omgeving, strikt genomen geen onderdeel van het bouwwerk maar welk belangrijk om de inpassing van het bouwwerk te kunnen beschouwen.

Tijdens het Concept ontwerp (Laag 02) worden ook de relaties gelegd tussen functies en bouwdelen. Een bouwdeel dient altijd een functie te bezitten. Een functie kan vervuld worden door één of meer bouwdelen. De volgende tabel wordt een functie/bouwdeel-matrix genoemd. In deze matrix wordt zichtbaar welke bouwdelen de gewenste functies vervullen.

In de fase constructief ontwerp (Laag 03) zijn de functies niet verder gespecificeerd. Dat is in dit voorbeeld een keuze geweest. De bouwdelen zijn wel verder gedetailleerd; de subsystemen zijn verdeeld in componenten. Bij iedere component is een Part-ID opgenomen. Die code verwijst naar een artikel in een artikelbibliotheek. Verder is de dimensie van de hoeveelheid van het desbetreffende artikel aangegeven. Voorts is bij een aantal componenten een 3D-

67

modelnummer aangegeven; dit is een verwijzing naar een 3D-file waarin de desbetreffende component is weergegeven. Indien de verwijzing naar de 3D-file aanwezig dan kan in de 3D-file informatie over hoeveelheden gevonden worden. Indien de verwijzing naar de 3D-file niet aanwezig is, dient de hoeveelheid in deze tabel gevonden te worden. Let op, er is in dit voorbeeld geen compleetheid nagestreefd.

Eisen benoemen, kwantificeren en verdelen over de functies 

Door middel van de functies wordt omschreven van het toekomstige bouwwerk moet 'kunnen'. Hoe 'goed' het bouwwerk dat moet 'kunnen' wordt vastgelegd door middel van de functionele eisen. Bij voorkeur proberen we die eisen kwantitatief te beschrijven. De volgende tabel geeft een voorbeeld van zulke eisen. In de tabel is ook voor iedere eis de relatie met de functie gelegd, waarop de eis betrekking heeft.

Beschrijving van de artikelbibliotheek 

Een artikelbibliotheek is ook in het informatiesysteem opgenomen. Naast karakteristieke gegevens als gewicht/unit, dimensie en eenheid, vinden we ook voor ieder onderdeel een 3D-beschrijving. Voor bepaalde onderdelen kan die beschrijving parametrisch zijn:

68

Beschrijving van een 3D‐model 

Dan de 3D-modellen van het bouwwerk. Het volgende plaatje geeft een bovenaanzicht zonder veel details. Voor enkele bouwdelen, zoals de putten, mantelbuizen en huisaansluitingen, zijn de bouwdeel-ID-'s en omschrijvingen weergegeven.

Vervolgens zoomen we in op de middelste put. We zien meer details: de pomp met afvoerleiding, het lichtpunt en de schakelaar.

69

We zien in het volgende plaatje een beeld van het IFC-model met de bebouwde omgeving (Bouwdeel X1600/1) en als laatste een IFC-model met een samenstelling van de overige bouwdelen.

70

71

Termen en definities COINS specifieke termen en definities 

Baseline De beschrijving van een product in een bepaalde fase van de ontwikkeling. Een 'baseline' kan bevroren worden en dan dienen als stabiel uitgangspunt voor werkzaamheden in volgende ontwikkelfasen.

Bouwdelen De beschrijving van een fysiek onderdeel van een bouwwerk

CBIM Het COINS Bouw Informatie Model (CBIM) bevat de afspraken over hoe de informatie van bouwwerken vastgelegd wordt. Dit model is onderdeel van de COINS-systematiek.

CEM De COINS Engineering Methode (CEM) is een verzameling werkmethoden die van belang is voor de integratie van het bouwproces. Deze werkmethoden zijn onderdeel van de COINS-systematiek.

COINS-systematiek Een verzameling algemene afspraken voor proces en informatie die gezamenlijk de ruggengraat vormt voor integratie van het bouwproces.

COINS-referentiekader Aanvullingen op de COINS-systematiek gericht op specifieke toepassingsgebieden zoals 'functioneel specificeren' of 'ramen van hoeveelheden'.

COINS-implementatierichtlijnen Richtlijnen voor de IT-implementatie van de COINS-standaard, met als doel om interoperabiliteit tussen IT-systemen te bewerkstelligen.

Eis Beschrijving van een gewenste eigenschap van een functie, product of dienst.

Functie Beoogde werking of verrichting van een product.

Functioneel ontwerpen Een proces waarin de functionele beschrijving van een product ontstaat.

Functionele eis Beschrijving van een eis ten aanzien van een functie van een product.

Status Door middel van de status wordt de betekenis vastgelegd van een bepaald informatieobject voor de totstandkoming van een bouwwerk. De status wordt bepaald door drie eigenschappen

72

die bij ieder informatieobject voorkomen, te weten: Vrijgavestatus, Baselinestatus en Geldigheidsstatus.

Systems Engineering Een interdisciplinaire aanpak en bijbehorende middelen die nodig zijn om een beheerste ontwikkeling van systemen mogelijk te maken.

Toestand Een bouwdeel doorloopt een Product Life Cycle, van ontwerp tot aan sloop. Waar een bouwdeel zich bevindt in de Life-cycle wordt vastgelegd door de Toestand (wordt ook wel Life-cycle stage genoemd).

Versie Een bepaald informatieobject kan meerdere keren voorkomen in een informatiesysteem. De verschillende instanties worden onderscheiden door een versienummer.

Virtueel Bouwen Virtueel bouwen is een kreet die staat voor het beeld dat een bouwwerk eerst in een digitale omgeving wordt vastgelegd, alvorens de werkelijke bouw plaatsvindt. Het virtuele/digitale bouwwerk is het resultaat van het specificeren en ontwerpen en vormt het uitgangspunt voor inkoop, logistiek, realisatie, kwaliteitsborging, etc.

73

FAQ - Vaak gestelde vragen 1. Hoe wordt de COINS-standaard ontwikkeld en beheerd? De standaard komt voort

uit het COINS-programma. Dit programma is een initiatief van de bouwsector voor de bouwsector. De organisatie bestaat uit een projectgroep, een kerngroep en werkgroepen. In de projectgroep vindt de besluitvorming plaats. De kerngroep is het dagelijkse bestuur. Een projectleider verzorgt de uitvoering van werkzaamheden in samenwerking met werkgroepen. Het COINS-programma stemt af met de Bouw Informatie Raad voor de samenhang met andere nationale bouwstandaarden. Internationale afstemming vindt plaats door deelname aan het IAI (Interntional Alliance for Interoperability). Het COINS-programma wordt uitgevoerd onder de vlag van CUR Bouw & Infra in Gouda.

Rijksgebouwendienst

© Projectgroep COINS, CUR Bouw & Infra, Gouda, 2008

Meer informatie over COINS, zie www.coinsweb.nl