1 1 j ul i / R e t h i n k i n g C O I N S / 14003o0842. Rethinking COINS

Transcriptie

1 Rethinking COINS Eindrapportage 11 juli

2 Colofon COINS Technical Management Group: Frans van Dam : Rijkswaterstaat, voorzitter René Dorleijn : Movares Henk Schaap : Gobar BV Peter Willems : TNO Aad Jongbloets : Tauw Renzo van Rijswijk : Strukton Engineering Bert de Wolde : Ipcon Leo van Ruyven : Croon Elektrotechniek René Wubbels : ProRail Wouter Notenbomer : SBRCURnet, secretaris Hans Schevers : Geodan Wouter Engelen : Movares Jeroen van Geijlswijk : Infostrait Dik Spekkink : Spekkink C&R, rapporteur 2

3 Inhoud Managementsamenvatting Inleiding Leeswijzer BIR Projectplan COINS Werkpakket Rethinking COINS Ontwikkeling van software-tools COINS 1.0: uitgangspunt voor het rethinking proces Introductie Aanleiding Doelstellingen Organisatie Onderdelen van COINS Knelpunten in het werken met COINS Uitgangspunten COINS Toekomstbeeld Inrichting proces Beschrijving van het product Organisatievormen ICT hulpmiddelen Functionele behoeften COINS Technische eisen voor COINS Architectuur Agenda voor COINS Geraadpleegde literatuur Bijlage 1: participanten in COINS

4 Managementsamenvatting COINS is een Nederlandse open BIM-standaard die de uitwisseling van informatie tussen projectpartners ondersteunt. Met behulp van de standaard kunnen onder andere een objectenboom, GIS-data, 2D-tekeningen, 3D-modellen, IFC-modellen en andere projectdocumenten in samenhang in één database worden vastgelegd. De COINS-standaard biedt ook een BIMcontainer uitwisselformaat. De ontwikkeling van COINS is gestart in 2003, in 2010 is versie 1.0 gepubliceerd. De standaard is ontwikkeld om informatie over objecten in de GWW-sector gedurende hun volledige levenscyclus eenduidig vast te leggen, uit te wisselen tussen projectpartners en herbruikbaar te maken voor assetmanagement, beheer en onderhoud. COINS is een aanvulling op (internationale) open BIM standaarden als IFC en IDM en bsdd en richt zich specifiek op het neutraal vastleggen en uitwisselen van de objectenstructuur in GWW-projecten. Hiervoor is geen andere open standaard beschikbaar. Belangrijke meerwaarde van COINS is bovendien, dat ook in de plan- en initiatieffase, wanneer nog geen fysieke objecten zijn gedefinieerd, al informatie via COINS kan worden uitgewisseld (zoals stakeholderseisen). Mede om deze redenen staat het bestaan van COINS op dit moment niet ter discussie. Sinds de publicatie van COINS 1.0 is ervaring opgedaan met de standaard door een aantal overheidsopdrachtgevers en opdrachtnemers (ingenieursbureaus en bouwbedrijven). De standaard wordt anno 2014 toegepast in een tiental grote en middelgrote GWW-projecten. In het gebruik komt een aantal knelpunten aan het licht, die een heroverweging van de uitgangspunten voor en de opbouw en technische invulling van de COINS-standaard noodzakelijk maken. In deze heroverweging is voorzien in werkpakket 3 Rethinking the standard van het Projectplan COINS van de BIR van 14 januari Vóór u ligt de rapportage van de uitvoering van dit werkpakket door de COINS Technical Management Group (TMG). De belangrijkste knelpunten zijn als volgt samen te vatten: de documentatie voor COINS 1.0 is niet geschikt voor professionals in de bouwsector. De documentatie is primair gericht op softwareprogrammeurs, die evenwel grote moeite hebben met de interpretatie. Voor projectpartners die in projecten via COINS data moeten uitwisselen, ontbreekt een goede uitleg of handleiding; het ontbreekt aan softwaretools die de implementatie en toepassing van de standaard in, c.q. de aansluiting op IT-omgevingen van opdrachtgevers en opdrachtnemers ondersteunen. Hierdoor worden softwareprogrammeurs en eindgebruikers teveel geconfronteerd met onderde-motorkap-technologie wanneer zij informatie willen of moeten uitwisselen via de COINS standaard; de standaard lijkt een processtandaard op te leggen (Systems Engineering), terwijl de algemene mening onder gebruikers is dat een standaard voor het uitwisselen van projectdata onafhankelijk dient te zijn van welk procesmodel dan ook; ervaringsdeskundigen plaatsen (grote) vraagtekens bij de geschiktheid van de specificatietaal OWL (toegepast in COINS 1.0) voor een uitwisselingsstandaard voor projectdata. OWL is primair voor een ander doel ontwikkeld (namelijk het bouwen van ontologieën), de kennis over OWL is nog niet wijd verbreid en er is weinig ondersteunende software beschikbaar voor vertaling naar de IT-omgeving die gebruikelijk is in de bouwsector. 4

5 Discussies in de TMG over de knelpunten hebben geleid tot het formuleren van functionele behoeften met betrekking tot COINS 2.0. De belangrijkste behoeften zijn: duidelijke afbakening van wat wel en niet tot de COINS-standaard behoort (in de huidige situatie is het bijvoorbeeld niet altijd duidelijk waar de uitwisselingsstandaard ophoudt en de uit te wisselen projectinformatie begint); de gebruiksdrempel voor softwareprogrammeurs in de bouwsector en eindgebruikers moet aanzienlijk worden verlaagd door goede documentatie van de standaard en (het stimuleren van) de ontwikkeling van ondersteunende software (zoals web services en/of API s); COINS 2.0 moet geen werkmethode opleggen, maar moet flexibel zijn in de methoden die zij ondersteunt. Hiertoe moet het kernmodel van COINS mogelijk kleiner worden gemaakt, c.q. worden ontdaan van procesaspecten; gewenste, aanvullende functionaliteit moet worden gerealiseerd in de vorm van referentiekaders. Bepaalde referentiekaders, zoals een Referentiekader SE kan COINS meeleveren bij de standaard, maar gebruikers moeten bij voorkeur ook zelf naar behoefte referentiekaders kunnen maken; de standaard moet niet alleen bruikbaar zijn voor de uitwisseling van informatie tussen Opdrachtgever en Opdrachtnemer bij de start en oplevering van een project, maar bijvoorbeeld ook voor de dagelijkse informatie-uitwisseling tussen betrokken ontwerpende en uitvoerende disciplines in de fasen van ontwerp en uitvoering; in het verlengde daarvan moet het mogelijk zijn om alleen delta-informatie (gewijzigde informatie) uit te wisselen in plaats van telkens de volledige COINS-container; dit impliceert tevens dat het mogelijk moet zijn om metadata mee te geven aan de informatie die het versiebeheer op tenminste het detailniveau van delta-informatie ondersteunt (bijvoorbeeld: versie, opsteller, wijzigingsdatum, status, enzovoort). In een volgende stap heeft de TMG de functionele behoeften door vertaald naar technische eisen aan COINS 2.0. Daarbij heeft de TMG zichzelf vragen gesteld als: Hoe kan worden voorkomen dat COINS 2.0 een engineeringsmethode oplegt? Hoe kunnen softwareprogrammeurs en eindgebruikers worden afgeschermd van onder-demotorkap-technologie? Wat is de minimale omvang van het kernmodel van COINS om zowel de doelstelling van de standaard te kunnen verwezenlijken als voldoende flexibiliteit in de toepassing te kunnen realiseren? Hoe moet het versiebeheer in COINS 2.0 worden geregeld? Hoe kan technisch worden gerealiseerd dat gebruikers eenvoudig zelf een referentiekader kunnen maken? Hoe moet een praktisch COINS uitwisselingsmechanisme eruit zien dat geschikt is voor zowel grote als kleine projecten? Omdat marktpartijen in praktijkprojecten veel problemen ervaren met de toepassing van OWL, is veel aandacht besteed aan het zoeken naar alternatieve programmeertalen voor COINS 2.0 (of een alternatief gebruik van OWL). RDFS Named Graphs lijkt een bruikbaar alternatief. De TMG heeft 5

6 echter geconcludeerd dat voor het nemen van een definitief besluit nader onderzoek noodzakelijk is. Besloten is om in het kader van de ontwikkeling van COINS 2.0 uitgaande van de gewenste functionaliteiten - een onderbouwde SWOT-analyse uit te voeren van in ieder geval OWL en RDFS Named Graphs (en mogelijk ook andere alternatieven). Resultaat van het werk van de COINS TMG is een agenda voor de ontwikkeling van COINS 2.0. Hiervoor is een aparte rapportage opgesteld: COINS 2014 Werkplan Wp5 Ontwikkeling release 2.0, dat als bijlage van deze rapportage Rethinking COINS kan worden beschouwd. 6

7 1. Inleiding 1.1 Leeswijzer Deze Inleiding beschrijft de aanleidingen voor en de context van Rethinking COINS. In hoofdstuk 2 volgt een korte beschrijving van de eerste versie van de standaard, zoals die in 2010 is gepubliceerd. Deze eerste versie duiden we in deze rapportage aan met de term COINS 1.0. Hoofdstuk 3 bevat een samenvatting van de knelpunten die in de praktijk van bouwprojecten worden ervaren met de toepassing van COINS 1.0. Deze worden in hoofdstuk 4 vertaald naar uitgangspunten en functionele behoeften voor COINS 2.0. In hoofdstuk 5 volgt een doorvertaling naar technische behoeften. Eén en ander mondt uit in een architectuur voor de noodzakelijke aanpassingen t.b.v. COINS 2.0. Deze architectuur is het onderwerp van hoofdstuk 6. In hoofdstuk 7 komt alles samen in de Agenda voor COINS BIR Projectplan COINS De Bouw Informatie Raad (BIR) zet zich in voor de ontwikkeling en implementatie van BIM (Bouw Informatie Modellering / Bouw Informatie Management) in de Nederlandse bouwpraktijk. Hiertoe ontplooit de BIR stimuleringsactiviteiten in vier clusters: Management & Organisatie, Informatietechnologie, Mens en Cultuur en Processen. Voor het aspect Informatietechnologie richt de BIR zich op de ontwikkeling van open BIM standaarden voor de uitwisseling van informatie in bouwprojecten. Eén van die open BIM standaarden is COINS, die in eerste versie is uitgegeven in Voor de verdere ontwikkeling en implementatie van deze standaard heeft de BIR het Projectplan COINS opgesteld [1]. Eén van de werkpakketten uit het Projectplan behelst de activiteit Rethinking the standard. De rapportage van dit werkpakket, opgesteld door de COINS Technical Management Group (TMG), ligt nu voor u. Het resultaat een Agenda COINS 2.0, een onderzoeks- en ontwikkelingsprogramma voor de ontwikkeling van een vernieuwde standaard. COINS wordt anno 2014 toegepast in een tiental grote en middelgrote GWW-projecten. COINS is een aanvulling op (internationale) open BIM standaarden als IFC en IDM en bsdd en richt zich specifiek op het neutraal vastleggen en uitwisselen van de objectenstructuur in GWW-projecten. Hiervoor is geen andere open standaard beschikbaar. Mede om deze redenen is het bestaansrecht van COINS in Rethinking the Standard niet ter discussie gesteld. In het Projectplan COINS, versie 0.2 d.d. 6 januari 2014 [1] wordt de standaard als volgt omschreven: COINS is een open BIM-standaard. Het vormt een aanvulling op en verbinding met standaarden die uitgebracht worden door buildingsmart (IFC, IFD, IDM), OGC en CB-NL. COINS ondersteunt de uitwisseling van Systems Engineering informatie en zorgt ervoor dat onder andere een objectenboom, GIS, 2D-tekeningen, 3D-modellen, IFC-modellen, en objecttype-bibliotheek in samenhang in één database vastgelegd kunnen worden. De COINS-standaard biedt ook een BIM-container als uitwisselingsformaat. 7

8 Sinds de publicatie van COINS 1.0 is ervaring opgedaan met de standaard door o.a. Movares, Strukton, Gemeentewerken Rotterdam, Van Meijel, Tauw, RHDHV, RWS en de Provincie Gelderland. De standaard wordt anno 2014 beproefd en toegepast in een tiental grote en middelgrote GWW-projecten. Uit deze praktijk is de behoefte gebleken aan: enkele aanpassingen/aanvullingen om in te spelen op directe behoeften uit lopende toepassingen; het verlagen van de gebruiksdrempel voor softwareprogrammeurs door externe systemen eenvoudig te laten aansluiten op de standaard, bijvoorbeeld door middel van applicatieinterfaces (API s); het verlagen van de gebruiksdrempel voor eindgebruikers (leden van projectteams) d.m.v. het beschikbaar maken van geschikte software-tools; meer flexibiliteit in de standaard om eenvoudig in te kunnen spelen op project-specifieke behoeften; praktische voorlichting. 1.3 Werkpakket Rethinking COINS Het Projectplan COINS beschrijft in de vorm van een aantal werkpakketten hoe wordt beoogd om te voorzien in de behoeften zoals verwoord in paragraaf 1.2. Het plan omvat de volgende werkpakketten: 1. Project startup; 2. Uitwerking release 1.1; 3. Rethinking the standard; 4. Software tooling 1.1; 5. Ontwikkeling release 2.0; 6. Update software tooling 2.0; 7. Publicatie release 2.0; 8. Certificering services; 9. Praktijkcasus; 10. Implementatie SE-standaard. 1. Project startup 2. Uitwerking release Rethinking the standard 4. Software tooling Ontwikkeling Release Update software tooling Publicatie Release Certificering services 9. Praktijk casus 10. Implem. SE-standaard Figuur 1: structuur werkpakketten Projectplan COINS 2014 Werkpakket 3 is in het Projectplan COINS als volgt gespecificeerd (zie de volgende pagina). 8

9 Werkpakket 3: Omschrijving: Rethinking the standard Rethinking the standard betekent afstand nemen en vanuit behoeften en knelpunten opnieuw naar de standaard kijken. Vanuit RWS zijn concrete behoeften om gebruikers in staat te stellen op een eenvoudiger manier gegevens te leveren. Voorts zijn er behoeften om flexibeler te kunnen inspelen op projectspecifieke omstandigheden en brede inzet bij tal van toepassingen. De resultaten worden getoetst met een Domein expert panel en een Software expert panel. Input: Werkplan, COINS 1.0 Output: Agenda voor COINS 2.0 Activiteiten 1. Review uitgangspunten en grondslag COINS Oplijnen kennis COINS Vaststellen functionele behoeften voor Vaststellen technische behoeften voor Functionele aanpassingen voor Architectuur aanpassingen voor Opstellen agenda voor Toetsing van de resultaten Randvoorwaarden: Relevante andere standaarden zoals VISI, CB-NL, IFC Agenda voor COINS 2.0 Output van Werkpakket 3 is de agenda voor de ontwikkeling van COINS release 2.0. Op basis van deze agenda zal het nodige ontwikkelwerk worden gedaan aan de standaard, dat vervolgens wordt verwerkt in een publicatie. Van release 2.0 wordt verwacht dat deze minder complex is in de toepassing in projecten dan COINS 1.0, maar wel de gewenste functionaliteit en meer flexibiliteit kan bieden om in te spelen op projectspecifieke behoeften. Dat houdt niet noodzakelijkerwijs in dat de standaard zelf minder complex moet worden, maar primair dat de complexiteit met name voor softwareprogrammeurs zoveel mogelijk onder de motorkap dient te blijven. Relatie met COINS release 1.1 Een korte termijn behoefte betreft de verwerking van enkele aanpassingen in de standaard om lopende en komende projecten te kunnen bedienen. Dit leidt vooruitlopend op de ontwikkeling van COINS tot een release 1.1 van de standaard. Daarbij wordt zoveel mogelijk geanticipeerd op de functionele en technische behoeften die zijn geformuleerd voor COINS Ontwikkeling van software-tools De behoefte aan software-tools om de gebruiksdrempel voor eindgebruikers te verlagen, c.q. de standaard te kunnen toepassen is urgent in verband met een aantal lopende en op korte termijn te starten infraprojecten, waarin toepassing van COINS wordt voorgeschreven. Dergelijke software 9

10 maakt geen deel uit van de standaard en behoort daarom strikt genomen niet tot het werkterrein van de Beheergroep COINS. Goede softwaretools zijn echter cruciaal voor de acceptatie en het gebruik van de standaard in de praktijk. Daarom is in het Projectplan COINS een werkpakket gedefinieerd om de ontwikkeling van dergelijke tooling in de markt te ondersteunen. Softwareleveranciers zal worden gevraagd tools te realiseren, c.q. compatible te maken met COINS 2.0. Mogelijk kan ook gebruik worden gemaakt van reeds bestaande softwaretools (al dan niet open source). De werkpakketten 4 en 6 van het Projectplan COINS voorzien in het opstellen van een vraagspecificatie voor software-tooling (mede op basis van de Agenda COINS 2.0), het aanbesteden van de ontwikkeling van de tooling, het begeleiden van die ontwikkeling en het testen van het resultaat. 10

11 2. COINS 1.0: uitgangsp unt voor het rethinking proces 2.1 Introductie De term Rethinking the standard impliceert dat een bestaande standaard grondig onder de loep wordt genomen en geëvalueerd. Voor een goed begrip bevat dit hoofdstuk een korte beschrijving van het uitgangspunt voor het rethinking proces: COINS 1.0, de standaard waarvan de ontwikkeling is gestart in 2003 en die in 2010 is uitgegeven. In korte, cursief gedrukte alinea s is aangegeven op welke punten inzichten inmiddels zijn verschoven. De rethinking richt zich in de navolgende hoofdstukken onder andere op die punten. 2.2 Aanleiding Projectpartners in de bouw hebben ervaren dat de wijze waarop de communicatie en samenwerking in het bouwproces anno 2003 was ingericht, een belangrijke oorzaak is van de grote foutgevoeligheid van de informatiestroom. In andere industrieën, zoals de scheepsbouw en de procesindustrie, heeft het werken met 3D objectinformatie geleid tot spectaculaire verbeteringen. In 2003 was dit voor een aantal vertegenwoordigers uit de Nederlandse bouw aanleiding voor het initiatief om ook voor deze bedrijfstak afspraken te ontwikkelen voor het werken met 3Dobjectinformatie. Dit vormde het begin van wat nu bekend staat als COINS [3]. Anno 2014 ligt er minder nadruk op 3D-objectinformatie. De primaire basis voor verbetering van informatie-uitwisseling tussen bouwpartners ligt hoewel belangrijk niet zozeer in 3D modellering, als wel in de opbouw van de semantisch objectstructuur. 2.3 Doelstellingen COINS is de afkorting van Constructieve Objecten en de INtegratie van processen en Systemen. Het initiële COINS-programma had de volgende doelstellingen: het beschikbaar maken van afspraken over werkmethoden en informatie (semantiek, syntax en uitwisselingsmechanisme) die nodig zijn om het bouwproces te ondersteunen; het bieden van een gemeenschappelijke basis voor het gebruik van 3D objectinformatie en de integratie van het bouwproces; het mogelijk maken van een beter gebruik van investeringen in informatie- en communicatietechnologie (ICT). 11

12 2.4 Organisatie Het COINS-programma wordt uitgevoerd door de Beheergroep COINS met daarin vertegenwoordigers van opdrachtgevers, bouwbedrijven, ingenieursbureaus, netwerkorganisaties en kennisinstellingen. Daarnaast nemen IT-bedrijven deel (zie ook bijlage 1). Voor technisch-inhoudelijke zaken laat de Beheergroep zich adviseren door de COINS Technical Management Group (TMC). Hierin hebben vooral IT-deskundigen uit de GWW-sector zitting. Het secretariaat van COINS wordt gevoerd door SBRCURnet. 2.5 Onderdelen van COINS 1.0 COINS 1.0 omvat de volgende producten, die in navolgende kort worden omschreven: a) afspraken over werkmethoden COINS Engineering Methode (CEM); b) afspraken over informatie COINS Bouwwerk Informatie Model (CBIM); c) implementatie strategieën en methoden (waaronder de COINS-Container); d) informatiemanagementsysteem COINS Bouwwerk Informatie Systeem (CBIS). Ad a): CEM Werkmethoden voor de bouw COINS haakte hiervoor in op reeds aanwezige trends in de bouw (zoals Systems Engineering) en nam werkwijzen over van andere industrieën. Gepoogd werd om sectorbrede afspraken te maken voor het toepassen van die werkwijzen. Dit werd gezien als een belangrijke eerste stap om te komen tot integratie van het bouwproces. Anno 2014 zijn de inzichten gewijzigd: een open standaard als COINS moet geen werkmethode opleggen, maar in principe binnen uiteenlopende werkmethoden toepasbaar zijn. Ad b): CBIM Bouwwerk Informatie Model Voor de projectgroep COINS gaat het in het bijzonder om begrippen die relevant zijn voor integratie van het bouwproces. Daarom wordt gesproken over een Bouwwerk Informatie Model (BIM). Ook voor dit onderwerp wil COINS niet opnieuw het wiel uitvinden, maar maximaal gebruik maken van wat er al aan standaarden beschikbaar is. Zo is in COINS 1.0 gebruik gemaakt van OWL (Ontology Web Language), waarmee objecten en hun onderlinge relaties in één bestandsformaat kunnen worden beschreven. Anno 2014 staat deze keuze ter discussie, onder andere omdat de kennis over OWL nog niet wijd verbreid is en er in de huidige praktijk, met name voor een dot.net omgeving, onvoldoende tools beschikbaar zijn voor het werken met en het interpreteren van OWL-bestanden. Ook is er twijfel of OWL voldoende mogelijkheden biedt om de gewenste informatie (op elementniveau), inclusief metadata, op een eenduidige wijze over te dragen tussen partijen, mede omdat OWL primair is ontwikkeld voor het bouwen van ontologieën en niet voor de uitwisseling van data. 12

13 Het COINS 1.0 kernmodel (CBIM) is afgebeeld in de onderstaande figuur. Het model bestaat in OWL-termen - uit een verzameling Classes, Object Properties en Datatype Properties (NB: dit zijn andere properties dan eigenschappen of kenmerken die normaal worden gebruikt in de bouwen infrasector). Classes Object Properties Datatype Properties Amount Baseline Building C-BIM Object Catalogue Part Connection Document Explicit 3D Representation Function Function Fulfiller Library Reference Locator Parameter Performance Person or Organisation Physical Object Property Type Property Value Requirement Space State Task Task Type Terminal Vector Verification VISI message affects amount property type baseline baseline object catalogue part child contains creator current state document female terminal first parameter fulfills is affected by is fulfilled by is situated in locator male terminal max bounding box min bounding box modifier next parameter next version parent performance performance of physical child physical parent previous state primary orientation property type property value requirement requirement of secondary orientation shape situates spatial child spatial parent state of supertype task type terminal terminal of translation verification function fulfiller verification performer verification requirement Figuur 2: COINS 1.0 Kernmodel (CBIM) baseline status change log creation day default value description document alias file pathe document type document URI end date end date actual end date planned expired layer index modification date name release date release status start date start date actual start dat planned unit user ID value value domain verification date verification method verification result x coordinate y coordinate z coordinate In het kader van Rethinking the standard wordt de vraag gesteld in hoeverre het Kernmodel kleiner kan worden gemaakt, teneinde de flexibiliteit te vergroten. Zie ook de hoofdstukken 3, 4 en 5. 13

14 Ad c): COINS-Container Het streven van COINS is om digitale informatie, gestructureerd volgens de COINS-standaard, op een uniforme wijze uit te wisselen tussen de verschillende partners in een bouw- en beheerproces. In het kader van COINS 1.0 wordt in dit verband onder digitale informatie verstaan: geometrische informatie; niet-geometrische informatie; informatie m.b.t. de relatie tussen geometrische en niet-geometrische informatie (relaties tussen functies, eisen, objecten en prestaties, zie figuur 3). Functies vervullen Objecten 'VALIDEREN' stellen leveren Eisen worden getoetst aan Prestaties 'VERIFIËREN' Figuur 3: Relaties tussen functies, eisen, objecten en prestaties, zoals gemodelleerd in COINS 1.0 In Rethinking the standard staat ter discussie of deze relaties thuishoren in het COINS Kernmodel, omdat juist hiermee de indruk wordt gewekt dat een werkmethode Systems Engineering wordt voorgeschreven. Zie ook de volgende hoofdstukken. Dit is één van de redenen van de wens om het Kernmodel kleiner te maken. 14

15 Voor de uitwisseling is de COINS-Container ontwikkeld, een informatiedrager die bovengenoemde informatie volgens een gestandaardiseerde structuur opslaat. Deze COINS-Container wordt binnen COINS 1.0 beschouwd als hét uitwisselformaat tussen verschillende soorten software binnen een BIM-proces. De COINS-Container is een ZIP-bestand, dat naast een BIM volgens de COINS-standaard (CBIM) alle documenten bevat (rapporten, tekeningen, 3D-modellen, planningen, presentaties enzovoort) waaraan in het BIM wordt gerefereerd. Een COINS-Container bevat drie submappen: 1. Bim-directory, waarin één CBIM file is opgeslagen met de file extensie.owl; 2. Woa-directory, met een optionele Woa.xml file voor de zogenaamde Window of authorization. Deze file bevat informatie over de rechten die men heeft om objecten uit de CBIM al dan niet te wijzigen. 3. Doc, waarin alle meegeleverde documenten zijn opgeslagen. Dit kunnen documenten van verschillende oorsprong zijn, met verschillende bestandsextensies. De belangrijkste (potentiële) toepassingen van de COINS- Container zijn in COINS 1.0: het overdragen van functionele specificaties en een objectstructuur naar bijvoorbeeld een 3D-CAD-applicatie of een planning; het samenstellen van een ontwerpdossier, bestaande uit tekeningen/modellen en ontwerpnota s waarin beslissingen worden onderbouwd; Figuur 4: schematische voorstelling COINS container het overdragen van as built informatie tussen de verschillende partners in een bouw- en beheerproces. Overdragen van technische specificaties tussen betrokken partijen in een bouwproject en wijzigingen hierop. Binnen een BIM-proces worden verschillende soorten software gebruikt, waartussen bijvoorbeeld via een COINS-Container kan worden uitgewisseld. Het is van belang dat alle bouwwerkinformatie behouden blijft bij een uitwisseling. Software dient daartoe COINScompatibel te zijn. In de richtlijn Identification of CBIM information objects is aangegeven aan welke eisen software moet voldoen om dat te bereiken [4]. Enkele softwareleveranciers hebben toegezegd interfaces te zullen ontwikkelen voor diverse applicaties, met als doel COINS-compatibiliteit te realiseren. Anno 2014 is er nog weinig COINS compatibele software beschikbaar, waarschijnlijk omdat er nog onvoldoende (commerciële) vraag is. Omdat een opdrachtgever als RWS de COINS standaard steeds 15

16 vaker zal voorschrijven in projecten, wordt verwacht dat die vraag op korte termijn wel gaat ontstaan. Software wordt pas COINS-compatibel verklaard, wanneer het is voorzien van een keurmerk. Dit keurmerk wordt toegekend wanneer een onafhankelijke organisatie namens de COINS beheerorganisatie de software heeft getest en goedgekeurd. Dat dient te gebeuren volgens een standaard testprotocol, dat aansluit bij de vastgestelde COINS-systematiek. Een dergelijk testprotocol is anno 2014 nog niet beschikbaar. Ad d:) CBIS COINS Bouwwerk Informatie Systeem In 2010 heeft COINS een functionele specificatie voor een zogenaamd COINS Bouwwerk Informatie Systeem (CBIS) opgesteld. CBIS zou het hart moeten vormen van het unieke Bouwwerk Informatie Model voor het object dat wordt voorbereid of gebouwd. Het idee achter CBIS is dat het model dient te worden beheerd door de BIM-regisseur. Onder zijn/haar hoede wordt de informatiestroom beheerd, wordt elke wijziging geregistreerd (wie, wat, wanneer en waarom). De gedachte was dat het model wordt gevoed door bijdragen van Systems Engineers, 3D-modelleurs, constructeurs, planners, werkvoorbereiders, enzovoort. Uiteindelijk ontstaat een model waarmee de productie kan worden aangestuurd. Het softwarebedrijf Infostrait heeft een bouwwerkinformatiesysteem ontwikkeld met COINS-compatibiliteit, dat op dit moment echter alleen beschikbaar is voor de vijf partijen in wiens opdracht het systeem is ontwikkeld Anno 2014 is het idee van één centraal opgeslagen BIM, waaraan alle bouwpartners online werken, grotendeels verlaten, niet alleen bij COINS, maar algemeen. De gangbare praktijk is dat iedere projectpartner zijn eigen vakspecifieke database en aspectmodel heeft en dat die periodiek worden gesynchroniseerd. Dat neemt niet weg dat CBIS een belangrijke rol kan spelen in een situatie dat iedere projectpartner zijn eigen vakspecifieke database beheert. Binnen het BIM-programma van RWS fungeert CBIS bijvoorbeeld als intermediair tussen as-built data die de opdrachtnemers via COINS containers overdragen, en de interne beheermanagementsystemen van RWS. Documentatie van COINS 1.0 is te vinden op de CoinsWiki: 16

17 3. Knelpunten in het werken met COINS 1.0 In praktijkprojecten waarin het gebruik van COINS 1.0 is voorgeschreven, zoals het project SAA- One, zijn diverse knelpunten naar voren gekomen. Diverse TMC-leden zijn betrokken bij deze praktijkprojecten en ondervinden de knelpunten derhalve aan den lijve. Na intensieve bespreking in de TMC zijn de knelpunten die betrokkenen ervaren, als volgt verwoord. a) De COINS-standaard wordt voor een deel beleefd als een processtandaard; dit wordt als een knelpunt ervaren. COINS dwingt ogenschijnlijk een werkmethode af, hetgeen beperkingen oplegt. b) De COINS-standaard is moeilijk te implementeren; teveel complexiteit boven de motorkap. ICT ers in de sector die COINS moeten implementeren in een project, lopen tegen onder andere de volgende vragen aan. a. Als ik COINS moet implementeren, waar moet ik dan beginnen? b. Waar kan ik de specificaties van de open standaard vinden die ik nodig heb om een tool te kunnen bouwen? Wat zijn de semantische principes achter COINS? c. Als ik een Informatie Leverings Specificatie (ILS) krijg waarin wordt verwezen naar COINS en een objecttypenbibliotheek en ik moet contractueel conform die ILS gaan leveren, hoe moet ik dat dan aanpakken vanuit mijn eigen IT-omgeving? c) Het gebruik van OWL wordt als complex ervaren, terwijl de toegevoegde waarde onvoldoende duidelijk is. OWL is gemaakt om ontologieën te bouwen, maar praktijkmensen ervaren het als te complex of zelfs ongeschikt voor het uitwisselen van objectinformatie. Ondersteunende software is niet of nauwelijks beschikbaar. d) Het gebruik van een objecttypenbibliotheek als de OTL ( Object Type Library ) van RWS is complex, met of zonder COINS. Met het gebruik van OWL én de OTL wordt complexiteit op complexiteit gestapeld, mede omdat goede tooling vooralsnog ontbreekt. e) De RWS OTL bibliotheek die wordt aangereikt voor een project, is te omvangrijk en bevat meer structuur dan voor een project nodig is. Opdrachtnemers ervaren het bijvoorbeeld als zeer complex om concepten met alle bijbehorende, overgeërfde eigenschappen te vinden binnen de semantische structuur van een objecttypenbibliotheek die in OWL is opgebouwd. Mitigerende tooling ontbreekt. f) Documentatie is niet geschikt voor professionals in de GWW-sector. De documentatie is primair gericht op softwareprogrammeurs (die overigens ook moeite hebben met de interpretatie, zie punt b). Voor projectpartners die in projecten via COINS data moeten uitwisselen, ontbreekt een goede uitleg of handleiding. g) In de praktijk is de standaard niet praktisch genoeg om uitwisselingsafspraken tussen twee of meer partijen vast te leggen (combinatie van referentiekader en bibliotheek). h) Er is behoefte aan meer vrijheid in de technische overdracht van informatie, waarbij data en betekenis gescheiden zijn. i) Er is behoefte aan hulpmiddelen om instantiemodellen te maken. j) Er is een wens om data aan relaties te kunnen vastleggen. 17

18 k) Er is een wens om de inhoud van COINS Containers te kunnen valideren (toetsen of de inhoud voldoet aan de standaard). 18

19 4. Uitgangspunten COINS Toekomstbeeld Een vernieuwde COINS standaard moet mede zijn geworteld in een toekomstvisie op de bouw. Hoe zal het toekomstige bouwproces eruit zien? Wat verandert er in de samenwerking tussen bouwpartners, in de communicatie tussen opdrachtgevers en opdrachtnemers? Welke rol speelt ICT daarbij? Deze paragraaf beschrijft een aantal toekomstbeelden die mede ten grondslag dienen te liggen aan COINS 2.0. De beschrijving is een update van eenzelfde hoofdstuk uit de COINS publicatie Toekomst voor het bouwproces Een 3D-objectbenadering uit 2006 [2] op basis van literatuur en actuele kennis en inzichten van TMC-leden Inrichting proces Ten opzichte van de hedendaagse bouwproces zijn de volgende veranderingen te verwachten. a. Van een proces waarin de actoren in het bouwproces centraal staan, naar een proces waarin het object (het bouwwerk) centraal staat. Team en proces worden georganiseerd rondom het object. De essentie van een bijdrage door een actor is de waarde die hij in afstemming en samenwerking met zijn projectpartners door middel van informatie toevoegt aan het object. b. Van sturing op inspanning naar sturing op output: procesbewaking gebaseerd op de gewenste toestand van objecten gedurende hun hele life cycle. De procesbewaking is nu vaak nog gebaseerd op de status van documenten. In de toekomst zal de bewaking worden gebaseerd op de gewenste toestand van objecten per fase in de levenscyclus. De gewenste toestand van een object in een bepaalde fase hangt nauw samen met het doel van die fase, c.q. de besluiten die in die fase over het object moeten worden genomen. Door middel van toestandsveranderingen doorloopt het object de product life cycle. c. Van een proces met een statisch Programma van Eisen naar een proces waarin de vraag zich stapsgewijs ontwikkelt van globaal naar specifiek, in wisselwerking met het aanbod (= het ontwerp). Daarbij wordt de vraag zoveel mogelijk gespecificeerd in de vorm van functionele eisen, die steeds een optimale oplossingsruimte laten voor het aanbod. Per ontwerpstap moet worden aangetoond dat de aangeboden oplossing prestaties kan leveren die voldoen aan de functionele eisen ( validatie volgens de methode Systems Engineering). d. Functioneel ontwerpen. Bij het ontwerpen staat niet de vraag hoe bouwen we het object? centraal, maar de vraag wat moet het object doen voor de gebruiker? Het bouwwerk wordt op de verschillende detail- of decompositieniveaus aanvankelijk puur functioneel ontworpen, technische keuzen worden gedurende het ontwerpproces stapsgewijs gedaan van globaal naar specifiek, in wisselwerking met de ontwikkeling van de Vraagspecificatie. Dit uitgangspunt is niet rigide, het staat de opdrachtgever altijd vrij om op voorhand een technische (deel)oplossing voor te schrijven, wanneer hij die om welke reden dan ook perse wil. e. Van sequentieel werken door bouwpartners naar concurrent werken, waardoor ontwerpbeslissingen kunnen worden genomen op basis van integrale, multidisciplinaire afwegingen en wachttijden worden gereduceerd. Door verantwoordelijkheden en procesbewaking objectgericht te organiseren, wordt het niet alleen eenvoudiger, maar zelfs noodzakelijk om activiteiten van verschillende bouwpartners parallel uit te voeren. 19

20 f. Doelgerichte communicatie: van paper based uitwisseling naar digitale uitwisseling van decentraal opgeslagen digitale gegevens. Door het gebruik van een gemeenschappelijke taal (zoals een objecttypen- of conceptenbibliotheek gecombineerd met gedefinieerde, betekenisvolle relaties tussen de objecten/concepten, tezamen de semantische objectstructuur) wordt het mogelijk om eenmaal ingevoerde gegevens te hergebruiken voor verschillende doeleinden en in verschillende applicaties. 3D modellen spelen een rol in de opbouw, ontsluiting, afstemming, representatie en uitwisseling van digitale objectgegevens. De basis voor de uitwisseling van die gegevens is echter niet het 3D model, maar de semantische objectstructuur. g. Beschikbaarheid van standaarden. Partners die met elkaar samenwerken in een bouwproject, moeten naast de eerder genoemde taalafspraken beschikken over gemeenschappelijke afspraken over wie wanneer welke informatie moet leveren om elkaar in staat te stellen efficiënt en effectief te kunnen werken (protocollen). Dergelijke afspraken kunnen maar ten dele worden gestandaardiseerd. Er komen raamwerken (model protocollen) beschikbaar die projectpartners in staat stellen om op gestandaardiseerde wijze projectspecifieke afspraken te maken en te bewaken. Daartoe behoren ook afspraken op het gebied van versie- en wijzigingenbeheer van informatie Beschrijving van het product De volgende veranderingen zijn te benoemen. h. De integrale beschrijving van een object staat centraal in het proces; actoren maken gebruik van die beschrijving en voegen in de loop van de levenscyclus informatie toe. Ter illustratie: in het traditionele proces beschrijven de architect, de constructeur, de aannemer en de prefab leverancier ieder dezelfde betonvloer, ieder vanuit het eigen perspectief, in separate documenten. In het nieuwe bouwproces werkt iedere participant met een eigen digitaal aspectmodel van de vloer, dat essentiële basisgegevens deelt met de aspectmodellen van de andere participanten. Deze basisgegevens worden periodiek gesynchroniseerd in een frequentie die passend is voor het project. Daarnaast kunnen aspectmodellen disciplinespecifieke data bevatten die voor de andere participanten niet relevant zijn (bijvoorbeeld: het bouwbedrijf heeft geen belang bij data in het aspectmodel van de prefab leverancier die nodig zijn voor de aansturing van machines in de fabriek). i. Het werken met Bouwwerk Informatie Modellen (BIM). Een BIM wordt als volgt gedefinieerd: Een BIM (Bouwwerk Informatie Model) is een digitale beschrijving van een (bestaand of in de toekomst mogelijk bestaand) concreet aanwijsbaar bouwwerk in de bestaande omgeving, relevant voor de hele levenscyclus en toeleverketen van dat bouwwerk. Een bouwwerk kan ook 'infrastructuur' zijn. Een BIM is een digitale voorstelling van het bouwwerk in al zijn fasen, op een manier die de fysieke werkelijkheid zeer dicht benadert. Deze gegevens van het bouwwerk zijn (min of meer) gelijktijdig door tal van disciplines te gebruiken voor bijvoorbeeld berekeningen, simulaties, aanpassingen en presentaties met behulp van specialistische programmatuur. Deze programmatuur moet gegevens kunnen uitwisselen met het BIM, maar is verder onafhankelijk van het BIM. (Bron: 20

21 j. Verbeterde afstemming van deelontwerpen, c.q. bijdragen van verschillende bouwpartners aan het project, door het (periodiek) digitaal samenvoegen van aspectmodellen tot één gemeenschappelijk coördinatiemodel. Efficiënte informatieoverdracht door opslag van alle projectbestanden binnen één digitale projectomgeving (die overigens decentraal kan zijn georganiseerd). k. Beschikbaarheid van standaarden. Partners die met elkaar samenwerken in een project, moeten beschikken over gemeenschappelijke afspraken over de inrichting van het BIM: onder andere de benaming en codering van objecten en hun (mogelijke) eigenschappen, de relaties tussen objecten, de relaties tussen objecten en eigenschappen, enzovoort Organisatievormen Ten opzichte van de huidige situatie zijn de volgende veranderingen te benoemen. l. (Overheids-)opdrachtgevers zullen projecten steeds meer aanbesteden op basis van geïntegreerde contracten, variërend van Engineering & Build (E&B) en Design & Build (D&B) tot Design, Build, Finance, Maintenance & Operate (DBFMO). Dit leidt tot meer samenwerking in de bouwketen, meer projectongebonden samenwerking tussen bouwpartners, verkorting van doorlooptijden van projecten, kwaliteitsverbetering en reductie van faalkosten. m. Systems Engineering (SE) heeft zijn intrede gedaan in de bouwwereld (met name de GWWsector) als methode voor de sturing en beheersing van bouw- en beheerprocessen, met als belangrijkste kenmerken: de klantvraag staat centraal; functioneel specificeren van die vraag; systeemdenken; life cycle benadering; verificatie en validatie van de oplossingen op de functioneel gestelde vraag in de diverse stadia van de levenscyclus van het systeem. n. Systems Engineering en BIM liggen in elkaars verlengde en vullen elkaar aan. Systeemdenken en objectgeoriënteerd werken zijn congruent. SE is proces-georiënteerd ( hoe weet ik wat ik moet maken en hoe zorg ik ervoor dat ik het juiste maak? ). BIM is object-georiënteerd en ondersteunt het maakproces in de zin van informatie en informatiemanagement. o. Tekenen wordt (3D-)modelleren. Modelleren beperkt zich daarnaast niet tot het invoeren van geometrische gegevens, maar omvat in beginsel het invoeren van alle relevante data met betrekking tot objecten binnen een bouwwerk. Dit vraagt om specifieke competenties van (3D-) bouwmodelleurs. p. Waar een aantal jaren geleden nog werd verwacht dat alle bij een bouwproject betrokken bouwpartners (online) zouden gaan werken in één centraal BIM, leert de praktijk inmiddels dat iedere bouwpartner zijn eigen aspectmodel maakt (zie ook de BIR kenniskaarten [12]). De aspectmodellen worden periodiek samengevoegd voor onderlinge synchronisatie en coördinatie. De verwachting is dat dit ook in de toekomst de dominante werkwijze rond BIM zal blijven. Iedere bouwpartner is daarbij in de gelegenheid om het gereedschap (computerapplicaties) te kiezen die zijn rol in het bouwproces het best faciliteert. Uitwisseling van gegevens vindt plaats via software-onafhankelijke, open standaarden. Voor het maken en bewaken van procesafspraken in BIM-ondersteunde bouwprocessen, het inrichten van de digitale projectomgeving, het ontvangen en samenvoegen van aspectmodellen 21

22 in coördinatiemodellen, het uitvoeren van clash controls, model checks (controleren of de uitgewisselde informatie voldoet aan de informatietechnische afspraken) en dergelijke dient een bouwpartner de rol van BIM manager of BIM regisseur op zich te nemen. In de huidige praktijk wordt deze rol veelal nog ingevuld door een BIM-specialist (iemand met een voorsprong in de kennis van BIM en de bijbehorende processen), maar de verwachting is dat het BIM management op termijn tot basiscompetenties van projectleiders zal behoren ICT hulpmiddelen Veel veranderingen die aangegeven zijn onder de aandachtsgebieden Inrichting proces en Beschrijving van het product worden mogelijk door en vereisen inzet van moderne ICThulpmiddelen. De volgende veranderingen zijn te benoemen. q. Toepassing van Bouwwerk Informatie Modellen en daaraan gelinkte data en/of digitale documenten, waarin facetten van functie, ruimte, materie, eisen, prestaties, kwaliteit, kosten en tijd in onderlinge samenhang zijn verwerkt. De informatie is eenduidig, objectgeoriënteerd en leesbaar/interpreteerbaar door computerapplicaties. r. Toepassing van Linked Data technologie: relevante informatie van het bouwwerk die bij/door verschillende projectpartners is gegenereerd en opgeslagen ( gedistribueerde datasets ), wordt in de toekomst via de cloud en linked data systemen gekoppeld (zie onder andere [15]). s. Een 3D-objectbeschrijving maakt deel uit van het informatiesysteem, c.q. het BIM. Naast facetten als onder andere functie, ruimte en materie kennen de objecten ook een 3Dvormbeschrijving. Deze beschrijving is belangrijk om invulling te kunnen geven aan doelgerichte communicatie (zie punt f.) en voor het uitvoeren van ruimtelijke coördinatie en analyses. t. Het gebruik van concepten- of objecttypenbibliotheken als de CB-NL. Voor het realiseren van de gewenste wijze van samenwerken en informatie-uitwisseling is de informatietechnologie niet het probleem. Het probleem schuilt in het ontbreken van een gemeenschappelijke taal. Verschillende partijen in de bouw gebruiken in hun datasets en applicaties verschillende gegevensdefinities voor dezelfde dingen. Ook het omgekeerde komt voor. Daarom kunnen gegevens die eenmaal zijn ingevoerd in een computerapplicatie, in de meeste gevallen niet automatisch worden hergebruikt in andere computerapplicaties. Anno 2014 moeten mensen meestal nog de vertaalslag maken van de ene naar de andere applicatie. De ontwikkeling van de Conceptenbibliotheek Nederland (CB-NL) brengt daar verandering in. De CB-NL is geen nieuwe producten- of objectenbibliotheek naast reeds bestaande, maar wordt een definiërende, uniformerende taal, die als een soort schakelmechanisme tussen bestaande standaarden, normen en object-/productbibliotheken in komt te staan [7]. 22

23 Figuur 5: CB-NL als schakelmechnisme tussen bestaande databronnen. 4.2 Functionele behoeften COINS 2.0 In deze paragraaf heeft de COINS TMG de knelpunten in het werken met COINS 1.0, zoals beschreven in hoofdstuk 3, vertaald naar functionele behoeften waaraan COINS 2.0 dient te voldoen, tegen de achtergrond van het toekomstbeeld uit paragraaf 4.1. a) COINS 2.0 dient eenduidige uitwisseling van alle data (informatie, documenten) die beschikbaar komen in een bouwproject (onder andere bij de toepassing van SE), inclusief hiermee samenhangende metadata (zoals versie, opsteller, datum en tijd) te faciliteren. Dat wil onder meer zeggen, dat niet alleen informatie over objecten, maar bijvoorbeeld ook (data uit) risicodossiers, validatie- en verificatierapporten, werkzaamheden e.d. moeten kunnen worden uitgewisseld. b) COINS 2.0 dient projectpartners geen werkwijze op te leggen, maar moet flexibel zijn in de methoden die het ondersteunt. 23

24 Organisatie A Proces Output Input Proces Organisatie B Input Proces Output Organisatie C Input Proces Output Uitwisseling via COINS Uitwisseling via COINS Figuur 6: COINS dient zich primair te richten op de uitwisseling van data en zich zo weinig mogelijk te bemoeien met de interne processen van bouwpartners c) In COINS 1.0 werd gebruik gemaakt van een objectstructuur, waarin slechts één type objectrelaties mogelijk was. In de praktijk blijken voor verschillende views op de objecten verschillende objectrelaties nodig te zijn. Voorbeeld: een systems engineering view vraagt om een decompositie op basis van functionaliteit, een bouwkosten view vraagt om een decompositie op basis van gelijksoortige materialen of werksoorten, een bouwplanning view vraagt om een decompositie op basis van bouwvolgorde. Het betreft steeds dezelfde objecten, maar op een andere wijze gerangschikt. In COINS 1.0 werd de systems engineering view in feite ook opgelegd aan andere domeinen, waar deze structuur als een keurslijf werd ervaren. COINS 2.0 moet het mogelijk maken om meerdere relaties tussen dezelfde objecten aan te brengen. Dat geldt ook voor andere informatie-entiteiten. Zo wordt het mogelijk om, afhankelijk van de context, dezelfde entiteiten in verschillende structuren weer te geven. d) Het systeem van informatie-uitwisseling dient bruikbaar te zijn in de volledige life cycle van het bouwwerk. Ook in de plan- en initiatieffase, wanneer nog geen fysieke objecten zijn gedefinieerd, moet al informatie via COINS 2.0 kunnen worden uitgewisseld (zoals stakeholdereisen). e) Vanuit de gebruikers is er behoefte aan een duidelijke afbakening van wat wel en niet tot de COINS standaard behoort. In de ISO 8000 Data Quality [8] wordt een aantal communicatielagen onderscheiden, zoals weergegeven in de onderstaande figuur (afkomstig uit het Europese ORCHID project, waarin de ISO 8000 een rol speelt). Dit lagenmodel kan helpen bij de gewenste afbakening van COINS 2.0. Vooralsnog is de gedachte dat COINS 2.0 zich met name zou moeten richten op de syntax- en semantieklagen.. 24

25 Figuur 7: Allocatie van COINS 2.0 in het lagenmodel communicatie op basis van ISO 8000 f) COINS 2.0 moet eenvoudig, vanuit en ten behoeve van de eigen IT-omgeving, kunnen worden geïmplementeerd door ICT ers van organisaties en bedrijven die betrokken zijn bij projecten in de bouwsector (softwareprogrammeurs). Voor degenen die software moeten schrijven, moet de standaard toegankelijk en eenvoudig te gebruiken zijn, onder andere in een.net omgeving 1, naast de meer WEB georiënteerde talen als JAVA. De basis van COINS moet overigens taalonafhankelijk en daarmee duurzaam zijn g) De door deze programmeurs ontwikkelde (COINS-)software moet door eindgebruikers (projectteamleden in bouwprojecten) zo eenvoudig mogelijk te gebruiken zijn. Eindgebruikers moeten via een gebruikersinterface worden afgeschermd van eventuele complexiteit van de technische oplossing die wordt gekozen voor COINS 2 h) Het kernmodel van COINS 2.0 moet voor en door eindgebruikers binnen een project, organisatie of samenwerkingsverband eenvoudig configureerbaar en uitbreidbaar zijn (bijvoorbeeld door middel van referentiekaders), zonder dat de standaard zelf moet worden uitgebreid. Gebruikersorganisaties moeten met een goede handleiding zelf een referentiekader kunnen maken. i) Er is behoefte aan hulpmiddelen/software om instantiemodellen te maken. 1 NOOT: Eenvoudig te implementeren wil niet zeggen dat de standaard zelf eenvoudig moet zijn, maar dat het noodzakelijk is om de complexiteit van de standaard zoveel mogelijk onder de motorkap te houden voor zowel softwareprogrammeurs als eindgebruikers. 2 Deze eis geldt ook al voor COINS 1.0, maar door het ontbreken van voldoende ondersteunende software worden softwareprogrammeurs nog te vaak geconfronteerd met onder de motorkap technologie. 25

26 j) De betekenis (semantiek) van de uitgewisselde informatie moet eenduidig zijn door verwijzing naar eventuele referentiekaders en/of erkende objecttypen- of conceptenbibliotheken k) De standaard moet zo goed mogelijk afdwingen, c.q. faciliteren dat projectpartners uitsluitend inhoudelijk consistente informatie uitwisselen. l) COINS 2.0 moet uitwisseling van (voor het doel van de uitwisseling relevante) delen van beschikbare informatie in projectdatabases van verschillende projectpartners mogelijk maken. Het moet niet nodig zijn om telkens een volledige COINS container uit te wisselen. m) Het moet mogelijk zijn om niet telkens een volledige (of gedeeltelijke) objecttypenbibliotheek met COINS 2.0 mee te moeten uitwisselen, maar slechts referenties naar informatie in een objecttypenbibliotheek mee te sturen 3. Per project moeten afspraken worden gemaakt welke (delen van) een bibliotheek of bibliotheken van toepassing zijn. n) De traceerbaarheid wie heeft wanneer welke eisen gesteld, wijzigingen doorgevoerd, informatie toegevoegd enzovoort wordt bij het werken met COINS 1.0 als onvoldoende ervaren. In dit verband leven verschillende wensen bij gebruikers van COINS: i. er is een wens om extra data aan statements te kunnen hangen, zodat relaties bijvoorbeeld kunnen worden voorzien van statusinformatie, opmerkingen en dergelijke. Ook de mogelijkheid om extra data over waarden van eigenschappen (property values) mee te geven is gewenst, bijvoorbeeld: schatting, berekend, met risico (zie figuur 8, de basisvorm van een z.g. Named Graph: een triple voorzien van een identifier); ii. Er is een wens om versiebeheer op statement-niveau te (kunnen) doen; iii. Er is een wens om verschillende versies van objecten te kunnen uitwisselen in één container, om te kunnen voldoen aan eisen van traceerbaarheid. Figuur 8: Koppelen van metadata aan relaties / statements 3 Dat dit tot dusver wel gebeurt, ligt niet zozeer aan COINS, als wel aan het feit dat een ontsluiting van de OTL van RWS via een publieke webservice nog niet beschikbaar is. Voor opdrachtnemers is het in de huidige situatie moeilijk om een onderscheid te maken tussen de COINS standaard en de OTL 26

27 o) Er dient een kennisinfrastructuur te zijn waarop zowel ICT ers als eindgebruikers een beroep kunnen doen als ze vastlopen bij de implementatie en/of het gebruik van COINS 2.0 (NB: de BIR beijvert zich voor één beheerorganisatie voor alle Nederlandse open BIM standaarden. Deze organisatie moet ook kunnen adviseren en assisteren bij de implementatie en het gebruik van de standaarden). p) COINS 2.0 moet bij voorkeur een uitwisselingsstandaard zijn/worden die niet alleen wordt gebruikt als vertaalslag bij oplevering, voor de overdracht van informatie tussen opdrachtnemer naar opdrachtgever, maar ook voor de dagelijkse uitwisseling tussen verschillende disciplines binnen een project of organisatie. q) Zie verder ook de functionele behoeften die zijn geformuleerd voor COINS release 1.1, waar onder: i. de mogelijkheid om met een COINS-container alleen verschilinformatie (en niet steeds de complete informatie) over te dragen; ii. realisatie compatibiliteit met de CB-NL en de OTL; iii. verbeteren van de documentatie. iv.... Deze functionele behoeften gelden uiteraard ook voor COINS 2.0/ 27

28 5. Technische eisen voor COINS 2.0 In dit hoofdstuk worden de functionele behoeften die zijn verwoord in paragraaf 4.2, nader uitgewerkt en/of vertaald naar technische eisen die kunnen worden gesteld aan COINS 2.0. Uitgaande van de functionele behoeften heeft de COINS TMG zich daarbij de volgende vragen gesteld. a) Hoe kan worden voorkomen dat COINS 2.0 een engineeringsmethode oplegt? b) Het eventuele gebruik van OWL binnen COINS: hoe verberg ik OWL? c) Wat is de minimale omvang van het kernmodel van COINS? d) Hoe moet het versiebeheer in COINS 2.0 worden geregeld? e) Hoe kan technisch worden gerealiseerd dat gebruikers eenvoudig een referentiekader kunnen maken? f) Eenvoudig aanbieden van (selecties uit) een bibliotheek (zoals de OTL): hoe doe je dat? g) Hoe verhoudt COINS zich idealiter tot de lagen volgens ISO 8000? h) Hoe moet een praktisch COINS uitwisselingsmechanisme eruit zien dat geschikt is voor zowel grote als kleine projecten? i) Hoe regel je in de diverse relevante softwareproducten dat een via COINS uitgewisseld model wordt omgezet naar de interne gegevensstructuur van die software, met behoud van de functionele betekenis en mogelijkheden? j) Zijn er mogelijkheden om zinvolle elementen van OWL toe te passen boven op een RDFSomgeving? Ad a) Hoe kan worden voorkomen dat COINS 2.0 een engineeringsmethode oplegt? De behoefte is om in de core van COINS 2.0 zo min mogelijk processemantiek op te nemen, waardoor het gebruik van de core flexibeler wordt (dat wil zeggen: bruikbaar in uiteenlopende procesmodellen). Proceselementen moeten waar nodig in referentiemodellen worden uitgewerkt (een referentiemodel is een specifieke uitbreiding op de core van COINS). Eén en ander kan tot gevolg hebben, dat de SE-module die is opgenomen in COINS 1.0, moet worden overgeheveld naar een referentiekader. Mogelijk moeten bij COINS 2.0 meerdere referentiekaders worden meegeleverd, bijvoorbeeld SE simpel, SE geavanceerd e.a. Andere mogelijk aan te bieden referentiekaders zijn Risicomanagement, Validatie & Verificatie, Eisenbeheer en Raakvlakkenbeheer. Aanbeveling is om dit uit te werken in samenspraak met de Werkgroep Systems Engineering van de BIR. Ad b) Het eventuele gebruik van OWL binnen COINS: hoe verberg ik OWL? Het implementeren van een standaard als COINS is in feite niet goed mogelijk zonder goede tooling. De ontwikkeling van tools moet prioriteit krijgen, c.q. worden gestimuleerd. COINS 1.0 gebruikt OWL voor de opbouw van het conceptuele model. Het instantiëren en uitwisselen gebeurt op het eenvoudiger RDF(S)-niveau. Gebruikers zijn hier kennelijk 28

29 onvoldoende van op de hoogte en/of ervaren ook dat niveau als complex. Ook hier zijn toegankelijke documentatie en een handleiding noodzakelijk. Kennis over RDF(S), RDFS-Named graphs en OWL is nog niet wijd verbreid. Software bibliotheken om het werken met OWL te vergemakkelijken bestaan, maar zijn zeker niet in overvloed aanwezig. Java lijkt de dominante software taal voor OWL bibliotheken. In de dot.net omgeving zijn minder OWL bibliotheken te vinden en de kwaliteit lijkt ook minder. Voor RDF/RDFS is wel bruikbare software beschikbaar, ook voor de dot.net omgeving. In beginsel kan het werken met triples (zoals gebeurt met RDF, RDFS, OWL en RDFS Named Graphs) goed de basis vormen voor het COINS kernmodel (c.q. de semantiek), maar om de gebruiksdrempel te verlagen is het belangrijk om de inhoud te kunnen overdragen via XML/XSD, ASCII files en via webservices en/of API s (software waarin bepaalde mechanismen zitten om bijvoorbeeld een COINS container uit te pakken en stukjes informatie te interpreteren). De meeste softwareleveranciers kunnen aanhaken op XML met bijbehorend XSD-schema en RDF/RDFS. Er moet goede documentatie komen die ICT ers in de GWW-sector bij de hand nemen bij het stap voor stap implementeren van COINS 2.0 in een project, vanuit en voor de eigen ITomgeving. Documentatie en handleiding(en) moeten worden afgestemd op de praktijk en denkwereld van verschillende doelgroepen. Er moet onderscheid worden gemaakt naar: o o o het structureren van data in een model of referentiekader; het implementeren van COINS 2.0 in software; het implementeren/gebruiken van COINS 2.0 (-software) in projecten. Vanwege het wijdverbreide gebruik van het pakket Relatics in projecten waarin SE wordt toegepast, is er met name behoefte aan tooling die de conversie van Relatics naar COINS (en omgekeerd) faciliteert. De ontwikkeling van een conversietool Relatics-COINS kan worden gezien en behandeld als een snelle route naar goede tooling. Dit mag er echter niet toe leiden dat Relatics expliciet of impliciet wordt voorgeschreven in projecten. Een conversietool moet nadrukkelijk worden gepresenteerd als een voorbeeld van hoe het kan. Ad c) Wat is de minimale omvang van het kernmodel van COINS? In de TMG is afgesproken om te onderzoeken of het COINS kernmodel kleiner kan worden gemaakt, met als doel een lichtere standaard te maken met optimale gebruiksflexibiliteit, maar wel valideerbaar. Aan de hand van het CBIM-model van COINS 1.0 zijn in het kader van Retinking the standard een voorbeeldset van relaties en root classes afgeleid die in het COINS 2.0 Kernmodel zouden moeten worden opgenomen. De root classes en de voorlopige voorbeeldset van relaties zijn weergegeven het schema van figuur 9. De getoonde root classes en relaties komen voort uit ISO Industrial automation systems and integration Integration of life-cycle data for process plants including oil and gas production facilities - - Part 11: Methodology for simplified industrial usage of reference data [9]. In deze norm zijn afspraken vastgelegd voor een systeem voor het vastleggen en uitwisselen van informatie in de procesindustrie, dat qua doelstellingen en technologie verwant is aan COINS. 29

30 COINS root classes COINS:PhysicalObject COINS:InformationObject COINS:AbstractObject COINS:RepresentationOfThing COINS:Scale COINS:Feature COINS:Status COINS:Organism COINS:Activity COINS:Event COINS:PeriodInTime COINS:Organization COINS:Role COINS:Phase COINS:Collection COINS:TemporalWholePart Basisset relaties Consists of (physical object) Is of material Has property (kenmerk, karakteristiek, prestatie Is quantified in (UOM) Has magnitude (kenmerkwaarde) Is located at (ruimte, area) Is represented by (linked data in 3D model) Has as shape (vorm) Has as topology (structuur) Is connected with (logisch/functioneel en fysiek) Has feature) Performs function Is materialized by Is a specification for Concerns characteristic Is fulfilled by Has acceptance criterion Has as upper bound Has as lower bound Is of type Is an instance of Is a specialization of Is verified by Has consequence if not fulfilled Has status Is a state for Is approved by Is released by Is verified by Figuur 9: lijst ter indicatie voor root classes en relaties in COINS 2.0 Kernmodel (dient nader te worden onderzocht en vastgesteld) Op basis van de root classes en voorbeeldset van relaties kunnen vervolgens referentiemodellen worden gemaakt, waarbij bij voorkeur gestandaardiseerde termen worden gebruikt(vastgelegd in onder andere de CB-NL), die specialisaties zijn van de COINS root classes. Het nader vaststellen van omvang en inhoud van het COINS Kernmodel en het toetsen daarvan moeten in een werkpakket voor COINS 2.0 worden opgepakt (zie figuur 16, activiteit 3). Daarbij behoort ook de beoordeling van een conversie van huidige toepassingen in 1.0/1.1 naar

31 Ad d) Hoe moet het versiebeheer in COINS 2.0 worden geregeld? In de COINS TMG zijn in grote lijnen twee opvattingen of benaderingen betreffende het versiebeheer van informatie in een COINS container besproken: 1. Het versie- en wijzigingenbeheer van COINS Containers is de verantwoordelijkheid van de ontvangers en wel binnen het eigen Document Management Systeem (DMS). De ontvanger vergelijkt het geen hij ontvangt, altijd met hetgeen hij al heeft en traceert zo de mutaties. Het betreft hier in feite versiebeheer van een COINS Container als geheel en impliceert bijvoorbeeld dat dezelfde Container bij verschillende projectpartners andere versienummers kan hebben. 2. Het versiebeheer van data (een statement, feit) is de verantwoordelijkheid van degene(n) die data muteert, c.q. muteren. Het versiebeheer vindt plaats op het niveau van de data zelf (lees: op het niveau van statements of triples). Dit impliceert onder andere dat binnen één COINS Container meerdere versies kunnen voorkomen van één object. Dit faciliteert de traceerbaarheid van beslissingen (wie heeft wanneer welke mutaties doorgevoerd e.d.). Een definitieve keuze tussen beide benaderingen is in het kader van Rethinking the standard nog niet gemaakt. Hiervoor is een diepgaander analyse nodig van mogelijke implicaties van beide benaderingen. De keuze heeft bijvoorbeeld implicaties voor ten eerste het uitwisselingsmechanisme (de wijze waarop je dit semantisch kunt duiden) en ten tweede de software die wordt gebruikt en voor het databasemanagement. Besloten is hiervoor een apart werkpakket op te nemen in de Agenda voor COINS 2.0. Het formuleren en uitvoeren van use cases dient bij te dragen aan de onderbouwing van de keuze voor een passende benadering van het versie- en wijzigingenbeheer. Ad e) Hoe kan technisch worden gerealiseerd dat gebruikers eenvoudig een referentiekader kunnen maken? Hiervoor zijn tools nodig die eenvoudig in het gebruik zijn. Dit zou op een visuele manier kunnen of door een vraag-en-antwoord methode. De TGM acht het mogelijk om een tool te maken die configureerbaar, dan wel implementeerbaar is door ICT ers in de GWW-sector. Het is belangrijk dat zo n tool vergezeld gaat van duidelijke instructie/handleiding. Hiernaast is het wenselijk dat een Referentiekader Validator wordt ontwikkeld om de kwaliteit van aldus ontwikkelde referentiekaders te kunnen toetsen. Ad f) dat? Eenvoudig aanbieden van (selecties uit) een concepten- of objectenbibliotheek: hoe doe je Inhoud, zoals een concepten- of objecttypenbibliotheek (bijvoorbeeld de OTL van RWS), valt buiten het domein van de COINS standaard, maar COINS moet kunnen worden toegepast in combinatie met welke objecttypenbibliotheek dan ook. Los daarvan moet het mogelijk zijn om voor een project bijvoorbeeld niet een volledige concepten- of objecttypenbibliotheek over te dragen, maar slechts referenties naar een voor het 31

32 project relevante subset. Er is tooling nodig om voor een project relevante selecties uit een objecttypenbibliotheek te kunnen maken. Dat moet bovendien zodanig kunnen, dat gebruikers niet een volledige taxonomische boom moeten nalopen om alle relevante eigenschappen van een bepaald objecttype te achterhalen. Dit is strikt genomen geen taak van de COINS-groep, maar omdat de acceptatie en het gebruik van COINS mede afhankelijk is van de beschikbaarheid van dergelijke tooling, is het raadzaam dat de COINS-groep aan de juiste knoppen draait om de ontwikkeling ervan te stimuleren. Ad g) Hoe verhoudt COINS zich idealiter tot de lagen volgens ISO 8000? Het onderwerp van de ISO 8000 is: hoe definieer je kwaliteit van informatie, hoe eenduidig, compleet en geldig is die informatie? De ISO 8000 is nog in discussie, de lagen zijn nog niet 100% goed gedefinieerd. Niettemin is het raadzaam om bij de ontwikkeling van COINS 2.0 naar deze norm te kijken. Ook in COINS zijn verschillende lagen te onderscheiden. Om de standaard ordelijk te kunnen ontwikkelen, is het goed om die lagen, naar analogie van ISO 8000, expliciet te benoemen en goed te definiëren (zie ook figuur 7). Organisatierol laag (VISI) Domeinkennis laag (Referentiemodellen bijv. SE, ILS specs ) Inhoud laag (referentie naar conceptenbibliotheken, bijv. CB-NL, OTL) Semantiek laag (COINS Kernmodel) ILS (Informatie Leverings Specificatie) Syntax laag ("drager" van semantiek) (W3C standaarden / RDF Named Graphs) Opslag van semantiek (COINS Container) Figuur 10: (Voorlopige) mapping van aspecten van COINS in het lagenmodel communicatie op basis van ISO 8000 Als partijen onderling informatie willen overdragen, moeten ze op iedere laag afspraken maken. COINS 1.0 heeft met iedere laag wel een relatie: o Opslaglaag COINS Container. De opslagmethode moet ook kunnen worden gespecificeerd in de ILS; dit kan bijvoorbeeld ook in de vorm van een zipfile of op een andere wijze. 32

33 o o o o o Syntaxlaag W3C standaarden: OWL of RDFS Named Graphs voor de opbouw van datamodellen en RDF-XML (als één van de serialisaties van RDF) voor het uitwisselen. De tool moet daarvoor geschikt zijn. De COINS Navigator voor COINS 1.0 accepteert al deze formaten als input, maar alleen RDF-XML als output. Semantieklaag COINS Kernmodel; Inhoudlaag referenties naar objecttypenbibliotheken; Domeinkennis laag (scope) Referentiemodellen + specificaties in de ILS; Organisatielaag gebruik van de VISI-standaard voor de formele transactiecommunicatie. De vraag kan worden gesteld welke lagen al voldoende worden afgedekt door andere normen en in welke leemten COINS 2.0 derhalve dient te voorzien. Besloten is om voor het definiëren van de inhoud van de lagen een apart werkpakket te definiëren in de Agenda COINS 2.0. Aandachtpunt daarbij is, dat de COINS systematiek ook het gebruik van andere objecttypenbibliotheken dan CB-NL en OTL moet ondersteunen Ad h) Hoe moet een praktisch COINS uitwisselingsmechanisme eruit zien dat geschikt is voor zowel grote als kleine projecten? Toepassing in grote of kleine projecten maakt voor de standaard in feite niets uit. Essentieel is dat de toepassingsdrempel van informatie die organisaties/bedrijven in projecten krijgen aangeboden, zo laag mogelijk wordt gemaakt. Goede documentatie van de uitwisselingsstandaard is een eerste vereiste. Zoals eerder is aangestipt, moet onderscheid worden gemaakt tussen het schema (semantieklaag, dus kernmodel en bijbehorende systematiek) en het uitwisselingsformaat (syntax/format laag). Het schema (de semantiek) kan goed met triples in OWL of RDFS- Named Graphs worden opgebouwd. Wanneer het schema goed is, kan de het uitwisselingsformaat (de syntax) relatief eenvoudig zijn. Gewaakt moet worden voor een wildgroei aan serialisatietechnieken. Een volgende vraag is hoe ontvangers van een COINS Container die in XML (o.i.d.) wordt aangeboden, de data moeten interpreteren in de eigen informatiesystemen. Die informatiesystemen zijn in essentie niet ingericht op het werken met en het interpreteren van triples. De softwaremodule die de container ontvangt, zal de ontvangen informatie altijd één op één moeten opslaan in een (tijdelijk) datamodel of interfacemodule. Door middel van mapping technieken kan de informatie vervolgens worden overgedragen naar het eigen informatiesysteem. Iedere andere oplossing zal gepaard gaan met informatieverlies. Verder is niet duidelijk hoe projectpartners de resultaten van hun applicaties weer terug moeten vertalen naar OWL of RDFS Named Graphs, wanneer wordt geëist dat data via de COINS systematiek moet worden uitgewisseld. Dit moet in een werkpakket voor de ontwikkeling van COINS 2.0 worden uitgezocht en gedocumenteerd. Dit onderdeel van de COINS systematiek is kritiek in verband met de technische haalbaarheid, waarbij bovendien in aanmerking moet worden genomen dat aangeboden, te verwerken informatie uit verschillende bronnen afkomstig kan zijn. 33

34 Ad i) Hoe regel je in de diverse relevante softwareproducten dat een via COINS uitgewisseld model wordt omgezet naar de interne gegevensstructuur van die software, met behoud van de functionele betekenis en mogelijkheden? Een gebruiker moet in een (COINS compatible) software-pakket: 1) het (semantisch) model kunnen inlezen, 2) de instantie-gegevens (syntactische gegevens) kunnen inlezen; 3) die gegevens eventueel in een intern formaat opslaan; 4) de benodigde functionele bewerkingen op de gegevens kunnen uitvoeren; 5) weer een correcte COINS container met (delta-) gegevens kunnen creëren. (Toelichting: een gebruiker moet bijvoorbeeld in Relatics een via COINS uitgewisseld model kunnen inlezen, het model in Relatics kunnen wijzigen en aanvullen en vervolgens weer vanuit Relatics naar een COINS model kunnen exporteren.) Ad j) Zijn er mogelijkheden om zinvolle elementen van OWL toe te passen in bijvoorbeeld een RDFS-omgeving? Zoals reeds opgemerkt, is er niet of nauwelijks software beschikbaar om het werken met OWL te vergemakkelijken. RDF en RDFS zijn goed begrijpbare technieken voor ICT en ICT ers in de GWW. Voordeel van RDFS is, dat er weliswaar niet ruim software voor implementatie beschikbaar in.net en Java-omgevingen. XML, XSD, RDF, RDFS en OWL en RDFS Named Graph zijn W3C standaarden (W3C staat voor World Wide Web Consortium). Deze standaarden bouwen in de aangegeven volgorde op elkaar voort. Figuur 10 geeft een overzicht van een deel van de modelleerconstructies die de W3C standaarden bieden (bron: Michel Böhms, TNO). XSD RDF RDFS OWL2 xsd:string, xsd:integer, xsd:float, xsd:boolean, xsd:anyuri, xsd:datetime rdf:type rdf:property rdfs:label rdfs:comment rdfs:class (abstract version of owl:class) rdfs:datatype rdfs:domain rdfs:range rdfs:subclassof rdfs:subpropertyof rdfs:resource owl file preamble: baseuri, imports and prefixes owl:ontology 34

35 owl:imports owl:versioninfo owl:class owl:datatypeproperty owl: FunctionalProperty owl: ObjectProperty owl:restriction owl:hasvalue & owl:onproperty owl:equivalentclass owl:allvaluesfrom owl:somevaluesfrom & owl:withrestrictions & owl:onsatatype owl:mincardinality, owl:maxcardinality, owl:cardinality & owl:onproperty owl:minwualifiedcardinality, owl:maxqualifiedcardinality, owl:qualifiescardinality & owl:onclass owl:disjointwith; owl:propertydisjointwith owl:complementof, owl:intersectionof, owl:unionof owl:one of (etcetera) Figuur 11: Overzicht van een deel van de modelleerconstructies van W3C standaarden Het COINS 1.0 Kernmodel en de COINS Referentiemodellen gebruiken in ieder geval alle hier genoemde XSD, RDF en RDFS modelleerconstructies. Daarnaast maakt COINS 1.0 gebruik van een deel van de OWL modelleerconstructies (vetgedrukt in figuur 11): o OWL Classes: owl:datatypeproperty, owl:functionalproperty, owl:objectproperty, owl:ontology, owl:restriction. o OWL Properties: owl:allvaluesfrom, owl:cardinality, owl:equivalentclass, owl:imports, owl:maxcardinality, owl:mincardinality, owl:onproperty, owl:unionof, owl:versioninfo. Deze OWL constructs bieden een aantal modelleringsmogelijkheden die RDFS niet kan bieden, maar die zeer welkom zijn in de COINS-omgeving en die je niet zomaar kunt of wilt missen. Voorbeelden zijn: o o o o o o het aan elkaar kunnen linken van verschillende modellen; een beter semantisch onderscheid tussen objecteigenschappen (objectrelaties) en datatype-eigenschappen (waarden); een verdere verfijning van objectrelaties (zoals van waar naar waar, bijvoorbeeld van klasse FunctionalObject naar klasse TechnicalSolution); de mogelijkheid om met behulp van restricties allerlei verfijningen te kunnen specificeren; meer gereedschap om de kardinaliteit van relaties te specificeren; zo kunnen bijvoorbeeld optionele en verplichte eigenschappen worden onderscheiden; het kunnen toepassen van meer complexe verzamelingsoperaties (doorsnee, vereniging, verschil, disjunctie, etc. 35

36 RDF Named Graph en ISO bieden in combinatie in grote lijnen dezelfde modelleringsmogelijkheden als OWL. De ISO norm gaat uit van RDFS triples, die in de norm worden aangevuld met gestandaardiseerde relaties. Deze relaties vertonen grote overlap met de OWL constructs, maar zijn semantisch rijker dan OWL. Daarnaast maakt de ISO norm gebruik van NamedGraphs, waarbij er een naam wordt toegekend aan een triple. Het wordt daarmee een quad. Deze naam. c.q. identifier wordt gebruikt voor o.a. het stellen van een feit over de betreffende triple door een andere triple. Hiermee kan metadata over een triple worden gedefinieerd, bijvoorbeeld de versie van het feit of extra informatie over kenmerkwaarden en objectrelaties. Zie figuur 8. Deze technologie is in een prove of concept met succes toegepast in de procesindustrie en lijkt relatief eenvoudig implementeerbaar. COINS 1.0 is een specifieke toepassing van OWL die wat afwijkt van de oorspronkelijke aanleidingen voor het ontwikkelen van deze ontologietaal. Kenmerkend verschil is bijvoorbeeld dat OWL uitgaat van open world technologie ( iedereen mag alles zeggen over alles, waarbij de validatie van wat iedereen zegt veel aandacht en energie vraagt), terwijl COINS 1.0 uitdrukkelijk uitgaat van een closed world paradigma (waardoor er meer zekerheid is dat de aangeboden informatie eenduidig en juist is). Zo is het uitdrukkelijk niet toegestaan om in COINS BIM-data OWL-taalelementen op te nemen, die het COINS Kernmodel en/of gehanteerde referentiekaders uitbreiden met extra objectklassen of relatietypen. Wanneer zoiets noodzakelijk blijkt, is de enige toegestane mogelijkheid het specificeren van een extra (custom) referentiekader. Classes in de Referentiekaders zijn altijd subtypes van de classes in het COINS Kernmodel. Het goed kunnen valideren van de inhoud van een BIM-container is direct afhankelijk van de precisie van de toegepaste conceptuele modellen. Het lijkt niet verstandig om de mogelijkheden om die precisie te bereiken, in te perken door het beperken van de toegestane modelleringsconstructies. Met andere woorden: het zou niet goed zijn om je bij de opbouw van het COINS Kernmodel en Referentiemodellen te beperken tot het gebruik van de modelleringsconstructies van XSD, RDF en RDFS. Om de noodzakelijke nauwkeurigheid te bereiken, is het gebruik van bepaalde OWL constructs (of als alternatief RDFS NamedGraphs, aangevuld met ISO relaties) noodzakelijk Gebruik van bepaalde OWL constructs is ongewenst. Om bijvoorbeeld te werken met owl:equivalentclasses, zijn formeel reasoners nodig. In de COINS TMG is gesteld dat het gebruik van reasoners moet worden uitgesloten, omdat daarmee in feite een voor COINS ongewenste open world wordt geïntroduceerd. Dit houdt in dan ook geen gebruik moet worden gemaakt van OWL constructs die daar eigenlijk om vragen. Samenvattend en concluderend (ad j): 1. COINS 1.0 maakt gebruik van een (beperkt) aantal OWL-constructs, die modelleringsmogelijkheden bieden die bijvoorbeeld RDFS niet biedt. Het is ongewenst om deze mogelijkheden af te snijden door voor COINS 2.0 exclusief te kiezen voor RDFS als modelleringstaal. Dus RDFS gebruiken met daarbovenop of OWL of Named Graph 36

37 2. Aan de andere kant is het evenmin gewenst om OWL in zijn volle omvang toe te passen binnen COINS, omdat daarmee al snel de voor COINS-gebruikers ongewenste open world wordt geïntroduceerd. 3. Voordeel van RDFS is, dat er weliswaar niet ruim software beschikbaar in dot.net en Javaomgevingen voor implementatie (met andere woorden: de adoptie van RDFS is groter dan die van OWL). 4. Eén mogelijke oplossingsrichting is om goed te definiëren welke set van OWL constructs kan worden toegestaan en deze te behandelen als een extra set RDFS constructs. Daardoor ontstaat een soort RDFS+ voor gebruik in COINS 2.0, die enerzijds geen beperkingen oplegt in vergelijking tot COINS 1.0, maar anderzijds de mogelijkheid biedt om gebruik te maken van beschikbare RDFS-tools voor implementatie. Voorstel is om deze oplossingsrichting verder te onderzoeken, c.q. uit te werken in een werkpakket voor COINS Een tweede mogelijke oplossing is het gebruik van RDF NamedGraphs als gedefinieerd in ISO De functionaliteit van de beschreven RDFS+ kan ook met deze standaard worden bereikt, met als bijkomende voordelen de mogelijkheid om metadata te koppelen aan de statements en een onbeperkte uitbreiding van de semantiek. Dat betekent bijvoorbeeld dat op het niveau van individuele statements ( triples ) versiebeheer mogelijk is (dit kan in OWL niet of in ieder geval minder direct/eenvoudig). Voorstel is om ook deze tweede oplossingsrichting nader te onderzoeken in het kader van de ontwikkeling van COINS Na een onderbouwde SWOT-analyse van beide oplossingsrichtingen kan vervolgens in overleg met gebruikers een keuze worden gemaakt. 37

38 6. Architectuur De architectuur van COINS 2.0 dient tenminste de volgende aspecten omvatten: a) Kernmodel, Referentiekaders en de relatie daartussen; b) het proces van data-uitwisseling via COINS ( business rules ); c) lagenmodel naar analogie van ISO 8000; d) gebruiks- en implementatiescenario s en toetsing daarvan; e) demarcatie van onderdelen van de systematiek. Ad a: Kernmodel, Referentiekaders en de relatie daartussen Het COINS Kernmodel vormt de neutrale basis voor het datamodel en is optimaal flexibel in het gebruik (NB: niet de kern is flexibel, maar het gebruik is flexibel). In het kader van COINS 2.0 moet dus worden onderzocht wat de minimale omvang van het Kernmodel moet/kan zijn om dit te bereiken. Ter ondersteuning van specifieke processen kunnen Referentiekaders worden ontwikkeld, die gebruik maken van, c.q. voortborduren op het Kernmodel. Basis Proces Basis-SE Proces SE Proces bepalen hoeveelheden Proces 'X' Referentiekaders Referentiekader Basis SE Referentiekader SE Referentiekader hoeveelheden Referentiekader 'X' Kernmodel COINS Kernmodel Figuur 12: COINS Kernmodel, Referentiekaders en de relatie daartussen. De Referentiekaders bevatten specifieke (proces-)kennis die nodig is ter ondersteuning van de data-uitwisseling binnen de betreffende processen. Er dient in ieder geval een Referentiekader te komen, dat samen met het Kernmodel, de functionaliteit van het huidige COINS 1.0 dekt ( Basis- SE ). Op de COINS Wiki worden de Referentiekaders Systems Engineering (SE) en Hoeveelheden (ten behoeve van calculatie) genoemd. RWS heeft een eigen Referentiekader, dat bestaat uit het COINS Referentiekader SE met RWS-specifieke toevoegingen. Wanneer voor COINS 2.0 het Kermodel wordt gewijzigd, zullen ook de reeds bestaande Referentiekaders moeten worden aangepast. Verder kan bijvoorbeeld worden gedacht aan het toevoegen van nieuwe Referentiekaders als Systeemgerichte Contractbeheersing (SCB), Risicomanagement en Validatie en Verificatie Verschillende referentiemodellen kunnen naast elkaar worden toegepast. 38

39 Ad b): Het proces van data-uitwisseling via COINS Figuur 13 geeft schematisch het principe weer van de data-uitwisseling via COINS weer: data afkomstig uit het bedrijfsproces van Organisatie 1 en gestructureerd volgens het datamodel dat gebaseerd is op concepten uit de CB-NL, behorend bij de software van Organisatie 1, wordt vertaald naar het neutrale (dat wil zeggen: software-onafhankelijke) COINS-formaat. Dat gebeurt via mapping van de data aan het COINS Kernmodel en het/de toepasselijke Referentiekader(s). Voor de inhoud wordt verwezen naar één of meer Reference Data Libraries of Objecttypenbibliotheken (RDL, bijvoorbeeld CB-NL of OTL van RWS). De vertaalde data worden in de vorm van een COINS Container verzonden naar de ontvangende partij: Organisatie 2 in figuur 13. Hier gebeurt het omgekeerde proces: de data uit de COINS-Container worden via mapping vertaald naar het datamodel (resp. de datamodellen) die behoren bij de bedrijfsprocessen en software van Organisatie 2. Dit alles dient te gebeuren met volledig behoud van de betekenis en functionaliteit van data uit het bedrijfsproces van Organisatie 1 (op basis van het feit dat beide organisaties de concepten uit de CB-NL respecteren). Dit principe moet in het kader van de ontwikkeling van COINS 2.0 nader technisch worden ingevuld. Figuur 13: Proces van data-uitwisseling via COINS (de RDL betreft in deze context de CB-NL) Ad c): Lagenmodel naar analogie van COINS 2.0 Ook het lagenmodel behoort tot de architectuur van COINS 2.0. Dit model is bij de behandeling van de functionele en technische behoeften al uitvoerig aan de orde geweest en behoeft op deze plek geen nadere toelichting. Essentie is dat het voor een ordelijke ontwikkeling van COINS

40 nuttig en nodig wordt geacht om de verschillende lagen in relatie tot COINS expliciet te benoemen en te definiëren. Figuur 14: Lagenmodel communicatie binnen projecten Duidelijk moet worden gemaakt hoe met de ILS wordt omgegaan in relatie tot COINS. De ILS is een apart document, waarin in de vorm van tekst (dus niet in de vorm van een datamodel) is beschreven welke informatie contractueel moet worden geleverd. COINS definieert het datamodel, het format voor de opslag en uitwisseling van de data. Met behulp VISI worden berichten met betrekking tot leveringen van informatie in COINS Containers uitgewisseld (bijvoorbeeld: vraag om levering, leveringsbevestiging, autorisatie, acceptatie of verwerping, enzovoort). Ad d): Gebruiks- en implementatiescenario s en toetsing daarvan De COINS TMG adviseert om na consultatie van en overleg met gebruikers, zoals ingenieursbureaus en bouwbedrijven 4 - verschillende gebruiks- en implementatiescenario s uit te werken en te toetsen in use cases. Uit de scenario s moet onder andere de demarcatie worden afgeleid van welke implementatie-functionaliteit vanuit COINS moet worden meegegeven en wat aan de markt kan worden overgelaten. Welke webservices en/of API s moeten worden ontwikkeld? Algemeen uitgangspunt is dat de architectuur zo helder en duidelijk moet zijn, dat marktpartijen de voor de diverse gebruiks- en implementatiescenario s noodzakelijke interfaces kunnen bouwen. Impementatiescenario s moeten onafhankelijk van besturingssystemen of opslagstructuren (in de cloud, centraal, decentraal,...) De TMG adviseert om ieder scenario te toetsen aan de kwaliteitscriteria voor software, zoals beschreven in ISO 9126 [11] (zie ook 4 De vraag bij de consultatie luidt: Waarvoor en hoe wilt u COINS gebruiken? 40

41 Functionaliteit (functionality) geschiktheid (suitability) juistheid (accuracy) koppelbaarheid (interoperability) beveiligbaarheid (security) nakomen van functionaliteitsnormen (functionality compliance) Betrouwbaarheid (reliability) bedrijfszekerheid (maturity) foutbestendigheid (fault tolerance) herstelbaarheid (recoverability) nakomen van betrouwbaarheidsnormen (reliability compliance) Bruikbaarheid (usability) begrijpelijkheid (understandability) leerbaarheid (learnability) bedienbaarheid (operability) aantrekkelijkheid (attractiveness) nakomen van bruikbaarheidsnormen (usability compliance) Efficiëntie (efficiency) responsiesnelheid (time behaviour) middelenbeslag (resource behaviour) nakomen van efficiëntie normen (efficiency compliance) Onderhoudbaarheid (maintain-ability) analyseerbaarheid (analysability) wijzigbaarheid (changeability) stabiliteit (stability) testbaarheid (testability) nakomen van onderhoudbaarheidsnormen (maintainability compliance) Overdraagbaarheid (portability) aanpasbaarheid (adaptability) installeerbaarheid (installability) verdraagzaamheid (co-existence) vervangbaarheid (replaceability) nakomen van overdraagbaarheidsnormen (portability compliance) Figuur 15: Kwaliteitscriteria voor software conform ISO 9126 Daarnaast is het aan te bevelen COINS 2.0 te toetsten aan ISO 8000 [8]. Deze norm biedt kaders voor het verbeteren van de kwaliteit van verschillende soorten data. ISO 8000 definieert welke datakarakteristieken relevant zijn voor de kwaliteit van data, specificeert eisen aan die karakteristieken en geeft richtlijnen voor het verbeteren van de kwaliteit van data. De norm kan worden gebruikt in combinatie met bijvoorbeeld de ISO 9000 serie, maar ook onafhankelijk daarvan. 41

42 De scope van ISO 8000 omvat: principes van de kwaliteit van data; kenmerken van data die de kwaliteit ervan bepalen; eisen aan de kwaliteit van data; eisen aan de representatie van data-eisen, meetmethoden en meetresultaten in relatie tot dee kwaliteit van data; kaders voor het meten en verbeteren van de kwaliteit van data. Ad e): Demarcatie van onderdelen van de systematiek Er moet duidelijk zijn of zaken als beveiliging, autorisatie, ontvangstbevestiging en dergelijke deel uit maken van de COINS systematiek zit of dat zij bijvoorbeeld via VISI worden geregeld. 42

43 7. Agenda voor COINS 2.0 De resultaten van het project Rethinking the standard zoals beschreven in de voorgaande hoofdstukken, vormen de basis voor de ontwikkeling van COINS 2.0. Voor die ontwikkeling is een apart werkplan opgesteld: COINS 2014 Werkplan Wp5 Ontwikkeling release 2.0. Wp5 verwijst naar werkpakket 5 van het Projectplan COINS van de BIR d.d. 6 januari De input voor het werkpakket 5 Ontwikkeling release 2.0 bestaat uit: Projectplan versie 1.0 De resultaten van de ontwikkeling van COINS 1.1 De resultaten van werkpakket 3 uit het Projectplan COINS: Rethinking the standard. De structuur van de activiteiten van werkpakket 5 is als volgt. Figuur 16: Structuur van activiteiten t.b.v. de ontwikkeling van COINS 2.0 Zie verder COINS 2014 Werkplan Wp5 Ontwikkeling release 2.0 d.d...., dat mede kan worden beschouwd als een bijlage bij deze rapportage Rethinking COINS. 43