---

Objectenbomen

Communicatie tussen disciplines in de bouw kan sterk worden verbeterd door effectieve inzet van Informatie- en CommunicatieTechnologie (ICT). Hier wordt dan ook al vele jaren onderzoek naar gedaan. Dit onderzoek heeft echter tot op heden nauwelijks geleid tot praktisch toepasbare resultaten.

Op deze plaats een bottom-up-benadering gepresenteerd die zich richt op eenvoudig ontwikkeling van projectinformatiesystemen. De benadering is gebaseerd op eenvoudige decompositiebomen van de fysieke objecten die worden ontworpen en gebouwd: objectenbomen.

1 Communicatie in de bouw

De bouw staat de komende jaren voor grote uitdagingen. Er ligt een grote hoeveelheid werk te wachten, inclusief een aantal zeer grote projecten. In Nederland bijvoorbeeld de uitbreiding van Schiphol, de tweede Maasvlakte, de Betuweroute, de HSL en andere grote spoorprojecten. Bij dergelijke projecten, maar ook bij kleinere, worden steeds hogere eisen gesteld aan de beheersing van kwaliteit, tijd en kosten.

Van oudsher wordt de bouw gekenmerkt door wisselende samenwerkingsverbanden tussen verschillende disciplines van verschillende organisaties. Daarbij is de communicatie tussen disciplines een kritische succesfactor. Bij het streven naar betere beheersing van kwaliteit, tijd en kosten richt men zich dan ook in belangrijke mate op verbetering van de onderlinge communicatie.

De laatste jaren zijn een aantal ontwikkelingen te herkennen die zijn gericht op het verbeteren van de communicatie tussen disciplines, zoals: nieuwe contractvormen, Design & Construct, Turnkey, e.d., classificatie en codering, prestatie-benadering, systeembenadering.

Nieuwe contractvormen

Op dit moment staan nieuwe contractvormen voor aanbesteding zeer in de belangstelling, zoals Design & Construct en Built - Operate - Transfer. De achterliggende gedachte is om de capaciteiten van de verschillende partijen zo goed mogelijk te gebruiken. Onder andere. door ervoor te zorgen dat oplossingen worden ontwikkeld en risico's worden beheerst door de partijen die dit het beste kunnen.

Classificatie en codering

Classificatie of identificatie is het onderscheiden van (object)klassen; codering is het toekennen van codes aan deze klassen. Het bekendste voorbeeld is SfB. Oorspronkelijk richtte classificatie in de bouw zich vooral op gebouwelementen. Later is men classificaties gaan uitbouwen met bijv. werksoorten naast elementen (zie STABU), met verschillende decompositieniveaus, met bibliotheekstructuren, etc. In wezen gaat het daarmee niet meer over classificatie maar over gebouwmodellering, zie verder.

Prestatiebenadering

Bij de prestatiebenadering gaat het erom dat de bouwopgave wordt omschreven in termen van kwantificeerbare, geëiste en gewenste prestaties, in plaats van in termen van voorgeschreven oplossingen.

Systeembenadering

De systeembenadering houdt eenvoudig gezegd in dat het te leveren product wordt beschouwd als een verzameling systemen, die een bepaalde prestatie moeten leveren. Bijvoorbeeld een ruimtesysteem, een draagsysteem of een verwarmingssysteem.

Ontwikkelingen als hierboven omschreven hangen sterk met elkaar samen. Bijvoorbeeld: Design & Construct vraagt om een prestatiegericht programma van eisen; en het ligt voor de hand om hierbij uit te gaan van eisen aan te onderscheiden systemen.

2 ICT in de bouw

Bij communicatie in de bouw speelt uiteraard ook Informatie- en CommunicatieTechnologie (ICT) een belangrijke rol. Als de stand van zaken met betrekking tot ICT in de bouw wordt beschouwd, dan kan worden vastgesteld dat deze voornamelijk is gebaseerd op CAD-systemen (tekensystemen) en uitwisseling van CAD-data. Daarbij is, in zeer bescheiden mate, sprake van integratie met CAE-systemen (rekenprogramma's), besteksprogramma's etc.

CAD-systemen en CAD-data zijn echter fundamenteel beperkt doordat het onderliggende werkproces, het tekenen, niet anders is dan vroeger. Bouwkundige informatie wordt weergegeven als geometrische informatie. De betekenis hiervan is impliciet vastgelegd en moet worden teruggevonden door menselijke interpretatie. Een verzameling lijntjes op een tekening wordt slechts door interpretatie van een bouwkundige herkend als een kolom.

Al geruime tijd geleden is men gaan zoeken naar een betere benadering waarbij ontwerpgegevens betekenisvol kunnen worden vastgelegd en uitgewisseld. Daarbij wordt een kolom niet als een groep lijntjes beschreven, maar als een object met de naam kolom en verder met vorm, materiaal, etc. Dit idee is de achtergrond van wat nu productmodelleren wordt genoemd. Het besef dat de gebruikte begrippen uniek gedefineerd zouden moeten zijn leidde vervolgens in de jaren tachtig tot de ontwikkeling van de STEP-standaard, officieel ISO 10303.

Het doel van STEP was (en is) het komen tot een standaard voor het vastleggen en uitwisselen van betekenisvolle productgegevens: niet alleen geometrie maar ook gegevens over materiaal, verbindingen, productstructuur, constructieve en fysische eigenschappen etc. Dit initiatief richtte zich niet specifiek op de bouw, maar mondde uit in een reeks van initiatieven en projecten voor verschillende industrieën. Uiteraard hangt de STEP-ontwikkeling sterk samen met ICT-concepten en ontwikkelingen hierin.

Tot dusverre is het doel van STEP maar gedeeltelijk bereikt. Er is een generieke basis (de zgn. generic resources) waar echter de nodige discussiepunten over bestaan. Voor andere industrieën dan de bouw zijn specifieke standaards ontwikkeld, bijvoorbeeld voor de procesindustrie, de scheepsbouw en de auto-industrie. Deze standaards zijn verschillend in opzet en mede daardoor niet compatibel met elkaar, ondanks het bestaan van de generieke basis.

Voor de bouw is er na al die jaren nog steeds geen algemeen aanvaarde en gebruikte STEP-standaard. Hoe komt dat? Waarom lukt het niet om een internationale, breed gedragen, krachtige standaard voor de bouw te ontwikkelen? Verschillende factoren spelen een rol:

• het veelal kleinschalige, lokale dan wel nationale karakter van de bouwbranche, zonder dominante partijen, waardoor het moeilijk is om te komen tot branche-afspraken,
• het internationale karakter van de IT-branche waardoor het extra moeilijk is om te komen tot IT-ondersteuning van standaards voor de bouw,
• het bestaan van diverse IT-benaderingen voor ondersteuning van de standaard, en (vooral) het steeds weer ontstaan van nieuwe benaderingen.

Een recentere ontwikkeling op dit gebied is de ontwikkeling van Industry Foundation Classes (IFCs) door de International Alliance for Interoperability (IAI). Dit zijn in wezen gestandaardiseerde CAD-objecten die zowel geometrische als betekenisvolle productinformatie bevatten. De IAI die deze ontwikkelt is een consortium van CAD-leveranciers zoals Autodesk, Bentley, Nemetschek e.a. Deze ontwikkeling heeft duidelijk voordelen boven de STEP-ontwikkelingen, o.a. doordat deze getrokken wordt door de CAD-leveranciers. Maar ook de IFCs komen uiterst langzaam tot stand.

3 Uitgangspunten voor verbetering

Bij het zoeken naar een benadering om communicatie en informatie-uitwisseling te verbeteren kan worden gekeken naar verschillende ontwikkelingen:

(1) basistechnologieën, en (2) nieuwe concepten voor communicatie in de bouw.

Basistechnologieën

Voor de basistechnologieën komen we in eerste instantie uit bij STEP. Binnen STEP zijn modelleertalen ontwikkeld (in het bijzonder EXPRESS), en zijn verschillende implementatieprincipes uitgewerkt. Het uitgangspunt van STEP is goed: betekenisvolle gegevensuitwisseling met behulp van een open standaard. In de uitwerking voor de bouw schiet STEP echter tekort. Het standaardisatieproces verloopt uiterst moeizaam, mede door het voortdurende gebrek aan capaciteit en financiële middelen. Daarnaast blijkt de IT-basis niet (meer) de meest effectieve en worden ontwikkelingen achterhaald door nieuwe IT-benaderingen.

Dit heeft geleid tot verschillende alternatieven en aanvullingen. Bijvoorbeeld het ondersteunen van functies en gedrag met de objectgeörienteerde CORBA-technologie. In het ESPRIT-project VEGA is recentelijk gewerkt aan de toepassing van CORBA in combinatie met STEP voor ondersteuning van werkstroombeheersing (workflow management) in bijvoorbeeld de bouw.

Een andere trend is aan te duiden als 'the minimal approach'. In deze benadering wordt het gegevensmodel tot een minimum beperkt om zo te komen tot een handzaam formaat voor gegevensuitwisseling in de bouw. Uitwerkingen van deze benaderingen hebben zich gericht op gebouwgeometrie (Tarandi) en op integratie met EDI (de Vries).

De meest belovende ontwikkeling in de sfeer van basistechnologieën is echter de verdere ontwikkeling van internet-technieken, in het bijzonder met XML.

Wat betreft nieuwe concepten voor communicatie in de bouw is de zogenaamde viewbenadering van belang. Deze benadering gaat uit van de vaststelling dat partijen in de bouw verschillende disciplines vertegenwoordigen die elk een eigen invalshoek op ontwerpinformatie hebben. Als gevolg daarvan hebben zij elk een eigen informatiebehoefte, die ondersteund moet worden met specifieke gegevensverzamelingen (te beschrijven in zgn. viewmodellen). Voor communicatie in de bouw betekent dit dat viewconversie ondersteund moet worden.

Ook de viewbenadering is op verschillende manieren uitgewerkt. Voor de bouw het verst in het ESPRIT-project ATLAS (1991-1994). Het grote probleem bij de view benadering, zoals in het ATLAS-project geconstateerd, is dat de relaties tussen de diverse, viewafhankelijke informatiemodellen (de viewconversie) te ingewikkeld worden, waardoor implementatie en onderhoud van de conversie-software te kostbaar wordt.

4 Probleemstelling

Terugkijkend kan worden vastgesteld dat de STEP-benadering voor neutrale, betekenisvolle gegevensuitwisseling op zich een goede benadering is en noodzakelijk om communicatie in de bouw verder te brengen. Maar bij het komen tot toepasbare resultaten bestaan enkele grote valkuilen:

1. verzanden in te ingewikkelde informatiemodellen, waardoor van implementatie en toepassing weinig terecht komt.
2. kiezen voor een informatietechnologie die na verloop van tijd achterhaald wordt door nieuwe ontwikkelingen,
3. te grote verwachtingen van standaardisatie, branche-afspraken e.d.

Hoe dan wel ?

Hoe dan wel? Zoals gezegd is het uitgaan van neutrale, betekenisvolle productinformatie een voorwaarde voor verbetering. Met oplossingen gebaseerd op CAD-systemen alleen komen we er niet. Maar verder moet vooral worden gestreefd naar eenvoud. Tenslotte is het zinvol om te streven naar ondersteuning van het projectmanagement; het projectmanagement kan er immers voor zorgen dat nieuwe communicatieconcepten snel ingevoerd kunnen worden.

De vraag die dit onderzoek wil beantwoorden is daarom:

Hoe kan een benadering voor interdisciplinaire communicatie in grote bouwprojecten worden ontwikkeld, die neutraal, pragmatisch en bottom up is en in elk geval zorgt voor ondersteuning van het projectmanagement?

5 Objectenbomen

Om de hierboven gestelde onderzoeksvraag te beantwoorden, is het zaak pragmatisch en bottom-up te werk te gaan. Hierbij zijn een aantal 'automatismes' van STEP-gerelateerde projecten ter discussie gesteld. Dit heeft geleid tot een benadering die we zullen aanduiden als de objectenboom-benadering.

Hieronder worden puntsgewijs de belangrijkste kenmerken van de objectenboom-benadering aangegeven.

• Een objectenboom is een instantiemodel
• Objecten zijn functievervullers
• De objectenboom is een decompositieboom
• De objectenboom beperkt zich tot een minimum aan relaties
• Voor vormbeschrijving wordt verwezen naar CAD-tekeningen

Een objectenboom is een instantiemodel

Of in gewoon Nederlands: een objectenboom beschrijft een enkel ding, geen klasse van dingen. Eén van de hierboven aangeduide 'STEP-automatismes' is het beginnen bij een zogenaamde type-model, een model dat een bepaalde klasse van objecten beschrijft, bijvoorbeeld gebouwen, wegen of viaducten. De objectenboom-benadering gaat echter uit van het exemplaar. Met andere woorden: de objectenboom is een instantiemodel, geen typemodel. Hierdoor wordt voorkomen dat de ontwikkeling van het typemodel zo langdurig en ingewikkeld wordt dat de ontwikkeling van instantiemodellen niet uit de verf komt. Dit was één van de grote problemen bij de STEP-gerelateerde projecten in het begin van de jaren '90.

Objecten zijn functievervullers

De 'bouwstenen' van een objectenboom zijn de objecten. Als objecten worden beschouwd: fysieke dingen die een functie vervullen. Deze functie kan zijn het leveren van een bepaalde geëiste prestatie, vastgelegd in een programma van eisen.

Op deze wijze is de objectenboom te beschouwen als een oplossingsboom, waarbij tevens wordt vastgelegd voor welke functies de objecten een oplossing zijn.

De objectenboom is een decompositieboom

Zoals de aanduiding 'boom' suggereert heeft de objectenboom een hiërarchische structuur. Nu zijn er vele manieren om hiërarchie aan te brengen in een productstructuur. De objectenboombenadering streeft echter naar eenvoud en kiest daarom voor één hiërarchisch principe: decompositie ('bestaat-uit').

Echter, ook met decompositie kan met nog verschillende kanten uit. De twee basisprincipes zijn:

• subsysteem- decompositie, d.w.z. decompositie naar vorm en plaats,
• aspectsysteem-decompositie, d.w.z. decompositie in objecten met een gemeenschappelijke rol.

Beide decompositieprincipes zijn nodig en maken daarom deel uit van de objectenboombenadering. De relatie tussen beiden is echter complex, en wordt daarom niet vastgelegd in de objectenboom.

De objectenboom beperkt zich tot een minimum aan relaties

Relaties tussen objecten is wederom een onderwerp dat kan leiden tot complexe modelstructuren. Daarom wordt voor objectenbomen een minimum aan soorten relaties gehanteerd. Allereerst de twee soorten decompositierelaties als hierboven omschreven. Daarnaast alleen nog fysieke raakvlakken. En dus geen functionele, logische of andersoortige relaties.

Voor vormbeschrijving wordt verwezen naar CAD-tekeningen

Ook voor het opnemen van vormbeschrijving bestaan vele methoden, die echter meestal ook leiden tot zeer complexe modellen. Ook hierbij wordt daarom gekozen voor eenvoud, en wel door te verwijzen naar CAD-tekeningen.

6 Implementeren van objectenbomen

Door de eenvoud van de benadering kan ook de implementatie van de objectenboom met ondersteunende software eenvoudig worden gehouden. Het kan zelfs met systemen als Excel en Access, maar levert dan weinig ondersteuning op het gebied van gegevensbeheer en -onderhoud, c.q. user interface. Een beter maar duurder alternatief is één van de vele PDM-systemen die op de markt zijn. In de nabije toekomst zullen vooral nieuwe besturingssystemen en internetsoftware de mogelijkheden voor softwareondersteuning verder vergroten.

7 De HSL case

Bij het HSL-project is de hierboven beschreven benadering in grote lijnen toegepast in de zogenaamde HSL-objectenboom. Dit heeft geleid tot een boomstructuur met bovenin uiteraard de HSL-spoorlijn. Deze decomponeert in een paar stappen tot enkele duizenden HSL-objecten, zoals bruggen, viaducten, duikers, geluidsschermen, te verleggen kabels en leidingen etc.

Eigenlijk is de HSL-benadering nog eenvoudiger geweest dan de hier gepropageerde benadering. Zo zijn onder andere de functionele kant van objecten, de aspectsysteem-decompositie en het vastleggen van fysieke raakvlakken in de HSL maar gedeeltelijk uitgewerkt. De implementatie van de HSL-objectenboom is gedaan met achtereenvolgens Excel, Access en het PDM-systeem SmarTeam.

Uit het HSL-project kan worden geconcludeerd dat ook een simpele aanpak al snel te moeilijk is. Wellicht is de indruk ontstaan dat de decompositiestructuur in een dag of wat tot stand is gekomen. In werkelijkheid zijn er vele uren van vele mensen in gaan zitten, vooral vergaderuren. Ook ten aanzien van implementatie bleek een voor de hand liggende conclusie soms maanden te vergen.

Toch kan de HSL-objectenboom al met al worden beschouwd als een bijdrage aan betere communicatie in een groot bouwproject op basis van betekenisvolle product/objectgegevens.

  8 Conclusies

1. De belangrijkste conclusies zijn:
2. Voor verbetering van de communicatie in de bouw is het betekenisvol vastleggen en uitwisselen van productgegevens een voorwaarde.
3. De ontwikkeling van methoden en technieken voor betere communicatie in de bouw mislukt gemakkelijk door te ingewikkelde informatiemodellen, ongelukkige ICT-keuzes en tegenvallende standaardisatie-ontwikkelingen.
4. Door uit te gaan van een zogenaamde objectenboom kan in relatief korte tijd een eenvoudige maar complete gegevensstructuur voor een bouwproject worden ontwikkeld, en daarmee een basis voor betere communicatie.
   
   Zo'n objectenboom moet voldoen aan de volgende criteria:
    
• bottom-up-ontwikkeling: eerst de objecten (instanties), later de klasses,
• objecten als fysieke dingen die een functie vervullen,
• een decompositiestructuur, met zowel subsysteem-decompositie (naar plaats) als aspectsysteem-decompositie (naar rol); geen andere hiërarchische structuren,
• verder slechts één soort relatie: de fysieke raakvlakrelatie,
• vormbeschrijving door verwijzing naar CAD-tekeningen.
  
  Zo'n objectenboom is relatief snel te ontwikkelen, en bovendien eenvoudig en snel te implementeren, desgewenst in commercieel verkrijgbare PDM-software.
   
5. De objectenboombenadering kan als volgt worden uitgebouwd:
• (verder) ontwikkelen van classificatieafspraken voor objectnamen en objecttypes,
• (verder) ontwikkelen van bibliotheken van standaardobjecten, maar ook van standaard productiemiddelen en processen.
• ontwikkelen van managementmethoden op basis van de objectenboom, zoals interfacemanagement en risicomanagement,
• generalisatie van de objectenboom tot een typemodel.

 

dr Sander van Nederveen

Lit 1: Eerder verschenen als samenvatting van het proefschrift 'Object Trees-Improving Electronic Communication between Participants of Different Disciplines in large-scale Construction Projects', ISBN 9013619-3.

 

Terug aar inhoudsopgave.

Heeft u commentaar of suggesties ?

Mailt u het dan aan: cur@cur.nl