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

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 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.
Enlarge
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).
Enlarge
Figuur 2: Decompositiestructuur van bouwdelen (physical objects).

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.
Enlarge
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.

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
Enlarge
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.

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.
Enlarge
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.
Enlarge
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.

Figuur 7: Een eis is verbonden met één functie
Enlarge
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
Enlarge
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.

Figuur 9: Prestaties worden vergeleken met de daaraan gestelde eisen
Enlarge
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
Enlarge
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.

Figuur 11: FunctieVervuller beschrijft het gemeenschappelijke gedrag van bouwdelen en ruimtes
Enlarge
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.

Figuur 12: Bouwdeel wordt samengesteld uit een verzameling bibliotheekobjecten.
Enlarge
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 probleemoplossingsproces. 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.

Figuur 11: Systems Engineering proces
Enlarge
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.

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
Enlarge
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.

Figuur 14: Modelmanagement attributen
Enlarge
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
  • 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
Enlarge
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 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 BIM Documentatie op het web

http://www.coinsweb.nl/c-bim.owl HTML documentatie

COINS Applicatie Programming Interface

De API is gedefinieerd op het abstractieniveau van model/class/object/attribute/relation. De specifieke COINS objecttypen, attributen en relaties worden aangeduid met een getalswaarde die als evenzovele constanten aan de interface worden toegevoegd.

Model level - object

  • int modelID = create(string uri)
    Create a new COINS BIM. The uri string will be the global ID of the model.
  • int modelID = load(string uri)
    Load a COINS BIM. A URI may either contain a web address or a reference to a local file.
  • void save(string filepath, int modelID)
    Save a model on a local file system.
  • int objectID = addObject(int modelID, int classID, string objectName)
    Create and add a new object to the model.
  • void removeObject(int modelID, int objectID)
    Remove an object from the model and remove also all relations with this object.
  • int objectCount = getObjectsCount(int modelID)
    Return the number of objects in the model.
  • int objectID = getObjectID(int ModelID, int index)
    Return the objectID of the object with a certain index in the model.

Object level – class

  • int classID = getObjectClass(int objectID)
    Return the class of an object.
  • string className = getClassName(classID)
    Return the name of a class.
  • string attributeName = getAttributeName(int attributeID);
    Return the name of an attribute.
  • string relationName = getRelationName(int relationID);
    Return the name of a relation.

Object level – singular attributes/relations

  • string value = getAttributeStringValue(int objectID, int attributeID)
    Return the string typed attribute value.
  • int value = getAttributeIntValue(int objectID, int attributeID)
    Return the integer typed attribute value.
  • float value = getFAttributeloatValue(int objectID, int attributeID)
    Return the float typed attribute value.
  • boolean value = getAttributeBooleanValue(int objectID, int attributeID)
    Return the boolean typed attribute value.
  • void setAttributeStringValue(int objectID, int attributeID, string value)
    (Re)Set the string typed attribute value.
  • void setAttributeIntValue(int objectID, int attributeID, int value)
    (Re)Set the integer typed attribute value.
  • void setAttributeFloatValue(int objectID, int attributeID, float value)
    (Re)Set the float typed attribute value.
  • void setAttributeBooleanValue(int objectID, int attributeID, boolean value)
    (Re)Set the boolean typed attribute value.
  • int targetObjectID = getRelationTargetObject(int sourceObjectID, int relationID)
    Return the object referenced by the singular relation.
  • void setRelationTargetObject(int sourceObjectID, int relationID, int targetObjectID)
    (Re)Set the object referenced by the singular relation.

Object level – multiple attributes/relations

  • int attributeValuesCount = getAttributeValuesCount(int objectID, int attributeID)
    Return the number of attribute values.
  • removeAttributeValue(int objectID, int attributeID, int index);
    Remove an attribute value.
  • addAttributeStringValue(int objectID, int attributeID, string value)
    Add a string typed attribute value.
  • string value = getAttributeStringValue(int objectID, int attributeID, int index)
    Return a string typed attribute value.
  • addAttributeIntValue(int objectID, int attributeID, int value)
    Add an integer typed attribute value.
  • int value = getAttributeIntValue(int objectID, int attributeID, int index)
    Return an integer typed attribute value.
  • addAttributeFloatValue(int objectID, int attributeID, float value)
    Add a float typed attribute value.
  • float value = getAttributeFloatValue(int objectID, int attributeID, int index)
    Return a float typed attribute value.
  • int relationsCount = getRelationsCount(int sourceObjectID, int relationID)
    Return the number of relations.
  • removeRelationTargetObject(int sourceObjectID, int attributeID, int index);
    Remove an object from the relations set.
  • void addRelationTargetObject(int sourceObjectID, int relationID, int targetObjectID)
    Add an object to the relations set.
  • int targetObjectID = getRelationTargetObject(int sourceObjectID, relationID, int index)
    Return a relation object.
Afkomstig van CoinsWiki NL, de Vrije Encyclopedie. "http://www.coinsweb.nl/wiki/index.php/Formele_beschrijving_van_de_systematiek"
Personal tools