Transcript deze link

1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
Rethinking COINS
Eindrapportage
11 juli 2014
1
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
Colofon
COINS Technical Management Group:
Frans van Dam
René Dorleijn
Henk Schaap
Peter Willems
Aad Jongbloets
Renzo van Rijswijk
Bert de Wolde
Leo van Ruyven
René Wubbels
Wouter Notenbomer
Hans Schevers
Wouter Engelen
Jeroen van Geijlswijk
Dik Spekkink
:
:
:
:
:
:
:
:
:
:
:
:
:
:
Rijkswaterstaat, voorzitter
Movares
Gobar BV
TNO
Tauw
Strukton Engineering
Ipcon
Croon Elektrotechniek
ProRail
SBRCURnet, secretaris
Geodan
Movares
Infostrait
Spekkink C&R, rapporteur
2
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
Inhoud
Managementsamenvatting ............................................................................................................................ 4
1.
2.
Inleiding ................................................................................................................................................... 7
1.1
Leeswijzer....................................................................................................................................... 7
1.2
BIR Projectplan COINS ................................................................................................................ 7
1.3
Werkpakket Rethinking COINS ................................................................................................... 8
1.4
Ontwikkeling van software-tools ............................................................................................... 9
COINS 1.0: uitgangspunt voor het rethinking proces ....................................................................... 11
2.1
Introductie .................................................................................................................................... 11
2.2
Aanleiding.................................................................................................................................... 11
2.3
Doelstellingen .............................................................................................................................. 11
2.4
Organisatie ................................................................................................................................... 12
2.5
Onderdelen van COINS 1.0 ....................................................................................................... 12
3.
Knelpunten in het werken met COINS 1.0 ........................................................................................ 17
4.
Uitgangspunten COINS 2.0 ................................................................................................................. 19
4.1
Toekomstbeeld ............................................................................................................................ 19
4.1.1
Inrichting proces ..................................................................................................................... 19
4.1.2
Beschrijving van het product ................................................................................................ 20
4.1.3
Organisatievormen ................................................................................................................. 21
4.1.4
ICT hulpmiddelen .................................................................................................................. 22
4.2
Functionele behoeften COINS 2.0 ............................................................................................. 23
5.
Technische eisen voor COINS 2.0 ....................................................................................................... 28
6.
Architectuur .......................................................................................................................................... 38
7.
Agenda voor COINS 2.0 ...................................................................................................................... 43
Geraadpleegde literatuur ............................................................................................................................ 44
Bijlage 1: participanten in COINS .............................................................................................................. 46
3
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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 2014. 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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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 2.0.
1.2
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
2010. 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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Project startup;
Uitwerking release 1.1;
Rethinking the standard;
Software tooling 1.1;
Ontwikkeling release 2.0;
Update software tooling 2.0;
Publicatie release 2.0;
Certificering services;
Praktijkcasus;
Implementatie SE-standaard.
2.
Uitwerking
release 1.1
4. Software
tooling 1.1
6. Update
software
tooling 2.0
3.
Rethinking
the standard
5.
Ontwikkeling
Release 2.0
7.
Publicatie
Release 2.0
1.
Project
startup
8.
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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
Werkpakket 3:
Omschrijving:
Input:
Output:
Activiteiten
Randvoorwaarden:
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.
Werkplan, COINS 1.0
Agenda voor COINS 2.0
1. Review uitgangspunten en grondslag COINS 1.0
2. Oplijnen kennis COINS 1.0
3. Vaststellen functionele behoeften voor 2.0
4. Vaststellen technische behoeften voor 2.0
5. Functionele aanpassingen voor 2.0
6. Architectuur aanpassingen voor 2.0
7. Opstellen agenda voor 2.0
8. Toetsing van de resultaten
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 2.0 - tot een release 1.1 van de standaard. Daarbij wordt zoveel mogelijk geanticipeerd
op de functionele en technische behoeften die zijn geformuleerd voor COINS 2.0.
1.4
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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
2. COINS 1.0: uitgangspunt 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].

2.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.
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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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)
b)
c)
d)
afspraken over werkmethoden – COINS Engineering Methode (CEM);
afspraken over informatie – COINS Bouwwerk Informatie Model (CBIM);
implementatie strategieën en methoden (waaronder de COINS-Container);
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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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

Amount

affects

physical child
Datatype Properties

baseline status

Baseline

amount property

physical parent

change log

Building
type

previous state

creation day

C-BIM Object

baseline

primary orientation

default value

Catalogue Part

baseline object

property type

description

Connection

catalogue part

property value

document alias file

Document

child

requirement

Explicit 3D

contains

requirement of

document type
Representation

creator

secondary

document URI

Function

current state
orientation

end date

Function Fulfiller

document

shape

end date actual

Library Reference

female terminal

situates

end date planned

Locator

first parameter

spatial child

expired

Parameter

fulfills

spatial parent

layer index

Performance

is affected by

state of

modification date

Person or

is fulfilled by

supertype

name
Organisation

is situated in

task type

release date

Physical Object

locator

terminal

release status

Property Type

male terminal

terminal of

start date

Property Value

max bounding box

translation

start date actual

Requirement

min bounding box

verification

start dat planned

Space

modifier
function fulfiller

unit

State

next parameter
verification

user ID

Task

next version
performer

value

Task Type

parent
verification

value domain

Terminal

performance
requirement

verification date

Vector

performance of

verification method

Verification

verification result

VISI message

x coordinate

y coordinate

z coordinate


pathe
Figuur 2: COINS 1.0 Kernmodel (CBIM)

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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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
'VALIDEREN'
leveren
stellen
Eisen
Objecten
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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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.
2.
3.
Bim-directory, waarin één CBIM file is opgeslagen met de file
extensie .owl;
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.
Doc, waarin alle meegeleverde documenten zijn opgeslagen.
Dit kunnen documenten van verschillende oorsprong zijn, met
verschillende bestandsextensies.
De belangrijkste (potentiële) toepassingen van de COINSContainer zijn in COINS 1.0:

het overdragen van functionele specificaties en een
objectstructuur naar bijvoorbeeld een 3D-CAD-applicatie of
Figuur 4: schematische voorstelling
een planning;
COINS container

het samenstellen van een ontwerpdossier, bestaande uit
tekeningen/modellen en ontwerpnota’s waarin beslissingen
worden onderbouwd;

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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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: www.coinsweb.nl/wiki.
16
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
3. Knelpunten in het werken met COINS 1.0
In praktijkprojecten waarin het gebruik van COINS 1.0 is voorgeschreven, zoals het project SAAOne, 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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
k) Er is een wens om de inhoud van COINS Containers te kunnen valideren (toetsen of de inhoud
voldoet aan de standaard).
18
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
4. Uitgangspunten COINS 2.0
4.1
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.
4.1.1
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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
f.
g.
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.
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
4.1.2
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: www.bouwinformatieraad.nl)
20
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
j.
k.
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).
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.
4.1.3
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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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.
4.1.4
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.
r.
s.
t.
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.
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]).
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.
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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
Organisatie A
Proces
Output
Input
Proces
Organisatie B
Input
Proces
Output
Input
Proces
Output
Organisatie C
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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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
omgeving1, 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 COINS2
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.
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’.
1
25
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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
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
3
26
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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)
b)
c)
d)
e)
Hoe kan worden voorkomen dat COINS 2.0 een engineeringsmethode oplegt?
Het eventuele gebruik van OWL binnen COINS: hoe verberg ik OWL?
Wat is de minimale omvang van het kernmodel van COINS?
Hoe moet het versiebeheer in COINS 2.0 worden geregeld?
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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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

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)

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.
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 15296-11 “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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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 2.0.
30
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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.
2.
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.
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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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)
ILS
(Informatie
Leverings
Specificatie)
Semantiek laag
(COINS Kernmodel)
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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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 RDFSNamed 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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |

RDF Named Graph en ISO 15926-11 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 15926-11 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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
2.
3.
4.
5.
6.
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.
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).
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 2.0.
Een tweede mogelijke oplossing is het gebruik van RDF NamedGraphs als gedefinieerd in ISO
15926-11. 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 2.0.
Na een onderbouwde SWOT-analyse van beide oplossingsrichtingen kan vervolgens in
overleg met gebruikers een keuze worden gemaakt.
37
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
6. Architectuur
De architectuur van COINS 2.0 dient tenminste de volgende aspecten omvatten:
a)
b)
c)
d)
e)
Kernmodel, Referentiekaders en de relatie daartussen;
het proces van data-uitwisseling via COINS (“business rules”);
lagenmodel naar analogie van ISO 8000;
gebruiks- en implementatiescenario’s en toetsing daarvan;
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
Proces
Basis-SE
Referentiekaders
Referentiekader
Basis SE
Kernmodel
Proces 'X'
SE
Proces
bepalen
hoeveelheden
Referentiekader
SE
Referentiekader
hoeveelheden
Referentiekader
'X'
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 (‘BasisSE’). 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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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 2.0
39
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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 bouwbedrijven4 - 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
http://nl.wikipedia.org/wiki/ISO_9126)
4
De vraag bij de consultatie luidt: “Waarvoor en hoe wilt u COINS gebruiken?”
40
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
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 2014.
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
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
Geraadpleegde literatuur
[1]
BIR Informatiecluster – Projectplan COINS
Bijlage B bij Notitie Aanpak BIR Speerpunt SE-COINS
Frans van Dam / Henk Schaap
6 januari 2014
[2]
Toekomst voor het bouwproces – Een 3D-objectbenadering
Rapport van de onderzoeksfase van het programma COINS
H.A. Schaap, J.W. Bouwman
CUR-rapport 218, mei 2006
[3]
De overdracht van as built 2D CAD tekeningen en 3D modellen in de GWW-sector
Rapportage van de Werkgroep COINS-NLCS - Update 2013
D. Spekkink
SBRCURnet, november 2013
[4]
Identification of CBIM information objects
Guideline identification of CBIM information objects – Technical note
COINS wiki
http://www.coinsweb.nl/wiki/index.php/Identification_of_CBIM_information_objects
[5]
Rethinking COINS in relatie tot ISO15926-11
Presentatie
L. van Ruijven
Januari 2014
[6]
Linked Open Data – Pilot Linked Open Data Nederland
Deel 1 – Het Managementoverzicht
Deel 2 – De Verdieping
Editors: Erwin Folmer, Marcel Reuvers, Wilco Quak
Geonovum e.a.
Amersfoort, 2013
[7]
Conceptenbibliotheek Nederland (CB-NL)
Initiatief van de Bouw Informatie Raad (BIR)
www.cb-nl.nl
[8]
ISO/TS 8000-1:2011, Data quality — Part 1: Overview
International Standardization Organization
44
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
[9]
[10]
ISO 15926-11 “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”
ISO/TC 184/SC-4
ICS: 25.040.40; 75.020
Versie 16-04-2014
“Integrated Project Delivery: A Guide”
American Institute of Architects (AIA)
Center for Integrated Practice & Californian Council
California USA, 2007
http://www.aia.org/about/initiatives/AIAS076981
[11]
ISO 9126 (Kwaliteitscriteria voor software)
http://nl.wikipedia.org/wiki/ISO_9126
[12]
BIR kenniskaart nr. 1 “Nederlandse BIM levels”
http://www.bouwinformatieraad.nl/wp-content/uploads/2014/04/Kenniskaart001.pdf
BIR kenniskaart nr. 2 “Open BIM Standaardenkaart”
http://www.bouwinformatieraad.nl/wp-content/uploads/2014/04/Kenniskaart002.pdf
45
1 1 j u l i 2 0 1 4 / 1 4 0 0 3 R e t h i n k i n g C O I N S / 14003o0842 |
Bijlage 1: participanten in COINS
Organisaties die zijn betrokken bij de ontwikkeling van COINS 1.0:

Arcadis

VolkerWessels

Rijkswaterstaat Dienst Infrastructuur

Strukton Engineering

DHV Ruimte & Mobiliteit

Universiteit Twente

Gemeente Rotterdam

Gobar adviseurs

Movares

SBRCURnet

Ballast Nedam

TNO

Hogeschool Utrecht

Universiteit Eindhoven

Gemeente Utrecht

Saxion Hogeschool Enschede

Tauw

CROW

PSIBouw

ProRail

IBA Ingenieursbureau Amsterdam

Rijksgebouwendienst

Provincie Groningen

BAM

Royal Haskoning DHV

TU Delft

Heijmans

Grontmij

Oranjewoud

Kokon architectuur en stedenbouw

Witteveen+Bos
46